밀당 IHFB Kubernetes 도입기
들어가며
안녕하세요. 밀당에서 백엔드 및 인프라 담당 고준호입니다.
어제가 입사날 같은데 벌써 개발팀 규모가 2배가 되었습니다. 급속도로 성장하는 밀당에 맞춰 저희 개발팀은 효율적인 개발을 위해 여러가지 ‘현대화’ 작업을 진행하고 있습니다. 저희는 기존 프로젝트의 Kubernetes 이전 작업과 새로운 프로젝트는 모두 Kubernetes를 적용하여 작업하고 있습니다.
Kubernetes 이전 작업을 진행하면서 많은 시행착오와 새롭게 알게된 지식이 많았고 이번 글에서는 도입하는 과정에서 밀당은 어떤 솔루션을 왜 채택하고 적용했는지 소개하도록 하겠습니다.
새로운 비지니스 요구사항의 등장
통합 도메인에서 전문적인 4개의 세부 도메인으로 세분화
기존에는 하나의 레거시 서버에서 CRM/CMS/LMS/B2C 4개의 도메인 서비스를 모두 제공해왔습니다. 각 도메인이 기능이 세분화 되고 크기가 커짐에 따라 의존성 문제와 관리 비용의 상승과 더불어 개발 비용을 상승시키는 문제가 발생합니다. 각 도메인을 분리하여 개발 비용은 낮추고 기존 모놀리식 구조에서 제공하던 데이터의 유기적인 흐름을 모두 만족시켜야 하는 새로운 요구사항이 생겼습니다.
어플리케이션 레벨에서 고도화된 실시간 이벤트 수집
저희 밀당의 서비스의 핵심은 학생의 개인화를 통한 차별화된 교육서비스 제공입니다. 개개인의 정확한 상태 파악을 통해 맞춤 교육 컨텐츠를 제공하고 밀당 선생님들의 세심한 관리가 곧 학생의 성적향상으로 이루어 집니다.
앞으로 고품질의 맞춤형 교육시스템을 제공하기 위해 학생 개개인이 발생시키는 이벤트와 로그를 수집하고 데이터 분석을 통한 학생의 현재 상태를 파악하여 학생의 부족한 부분에 대해 교육서비스를 제공할 수 있어야 합니다. 또한 각 도메인에서 발생하는 데이터들이 유기적으로 연결되어 서로 다른 도메인에서 이를 활용할 수 있어야합니다.
도메인 서비스 기능 요구사항에 따른 유연한 언어의 선택
기존 사용하는 언어와 프레임워크에서 다양한 요구사항을 빠르게 대응하기에 한계점을 느꼈습니다. Kafka나 Kubernetes 같은 스케일러블한 솔루션을 이용하여 마이크로 서비스 마다의 유연한 언어선택이 가능한 환경을 구성할 필요성이 커졌습니다.
위와 같은 새로운 요구사항이 생겨나면서 저희 밀당은 기존 모놀리식한 구조를 탈피한 유연한 인프라환경과 도메인별 서비스 분리의 필요성을 느껴 새로운 인프라구조와 Kubernetes 도입이 불가피하다고 판단했습니다.
밀당이 선택한 도구를 소개합니다.
Terraform
Terraform은 코드로 인프라와 더불어 Kubernetes의 리소스까지 정의하고 관리할 수 있습니다. 밀당이 사용하는 EKS 설정과 Kubernetes의 리소스를 같은 워크플로우내에서 코드로 모두 관리할 수 있다는 점이 장점으로 다가와 선택했습니다.
Github Action
밀당은 프로젝트 관리에 Github을 사용하고 있고 AWS의 다양한 서비스를 이용하고 있습니다. Github Action은 AWS의 다양한 서비스를 쉽게 이용이 가능하고 Github을 사용하고 있다면 workflow만 작성하여 바로 도입이 가능한 점이 장점입니다.
ArgoCD
Gitops 방식인 ArgoCD!! Kubernetes에 설치와 운용이 쉽고 GUI 환경에서 현재 상태를 쉽게 파악할 수 있는 점이 장점으로 다가왔습니다. ArgoCD는 지정된 Github repository를 추적하고 변화를 감지하면 deployment를 Kubernetes에 어플리케이션을 자동으로 배포합니다.
Kustomize
Kubernetes yaml 파일들을 관리하는 솔루션으로 Kustomize를 선택했습니다. kubectl과 ArgoCD에서 native로 지원하고 있고 Github Action에서 Kustomize를 사용하기 쉽습니다. 또한 Github 브랜치 운영 정책에 맞춘 브랜치별 Yaml파일을 관리가 가능하고 Github Action에서 빌드시 새로운 Image Url 로 교체하는 명령어를 제공합니다.
INFRA
기존 인프라관리의 문제점
기존에는 AWS 콘솔로 인프라를 설정하고 관리하였습니다. 이용하는 서비스 종류가 많아 각 서비스 콘솔로 이동하다 보니 관리가 어렵고 효율적인 관리가 어려웠습니다.
새로운 인프라 관리 방법
코드형 인프라(IaC)란?
인프라를 코드로 정의하고 관리하는 솔루션입니다. 코드형 인프라 솔루션을 도입하면 인프라 리소스를 코딩할 수 있습니다. 코드로 관리한다면 버전관리가 가능하여 변경이력을 추적할 수 있다는 장점을 얻을 수 있습니다. 또한 멀티클라우드 또는 하이브리드 클라우드 환경을 하나의 워크플로우 안에서 관리가 가능합니다.
만약 Production,Staging,Develop 환경을 인프라 레벨에서 분리한다면 이미 정의된 인프라 코드를 이용해 똑같이 생성이 가능합니다.
Terraform
Terraform은 HashiCorp사가 만든 오픈소스 IaC 솔루션 입니다. HCL(HashiCorp Configuration Language)를 사용하여 프로그래밍을 통한 인프라 관리를 가능하게 합니다.
인프라의 코드화
코드로서의 인프라를 프로비저닝하여 인적 오류를 줄이고 자동화를 가능하게 합니다. 이제 여러 콘솔 페이지를 돌아다니며 헤메는 일은 그만할 수 있습니다.
클라우드 전반의 인프라 관리
단일 워크플로를 사용하여 인프라를 프로비저닝합니다.
재현 가능한 인프라 생성
동일한 구성으로 일관된 테스트, 스테이징 및 프로덕션 환경을 프로비저닝합니다.
코드로 인프라 정의 → 플랜을 통한 변경점 확인 → 클라우드에 적용
이제 어떤 클라우드 서비스를 사용한다고 하더라도 동일한 워크플로우에서 인프라를 정의할 수 있습니다.
Terraform은 HCL로 정의된 인프라 상태와 클라우드의 인프라 상태를 추적하고 비교하여 HCL로 정의된 인프라 리소스 상태와 일치되도록 프로비저닝을 합니다. Terraform을 이용한다면 인프라 리소스 수정사항에 대해 적용전 미리 확인이 가능하고 적용도 쉽게 가능합니다.
또한 인프라 리소스에 의존적인 Kubernetes의 특정 리소스를 인프라 리소스와 같은 워크플로우에서 관리 할 수 있고 콘솔을 통한 관리 방법에 비해 실수는 줄이고 여러 인프라 리소스를 통합적으로 관리가 가능합니다.
기존 인프라에 대한 Terraform 도입방법
Terraform을 공부하면 대부분의 예제는 없는 인프라에서 Terraform으로 새로 정의하는 예제가 대부분이라 어려움을 겪었습니다. 그래서 이 파트에서는 이미 존재하는 기존 인프라에 대해 Terraform으로 관리를 하는 방법을 소개하도록 하겠습니다.
1. 인프라 리소스를 Import할 비어있는 Terraform 오브젝트 만들기
Terraform Registry에 들어가서 사용하는 서비스의 Provider를 선택하고 오른쪽 상단에 Documentation 탭으로 들어간 후 Terraform으로 관리하려는 인프라 리소스를 검색합니다.
Basic usage를 참고해서 아래와 같이 .tf 파일에 빈 리소스하나를 정의 합니다.
2. 인프라 리소스 Import 하기
Provider 들이 제공하는 인프라 리소스들은 Document 하단에 Import 예시가 있습니다.
명령어를 수행하고 Import가 성공해도 vpc.tf 파일에 정의한 리소스에는 리소스 정보가 기입되어 있지 않아 아직 관리할 수 있는 상태가 아닙니다.
3. 리소스 정보 가져오기
terraform show -no-color 명령어를 수행하면 이전 단계에서 Import 한 vpc 리소스가 출력됩니다. 이 정보를 복사하여 .tf 파일의 리소스 오브젝트에 기입합니다.
4. Terraform plan 명령어로 설정 불가능한 옵션 제거하기
terraform plan 명령어를 수행한다면 아래와 같은 error가 출력됩니다.
우리가 복사해온 옵션중에는 arn과 같이 설정이 불가능한 옵션이 같이 들어있어 제거해 주어야 비로소 해당 리소스를 Terraform으로 관리가능한 상태가 됩니다.
Error가 출력된 모든 설정을 제거해주고 terraform plan 명령어를 수행하면 No changes. Your infrastructure matches the configuration. 메세지가 출력됩니다. 비로소 우리가 정의한 terraform 리소스가 현재 존재하는 인프라 리소스와 상태가 일치됨을 나타냅니다.
자! 이제 Terraform으로 VPC 리소스를 관리할 수 있게 되었습니다. 이 리소스의 수정을 원한다면 수정하고자 하는 옵션을 변경후 terraform apply 를 실행하면 수정사항이 반영됩니다. 이렇게 Import 하는 과정을 테라포밍이라고 하며 관리하고자 하는 인프라 리소스를 모두 테라포밍 하시면 됩니다.
위 방법 말고도 Terraformer 와 같이 리소스 imort를 쉽게 해주는 프로젝트가 존재하니 참고하시길 바랍니다.
Terraform을 도입한 후 인프라 관리의 장점
실수가 두렵지 않다.
새로운 클라우드 서비스를 도입하면 시행착오를 많이 겪습니다. 더군다나 서비스가 운영중인 상태라면 실수 할까 굉장히 두렵습니다. 하지만 Code로서 인프라를 관리하고 Apply 하기전 Plan을 통해 현재 상태가 어떻고 앞으로 어떤 인프라 리소스가 변경될지 미리 확인해 볼 수 있기 때문에 오류를 사전에 방지 할 수 있습니다. 또한 실수를 했다고 하더라도 이전 상태로 돌아가는 일이 매우 쉽습니다. 선언한 resource를 삭제하거나 이전 상태를 기억하는 backup state 파일을 이용하여 되돌리기만 하면 됩니다.
디버깅이 쉽다.
공식문서를 참고하여 콘솔을 이용하여 새로운 서비스를 설정하다보면 알게 모르게 다양한 리소스가 같이 생성됩니다. 어떤 리소스 설정에서 실수하여 재대로 작동하지 않는지 파악하기가 굉장히 힘들었습니다.
Terraform을 이용하면 현재 상태의 모든 리소스가 코드로서 정의되어 있기 때문에 차근차근 설정 들을 살펴보며 디버깅을 할 수 있었습니다.
도입이 쉽다.
Terraform Registry에는 어떤 인프라 리소스를 적용할때 하위 리소스가 많이 필요한 경우 Module로 패키징한 형태로 제공될 수 있습니다. Module을 이용한다면 Boiler plate 없이 훨씬 빠르게 새로운 클라우드 서비스를 도입할 수 있습니다.
Terraform으로 EKS를 새로 생성하면서 쉽게 설치가 가능했고 기존에 eksctl로 설치했을때 발생했던 Worker Group이 인식되지 않아 scale이 불가능 했던 문제가 해결되었습니다. Instance type을 변경하기가 매우 쉬워졌습니다. 그저 Instance type을 변경하고 terraform apply 만 하면 변경되니까요.
Terraform Module을 이용하여 EKS ( Kubernetes )를 도입할 때 같이 관리하면 좋은 모듈입니다.
- eks-external-dns
- alb-ingress-controller ( aws_alb_ingress_controller_version = 1.19 )
- eks-argocd
KAFKA ( MSK )
밀당의 카프카 도입에 대한 내용이 궁금하시다면 이전 블로그글 참조
CI/CD
CI (Continuous Integration)
지속적으로 품질을 유지하면서 코드의 통합을 하기위한 개념 입니다.
일반적으로 기능개발 후 Main 브랜치로의 통합 과정은 BUILD — TEST — MERGE 순으로 일어납니다. 위 파이프 라인을 자동화 하여 코드 품질을 유지하면서 쉬운 통합을 가능하게 합니다.
CD (Continuous Delivery & Deployment)
CI 과정을 거치고 만들어진 신뢰할만한 어플리케이션 코드를 지속적으로 배포될 수 있도록 하는 개념입니다.
ArgoCD와 같은 CD 솔루션을 이용하여 파이프라인을 자동화한다면 개발자의 코드변경 사항이 CI 과정을 거처 레포지토리에 통합되고 Production 레벨까지 릴리즈 될 수 있습니다.
기존에는 개발자의 변경사항을 통합하는 과정과 어플리케이션을 배포하는 과정이 분리 되어있었다면, CI/CD Pipeline을 구축하여 서비스 개발 과정과 운영 과정을 통합할 수 있습니다.
기존 밀당의 CI/CD 과정
기존에는 Main, Develop 2단계 브랜치를 운영하였고 기능 개발 후 Develop 브랜치에 통합하고 추후 Main브랜치에 통합하면 AWS Code Deploy를 이용하여 EC2 Instance로 배포되었습니다.
EC2 Instance에서 Kubernetes로 이전하게 되면서 AWS CodeDeploy가 지원하지 않으면서 새로운 CD 솔루션을 찾아야 했습니다. 그 외에 ACM이나 Route53과 같은 서비스는 배포과정과 별개로 설정을 따로 해줘야하는 불편함이 존재합니다.
새로운 밀당의 CI/CD
새로운 CI/CD 과정에서는 Production,Staging,Develop 브랜치 각각 Kustomize로 Yaml파일들을 프로젝트 소스코드와 같이 관리하고 브랜치 운용절차에 맞게 코드를 Merge하면 위 과정을 통해 자동으로 통합되고 브랜치에 맞는 POD에 Kubernetes로 배포됩니다. 또한 Service와 Ingress의 annotation 설정에 따라 ALB의 자동 생성과 더불어 Route53 서브 도메인 설정과 ACM의 인증서가 ALB로 자동 연동됩니다. 이제 개발자는 그저 코드를 수정하고 Merge만 한다면 배포까지 자동화 되어 진행됩니다.
Kustomize
밀당의 새로운 프로젝트는 Prod,Staging,Production 레벨로 브랜치를 관리하고 있습니다. 각 브랜치마다 Kubernetes에 자동으로 배포가 되고 있습니다. 브랜치 마다 Kubernetes 리소스 정의는 사소하게 다르지만 대부분 공통된 Yaml 파일을 공유합니다. Kustomize는 이러한 브랜치 운영 컨셉에 딱맞는 Kubernetes 리소스 파일 관리 솔루션입니다. 각 환경에 Namespace,Name Prefix 등 공통 옵션을 쉽게 주입할 수 있고 각 환경별로 리소스를 구분하여 관리할 수 있습니다.
또한 빌드 과정에서 컨테이너 이미지 주소가 바뀌는데 Yaml에서 이미지 주소만 쉽게 교체할 수 있는 명령어를 제공하고 Github Action ( CI/CD ) 과정에서 Kustomize 플러그인을 제공하고 있으며 빌드시 새로운 이미지 주소로 쉽게 교체할 수 있습니다.
기타 환경
Route53
Amazon Route 53은 AWS에서 제공하는 DNS 이고 도메인과 관련된 다양한 서비스를 제공합니다. Route53은 AWS 서비스 답게 EKS와 연동이 잘 됩니다. Kubernetes에 external DNS를 설치하면 k8s Service 파일에 annotation설정만으로 ALB에 서브 도메인 연결을 자동화 할 수 있습니다.
ACM
AWS Certificate Manager는 AWS에서 제공하는 인증서를 손쉽게 관리 및 배포할 수 있도록 지원하는 서비스입니다. ACM은 SSL/TLS 인증서를 구매, 업로드 및 갱신하는 데 드는 시간 소모적인 수동 프로세스를 대신 처리해줍니다.
ACM 또한 EKS와 연동이 매우 잘됩니다. kubernetes에 ingress controller를 사용할때 annotation 설정을 해주면 쉽게 Https 적용이 가능합니다. ingress controller 종류에 맞게 annotation 설정이 다르니 문서를 참고하셔서 설정하길 바랍니다.
마무리
개발자가 아주 많은 큰 팀을 제외하고는 많은 스타트업 개발팀에서 백엔드 개발자들이 인프라 관리를 같이 하고 있으리라 생각합니다. Kubernetes, Terraform,CI/CD 파이프라인 구축 이 세가지를 도입하면서 느낀점은 운영과 개발 워크플로우를 일치 시킬 수 있는 가장 좋은 방법(literally DevOps)이고 백엔드 개발자는 개발에만 몰두 할 수 있습니다. 이제 개발 외적인 요소로 스트레스 받을 일이 정말 줄었습니다. 왜냐하면 대부분 자동화가 되어있으니까요!!
고민은 도입만을 늦출 뿐 …
이번 작업을 진행하면서 기술 각 요소에 대한 자료는 충분했으나 한번에 어떤 조합으로 사용해야 하는지에 대한 통합적 관점의 자료가 부족했었다고 느꼈습니다. 이 글을 통해 Kubernetes나 Terraform 도입을 고민하는 많은 분들이 도움이 되었길 바랍니다.
여기까지 밀당이 Kubernetes 서비스 환경을 구축하기 위해 필요한 작업들을 소개해봤습니다.
백엔드 팀에서 동료를 찾고 있습니다!
밀당 영어가 최근 급성장하여 에듀테크 유니콘이 되기 위해 새로운 시스템을 개발하고 있습니다. 데이터 파이프라인 구축부터 인프라 개선 등 기존 레거시에 존재하는 다양한 문제를 해결, 개선하고 있습니다. 새로운 도전을 즐기시는 분들과 함께 하면 교육의 혁신을 더욱 빠르고 멋지게 이룰 수 있을 것 같습니다!
