1. Kubernetes 도입 조건 정의 - 100-hours-a-week/KTB4-13th-wiki GitHub Wiki
1. Kubernetes 도입 필요성 분석
1. 성장 규모 가정
v2의 장기 목표는 MAU 100만 명이었다. v3에서는 교보문고 광고센터 자료에 나온 월 활성 고객 수 약 900만 명을 성장 기준으로 잡았다.
사용자의 월평균 이용일은 v2와 동일하게 3일로 가정한다.
MAU 900만 명 × 월평균 이용일 3일 ÷ 30일 = 평균 DAU 90만 명
사용자 행동과 세션당 요청 수도 v2와 같다고 보고, 평상시 Peak Traffic은 v2의 625 RPS에 MAU 증가 비율을 적용했다.
625 RPS × 9 = 약 5,625 RPS
| 항목 | v2 | v3 |
|---|---|---|
| 목표 MAU | 100만 명 | 900만 명 |
| 평균 DAU | 10만 명 | 90만 명 |
| 평상시 Peak Traffic | 약 625 RPS | 약 5,625 RPS |
트래픽이 약 9배 증가하면 Application을 실행하는 Task 수와 이를 배치할 EC2 서버 수도 늘어난다. 그러나 v3에서 운영 플랫폼을 다시 검토하게 된 직접적인 배경은 규모뿐만 아니라 서비스와 조직이 함께 나뉜다는 점이다.
2. 서비스와 조직의 변화
v2까지는 개발자 6명이 Frontend, Backend, AI Server와 인프라를 함께 관리했다. v3에서는 한 팀이 모든 기능의 변경과 배포를 맡기 어려워졌다고 보고, 변경 주기와 운영 특성이 다른 영역을 별도의 팀과 Repository로 분리한다.
| 팀 | 담당 영역 | Repository와 배포 단위 |
|---|---|---|
| 서비스 팀 | 회원, 도서 상세, 리뷰, 나의 도서관 | Core Backend |
| 주문·결제 팀 | 장바구니, 주문, 결제 | Order Service |
| 검색 팀 | 일반 검색, 자연어 검색 | Search Service |
| AI 팀 | 자연어 도서 추천·추가 질문, 이미지 도서 인식 | AI Server |
| 프론트엔드 팀 | 사용자 화면 | Frontend |
| 클라우드 팀 | AWS 인프라, 배포, 모니터링, 공통 운영 환경 | Infra·GitOps |
v2에서는 회원, 주문·결제, 도서 조회·검색, 리뷰, 나의 도서관 기능을 하나의 Backend에서 함께 운영했다.
v3에서는 기능별 변경 주기와 운영 요구사항이 다른 영역을 분리해 각 팀이 독립적으로 관리하도록 한다.
회원·도서 상세·리뷰·나의 도서관은 Core Backend에 유지한다.
주문·결제는 기능 변경 시 결제 흐름과 데이터 정합성을 별도로 검증해야 하므로 Order Service로 분리한다.
검색은 도서 정보 변경에 따른 색인 갱신이 필요하고, 검색량에 맞춰 독립적으로 확장해야 하므로 Search Service로 분리한다.
AI Server는 추천 품질과 이미지 인식 정확도를 개선하는 과정에서 모델, 프롬프트, 전처리 로직이 자주 바뀐다.
AI Server는 모델 로딩과 이미지 처리로 일반 API보다 높은 CPU·메모리를 사용할 수 있다. v3에서는 AI Server의 자원 사용이 Core Backend, Order Service, Search Service의 요청 처리에 영향을 주지 않도록 Workload별 자원 할당과 배치 기준을 분리할 필요가 있다.
따라서 네 Application의 배포 시점을 하나로 맞추지 않는다. 검색 기능을 변경했다고 주문·결제까지 다시 배포하거나, AI Server 배포를 위해 Core Backend의 일정을 기다리지 않도록 각 팀이 담당 Repository에서 개발하고 별도로 배포한다.
Frontend는 기존 배포 방식을 유지한다. 이번 Kubernetes 검토 범위는 Core Backend, Order Service, Search Service, AI Server다.
v2에서는 App과 AI를 각각 ECS Service로 운영하며 서비스별 실행 수와 Auto Scaling 기준을 관리했다. v3에서는 Core Backend, Order Service, Search Service, AI Server가 각각 다른 요청 특성과 자원 사용량을 가지므로, 서비스 수가 늘어날수록 실행 설정·배치·확장 정책을 공통 기준으로 관리할 필요가 커진다.
3. 기존 운영 플랫폼과 Kubernetes 비교
현재 북적북적은 ECS on EC2에서 운영하고 있다. ECS에서도 Application을 각각 Service로 분리하면 독립 배포가 가능하고, 서비스별 자원 할당과 Auto Scaling도 설정할 수 있다.
따라서 ECS에서 구현할 수 없는 기능이 있어서 Kubernetes를 검토하는 것은 아니다. v3에서 중요한 것은 네 팀이 서로 다른 일정으로 배포하면서도 자원 관리, 상태 확인, 배포와 롤백 같은 운영 기준을 일관되게 유지할 수 있는지다.
이 기준으로 현재 운영 방식인 ECS on EC2와 Kubernetes를 비교한다.
| 비교 항목 | ECS on EC2 | Kubernetes |
|---|---|---|
| 독립 배포 | ECS Service별로 배포 | Application별 Deployment로 배포 |
| 자원과 배치 | Task별 CPU·메모리를 설정하고 EC2와 AZ에 배치 | Application별 자원과 배치 조건을 같은 리소스 정의에 기록 |
| Auto Scaling | ECS Service와 EC2 용량을 각각 확장 | Pod와 Node를 각각 확장하며 서비스별 지표를 연결 가능 |
| 공통 설정 적용 | Service 실행 설정과 배포 파이프라인에서 관리 | 공통 Helm Chart와 Application별 Values로 관리 |
| 배포 상태 관리 | ECS Service 상태와 CI/CD 실행 결과를 각각 확인 | Git에 선언한 상태와 Cluster의 실제 상태를 지속해서 비교 |
| AWS 연동 | IAM, ALB, CloudWatch 연동이 단순함 | AWS 연동을 위한 추가 구성과 권한 관리가 필요함 |
| 운영 부담과 비용 | 현재 팀이 익숙하며 별도 Control Plane 비용이 없음 | Cluster 운영 범위와 Control Plane 비용이 추가됨 |
3.1. ECS on EC2를 유지하는 경우
ECS on EC2를 유지하면 지금까지 쌓은 운영 경험과 AWS 연동 방식을 그대로 사용할 수 있다. 새로운 Kubernetes Cluster를 구성하고 운영하는 데 필요한 학습 비용도 발생하지 않는다.
Application별 배포와 확장
현재 네 Application을 각각 ECS Service로 분리하면 독립 배포가 가능하다. Service마다 CPU·메모리, 환경 변수, 실행 수를 설정할 수 있다.
ECS Service Auto Scaling으로 Task 수를 조정하고, Task를 실행할 EC2 서버가 부족해지면 EC2 Auto Scaling으로 서버 용량도 늘릴 수 있다.
기존 배포 방식의 유지
배포도 기존 방식을 유지할 수 있다. GitHub Actions가 새 이미지를 ECR에 업로드한 뒤 해당 ECS Service의 실행 설정을 갱신하면, 각 팀이 담당 Application을 별도로 배포할 수 있다.
Application 증가에 따른 관리 부담
다만 Application과 팀이 늘어나면 관리해야 할 설정도 함께 증가한다. Service마다 실행 설정, Auto Scaling 정책, 배포 파이프라인을 따로 관리해야 한다.
공통 운영 기준이 변경되면 관련 Service에 빠짐없이 반영해야 한다. 배포 후에는 CI/CD 실행 기록과 각 ECS Service의 상태를 따로 확인해야 한다.
현재 구조에서는 이 방식으로 운영할 수 있다. 하지만 Application이 더 분리되면 클라우드 팀이 여러 Service의 설정 차이와 변경 누락을 계속 확인해야 한다. ECS에서도 필요한 기능은 구현할 수 있지만, Application이 늘어날수록 공통 운영 기준을 유지하는 관리 부담이 커진다는 점이 한계다.
3.2. Kubernetes로 전환하는 경우
Kubernetes에서는 Application 실행에 필요한 자원, 상태 확인, 배포 방식과 Auto Scaling 조건을 Application 설정과 함께 관리할 수 있다. 팀마다 별도의 배포 방식을 만들기보다, 클라우드 팀이 공통 기준을 정하고 각 Application은 필요한 값만 다르게 적용하는 구조다.
공통 기준과 Application별 설정
클라우드 팀은 공통 설정을 Helm Chart로 관리하고, 각 팀은 이미지 버전, Replica 수, 자원 크기처럼 Application마다 달라지는 값만 관리한다.
새로운 Application이 추가되어도 기존 Chart를 바탕으로 설정할 수 있기 때문에 운영 기준을 처음부터 다시 만들 필요가 없다.
Git에 기록되는 운영 상태
GitOps를 적용하면 Git에 저장된 설정을 운영 환경의 기준으로 삼는다. Argo CD는 Git의 설정과 실제 Cluster 상태를 비교해 두 상태가 다른지 확인한다.
따라서 배포가 많아져도 현재 어떤 버전과 설정이 운영 중인지 Git에서 확인할 수 있다. 운영 환경에 직접 변경이 발생한 경우에도 Git의 설정과 비교해 그 차이를 파악할 수 있다.
Application별 자원과 배치
서비스별 운영 특성도 같은 관리 방식 안에서 구분할 수 있다. Core Backend와 Order Service는 안정적인 요청 처리와 DB 연결을 기준으로 자원과 확장 정책을 설정한다.
Search Service는 검색 요청량을 기준으로 확장하고, AI Server는 CPU·메모리 사용량과 처리 중인 요청 수를 함께 고려한다.
AI Server처럼 자원 사용량이 크거나 일반 API와 처리 방식이 다른 Application은 별도의 Node 그룹에 배치할 수 있다. 이렇게 하면 AI Server의 자원 사용이 Core Backend나 Order Service의 실행에 직접적인 영향을 주는 상황을 줄일 수 있다.
Kubernetes 도입에 따른 부담
다만 Kubernetes를 도입하면 관리 범위와 운영 비용이 커진다. 클라우드 팀은 Cluster와 Node뿐 아니라 네트워크, 권한, AWS 연동 구성요소, 모니터링과 버전 업그레이드까지 관리해야 한다.
장애가 발생하면 Application 문제인지 Kubernetes 계층의 문제인지 함께 확인해야 하며, Control Plane과 운영 도구에 대한 비용도 추가된다.
4. Kubernetes 도입 판단
4.1. v3에서 필요한 운영 방식
v3에서는 Core Backend, Order Service, Search Service, AI Server를 서로 다른 팀이 운영한다. 각 팀의 배포 일정이 다르고, Application마다 필요한 자원과 Auto Scaling 기준도 다르다.
이러한 차이는 유지하되, 운영 방식까지 팀마다 달라져서는 안 된다. 다음 기준은 모든 Application에 공통으로 적용해야 한다.
- 배포 상태를 확인하고 문제가 생기면 이전 버전으로 되돌리는 방법
- Application이 정상적으로 요청을 받을 수 있는지 확인하는 기준
- CPU·메모리 할당과 Auto Scaling 설정 방식
- 로그와 모니터링을 연결하는 방식
- 운영 설정을 변경하고 승인하는 과정
이 기준을 각 팀이 따로 구성하면 같은 목적의 설정이 Repository마다 다른 형태로 관리된다. 공통 기준을 변경할 때도 여러 설정과 배포 파이프라인을 각각 수정해야 하며, 일부 Application에 변경이 누락될 가능성이 있다.
따라서 클라우드 팀이 모든 Application의 배포를 직접 담당하기보다는, 공통 기준을 제공하고 각 팀이 그 기준 안에서 스스로 배포할 수 있는 운영 환경이 필요하다.
4.2. Kubernetes를 선택한 근거
ECS on EC2에서도 Application을 Service로 분리하면 독립 배포와 Auto Scaling을 구현할 수 있다. 현재 Application 수와 조직 규모만 유지한다면 ECS를 계속 사용하는 편이 더 단순하다.
하지만 v3에서는 네 Application을 서로 다른 팀이 운영하고, 앞으로 기능과 Application이 더 분리될 가능성도 있다. 이 구조에서는 Service마다 설정과 배포 방식을 따로 관리하기보다, Application 운영에 필요한 설정을 공통 형식으로 만들고 반복해서 적용하는 편이 적합하다.
각 팀은 담당 Application을 원하는 일정에 배포할 수 있어야 한다. 동시에 상태 확인, 자원 설정, 배포와 롤백 방식은 공통 기준을 따라야 한다. Core Backend, Order Service, Search Service, AI Server의 자원 사용 방식과 Auto Scaling 기준은 서로 다를 수 있지만, 이를 관리하는 기본 방식까지 달라질 필요는 없다.
Kubernetes에서는 Application 운영에 필요한 설정을 함께 선언하고, 공통 부분은 Helm Chart로 관리할 수 있다. Application마다 다른 이미지 버전, Replica 수, 자원 크기만 별도로 설정하면 되므로 새로운 Application에도 같은 운영 기준을 적용하기 쉽다.
Git에는 승인된 운영 설정을 남기고, Argo CD를 통해 실제 Cluster 상태와 비교할 수 있다. 배포 횟수가 늘어나도 현재 어떤 버전과 설정이 적용되어 있는지 확인할 수 있으며, 운영 환경이 Git의 설정과 달라진 경우에도 그 차이를 찾을 수 있다.
ECS에서도 이러한 기능을 각각 구현할 수 있다. 다만 팀과 Application이 늘어날수록 같은 운영 기준을 여러 ECS Service와 배포 파이프라인에 반복해서 반영해야 한다. v3에서는 독립적으로 배포하는 Application이 계속 늘어날 것으로 보고, 공통 운영 기준을 한 가지 방식으로 관리하고 재사용하기 위해 Kubernetes를 선택한다.
4.3. 도입에 따라 늘어나는 운영 책임
Kubernetes를 도입한다고 해서 운영 업무가 줄어드는 것은 아니다. Application 팀의 배포 방식은 정리되지만, 클라우드 팀이 새롭게 관리해야 할 영역이 생긴다.
- Cluster와 Node 운영
- 네트워크와 AWS 연동 구성요소 관리
- Application과 운영자 권한 관리
- Cluster 모니터링과 장애 대응
- Kubernetes와 운영 구성요소 업그레이드
v3에서는 이러한 운영 부담을 감수하고 Kubernetes를 운영 플랫폼으로 선택한다. 네 팀의 배포를 클라우드 팀이 매번 조정하는 대신, 공통 운영 기준을 클라우드 팀의 운영 환경에 마련하고 각 팀이 독립적으로 사용하는 구조가 앞으로의 서비스 분리에 더 적합하다고 판단했다.