AWS Game Day!
이벤트가 끝나고 며칠이 지난 뒤 쓰는 회고라 몇몇 부분은 기억이 잘 기억이 나지않아 글이 매끄럽지 않습니다. ㅎㅎ
어떻게 참여하게 되었는가?
회사내에서 Game Day 참가자 모집을 하고 있었고, 입사 동기들과 이야기를 하다가 인프라팀에 속해있는 동기가 같이 참가할 사람을 구하기 시작했습니다.
백엔드 개발자로 일을 하면서 어플리케이션 레벨의 코드를 작성하는 것은 큰 어려움 없이 학습하고 조금씩 자신감이 붙고 있지만, 인프라 요소에 대해서는 잘 알지도 못할뿐더러 학습도 제대로 하지 않고 있었습니다.
또 이전에 타 팀분들이 Auto Scailing Group 변경에 대해 검토와 요청을 하셨는데 어떻게 해야 하는지 몰라서 당황했던 적이 있었는데 선배 개발자분이 해결해주셨었습니다. 이때 선배 개발자분이 없었다면 큰일 났겠다 생각을 했었습니다. 그래서 팀 내에서 사용하는 아키텍쳐에 대해 잘 이해하지 못하고 있다는 불안감을 가지고 있었는데 ''이번 기회를 통해서 조금이라도 해소 할 수 있지 않을까?'라는 막연한 기대를 품고 참여한 것 같습니다.
그래서 AWS Game Day 는 뭘 하는 건가?
가상의 회사 유니콘 렌탈사의 신입 DevOps로 입사한 상황에서 시시각각 변하는 요구사항에 따라 아키텍쳐를 진화하면서 점수를 얻는 방식의 이벤트입니다. 기본적으로 주어지는 배포된 환경의 Aws 자원들을 살펴보고 실시간으로 늘어나고 줄어드는 트래픽 속에서 얼마나 효율적으로 대처를 하는지에 따라 점수를 주는 방식으로 4시간 30분 정도 진행되었습니다.
어떻게 준비했는가?
동기를 비롯한 저의 AWS 기반 지식 수준은 정말 처참했습니다. 사전에 AWS 측에서 난이도 조절을 위해 설문조사를 진행했는데 부끄럽게도 아래 표와 같이 완전히 박살난 수준을 볼 수 있습니다.
그리고 마치 저희 팀의 수준을 알고 계셨던것 처럼 미리 봐두면 좋을 동영상을 소개해주셨습니다.
5명의 팀원이 하나의 동영상을 전담해서 정리를 하고 밤에 화상 채팅을 통해서 해당 내용을 공유하는 시간을 가지면서 준비를 했습니다.
그리고 AWS Game Day 홈페이지를 가면 있는 에피도스 별 동영상을 참고하였습니다.
AWS Game D-Day!
회사의 명예가 걸려버렸다..!
이벤트가 열리는 날 회사 사무실에 동기들과 전부 모여 마이너스 점수만은.. 꼴등만은 하지 말자고 마음을 다잡고 시작했습니다.
하지만 마음처럼 이벤트는 쉽지 않았고 지금부터 저희가 삽질하고 겪은 시행착오를 나열해보고자 합니다.
처음 주어진 환경은 EIP가 주어졌고, EC2 인스턴스 2대, Clasic Load Balancer(CLB) 였던것 같습니다. (정확히 몇대 였는지 기억이 나질 않네요.)
네트워크 생성
더 많은 트래픽을 잘 처리할 수 있도록 ASG를 설정하고 LB에 연결했는데 LB가 Classic인 부분을 확인하고 ALB로 교체하려고 하였습니다. 그런데 ALB로 업그레이드하려는 순간 subnet에 가용 IP가 남아있지 않아 업그레이드할 수 없다고 실패했습니다.
지금 생각해보니 새로운 subnet을 생성해서 연결해주면 쉽게 해결됐을 것 같고 아마 AWS에서 의도도 그렇지 않았을까 생각합니다.
새로운 subnet을 생성했는데 LB의 subnet을 교체하는 걸 잊어버리고 새롭게 생성해도 안 된다고 생각했습니다. 그렇게 멘탈이 와르르 무너진 저희는 새로운 VPC를 만들기로 합니다. 결국 새로운 VPC를 만들고 subnet의 가용영역을 적지도 많지도 않게 적절하게 쪼개서 만들었습니다. 그리고 새로운 ASG를 생성하고 새로운 ALB를 생성하여 연결해줬습니다.
네트워크 구성에 대해 기반 지식이 모두 부족하다고 느껴서 굉장히 시간을 많이 잡아먹은 부분이었습니다.
모니터링 지표 확인
ALB와 ASG를 구축한 뒤 ''이제 요청이 잘 들어오겠지?' 라고 생각했는데 이상하게 요청을 처리 못해서 점수를 획득하지 못했습니다. 그래서 ALB, ASG, EC2의 모니터링 지표를 차례대로 확인해 보니 모든 자원에 request가 정상적으로 들어오는 것을 확인했습니다. 그래서 곧바로 어플리케이션의 문제인가 하고 의심하고 있던 중 Launch Configuration 에 설정한 script가 잘못된 것을 발견하고 고칠 수 있었습니다.
모니터링 지표에 대한 힘을 굉장히 크게 느끼게 된 부분이었고, 이벤트를 진행하면서 가장 빠르게 해결한 문제였지 않았나 싶습니다.
캐시 적용
이제 요청을 잘 처리하고 있었지만 조금 더 빠른 처리로 점수를 얻고 싶었고 곧 바로 캐시에 대한 적용을 진행하기로 했습니다. 어처구니가 없게도 캐시를 적용하면 속도가 무조건 빨라질거라는 생각을 했고 곧장 Elastic Cache를 적용합니다. 당연하게도 성능 개선은 이루어지지 않았습니다. 프로세스의 워크로드에는 DB를 거치는 부분이 없었기 때문에 Elastic Cache를 적용해서 얻을 수 있는 이점이 없었기 때문입니다.
AWS 자원에 대한 용도를 제대로 알지 못하고 무작정 적용하면서 발생할 일이었습니다.
곧바로 Elastic Cache를 걷어내고 Cloud Front를 적용하였습니다. 그런데 저희의 예상과는 다르게 생각보다 latency가 크게 줄어들지 않았습니다. 이유를 다같이 고민하면서 공식문서를 읽었고 요청의 query parameter에 대해서는 정책을 생성해서 적용해야 한다는 사실을 뒤늦게 발견하였습니다. 캐시 정책을 적용한 뒤에는 latency가 줄어드는 것을 확인했습니다.
지금까지 나열한 사건은 어찌돼었든 해결한 문제입니다. 하지만 해결하지 못한 문제도 있었습니다.
LB 가용성
캐시까지 잘 적용하고 이제 어떻게 성능개선을 고민하고 있던 순간 로그에서 갑자기 요청에 대한 실패가 쌓여가는 것을 확인했습니다. 문제는 ALB였습니다. 놀랍게도 ALB가 삭제되어 있었습니다. 부랴부랴 ALB를 새롭게 만들어서 다시 요청을 받게 했는데 다음에도 똑같이 ALB에 문제가 발생하면 어떻게 해결하지 라는 생각만 할 뿐 그에 대한 해결 방법을 구상하고 구축하지는 못했습니다. LB도 이중화를 미리 해두어야 하는가 라는 생각을 하긴 했지만 명확한 해답은 찾지 못했습니다.
가성비
요청을 처리하는 것도 중요하지만 요청을 처리하는데 사용되는 자원을 효율적으로 관리하는 것도 중요한 포인트였습니다. EC2 인스턴스의 개수가 늘어나면 늘어날수록 요청을 처리하는 속도도 높아졌지만 그만큼 자원 사용 비용이 늘어나서 잃는 점수도 높아졌습니다. 이때 ASG의 정책을 적용하면 된다는 것이 생각나서 한 인스턴스 당 특정 건수의 요청을 받을 수 있을 만큼 EC2를 증설하도록 정책을 조절했는데 정책 설정을 잘 못 한 것인지 EC2의 증설과 축소가 원하는 대로 이루어지지 않았습니다.
결국 팀원 한 명이 인간 오토 스케일러가 되어 계속해서 트래픽을 모니터링하면서 EC2의 개수를 조절하는 무한 지옥에 빠졌습니다..
ECS, EKS, Fargate
여자저차 요청에 대한 처리를 잘하고 있었지만, 점수를 얻는 속도가 좀 더 빠른 팀이 눈에 띄었습니다. 여기서 어떻게 더 빠르게 요청을 처리하는 것인지 고민을 하다가 도저히 알 수 없어서 서포터분에게 문의했고 하나의 EC2에 단일 프로세스로 요청을 처리하고 있어서 그런 것 같다는 힌트를 얻을 수 있었습니다. 이러한 문제를 해결하기 위해서는 EC2에 여러 개의 인스턴스를 띄울 수 있도록 Docker 그리고 K8s 도입을 고려하면 될 것 같았지만 팀원 중 해당 기술을 다룰 줄 아는 사람은 단 한 명도 존재하지 않아 도입하지 못하였습니다.
AWS Game Day를 통해 얻은 것
이번 Game Day를 통해서 인프라를 다루기 위한 기반 지식 수준이 어느 정도인지 어렴풋이 파악하게 된 것 같습니다. 내가 무엇을 모르고 있는지조차 모르는 단계에서 무엇을 모르는지는 알고 있는 단계로 올라온 것 같아 인프라를 다루기 위한 공부의 방향을 알게 되었다고 볼 수 있을 것 같습니다.
로그와 모니터링이 정말 중요하다는 것을 또 깨달았습니다. 코드 레벨의 어플리케이션 개발을 한 뒤 배포를 하고 모니터링을 하면서 문제가 없는지 잘 살펴봤었는데, 인프라 영역에서도 똑같이 살펴봐야 했습니다. 더구나 제대로 알지도 못하는 기술을 그냥 연결만 했다고 적용되는 게 아니라, 적용 후 모니터링 지표와 로그를 잘 살펴보면서 제대로 적용이 되었는지, 문제가 없는지 확인해야 한다는 것을 다시 한번 깨닫게 되었습니다.
그리고 AWS 아키텍쳐에 대한 전반적인 이해도가 올라갔다고 느끼고 있습니다. 실패해도 괜찮고, 실패하면서 시도하기 좋은 환경에서 이것저것 다룰 기회를 얻은 덕분에 평소에 엄두도 못 낸 여러 가지 시도를 하면서 아키텍쳐의 이해를 할 수 있었던 것 같습니다.
마치며
잘 모르기도 하고 겁도 나서 손도 못 대던 인프라 영역에 대해 성장할 좋은 기회를 마련해 준 AWS, 회사에 감사합니다. 또, 제 멘탈이 와르르 무너져가는 와중에도 침착함을 유지하고 같이 문제를 해결할 수 있게 도와준 팀원들 그리고 서포터분에게도 감사합니다.
이번에는 트래픽을 받는 이벤트였는데 여러 가지 시나리오가 더 있다고 들었습니다. 다음에도 기회가 된다면 또 참여해보고 싶은 이벤트였습니다.
