[번역] 서비스 장애로부터 얻은 7가지 교훈

크던 작던 피해갈 수 없는 서비스 장애. 이러한 서비스 장애의 여러 사례를 정리해 둔 글이 있는데, 몇 가지 배울 점들이 있어 간략하게 정리해 둡니다. 근데 7가지라면서 정작 큰 목차는 5개네

1. 순환 의존성 피하기

복구 플랫폼이 현재 플랫폼 등에 영향을 최대한 받지 않아야 함을 이야기합니다. 이를 테면, kube의 status를 보여주는 서비스를 Kube로 만들어 버리면, Kube가 뻗었을 때 정작 status를 확인할 수 없겠죠.

이에 관련하여 여러 에피소드들이 있지만, 개인적으로 굳이 멀리 안 가더라도 Windows의 작업 관리자가 대표적인 예로 있습니다. 실제로 대부분의 프로그램들이 의존하는 쉘이 고장나더라도 작업 관리자는 어떻게든 실행되는 모습을 종종 확인할 수 있습니다.

2. 자동화가 문제를 더 키울 수도 있다

과도한 자동화가 장애시 악영향을 미칠 수도 있습니다. Slack의 경우, 네트워크 장애 발생후 자동화된 스크립트가 Auto-scaling을 수행하여 운영 규모를 축소했다가, 이후 다시 네트워크 정상화 되었을 때 트래픽 감당을 하지 못하고 일시적인 장애가 발생했다고 합니다.

그런데 이게 아주 불합리한 경우는 아니라서, 문제 상황으로 보기에는 좀 애매하다고 생각되네요. 다만, 한 가지 공통점은 시스템 장애는 고려했어도 네트워크 장애시에 대한 대처가 미흡했다는 점입니다. 이렇게 구체화한다면, 어느 정도 공감가는 부분이 있는 듯.

3. 데이터베이스가 문제다

대부분의 장애는 DB에서 비롯된다는 건데, 이렇게 말하면 “이거 당연한 소리 아니야?” 라고 하겠죠? 구체화가 필요합니다.

3a. 실제 운영시 갑작스런 부하가 발생할 것을 염두에 둘 것

3b. DB 운영은 최대한 단순하게: SaaS나, 아니면 단순한 Monolithic 서버로 하자.

한 마디로 줄여서: 클러스터 구성까지 셀프로 했다가 고장나면 답도 없다라는 이야기입니다.

3c. 백업보다 복구를 신경쓸 것

DB Restore는 실제 할 일이 없다 보니까, 정작 필요할 때 고장나 있는 경우가 많다는 이야기입니다. 이 부분은 의외로 자주 겪게 되는 일이라 공감가는 바가 큽니다. 정기적인 e2e 테스트가 중요하다는 결론.

4. 배포는 천천히

구체적으로, Prod에 바로 돌리지 말고 — 그 전에 사내직원 테스트 해 보고(main 브랜치), 그 다음 Internal 테스트서버 디플로이도 해보고, 마지막으로 prod에 올리자는 이야기입니다.

가끔 Internal deployment 비용이 아깝다는 식으로 이야기하며 안 하는 경우를 종종 봤는데, 그러다 문제 터지면 답도 없습니다. 특히 마이그레이션 때 아주 잘 터짐

5. 실패 대응책 마련

간단히 말하면, 문제가 생기기 전에 미리 문제 대응 가이드를 준비해 두어야 한다는 이야기입니다.

사실 매 제품/기능 릴리즈마다 보통 내부적으로 하게 됩니다. 기능 설명, 디버깅 방법 등을 documentation 하는게 일련의 작업이라고 볼 수 있습니다. 좃소는 안 합니다

여기서는 Policies와 Knobs를 이야기하는데, Policies가 상황에 대한 대응 가이드입니다. 이를테면 어떤 서버가 내려갔을 시, 고객사에게 취해야 할 조치는 무엇이고, 엔지니어가 취해야 할 조치는 무엇이고(대충 DAG로), 등등. Knobs는 말 그대로 “노브”, 구체적으로는 “설정 가능한 파라미터”입니다. 문제가 발생하기 전에, 운영 측에서 대응할 수 있는 방법(기능)을 미리미리 만들어 두어야 한다는 이야기가 되겠습니다. 이를테면 “안전 모드”, “성능 단계 조정” 같은 거라던가…

참고

• 원문: 7 Lessons from 10 Outages
• 트위터: Daniel Lee씨의 글