Category: AWS Partner Network*


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 DynamoDBAmazon 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부 등의 연재를 한국어로 번역하였습니다.

AWS 국내 파트너사 수상을 축하합니다! 메가존, NDS, 코오롱베니트, BSG파트너스

지난 2 개월 동안 호주, 싱가포르, 인도 및 한국을 포함한 전 세계 여러 곳에서 AWS Partner Summit을 개최했습니다. 본 행사에서 AWS는 여러 APN 컨설팅 및 기술 파트너 그룹의 업적을 인정하고, 이에 대해 감사의 마음을 담아 시상을 진행했습니다.  이중 한국에서 여러 파트너들이 수상하였습니다.

AWS 고객을 위해 그동안 수고해 주신 국내 수상 파트너사에 축하드립니다.

아시아 태평양 전체 수상 파트너사


APAC Partner of the Year: Megazone Corporation 

APAC Rising Star: NDS 
NDS 뉴스 읽기

한국 지역 수상 파트너사


Korea Consulting Partner of the Year: Megazone

Korea Innovation Partner of the Year: Kolon Benit

Kolon Benit 뉴스 읽기

Korea Rising Star Partner of the Year: NDS

NDS 뉴스 읽기
Korea Specialized Partner of the Year: BSG Partners

수상 하신 국내 파트너사에 축하드립니다! 2017년 남은 기간 동안 국내 AWS 파트너사의 건승을 기원합니다. AWS 파트너 프로그램에 대해 관심 있으신 분은 언제라도 APN에 가입하시거나, 문의해 주시기 바랍니다.

– AWS코리아 파트너팀;

AWS 9월 온라인 세미나 – 클라우드 보안 특집

AWS 한국팀에서도 AWS 클라우드를 아껴주시는 한국 고객 분들을 위해 지속적으로 “AWS 월간 웨비나 시리즈”를 진행하고 있습니다.

aws-security-webinar-2016-09

이번 9월 웨비나에서는 AWS의 보안 전문 파트너사들과 함께 클라우드 도입과 활용 과정에서 고려해야 할 다양한 보안 관련 요소들을 소개해 드리고자 합니다.

기존 온프레미스 환경에서의 보안 절차를 클라우드에서 구현하는 방법, AWS의 다양한 보안 관련 기능 및 서비스를 활용해 보안을 강화할 수 있는 모범사례, AWS 클라우드 기반의 아키텍처 보안을 더 강화하기 위한 파트너사 솔루션의 소개 등 다양한 내용으로 준비되어 있습니다.

기초 | AWS와 함께하는 클라우드 컴퓨팅
연사: 박은애 어카운트 매니저
일시: 2016년 9월 27일 (화) 오전 10:00 – 오전 11:30

강연 요약: AWS 클라우드는 IT의 새로운 기준을 정립하며 클라우드 컴퓨팅 산업을 혁신하고 있습니다. 이 세미나에서는 클라우드 컴퓨팅의 개념과 AWS가 제공하는 서비스 및 솔루션의 특장점, 주요 사용사례에 대해 말씀드리고 질답 시간을 가질 예정입니다. 부디 참석하셔서 귀사의 사업과 서비스에 적용할 수 있는 정보를 얻어가시기 바랍니다.

기초 | AWS 클라우드 보안의 이해
연사: 양승도 솔루션즈 아키텍트
일시: 2016년 9월 27일 (화) 오후 02:00 – 오후 03:30

강연 요약: AWS 클라우드를 사용하는 고객들의 데이터와 애플리케이션을 보호하기 위해 다양한 종류의 기능과 서비스를 제공하고 있으며, 강력한 보안 체계를 구축할 수 있도록 이런 기능과 서비스들을 도입하고 고객의 상황에 맞는 모범사례에 따라 인프라를 구축할 것을 권하고 있습니다. 이 강연에서는 AWS가 제시하는 보안 모델의 기초적 개념을 소개하고 다양한 보안 관련 기능 및 서비스의 활용법을 안내해 클라우드 위에서 확장성과 안전성을 두루 갖춘 아키텍처를 구축할 수 있는 방법을 알려 드리도록 하겠습니다.

기초 | AWS에서의 네트워크 보안(DDoS, UTM 및 WAF)
연사: 이경수 솔루션즈 아키텍트
일시: 2016년 9월 28일(수) 오전 10:00 – 오전 11:30

