Amazon DOP-C02: 컨테이너 및 서버리스 운영 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS DevOps Engineer Professional DOP-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

컨테이너와 서버리스는 AWS에서 애플리케이션을 운영, 확장 및 릴리스하는 방식을 바꿉니다. 이 섹션에서는 Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda, Amazon API Gateway 전반의 운영 기본 요소를 연결하여 안전한 배포를 설계하고, 이미지 거버넌스를 시행하며, 동시성을 조정하고, EC2 기반 용량과 Fargate 기반 용량 간에 일관된 선택을 할 수 있도록 합니다. 작업 및 파드 스케줄링 모델, 상태 확인 및 배포 제어, 트래픽 전환, 계정 간 이미지 배포, API 캐싱 및 Lambda 프로비저닝된 동시성과 같은 성능 기능에 중점을 둡니다.

Amazon ECS와 AWS Fargate

ECS 작업 정의(task definition)는 하나 이상의 컨테이너와 스케줄러에 필요한 모든 런타임 구성을 선언합니다. 주요 요소에는 CPU/메모리 예약 및 제한, portMappings, 환경 변수 및 보안 암호(AWS Secrets Manager 또는 Systems Manager Parameter Store 사용), Linux 파라미터 및 ulimits, logConfiguration(awslogs, firelens 등), ephemeralStorage 크기(Fargate의 경우 20–200GB), 볼륨(EFS 포함)이 포함됩니다. 이미지 풀(pull) 및 로그 드라이버에는 작업 실행 역할(task execution role)을 사용하고, 애플리케이션의 AWS API 액세스에는 작업 역할(task role)을 사용합니다. 컨테이너 healthCheck는 command, interval, timeout, retries, startPeriod를 정의합니다. dependsOn(condition=HEALTHY)과 결합된 상태 확인은 사이드카의 시작 순서를 강제합니다.

ECS 서비스는 원하는 작업 수를 유지하고 선택적으로 작업을 ALB/NLB에 등록합니다. 서비스 deploymentConfiguration은 minimumHealthyPercent와 maximumPercent를 사용하여 롤링 업데이트를 제어합니다. 배포 서킷 브레이커(deployment circuit breaker)(enabled/rollback)는 작업이 상태 확인에 실패할 때 실패한 롤아웃을 자동으로 되돌릴 수 있습니다. 서비스 오토스케일링은 Application Auto Scaling과 통합되어 CPU/메모리 기반 목표 추적 또는 ALB RequestCountPerTarget을 수행합니다. 서비스 디스커버리(AWS Cloud Map)와 ECS Service Connect는 서비스 간 트래픽을 단순화합니다.

클러스터 유형 및 용량:

EC2 시작 유형은 자체 관리하는 EC2 인스턴스에서 작업을 실행합니다. Auto Scaling 그룹, 배치 제약 조건/전략, 그리고 모든 networkMode(bridge/host/awsvpc)를 사용합니다. 데몬 작업과 특수 AMI(예: Bottlerocket)가 지원됩니다.
Fargate 시작 유형은 컨테이너를 위한 서버리스 컴퓨팅입니다. awsvpc 네트워킹만 사용하며 각 작업에 자체 ENI와 보안 그룹을 부여합니다. 데몬 작업은 없으며, 사이드카나 서비스 네이티브 통합(예: FireLens)에 의존합니다. 플랫폼 버전에 따라 기능이 결정됩니다(EFS, 임시 스토리지, exec 지원에 대한 릴리스 노트 확인). Fargate Spot은 중단 가능한 작업의 비용을 절감합니다. 지원되는 쌍으로 CPU/메모리를 선택합니다(예: 0.25 vCPU/0.5–2GB부터 16 vCPU/120GB까지). 프라이빗 서브넷에서 실행할 때, NAT 없이 이미지를 가져오고 로그를 전송하려면 ECR(api 및 dkr), CloudWatch Logs용 VPC 인터페이스 엔드포인트와 S3 게이트웨이 엔드포인트를 추가해야 합니다.

Fargate와 EFS: 작업 정의에서 EFS 볼륨을 정의하고 TLS로 마운트합니다. 최소 권한 및 ID 적용을 위해 EFS 액세스 포인트를 사용하는 것이 좋습니다. 이를 통해 공유 구성, 모델 가중치 또는 중간 파일과 같은 상태 저장 요구 사항을 이미지에 포함시키지 않고 지원할 수 있습니다.

