🏆 AWS 대회에서 1등 했습니다!

안녕하세요 리멤버를 서비스하고 있는 드라마앤컴퍼니의 개발실 리더 김담형입니다.

지난 6월 7일 진행된 AWS GameDay에서 저희 리멤버 팀이 1위를 차지했습니다! 🥳

좋은 성적을 거뒀다는 사실도 만족스럽지만, 게임 자체의 퀄리티가 너무 좋아서 저희 모두 정말 시간 가는 줄 모르게 재미있는 경험을 했습니다. 이번 글에서는 AWS GameDay가 낯선 분들을 위해 간략하게나마 어떤 내용의 대회였고 또 저희가 대회 중에 문제들을 어떻게 해결했는지 설명해 드리고자 합니다.

대회 설명

AWS GameDay는 AWS 아키텍처에서 생길 수 있는 다양한 문제들을 게임화된 환경에서 직접 대처하며 AWS에 대한 이해를 높일 수 있는 인터랙티브 콘텐츠입니다. 참여한 팀마다 모의 서비스가 운영되고 있는 AWS 계정이 하나씩 주어집니다. 운영되고 있는 서비스에는 예상하지 못한 장애, 트래픽 증가 등 여러 돌발상황이 발생하기 때문에 AWS 아키텍처를 변경하여 안정적으로 서비스를 운영해야 하는 대회입니다. 한 팀은 최대 5명으로 구성됩니다. 고퀄리티로 만들어진 대회인 만큼 아마 해당 내용 기반으로 대회가 또 열릴 것 같아 너무 상세한 내용은 적지 못하는 점 양해 부탁드립니다 😉

제가 굉장히 고퀄리티라고 생각했던 첫 이유는 바로 몰입을 위한 상황설정이었는데요, 대회 시작부터 AWS 분들의 연기와 함께 상황극이 시작되었습니다. (눈치 없는 저는 5분쯤 지나서야 이게 상황극이란 걸 인지했습니다.. 😓)

Unicorn.Rentals라는 회사의 CEO가 등장하여 CTO가 코로나로 인한 자가격리 중이라 서비스 대응을 제대로 하지 못한다는 비극을 전해줍니다. 저희는 모두 Unicorn.Rentals의 DevOps 엔지니어들로 CTO가 구축해놓은 시스템을 파악하고 운영해야 합니다. 이 서비스는 이미 고객들의 요청을 처리하고 있으며 트래픽은 더욱 늘어날 예정입니다. 4시간 동안 CTO의 도움 없이 빨리 현재 상황을 파악하고 수정하여 시스템을 안정적으로 운영해야 하는 것이 저희의 임무입니다.

조금 더 설명해 드리자면 저희 서비스는 하나의 API endpoint를 노출하고 있고 해당 API로 사용자들의 요청이 꾸준하게 들어오고 있습니다. API는 하나의 파라미터를 query string parameter로 받으며 응답으로는 파라미터에 대한 hash 값을 주고 있습니다. 저희가 얼마나 서비스를 잘 운영하고 있는지는 점수로 확인 할 수 있습니다. 요청을 더 빨리 처리할수록 높은 점수를 받고 요청을 제대로 처리하지 못하는 경우 점수가 차감됩니다. 또한 주기적으로 저희가 사용하고 있는 AWS 인프라 리소스에 대한 비용이 점수에서 차감됩니다.

따라서 대회의 목적은 최소의 비용으로 최고의 효용과 안정성을 갖춘 인프라를 구성하는 것입니다. 제공되는 스코어 보드 페이지를 통해 현재 참여한 팀들의 점수와 점수 trend를 실시간으로 확인할 수 있습니다.

진행 내용

게임이 시작되고 기존에 갖춰져 있던 시스템이 들어오는 요청을 잘 처리하는 덕분에 모든 팀의 점수가 조금씩 같이 오르기 시작했습니다. 저희는 우선 대회에서 제공되는 Runbook을 읽고 상황을 파악하고 여러 단서를 찾는 데 집중했습니다.

