안정성을 지원하는 클라우드 디자인 패턴
워크로드 아키텍처를 디자인할 때 일반적인 문제를 해결하는 업계 패턴을 사용해야 합니다. 패턴은 워크로드 내에서 의도적인 절충을 수행하고 원하는 결과를 최적화하는 데 도움이 될 수 있습니다. 또한 보안, 성능, 비용 및 운영에 영향을 줄 수 있는 특정 문제에서 발생하는 위험을 완화하는 데 도움이 될 수 있습니다. 완화되지 않으면 이러한 위험으로 인해 결국 안정성 문제가 발생합니다. 이러한 패턴은 실제 환경에서 지원되고, 클라우드 규모 및 운영 모델을 위해 설계되었으며, 본질적으로 공급업체에 구애받지 않습니다. 워크로드 디자인을 표준화하는 방법으로 잘 알려진 패턴을 사용하는 것은 운영 우수성의 구성 요소입니다.
많은 디자인 패턴은 하나 이상의 아키텍처 핵심 요소들을 직접 지원합니다. 안정성을 지원하는 디자인 패턴은 워크로드 가용성, 자체 보존, 복구, 데이터 및 처리 무결성 및 오작동 억제의 우선 순위를 지정합니다.
안정성을 위한 디자인 패턴
다음 표에는 안정성 목표를 지원하는 클라우드 디자인 패턴이 요약됩니다.
| 패턴 | 요약 |
|---|---|
| 특사 | 네트워크 통신과 관련된 교차 절단 작업을 오프로드하여 네트워크 통신을 캡슐화하고 관리합니다. 결과 도우미 서비스는 클라이언트를 대신하여 통신을 시작합니다. 이 조정 지점은 다시 시도 또는 버퍼링과 같은 네트워크 통신에 안정성 패턴을 추가할 수 있는 기회를 제공합니다. |
| 프런트 엔드에 대한 백 엔드 | 특정 프런트 엔드 인터페이스에만 적용되는 별도의 서비스를 만들어 워크로드의 서비스 계층을 개별화합니다. 이러한 분리로 인해 한 클라이언트를 지원하는 서비스 계층의 오작동은 다른 클라이언트의 액세스 가용성에 영향을 미치지 않을 수 있습니다. 다양한 클라이언트를 다르게 처리할 때 예상되는 클라이언트 액세스 패턴에 따라 안정성 작업의 우선 순위를 지정할 수 있습니다. |
| 격벽 | 오작동의 폭발 반경을 격리하기 위해 구성 요소 간에 의도적이고 완전한 구분을 도입합니다. 이 오류 격리 전략은 문제가 발생하는 격벽에만 오류를 포함하려고 시도하여 다른 격벽에 미치는 영향을 방지합니다. |
| Cache-Aside | 요청 시 채워진 캐시를 도입하여 자주 읽는 데이터에 대한 액세스를 최적화합니다. 그런 다음 캐시는 동일한 데이터에 대한 후속 요청에 사용됩니다. 캐싱은 데이터 복제를 만들고, 제한된 방법으로 원본 데이터 저장소를 일시적으로 사용할 수 없는 경우 자주 액세스하는 데이터의 가용성을 유지하는 데 사용할 수 있습니다. 또한 캐시에 오작동이 발생하면 워크로드가 원본 데이터 저장소로 대체됩니다. |
| 회로 차단기 | 오작동하거나 사용할 수 없는 종속성에 대한 지속적인 요청을 방지합니다. 이렇게 하면 이 패턴은 오류 종속성을 오버로드하는 것을 방지합니다. 이 패턴을 사용하여 워크로드에서 정상적인 저하를 트리거할 수도 있습니다. 회로 차단기는 자동 복구와 결합되어 자기 보존과 자가 복구를 모두 제공하는 경우가 많습니다. |
| 클레임 검사 | 메시지 흐름과 데이터를 구분하여 메시지와 관련된 데이터를 별도로 검색하는 방법을 제공합니다. 메시지 버스는 전용 데이터 저장소에 있는 것과 동일한 안정성 및 재해 복구를 제공하지 않으므로 메시지에서 데이터를 분리하면 기본 데이터에 대한 안정성을 높일 수 있습니다. 또한 이 분리를 통해 재해 후 메시지 큐 복구 접근 방식을 사용할 수 있습니다. |
| 보정 트랜잭션 | 이전에 적용된 작업의 효과를 반전하여 오류로부터 복구하는 메커니즘을 제공합니다. 이 패턴은 보정 작업을 사용하여 중요한 워크로드 경로의 오작동을 해결합니다. 여기에는 데이터 변경 내용을 직접 롤백하거나 트랜잭션 잠금을 끊거나 네이티브 시스템 동작을 실행하여 효과를 되돌리는 등의 프로세스가 포함될 수 있습니다. |
| 경쟁 소비자 | 분산 및 동시 처리를 적용하여 큐의 항목을 효율적으로 처리합니다. 이 모델은 소비자를 복제본으로 처리하여 큐 처리에서 중복성을 빌드하므로 instance 실패로 인해 다른 소비자가 큐 메시지를 처리하는 것을 막을 수 없습니다. |
| 이벤트 소싱 | 상태 변경을 일련의 이벤트로 처리하여 변경할 수 없는 추가 전용 로그에 캡처합니다. 복잡한 비즈니스 프로세스에서 신뢰할 수 있는 변경 기록이 중요한 경우 이 패턴을 사용할 수 있습니다. 또한 상태 저장소를 복구해야 하는 경우 상태 재구성을 용이하게 합니다. |
| 페더레이션 ID | 사용자를 관리하고 애플리케이션에 대한 인증을 제공하기 위해 워크로드 외부에 있는 ID 공급자에게 트러스트를 위임합니다. 사용자 관리 및 인증을 오프로드하면 해당 구성 요소의 안정성이 일반적으로 높은 SLA를 가진 ID 공급자로 전환됩니다. 또한 워크로드 재해 복구 중에는 인증 구성 요소를 워크로드 복구 계획의 일부로 해결할 필요가 없습니다. |
| 게이트웨이 집계 | 단일 요청에서 여러 백 엔드 서비스에 대한 호출을 집계하여 워크로드와의 클라이언트 상호 작용을 간소화합니다. 이 토폴로지를 사용하면 일시적인 오류 처리를 클라이언트의 분산 구현에서 중앙 집중식 구현으로 전환할 수 있습니다. |
| 게이트웨이 오프로딩 | 요청을 백 엔드 노드로 전달하기 전과 후에 게이트웨이 디바이스에 요청 처리를 오프로드합니다. 이 책임을 게이트웨이에 오프로드하면 백 엔드 노드에서 애플리케이션 코드의 복잡성이 줄어듭니다. 경우에 따라 오프로드는 기능을 신뢰할 수 있는 플랫폼 제공 기능으로 완전히 대체합니다. |
| 게이트웨이 라우팅 | 들어오는 네트워크 요청을 요청 의도, 비즈니스 논리 및 백 엔드 가용성에 따라 다양한 백 엔드 시스템으로 라우팅합니다. 게이트웨이 라우팅을 사용하면 시스템의 정상 노드로만 트래픽을 라우팅할 수 있습니다. |
| 지오드 | 여러 지역에 걸쳐 활성-활성 가용성 모드로 작동하는 시스템을 배포합니다. 이 패턴은 데이터 복제를 사용하여 모든 클라이언트가 지리적 instance 연결할 수 있는 이상적인 기능을 지원합니다. 워크로드가 하나 이상의 지역 중단을 견딜 수 있습니다. |
| 상태 엔드포인트 모니터링 | 해당 용도로 특별히 설계된 엔드포인트를 노출하여 시스템의 상태 또는 상태 모니터링하는 방법을 제공합니다. 이 엔드포인트를 사용하여 워크로드의 상태를 관리하고 경고 및 대시보드를 관리할 수 있습니다. 자가 복구 수정을 위한 신호로 사용할 수도 있습니다. |
| 인덱스 테이블 | 클라이언트가 데이터를 직접 검색할 수 있도록 메타데이터를 조회할 수 있도록 하여 전체 데이터 저장소 검사를 수행할 필요가 없도록 하여 분산 데이터 저장소에서 데이터 검색을 최적화합니다. 클라이언트는 조회 프로세스를 통해 분할, 파티션 또는 엔드포인트를 가리키므로 이 패턴을 사용하여 데이터 액세스에 대한 장애 조치(failover) 접근 방식을 용이하게 할 수 있습니다. |
| 리더 선택 | 분산 애플리케이션 인스턴스의 리더 를 설정합니다. 리더는 목표 달성과 관련된 책임을 조정합니다. 이 패턴은 작업을 안정적으로 리디렉션하여 노드 오작동의 영향을 완화합니다. 또한 리더가 오작동할 때 합의 알고리즘을 통해 장애 조치(failover)를 구현합니다. |
| 파이프 및 필터 | 복잡한 데이터 처리를 일련의 독립적인 단계로 나누어 특정 결과를 달성합니다. 각 단계의 단일 책임은 집중된 주의를 가능하게 하고 데이터 처리가 섞이는 방해를 방지합니다. |
| 우선 순위 큐 | 우선 순위가 낮은 항목보다 우선 순위가 높은 항목이 처리되고 완료되도록 합니다. 비즈니스 우선 순위에 따라 항목을 분리하면 가장 중요한 작업에 안정성 노력을 집중할 수 있습니다. |
| 게시자/구독자 | 중간 메시지 브로커 또는 이벤트 버스를 통해 직접 클라이언트-서비스 또는 클라이언트-서비스 통신과 통신을 대체하여 아키텍처의 구성 요소를 분리합니다. |
| 큐 기반 부하 평준화 | 큐에서 버퍼링하고 큐 프로세서가 제어된 속도로 처리하도록 하여 들어오는 요청 또는 작업의 수준을 제어합니다. 이 방법은 작업의 도착을 처리에서 분리하여 갑작스러운 수요 급증에 대한 복원력을 제공할 수 있습니다. 또한 큐 처리에서 오작동을 격리하여 섭취에 영향을 주지 않도록 할 수 있습니다. |
| 속도 제한 | 클라이언트 요청 속도를 제어하여 제한 오류를 줄이고 무제한 재시도 오류 시나리오를 방지합니다. 이 전술은 서비스가 지정된 제한에 도달하지 않도록 설계된 경우 서비스와 통신하는 데 드는 제한 사항 및 비용을 인정하여 클라이언트를 보호합니다. 특정 기간 동안 서비스로 전송되는 작업의 수 및/또는 크기를 제어하여 작동합니다. |
| 다시 시도 | 제어된 방식으로 특정 작업을 다시 시도하여 일시적이거나 간헐적일 수 있는 오류를 해결합니다. 분산 시스템에서 일시적인 오류를 완화하는 것은 워크로드의 복원력을 개선하기 위한 핵심 기술입니다. |
| Saga 분산 트랜잭션 | 작업을 더 작고 독립적인 트랜잭션 시퀀스로 분해하여 장기 실행 및 잠재적으로 복잡한 트랜잭션을 조정합니다. 또한 각 트랜잭션에는 실행 실패를 되돌리고 무결성을 유지하기 위한 보상 작업이 있어야 합니다. 여러 분산 시스템의 모놀리식 트랜잭션은 일반적으로 불가능하기 때문에 이 패턴은 원자성 및 보정을 구현하여 일관성과 안정성을 제공합니다. |
| Scheduler 에이전트 감독자 | 시스템에서 관찰 가능한 요인에 따라 시스템 전체에 작업을 효율적으로 배포하고 재배포합니다. 이 패턴은 상태 메트릭을 사용하여 오류를 감지하고 오작동의 영향을 완화하기 위해 작업을 정상 에이전트로 다시 라우팅합니다. |
| 순차 호위(convoy) | 정의된 순서로 처리를 지원하면서 동시 메시징 수신을 유지 관리합니다. 이 패턴은 문제 해결이 어려운 경합 조건, 논쟁의 여지가 있는 메시지 처리 또는 오작동으로 이어질 수 있는 잘못된 순서의 메시지를 해결하기 위한 기타 해결 방법을 제거할 수 있습니다. |
| 분할 | 특정 요청을 처리하기 위해 특정 논리 대상으로 로드를 전달하여 최적화를 위해 공동 배치를 사용하도록 설정합니다. 데이터 또는 처리는 분할된 데이터베이스로 격리되므로 한 분할된 데이터베이스의 오작동은 해당 분할된 데이터베이스에 격리된 상태로 유지됩니다. |
| 스트랭글러 그림 | 시스템을 마이그레이션하거나 현대화하는 동안 실행 중인 시스템의 구성 요소를 새 구성 요소로 체계적으로 교체하는 방법을 제공합니다. 이 패턴의 증분 접근 방식은 전환 중에 위험을 완화하는 데 도움이 될 수 있습니다. |
| 제한 | 리소스 또는 구성 요소에 들어오는 요청의 속도 또는 처리량에 제한을 적용합니다. 오작동으로 이어질 수 있는 리소스 소모를 방지하기 위해 제한을 디자인할 수 있습니다. 이 패턴을 정상적인 성능 저하 계획에서 제어 메커니즘으로 사용할 수도 있습니다. |
다음 단계
다른 Azure Well-Architected Framework 핵심 요소들을 지원하는 클라우드 디자인 패턴을 검토합니다.