次の方法で共有

DevTest Labs のエンタープライズ参照アーキテクチャ

  • [アーティクル]

この記事では、エンタープライズで Azure DevTest Labs をデプロイするための参照アーキテクチャを提供します。 このアーキテクチャには次の重要な要素が含まれます。

  • Azure ExpressRoute を介したオンプレミス接続
  • 仮想マシン (VM) にリモート サインインするためのリモート デスクトップ ゲートウェイ
  • プライベート成果物リポジトリへの接続
  • ラボで使用されるその他のサービスとしてのプラットフォーム (PaaS) コンポーネント

アーキテクチャ

次の図は、一般的な DevTest Labs エンタープライズ デプロイを示しています。 このアーキテクチャでは、異なる Azure サブスクリプション内のいくつかのラボを、会社のオンプレミス ネットワークに接続します。

エンタープライズ DevTest Labs デプロイの参照アーキテクチャを示す図。

DevTest Labs コンポーネント

DevTest Labs によって、エンタープライズでは簡単かつ迅速に Azure リソースへのアクセスを提供できるようになります。 各ラボには、サービスとしてのソフトウェア (SaaS)、サービスとしてのインフラストラクチャ (IaaS)、および PaaS リソースが含まれています。 ラボ ユーザーは、VM、PaaS 環境、および VM 成果物を作成して構成できます。

前の図では、Azure サブスクリプション 1 のチーム ラボ 1 に、ラボからアクセスして使用できる Azure コンポーネントの例が示されています。 詳細については、DevTest Labs についてのページを参照してください。

接続コンポーネント

ラボからオンプレミスの企業リソースにアクセスする必要がある場合は、オンプレミス接続が必要です。 一般的なシナリオを次に示します。

  • 一部のオンプレミス データをクラウドに移行できない。
  • ラボ VM をオンプレミス ドメインに参加させたい。
  • セキュリティまたはコンプライアンス上の理由から、すべてのクラウド ネットワーク トラフィックを強制的にオンプレミスのファイアウォール経由にしたい。

このアーキテクチャでは、オンプレミス ネットワークに接続するために ExpressRoute を使用します。 サイト間 VPN を使用することもできます。

オンプレミスでは、リモート デスクトップ ゲートウェイを使用すると、DevTest Labs への送信リモート デスクトップ プロトコル (RDP) 接続が有効になります。 エンタープライズの企業ファイアウォールでは通常、企業ファイアウォールでの送信接続がブロックされます。 接続を有効にするには、次のようにします。

  • リモート デスクトップ ゲートウェイを使用し、ゲートウェイ ロード バランサーの静的 IP アドレスを許可します。
  • 強制トンネリングを使用して、すべての RDP トラフィックを ExpressRoute またはサイト間 VPN 接続経由でリダイレクトします。 強制トンネリングは、エンタープライズ規模の DevTest Labs デプロイの一般的な機能です。

ネットワーク コンポーネント

このアーキテクチャでは、Microsoft Entra ID によって、すべてのネットワークで ID とアクセスの管理が提供されます。 ラボ VM には通常、アクセス用のローカル管理アカウントがあります。 使用できる Microsoft Entra ID、オンプレミス、または Microsoft Entra Domain Service ドメインがある場合は、ラボ VM をドメインに参加させることができます。 これでユーザーは自分のドメイン ベースの ID を使用して VM に接続できるようになります。

Azure ネットワーク トポロジでは、ラボ リソースがオンプレミス ネットワークやインターネットにアクセスして通信する方法を制御します。 このアーキテクチャは、エンタープライズ ネットワーク DevTest Labs の一般的な方法を示しています。 ラボは、ExpressRoute またはサイト間 VPN 接続を経由し、ハブスポーク構成のピアリングされた仮想ネットワークを介して、オンプレミス ネットワークに接続します。

DevTest Labs では Azure Virtual Network を直接使用するため、ネットワーク インフラストラクチャの設定方法に制限はありません。 ソースと宛先の IP アドレスに基づいてクラウド トラフィックを制限するために、ネットワーク セキュリティ グループを設定できます。 たとえば、企業ネットワークからラボのネットワークに送信されたトラフィックのみを許可できます。

スケーラビリティに関する考慮事項

