SaaS 개발을 위한 시작 웹앱

SaaS(서비스 제공 소프트웨어)는 고려해야 할 사항이 많은 복잡한 항목입니다. Azure에서 SaaS 솔루션을 빌드하는 ISV(독립 소프트웨어 공급업체)는 다음과 같은 문제를 해결하고 결정을 내려야 합니다.

• 어떤 임대 모델을 사용해야 하나요?
• 다중 테넌트 아키텍처에서 사용할 ID 솔루션을 설정하려면 어떻게 해야 하나요?
• 신규 고객 온보딩을 어떻게 처리하나요?

이 아키텍처는 이러한 질문 중 일부에 답하고 SaaS 세계로의 출발점을 제공하는 것을 목표로 합니다. 이 아키텍처는 다양한 시나리오에 맞게 조정할 수 있습니다.

잠재적인 사용 사례

다음은 이 아키텍처를 사용할 수 있는 몇 가지 사용 사례입니다.

• SaaS 기반 비즈니스 모델로의 전환의 일환으로 전체 다중 테넌트를 지원하도록 기존 애플리케이션을 현대화합니다.
• 완전히 새로운 SaaS 제품을 개발합니다.
• 다른 클라우드 서비스에서 Azure로 SaaS 제품을 마이그레이션합니다.

아키텍처

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

용어

다음 표에서는 이 문서에 나오는 용어에 대해 설명합니다.

워크플로

1. SaaS 고객 관리자는 온보딩 및 관리 앱에서 호스트되는 사이트로 이동합니다.

2. SaaS 고객 관리자는 사용자 로그인 워크플로를 사용하여 로그인합니다.

3. SaaS 고객 관리자가 온보딩 흐름을 완료합니다.

4. SaaS 고객 관리자는 온보딩 및 관리 앱 의 테넌트 관리 영역으로 이동하고 새로 만든 테넌트에 SaaS 고객 사용자를 추가합니다.

5. SaaS 고객 사용자는 SaaS 애플리케이션 앱으로 이동하여 SaaS 애플리케이션을 사용합니다.

사용자 로그인

사용자 로그인 워크플로는 다음 단계로 구성됩니다.

1. 최종 사용자는 프런트 엔드 애플리케이션으로 이동하여 로그인 단추를 선택합니다.

2. 프런트 엔드 애플리케이션은 최종 사용자를 ID 공급자가 호스트된 로그인 페이지로 리디렉션합니다.

3. 최종 사용자는 계정 정보를 입력하고 로그인 양식을 ID 공급자에 제출합니다.

4. ID 공급자는 최종 사용자의 이메일 주소와 개체 ID로 POST 요청을 실행하여 권한과 역할을 검색합니다.

5. 권한 데이터 API는 권한 데이터 스토리지에서 최종 사용자의 정보를 조회하고 해당 최종 사용자에게 할당된 권한 및 역할 목록을 반환합니다.

6. ID 공급자는 JWT(JSON 웹 토큰)인 ID 토큰에 사용자 지정 클레임으로 권한과 역할을 추가합니다.

7. ID 공급자는 최종 사용자에게 ID 토큰을 반환하고 프런트 엔드 애플리케이션으로의 리디렉션을 시작합니다.

8. 최종 사용자는 프런트 엔드 애플리케이션의 로그인 엔드포인트로 리디렉션되고 ID 토큰을 제시합니다.

9. 프런트 엔드 애플리케이션은 제시된 ID 토큰의 유효성을 검사합니다.

10. 프런트 엔드 애플리케이션은 성공적인 로그인 페이지를 반환하고 최종 사용자는 이제 로그인됩니다.

이 로그인 과정의 작동 방식에 대한 자세한 내용은 OpenID Connect 프로토콜을 참조하세요.

새 테넌트 온보딩

테넌트 온보딩 워크플로는 다음 단계로 구성됩니다.

1. SaaS 고객 관리자는 온보딩 및 관리 앱으로 이동하여 등록 양식을 완료합니다.

2. 온보딩 및 관리자 앱은 테넌트 데이터 API에 POST 요청을 실행하여 새 테넌트를 만듭니다.

3. 테넌트 데이터 API는 테넌트 데이터 스토리지에 새 테넌트를 만듭니다.

4. 테넌트 데이터 API는 새로 만들어진 테넌트에 SaaS 고객 관리자 권한을 부여하기 위해 권한 데이터 API에 POST 요청을 보냅니다.

5. 권한 데이터 API는 권한 데이터 스토리지에 새 권한 레코드를 만듭니다.

6. 권한 데이터 API가 성공적으로 반환됩니다.

7. Tenant data API가 성공적으로 반환됩니다.

