Amazon Web Services 한국 블로그

AWS Well-Architected Framework 기반 AWS GameDay 구성하기

GameDay는 몇 년 전부터 AWS Summits와 re:Invent에서 개최해 온 몰입형 팀 기반이벤트입니다. 도전적이고 재미있는 시나리오에 따라 진행되는 이 이벤트에서 각 참가 팀은 널리 기대되는 제품의 출시를 목전에 둔 인기 스타트업, Unicorn.Rentals를 DevOps의 입장에서 이끌어 갑니다. 자세한 내용은 GameDay 웹 사이트를 참조하십시오.

물론, GameDay를 효과적으로 만들기 위해 무대 뒤에서 많은 일을 진행하고 있습니다. 모든 열광적인 연기와 재미있는 소품 뒤에는 라이브 점수 추적 엔진, 게임하는 동안 로드를 실시간으로 변경할 수 있는 단일 인스턴스의 Load Generator, 다양한 명령과 제어 기능이 포함된 복잡한 AWS 인프라가 있습니다. 전체 인프라는 단순하게 설계되었지만 운영하기는 복잡하며, 게임 과정 중 플레이어에게 추천하는 똑같은 모범 사례를 통합하여 개선할 수 있는 여지가 있습니다.

AWS 파트너 솔루션스 아키텍트 팀에서는 오늘 플레이어 환경과 운영 방식을 개선하기 위해 표준 벤치마크인 AWS Well-Architected 프레임워크를 기준으로 GameDay 아키텍처를 검토했습니다. 검토 팀은 아키텍처를 상세히 이해하고, 설계와 의도에 대해 세부적인 질문을 한 다음, 우선 순위에 따라 결과를 정리한 문서를 제공할 것입니다.

1부

이 게시물에서는 초기 아키텍처 검토 결과 및 검토 팀에서 알아낸 정보를 살펴보겠습니다. 이번 개선 과정에 대한 소개와 앞으로 지속적인 개선 및 AWS 솔루션스 아키텍트와의 공동 작업을 통해 아키텍처를 향상하기 위한 계획은 향후 게시물을 통해 알려 드릴 예정입니다.

아키텍처 개요

먼저, 적절한 위치에서 다이어그램과 기타 부대 자료를 사용하여 다양한 구성 요소 및 관계를 강조하면서 GameDay의 아키텍처 개요를 검토 팀에게 제공하는 것으로 검토 세션을 시작했습니다. 독자의 이해를 돕기 위해 GameDay 아키텍처에 대해 검토 팀에게 제공한 고급 세부 정보를 요약하면 다음과 같습니다.

GameDay 인프라는 마스터 AWS 계정에서 실행되며, 각 팀에는 고유의 플레이어 AWS 계정이 있습니다(그림 1). 마스터 계정의 다양한 구성 요소는 플레이어 계정에 로드를 제공하고 점수표 및 비용 계산기와 같은 기타 서비스를 호스팅합니다. 마스터 계정은 각 플레이어 계정에서 일상적인 관리 작업을 수행하기 위한 필수 권한을 제공하는 IAM 교차 계정 역할을 이용합니다.

그림 1: 마스터 – 플레이어 계정 관계

