このサンプル シナリオでは、Azure の提供するサービスとしてのプラットフォーム (PaaS) ツールを使用した eコマース フロントエンドの実装について説明します。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
このシナリオでは、eコマース サイトからのチケット購入に対応します。シナリオのデータ フローを次に示します。
- Azure Traffic Manager により、ユーザーの要求が、Azure App Service でホストされている eコマース サイトにルーティングされます。
- Azure CDN は、静的なイメージとコンテンツをユーザーに提供します。
- ユーザーが Azure Active Directory B2C テナントを介してアプリケーションにサインインします。
- ユーザーが Azure Search を使用してコンサートを検索します。
- Web サイトによって、Azure SQL Database からコンサートの詳細がプルされます。
- Web サイトから、Blob Storage にある購入済みチケットの画像を参照します。
- データベース クエリの結果が、パフォーマンス向上のため、Azure Cache for Redis にキャッシュされます。
- ユーザーが送信したチケット注文とコンサート レビューがキューに配置されます。
- Azure Functions によって、注文の支払いとコンサート レビューが処理されます。
- Cognitive Services ではコンサート レビューが分析され、センチメント (肯定的または否定的) が判別されます。
- Application Insights が、Web アプリケーションの正常性を監視するためのパフォーマンス メトリックを提供します。
Components
- Azure CDN が、待機時間を減らすために、ユーザーに近い場所から、キャッシュされた静的なコンテンツを提供します。
- Azure Traffic Manager によって、さまざまな Azure リージョンにおけるサービス エンドポイントのユーザー トラフィックの分散が制御されます。
- App Services - Web Apps により Web アプリケーションがホストされ、自動スケーリングと高可用性が可能になります。インフラストラクチャの管理は不要です。
- Azure Active Directory B2C は ID 管理サービスです。このサービスを使用すると、アプリケーションでの顧客のサインアップ、サインイン、およびプロファイル管理の方法をカスタマイズし、制御できます。
- Storage キューには、アプリケーションからアクセスできるキュー メッセージが多数格納されています。
- Functions は、インフラストラクチャを管理せずに、アプリケーションをオンデマンドで実行できるようにするサーバーレス コンピューティング オプションです。
- Cognitive Services - 感情分析は機械学習 API を使用して、開発者が、アプリケーションに感情認識や映像検出、顔認識、音声認識、視覚認識、音声理解、言語理解など、インテリジェントな機能を簡単に追加できるようにします。
- Azure Search はサービスとしての検索クラウド ソリューションで、多彩な検索機能を、Web、モバイル、およびエンタープライズ アプリケーション内のプライベートな異種コンテンツに提供します。
- Storage Blob は、テキスト データ、バイナリ データなど、大量の非構造化データを格納するために最適化されています。
- Azure Cache for Redis は、アクセス頻度が高いデータを、アプリケーションに近い場所にある高速ストレージに一時的にコピーすることで、バックエンドのデータストアに大きく依存するシステムのパフォーマンスとスケーラビリティを向上させます。
- Azure SQL Database は、リレーショナル データ、JSON、空間、XML などの構造体をサポートする、汎用リレーショナル データベース管理サービスです。
- Application Insights は、パフォーマンスやユーザビリティを継続的に向上させるうえで役立つように設計されています。これを実現するために、アプリでのユーザーの操作内容を把握しやすいように、組み込みの分析ツールを使用してパフォーマンスの異常が自動検出されます。
代替
他のさまざまなテクノロジを、大規模な eコマースに焦点をあてた顧客向けアプリケーションを構築するために使用できます。 これらのテクノロジは、アプリケーションのフロントエンドとデータ層の両方を対象としています。
Web 層と機能に関するその他のオプションは次のとおりです。
- Azure Kubernetes Service - マイクロサービス アーキテクチャの実装として使用できる、コンテナー ベースのソリューションを構築およびデプロイするためのプラットフォーム。 プラットフォームでは、アプリケーションのさまざまなコンポーネントの俊敏性が実現し、オンデマンドで個別にスケーリングできます。
- Azure Container Instances - コンテナーを短いライフサイクルですばやくデプロイし、実行する手段。 このコンテナーは、メッセージの処理や計算の実行など、簡単な処理ジョブを実行するためにデプロイされ、完了するとすぐにプロビジョニングが解除されます。
- Service Bus は、ストレージ キューの代わりに使用できます。
データ層の他のオプションを次に示します。
- Azure Cosmos DB: Microsoft のグローバル分散型マルチモデル データベースです。 このサービスは、MongoDB、Cassandra、Graph データ、シンプルなテーブル ストレージなど、他のデータ モデルを実行するためのプラットフォームを提供します。
シナリオの詳細
eコマース Web サイトの多くが、季節性および時期的なトラフィックの変動に直面します。 PaaS ツールを利用すれば、予想通りでも、予想外であっても、商品やサービスの需要が急増したときに、顧客や取引の増加に自動的に対処できます。 また、このシナリオでは、使用した容量分だけ支払うため、経済的にもクラウドの恩恵を受けられます。
このドキュメントは、さまざまな Azure PaaS コンポーネントと、サンプル eコマース アプリケーションである Relecloud Concerts というオンライン コンサート発券プラットフォームをデプロイするために使用される考慮事項について学ぶのに役立ちます。
考えられるユース ケース
このソリューションは、小売業界向けに最適化されています。 その他の関連するユース ケース:
- さまざまなタイミングでユーザーの急増に対処できるように弾力性のあるスケーリングを必要とするアプリケーションを構築する。
- 世界中のさまざまな Azure リージョンで高い可用性で運用されるよう設計されたアプリケーションを構築する。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
可用性
- クラウド アプリケーションを構築する際には、可用性のために標準的な設計パターンの使用を検討してください。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャで可用性に関する考慮事項を確認します
- 可用性に関する追加の考慮事項については、Azure アーキテクチャ センターの可用性のチェックリストを参照してください。
スケーラビリティ
- クラウド アプリケーションを構築するときは、スケーラビリティのための標準的な設計パターンに注意してください。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャでスケーラビリティに関する考慮事項を確認します
- スケーラビリティに関する他のトピックについては、Azure アーキテクチャ センターの「パフォーマンス効率のチェックリスト」を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
- 必要に応じて、セキュリティの標準的な設計パターンを使用することを検討してください。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャでセキュリティに関する考慮事項を確認します。
- セキュリティで保護された開発ライフサイクル プロセスに従って、開発コストを削減しながら、開発者がより安全なソフトウェアを構築し、セキュリティ コンプライアンス要件に対応できるようにします。
- Azure PCI DSS コンプライアンスを実現するためのブループリント アーキテクチャを確認してください。
回復性
- アプリケーションの一部が使用できない場合は、サーキット ブレーカー パターンを使用して、グレースフル エラー処理を提供することを検討してください。
- 回復性のための標準的な設計パターンを確認し、必要に応じて、これらのパターンを実装することを検討してください。
- Azure アーキテクチャ センターでは、多数のApp Service に関する推奨プラクティスを確認できます。
- データ層にはアクティブ geo レプリケーションを、イメージおよびキューには geo 冗長ストレージを使用することを検討します。
- 回復性の詳細については、Azure アーキテクチャ センターの関連記事を参照してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
このシナリオの実行コストを調べてください。すべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースについて価格の変化を確認するには、予想されるトラフィックに合わせて該当する変数を変更します。
取得するトラフィックの量に基づいて、次の 3 つのサンプル コスト プロファイルが用意されています。
- Small:この価格例は、最小の運用レベル インスタンスの構築に必要なコンポーネントを表します。 ここでは、1 か月あたり数千人の少人数のユーザーを想定しています。 アプリでは標準の Web アプリの単一インスタンスが使用されており、自動スケーリングを有効にするにはこれで十分です。 その他のコンポーネントはそれぞれ Basic レベルにスケーリングされ、最小限のコストで、SLA をサポートし、運用レベルのワークロードを処理できるだけの容量が確保されます。
- 中: この価格例は、中規模サイズのデプロイの指標となるコンポーネントを表します。 ここでは、1 か月間に約 100,000 人のユーザーがシステムを使用することを推定しています。 予想されるトラフィックは、中程度の Standard レベルによって単一アプリ サービス インスタンスで処理されます。 また、中レベルのコグニティブおよび検索サービスが計算ツールに追加されています。
- Large: この価格例は、高スケールを想定したアプリケーションを表します。このアプリケーションでは、1 か月あたり数百万人のユーザーが数テラバイトのデータをやり取りします。 このレベルの使用状況では、トラフィック マネージャーがアクセスする複数のリージョンにデプロイされた、高パフォーマンスの Premium レベルの Web アプリが必要です。 データは、ストレージ、データベース、および CDN で構成され、これらはテラバイト データ用に構成されています。
このシナリオのデプロイ
このシナリオをデプロイするには、こちらのステップ バイ ステップのチュートリアルに従います。このチュートリアルでは、各コンポーネントを手動でデプロイする方法を示しています。 また、このチュートリアルでは、シンプルなチケット購入アプリケーションを実行する .NET サンプル アプリケーションも提供します。 さらに、ほとんどの Azure リソースのデプロイを自動化する Resource Manager テンプレートもあります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Chris Mason |ソフトウェア エンジニアリング シニア マネージャー