8. 온보딩 및 관리자 앱은 이메일 알림 공급자에게 POST 요청을 실행하여 SaaS 고객 관리자에게 "테넌트 생성" 전자 메일 메시지를 보냅니다.

9. 이메일 알림 공급자가 이메일을 보냅니다.

10. 이메일 알림 공급자가 성공적으로 반환됩니다.

11. 온보딩 및 관리자 앱은 새로 만든 테넌트에 대한 JWT 클레임을 포함하도록 ID 공급자에게 SaaS 고객 관리자의 ID 토큰을 새로 고치라는 요청을 발급합니다.

12. ID 공급자는 SaaS 고객 관리자의 이메일 주소와 개체 ID를 사용하여 POST 요청을 실행하여 권한과 역할을 검색합니다.

13. 권한 데이터 API는 권한 데이터 스토리지에서 SaaS 고객 관리자의 정보를 조회하고 SaaS 고객 관리자에게 할당된 권한 및 역할 목록을 반환합니다.

14. ID 공급자는 권한과 역할을 사용자 지정 클레임으로 ID 토큰에 추가합니다.

15. ID 공급자는 ID 토큰을 온보딩 및 관리 앱에 반환합니다.

16. 온보딩 및 관리 앱은 성공 메시지와 새 ID 토큰을 SaaS 고객 관리 반환합니다.

테넌트에 사용자 추가

테넌트 워크플로에 사용자를 추가하는 작업은 다음 단계로 구성됩니다.

1. SaaS 고객 관리자는 온보딩 및 관리 앱의 테넌트 관리 영역에서 테넌트 목록을 확인하도록 요청합니다.

2. 온보딩 및 관리자 앱은 테넌트 데이터 API에 GET 요청을 실행하여 SaaS 고객 관리자에 대한 테넌트 목록을 가져옵니다.

3. 테넌트 데이터 API는 권한 데이터 API에 GET 요청을 보내 SaaS 고객 관리자가 볼 수 있는 테넌트 목록을 가져옵니다.

4. 권한 데이터 API는 테넌트 권한 목록을 반환합니다.

5. 테넌트 데이터 API는 테넌트 데이터 스토리지에서 테넌트 정보를 조회하고 받은 테넌트 권한 목록을 기반으로 테넌트 데이터 목록을 반환합니다.

6. 온보딩 및 관리자 앱은 테넌트 데이터 목록을 SaaS 고객 관리자에게 반환합니다.

7. SaaS 고객 관리자는 SaaS 고객 사용자를 추가할 테넌트를 목록에서 선택하고 SaaS 고객 사용자의 이메일 주소를 입력합니다.

8. 온보딩 및 관리자 앱은 지정된 테넌트에 대한 SaaS 고객 사용자에 대한 권한을 추가하기 위해 테넌트 데이터 API에 POST 요청을 발급합니다.

9. Tenant data API는 SaaS 고객 관리자가 지정된 테넌트에 대한 유효한 JWT 클레임이 있고 사용자의 쓰기 권한이 있는지 확인합니다.

10. 테넌트 데이터 API는 지정된 테넌트에서 SaaS 고객 사용자에 대한 권한을 추가하기 위해 권한 데이터 API에 POST 요청을 보냅니다.

11. 권한 데이터 API는 제공된 이메일 주소로 SaaS 고객 사용자를 조회하기 위해 ID 공급자에 GET 요청을 보냅니다.

12. ID 공급자는 SaaS 고객 사용자의 개체 ID를 반환합니다.

13. 권한 데이터 API는 개체 ID를 사용하여 지정된 테넌트의 SaaS 고객 사용자에 대한 권한 데이터 스토리지에 권한 레코드를 추가합니다.

14. 권한 데이터 API가 성공적으로 반환됩니다.

15. Tenant data API가 성공적으로 반환됩니다.

16. 온보딩 및 관리 앱이 성공적으로 반환됩니다.

구성 요소

이 아키텍처는 다음 Azure 서비스를 사용합니다.

• App Service를 사용하면 인프라를 관리할 필요 없이 선택한 프로그래밍 언어로 웹앱 및 API 앱을 빌드하고 호스트할 수 있습니다.

• Azure Active Directory B2C는 최종 사용자 애플리케이션의 ID 및 액세스 관리를 쉽게 지원합니다.

• Azure SQL Database는 관계형 데이터, 공간 데이터, JSON 및 XML을 지원하는 범용 관계형 데이터베이스 관리 서비스입니다.

• Azure Logic Apps를 사용하면 간단한 GUI 도구를 사용하여 강력한 통합을 빠르게 빌드할 수 있습니다.

대안

