쿠버네티스(Kubernetes)를 활용한 안정적이고 효율적인 운영 환경 구성하기

스캐터랩이 AWS EKS 위에서 CPU 서비스와 GPU 모델 서버를 함께 운영한 배포 환경을 설명한다. GitHub Actions에서 컨테이너 이미지를 만들고 ECR에 올리는 과정부터 Kubernetes 리소스 구성, Pod 간 상태 동기화, TensorFlow Serving과 로그 파이프라인까지 실제 설정을 따라간다. 작은 변경을 자주 검증하고 사람이 승인해 운영에 반영하는 Continuous Delivery가 전체 흐름의 중심이다.

핵심 포인트

기능 브랜치의 테스트·커버리지·스테이징 검수를 통과한 뒤 2명 이상의 리뷰 승인을 받아 master에 병합하고, Release 태그를 기준으로 이미지를 빌드한다.
GitHub Actions는 Release 이벤트에서 버전을 추출해 Docker 이미지 태그로 쓰고 AWS 자격 증명과 ECR 로그인을 거쳐 저장소에 이미지를 푸시한다.
EKS 클러스터에서 CPU 서비스와 GPU 모델 서비스를 nodeSelector로 분리하고 Service·Deployment·HPA·Ingress를 조합한다.
ReplicaSet의 모든 WAS에 요청을 전파해야 할 때 kubectl 사이드카가 Kubernetes API의 Endpoints를 읽어 각 Pod를 직접 호출한다.
TensorFlow Serving은 모델과 설정을 S3에서 동적으로 읽고, 로그는 사이드카를 통해 BigQuery로 스트리밍하며 오류 유형에 따라 Slack으로 알린다.
운영 배포는 Git으로 관리하는 YAML의 이미지 태그를 바꾸고 `kubectl apply`와 `rollout status`로 반영 상태를 확인한다.

상세 정리

배포 원칙: 큰 업데이트를 드물게 수동 배포하는 위험을 줄이기 위해 작은 단위로 지속적으로 검증하고 전달한다. 2020년 8월 20일부터 9월 17일까지 4주 동안 10회 업데이트한 기록을 사례로 든다.
개발 흐름: 기능별 브랜치를 만든 뒤 push할 때마다 CI가 테스트와 커버리지를 검사한다. 스테이징 검수를 거쳐 PR을 만들고, 테스트 통과와 2명 이상의 승인 없이는 병합할 수 없게 했다.
이미지 생성: GitHub Release가 발행되면 Actions가 태그 이름을 이전 job의 output으로 전달한다. 다음 job은 AWS credentials와 ECR login action을 사용해 같은 버전 태그의 이미지를 ECR에 올린다.
운영 승인: 이미지를 만들었다고 바로 배포하지 않는다. 엔지니어의 승인을 거친 뒤 Git에 있는 Pod YAML의 버전을 수정하고 클러스터에 적용해 Continuous Deployment보다 넓은 Continuous Delivery 흐름을 유지한다.
클러스터 배치: 제품별 일반 서비스는 CPU node, 딥러닝 모델은 GPU node에서 실행한다. Deployment의 readinessProbe와 livenessProbe로 트래픽 수용 가능 상태와 생존 여부를 구분한다.
자동 확장과 라우팅: HPA가 Deployment를 확장하고, Ingress 전용 파일에서 URL 경로를 적절한 Kubernetes Service에 연결한다. 실행 단위와 외부 진입 규칙을 분리해 관리한다.
Pod 동기화: 로드밸런서를 거치면 특정 ReplicaSet의 모든 Pod에 요청을 보내기 어렵다. `bitnami/kubectl` 사이드카가 로컬 프록시를 열고 API Server의 Endpoints 목록에서 IP를 얻어 각 WAS에 요청을 전달한다.
권한 조건: 사이드카가 클러스터 정보를 읽으려면 적절한 ServiceAccount가 필요하다. 단순히 kubectl 이미지만 추가해서는 Endpoints API에 접근할 수 없다.
모델 서빙: `tensorflow/serving` GPU 이미지를 쓰고 `--model_config_file`에 S3 경로를 지정한다. AWS key와 region은 Kubernetes Secret과 환경 변수로 주입해 모델 이미지를 설정 파일에 결합하지 않는다.
로그 처리: 로그 유형별 사이드카가 BigQuery로 이벤트를 스트리밍하고 필요한 오류는 Slack으로 알린다. 별도 Airflow 파이프라인은 배치 백업과 정제·분석을 담당한다.
배포 확인: ECR push 후 YAML의 이미지 태그를 변경해 `kubectl apply`를 실행한다. Blue/Green이나 Rolling Update 정책은 환경에 맞게 선택하고 `kubectl rollout status`로 진행 상황을 확인한다.