단일 영역 배포

단일 영역 배포에서는 여러 애플리케이션 인스턴스가 하나의 영역에 배포됩니다. 애플리케이션 인스턴스가 단일 가상 서버에서 실행되는 경우, 배치 그룹을 사용하면 이러한 가상 서버를 별도의 물리적 호스트에서 프로비저닝할 수 있습니다. VPC 자동 확장을 사용하면 워크로드 변경에 따라 동적으로 용량을 조정할 수 있습니다. 단일 영역 배포는 99.9 인프라 가용성으로 비용 효율적인 솔루션을 제공합니다. 이 배포는 비프로덕션 환경이나 비즈니스에 중요하지 않은 애플리케이션에 적합할 수 있습니다. 그러나 단일 영역 배포는 영역 중단에 대한 보호 기능을 제공하지 않습니다.

이 배포 모델을 사용할 때는 구역 간 불균형을 피하는 것이 모범 사례입니다. 존 간 불균형이란, VPC 가상 서버 인스턴스(VSI)와 같은 리소스가 각 존에 고르게 분산되지 않은 상태를 말합니다. 워크로드의 VSI 용량 중 70%가 존 1에, 20%가 존 2에, 10%가 존 3에 배포된 사례를 생각해 봅시다. 존 1에 장애가 발생하더라도 워크로드는 계속 이용 가능할 수 있으나, 용량은 기존 용량의 30% 수준으로 제한됩니다. 한 가지 해결책은 존 1에 장애가 발생할 경우 더 많은 리소스를 할당하는 것이지만, 이로 인해 나머지 존에서 용량 수요가 비정상적으로 급증할 수 있습니다. 더 나은 해결책은 불균형을 해소하고 필요한 용량을 각 구역에 고르게 분배하는 것이며, 특정 구역에서 발생할 수 있는 손실을 상쇄하기 위해 각 구역에 약 17%의 여유 용량을 추가로 확보하는 것입니다. 이를 통해 특정 구역에 장애가 발생하더라도 워크로드의 가용성이 유지되고 최대 용량으로 운영될 수 있도록 보장합니다.

다중 영역, 단일 지역 배포

다중 영역, 단일 지역 배포에서는 여러 애플리케이션 인스턴스가 지역 내 두 개 이상의 가용 영역에 배포됩니다. 애플리케이션을 3개의 가용 영역에 걸쳐 배포할 경우, 다중 존·단일 리전 배포 방식은 최대 99.99 %의 인프라 가용성을 제공할 수 있습니다. 이 배포 방식은 애플리케이션을 존 장애로부터 보호하며, 가용성 요구 사항이 99.9 % 이상인 프로덕션급 엔터프라이즈 워크로드에 적합합니다. 실제 애플리케이션 가용성은 애플리케이션 고가용성 설계에 따라 달라집니다.

이 배포 모델을 사용할 때는 존 간 불균형이 발생하지 않도록 주의하십시오. 존 간 불균형은 용량(예: IBM Cloud® Virtual Servers for Virtual Private Cloud s(VSIs))이 각 존에 고르게 분배되지 않을 때 발생합니다. 워크로드의 VSI 용량 중 70%가 존 1에, 20%가 존 2에, 10%가 존 3에 배포된 사례를 생각해 봅시다. 존 1에 장애가 발생하면 워크로드는 계속 가동될 수 있지만, 용량은 30% 수준으로 제한될 수 있습니다. 서비스 중단이 발생하면 리소스를 추가로 할당할 수는 있지만, 이로 인해 나머지 존 전반에 걸쳐 용량 수요가 비정상적으로 급증할 수 있습니다. 대신, 필요한 용량을 각 구역에 고르게 분배하여 불균형을 해소하고, 개별 구역의 장애 발생 시 이를 상쇄하기 위해 구역당 약 17%의 여유 용량을 추가로 확보하십시오. 이를 통해 특정 구역에 장애가 발생하더라도 워크로드의 가용성이 유지되고, 최대 용량으로 운영될 수 있도록 보장합니다.

다중 영역, 다중 지역 배포

다중 영역, 다중 지역 배포는 지역 중단에 대한 보호 기능을 제공합니다. 이 배포는 연속 또는 거의 연속적인 가용성 요구 사항이 있는 미션 크리티컬 애플리케이션에 권장됩니다. 이 배포는 또한 지역 간 또는 특정 분리 거리 요구 사항이 있는 애플리케이션에 대한 지역 외 재해 복구 및 비즈니스 연속성을 지원합니다.