강연 요약: AWS 클라우드가 제공하는 보안 관련 서비스는 애플리케이션 레벨, 네트워크 레벨 등 다양한 레이어와 범위에 걸쳐 있습니다. 이 강연에서는 네트워크 레벨에서 허가되지 않은 접근과 DDoS 등 보안상의 위협을 막기 위해 취해야 할 모범사례들에 대해 소개하고 이를 구현하기 위해 네트워크 보안 구성 요소인 UTM과 WAF를 구성하는 방법에 대해 알아보도록 하겠습니다.

중급 | Deep Security를 통한 AWS에서의 보안 적용
연사: 양희선 차장, 트렌드마이크로
일시: 2016년 9월 28일(수) 오후 02:00 – 오후 03:30

강연 요약: 기업이 클라우드를 본격적으로 활용하기 위해 필요한 요소 중 하나는 기존 온프레미스 환경의 보안 체계를 클라우드에서도 활용할 수 있도록 설정하는 것입니다. 이 강연에서는 트렌드마이크로 Deep Security를 통해 기존의 물리적 환경에 구현되어 있던 보안 체계를 AWS 클라우드 상에 동일하게 구현하는 방법에 대해 말씀드리도록 하겠습니다.

중급 | AWS에서의 웹방화벽(WAPPLES)과 암호플랫폼(D’Amo) 적용
연사: 남경문 부장, 펜타시큐리티
일시: 2016년 9월 29일 (목) 오전 10:00 – 오전 11:30

강연 요약: 펜타시큐리티에서는 클라우드를 사용하는 기업들이 웹 어플리케이션과 최종 사용자들의 개인정보를 보호할 수 있도록 위하여 웹방화벽(WAPPLES)과 암호플랫폼(D’Amo)을 클라우드 환경에 맞추어 제공하고 있습니다. 이 강연에서는 클라우드 환경에서 왜 웹방화벽과 암호플랫폼을 사용해야 하는지 말씀드리고 AWS 클라우드에서 활용할 수 있는 펜타시큐리티의 보안 아키텍쳐와 이를 구현하는 방법에 대해서 소개하겠습니다.

중급 | AWS 클라우드 환경에서의 사전 방어(Prevention)
연사: 김민석 수석부장, 팔로알토 네트웍스
일시: 2016년 9월 29일 (목) 오후 02:00 – 오후 03:30

강연 요약: 팔로알토 네트웍스는 클라우드 환경을 위한 East West 트래픽 보안 통제 시스템을 통해 애플케이션에 대한 철저한 검증 및 클라우드 사용 권한 설정을 보안 관점에 촛점을 맞춰 원치 않은 이용자들의 접근을 제한해 드립니다. 이 강연에서는 클라우드 IT 환경에서의 다양한 보안 이슈 분석을 통해 위협에 사전 방어(Prevention)할 수 있는 구체적이면서도 효율적인 방안을 제시하고자 합니다.

클라우드 보안 특집 웨비나를 통해 클라우드 도입에 대한 다양한 정보를 얻으시길 바라며, 본 온라인 세미나에 대한 자세한 발표 내용 및 연사 소개는 월간 웨비나 홈페이지를 참고하시기 바랍니다.

– AWS 코리아 마케팅팀;

첫 AWS 매니지드 서비스 국제 파트너 선정 – 한국 vSystems

많은 고객들이 AWS 내 여러 리전을 넘어 다양한 산업군과 수준에 따라 매니지드 서비스(Managed Services)를 받고자 AWS 파트너의 도움을 요청하고 계십니다. 고객들에게 더 높은 품질의 서비스를 드리고자 제 3자의 검증 과정을 거쳐 매니지드 서비스 파트너를 선정하는데 높은 기준을 적용해오고 있습니다.

오늘은 AWS 매니지드 서비스 프로그램에 새롭게 선정된 국제 파트너들을 소개해 드리고자 합니다. Cloudreach (영국), Datacom (호주), Minjar (인도), NRI (일본), Smart421 (영국), Softchoice (캐나다) 및 vSystems (한국)입니다.

