AWSKRUG architecture 소모임 후기

11월 22일 AWS 서울리전에서 장애가 발생해 여기저기 서비스가 중단되는 사태가 발생했었다. 공식적인 장애 내용은 아래 링크 첨부. 아시아-태평양 서울 리전(AP-NorthEast-2)의 Amazon EC2 DNS 확인(Resolution) 이슈 요약

나는 현재 회사에 다니고 있질 않아 간간히 이슈만 듣던 참에 아는 분의 소개로 AWSKRUG에서 "AWS 장애에 대비하는 우리의 자세"란 주제로 이야기 한다는 소식을 듣고 흥미가 생겨 참여하게 되었다. 나도 이전 회사에서 AWS를 쓰고 있었고, 이번 장애가 발생했을 때 나는 AWS를 맹신하고 있단 생각을 했었다.

업계 1위 AWS가 장애때문에 그렇게 수많은 서비스들이 죽었다고?

물론 서울리전에 한정된 장애긴 하나 피해 입은 업체들이 꽤나 많았고, 똑같거나 비슷한 장애가 발생했을 때 다른분들은 어떤식으로 설계하시는지가 궁금했다. 장애원인은 결국 휴먼에러긴 하지만...

먼저 행사 순서는 이렇게

• re:Invent에서 언급된 새로운 AWS 서비스들 / 정도현(AWS)
• 인공지능 로봇 저널리즘 / 이주경 (DaumSoft)
• "AWS 장애에 대비하는 우리의 자세"
  • 지난 11월 22일 Seoul region 장애 관련 경험 공유 및 대비책

사실 첫번째 세션은 AWS들어가서 문서 읽어도 될 내용이였지만 그래도 한번 말로 쭉 설명해주시니 오..하구 들었다. 두번째 세션은 생각보다 결과물이 꽤 괜찮아서 재밌게 들었는데 주제와 데이터셋을 어느정도 정해주면 보고서를 알아서 작성해주는 서비스를 설명해 주셨었다. 아쉽게도 설계부분에서는 취약한 부분이 많았고, AWS를 사용하고 있지는 않아서 내가 듣고자 하는 부분을 듣지 못했다.

마지막 핵심(?) 세션인 AWS 장애에 대한 토론으로는 직접적으로 경험하셨던 분들의 이야기가 재밌었다.

• 스타트업에서 사실 한시간정도 안되는건 괜찮지 않나요?
• 해결하려고 고민하던 찰나에 해결이 됐다.
• 구글로 DNS를 우회하니 되었다.
  • 이 내용은 사실 검증이 되지 않았다.
  • 이 의견에 대해서는 다양한 의견이 나왔었다.
  • 캐싱된 데이터때문에 됐던것 같다.
  • 우연히 장애 복구 시점에 잘 된것처럼 보인거다.
  • AWS에서 근무하시는 분의 공식적인 입장은 말이 안된다는 거였고..
• 모든 서비스가 EC2 없이 Lambda로 구성된 'A'사의 경우 Lambda@Edge가 있어 문제 없이 넘어갔다.
• S3에 static 페이지를 저장해놨기 때문에 메인페이지 띄우는 데 혹은 에러 메세지 띄우는데 문제가 없었다.

등의 여러가지 의견들이 오고 갔다.

나는 프로그래머로 일하면서 내가 설계 측면에서 많이 약하다고 생각되는데 이유로는 경험이 많이 없고, 공부할 방법을 몰라서였다. 첫번째 회사에서는 설계할 만한 것도 딱히 없었고.. 두번째 회사에서는 설계를 튼튼히 하고 싶어도 팀장님이 설계를 중요시 하지 않아 일단 빨리 돌아가게끔 하는데 초점이 맞춰졌었다. 공부할 방법을 몰랐던 이유는 1+1=2처럼 답이 딱 정해져 있는 것이 아니라 케이스가 너무 다양하고 그 때마다 다양하게 설계 될 수 있기 때문에 참 막막했던 것 같다. 근데 처음으로 아키텍처 소모임에 가서 사례들을 듣다 보니 여러 사례를 접하는게 도움이 될 것 같다는 생각이 들었다. 내 경험도 중요하지만 나와 비슷한 상황에서 다른 사람들은 어떻게 했을까?를 듣는 것이 공부할 갈피를 잡는데 도움되는 것 같다.

짧은 시간이었지만 꽤 많은 분들이 의견을 내주시는 모습을 보고 신기하기도 했다. 커뮤니티 참석해도 (행사마다 분위기가 다르겠지만)다양한 사람들이 의견을 내기가 어려운데 이 커뮤니티는 그래도 그런 분위기가 잘 조성되어있고 무엇보다 사회자분이 진행을 잘 해주셨던것 같다.

• 본인의 사례 이야기
• 검증된(?) 참석자에게 이야기 유도
• 다른 분들의 자연스러운 참여

이 순서대로 진행했는데 내가 나중에 행사를 계획할때 참고해야 겠다!