BLOG
SaaS (Software-as-a-Service) 기업이 늘어나고 전 세계적를 대상으로 서비스가 확장되기 시작함에 따라 더 넓은 지리적 확장을 어떻게 대응해야 할지, 이는 시스템 아키텍처에 어떤 영향을 미치는지 고려 해야 할 필요가 있습니다. 지리적으로 분산 된 SaaS 모델로 전환 하는 것은 운영, 배포, 민첩성, 보안 및 확장성 모든 측면에 영향을 줄 수 있습니다.
이러한 멀티 리전 모델로의 이행은 종종 SaaS 기업의 주요 변화를 시사합니다. 시스템의 운영 및 배포 프로필에 복잡성이 추가 될수록 종종 SaaS 전달 모델과 관련된 민첩성에 대한 목표를 유지하기가 더욱 어려워집니다.
이 블로그는 시장에 대한 신속한 대응을 유지하되 멀티 리전 배포 요구사항을 수용 해야 하는 어려움에 대해 초점을 맞춰 다룹니다. 여기서의 목표는SaaS 기업이 멀티 리전 전략을 채택한 데 영향을 준 요소를 살펴 보는 것입니다. 이러한 동기를 배경으로 하여 멀티 리전의 SaaS 환경을 구축, 배포 및 관리 할 때 일반적으로 사용되는 아키텍처 패턴과 전략을 파헤칠 수 있습니다.
멀티 리전 문제의 범주
멀티 리전 아키텍처의 주제는 매우 광범위 하여, 시스템 아키텍처의 많은 측면에 영향을 줄 수 있는 광범위한 아키텍처 상의 고려 사항을 다루고 있습니다. AWS에는 멀티 리전 아키텍처에 대한 일반적인 지침을 제공하는 유용한 리소스 모음이 있습니다. 개별 서비스, 네트워크 모델 및 일반적인 장애 조치 패턴의 멀티 리전 기능을 살펴 보는 블로그 게시물 및 백서가 있습니다. 이 게시 글의 끝에 멀티 리전 참조 자료의 샘플들을 포함하였습니다.
이 논의의 목적 상, 멀티 리전 SaaS 환경과 관련된 뉘앙스와 동기에 초점을 맞추는 것이 더 합리적입니다. 이러한 지침은 멀티 리전 전략의 광범위한 적용 범위와 연계하여, 전체적인 멀티 리전 전략에 넣을 수 있는 기본적인 고려 사항 또한 갖추어야 합니다.
멀티 리전 SaaS로 전환 한 이유는 무엇일까요?
멀티 리전 아키텍처를 살펴보기 전에 일부 SaaS 서비스사업자를 멀티 리전 모델로 이행을 드라이브하는 역학 관계를 이해하는 것부터 해 봅시다. 대부분의 경우 SaaS ISV기업들은 종래의 엣지 기반 컨텐츠 배포 전략을 통해 기본적인 지리적 문제를 대처 할 수 있습니다. 예를 들어 Amazon CloudFront를 사용하면 지리적 분포와 관련된 레이턴시 문제를 해결할 수 있습니다.
이 문제는 단순한 정적인 컨텐츠 배포보다는 가용성, 성능 및 지역적 고려 사항에 더 중점을 둔다는 것에 포인트가 있습니다. 이 경우 멀티 리전 목표를 달성하기 위해서는 새로운 사용자 정의 메커니즘을 도입 해야 합니다. 이하의 내용은 SaaS 서비스사업자가 멀티 리전 모델로 이동하도록 동기를 부여하는 일반적인 요소에 대한 목록입니다.
- Failover : 지역적으로 시스템 장애 발생 시, 시스템의 일부 또는 전체가 로딩을 대체 지역으로 효과적으로 전환하여 장애를 극복 할 수 있는 기능
- Latency : 긴 네트워크 홉의 오버 헤드를 발생시키지 않은 채 비 정적 데이터를 처리하고 제공 해야 할 필요성.
- Compliance : 지역별 컴플라이언스 요구 사항의 차이는 데이터 및 서비스가 반드시 지역적 내 호스팅되어야 함을 의미.
Failover는 지역에 국한된 애플리케이션 문제를 견딜 수 있는 재해 복구 모델을 채택하는 것 보다 광범위한 멀티 리전의 주제입니다. 이 모드에서 SaaS 서비스사업자는 주로 일부 또는 모든 환경을 다른 지역으로 복제하는 방법들을 모색하곤 합니다. 장애가 발생하면 시스템이 트래픽을 정상적으로 다른 지역으로 리디렉션 할 수 있습니다.
Failover는 SaaS 솔루션 내에 다양한 모델들로, 다양한 수준으로 구현 될 수 있습니다. 여기서 여러분이 선택한 접근 방식은 아키텍처 본연의 특성과 시스템의 분해에 따라 결정 될 겁니다. 또한 SaaS 솔루션에서 사용 중인 다양한 툴 및 서비스의 Replication 역량에도 영향을 받을 수 있습니다. 강력한 Failover 전략을 세우는 것은, 모든 지역 별 고객을 단일화된 공유 인프라 공간에서 호스팅 할 수 있는 SaaS 서비스사업자에게는 특히 중요 할 수 있습니다. 이러한 모델에서는 지역 중심 애플리케이션 문제의 파급력을 제한하기 위해 크로스 리전 모델을 선택할 수 있습니다.
반면, Latency과 Compliance는 SaaS 서비스사업자가 멀티 리전 전략을 채택하는 데 가장 일반적인 요인입니다. 일부 글로벌 SaaS 서비스사업자의 경우 애플리케이션에 대한 액세스 패턴 및 일반 사용량 모델을 통해 단일 지역에 솔루션을 수용하기가 어렵습니다. Edge 기반 콘텐츠가 도움이 될 수 있지만 CDN에서 제대로 다루지 못하는 일부 애플리케이션 Flow도 있습니다. 하나 이상의 애플리케이션 서비스에서 직접 제공 해야 하는 데이터를 처리하는 애플리케이션의 측면이 있는 경우가 있습니다. 이 경우 일부 또는 모든 애플리케이션을 지역에 직접 배포하는 것이, 자연스럽게 되는 전환점에 빨리 도달 할 수 있습니다. 예를 들어 광고의 밀리 초 렌더링이 필요한 광고 게재 플랫폼을 구축 한 경우, 1개의 지역에서 컨텐츠의 제공이 불충분할 가능성이 있습니다.
Compliance는 종종 데이터 프라이버시를 관리하는 지역별 규제에 의해 결정됩니다. 데이터 주권 및 일반 데이터 보호 규정 (GDPR)의 요구 사항은 종종 멀티 리전 전략의 일부를 통해서만 성공적으로 해결 될 수 있는 제한으로 작용 합니다. 심지어 이러한 시나리오에서도 지역별 Compliance 문제의 영향을 받는 애플리케이션의 일부 만을 선택할 수 있는 옵션이 있습니다. 이러한 경우, 보다 복잡한 아키텍처 범주를 배포, 관리 해야 하는 복잡성의 균형을 찾으려 할 것입니다. 일반적으로 이러한 시나리오라면 서비스사업자는 전체 SaaS 솔루션을 지역 내로 옮기는 것을 선하는 편입니다.
멀티 리전 모델의 영향
이제 SaaS 서비스사업자를 멀티 리전 모델로 푸시 할 수 있는 몇 가지 공통 주제를 잘 처리 했으므로 멀티 리전 모델의 도입이 SaaS 솔루션의 설계, 아키텍처, 운영 및 민첩성에 어떤 영향을 미치는지 살펴 보겠습니다. 여기에서 가장 중요한 목표는 대부분의 SaaS 솔루션의 가장 근원인 민첩성 목표를 완전히 손상시키지 않으면서 멀티 리전 개념을 도입 할 수 있는 방법을 찾는 것입니다.
다음 섹션에서는 멀티 리전 SaaS 모델로 이동할 때 고려해야 할 주요 영역 중 몇 가지를 강조합니다. 아래 내용은 포괄적인 목록은 아니지만 많은 SaaS 기업이 마주하는 공통적인 어려움 중 일부를 대표 합니다.
Tenant Onboarding
끊김 없는 고객 온보딩 경험을 제공하는 것은 SaaS기업들의 필수 과제 입니다. 여기서의 핵심은 신규 고객 유치와 고객 환경을 프로비저닝하는 프로세스를 간소화하는 것입니다. 만약, SaaS 솔루션이 여러 지역에서 호스팅 되는 경우 온보딩 프로세스에 해당 절차가 추가 될 수도 있습니다.
그림 1 은 멀티 리전 모델에서 신규 테넌트를 온보딩 할 때 적용되는 한 방법을 보여줍니다. 여러 지역에서 새로이 SaaS 솔루션을 가입한 테넌트 그룹이 있는걸 볼 수 있습니다. 이 모델 내에서 테넌트 들은 가입 과정에서 대상 리전을 구분 할 수 있는 데이터를 제공합니다. 그런 다음, 공유 온보딩 서비스가 이 데이터에 기반하여 지정된 리전 내에 신규 테넌트에 맞춘 프로비저닝 및 오케스트레이션을 담당합니다.
그림 1 – 중앙 집중식 온 보딩 모델.
이 모델은 단일 지역에서 온보딩 프로세스를 중앙 집중화 시키고자 합니다. 이 과정은 전체 프로세스를 단순화하고 능률화하지만, Compliance 측면에서는 어려움이 될 수 있습니다. 각 지역 외부로 사용자 정보를 수집 할경우, 특정 지역의 데이터 주권 요구 사항을 위반할 가능성이 있습니다. 그러나 Compliance 문제에 직면하지 않았다면, 위 접근 방식이 매력적일 수 있습니다.
이 전략의 대안은 온보딩 프로세스의 일부 측면을 탈중앙화 시키는 것입니다. 그림 2 는 온보딩 프로세스를 각 지역 별로 분산시키는 형태로 위 문제에 대한 대안을 나타냅니다.
그림 2 – 탈 중앙화 온 보딩 모델.
기본적인 차이점은 온보딩 경험을 이제 각 지역 별로 호스팅 한 것 입니다. 이에 따라 테넌트에 관해 수집 된 모든 데이터가 지역 범위 내에서 관리 될 수 있습니다. 이 모델의 주요 과제는 어떻게 테넌트들을 각 지역 온 보딩 경험으로 리디렉션되게 할 것인가를 결정하는 것입니다. 이 경우, 우리는 사용자가 직접 원하는 지역을 선택할 수 있는 랜딩/라우팅 페이지를 구성 하였습니다. 다만, 이것은 하나의 옵션일 뿐이며 각 SaaS 솔루션은 그들의 테넌트들을 올바른 지역에 랜딩 시키기 위한 다른 접근 방식을 취할 수 있습니다. 중요한 포인트는 테넌트의 실제 온보딩 과정과 테넌트에 대한 데이터 수집이 지역 내로 국한되어 있다는 것입니다.
결과적으로, 이전보다 조금 더 분산된 모델은 배포 모델에 복잡성이 추가되고 중앙화된 경험을 관리, 배포하는 기능을 잃게 됩니다. 하지만, GDPR 또는 일반 데이터 주권 요구 사항이 강력한 지역에 배포하는 경우 이것이 유일한 선택지인 경우가 많습니다.
멀티 리전 아이덴티티
테넌트를 성공적으로 온보딩 시킨 후에도 멀티 리전 환경에서 인증을 어떻게 지원 할지 결정 해야 합니다. 모든 사용자를 위한 중앙화된 모델의 아이덴티티 공급자가 있으면 좋지만, 이러한 데이터의 중앙 집중화는 개인 정보 관리를 요구하는 데이터 주권 요구 사항의 기본적인 사항과 배치되는 경우가 많습니다.
이를 염두에 두고 ID에 대한 접근 방식은 테넌트 경험과 각 지역으로 ID 관리를 효과적으로 라우팅 할 수 있는 메커니즘 도입에 중점을 두어야 합니다. 여러 측면에서, 여기에 요약 된 과제는 위에서 언급 한 온 보드 논의와 중복됩니다. 그러나 이제 사용자를 지역 중심 인증 환경으로 라우팅 하기 위한 비 침투적인 모델이 있어야합니다.
이상적으로는 특정 지역으로의 라우팅이 대부분 투명적인 테넌트에게 비교적 원활한 경험이 되길 원합니다. 이 문제를 해결하는 일반적인 방법 중 하나는 애플리케이션의 URL에 테넌트 문장을 포함시키는 것입니다. 그림 3 은 이것이 실제로 어떻게 보일지에 대한 샘플을 제공합니다.
그림 3 – URL을 사용하여 테넌트 인증을 라우팅 함
이 모델을 사용하면 각 테넌트에 온 보딩 경험의 일부로 프로비저닝 된 고유 한 URL이 할당됩니다. 이 예시 에서는 테넌트 범위를 응용 프로그램의 URL 앞에 추가하는 하위 도메인을 만들었습니다. 이 하위 도메인은 전통적인 DNS 라우팅 ( 그림 3의 Amazon Route 53 으로 표시 )을 사용하여 각 테넌트를 적절한 지역으로 보냅니다.
적절한 지역으로 라우팅 되면 SaaS 솔루션은 지역적으로 호스팅 되는 아이덴티티 공급자를 사용하여 시스템 사용자를 관리하고 인증합니다. 여기에서는 각 지역의 아이덴티티 공급자로 Amazon Cognito를 사용 했습니다 .
이 모델은 테넌트 프로비저닝 프로세스에 구성 요소와 움직이는 부분을 추가하는 동시에 최종 사용자에게 훨씬 직관적인 경험을 제공합니다. 하위 도메인 앞에 추가 된 테넌트 식별자는 실제 테넌트 식별자의 내부 표현에 직접 매핑 해서는 안됩니다. 대신, 이는 사용자를 해당 지역으로 라우팅 하는 목적으로 만 사용되는 고유 한 하위 도메인으로 표시됩니다.
애플리케이션이 인증하기 전에 테넌트에 의존하여 대상 지역 또는 환경을 선택 해야 하는 몇 가지 시나리오가 있습니다. 사용자가 여러 지역에 계정을 보유 할 수 있는 옵션이 있는 경우에 나타납니다. 이 경우 인증 경험의 일부로 영역을 표면 처리하는 것이 불가피 할 수 있습니다.
일부 솔루션의 경우 사용자가 기존 ID를 한 지역에서 다른 지역으로 이동하려는 ID 이식성을 지원해야 할 수 있습니다. 또한 이 특성을 전송할 수 있도록 사용자 관리 시스템에서 추가 워크 Flow가 필요할 수 있습니다. 또한 Compliance 규정에 이의를 제기 할 가능성이 있습니다.
관리 및 모니터링
고객 환경을 개별 지역에 배포하더라도 테넌트의 전반적인 상태를 관리하고 모니터 하기 위해 중앙 집중식 모델을 선호합니다. 실제로 보다 분산 된 멀티 리전 모델로 전환함에 따라 강력한 운영 도구의 필요성이 더욱 두드러집니다. 핵심은 운영 공간을 효율적으로 확장하는 메커니즘을 배치하여 중앙 집중식 경험을 통해 SaaS 환경의 지역 및 전 세계 건강을 관찰 할 수 있도록 하는 것입니다.
각 지역의 데이터를 중앙에서 집계하기 위해 사용 할 수 있는 여러 가지 접근 방식이 있습니다. 선택한 모델은 어플리케이션에 가장 적합한 스택 및 툴에 의해 구동됩니다. 예를 들어, 일부 솔루션은 데이터를 로컬로 캡쳐 한 후 여러 지역에 복제합니다. 다른 사람들은 로그 데이터를 일부 중앙 저장소로 직접 스트리밍 할 수 있습니다.
다행히도 APN 파트너 커뮤니티는 관리 모니터링 도메인에 여러 지역의 모니터링을 간소화 할 수 있는 다양한 솔루션을 포함하고 있습니다. Sumologic, New Relic, Datadog, 및 Dynatrace 는 다양한 모니터링 파트너 솔루션 중 하나입니다. 이러한 각 제품에는 멀티 리전 환경을 캡쳐하고 분석 하기 위한 고유 모델이 있습니다.
AWS에는 관리 환경을 구축하는 데 유용한 네트워킹 구성도 있습니다. 예를 들어 지역 간 VPC peering은 일부 조직에서 분산 환경을 관리하는 데 사용됩니다. 이를 통해 관리 공간에 보안을 추가하고 자동화 및 배포 환경을 단순화 할 수 있습니다. 당신이 의심한 대로, GDPR을 모니터링 전략에 포함 시켜야 합니다. 경우에 따라 로깅 중인 데이터가 완전히 제거 처리되고 GDPR 규정에 요약 된 요구 사항을 준수하는지 확인해야 할 수도 있습니다.
배포 자동화
민첩성은 SaaS 제공 모델 채택의 원동력 중 하나입니다. 그러나 멀티 리전 공간으로 전환하면 환경에 복잡성을 추가하고 민첩성 목표를 저해 할 수 있습니다. 예를 들어 배포는 여러 지역에서 제품을 출시하는 것과 관련된 자동화 및 DevOps 파이프 라인 영향을 고려할 때 훨씬 더 복잡한 프로세스가 됩니다.
멀티 리전 모델에서 민첩성을 유지하는 핵심은 각 배포에 대해 도입되는 변동량을 제한하는 것입니다. 이는 실제로 코드를 통해 구성의 모든 측면을 관리하는 반복 가능한 자동화 된 배포 프로세스를 만드는 데 중점을 둔 핵심 DevOps 원칙의 확장입니다.
그림 4 는 멀티 리전 파이프 라인의 개념도를 제공합니다. 여기에서의 목표는 각 지역 배포가 원래 단일 지역에서 호스팅 되었던 환경의 복제본으로 보는 것입니다. 멀티 리전 모델로 이동할 때 파이프 라인은 서비스에 최소한의 지역별 변경이 필요하기 때문에 각 변경 (이 경우 각 마이크로 서비스)을 대상 지역에 배포 해야 합니다. 궁극적으로, 모든 지역에서 차지하는 공간이 보편적 일수록 멀티 리전 모델이 민첩성을 저해하지 않는다는 느낌 없이, 새로운 기능을 출시 할 가능성이 높아집니다.
그림 4 – 멀티 리전 배포 인증
여기서 목표는 변동을 최소화하는 것이지만 일부 지역별 요구 사항으로 인해 파이프 라인에 새로운 요소를 추가 할 수도 있습니다. 예를 들어 Compliance의 유효성 검사를 담당하는 각 지역에서 파이프 라인에 다운 스트림 단계가 추가되는 것은 드문 일이 아닙니다. 지역별 구성 및 배포 변형을 유발할 수 있는 AWS 서비스 변형을 기반으로 하는 미묘한 차이가 있을 수 있지만 목표는 여전히 전체 파이프 라인의 확장으로 간주하는 것입니다.
비용 청구 (Billing)
관리 및 모니터링 서비스와 마찬가지로 비용 청구 부분은 중앙 집중식 모델을 사용하여 구현 해야 하는 서비스입니다. 궁극적으로 SaaS솔루션의 고객 계정, 정책 및 비용 청구 활동을 관리하는 하나의 사용자 경험이 필요하게 됩니다. SaaS 솔루션의 비용 청구서를 생성하는 데 필요한 사용량 미터링 및 활동량 데이터는 각 지역 내의 정보를 집계한 뒤 비용 청구서를 생성을 담당하는 중앙 시스템으로 전달하여 정보를 통합하고 계산서를 생성 해야 한다고 있다고 생각 합니다. 이 시스템은 고객의 상태, 정책 및 구성에 대한 업데이트를 각 지역으로 푸시 하는 역할도 합니다.
물론 이것이 선호되는 모델이지만, Compliance 또는 각종 규제로 인해 복잡 할 수 있습니다. 데이터 주권 또는 GDPR 요구 사항을 대응해야 하는 상황에서는 고객 정보가 지역을 벗어나지 않는, 보다 분산된 비용 청구 모델을 만들어야 합니다. 따라서 비용 청구 메커니즘은 모든 지역에서 동일하지만 각 지역마다 고유 한 청구서를 생성 해야 합니다. 이는 비용 청구 프로세스에 복잡성과 비효율성을 추가하지만 불가피 한 경우입니다.
멀티 리전 또는 다중 가용 영역
멀티 리전 모델로의 전환은 종종 지역에 따른 Latency 및 Compliance 이슈에 직면 한 SaaS 기업의 자연스러운 발전을 나타냅니다. 그러나 멀티 리전을 단순한 Failover 전략으로 도입하면 논의가 더욱 복잡해집니다. 경우에 따라, 다중 가용 영역 접근 방식은 멀티 리전 모델에 따른 추가 오버헤드 없이도, SaaS 솔루션의 Failover 요구 사항을 충족시킬 수 있습니다.
따라서, 멀티 리전 활용 필요성을 유발하는 요소를 명확하게 할 필요가 있습니다. 특히, 여러 옵션을 살펴볼 때, SaaS 솔루션의 전반적인 복잡성과 민첩성에 미치는 영향을 평가 해 보시기 바랍니다.
실질적인 이행을 위하여
멀티 리전 모델로의 이행은 결코 사소한 일이 아닙니다. 위에서 다룬 항목에서 알 수 있듯이 멀티 리전 환경에서 SaaS 솔루션을 제공하는 방법을 고려할 때 고려해야 할 여러 가지 요소가 있습니다. 온보딩, 인증, 운영 – 이 모든 영역에는 멀티 리전 모델이 내포하는 요구 사항을 대처할 수 있는 구체적인 아키텍처 전략이 필요합니다. 그리고 이러한 전환 과정 잊지 말아야 할 것은, 항상 고객을 위한 끊김없는 환경(Seamless Experience)을 제공하는 데 계속 집중 해야 한다는 것입니다.
멀티 리전 환경은 또한 조직의 민첩성에 영향을 줄 가능성이 있습니다. 따라서, 여러분의 멀티 리전 접근 방식은, 빠른 속도로 새로운 기능을 지속적으로 릴리즈 할 수 있도록 솔루션을 자동화하고 효과적으로 관리할 수 있는 능력에 많은 신경을 써야 합니다.
추가 자료 및 다음 단계
- 멀티 리전 다중 VPC 연결
- 비디오: 멀티 리전 활성-활성 아키텍처를 설계하는 방법
- Amazon API Gateway 및 AWS Lambda를 사용하여 멀티 리전 서버리스 애플리케이션 구축
- Amazon S3 교차 리전 복제
- 글로벌 DynamoDB 테이블
- Amazon Aurora 교차 리전 복제
원문 URL: https://aws.amazon.com/jp/blogs/apn/architecting-multi-region-saas-solutions-on-aws/
** 메가존 클라우드의 ‘Lab to Scale’ 프로그램은 AWS SaaS Factory 베스트 프랙티스 기반의 확장성 높은 SaaS 서비스 설계/구축/운영 서비스를 제공 합니다. 메가존 클라우드의 클라우드 전문가들과 함께 신규 SaaS 서비스 설계부터 국내/외 비즈니스 협업까지 SaaS 서비스의 성공적인 사업화를 지원 합니다.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.