次の方法で共有


Service Fabric アプリケーションのシナリオ

Azure Service Fabric はさまざまな種類のビジネス アプリケーションやサービスを作成し実行できる信頼性の高い柔軟なプラットフォームを提供します。 これらのアプリケーションとマイクロサービスはステートレスまたはステートフルが考えられますが、最大限に効率化するために仮想マシン間でリソース分散されます。

Service Fabric 独自のアーキテクチャでは、リアルタイムに近いデータ分析、メモリ内のコンピューティング、並列トランザクション、アプリケーションでのイベント処理を実行できます。 リソース要件の変化に応じて、アプリケーションを簡単にスケールインまたはスケールアウトできます。

アプリケーションの構築での設計のガイダンスについては、「Azure Service Fabric でのマイクロサービス アーキテクチャ」 および「Service Fabric を使用したアプリケーションの設計に関するベスト プラクティス」をご覧ください。

次の種類のアプリケーションに Service Fabric プラットフォームを使用することを検討してください。

  • データ収集、プロセッシングおよび IoT: Service Fabric では大規模な処理が行われ、そのステートフル サービスによって待機時間が短縮されます。 これは、デバイスのデータと計算用のデータが併置されている多数のデバイスでのデータ処理に役立ちます。

    Service Fabricを使用してIoTサービスを構築したお客様には、PCL ConstructionCitrixASOSオマーンデータパークKohlerDover Fueling Systemsなどがあります。

  • ゲームおよびセッション ベースの対話型アプリケーション: Service Fabric は、オンライン ゲームやインスタント メッセージングなどのアプリケーションで低遅延の読み取りや書き込みが必要な場合に便利です。 Service Fabric では、専用のストアやキャッシュを作成する必要なしに、対話型のステートフルなアプリケーションを構築できます。 ゲーム サービスでの Service Fabric の使用に関する設計ガイダンスについては、Azure のゲーム ソリューションに関するページをご覧ください。

    ゲームサービスを構築されているお客様としては、Next Gamesなどがあります。 対話型セッションを構築されているお客様としては、Honeywell with Hololens などがあります

  • データ分析とワークフロー プロセッシング: イベントやデータのストリームを確実に処理する必要のあるアプリケーションには、Service Fabric での最適化された読み取りや書き込みによるメリットがあります。 また、Service Fabric では、信頼できる結果を、損失なく次の処理ステージに渡す必要がある、アプリケーション処理パイプラインがサポートされています。 これらのパイプラインには、データの一貫性と確実な計算が不可欠となる取引システムや金融システムが含まれます。

    ビジネスワークフローサービスを構築されているお客様としては、Zeiss GroupPCL Constructionなどがあります。

  • データにおける評価: Service Fabric では、集中型のデータ計算処理を行うステートフル アプリケーションを構築できます。 Service Fabric では、アプリケーションでの処理 (計算) とデータの併置を実現できます。

    通常、アプリケーションでデータにアクセスする必要があるときは、外部のデータ キャッシュまたはストレージ階層に関連するネットワーク待機時間により、計算時間が制限されます。 ステートフルな Service Fabric サービスでは、その待機時間をなくして、いっそう最適化された読み取りと書き込みを実現できます。

    たとえば、顧客に対してリアルタイムに近い推奨選択を実行するアプリケーションがあり、そのラウンド トリップ時間の要件が 100 ミリ秒未満であるとします。 リモート ストレージから必要なデータを取得する必要がある標準的な実装モデルの場合と比較して、Service Fabric サービスの待機時間とパフォーマンスの特性は、ユーザーに応答性の高いエクスペリエンスを提供します。 推奨選択の計算がデータおよび規則と併置されているため、システムの応答性は高くなります。

    計算サービスを構築されているお客様としては、ASOSCCCなどがあります。

  • 高可用性サービス: Service Fabric は、複数のセカンダリ サービス レプリカを作成することによって、高速のフェールオーバーを実現します。 ハードウェアまたはその他の障害によってノード、プロセス、または個々のサービスがダウンした場合、セカンダリ レプリカの 1 つが最小限のサービス中断でプライマリ レプリカに昇格されます。

  • スケーラブルなサービス: クラスター間でスケールアウトの状態になれるよう個々のサービスをパーティション分割できます。 個々のサービスは、その場で作成したり削除したりすることもできます。 数個のノード上の数個のインスタンスから、多数のノード上の数千個のインスタンスまで、サービスをスケールアウトし、必要に応じて再びそれらをスケールインすることができます。 Service Fabric を使用することで、このようなサービスを構築し、その完全なライフサイクルを管理することができます。

アプリケーション設計のケース スタディ

アプリケーション設計における Service Fabric の使用方法を示すケース スタディが、顧客事例サイトと Azure のマイクロサービス サイトで公開されています。

ステートレスとステートフルなマイクロサービスから成るアプリケーションを設計する

Azure Cloud Services worker ロールでのアプリケーションの構築は、ステートレス サービスの一例です。 対照的に、ステートフルなマイクロサービスは、要求とその応答を超える権限のある状態を維持します。 この機能では、レプリケーションによって裏付けられたトランザクションの保証を提供するシンプルな API により、状態の高可用性と一貫性が実現されます。

Service Fabric のステートフル サービスは、データベースや他のデータ ストアだけでなく、すべての種類のアプリケーションに高可用性をもたらします。 これは自然な進展です。 アプリケーションは既に、高可用性のための純粋なリレーショナル データベースから NoSQL データベースに移っています。 アプリケーション自体を「ホット」な状態にして、データを中で管理し、信頼性、一貫性、可用性を犠牲にすることなく、パフォーマンスを上げることができるようになりました。

マイクロサービスから成るアプリケーションを構築している場合、通常、ステートレスとステートフルなビジネス中間層サービスを呼び出すステートレスな Web アプリの組み合わせ (ASP.NET と Node.js など) があります。 アプリとサービスは、Service Fabric のデプロイ コマンドを使用して、すべて同じ Service Fabric クラスターにデプロイされます。 これらの各サービスは、スケール、信頼性、およびリソースの使用に関して独立しています。 この独立性により、開発およびライフサイクル管理での俊敏性と柔軟性が向上します。

純粋にステートレスなアプリケーションの可用性と待機時間の要件に対応するために従来必要だった追加のキューとキャッシュは、ステートフル マイクロサービスでは不要になるため、アプリケーション設計が単純化されます。 ステートフル サービスは可用性が高く待機時間が短いため、アプリケーションで管理すべき詳細は少なくなります。

次の図では、ステートレスとステートフルなアプリケーション設計の違いを示しています。 Reliable ServicesReliable Actors のプログラミング モデルを利用することで、高スループットと低待機時間を実現しながら、ステートフル サービスによりアプリケーションの複雑さが軽減されます。

ステートレス サービスを使用するアプリケーションの例を次に示します。ステートレス サービスを使用するアプリケーション

ステートフル サービスを使用するアプリケーションの例を次に示します。ステートフル サービスを使用するアプリケーション

次のステップ