AWS Compute와 Container 운영

Overview

Compute 계층은 Application Process가 CPU, Memory, Network를 받아 실행되는 곳이다. EC2에 직접 배포하든 Container Orchestrator를 쓰든 Artifact, 설정, Health, 종료, Rollback 계약이 필요하다.

한 문장 설명: 실행 환경을 교체 가능한 단위로 만들고 상태를 밖으로 분리해야 안전하게 확장하고 배포할 수 있다.

왜 필요한가

수작업 서버 수정은 환경 편차를 만들고 복구를 어렵게 한다. 불변 Image와 자동 배포, Stateless Process를 사용하면 같은 Artifact를 반복 검증하고 장애 Instance를 교체할 수 있다.

핵심 원리

Build Artifact와 환경별 Config/Secret을 분리한다. CPU보다 Memory, Connection, Thread 같은 실제 병목을 기준으로 Capacity를 잡는다. Liveness는 재시작 필요성, Readiness는 Traffic 수신 가능성을 나타낸다. 배포에는 Drain과 Graceful Shutdown이 포함된다.

내부 동작

sequenceDiagram; participant D as Deployer; participant N as New Instance; participant L as Load Balancer; participant O as Old Instance; D->>N: Artifact+Config 시작; N->>L: Readiness OK; L->>N: 신규 Traffic; L->>O: Deregister/Drain; O->>O: 진행 요청 완료 후 종료

Container Image는 Application과 Runtime을 묶지만 Kernel을 공유한다. Orchestrator는 원하는 Replica 수를 유지하고 Health에 따라 재시작·배치한다. Auto Scaling은 지표와 Cooldown에 따라 Capacity를 바꾸므로 하위 DB 한계와 함께 설계한다.

쉬운 비유

불변 Image는 표준 조립 설명서이고 Instance는 조립된 제품이다. 고장 난 제품을 현장에서 계속 고치기보다 같은 설명서로 교체하면 환경 차이가 줄어든다.

Example

Spring Boot 종료 유예를 30초로 잡았다면 Load Balancer Deregistration Delay와 최대 요청 시간을 맞춘다. Readiness는 기동 완료 전 실패해야 하지만 일시적 외부 Dependency 장애마다 모든 Instance를 동시에 제외하지 않도록 범위를 구분한다.

실무에서 발생하는 문제

OOM Kill, CPU Throttling, Disk 부족, File Descriptor 고갈이 Process 장애로 나타난다. Scale-out이 RDS Connection을 폭증시키거나 Warm-up 전 Traffic이 들어올 수 있다. Config Server/Discovery 의존성이 기동을 막는 경우도 있다.

Trade-off

VM 직접 운영은 단순한 초기 구조를 주지만 Patch와 편차 관리가 필요하다. Container는 이식성과 배포 단위를 개선하지만 Image 보안, Orchestration, Resource Limit 학습 비용이 있다. Serverless는 관리 범위를 줄이지만 실행·연결 모델 제약이 있다.

흔한 오해

Container는 VM과 같은 완전 격리가 아니다.
Auto Scaling은 순간 Traffic을 즉시 해결하지 않는다.
Health Endpoint가 200이면 모든 핵심 기능이 정상인 것은 아니다.

Production Considerations

CPU/Memory뿐 아니라 GC, Thread, Connection Pool, Queue, 재시작 수를 관측한다. Image 취약점과 Base Image 갱신, 최소 권한 IAM Role, Secret 주입을 관리한다. 배포마다 Canary/Blue-Green/Rolling 중 적합한 전략과 자동 Rollback 조건을 정한다.

Interview Questions / Follow-up Questions

Liveness와 Readiness를 잘못 설계하면 어떤 장애가 나는가?
Stateless가 Scale-out에 유리한 이유는?
후속: Auto Scaling이 DB 장애를 악화시키는 과정은?
후속: Graceful Shutdown 순서를 설명해보라.

AWS 운영 지도, Observability, 부하 테스트와 함께 Capacity를 검증한다.