[Games on AWS 2019] 오전 강연 | 새로운 게임을 준비하며 아쉬웠던 2% 를 채워줄 AWS 의 서비스와 기능 업데이트 - 안효빈 AWS 게이밍 솔루션즈 아키텍트

Editor's Notes

• #2: 안녕하세요 저는 Amazon Web Services 에서 솔루션즈 아키텍트로 근무하고 있는 안효빈입니다. 오전 세션의 마지막 시간은 신규 기능과 서비스에 대한 업데이트를 준비했습니다. 그래서 이번 시간에는 다양한 게임 장르 중에서 FPS 게임의 아키텍처를 바탕으로 그 게임을 구성하는데 사용되는 다양한 AWS 서비스의 기능 업데이트를 드리고, 기술 도메인 별로 새롭게 출시된 서비스를 소개해드리도록 하겠습니다.
• #3: 본격적인 서비스 이야기에 앞서서 우선 AWS 의 글로벌 인프라는 여전히 빠른 속도로 확장되고 있습니다. 가장 최근에는 중동의 바레인과 홍콩 리전이 오픈했고, 이에 따라 전세계에서 22개의 리전과 69개의 가용 영역을 운영 중에 있습니다. 추가로 화면의 빨간점으로 보이는 3군데 자카르타, 남아공, 그리고 이탈리아 밀란의 리전이 새롭게 오픈할 예정에 있습니다. CloudFront 나 Route53 과 같은 서비스를 제공하는 Edge 로케이션 역시 빠르게 확장하여 현재 전세계 33개국 73개 도시에서 191개의 PoP 을 통해 제공되고 있습니다. 이 역시도 지속적으로 확장해 나가고 있습니다.
• #4: AWS 의 리전, 가용 영역, 그리고 엣지로케이션은 굉장히 빠른 이중화된 100G 네트워크로 연결되어 있습니다. 따라서 개발하신 게임의 글로벌 서비스를 고려하고 계시다면 전 세계의 사용자들이 이러한 AWS 의 Backbone 네트워크를 타고 게임에 접속하도록 아키텍처를 구성하실 수 있습니다. 여기에는 CloudFront 나 이후에 설명드릴 Global Accelerator 와 같은 서비스를 사용하실 수 있고, 직접 자체 프록시를 구축하셔서 운영하는 것도 가능합니다.
• #5: 지난 4월에 런칭한 홍콩 리전에 대해 조금 더 설명 드리도록 하겠습니다. 많은 게임사에서 대만 진출에 관심이 있으실 것으로 보입니다. 이럴 경우에 이용하실 수 있는 것이 바로 홍콩 리전입니다. 대만과 홍콩 사이 네트워크 라우팅 최적화 작업이 있었습니다. 이에 따라 대만의 사용자들이 퍼블릭 인터넷을 통해 홍콩 리전에 접속하더라도 화면에 보시는 것과 같이 빠르고 안정적인 네트워크 성능을 기대하실 수 있게 되었습니다. 이후 대만 런칭을 준비 중이시라면 홍콩 리전을 한번 고려해보시는게 좋을 것 같습니다.
• #6: 이렇게 빠르게 확장하고 있는 AWS 인프라로 마이그레이션 하시는 방법도 이미 아시는 것처럼 다양하게 제공하고 있습니다. 한가지는 물리적으로 페타바이트 규모의 데이터를 빠르게 마이그레이션 할 수 있는 Snowball 의 경우 지난 7월 서울에도 런칭했습니다. 이를 통해 한국 고객분들이 조금 더 빠르고 간편하게 온프레미스에서 AWS 클라우드로 마이그레이션이 가능해졌습니다.
• #7: 그 외에 온프레미스의 데이터를 AWS 의 S3 나 EFS 로 빠르게 가져올 수 있게 도와주는 DataSync 서비스가 추가되었습니다. DataSync 는 관리형 온라인 데이터 전송 서비스로, 인터넷 또는 AWS Direct Connect를 통한 온프레미스 스토리지 시스템과 AWS 스토리지 시스템 간 대량의 데이터 이동하고 복제할 수 있습니다. 이를 통해 온프레미스의 수백만 개의 데이터 세트를 AWS 로 손쉽게 이동, 복사, 동기화까지 가능하게 됩니다. 일회성 마이그레이션이나, 지속적인 복제 모두에 사용하실 수 있는 서비스입니다.
• #8: 동작은 표준 NFS 를 지원하는 에이전트를 온프레미스에 배포하시게 되구요, 이 에이전트가 로컬 NFS에 액세스 하여 데이터를 읽고 쓰는 작업을 하게 됩니다. 이후에 전송 작업을 생성하면 됩니다. 현재는 최대 10G 의 속도로 데이터 전송이 가능합니다.
• #9: 이제부터는 본격적으로 새로운 기능에 대한 설명을 드리도록 하겠습니다. AWS 는 매년 굉장히 빠른 속도로 새로운 서비스와 feature 를 업데이트 하고 있습니다. 2017년에는 1430건, 그리고 2018년에는 1957건의 업데이트가 있었습니다. 2019년에는 2천개가 넘는 서비스와 기능 업데이트가 있을 것으로 생각됩니다. 지금부터는 본격적으로 작년 11월 이후 새롭게 출시된 서비스와 feature 중에서 여기 계신 게임 업계의 고객분들에게 직접적인 도움이 될 만한 기능들만 소개해드리도록 하겠습니다.
• #10: 화면에 보시는 아키텍처는 많은 분들이 FPS 게임을 런칭하실 때 고려하시는 구성이라고 생각됩니다. 당연히 게임마다 각기 다른 특징이나 요구사항이 있고, 개발자의 취향도 다르기 때문에 실제 현재 운영 중이신 게임들과는 디테일이 다르실 겁니다. 하지만 하나의 큰 맥락에서 본다면 많은 공통점이 있을거라 생각됩니다. 그래서 유저는 S3 에 저장되어 있는 컨텐츠나 패치 파일 등을 CloudFront 를 통해서 다운 받게 되구요, 그 뒤에는 하단의 코어 서비스 부분에서 플레이어간의 매치 메이킹이 이루어지고, 기타 스탯이나 전력을 가져오는 작업이 이루어 집니다. 실제 게임의 플레이는 좌측의 세션 서버군에서 어느 플레이어가 누구에게 데미지를 주었는지와 같은 게임 플레이 자체의 싱크를 할 수 있습니다. 그리고 마지막으로 우측이 데이터베이스들로 게임 결과를 저장하거나 게임 내 상점의 결제 등이 이루어 지는 구조를 많이 체택하고 계십니다.
• #11: 그러면 앞에 살펴보신 아키텍처에서 사용된 서비스들을 카테고리 별로 나누어서 간단히 설명 드리고, 신규 기능에 대한 소개를 드리도록 하겠습니다. 우선 네트워크 부터 시작하겠습니다.
• #12: 해당 아키텍처에서 네트워크 서비스에 해당하는 것은 좌측의 CloudFront, VPC 그리고 Elastic Load Balancer 입니다.
• #13: 우선 CloudFront 는 이미 너무나도 유명한 CDN 서비스 입니다. 앞서 살펴보신 191 개의 AWS 엣지 로케이션을 활용하여 엔드 유저에게 컨텐츠를 더 빠르게 배포할 수 있도록 도와드리는 서비스입니다. 한가지는 이미지와 같은 정적 컨텐츠의 캐싱에만 사용할 수 있는 것이 아니라 동적 컨텐츠 및 API 가속에도 이 CloudFront 를 활용하실 수 있습니다. 이는 AWS 의 Global Backbone 네트워크를 활용하여 유저들이 게임 서버에 접근할 때 AWS 의 고속 네트워크를 통한 빠른 접근이 가능할 수 있기 때문입니다. 그래서 이미 많은 고객 분들이 웹 기반 게임의 네트워크 가속 용도로 사용하고 계시고, 패치 파일 등의 배포에는 거의 모든 고객 분들의 S3 오리진을 활용한 CloudFront 배포를 사용하고 계십니다.
• #14: 그리고 이제는 WebSocket 프로토콜을 사용하는 멀티 플레이 게임이나 애플리케이션 에서도 CloudFront 를 사용하여 최종 사용자에게 더 빠른 성능과 보안을 제공할 수 있게 되었습니다. 현재 WebSocket 을 통한 게임을 고려하고 계시다면 CloudFront 에서 추가 구성 없이 해당 기능을 활성화하여 사용하실 수 있습니다. 한가지 제약 사항으로는 10분간 오리진과 클라이언트 사이의 전송이 없다면 유후 상태로 간주하여 연결이 종료됩니다.
• #15: 다음은 가장 대표적인 네트워크 서비스인 Amazon VPC 입니다. 현재 AWS 를 사용 중이신 모든 분들이 이미 VPC 를 사용하고 계십니다. 이 서비스는 AWS 클라우드에 논리적으로 격리된 네트워크 공간을 프로비저닝하고 AWS 의 EC2나 RDS와 같은 리소스들을 생성할 때 내가 정의한 네트워크 환경에서 구동되도록 하는 모든 인프라의 기반이 되는 서비스입니다.
• #16: VPC 에서 소개해드릴 만한 신규 기능은 VPC 의 공유 기능으로 관리를 조금 더 편리하게 해주는 기능이라고 이해하시면 될 것 같습니다. 이전까지는 VPC 를 사용하는 사용자가 VPC 의 소유자이기도 했습니다. 따라서 회사에서 EC2 인스턴스 한대만 필요했더라도 이를 생성하기 위한 VPC 까지 별도 생성하고 관리해줬어야 했습니다.
• #17: 하지만 VPC Sharing 기능을 사용하다면 일종의 중앙 관리형 VPC 를 생성하시는게 가능합니다. 네트워크팀에서 VPC 를 생성한 뒤 개발팀에 VPC 를 공유해준다면 개발팀에서는 더 이상 VPC 를 생성할 일 없이 할당받은 VPC에 원하는 리소스를 생성하는게 가능해지게 됩니다. VPC Sharing 을 사용하게 되면 해당 VPC 의 소유자와 사용자가 구분이 되게 됩니다. VPC 소유자는 VPC 를 만들고 관리 하는 작업등을 수행할 수 있으나 참여자가 생성한 보안그룹이나 VPC 내의 리소스를 수정하거나 삭제하는 것은 불가능합니다. VPC 사용자의 경우는 VPC 내에 필요한 서버나 DB 를 생성하고 사용할 수 있지만, 네트워크 자체인 VPC 에 대한 라우팅 구성을 바꾸는 등의 작업은 불가능합니다. 또한 다른 참여자의 리소스를 수정하거나 접근하는 것도 불가능합니다.
• #18: 네트워크에서 소개드릴 마지막 서비스는 바로 ELB, Elastic Load Balancing 입니다. ELB 는 로드 밸런싱 기능을 제공하고 들어오는 트래픽을 여러 가용 영역의 EC2 인스턴스나 컨테이너, 특정 IP, Lambda 등으로 자동 분산 해주는 기능을 제공합니다. ELB 는 현재 클래식, 애플리케이션, 네트워크 3가지 유형의 로드밸런서를 제공해서 개발하시는 게임의 프로토콜에 따라 선택하여 사용할 수 있었습니다. 현재 웹 기반 게임은 애플리케이션 로드 밸런서를 사용하고 계시고, TCP 기반 게임에서는 네트워크 로드 밸런서를 사용할 수 있습니다.
• #19: 이전 까지는 UDP 프로토콜을 지원하는 ELB 가 없었지만, 이제는 네트워크 로드 밸런서에서 UDP 프로토콜을 지원하게 됐습니다. 네트워크 로드 밸런서는 4계층에서 동작하는 로드 밸런서로 초당 수백만개의 요청을 처리할 수 있는 대용량 로드 밸런서입니다. FPS 장르와 같은 UDP 기반 게임에서 이제는 게임 서버들 앞에 NLB 를 통한 로드 밸런싱이 가능해졌습니다. 그리고 지난달 발표된 HTTP3 에서 UDP 로의 확장에 대한 이야기가 있었습니다. 이렇게 최근 UDP 에 대한 수요가 많아지고 있는 상황에서 NLB 의 UDP 지원에 관한 것도 알아두시면 좋을 것 같습니다.
• #20: 지금부터는 컴퓨트 쪽을 한번 살펴 보겠습니다.
• #21: 아키텍처 상에 모든 서버에 해당하는 EC2 그리고 우측에 몇가지 로직 처리에 사용하는 Lambda 가 컴퓨트 서비스에 해당합니다.
• #22: 우선 EC2 부터 간단히 설명을 드리도록 하겠습니다. EC2 는 너무 유명한 코어서비스로 AWS 를 이용 중이신 고객분들은 거의 모두 사용하고 계신 서비스일 것으로 보입니다. EC2 는 AWS 의 가장 대표적인 컴퓨트 서비스로 클라우드에서 컴퓨팅 파워를 제공하는 즉 가상 서버에 해당하는 서비스입니다. 당연히 여러 게임 서버, API 서버, 상점이나 로비 서버 등 모든 서버에 활용되고 있는 서비스가 바로 EC2 입니다.
• #23: EC2 의 경우는 사용하시고자 하는 워크로드에 따라 다양한 인스턴스 타입 중 선택하시는게 가능합니다. AWS는 고객분들의 워크로드가 다양해짐에 따라 이러한 인스턴스 타입도 계속 추가하고 있습니다. 최근 추가된 인스턴스 타입 중 첫번 째는 C5n 인스턴스입니다. C5 인스턴스는 컴퓨팅 최적화 인스턴스로 EC2 중 vCPU 당 가격이 가장 낮아 높은 CPU 파워가 게임에 많이 사용되고 있습니다. 이번에 추가된 C5n 타입에서 n 은 네트워크를 의미합니다. 그래서 Nitro 시스템을 기반으로 기존 C5 에서 제공하던 최대 25G 네트워크 대역폭에서 한층 업그레이드 되어 최대 100G 의 네트워크 대역폭을 제공합니다. 또한 일반 C5 인스턴스보다 33% 높은 메모리도 제공합니다. 높은 네트워크
• #24: 두번 째 소개드릴 인스턴스는 AWS 에서 ARM 기반으로 최초로 제공하는 A1 인스턴스로 최대 45% 저렴한 비용으로 사용하실 수 있는 인스턴스입니다. 개발하시는 게임이 단일 코어 성능에 의지하지 않는 마이크로 서비스 형태이거나 혹은 캐싱용도로 사용하는 서버에 사용을 고려해보실 수 있을 것 같습니다.
• #25: AMD 기반 인스턴스도 추가되었습니다. 여기에는 모두 AMD EPYC 7000 시리즈의 프로세서가 탑재되어 있고 10% 더 낮은 비용으로 EC2 인스턴스를 활용하시느넥 가능합니다. AMD 기반 인스턴스는 M5, R5 그리고 T3 타입 3가지를 지원합니다. 이에 따라 고성능 DB 나 메모리 캐시 등과 같이 메모리 집약적인 목적으로는 R5 타입을 범용 목적의 게임 서버나 애플리케이션 서버에는 M5 타입을 활용하실 수 있습니다.
• #26: EC2 의 기능도 업데이트가 있었습니다. 하이버네이션이라고 하여 최대 절전 모드를 생각하시면 될 것 같습니다. 인스턴스를 이렇게 최대 절전 모드로 설정 하시면 인스턴스를 중지한 것과 마찬가지로 EBS 볼륨과 EIP 에 대한 요금만 발생하게 됩니다. 하이버네이션 모드를 설정하시게 되면 해당 시점의 인메모리의 상태와 EIP 를 EBS 볼륨의 파일에 저장한 뒤에 인스턴스가 종료됩니다. 따라서 이후 인스턴스를 시작할 때 이전 작업에서와 동일한 시점에서 인스턴스가 시작되게 됩니다. 활용하시는 방법은 단순히 하이버네이션을 활성화 하시기만 하면 바로 해당 기능 사용하실 수 있습니다. EC2 상에서 뭔가 작업하시고 퇴근하실 때 굉장히 유용하게 활용할 수 있을 것으로 보입니다.
• #27: 컴퓨트에서 두번 째 서비스는 바로 AWS Lambda 입니다. Lambda 는 서버리스 컴퓨팅의 대표적인 서비스로 작성한 코드를 서버 없이 단지 실행해주는 서비스입니다. 동작은 이벤트 기반으로 하게 되며 설정하신 특정 이벤트가 발생했을 때 해당 코드가 실행되게 됩니다. 서버로는 활용할 수 없지만 게임 플레이 완료 후 해당 내용을 DynamoDB 에 기록한다거나 운영 자동화 등에 사용하는 것이 가능합니다.
• #28: 이러한 Lambda 를 애플리케이션 로드 밸런서의 타겟으로 지정하는 것이 가능해졌습니다. 그래서 ALB 의 규칙을 설정해서 헤더값에 따라 특정 HTTP 요청은 Lambda 가 처리하도록 구성하는게 가능합니다. 당연히 EC2 인스턴스와 함께 사용할 수 있고, 로드밸런서에서 상태확인을 하기 때문에 이 때 Lambda 호출 비용이 발생하게 됩니다.
• #29: 다음은 스토리지 영역을 살펴 보겠습니다.
• #30: 아키텍처 상에는 S3 와 EC2 인스턴스에서 사용 중인 EBS 볼륨이 이에 해당합니다.
• #31: 우선 S3 는 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있는 인터넷 기반의 객체 스토리지입니다. S3 에 파일 하나를 저장하시게 되면 기본적으로는 6 카피가 저장되기 때문에 굉장히 높은 가용성을 제공하고, 다양한 암호화 옵션 등을 통해 높은 보안을 제공하는 스토리지 서비스입니다. 이러한 특징과 파일 저장 비용이 저렴하기 때문에 인 게임 로그를 저장하여 분석에 활용하시거나 게임 컨텐츠의 배포에 정말 많이 사용되고 있는 서비스입니다.
• #32: S3 에서는 성능과 비용에 대한 업데이트가 있었습니다. 지금 보시는게 이전까지의 S3 성능입니다. 동일한 프리픽스의 2MB 파일 5테라를 S3 에 쓰고 읽는데는 앞에 보시는 정도의 시간이 필요했습니다. 물론 테스트 환경에 따라 달라질수는 있는 속도입니다.
• #33: 그리고 이번에 성능 개선을 통해 보시는 것처럼 쓰기와 읽기 성능 모두가 향상된 것을 확인하실 수 있습니다.
• #34: S3 에서는 병렬 요청을 지원하기 때문에, 이러한 성능 개선과 더불어 parallel processing 을 하게 되면 보시는 것처럼 dramatic 한 성능 개선 효과를 얻으실 수 있습니다. 병렬 요청을 하는 방법은 아래 보시는 것처럼 단순히 프리픽스가 늘리는 것을 통해 가능합니다.
• #35: S3 intelligent tiering 이란 기능이 업데이트 되었습니다. S3 에 스토리지 클래스라는 개념이 있다는 것은 이미 아시는 사실일 것 같습니다. 일반적으로 사용하게 되는 Frequent access tier 가 있었구요, 데이터에 액세스가 자주 이루어 지지 않을 경우에는 Infrequent access tier 클래스를 사용하면 보다 저렴한 비용으로 데이터를 저장할 수 있었습니다. 저장 비용은 절반 수준으로 저렴해지는 대신에 API 호출에 대한 비용이 올라가는 스토리지 클래스였죠. 이 둘을 적절하게 사용하는 것만으로도 S3 요금을 효율화 할 수 있었습니다. 그리고 이번에 S3 intelligent tiering 기능이 업데이트 됨으로써 성능/운영 등에 영향 없이 스토리지 비용을 자동으로 최적화하는 클래스가 출시되었습니다. 동작은 객체별로 액세스 패턴을 모니터링 하여 30일 연속으로 액세스 하지 않은 객체에 대해 자동으로 IA 로 이동하는 방식으로 동작합니다. 이후에 다시 액세스가 발생할 경우에는 Frequent Access 티어로 객체가 이동하게 됩니다. 티어간 이동에 대한 추가 요금은 없기 때문에 S3 에 데이터를 저장하여 운영중이신 고객분들께서는 바로 사용해보실 수 있을 것 같습니다.
• #36: 또 다른 S3 스토리지 클래스 중 Glacier 라는 아카이빙 용도의 스토리지가 있었습니다. 테이프 장비에 데이터를 보관하시는 것과 같은 기능을 제공하던 서비스 였는데요, Glacier Deep Archive 라는 기능이 새롭게 추가되었습니다. 이를 통해 기존 Glacier 보다 75% 저렴한 비용으로 데이터를 아카아빙 하여 보관하는게 가능해졌습니다. 0.00099 센트가 조금 와닿지 않으실텐데 100GB 저장하시는데 약 1원 정도라도 생각하시면 될 것 같습니다. 이러한 아카이빙 용도로 제공되는 Glacier 는 파일을 한번 저장하시면 바로 사용하시는게 불가능합니다. 다시 S3 로딩한 후에 해당 데이터에 접근이 가능하신데요, Glacier Deep Archive 의 경우는 한번 저장하신 뒤에 약 12시간 정도의 데이터 복원 시간이 필요합니다. 일반적인 Glacier 는 파일 복원에 약 3시간 정도 소요됩니다. 때문에 꼭 이런 점을 고려하여 정기 감사 등과 같이 예정된 스케줄에만 필요한 데이터를 저장하시는 것을 권장합니다.
• #37: 다음 이야기할 스토리지는 EBS 볼륨입니다. EBS 는 EC2 인스턴스에서 사용하도록 설계된 고성능의 블록 스토리지입니다. SSD 와 HDD 두가지 타입에서 총 4 가지의 볼륨 타입을 현재 제공하고 있습니다. 조금 헤비한 워크로드와 같은 MMORPG 게임을 운영할 때도 EBS 에서 충분히 높은 I/O 를 제공하여 모든 장르의 게임에서 이미 사용 중인 블록 스토리지 입니다.
• #38: EBS 역시도 성능 향상이 있었습니다. Provisioned IOPS 라고도 불리는 io1 볼륨의 경우 최대 성능이 두배로 증가하여 볼륨당 64,000 IOPS 까지 제공하며 초당 처리량도. 500MB 에서 1000MB 로 증가했습니다. 일반적으로 사용하시고 계실 GP2 옵션의 경우 최대 버스트 IO 가 16000 IOPS 로 60% 증가했습니다. EBS 볼륨의 경우 EC2 인스턴스와 함께 사용되기 때문에 사용 중이신 EC2 인스턴스 타입에서 제공하는 최대 I/O 를 함께 고려하셔야 하는 점은 기억해주시기 바랍니다.
• #39: 마지막으로 데이터 베이스 입니다.
• #40: 이번에 설명드리는 아키텍처에는 RDS 와 DynamoDB 두 가지를 사용하고 있습니다.
• #41: 첫번 째로 이야기 드릴 서비스는 관계형 데이터베이스 서비스인 Amazon RDS 입니다. 이미 익숙하신 MySQL, MariaDB, Oracle, MS SQL, PostgreSQL 등을 관리형으로 제공해드리는 서비스로 기존의 DBA 가 해야하는 많은 관리 작업을 자동으로 수행할 수 있는 서비스입니다.
• #42: RDS 에서 처음 드릴 업데이트는 SQL Server 의 Always On 기능입니다. 굉장히 많은 게임 고객분들께서 SQL Server 를 게임에 활용하고 계신데, 이제 RDS 에서 제공하는 Always On 기능을 통해 엔터프라이즈 급 프로덕션 워크로드를 충족할 수 있게 되었습니다. 이를 활용하도록 DB 를 생성하거나 수정하실 경우, 하나의 가용 영역에 기본 데이터베이스를 프로비저닝하고 상시 가용성 그룹을 사용하여 다른 가용 영역에 동기식 "예비" 복제본을 유지하게 됩니다. 이후에 DB Maintenance나 예기치 않은 서비스 중단이 발생할 경우, SQL Server 데이터베이스를 최신 예비 복제본으로 자동으로 장애 조치를 수행하므로 데이터베이스 작업을 빠르게 재개하는게 가능합니다. 지원하는 버전은 SQL Server 2016 과 2017 입니다.
• #43: RDS 스토리지의 Auto Scaling 기능도 업데이트 되었습니다. 아마 기능의 이름만으로도 어떤 내용이실지 감이 잡히실 것 같습니다. 운영 중이신 RDS 스토리지의 여유 공간이 10% 미만일 경우 자동으로 스토리지의 확장이 이루어집니다. 이때 증분은 5GB 혹은 전체 스토리지의 12% 중 더 많은 양이 추가 됩니다.
• #44: 실제 동작은 화면에서와 같이 해당 기능을 활성화를 우선 해주셔야 합니다. 이후에 화면에서 보시는 것처럼 USERS 테이블의 스토리지 여유 공간이 부족해지면
• #45: 다음과 같이 스토리지가 스케일링됩니다. 설명 드린 것과 같이 5GB 와 12% 중 큰 값으로 증분이 이루어지며, 화면에는 5GB 의 용량이 추가된 것을 확인하실 수 있습니다.
• #46: RDS 중 저희 AWS 에서 개발한 Aurora 엔진은 MySQL 과 PostgreSQL 과의 호환성을 제공합니다. 표준 MySQL 보다는 5배 빠른 성능을 제공해드리고 PostreSQL 보다는 약 3배 빠른 성능을 기대하실 수 관계형 데이터베이스 입니다. Amazon Aurora 의 활용 사례나 성능에 관한 보다 자세한 내용은 오후에 Aurora 관련된 세션에서 보다 많은 정보를 얻으실 수 있을 것 같습니다. 이번 시간에는 Aurora 의 두가지 업데이트만 간단히 소개드리도록 하겠습니다.
• #47: 첫번째 소개드릴 업데이트는 Aurora Global Database 입니다. 이는 글로벌하게 분산된 애플리케이션을 위해 설계되었으며, 단일 Amazon Aurora 데이터베이스를 여러 AWS 리전으로 확장해 주는 기능을 제공합니다. 이를 지원하기 위해서, 데이터베이스 성능에 어떠한 영향도 주지 않고 데이터를 복제하고, 각 리전에서 낮은 지연 시간으로 빠른 로컬 읽기를 지원하며, 리전 규모의 가동 중단 발생 시 재해 복구를 제공합니다. Global Database 는 일반적으로 1초 미만의 지연시간으로 스토리지 기반 데이터 복제를 합니다. 결과적으로는 모든 리전에서 해당 Aurora RDS 데이터에는 1초 이내에 접근할 수 있다는 이야기입니다. 또한 이러한 기능을 활용해 특정 리전 전체에 장애가 나더라도 다른 리전 중 하나의 DB 인스턴스가 1분 이내에 읽기/쓰기 기능으로 승격이 가능해지기 때문에 1초의 RPO 와 1분의 RTO 를 제공하는 DR 구축이 가능해집니다.
• #48: 두번 째 업데이트는 지난 8월에 GA가 된 Aurora 의 멀티 마스터입니다. 제목 그대로의 기능을 제공해서, 이 기능을 활용하실 경우 Aurora 데이터베이스가 애플리케이션 다운타임 없이 읽기 및 쓰기 가용성을 유지할 수 있습니다. 이전까지는 쓰기가 가능한 인스턴스에 장애가 발생할 경우에는 Failover 를 했어야 했지만 화면에 보시는 것과 같이 Multi Master 에서는 단일 장애점이 없습니다. 또한 각 인스턴스의 fail 이 다른 인스턴스에 영향을 주지 않습니다. 일반 Amazon Aurora 와 마찬가지로 데이터는 여전히 3개 가용영역의 6개의 스토리지 노드에 데이터 쓰기 작업이 이루어집니다.
• #49: 아직 출시된지 얼마 안된 기능이라 몇가지 제약 조건이 있습니다. 현재는 하나의 리전내에서만 Multi Master 를 구성하실 수 있으며, 몇 가지 추가적인 RDS 나 Aurora 의 제공 기능을 사용하실 수 없는 제한이 있습니다. 하지만 Aurora 의 경우 AWS 에서 가장 빠르게 성장하고 있는 서비스 중 하나이기 때문에 지속적인 개선이 이루어질 것입니다.
• #50: 다음 이야기 드릴 데이터베이스는 대표적인 NoSQL 엔진 중 하나 Amazon DynamoDB 입니다. DynamoDB 는 어떤 규모에서도 10ms 미만의 굉장히 높은 성능을 보여주는 Key-Value 및 Document 기반 NoSQL 엔진입니다. DynamoDB는 하루에 10조 개 이상의 요청을 처리할 수 있고, 초당 2,000만 개 이상의 피크 요청을 지원할 수 있을 만큼 높은 성능을 제공합니다. 또한 서버리스입니다. RDS의 경우 DB 인스턴스의 관리가 필요했다면 DynamoDB 의 경우 별다른 서버 관리가 필요하지 않습니다.
• #51: 개발자들은 때론 하나 이상의 테이블에서 여러 개의 별도 작업을 묶는 비즈니스 로직을 구현 할 일이 필요합니다. 이 때 트랜잭션을 걸게되면 굉장히 작업을 처리 하게 되는데, NoSQL 인 DynamoDB 에서 이전까지는 트랜잭션을 지원하지 않았습니다. 따라서 이전에는 이러한 요구사항을 DynamoDB 를 통해 구현하려면 애플리케이션 자체에서 복잡한 로직이 추가로 필요했었습니다.
• #52: 이러한 어려움을 해결해드리고자 DynamoDB 에서 트랜잭션 기능을 지원하게 됐습니다. 이를 통해 DynamoDB 테이블에서 ACID를 제공합니다. 하나의 비지니스 로직 작업 중에 여러 항목에 대해 삽입, 삭제 또는 업데이트를 조정해야 하는 애플리케이션을 구축할 때 트랜잭션을 사용할 수 있습니다. DynamoDB는 여러 파티션과 테이블에서 트랜잭션을 지원하는 최초의 비관계형 데이터베이스가 되었습니다. 활용은 간단히 TransactionGetItems, TransactionWriteItems 를 호출하는 것으로 통해 가능합니다.
• #53: 새로운 용량 모드인 DynamoDB 온디맨드도 추가되었습니다. 기존의 DynamoDB 는 읽기/쓰기 용량을 지정해주고, 이것이 Auto Scaling 을 통해 조정되었습니다. 이번에 새롭게 나온 DynamoDB 온디맨드는 이러한 용량 계획없이 초당 수천 건의 요청을 처리할 수있는 DynamoDB의 유연한 새 용량 모드입니다. DynamoDB 온디맨드는 읽기 및 쓰기 요청에 대한 간단한 요청별 가격 책정 기능을 제공하므로 사용하는 제품에 대해서만 비용을 지불하므로 비용과 성능의 균형을 쉽게 맞출 수 있습니다.
• #54: 이전의 Provisioned 모드와 비교한다면 화면의 그래프와 같은 차이가 있습니다. 이전에는 어느정도의 용량을 예측하고 Peak 가 발생했을 때 Scale out 되는 시간이 필요했었습니다. 하지만 새로운 온디맨드 모드에서는 DynamoDB가 모든 워크로드를 수용하기 위해 신속하게 늘어나게 됩니다. 둘 사이의 과금 체계가 다르기 때문에 보다 자세한 내용은 DynamoDB 페이지를 참고해보시기 바랍니다. 또한 오후 DynamoDB 워크샵에 참여하시면 설명 드린 내용 등을 포함해 보다 다양한 DynamoDB 활용 사례에 대해 알아보시고 실습해보실 수 있습니다.
• #55: 지금까지 이미 사용중이실 서비스에 대한 신규 기능을 살펴봤습니다. 지금부터는 이러한 게임을 개발하시거나 운영하실 때 도움이 될 만한 새로운 서비스를 살펴보도록 하겠습니다.
• #56: 기능 설명에서와 마찬가지로 기술 도메인 별로 한번 살펴보도록 하겠습니다. 우선 네트워크 입니다.
• #57: 예상하신 분도 있을 것 같습니다. 우선 개발하신 게임의 글로벌 진출을 계획중이시라면 고려해보실 만한 서비스는 Global Accelerator 라는 서비스가 있습니다.
• #58: 앞서 CloudFront 설명에서 CloudFront 가 캐시 뿐 아니라 동적컨텐츠나 API 가속에도 사용하실 수 있다고 말씀 드렸습니다. Global Accelerator 역시 이와 비슷한 기능을 제공하는데, CloudFront 와는 달리 TCP, UDP 프로토콜을 지원하는 서비스 입니다. 요지는 전 세계의 사용자들이 AWS 의 게임서버나 애플리케이션으로 접근할 때 Global Accelerator 를 통하면 퍼블릭 인터넷 구간을 최소화하는 대신 AWS 의 Global Backbone 네트워크를 통해 접속할 수 있다는 것입니다. 보다 자세하게 살펴 보도록 하겠습니다.
• #59: Global Accelerator 의 경우 화면 하단에 보시는 것처럼 게임이나 애플리케이션의 앞에 위치하여 Edge Location 에서 동작하게 됩니다. 적용하시게 되면 Static Anycast IP 가 할당되어 설정하신 게임서버나 ELB 로 최적의 경로로 트래픽이 라우팅됩니다. 때문에 뒤에 게임 서버가 추가되더라도 애플리케이션을 변경하실 필요가 없어지게 됩니다. 전 세계의 사용자들이 Global Accelerator IP 로 접근하면 사용자 기준으로 가장 빠른 엣지로케이션 까지 우선 인터넷을 통해 접근하게 됩니다.
• #60: 이후 Edge 에서 게임 서버가 있는 AWS 리전까지는 AWS Global Backbone 네트워크를 활용해 접근합니다. 때문에 보다 빠르고 안정적인 네트워크 성능을 기대하실 수 있습니다. 기존에 글로벌 원빌드를 구성하실 때 각 거점별로 리버스 프록시 서버를 구축하셨다면, Global Accelerator 를 활용하시면 이러한 번거로운 작업을 하지 않으셔도 됩니다. 추가로 꼭 업데이트 드리고 싶은 내용이 두 가지 있습니다.
• #61: 최근 업데이트로 Global Accelerator 에서 ALB 를 타겟으로 설정할 경우 타겟에 client IP 가 보존되어 보입니다. 서버에서 클라이언트 IP 를 체크해야 하는데, 해당 기능이 제공되지 않아 도입하지 못한 고객분들이 계셨습니다. 이제는 ALB 를 타겟으로 할경우 client IP 를 확인하는 것이 가능해졌습니다. 현재는 ALB 에 대해서만 제공되지만, EC2 타겟에 대해서도 client IP 보존 기능이 몇 주 내로 업데이트 될 예정에 있습니다.
• #62: 또 한가지 서비스는 회사가 커지면서 점점 더 복잡해지는 여러 VPC 와 온프레미스 네트워크를 단일 게이트웨이로 연결해주는 Transit Gateway 란 서비스입니다. 이전까지 VPC Peering 이란 기능을 통해 여러 VPC 를 서로 연결하는 것은 가능했습니다. 하지만 VPC 가 수십개로 늘어날 때 이를 각각 따로 연결하고, 또한 온프레미스와 VPN 연결까지 해야 하는 상황이면 네트워크 관리가 상당히 어려워질 수 있었습니다. Transit Gateway 를 활용하시면 화면에 보시는 것처럼 좌측보다 훨씬 단순한 구조로 우측과 같이 구성하는게 가능해집니다. 단순히 중앙의 게이트웨이에 VPC, 온프레미스와의 VPN, DX 등을 연결하여 관리하시면 되고, 중앙에서 라우팅을 해주게 됩니다. 현재 운영 중이신 VPC 가 많고 이것들이 Peering 등으로 복잡하게 연결되어 있다면 Transit Gateway 를 통해 이러한 관리 작업을 단순화 하시기 바랍니다.
• #63: 그리고 AWS 에서 VPN 서비스도 출시하였습니다. 이제는 VPN 을 직접 구축하는 것이 아니라 많이 사용 중이신 OpenVPN 기반 클라이언트를 통해 보다 안전하게 AWS 네트워크에 액세스 하실 수 있습니다.
• #65: 앞서 Global Accelerator 를 통해 글로벌 게임의 네트워크 성능과 안정성을 높이고, 아키텍처에 나타나있지는 않지만 Transit Gateway 를 통해 많은 VPC 를 중앙에서 편리하게 관리하는 방법을 살펴봤습니다. 이번 에는 컴퓨트에 대해 다루겠습니다.
• #66: 요즘 많이 시도하시는 것처럼 EC2 인스턴스는 컨테이너로 일정 부분 대체 하는 것이 가능합니다.
• #67: AWS 에서는 이미 다양한 컨테이너 관리 서비스를 제공하고 있습니다. 관리형 서비스와 호스팅 그리고 이미지 레지스트리 이러한 세가지 카테고리의 서비스를 제공하고 있습니다. 첫번째로 관리형으로 컨테이너의 배포와 오케스트레이션 등의 작업을 손쉽게 할 수 있는 서비스로 ECS 와 EKS 가 있습니다. 두번째는 호스팅으로 EC2 에 직접 구축하시거나 혹은 Fargate 라는 서버나 클러스터 없이 컨테이너 실행을 도와드리는 서비스가 있습니다. 마지막으로 단순히 Docker 컨테이너 레지스트리만 원하실 경우에는 ECR 서비스를 활용하실 수 있습니다. 이번 시간에는 이러한 서비스에 대한 자세한 설명은 다루지 않습니다만 오후에 준비되어 있는 컨테이너 워크숍에 참석하시면 AWS 의 컨테이너 서비스 실습을 진행해보실 수 있습니다.
• #68: 세번째 파트는 스토리지입니다.
• #69: 앞에서 기존 서비스의 성능향상에 대해 이야기는 이미 드렸습니다. 몇 가지 스토리지 관련 서비스가 출시되었지만 시간 관계상 이번 시간에는 FTP 서비스 하나 간단히 소개 드리도록 하겠습니다. 아마 FTP 를 활용하여 파일 전송을 이미 많이들 하고 계실 것 같습니다. 이런 요구사항을 충족하기 위해 Amazon S3 와 SFTP 를 활용해 파일을 주고 받을 수 있는 서비스가 출시되었습니다.
• #70: Transfer for SFTP 의 경우 기존의 AD 와 같은 인증 시스템과 통합이 가능하며 기존에 사용하시던 SFTP 클라이언트를 그대로 활용하실 수 있습니다. 이를 통해 개발사와 퍼블리셔 간에 FTP 를 통해 파일을 주고 받는 경우나 혹은 다른 외부 회사와의 파일 공유에 FTP 를 활용하고 계시다면 운영 중이신 FTP 서버 대신 Transfer for SFTP 서비스를 활용하실 수 있을 것으로 보입니다.
• #71: 마지막으로 데이터베이스입니다.
• #72: 요즘 right tool for right job 이라는 이야기가 데이터베이스에도 동일하게 적용됩니다. 이전과는 달리 워크로드가 다양해짐에 따라 이러한 요구 조건을 만족시키기 위해 데이터베이스의 종류도 그와 같이 굉장히 다양해지고 있습니다. 예를 들어 게임 내 상점과 같은 주문과 스키마가 엄격해야 하는 경우 관계형을 선택하게 됩니다. 수백만명의 플레이어가 접속하는 온라인 게임이나 소셜 미디어에는 높은 수준의 쓰기 작업이 필요하고 이럴 때는 Key-Value 를 선택하실 수 있습니다. 또한 어떤 연결된 데이터를 기반하여 이런 데이터에 관계에 집중할 필요가 있을 때는 그래프 디비를 선택하게 됩니다.
• #73: AWS 에서는 이러한 모든 요구 조건을 충족하기 위해 각각의 서비스를 제공하고 있습니다. 앞에서 몇차례 말씀드린 RDS 나 DynamoDB 외에도 Redis 를 관리형으로 제공하는 인메모리 캐시 디비인 ElastiCahce, 그래프DB 인 Netpune 이 있습니다. 새롭게 제공하는 서비스로는 타임 시리즈 데이터베이스인 Timestream, 그리고 원장 DB 에 사용할 수 있는 QLDB 등을 새롭게 제공하고 있습니다. 한가지 이야기 안한 DocumentDB 는 뒤에서 조금 더 살펴보도록 하겠습니다.
• #74: 마지막으로 소개드릴 서비스는 MongoDB 호환 NoSQL 데이터베이스인 DocumentDB 입니다. 이미 DynamoDB 에서 Key-Value 나 문서 타입을 지원하지만, DocumentDB 의 경우는 MongoDB 와 완벽하게 호환되는 완전 관리형 문서 데이터베이스 서비스입니다. 따라서 기존 MongoDB 애플리케이션 코드나 드라이버를 그대로 DocumentDB 에서 활용하여 높은 가용성과 확장성 그리고 성능을 기대할 수 있습니다. 모든 코드를 그대로 사용하실 수 있지만 한가지 다른 점은 MongoDB 의 샤딩과는 다른 확장 방식을 제공한다는 것입니다. 성능 면에서는 최대 15개의 읽기 전용 복제본을 지원하기 떄문에 초당 수백만건의 데이터를 읽을 수 있고, 쓰기 작업 full 버퍼 페이지 싱크가 필요 없기 떄문에 일반적인 데이터베이스보다 빠른 성능을 보여줍니다. 자동 백업과 point in time recovery 를 지원하기 때문에 DocumentDB 를 활용하시면 높은 가용성 얻으실 수 있습니다.
• #75: 네 여기까지 정말 바쁘게 지난 1년간 새롭게 추가된 기능과 서비스를 살펴 봤습니다. 모든 것은 아니지만 이 중에 몇가지는 게임을 개발하시는데, 혹은 운영하시는데 도움이 되실거라 생각됩니다.
• #76: 추가로 다음 링크에서 AWS 의 새로운 기능 업데이트와 서비스에 대한 뉴스를 제공하고 있습니다. 현재 AWS 를 활용 중 이시라면 한번씩 접속하셔서 최신 뉴스를 접해보시기 바랍니다.