シナリオ 1 のソリューション - グローバル スケールとセキュリティで保護されたアクセスを設計する
前のユニットでは、コンテンツ配信ネットワークのグローバル スケールに関するシナリオに取り組みました。 このユニットでは、考えられる 1 つのソリューションと、考慮すべきいくつかの項目を確認します。
確認する場合、提供されたソリューションを前のユニットで開発したものと比較する必要があります。 多くの場合、問題には適切なソリューションが複数存在しますが、常にトレードオフがあります。 自分のソリューション内のどの項目が提案されたものと異なりますか。 自分のソリューションには、再考の可能性があるものは何かありますか。 提供されたソリューションに、自分のソリューション内でより詳細に対処されると考えられることが何かありますか。
デプロイ オプションと構成
検討すべき最初の決定事項は、Azure SQL のどのデプロイ オプションを選択する必要があるかということです。 Azure 仮想マシン (VM) 内の SQL Server は機能しますが、サービスとしてのプラットフォーム (PaaS) オファリングを使用すると管理オーバーヘッドが少なくなり、より適している可能性があります。
顧客は、インスタンススコープ機能である共通言語ランタイム (CLR) を使用しています。 Azure SQL Managed Instance は、CLR、Service Broker、データベース メールなどのインスタンススコープ機能をサポートする唯一の PaaS デプロイ オプションです。 このため、Azure SQL Managed Instance を使用すると、顧客は CLR アプリケーションを Azure SQL Database と互換性のあるソリューション (エラスティック データベース ジョブなど) に書き直さずに、PaaS オファリングに移行できるようになります。
次の決定事項は、サービス レベルに関係します。 顧客はその読み取りと書き込みのワークロードを分離する必要があるため、Business Critical サービス レベルを使用するのが、それを実現する最も簡単な方法です。 Business Critical サービス レベルには、バックグラウンドで実行されている Always On 可用性グループがあります。 これらのセカンダリ レプリカの 1 つを、読み取り専用ワークロードに使用できます。
Business Critical は、読み取りと書き込みのワークロードを分離するためのここでの構成の半分に過ぎません。 このシナリオは、顧客が、読み取りと書き込みのワークロードを分離しながら、複数のクエリが同時に実行されている複数のリージョンにわたってスケーリングできる必要があることを示しています。
この課題に対処できる可能性のある 2 つのオプションとして、geo レプリケーションと自動フェールオーバー グループがあります。 ただし、geo レプリケーションは現在、 Azure SQL Managed Instance ではサポートされていません。 そのため、自動フェールオーバー グループの使用が、グローバルな読み取りスケーリングを実現する際にこのシナリオで役立つ唯一のオプションです。
顧客は自動フェールオーバー グループを使用するため、Business Critical サービス レベルを必要とするかどうかは、その分析ワークロードに必要な読み取り専用エンドポイントの数によって異なります。 顧客は、Business Critical サービス レベルで自動フェールオーバー グループを使用して、次の 3 つの読み取り可能なエンドポイントを取得します。
- プライマリ リージョンの可用性グループからの 1 つのセカンダリ レプリカ
- フェールオーバー グループのセカンダリ (セカンダリ リージョン内のデータベースのプライマリ レプリカ)
- セカンダリ リージョンの可用性グループからのセカンダリ レプリカ
分析ワークロードでこれらの読み取り可能なレプリカがすべて必要とされるわけではない場合、General Purpose を使用すると、よりコスト効率の高いソリューションになる可能性があります。
最適な認証方法の選択
このシナリオのもう 1 つの要素には、可能な限り最も安全なテクノロジを作成して使用する必要がある場合に、各アプリケーションやユーザーがソリューションに接続するための最適な方法を決定することが関係します。 シナリオを分解すると、次の 4 つの別個のクライアントに Azure SQL Managed Instance へのアクセスが必要になります。
- 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 経由の統合認証は、Azure の外部にあるドメインに参加しているマシンで実行されているアプリで推奨される認証方法です (ドメインが Microsoft Entra ID とフェデレーションされていることを前提とします)。
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 認証を使用する必要があります。 アプリケーションの認証にさらに安全で保護された方法を使用するために、制限事項についてさらに詳しく調べ、それらを取り除く方法を検討してください。