이 글은 Kubernetes, AWS와 같은 인프라에 대한 설명이 아닌, 인포팀의 인프라 팀인 이카루스에 대한 이야기입니다. 기본적인 인프라에 대한 이해만 있어도 글을 충분히 읽을 수 있지만, Kubernetes와 클라우드에 대한 이해가 있으면 더 폭넓게 이해할 수 있습니다. 추후에 다른 글에서 각각의 요소에 대해서 구체적으로 다뤄볼 예정이에요!
안녕하세요. 인포팀에서 잡부..를 담당하고 있는 이보성입니다.
인포팀에는 인프라를 관리하는 팀, icarus가 존재해요.
이 글에서는 이카루스가 어떤 팀이고 왜 존재하는지, 어떤 일을 하는지에 대해서 소개할까 합니다.
지금의 이카루스에 대해 이야기하기 전에 제가 입부한 2023년부터 어떻게 인프라가 발전하였는지 이야기하려고 해요.
Back to the 2023
인포팀은 2023년부터 인프라 기술이 남달랐습니다.
인포팀에 입부하기 전에 Docker와 nginx의 reverse proxy를 가지고 서버를 띄우는 것은 해보았지만, IaC가 본격적으로 도입 되어있는 도커는 처음 보았습니다.
Lightsail
예전부터 인포팀의 모든 서비스들은 Lightsail을 통해서 돌아가고 있어요.
Lightsail은 AWS에서 지원하는 경량 클라우드 인스턴스로, 컴퓨팅 인스턴스로 유명한 서비스인 EC2보다 저렴한 가격으로 동일한 성능을 낼 수 있습니다.
정확하게 기억은 안 나지만, 초기에는 월마다 24$의 요금을 내고 있었던 것 같습니다.
Terraform
인포팀은 인프라 형상을 관리하는데부터 IaC(Infrastructure as Code)를 사용하고 있습니다.
lightsail을 제외한 s3, iam, ecr 뿐만 아니라 cloudflare로 관리하고 있는 DNS까지 모두 terraform을 통해서 관리하고 있었으며, 굳이 콘솔에 접근하지 않아도 인프라가 어떻게 구성 되어있는지 확인하고 수정하기에 용이했습니다.
Traefik
인포팀에서는 nginx 대신에 traefik을 사용하고 있었습니다.
traefik도 nginx처럼 reverse proxy를 제공하고 있어서 백엔드 서버를 도커로 띄운 다음에 reverse proxy를 사용하여 도메인 주소에 따라서 적절하게 라우팅 되게끔 했습니다. 이때에는 프론트엔드 코드도 서버에서 직접 서빙하고 있었기 때문에
traefik → nginx → static files와 같은 구조도 가졌습니다.GitHub Actions
GitHub Actions를 사용한 CI/CD 파이프라인을 구축해서 git에 푸시를 하면 자동으로 빌드와 배포가 되는 방식을 사용하고 있습니다.
빌드 과정에서는 GitHub Actions에서 제공하는 runner를 사용해서 ecr에 푸시하고, 배포 과정에서는 도커 이미지의 sha를 gitops 레포지토리상에 기록한 다음에 scp-action과 ssh-action을 사용해서 바뀐 파일을 서버에 동기화하고 deploy 스크립트를 실행하는 방식으로 동작합니다.
2024 : Kubernetes
2022년 말부터 이러한 체계를 갖추게 된 것은
인프라를 모르는 부원들도 충분히 배포를 할 수 있게끔 하자! 였습니다. 하지만, 점점 더 복잡한 구성을 가지게 되었고, reliable 하지 않았습니다.또한 traefik을 사용한 배포시에 blue green배포 방식을 사용하고 있지 않았기 때문에 백엔드를 업데이트할 때 30초에서 2분정도 서비스가 중단되는(503 Service Unavailable) 현상이 있었습니다.
docker stop으로 중단 후에 docker run으로 컨테이너를 다시 띄웠기 때문에 cold start를 기다리는 시간이 필요했습니다
이때 인포팀 내부적으로 클라우드, 쿠버네티스에 대한 스터디가 진행되려는 움직임이 있었고, 그 덕에 인포팀의 인프라도 발전할 수 있는 발판이 마련되었습니다. k3s 스터디로 시작된 채널이 지금의 icarus 팀이 되었어요.
인포팀은 금전적인 지원을 받아서 운영되는 조직이 아니기 때문에, Kubernetes를 도입할 때 가장 먼저 우려 되는 것은 비용이었습니다. AWS나 GCP와 같은 클라우드에는 Kubernetes를 편리하게 사용할 수 있는 관리형 서비스들이 존재하는데, 이는 관리형 서비스를 사용하는데에만 비용이 청구 됩니다. Kubernetes 뿐만 아니라 RDS도 비용 문제로 채택할 수 없었기 때문에, k3s를 구성하는데에 DB를 어떻게 띄우고 백업할지도 계획이 필요했습니다.
k3s
그래서 Kubernetes를 사용할 수 있는 환경을 직접 노드에 구성을 하고자 하였고, k8s 대신에 경량 k8s인 k3s를 사용하였습니다. 또한 Kubernetes를 사용하는 목적에 맞게 다중 노드로 구성하였습니다. control-plane의 경우에는 medium, worker의 경우에는 small lightsail 노드를 사용했습니다.
그리고 Kubernetes상에서 돌아가고 있는 서비스 몇가지 들을 더 소개하고자 합니다.
ArgoCD
우리는 ArgoCD가 있어서 편하게 배포 자동화를 할 수 있습니다. 이를 gitops라고 부르는데, github에 kubernetes manifest 파일들을 모아 두면 ArgoCD가 이 레포지토리의 변경사항을 추적하게 되고, 항상 git에 있는 manifest와 같은 형상을 유지하려고 합니다.
cert-manager
HTTP 기반의 서비스를 안전하게 제공하기 위해서는 TLS 설정이 필수입니다. TLS 인증서는 letsencrypt를 통해서 무료로 받을 수 있고, cert-manager를 사용한다면 이 과정을 더 편하게 자동화 할 수 있죠.
Infisical
서버를 운용할 때에는 시크릿 관리가 필수적이에요. 특히 2023년 하반기부터는 인포팀이 운영하는 거의 모든 레포지토리를 public으로 전환하고자 했기 때문에 크리덴셜을 코드에 하드 코딩하는 것은 불가능해요. 2023년에 Docker 기반으로 서비스를 운영할 때에는 env file을 사용해서 도커 실행시에 주입 시키는 방식으로 사용했습니다. 즉, 시크릿을 바꿔야하는 경우에는 서버에 직접 ssh로 접속해서 바꾸어야 했습니다. 하지만 Kubernetes의 특성상, 시크릿을 특정 노드가 관리할 수 없고 kubernetes 상에서 관리하도록 해야합니다. 다행이도 Kubernetes의 Secret을 사용해서 Opaque 타입으로 설정한다면 원하는 문자열을 담을 수 있기는 한데, 그렇다고 이 secret도 plain-text로 넣어서 gitops로 관리할 수는 없습니다. 이를 gitops를 사용해서 관리할 수 있는 방법으로 sealed-secrets라는 것이 있습니다. 시크릿을 암호화하여서 gitops로 관리하면 실제 Kubernetes가 sealed-secret을 읽어서 secret을 생성해주는 방식이에요.
하지만 이 방식도 항상 좋지만은 않았어요. 인포팀에는 여러명의 개발자가 있기 때문에 시크릿에 접근 해야하는 사람들이 한둘이 아니에요. 이 사람들끼리는 시크릿 원문을 알고 있어야하는데, 이를 Slack으로 공유를 하는 것? 그렇게 할 수는 없겠죠. 그래서 다른 방법을 찾아보던 중, infisical이라는 self-hosting이 가능한 서비스를 찾았습니다. infisical을 띄워서 서비스별로 프로젝트를 만들고, 프로젝트 내에서도 환경을 여러개 만들어서 환경별로 맞게 시크릿을 관리하고 시크릿을 넣어줄 수 있게 됩니다.
2025 : Now, icarus
올해에 들어서 이카루스를 포함한 인포팀의 목표는 “안정화”입니다. 어떻게 하면 적은 비용으로 이 인프라를 굴릴 수 있을지, 더 단단하게 서비스를 굴릴 수 있을지 고민 하고 있습니다. 지금도 인포팀에는 외부에 공개되지 않거나 내부로 돌아가고 있는 다양한 서비스들이 있습니다. 이러한 서비스들은 점점 더 늘어날 것이기 때문에 이에 대한 대비가 필요합니다. 인포팀 서버에는 내부 서비스와 스테이징 서버를 포함하여서 26개의 deployments가 쿠버네티스 상에 존재합니다. k3s나 argocd와 같은 것까지 생각하면 총 40개의 deployments들과 76개의 pods가 띄워져 있는 상태에요. 늘어난 인프라 요구에 대응하기 위해서 인스턴스의 사이즈도 large로 사용하고 있습니다.
이 때문에 노드의 메모리는 정상적이라고 할 수 없는 상태를 유지하고 있습니다. (ㅜㅜ) 조금만 건드려도 뻑이 날 수 있는 상황이죠. 한번은 kubernetes manifest 파일을 모두 한번에 수정하는 바람에 pods의 개수가 두 배가 된 적이 있었습니다. 당연히 우리의 서버는 이를 버티지 못하였고, 이와 같은 일 때문에 lightsail 콘솔을 통해서 강제로 재부팅 해야했던 적이 여럿 있습니다.
DB 백업
그리고 정말 놀랍게도 이카루스팀의 인력난으로 인해 (또는 귀찮음) DB가 MySQL에서 PostgreSQL로 마이그레이션 된 이후 백업이 붙어있지 않았었습니다. 올해 초 PostgreSQL도 백업 체인을 구축하였고, 이외에도 더 단단한 인프라를 만들기 위해서 더욱 고민 중입니다.
로그 시스템
우선 제일 큰 과제로는 백엔드 엔지니어들과 같이 협업하여 로그 시스템과 모니터링 시스템을 구축하고자 하고 있습니다.
비용 절약하기
이외에도 ECR로 관리하고 있던 Container Registry를 GitHub에서 제공하는 Package로 바꾸었고, GitHub의 공개 레포지토리에서는 GitHub Actions의 제한 시간이 없기 때문에 GitHub Actions로 CI/CD 파이프라인을 꼼꼼하게 달아서 더 탄탄한 코드를 만들기 위해 노력하고 있어요.
마치며…
이 모든 것은 제가 혼자였다면 절대 할 수 없는 일이었습니다.
인포팀에 있으면서 원래하던 개발과는 다른 도메인의 지식을 많이 습득하고, 또 이를 실제로 적용도 해볼 수 있는 좋은 기회를 가지게 되었습니다.
열정적으로 서포트 해주고 도와주며 같이 이뤄내간 우리 이카루스 팀원들과 인포팀원들에게 감사를 바칩니다.