컨테이너 상태 확인, 롤링 업데이트, 블루/그린:

상태 확인은 여러 계층에서 발생합니다: 컨테이너(CMD 기반), ECS 작업(집계된 컨테이너 상태), 로드 밸런서 대상 상태(HTTP/TCP). ALB가 대상을 등록 취소하기 전에 ECS가 비정상 작업을 정상적으로 교체할 수 있도록 간격과 임계값을 조정해야 합니다.
롤링 업데이트는 ECS의 기본값입니다. minHealthy/maxPercent를 조정하여 서지(surge) 및 용량 안전성을 제어합니다.
블루/그린은 ECS와 함께 CodeDeploy를 사용합니다(deploymentController 유형: CODE_DEPLOY). CodeDeploy는 ALB 뒤에서 두 개의 대상 그룹을 관리하고, 테스트 트래픽을 그린(green) 세트로 전환하며(AfterAllowTestTraffic), 자동화된 검사(예: Lambda를 통해)를 실행한 다음, 프로덕션 트래픽을 전환합니다. 5XX 급증, 지연 시간 또는 사용자 지정 지표 발생 시 롤백하도록 CloudWatch 경보를 연결합니다. 이 패턴은 장애를 격리하고 거의 제로 다운타임으로 빠른 복구를 제공합니다.

ECR을 사용한 이미지 거버넌스:

스캐닝: 푸시 시 스캔(scan-on-push)을 활성화하고 지속적인 CVE 적용 범위 및 SBOM을 위해 Amazon Inspector 고급 스캐닝을 채택합니다. 파이프라인 검사를 사용하여 취약점 심각도에 따라 배포를 제어(gate)합니다.
수명 주기 정책은 개수/기간 및 태그 접두사를 기준으로 오래된 이미지 태그를 만료시킵니다. 태그 불변성(tag immutability)과 결합하여 우발적인 덮어쓰기를 방지합니다.
암호화: ECR 관리형 암호화 또는 적절한 키 정책이 있는 고객 관리형 KMS 키를 사용합니다.
계정 간 액세스: 리포지토리 리소스 정책을 연결하여 다른 계정이나 CI 역할로부터의 풀/푸시(pull/push)를 허용합니다. ECR 복제 규칙을 사용하여 리전/계정 간에 이미지를 복사하여 로컬리티를 확보하고 장애 영향 반경을 줄입니다. PrivateLink(VPC 엔드포인트)를 사용하면 인터넷 없이 이미지를 풀(pull)할 수 있습니다.

Amazon EKS 컴퓨팅 모델

EKS는 관리형 컨트롤 플레인을 데이터 플레인 선택 사항과 분리합니다.

관리형 노드 그룹(MNG)은 EC2 워커 노드를 프로비저닝하고 수명 주기를 관리합니다. 시작 템플릿과 통합되어 AMI 선택(Amazon Linux 2, Bottlerocket), 인스턴스 유형, 부트스트랩 파라미터를 지정할 수 있습니다. MNG는 서지 용량(surge capacity)을 이용한 롤링 업데이트와 자동화된 cordon/drain을 처리하여 중단을 최소화합니다. 노드 테인트/톨러레이션(taints/tolerations)을 사용하여 특정 워크로드를 지정된 노드로 보낼 수 있습니다. Cluster Autoscaler(또는 Karpenter)와 결합하여 보류 중인 파드를 기반으로 노드 용량을 적절하게 조정합니다.

자체 관리형 노드는 부트스트랩과 OS에 대한 완전한 제어권을 제공하지만 운영 오버헤드가 추가됩니다. 일반적으로 특수 커널이나 특정 하드웨어를 위해 사용됩니다.

EKS on Fargate는 노드를 관리할 필요 없이 파드를 실행합니다. Fargate 프로파일은 네임스페이스/레이블을 Fargate에 매핑합니다. 각 파드는 자체 ENI(awsvpc)를 할당받아 네트워크 격리를 단순화합니다. DaemonSet 사용 불가, 호스트 네트워킹/볼륨 사용 불가, 권한 있는 워크로드에 대한 제약 등의 제한 사항이 있습니다. Fluent Bit과 같은 관찰성 에이전트는 사이드카로 실행하거나 관리형 로그 수집을 사용해야 합니다. 이 모델은 파드별 격리와 파드당 과금 경제성의 이점을 누릴 수 있는 스파이크성, 소규모 또는 멀티테넌트 워크로드에 이상적입니다.