마스터 계정에는 다음과 같은 구성 요소가 있습니다.

  1. 점수표 – 이 항목은 Amazon Simple Storage Service(Amazon S3) 버킷에서 호스팅하는 정적 사이트이며 JavaScript와 HTML로 작성됩니다.
  2. 비용 계산기 – 플레이어가 비용 최적화를 생각해 보도록 유도하기 위해 Amazon Elastic Computer Cloud(Amazon EC2) 이용 요금을 실제 세계와 같은 방식으로 부과합니다. 비용 계산기에는 소비에 비례하여 포인트를 차감하는 AWS Lambda 함수가 포함되어 있습니다.
  3. Amazon DynamoDB – Amazon DynamoDB 테이블 여러 개에 팀 정보, 점수 정보, 일반 게임 구성 값 및 마스터 계정 구성 요소에서 사용하는 기타 지원 정보를 저장합니다.
  4. Load Generator – 이 구성 요소는 게임 구현의 핵심입니다. EC2 인스턴스 하나로 이루어진 이 Load Generator는 게임을 제어하고 관리 작업을 시작합니다.
    1. 플레이어 계정이 동적으로 생성되면 계정 생성 알림과 함께 마스터 계정의 Amazon Simple Notification Service(Amazon SNS) 주제에 메시지가 게시됩니다. Load Generator에서는 SNS 메시지를 기반으로 계정 등록/프로비저닝을 수행하기 위해 PHP 스크립트가 실행됩니다.
    2. Load Generator는 팀당 하나의 프로세스를 실행하여 각 플레이어의 계정에서 실행 중인 인프라에 연결을 시작합니다.
    3. 플레이어 계정에 제공되는 메시지 수는 이 Load Generator 인스턴스 내에서 팀별 추가 프로세스 생성에 따라 조정됩니다.

그림 2는 마스터 계정 아키텍처의 고급 개요를 보여 줍니다.

그림 2: 초기 아키텍처

심층 분석

검토 팀은 아키텍처를 이해한 후 심층 분석을 시작하여 Well-Architected Framework 백서의 부록에 있는 질문을 기반으로 다양한 구성 요소에 대해 심도 있는 질문을 했습니다. 특히 수작업(예: Load Generator의 작업), 재해 복구(예: 이벤트 전 손실된 자산의 복구 시간) 및 전체적인 애플리케이션 보안(예: 고객 데이터 및 자격 증명의 보안)에 높은 관심을 보였습니다. 전체 검토는 포괄적으로 이루어졌으며 완료하는 데 약 3시간 걸렸습니다.

검토 결과

검토 팀은 데이터를 통합하여 다양한 결과가 요약된 서면 보고서를 제공했습니다. 또한 검토 팀은 수정 계획을 개발하기 위한 시작점으로 삼을 수 있도록 각 결과에 대한 메모와 우선 순위에 따른 권장 사항도 제공했습니다.

Well-Architected Framework의 관점으로 GameDay를 살펴보면 많은 개선 기회가 있다는 점이 분명했습니다. AWS 검토 팀은 심각 및 권장이라는 두 가지 세트로 결과에 우선 순위를 지정했습니다. 대부분의 결과는 권장으로 분류되었으며, 이러한 결과는 즉각적인 위험이 없고 기존 로드맵에 통합됩니다. 하지만 심각으로 식별된 세 가지 요소는 즉시 처리해야 했습니다.

검토 팀이 제공한 결과 텍스트는 다음과 같습니다.

보안 11. 키를 어떻게 관리하고 있습니까?

  • 심각한 결과: GameDay용 레거시 관리 스크립트는 AWS 액세스 키와 보안 액세스 키를 사용하며 Amazon DynamoDB 테이블에 일반 텍스트로 저장됩니다.
  • 참고: 레거시 관리 스크립트는 플레이어 계정의 AWS API와 상호 작용하기 위해 AWS 액세스 키와 보안 액세스 키를 사용해야 하며, 교차 계정 역할을 지원하지 않습니다. 현재 이러한 키는 Amazon DynamoDB 테이블에 일반 텍스트로 저장되고 있으며, 스크립트는 이 테이블에 쿼리하여 키를 가져옵니다. AWS 액세스 키와 보안 액세스 키는 명시적으로 취소될 때까지 만료되지 않는 수명이 긴 자격 증명입니다. 이러한 키를 일반 텍스트로 저장하면 키가 손상될 가능성이 증가하며, 현재 설계에서는 DynamoDB 테이블에 읽기 액세스 권한이 있는 모든 사람이(애플리케이션 또는 애플리케이션 관리 인터페이스를 통해, 백업 또는 로그를 통해 간접적으로, 또는 AWS DynamoDB API를 통해 직접적으로) 키를 읽고 도용할 수 있습니다.
  • 권장: 교차 계정 역할을 지원하도록 레거시 관리 스크립트를 수정합니다. 그러면 AWS 액세스 키와 보안 액세스 키를 저장하여 사용할 필요가 없습니다.

