準備

  • 5 分

組織の信頼性の高い要件を満たす既存のアーキテクチャに独自の機能強化を追加します。 ここでは、演習に成功するために必要なバックグラウンドとなるコンテキストについて説明します。

問題のコンテキスト

Contoso Shoes は、次の注目度の高い製品の発売に備える必要があります。このリリースでは、トラフィックの大幅な増加が予想されます。 過去 2 年間に、Web サイトが半日ほどオフラインになるといった問題を引き起こした、いくつかのインシデントがありました。 開発/テスト環境でシステムが完全にテストされておらず、いくつかのバグが運用環境に紛れ込んでいました。 オペレーターが根本原因をすばやく特定できなかったため、トラブルシューティングと修復に長い時間がかかりました。

特定のコンポーネントを使用できないときに、いくつかの課題が生じました。 コンピューティングに対するスケールアウト操作は、Azure Key Vault が正しく構成されていない場合に影響を受けました。 また、リージョンの障害に対する戦略がありません。 最近のインシデントでは、西ヨーロッパ地域全体がダウンしました。 ワークロードはそのリージョンでのみ実行されていたため、会社はリージョンが復旧するまで財務上の損失を負わざるを得ませんでした。

現在のアーキテクチャ

この課題を完了するには、Contoso Shoes の現在のアーキテクチャをよく理解している必要があります。 API レイヤーに焦点を当ててみましょう。

Web アプリケーションの基本的なアーキテクチャの図。

コンポーネント

このアーキテクチャのすべてのコンポーネントは、1 つのリージョンにデプロイされます。

  • Azure App Service プランの Standard S2 SKU は、アプリをホストするコンピューティング プラットフォームを提供します。 自動スケールが有効になっています。 開発環境では、Basic B1 SKU が使用されます。

  • Azure App Service は、コンテナー内で API コードを実行するアプリケーション プラットフォームを提供します。 App Service 認証機能は、承認に対して有効になっています。

  • デプロイ スロットでは、デプロイをステージングし、運用環境のデプロイとスワップできます。 これらは運用環境でのみ使用されます。

  • Azure Container Registry は、コンテナー化された API コードを格納し、ワークロード チームが作成および管理する継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを介してプッシュされます。 運用環境と開発/テスト環境の両方でコンテナー レジストリが使用されます。

  • SQL API を使用する Azure Cosmos DB には、ワークロードに関連するすべての状態が格納されます。 Cosmos DB データベース アカウントには、共有スループット モデルのいくつかのコンテナーを含む 1 つのデータベースがあります。 Azure Cosmos アカウントでは、サーバーレス容量モードが使用されます。 運用環境用に 1 つのインスタンスがあり、開発/テスト環境用にもう 1 つあります。

  • Azure Key Vault には、API が 1 つの要求フローの一部として外部のサードパーティ API への HTTP POST 呼び出しを行うために必要なシークレットが格納されます。 アプリケーションは、Azure App Service のアプリ構成の Key Vault 参照を介してシークレットにアクセスします。 運用環境用に 1 つの Key Vault があり、開発/テスト環境用にもう 1 つあります。

  • Azure Log Analytics は、ソリューションで使用されるすべてのコンポーネントのすべての Azure Diagnostics 設定のログとメトリックを格納するための統合シンクとして使用されます。 運用環境用に 1 つのワークスペースがあり、開発/テスト環境用にもう 1 つあります。

  • Azure Application Insights は、API からテレメトリとログをキャプチャするために使用されます。 Application Insights では、専用のログ分析ワークスペースに書き込むのではなく、自己完結型モードを使用します。 運用環境と開発/テスト環境では、共通のインスタンスは共有されません。

  • Azure Pipelines は、運用前および運用環境でワークロードをビルド、テスト、デプロイする CI/CD に使用されます。 ワークロード チームはパイプラインを管理します。また、ソリューション内のすべてのインフラストラクチャも管理します。 Bicep は、コードとしてのインフラストラクチャ (IaC) のために選ばれるテクノロジです。

設計の選択肢

コンポーネントの一覧では、"デプロイ スタンプ" は、要求の処理に参加するサービスで構成されます。 これらのサービスには、App Services と API コードと Cosmos DB が含まれます。 スタンプには、非機能コンポーネントも含まれます。キー コンテナーおよびコンテナー レジストリ。 アプリケーションには、パフォーマンスと回復性のフレームワークに関して、サードパーティとの依存関係があります。 システム マネージド ID は、スタンプのコンポーネント間で使用されます。

