Release 의 모든 것 (1~4장)

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

버그

버그는 반드시 발생한다. 그러나 가장 큰 문제는 한 시스템의 버그가 관련이 있는 다른 모든 시스템으로 전파될 수 있다는 사실이다.
버그를 예방할 방법을 찾는 것보단 더 나은 질문은 ‘한 시스템의 버그가 다른 시스템에 영향을 미치지 않게 하는 방법은 무엇인가?’ 이다.

안정성

대부분 안정성이 높은 설계와 그렇지 않은 설계에 들어가는 비용은 비슷하다.
트랜잭션 : 시스템이 처리하는 주상적인 작업 단위로, 어떤 시스템이 존재하는 이유.
시스템 : 완결적이면서 상호 의존적인 하드웨어, 어플리케이션, 서비스의 집합을 의미하며, 사용자의 트랜잭션을 처리하는 데 필요함.
안정성 : 시스템이 강건해서, 일시적인 충격, 영구적인 변형력, 구성 요소의 장애가 정상적인 처리를 방해하더라도 계속 트랜잭션 처리를 할 수 있는 능력.

수명 연장

시스템의 장수를 위협하는 주요 원인은 메모리 누수와 데이터 증가다.
테스트는 메모리가 충분히 누수될 만큼, 데이터가 충분히 증가하는 만큼 실행되지 않기에 그런 종료의 버그는 부하 테스트로도 잡기 어렵다.

장애 사슬

결함이 발생하면 균열이 생긴다. 결함은 오류가 되고, 오류는 장애를 일으키며 이렇게 균열이 확산된다.
결함 : 소프트웨어에 잘못된 내부 상태가 만들어지는 조건
오류 : 눈에 띄게 잘못된 작동
장애 : 시스템이 응답을 하지 않는 것

소켓 기반 프로토콜

많은 고수준 통합 프로토콜은 소켓 위에서 작동한다.
가장 단순한 장애 모드는 원격 시스템이 연결을 거부할 때 발생한다. 그러나, 서버가 요청을 읽고 응답하는데 오랜 시간이 걸려서 호출이 블록되거나, 제한 시간을 초과할 수 있다.
연결 거부는 빠른 장애여서 호출한 측에 돌아오는 데 수밀리초 밖에 걸리지 않지만 ack 누락 같은 느린 장애는 예외가 발생하기 전 수 분 동안 스레드를 블록시킨다.
일례로, TCP 기반 통신에서는 방화벽에서 1시간 이상 패킷이 미전송 된 경우 반대쪽 연결 정보를 삭제하지만, 연결된 쪽에서는 아직 서로가 유혀한 연결을 맺고 있다고 가정해서 데이터를 계속 보낼 수 있다.

통합 지점

통합 지점은 언젠가 어떤 식으로든 장애를 일으킬 것이므로 장애에 대비해야 한다.
다양한 네트워크 오류가 발생할 수 있음을 유념해라

연쇄 반응

서버가 8개인 팜에서 각 노드는 전체 부하의 12.5 % 를 처리한다. 서버 하나가 작동을 멈추면 각 노드는 총 부하의 14.3 % 를 처리한다.
이는 서버마다 처리하는 부하가 기존 대비 15 % 증가한 것으로, 다른 서버에서 장애의 원인의 될 수 있다. 즉, 첫 번째 서버에서 발생한 문제가 다른 서버에도 문제를 일으키는 것이다.

가용 메모리의 한계

웹 백엔드에서 모든 사용자가 세션을 갖는데, 메모리 기반 세션을 사용하면 세션은 사용자의 마지막 요청 이후에도 일정 기간 동안 메모리 내에서 유지된다.
이 문제를 해결하기 위해 다른 프로세스에 위탁해서 처리하게 할 수 있다. 멤케시를 사용하면 데이터를 힙 내부에 보관하는 대신 다른 프로세스로 옮길 수 있다.
레디스의 사용도 고려해보자.

닫힌 소켓

작업이 끝나서 닫힌 소켓도 문제가 될 수 있다.
어플리케이션 코드가 소켓을 닫으면 TIME_WAIT 상태로 변하며 이 기간은 TCP 가 지연 패킷으로부터 시스템을 보호하는 수단이다.
소켓을 너무 빨리 재사용하면, 정당한 데이터로 인정되는 지연 패킷이 새 연결의 중간에 끼어들 수 있다.

캐시 사용 주의

캐시는 성능 문제에 대한 강력한 대응책이 될 수 있지만 새로운 문제를 발생시킬 수도 있다.
캐시의 최대 메모리 사용량을 제한하지 않는다면, 결국 시스템이 사용할 메모리를 잠식하게 된다.
또한 캐시 적중률을 모니터링해서, 적중률이 낮은 캐시를 사용하는 것은 오히려 시스템 성능의 해가 될 수 있다.

라이브러리

라이브러리는 블록을 거는 스레드의 출처로 악명 높다. 안전한 라이브러리를 배우고 적용해라. 라이브러리가 장애에 취약하다면, 우리가 직접 요청 처리 스레드를 보호해야 한다.

공유 자원

안정성을 위태롭게 할 수 있는 또 다른 문제점은 공유 자원이다. 공유 자원이 다중화되고 비독점적이라면 자원을 추가해서 병목 현상을 줄일 수 있다.

도그 파일

어플리케이션이 한동한 실행된 후보다, 처음 시작할 때 데이터베이스의 일시적인 부하가 훨씬 더 높다.
도그 파일은 다음과 같은 경우에 발생할 수 있다.

• 코드를 업그레이드하고 재시작할 때와 같이 여러 서버를 부팅할 때
• 크론 작업이 자정(또는 정각)에 발동할 때
• 구성 관리 시스템이 변경 사항을 푸시할 때

응답 지언

응답 지연은 연계 장애를 유발한다. 웹 사이트의 경우, 응답 지연이 발상하면 더 많은 트래픽이 발생한다(사용자가 반복해서 새로 고침을 누르기 때문이다)

제한 없는 결과

데이터의 규모에 따라서, 단순한 select 문이 장애의 원인이 되기도 한다.
SQL 을 작성하는 경우, 항상 가져올 행 수를 제한하자.