안정성

안정성 원칙에는 인프라나 서비스의 시스템 장애를 복구하고, 컴퓨팅 리소스를 동적으로 확보하여 수요에 대응하거나, 구성 오류나 일시적 네트워크 문제와 같은 장애를 완화하는 시스템의 기능이 포함됩니다.이(가) 포함됩니다.

안정성 부문에서는 설계 원칙 개요, 모범 사례 및 질문 사항을 제공합니다. 구현 방법에 대한 선제적 가이드는 안정성 부문 백서에서 확인할 수 있습니다.

설계 원칙

클라우드에는 안정성에 대한 five개의 설계 원칙이 있습니다.

정의

클라우드에는 안정성에 대한 three개의 모범 사례 영역이 있습니다.

시스템 안정성을 얻기 위해서는 잘 계획된 기반 위에 모니터링을 실시하고, 수요 또는 요구 변화를 처리하기 위한 메커니즘을 갖춰야 합니다. 또한 장애를 탐지하고 자동으로 해결될 수 있도록 시스템을 설계해야 합니다.

모범 사례

기초

시스템을 설계할 때는 먼저 안정성을 좌우하는 기초 요구 사항부터 갖춰야 합니다. 예를 들어, 데이터 센터의 네트워크 대역폭을 충분히 확보해야 합니다. 특정 프로젝트의 범위를 넘어선다는 이유로 이러한 요구 사항을 간과하는 경우도 있습니다. 이렇게 되면 안정적인 시스템을 제공하는 능력이 상당히 저하될 수 있습니다. 온프레미스 환경의 경우, 이러한 요구 사항에 따른 종속성으로 인해 리드 시간이 길어질 수 있으므로 결국 초기 계획에 이를 반영해야 합니다.

그러나 AWS에는 이러한 기초 요구 사항이 대부분 이미 통합되어 있거나 필요에 따라 적용할 수 있습니다. 클라우드는 기본적으로 한계가 없도록 설계되어 있으므로 충분한 네트워킹 및 컴퓨팅 파워에 대한 요구는 AWS의 책임입니다. 고객은 스토리지 디바이스의 크기 등 리소스 크기와 할당 비율을 필요에 따라 자유롭게 변경할 수 있습니다.

다음 질문은 안정성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

REL 1: 계정에 대한 AWS 서비스 한도를 어떻게 관리하고 있습니까?
REL 2: 네트워크 토폴로지를 어떻게 관리하고 있습니까?

AWS는 실수로 인한 리소스 과다 프로비저닝을 방지하기 위해 서비스 한도(팀에서 요청할 수 있는 각각의 리소스 수 상한선)를 설정하고 있습니다. 이러한 한도를 모니터링하고 비즈니스상 필요에 따라 변경하기 위한 거버넌스 및 프로세스를 마련해 두어야 합니다. 클라우드 도입 과정에서 기존 온프레미스 리소스와의 통합을 계획해야 할 수 있습니다(하이브리드 접근 방식). 하이브리드 모델에서는 시간을 두고 완벽한 클라우드 방식으로 점진적으로 이전할 수 있습니다. 따라서 AWS 리소스와 온프레미스 리소스가 네트워크 토폴로지에 따라 상호 작용하는 방식을 반드시 설계해 두어야 합니다.

변경 관리

변경 사항이 시스템에 미치는 영향을 알고 있으면 적극적인 계획 수립이 가능하며, 모니터링을 통해 용량 문제 또는 SLA 위반으로 이어질 수 있는 동향을 신속하게 파악할 수 있습니다. 기존 환경에서는 변경 제어 프로세스를 수작업으로 처리하는 경우가 많았고, 변경 담당자와 변경 시기를 효과적으로 관리하기 위해서는 반드시 감사 부서와 철저히 공조해야 했습니다.

AWS를 이용하면 시스템 동작을 모니터링하고 KPI 대응을 자동화할 수 있습니다. 예를 들어, 서버 시스템을 추가하면 이를 관리하는 사용자 수가 늘어납니다. 시스템 변경 권한을 가진 사용자를 관리하고 이러한 변경 기록을 감사할 수 있습니다.

다음 질문은 안정성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

