서버 개발자로써 일을 하다보면, 어쩔 수 없이 장애라는 것을 맞게 된다. 이러한 장애가 발생했을 때, 어떻게 장애에 슬기롭게 대응할 수 있을까?
이 글은 "슬기롭게 장애에 대응하는 방법" 을 알려주는 글이 아닙니다. 스스로 장애를 겪으면서 어떻게 대응했었는지에 대한 회고에 가깝습니다.
장애가 발생했다.
장애의 발생에는 여러가지 유형이 있다.
- 단순 롤백으로 바로 해결되는 유형
- 롤백으로 해결되지 않아 새롭게 수정 배포를 해야하는 유형
- 문제가 생긴 데이터들을 보정까지 해야하는 유형
등등..
이런 여러가지 유형이 있지만 결국 문제가 생겼을 때, 가장 먼저 해야하는 것은 당연히 당장 급한 불을 끄는 것이다. 당장 불을 꺼야하는 이 상황 어떻게 대응하는 것이 좋을까?
혼자서 대응하는 것이 아닌 나를 포함한 다른 사람과 함께 대응하는 것이 제일 좋은 방식이라고 생각한다. 한 명은 롤백을 하거나 수정 배포를 하면서 상황을 해결하고, 다른 사람들은 팀 내의 매니저 혹은 다른 팀과 소통을 이어가면서 현재 상황을 브리핑하여 어떻게 해결되고 있는지 이야기 하는 것이다.
심폐소생술 단계별 요령도 비슷한 방식이라고 생각한다. 적절한 역할 분배를 통해 심폐소생술을 하는 사람은 당장의 문제를 해결하고, 주변 사람은 외부 ( 119 ) 와 이야기하면서 현재 상황에 대해 브리핑하게 된다.
이렇게 하면, 해결도 해결이지만 해결하면서 어떤 방식으로 점진적 해결을 해 나갔는지 실시간으로 공유할 수 있게 된다. 이런 공유는 타 팀이 해당 상황을 인지하기 쉽게 해주며, 브리핑을 하는 사람이 기록을 남기기 때문에 추후 같은 문제가 생겼을 때도 대응하기 쉬워진다.
장애가 해결되고 나서
그럼 이제 롤백 혹은 수정 배포 등 여러 가지 방법으로 장애가 해결되고 나서, 가장 먼저 해야하는 것이 무엇일까? 회고? 재발 방지 대책 작성? 이것 저것 할 일이 많겠지만, 가장 중요한 것은 상세한 원인 파악 이라고 생각한다.
장애를 대처하는 당시에는 일단 불을 끄는 것에 집중을 하기 때문에, 원인 파악을 생각보다 상세하게 하지 않고 일단 해결을 먼저하게 되는 경우도 생긴다.
실제 사례를 통해 살펴보자.
사례
어느 날 갑자기 IDC에 있는 레거시 서버의 http user count가 급격하게 올라가서 해당 서버의 어플리케이션이 제대로 요청을 처리하지 못하는 일이 발생했다. 해결을 위해 로그를 살펴봤고, 일회성으로 많은 요청이 인입되어 문제가 발생했다는 것을 알게 되었다. 해당 어플리케이션은 여러 서버에 나뉘어 배포되어 있었기에, 일단 해결을 위해 어플리케이션들을 처리하는 웹 서버들을 차례로 재기동하여 http user count를 줄이는 방식을 사용하여 문제를 해결했다.
이렇게 상황을 해결하고나면, 어떤 자세를 취해야 할까? 어떤 사람들은 해결 됐으니 넘어가자라는 방식을 취하는 사람도 있을 것이고, 또 다른 사람들은 이 문제의 자세한 원인을 파악하려고 할 것이다.
나는 후자의 방식을 택하는 것이 맞다고 생각한다.
실제로 나는 해당 방식을 택해 장애 시점의 로그들을 유심히 살펴봤고, 해당 문제가 발생했던 시기에 급격하게 레거시 서버에서 서빙하던 특정 js 파일에 대해 접근이 많아졌다는 것을 알게 되었다.
해당 js 파일은 가맹점에서 html에 임베딩하여 사용하는 경우가 많았기에, 가맹점에서 할인 이벤트 같은 행사를 했던 당시에 가맹점의 트래픽이 올라감과 동시에 우리 서버의 트래픽도 함께 올라가는 문제를 겪게 된 것이다. 이런 상황을 해결하기 위해 DevOps 팀과 인프라 팀의 도움을 받아 해당 js 파일을 CDN을 통해 서빙하도록 하여, 서버의 트래픽을 줄일 수 있도록 해결하였고 이를 통해 다시 이 문제가 재발하지 않게 되었다.
결국 장애가 끝나고 해야하는 것은 원인 파악
위 사례를 보면, 장애가 발생했을 때의 대처는 단순히 차례대로 재기동이였지만 그것을 실제로 해결한 방식은 CDN을 붙이는 방법이였다.
만약, "차례대로 재기동하니 해결되었다" 하고 넘어갔다면 어떻게 되었을까? 당연히 똑같은 문제를 또 다시 마주하게 되었을 것이다.
그렇기에 장애가 끝난 뒤에는 자세한 원인 파악 및 재발 방지 대책 수립 혹은 재발 방지 대책을 찾아 적용하는 것은 장애를 마주할 때 가장 중요한 행위 중 하나라고 생각한다.
그 다음은 무엇을 해야할까?
회고
이렇게 원인 파악과 재발 방지 조치까지 완료했다면, 해야 할 것은 이를 기반으로 PIR ( Post Incident Reviw ) 혹은 장애 회고라고 불리는 회고를 해야한다.
해결까지 했는데, 회고를 왜 해야할까? 회고를 하게 되면, 우리는 다시 한 번 문제 되었던 것을 상기할 수 있고 다른 개발자들도 같은 문제를 겪지 않도록 해당 문제에 대해 공유할 수 있는 기회를 얻기 때문이다.
이렇게 회고를 쓰고 공유하고 나서는 추후 다시는 이러한 문제를 동일하게 겪지 않도록, 시스템을 구성하거나 구현에서 신경써야 할 것이다.
만약 이것이 매우 크리티컬한 문제라면, 팀 혹은 같은 직군과 이야기를 할 수 있는 위클리 같은 시간에 해당 문제와 해결 방식등을 공유하는 것도 좋은 방법이라고 생각한다.
