Practice Test #6

AWS Systems Manager Automation은 런북을 사용하여 운영 워크플로(패치 적용, AMI 베이킹 단계, 인스턴스 복구 작업)를 실행하는 데 가장 적합합니다. API 호출을 오케스트레이션할 수는 있지만 전체 다중 리소스 아키텍처를 재사용 가능한 선언적 블루프린트로 모델링하고 버전화하도록 설계되지 않았습니다. 또한 CloudFormation이 제공하는 것과 동일한 반복 가능하고 환경 파라미터화된 스택 수명 주기 관리를 본질적으로 제공하지 않습니다.

AWS Config는 주로 구성 기록을 기록하고, 규칙에 따라 리소스를 평가하고, 규정 준수를 보고합니다. Config 자동 수정이 특정 규정 위반 설정을 수정하기 위해 자동화를 트리거할 수 있지만, 여러 AZ에 걸쳐 처음부터 전체 애플리케이션 스택을 프로비저닝하기 위한 것은 아닙니다. Config를 배포 메커니즘으로 사용하는 것은 오용이며 복잡하고 불안정하며 표준 IaC 모범 사례와 일치하지 않습니다.

Elastic Beanstalk는 지원되는 웹/앱 플랫폼에 대한 기본 리소스를 프로비저닝하는 관리형 애플리케이션 배포 서비스입니다. Network Load Balancer 구성, Auto Scaling 세부 정보 및 뱅킹 트랜잭션을 위해 설계된 Aurora 클러스터에 대한 명시적 제어가 필요한 맞춤형 아키텍처에는 적합하지 않습니다. Beanstalk는 여러 AZ에 걸쳐 배포할 수 있지만 인프라를 추상화하며 검증된 프로토타입을 정확하게 복제하는 데 가장 적합하지 않습니다.

Docker Engine 및 Auto Scaling 그룹이 있는 EC2는 인스턴스 수를 확장할 수 있지만 AMI 유지 관리, OS 패치 적용, 용량 계획, 컨테이너 예약, 서비스 검색 및 롤링 배포와 같은 상당한 운영 작업을 남깁니다. 또한 인스턴스 전체에서 컨테이너를 오케스트레이션하기 위해 추가 도구가 필요하거나 자체적으로 구축해야 합니다. 이는 서버 프로비저닝을 제거하고 인프라 관리를 최소화하라는 요구 사항과 모순됩니다.

EC2 시작 유형의 ECS는 원시 EC2 + Docker에 비해 오케스트레이션을 개선하지만 여전히 EC2 클러스터를 관리해야 합니다. 인스턴스 선택, 패치 적용, 조정 정책, 급증 시 작업 배치를 위한 충분한 여유 용량 확보 등이 포함됩니다. 클러스터 Auto Scaling이 도움이 되지만 여전히 Fargate보다 운영 부담이 크며 빠른 트래픽 급증 시 용량 부족을 방지하기 위해 신중한 튜닝이 필요할 수 있습니다.

EC2에서 ECS-optimized AMI를 사용하고 오케스트레이션을 수동으로 구성하는 것은 옵션 중 운영 부담이 가장 높습니다. ECS를 사용하더라도 "수동으로 구성"한다는 것은 클러스터 용량, 배포 및 유지 관리에 대한 더 많은 실무 관리를 의미합니다. 이는 애플리케이션 로직에 집중하고 서버 프로비저닝 및 지속적인 인프라 유지 관리를 피하라는 요구 사항과 직접적으로 충돌합니다.

이것이 적합하지 않은 이유는 sub-millisecond latency가 필요한 high-frequency trading system은 Redshift와 같은 data warehouse platform과 맞지 않기 때문입니다. Redshift는 ultra-low-latency event processing이나 transaction execution이 아니라 analytical query throughput에 최적화되어 있습니다. Real-time streaming 및 HFT 스타일의 decisioning은 Kinesis, Apache Flink, in-memory database, 또는 특화된 low-latency architecture와 같은 서비스가 더 적합합니다.

