[keyword] 5장 - 안정성 패턴

[kth990303]

주제

'5장 - 안정성 패턴'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

16

---

@caffeine-library/readers-release-everything

[kth990303]

가능한 한 사람들이 운영 시스템에 가까이 가지 못하게 하는 것이 가장 좋다. (p.159)

• 예를 들어, 배포 시마다 사람이 직접 배포 job 작동 순서를 생각하여 돌려야 한다면 휴먼 에러가 발생할 수 있습니다. 파이프라인 자동화 과정이 존재한다면, 배포 시작 버튼만으로 휴먼 에러를 최소화하고 편리하게 할 수 있을 듯합니다. 이렇게 휴먼에러가 발생할 수 있고 비교적 복잡한 부분의 운영적인 면에서는 확실히 사람의 손을 최소화하는 것이 중요하다 생각합니다.
• 다만, 모든 부분을 자동화시키는 것보다는 일부 중요한 부분은 사람의 크로스체크를 필요로 하는 듯하다고 느꼈습니다.

---

파일 시스템이 가득 차자마자 이 조악한 예외 처리기는 미쳐버려서 계속 증가하는 예외 스택을 기록하려고 했다. 여러 개의 스레드가 자신의 헛된 예외를 기록하려 했기 때문에 이 애플리케이션 서버는 잠시 동안이나마 전체 CPU 8개를 사용할 수 있었다. 피보나치 수열처럼 일정 비율로 늘어나는 예외는 모든 가용한 메모리를 빠르게 소모했다. 이는 곧 비정상 종료로 이어졌다.(p.162)

• 로그의 단점 및 로그 저장 위치 및 설계 관리의 중요성이라 생각되는 사례였습니다. 실제로 사이드프로젝트에서는 로그가 이만큼 쌓이지 않고, 실무에서는 로그 관리포인트가 잘 운영되고 있기 때문에 이러한 경험을 해본적이 없어 인상깊어 키워드로 남겨보았습니다.

---

코드가 '200 OK', '401 인증 필요', '302 임시 이동'이 아닌 경우 클라이언트는 아마도 응답을 치명적인 오류로 처리할 것이다. 많은 클라이언트가 다른 200 계열의 코드를 오류로 취급하기도 한다.(p.172)

• 이 부분은 궁금해서 키워드로 들고와봤습니다. 실제로 200, 401, 302 를 제외하곤 오류로 처리하는 경우가 많나요? 특히 200 제외한 201, 204 등의 status code를 오류로 취급하는 경우가 많은지 궁금해요.

[JasonYoo1995]

서론

• 안정성 패턴을 적용한 숫자가 클수록 좋다기 보단 복구 지향(recovery-oriented) 의식을 길러서 시기 적절하게 안정성 패턴을 적용해 피해를 줄이는 것에 초점

5.1 시간 제한

• 전선이 끊거지거나 자연 재해가 발생하는 등 우리가 통제할 수 없는 네트워크 이슈는 언제나 발생할 수 있다
• 이로 인해 오지 않을 응답을 끝없이 기다려서는 안 된다
• 적절한 시간 제한은 결함을 격리하여 다른 곳으로 전파되지 않게 한다
• 똑같은 API에 대하여 ‘시간 제한을 두는 함수’와 ‘영원히 블록될 수 있는 함수’를 둘 다 제공할 수 있는데 전자는 꼭 제공해야 하며, 전자를 제공하지 않는 라이브러리는 조심해야 한다
• 모든 API에 시간 제한 관련 코드를 작성하면 코드 복잡성이 높아지므로 일반화된 게이트웨이(generic gateway)에서 공통 사항을 처리하는 방법도 있다
  • Ex: 아마존 API 게이트웨이
• 콜백 또는 반응형 프로그래밍 방식을 사용하는 언어 런타임을 사용하면 더 쉽게 시간 제한 지정 가능
• 재시도
  • 시간 제한은 종종 재시도와 함께 쓰인다
  • WAN 패킷 누락 등의 케이스는 재시도로 실패를 극복할 수 있지만 대부분의 경우 즉각적인 재시도는 또 다시 실패할 가능성이 높다