スタンプでは、App Services は負荷に基づいて自動的にスケーリングするように構成されます。

運用と開発/テストには、個別の環境が使用されます。 運用環境では、App Service プランの Standard SKU が使用されています。 会社は、アプリケーションを運用環境にデプロイする前にスロットでプレウォーミングできるようにするために、この選択をしました。 開発/テスト環境では、コストの最適化のために Basic SKU が使用されています。 どちらの環境にも、独自のサービス インスタンスがあります。 Container Registry のみが環境間で共有されます。

コンテナー化された API コードは、App Service で実行される 1 つのコンテナー イメージで提供されます。 API には、さまざまなフロントエンドが読み取りと書き込みの両方に使用する、複数の HTTP エンドポイントがあります。 フロントエンドはこのモジュールのスコープ外ですが、この状態のミッションクリティカルな状態を考慮した全体像ではスコープ内になります。 このコードは、基本的なテレメトリをキャプチャするために Application Insights でインストルメント化されました。 このコードを開発したチームは、API コンテナー イメージと CI/CD パイプラインの CI/CD パイプラインも管理します。

トレードオフ

しかし、他と同様に、現在のアーキテクチャとのトレードオフがあります。 ビジネス要件では、信頼性や操作性よりもコストの最適化が優先されました。 コスト制限内を収めるために、アーキテクチャは改善していません。 プラットフォームが提供する信頼性機能を利用するには、コンポーネントが不足しています。 たとえば、コンピューティング用の SKU を選択すると、ワークロードで Availability Zones を使用できなくなります。 テレメトリの場合、Log Analytics と統合されていない古いバージョンの Application Insights が使用されます。

また、ワークロードへのアクセスが広範囲に広がり過ぎています。 たとえば、仮想ネットワークを統合せずに、すべての Azure サービスにパブリック インターネット経由で直接アクセスできます。

ソリューションが開発されたとき、アプリ開発チームは 1 つの Azure サブスクリプションを使用し、開発/テストと運用環境を同じサブスクリプションに併置しました。これにより、DevOpsチームにとってツールの使用が容易になりました。 ただし、運用リソースと開発/テスト リソースは完全には分離されていません。 一部のリソースは 2 つの環境間で共有されますが、Contoso Shoes の他のソリューションから分離されたサブスクリプションを取得しました。

また、開発/テスト環境は、開発チームと QA チームのすべてのメンバーで共有される 1 つの環境です。 チームの規模と、チーム間の調整に高度な分離が必要でなかった点から、この選択が妥当であると判断されました。 チームとソリューションが進化するにつれて、単一の開発/テスト環境では、ワークストリームのライフサイクルが衝突するようになり、一本化することが難しくなりました。 チャーンと信頼性に与える影響は、はかり知れません。

プロジェクトの仕様

同社は、予想される負荷の増加に対応できるように、ソリューション アーキテクチャに機能を追加したいと考えています。 ビジネス要件を次に示します。

  • アーキテクチャを複数のリージョンに拡張することで、リージョンの障害に耐える機能を構築する
  • 地理的により近いリージョンでより迅速にクライアントにサービスを提供することで、カスタマー エクスペリエンスを向上する
  • Azure ロードマップに合わせて、Azure サービスが提供する最新の信頼性機能を活用する
  • 全体的な正常性モデルを構築して、問題を早期にキャッチし、システム内の連鎖的な影響を検出する

これらの要件は、改善計画を優先順に並べたリストにすぎません。 アプリケーション チームは、このソリューションの信頼性をミッションクリティカルな標準にまで引き上げるには、"すべて" の設計領域を考慮する必要があることを認識しています。 今後の演習で取り上げる側面でチームを支援した後は、ソリューションと操作性の改善が妨げられることはありませんので、ご安心ください。

チームへようこそ! Contoso Shoes は、あなたが勧める事柄を聞くのを楽しみにしています。

セットアップ

この "チャレンジ プロジェクト" では、あなたは Contoso Shoes が信頼性を高めるという目標を達成できるように助けるアーキテクトの役割を担います。上記の優先順位が付けられた項目から始めて行きましょう。

  • アーキテクチャ ダイアグラム ツールを使用してアーキテクチャを視覚化することをお勧めします。
  • サービスとその機能に慣れている場合は、この課題のために Azure サブスクリプションを取得する必要はありません。