Azure에서 다중 테넌트 솔루션을 설계하고 빌드하기 위한 검사 목록

Azure에서 다중 테넌트 솔루션을 빌드할 때 고려해야 할 요소가 많이 있습니다. 이 검사 목록을 시작점으로 사용하여 다중 테넌트 솔루션을 디자인하고 빌드할 수 있습니다. 이 검사 목록은 Azure에서 다중 테넌트 솔루션 설계 문서 시리즈와 관련된 동반 리소스입니다. 검사 목록은 비즈니스 및 기술 고려 사항과 Azure Well-Architected Framework의 5가지 핵심 요소를 중심으로 구성됩니다.

비즈니스 고려 사항

• B2B(기업-기업), B2C(기업-소비자) 또는 엔터프라이즈 소프트웨어와 같이 만드는 솔루션의 종류와 테넌트가 사용자와 어떻게 다른지를 이해합니다.
• 테넌트를 정의합니다. 초기에 지원할 테넌트 수와 성장 플랜을 이해합니다.
• 가격 책정 모델을 정의 하고 테넌트의 Azure 리소스 사용량과 일치하는지 확인합니다.
• 테넌트를 여러 계층으로 분리해야 하는지를 이해합니다. 계층은 가격 책정, 기능, 성능 약속, 지리적 위치 등이 다를 수 있습니다.
• 고객의 요구 사항에 따라 솔루션의 다양한 부분에 적합한 테넌시 모델을 결정합니다.
• 준비가 되면 Microsoft 상업용 마켓플레이스를 사용하여 B2B 다중 테넌트 솔루션을 판매합니다.

안정성 고려 사항

• 모든 워크로드에 적용되는 Azure Well-Architected 안정성 검사 목록을 검토합니다.
• 노이지 네이버 안티패턴을 이해합니다. 개별 테넌트가 다른 테넌트에 대한 시스템의 가용성에 영향을 주지 않도록 합니다.
• 기대하는 성장 수준에 맞게 다중 테넌트 솔루션을 디자인합니다. 그러나 비현실적인 성장을 위해 과도한 엔지니어링을 해서는 안 됩니다.
• 솔루션에 대한 SLO(서비스 수준 목표) 및 선택적으로 SLA(서비스 수준 계약)를 정의합니다. SLA 및 SLO는 테넌트의 요구 사항을 기반으로 해야 합니다.
• 솔루션의 규모를 테스트합니다. 모든 로드 수준에서 제대로 수행되고 테넌트 수가 증가함에 따라 올바르게 스케일링되는지 확인합니다.
• 카오스 엔지니어링 원칙을 적용하여 솔루션의 안정성을 테스트합니다.

보안 고려 사항

• 솔루션의 모든 계층에 제로 트러스트 및 최소 권한 원칙을 적용합니다.
• 테넌트에 사용자 요청을 올바르게 매핑할 수 있는지 확인합니다. 테넌트 컨텍스트를 ID 시스템의 일부로 포함하거나 애플리케이션 수준 테넌트 권한 부여와 같은 다른 방법을 사용하는 것을 고려합니다.
• 테넌트 격리를 위한 디자인을 합니다. 지속적으로 격리 모델을 테스트합니다.
• 애플리케이션 코드가 테넌트 간 액세스 또는 데이터 유출을 방지하는지 확인합니다.
• 지속적인 침투 테스트 및 보안 코드 검토를 수행합니다.
• 데이터 상주를 포함한 테넌트의 규정 준수 요구 사항 및 테넌트가 사용자에게 충족하도록 요구하는 모든 규정 준수 또는 규제 표준을 이해합니다.
• 올바르게 도메인 이름을 관리하고 현수 DNS 및 하위 도메인 인수 공격과 같은 취약성을 방지합니다.
• 다중 테넌트 지원에 대한 서비스별 참고 자료를 따릅니다.

비용 최적화 고려 사항

• 모든 해당 워크로드에 적용되는 Azure Well-Architected 비용 최적화 검사 목록을 검토합니다.
• 적절하게 테넌트당 사용량을 측정하고 인프라 비용과의 상관관계를 파악할 수 있는지 확인합니다.
• 안티패턴을 피합니다. 안티패턴에는 비용 추적 실패, 불필요한 정밀도로 비용 추적, 실시간 측정 및 청구에 모니터링 도구 사용 등이 포함됩니다.

운영 우수성 고려 사항

• 자동화를 사용하여 온보딩, 배포, 프로비저닝 및 구성과 같은 테넌트 수명 주기를 관리합니다.
• 다중 테넌트 솔루션의 컨트롤 플레인과 데이터 평면 간의 차이점을 이해합니다.
• 서비스 업데이트를 배포하기 위한 적절한 균형을 찾습니다. 테넌트의 요구 사항과 사용자 자신의 운영 요구 사항을 모두 고려합니다.
• 전체 시스템 및 각 테넌트 상태를 모니터링합니다.
• 특정 테넌트에 문제가 발생하거나 사용량 한도를 초과하는 경우 알리도록 경고를 구성하고 테스트합니다.
• 격리 및 스케일링에 대한 Azure 리소스를 구성합니다.
• 배포 및 구성 안티패턴을 피합니다. 안티패턴에는 각 테넌트에 대해 별도의 버전의 솔루션 실행, 테넌트별 구성 또는 논리의 하드 코딩, 수동 배포 등이 포함됩니다.

성능 효율성 고려 사항

• 모든 워크로드에 적용되는 Azure Well-Architected 성능 효율성 목록을 검토합니다.
• 공유 인프라를 사용하는 경우 노이지 네이버 문제를 완화하는 방법을 계획합니다. 한 테넌트가 다른 테넌트의 시스템 성능을 감소할 수 없도록 합니다.
• 테넌트의 요구에 맞게 컴퓨팅, 스토리지, 네트워킹 및 기타 Azure 리소스를 스케일링할 방법을 결정합니다.
• 각 Azure 리소스의 스케일링 제한을 고려합니다. 리소스 조직 안티패턴을 방지하기 위해 적절하게 리소스를 구성합니다. 예를 들어 솔루션을 과도하게 설계하여 비현실적인 스케일링 요구 사항 내에서 작동하게 해서는 안 됩니다.

참가자

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

주요 작성자:

• Arsen Vladimirskiy | 수석 고객 엔지니어
• 보단 체르치크 | 선임 고객 엔지니어

기타 기여자:

• John Downs | 주요 소프트웨어 엔지니어

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

• 다중 테넌트 솔루션에 대한 아키텍처 고려 사항을 검토합니다.
• 다중 테넌트 지원에 대한 아키텍처 접근 방식을 검토합니다.
• 다중 테넌트 지원에 대한 서비스별 참고 자료를 검토합니다.
• 다중 테넌트 솔루션의 설계자 및 개발자를 위한 추가 리소스를 검토합니다.