データ アプリケーション参照パターン
データ アプリケーションをデータ ランディング ゾーンにオンボードすると、チームには専用のリソース グループ、サブネット、共有リソースへのアクセスが付与されます。 この時点から、環境の所有権はそれぞれのデータ アプリケーション チームに引き渡されます。 これらのチームが、エンドツーエンドの実装と所有コストの観点から責任を引き継ぐ必要があります。
開始する方法を簡略化してリード タイムを短縮し、特定のユース ケースに向けた環境を作成するために、組織は組織内に参照パターンを提供できます。 これらの参照実装は、バッチ データ処理、ストリーミング データ処理、データ サイエンスなどの特定のユース ケースに向けた一連のサービスを正しく作成し、成功への道を具体的に示す、コードとしてのインフラストラクチャ (IaC) 定義で構成されます。 これらのパターンには、データ ソリューションの実装時にベースラインとして利用できる汎用のアプリケーション コードも含まれることがあります。 データ アプリケーションの参照パターンは、組織によって異なる場合があり、利用されるツールと、データ ランディング ゾーン全体で繰り返し使用される共通のデータ実装パターンに大きく左右されます。 クラウド規模の分析では、ベースラインとして使用でき、企業の要件に応じてさらに強化できる、一連のキュレーション データ アプリケーション参照設計も提供されます。 これらは以下のページにあります。
その他の自動化を使用すると、摩擦を生じる可能性のある点をさらに減らし、データ アプリケーション チームのためにパターンの初期デプロイを自動化することさえできます。 詳細については、クラウド規模の分析に向けたプラットフォームの自動化と DevOps に関するページを参照してください。
最終的には、データ アプリケーション チームがソリューションのコードベース全体を所有する必要があるため、これらの参照実装をチームに引き渡すことを目的とする必要があります。 Azure テンプレート スペックなどの抽象化レイヤーを追加することは、1 つの選択肢でもありますが、摩擦を生じる点の数を増やすだけです。これらのリソースを所有し、管理している中央チームが、前記と同様に、必要とされる変更を要求する必要があるためです。 中央チームがその後、変更をテストしてリリースするためのアクションを実行する必要があります。 さらに、テンプレート スペックの他の利用者に影響を与えないために、より複雑なリリース管理プロセスが必要な場合があります。最後に、テンプレート内で特定の変更を適用するために、各チームが異なるパラメーターを公開する必要が生じる場合があるため、テンプレートは時間がたつとより複雑になります。 したがって、参照パターンを引き継ぐことが、それによって必要がある場合にはデータ アプリケーション チームが必要な変更を加えられるようになるため、最も容易で有効な解決策です。 これらのチームに IaC の概念に触れてもらうことは、一定の時間がかかることもありますが、最終的にはデータ プラットフォーム全体でより優れたエンジニアリングの実務が実現されることになる優れたアプローチです。
詳細については、クラウド規模で分析をスケーリングすることに関するページを参照してください。