[Well-Architected] Reliability Pillar

Reliability Pillar

이번 장에서는 Well-Architected Framework의 안정성 원칙(Reliability Pillar)에 대해서 알아본다.

---

안정성 원칙

• 안정성은 워크로드가 의도한 기능을 원하는 시점에 올바르고 일관되게 수행할 수 있는 능력이다.
• 전체 수명 주기 동안 워크로드를 작동 및 테스트하는 기능이 포함되며, 안정성을 달성하기 위해 복원력에 중점을 둔다.
• 복원력이란 인프라 또는 서비스 중단으로부터 복구하고, 수요에 맞춰 컴퓨팅 리소스를 동적으로 확보하고, 구성 오류나 일시적 네트워크 문제와 같은 중단 사태를 완화할 수 있는 워크로드의 기능이다.
• 안정성 원칙은 아래 영역에서 장애로부터 복구하고 요구를 충족할 수 있는 기능에 중점을 둔다.
  • 설정 및 교차 프로젝트 요구 사항을 포함하는 기본 요소
  • 분산 시스템 설계 시 선택할 수 있는 아키텍처 선택
  • 변경 사항 처리 방법
  • 장애 관리를 통한 장애 복구

안정성 설계 원칙

• 기존 환경에서의 안정성을 살벼보도록 한다.
  • 복구 절차를 거의 테스트하지 않음:
    • 우리는 상황이 정상적으로 작동하는지 종종 테스트했으며 기대치를 충족하는지를 확인한다.
    • 그러나 어떤 장애가 발생한 후 어떤 일이 일어나는지는 거의 테스트하지 않으므로, 복구 프로세스를 처음 테스트할 때는 실시간 안정성 결함의 한가운데에 있으며, 이것은 훌륭한 학습 경험이 아니다.
    • 이런 이유로 많은 시스템 장애를 겪게 된다. X가 실패한 다음 Y를 실패했으며, Y는 우리가 결코 테스트할 수 없었던 것이 되고 만다.
  • 장애로부터 수동 복구:
    • 장애가 발생하면 수동으로 해결한다. 많은 일이 발생하면 장애를 해결하는 절차를 적어 두는데, 이는 매우 수동식 프로세스다.
  • 여러 개의 단일 장애 발생 지점:
    • 기존의 아키텍처에는 많은 singleton이 있었으며, 이것은 단일 장애 발생지점이었다.
    • 일반적으로 여러 개의 단일 장애 발생 지점이 있었다.
  • 용량을 추측할 필요가 없음:
    • 얼마나 필요한지 추측해야 했으므로, 지나치다 싶을 정도로 주의를 기울여서 데이터 센터의 활용도 수치가 20%미만으로 떨어지게 되었다.
      이것은 “서버가 다운되지 않을까”라는 걱정 때문에 “오버프로비저닝 했음”을 의미한다.
• 클라우드 환경에서의 안정성을 살펴보도록 한다.
  • 장애로부터 자동 복구한다, 복구 절차를 테스트한다:
    • 기존 환경에서 직면한 제약이 제거되면, 클라우드에서 이러한 설계 원칙을 사용하여 폐기를 넘어 테스트하고 복구 절차가 자동적으로 성공적은지 확인할 수 있다.
  • 전체 워크로드 가용성을 높이도록 수평적으로 확장한다, 용량을 추정할 필요가 없다:
    • 단일 구성 요소에서의 장애에는 대개 형제 요소가 있기 때문에, 요청에 응답하는 여러 리소스가 있을 수 있다. 여러 리소스가 개입해서 서버의 부하를 줄일 수 있다.
  • 변경 관리를 자동화한다:
    • 활용도를 높이고 수요에 맞춰 확장하도록 리소스를 추가 및 제거할 수 있다.

---

기본 요구 사항

네트워크 토폴로지(Network Topology)

• 기본 요구 사항의 범위가 단일 워크로드 또는 프로젝트를 넘어선다.
• 시스템을 설계하기 전에 안정성에 영향을 미치는 기본 요구 사항을 마련해야 한다.
  예를 들어, 데이터 센터에 충분한 네트워크 대역폭을 갖추고 있어야 하지만 이러한 요구 사항은 때때로 무시된다. 이유는 단일 프로젝트의 범위를 벗어나기 때문이다.
