# 안정성
안정성 원칙에서는 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행하는 역량에 대해 다룹니다. 여기에는 전체 수명 주기에 걸쳐 워크로드를 운영 및 테스트할 수 있는 기능이 포함됩니다. 이 백서는 AWS에서 안정적인 워크로드를 구현하기 위한 세부적인 모범 사례 지침을 제공합니다.
안정성 원칙에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현 방법에 대한 선제적인 가이드는 [안정성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp).
**Topics**
+ [설계 원칙](rel-dp.md)
+ [정의](rel-def.md)
+ [모범 사례](rel-bp.md)
+ [리소스](rel-resources.md)
# 설계 원칙
클라우드에는 5가지 신뢰성 설계 원칙이 있습니다.
+ **장애 자동 복구**: 워크로드의 KPI(핵심 성능 지표)를 모니터링하면 임계값이 위반될 때 자동화를 트리거할 수 있습니다. 이러한 KPI는 서비스 운영의 기술적 측면이 아닌 비즈니스 가치를 측정한 값이어야 합니다. KPI를 모니터링하면 장애 추적 및 자동 알림을 지원하고, 자동화된 복구 프로세스에 따라 장애 지점을 우회하거나 복구할 수 있습니다. 보다 정교한 자동화를 구현할 경우 장애가 발생하기 전에 예측하여 해결하는 것도 가능합니다.
+ **복구 절차 테스트**: 온프레미스 환경에서 테스트는 워크로드가 특정 시나리오에서 작동하는 것을 증명하기 위해 시행됩니다. 일반적으로 복구 전략을 검증하기 위해 테스트하지는 않습니다. 클라우드에서는 워크로드의 장애 과정을 테스트하고 복구 절차를 검증할 수 있습니다. 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애로 이어졌던 시나리오를 재현할 수 있습니다. 이 접근 방식은 장애 경로를 노출한 후 실제 장애 시나리오가 발생하기 전에 테스트하고 수정하여 위험을 줄일 수 있습니다.
+ **수평적 확장으로 워크로드 전체 가용성 증대**: 단일의 큰 리소스를 다수의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 축소합니다. 요청을 더 작은 리소스 여러 개로 분산시키면 단일 장애 지점을 회피할 수 있습니다.
+ **용량 추정 불필요**: 워크로드에 대한 수요가 해당 워크로드의 용량을 넘어서는 리소스 포화 상태는 온프레미스 워크로드에서 흔히 발생하는 장애의 원인입니다(서비스 거부 공격의 대상). 클라우드에서는 수요 및 워크로드 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화함으로써 프로비저닝 과다 또는 부족 현상 없이 최적의 수준으로 수요를 충족할 수 있습니다. 클라우드에도 제한은 있지만 할당량을 어느 정도 제어하고 관리하는 것이 가능합니다(Service Quotas 및 제약 조건 관리 참조).
+ **자동화 변경 사항 관리**: 인프라 변경은 자동화를 통해 수행되어야 합니다. 자동화 변경을 통하여 인프라를 관리해야 하며 이후에 이러한 변경을 추적하고 검토할 수 있습니다.
# 정의
클라우드의 안정성에는 4가지 모범 사례 영역이 있습니다.
+ **기반**
+ **워크로드 아키텍처**
+ **변경 관리**
+ **장애 관리**
안정성을 달성하려면 기반에서 시작해야 합니다. 이 기반은 서비스 할당량과 네트워크 토폴로지로 워크로드를 수용하는 환경을 의미합니다. 분산 시스템의 워크로드 아키텍처는 장애를 예방하고 완화하도록 설계되어야 합니다. 워크로드는 수요 또는 요구 사항의 변경을 처리해야 하며, 장애를 감지하고 자동으로 복구되도록 설계되어야 합니다.
# 모범 사례
**Topics**
+ [기반](rel-found.md)
+ [워크로드 아키텍처](rel-workload-arch.md)
+ [변경 사항 관리](rel-chg-mgmt.md)
+ [장애 관리](rel-failmgmt.md)
# 기반
기반에 관한 요구 사항은 그 범위가 단일 워크로드 또는 프로젝트 이상으로 확장됩니다. 시스템을 설계할 때는 먼저 안정성을 좌우하는 기반에 관한 요구 사항부터 갖춰야 합니다. 예를 들어, 데이터 센터의 네트워크 대역폭을 충분히 확보해야 합니다.
AWS에서는 이러한 기반에 관련된 요구 사항이 대부분 이미 통합되어 있거나 필요에 따라 적용할 수 있습니다. 클라우드는 거의 한계가 없도록 설계되었기 때문에 충분한 네트워킹 및 컴퓨팅 용량에 대한 요구 사항을 충족할 책임은 AWS에 있습니다. 따라서 고객은 리소스 크기와 할당을 필요에 따라 자유롭게 변경할 수 있습니다.
다음은 안정성 고려 사항에 중점을 둔 질문입니다. 안정성 관련 질문 및 모범 사례 목록은 [부록](a-reliability.md)을 참조하십시오.
| REL 1: 서비스 할당량과 제약 조건은 어떻게 관리합니까? |
| --- |
| 클라우드 기반 워크로드 아키텍처에는 서비스 할당량(서비스 한도라고도 함)이라는 것이 있습니다. 이러한 할당량은 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 API 작업에 대한 요청 속도를 제한하여 서비스를 침해로부터 보호하기 위해 존재합니다. 광섬유 케이블을 통해 비트를 전송할 수 있는 속도나 물리적 디스크의 스토리지 양과 같은 리소스 제약 조건도 있습니다. |
| REL 2: 네트워크 토폴로지는 어떻게 계획합니까? |
| --- |
| 워크로드는 여러 환경에 존재할 수 있습니다. 여기에는 다중 클라우드 환경(퍼블릭 액세스 및 프라이빗)과 기존 데이터 센터 인프라가 포함됩니다. 따라서 시스템 내부 및 시스템 간 연결, 퍼블릭 IP 주소 관리, 프라이빗 IP 주소 관리 및 도메인 이름 확인과 같은 네트워크 고려 사항을 계획에 포함해야 합니다. |
클라우드 기반 워크로드 아키텍처에는 서비스 할당량(서비스 한도라고도 함)이라는 것이 있습니다. 이러한 할당량은 실수로 필요한 것보다 많은 리소스를 프로비저닝하는 것을 방지하고 API 작업에 대한 요청 속도를 제한하여 서비스를 침해로부터 보호하기 위해 존재합니다. 워크로드는 여러 환경에 존재할 수 있습니다. 모든 워크로드 환경에 대해 이러한 할당량을 모니터링하고 관리해야 합니다. 여기에는 다중 클라우드 환경(퍼블릭 액세스 및 프라이빗)이 포함되며 기존 데이터 센터 인프라도 포함될 수 있습니다. 따라서 시스템 내부 및 시스템 간 연결, 퍼블릭 IP 주소 관리, 프라이빗 IP 주소 관리 및 도메인 이름 확인과 같은 네트워크 고려 사항을 계획에 포함해야 합니다.
# 워크로드 아키텍처
안정적인 워크로드는 소프트웨어와 인프라에 대한 사전 설계 결정에서 시작됩니다. 선택한 아키텍처는 모든 Well-Architected 원칙에서 워크로드 동작에 영향을 미칩니다. 안정성을 달성하려면 특정 패턴을 따라야 합니다.
AWS에서는 워크로드 개발자가 사용할 언어와 기술을 선택할 수 있습니다. AWS SDK는 AWS 서비스를 위한 언어별 API를 제공하여 코드 작성의 복잡성을 제거합니다. 이러한 SDK와 언어 선택을 통해 개발자는 여기에 나열된 안정성 모범 사례를 구현할 수 있습니다. 또한 개발자는 다음에서 Amazon의 소프트웨어 구축 및 운영 방법에 대해 자세히 알아볼 수 있습니다. [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp).
다음은 안정성 고려 사항에 중점을 둔 질문입니다.
| REL 3: 워크로드 서비스 아키텍처는 어떻게 설계합니까? |
| --- |
| SOA(서비스 지향 아키텍처) 또는 마이크로서비스 아키텍처를 사용하여 확장성과 안정성이 뛰어난 워크로드를 구축합니다. SOA(서비스 지향 아키텍처)는 서비스 인터페이스를 통해 소프트웨어 구성 요소를 재사용 가능하게 만드는 방식입니다. 마이크로서비스 아키텍처는 구성 요소를 더 작고 간단하게 만듭니다. |
| REL 4: 분산 시스템에서 장애 방지를 위한 상호 작용은 어떻게 설계합니까? |
| --- |
| 분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 여기에 나온 모범 사례는 장애를 방지하고 MTBF(평균 장애 간격)를 개선합니다. |
| REL 5: 분산 시스템에서 장애 완화 또는 극복을 위한 상호 작용은 어떻게 설계합니까? |
| --- |
| 분산 시스템에서 구성 요소(예: 서버 또는 서비스)는 통신 네트워크를 사용하여 상호 연결됩니다. 워크로드는 이러한 네트워크에서 데이터 손실 또는 지연 시간이 발생하더라도 안정적으로 작동해야 합니다. 분산 시스템의 구성 요소는 다른 구성 요소나 워크로드에 부정적인 영향을 미치지 않는 방식으로 작동해야 합니다. 이러한 모범 사례를 준수하면 워크로드가 스트레스 또는 장애를 견디고, 더 빠르게 이를 복구하며, 이러한 장애의 영향을 완화할 수 있습니다. 그러면 결과적으로 MTTR(평균 복구 시간)이 개선됩니다. |
# 변경 사항 관리
워크로드의 안정적인 운영을 위해서는 워크로드 또는 환경에 대한 변경을 예상하고 수용해야 합니다. 변경에는 수요 급증과 같이 워크로드에 적용되는 변경은 물론 기능 배포 및 보안 패치와 같은 워크로드 내부의 변경이 포함됩니다.
AWS를 사용하면 워크로드 동작을 모니터링하고 KPI에 대한 대응을 자동화할 수 있습니다. 예를 들어 워크로드의 사용자가 증가하면 워크로드 서버를 추가할 수 있습니다. 워크로드 변경 권한을 가진 사용자를 관리하고 이러한 변경 기록을 감사할 수 있습니다.
다음은 안정성 고려 사항에 중점을 둔 질문입니다.
| REL 6: 워크로드 리소스는 어떻게 모니터링합니까? |
| --- |
| 로그와 지표는 워크로드의 상태를 파악할 수 있는 유용한 도구입니다. 로그 및 지표를 모니터링하여 임계값을 초과하거나 중요한 이벤트가 발생하면 알림을 보내도록 워크로드를 구성할 수 있습니다. 모니터링을 수행하면 워크로드가 저성능 임계값을 초과하거나 장애가 발생할 때를 인식하고 이에 대응하여 자동으로 복구할 수 있습니다. |
| REL 7: 수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까? |
| --- |
| 확장 가능한 워크로드는 리소스를 자동으로 추가하거나 제거하여 특정 시기의 수요에 리소스 공급을 맞출 수 있는 탄력성을 제공합니다. |
| REL 8: 변경 사항은 어떻게 적용합니까? |
| --- |
| 새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하기가 어려워집니다. |
수요 변화에 따라 리소스를 자동으로 추가하거나 제거하도록 워크로드를 설계하면 안정성이 향상될 뿐 아니라 비즈니스 성공의 가능성도 높아집니다. 모니터링을 통해 KPI가 통상적인 수준을 벗어나면 담당 팀에 자동으로 알려 줍니다. 환경에 대한 변경 사항이 자동으로 로깅되므로 안정성에 영향을 미칠 가능성이 있는 작업을 감사하여 신속하게 파악할 수 있습니다. 변경 관리 제어를 통해 규칙을 적용함으로써 필요한 수준의 안정성을 확보할 수 있습니다.
# 장애 관리
통상적인 수준의 복잡한 시스템에는 장애가 발생하기 마련입니다. 안정성을 유지하려면 워크로드에서 장애가 발생할 때 이를 인식하고 가용성에 미치는 영향을 방지하는 조치를 취해야 합니다. 워크로드는 장애를 견디는 동시에 문제를 자동으로 복구할 수 있어야 합니다.
AWS에서는 자동화를 활용하여 모니터링 데이터에 대응합니다. 예를 들어, 특정 지표가 임계값을 넘어서면 자동화된 작업을 트리거하여 문제를 해결할 수 있습니다. 또한 운영 환경에서 장애가 발생한 리소스를 진단하여 수정하는 대신, 일단 새 리소스로 대체한 다음 운영 환경이 아닌 외부에서 장애 리소스를 분석해 볼 수도 있습니다. 클라우드에서는 저렴한 비용으로 전체 시스템의 임시 버전을 설정할 수 있기 때문에 전체 복구 프로세스를 자동으로 테스트하는 것이 가능합니다.
다음은 안정성 고려 사항에 중점을 둔 질문입니다.
| REL 9: 데이터는 어떻게 백업합니까? |
| --- |
| RTO(복구 시간 목표) 및 RPO(복구 시점 목표)에 대한 요구 사항을 충족하도록 데이터, 애플리케이션 및 구성을 백업합니다. |
| REL 10: 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까? |
| --- |
| 장애 격리 경계는 워크로드 내부 장애의 영향을 제한된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애가 발생하더라도 영향을 받지 않습니다. 다수의 장애 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있습니다. |
| REL 11: 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까? |
| --- |
| 고가용성 및 낮은 MTTR(평균 복구 시간)이 요구되는 워크로드는 복원력을 고려하여 설계해야 합니다. |
| REL 12: 안정성은 어떻게 테스트합니까? |
| --- |
| 프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다. |
| REL 13: DR(재해 복구)를 어떻게 계획합니까? |
| --- |
| DR 전략의 시작은 백업 및 이중화 워크로드 구성 요소를 갖추는 것입니다. [RTO 및 RPO는 워크로드 복원을 위한](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 목표입니다. 비즈니스 요구 사항에 따라 이러한 목표를 설정합니다. 워크로드 리소스 및 데이터의 위치와 기능을 고려하여 이러한 목표를 충족하는 전략을 구현합니다. 중단 가능성과 복구 비용도 워크로드에 대한 재해 복구 옵션을 갖추는 것의 비즈니스 가치를 파악하는 데 도움이 되는 주요 요소입니다. |
정기적으로 데이터를 백업하고 백업 파일을 테스트하여 논리적 오류와 물리적 오류를 모두 복구할 수 있는지 확인하십시오. 빈번한 워크로드 자동 테스트를 통해 장애 원인을 파악하고 복구 방식을 살펴보는 것이 장애 관리의 열쇠입니다 정기 일정에 따라 이 테스트를 수행하고, 중요한 워크로드 변경 이후에도 이 테스트가 트리거되는지 확인해야 합니다. Recovery Time Objective(RTO), Recovery Point Objective(RPO) 등의 KPI를 적극적으로 추적하여 장애 테스트 시나리오 등에서 워크로드의 복원력을 평가합니다. KPI를 추적하면 단일 장애 지점을 파악 및 완화하는 데 도움이 됩니다. 목표는 워크로드 복구 프로세스를 철저히 테스트함으로써 모든 데이터를 복구할 수 있으며 문제가 지속되더라도 고객에게 계속 서비스를 제공할 수 있다는 확신을 얻는 것입니다. 통상적인 프로덕션 프로세스와 마찬가지로 복구 프로세스도 제대로 실행해야 합니다.
# 리소스
안정성 관련 AWS 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하십시오.
## 설명서
+ [AWS 설명서](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp)
+ [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp)
+ [AWS Backup이란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp)
## 백서
+ [신뢰성 원칙: AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)
+ [AWS에서 마이크로서비스 구현](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)