演習 - 階層化された正常性の構造を構築する
この演習のタスクは、サンプル アプリケーションの階層化された正常性モデルを設計することです。 まず、アプリケーション アーキテクチャ、アプリケーションで使用される主要な Azure サービス、Azure サービスが全体的なユーザー エクスペリエンスにどのように貢献するかを確認します。
サンプル アプリケーション
この演習の例は、Contoso Shoes によって使用される Web アプリケーションです。 このアプリケーションを使うと、従業員は、製品のカタログを参照したり、カタログ内の個々のアイテムを更新したり、アプリケーション内でコメントを作成することで他のユーザーと対話したりできます。
Contoso Shoes の運用チームは、このアプリケーションに対する 2 つの重要なビジネス要件を特定しました。 従業員が次のことを行える必要があります。
- アイテムの一覧を表示したり、アイテムを参照したりして、カタログと対話する。
- 他のユーザーが表示できるように個々のアイテムのコメントを作成する。
正常性モデルには、少なくともそれら 2 つの重要な操作が含まれている必要があります。
アーキテクチャ
Components
フロントエンド Web アプリケーション: Azure Web Apps で実行される、このワークロードのユーザー インターフェイスです。
- "読み取り元": Catalog API、Azure Blob Storage
- "書き込み先": Catalog API
Catalog API: フロントエンド Web アプリケーションがカタログ アイテムとコメントに対するデータ操作に使用する API レイヤーです。 データベースへの書き込みは行いません。 代わりに、非同期的に処理されるメッセージがイベント ハブに送信されます。 このコンポーネントは、Azure Functions でホストされます。
- "読み取り元": Azure Cosmos DB
- "書き込み先": Azure Event Hubs
バックグラウンド プロセッサ: データベースの更新を非同期的に処理するコンポーネントです。 このプロセッサにはパブリック エンドポイントがありません。 このコンポーネントは、Azure Functions でホストされます。
- "読み取り元": Azure Event Hubs
- "書き込み先": Azure Cosmos DB
メッセージ ブローカー: メッセージング プロセッサは、Azure Event Hubs を使って、Catalog API とバックグラウンド プロセッサの間でメッセージを渡します。
データベース: データは Azure Cosmos DB に保持されます。 Catalog API は、データベースから直接読み取ります。 バックグラウンド プロセッサは、書き込みを処理します。 画像は Azure Blob Storage に格納されます。
シークレット: このワークロードのアプリケーション コンポーネントは、シークレットを使用してアクセスを認可します。 シークレットは Azure Key Vault に格納されます。 Catalog API とバックグラウンド プロセッサは、接続文字列を使ってデータベースと Azure Event Hubs にアクセスします。 フロントエンド Web アプリケーションは、API キーを使って Catalog API を呼び出します。
監視: アプリケーション コンポーネントは、すべてのデータ測定を Application Insights に送信し、Log Analytics ワークスペースでサポートされます。 同じワークスペースを使用して、このワークロードの他のログとメトリックが収集されます。
アーキテクチャをレイヤーで分割する
前のユニットで説明したように、正常性モデルは階層化された構造である必要があります。 正常性をモデリングするプロセスは、すべてのユーザー フローを定義し、機能コンポーネントと論理コンポーネントの間の依存関係、および Azure リソース間の依存関係をマップする、アーキテクチャに関する演習です。
ユーザー フローを特定し、正常性モデルを構築することは、この段階での概念的な演習です。 ペンと紙、または空白のドキュメントを使って、個々のレイヤーをメモし、構造を描きます。
この演習の正常性モデルには、ユーザー フロー、アプリケーション コンポーネント、Azure リソースという 3 つのレイヤーがあります。
ユーザー フロー
アーキテクチャの上部から始めて、考えられる "ユーザー フロー" を、アプリケーションの期待される機能に基づいて検討します。 技術的な詳細と Azure サービスは抽象化し、ユーザーの観点からフローを評価してみてください。
- "重要なプロセスは何ですか?"
- "従業員はアプリケーションをどのように使ってビジネス目標を達成しますか?"
運用チームによって特定された要件に基づき、上位レイヤーには少なくとも 2 つのユーザー フロー、すなわちカタログ アイテムの一覧表示とコメントの追加が必要です。
もっと思いつく場合は、それらを正常性モデルに含めます。
アプリケーション コンポーネント
レイヤーを下に移動して、アプリケーション コンポーネントを評価します。 まず、次のような質問をします。
- "アプリケーションのどの部分によって、このフローが機能しますか?"
- "このフローに参加するマイクロサービスまたはコンポーネントはどれですか?"
- "この部分が失敗しても、このフローは引き続き機能しますか?"
目的は、各ユーザー フローに関係するアプリケーション コンポーネントを技術レベルで特定することです。 このようなコンポーネントには、API、バックグラウンド ワーカー、マイクロサービスなどが考えられます。
このワークロードには、特定された 2 つのユーザー フローに参加する、少なくとも 3 つのアプリケーション コンポーネントがあります。すなわち、フロントエンド、Catalog API、バックグラウンド プロセッサです。
Azure リソース
下部のレイヤーには、個々のアプリケーション コンポーネントによって使用される Azure リソースが含まれます。 この演習では、そのコンポーネントとリソースについては「コンポーネント」セクションで説明しています。
Note
実際のシナリオでは、おそらくより多くのサービスがあり、それらの間により複雑な関係があるでしょう。 正常性モデルの構築を成功させるための鍵は、どの部分が重要であり、各コンポーネントがシステムの全体的な正常性にどのように影響するかを特定することです。
最終的な正常性モデル構造を描く
集めた情報を、正常性モデル構造のグラフィカルな表現に書き込みましょう。 次の図のようになるはずです。
上から下に、Web アプリケーションの正常性モデルには次のレイヤーがあります。
ユーザー フロー
- カタログ アイテムの一覧表示。 フロントエンド Web アプリケーションと Catalog API に依存します。
- コメントの追加。 フロントエンド Web アプリケーション、Catalog API、バックグラウンド プロセッサに依存します。
アプリケーション コンポーネント
- フロントエンド Web アプリケーション。 Blob Storage と Catalog API に依存します。
- Catalog API。 Azure Cosmos DB、Key Vault、Event Hubs に依存します。
- バックグラウンド プロセッサ。 Azure Cosmos DB、Key Vault、Event Hubs に依存します。
Azure リソース
- Blob Storage
- Azure Cosmos DB
- Key Vault
- Event Hubs