이것이 최선의 답 중 하나가 아닌 이유는 문구가 application access를 위한 'data sharing APIs'에 초점을 맞추고 있는데, 이는 보기에서 제시하는 방식의 주요 Redshift 사용 사례가 아니기 때문입니다. Redshift는 application에서 query할 수 있고 data sharing 기능도 지원하지만, 근본적으로 operational application integration을 위한 API-serving platform이라기보다 analytical warehouse입니다. 이 문제에서는 scheduled analytics, security, 그리고 petabyte-scale historical analysis가 더 직접적이고 전형적인 Redshift 기능입니다.

이것이 적합하지 않은 이유는 Redshift가 자주 액세스되는 customer profile data를 위한 고성능 cache 역할을 하도록 설계되지 않았기 때문입니다. Caching 및 low-latency key-value access pattern은 access model에 따라 Amazon ElastiCache, DynamoDB, 또는 Aurora와 같은 서비스가 더 적합합니다. 이 목적에 Redshift를 사용하는 것은 비효율적이고 비용이 많이 들며, OLAP 중심 설계와도 맞지 않습니다.

AWS CloudFormation 템플릿은 코드형 인프라 및 파라미터화된 배포를 제공하므로 LMS 스택을 표준화할 수 있습니다. 그러나 CloudFormation 단독으로는 거버넌스된 셀프 서비스 카탈로그 환경, 포트폴리오 배포, 제품 버전 수명 주기 관리 또는 많은 독립 기관을 위한 내장된 제약 조건을 제공하지 않습니다. Service Catalog가 기본적으로 제공하는 것과 유사한 추가 도구 및 액세스 제어를 구축해야 합니다.

AWS Systems Manager는 운영 관리(예: Patch Manager, State Manager, Automation 런북, Parameter Store)에 중점을 두며 배포된 리소스를 구성하고 유지 관리하는 데 도움이 될 수 있습니다. 많은 기관에 걸쳐 중앙 집중식 거버넌스 및 셀프 서비스 프로비저닝을 통해 표준화된 배포 가능한 "제품"을 배포하기 위한 기본 메커니즘으로 의도되지 않았습니다. 프로비저닝 도구를 보완하지만 카탈로그 기반 배포를 위해 Service Catalog를 대체하지는 않습니다.

AWS Config는 구성 변경 사항을 기록하고, 규칙에 따라 리소스를 평가하며, 규정 준수 보고 및 수정 워크플로를 지원합니다. 리소스가 존재한 후 지역 규정 준수 요구 사항을 적용하고 감사하는 데 도움이 되지만 셀프 서비스 배포 메커니즘이나 중앙 집중식 버전 제어 제품 배포를 제공하지 않습니다. Config는 프로비저닝/카탈로그 서비스가 아니라 거버넌스/규정 준수 모니터링 서비스입니다.

Amazon CloudWatch Container Insights는 주로 observability 솔루션이지 deployment management 플랫폼이 아닙니다. metrics 및 logs를 중앙 집중화할 수는 있지만, ECS와 on-premises clusters 전반의 container deployments를 관리하기 위한 단일 dashboard를 제공하지는 않습니다. 문제는 가시성과 관리 둘 다를 명시적으로 요구하므로 모니터링만으로는 충분하지 않습니다. 또한 non-ECS Docker Swarm 환경에 대해서는 추가적인 custom setup이 필요하므로, 전체 관리 요구 사항에 대해 '최소 운영 오버헤드'라는 주장도 약해집니다.

AWS App2Container는 기존 applications를 ECS 또는 EKS용 containerized workloads로 변환하는 데 도움을 주는 migration 및 modernization 도구입니다. 기존의 다중 환경 container clusters에 대한 중앙 집중식 지속 관리 기능은 제공하지 않습니다. 이를 사용하면 상당한 migration effort가 추가되며, 현재의 AWS 및 on-premises 환경 전반에서 통합 모니터링과 deployment control이 필요하다는 요구를 직접 해결하지도 못합니다. 따라서 가장 낮은 오버헤드의 운영 솔루션이 아닙니다.

AWS Systems Manager는 servers 및 patching, inventory, remote command execution과 같은 operational tasks를 관리하는 데 유용합니다. 그러나 container orchestration 플랫폼은 아니며 ECS에 필적하는 native multi-cluster container deployment management를 제공하지 않습니다. Systems Manager로 통합 container management 솔루션을 구축하려면 상당한 custom engineering 및 integration이 필요합니다. 따라서 오버헤드가 더 높고, 제시된 요구 사항과도 덜 부합합니다.