가장 첫 번째 눈에 들어온 건 query string parameter로 parameter가 넘어오고 같은 parameter의 경우 응답에 담기는 hash가 일정하다는 것이었습니다. 그래서 맨 처음 한 작업은 AWS의 CDN 서비스인 CloudFront를 이용하여 query string parameter 기반의 캐싱을 진행하는 것이었습니다. 저희가 제공하고 있는 API는 요청을 하나 처리하는데 4초 이상 걸리는 굉장히 오래 걸리는 API였기 때문에 캐싱이 큰 효과를 발휘할 것이라는 판단을 했습니다. 다만 같은 값이 얼마나 중복으로 요청될지는 몰랐지만 간단하게 할 수 있는 작업이었다 보니 바로 적용을 해뒀습니다. 캐시 히트가 되는 경우 EC2까지 요청이 전달되지도 않고 앞단에서 바로 클라이언트로 응답을 줄 수 있으니 가장 효과적인 캐싱 방법이라고 생각했습니다. CloudFront는 리멤버 커리어, 리멤버 커뮤니티, 커리어 채용공고 등 평소 리멤버 웹 사이트들이 모두 잘 사용하고 있는 서비스다 보니 어려움 없이 바로 적용할 수 있었습니다.

그다음으로는 지금 구성되어있는 아키텍처에 잘못된 부분은 없는지 확인했습니다. 불필요한 설정으로 추가 금액이 나가는 예도 있었고 사용되지 않는 지원들도 있어서 이를 모두 제거했습니다. 또한, VPC 설정을 보다 보니 사용 가능한 IP의 제한이 있어서 subnet도 바로 추가했습니다. 그 외 배포 과정에도 비효율적인 내용을 제거했습니다.

API의 처리 시간이 매우 길어서인지 제공되는 서비스 binary가 EC2 서버 한 대의 처리량이 명확해 보였습니다. 따라서 요청량에 따른 EC2 auto scaling이 필요하다고 판단했고 Request count per target 지표를 확인하기 위해 Classic Load Balancer를 Application Load Balancer로 변경했습니다.

ELB에서 관리하고있는 target당 처리하고 있는 request count 지표

요청량이 급격하게 변화하기도 하고 어떤 규칙을 보일지 몰라서 최대한 빠르게 대응하기 위하여 손토스케일링(손 auto scaling)을 진행했습니다. 이 부분이 꽤 큰 역할을 해줬는데요, 다른 팀들의 점수가 갑자기 급감할 때 저희는 플러스 점수를 유지하는 경우도 있었습니다. (인간이 기계보다 뛰어나다는 것을 보여줬습니다🤖)

게임 규칙상 생성할 수 있는 EC2의 사양이 한 가지로 정해져 있었고 서비스가 EC2 인스턴스의 리소스를 충분히 활용하지 못하는 상황이었다 보니 더 효과적인 비용 절감을 위해서는 AWS의 container 서비스인 ECS를 이용해야겠다고 판단했습니다.

마치 약속이라도 한 듯 누가 시키지도 않았지만 자연스럽게 참여 인원의 절반은 ECS의 신규 아키텍처 기반의 설계를, 절반은 더 빠른 Auto Scaling을 통해 기존 시스템 운영을 맡았습니다.

ECS(Elastic Container Service)는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스이며 어떻게 서버를 구성하냐에 따라 두 가지 방식으로 나뉩니다. 하나는 저희가 EC2를 직접 실행한 뒤 그 안에 실행되는 container들을 ECS에서 관리해주는 방식이고 다른 하나는 Fargate라고 부르는 serverless 방식입니다. Fargate는 쉽게 생각해서 AWS Lambda와 같은 개념이라고 보시면 됩니다. 처음에는 EC2 기반의 ECS를 구축하려고 시도했었는데 저희 모두 EC2 기반의 ECS를 구축한 경험이 없었어서 일부 설정에서 생각대로 잘 동작하지 않았습니다.

그러다가 중간에는 더 늦어지면 안 되겠다 싶어서 Fargate 기반의 ECS로 변경했습니다. Fargate의 경우 리멤버 커뮤니티 등 여러 서비스에서 이미 사용하고 있었기 때문에 손쉽게 구축할 수 있었습니다. Fargate로 아키텍처를 모두 이전한 뒤 점수가 많이 오르기 시작했습니다.