• 이러한 무시는 안정적인 시스템을 제공할 수 있는 능력에 상당한 영향을 미칠 수 있다.
• 기존 환경에서 이러한 요구 사항은 종속성 때문에 긴 리드 타임을 발생시킬 수 있으므로 초기 계획 단계에 포함되어야 한다.

서비스 할당량 및 제약 조건

• 클라우드 기반 워크로드 아키텍처의 경우 서비스 할당량(서비스 한도)이 있다.
• 이러한 할당량은 서비스를 남용하지 않도록 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 API 연산에 대한 요청 속도를 제한하기 위해 존재한다.
• 예를 들어, 광섬유 케이블 아래로 비트를 푸시할 수 있는 속도 또는 물리적 디스크의 스토리지 양과 같은 리소스 제약도 있다.
• 워크로드 아키텍처에 대한 기본 할당량 및 할당량 증가 요청을 알고 있어야 한다.
• 추가로 어떤 리소스 제약(디스크 또는 네트워크)이 잠재적으로 영향을 미칠 수 있는지도 알아야 한다.

워크로드 아키텍처: 분산 시스템

• 서비스 지향 아키텍처(SOA) 또는 마이크로서비스 아키텍처(MSA)를 사용하여 확장성과 안정성이 뛰어난 워크로드를 구축한다.
• 서비스 지향 아키텍처(SOA)는 서비스 인터페이스를 통해 소프트웨어 구성요소를 재사용 가능하게 하는 사례이다.
• 마이크로 서비스 아키텍처(MSA)는 한 단계 더 나아가 구성 요소를 더 작고 단순하게 만든다.
• 분산 시스템은 통신 네트워크에 의존하여 서버 또는 서비스와 같은 구성 요소를 상호 연결한다.
• 네트워크에서의 데이터 손실 또는 지연 시간에도 불구하고 워크로드가 안정적으로 작동해야 한다.
• 분산 시스템의 구성 요소는 다른 구성 요소 또는 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 하며 이러한 모범 사례는 장애를 예방하고 MTBF(평균 장애 간격)을 개선한다.
• 장애를 예방하기 위한 아키텍처 선택에는 느슨하게 결합된 종속성 구현 및 모든 응답을 멱등성으로 만들기(각 요청은 정확히 한 번 완료됨)가 포함된다.
• 장애 발생 시 장애를 완화하기 위한 아키텍처 선택으로는 단계적 성능 저하 구현, 요청 조절, 빠른 실패 및 대기열 제한 등이 있다.

---

변경 관리

워크로드 모니터링

• 변경이 시스템에 어떻게 영향을 미치는지 인식하면 선제적으로 계획을 세울 수 있다.
• 모니터링을 통해 용량 문제 또는 SLA 위반으로 이어질 수 있는 추세를 신속하게 파악할 수 있다.
• 기존 환경에서는 변화 제어 프로세스가 수동으로 진행되는 경우가 많으며, 변화 주체 및 언제 변화가 발생했는지 효과적으로 제어하기 위해 감사를 통한 세밀한 조율이 필요하다.
• AWS를 사용하여 시스템의 동작을 모니터링하고 KPI에 대한 대응을 자동화할 수 있다. 예를 들어, 시스템의 사용자가 늘어남에 따라 서버를 추가할 수 있고, 시스템에 변화를 주고 해당 변화를 이력으로 감사하는 권한을 가진 사람을 통제할 수 있다.
• 또 다른 예시는 자동 조정 및 내결함성 솔루션이 있는 경우다. 이러한 경우라도 우리는 주요한 지표를 면밀히 모니터링하고 예외 발생 시 알림을 받아야 한다. 한밤 중에 일어나지 않고 자동 응답에 집중할 수 있다.
• 자동 응답은 비정상 서비스의 재시작을 자동으로 처리하므로 직접 수동으로 처리할 필요가 없다.

수요에 맞춰 자동 조정(Auto Scailing)