안정성 7. 재해 복구를 어떻게 계획하고 있습니까?

  • 심각한 결과: 명확하게 정의된 재해 복구 계획, 복구 시점 목표(RPO) 또는 복구 시간 목표(RTO)가 없습니다. 또한 계획이 없기 때문에 RPO 및 RTO 목표를 기준으로 정기적으로 테스트할 수 없습니다.
  • 참고: GameDay는 원래 최소한으로 구성된 계정에서 플레이어가 반복적으로 실행하는 명령 세트로 계획되었습니다. 시간이 지나면서 도구 구성 및 부가 기능이 추가됨에 따라, 이전 단계로 돌아가서 전체 스택을 점검하고 우발적, 악의적 또는 환경적 결함으로부터 보호하는 방법을 고려할 수 없게 되었습니다. 단순한 게임일 뿐이지만, GameDay 고객은 하루 전체를 투자하여 참가하며 최대한 좋은 환경을 제공받을 자격이 있습니다. 이벤트 준비 중에 또는 라이브 게임 중에 허둥지둥 복구 프로세스를 만들어 내야 한다면 관련된 모든 사람에게 나쁜 경험이 될 것입니다.
  • 권장:
    1. RPO 및 RTO를 포함하여 재해 복구 계획을 정의합니다.
    2. 정의된 목표를 기준으로 계획을 정기적으로 테스트합니다.

안정성 2. 구성 요소 장애 시 시스템에서 어떻게 대처합니까?

  • 심각한 결과: 현재 Load Generator는 단일 가용 영역의 단일 인스턴스이며, 복구 옵션이 구성되지 않았습니다.
  • 참고: 하드웨어 결함 또는 가용 영역 장애(가능성은 낮음)가 발생할 경우 Load Generator 인스턴스가 장애를 일으키거나 사용 불가능하게 되면 장애 노드를 복구하기 위한 자동 프로세스가 없기 때문에 게임을 더 이상 계속할 수 없습니다. Load Generator는 현재 Auto Scaling 그룹에 속하지 않으며, EC2 인스턴스 복구도 구성되어 있지 않습니다. 또한 인스턴스가 수동으로 구성되었으며 필요한 모든 설정과 스크립트가 인스턴스에 포함되어 있지 않습니다. 마지막으로, 모든 상태가 인스턴스에 로컬로 저장되며 다중 인스턴스 아키텍처를 구현할 때 모든 상태를 세분화해야 합니다. 상태를 외부에 저장하면 인스턴스 장애로 인해 상태가 손실되는 문제도 완화할 수 있습니다.
  • 권장:
    1. 필요한 모든 구성 요소가 자체 완비된 Amazon 머신 이미지(AMI)를 생성하여 시작 구성이 포함된 EC2 Auto Scaling 그룹을 구현합니다. 선택 사항으로 사용자 데이터를 이용하여 필요한 모든 구성 요소를 준비할 수 있습니다.
    2. 여러 가용 영역에 걸쳐 Auto Scaling 그룹을 구성하여 아키텍처의 복원성과 내결함성을 향상합니다.
    3. 인스턴스를 상태 비저장으로 전환하여 장애가 발생할 경우 정보가 손실될 가능성을 낮춥니다.

다음 단계

검토 팀이 이 피드백과 해결해야 할 심각한 항목을 제공했으므로, 이제 이러한 결점을 해결하기 위한 수정 계획을 구성해야 합니다. 다음 블로그 게시물에서는 이 수정 계획을 살펴보고 이러한 항목을 해결하여 보안과 안정성을 향상하기 위한 계획 방법을 심층적으로 설명합니다.