Fargate에서 사용하는 Task Definition 설정. 기존에 사용하던 EC2 인스턴스보다 훨씬 효율적으로 자원을 사용할 수 있었습니다.

Fargate 위에서 동작하는 리멤버 커뮤니티 API, 리멤버 커뮤니티 Web의 화면

어느 정도 작업도 완료했고 안정적으로 오르는 점수에 만족하던 중에 갑자기 EC2 인스턴스가 종료되기 시작했습니다. 빠르게 돌아가는 상황이다 보니 _“이상하네? 근데 뭐 누군가 실수했겠지”_라고 생각할 수도 있었지만, 혹시 모를 문제를 대비하기 위하여 사용자 활동 감시 서비스인 CloudTrail에서 로그를 확인했습니다. 역시 저희의 실수가 아니라 Chaos Monkey가 AWS 리소스들을 조회하고 종료하는 것을 확인했습니다. 문제를 일으켜서 대응이 필요한 부분은 빠르게 대응을 했고 망가트리지 못하게 일부 설정은 조정해두었습니다.

Chaos Monkey는 Netflix에서 만든 Chaos Engineering을 위한 모의훈련 툴로 임의로 서버나 컨테이너를 종료시켰을 때도 서비스가 잘 동작하는지 확인하기 위한 목적으로 만들어졌습니다. 인스턴스 종료뿐만 아니라 AZ나 리전 전체를 셧다운 하는 Chaos Gorilla, Chaos Kong 등도 있습니다. Chaos Engineering에 대해 궁금하시다면 카오스 엔지니어링의 원칙을 읽어보시거나 YouTube에서 Netflix의 기술 발표 영상들을 참고해보시면 좋을 것 같습니다.

Chaos Monkey뿐만 아니라 적은 내부에 있다고 Unicorn.Rentals 대표님이 뭔가 해보시겠다고 하는 게 문제를 발생시키는 경우도 있었습니다 😫

또한 후반으로 갈수록 트래픽이 급증했는데, 가장 처음에 도입했던 CloudFront가 효자 노릇을 톡톡히 해줬습니다. 중복된 parameter 요청이 많이 날라왔는지 대부분의 요청이 CloudFront 단에서 처리되고 끝났습니다.

4초가 걸리는 처리 시간이 CloudFront 캐싱을 통해 0.004초만에 처리되는 모습.

어느덧 4시간이 지나버렸고 대회가 종료되었습니다. 이멤버리멤버 팀이 1등으로 게임을 끝냈습니다. 처음에는 중간 등수였지만 작업을 할 때마다 점수와 순위가 함께 오르기 시작했습니다.

후기

저희 모두 큰 기대를 갖고 참여했던 대회는 아니었습니다. 다들 워낙 바쁘다 보니 오랜만에 재미있게 놀다 오자라는 마음으로 참여했다가 점수가 잘 나오니 뒤로 갈수록 더 열심히 몰입했던 것 같습니다. 개인적으로는 방 탈출을 정말정말 좋아하는데 처음에 몰입을 위한 설정, 상황극, 연기, 다양한 함정 및 문제 등이 방 탈출과 비슷하여 훨씬 더 몰입할 수 있었습니다.

저희가 평소에 고민했던 부분을 해결하기 위한 아키텍처와 서비스를 그대로 적용되었다는 점이 만족스러웠고 손발이 착착 맞는 팀워크에 저희 모두 감탄했습니다. 누가 시키지 않았음에도 서로 역할 분담을 하며 업무를 나눠가고 긴박한 상황에서도 실시간으로 상황 공유 및 확인을 계속 진행하여 여러 명이 동시에 AWS 리소스를 수정하면서도 충돌 없이 해낼 수 있었습니다. 그리고 나중에 알게 된 사실이지만 대회에 참가한 다른 회사들이 국내에서 손꼽히는 IT 스타트업, 대기업들이었다고 합니다. 코로나만 아니었어도 네트워킹 시간을 가질 수 있었을 텐데 아쉽지만 이런 팀들이 모두 모여 대회를 진행했다는 것만으로도 충분히 재미있는 경험이었습니다.

관심 있으신 분들은 정말 재미있는 시간을 보내실 수 있을 것 같으니 나중에 대회가 열리면 꼭! 참여해보시길 추천드립니다.