개요

트위터에서 AWS Gameday가 엄청 흥하길래 도전해봤다.

Unicorn Corp에 입사한 one and only operation팀 팀멤버라는 시나리오 속에서 문제를 해결해 나가는 형태의 컨테스트였는데, 문제를 잘 해결하면 점수를 얻고, 아니면 점수를 잃거나, 얻지 못하는 형태 였다. (잘하면 이력서에 Unicorn Corp를 써볼 수 있겠는데? 라는 생각도 했다.)

매번 스프린트와 실습만 하는 게 싫어서 실무에선 어떻게 AWS를 쓰게 될까 궁금해서 무작정 회사 팀원 3명을 부추겨 신청했다. 결과는 처참했지만, 적어도 매 포인트마다 어떤 서비스를 어떻게 써야 하는지 알게 되었고, 인프라 테스트 방법도 어느정도 이해하게 되어 진심으로 내내 즐거웠다.


게임데이를 어떻게 진행했길래 망했나.

게임데이에서 총 모듈에 3개, 각 모듈마다 태스크가 4-6개 정도 주어진다. 각 태스크를 풀면 점수가 ++되는 형태인데, 0점에서 시작해서 우리 예선전에서 최고점은 12,000점이었다. (점수는 각 태스크마다 다른 듯 했다)


가장 먼저 우리가 실수 했던 부분

1. 모듈이 모두 연계된 모둘인줄 착각함.

각각 모듈이 모두 연결되어, 모듈 1을 풀어야 모듈 2를 할 수 있는 줄 알았다. 그래서 모듈 1에서 모두 끙끙 댔는데 AWS 엔지니어가 들어와서는 모듈 2,3도 해도 되니 진행하라고 해주기까지 우리는 모듈 1에 머물러 있었다.

2. 그럼에도 불구하고 모듈 2,3로 넘어갈 수 없었다.

모듈 1의 태스크 1에 대한 접근은 우리가 옳았다. 프라이빗 서브넷에 있는 인스턴스에 접근하기 위한 방법은 여러가지 였는데, 여태껏 우리는 바스티온을 만들어서 접근했다면, 이번에는 세션 매니저를 사용해야 했다. 우리는 자습서와 aws 블로그에 나온대로 했는데도 It doesn’t work!

그래서 AWS 엔지니어에게 물어봤더니 인스턴스를 재부팅 하라고 했다. 그리고 재부팅 하고 나서 세션 매니저 타겟 인스턴스에 뜨길래 됐다!!! 했는데, 여기까지 보고 엔지니어가 우리에게 1000점을 부여하고 쿨하게 나갔다.

이렇게 재부팅 하니 됐다고? 엄청 허무했는데, 나중에 찾아보니 세션매니저 에이전트가 다시 시작해야 설정을 반영하기 때문이라고 했다.

그런데 문제는 그럼에도 불구하고 세션 매니저를 통한 인스턴스 연결이 되지 않았다. 이제 더 불편해졌다.. 모든 팀원이 1000점에 대한 정당성을 가지고 싶어 했다. 그래서 더 매달렸고, 우리는 정말 초심자나 할 법한 실수에 매몰됐다.

3. 하지만 나는 혼자서 과감하게 모듈2로 넘어갔다.

왜냐면 엔지니어가 그렇게 해도 된다고 들어와서 힌트를 줬으니까. 모듈2를 보니 어느정도 할만 했다.

그리고 나서 첫번째 문제를 보니, 우리에게 chaos 엔지니어링의 일부로 이상한 인스턴스가 매번 5개씩 만들어졌다. 그래서 나는 다음과 같은 플로우를 생각했다.

  1. 매번 다섯개? 그렇다면 당연 ASG를 쓰고 있겠군
  2. 그럼 템플릿을 보자! 시작구성은 구려서 안쓸거야
  3. 템플릿을 보니… 음…? 이상한 인스턴스를 만드는 게 아니네?!?! 어?!?! 메인서버를 오토스케일링으로 만들어 내고 있잖아!??!?!
  4. 뭐지뭐지 어디서 만드는거지 이거…?
  5. 그래서 다른 조건들이 다 동일하길래, UserData부터 확인했다. 그랬더니 BOOM!
  6. bash로 이상한 인스턴스의 수를 조건으로 수 이하면 인스턴스를 만들어 내고 있었다.