• 대기열(queue)의 저장 후 전달(store-and-forward) 방식이 대안이 될 수도 있다 (Ex: 메일 서버)
• 시간 제한은 회로 차단기와 시너지 효과를 낸다 (5.2 회로 차단기 참고)
• 시간 제한 패턴과 빠른 실패 패턴은 동전의 양면과 같다 (5.5 빠른 실패 참고)

5.2 회로 차단기

• 과전류를 방지하는 ‘퓨즈’와 유사
• Closed 상태 : 호출 진행
  • 실패 시 실패 이력 기록
• Open 상태 : 호출 차단
  • 실패 횟수 또는 실패 빈도가 임곗값을 초과하면 호출 차단
  • Open 상태에서 요청 수신 시
    • 즉시 실패 응답
    • 대체(fallback) 응답
      • 마지막 정상 응답 값 응답
      • 캐시된 값 응답
      • 기타 사전에 지정된 값 응답
      • 보조 서비스를 대신 호출하여 응답
  • Open 상태에서 어떤 전략을 취할지에 대해서는 시스템의 이해관계자를 꼭 참여 시켜 논의해야 함
    • Ex : 온라인 상거래 시스템에서 상품 재고를 확인할 수 없는 경우 주문을 수락해야 할까?
    • Ex : 고객의 신용 카드 또는 배송 주소를 확인할 수 없는 경우에는 어떻게 해야 할까?
• Half-open 상태 : 일정 시간 후 호출 재시도
  • 호출 성공 시 Closed 상태로 전환
  • 호출 실패 시 Open 상태로 전환
• 오류 유형에 따라 다르게 반응 가능
  • Ex: ’연결 거부‘ 오류에는 높은 임곗값을, ’원격 시스템 호출 시간 초과‘ 오류에 대해서는 낮은 임곗값을 줌
• 회로 차단기의 상태 변화는 항상 로그로 남아서 모니터링 가능해야 한다
  • 시간 경과에 따른 차트를 그리면 유용한 자료가 될 수 있다
  • 통신량과 응답 시간 측정값을 수집하기 좋다
  • 수동으로 회로 차단기를 움직이는 방법이 있으면 좋다
• 회로 차단기는 같은 서버 내 스레드 간에는 공유되지만 다른 서버끼리는 공유되지 않는다 (서버마다 회로의 상태가 독립적으로 존재한다)

5.3 격벽

• 격벽이라는 용어의 유래

  • 선박의 일부가 침수됐을 때, 격벽(bulkhead)의 해치를 닫아 다른 구획으로 물이 넘어가지 못하게 하여 피해를 억제함

• 물리적으로 독립된 두 서버는 비정상 종료가 전파되지 않음

• 가상화된 두 서버는 같은 물리 기기에서 실행될 수 있으므로, 비정상 종료가 전파될 수 있음

• 미션 크리티컬 서비스의 격벽 예시 (독립적인 서버 팜으로 분리)

  • 고객 체크인용으로 별도의 전용 서버 운영 → 메인 서버 팜의 과부하로 요금 조회는 못해도, 전용 서버 팜을 통해 체크인은 가능

• Foo로 인해 Baz에 결함이 발생하면 Bar도 영향을 받음 → Foo 전용 Baz와 Bar 전용 Baz로 분리하면 결함이 전파되지 않음 (단, 두 Baz가 공통 의존하는 DB에서는 교착 상태 발생 가능하다는 한계 존재)

  

• 자연스러운 경계를 식별하려면, 아래 2가지 요소를 동시에 고려

  1. 기능 손실이 사업에 미치는 금전적 영향
  2. 기능 손실이 시스템에 미치는 기술적 영향

• 소프트웨어 정의(software-defined) 부하 분산기를 사용하면 영구적인 격벽이 아닌, 동적인 격벽을 생성할 수 있음

