Unknown Artist
운영을 하다보면 만든 사람이 직접 조치를 해야 하는 문제들이 생길 수 있다. 온콜(On-call)1은 이러한 상황에 빠르게 대응하기 위한 방법 중 한 가지인데, 실무에서 온콜이 의도와 다르게 동작하는 경우를 보았다. 먼저, 온콜과 런북(Runbook)2을 활용하여 절차에 따라 긴급 장애에 대응하는 방식으로 발전하기보다, 서비스가 파편화되어있고 복잡하기 때문에 만든 사람만이 해결할 수 있다는 근거를 내세워 긴급하게 담당자를 찾는 수준에만 장애 대응 절차가 머무른 경우다. 페이징(Paging)3을 받으면 임계값 기준에따라 미리 정의한 장애 수습절차(런북)를 수행해야 하는 것이 모범 사례다. 하지만, 'System error 50건 이상 발생'이라는 메시지를 받고 그제서야 로그를 분석해서 장애 등급을 판단하고 실시간으로 원인을 파악하는 모습을 목격하기도 했다. 직관적인 알람과 체계화된 런북이 필요한 이유다.
또 다른 상황은, 신입 엔지니어들이 상대적으로 시스템과 서비스에 대한 이해가 부족해서 실수를 할 수 밖에 없다는 것이었고, 결국 연차가 오래된 선임을 온콜로 불러내어 문제를 수습하는 것이 반복되는 것이었다. 어떻게 보면, 연차가 오래된 엔지니어일수록 시스템의 맥락과 동작을 잘 알고 있기 때문에 문제를 빠르게 수습하는 것은 당연하다. 그리고 리더십의 입장에서도 이러한 슈퍼히어로 방식은 당장 문제를 빠르게 해결하는 것처럼 보이기 때문에 매혹적이다. 하지만 아무나 빨리 해결해 주길 바라는 마음과 슈퍼히어로 역할을 즐기는 마음이 만들어낸 시너지는 장기적으로 조직이나 시스템 모두에 대해 규모의 확장을 방해하게 된다. 뛰어난 누군가가 드라마틱하게 문제를 해결해 주는 상황이 반복되면, 리더십은 슈퍼히어로에게 의지하게 되고 항상 그 사람을 찾게 된다. 주니어 엔지니어 혹은 시스템에 익숙하지 않은 사람들은 문제를 빠르게 수습하지 못한 것 때문에 성과 평가에 대한 부담이 생기면서 자존감이 떨어지며, 시스템에 대해 빠르게 배워야 한다는 부담감도 생겨서 퇴사를 고민하게 된다. 반대로 선임 엔지니어들이나 슈퍼 히어로 역할을 하는 당자사는 지속적으로 문제를 해결해야 하기 때문에 번아웃(Burn-out)의 위협을 받는다.
이러한 문제들을 해결하고, 규모의 확장을 효율적으로 수행하기 위해서는 소프트웨어를 대하는 시각이 작자 미상의 제품을 바라보는 것처럼 되어야 한다고 생각한다. 누가 만들었는 지 알지 못해도, 어떤 의도가 있는 지 알 수 없어도 활용하는데 지장이 없도록 소프트웨어 제품의 품질 목표를 설정하는 것이다. 작자 미상(未詳): 여기서 미상은 불분명하다는 의미다. 작가를 알 수 없다는 것이 여러 의미를 갖겠지만, 누가 만들었는 지 상관없이 작품이 의미가 있어야 한다는 의미를 말하고 싶었다. 작자 미상의 소프트웨어를 만들려는 목표를 가지고 소프트웨어를 설계하고 운영한다면4 슈퍼히어로가 없어도 안정적인 서비스 운영을 할 수 있을 것이다.
기본적으로 장애 심각도 등급에 따라 담당자를 연락하는 페이징은 필요하다. 하지만 이미 상황이 벌어진 뒤이기 때문에 사전에 예방하는 것이 더 중요하고 필요하다고 생각한다. 사전 조치라는 표현 보다 예방이라는 표현을 선택한 것은, 사전 조치에 대한 시각이 다를 수 있다는 것을 배웠기 때문이다. 서비스 장애는 즐거운 일이 아니며 모두가 겪고 싶지 않은 일이기 때문에 미리 회피하길 바란다. 하지만, 서비스 품질을 높여서 미리 예방하는 것은 풍부한 경험과 개발 실력, 그리고 많은 노력이 필요하다. 그러다 보니, 장애 조짐이 조금이라도 보이면 미리 페이징을 해서 장애로 번지기 전에 미리 수습하는 전략을 택한다. 이론적으로는 그럴듯 해보이지만, 이 방식은 거짓 알람(False Alert)이 늘어나는 문제가 생긴다. 아무리 지표를 잘 분석한다하더라도 10 분 뒤에 일어날 문제를 정확하게 예측하는 것은 어렵다. 장애는 단순히 한 가지 원인만으로 발생하지 않으며, 10분은 장애를 예측한 원인이 아닌 다른 이유로인해 문제가 해결 될 수 있는 충분한 시간이기 때문이다. 만에하나 5분에서 10분 뒤의 장애를 맞게 예측했더라도, 10분 안에 완벽한 대응을 수행하는 것은 불가능에 가깝다. 마치 농구나 축구 경기에서 사람보다 공이 빠른 것과 비슷하다. 결국 쉽지 않은 길이지만, 오류의 정정(Correction of Error, CoE)5과 지속적 전달(Continuous Delivery)6에서도 설명했던 것처럼, 장애가 발생할 가능성이 있는 부분을 근원적으로 해결하고 검증해서 문제가 발생할 불씨를 애초에 없애야 한다. 이렇게 말하면, 우리가 아직 모르는 원인으로 장애가 발생할 수도 있는데 어떻게 모든 일을 예상할 수 있냐고 반문하는 경우가 있다. 그럴 경우에는 장애가 난 부분을 고칠 것이 아니라 잠시 전체 서비스 또는 일부 서비스를 중단해서 고객에게 양해를 구하고 대체제7를 빠르게 투입해서 대응해야 한다. 예측하지 못한 장애들을 최대한 미리, 그리고 많이 발견하기 위한 카오스 엔지니어링(Chaos Engineering)8과 같은 모범 사례들이 있으니 예전에는 이러한 주장이 똑똑한 주장이었을 수 있겠지만, 이제는 변명일 뿐이다.
좋은 소프트웨어를 만드는 단 한 개의 원칙을 선택하라고 한다면, '내 손을 떠나도 동작해야 한다'9를 선택하고 싶다.
- On-calls [본문으로]
- Runbook [본문으로]
- 영어로 '전화기 앞(에 대기)'이라는 의미의 온콜(On-call)이 비상 당직 근무인 것과 비슷하게 담당자를 호출하는 (한국에서는 삐삐로 더 알려진) 무선 호출기인 페이저를(Pager)를 통해 연락하다는 개념으로 사용한다. [본문으로]
- 대표적인 사례로 플랫폼이나 프레임워크가 있다. [본문으로]
- Correction of Error [본문으로]
- Continuous Delivery [본문으로]
- Fallback, Rollback [본문으로]
- Chaos Engineering [본문으로]
- 'Software Release'라는 단어가 있는데, Release는 손을 떠났다는 의미가 들어있다. [본문으로]