그래서 템플릿의 유저데이터를 수정하고, 버전을 업그레이드하고, ASG에도 새로운 버전을 적용했다. 그리고 이상한 인스턴스를 다 제거해서 다시 생성되나 확인했다.

4. 그렇지만, 이상한 인스턴스는 계속 생성됐다.

분명 접근 잘했다고 생각했는데, 이상한 인스턴스는 계속 만들어졌고, cloudformation을 보고, cloudtrail을 확인해도 내가 접근한 방법이 맞았다.

그렇지만 다른 팀원이 이후 템플릿을 새로 적용한 후, 업데이트 버튼을 눌러야 한다고 했고, 그렇게 업데이트 버튼을 누르자, 이상한 인스턴스들은 더 이상 생성되지 않았다. 하지만 이건 게임이 끝난 후였다. 접근은 맞았지만 마무리가 부족했다. 알고 있는 내용이었는데 막상 실전에서 생각이 나지 않았다.

5. 게임데이 진행 시간을 착각했고, 시간 분배를 제대로 하지 못했다.

나는 총 4시간 진행한다고 생각했다. 그래서 1시반부터 2시, 3시, 4시, 5시 반이면 끝날거라고 생각했는데. 4시 반에 끝나버렸다. 두어개 더 할 수 있을거라고 생각했는데, 두어개 하고 끝나버렸다. 물론 실전에서는 시간이 제일 중요하기 때문에 가장 중요한 요소였음에도 불구하고 제대로 시간관리를 하지 못했다는 점이 너무 아쉬웠다.


그럼에도 불구하고 잘한 점도 있다.

첫 번째는 지금 이렇게 회고글을 쓰고 있다는 점이다. 나에게는 정말 좋은 경험이었기 떄문에 꼭 이 졌잘싸를 쓰고 싶었다. 배운게 정말 정말 많았다.

두 번째로는 CloudWatch와 CloudTrail을 통한 경보 모니터링을 꽤 잘했다고 생각한다. AWS 자습서를 보면서 따라 해본 것이 이렇게 도움이 될 줄이야.

관련 태스크는 어렵지 않았다. 인스턴스가 run되면 이메일로 알림을 받고 싶다는 거였다. RunInstances는 API 콜이기 때문에 먼저 CloudTrail을 떠올렸다. 그리고 email로 알림을 받기 위해서는 SNS을 사용하면 됐고, API콜 이벤트가 있을 때마다 전송하면 되기 때문에, EventBridge를 사용하기로 결정했다. 그리고 연결! 따란~

세 번째로 끝나고, cloudformation을 살펴보고 전부 다운 받아 살펴봤다. 나에게는 인프라 CRUD 테스트에 대한 갈망이 있었는데, 여태까지 적절한 방법을 찾아내지 못했는데, Gameday에서 찾을 수 있었다. 결국 인프라도 코드와 같이 관리하기 때문에, 코드를 테스트 하는 것과 비슷한 방향으로 테스트할 수 있다는 것을 깨달았다. 다음에는 실습용 스프린트에 한번 적용해볼만 할 것 같다.

마지막으로 끝나고, 각 태스크에 어떻게 접근할 수 있을지 고민해봤다. 어떤 서비스를 어떻게 써야 할 지, 어떻게 구현해야 할지 각각 적어보았다. 그리고 이 작업을 처음에 다 같이 했다면 더 좋았겠다는 생각이 들었다.


마무리

비록 원하는 점수는 아니었지만, 저어어엉말 재밌었다. 3시간 동안 몰입해서 했던 것도 좋았고, 정말 많은 공부가 됐다. 내가 단순 실습만 해본 다양한 서비스들을 엮어보는 경험도 유익했, 실무에서는 어떻게 구현해서 쓰는지 프로젝트 형식으로 접근해볼 수 있는 것도 짜릿했다. 그러면서 내가 정말 많이 알고 있는지를 확인하는 일종의 테스트이기도 해서, 뿌듯하기도 하고 이런 테스트는 오랜만이라서 쫄깃했다. 너무 좋은 기회라서 다음에도 비슷한 기회가 있다면 꼭 참여해보고 싶다.