• 더 작은 규모에서의 격벽

  • 프로세스와 CPU 간의 바인딩에서 격벽
  • 전용 스레드 그룹 분할
    • Ex: 고객 전용 스레드 풀과 관리자 전용 스레드 풀을 분리 → 작동 중단 상태에서도 관리자가 사후 분석 및 처리 목적으로 스레드 사용 가능

5.4 정상 상태

• 사람이 수동으로 개입하기 위해 운영 시스템에 로그인 하는 경우
  • DB 데이터 삭제, 파일 시스템의 로그 파일 정리, 메모리의 캐시 제거 등
  • 이러한 관리를 하지 않으면, 시스템이 느려지거나 오류가 발생하거나 멈출 수 있다
• 정상 상태(steady state) 패턴 : 시간이 지나도 변하지 않고 안정된 상태를 유지하는 패턴
  • 시스템은 사람의 개입 없이 적어도 1번의 Release Cycle 동안 운영될 수 있어야 한다
• 사람이 수동으로 디스크 동기화 명령어를 입력 하다가 오타로 인해 OS를 통째로 소멸시킨 사례 언급 → 사람은 가능한 한 운영 시스템에 가까이 가지 못하게 하는 것이 좋다

5.4.1 데이터 정리

• 애플리케이션 출시 후 시간이 지나면서, DB의 시간당 입출력 처리량이 증가하고 지연 현상 증가할 수 있다
• 데이터 정리(data purging)를 통해 이러한 현상을 해결할 수 있다
• 불필요한 데이터는 제거하고, 제거해서는 안 되는 데이터는 남기도록 잘 구분해야 한다

5.4.2 로그 파일

• 로그 파일이 점점 늘어나 시스템을 가득 채우면, 오류가 발생한다
• 해결책
  • 로그 순환 : 크기가 일정 수준 이상 커지면 로그 파일을 백업하고, 다시 빈 상태에서 시작
  • 규제 준수를 위해 로그를 보관해야 할 경우 운영 서버 외부에 보관 (Logstash 같은 중앙 집중식 로그 서버 등)

5.4.3 메모리 전용 캐시

• 서버 내 메모리에 캐싱하는 경우, 메모리 부족 초래 → 캐시 무효화 필요
  • 캐시 크기 제한
  • 일정 주기로 캐시 제거
  • LRU 또는 working set 알고리즘 사용

5.5 빠른 실패

• 자원 사용 불가 상태를 미리 파악할 수 있다면, 즉시 거부 응답을 주는 것이 좋다
  • ex: 부하 분산기가 요청을 받았는데 가용한 서버가 없다면 즉시 거부

5.6 파손 방치

• 프로그램이 가장 깨끗할 때는 시작 직후이다
• 재시작하지 않아도 오랫 동안 유지되는 시스템이 가장 이상적이지만 그것이 어려운 상황에서 시스템이 불안정할 때는 재시작(=파손)하는 것도 하나의 방편이다.

5.6.1 크기 제한

• 파손에는 경계가 있어야 한다. 파손의 범위를 격리 시켜야 한다
• 행위자 모델(actor model) 기반으로 파손 시킬 수 있다
• 마이크로서비스 아키텍처에서는 서비스의 전체 인스턴스가 적절한 파손 경계이다

5.6.2 교체 속도

• 재시작 속도가 빨라야 한다. 느리면 재시작하지 않는 것이 나을 수 있다
  • ex: 컨테이너나 프로세스의 재시작 시간은 ms 단위 → 재시작해도 괜찮다
  • ex: 가상 머신 재시작은 몇 분 단위 → 재시작하면 서비스에 영향이 크므로 가상 머신 내 프로세스만 재시작하는 것이 낫다

5.6.3 감독

• 재시작을 계속 반복한다면, 죽이는 편이 나을 수 있다
• 행위자 모델에 따라, 감독이 자식의 재시작을 감시하고 자식이 재시작을 너무 높은 밀도로 반복하면 감독과 자식들을 죽여서 전체 시스템이 위험에 빠지는 것을 방지할 수 있다

