Azure DevTest Labs インフラストラクチャをスケールアップする

エンタープライズ規模で DevTest Labs の実装を成功させるには、重要な意思決定ポイントを考慮し、Azure DevTest Labs の迅速なデプロイと実装のためのアプローチを計画する必要があります。

この記事では、実装を計画するときに考慮する必要がある重要な決定ポイントについて説明し、デプロイに推奨されるアプローチを提供します。

重要な意思決定ポイント

エンタープライズ規模で DevTest Labs を実装する前に、いくつかの重要な意思決定ポイントがあります。 これらの意思決定ポイントを高いレベルで理解することは、将来の設計上の決定を抱えている組織に役立ちます。 ただし、これらのポイントが、組織が概念実証を開始する妨げとならないようにする必要があります。

初期のスケール アップ計画には、重要な領域が 3 つあります。

• ネットワークとセキュリティ
• サブスクリプションのトポロジ
• ロールと責任

ネットワークとセキュリティ

ネットワークとセキュリティは、すべての組織の土台となるものです。 エンタープライズ全体の展開には非常に深い分析が必要ですが、適切に概念実証を完了するための要件の数は、より少数です。 いくつかの主な重点領域は次のとおりです。

• Azure サブスクリプション – DevTest Labs を配置するためには、リソースを作成するための適切な権限を持って Azure サブスクリプションにアクセスできる必要があります。 マイクロソフト エンタープライズ契約や従量課金制など、Azure サブスクリプションにアクセスする方法はいくつかあります。 Azure サブスクリプションへのアクセス権取得の詳細については、「企業向け Azure ライセンス付与」をご覧ください。
• オンプレミスのリソースへのアクセス – 組織によっては、DevTest Labs 内のリソースが、オンプレミスのリソースにアクセスできる必要があります。 オンプレミス環境から Azure へのセキュリティ的に安全な接続が必要です。 開始する前に、VPN または接続 Azure ExpressRoute 接続をセットアップして構成することが重要です。 詳細については、「Virtual Network の概要」を参照してください。
• その他のセキュリティ要件 – マシン ポリシー、パブリック IP アドレスへのアクセス、インターネットへの接続など、その他のセキュリティ要件は、概念実証を実行する前に再調査が必要となる可能性があるシナリオです。

サブスクリプションのトポロジ

サブスクリプションのトポロジは、企業に DevTest Labs を配置する場合の重要な設計上の考慮事項です。 ただし、概念実証が完了するまでにすべての決定を固める必要はありません。 エンタープライズ実装に必要なサブスクリプションの数を評価する場合、2 つの極端な状況があります。

• 組織全体に対して 1 つのサブスクリプション
• ユーザーごとのサブスクリプション

次に、各アプローチの利点を強調します。

1 つのサブスクリプション

大企業においては、1 つのサブスクリプションのアプローチでは管理ができないことがよくあります。 ただし、サブスクリプションの数を制限すると以下の利点があります。

• エンタープライズのコストの予測。 1 つのサブスクリプションでは、すべてのリソースが 1 つのプール内にあるため、予算の作成がずっと容易になります。 このアプローチでは、請求サイクル内の特定の時点において、コスト管理対策をいつ実施するかの意思決定を単純化できます。
• 多数のサブスクリプションにわたって更新を行うのではなく、すべての更新は 1 つのサブスクリプション内でのみ必要となるため、VM、成果物、数式、ネットワーク構成、アクセス許可、ポリシーなどの管理の容易性が高まります。
• オンプレミス接続を要件とする企業にとって 1 つのサブスクリプションとなるためネットワーク作業が容易です。 サブスクリプションの追加があると、サブスクリプション間の仮想ネットワークの接続 (ハブスポーク モデル) が必要となり、より多くの構成、管理、IP アドレス空間が必要となります。
• 全員が同じサブスクリプションで作業すれば、チームのコラボレーションが容易になります。 たとえば、同僚への VM の再割り当てやチーム リソースの共有が簡単です。