운영 애드온:

VPC CNI, CoreDNS, kube-proxy는 관리형 애드온입니다. 클러스터 버전과 호환되는 버전을 고정하고 신중하게 업그레이드해야 합니다.
IAM Roles for Service Accounts (IRSA)는 파드별로 최소 권한의 AWS 액세스를 강제하며, 노드 역할 자격 증명 공유를 대체합니다.
AWS Load Balancer Controller를 통한 로드 밸런싱은 Service 및 Ingress에 대해 ALB/NLB를 지원합니다. 특히 MNG와 Fargate를 혼용할 때 적절한 IAM 및 보안 그룹 규칙을 보장해야 합니다.
CSI 드라이버를 통한 영구 스토리지(파드별 블록 스토리지를 위한 EBS, 공유 POSIX를 위한 EFS). Fargate의 경우, 공유 상태를 위해서는 일반적으로 EFS가 사용됩니다.

AWS Lambda 운영 및 동시성

패키징 및 구성:

배포 패키지는 ZIP 아카이브(언어 런타임 포함) 또는 최대 10GB의 컨테이너 이미지일 수 있습니다. ZIP은 작은 코드에 더 가볍고, 이미지는 컨테이너 기반 빌드와 툴링을 통합합니다.
계층(Layer)은 여러 함수에 걸쳐 공유 라이브러리를 캡슐화합니다. 최소한으로 유지하고 버전을 관리해야 합니다. 함수는 최대 5개의 계층을 포함할 수 있습니다.
버전은 불변의 스냅샷입니다. 별칭(Alias)은 버전을 가리키는 안정적인 포인터이며 트래픽 시프팅을 위한 가중치를 가질 수 있습니다.
임시 스토리지는 기본 512MB이며 빌드, 임시 파일 또는 ML 추론 캐시를 위해 최대 10,240MB까지 늘릴 수 있습니다. 비용/성능 절충을 위해 x86_64 또는 arm64를 선택합니다. 구성을 위해 환경 변수를 사용하고 Secrets Manager 또는 Parameter Store와 통합합니다.

트래픽 시프팅 및 안전성:

CodeDeploy를 사용하여 CloudWatch 경보(예: 5XX, 지연 시간 또는 사용자 지정 앱 지표)에 따른 자동 롤백과 함께 카나리/선형 배포를 수행합니다. 또는 간단한 A/B 라우팅을 위해 별칭 가중치를 직접 설정할 수 있습니다.
CloudWatch Logs에 구조화된 로깅을 사용하여 지표 계측을 변경하지 않고도 운영/버전/코드 차원의 지표를 도출하는 지표 필터를 생성합니다. 종단 간 지연 시간 추적을 위해 X-Ray를 활성화합니다.

동시성 제어:

예약되지 않은 동시성(Unreserved concurrency)은 계정의 리전별 풀에서 가져옵니다. 트래픽이 급증하면 다른 함수가 고갈될 수 있습니다.
예약된 동시성(Reserved concurrency)은 함수의 최대 동시성을 제한하고 리전별 풀에서 용량을 할당하여 보장합니다. 이는 노이지 네이버(noisy neighbor)로부터 격리를 제공합니다.
프로비저닝된 동시성(Provisioned concurrency)은 특정 버전/별칭에 대해 실행 환경을 초기화된 상태로 유지하여 콜드 스타트를 거의 제거하고 지연 시간을 안정화합니다. Application Auto Scaling을 사용하여 시간대 또는 지표에 따라 프로비저닝된 동시성을 확장합니다.
스로틀링(Throttling)은 함수가 동시성 한도에 도달할 때 발생합니다. 동기식 호출자는 429 오류를 받고, 비동기식 호출은 지수 백오프와 함께 재시도되며 구성된 시도 횟수 이후에 데드레터(dead-letter) 큐로 보내질 수 있습니다. SQS와 같은 폴링 기반 소스의 경우, Lambda는 큐 깊이에 따라 동시성을 증가시킵니다. 백로그 증가를 피하려면 예약된/프로비저닝된 동시성과 다운스트림 용량이 최대 처리 중인 메시지 수와 일치하도록 해야 합니다.