2부

AWS Well-Architected 프레임워크 원칙을 활용하여 GameDay의 문제를 수정하는 프로젝트를 다룬 시리즈 중 두 번째 게시물을 시작해 보겠습니다. 이 프로세스의 개요, 초기 검토, 검토 팀에서 확인한 중요 결과 목록에 대해서는 본 게시물의 1부를 참조하십시오.

본 게시물에서는 검토 팀에서 확인한 중요 사항을 수정하기 위해 취한 조치를 다룹니다. 향후 게시물에서 지속적인 개선과 AWS 솔루션스 아키텍트와의 협업을 통해 아키텍처를 구체화하는 계획을 발표합니다.

결과 검토

검토 팀은 즉시 우선 순위를 정하여 수정하는 데 필요한 중요 사항 목록뿐 아니라 GameDay 아키텍처 로드맵에서 처리하도록 권장되는 일반 아이디어 목록의 우선 순위를 지정하고 수정하는 데 필요한 중요 결과 목록을 제공했습니다.

다음은 중요 항목입니다.

  • GameDay용 레거시 관리 스크립트는 Amazon DynamoDB 테이블의 일반 텍스트에 저장된 AWS 액세스 키와 보안 액세스 키를 사용합니다.
  • Load Generator는 복구 옵션을 전혀 구성하지 않은 단일 가용 영역의 단일 인스턴스입니다.
  • 재해 복구(DR) 계획이 명확하게 정의되지 않고, 복구 시점 목표(RPO)와 복구 시간 목표(RTO)가 설정되어 있지 않습니다.  또한, 재해 복구 계획이 RPO 및 RTO 목표를 기준으로 정기적으로 테스트되지 않았습니다.

검토 팀은 구현 전에 수정 계획을 기꺼이 검토할 것이라고 언급했으므로, 저희는 결함을 분석하고, 계획을 기록하고, 변경 전에 수정 사항을 실행하는 데 필요한 작업량을 대략적으로 추정할 것입니다.

다음은 필수 결과를 처리하기 위해 제안한 고급 수정 계획으로, 우선 순위 순서로 나열한 것입니다.

  • 교차 계정 역할을 사용하여 보안 키와 액세스를 사용하지 않습니다. 
    신속한 코드 검토의 경우 교차 계정 액세스를 개발하고 테스트하는 데 하루를 할애하고 지침을 업데이트하고 새 기능을 직원에게 교육시키는 데 추가 하루를 더 할애해야 한다고 제안했습니다. 이 수정 사항은 비교적 간단해 보이고 보안과 운영상의 이점을 모두 갖추고 있기 때문에 새 설계에 통합하기 위해 이 수정 사항을 최우선 순위에 놓기로 결정했습니다.
  • Load Generator의 경우 단일 인스턴스에서 클러스터링된 배포를 허용하는 컨테이너 모델로 전환합니다. 
    이 변경은 이전 액세스 키 수정 사항보다 약간 더 복잡했습니다. 로컬로 작성하지 않고 DynamoDB에 상태를 저장하도록 애플리케이션을 수정해야 했으며 다양한 애플리케이션과 바이너리를 Docker 컨테이너에 패키징해야 했습니다.  이 구성 요소별로 Amazon EC2 Container Service(Amazon ECS) 작업 정의와 서비스를 만들 계획을 세웠고, 이것은 예약과 작업 배치를 자동으로 관리할 것입니다. DynamoDB와 컨테이너로 전환하면 하드 코딩된 구성을 Auto Scaling 그룹 시작 구성으로 이동하고, 실행 시 변수 세트에 유리하게 하드 코딩된 모든 값을 제거하고, AWS CloudFormation 템플릿을 배포 메커니즘에 사용할 수 있게 됩니다.  정적 구성 파일이 아닌 DynamoDB와 Auto Scaling 그룹을 사용하기 위해 로드 관리 도구 및 게임 설정 스크립트를 업데이트해야 했다는 점을 감안하더라도 이러한 변경은 상당한 개선을 가져다 주고 전체 게임 흐름에 거의 영향을 미치지 않습니다. 새로운 기능을 개발하고 테스트하는 데 2주, 새로운 작업에서 문서를 업데이트하고 직원을 교육하는 데 일주일을 할애했습니다.
  • 재해 복구 계획을 세우고 이 계획을 검증합니다. Amazon ECS 및 Auto Scaling 그룹을 사용한 인프라 배포 자동화를 통해 재해 복구 계획을 간소화했지만 이는 완벽한 솔루션이 되지 못했습니다.  복구 프로세스에는 여전히 여러 문제점이 있었기 때문에 솔루션이 있지만 테스트하지 않았거나 최소한 여러 시나리오를 실행하면 계획을 이행할 때 프로세스의 문제점이 쉽게 드러날 것입니다.  계획을 세우는 데 추가로 1주일을 할애하고, 모든 비상 사태가 포함되어 예행 연습이 실시되었는지 확인하는 데 추가로 하루를 더 할애했습니다.

