Ignite Service Grid - 再起動

26 月 XNUMX 日、私たちは Apache Ignite GreenSource ミートアップを開催し、オープンソース プロジェクトの貢献者が講演しました。 アパッチ・イグナイト。 このコミュニティの生活における重要な出来事は、コンポーネントの再構築でした。 サービスグリッドに点火するこれにより、カスタム マイクロサービスを Ignite クラスターに直接デプロイできるようになります。 彼は交流会でこの困難なプロセスについて話しました ヴャチェスラフ・ダラドゥル、ソフトウェア エンジニアであり、XNUMX 年以上 Apache Ignite に貢献しています。

Apache Ignite とは一般的に何なのかから始めましょう。 これは、SQL、トランザクション性、およびキャッシュをサポートする分散キー/値ストレージであるデータベースです。 さらに、Ignite を使用すると、カスタム サービスを Ignite クラスターに直接デプロイできます。 開発者は、分散データ構造、メッセージング、ストリーミング、コンピューティング、データ グリッドなど、Ignite が提供するすべてのツールにアクセスできます。 たとえば、Data Grid を使用すると、データ ストレージ用に別のインフラストラクチャを管理するという問題がなくなり、その結果として生じるオーバーヘッド コストがなくなります。

Service Grid API を使用すると、構成内でデプロイメント スキームを指定し、それに応じてサービス自体を指定するだけでサービスをデプロイできます。

通常、デプロイメント スキームは、クラスター ノードにデプロイする必要があるインスタンスの数を示します。 典型的な導入スキームは XNUMX つあります。 XNUMX つ目はクラスター シングルトンです。クラスター内では常に、ユーザー サービスの XNUMX つのインスタンスが利用可能であることが保証されます。 XNUMX つ目はノード シングルトンです。サービスの XNUMX つのインスタンスが各クラスター ノードにデプロイされます。

ユーザーは、クラスター全体のサービス インスタンスの数を指定し、適切なノードをフィルター処理するための述語を定義することもできます。 このシナリオでは、Service Grid 自体がサービスをデプロイするための最適な分散を計算します。

さらに、Affinity Service などの機能もあります。 アフィニティは、トポロジ内のパーティションとキーの関係、およびパーティとノードの関係を定義する機能です。 キーを使用すると、データが保存されているプラ​​イマリ ノードを特定できます。 このようにして、独自のサービスをキーおよびアフィニティ関数のキャッシュに関連付けることができます。 アフィニティ関数が変更されると、自動再デプロイが行われます。 こうすることで、サービスは常に操作する必要のあるデータの近くに配置されるため、情報にアクセスする際のオーバーヘッドが軽減されます。 この方式は、一種のコロケーションコンピューティングと呼ぶことができる。

Service Grid の魅力が何かを理解したところで、その開発の歴史について話しましょう。

以前はどうだった

Service Grid の以前の実装は、Ignite のトランザクション レプリケート システム キャッシュに基づいていました。 Ignite の「キャッシュ」という言葉はストレージを指します。 つまり、これはあなたが考えているような一時的なものではありません。 キャッシュが複製され、各ノードにデータ セット全体が含まれているにもかかわらず、キャッシュ内にはパーティション化された表現があります。 これはストレージの最適化によるものです。

ユーザーがサービスをデプロイしようとしたとき、何が起こったのでしょうか?

• クラスター内のすべてのノードは、組み込みの連続クエリ メカニズムを使用してストレージ内のデータを更新するようにサブスクライブしました。
• 開始ノードは、読み取りコミットされたトランザクションの下で、シリアル化されたインスタンスを含むサービス構成を含むレコードをデータベースに作成しました。
• 新しいエントリが通知されると、コーディネーターは構成に基づいて分散を計算しました。 結果のオブジェクトはデータベースに書き戻されました。
• ノードがディストリビューションの一部である場合、コーディネーターはそれをデプロイする必要がありました。

私たちに合わなかったもの

ある時点で、これはサービスを扱う方法ではないという結論に達しました。 理由はいくつかありました。

デプロイメント中に何らかのエラーが発生した場合、すべてが発生したノードのログからのみ発見できます。 非同期デプロイメントのみが存在したため、デプロイメント メソッドからユーザーに制御を返した後、サービスを開始するまでに追加の時間が必要となり、この間、ユーザーは何も制御できませんでした。 Service Grid をさらに発展させ、新しい機能を作成し、新しいユーザーを引き付け、みんなの生活を楽にするためには、何かを変える必要があります。

新しいサービス グリッドを設計するとき、私たちはまず同期デプロイメントの保証を提供したいと考えました。つまり、ユーザーが API から制御を返すとすぐに、サービスをすぐに使用できるようになります。 また、イニシエーターにデプロイメント エラーを処理できる機能を与えたいと考えていました。

さらに、実装を簡素化したい、つまり、トランザクションとリバランスを省略したいと考えていました。 キャッシュがレプリケートされ、バランシングが行われないという事実にもかかわらず、多くのノードを含む大規模な展開中に問題が発生しました。 トポロジが変更されると、ノードは情報を交換する必要があり、大規模な展開では、このデータの重みが大きくなる可能性があります。

トポロジーが不安定な場合、コーディネーターはサービスの分散を再計算する必要がありました。 また、一般に、不安定なトポロジでトランザクションを操作する必要がある場合、予測が困難なエラーが発生する可能性があります。

問題