ユーザーごとのサブスクリプション

ユーザーごとの個別のサブスクリプションでは、選択肢の範囲が限定されなくなります。 多くのサブスクリプションを利用する場合の利点は以下のとおりです。

• Azure のスケーリング クォータ による導入の妨げがない。 たとえば、この記事の作成時点では、Azure においてサブスクリプションあたり 200 のストレージ アカウントを使用できます。 Azure ではほとんどのサービスにおいて運用上のクォータがあります (多くはカスタマイズできますが、できないサービスもあります)。 このユーザーごとのサブスクリプションというモデルでは、ほとんどのクォータに関して、上限に達する可能性はごくわずかです。 Azure でのスケーリングのクォータに関する詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。
• グループまたは個人開発者へのチャージ バックが大幅に容易になるので、組織は現在のモデルを使用してコストを計上できます。
• DevTest Labs 環境の所有権とアクセス許可は単純です。 開発者にはサブスクリプション レベルのアクセスを与え、ネットワーク構成、ラボのポリシー、VM の管理を含むすべてのことを管理させます。

Enterprise 内では、こうした両極端の範囲では多くの制約が生じる可能性があります。 そのため、これらの両極端の間になる方法でサブスクリプションを設定する必要があるでしょう。 ベスト プラクティスとしては、組織の目標は、できるだけ少ない数のサブスクリプションを使うことであるべきです。 サブスクリプションの総数が増加するような機能に注意しましょう。 繰り返しますが、サブスクリプションのトポロジは企業の DevTest Labs のデプロイにおいて重要ですが、概念実証を遅らせてはいけません。 ガバナンスに関する記事に、組織におけるサブスクリプションとラボの細分性を決定する方法についての詳細が記載されています。

ロールと責任

DevTest Labs での概念実証には、責任が定義されたプライマリ ロールとして、サブスクリプション所有者、DevTest Labs 所有者、DevTest Labs ユーザーの 3 つがあります。また、必要に応じて共同作成者が加わります。

• サブスクリプション所有者 – サブスクリプション所有者は、ユーザーの割り当て、ポリシーの管理、ネットワーク トポロジの作成と管理、クォータ増加の要求など、Azure サブスクリプションを管理する権限を持ちます。 詳細については、 こちらの記事を参照してください。
• DevTest Labs 所有者 – DevTest Labs 所有者は、ラボに対する完全な管理者アクセスを持っています。 このユーザーは、ユーザーの追加と削除、コスト設定の管理、一般的なラボの設定、およびその他の VM/成果物ベースのタスクを管理します。 ラボ所有者は、DevTest Labs ユーザーのすべての権利も持っています。
• DevTest Labs ユーザー – DevTest Labs ユーザーは、ラボ内で仮想マシンを作成して使用することができます。 これらのユーザーは、自分が作成する VM に対して最小限の管理機能をいくつか持ってします (自分の VM の開始/停止/削除/構成)。 ユーザーは、他のユーザーの VM は管理できません。

DevTest Labs の実装を調整する

このセクションでは、Azure DevTest Labs を短時間でデプロイして実装するための推奨される方法を示します。 次の図は、規範的なガイダンスとして全体的なプロセスに注目したものです。業界のさまざまな要件とシナリオが柔軟にサポートされていることがわかります。

前提条件

この記事では、DevTest Labs をパイロット実装する前に、次のものが既にあることを前提としています。

• Azure サブスクリプション:パイロット チームに、Azure サブスクリプションにリソースをデプロイするためのアクセス権があること。 ワークロードが開発とテストのみの場合、使用できるイメージを追加し、Windows 仮想マシンの料金を抑えるため、Enterprise DevTest オファーを選択することをお勧めします。
• オンプレミス アクセス:必要な場合、オンプレミスへのアクセスが既に構成されていること。 オンプレミス アクセスは、サイト間 VPN 接続または ExpressRoute を使用して実現できます。 ExpressRoute による接続を確立するには何週間もかかるのが普通なので、プロジェクトを始める前に ExpressRoute を用意しておくことをお勧めします。
• パイロット チーム:DevTest Labs を使用する初期開発プロジェクト チームと該当する開発またはテスト アクティビティが特定され、チームの要件/目標/目的が確立されていること。

