엔터프라이즈를 위한 통합(integration) 아키텍처 설계

오늘의 주간SaaS 소개 글

SaaS 서비스를 구축할 때, 다양한 시스템들을 효과적으로 통합하는 것은 매우 중요한 과제입니다. 다양한 유형의 클라이언트, 내부 서비스 그리고 고객 관리, 결제, 마케팅 자동화 등 여러 솔루션들이 유기적으로 연동 되어야만 비로소 SaaS가 제대로 된 가치를 발휘할 수 있기 때문입니다. 

이 글에서는 SaaS 개발자와 아키텍트를 위해 중요한 통합 아키텍처 설계 패턴과 핵심 구성 요소들을 이해하기 쉽게 정리할 뿐 아니라 각 패턴의 장단점과 실제 적용 시 고려해야 할 사항들을 제시합니다.

기업 통합 아키텍처 설계

기업들은 저마다 다른 통합 문제에 직면합니다. 어떤 기업은 Salesforce에서 발생하는 판매 이벤트를 기반으로 SAP ERP 시스템에 데이터를 생성하는 것과 같이, 단순히 몇 개의 지점 간 연결만 구현하면 될 수 있습니다. 반면, 온라인 구매를 위한 모바일 앱을 제공하기 위해 재고, 판매 및 유통 시스템을 상호 연결해야 하는 경우도 있습니다. 또한 이러한 통합 작업은 중앙 팀에서 수행할 수도 있고 여러 독립적인 팀에서 개발할 수도 있습니다. 매우 높은 확장성이 요구되는 통합도 있고 비용에 민감한 통합도 있습니다.

각 통합 문제에 가장 적합한 아키텍처 역시 통합의 특성에 따라 다릅니다. 이 글에서는 다양한 통합 프로젝트에 사용할 수 있는 몇 가지 아키텍처 패턴을 살펴보겠습니다.

통합 아키텍처의 구성 요소

통합 아키텍처에 대해 자세히 알아보기 전에 먼저 통합 아키텍처에서 일반적으로 사용되는 구성 요소와 그 용도를 이해하는 것이 좋습니다.

1. 통합 플랫폼:

통합 아키텍처의 핵심 구성 요소입니다. 통합 플랫폼은 통합 흐름을 실행하고 다른 시스템과 통합하기 위한 다양한 커넥터와 프로토콜을 제공합니다. 또한 여러 시스템 간에 데이터 구조를 매핑하는 고급 데이터 변환 기능도 포함합니다.

2. API 관리:

서비스 호출에 대한 인증, 액세스 제어, 속도 제한 및 사용량 모니터링을 제공하여 통합된 서비스를 API로 제공합니다.

사용 시기: 통합 서비스가 외부 당사자 또는 다른 사업부에 공개되는 경우.

3. ID 및 액세스 관리(IAM) 시스템:

통합 배포에 대한 고급 보안 기능을 제공합니다.

사용 시기: API 관리자도 인증 및 액세스 제어와 같은 특정 수준의 보안 기능을 제공합니다. 다단계 인증, 액세스 제어 정책 및 완벽한 사용자 관리와 같은 고급 보안 기능을 지원해야 하는 경우 IAM 시스템을 사용할 수 있습니다.

4. 레지스트리:

통합 아티팩트를 저장하는 중앙 집중식 위치를 제공합니다.

사용 시기: 엔드포인트 및 데이터 스키마와 같은 특정 통합 아티팩트는 여러 통합에서 재사용될 수 있습니다. 또한 서비스 재배치로 인해 엔드포인트가 변경될 수 있습니다. 이러한 경우 이러한 통합 아티팩트를 레지스트리에 저장하고 모든 통합이 레지스트리에서 해당 아티팩트를 조회하도록 구성하는 것이 좋습니다.

5. 메시징 플랫폼:

메시지 지속성을 통해 메시지의 게시-구독 및 멀티캐스트 전달을 제공합니다.

사용 시기: 메시지 수신자가 자주 변경되어야 하고 처리 중 메시지 손실을 방지해야 하는 경우.

6. 관측 가능성 구성 요소:

사용량 대시보드, 메시지 흐름 분석, 로그 분석, 리소스 소비 지표 및 사전 구성된 임계값 기반 알림과 같은 배포에 대한 모니터링 및 분석 기능을 제공합니다.

사용 시기: 배포 상태를 파악하고 예방 조치를 취하는 데 유용합니다.

이제 통합 아키텍처의 구성 요소에 대한 이해를 바탕으로 다양한 아키텍처와 그 용도를 살펴보겠습니다.

중앙 집중식 통합

이 아키텍처에서는 중앙 통합 플랫폼을 사용하여 통합을 배포합니다. API 관리자 및 아키텍처의 다른 구성 요소도 중앙 집중식으로 배포됩니다. 중앙 통합 플랫폼과 다른 구성 요소는 일반적으로 확장성과 고가용성을 위해 두 개 이상의 인스턴스로 구성된 클러스터로 배포됩니다. 중앙 집중식 통합 아키텍처는 다음과 같습니다.