이 작업을 시작하기 전에 검토 팀에 계획을 전달하여 모든 요구 사항에 부합하도록 올바른 방향으로 진행했는지 확인했습니다.  검토 팀이 저희 작업에 동의하여 계획을 이행하기 시작했습니다.

최초 분석 및 아키텍처의 재구성

보기에는 목록이 간단해 보였지만 이들 항목에 공통적으로 근본적인 문제가 있음을 바로 깨닫게 되었습니다. 즉, 아키텍처가 상당히 단순하고 오래된 것은 물론, AWS 플랫폼의 최신 기능을 제대로 활용하지 못했습니다.  처음 GameDay를 빌드하던 당시에는 기능에 초점을 두고 이전 환경을 토대로 빌드했습니다.  따라서 이 아키텍처는 사실상 장애에 대비한 빌드, 재해 복구 기능 개선 필요성 등 최신 도구나 기법을 수용하지 못했습니다.

이러한 문제를 염두에 두고, 이 핵심 아키텍처 문제에 대처해야 한다는 사실을 깨달았으므로 중요한 사항 대다수를 해결하는 것은 물론 많은 일반 권장사항을 적용할 것입니다.  이 조치를 이행하기 위해 단일 인스턴스 Load Generator에서 Amazon ECS 클러스터에서 실행되는 Docker 컨테이터로 전환했습니다. 그 즉시 Multi-AZ 아키텍처의 이점을 활용하면서도 인프라를 확장하고 구성 요소 손실을 처리할 수 있게 되었습니다.  또한 AWS Lambda 함수로 실행되도록 Load Generator의 추가 서비스를 수정하자, 확장과 인프라 관리가 자동으로 처리되었습니다.

업데이트된 Amazon ECS 아키텍처

이 새로운 아키텍처를 실행하면서 이전 배포 프로세스에 수동 리소스 및 구성 생성이 포함되어 있다는 사실을 알게 되었습니다.  저희는 처음부터 인프라를 코드로 처리하고 AWS CloudFormation을 사용하여 환경을 정의하려는 확고한 입장을 취했습니다.  그 덕분에 수정 단계를 진행하고 새로운 재해 복구 계획을 세우는 데 중요한 역할을 담당하면서 인프라 버전을 쉽게 관리할 수 있었습니다.

문제 해결

문제 1: AWS 액세스 키

놀랍게도 이 항목은 가장 쉽게 해결할 수 있는 것으로 드러났습니다. AWS에는 계정 간 역할 기반 액세스를 지원하는 기능이 있습니다. AWS CloudFormation으로 관리자 계정과 플레이어 계정 구성을 이미 자동화했기 때문에 플레이어 계정에서 액세스/비밀 키 페어가 아닌 역할을 만들기 위한 템플릿 업데이트가 간단해 보였습니다.