• 변경 관리에서 안정성 모범 사례의 예는 수요에 맞춰 자동 조정(Auto Scailing)을 사용하고 있는지 확인하는 것이다.
• 자동 조정의 몇 가지 이점을 입증하려면 AWS에서 실행되는 웹 애플리케이션을 고려한다. 이 애플리케이션을 사용하여 직원들이 회의에 사용하려는 회의실을 찾을 수 있다.
• 한 주의 시작과 끝에는 사용량이 최소 수준이며, 주 중반쯤에는 보다 많은 직원들이 회의 일정을 잡고 있으며, 따라서 애플리케이션에 대한 수요가 눈에 띄게 증가한다. 그래프를 전반적으로 확인해보면 일주일 동안 애플리케이션의 용량이 얼마나 사용되었는지 확인할 수 있다.
• 일반적으로 이러한 용량 변동을 계획하는 방법에는 두 가지가 있다.
  • 충분한 서버를 추가하여 애플리케이션이 항상 수요를 충족할 만큼의 충분한 용량이 확보되도록 하는 방법이다. 이러한 방식의 단점은 애플리케이션의 용량이 불필요한 날들도 있다는 점이다. 용량이 미사용으로 남아있다는 것은 결국 애플리케이션 실행 유지 비용의 상승을 의미한다.
  • 두 번째 옵션은 애플리케이션에 대한 평균 수요를 처리할 수 있는 충분한 용량이 확보되도록 하는 것이다. 이 옵션을 선택하면 가끔씩 사용되는 장비를 구매하지 않아도 되므로 비용이 절감된다. 하지만 애플리케이션에 대한 수요가 용량을 초과할 경우 부정적 고객 경험을 초래할 위험이 있다.
  • 세 번째 옵션은 필요 시에만 애플리케이션에 새 인스턴스를 추가하고 더 이상 필요 없을 때 이를 종료하는 것이다. 또한 자동 조정(Auto Scailing)은 Amazon EC2 인스턴스를 사용하므로 사용하는 인스턴스에 대해서만 비용을 지불하면 된다. 가장 효율적인 방법이라고 볼 수 있다.

배포(Deployment)

• 런북은 특정 결과를 달성하기 위해 사용되는 미리 정의된 단계이며, 런북을 사용하여 수동 또는 자동으로 표준 활동을 수행한다. 예를 들어, 워크로드 배포, 패치 적용 또는 DNS 수정 등의 활동이 포함된다.
• 테스트는 자동화된 배포의 일부로 실행된다. 성공 기준이 충족되지 않으면 파이프라인이 중단되거나 롤백된다.
• 변경 불가능한 인프라에는 블루-그린 배포와 같은 방법이 포함된다. 프로덕션 시스템에서는 현재 위치 업데이트가 일어나지 않고, 변경이 필요한 경우 아키텍처가 새 인프라에 구축되고 프로덕션에 배포된다.

---

장애 관리

구성 요소 장애 극복

• 시스템이 어느 정도 복잡해 지면 장애가 발생할 수 있다. 이러한 장애를 인지하고 대응하며 재발을 방지하는 방법을 찾아내는 것은 일반적으로 관심의 대상이다.
• AWS를 사용하면 모니터링 한 데이터에 자동으로 반응하는 기능을 활용할 수 있다는 장점이 있다. 예를 들어, 특정한 지표가 임계값을 초과하면 문제를 해결하기 위해 자동화된 조치를 트리거할 수 있다.
• 또한 프로덕션 환경의 일부인 결함이 있는 리소스를 진단하고 수정하기보다는 새로운 자원으로 교체하고 해당 결함 리소스를 대역 외에서 분석할 수 있다.
• 클라우드에 의해 낮은 가격으로 전체 시스템의 임시 버전을 유지할 수 있으므로 데이터를 정기적으로 백업해야 한다. 이후 자동화된 테스트를 사용하여 전체 복구 프로세스를 확인할 수 있다.

장애 격리