API Gateway 설계 및 ECR 계정 간 액세스

API Gateway REST API와 HTTP API 비교:

REST API는 가장 풍부한 기능 세트를 제공합니다: 요청/응답 매핑(VTL), 사용량 계획 및 API 키, 권한 부여(authorizer), WAF, 스테이지 수준 캐싱. 고급 변환, 할당량이 있는 API 키 또는 성숙한 생태계 통합이 필요할 때 REST API를 선택하십시오.
HTTP API는 지연 시간이 더 짧고 비용이 저렴하며, Lambda 및 HTTP 백엔드(ALB/NLB/프라이빗 통합 포함)로의 라우팅이 더 간단합니다. JWT 권한 부여 및 IAM을 지원하지만 스테이지 수준 캐싱 및 VTL 변환을 포함한 많은 REST 기능이 부족합니다. 오버헤드를 최소화하면서 간단한 프록시 역할이 필요할 때 HTTP API를 선택하십시오.

스테이지 및 조절(throttling):

스테이지는 특정 배포를 URL 경로에 바인딩합니다. 스테이지에서 스테이지 변수, 로깅, 조절을 구성합니다. 사용량 계획(REST)을 적용하여 API 키별 조절 및 할당량을 강제합니다. 조절 설정에는 속도(rate)와 버스트(burst)가 포함되며, 계정 수준 제한과 결합되므로 총 트래픽이 리전 할당량을 초과하지 않도록 해야 합니다. 구조화된 JSON으로 액세스 로깅을 활성화하고 WAF를 통합하여 악의적인 요청을 검사하고 차단합니다.

캐싱(REST API만 해당):

스테이지 수준 캐시는 백엔드 부하와 지연 시간을 줄여줍니다. 메서드별로 TTL을 설정하고, 암호화를 활성화하며, 정확성을 위해 캐시 키 파라미터/헤더를 고려하십시오. 응답 형태나 동작을 변경하는 배포 후에는 캐시를 무효화합니다.

프라이빗 연결:

엔드포인트 유형 선택: 엣지 최적화(REST, CloudFront를 통한 글로벌), 리전, 또는 프라이빗(VPC 엔드포인트). VPC Link를 사용한 프라이빗 통합은 VPC 내의 NLB/ALB 백엔드에 외부 노출 없이 연결됩니다.

ECR 계정 간 액세스:

리포지토리 리소스 정책을 사용하여 다른 계정의 보안 주체(CI/CD 또는 런타임 역할)에 pull/push 권한을 부여합니다. 고객 관리형 KMS 키를 사용하는 경우, 키 정책도 그에 맞게 확장합니다. 다중 계정 배포를 위해, ECR 복제 규칙을 정의하여 대상 계정/리전을 지정하고, 배포 시 태그 불변성(tag immutability)과 다이제스트 피닝(digest pinning)으로 이미지 무결성을 검증합니다.

실용적인 문제 시나리오

Spotify는 피크 출시 기간 동안의 지연 시간 변동을 줄이고 여러 AWS 계정에 걸쳐 이미지 공급망을 강화하기 위해 플레이리스트 마이크로서비스 스택을 현대화하고 있습니다.

이미지 빌드 및 거버넌스 표준화

scan-on-push 및 Amazon Inspector 고급 스캐닝 기능이 있는 ECR 리포지토리를 구현합니다. 태그 불변성 및 수명 주기 정책을 추가하여 브랜치별 최신 N개 버전을 유지하고 드리프트를 정리합니다. 빌드 계정에서 프로덕션 및 스테이징 계정으로 리전 간/계정 간 복제를 구성합니다. 이유: Inspector는 지속적인 CVE 커버리지를 보장하고, 불변성은 태그 하이재킹을 방지하며, 복제는 풀(pull) 작업을 로컬화하여 배포 지연 시간과 장애 영향 반경을 줄입니다.

Fargate를 사용하여 ECS에서 상태 비저장 API 제공

