컨테이너 오케스트레이션 플랫폼을 바꾸는 건, 비행 중에 엔진을 교체하는 것과 같다. 핵심은 “어떻게 전환할 것인가"다. 한 번에 스위칭하면 빠르지만 위험하고, 너무 느리면 두 환경을 동시에 운영하는 비용이 커진다.
플랫폼 서버를 ECS에서 EKS로 마이그레이션했다. Big Bang 전환 대신 가중치 기반 점진적 트래픽 전환 전략을 택했다. 99:1에서 시작해 0:100까지, 각 단계마다 모니터링하고 이상이 없을 때만 다음 단계로 넘어가는 방식이다. 결과적으로 에러 없이 무중단으로 전환을 완료했다. 그 과정을 공유한다.
마이그레이션 전환 방식은 크게 세 가지가 있다.
EKS에서 Pod가 S3에 파일을 올리거나 SQS에 메시지를 보내려면 AWS 자격 증명이 필요하다. 예전에는 AWS Access Key를 환경변수나 ConfigMap에 넣어서 해결했다. 동작은 하지만, 키가 유출되면 누구나 해당 권한을 사용할 수 있고, 키 로테이션도 수동이다.
IRSA(IAM Roles for Service Accounts)는 이 문제를 근본적으로 해결한다. Kubernetes의 ServiceAccount와 AWS IAM Role을 OIDC 프로토콜로 연결해서, Pod에 임시 자격 증명을 자동으로 주입한다. 키를 코드에 넣을 필요가 없고, 토큰은 자동 갱신되며, 네임스페이스 단위로 권한을 분리할 수 있다.
K8s 환경에서 앱이 DB 비밀번호나 API 키 같은 시크릿을 사용하려면, 어딘가에서 가져와야 한다. 이 “어딘가"와 “가져오는 방식"에 따라 아키텍처가 달라진다.
크게 두 가지 접근이 있다. 앱이 AWS API를 직접 호출해서 읽는 방식과, K8s Operator가 대신 읽어서 환경변수로 넣어주는 방식이다. 전자는 Parameter Store 직접 읽기, 후자는 External Secrets Operator다. 각각의 동작 원리와 트레이드오프를 정리한다.
Spring Boot 기준으로, Spring Cloud AWS가 제공하는 Parameter Store 통합 기능을 사용하는 방식이다.
