AWS 기술 블로그
Amazon QuickSight를 사용하여 SaaS 환경을 위한 멀티테넌트 애플리케이션 지원
본 게시물은 AWS Business Intelligence Blog에 Evangelos Pertsinis 님, Mike Gillespie님, Ramon Lopez 님이 공저한 “Support multi-tenant applications for SaaS environments using Amazon QuickSight” 원문을 한국어로 번역 및 편집한 글입니다.
시각화 및 보고 기능을 갖춘 애플리케이션 서비스는 고객 확보, 수익 증대, 경쟁력 제고에 크게 기여합니다. 통합된 분석 및 보고 기능이 없는 서비스형 소프트웨어(SaaS) 솔루션은 시장에서 경쟁력이 낮아질 수밖에 없습니다. 하지만 자체 개발 및 상용 비즈니스 인텔리전스(BI) 솔루션 도입은 구축 및 유지 관리 비용이 많이 듭니다. 수천 명의 고객사에서 AWS의 서버리스 BI 서비스인 Amazon QuickSight는 임베디드 애플리케이션에서 비용 효율적으로 시각화와 분석 경험을 원활하게 통합하는 데 사용되고 있습니다. 이 포스팅은 QuickSight의 멀티테넌시에 초점을 맞추고 있습니다. 그 외 QuickSight 임베디드 분석 아키텍처 패턴에 대한 자세한 내용은 Amazon QuickSight를 활용한 임베디드 분석 아키텍처 구축 블로그를 참고하세요.
많은 조직에서 멀티 테넌시를 활용할 수 있지만, 가장 일반적인 멀티 테넌시 사용자는 운영 오버헤드나 비용 없이 소프트웨어를 사용할 수 있는 SaaS 솔루션입니다. SaaS 솔루션이 직면한 한 가지 과제는 낮은 비용과 대규모의 고객을 수용할 수 있는 고품질의 BI 솔루션을 제공하는 것입니다. QuickSight는 비용 효율적이면서 자체 관리 솔루션의 운영 부담을 줄일 수 있어 이 같은 요구사항을 충족할 수 있습니다. 또한 QuckSight의 멀티 테넌시 기능은 고객을 대상으로 대시보드 및 보고 솔루션을 제공하는 컨설팅 업체에도 유용합니다.
이 게시물에서는 멀티 테넌트 환경에 QuickSight를 배포하는 방법과 QuickSight 애플리케이션에서 데이터를 격리하고 테넌트에 리소스를 배포데 고려해야 할 사항을 제공합니다. 애플리케이션 내 멀티 테넌시는 사용자 그룹을 서로 구분할 수 있는 메커니즘을 제공합니다. 이러한 그룹은 서로 다른 회사, 서로 다른 지리적 지역 또는 기업 내 다른 비즈니스 라인의 사용자일 수 있습니다. 서로 다른 테넌트 내의 사용자는 다른 사용자, 데이터 및 asset을 볼 수 없으며, 각 사용자 집합에 대해 서로 다른 인프라를 보유해야 하는 복잡성을 줄일 수 있습니다.
이 게시물에서는 다음 주제를 다룹니다:
- 사용 사례에 이상적인 QuickSight 데이터 격리 방법 선택하기
- QuickSight 내에서 객체를 배포하고 액세스 권한을 부여하는 가장 좋은 방법 선택하기
- 테넌트 사용자 프로비저닝
- 모든 테넌트에 asset을 배포할 수 있는 개발 및 배포 방법론
Group vs Namespace
Amazon QuickSight는 리소스를 격리하여 멀티 테넌시를 달성하는 두 가지 방식을 제공합니다: 그룹 사용 또는 네임스페이스 사용. 두 가지 방법 모두 리소스(데이터 소스, 데이터 세트, 분석, 대시보드)를 격리할 수 있지만, 근본적인 차이점이 하나 있습니다. 최종 사용자가 QuickSight를 이용해 대시보드를 직접 생성, 배포, 또는 공유해야한다면 네임스페이스를 사용해야 합니다.
최종 사용자가 보고서를 직접 작성하고 작성자 자격이 필요한 경우 네임스페이스는 필수입니다. 그룹 멤버십만으로는 작성자 자격 소지자가 새로 만든 리소스를 그룹 외부로 공유하는 것을 제한할 수 없어, 의도치 않은 데이터 유출 위험이 커집니다.
통합 가시성 관점에서 네임스페이스는 테넌트 수준에서 QuickSight 사용량 모니터링을 간소화하여 조직이 고객에 대한 요금 부과를 추적하기 용이합니다.
그룹과 네임스페이스 중 어떤 방식을 사용할지 결정하기 전에 각 방식의 제한사항 관련 문서를 검토하세요.
테넌트별 데이터 세트 및 데이터 소스 vs 행 수준 보안 기능이 적용된 단일 데이터 세트
QuickSight 기반 멀티 테넌트 아키텍처에서는 데이터 세트 구성 방식에 대한 결정이 필요합니다. 이 섹션에서는 두가지 옵션을 살펴봅니다. 어떤 옵션이 적합한지는 조직의 리스크 허용 범위와 산업별 규정 준수 요구 사항에 따라 달라집니다.
테넌트별 데이터 세트 및 데이터 소스
이 시나리오에서는 테넌트별로 독립된 데이터 세트를 구성합니다. 각 데이터 세트는 데이터 필터 또는 parameter가 포함된 사용자 정의 쿼리를 통해 해당 테넌트의 데이터만 가져오도록 구성됩니다.
테넌트별 데이터 소스는 필수는 아닙니다. 예를 들어, Amazon Athena를 사용하여 Amazon Simple Storage Service (Amazon S3)의 데이터를 쿼리하는 경우, 모든 테넌트 간에 공유되는 연결 정보로 단일 데이터 소스를 구성할 수 있습니다. 각 테넌트의 데이터 세트는 서로 다른 테넌트 ID를 포함한 쿼리를 Athena로 전달합니다.
데이터베이스 수준의 멀티테넌시에 테넌트당 데이터베이스 스키마 또는 클러스터와 같이 분리된 하드웨어 또는 스키마가 포함된 경우, 테넌트별로 데이터 소스를 구성해야 합니다.
AWS Lambda 함수를 사용하면 자동화된 방식으로 테넌트별로 asset을 배포할 수 있습니다. 이 프로세스는 새 asset을 생성하고, 특정 네임스페이스(테넌트)의 그룹 또는 사용자에게만 해당 asset에 대한 액세스 권한을 부여합니다. 또한 필요 시 Lambda를 사용하여 테넌트를 정리하고 사용자와 asset을 삭제할 수도 있습니다.
다음 다이어그램은 이러한 아키텍처를 보여줍니다.
행 수준 보안 기능이 적용된 단일 데이터 세트
이 시나리오에서는 모든 테넌트의 원본 데이터를 포함하는 단일 데이터 세트가 있으며, 이 데이터 집합에는 행 수준 보안(RLS) 기능이 활성화되어 있습니다. 단일 대시보드는 이 데이터 세트를 참조해서 모든 테넌트와 공유됩니다.
RLS를 사용하려면 각 테넌트가 액세스할 수 있는 데이터에 대한 정보를 담고 있는 별도의 데이터 세트를 생성해야합니다. 자세한 내용은 Amazon QuickSight에서 행 수준 보안(RLS) 기능 사용하기를 참고하세요.
다음 다이어그램은 이러한 아키텍처를 보여줍니다.
옵션 비교
다음 표에서는 각 옵션의 장단점을 요약하고 있습니다.
| 옴션 | 장점 | 단점 |
| 테넌트 별 고유 asset(데이터 소스, 데이터 세트, 대시보드) | 데이터 격리가 필요한 산업별 요구 사항 준수 | asset 관리를 위한 자동화 필요, 개발 오버헤드 증가 |
| SPICE에 대한 테넌트별 비용 추적 용이 | ||
| 테넌트 간 RLS로 asset 공유 | 구현이 간단하고 개발 오버헤드 낮음 | SPICE에 대한 테넌트별 비용 추적 불가 |
| RLS 규칙이 데이터 세트의 보안의 핵심 | ||
| 저장된 데이터 규모에 따라 SPICE 한도 도달 위험 증가 |
프로비저닝, 인증 및 권한 부여
이 블로그의 목적에 맞게, 이제 테넌트(네임스페이스), 그룹 및 사용자를 프로비저닝합니다. 다른 구현 방식에서는 ID 페더레이션을 사용하여 QuickSight 외부에서 그룹을 관리할 수 있습니다.
애플리케이션에 대시보드를 임베딩하면 QuickSight에서 사용자 관리가 불필요해지며 원활한 사용자 경험을 제공할 수 있습니다. 임베딩 애플리케이션은 사용자를 대신하여 QuickSight API를 호출하여 iFrame에서 사용할 수 있는 일회용 URL을 생성하고, 이 URL은 사용자에게 대시보드를 표시합니다. 임베딩 URL 생성 시 사용자 컨텍스트가 전달되므로 QuickSight에 로그인할 필요가 없습니다. 자세한 내용은 임베딩 워크플로우 워크샵을 참조하세요.
QuickSight 관련 보안 모범 사례는 Amazon QuickSight의 보안 모범 사례를 참조하세요.
다음 섹션에서는 AWS Identity and Access Management (IAM) 사용자, 그룹, 네임스페이스 및 asset을 사용하여 QuickSight에서 멀티 테넌트 환경에 필요한 리소스를 생성합니다. 설명을 간단하게 하기 위해 AWS Command Line Interface (AWS CLI) 예제를 사용합니다. AWS CLI 대신 AWS SDK for Python (Boto3)와 같은 다른 SDK를 사용할 수도 있습니다.
테넌트(네임스페이스)
이 섹션에서는 사용자 정의 네임스페이스의 형태로 첫 번째 테넌트를 생성한 후, 그룹을 만듭니다. 네임스페이스 내의 그룹은 다수의 사용자에게 권한을 적용하는 데 유용합니다.
다음 명령을 입력합니다(AWS 계정 ID와 네임스페이스의 이름을 입력합니다):
이 프로세스는 비동기식으로 실행됩니다. 네임스페이스가 생성되었는지 확인하려면 다음 명령을 입력합니다:
사용자
이 섹션에서는 IAM 사용자를 생성한 후, QuickSight에서 해당 사용자를 네임스페이스에 등록합니다.
먼저, 적절한 권한을 가진 IAM 사용자를 생성해야 합니다. 자세한 내용은 AWS 계정에서 IAM 사용자 생성하기를 참조하세요.
다음 명령을 입력하여 생성한 사용자를 QuickSight 네임스페이스에 작성자로 등록합니다:
테넌트 전체에 asset 배포
이 섹션에서는 테넌트 전체에 데이터 세트를 배포하는 프로세스를 살펴봅니다. AWS CLI를 사용하여 데이터 세트를 JSON으로 내보낸 후 템플릿을 만들어 다른 테넌트에 배포할 수 있습니다.
AWS CLI 명령어나 Python용 SDK를 Lambda와 함께 사용하여 export 및 배포 파이프라인을 생성하고, 운영 워크로드를 위해 이러한 파이프라인을 자동화할 수 있습니다.
QuickSight에서 asset을 코드로 내보내는 방법에는 두 가지가 있습니다:
- 표준 API 사용 (예: describe-dashboard)
- 번들 API 사용
번들 API를 사용하면 모든 종속성을 하나의 export 파일에 번들링하여 export 프로세스가 간소화됩니다.
멀티 테넌트 환경에서 asset을 개발할 때는 개발 용도의 네임스페이스를 할당하세요. 개발 용도의 네임스페이스로 기본 네임스페이스나 고객의 네임스페이스를 사용할 수 있습니다.
다음 다이어그램은 네임스페이스 전반에서 asset을 내보내고, 템플릿화하여 가져오는 프로세스를 보여줍니다.
번들 export를 통해 asset을 배포하려면 다음 단계를 수행하세요:
- 내보내려는 대시보드의 ARN을 가져오기 위해 다음 명령을 입력합니다:
- 검색한 리소스 ARN을 사용하여 export 작업을 시작합니다. AWS CLI에서 종속성을 포함하도록 지정하면 대시보드에서 사용 중인 데이터 세트와 데이터 소스도 함께 내보내집니다. 이 블로그에서는, export 형식으로 JSON을 사용하지만, AWS CloudFormation도 지원 됩니다. 다음 코드를 참조하세요:
–asset-bundle-export-job-id 값은 export 작업이 진행되는 동안 고유해야 합니다. QuickSight는 최대 5개의 동시 asset 번들 export 작업을 지원합니다. export 작업은 파일 확장자가 .qs인 .zip 파일을 생성하며, 그 안에는 대시보드, 데이터 세트, 데이터 소스가 JSON 파일(CloudFormation 형식)로 포함되어 있습니다. .zip 파일은 Amazon S3에 저장됩니다.
export 작업이 완료되면 .qs 파일의 위치를 나타내는 S3 presigned URL이 생성됩니다. 이 URL은 5분 동안 활성화되어 있습니다. URL이 만료되면 describe-asset-bundle-export-job 호출을 실행하여 다시 활성화할 수 있습니다.
- API는 비동기식이기 때문에 다음 명령을 입력하여 번들 export 진행 상황을 확인하세요:
다음 코드는 출력 예시를 보여줍니다:
- DownloadUrl의 값을 복사하고 curl을 사용하여 Amazon S3에서 파일을 다운로드하세요. DownloadURL 값에 쌍따옴표를 사용해야 합니다:
- 다음 명령을 사용하여 콘텐츠의 압축을 풉니다:
다음 스크린샷은 폴더 구조가 어떤 모습이어야 하는지 보여줍니다.
QuickSight는 가져오기 시 호스트 이름, 비밀번호 또는 데이터 소스 이름과 같은 parameter 재정의할 수 있는 몇가지 기본 옵션을 제공합니다. 이를 위해 AssetBundleImportJobOverrideParameters API를 사용합니다.parameter로 사용할 속성이 API에서 지원되지 않는 경우, 수동으로 템플릿에 해당 parameter를 추가해야 합니다. 스크립트를 사용하여 parameter를 찾아필요한 값으로 바꿀 수 있습니다. 이 글에서는 찾아 바꾸는 프로세스에 대해서는 다루지 않습니다.
번들에서 내보낸 파일을 보면, 다음 스크린샷과 같이 각 JSON 파일에는 업데이트해야 하는 ID(datasourceId, dataSetId 또는 dashboardId)와 이름 키가 있습니다.
테넌트별로 datasourceId, dataSetId, 이름을 고유하게 설정해야 합니다.
다음 예제에는 국가별 데이터 세트 필터가 있는데, 이를 각 테넌트마다 다른 값으로 설정해야 합니다. 대시보드에 동일한 필드나 필터가 없을 수도 있습니다. 볼 수 있도록 설정할 열이나 필터를 선택하세요.
다음 스크린샷은 원본 필터를 보여줍니다.
다음 스크린샷은 새로운 parameter가 적용된 필터를 보여줍니다.
이제 프로세스를 자동화하고 스크립트를 사용하여 {{COUNTRY_PARAMETER}}를 관련 값으로 바꿀 수 있습니다. - 이 글에서는,
{{COUNTRY_PARAMETER}}를 특정 값으로 수동으로 설정하고 파일을 저장합니다. - 대시보드, 데이터 세트, 데이터 소스 폴더가 있는 동일한 디렉터리 수준으로 이동하여 새 .zip 파일을 만듭니다:
- 새 번들 파일을 Amazon S3에 업로드합니다:
- 다음 AWS CLI 명령을 사용하여 가져오기 작업을 시작합니다:
- 진행 상황을 확인하려면 다음 명령을 입력합니다:
번들을 가져온 후에는, 누구도 생성된 asset을 보거나 접근할 수 없습니다. 이는 디자인 상 번들에 권한이 포함되어 있지 않기 때문입니다.
- 관련 테넌트와 연결된 그룹이 볼 수 있도록 새 대시보드에 권한을 추가하려면 다음 명령을 입력합니다(YOUR_PRINCIPAL_ARN의 값은 사용자가 만든 IAM 사용자일 수 있음):
테넌트 그룹에 대한 대시보드 권한을 업데이트한 후에, 작업이 완료되고 사용자는 해당 대시보드에 액세스할 수 있습니다. 사용자가 데이터 세트에도 액세스해야 하는 경우, 해당 asset에 대한 권한도 업데이트해야 합니다.
- 다음 명령을 입력하여 권한을 업데이트합니다:
다른 네임스페이스에 asset 배포
다른 네임스페이스에 asset을 배포하려면, 이전 단계를 반복하되, 템플릿에 속성 parameter를 추가하는 것부터 시작하세요.
결론
이 게시물에서는 멀티 테넌트 SaaS 환경에서 QuickSight 보고서를 배포할 때의 설계 고려 사항을 다루었습니다. 첫 번째 설계 결정 사항은 테넌트 간에 권한을 격리하는 것입니다. 테넌트가 리소스를 생성하거나 편집할 수 있게 하려면, 네임스페이스가 가장 적합합니다. 다음 설계 결정사항은 행 수준 보안을 적용할지 아니면 테넌트별 단일 데이터 세트를 사용할지 여부입니다. SPICE 데이터 세트 간에 격리를 원한다면 테넌트별 데이터 세트가 필요합니다. 이 글의 마지막 섹션에서는 테넌트 전반에 asset 번들을 배포하는 방법에 대한 지침을 제공했습니다.
QuickSight를 사용한 임베디드 분석 및 멀티 테넌시에 대한 자세한 내용은 Amazon QuickSight를 사용한 임베디드 분석 아키텍처 구축하기 및 Amazon QuickSight를 사용하여 애플리케이션에 멀티 테넌트 분석을 임베딩시키기를 참조하세요.