처음에는 이 작업이 전체 코드 기반을 수정하여 sts:AssumeRole을 사용하는 방대한 작업이라고 생각했지만, 곧 간단한 작업임이 드러났습니다.  AWS SDK를 사용했고, 액세스 키와 IAM 역할이 기본 자격 증명 공급자 체인의 일부이고 SDK를 통해 완벽하게 지원되기 때문에 유일한 필수 변경은 액세스 키를 제거하고 맡을 역할 ARN을 전달하는 것이었습니다.

문제 2: Load Generator

이 문제를 해결하기 위해 단일 EC2 인스턴스에서 Amazon ECS 클러스터로 전환했습니다.  이 작업을 위해 팀 및 플레이어 데이터를 외부에 저장하도록 애플리케이션을 수정해야 했습니다.  이미 다른 메타데이터에서 Amazon DynamoDB를 사용하고 있었기 때문에 이 용도로도 이것을 선택했습니다.  Load Generator 컨테이너가 이제 임시로 사용되었고 새 서비스를 만들어 구성원을 추적하는 것이 아닌 업데이트를 푸시하려고 했기 때문에 DynamoDB로의 상태 전환 및 구성 폴링 작업은 필수적이었습니다.

Amazon ECS를 사용하면 Load Generator를 Amazon ECS 내부의 서비스로 작동할 수 있으므로 복잡한 분산 구성 관리 도구를 관리하지 않고도 게임 전체에서 애플리케이션을 확장할 수 있었습니다.  또한 내결함성을 강화하기 위해 세 가지 가용 영역에서 작업을 예약 및 배치하고 오류나 장애가 발생할 경우 컨테이너를 교체했습니다.

문제 3: 재해 복구

재해 복구는 시도한 수정 조치 중에서도 가장 난해한 작업이었습니다. 문제는 애플리케이션을 빠르고 안정적으로 배포해 주는 도구와 기법 활용에 대한 확장 계획을 이미 세웠기 때문에 기술적인 문제로만 국한되지 않았습니다. 그렇다면, 정의(재해를 어떻게 정의할 것인가?), 예상(합리적인 복구 시간 목표는?), 규정 준수(DR 테스트를 실행하는 주기는? 자동화할 수 있는 기능은? 테스트 프레임워크는 새 릴리스 이후에도 DR 계획의 유효성을 보장하는가?), 소유권(재해 선언 책임자는? 시간이 흐르면서 프로세스가 적절히 유지되도록 보장할 책임자는?)과 같은 과제는 해결이 더 어려운 과제입니까?

결국 이 모든 문제를 한꺼번에 해결하기 보다는 점증적이고 단계적인 접근 방식을 취하기로 결정했습니다. 시뮬레이션된 이벤트 손실(프로덕션 계정 제어력 상실)에 초점을 둔 시뮬레이션된 재난에 대한 대응 전략을 세우는 데 하루를 할애하고, 다른 결과를 작성하는 데 하루를 더 할애했습니다.

시뮬레이션된 테스트에는 시나리오 발표를 담당하는 중재자와 함께 팀원이 방 안에 앉아서 참여했으며 현재 보유한 모든 자료를 사용하여 복구 프로세스를 시뮬레이션했습니다. 중재자는 솔직한 태도로 응답하려고 노력하고, 시나리오가 진행되면서 세부 사항의 부연 설명을 할 것입니다. 복구 팀은 주의 사항을 기록하고, 허점, 행운 및 개선할 부분을 확인한 후 가장 중요한 유효 RTO 및 RPO를 기록합니다.