5.6.4 재통합

• 시스템은 재시작한 인스턴스에 대한 호출을 재개해야 하므로 호출을 재개하기 위한 회로 차단기가 필요하다 (재통합)

5.7 핸드셰이킹

• 핸드셰이킹의 본질 : 자신에게 들어오는 부하를 조절하여 스스로를 보호하는 것
• 저수준 프로토콜과 달리 HTTP 프로토콜는 핸드셰이킹을 하기에 좋지 않다
  • ex: 호출처에서 HTTP 응답 에러 코드별로 핸들링을 천차만별로 하기 때문
• 그럼에도 불구하고, 애플리케이션 수준에서 핸드셰이킹을 구현할 수 있는 방법
  • ex: 서버가 과부하에 걸리면 부하 분산기에게 바쁘다는 응답을 보내고 부하 분산기는 해당 서버에 추가로 작업을 보내지 않는다

5.8 테스트 하네스

• 테스트 하네스 : 다양한 유형의 비정상 작동을 모방하는 것으로, 분리된 서버에서 구성된다
• Mock 객체와 테스트 하네스의 차이점
  • Mock 객체는 정의된 인터페이스/스펙을 준수해야 하지만 테스트 하네스는 그럴 필요가 없다 (네트워크 오류, 프로토콜 오류, 애플리케이션 오류 등을 모두 일으킬 수 있다)
  • Mock 객체는 같은 서버 내에서 구성되지만 테스트 하네스는 분리된 서버에서 구성되고, 원격 호출을 통해 통신한다
• 팁 : 포트별로 서로 다른 동작을 구현하면 테스트하기 편리하다
• 원격 호출 시에는 아래와 같은 실패에 취약하며 테스트 하네스를 아래와 같은 상황들을 재현할 수 있다
  • 거부된다
  • 시간 초과 전까지 수신 대기열에서 대기한다
  • 원격 종단이 SYN/ACK로 응답하고 나서 아무런 데이터도 보내지 않는다
  • 원격 종단이 아무 것도 보내지 않고 RESET 패킷만 보낸다
  • 원격 종단은 수신 윈도가 가득 찼다고 알리고서 데이터를 비우지 않는다
  • 연결은 맺어지지만 원격 종단이 데이터를 한 바이트도 보내지 않는다
  • 연결은 맺어지지만 패킷이 손실되어 재전송으로 인한 지연이 발생한다
  • 연결은 맺어지지만 원격 종단에서 패킷을 수신했다는 ACK 신호를 보내지 않아 끝없이 재전송된다
  • (HTTP인 경우) 서비스는 요청을 수락하고 응답 헤더를 보내지만 응답 본문을 보내지 않는다
  • 서비스가 30초마다 1바이트씩 띄엄띄엄 응답을 보낸다
  • 서비스가 예상했던 XML 대신 HTML을 응답으로 보낸다
  • 서비스가 킬로바이트 정도를 예상했는데 메가바이트의 데이터를 보낸다
  • 서비스가 모든 인증 자격 증명을 거부한다

5.9 결합 분리 미들웨어

• 동기식 미들웨어
  • 강하게 결합된 미들웨어
  • 종단 간에 같은 시간에 처리
  • ex: 프로세스 내 메서드 호출, 프로세스 간 통신, HTTP 통신 등
  • 장점 : 논리적 단순성 (설계 난이도가 낮음)
  • 단점 : 연계 장애 발생 가능
• 비동기식 미들웨어
  • 결합이 분리된 미들웨어
  • 종단 간에 다른 시간에 처리
  • ex: MQ 등
  • 단점 : 비동기 절차 설계의 난이도가 높음
  • 장점 : 연계 장애 미발생 (종단 간 결함이 분리됨)
• 동기식 아키텍처와 비동기식 아키텍처 간에 전환 비용이 많이 들거나 전환 불가능하므로 설계 초기부터 아키텍처를 잘 선정해야 함

