[릴리즈의 모든 것] 3장. 시스템 안정화

스터디 메인 페이지

목차

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한대로 적어놓은 것으로, 책에 나오지 않는 내용입니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 Release의 모든 것(마이클 나이가드 지음) 책 입니다.

 

---

 

3장. 시스템 안정화

• 엔터프라이즈 소프트웨어는 냉소적이어야 한다. 나쁜 일이 일어날 것이라고 예상하고 그런 일이 일어나도 절대 놀라지 않는다. 자기 자신조차 믿지 않기 때문에 내부에 장벽을 세워 장애로부터 자신을 지키고, 다른 시스템과 지나치게 친밀해지는 것을 거부한다.
• 안정성이 부실하면 상당한 수익 손실이 발생한다. 또 신임을 잃는다. 홍보를 위한 수십억 원이 불량 하드 드라이브 때문에 몇 시간 만에 의미 없는 것이 될 수 있다. 

 

안정성 정의

• 트랜잭션은 시스템이 처리하는 추상적인 작업 단위다. 데이터베이스 트랜잭션과는 다르다. 작업 단위 하나에 많은 DB 트랜잭션이 포함될 수 있다. (예를들어 '주문 진행')
• 강건한 시스템은 일시적인 충격, 영구적인 변형력, 구성 요소의 장애가 정상적인 처리를 방해하더라도 계속 트랜잭션을 처리하는 시스템이다. 이것이 안정성이다.
  
  • 충격 : 극겹한 힘의 변화. 예를들어 유명 인사가 우리 사이트를 트위터에 올리는 경우
  • 변형력 : 장기간 가해지는 힘. 예를들어 신용 카드 처리 시스템의 용량이 모든 고객을 처리하기에 충분하지 않아서 응답이 느린 것

 

수명 연장

• 시스템의 장수를 위협하는 주요 원인은 메모리 누수와 데이터 증가다. 둘 다 테스트 중에는 잘 드러나지 않는다.
• 머피의 법칙에 따라 테스트하지 않은 일은 그것이 무엇이든 반드시 일어난다.
• 자체적으로 장기 안정성 테스트를 시행하자. 가능하다면 개발용 컴퓨터를 따로 두고 JMeter, 마라톤(Marathon), 그 밖의 부하 테스트 도구가 돌아가게 하자.
• 비용 때문에 완벽한 환경을 구성하도록 승인받기 어렵다면 주요 부분만 테스트하고 나머지는 제거하도록 하자. 테스트를 전혀 하지 않는 것 보다는 낫다.

 

장애 모드

• 장애 모드(failure mode) : 피해 결과를 포함하여 원래의 계기와 균열이 여타 시스템으로 번지는 방식
• 시스템에는 다양한 장애 모드가 있을 것이다. 일단 장애가 일어날 것이라는 사실을 수용하면 특정 장애에 반응하도록 시스템을 설계할 수 있다. 안전한 장애 모드를 만들어 피해를 억제하고 시스템의 다른 부분을 보호할 수 있다.
• 시스템의 필수기능을 결정하고 장애 모드를 구축해서 필수 기능에 균열이 번지지 않도록 막을 수 있다.

 

균열 확산 차단

• 2장의 항공사의 경우 장애 모드가 어떻게 적용되는지 봐보자.
• 자원 풀이 없을 때 자원을 요청한 스레드를 블록하도록 구성되었기 때문에 결국 모든 스레드가 정지된다. -> 자원이 소진되어도 연결을 더 생성하도록 구성될 수 있었다. 또는 일정 시간 동안만 블록되도록 구성될 수 있었다.
• 한 단계 위에서 보면, 호출 하나에서 발생한 문제가 다른 호스트에 있는 애플리케이션에 문제가 발생하도록 만들었다. -> 클라이언트 호출 시 제한 시간을 설정하도록 작성될 수 있었다.
• 좀 더 넓은 관점에서 보면 문제가 된 서버들은 하나 이상의 서비스 그룹으로 분할될 수 있다 (한 서비스 그룹에만 문제를 묶어둘 수 있도록).
• 더 관점을 넓혀 아키텍처 문제를 살펴보면, 요청 응답 메시지 큐를 사용하도록 만들어지지 않았다. 아키텍처가 강하게 결합될수록 코딩 오류가 전파될 가능성이 높아진다. 반대로 느슨하게 결합된 아키텍처는 완충기와 같은 역할을 하므로 오류의 영향을 감소시킨다.

 

장애 사슬

• 모든 시스템 장애는 사건이 사슬처럼 꼬리에 꼬리를 물고 연쇄적으로 일어난다.
• 연쇄적으로 일어나는 사건들을 정확히 설명하는 데 쓰이는 몇 가지 일반적인 용어들
  • 결함 : 소프트웨어에 잘못된 내부 상태가 만들어지는 조건.
  • 오류 : 눈에 띄게 잘못된 작동.
  • 장애 : 시스템이 응답을 하지 않는 것.
• 발생할 수 있는 모든 장애에 대비하는 방법은 모든 예상 결과를 보고 '이것이 잘못될 수 있는 모든 경우에는 어떤 것이 있는가?' 라고 질문하는 것이다.
  • 초기 연결을 맺지 못한다면?
  • 연결되는 데 10분이 걸린다면?
  • 연결되고 나서 끊어지면?
  • 연결은 되었지만 상대편에서 응답이 오지 않는다면?
  • 전송한 요청의 응답을 받는 데 2분이 걸린다면?
  • 만 개의 요청이 동시에 들어온다면?
  • 웜(worm) 같은 악성코드 때문에 네트워크가 끊겨 SQLException이 발생했는데, 애플리케이션이 오류 메시지를 로그에 남기려고 하니 디스크가 가득 찼다면?
• 위와 같은 나열은 잘못될 수 있는 모든 경우 중 극히 일부이다.
• 무턱대고 모든 가능성을 나열하는 것은 실용적이지 못하다. 완성에 10년이 넘게 걸릴 수도 있다.
• 우리가 아무리 결함을 처리하고 복원하더라도 예상하지 못한 일은 일어난다.
  • 결함은 결코 완벽히 방지할 수 없다.
  • 결함이 오류가 되지 않게 막아야 한다.