Azure의 다중 테넌트 검사 목록

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

비즈니스 고려 사항

• B2B(비즈니스 대 기업), B2C(기업-소비자) 또는 엔터프라이즈 소프트웨어와 같이 만드는 솔루션의 유형과 테넌트가 사용자와 어떻게 다른지 이해합니다.

• 당신의 테넌트를 정의하세요 처음에 지원하는 테넌트 수를 이해하고 성장 계획을 정의합니다.

• 가격 책정 모델을 정의 하고 테넌트의 Azure 리소스 사용량과 일치하는지 확인합니다.

• 테넌트를 다른 등급으로 구분해야 하는지를 이해합니다. 계층에는 가격 책정, 기능, 성능 약속 및 지리적 위치가 다를 수 있습니다.

• 고객의 요구 사항에 따라 솔루션의 다양한 부분에 적합한 테넌시 모델을 결정합니다.

• 준비가 되면 Microsoft 상업용 Marketplace를 사용하여 B2B 다중 테넌트 솔루션을 판매합니다.

안정성 고려 사항

• 모든 워크로드에 적용되는 Well-Architected Framework 안정성 검사 목록을 검토합니다.

• 시끄러운 이웃 안티패턴을 이해합니다. 개별 테넌트가 다른 테넌트에 대한 시스템의 가용성에 영향을 주지 않도록 합니다.

• 원하는 성장 수준에 맞게 다중 테넌트 솔루션을 디자인합니다. 그러나 비현실적인 성장을 위해 자동화를 너무 많이 하지 마십시오.

• 솔루션 에 대한 SLO(서비스 수준 목표) 및 선택적으로 SLA(서비스 수준 계약)를 정의합니다. SLO 및 SLA는 테넌트의 요구 사항을 기반으로 해야 합니다.

• 솔루션의 규모를 테스트합니다. 모든 부하 수준에서 잘 수행되고 테넌트 수가 증가함에 따라 올바르게 확장되는지 확인합니다.

• 비정상 상황 엔지니어링 원칙을 적용하여 솔루션의 안정성을 테스트합니다.

보안 고려 사항

• 솔루션의 모든 계층에서 제로 트러스트 및 최소 권한 원칙을 적용합니다.

• 사용자 요청을 테넌트에 올바르게 매핑할 수 있는지 확인합니다. ID 시스템의 일부로 또는 애플리케이션 수준 테넌트 권한 부여와 같은 다른 방법을 통해 테넌트 컨텍스트를 포함하는 것이 좋습니다.

• 테넌트 격리를 위한 디자인입니다. 격리 모델을 지속적으로 테스트합니다.

• 애플리케이션 코드가 테넌트 간 액세스 또는 데이터 누출을 방지하는지 확인합니다.

• 지속적인 침투 테스트 및 보안 코드 검토를 수행합니다.

• 테넌트의 규정 준수 요구 사항을 이해하십시오. 여기에는 데이터 상주와 귀하가 충족해야 하는 규정 준수 또는 규제 표준이 포함됩니다.

• 도메인 이름을 올바르게 관리하고매달린 DNS 및 하위 도메인 탈취 공격과 같은 취약성을 방지합니다.

• 다중 테넌시에 대한 서비스별 지침을 따릅니다.

비용 최적화 고려 사항

• 모든 워크로드에 적용되는 Well-Architected Framework 비용 최적화 검사 목록을 검토합니다.

• 테넌트당 사용량을 적절하게 측정하고 인프라 비용과 상호 연결할 수 있는지 확인합니다.

• 안티패턴을 피하십시오. 안티패턴에는 비용 추적 실패, 불필요한 정밀도로 비용 추적, 실시간 측정 사용, 청구를 위한 모니터링 도구 사용 등이 포함됩니다.

운영 우수성 고려 사항

• 자동화를 사용하여 온보딩, 배포, 프로비전 및 구성과 같은 테넌트 수명 주기를 관리합니다.

• 다중 테넌트 솔루션의 컨트롤 플레 인과 데이터 평면 간의 차이점을 이해합니다.

• 서비스 업데이트를 배포하기 위한 적절한 균형을 찾습니다. 테넌트의 요구 사항과 고유한 운영 요구 사항을 모두 고려합니다.

• 전체 시스템 및 각 테넌트 상태를 모니터링합니다.

• 특정 테넌트에 문제가 발생하거나 소비 한도를 초과하는 경우 알림을 알리도록 경고를 구성하고 테스트합니다.

• 격리 및 크기 조정을 위해 Azure 리소스를 구성합니다.

• 배포 및 구성 안티패턴을 방지합니다. 안티패턴에는 각 테넌트에 대해 별도의 버전의 솔루션을 실행하고, 테넌트별 구성 또는 논리를 하드 코딩하고, 수동 배포를 사용하는 것이 포함됩니다.

성능 효율성 고려 사항

• 모든 워크로드에 적용되는 Well-Architected Framework 성능 효율성 검사 목록을 검토합니다.

• 공유 인프라를 사용하는 경우 시끄러운 이웃 문제를 완화하는 방법을 계획합니다. 한 테넌트가 다른 테넌트에 대한 시스템의 성능을 줄일 수 없는지 확인합니다.

• 테넌트 요구에 맞게 컴퓨팅, 스토리지, 네트워킹 및 기타 Azure 리소스의 크기를 조정하는 방법을 결정합니다.

• 각 Azure 리소스에 대한 확장 제한을 고려합니다. 리소스 조직 안티패턴을 방지하기 위해 리소스를 적절하게 구성합니다. 예를 들어 비현실적인 규모 요구 사항 내에서 작동하도록 솔루션을 과도하게 설계하지 마세요.

기여자

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

주요 작성자:

• 아르센 블라디미르스키 | 수석 고객 엔지니어
• 보단 체르치크 | 선임 고객 엔지니어

기타 기여자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

관련 리소스

• 다중 테넌트 솔루션에 대한 아키텍처 고려 사항
• 다중 테넌트 아키텍처 접근 방식
• 다중 테넌시용 서비스별 지침
• 다중 테넌트 솔루션 설계자 및 개발자를 위한 리소스