awslogs 및 FireLens를 사용하여 구조화된 로그 및 지표를 위한 ECS 작업 정의를 정의합니다. 컨테이너 healthCheck를 활성화하고 ALB 대상 그룹 상태 확인과 일치시킵니다. 액세스 포인트를 통해 공유 읽기 전용 구성을 위해 EFS 볼륨을 마운트합니다. 비용 효율성을 위해 Fargate와 Fargate Spot을 혼합하는 용량 공급자 전략을 사용하여 Fargate에서 서비스를 실행합니다. 이유: Fargate는 노드 관리를 제거하고 ENI별로 작업을 격리합니다. EFS는 구성 정보를 이미지에 포함시키는 것을 피하고 구성의 원자적 롤백을 지원합니다.

블루/그린 및 자동화된 테스트를 통한 안전한 배포

ECS 서비스를 CodeDeploy 배포 컨트롤러로 전환합니다. ALB에 두 개의 대상 그룹을 구성합니다. AfterAllowTestTraffic과 함께 카나리 시프트를 사용하여 5분 이내에 중요한 엔드포인트를 실행하는 Lambda 테스트 러너를 호출합니다. 5XX 및 p90 지연 시간에 대한 CloudWatch 경보를 연결하여 롤백을 트리거합니다. 이유: CodeDeploy 블루/그린은 위험을 격리하고, 테스트 훅은 전체 전환 전에 그린 환경을 검증하며, 경보는 자동화되고 객관적인 롤백을 제공합니다.

안정화된 콜드 스타트로 Lambda에서 지연 시간에 민감한 작업 처리

토큰화 헬퍼 API의 경우, 함수를 의존성을 최소화한 ZIP으로 패키징합니다. 버전/별칭을 생성하고 피크에 맞춰 크기가 조정된 프로비저닝된 동시성을 활성화합니다. 출시 기간을 추적하는 일일 스케줄로 Application Auto Scaling을 통해 프로비저닝된 동시성을 구동합니다. CloudWatch 경보에 연결된 별칭 기반 트래픽 전환을 위해 CodeDeploy 카나리(10%/15분)를 사용합니다. 이유: 프로비저닝된 동시성은 급증하는 동안 콜드 스타트를 제거합니다. 별칭 카나리는 빠른 롤백과 함께 점진적인 노출을 가능하게 합니다.

API Gateway를 통해 외부 API를 노출하고 프라이빗 백엔드 보안

API Gateway를 사용하여 Lambda 및 ECS ALB를 프론트엔드로 구성합니다. Lambda 프록시에는 비용/지연 시간을 최소화하기 위해 HTTP API를 사용합니다. 요청/응답 매핑 및 읽기량이 많은 엔드포인트에 대한 스테이지 캐싱이 필요한 ECS ALB 경로에는 REST API를 사용합니다. WAF 웹 ACL 및 스테이지 조절을 적용하고 구조화된 액세스 로그를 활성화합니다. 이유: 요구 사항에 맞는 API 유형을 사용하면 비용과 기능을 최적화할 수 있습니다. 캐싱은 부하를 줄이고, WAF 및 조절은 이벤트 급증 시 보호 기능을 추가합니다.

인터넷 없이 계정 간 런타임 풀(pull)

런타임 VPC에 ECR(api, dkr) 및 CloudWatch Logs용 인터페이스 엔드포인트와 S3 게이트웨이 엔드포인트를 추가합니다. 프로덕션 계정의 작업 실행 역할이 이미지를 풀(pull)할 수 있도록 ECR 리포지토리 리소스 정책을 연결합니다. 미사용 이미지 암호화를 위해 계정 간 키 정책이 있는 고객 관리형 KMS 키를 사용합니다. 이유: 프라이빗 이미지 풀은 NAT 비용과 외부 유출 위험을 방지합니다. 명시적인 리소스/키 정책은 최소 권한의 계정 간 액세스를 강제합니다.

이 설계는 운영 부담을 줄이고(관리할 노드 없음), 프로비저닝된 동시성 및 ALB 상태 확인과 연계된 롤아웃을 통해 예측 가능한 지연 시간을 제공하며, ECR 스캐닝, 복제 및 불변성을 통해 이미지 출처를 엔드 투 엔드로 강제합니다.

← 보안 · 모든 도메인 · 고가용성 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →