2021년 6월 N일 오전 11시였다. 갑자기 beanstalk 환경이 재구축이 되면서 한 동안 서비스가 중단 되었다.
1시간 전으로 돌아가서... 오전 10시 출근하자마자 나는 새로 입사하신 개발자분들과 함께 새로운 서비스를 위한 실서버 환경에서 beanstalk 환경을 구축하고 있었다. 그러니 갑자기 다음과 같은 로그가 있었다. 나는 그저 환경을 하나 새로 구축 밖에 하지 않았다. 우선 매우 당황했고 슬랙에 알렸다. 실서버가 다 사라졌다고.. 앱, 웹 접속이 되지 않을 것이라고..
우선 어찌어찌해서 환경을 새로 만들어서 서비스 정상화를 시켰다. 그리고 원인을 파악하려고 여러 로그를 뒤졌다.
먼저, 재구축 시도한 환경이 새로 살아나지 않는 현상이 발생했다.
다음과 같은 에러를 뿜으며 새로 재구축이 되지 않았다.
우선 전에 다른 환경을 구축하면서 실서비스에 만들어진 보안그룹을 새로운 환경에 대한 보안그룹으로 추가해주었었다. 이게 문제가 되었던 것 같다. 실서비스 환경을 지우려고 하니 실서비스에 대한 보안그룹이 다른 환경에서 사용 중이어서 삭제를 못 하는 듯 싶었다. 우선 이렇게 재구축 실패에 대해서 파악하고 다른 환경에서 해당 보안그룹을 풀어주었다.
이제 왜 갑자기 재구축이 되었는지 파악을 해보려고 했다. 다행히 CloudTrail 이란 이벤트를 기록해주는 서비스를 aws 에서 제공했고, 여기서 로그를 찾아보았다. 그리고 다음과 같은 이벤트 로그가 있었다.
팀 개발자분께서 실수로 테스트로 만든 환경을 재구축을 누르셨는데 알고보니 선택한 환경이 실서버 환경이었던 것이다.
어쨌든 백엔드 개발자 중 가장 오래다닌 내가 가장 큰 책임이 있다고 생각했다. 물론 aws 를 prod, dev 로 분리해서 사용하긴 한다. 어쨌든 이렇게 스타트업 특성 상 백엔드 개발자가 적은 상황에서 새로운 개발자 분에게 iam 사용자 권한을 어디까지 허용하면 좋을까라는 고민이 생겨서 글을 작성했다. 물론 백엔드 시니어 개발자나 CTO 가 있는 상황에서면 권한을 적용한 그룹을 세세하게 나누어서 적용하면 좋을 것 같다. 그러나 백엔드 개발자가 나 포함 2명인 상황이며 나도 주니어인 상황에서 어떻게 하면 좋을지 모르겠다.
- 어드민 사용자를 하나 따로 만들어서 환경 수정 및 생성 할 때만 개발자 모여서 신중하게 한다. 그리고 나머지 사용자는 수정 권한을 제거한다.
- aws 익숙해지기 전까지만 배포 권한을 준다.
- 그냥 내가 총대 매고 관리한다.
정리하면 이 정도로 생각할 수도 있을 것 같다. 3번은 우선 탈락이다. 왜냐하면 이렇게 되면 장애가 발생하거나 내가 회사에서 사라졌을 때 어떻게 할 지 익숙치 않은 상태이실 것이기 때문이다. 그리고 2번은 익숙해지는 것의 기준이 모호해서 패스한다. 그러면 1번이 남았는데 그나마 가장 낫지 않을까 싶다. 항상 수정이 있을 때는 같이 모여서 하는 것으로 하면 그나마 N명의 사람이 모여서 하니 덜 실수하지 않을까 싶다(페어코딩처럼). 내가 환경을 처음에 잘 세팅하고 권한을 잘 나누었거나 내가 환경 세팅하는 것을 계속 봐주었다면 장애도 발생하지 않았을 것 같다. 귀차니즘을 버리도록 하자..