• 장애 격리 경계는 워크로드 내 장애의 영향을 제한된 수의 구성 요소로 제한하여 경계 외부의 구성 요소는 장애로 인한 영향을 받지 않도록 한다.
• 여러 개의 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있다.
• 워크로드를 여러 위치에 배포하여, 워크로드 데이터와 리소스를 여러 가용 영역 또는 필요한 경우 AWS 리전에 분산한다. 이러한 위치는 필요에 따라 다양할 수 있다.
• Shell(격벽) 아키텍처를 사용한다. 선박의 Shell과 마찬가지로, 이 패턴은 장애가 “요청/사용자”의 작은 하위 집합에 포함되어서 손상된 요청의 수가 제한되고 대부분 오류 없이 계속될 수 있도록 보장한다.
• 데이터의 격벽은 일반적으로 파티션 또는 샤드라고 하는 반면 서비스의 격벽은 셀이라고 한다.

백업 및 재해 복구

• 장애 관리에서 안정성 모범 사례의 예는 백업 및 재해 복구, DR, 전략을 수립하는 것이다. 백업 및 재해 복구는 안정성의 또 다른 핵심 요소이다.
• 코드로 구동되는 인프라에서 자동화 도구를 사용함으로써 자동 복구가 가능한 시나리오를 허용한다.
• 논리적 및 물리적 오류에서 복구할 수 있도록 정기적으로 데이터를 백업하고 백업 파일을 테스트해야 한다.
• 장애 관리의 핵심은 장애를 방지하고 복구를 거치며 시스템을 자주 자동 테스트하는 것이다. 이 작업은 중요한 시스템 변경 후에 트리거되며 정기적인 일정에 따라 일어나야 이상적이다.
• 복구 시간 목표(또는 RTO) 및 복구 시점 목표(또는 RPO)와 같은 핵심 성능 지표(또는 KPI)를 능동적으로 추적할 수 있다.
• 이는 특히 장애 테스트 시나리오에서 시스템의 적합성을 평가하고 단일 장애 지점을 식별 및 완화하는 데 도움이 된다.

안정성 테스트

• “플레이북”에서 조사 프로세스를 문서화하여 잘 이해할 수 없는 장애 시나리오에 대해 일관되고 즉각적인 응답을 활성화한다.
• “플레이북”은 장애 시나리오에 기여하는 요인을 식별하기 위해 수행되는 미리 정의된 단계이다.
• “기능 단위 테스트 및 통합 테스트” 외에도 “로드 테스트 및 성능 평가가 포함된 테스트” 제품군을 실행한다.
• “카오스 엔지니어링”을 사용한다. “카오스 엔지니어링”은 사전 프로덕션 및 프로덕션 환경에 정기적으로 장애를 주입하는 테스트를 의미한다.
• 워크로드가 장애에 어떻게 대응하는지 가설을 세운 다음, 그 가설을 테스트 결과와 비교하고 일치하지 않을 경우 반복한다.
• 프로덕션 테스트가 사용자에게 영향을 주지 않는지 확인한다.

---

핵심 사항

• 안정성은 워크로드가 의도한 기능을 원하는 시점에 올바르고 일관되게 수행할 수 있는 능력을 포함한다.
• 이를 달성하기 위해, 인프라 또는 서비스 중단으로부터 복구하고, 수요에 맞춰 컴퓨팅 리소스를 동적으로 확보하고, 구성 오류나 일시적 네트워크 문제와 같은 중단 사태를 완화할 수 있는 워크로드의 기능인 복원력에 중점을 둔다.
• 안정성 원칙의 핵심 사항은 아래와 같다.
  • 네트워크 토폴로지 계획과 서비스 할당량 및 제약 조건 관리를 포함하는 기본 요구 사항
  • 장애를 예방하고 완화하기 위한 설계 선택을 구현하기 위한 워크로드 아키텍처
  • 모니터링 및 KPI와 복원력 있는 배포 전략을 포함하는 변경 관리
  • 가용 영역 사용, 백업 및 재해 복구, 정기적인 안정성 테스트를 통한 구성 요소 장애 극복을 포함하는 장애 관리

---

참고 자료

• https://explore.skillbuilder.aws/learn/course/1793/play/48098/the-reliability-pillar-korean