Azure
Azure Logic Apps
동일한 의미 체계를 공유하지 않는 서로 다른 하위 시스템 간에 외관 또는 어댑터 계층을 구현합니다. 이 계층은 한 하위 시스템이 다른 하위 시스템에 만드는 요청을 변환합니다. 이 패턴을 사용하여 애플리케이션의 디자인이 외부 하위 시스템에 대한 종속성에 의해 제한되지 않도록 합니다. 이 패턴은 Domain-Driven 디자인에서 에릭 에반스에 의해 처음 설명되었다.
컨텍스트 및 문제
대부분의 애플리케이션은 일부 데이터 또는 기능에 다른 시스템을 사용합니다. 예를 들어 레거시 애플리케이션을 최신 시스템으로 마이그레이션하는 경우에도 기존 레거시 리소스가 필요할 수 있습니다. 새 기능은 레거시 시스템을 호출할 수 있어야 합니다. 특히 대규모 애플리케이션의 다양한 기능이 시간이 지남에 따라 최신 시스템으로 이동하는 점진적 마이그레이션의 경우 특히 그렇습니다.
이러한 레거시 시스템은 복잡한 데이터 스키마 또는 사용되지 않는 API와 같은 품질 문제로 어려움을 겪는 경우가 많습니다. 레거시 시스템에 사용되는 기능과 기술은 최신 시스템과 크게 다를 수 있습니다. 레거시 시스템과 상호 운용하기 위해 새 애플리케이션은 오래된 인프라, 프로토콜, 데이터 모델, API 또는 최신 애플리케이션에 추가하지 않는 기타 기능을 지원해야 할 수 있습니다.
새 시스템과 레거시 시스템 간의 액세스를 유지 관리하면 새 시스템이 레거시 시스템의 API 또는 기타 의미 체계 중 일부를 준수하도록 강제할 수 있습니다. 이러한 레거시 기능에 품질 문제가 있는 경우 이를 지원하면 완전히 디자인된 최신 애플리케이션이 될 수 있는 것이 "손상"됩니다.
개발 팀이 레거시 시스템뿐만 아니라 제어하지 않는 외부 시스템에서도 비슷한 문제가 발생할 수 있습니다.
해결 방법
손상 방지 계층을 배치하여 서로 다른 하위 시스템을 격리합니다. 이 계층은 두 시스템 간의 통신을 변환하여 한 시스템이 변경되지 않은 상태로 유지되고 다른 시스템은 설계 및 기술 접근 방식을 손상시키지 않도록 할 수 있습니다.
위의 다이어그램은 두 개의 하위 시스템이 있는 애플리케이션을 보여 줍니다. 하위 시스템 A는 손상 방지 계층을 통해 하위 시스템 B를 호출합니다. 하위 시스템 A와 손상 방지 계층 간의 통신은 항상 하위 시스템 A의 데이터 모델과 아키텍처를 사용합니다. 손상 방지 계층에서 하위 시스템 B로의 호출은 해당 하위 시스템의 데이터 모델 또는 메서드를 준수합니다. 손상 방지 계층에는 두 시스템 간에 변환하는 데 필요한 모든 논리가 포함됩니다. 계층은 애플리케이션 내의 구성 요소 또는 독립적인 서비스로 구현할 수 있습니다.
문제 및 고려 사항
- 손상 방지 계층은 두 시스템 간의 호출에 대기 시간을 추가할 수 있습니다.
- 손상 방지 계층은 관리 및 유지 관리해야 하는 추가 서비스를 추가합니다.
- 손상 방지 계층의 크기를 조정하는 방법을 고려합니다.
- 둘 이상의 손상 방지 계층이 필요한지 여부를 고려합니다. 다양한 기술 또는 언어를 사용하여 기능을 여러 서비스로 분해하거나 손상 방지 계층을 분할하는 다른 이유가 있을 수 있습니다.
- 다른 애플리케이션 또는 서비스와 관련하여 손상 방지 계층을 관리하는 방법을 고려합니다. 모니터링, 릴리스 및 구성 프로세스에 어떻게 통합되나요?
- 트랜잭션 및 데이터 일관성이 유지 관리되고 모니터링될 수 있는지 확인합니다.
- 손상 방지 계층이 서로 다른 하위 시스템 간의 모든 통신을 처리해야 하는지 또는 기능의 하위 집합만 처리해야 하는지 고려합니다.
- 손상 방지 계층이 애플리케이션 마이그레이션 전략의 일부인 경우 영구 계층인지 아니면 모든 레거시 기능이 마이그레이션된 후 사용 중지될 것인지를 고려합니다.
- 이 패턴은 위의 고유한 하위 시스템을 사용하여 설명되지만, 모놀리식 아키텍처에서 레거시 코드를 함께 통합하는 경우와 같이 다른 서비스 아키텍처에도 적용할 수 있습니다.
이 패턴을 사용하는 경우
다음 경우에 이 패턴을 사용합니다.
- 마이그레이션은 여러 단계에서 수행될 예정이지만 새 시스템과 레거시 시스템 간의 통합을 유지 관리해야 합니다.
- 둘 이상의 하위 시스템에는 서로 다른 의미 체계가 있지만 여전히 통신해야 합니다.
새 시스템과 레거시 시스템 간에 의미 체계 차이가 큰 경우 이 패턴이 적합하지 않을 수 있습니다.
워크로드 디자인
설계자는 손상 방지 계층 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 다음은 그 예입니다.
| 기둥 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 운영 우수성표준화된 프로세스 팀 응집력을 통해 워크로드 품질 제공하는 데 도움이 됩니다. | 이 패턴은 이러한 레거시 시스템과 통합할 때 다른 데이터 모델 또는 비즈니스 규칙을 가질 수 있는 레거시 구현에 의해 새 구성 요소 디자인이 영향을 받지 않도록 하고 기존 구성 요소를 계속 지원하면서 새 구성 요소의 기술 문제를 줄일 수 있도록 합니다. - OE:04 도구 및 프로세스 |
디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.