AWS 매니지드 서비스 프로그램 소개
AWS 매니지드 서비스 프로그램(Managed Service Program)은 높은 수준의 AWS 파트너가 AWS 고객들에게 비지니스 솔루션으로서 클라우드를 제공하는 기술 및 비지니스적 서비스를 제공하는 것입니다. 이러한 파트너를 선정하는 기준은 매우 높습니다. 저희 목적은 AWS 매니지드 서비스를 원하는 고객들에게 일관되고 높은 수준의 서비스를 제공하는 것입니다. 이에 따라 고객들이 더 쉽게 기준에 맞는 APN 파트너를 찾고 올바른 IT 서비스 관리 및 클라우드 서비스를 조합할 수 있는 깊은 지식을 전수 받을 수 있도록 합니다. 이 서비스에 선정하려면 매니지드 서비스 능력에 대한 제 3자의 검증 및 평가를 통과하여야만 합니다.

이번에 한국 vSystems가 새롭게 MSP로 선정되었습니다.

“MSP 인증을 통해 저희 vSystems가 매니지드 서비스에 대한 글로벌 표준에 부합하는지 역량을 확인할 수 있는 좋은 기회였습니다. 이 과정을 통해 객관적으로 서비스에 대한 내부 인식 및 상태를 조사할 수 있었습니다. 저희는 큰 AWS 고객사에 대해 몇 년에 걸쳐 기업형 매니지드 서비스를 제공해 왔으며 MSP 파트너로서 저희 역량을 보여 드릴 수 있게 되었습니다. vSystems는 계속 높은 수준의 매니지드 서비스를 고객들에게 제공하면서, 국제 표준 및 방법론 그리고 각종 도구를 통해 품질을 더 높여 나갈 예정입니다.” – 이근우 (CTO) vSystems

이 프로그램에 대해서는 지난 3월에 APN 영문 블로그를 통해 매니지드 서비스 프로그램 및 선정에 대한 소개를 하였습니다. 더 자세한 사항은 매니지드 서비스 프로그램을 참고하십시오.

본 글은 APN 파트너 블로그의 An Increasing Global MSP Presence – Announcing Our First International AWS MSP Partners의 한국어 요약 편집된 번역입니다.

AWS SaaS 파트너 프로그램 시작!

과거 CD로 소프트웨어를 배포하던 시기로 돌아가면, 출시 간격은 시간이 거의 분기 혹은 일년에 한번이었습니다. 너무 길고 느린 피드백 과정을 통해 고객들은 너무 오래 신기능이나 버그 수정을 기다려왔습니다.

오늘날 서비스로서 소프트웨어(Software as as Service, SaaS) 시대에서는 민첩한 개발 방법론지속적 통합으로 독립 소프트웨어 벤더(ISVs)들이 더 빠르게 혁신을 만들어서 공급할 수 있게 되었습니다. 고객들은 자신들의 비지니스가 성장하는 만큼 소프트웨어를 구매할 수 있고, 이를 통해 변화에 더 빠르게 대처하고 있습니다.

많은 ISV는 자신들의 SaaS 애플리케이션을 AWS 클라우드에 올리고 있습니다. 단일 혹은 멀티 터넌스 기반의 풍부한 기능의 편익과 글로벌 서비스 범위와 낮은 가격(및 주기적 인하), 높은 신뢰성 및 보안의 이익을 보고 있습니다.

신규 SaaS 파트너 프로그램
오늘 SaaS 개발사를 위한 새로운 글로벌 파트너 프로그램을 시작합니다. 이 프로그램은 APN (AWS Partner Network)에서 SaaS 고객을 위해 더 많은 솔루션을 만들도록 도와주게 됩니다.

이 프로그램은 비지니스 및 기술적 콘텐츠(문서, 기술 백서, 참고 아키텍쳐) 등을 제공하고 신규 파트너들이 AWS를 더 생산적이고 효과적으로 사용할 수 있도록 할 것입니다. SaaS 파트너 프로그램 웹캐스트와 오피스 아워 및 멀티 미디어를 활용합니다. 모든 자료들은 SaaS 비지니스의 각 단계별 파트너에게 맞도록 제작되었으며 고객의 편익을 높히는 솔루션을 만드는데 도움이 되도록 제작하였습니다.

새로운 Innovation Sandbox는 파트너에게 SaaS 제공 및 고객들이 무료로 서비스를 활용할 수 있도록 무료티어를 공급하도록 도움을 주는 플랫폼입니다.

더 자세한 사항을 살펴 보시려면, APN 블로그의 자세한 기사를 참고하시기 바랍니다. 만약 APN 파트너에 대해 더 자세히 알고 싶으시다면 AWS SaaS Partner 프로그램 홈페이지를 방문하세요.

— Jeff;

이 글은 New – AWS Partner Program for SaaS의 한국어 번역입니다.