GitHub, Slack, Salesforce 등 10개가 넘능 장애 부고를 읽고 정리한 서비스 장애의 7가지 교훈들의 포스트 번역:
downtimeproject.com/podcast/7-lessons-from-10-outages/
1. 순환 의존성의 덫
대부분 서비스 인프라는 끈끈하게 묶여있다. 문제는 장애 복구 툴 역시 장애를 겪고있는 인프라에 묶여있을 때 발생한다.
Slack 팀은 장애를 진단할 대시보드 역시 장애로 접근할 수 없었다. Monzo 팀은 인증 서버 장애로 인해 핫 픽스를 배포할 수 없는 황당한 상황에 빠졌었다. 정애를 염두하고 서비스 의존성을 검토해 봐야한다.
2. 자동화의 배신
인프라 관리의 자동화는 효율적인 운영을 위해 중요한 역활을 하지만, 서비스 장애시 상황을 악화시킬 때도 있다.
Slack의 경우 네트워크 장애로 서비스 트래픽이 줄자 자동화 스크립크가 모든 서버를 제거해 버려 장애 복구 시간이 배로 늘어났다. Github의 경우 1분동안의 네트워크 이슈가 있었고 가만히 냅두면 복구를 했었겠지만 자동화 스크립이 DB primary를 바꾸는 과정에 또 장애가 발생, 장애가 더 커졌다.
3a. 항상 디비가 문제다
많은 장애 원인은 DB였다. 실수로 드랍된 인덱스, 과부하로 이어진 수면 계정 처리 스크립트, 데이터를 뽑기위한 one-off 쿼리 등 생각보다 비싼 쿼리가 주는 부하를 DB가 버티지 못하고 쓰러지는 경우가 정말 많았다.
3b. 특히 간단한 DB setup (e.g. 1 MySQL server)이나 DB as a service를 사용하지 않고 직접 클러스터링을 운영할 경우 DB 장애 대응이 정말 어려워 진다. DB as a service의 비용은 운영 및 장애 대응 까지 포함한다는 걸 잊지말고 가능하면 사용 하는 편이 운영에는 유리하다.
3.c DB 장애에 대응하기 위한 DB restore operation은 정기적으로 테스트 하는 것이 정말 중요하다. GitLab의 경우 장애를 겪고나서야 backup script가 고장난걸 발견했고, GitHub은 backup을 갖고 있엇지만 restore하는데 10시간이 넘게 걸렸다.
4. 배포는 조금씩 천천히
서비스 안정화와 빠른 배포는 결국 맞바꿔야 한다. 대부분 서비스 장애는 변경된 코드나 환경 설정이 별다른 검증 없이 모든 프로덕션 서비스에 빠르게 배포될때 발생했다. Canary, gradual rollout등 개발 속도에 브레이크를 조금 거는 선택이 필요하다.
5. 장애 대응 플레이북
서비스 장애는 피해갈 수 없다. 서비스 장애 시뮬레이션을 하고 복구 우선순위를 미리 정하는 등 매뉴얼을 짜고, 장애시 panic mode/code red가 발동해 자동화를 정지시키는 인프라 투자는 (당연하게도) 더 좋은 장애 대응으로 이어진다.