티스토리 뷰
AWS GameDay?
“GameDay에 참여한 사람들은 Unicorn Rentals라는 가상의 회사에 속한 엔지니어들입니다. 회사의 대표가 부재 중일 때 하필 회사에 문제가 발생합니다. 어떤 가상의 서비스가 동작 중인데 각 팀에 주어진 것은 AWS 콘솔 접근 권한 하나 뿐입니다. 각 팀은 이 서비스의 현재 상태를 진단하고, 앞으로 다가올 큰 트래픽과 예기치 못한 장애상황을 이겨내 서비스를 안정적으로 운영해야만 합니다.”
회사 인프라 동아리 활동 중 AWS GameDay에 참여할 수 있는 좋은 기회가 생겼다. 가상의 회사 유니콘 사에 입사하여 실제 환경에서 생기는 문제들을 체험하고, 해결해 점수를 가장 많이 얻는 팀이 우승하는 행사였다.
팀이 4인 1조로 구성되었고,일정 시간마다 TREND가 쌓여 SCORE 가 되는 방식이었다. 요청을 더 빠르게 처리할 수록 TREND가 오르고, 반대로 처리하지 못하거나 많은 AWS 인프라를 사용할 수록 TREND가 깎였다.
본격적으로 시작하기 전에 런북이라는 메뉴얼 겸 룰북을 받았는데, 여러가지 제약사항과 힌트들이 적혀있었다.
- EC2 한 대당 요청을 2개 까지밖에 처리하지 못함.
- 요청은 암호화된 해시 값으로 오고, 주어진 키에 대해 동일한 해시 값을 반환함.
- 인프라 설정이 랜덤하게 한번씩 바뀜.
- ...등등
클라이언트쪽 소스는 볼 수 없었고, HTTP 응답 코드로 요청이 정상적으로 처리되었는지만 알 수 있었다.
오토스케일링을 설정하려면 특정 지표가 필요했는데, aws SA분께서 웹서비스의 경우 서버의 CPU 부하로는 측정하기 어렵다고 하셔서, 요청 개수와 5XX 에러 발생 개수를 지표로 설정하였다. 실제로 로드밸런서로 들어오는 요청에 대해 모니터링 할 수 있었는데, 요청이 정말 많아지더라도, CPU 부하는 늘지 않고, 요청 수만 치솟는 것을 확인할 수 있었다.
주어진 키에 대해 동일한 해시 값을 반환한다는 것에 힌트를 얻어 Cloud Front CDN으로 캐싱하여 같은 요청에 대해서는 캐시된 값을 반환하도록 설정해줬더니 4초나 걸리던 요청을 0.08초 대로 줄일 수 있었다. 대신 캐싱 히트되지 않은 요청에 대해서는 조금 더 시간이 걸렸었다.
오토스케일링을 설정했었더라도, EC2 인스턴스가 생성되고 로드밸런서에 연결되어 응답할 수 있게되기 까지는 5분 이상이 걸렸다. 1분단위로 순식간에 트래픽이 치솟았다가 빠지는 상황이 되면, EC2 인스턴스를 수십대 늘리는 오토스케일링 중에 요청은 요청대로 모두 실패하고, EC2 인스턴스는 많이 늘어나 인프라 비용은 증가했다. 때문에, 오토스케일링으로 EC2 인스턴스를 몇 개 씩 늘이고 줄이는 방식으로는 정상적인 서비스를 유지하기 어려웠다.
트래픽이 예측 가능하고 많지 않은 서비스라면 수동으로 미리 서버를 늘려놓거나 오토스케일링으로 처리할 수 있었겠지만, 예측 불가능하고 단시간에 트래픽이 치솟았다가 사라지는 서비스에서는 EC2 대신 ECS serverless Fargate를 사용하는 것이 좋았다. 행사 막바지에 트래픽이 엄청나 EC2로 정상적인 서비스가 되지않아 serverless Fargate로 구성을 모두 바꿨는데, 새로고침할 때마다 빠르게 늘어나는 서버를 확인할 수 있었다.(비용도...)
후기
초반에 빠르게 Cloud Watch, Cloud Front 를 붙이고, 오토스케일링 설정까지 걸어서 순조롭게 진행되었는데,
server가 바뀌면서 서버 도메인은 잘 바꿨으나, 실행 명령어를 바꾸는 것을 찾지 못해 오랫동안 점수를 획득하지 못해 아쉬웠다.
- 예측 불가능한 많은 양의 트래픽을 처리해볼 수 있었던 값진 경험이었다.
- Cloud Trail로 aws 인프라 설정이 바뀌는 로그를 볼 수 있다는 것을 배웠다.
- ECS Fargate 서버뜨는 속도 보고, 서버리스의 폼이 좋다고 생각했다.