5.10 부하 제한

• 유저의 요청이 기하급수적으로 증가 시 인프라로 수평 확장하는 것만으로는 한계가 있다 → 서버는 들어오는 부하를 줄이는 능력을 갖춰야 한다
• 부하를 줄여야 하는 시점
  • 요청 처리 속도가 SLA 보다 오래 걸리기 시작할 때
• 부하를 줄이는 방법
  • 인스턴스가 503을 응답하면 부하 분산기가 해당 인스턴스에 요청을 잠시 할당하지 않도록 함
  • 초과된 부하에 대해서는 빠른 실패로 응답함

5.11 배압 생성

• 대기열의 종류
  • 소켓의 수신 대기열
  • OS의 실행 대기열
  • DB의 입출력 대기열
• 대기열 길이 제한의 필요성
  • 대기열이 너무 길면 오래 방치되어, 느린 응답의 원인이 됨
  • 대기열도 메모리로 관리되므로, 메모리 차지 공간에 제한 필요
• 대기열 초과 시 처리 방법
  1. 대기열 내 항목을 제거
  2. 대기열 삽입 없이 항목을 즉시 거부
  3. 대기열에 공간이 생길 때까지, 대기열 삽입 작업을 블록 = 배압(backpressure)
     • 동기식 호출이라면 호출처의 요청 스레드가 블록 되면서 요청 속도가 늦춰지는 효과 발생
     • 비동기식 호출과 비동기식 프로그래밍에서 가장 효과가 좋다

5.12 조속기

• 사람이 못하는 일은 자동화 도구가 처리하게 하고 자동화 도구의 판단 착오 가능성이 높은 영역에 대해서는 조속기를 도입하여 사람이 개입할 시간을 확보하라 (조속기 : 원동기에서, 하중의 증감에 따라 회전 속도를 일정하게 조정하는 기계)
• 조속기의 예시
  • ex 1) 4.10의 레딧 사례에서 한 번에 일정 비율의 인스턴스만 종료할 수 있는 로직을 Autoscaler에 추가한다
  • ex 2) 인스턴스 확장이 일정 개수 이상이 되면, 확장 속도를 줄인다
• 조속기 로직 가이드
  • 사람이 개입할 수 있는 속도로 저항을 걸어라
  • 안전이 위협되는 영역일수록 저항을 크게 걸어라

[binchoo]

5.4 정상 상태

5.4.1 데이터 정리

• 데이터가 차는 속도 보다 빠르게 데이터를 비워야 하지만, 뒷전으로 밀리는 경향
• 데이터 증가 증상
  1. 시간 당 입출력 처리량(Throughput)이 꾸준히 증가
  2. 특정 부하에서 지연 증가
• 데이터 정리의 까다로움
  • RDB의 참조 무결성 제약
  • 데이터를 지워도 시스템이 영향이 없는지 테스트 필요
  • ORM에서 없는 데이터를 참조하는 상태일 수 있음
  • 문서 DB라면 없앤 데이터를 참조 중인지 확인조차 어려움

5.4.2 로그 파일

• 일반적으로 가치 없게 느껴짐, 충분히 모여야 의미가 있음
• 로그가 파일 시스템을 잠식하면 부정적인 영향
  • 루트 영역 제외한 90~95% 수준을 차지했을 경우
• 대응 방안
  • 어플리케이션과 별도 데이터 저장소 사용
  • 파일 시스템을 이용하지 않기
  • n분 주기로 로그 파일 순환(logrotate)시켜 언젠가는 꼭 정리되도록 하기
• 규정 준수
  • 대다수 규정 준수 체계는 수년간 로그를 보관하도록 요구하므로, 클라우드 같이 오래 유지할 수 없는 기기에서는 로그를 빠르게 빼와서 중앙 저장소에 저장하는 것이 좋다

5.4.3 메모리 캐시

• 캐시 적재 후 방치하는 등, 잘못된 사용은 메모리 누수를 야기함
  • 사용량 제한이나 주기적인 정리 필요

