Release 의 모든 것 (5~6장)

Release 의 모든 것 (5~6장) 의 내용 중, 인상적이었던 부분을 발췌 및 요약합니다.

시간 제한

시간 제한은 응답이 오지 않을 것 같으면 기다림을 멈추는 간단한 작동 방식이다.
적절한 시간 제한은 결함을 격리하여 한 서비스나 장치세 생긴 문제가 다른 곳의 문제로 번지지 않게 한다. 플랫폼을 최대한 활용하면, 자질구레한 여러 세부 사항을 대신 처리해준다(아마존 API 게이트웨이)
콜백 또는 반응형 프로그래밍 방식을 사용하는 것도 고려해볼 수 있다.
작업을 대기열에 넣어두고 재시도하는 방식은 시스템을 견고하게 만든다.
시간 제한 패턴은 통합 지점 호출로 스레드가 블록되는 것을 방지한다.

회로 차단기

시스템이 정상이 아닐 때 호출을 방해하는 구성 요소로 위험한 작업을 제어하도록 하여 소프트웨어에도 회로 차단기를 적용할 수 있다.
회로 차단기는 개방, 폐쇄, 반개방 상태를 가진다. 혹은 개방되면 작업이 실패하는 대신에 대체 전략을 사용할 수 있다.
대체 전략으로 마지막 정상 응답이나 캐시된 값을 반환하도록 할 수 있다.

격벽

격벽은 피해 억제 원칙을 시행한다. 서로 다른 기능을 별도의 전용 스레드 그룹에 할당하여 단일 프로세스 내에서도 스레드를 분할할 수 있다.
예를 들어 요청 처리 스레드 풀 하나를 관리 전용으로 마련해두면, 서버의 모든 요청 처리 스레드가 작동 중단 상태가 되더라도 관리자 요청에 계속 응답할 수 있다.
공유 서비스 모델에서 특히 격벽을 고려하라

데이터 정리

정답은 없지만, 무결성 제약을 지키면서 꾸준히 운영해야 한다.

로그 파일

확인되지 않은 상태로 남겨진 개별 기기의 로그 파일은 위험하고, 해당 파일의 시스템을 가득 채울 것이다.
중앙 집중식 로그 서버의 활용을 고려해보자(Sentry, LogStash 등)

파손 방치

떄로는 구성 요소의 안정성을 포기하는 것이 시스템 수준의 안정성 형성을 위한 최선의 방법이다.
오류 복구가 신뢰할 수 없다면, 가능한 초기의 깨끗한 상태(프로그램의 시작 직후)로 돌아가야 한다.

• 구성 요소를 파기하고 시스템을 보호하라
• 신속히 재시작하고 재통합하라
• 독립적으로 파손되도록 구성 요소를 격리하라(회로 차단기를 사용해라)
• 모노리스를 파손하지 말라(무거운 런타임이나, 시작 시간이 긴 프로세스의 경우)

부하 제한

아무리 큰 인프라가 있어도 세상의 모든 사람과 장치를 지원할 수는 없다. 부하 제한 패턴을 사용하여 느린 응답을 피해야 한다.
부하 분산기를 충격 흡수 장치로 사용해서, HTTP 503 을 통해 개별 인스턴스에 여유를 줘라.

복구 지향 컴퓨팅

• 하드웨어와 소프트웨어 모두 장애는 불가피하다.
• 모델링과 분석은 절대 완벽할 수 없다.
• 시스템 장애의 주요 출처는 인간의 활동이다.