다중 영역 배포는 가용성 영역 전반에서 애플리케이션 인식 데이터 복제에 의존하며 액티브-액티브 및 액티브-스탠바이 아키텍처 패턴을 지원합니다. 다중 영역, 다중 지역 배포는 지속적인 가용성 및 상시 가동 요구 사항이 있는 엔터프라이즈 애플리케이션을 위한 아키텍처 패턴을 지원합니다. 다음 표는 다양한 배포 옵션과 권장 사용법을 비교한 것입니다.

다음 아키텍처 프레임워크는 IBM Cloud Virtual Private Cloud (VPC) 인프라에 복원력 있는 애플리케이션을 배포하기 위한 설계 고려 사항과 아키텍처 결정을 제공합니다. 다음과 같은 솔루션 측면과 도메인을 다룹니다:

• 네트워킹: 로드 밸런싱, 도메인 이름 시스템
• 보안: 보안: 데이터 보안
• 복원력: 고가용성, 백업 및 복원, 재해 복구
• 서비스 관리 모니터링, 로깅, 감사, 알림

아키텍처 설계 프레임워크는 일련의 측면과 도메인에 걸쳐 요구 사항을 해결하여 클라우드 솔루션을 설계하는 일관된 접근 방식을 제공합니다. 도메인은 기술에 관계없이 모든 엔터프라이즈 솔루션에서 고려해야 하는 아키텍처 영역입니다.

고가용성 애플리케이션을 위한 클라이언트 재시도 로직

일시적인 오류를 효과적으로 처리할 수 있는 클라이언트 애플리케이션을 구축할 책임이 있습니다. 일시적 오류에는 네트워크 오류 및 지역 서비스가 영역 장애에서 복구되는 경우와 같이 서비스의 고가용성 구현으로 인해 발생하는 일시적 장애가 포함됩니다. 특정 IBM Cloud 서비스에 대한 자세한 내용은 고가용성 및 재해 복구에 대한 서비스 설명서를 참조하세요.

대부분의 IBM Cloud SDK는 429 및 503 오류와 같은 특정 HTTP 오류를 처리하도록 설계된 자동 재시도를 지원하는 IBM Cloud SDK 공통 을 기반으로 구축되었습니다. SDK가 모든 오류를 자동으로 처리하지는 않습니다. 재시도 로직을 활용하려면 SDK를 올바르게 구성해야 합니다.

일부 IBM Cloud 서비스는 오픈 소스 프로토콜을 지원하므로 오픈 소스 SDK를 사용하는 것이 적절할 수 있습니다. 이러한 SDK를 검토하여 애플리케이션에 유용한지, 적절한 재시도 기능을 제공하는지 확인하세요.

재시도 로직은 IBM Cloud 서비스 유형과 작업 유형에 따라 다릅니다. 일부 실패한 작업은 재시도에 적합한 상태 코드를 생성하고, 일부 작업은 재시도에 적합하지 않은 상태 코드를 생성합니다. 실패한 읽기 및 HTTP GET 작업은 일반적으로 고정된 기간의 지수 백오프를 사용하여 재시도할 수 있습니다. 지수 백오프는 네트워크 요청이나 API 호출과 같은 작업이 실패한 후 재시도를 관리하는 재시도 전략입니다. 재시도 사이의 지연 시간을 기하급수적인 패턴으로 점차 늘려 시스템 과부하 위험을 줄입니다. 다시 시도해야 하는 실패는 실패 유형과 특정 IBM Cloud 서비스에 따라 다릅니다. 자세한 내용은 각 IBM Cloud 서비스 SDK 및 설명서를 참조하세요.

작업이 완료되지 않았음이 분명하고 문서화된 클라이언트 로직에 재시도가 적절하다고 명시되어 있지 않는 한, 쓰기 실패, HTTP PUT, POST, DELETE 및 기타 작업은 간단한 재시도 메커니즘을 사용하여 복구할 수 없을 가능성이 높습니다. 리소스 생성과 같이 시스템 상태를 변경하는 작업이 실패하면 실패의 원인을 알 수 없는 경우가 많습니다. 이러한 불확실성 때문에 문제를 해결하기 위해 단순한 재시도 로직에 의존해서는 안 됩니다. 대신 IBM Cloud 서비스를 위해 특별히 설계된 고급 방법을 사용하세요.

클라이언트 재시도는 단일 클라이언트의 가용성을 향상시키며 워크로드는 여러 클라이언트로 구성할 수 있습니다. IBM Cloud Logs 같은 중앙 집중식 로깅 서비스에 클라이언트 장애를 기록하면 전체 워크로드에 대한 장애 및 가용성 분석이 가능합니다.