본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
2부 링크 : AWS상에 내결함성이 뛰어난 애플리케이션 구축 2/2
요약
이 백서는 AWS (Amazon Web Services)를 사용하여 내결함성 소프트웨어 시스템을 구축하는 방법을 소개합니다. 컴퓨팅, 스토리지, 네트워킹 및 데이터베이스 솔루션을 포함하여 다양한 AWS 서비스에 대해 배웁니다. 이러한 솔루션을 활용하면 자동으로 갱신되는 인프라를 설정하여 성능 저하 및 장애 지점을 피할 수 있습니다. AWS 플랫폼은 최소한의 인간 상호 작용과 선행 금융 투자로 운영 할 수 있습니다. 또한 AWS 리전 및 가용 영역을 사용하여 고가용성을 제공하는 아키텍처 인 AWS 글로벌 인프라에 대해 배웁니다.
이 백서는 고가용성, 안정성 및 내결함성 시스템을 제공하는 플랫폼을 사용하여 솔루션을 클라우드로 배포 또는 마이그레이션하려는 IT 관리자 및 시스템 설계자를 위해 작성되었습니다.
소개
내결함성은 시스템을 구축하는 데 사용 된 일부 구성 요소에 장애가 있어도 시스템이 계속 작동 할 수 있는 기능입니다. 매우 보수적인 가정에도 불구하고 분주한 전자 상거래 사이트는 1 분마다 수천 달러를 잃을 수 있습니다. 이것이 기업과 조직이 결함에서 살아남을 수 있는 소프트웨어 시스템을 개발하려고 노력하는 이유 중 하나입니다. AWS (Amazon Web Services)는 내결함성 소프트웨어 시스템을 구축하는 데 가장 적합한 플랫폼을 제공합니다. AWS 플랫폼을 사용하면 최소한의 인간 상호 작용 및 선행 금융 투자로 작동하는 내결함성 시스템을 구축 할 수 있습니다.
실패가 그렇게 흥미로워서는 안 됩니다.
기존의 사내 데이터 센터 환경에서 이상적인 상태는 문제를 해결하기 위해 신속하고 결정적인 조치를 취할 준비가 된 관리자에게 장애 통지를 안정적으로 전달하는 경향이 있습니다. 많은 조직에서 이러한 IT 열정에 도달할 수 있지만, 이를 위해서는 일반적으로 광범위한 경험, 초기 재무 투자 및 상당한 인력이 필요합니다. Amazon Web Services는 클라우드에서 안정적이고 내결함성이 뛰어나며 가용성이 높은 시스템을 구축하기 위한 서비스와 인프라를 제공합니다. 그 결과, 잠재적인 장애는 시스템 자체에서 자동으로 처리될 수 있으며, 결과적으로 상당히 재미없는 사건입니다.
AWS는 거의 모든 종류의 장애를 설명하기 위해 자동으로(또는 거의 자동으로) 할당할 수 있는 몇 가지 이름(예: Amazon Elastic Compute Cloud, Amazon EC2, Amazon EBS, Auto Scaling)을 지정하기 위해 방대한 양의 IT 인프라에 액세스할 수 있도록 합니다. 실제로 사용하는 리소스에 대해서만 요금이 부과되므로 선불 금융 투자는 없습니다.
Amazon Elastic Compute Cloud
Amazon Elastic Compute Cloud(Amazon EC2)는 소프트웨어 시스템을 구축하고 호스팅하는 데 사용하는 컴퓨팅 리소스(말 그대로 서버 인스턴스)를 제공합니다. Amazon EC2는 애플리케이션 개발을 위한 AWS의 자연스러운 진입점입니다. 여러 EC2 인스턴스와 자동 스케일링 및 탄력적 로드 밸런싱과 같은 보조 서비스를 사용하여 매우 안정적이고 내결함성이 높은 시스템을 구축할 수 있습니다.
표면적으로는 EC2 인스턴스가 기존 하드웨어 서버와 매우 유사합니다. EC2 인스턴스는 Linux 또는 Windows와 같은 친숙한 운영 체제를 사용합니다. 따라서 이러한 운영 체제에서 실행되는 거의 모든 종류의 소프트웨어를 수용할 수 있습니다. EC2 인스턴스에는 IP 주소가 있으므로 원격 시스템과 상호 작용하는 일반적인 방법(예: SSH 또는 RDP)을 사용할 수 있습니다. 서비스 인스턴스를 정의하는 데 사용하는 템플릿을 AMI(Amazon Machine Image)라고 하며 여기에는 정의된 소프트웨어 구성(즉, 운영 체제, 애플리케이션 서버 및 애플리케이션)이 포함됩니다.
AMI에서는 클라우드에서 가상 서버로 실행되는 AMI의 복사본인 인스턴스를 실행합니다. 다음 그림과 같이 AMI의 여러 인스턴스를 시작할 수 있습니다.
Amazon EC2의 인스턴스 유형은 기본적으로 하드웨어 원형입니다. 애플리케이션에 필요한 메모리(RAM) 및 컴퓨팅 성능(CPU 수)과 일치하는 인스턴스 유형을 선택합니다. 인스턴스를 중지하거나 종료할 때까지 또는 실패할 때까지 인스턴스가 계속 실행됩니다. 인스턴스가 실패하면 AMI에서 새 인스턴스를 시작할 수 있습니다.
Amazon은 공용 소프트웨어 구성이 포함된 많은 AMI를 게시합니다. 또한 AWS 개발자 커뮤니티의 회원들은 자신만의 사용자 지정 AMI를 게시했습니다. 또한 사용자 정의 AMI를 생성하여 필요한 소프트웨어 구성이 포함된 새 인스턴스를 빠르고 쉽게 시작할 수 있습니다.
AWS에서 장애 발생 방지 응용 프로그램을 구축하는 첫 번째 단계는 AMI 구성 방법을 결정하는 것입니다. 이를 위한 두 가지 뚜렷한 메커니즘, 즉 동적인 메커니즘과 정적 메커니즘이 있습니다. 동적 구성은 기본 AMI로 시작되며, 시작 시 애플리케이션에 필요한 소프트웨어와 데이터를 배포합니다. 정적 구성은 필요한 소프트웨어와 데이터를 기본 AMI에 배포한 다음 이를 사용하여 애플리케이션 배포에 사용되는 애플리케이션별 AMI를 생성합니다. 동적 또는 정적 구성을 사용하기로 결정할 때 다음 요소를 고려해야 합니다.
· 응용 프로그램 변경 빈도 — 동적 구성은 빈번한 응용 프로그램 변경에 더 큰 유연성을 제공합니다.
· 시작 속도 — AMI에 설치된 애플리케이션은 시작 시간과 인스턴스를 사용할 수있는 시간을 줄입니다. 이것이 중요한 경우 정적 구성은 시작 시간을 최소화합니다.
· 감사 — 애플리케이션 구성의 감사 추적이 필요할 때 AMI에 대한 보존 정책과 결합 된 정적 구성을 통해 과거 구성을 다시 생성 할 수 있습니다.
동적 구성과 정적 구성을 혼합할 수 있습니다. 일반적인 패턴은 인스턴스가 시작되면 데이터가 배포되는 동안 애플리케이션 소프트웨어를 AMI에 배포하는 것입니다. 응용 프로그램은 사용자가 구성한 하나 이상의 AMI로 구성되어야 합니다. 응용 프로그램을 시작하려면 AMI에서 필요한 수의 인스턴스를 시작합니다. 예를 들어 응용 프로그램이 웹 서버 또는 웹 서비스인 경우 AMI에는 웹 서버, 관련 정적 콘텐츠 및 동적 페이지의 코드가 포함될 수 있습니다. 따라서 이 AMI에서 인스턴스를 실행하면 웹 서버가 시작되고 응용 프로그램이 요청을 수락할 준비가 됩니다.
AMI에서 필요한 인스턴스(instance)가 실행되면 동일한 AMI를 사용하는 대체 인스턴스를 실행하여 인스턴스 오류를 해결할 수 있습니다. 이 작업은 API 호출, 스크립트 가능 명령줄 도구 또는 AWS 관리 콘솔을 통해 수행할 수 있습니다. 또한 실패하거나 성능이 저하된 인스턴스를 자동으로 대체하도록 오토 스케일링 그룹을 구성할 수 있습니다. 문제가 있는 인스턴스를 신속하게 교체할 수 있는 기능은 장애 허용을 위한 첫 번째 단계일 뿐입니다. AWS를 사용하면 AMI를 사용하여 동일한 템플릿을 기반으로 새 인스턴스를 시작하여 장애 또는 문제 있는 동작에서 신속하게 복구할 수 있습니다.
다운타임을 최소화하기 위해 장애 발생 시 임시 인스턴스를 계속 실행할 수 있는 옵션이 있습니다. 이 작업은 탄력적인 IP 주소를 사용하여 효율적으로 수행할 수 있습니다. 탄력적인 IP 주소를 새 인스턴스로 다시 연결하여 대체 인스턴스 또는 (실행) 예비 인스턴스로 페일오버합니다.
Elastic Block Store
Amazon EBS(Amazon Elastic Block Store)는 Amazon EC2 인스턴스에서 사용할 수 있는 영구 블록 스토리지 볼륨을 제공합니다. EBS 볼륨은 실행 중인 EC2 인스턴스에 연결될 수 있으며 인스턴스와 독립적으로 지속될 수 있습니다. EBS 볼륨은 구성요소 장애로부터 보호와 함께 높은 내구성과 가용성을 제공하는 가용성 영역 내에서 자동으로 복제됩니다.
Amazon EBS는 특히 데이터베이스, 파일 시스템 또는 원시 블록 스토리지에 대한 액세스가 필요한 애플리케이션에 적합합니다. 일반적인 사용 사례로는 빅 데이터 분석, 관계형 또는 NoSQL 데이터베이스, 스트림 또는 로그 처리 애플리케이션, 데이터 웨어하우징 애플리케이션 등이 있습니다.
Amazon EBS와 Amazon EC2는 종종 AWS 플랫폼에서 결함성 애플리케이션을 구축할 때 서로 함께 사용됩니다. 지속되어야 하는 모든 애플리케이션 데이터는 EBS 볼륨에 저장되어야 합니다. EC2 인스턴스가 실패하여 교체해야 하는 경우, EBS 볼륨을 새 EC2 인스턴스에 간단히 첨부할 수 있습니다. 이 새 인스턴스는 기본적으로 원본의 복제본이기 때문에 데이터나 기능이 손실되지 않아야 합니다.
Amazon EBS 볼륨은 매우 신뢰성이 높지만, 장애 가능성을 더욱 완화하기 위해 스냅샷이라는 기능을 사용하여 이러한 볼륨의 백업을 생성할 수 있습니다. 강력한 백업 전략에는 간격(일반적으로 일일 수도 있지만 특정 애플리케이션의 경우 더 자주), 보존 기간(애플리케이션 및 롤백에 대한 비즈니스 요구 사항에 따라 달라짐) 및 복구 계획이 포함됩니다. EBS 볼륨의 백업에 대한 높은 내구성을 확보하기 위해 스냅샷은 Amazon Simple Storage Service(Amazon S3)에 저장됩니다.
EBS 스냅샷은 새로운 Amazon EBS 볼륨을 생성하기 위해 사용되며, 이는 스냅샷이 생성되었을 때의 원본 볼륨의 정확한 복제본입니다. 스냅샷은 애플리케이션의 디스크 상태를 나타내기 때문에 스냅샷을 시작하기 전에 메모리 내 데이터를 디스크에 플러시해야 합니다.
EBS 스냅샷은 API, AWS Management Console, Amazon Data Lifecycle Manager(DLM) 또는 AWS 백업을 사용하여 생성 및 관리합니다.
Auto Scaling
오토 스케일링 그룹에는 자동 확장 및 관리를 위해 논리적 그룹으로 취급되는 Amazon EC2 인스턴스가 포함되어 있습니다. 가용성이 높은 솔루션에서는 자동 확장 그룹을 사용하면 EC2 비행대가 필요한 용량을 제공할 수 있습니다. 비행대 인스턴스 상태 메트릭을 지속적으로 모니터링하면 장애가 자동으로 감지되고 필요할 때 교체 인스턴스를 시작할 수 있습니다.
EC2 비행대의 필요한 크기가 다를 경우 자동 배율은 특정 메트릭 값에 대한 예약 및 표적 추적을 포함한 여러 기준을 사용하여 용량을 조정할 수 있습니다. EC2 용량을 관리하기 위한 유연한 메커니즘을 제공하는 다중 스케일링 기준을 적용할 수 있습니다.
애플리케이션 및 고가용성(HA) 전략의 요구 사항에 따라 필요한 자동 확장 그룹 수가 결정됩니다. 하나 이상의 가용성 영역(AZ)에 분산된 EC2 용량을 사용하는 애플리케이션의 경우 단일 자동 확장 그룹이면 충분합니다. 사용 가능한 경우 용량이 시작되고 필요에 따라 오토 스케일링 그룹이 인스턴스를 대체하지만 선택한 AZ 내의 배치가 임의로 수행됩니다. HA 전략에 EC2 용량 배포를 보다 정확하게 제어해야 하는 경우 AZ당 자동 확장 그룹을 사용하는 것이 적절한 솔루션입니다. 두 개의 인스턴스(프로덕션)와 페일오버(fail-over)가 있는 애플리케이션이 있으며, 이를 별도의 가용성 영역에 배포해야 합니다.
실패는 유용 할 수 있습니다
소프트웨어 시스템은 시간이 지남에 따라 성능이 저하됩니다. 이는 부분적으로 다음과 같은 이유 때문입니다.
· 사용자가 작성한 소프트웨어 및 의존하는 소프트웨어(예: 애플리케이션 프레임워크, 운영 체제 및 장치 드라이버)를 포함하여 메모리 및/또는 리소스가 유출됩니다.
· 파일 시스템이 시간에 따라 단편화되어 성능에 영향을 미칩니다.
· 하드웨어(특히 스토리지) 장치는 시간이 지남에 따라 물리적으로 저하됩니다.
규율화된 소프트웨어 엔지니어링은 이러한 문제를 일부 완화할 수 있지만, 궁극적으로 가장 정교한 소프트웨어 시스템도 통제할 수 없는 여러 구성 요소(예: 운영 체제, 펌웨어 및 하드웨어)에 따라 달라집니다.
결국 하드웨어, 시스템 소프트웨어 및 소프트웨어의 조합으로 인해 오류가 발생하고 애플리케이션의 가용성이 중단됩니다.
기존 IT 환경에서는 하드웨어를 정기적으로 유지보수 및 서비스할 수 있지만, 이를 얼마나 적극적으로 수행할 수 있는지에 대한 실질적이고 경제적인 한계가 있습니다. 그러나 Amazon EC2를 사용하면 필요한 리소스를 원하는 대로 종료하고 재생성할 수 있습니다.
AWS 플랫폼을 최대한 활용하는 응용 프로그램을 새 서버 인스턴스로 정기적으로 새로 고칠 수 있습니다. 따라서 잠재적인 성능 저하가 시스템 전체에 부정적인 영향을 미치지 않습니다. 기본적으로 이 리소스를 새로 고치기 위해 서버 종료와 같은 장애로 간주되는 기능을 사용하고 있습니다.
이 접근 방식을 사용하면 AWS 애플리케이션은 구성된 서버 인스턴스보다 클라이언트에 제공하는 서비스로 더 정확하게 정의됩니다. 이러한 사고방식을 통해 서버 인스턴스는 중요하지 않으며 일회용입니다.
AWS 글로벌 인프라
AWS에서 내결함성 애플리케이션을 구축하려면 AWS 글로벌 인프라의 아키텍처를 이해해야합니다. AWS 글로벌 인프라는 리전 및 가용 영역을 중심으로 구축됩니다.
AWS 리전 및 가용 영역
AWS 리전은 세계의 지리적인 영역입니다. 각 AWS 리전은 가용 영역이라고 하는 것으로 논리적으로 그룹화 된 데이터 센터 모음입니다. AWS 리전은 대기 시간이 짧고 처리량이 많으며 중복성이 높은 네트워킹으로 연결된 물리적으로 분리되고 분리 된 가용 영역을 여러 개 (일반적으로 3 개) 제공합니다. 각 AZ는 하나 이상의 물리적 데이터 센터로 구성됩니다. 가용 영역은 물리적 이중화를 위해 설계되었으며 복원력을 제공하여 정전, 인터넷 다운 타임, 홍수 및 기타 자연 재해가 발생하더라도 중단 없는 성능을 제공합니다.
여러 가용 영역을 통한 고가용성
가용 영역은 빠른 개인 광섬유 네트워킹으로 서로 연결되어 중단없이 AZ간에 자동 장애 조치를 수행하는 응용 프로그램을 설계 할 수 있습니다. 이 AZ는 AWS 고객에게 애플리케이션 및 데이터베이스를보다 쉽고 효과적으로 설계 및 운영 할 수있는 방법을 제공함으로써 기존 단일 데이터 센터 인프라 또는 다중 데이터 센터 인프라보다 가용성, 내결함성 및 확장 성이 뛰어납니다.
고가용성을 달성하기 위한 아키텍처 구축
여러 가용 영역에 걸쳐 애플리케이션을 배포하여 고가용성을 달성 할 수 있습니다. 각 응용 프로그램 계층 (웹, 응용 프로그램 및 데이터베이스)에 대해 여러 중복 인스턴스를 별개의 AZ에 배치하면 다중 사이트 솔루션이 만들어집니다. ELB (Elastic Load Balancing)를 사용하면 ELB 서비스가 여러 가용 영역의 여러 인스턴스에서 트래픽의 균형을 자동으로 조정하므로 정상적인 인스턴스 만 트래픽을 수신 할 수 있습니다. 바람직한 목표는 2 개 이상의 AZ에 각 응용 프로그램 스택의 독립적 인 복사본을 보유하고 정상적인 리소스로 트래픽을 자동 라우팅하는 것입니다.
리전 간 복제를 통한 연속성 향상
가용 영역을 사용하여 동일한 리전의 여러 데이터 센터에서 애플리케이션 및 데이터를 복제하는 것 외에도 지리적 리전간에 데이터를 복제하여 중복성과 내결함성을 더욱 높이도록 선택할 수 있습니다. 프라이빗, 고속 네트워킹 및 퍼블릭 인터넷 연결을 모두 사용하여 추가 비즈니스 연속성을 제공하거나 전 세계에서 낮은 대기 시간 액세스를 제공 할 수 있습니다.
고가용성 빌딩 블록
Amazon EC2 및 관련 서비스는 애플리케이션을 배포 및 구축 할 수있는 강력하면서도 경제적인 플랫폼을 제공합니다. 그러나 이들은 Amazon Web Services 플랫폼의 한 측면 일뿐입니다. AWS는 애플리케이션의 가용성을 높이기 위해 애플리케이션 개발 및 배포에 통합 할 수 있는 여러 가지 다른 서비스를 제공합니다.
탄력적 IP 주소
탄력적 IP 주소는 AWS 계정에 할당 된 고정 공개 IPv4 주소입니다. 탄력적 IP 주소를 사용하면 계정의 다른 인스턴스로 주소를 빠르게 다시 매핑하여 인스턴스 또는 소프트웨어의 장애를 숨길 수 있습니다. 탄력적 IP는 변경하지 않고 삭제할 때까지 계정에 할당 된 상태로 유지됩니다.
탄력적 IP 주소는 특정 리전의 퍼블릭 AWS IPv4 네트워크 범위에서 할당됩니다. 인스턴스에 퍼블릭 IPv4 주소가없는 경우 탄력적 IP 주소를 인스턴스와 연결하여 인터넷과 통신 할 수 있습니다. 예를 들어 로컬 컴퓨터에서 인스턴스에 연결합니다. 탄력적 IP 주소는 인터넷 게이트웨이를 통해 인스턴스의 개인 주소로 매핑됩니다. 탄력적 IP 주소를 인스턴스와 연결 한 후에는 연결을 제거하거나 다른 리소스와 주소를 연결할 때까지 연결된 상태로 유지됩니다.
탄력적 IP 주소는 특히 수평으로 확장 할 수없는 레거시 유형 응용 프로그램의 경우 장애 조치를 처리하는 한 가지 방법입니다. 연결된 탄력적 IP 주소를 가진 단일 서버에 장애가 발생한 경우 장애 조치 메커니즘은 이상적으로 자동화 된 방식으로 탄력적 IP 주소를 대체 인스턴스에 다시 연결할 수 있습니다. 이 시나리오에서는 애플리케이션 다운 타임이 발생할 수 있지만, 장애를 감지하고 탄력적 IP 주소를 대체 리소스에 신속하게 다시 연결하는 데 걸리는 시간으로 제한 될 수 있습니다.
고가용성 수준이 필요한 경우 여러 인스턴스와 Elastic Load Balancer를 사용할 수 있습니다.
탄력적 로드 밸런싱
Elastic Load Balancing은 Amazon EC2 인스턴스, 컨테이너, IP 주소 및 Lambda 함수와 같은 여러 대상에 들어오는 애플리케이션 트래픽을 자동으로 분산하고 정상적인 대상 만 트래픽을 수신하도록하는 AWS 서비스입니다. 단일 가용 영역 또는 여러 AZ에서 애플리케이션 트래픽의 다양한로드를 처리 할 수 있으며 동일한 로드 밸런서에서 AWS 및 온 프레미스 리소스에로드 밸런싱 기능을 지원합니다.
Elastic Load Balancing은 3 가지 유형의로드 밸런서를 제공합니다. 이 유형에는 모두 애플리케이션의 내결함성에 필요한 고가용성, 자동 스케일링 및 강력한 보안 기능이 있습니다.
애플리케이션로드 밸런서
Application Load Balancer는 HTTP 및 HTTPS 트래픽의로드 밸런싱에 가장 적합하며 마이크로 서비스 및 컨테이너를 포함한 최신 애플리케이션 아키텍처 제공을 목표로 하는 고급 요청 라우팅을 제공합니다. 개별 요청 수준 (계층 7)에서 작동하는 Application Load Balancer는 요청 내용을 기반으로 Amazon Virtual Private Cloud (Amazon VPC) 내의 대상으로 트래픽을 라우팅합니다.
네트워크 로드 밸런서
Network Load Balancer는 최고의 성능이 필요한 TCP (Transmission Control Protocol), UDP (User Datagram Protocol) 및 TLS (Transport Layer Security) 트래픽의 로드 밸런싱에 가장 적합합니다. 연결 수준 (계층 4)에서 작동하는 Network Load Balancer는 트래픽을 Amazon VPC 내의 대상으로 라우팅하며 초저 대기 시간을 유지하면서 초당 수백만 건의 요청을 처리 할 수 있습니다.
Network Load Balancer는 갑작스럽고 변동이 심한 트래픽 패턴을 처리하도록 최적화 되었습니다.
Elastic Load Balancing 사용의 이점
· 고가용성 — Elastic Load Balancing은 들어오는 트래픽을 여러 AZ에있는 Amazon EC2 인스턴스, 컨테이너, IP 주소 및 Lambda 함수와 같은 여러 대상에 자동으로 분산하고 정상적인 대상 만 트래픽을 수신하도록 합니다. Amazon Elastic Load Balancing 서비스 수준 계약 약정은 로드 밸런서에 대한 99.99 %의 가용성입니다.
· 보안 — Elastic Load Balancing은 Amazon VPC와 함께 작동하여 통합 인증서 관리, 사용자 인증 및 SSL / TLS 암호 해독을 포함한 강력한 보안 기능을 제공합니다. 또한 TLS 설정을 중앙에서 관리하고 CPU 집약적 인 워크로드를 애플리케이션에서 오프로드 할 수 있는 유연성을 제공합니다.
· 탄력성 — Elastic Load Balancing은 네트워크 트래픽 패턴의 급격한 변화를 처리 할 수 있습니다. 또한 Auto Scaling과의 긴밀한 통합으로 수동 개입없이 다양한 수준의 애플리케이션로드를 충족 할 수 있는 충분한 애플리케이션 용량이 보장됩니다.
· 유연성 — 탄력 부하 분산을 사용하면 IP 주소를 사용하여 요청을 응용 프로그램 대상으로 라우팅 할 수 있습니다. 이를 통해 애플리케이션 대상을 가상화하는 방법에 유연성을 제공하여 동일한 인스턴스에서 더 많은 애플리케이션을 호스팅 할 수 있습니다. 또한 이러한 응용 프로그램은 개별 보안 그룹을 보유하고 동일한 네트워크 포트를 사용하여 마이크로 서비스 기반 아키텍처에서 응용 프로그램 간 통신을 더욱 단순화 할 수 있습니다.
· 강력한 모니터링 및 감사 — Elastic Load Balancing을 사용하면 Amazon CloudWatch 지표, 로깅 및 요청 추적을 통해 애플리케이션 및 성능을 실시간으로 모니터링 할 수 있습니다. 이렇게 하면 개별 동작의 세분성으로 응용 프로그램 동작에 대한 가시성이 향상되어 문제를 발견하고 응용 프로그램 스택에서 성능 병목 현상을 식별 할 수 있습니다.
하이브리드로드 밸런싱 — Elastic Load Balancing은 동일한 로드 밸런서를 사용하여 AWS 및 온 프레미스 리소스에서로드 밸런싱 기능을 제공합니다. 따라서 온 프레미스 애플리케이션을 클라우드로 마이그레이션, 버스트 또는 페일 오버 할 수 있습니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Fault-Tolerant Components on AWS(2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