이 아키텍처에서는 두 개의 API 게이트웨이를 사용하여 외부 및 내부 트래픽을 처리합니다. 이를 통해 외부 API 게이트웨이에 대해서만 외부 요청을 허용하는 것과 같은 네트워크 보안 정책을 시행할 수 있습니다. 통합 아키텍처의 모든 구성 요소는 사용량 지표, 오류 세부 정보 및 로그와 같은 관측 가능성 데이터를 관측 가능성 구성 요소에 게시하여 시스템에 대한 포괄적인 보기를 제공합니다. 실제로 이 관측 가능성 구성 요소는 로그 분석을 위한 ELK, 런타임 지표를 위한 Prometheus, 추적을 위한 Jaeger와 같은 여러 시스템으로 구성될 수 있습니다.

중앙 집중식 통합을 사용하는 경우

중앙 집중식 통합은 조직의 모든 통합이 중앙 팀에서 관리되는 경우에 유용합니다. 여러 팀이 통합을 개발할 수는 있지만 통합 배포는 중앙 팀에서 수행하거나 승인합니다. 통합의 운영 측면도 이 중앙 팀에서 처리합니다. 이 아키텍처는 보다 효율적이고 간단한 통합 관리를 용이하게 하고 일반적으로 인프라 요구 사항이 적습니다. 이 방식의 주요 단점은 통합 개발자가 배포를 위해 중앙 팀에 의존해야 하므로 통합 개발의 민첩성이 저하된다는 것입니다.

마이크로서비스 스타일 통합(마이크로 통합)

이 아키텍처에서는 통합이 마이크로서비스로 배포됩니다. 일반적으로 단일 팀에서 개발하는 단일 통합 작업과 관련된 적은 수의 통합이 하나의 통합 런타임에 배포됩니다. 통합 작업 및 개발 팀의 수에 따라 여러 개의 통합 런타임이 배포됩니다. API 관리 구성 요소도 마이크로서비스 스타일(즉, 마이크로 API 게이트웨이)에 따라 배포할 수 있습니다. 일반적으로 이러한 통합 런타임은 리소스 소비를 줄이고 Kubernetes와 같은 컨테이너 환경에서 배포를 지원하도록 특별히 설계되었습니다. 아래 다이어그램은 마이크로서비스 스타일 통합 아키텍처를 보여줍니다.

위 아키텍처에는 세 가지 통합이 표시되어 있으며 각 통합은 자체 통합 런타임에 배포됩니다. 통합 1(Integration 1)과 2(Integration 2)는 마이크로 API 게이트웨이를 통해 외부에 노출됩니다. 각 API는 자체 API 게이트웨이에 배포되므로 해당 마이크로 통합을 개발하는 팀에서 독립적으로 관리할 수도 있습니다. 통합 3(Integration 3)은 백엔드 시스템만 연결하므로 외부에 노출되지 않습니다.

마이크로 통합을 사용하는 경우

마이크로 통합은 많은 수의 팀 간에 보다 독립적인 통합 개발을 용이하게 해야 하는 경우에 유용합니다. 중앙 집중식 관리 프로세스로 인한 병목 현상을 줄여 통합을 신속하게 프로덕션 환경에 적용하고 점진적으로 개선할 수 있습니다. 주요 단점 중 일부는 통합 런타임 관리를 위해 Kubernetes와 같은 컨테이너 플랫폼이 필요하고 통합에 대한 전반적인 분석을 얻기 위해 복잡한 모니터링 솔루션을 구현해야 한다는 것입니다.

중앙 집중식 통합과 마이크로 통합의 혼합

이 아키텍처는 중앙 집중식 통합과 마이크로 통합을 모두 용이하게 합니다. 따라서 이 아키텍처의 통합 계층은 중앙 통합 플랫폼과 여러 마이크로 통합 런타임으로 구성됩니다. API 계층에는 중앙 집중식 API 게이트웨이와 API 마이크로 게이트웨이가 조합되어 있을 수도 있습니다. 이 아키텍처는 아래 그림에 나와 있습니다.

다이어그램에 표시된 것처럼 마이크로 통합은 중앙 통합에 대한 구성 가능한 서비스 역할을 할 수 있습니다. 또한 마이크로 통합은 마이크로 API 게이트웨이나 메시징 시스템을 통해 중앙 통합에 노출되어 인증, 액세스 제어 및 안정성을 용이하게 할 수 있습니다.

혼합형 통합 아키텍처를 사용하는 경우

대기업에는 두 가지 범주의 통합, 즉 일반적으로 단일 사업부에서 액세스하는 하위 수준 서비스를 연결하는 통합과 여러 사업부에 걸쳐 있고 중요한 서비스에 액세스하는 통합이 있을 수 있습니다. 이 시나리오에서 첫 번째 범주의 통합은 사업부 내에서 개발 및 프로덕션 환경에 적용할 수 있는 마이크로 통합으로 배포할 수 있습니다. 두 번째 범주에는 여러 이해 관계자의 승인 및 여러 서비스에 대한 액세스 권한이 있는 보다 엄격한 관리가 필요합니다. 따라서 이러한 통합은 중앙 집중식으로 구현할 수 있습니다.

마무리

이 글에서 설명한 아키텍처 패턴은 통합 프로젝트에 적합한 아키텍처를 선택하기 위한 지침이 될 수 있습니다. 그러나 아키텍처 내에서 아키텍처 및 구성 요소를 선택할 때는 통합의 특성, 비기능적 요구 사항, 조직 규모, 사용 가능한 인프라 및 예산과 같은 요소를 고려해야 합니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요