DevTest Labs には組み込みのクォータや制限はありませんが、ラボで使用される他の Azure リソースにはサブスクリプション レベルのクォータがあります。 一般的なエンタープライズ デプロイでは、DevTest Labs の大規模なデプロイに対応するためにいくつかの Azure サブスクリプションが必要です。 通常、エンタープライズは次のクォータに達します。

  • リソース グループ。 DevTest Labs では新しい VM ごとにリソース グループを作成し、ラボ ユーザーはリソース グループ内に環境を作成します。 サブスクリプションには、最大 980 のリソース グループを含めることができるので、これがサブスクリプション内の VM と環境の制限です。

    次の 2 つの戦略が、リソース グループの制限を超えないようにするのに役立つ場合があります。

    • すべての VM が同じリソース グループに入るようにする。 この戦略はリソース グループの制限を満たすのに役立ちますが、リソース グループごとのリソースの種類の制限に影響します。
    • 共有パブリック IP を使用する。 VM にパブリック IP アドレスの使用が許可されている場合は、同じサイズとリージョンのすべての VM を同じリソース グループに入れます。 この構成は、リソース グループ クォータとリソース グループごとのリソースの種類クォータの両方を満たすのに役立ちます。

  • リソースの種類ごとのリソース グループあたりのリソース数。 リソースの種類ごとの、リソース グループあたりのリソース数の既定の制限は 800 です。 すべての VM を同じリソース グループに入れると、特に VM に多くの追加ディスクがある場合は、この制限に達するのがはるかに早くなります。

  • ストレージ アカウント。 DevTest Labs のすべてのラボに、ストレージ アカウントが付属しています。 既定では、Azure のクォータ (ストレージ アカウント数) は、サブスクリプションごと、リージョンごとに 250 です。 したがって、1 つのリージョン内の DevTest Labs の最大数も 250 です。 クォータの引き上げにより、リージョンごとに最大 500 個のストレージ アカウントを作成できます。 詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。

  • ロールの割り当て。 ロールの割り当てでは、ユーザーまたはプリンシパルにリソースへのアクセス権を付与します。 Azure には、サブスクリプションあたり 2,000 のロールの割り当て制限があります。

    DevTest Labs では、既定でラボ VM ごとに 1 つのリソース グループが作成されます。 VM 作成者は、VM に対する "所有者" アクセス許可と、リソース グループに対する "閲覧者" アクセス許可を取得します。 そのため、各ラボ VM では 2 つのロールの割り当てが使用されます。 ラボに対するアクセス許可をユーザーに付与する場合も、ロールの割り当てが使用されます。

  • API 読み取り/書き込み。 REST API、PowerShell、Azure CLI、および Azure SDK を使用して、Azure と DevTest Labs を自動化することができます。 各 Azure サブスクリプションでは、1 時間あたり最大 12,000 の読み取り要求と 1,200 の書き込み要求が可能です。 DevTest Labs を自動化することで、API 要求の制限に達する可能性があります。

管理容易性に関する考慮事項

Azure portal を使用して 1 つの DevTest Labs インスタンスを一度に管理できますが、エンタープライズには管理対象の複数の Azure サブスクリプションと多数のラボがある場合があります。 すべてのラボに一貫して変更を加えるにはスクリプトの自動化が必要です。

DevTest Labs のデプロイでスクリプトを使用する例をいくつか以下に示します。

  • ラボ設定の変更。 PowerShell スクリプト、Azure CLI、または REST API を使用して、すべてのラボの特定のラボ設定を更新します。 たとえば、新しい VM インスタンス サイズを許可するためにすべてのラボを更新します。

  • 成果物リポジトリの個人用アクセス トークン (PAT) の更新。 通常、Git リポジトリの PAT は、90 日、1 年、または 2 年で有効期限が切れます。 継続性を確保するために、PAT を延長することが重要です。 または、新しい PAT を作成し、自動化を使用してすべてのラボに適用します。

  • ラボ設定に対する変更の制限。 マーケットプレース イメージの使用を許可するなど、特定の設定を制限するために、Azure Policy を使用してリソースの種類に対する変更を防ぐことができます。 あるいはカスタム ロールを作成し、組み込みのラボ ロールではなく、そのロールをユーザーに付与することもできます。 内部サポート、ラボのお知らせ、許可される VM サイズなど、ほとんどのラボ設定の変更を制限できます。

  • VM の名前付け規則の適用。 Azure Policy を使用して、クラウド ベースの環境で VM を特定するのに役立つ名前付けパターンを指定することができます。

DevTest Labs の Azure リソースは、他の目的の場合と同じように管理します。 たとえば、Azure Policy はラボで作成した VM に適用されます。 Microsoft Defender for Cloud では、ラボ VM のコンプライアンスに関するレポートを作成できます。 Azure Backup では、ラボ VM の定期的なバックアップを提供できます。

セキュリティに関する考慮事項

DevTest Labs では自動的に、組み込みの Azure セキュリティ機能の利点が得られます。 受信リモート デスクトップ接続の発信元を企業ネットワークのみに制限するために、リモート デスクトップ ゲートウェイ上の仮想ネットワークにネットワーク セキュリティ グループを追加できます。

もう 1 つのセキュリティ上の考慮事項は、ラボ ユーザーに付与するアクセス許可のレベルです。 ラボ所有者は、Azure ロールベースのアクセス制御 (Azure RBAC) を使用してロールをユーザーに割り当て、リソースとアクセス レベルのアクセス許可を設定します。 DevTest Labs の最も一般的なアクセス許可は、所有者、共同作成者、およびユーザーです。 カスタム ロールを作成して割り当てることもできます。 詳細については、「Azure DevTest Labs での所有者とユーザーの追加」をご覧ください。

次の手順

このシリーズの次の記事「概念実証の提供」を参照してください。