サービスファブリック - ステートフルサービスコンセプト

管理者 · 掲載地 2018/03/15 10:03:44

前節では、Service Fabricの最も低い2つの概念、1つはNode TypeとハードウェアレベルでのNodeについて説明しました。もう一つは応用です。

ノードタイプは、デプロイ中のマシンの概念的抽象化であるノードの集合体です。 Service Fabricの場合、ノードは物理マシン、仮想マシン、あるいは現在最も人気のあるコンテナでもあります。

ノード上で動作するタイプはアプリケーションです。これはシステムソフトウェアレベルでの抽象的な理解です。アプリケーションには複数のマイクロサービスがあります。 FailoverManagerサービスやネーミングサービスなど、Service Fabricのすべての基盤サービスもマイクロサービスです。

サービスファブリックのすべての分散機能はマイクロサービスの展開に対応しています。マイクロサービスがどのノードで何インスタンスを動的に調整し、負荷負荷を分散させたり災害復旧バックアップを行ったりすることができます。各インスタンスは異なるポートを受信し、ロードバランシング層は異なるインスタンスにリクエストを分散させます。

実際のシナリオ

ステートフルサービスはマイクロサービスの一つです。

ステートフルサービスを紹介する前に、以下の一般的なビジネスシナリオを検討しましょう。

あなたはウェブサイトにショッピングカート機能を導入しようと考えています。ログイン後、ユーザーは一部の商品をショッピングカートに入れます。

次にログインすると、フロントデスクのページがショッピングカートサービスを呼び出し、保存されたショッピングカートデータを再度読み取り表示する必要があります。

もしそうなら、どのように達成しますか?

ユーザー数が特に多くない場合は、データベースにショッピングカートテーブルを追加し、ユーザーテーブルと関連付けます。カートテーブルにはユーザーIDフィールドがあり、大量のユーザーカートデータを記録します。

そうなると、その後の問題が起こるでしょう。

ユーザー数が増え続けると、データベーステーブルのパフォーマンスはさらに低下し続けます。
データベーステーブルデータはデータ損失に備えて定期的にバックアップする必要があります
データベースのパフォーマンスに問題がある場合は、テーブルをデバンクするかパーティション分割する必要があります
ショッピングカートシステム自体がデータベースの調整を処理しなければならず、場合によっては負荷分散が必要になるかもしれません
この問題の根本は、システム自体がそもそもスケーラブルに設計されていないことです。さらに、データベースは潜在的なボトルネックであり、パフォーマンスへの脅威となります。

国家での奉仕

まったく新しいアーキテクチャを考えてみましょう。

ショッピングカートシステムには、すべてのリクエストを処理する36のサブサービスがありました(ユーザーIDのイニシャルが0-9 a-zで、合計36です)。

ユーザーのリクエストは、ユーザーIDの初期ハッシュに基づいて特定のサブサービスに処理されます。

サブサービスは、買い物カートデータを社内で軽量データベースで保存し、独自のストレージデバイス上で永続化します。

各サブサービスには3つのバックアップがあり、これらが常に保存されたデータを同期させており、これらのバックアップは常に異なるノードで稼働しています。

同時に、リクエスト処理をアクティベーション状態として担当するのは1つのバックアップのみで、バックアップの有効化に問題が発生した場合、残りの2つのバックアップがスケジューリングアルゴリズムに従って1つを起動します。

災害復旧サブシステムは新しいバックアップを作成し、サブサービスに常に3つの健全なバックアップを確保させます。

ステートフルサービスはそのような解決策の一つです。

上記のシナリオに戻りますが、ショッピングカートシステムはステートフルなサービスです。

36のサブシステムは、このステートフルサービスの36インスタンスであり、これをパーティションと呼びます。

各サブシステムのバックアップはレプリカで、パーティションには3つのレプリカがあります。

現在アクティブなバックアップはActive Replicaで、非アクティブな2つのスタンバイバックアップはSecondary Replicaです。

同じパーティオンの各レプリカは異なるノード上で動作しなければなりません。

ステートフルサービスコードは、<T>IReliableCollection、IReliableDictionary<T1、>T2などのインターフェースを用いてデータを保存し、内部同期を行います。

さらに、ステートフルサービスは以下の機能を実装できます:

上記の数値はすべてリセット可能で、カートシステムに数百のパーティションを設けて負荷を増やすことができます。さらに、1パーティションに5つ以上のレプリカを配置することで、より堅牢性を保つこともできます。
外部システムはステートフルサービスにパーティションの数は気にせず、パーティションキーで呼ばれます。パーティションキーと対応するパーティションは、Service Fabricの基盤となるマイクロサービスによって解決されます。例えば、あなたのビジネスでは数百万のユーザーがいても、パーティションは5つしか設定していないかもしれません。ショッピングカートをステートフルサービスと呼ぶ際、外部システムはユーザーID(パーティションキー)と保存データのみを通知すればよい。このリクエストはユーザーIDとハッシュアルゴリズムに基づいて自動的に5つのパーティションのいずれかにマッピングされます。
ステートフルサービスにおけるデータ操作はトランザクションをサポートします。つまり、失敗した場合にロールバックできます

上記の紹介が、国家的奉仕についてよりよく理解する助けになれば幸いです。

以下のセクションでステートフルサービスのコード例を説明します。

[出典] サービスファブリック - ステートフルサービスコンセプト

関連記事

閲覧したセクション