컨테이너화된 애플리케이션이 퍼블릭 IP를 가진 EC2 인스턴스에서 실행됩니다. Apache Kafka는 해당 EC2 인스턴스에서 자체 호스팅되며, PostgreSQL은 Amazon RDS for PostgreSQL로 마이그레이션되었습니다. 회사는 제품 출시로 인해 주문이 급증할 것으로 예상합니다. 운영 오버헤드를 줄이고 증가된 로드를 지원할 수 있는 아키텍처 변경 사항은 무엇입니까?

정답은 운영 오버헤드를 줄이고 증가된 로드를 지원하기 위한 최적의 솔루션을 제공합니다. AWS Fargate를 사용하는 Amazon EKS는 컨테이너화된 애플리케이션에 대한 서버리스 접근 방식을 제공하여 EC2 인스턴스 관리의 필요성을 제거하고 자동 스케일링을 통해 로드 급증을 처리합니다. RDS 읽기 복제본은 데이터베이스 읽기 용량을 확장합니다. 자체 관리형 Kafka를 Amazon MSK로 교체하면 Kafka 클러스터 관리에 대한 운영 부담이 줄어들고 확장성이 향상됩니다. CloudFront 뒤의 S3는 정적 콘텐츠를 효율적으로 제공하여 로드를 줄이고 성능을 향상시킵니다. 다른 옵션들은 다음과 같은 이유로 최적이 아닙니다. 첫 번째 옵션은 Kinesis Data Streams를 제안하는데, 이는 Kafka와 직접적인 대체재가 아닐 수 있으며, 기존 애플리케이션 변경이 더 필요할 수 있습니다. 또한, RDS 읽기 복제본만으로는 쓰기 확장을 처리하지 못합니다. 두 번째 옵션은 DB 인스턴스를 Multi-AZ로 변환하고 스토리지 자동 스케일링을 활성화하지만, 이는 주로 가용성과 스토리지 관리에 중점을 둡니다. 읽기 용량 확장에 대한 직접적인 해결책은 아닙니다. Kinesis Data Streams에 대한 동일한 우려 사항이 적용됩니다. 세 번째 옵션은 Kubernetes 클러스터로 리플랫폼하는 것을 제안하지만, EC2 인스턴스에서 실행되는 Kubernetes 클러스터는 여전히 EC2 인스턴스 관리에 대한 운영 오버헤드가 있습니다.