📃 장애에 대한 개발자의 시선

✍️ 전 국민이 사용한다 해도 과언이 아닐 정도의 큰 서비스가 셧다운(전원 꺼짐) 수준으로 오류가 발생했습니다. 이 글을 작성하고 있는 지금까지도 복구가 아직 안 되고 있는데(현재 시간 기준 약 6시간 경과) 이 정도로 큰 장애가 있었나 싶은 생각도 드는데요. 여기저기서 해당 서비스에 대한 악의적인 이야기를 하거나, 강 건너 불구경 하듯 손가락질만 하는 모습이 보기 참 안타까운 심정입니다. 개발자인 우리들은 '내가 운영하지 않은 다른 서비스'의 장애 상황을 보고 어떤 생각을 가져야 하는 게 좋을까요? 사전에 정의되어 있는 건 아니지만 개인적인 생각을 정리해 보고자 합니다. 이제까지 알려진 정보에 의하면 데이터 센터에 화재가 발생하였고 그곳에 있는 서버가 셧다운 되어 발생한 문제로 추측됩니다. 화재가 발생했던지 지나가던 고양이가 데이터 센터 메인 두꺼비 집을 솜뭉치 발로 내려버렸다든지 어쨌든 데이터 센터의 셧다운이 발생하면 아무것도 할 수 없을까요? 서비스의 안정화를 위해서는 이중화(HA : High Availability) 나 재해복구(DR : Disaster Recovery) 시스템을 구성해두곤 합니다. 서비스의 규모상 이런 구성을 안 했을 리가 없을 텐데 만약에 구성을 했다면 그럼에도 불구하고 왜 서비스가 전면 장애까지 발생했을까요? 본인이 해당 서비스의 담당자인 것처럼 생각을 하며 원인을 다방면으로 추측해 보는 게 좋다고 생각합니다. 내가 직접 경험하진 않았지만 사례를 통해 미리 예방할 수 있으니까요. 원인이 무엇인지 생각을 해봤으면 이제 복구에 대해서 고민을 해봅시다. 화재가 모두 진압이 되었다고 가정을 하면 이제 어떻게 복구를 해야지 사용자가 서비스를 기존처럼 사용할 수 있는 상태가 될까요? 손전등 스위치를 조작하여 불을 켜고 끄는 것처럼 간단히 해결되진 않을 테고 무엇을 먼저 복구를 하는 등 순서는 어떻게 될까요? 수천만명이 계속 해당 서비스에 문을 두드리고 있다면 그 트래픽을 한 번에 받을 땐 문제가 되지 않을까요? 어떤 방법을 써서라도 최대한 빠르게 복구하는 게 가장 중요하긴 하지만 여러 가지 관점으로 고민을 한 뒤에 2차, 3차 장애가 발생하지 않도록 전략적으로 복구를 해야 하지 않을까 생각이 됩니다. 어떤 방법으로 복구를 했다고 칩시다. 그럼 이제 서비스가 돌아가니 발 닦고 잠자면 그만일까요? 장애의 영향도를 체크하고 서비스의 기능들을 전반적으로 점검해서 복구가 안된 부분이 있는지 살펴봐야 하며 안정적으로 서비스가 돌아가는지 모니터링을 해야 합니다. 물론 복구 이후에는 트래픽이 기존과는 다른 형태로 들어와 서비스가 간헐적으로 비정상적일 때도 있겠지만 CPU, 메모리 상태나 각종 지표들이 장애가 발생하지 않는 평상시의 수준으로 돌아올 때까지 계속 살펴봐야 합니다. 원인을 파악했고 복구를 했으며 모니터링까지 끝났다면 이제 정말 끝일까요? 타임라인별로 있었던 일들을 정리하고 (장애의 원인부터 대응한 내역 등 모든 히스토리) 이를 잘 정리해서 공유할 수 있는 범위 내에서 최대한 많은 인원이 볼 수 있도록 공유하고 비슷한 상황이 발생했을 때 장애가 발생하지 않기위해 재발방지 대책을 미리미리 마련해야 합니다. 더불어 계획을 세워서 장애가 발생하면 복구를 얼마나 빨리하는지에 대한 일종의 훈련 같은 절차 또한 필요하다 생각이 됩니다. 크게 정리하면 " 원인 파악 → 복구 → 모니터링 → 정리 → 훈련 "의 순서가 될 텐데요. 제가 말하고자 하는 핵심은, 장애가 발생한 담당자의 시선에서 가상으로라도 생각을 해보자입니다. 경험을 사례로 미리 해볼 수 있는 건 엄청난 좋은 기회가 되죠. 그러면서 몰랐던 개념이나 듣기만 했던 내용들을 이번 기회에 공부를 할 수도 있고요. 아무쪼록 단 한 명의 인명피해 없이 화재 진압이 잘 되었으면 좋겠고, 서비스 또한 무사히 잘 복구되면 좋겠습니다. 마지막으로 황금 같은 주말 연휴에 고생하고 계실 담당자분들께 힘내라는 응원의 메시지를 전달드리고 싶습니다.🙏