영역별 서비스 - AWS 장애 격리 경계

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

영역별 서비스

가용 영역 독립성 (AZI) AWS 을 통해 Amazon EC2 및 Amazon EBS와 같은 영역 서비스를 제공할 수 있습니다. 영역 서비스는 리소스를 배포할 가용 영역을 지정하는 기능을 제공하는 서비스입니다. 이러한 서비스는 지역 내 각 가용 영역에서 독립적으로 작동하며, 더 중요한 것은 각 가용 영역에서도 독립적으로 장애가 발생한다는 것입니다. 즉, 한 가용 영역에 있는 서비스의 구성 요소는 다른 가용 영역의 구성 요소에 종속되지 않습니다. 영역 서비스에는 영역 데이터 플레인이 있기 때문에 이렇게 할 수 있습니다. EC2와 같은 일부 경우에는 EC2 인스턴스 시작과 같이 영역별로 정렬된 작업을 위한 영역 제어 플레인도 서비스에 포함됩니다. AWS 또한 이러한 서비스의 경우 서비스와 쉽게 상호 작용할 수 있도록 지역 컨트롤 플레인 엔드포인트를 제공합니다. 또한 지역 제어 플레인은 지역 범위 기능을 제공할 뿐만 아니라 영역 제어 플레인 상단의 집계 및 라우팅 계층 역할도 합니다. 이는 다음 그림에 나와 있습니다.

이 이미지는 영역별로 분리된 컨트롤 플레인과 데이터 플레인이 있는 영역 서비스를 보여줍니다.

영역별로 분리된 컨트롤 플레인 및 데이터 플레인이 있는 영역 서비스입니다.

가용 영역을 통해 고객은 단일 데이터 센터에서보다 가용성이 높고 내결함성이 뛰어나며 확장 가능한 프로덕션 워크로드를 운영할 수 있습니다. 워크로드가 여러 가용 영역을 사용하는 경우 단일 가용 영역의 물리적 인프라에 영향을 미치는 문제로부터 고객을 더 잘 격리하고 보호할 수 있습니다. 이를 통해 고객은 가용 영역 전반에 걸쳐 중복되는 서비스를 구축할 수 있으며, 올바르게 설계되면 한 가용 영역에 장애가 발생하더라도 운영 상태를 유지할 수 있습니다. 고객은 AZI를 활용하여 가용성이 높고 복원력이 뛰어난 워크로드를 만들 수 있습니다. 아키텍처에 AZI를 구현하면 한 가용 영역의 리소스가 다른 가용 영역의 리소스와의 상호 작용을 최소화하거나 제거하므로 격리된 가용 영역 장애로부터 빠르게 복구할 수 있습니다. 이를 통해 가용 영역 간 종속성을 제거하여 가용 영역 대피를 단순화할 수 있습니다. 가용 영역 제거 메커니즘 생성에 대한 자세한 내용은 고급 다중 AZ 복원 패턴을 참조하십시오. 또한 가용 영역을 한 번에 단일 가용 영역에만 배포하거나 해당 가용 영역의 변경이 잘못된 경우 서비스에서 가용 영역을 제거하는 등 자체 서비스에 AWS 사용되는 것과 동일한 모범 사례를 따라 가용 영역을 더욱 활용할 수 있습니다.

정적 안정성은 다중 가용 영역 아키텍처에서도 중요한 개념입니다. 다중 가용 영역 아키텍처에서 대비해야 하는 장애 모드 중 하나는 가용 영역의 손실이며, 이로 인해 가용 영역의 가치가 손실될 수 있습니다. 가용 영역 손실을 처리할 수 있을 만큼 충분한 용량을 미리 프로비저닝하지 않은 경우 현재 부하로 인해 남은 용량이 과다하게 될 수 있습니다. 또한 손실된 용량을 대체하려면 사용하는 영역 서비스의 컨트롤 플레인에 의존해야 하는데, 이는 정적으로 안정적인 설계보다 안정성이 떨어질 수 있습니다. 이 경우 충분한 추가 용량을 사전 프로비저닝하면 동적으로 변경할 필요 없이 정상 운영을 계속할 수 있으므로 가용 영역과 같은 장애 도메인이 손실되어도 정적으로 안정적으로 대처할 수 있습니다.

