🎤 이 아티클은 3회차 구름 세미나에서 레몬트리 CTO 강대명 님이 강의해주신 내용을 바탕으로 재구성되었습니다. 어느 날 갑자기 장애가 발생했다심장이 두근거리면서 머리가 새하얘지죠. 제발 내 코드에서 발생한 장애가 아니기만 바라게 되는데요. 일단 장애가 발생하면 서비스 제공자가 고객보다 먼저 인지하는 게 중요합니다. 가장 아찔한 상황은 장애가 발생했는데 모르고 있는 경우라고 생각해요. 대부분은 장애가 발생한 걸 고객 CS로 아실 텐데요, 좋지 않은 장애 인지 순서입니다. 고객이 먼저 장애를 인지하면 불만이 쌓이고, 불만이 쌓이면 서비스를 떠나게 됩니다. 그렇게 회사 매출이 줄어들면 여러분과 제 자리가 위험해지고요. 고객보다 먼저 장애를 인지했다면 버그를 수정해서 조용히 배포하면 됩니다. 전문 용어로 ‘잠수함 패치’라고 하는데요, 없었던 일로 만드는 거죠. 고객보다 먼저 장애를 인지하려면‘모니터링’이 중요해요. 우리 서비스가 문제없이 잘 돌아가고 있는지 서비스에 영향을 주는 모든 걸 확인해야 합니다. 6가지 중요 장애 대비 모니터링 요소위에서 언급한 항목 외에도 우리 서비스 도메인에 맞는 모니터링을 적절히 추가해야 합니다. 예를 들어 우리 서비스가 이커머스(e-commerce)라면 일정 시간대가 피크 타임이겠죠? 어느 날 피크 타임에 매출이 전혀 발생하지 않는데, 에러 메시지가 1개도 오지 않는다면 장애 상황일 수 있습니다. 매출이 발생하는지도 모니터링해야 하는 거죠. 제대로 모니터링하려면 어떤 상황이 장애인지부터 알아야 해요. 예전에 A 서비스를 운영할 때 주 사용자가 초등학생이었는데요. 3월 초에 트래픽을 봤는데 평소 트래픽의 4분의 1밖에 안 들어오는 거예요. ‘이건 장애다’ 싶어서 팀원들을 모았는데 알고 보니 3월 초가 개학 시즌이라 친구들하고 노느라 접속을 안 했더라고요. 정상적인 상황이었던 거죠. 모니터링 프로세스가 잘 갖춰져 있는 팀은 이상 수치에 대한 알람도 잘 되어 있습니다. 물론 알람은 중요도에 따라 잘 구분해야 해요. 하루에 알람이 999개씩 오는데 매번 큰 이슈가 아니라면 별거 아니라고 생각하고 넘기게 되거든요. 중요하지 않은 알람은 기준 수치를 높여서 덜 오게 만들고, 알람을 못 받았는데 장애가 발생했다면 기준 수치를 낮춰야겠죠? 모니터링 수치도 리팩토링이 필요합니다. 모니터링 지표는 일주일 전, 한 달 전, 1년 전 시점하고 비교해보는 게 좋아요. 이번 주 지표는 지난주나 한 달 전하고 비교해 보면 달라진 점이 확연히 보이거든요. 정보를 더 가시적으로 볼 수 있도록 그래프를 개선하는 것도 필요합니다. 그래프 모양만 보고 이벤트나 장애 시점을 찾기도 하거든요. 💡
모니터링 프로세스의 기본 만약 회사에 모니터링 시스템이 없다면 만들면 됩니다. 처음에는 간단하게 핑을 보내고 안 받으면 문자나 전화가 오게 하는 거죠. 저희 서비스는 1시간이나 2시간 단위로 에러 메시지가 모이면 가장 많이 발생한 에러를 순서대로 볼 수 있도록 만들어 놨습니다. 이런 식으로 만들어 두면 장애 원인을 파악하는 게 조금 더 수월하겠죠. 장애가 발생하면 |