개요
안녕하세요. WATCHA 에서 서버 개발을 하고 있는 Allan 입니다.
이번 포스팅은 WATCHA 에서 사용하고 있는 서비스 인프라를 Kubernetes 로 변경한 스토리를 이야기해보고자 합니다.
바야흐로 2020년 12월 말, 서버 및 인프라 시니어 개발자들이 모여 2021년 한해
목표를 논의하는 중에 아래와 같은 의견이 나왔습니다.
현재 폭발적으로 사용자가 증가하고 있다.
게다가 추가적으로 진행될 서비스들이 준비되어 있어 MSA가 더욱 가속화 될 것이다.
그것에 맞추어 서비스 인프라를 Kubernetes 기반으로 이전하자.
참가자들이 해당 의견에 동의하면서, 2021년 1월 Kubernetes 원정대에
3인의 개발자들이 참전하게 됩니다. 🎉
What’s Kubernetes?
Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
이전 WATCHA 에서는 AWS EC2 를 직접 운영하거나, ElasticBeanstalk 를 이용해서 EC2 또는 ECS 기반으로 운영하고 있었습니다.
하지만 Kubernetes로 이전 하면서 각 서비스 개발자들이 인프라담당자 지원 없이도
손쉽게 원하는 자원(CPU, Memory)을 이용하여 서버를 운영해 볼수 있으며
배포와 각종 설정을 코드 또는 YAML 로 관리하여 서비스 서버에 관련된 모든 설정 들을 한곳에 모으기 용이 했습니다.
게다가 빠른 배포와 자원을 효율적으로 이용할수 있었습니다.
물론 단점도 있습니다.
운영 관리가 어렵다. 사용이 어렵다. 진입장벽이 꽤 높다 … 등이 있습니다.
(결론은 어렵다는 것입니다. 😮💨)
그럼에도 불구하고, 장점이 단점보다 크기 때문에 많은 IT 회사에서 Kubernetes 로
이전하고 있고, WATCHA 도 Kubernetes 로 이전하게 되었습니다.
EKS VS GKE ?
WATCHA 에서는 AWS 와 GCP 모두를 운영을 하고 있습니다.
그래서 각 클라우드서비스 관리형 Kubernetes 서비스인 EKS 와 GKE
둘다 검토 대상이었습니다.
하지만 서비스에서 사용하는 주요 자원들이 AWS 에 종속된 상황이기때문에
GKE를 사용하기에는 많은 사이드이펙트가 우려되어 결국은 EKS를 선택하게 되었습니다. (개인적으로는 GKE 를 선호합니다.)
물론 Google Anthos 이용하여서 AWS 에서 Kubernetes 를 운영하는 방안도 고민해 보았으나 이것 또한 적용사례를 찾아 볼수 없었고, 사이드이펙트가 우려되어 고려 대상이 아니었습니다.
EKS NodeGroup VS EKS Fargate ?
AWS EKS 에서는 Node 들을 NodeGroup 또는 Fargate 로 운영이 가능합니다.
NodeGroup는 EC2 머신을 사내 인프라 관리자들이 업데이트 및 관리를 하고
Fargate는 EC2 머신을 AWS에서 직접 업데이트 및 관리를 해주는 차이점이 있습니다.
하지만 Fargate를 아래와 같은 단점이 있습니다.
- Daemonset 을 이용할수 없다.
- SecurityContext 를 이용할수 없다. (권한 문제)
- Istio 같은 Service Mesh를 이용할수 없다. (권한 문제)
- 사용할 머신 타입이 제한이 있다. (GPU 머신 사용 X)
- 트러블슈팅이 어렵다. (접근이 제한되어 있음.)
EKS Fargate 특성상 1 Node 에 1 Pod 만 가능해서 구조상 Daemonset 이 뜰수
없으며, AWS쪽에서 직접 운영 하기때문에 권한이 제한되어 있습니다.
그래서 특정 ROOT 권한이 필요한 SecurityContext 를 이용할수가 없고, Istio
도 이용할수 없습니다.
하지만 Fargate 를 이용하면 인프라 관리자들이 관리포인트가 줄어들고,
1 Node에 1 Pod 구조만 가능하여 같은 Node 에 떠 있는 특정 Pod의 영향으로 인한
성능저하를 일으킬수 있는 이슈가 없고 머신 성능을 풀로 사용할수 있어서
상황에 맞게 사용하면 좋습니다.
물론 WATCHA에서는 서비스 종류에 따라 NodeGroup 과 Fargate 를 동시에
이용하는 하이브리드 구조로 운영하고 있습니다.
EKS 운영하기 위한 기본적인 패키지들
EKS NodeGroup 및 EKS Fargate 를 운영 하기 위해서 필요한 패키지들이
매우 많습니다. 그중에서도 중요한것들만 정리해보면 아래와 같습니다.
- PROMETHEUS: 매트릭 수집 저장 및 커스텀 오토스케일링(HPA)사용
- METRIC-SERVER: 노드의 리소스 매트릭 수집 및 오토스케일링(HPA)에 사용
- CLUSTER AUTO SCALER: NODE 가 부족할시 자동으로 NODE를 늘려줌.
- AWS LOAD BALANCER CONTROLLER: Ingress 및 service 생성시 AWS NLB 또는 ALB 를 프로비저닝.
- EXTERNAL DNS: Ingress 와 service 에 연결된 AWS NLB, ALB 에 쉽게 도메인을 연결.
- EXTERNAL SECRETS: AWS Secrets Manager 등록된 Key, Value 들을 쉽게 Container 쪽 주입.
전체 구조
아래는 3편의 블로그 포스팅으로 공유 해보려고 하는 개략적인 전체 구조 입니다.
사용한 기술 스택
사용한 기술 스택에 대해서 아래와 같이 파트 별로 정리 해보았습니다.
PART 1
- Fluent-Bit: Fluentd 의 경량버전입니다. C로 구현되어 있고, 라이브러리에 의존성이 없습니다. 가볍고 빨라서 대용량 로그 수집에 최적화 되어있습니다.
WATCHA 에서는 POD 에서 수집한 로그를 로그플랫폼으로 전달하기 위해 사용하고 있습니다. - DataDog: 다양한 모니터링 서비스를 제공하는 솔루션 입니다.
WATCHA 에서는 AWS 와 GCP 및 EKS 인프라 모니터링에 이용하고 있고,
각 서비스 별로 Opentracing 또는 Opentelemetry 를 활용해서 서비스 성능 측정 및 개선을 위한 APM 과 OpenMetrics 을 이용해서 모니터링 지표를 수집합니다. - App Mesh: AWS 에서 서비스로 제공하는 Service Mesh 솔루션입니다.
EKS Fargate 에서는 Istio 같은 Service Mesh를 사용할수 없어, 대안으로
App Mesh 를 이용하고 있습니다. Istio 와 비슷하게 Pod의 Sidecar 로 Envoy 를 이용합니다.
WATCHA 에서는 Service Mesh 솔루션으로 App Mesh 를 이용하고 있습니다.
PART 2
- Gloo Edge: 오픈 소스로 개발중인 API GATEWAY 입니다.
Control Plane 으로 Golang 개발된 Controller 와 Data Plane 으로
Envoy 를 이용하고 있습니다. Kubernetes 친화적으로 다양한 CRD를 지원합니다.
WATCHA 에서는 API GATEWAY 로 Gloo Edge를 이용하고 있습니다.
자세한 설명은 PART 2 블로그 포스팅때 이야기 해보도록 하겠습니다.
PART 3
- HELM: Kubernetes에서 이용하는 패키지 매니저입니다.
WATCHA 에서는 Application 배포할때 Helm Chart 를 작성해서
배포를 하고 있습니다. - CircleCI 와 Github Action: CI/CD에 사용하는 솔루션입니다.
WATCHA 에서는 테스트와 도커 이미지 생성 및 배포에 해당 솔루션을
사용하고 있습니다. - ArgoCD: Kubernetes 에 Application 배포를 위해 사용하는 솔루션입니다.
ArgoCD는 사용하기 쉬운 UI 를 제공하며 다양한 Repository 를 이용하여
Canary 와 Blue-Green 형태의 배포를 지원합니다.
게다가 지속적으로 상태를 감지하면서 Sync를 맞춰주며, 문제 발생시 쉽게
롤백도 할수 있습니다.
WATCHA 에서는 서비스 배포에 ArgoCD를 이용하고 있으며, 자세한 설명은
PART 3 블로그 포스팅때 이야기 해보도록 하겠습니다.
POD 내 CONTAINER 구조
각 서비스별로 차이는 있지만, WATCHA 에서 일반적으로 Pod 내에 구동되는 Container 들은 아래 그림과 같습니다.
보통 Sidecar Container 로 FluentBit, Datadog Agent, Envoy(App Mesh)
3개의 Container가 뜨게 됩니다.
맨 앞에 App Mesh 가 Service Mesh 역할로써 모든 Inbound 와 outbound 트래픽을 제어합니다. 익명의 Inbound 또는 outbound 요청을 차단하여 보안적으로 좋습니다.
게다가 App 서버에서 일시적으로 에러 발생시 Retry 및 Timeout 기능도 제공하고
장애상황에 대비하여 Circuit Breaker 와 Rate Limit 기능도 제공합니다.
DataDog Agent 는 App 에서 발생하는 다양한 metric 을 App 코드에 큰 변경 없이도 손쉽게 수집이 가능하며, Opentracing 및 Opentelemetry 기반을 데이터를 수집하여서 손쉽게 APM 을 사용할수 있도록 해줍니다.
가장 큰 장점은 metric 통합하여 서비스들간 연관관계를 손쉽게 UI로 확인
가능하며, 장애 대응 및 분석에도 좋습니다.
FluentBit 는 App 에서 발생하는 RAW 한 로그를 수집하여 WATCHA 로그플랫폼으로 전송합니다. 이렇게 수집된 로그는 BigQuery 에 저장되어서 데이터 분석에 활용하고 있습니다.
Conclusion
지금 까지 간략하게 PART 1- 전반적인 소개 및 POD 내 CONTAINER 알아보기 에
대해서 알아보았습니다.
이글 전체에 담을수 없지만 Kubernetes 인프라를 구축 하면서 많은 삽질과 좌절 😂로
고생하신 Kubernetes 원정대 분들의 노력이 있었습니다.
그리고 컨테이너와 Kubernetes 에 익숙하지 못한 서비스 개발자 분들도 고생 끝에
단기간에 모든 서비스를 Kubernetes 로 이전 하시느라 많은 노력을 하셨습니다.
고생하신 모든 분들께 감사하다고 말씀드리고 싶습니다.
Kubernetes 인프라를 구축 하면서 삽질😂 끝에 알게된 노하우들도 해당 시리즈 블로그 외에도 다른 블로그 포스팅에서 하나하나 공유해 보도록 하겠습니다.
다음 포스팅은 PART 2 — Api-Gateway 대해 포스팅 해보도록 하겠습니다.
WATCHA에서는 다양한 기술들을 활용해 서비스를 지속적으로 개선, 발전시켜 갈 실력 있고 뜻있는 개발자들을 모집하고 있습니다. 관심있는 분은 채용공고를 참고해주세요.
