서버 개발자가 장애를 만났을 때
그동안 쌓여왔던 문제와 함께 능력 있는 개발자가 빛나는 시간
최근에 듀랑고라는 게임이 정식 출시되면서 온갖 서버 장애로 인해 많은 이들에게 욕을 먹는 것을 볼 수 있었다. 같은 개발자로서 비난보다는 안타깝다는 생각이 많이 들었다. 아무리 잘 준비한다고 하더라도 장애가 발생하지 않기란 어려운 일이다. 종단 간 테스트(End to End Test)를 충분히 잘 해뒀으면 문제가 생기지 않을 것 아니냐고 쉽게 말하는 사람들도 있지만 먼저 종단 간 테스트를 잘 설계하는 것도 어려울 뿐더러 대규모에 대해 수행하는 것은 더 어렵지 않나.
서버 개발자로서 살아가다 보면 장애는 언제나 함께할 수밖에 없는 존재다. 애플리케이션의 문제에서부터 인프라의 문제까지 온갖 문제로 인해 장애가 발생할 수 있다. 전에 존경스러운 시니어 개발자 분으로부터 "장애는 무조건 발생한다. 막을 생각보다 잘 극복할 생각을 해라."라는 조언을 들은 적이 있다. 그도 그럴 듯이, 수천 대의 서버가 돌아가는 환경에서는 오히려 모든 서버가 문제없이 돌아가는 상황을 기대하는 것 자체가 과도한 욕심일 것이다. 그분의 조언의 속 뜻은 이런 환경에서 서버가 장애를 일으키는 것이 당연하고, 그런 경우에도 전체 시스템은 문제없이 수행될 수 있도록 하되, 문제가 된 서버는 빠르게 교체 및 복구할 수 있도록 해야 한다는 뜻이었다.
물론 이것도 말이 쉽다. 문제가 된 서버를 빠르게 교체할 수 있다는 말은 그 서버와 동일한 일을 수행할 수 있는 환경으로 빠르게 복구시킬 수 있어야 한다는 말이다. 잠깐 간단한 산수를 해보자. 초당 200 MiB를 읽을 수 있는 스토리지 2 TiB를 복제하려면 얼마나 시간이 걸릴까? 약 10000초, 3시간 정도이다. 몇 분의 장애에도 민감한 상황에서 몇 시간의 장애는 재앙이다. 그런데 이건 단순 복사 작업에만 이 정도 시간이 든다는 것이고, 스토리지 복제 후 애플리케이션이 시작하기 전 스토리지를 Full Scan 해야만 한다면 더 시간이 많이 들 것이다.
이런 문제는 Replica를 잘 만들어뒀으면 문제가 되지 않았을 수도 있을 것이다. 그러나 일단 문제가 발생했다고 생각해보자. 지금부터는 최대한 지식을 짜내서 복구를 1분 1초라도 빠르게 할 수 있는 방법을 생각해내야 한다. 스토리지 복구를 위한 가장 빠른 방법은 무엇인가? 스냅샷을 만들어뒀던가? 만약 그렇지 않다면 어떻게 하는 게 가장 빠른가? 스토리지와 관련된 설정 값은 어느 값으로 변경하는 것이 가장 빠를 것인가? 여러 방법을 동시에 시도해볼 수 있는가? 서버 복구를 위해 돈을 투자할 수 있는가? 그렇다면 어떤 자원에 얼마나 투자하는 것이 가장 효율적인가? 복구가 완료되고 나면 자원을 회수할 수 있는가?
머신이 복구되고 나면 이제 애플리케이션을 다시 띄워야 할 것이다. 애플리케이션은 바로 다시 역할을 수행할 수 있는가? 그렇지 않다면 어떻게 해야 가장 빠르게 다시 제 역할을 할 수 있는가? 애플리케이션이 재실행시 서버 자원을 얼마나 쓰고 있는가? 만약 일부만을 쓰고 있다면 어떤 설정들을 수정하여 재실행 속도를 끌어올릴 수 있을 것인가? 이 애플리케이션을 다시 살리는 과정에 클러스터 내 다른 노드들이 영향을 받지는 않는가?
그냥 복구만 있겠는가. 장애 극복(Failover)도 해야 한다. 장애 동안 우회하여 처리할 수 있는 방법도 생각해야 하지만, 장애로 인해 잘못 만들어진 결과물을 갱신할 방법을, 그것도 가장 빠른 방법을 생각해내야 한다. 한 건에 10ms 밖에 걸리지 않는다 하더라도 천만 건의 데이터가 밀려있다면 직렬로 처리하는데 28시간이 걸린다. 당연히 병렬로 처리하게 해서 시간당 처리량을 최대한 끌어올려야 한다. 어떻게 병렬로 처리하는 게 더 빠를 것인가? 프로세스를 나눠서 처리할 수 있는가? 쓰레드는 얼마나 띄우는 게 적절할 것인가? Thrashing은 발생하지 않을까? 별도로 서버를 따로 돌려서 장애 극복을 더 빠르게 할 수는 없을까? 그렇다고 하면 머신 성능은 어떤 것으로 선택하는 게 좋을까? CPU가 많은 것을 골라야 하는가, 메모리가 많은 것을 골라야 하는가, 네트워크 자원이 많은 것을 골라야 하는가, 스토리지는 어떻게 해야 하는가? 머신은 몇 대를 띄우는 게 좋을까? 이 장애 극복 작업으로 인해 2차 장애가 발생하지는 않을 것인가?
상황이 정리되고 나면 그동안의 작업 내역을 검토해본다. 복구를 위해 수행한 방법은 가장 좋은 방법이었는가? 왜 장애가 발생했는가? 어떤 지점이 장애 지점이었는가? 다음에 똑같은 문제가 다시 발생했을 때 장애가 나지 않도록 하기 위해서는 시스템의 어떤 부분을 개선해야 하는가? 개선을 위해 가장 적절한 솔루션들은 무엇이 있는가? 그 솔루션을 도입하기 위해 필요한 역량과 자원을 갖고 있는가?
그동안 장애 시 드는 고민들 중 생각나는 것들을 몇 개 열거해봤다. 다소 경박하게 표현하자면, 멍청한 방법으로도 복구는 할 수 있다. 단지 복구 작업에 얼마나 많은 시간이 드는지가 다를 뿐이다. 그렇기 때문에 장애가 발생했을 때 개발자의 역량 차이가 더욱 두드러진다고 생각한다. 누군가는 복구에 며칠이 걸리는 방법을 생각해낼 때 역량이 뛰어난 개발자는 몇 시간 내에 복구되는 방법을 생각해낼 수 있다. 이는 알고리즘 문제 풀이와도 비슷하다. 누군가는 O(n^3)를 생각해낼 때, 누군가는 O(n^2)를 생각해낸다.
의료계에 종사하는 것이 아니기 때문에 적절한 비유인지 모르겠지만, 장애는 암과 비슷하다고 생각한다. 평상시에는 보이지 않던 문제들이 장애 상황에서 드러난다. 역량 있는 개발자가 되어 극복과 개선 모두 잘할 수 있도록 해야겠다.