マイルストーン 1:最初のネットワーク トポロジと設計を確立する

Azure DevTest Labs ソリューションをデプロイするときに最初に注目するのは、仮想マシンに対して計画されている接続を確立することです。 必要な手順の概要は以下のとおりです。

1. Azure で DevTest Labs サブスクリプションに割り当てる初期 IP アドレス範囲を定義します。 このステップでは、将来の拡張に備えて十分な大きさのブロックを提供できるように、予想される VM 使用数を予測する必要があります。
2. DevTest Labs への望ましいアクセス方法を明らかにします (たとえば、外部/内部アクセス)。 このステップでの重要なポイントは、仮想マシンにパブリック IP アドレスを割り当てるかどうかを決定することです (つまり、インターネットから直接アクセスできるようにするか)。
3. Azure クラウド環境とオンプレミスの残りの部分の接続方法を決定して確立します。 ExpressRoute による強制ルーティングが有効になっている場合は、企業のファイアウォールを通過するように仮想マシンでプロキシを適切に構成することが必要になる可能性があります。
4. VM をドメインに参加させる場合は、クラウド ベースのドメイン (たとえば Microsoft Entra ディレクトリ サービス) またはオンプレミスのドメインのどちらに参加するかを決定します。 オンプレミスの場合は、仮想マシンが参加する Active Directory 内の組織単位 (OU) を決定します。 さらに、ユーザーに参加へのアクセス権があることを確認します (または、ドメインにマシン レコードを作成できるサービス アカウントを確立します)

マイルストーン 2:パイロット ラボをデプロイする

ネットワーク トポロジを設定した後は、以下の手順で最初のパイロット ラボを作成できます。

1. 最初の DevTest Labs 環境を作成します。
2. ラボで使用できる VM イメージとサイズを決定します。 DevTest Labs で使用するために Azure にカスタム イメージをアップロードできるかどうかを決定します。
3. ラボにとって最初の Azure ロールベースのアクセス制御 (Azure RBAC) を作成して、ラボへのアクセスをセキュリティ保護します (ラボ所有者とラボ ユーザー)。 DevTest Labs での ID に対しては Microsoft Entra ID と同期された Active Directory アカウントを使用することをお勧めします。
4. スケジュール、コスト管理、クレーム可能 VM、カスタム イメージ、数式など、ポリシーを使用するように DevTest Labs を構成します。
5. Azure Repos/Git などのオンライン リポジトリを設定します。
6. パブリック リポジトリかプライベート リポジトリまたは両方の組み合わせのいずれを使用するかを決定します。 デプロイと長期的な維持のために JSON テンプレートを整理します。
7. 必要な場合は、カスタム成果物を作成します。 この手順は省略可能です。

マイルストーン 3:ドキュメント化、サポート、学習、改善する

最初のパイロット チームは、作業を始めるために詳細なサポートを必要とする場合があります。 その経験を利用して、引き続き Azure DevTest Labs をロールアウトするために適切なドキュメントとサポートを用意します。

1. 新しい DevTest Labs リソースにパイロット チームを紹介します (デモ、ドキュメント)
2. パイロット チームの経験に基づき、必要に応じてドキュメントを計画して配布します
3. 新しいチームのオンボード プロセスを定型化します (ラボの作成と構成、アクセスの提供など)
4. 最初の利用状況に基づき、IP アドレス空間の当初の予測が合理的で正確かどうかを検証します
5. 適切なコンプライアンスとセキュリティ レビューが完了したことを確認します

次のステップ

このシリーズの次の記事をご覧ください。Azure DevTest Labs インフラストラクチャのガバナンス