REL 3: 시스템이 수요 변화에 어떻게 대처하고 있습니까?
REL 4: 리소스를 어떻게 모니터링하고 있습니까?
REL 5: 변경 관리를 어떻게 수행하고 있습니까?

수요 변화에 따라 리소스를 자동으로 추가하거나 제거하도록 시스템을 설계하면 안정성이 향상될 뿐 아니라 비즈니스 성공의 가능성도 높아집니다. 모니터링을 통해 KPI가 통상적인 수준을 벗어나면 담당 팀에 자동으로 알려 줍니다. 환경에 대한 변경 사항이 자동으로 로깅되므로 안정성에 영향을 미칠 가능성이 있는 작업을 감사하여 신속하게 파악할 수 있습니다. 변경 관리 제어를 통해 규칙을 적용함으로써 필요한 수준의 안정성을 확보할 수 있습니다.

장애 관리

통상적인 수준의 복잡한 시스템에는 장애가 발생하기 마련입니다. 이러한 장애를 파악하는 방법과 대응 방법, 재발 방지 방법 등을 알아 둘 필요가 있습니다.

AWS 에서는 자동화를 이용하여 모니터링 데이터에 대응합니다. 예를 들어, 특정 지표가 임계값을 넘어서면 자동화된 작업을 트리거하여 문제를 해결할 수 있습니다. 또한 운영 환경에서 장애가 발생한 리소스를 진단하여 수정하는 대신, 일단 새 리소스로 대체한 다음 운영 환경이 아닌 외부에서 장애 리소스를 분석해 볼 수도 있습니다. 클라우드에서는 저렴한 비용으로 전체 시스템의 임시 버전을 설정할 수 있기 때문에 전체 복구 프로세스를 자동으로 테스트하는 것이 가능합니다.

다음 질문은 안정성에 대한 이러한 고려 사항을 중점적으로 다룹니다.

REL 6: 데이터를 어떻게 백업하고 있습니까?
REL 7: 구성 요소 장애 시 시스템에서 어떻게 대처합니까?
REL 8: 복원성은 어떻게 테스트하고 있습니까?
REL 9: 재해 복구를 어떻게 계획하고 있습니까?

정기적으로 데이터를 백업하고 백업 파일을 테스트하여 논리적 오류와 물리적 오류를 모두 복구할 수 있는지 확인하십시오. 빈번한 시스템 자동 테스트를 통해 장애 원인을 파악하고 복구 방식을 살펴보는 것이 장애 관리의 열쇠입니다 정기 일정에 따라 이 테스트를 수행하고, 중요한 시스템 변경 이후에도 이 테스트가 트리거되는지 확인해야 합니다. 복구 시간 목표(RTO), 복구 시점 목표(RPO) 등의 KPI를 적극적으로 추적하여 장애 테스트 시나리오 등에서 시스템의 복원력을 평가합니다. KPI를 추적하면 단일 장애 지점을 파악 및 완화하는 데 도움이 됩니다. 목표는 시스템 복구 프로세스를 철저히 테스트함으로써 모든 데이터를 복구할 수 있으며 문제가 지속되더라도 고객에게 계속 서비스를 제공할 수 있다는 확신을 얻는 것입니다. 통상적인 프로덕션 프로세스와 마찬가지로 복구 프로세스도 제대로 실행해야 합니다.

주요 AWS 서비스

안정성에 필수적인 AWS 서비스은(는) Amazon CloudWatch, 런타임 지표를 모니터링합니다.이며, 다음 서비스 및 기능이 안정성의 three개 영역을 지원합니다.

리소스

안정성 관련 AWS 모범 사례에 대해 자세히 알아보려면 다음 리소스를 참조하십시오.

Reliability Pillar
How do I manage my AWS service limits?
Embracing Failure: Fault-Injection and Service Reliability
AWS Limit Monitor
Service Limits
Service Limits Reports Blog
Amazon Virtual Private Cloud
AWS Shield
Amazon CloudWatch
Amazon S3
AWS KMS
Backup Archive and Restore Approach Using AWS
Managing your AWS Infrastructure at Scale
AWS Disaster Recovery
AWS Amazon VPC Connectivity Options
AWS Premium Support
Trusted Advisor