5.5 빠른 실패

악영향도: 무응답 < 느린 성공 응답 < 느린 실패 응답

• 쓸모없는 결과를 위해 자원을 허비함
• 시스템 실패가 예측된다면, 곧 바로 실패 처리하기
  • "자원을 사용할 수 없다면 바로 실패하기" vs. "대기 큐에 넣고 자원을 사용할 수 있으리라 기다리기"
  • 사용자가 여러 차례 재시도 하지 않도록 시스템 실패라고 알려 주는 것이 좋음
• 입력 유효성을 검사해 빠르게 실패 처리

5.6 파손 방치

• Let it crash 철학
  • 컴포넌트 수준 안정성을 포기하면, 시스템 안정성이 향상된다?
  • 오류가 발생하여 "더럽고 신뢰할 수 없는 상태"인 시스템을, "초기의 깨끗한 상태"로 되돌리겠다는 것
  • 껐다 켜라...

5.6.1 크기 제한

• 너무 큰 범위를 껐다 켜지 말고, 특정 구성 요소만 격리해야 한다
• 행위자 모델에서 각 행위자가 기준이 될 수 있음
• MSA에서 서비스용 인스턴스 풀이 기준이 될 수 있음

5.6.2 교체 속도

• 빠르게 재시작 해야함
  • 재시작이 길어 손실로 이어질 수 있다
  • 행위자 파괴, 컨테이너 파괴, 프로세스 파괴
• 가상 머신 파괴는 좋은 선택이 아닐 수 있음

5.6.3 감독

• 파손시킨 뒤 새 컴포넌트를 실행할 방법이 필요
• 감독 트리
  • 감독자가 모든 자식을 제어함
  • 감독자가 죽으면 런타임이 모든 자식을 종료. 감독자의 감독자에게 알림
  • 감독자가 근본 원인일 수 있으므로 파손 빈도에 따라 스스로를 종료시켜야 할 수도 있음
• PaaS (AWS ElasticBeanstalk, Auto Scaling group)는 판단 능력 없이 그저 재시작 시키므로 주의

5.6.4 재통합

• 재시작한 컴포넌트와 다시 통합되기 위해선, 회로 차단 기능 필요
  • 헬스 체크를 통과한 인스턴스를 풀에 포함시키기

5.7 핸드셰이킹

• 핸드셰이킹은 저수준 통신에서 많이 쓰이지만, 어플리케이션 수준에서는 흔치 않다. (비즈니스 준비 상태를 알리지 않는다)
• 호출하는 속도를 늦춰 달라고 주장할 수 있어야 한다
• HTTP로 핸드셰이킹 구현 어려움
  • 헬스 체크 응답을 503으로 내려서 부하 분산기 및 협력 웹 서버에게 알려주기
  • 503 조차 내려주기 버거운 상태라면?
  • 서버에서 부하분산기를 제어시켜 응답이 오지 못하게 하기
• 저수준의 핸드셰이킹 내재하기
  • 회로 차단기는 핸드셰이킹 없는 상태에서 임시방편으로 사용

5.8 테스트 하네스

실제 어플리케이션을 호출하면, 실제 어플리케이션이 일부러 생성할 수 있는 오류만 테스트할 수 있다. (p. 179)

• 분리된 서버에 테스트 하네스 구축을 고려하자.
• OSI 7계층 마다 발생할 수 있는 장애 모드를 고려해 테스트하자.

5.9 결합 분리 미들웨어

• 미들웨어는 시스템을 통합시키는 동시에 결합되지 않게 분리한다.
  • 결합이 약한 미들웨어: MQ, 대기열 기반 발행/구독 메시징
  • 결합이 강한 미들웨어: 원격 프로시저, XML-RPC
• 각 구조별 장단점이 있음
  • 동기식: 논리적으로 단순하나 연계된 장애가 발생함.
  • 비동기식: 예외 큐, 지연된 응답, 콜백 처리, 전환 비용 추가