|
ServiceFabric: クラウドでマイクロサービスを構築するための分散プラットフォーム。 Microsoft の Service Fabric は、Azure の重要なサービスの多くを支えています。Service Fabric は約 15 年間にわたって開発され、10 年間にわたって本番環境に導入され、2015 年に一般公開されました。 ServiceFabric (SF) を使用すると、マシンの共有クラスター上で高密度に実行されるマイクロサービスで構成されたスケーラブルで信頼性の高いアプリケーションのアプリケーション ライフサイクルを管理でき、開発から展開、管理までワンストップのソリューションが提供されます。 SF 上で実行されている注目すべきシステムには次のようなものがあります。
SF は複数のクラスターで実行され、各クラスターには数百または数千のマシンがあり、合計で 160,000 台を超えるマシンと 250 万を超えるコアが含まれます。 ポジショニングと目標 Service Fabric を分類するのは難しいですが、論文の著者はこれを「クラウド上でマイクロサービス アプリケーションをサポートするための Microsoft プラットフォーム」と説明しています。Service Fabric の特にユニークな点は、信頼性の高いコレクション（信頼性、永続性、効率性、トランザクション性を備えた高レベルのデータ構造）によるステートフル サービスのサポートを含む、強力な一貫性を基盤として構築されていることです。 既存のシステムはマイクロサービスに対して様々なレベルのサポートを提供しており、市場で最も有名なシステムとしては、Nirmata、Akka、Bluemix、Kubernetes、Mesos、AWS Lambda（品質は様々）などが挙げられます。SFはより強力で、現在、識別可能なデータを持つステートフルなマイクロサービス向けの唯一のオーケストレーションシステムです。特に、低レベルのアーキテクチャコンポーネントにおける状態と一貫性のサポートの必要性から、障害検出、フェイルオーバー、リーダー選出、一貫性、スケーラビリティ、管理性といった分散コンピューティングの課題に対処する必要が生じています。上記のシステムとは異なり、SFは外部依存関係を持たず、独立したフレームワークです。 SF の各レイヤーは強力な一貫性をサポートしています。これは、（必要に応じて）その上に弱い一貫性のサービスを構築できないという意味ではありませんが、一貫性のないコンポーネント上に強い一貫性のサービスを構築するよりも、その課題は克服しやすいものです。「ユースケース調査によると、SF を必要とするチームのほとんどが、トランザクションの実行時に SF に依存する Microsoft Azure DB や Microsoft ビジネス分析ツールなどの強力な一貫性を必要としていることがわかりました。」 全体デザイン SF アプリケーションは、独立してバージョン管理され、アップグレード可能なマイクロサービスの集合であり、各マイクロサービスは独立した機能を実行し、コード、構成、およびデータで構成されます。 SF 自体は複数のサブシステムで構成されており、その主なサブシステムを下図に示します。 SFの中核を成すのは、障害検出、ルーティング、リーダー選出を担うフェデレーション・サブシステムです。フェデレーション・サブシステム上に構築される信頼性サブシステムは、レプリケーションと高可用性を提供します。本稿では、これら2つのサブシステムについて詳しく説明します。 関節サブシステム 指輪 フェデレーションサブシステムの中核には、2^m個のポイントを持つ仮想リング「SFリング」があります。これは2000年代初頭にMicrosoft社内で開発されたもので、ChordやKademliaによく似ています。ノードとキーはリング内のポイントにマッピングされます。キーはそのポイントに最も近いノードによって保持され、その前のノードに接続されます。各ノードは、リング内で直後のノードと前のノードを追跡します。これらのノードは近傍集合を形成します。 ルーティングテーブルのエントリは双方向かつ対称的です。ルーティングパートナーは、リング内で時計回りと反時計回りの両方向で、距離が劇的に増加する方向に維持されます。この双方向性により、ほとんどのルーティングパートナーは最終的に対称になります。これにより、ルーティング情報と障害情報の伝播、そしてノード損失後のルーティングテーブルの更新が高速化されます。 キーメッセージを転送する際、ノードはルーティングテーブルを検索し、キーに最も近いノードを時計回りまたは反時計回りで検索します。時計回りのみのルーティングと比較して、これによりルーティング速度が向上し、期限切れまたは空のテーブルに対するルートオプションが増え、ノード間の負荷分散が効率化され、ルーティングループが回避されます。 ルーティングテーブルは最終的に収束します。チャットプロトコルはルーティングパートナー間でルーティングテーブル情報を交換し、遠方の隣接ノード間の最終的な一貫性を確保します。 SFの重要な成果の一つは、リング上の強整合性メンバーと弱整合性メンバーを組み合わせることで、大規模な強整合性アプリケーションをサポートできることです。文献では強整合性メンバーは仮想同期と同一視されることが多いですが、このアプローチにはスケーラビリティの面で限界があります。 リング内のノードはルーティングトークンを保持しており、これはリングの鍵のどの部分を担当しているかを示します。SFリングプロトコルは、トークン間の重複がないこと（常に安全）と、各トークン範囲が最終的に少なくとも1つのノードによって所有されること（耐久性ベース）を保証します。ノードが参加すると、隣接する2つのノードはそれぞれ、リングのセグメントを新しいノードと共有します。ノードが離脱すると、隣接する2つのノードはトークン範囲を分割します。 信頼性サブシステムを見ると、ノードとオブジェクト（サービス）がハッシュに頼るのではなく、リング状に配置されていることがわかります。これにより、障害ドメインと負荷分散を考慮した優先配置が可能になります。 一貫性のあるメンバーと障害検出 メンバーシップと障害検出は隣接ノードセット上で実行されます。設計上の主要な原則は2つあります。
ノードXは、隣接する各ノード（監視ノード）に定期的にリース更新要求を送信します。リース期間は動的に調整されますが、通常は約30秒です。Xは、すべての監視ノードから確認（リース）を取得する必要があります。この特性は、強力な一貫性を定義します。Xがすべてのリースを取得できない場合、グループからの離脱を検討します。監視ノードがXの更新ハートビートを受信しなかった場合、Xを障害ありとしてマークすることを検討します。どちらの場合も、証拠は調停ノードグループに送信されます。 アービトレーションノードは、障害検出と競合解決のための調停者として機能します。速度とフォールトトレランスを確保するため、アービトレーションノードは分散ノードグループ（各ノードは独立して動作します）として実装されます。システム内のいずれかのノードが障害を検出すると、その障害に関連する何らかのアクションを実行する前に、アービトレーションノードグループ内の過半数（規定数）のノードからの確認が必要となります。 調停ノードプロトコルの詳細については、本論文のセクション4.2.2をご覧ください。軽量な調停ノードグループを使用することで、メンバーの統合が可能になり、リングをデータセンター全体に拡張できるようになります。 リーダー選挙 適切に管理されたリングがあることを前提として、SF はリーダー選出のための巧妙かつ実用的なソリューションを提供します。 SFリング内の任意のキーkに対して、唯一のリーダーが存在します。これは、トークン範囲にkが含まれるノードです（このノードは、ルーティングトークンのセキュリティと有効性により一意です）。どのノードもキーkへのルーティングによってリーダーに連絡できます。したがって、リーダー選出は暗黙的に行われ、追加のメッセージは必要ありません。リング全体にリーダーが必要な場合は、k = 0を使用します。 信頼性サブシステム 簡潔にするために、信頼性サブシステムとロードバランサ（PLB）コンポーネントのデプロイメントに焦点を当てます。PLBの役割は、負荷分散を確保しながら、マイクロサービスインスタンスをノード全体にデプロイすることです。 オブジェクト ID がリングにハッシュされる従来の分散ハッシュ テーブル (DHT) とは異なり、PLB は各サービスのレプリカ (プライマリ レプリカとセカンダリ レプリカ) を SF リング内のノードに割り当てます。 デプロイメントコンポーネントは、各ノードで利用可能なリソース、未処理のリクエスト、および典型的なリクエストのパラメータを考慮します。また、過負荷状態のノードから十分に活用されていないノードへサービスを継続的に移行します。PLBは、アップグレードが迫っているノードからもサービスを移行します。 PLBは絶えず変化する環境において数千ものオブジェクトを処理するため、ある瞬間に下した判断が次の瞬間には必ずしも最適とは限りません。そのため、PLBは迅速かつ機敏な判断を下し、小さな改善を継続的に行う傾向があります。この目的のために、シミュレーテッドアニーリング法が用いられます。シミュレーテッドアニーリング法のアルゴリズムはタイマー（高速モードでは10秒、低速モードでは120秒）を設定し、収束するかタイマーが切れるまで状態空間を探索します。各状態にはエネルギーがあります。エネルギー関数はユーザーが定義できますが、一般的なアプローチはクラスター全体のすべてのメトリックの平均標準偏差です（低いほど良い）。 各ステップではランダムな動きを生成し、その動きによって生じる新しい状態のエネルギーを考慮し、ジャンプするかどうかを決定します。新しい状態のエネルギーが低い場合、アニーリングプロセスにおけるジャンプの確率は1です。そうでない場合、新しい状態のエネルギーが現在の状態よりd高く、現在の温度がTである場合、ジャンプの確率はed/Tです。この温度Tは初期ステップでは高く（局所最小値からのジャンプを可能にします）、反復を通じて線形に減少し、後に収束に達します。 検討対象となる移動はきめ細やかです。例えば、セカンダリレプリカを別のノードにスワップしたり、プライマリレプリカとセカンダリレプリカをスワップしたりします。 信頼できるセット SF の Reliable Collections は、辞書やキューなどのデータ構造を提供し、耐久性、可用性、フォールトトレランス、効率性、トランザクション性を実現します。状態はサービスインスタンス内にローカルに保存されるため、高可用性が確保され、読み取りもローカルで行われます。書き込みはプライマリレプリカからセカンダリレプリカにパッシブにレプリケートされ、クォーラムが確認されると完了とみなされます。 信頼性の高いコレクションは、フェデレーションサブシステムと信頼性サブシステムのサービスに基づいています。レプリカはSFリングに編成され、障害検出時にマスターノードが選出されます。PLB（フェイルオーバーマネージャーと併用）は、レプリカのフォールトトレランスと負荷分散を維持します。 SF は、信頼性が高く、自立的で、スケーラブルなトランザクション一貫性のあるデータベースを構築するために使用できる唯一の自己完結型マイクロサービス システムです。 学んだ教訓 論文の第7節では、SFの開発過程で得られた教訓について詳細に論じています。紙面の都合上、ここではタイトルのみを記載します。詳細については、論文をご参照ください。
次は何? 私たちの日々の業務は、主にこの問題、つまりクラスター管理の複雑さを軽減することに取り組んでいます。その一環として、お客様が個々のサーバーを目にすることのないサービス モデルへの移行が挙げられます。その他の注目すべき長期モデルは、お客様がサーバーを所有し、サーバーを追加したらマイクロサービス管理をサービスとして実行できるようにすることです。短期的には、信頼性の高いコレクションに異なる一貫性レベルの実装、信頼性の高いコレクション パーティションの自動スケーリング (内側と外側)、地理的に分散したレプリカ セットの提供を検討しています。さらに先では、ServiceFabric の信頼性の高いコレクションのストレージとして、不揮発性メモリを最も効率的に使用する方法を検討しています。そのためには、レコード バイトとブロック指向のストレージのどちらを使用するか、効率的な暗号化からトランザクションに対応したメモリ割り当てまで、さまざまな懸念事項に対処する必要があります。 紙： |