대체 선택의 효과는 SaaS 애플리케이션이 지원할 테넌트 모델에 따라 크게 달라집니다. 다음은 이 솔루션을 구현할 때 따를 수 있는 대체 방식의 몇 가지 예입니다.

• 현재 솔루션은 Azure Active Directory B2C를 ID 공급자로 사용합니다. 대신 Microsoft Entra ID와 같은 다른 ID 공급자를 사용할 수 있습니다.

• 보다 엄격한 보안 및 규정 준수 요구 사항을 위해 교차 서비스 통신을 위한 개인 네트워킹을 구현하도록 선택할 수 있습니다.

• 서비스 간에 REST 호출을 사용하는 대신 교차 서비스 메시징을 위해 이벤트 기반 아키텍처 스타일을 구현할 수 있습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 개선하기 위해 따를 수 있는 지침 원칙 집합인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

이 솔루션은 ID를 보안 패러다임으로 사용합니다. 웹앱 및 API에 대한 인증 및 권한 부여는 JWT(사용자 ID 토큰) 발급 및 확인을 담당하는 Microsoft ID 플랫폼 의해 제어됩니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

이 솔루션의 구성 요소에는 운영과 관련된 약간의 비용이 있지만 대부분의 웹 애플리케이션 및 SaaS 솔루션의 경우 비용이 적당합니다. 또한 다음 리소스 설정을 관리하여 비용을 제어할 수 있습니다.

• 필요한 처리량에 맞게 애플리케이션을 실행하는 App Service 요금제의 크기를 조정할 수 있습니다. 또한 더 높은 처리량이 필요한 경우 별도의 계획에서 각 앱을 실행할 수 있지만 결과적으로 더 높은 비용이 발생합니다. 자세한 내용은 Azure App Service 요금제 개요를 참조하세요.

• Azure AD B2C는 Premium P1 및 Premium P2의 두 가지 SKU를 제공합니다. 두 SKU에는 MAU(월 활성 사용자) 수에 대한 무료 허용량이 포함되어 있지만 사용 사례에 필요한 기능을 결정하려면 각 SKU가 제공하는 기능을 평가해야 합니다. 자세한 내용은 Microsoft Entra 외부 ID 가격 책정을 참조하세요.

• Azure SQL에는 자동 크기 조정 기능을 포함하여 다양한 사용 사례에 맞는 여러 구매 모델이 있습니다. 데이터베이스의 크기를 올바르게 조정하려면 자체 데이터베이스의 사용량을 평가해야 합니다. 자세한 내용은 Azure SQL Database의 vCore 및 DTU 기반 구매 모델 비교를 참조하세요.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

이 아키텍처는 대부분의 중대형 워크로드를 쉽게 충족하도록 크기 조정할 수 있어야 합니다. 아키텍처는 주로 Azure의 플랫폼(PaaS) 서비스를 사용하므로 요구 사항 및 부하에 따라 솔루션의 규모를 조정할 수 있는 많은 옵션이 있습니다.

시나리오 배포

이 시나리오를 배포하려면 GitHub에서 Azure SaaS Dev Kit를 참조하세요. 이 아키텍처의 배포 가능한 참조 구현입니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Landon Pierce | 고객 엔지니어

기타 기여자:

• Chris Ayers | 선임 고객 엔지니어
• John Downs | 선임 고객 엔지니어
• LaBrina Loving | 수석 SVC 엔지니어링 관리자
• Gary Moore | 프로그래머/작가
• Nick Pinheiro | 선임 컨설턴트
• William Salazar | 선임 고객 엔지니어
• Ali Sanjabi | 선임 고객 엔지니어
• Arsen Vladimirskiy | 수석 고객 엔지니어
• Jason Young | 수석 SVC 엔지니어링 관리자

다음 단계

다음은 Azure에서 SaaS 애플리케이션을 빌드하기 위한 추가 권장 리소스입니다.

• Azure의 다중 테넌트 솔루션 설계 - 모범 사례를 설명합니다.
• Azure 랜딩 존에 대한 ISV 고려 사항
• Microsoft Azure Well-Architected Framework
• WingTips Tickets SaaS 애플리케이션 - 데이터베이스 계층 내의 다양한 테넌트 모델 간의 장단점에 대한 세부 정보를 제공합니다.

관련 참고 자료

• 다중 테넌트 솔루션에 대해 고려해야 하는 테넌트 모델
• 다중 테넌트 솔루션의 컴퓨팅을 위한 아키텍처 접근 방식
• 다중 테넌트 솔루션의 스토리지 및 데이터에 대한 아키텍처 접근 방식
• 다중 테넌시를 위한 Azure App Service 및 Azure Functions 고려 사항
• Azure의 다중 테넌트 SaaS
• 클라우드 디자인 패턴