시나리오 1 솔루션 - 글로벌 스케일링 및 보안 액세스 설계
이전 단원에서는 콘텐츠 배달 네트워크의 글로벌 스케일링에 관한 시나리오를 살펴보았습니다. 이 단원에서는 하나의 잠재적 솔루션과 고려해야 할 몇 가지 항목을 검토해 보겠습니다.
검토할 때는 제공된 솔루션을 이전 단원에서 개발한 솔루션과 비교해야 합니다. 문제에 적합한 솔루션은 두 개 이상인 경우가 많으며 각 솔루션에는 항상 장단점이 있습니다. 개발한 솔루션에서 제안된 솔루션과 다른 항목은 무엇입니까? 개발한 솔루션에 재고해 볼 수 있는 항목이 있나요? 제공된 솔루션의 항목 중 개발한 솔루션에서 더 확실하게 처리된다고 생각하는 항목이 있나요?
배포 옵션 및 구성
첫 번째 결정 단계는 선택해야 할 Azure SQL 배포 옵션입니다. Azure VM(가상 머신)의 SQL Server도 사용할 수 있지만 PaaS(Platform as a Service) 제품이 관리 오버헤드가 적어 더 적절할 수도 있습니다.
고객이 인스턴스 범위 기능인 CLR(공용 언어 런타임)을 사용하고 있습니다. Azure SQL Managed Instance는 CLR, Service Broker 및 데이터베이스 메일과 같은 인스턴스 범위 기능을 지원하는 유일한 PaaS 배포 옵션입니다. 따라서 고객은 Azure SQL Managed Instance를 사용하여 Azure SQL Database 호환 솔루션(예: 탄력적 데이터베이스 작업)에 CLR 애플리케이션을 다시 작성하지 않고도 PaaS 제품으로 이동할 수 있습니다.
다음 결정 단계는 서비스 계층에 대한 것입니다. 고객이 읽기 및 쓰기 워크로드를 격리하려 하므로 중요 비즈니스용 서비스 계층 사용은 격리를 실현하는 가장 간단한 방법입니다. 중요 비즈니스용 서비스 계층에는 백그라운드에서 실행되는 Always On 가용성 그룹이 있습니다. 이러한 보조 복제본 중 하나를 읽기 전용 작업에 사용할 수 있습니다.
여기서 중요 비즈니스용은 읽기 및 쓰기 워크로드를 분리하는 구성의 절반에 불과합니다. 시나리오에 따르면 고객은 읽기 및 쓰기 워크로드를 격리하는 한편, 동시에 발생하는 여러 쿼리를 사용하여 여러 지역에 걸쳐 스케일링할 수 있어야 합니다.
이 과제를 해결할 수 있는 두 가지 옵션은 지역에서 복제와 자동 장애 조치 그룹입니다. 하지만 현재 Azure SQL Managed Instance에서는 지역에서 복제가 지원되지 않습니다. 따라서 이 시나리오에서는 자동 장애 조치 그룹을 사용하는 것이 글로벌 읽기 스케일링을 실현하는 데 도움이 될 수 있는 유일한 옵션입니다.
고객이 자동 장애 조치 그룹을 사용하므로 중요 비즈니스용 서비스 계층이 필요한지 여부는 분석 워크로드에 필요한 읽기 전용 엔드포인트 수에 따라 달라집니다. 중요 비즈니스용 서비스 계층의 자동 장애 조치 그룹을 사용하는 경우 고객은 읽기 가능한 엔드포인트 3개를 얻게 됩니다.
- 주 지역 가용성 그룹의 보조 복제본 1개
- 장애 조치 그룹(보조 지역에 있는 데이터베이스의 주 복제본)의 보조
- 보조 지역 가용성 그룹의 보조 복제본
분석 워크로드에 이러한 읽기 가능한 복제본 중 일부가 필요하지 않은 경우 범용을 사용하면 더욱 비용 효율적인 솔루션이 될 수도 있습니다.
가장 적절한 인증 방법 선택
이 시나리오의 나머지 부분은 가능한 한 가장 안전한 기술을 만들어 사용해야 한다는 요구를 고려하여, 각 애플리케이션이나 사용자가 솔루션에 연결하는 가장 좋은 방법을 결정하는 것과 관련되어 있습니다. 시나리오를 자세히 살펴보면 Azure SQL Managed Instance에 액세스해야 하는 개별 클라이언트는 다음 4가지입니다.
- Azure VM에서 실행되는 애플리케이션
- 도메인 조인된 비 Azure 머신에서 실행되는 애플리케이션
- 도메인 조인되지 않은 비 Azure 머신에서 SQL 관리 도구(SQL Server Management Studio, Azure Data Studio, PowerShell)를 사용하는 DBA 또는 다른 사용자
- 드라이버나 연결 문자열을 변경할 수 없는 비 Azure 머신에서 실행되는 이전 애플리케이션
위와 같은 클라이언트에 대해 인증 방법 선택 방식과 추가 고려 사항 및 제약 조건의 측면에서 살펴보겠습니다.
Azure VM에서 실행되는 애플리케이션
Azure 리소스에 대한 관리 ID는 일반적으로 Azure 가상 머신에서 실행되는 애플리케이션에 대한 암호 없는 인증의 권장되는 형식입니다.
도메인 조인된 비 Azure 머신에서 실행되는 애플리케이션
비 Azure 머신의 경우 관리 ID 사용 옵션이 지원되지 않습니다. Microsoft Entra ID를 통한 페더레이션된 인증은 도메인이 Microsoft Entra ID와 페더레이션되었다고 가정할 때 Azure 외부의 도메인 조인 컴퓨터에서 실행되는 앱에 권장되는 인증 방법입니다.
비 Azure 머신이 도메인 조인되지 않은 경우 다음을 수행할 수 있습니다.
- Microsoft Entra ID에서 애플리케이션에 대한 애플리케이션 ID를 만듭니다.
- 인증서를 애플리케이션 ID와 연결합니다.
- 클라이언트 ID와 인증서를 제공하여 Azure SQL Database의 토큰을 획득하도록 애플리케이션을 수정합니다.
인증서에 프라이빗 키가 포함되어 있어야 하고 프라이빗 키가 애플리케이션을 호스트하는 머신에 배포되어야 하지만 최소한 애플리케이션 코드 또는 구성에서 애플리케이션 비밀을 하드 코딩하지 않도록 해야 합니다. (인증서 지문으로 앱을 구성해야 합니다.)
도메인 조인되지 않은 비 Azure 머신에서 SQL 관리 도구를 사용하는 DBA 또는 다른 사용자
Azure 외부의 사용자는 가능하면 암호 사용을 제거하는 것이 가장 좋습니다. Microsoft Entra 통합 인증을 사용하면 SQL 도구에서 사용되는 암호를 제거할 수 있습니다. 그러나 도구는 도메인 가입 컴퓨터에서 실행되어야 하며 도메인은 Microsoft Entra ID와 페더레이션되어야 하지만 이 시나리오에서는 그렇지 않습니다.
환경이 통합 인증에 요구되는 필수 조건을 충족하지 못하므로 대부분의 SQL 도구에서 지원하는 다단계 인증을 통해 Microsoft Entra 대화형 인증을 사용하는 것이 좋습니다.
드라이버나 연결 문자열을 변경할 수 없는 비 Azure 머신에서 실행되는 이전 애플리케이션
드라이버 또는 연결 문자열을 변경할 수 없는 시나리오에서 암호 제거용 옵션이 현재 존재하지 않습니다. 이러한 이전 애플리케이션은 계속해서 SQL 인증을 사용해야 합니다. 애플리케이션 인증을 위한 더욱 안전하고 보호되는 접근 방식을 사용하기 위해 제한에 대한 내용과 제한을 해제할 수 있는 방법을 자세히 알아보는 것이 좋습니다.