問題を伴わない地球規模の変化とは何でしょうか? XNUMX つ目はトポロジの変更です。 サービスのデプロイメントの瞬間であっても、いつでもノードがクラスターに出入りできることを理解する必要があります。 さらに、展開時にノードがクラスターに参加する場合は、サービスに関するすべての情報を新しいノードに一貫して転送する必要があります。 そして、すでに展開されているものだけでなく、現在および将来の展開についても話しています。

これは、別のリストにまとめられる問題の XNUMX つにすぎません。

• ノードの起動時に静的に構成されたサービスをデプロイするにはどうすればよいですか?
• クラスターからノードを離脱する - ノードがサービスをホストしている場合はどうすればよいですか?
• コーディネーターが変わった場合はどうすればよいですか？
• クライアントがクラスターに再接続した場合はどうすればよいですか?
• アクティブ化/非アクティブ化リクエストは処理する必要がありますか?またその方法は?
• 彼らがキャッシュの破棄を要求し、それにアフィニティ サービスが関連付けられている場合はどうなるでしょうか?

そして、これはすべてから遠いです。

ソリューション

目標として、メッセージを使用したプロセス通信を実装するイベント駆動型のアプローチを選択しました。 Ignite は、ノード間でメッセージを転送できるようにする XNUMX つのコンポーネント、communication-spi と Discovery-spi をすでに実装しています。

Communication-spi を使用すると、ノードが直接通信してメッセージを転送できるようになります。 大量のデータを送信するのに適しています。 Discovery-spi を使用すると、クラスター内のすべてのノードにメッセージを送信できます。 標準実装では、これはリング トポロジを使用して行われます。 Zookeeper との統合もあり、この場合はスター トポロジが使用されます。 注目すべきもう XNUMX つの重要な点は、discovery-spi は、メッセージがすべてのノードに正しい順序で確実に配信されることを保証することです。

デプロイメントプロトコルを見てみましょう。 デプロイメントおよびアンデプロイメントに対するすべてのユーザー要求は、discovery-spi を介して送信されます。 これにより以下が得られます 保証:

• リクエストはクラスター内のすべてのノードによって受信されます。 これにより、コーディネーターが変わってもリクエストの処理を継続できるようになります。 これは、XNUMX つのメッセージ内に、各ノードにサービス構成やそのシリアル化されたインスタンスなどの必要なメタデータがすべて含まれることも意味します。
• メッセージ配信の厳密な順序は、構成の競合や競合するリクエストの解決に役立ちます。
• トポロジへのノードのエントリも Discovery-spi を介して処理されるため、新しいノードはサービスの操作に必要なすべてのデータを受け取ります。

リクエストが受信されると、クラスター内のノードはそれを検証し、処理タスクを作成します。 これらのタスクはキューに入れられ、別のワーカーによって別のスレッドで処理されます。 導入にはかなりの時間がかかり、高価な検出フローが耐えられないほど遅延する可能性があるため、このように実装されています。

キューからのすべての要求はデプロイメント・マネージャーによって処理されます。 このキューからタスクを取得し、それを初期化してデプロイメントを開始する特別なワーカーがあります。 この後、次のアクションが発生します。

1. 新しい決定論的割り当て関数のおかげで、各ノードは独立して分布を計算します。
2. ノードは、デプロイメントの結果を含むメッセージを生成し、コーディネーターに送信します。
3. コーディネーターはすべてのメッセージを集約し、展開プロセス全体の結果を生成します。この結果は、discovery-spi を介してクラスター内のすべてのノードに送信されます。
4. 結果を受信すると、展開プロセスが終了し、その後タスクがキューから削除されます。

新しいイベント駆動型設計: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

デプロイメント中にエラーが発生した場合、ノードはコーディネーターに送信するメッセージにこのエラーを直ちに含めます。 メッセージの集約後、コーディネーターは展開中のすべてのエラーに関する情報を取得し、このメッセージを Discovery-spi 経由で送信します。 エラー情報はクラスター内のどのノードでも入手できます。

Service Grid 内のすべての重要なイベントは、この動作アルゴリズムを使用して処理されます。 たとえば、トポロジの変更も、discovery-spi を介したメッセージです。 そして一般的に、以前のものと比較すると、プロトコルは非常に軽量で信頼性が高いことがわかりました。 導入中のあらゆる状況に対処するのに十分です。

次に何が起こるでしょうか？

次に計画についてです。 Ignite プロジェクトに対する大きな変更は、IEP と呼ばれる Ignite 改善イニシアチブとして完了します。 Service Grid の再設計には IEP もあります - IEP #17 「サービスグリッドのオイル交換」という嘲笑的なタイトルが付けられました。 しかし実際には、エンジンオイルを交換したのではなく、エンジン全体を交換しました。

IEP のタスクを 2 つのフェーズに分割しました。 2.8 つ目は主要なフェーズで、展開プロトコルの再作成で構成されます。 これはすでにマスターに含まれており、バージョン XNUMX で登場する新しい Service Grid を試すことができます。 第 XNUMX フェーズには、他にも多くのタスクが含まれます。

• ホットリデプロイ
• サービスのバージョン管理
• 耐障害性の向上
• シン・クライアント
• さまざまな指標を監視および計算するためのツール

最後に、フォールトトレラントで高可用性のシステムを構築するための Service Grid についてアドバイスできます。 ぜひこちらにもお越しください。 開発リスト и ユーザーリスト あなたの経験を共有してください。 あなたの経験はコミュニティにとって非常に重要であり、次にどこに進むべきか、将来コンポーネントをどのように開発するかを理解するのに役立ちます。

出所： habr.com