여러 가용 영역에 배포된 EC2 인스턴스의 Auto Scaling 그룹을 사용하여 워크로드의 요구 사항에 따라 동적으로 규모를 확장 및 축소할 수 있습니다. Auto Scaling은 몇 분에서 수십 분에 걸쳐 점진적으로 사용량이 변경되는 경우에 적합합니다. 하지만 새 EC2 인스턴스를 시작하는 데는 시간이 걸립니다. 특히 인스턴스에 부트스트래핑 (예: 에이전트, 애플리케이션 바이너리 또는 구성 파일 설치) 이 필요한 경우에는 더욱 그렇습니다. 이 기간 동안에는 현재 부하로 인해 남은 용량이 과다해질 수 있습니다. 또한 Auto Scaling을 통한 새 인스턴스 배포는 EC2 컨트롤 플레인을 기반으로 합니다. 이는 단점이 있습니다. 단일 가용 영역이 손실되어도 정적으로 안정적으로 작동하려면 새 인스턴스를 프로비저닝할 때 Auto Scaling에 의존하는 대신 손상된 가용 영역으로부터 이동된 부하를 처리할 수 있을 만큼 충분한 EC2 인스턴스를 다른 가용 영역에 미리 프로비저닝해야 합니다. 하지만 추가 용량을 사전 프로비저닝하면 추가 비용이 발생할 수 있습니다.

예를 들어 정상 운영 중에 워크로드에 3개의 가용 영역에서 고객 트래픽을 처리하기 위해 6개의 인스턴스가 필요하다고 가정해 보겠습니다. 단일 가용 영역 장애에 대해 정적 안정성을 유지하려면 각 가용 영역에 총 9개의 인스턴스를 배포해야 합니다. 가용 영역 상당의 인스턴스 중 하나에 장애가 발생하더라도 여전히 6개 남았기 때문에 장애 발생 시 새 인스턴스를 프로비저닝하고 구성할 필요 없이 고객 트래픽을 계속 제공할 수 있습니다. 이 경우 50% 의 추가 인스턴스를 실행하기 때문에 EC2 용량의 정적 안정성을 확보하려면 추가 비용이 듭니다. 리소스를 사전 프로비저닝할 수 있는 모든 서비스 (예: S3 버킷 또는 사용자 사전 프로비저닝) 에 추가 비용이 발생하는 것은 아닙니다. 원하는 워크로드 복구 시간을 초과할 위험과 정적 안정성 구현의 절충점을 비교해야 합니다.

AWS Local Zones 및 Outposts는 일부 AWS 서비스의 데이터 플레인을 최종 사용자에게 더 가깝게 제공합니다. 이러한 서비스의 컨트롤 플레인은 상위 지역에 있습니다. 로컬 영역 또는 Outposts 인스턴스는 로컬 영역 또는 Outposts 서브넷을 생성한 가용 영역의 EC2 및 EBS와 같은 영역 서비스에 대한 컨트롤 플레인 종속성을 갖게 됩니다. 또한 Elastic Load Balancing (ELB), 보안 그룹, Amazon EKS (Amazon EKS) 에서 관리하는 쿠버네티스 컨트롤 플레인 (EKS를 사용하는 경우) 과 같은 리전 서비스를 위한 리전 컨트롤 플레인에 종속됩니다. Outposts와 관련된 추가 정보는 설명서와 지원 및 유지 관리 FAQ를 참조하십시오. Local Zones 또는 Outposts를 사용할 때 정적 안정성을 구현하면 상위 지역에 대한 네트워크 연결 중단이나 제어 플레인 장애에 대한 복원력을 개선하는 데 도움이 됩니다.