クラウド規模の分析をプロビジョニングする
データ管理ランディング ゾーンのデプロイ プロセス
データ プラットフォーム運用チームが、データ管理ランディング ゾーンのデプロイを担当します。 データ管理ランディング ゾーンには、データ プラットフォーム運用チームによって管理される独自のリポジトリが必要です。
注意事項
データ管理ランディング ゾーンを作成して展開した後で、データ ランディング ゾーンをデプロイします。
データ ランディング ゾーンのデプロイ プロセス
チームは、データ プラットフォーム運用チームから提供られるテンプレートを使用すると、資産ごとに最初から開始せずにすみます。 新しいランディング ゾーンのデプロイの自動化には分岐パターンをお勧めします。
たとえば、データ ランディング ゾーン運用チームは、IT 管理ツールまたは Power Apps を使用して、新しいデータ ランディング ゾーンを要求します。 要求が承認されたら、要求のパラメーターを使用して次のワークフローを開始します。
- 新しいデータ ランディング ゾーン用の新しいサブスクリプションをデプロイします。
- データ ランディング ゾーン テンプレートのメイン ブランチから分岐させて、新しいリポジトリを作成します。
- 新しいリポジトリにサービス接続を作成します。
- 要求のパラメーターに基づいて、新しいリポジトリのパラメーターを更新します。
- 更新されたパラメーターのチェックインによってトリガーされるサービスをデプロイするためのデプロイ パイプラインを作成します。
- 新しいランディング ゾーンが使用可能になったことを、データ ランディング ゾーン運用チームに通知します。
これで、データ ランディング ゾーン運用チームは、Azure Resource Manager テンプレートを変更または追加できるようになりました。
このワークフローは、Azure プラットフォーム上の複数のサービス セットを使用して自動化できます。 CI/CD パイプラインを使用して、パラメーター ファイル内のパラメーター名の変更など、一部の手順を処理します。 その他の手順は、Logic Apps などの他のワークフロー オーケストレーション ツールを使用して実行できます。
分岐パターンを使用すると、チームは、分岐に使用した元のテンプレートからテンプレートを更新できます。 また、機能強化や新機能がテンプレート リポジトリに実装された場合、運用チームはそれらをフォークにプルすることができます。
リポジトリについて次のベスト プラクティスを採用します。
- メイン ブランチをセキュリティで保護します。
- 変更、更新、および機能強化にはブランチを使用します。
- 変更をメイン ブランチにマージする前に、プル要求を承認するコード所有者を定義します。
- 自動テストを使用してブランチを検証します。
- チーム内のアクションと担当者の数を制限します(ビルド パイプラインとリリース パイプラインをトリガーできるユーザーなど)。
ヒント
チーム間でアクティビティを調整して、元のテンプレートの機能強化や新機能がすべてのデータ ランディング ゾーン インスタンスでレプリケートされるようにします。 運用チームは、元のテンプレートの変更をフォークにプルすることができます。
オンボード プロセスは、データ ランディング ゾーンのデプロイ プロセスとは分離されています。 この分離は、ほとんどの組織にはクラウド運用モデルの一部として標準の Azure サブスクリプション デプロイ プロセスがあるという前提に基づいています。 オンボード プロセスでは、標準の企業コンポーネント (サード パーティの IT サービスマネジメント ツールなど) がデプロイされます。 データ ランディング ゾーン固有のコンポーネントは、次にデプロイされます。
提案される自動化ソリューションには複製/更新/コミット/プッシュに使用できる Git API はありません。 そのため、アプローチとしては、次の PowerShell Runbook を含む Azure Automation アカウントを使用します。
- データ ランディング ゾーンを設定する
- メイン リポジトリをデータ プラットフォームの Git リポジトリに分岐させる
- データ ランディング ゾーンのサブネット構成を設定する
- Microsoft Entra ID を設定する
Runbook は、GitAutomation PowerShell モジュールのGit 関数を使用して、Git リポジトリを操作します。 このモジュールを Azure Automation アカウント内にインストールすることで、ユーザーは Git リポジトリで作成、複製、クエリ、プッシュ、プル、コミットの操作を実行できます。 次の図は、Azure Automation アカウント内にインストールされている GitAutomation モジュールを示しています。
GitAutomation モジュールの Copy-GitRepository 関数を使用して、URL に指定された URL にあるメインの Git リポジトリを、DestinationPath に指定されたデータ プラットフォーム Git パスにクローンします。
データ ランディング ゾーンのデプロイに対するこのアプローチは、柔軟性があると同時に、アクションが組織の要件に準拠することを保証できます。 ライフサイクル管理を有効にするには、元のテンプレートから新しい機能または最適化を適用します。
データ アプリケーション展開プロセス
データ ランディング ゾーンが作成された後に、データ アプリケーション チームのためにオンボードを開始できます。 データ プラットフォームまたはデータ ランディング ゾーンの運用チームが、デプロイの承認を付与します。
デプロイは、DevOps ツールを使用して直接行うことも、API として公開されているパイプライン/ワークフローから呼び出すこともできます。 データ ランディング ゾーンと同様に、デプロイは、元のデータ アプリケーション リポジトリの分岐から始まります。
- ユーザーが新しいデータ アプリケーション サービスを要求します。
- ワークフロー プロセスは、データ プラットフォームまたはデータ ランディング ゾーンの運用チームに承認を要求します。
- ワークフローによって IT Service Management API が呼び出されて、必要なリソース グループが作成され、Azure DevOps サービス接続が作成されます。 ワークフローによってチームが Azure DevOps プロジェクトに割り当てられます。
- ワークフローによって、元のデータ アプリケーション リポジトリが分岐され、宛先の Azure DevOps プロジェクトが作成されます。
- ワークフローによって、Azure Resource Manager テンプレート パラメーター ファイルおよびパイプラインが作成されます。
- 次に、ワークフローによって、ネットワーク要件を作成する Azure パイプラインと、データ アプリケーション サービスをデプロイする、もう 1 つの Azure パイプラインが開始されます。
- ワークフローによって、完了時にユーザーに通知されます。
ヒント
DataOps を初めて使用する場合は、Azure アーキテクチャ センターにある最新のデータ ウェアハウスの DataOps のハンズオン ラボを確認してください。 このラボのシナリオでは、このデプロイ ソリューションを使用できる架空の都市計画オフィスについて説明しています。 このデプロイ ソリューションでは、最新のデータ ウェアハウス アーキテクチャ パターンに従うエンドツーエンドのデータ パイプラインを、対応する DevOps および DataOps プロセスと共に提供し、駐車場の使用を評価して、情報に基づいたビジネス上の意思決定を行います。
まとめ
上記のパターンによって、ポリシーの制御、機敏性、セルフサービス、ライフサイクル管理が実現します。
プロジェクトの開始時点で、データ プラットフォームには、1 つ以上の Azure Boards を含む Azure DevOps プロジェクトが 1 つあります。 個々の DevOps チームは次のことに注目します。
- データ管理ランディング ゾーン、パイプライン、クラウド環境へのサービス接続用として、1 つのリポジトリ。
- データ ランディング ゾーン、データ ランディング ゾーン インスタンスをデプロイするためのパイプライン、クラウド環境へのサービス接続用として、1 つのテンプレート リポジトリ。
- データ製品サービス、データ製品インスタンスをデプロイするためのパイプライン、クラウド環境へのサービス接続用として、1 つのテンプレート リポジトリ。 これらの接続は、データ ランディング ゾーンの Azure DevOps Projects から分岐されます。
データ ランディング ゾーンがデプロイされると、クラウド規模の分析では次のように指定されます。
- 各データ ランディング ゾーンには、独自の Azure DevOps プロジェクトがあり、1 つまたは複数の Azure Boards が含まれます。
- データ アプリケーションごとに、要求の承認後に、データ ランディング ゾーンの Azure DevOps プロジェクト フォークが作成されます。
- 各データ アプリケーションには、次のものが含まれます。
- サービス接続。
- 登録されたパイプライン。
- Azure ボードとリポジトリにアクセスできる DevOps チーム。
- 分岐されたリポジトリの異なるポリシー セット。
データ アプリケーションのデプロイをコントロールするには、次の手順に従います。
- データ ランディング ゾーン運用チームが、メイン リポジトリ ブランチを所有し、セキュリティで保護します。
- メイン ブランチは、テスト環境と運用環境へのデプロイのみに使用されます。
- 機能ブランチは開発環境にデプロイできます。
- 機能ブランチは DataOps チームによって所有されます。 これらは、新機能または変更された機能をテストするために使用されます。
- DataOps チームは、承認なしで、機能ブランチを他の機能ブランチにマージできます。
- DataOps チームが、機能ブランチをメイン ブランチにマージするプル要求を作成し、データ ランディング ゾーン運用チームが承認を行います。
- 元のテンプレートに対する新機能または機能強化は、分岐されたリポジトリにマージされ、更新された状態が維持されます。