시나리오(프로덕션 계정 제어력을 완전히 상실)를 고려해 볼 때 우리가 취할 수 있는 유일하고도 안전한 대응은 이 계정을 포기하고 완전히 새로운 계정으로 복구를 시뮬레이션하는 것이었습니다. 이 목적으로 사용할 수 있도록 대부분 구성되지 않은 미사용 계정이 있어야 했고, RTO에서 계정 생성과 초기 설정을 고려해야 한다는 사실은 분명했습니다. 새 계정에서 게임 자산 배포는 새 CloudFormation 템플릿을 사용하면서 상당히 수월해졌고, 다행히 이 템플릿은 위반에 따른 영향을 받지 않는 다른 AWS 계정이 소유한 S3 버킷에 저장되어 있었습니다.

훨씬 더 큰 문제는 DynamoDB에 저장된 게임 데이터를 복구하는 일이었습니다. 현재 백업 계획은 수동으로 실행되었고, 소스 데이터와 동일한 계정 및 AWS 리전에 있는 S3 버킷에 푸시되었습니다. 확실히 기본 계정을 제어했던 공격자는 유일한 백업도 제어할 수 있을 것입니다. 계정 제어력을 상실한 이벤트에서 백업은 자동화되지 않고 액세스할 수 없기 때문에 RPO를 명확하게 정의할 수 없었습니다.  간단히 말해 이 시나리오에서는 복구 성공을 보장할 수 없었습니다.

이런 과제가 있더라도 DR 시뮬레이션은 꽤 성공적일 것이라고 생각했습니다. 복구를 테스트하고 실행 중인 작업(데이터 결합 해제, AWS CloudFormation을 통한 배포 자동화), 필요한 작업(자동화된 DynamoDB 백업 및 다른 계정의 S3 버킷에 감사 로깅), 현재 달성 가능한 RTO 및 RPO를 확인했습니다.

결국 직접적인 로드맵에 복구 및 감사 작업을 추가했고, 변경이 이뤄지고 새로운 재해가 예상되면 실제 대응 역량을 계속 조사할 수 있는 분기별 DR 시뮬레이션의 향후 케이던스에 동의했습니다.

결론

지금 시점에서 뒤돌아 보면 매우 취약한 아키텍처로 이 프로세스를 시작한 탓에 보안과 재해 복구 보안 및 재해 복구 관점에서 취약할 수 밖에 없었습니다.  우리의 단점을 확인하는 일은 내키지 않는 일이었지만, 유능한 AWS 솔루션 아키텍트들이 아키텍처를 단계별로 실행하면서 개선할 영역을 알려준 덕분에 변경 사항을 기록하고 우선 순위를 지정할 수 있었습니다.  이로써 한 걸음 물러나 잠재 문제를 계속 완화하면서 고객 환경 개선 작업에 주력하는 데 필요한 사항을 점검할 수 있었습니다.  이제 아키텍처에 대한 신뢰도가 훨씬 높아져 장애에 잘 대비할 수 있게 되었습니다.

그러나 재해 복구 시뮬레이션에서도 알 수 있듯이 GameDay 애플리케이션은 완벽하지 않습니다.  물론, 초기 검토에서 로드맵에 대한 권장 사항이 아직도 있습니다.  AWS에 새 기능이 추가되고 모범 사례가 업데이트되면서 다른 솔루션 아키텍트와 계속 협력하여 이러한 기능과 모범 사례를 아키텍처에 계속 통합하고 있습니다.

다음 게시물에서는 그 사이 AWS가 새로운 기능을 출시했다는 점을 고려하여 이 게시물에서 다룬 변경 사항을 적용한지 6개월이 되었을 때 어떤 일이 일어났는지 살펴보겠습니다.  이 새로운 기능에 대한 평가 과정을 거친 후 통합 가능한 부분을 살펴볼 것입니다.  그 외에도, 일반 항목에 대해서도 검토 팀과 어떤 방식으로 계속 협력했는지에 대해 다루겠습니다.

이 글은 AWS Partner 블로그에서 Ian Scofield, Juan Villa, and Mike Ruiz 가 작성한 Testing AWS GameDay with the AWS Well-Architected Framework  1부, 2부 등의 연재를 한국어로 번역하였습니다.