🎤 이 아티클은 3회차 구름 세미나에서 레몬트리 CTO 강대명 님이 강의해주신 내용을 바탕으로 재구성되었습니다.
어느 날 갑자기 장애가 발생했다
심장이 두근거리면서 머리가 새하얘지죠. 제발 내 코드에서 발생한 장애가 아니기만 바라게 되는데요.
일단 장애가 발생하면 서비스 제공자가 고객보다 먼저 인지하는 게 중요합니다. 가장 아찔한 상황은 장애가 발생했는데 모르고 있는 경우라고 생각해요.
대부분은 장애가 발생한 걸 고객 CS로 아실 텐데요, 좋지 않은 장애 인지 순서입니다. 고객이 먼저 장애를 인지하면 불만이 쌓이고, 불만이 쌓이면 서비스를 떠나게 됩니다. 그렇게 회사 매출이 줄어들면 여러분과 제 자리가 위험해지고요. 고객보다 먼저 장애를 인지했다면 버그를 수정해서 조용히 배포하면 됩니다. 전문 용어로 ‘잠수함 패치’라고 하는데요, 없었던 일로 만드는 거죠.
고객보다 먼저 장애를 인지하려면
‘모니터링’이 중요해요. 우리 서비스가 문제없이 잘 돌아가고 있는지 서비스에 영향을 주는 모든 걸 확인해야 합니다.
위에서 언급한 항목 외에도 우리 서비스 도메인에 맞는 모니터링을 적절히 추가해야 합니다. 예를 들어 우리 서비스가 이커머스(e-commerce)라면 일정 시간대가 피크 타임이겠죠? 어느 날 피크 타임에 매출이 전혀 발생하지 않는데, 에러 메시지가 1개도 오지 않는다면 장애 상황일 수 있습니다. 매출이 발생하는지도 모니터링해야 하는 거죠.
제대로 모니터링하려면 어떤 상황이 장애인지부터 알아야 해요. 예전에 A 서비스를 운영할 때 주 사용자가 초등학생이었는데요. 3월 초에 트래픽을 봤는데 평소 트래픽의 4분의 1밖에 안 들어오는 거예요. ‘이건 장애다’ 싶어서 팀원들을 모았는데 알고 보니 3월 초가 개학 시즌이라 친구들하고 노느라 접속을 안 했더라고요. 정상적인 상황이었던 거죠.
모니터링 프로세스가 잘 갖춰져 있는 팀은 이상 수치에 대한 알람도 잘 되어 있습니다. 물론 알람은 중요도에 따라 잘 구분해야 해요. 하루에 알람이 999개씩 오는데 매번 큰 이슈가 아니라면 별거 아니라고 생각하고 넘기게 되거든요. 중요하지 않은 알람은 기준 수치를 높여서 덜 오게 만들고, 알람을 못 받았는데 장애가 발생했다면 기준 수치를 낮춰야겠죠? 모니터링 수치도 리팩토링이 필요합니다.
모니터링 지표는 일주일 전, 한 달 전, 1년 전 시점하고 비교해보는 게 좋아요. 이번 주 지표는 지난주나 한 달 전하고 비교해 보면 달라진 점이 확연히 보이거든요. 정보를 더 가시적으로 볼 수 있도록 그래프를 개선하는 것도 필요합니다. 그래프 모양만 보고 이벤트나 장애 시점을 찾기도 하거든요.
💡 모니터링 프로세스의 기본
1. 중요도에 따라 알람 구분하기
2. 모니터링 지표는 1주일, 1달, 1년 단위로 비교하기
만약 회사에 모니터링 시스템이 없다면 만들면 됩니다. 처음에는 간단하게 핑을 보내고 안 받으면 문자나 전화가 오게 하는 거죠. 저희 서비스는 1시간이나 2시간 단위로 에러 메시지가 모이면 가장 많이 발생한 에러를 순서대로 볼 수 있도록 만들어 놨습니다. 이런 식으로 만들어 두면 장애 원인을 파악하는 게 조금 더 수월하겠죠.
장애가 발생하면
빠르게 전파해야 합니다
특정 상황이 발생하면 이게 장애가 맞는지부터 확인해야겠죠. 에러 메시지와 수치 모니터링으로 장애를 인식합니다. 주의할 점은 이 단계에서 원인까지 파악하려고 하면 안 된다는 거예요. 초반에는 장애라는 것만 확인한 다음 유관 부서에 장애 발생을 전파해야 합니다.
장애 인지 다음은 ‘전파’입니다. 장애가 발생했을 때 대응하는 건 개발팀만이 아니에요. 전사가 관여합니다. 특히 CS팀과 함께하죠. CS팀은 장애를 인지하는 최전선에 있습니다. 고객에게 문의를 받는 분들이 장애 상황을 모르고 있다면 답변을 해드릴 수 없겠죠. 우리 팀과 연관 있는 다른 개발 팀에도 빠르게 전달해야 합니다. 만약 우리 서비스가 API를 제공하고 있다면 해당 API를 사용하는 팀이나 외부 고객들에게도 알려야 하죠.
장애 전파는 처음 한 번만 진행하는 게 아닙니다. 1시간 혹은 2시간 간격으로 변화가 있는지 없는지 알려야 해요. 지금 상황에서 큰 변화는 없지만 해결하려고 노력하고 있다던지, 원인을 발견해서 처리 중인데 시간은 어느 정도 걸릴 것 같다는 식이죠. 물론 예상했던 시간보다 오래 걸릴 수 있어요. 시간에 너무 얽매이지 마시고 중간중간 상황을 공유하는 게 중요합니다.
장애를 인지하고 전파했다면 분석해야 합니다. 어떤 장애인지 파봐야죠. 보통 90%의 장애는 간단한 작업으로 해결할 수 있는 경우가 많습니다. 큰 장애는 1년에 몇 번 발생하죠. 그래서 장애 매뉴얼이 필요합니다. 장애가 발생해도 매뉴얼이 있다면 금방 처리할 수 있으니까요.
장애 처리 매뉴얼은
거창하지 않습니다
저는 어느 회사에 가도 장애 처리 매뉴얼이 없다면 먼저 만드는 편입니다. 굳이 많은 정보를 넣으려고 하거나, 잘 만들려고 하지 않아요. 처음에는 나만 알아본다는 생각으로 간단하게 만듭니다. ‘이런 에러 메시지가 발생하면 서버를 리부팅해라’, ‘이런 에러 메시지가 발생하면 누구를 불러라’는 식으로요. 무엇이든 처음부터 완벽하게 만들려고 하면 시작할 수 없습니다.
장애를 겪으면서 기존에 정리해둔 내용이 있다면 보고 해결하면 되고, 없으면 해당 내용을 추가하면 됩니다. 계속 업데이트 해나가는 거죠.
다만 매뉴얼을 작성할 때 ‘무슨 에러가 발생했다’에서 끝내면 안 됩니다. IP는 어디였고, 무슨 에러였고, 이런 케이스였다 등을 최대한 자세히 남기면 좋아요.
장애 매뉴얼은 누구나 볼 수 있어야 합니다. 우리 팀과 외부 팀 모두요. 아까도 이야기 드렸지만 90%의 장애는 간단한 절차로 해결되는 경우가 많아요. 서버 리부팅이 대표적이죠. 장애 대응 매뉴얼이 잘 만들어져 있으면 편하겠죠?
혼자 해결하려고 하지 마세요
제가 짠 코드 때문에 문제가 발생했을 때 이런 생각이 들 때도 있습니다. ‘큰 장애가 아니니까 5분 내로 조용히 해결하면 덮을 수 있을 것 같은데..?’ 위험한 생각입니다.
혼자 고민하는 것보다 같이 고민하는 게 훨씬 좋잖아요. 제가 생각하지 못한 부분을 다른 분이 알아차릴 수도 있고요. 다각도로 함께 보는 게 장애를 빨리 해결하는 방법입니다. 무엇이든 빠르게 공유하는 분위기를 만드는 게 중요해요.
장애 매뉴얼에 없는
새로운 장애가 발생했다면?
원인을 파악하는 것보다 서비스를 정상화하는 게 먼저입니다. 보통 장애는 배포 직후에 많이 터집니다. 코드를 잘못 짰을 가능성이 높거든요. 배포하고 나서 장애가 터지면 롤백(rollback)하는 게 좋습니다. 원인이 명확하다면 빨리 수정해서 재배포하면 되지만, 잠깐 봐도 시간이 걸릴 것 같으면 바로 롤백해야 합니다.
롤백이나 재배포를 빨리하려면 배포 시스템도 좋아야 합니다. 배포하는 데 10시간씩 걸리면 롤백에 10시간이 걸린다는 거니까요.
개발 후 리그레이션 테스트(Regression Test)를 하면 좀 더 안심하고 배포할 수 있습니다. 가끔 버그 하나를 수정했는데 오히려 버그가 3~4개씩 늘어나는 경우도 있거든요.
장애 보고서 이렇게 쓰세요
장애를 해결했다면 발생했던 장애에 대한 보고서를 써야 합니다. 누군가에게 책임을 떠넘기려고 적는 보고서가 아니에요. 다음에 같은 장애가 발생했을 때 어떻게 해야 할지 남겨두는 거죠.
장애 보고서에 들어가야 하는 내용을 정리해 볼까요? 보통 아래 정도를 적습니다.
장애 요약장애 영향도장애 원인장애 처리 타임라인별 행동장애 재발 대비책그 외 추가 정보 등
어떤 장애였는지는 반드시 들어가야 하고요. 인지 경로나 장애 영향도도 기록하면 좋습니다. 장애로 인해 영향을 받은 서비스는 무엇이고, 장애 원인은 무엇이었는지도 적어야 하고요. 장애 처리 타임라인별 행동도 중요합니다. 처음에 어떻게 인지했고, 다음으로 몇 시에 누구에게 전파했는지, 전파하면서 어떤 작업을 해서 어떤 효과가 있었는지 적습니다. 장애 재발 대비책도 필요하죠. 이런 장애가 또 발생하지 않도록 하는 게 중요하니까요.
장애도 회고합시다
이번 세미나의 핵심입니다. 장애 회고에서 꼭 지켜야 할 규칙은 누가 문제를 만들었는지 언급하지 않는 거예요. 실제로 어떤 회사에서 장애가 났는데 보고서에 ‘이 사람이 장애를 냈습니다’라고 적어서 보고하는 경우를 봤어요. 그분은 앞으로 배포할 수 있을까요? 초점은 어떻게 개선할 것인지에 맞춰야 합니다.
장애 회고에 참여하는 사람은 장애를 해결한 팀과 장애 해결에 필요했던 팀, 앞으로 도움이 될만한 팀입니다. 회고 내용은 장애 발생을 막을 수는 없었는지 살펴보는 거예요. 적절한 테스트 단계가 빠진 건 아닌지, 구조적으로 문제는 없는지 뜯어봅니다. 모니터링 지표에서 수정할 항목이나 빠진 항목은 무엇인지, 알람 빈도가 너무 높거나 낮지 않은지도 살펴봐야 해요.
장애 대응 방식에 대한 회고도 진행합니다. 다른 방법을 선택했다면 좀 더 빨리 해결할 수 있지 않았을지 논의하는 단계예요. 회고를 바탕으로 개선해야 할 부분이 있다면 고쳐야 합니다. 개선하지 않는 시스템은 죽은 시스템에 가까워요. 그 상태로 멈춰 있으면 똑같은 장애를 끝없이 처리해야 하잖아요.
예전에 B 회사에서 근무할 때 서버가 죽으면 사람이 해당 서버 주소를 다른 서버 주소로 직접 치환해야 했어요. 사람이 해야 하는 일이다 보니 손에 전화기를 들고 잔 적도 수두룩합니다. 계속 알람이 오니까 잠을 못 자겠더라고요. 그래서 이 부분을 자동화했습니다. 1분마다 서버 상태를 체크해서 3번 이상 연속으로 응답하지 않으면 서버 주소를 자동으로 교체하도록 했어요. 아침에 일어났는데 서버가 죽었다면 몇 시에 서버가 죽어서 자동으로 교체됐다고 알리기만 하면 되죠. 귀찮거나 시간이 없어서 못 하는 것들을 장애 회고에서 계속 찾아내야 해요. 개선 과정에서 자동화할 수 있다면 하는 게 좋고요.
이 모든 단계를
계속 모니터링합니다
장애 보고서를 쓰고 장애 회고도 했는데 같은 실수를 반복하면 안 되겠죠? 이 모든 과정을 잘 개선해나가는지도 모니터링해야 합니다. 찾아보니 라인에서 잘하고 있더라고요. 장애 대응 레퍼런스는 다른 기업들의 기술 블로그를 살펴보셔도 좋습니다.
예상할 수 있는
장애는 연습해보세요
저도 장애를 대비하려고 연습해본 적은 없습니다. 작은 회사에서는 쉽지 않은 일이거든요. 넷플릭스 같은 경우는 ‘카오스 몽키(Chaos Monkey)’, 서비스를 의도적으로 죽이는 테스트를 진행합니다. 우리나라에서는 진행하기 어렵죠.
보통은 개발망 외에 스테이지망(베타망)을 하나씩 더 보유하고 있으니 베타에서 테스트를 진행하실 텐데요. 베타에서 장애 상황을 만들어 보세요. 실제 대응 능력을 높이는 데 도움이 될 겁니다. 예를 들면 1명이 의도적으로 DB를 끄거나, 서버 몇 개를 지우는 거예요. 그다음 베타에서 어떻게 대응하는지 보는 거죠. 무엇이든 배운 다음 시뮬레이션하고 리뷰하는 게 큰 도움이 되니까요.
우리는 인지할 수 있는 장애만 대응할 수 있습니다. 내가 경험해보지 못한 장애는 만들어낼 수 없거든요. 몸소 겪으면서 발전시켜나가는 게 중요합니다.
장애가 발생하지 않는 서비스는
세상에 없습니다
구글, 아마존도 장애가 발생해요. 장애는 막는 게 아닙니다. 처음부터 완벽하게 대응할 수 없어요. 발생할 때마다 맞춰서 대응해야 합니다. 인지할 수 있는 장애는 미리 준비하되 인지할 수 없는 장애를 찾기 위해 문제가 될 만한 부분을 지켜보세요.
겁먹지 마세요. 모니터링, 장애 처리 매뉴얼, 장애 회고 등은 완벽보다 일단 시작하는 게 중요합니다. 장애 대응부터 회고까지 이어지는 프로세스를 잘 만들어두면 개발 리소스를 아끼는 데 많은 도움이 될 거예요. 응원합니다.
Edit Sunny Design Lily
