Apache Igniteトポロジを使用する

以前の記事で、 Apache Igniteの単純なトポロジーを構築する方法について説明しました。 1つのクライアントと1つのサーバーで構成され、クライアントはサーバーにメッセージを送信し、サーバーはそれを表示しました。 製品を構成し、その重要なアクティビティを監視する方法について説明されました。 ここで、より複雑な例の時間です。 複雑なトポロジの構築と、より興味深い相互作用のシナリオが示されます。 読者は、最初の記事で説明したApache Igniteの基本操作に精通していることを前提としています。 これら2つの記事を読んだ結果、読者は自分のプロジェクトでこれを誇張せずに強力な製品に適用する方法についていくつかの仮定を持っているかもしれません。 また、この記事は、高性能システムの構築に関心があり、自転車のターンキーソリューションを覗きたい人にも役立ちます。

トポロジ設定

Igniteトポロジは、クライアントとサーバーの2種類のノードで構成されていることを思い出してください。 クライアントは、一般的な場合（ただし必須ではありません）、要求を送信し、サーバーがそれらを処理します。 ノードの動作は、その構成によって決まります。これは、対応するIgniteオブジェクトのSpring構成です。 ノードの構成に関連する主なポイントは、 前の記事で説明されています 。 次に、「gridName」プロパティが異なり、他の点では同じである2つのサーバータイプxml構成を作成します。 この例では、これらは「testGrid-server」および「testGrid-server1」という名前になります。 たとえば、最初の構成で2つのノードを実行し、2番目の構成で1つのノードを実行します。 それぞれが個別のJVMで起動されるため、ノードメモリの構成に注意する必要があります。そのため、ignite.batの-Xmsおよび-Xmxパラメーターの値を減らすことができます。 ignitevisorcmd。（Bat | sh）コマンドを使用して、Igniteトポロジの監視に使用されるVisorユーティリティを実行します。 起動時に、いずれかの構成を指定し、いずれかを指定する必要があります。結果は同じです。









このような複雑なトポロジができたので、バイザーの主な機能に慣れるときが来ました。 彼は、 helpコマンドでコマンドの完全なリストを表示します。 それらの簡単な説明付きの完全なリストは、製品ドキュメントのページで見ることができます 。 ドキュメントに記載されていることに加えて、バイザー用にプラグインを作成でき、Scala自体で作成されていることに注意してください。 この記事のコンテキストでは、バイザーコマンドconfigに注意を払う必要があります。このコマンドは、指定されたノードに関するすべての関連詳細を表示します。 これは非常に大量の情報であるため、ここでは説明しません。



ちなみにこれは必要ではありませんでしたが、非Javaノードもあり、現在はC ++と.NETのサポートがあります。 また、ノードのライフサイクルハンドラを定義できることも言及していません。 つまり、ノードの開始/停止の前後に4つのイベントがあります。 そこで行う価値は明確ではありません。ロギングは標準的な手段、おそらくいくつかのセキュリティチェックまたはサーバー設定によって提供されます。 Igniteで提供されるLifecycleBeanインターフェイスの唯一の実装は、.NETノードの初期化に使用されます。 一見したところ、この機能を使用しても便利なことは何もできません。

サーバーに接続する

前の記事では、クライアントをサーバーに接続し、「Hello World！」というメッセージを送信しました。 前の例から少し変更して、テストでクライアントとサーバーの2つのノードを作成します。 作成方法によっては、同じJVMで作成されます。 それらは異なるxml構成で構成され、サーバーのgridNameは「testGrid-server0」になります。 テストコードは次のとおりです。

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"/ignite/providerConfig.xml"}) public class IgniteHelloWorld { @Autowired @Qualifier("clientProvider") private IgniteProvider igniteClient; @Autowired @Qualifier("serverProvider") private IgniteProvider igniteServer; @Test public void sendHelloTest() { try (Ignite server = igniteServer.getIgnite(); Ignite client = igniteClient.getIgnite()) { client.compute().broadcast(() -> System.out.println("Hello World from client!")); server.compute().broadcast(() -> System.out.println("Hello World from server!")); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AutoCloseableインターフェイスを実装するIgniteオブジェクトは、使用後に良好なトーンで閉じることに注意してください。 そのため、コマンドラインから3つのサーバーノードを起動しました。 3つのコンソールのそれぞれ、およびIDEのコンソールでテストを実行した後、同じことがわかります。









別のクライアントとサーバーが3つの既存のサーバーに参加しました。 この動作はどのように保証されますか？ タスクを実行するサーバーのグループを決定するcompute（）メソッドには、2つの実装があります。 テストで呼び出すパラメーターなしの実装は次のようになります。

  @Override public IgniteCompute compute() { return ((ClusterGroupAdapter)ctx.cluster().get().forServers()).compute(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで何が起こるか見てみましょう。 GridKernalContextImpl型のctxオブジェクト（開発者はいくつかの重要な伝統のために「 Kernal 」という単語を使用します）で、cluster（）メソッドが呼び出され、トポロジーとの相互作用に関して明らかにノードを象徴するClusterProcessorオブジェクトを返します。 実際に、get（）メソッドをさらに呼び出すことにより、シングルトンクラスターの形式でノードを取得します。これにより、 IgniteClusterImplオブジェクトが提供され、多くのことが可能になります。 まず、述語をノードに適用することに基づいてノードのサブセットを構築します。つまり、オブジェクトの特定のセットで計算され、フィルタリングする条件です。 この場合、forServers（）メソッドは、ATTR_CLIENT_MODE == falseプロパティを持つノードに対してtrueを返す述語を返します。 属性の完全なリストが利用可能です 。 属性の述部に加えて、Igniteには、他の興味深い述部の実装がいくつか付属しています。 たとえば、キャッシュの内容でフィルタリングすることができます。これは、後で導入するのが理にかなっていますし、他の多くの、よりエキゾチックなものでも構いません。



この知識があれば、選択したノードにメッセージが送信されるようにテストを変更することは難しくありません。 識別のために、gridNameパラメーターがあります。gridName== "testGrid-server"のサーバーに送信してみましょう。これは2です。

 client.compute(client.cluster() .forAttribute(ATTR_GRID_NAME, "testGrid-server") .forServers()) .broadcast(() -> System.out.println("Hello World from client!")); server.compute(server.cluster() .forAttribute(ATTR_GRID_NAME, "testGrid-server1") .forServers()) .broadcast(() -> System.out.println("Hello World from server!"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予想どおり、クライアントから2つのメッセージとサーバーから1つのメッセージを受信します。 述語が何も返さない場合、例外がスローされます： "ClusterGroupEmptyCheckedException：Cluster group is empty"。 forServers（）に加えて、forRemotes（）、forRandom（）、forOldest（）、forYoungest（）など、他の多くの興味深い標準述語があります。



最後に、broadcast（）を呼び出すことだけができるわけではありません。 ここで実行するとは、実行のためにIgniteCallableオブジェクトを渡すことを意味します。 また、call（）メソッドにはいくつかのバージョンがあり、broadcast（）とは異なり、結果を返します。

しかし、中身は何ですか？

それがどのように機能するかを知ることは興味深いでしょう。 調べるために、次の実験を実行します。クライアントから、gridName ==“ testGrid-server0”でテストで作成されたサーバーにメッセージを送信し、デバッグで何が起こるかを確認します。 より参考になるように、テストを少し変更します。

 int param = 1; Integer clientResult = client.compute(client.cluster() .forAttribute(ATTR_GRID_NAME, "testGrid-server0") .forServers()) .call(() -> { System.out.println("Hello World from client!"); return param + 1; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

call（）メソッドを呼び出したときに最初に起こることは、クライアントで読み取り/書き込みロックを設定することです。 興味深いことに、Igniteはsun.misc.Unsafeに基づいて、 thisのGridSpinReadWriteLockクラスでこのメカニズムの独自の実装を使用します。 一方で、これは良いことです。Ignite開発者はパフォーマンスに関心がありますが、一方で、Java 9 Unsafeで切り取るとどうなりますか？ 不安を持ってイベントの経過をたどります... Ignite開発者が標準のjava.util.concurrent.Futureクラスを拒否して、 IgniteFutureインターフェイスの独自の実装を支持していることは、 驚くことではありません 。 それらがはるかに優れているかどうかはわかりませんが、1つのことは明らかです。ApacheIgniteで密輸したい人は、並行性について非常に深い知識を持っている必要があります...次に、ラムダに基づいて、実行のために転送されるタスクが生成されます。 このタスクは、GridTaskProcessorクラスのstartTaskメソッドに委任されます。 ここではセキュリティチェックが提供されますが、実装されていません。将来のバージョンで表示される可能性があります。 次の重要なステップは、クラスの分散展開ですが、これまでこの強力な機能については説明しません。 元のドキュメントを参照してください。 Igniteは、タスクが実行されるすべてのノードで実行可能コードが確実に実行されるように対策を講じる必要があることを思い出させてください。 タスクの場合、デフォルトのLong.MAX_VALUEに等しいタイムアウトを設定でき、実際には無限大であり、再定義できます。 タスク起動ログを構成することもできます。 エンタープライズ機能のトレースが表示されます-負荷分散、フォールトトレランス、およびトランザクション性の設定については、以下をご覧ください。 処理時間のある時点で、タスクがダンプされたサーバーが落ちたように見える場合、処理は例外で中断されます。 途中で落ちなかった場合、ジョブが形成され、GridIoManager I / Oマネージャーに渡されます。 メッセージを形成し、 TcpCommunicationSpiを使用して送信します 。 このオブジェクトはノードのxml構成で指定できることを思い出してください。つまり、TcpCommunicationSpiの子孫を実装することにより、メッセージの送信プロセスに影響を与えることができます。 さらに、簡単ではありませんが、最終的にNIOを使用するとメッセージは消えます。 そして、サーバーを取得します。 計算し、同様に回答を送信します。 そして、彼は呼び出しの場所に来ました。この場合、それは2番です。

負荷管理

複数のサーバーでタスクを完了できるとどうなりますか？ これを確認するには、gridName ==“ testGrid-server”を使用してサーバーに要求を送信します。その中、ノードの可用性に関する情報を考慮して、複数のノードがタスクに使用できる場合、Collections.shuffle（）を使用して混合します。このリストは標準のロードバランサーに転送され、ノード1から選択する必要があります。 デフォルトですべてを残した場合、 RoundRobinLoadBalancingSpiクラスによって提供されるRound-Robbinアルゴリズムが使用されます。 このSPI（Igniteでは、すべてのプラグインアルゴリズムはSPIと呼ばれます）は、ラウンドロビン方式を使用してノードを反復処理し、次のノードを順番に選択します。 setPerTask（boolean）を呼び出すことにより設定される、タスクとグローバルの2つの動作モードが利用可能です。 タスクモードが選択されている場合、SPIは実行の開始時にノードをランダムに選択し、タスクが完了すると周期的に繰り返します（この場合、タスクは1つだけですが、実行のためにタスクのリストを転送できます）。 このアプローチはデフォルトで使用されます。 グローバルモードでは、ノードの共通の順次キューがすべてのタスクに使用されます。 この場所でアルゴリズムを選択すると、ノード間の負荷分散に影響する可能性があることは明らかです。 Round-Robbinバランサーに加えて、さらに2つが利用可能です。adaptiveは、デフォルトでノードサーバーのCPUの負荷であるカスタムメトリックに基づいてノードのパフォーマンスを考慮し、構成中に指定できるノードの重みに基づくランダム選択です（デフォルトではすべて10です） 。 最後に、適切なインターフェースを実装することにより、独自のものを作成できます。 ノードのxml構成でバランシングSPIを指定できます（ここでは少し理解できませんが、それらのリストを指定できます。どのようにバランシングを実行するか、誰が正確にバランスを取りますか？コードから判断すると、クラス名は文字列にスタックされ、その後SPIはクラス名によってインスタンス化されますこれは機能しますか？Javadocのヒントから判断すると、バージョン2.1から機能します。）



バランシングに加えて、開発者はさらに2つのエンタープライズレベルの機能を管理できます。 フェイルオーバーは、 フェイルオーバーSPIを使用して制御できます。 これが必要になる可能性がある理由には、タスクの実行プロセスでのエラー、トポロジからのターゲットノードの損失、およびタスクの完了を拒否するノードが含まれます。 このタイプのSPIの目的は、欠陥のあるノードと引き換えにノードを提供することです。 すぐに使用できる3つの実装が提供されます。NeverFailoverSpi（何も返さない）と、2つのトリッキーな実装 、 AlwaysFailoverSpiおよびJobStealingFailoverSpiです。 AlwaysFailoverSpiは、別のノードを提案する前に、ノードにいくつかの試行を与えます（デフォルト5はオーバーライドできます）。 同時に、タスクの親和性が考慮されます-タスクが接続されている場合、一定の試行回数の後にドロップが発生し、そうでない場合は、バランサーのデータを考慮して、新しいノードが選択され、欠陥のあるノードがブラックリストに登録されます。 試行回数とノードのブラックリストは、タスクのコンテキストに保存されます。 JobStealingFailoverSpiはさらにトリッキーであり、考慮しません。 フェイルオーバーSPIリストも構成で指定できます。 何も指定しない場合、デフォルトでAlwaysFailoverSpiが作成されます。



このシリーズの最後のSPIであるCheckpoint SPIは、ご想像のとおり 、セーブポイント（チェックポイント）、つまり、長いタスクまたは複雑なタスクの中間ポイントを作成するように設計されています。 このタイプのSPIは、チェックポイントを保存、削除、およびロードできるAPIを提供します。 Igniteの作成者が考案したこのAPIは、システムでのみ使用する必要があります。 ただし、技術的には、この機能はアプリケーション開発者に限定されません。 この機能の恐ろしい腸に飛び込むことはありません;デフォルトでは、何もしない実装は接続されていません。

トラックを検索する

最後に、これらすべての課題の痕跡を見つけてみましょう。 Igniteは完全なロギングを提供します。 デフォルトの状態を変更するために何もしないと、コンソールにメッセージを書き込むデフォルトのロガーが作成されます。 これは通常のJavaロギングであり、config / java.util.logging.properties構成を作成できる構成用です。 これが適切でない場合は、 IgniteLoggerインターフェイスを実装し、xml-configを介して接続できます。



バイザーを求めることもできます。 nodeコマンドを使用すると、ノードの詳細な統計を要求できます（どの統計情報を尋ねるべきかわかっている場合は、計算にコンソールに出力を追加したため、知ることができます）。 その結果、数回起動すると次のようなものが表示されます。









ただし、トポロジの監視については別の機会に話します。

結論

Igniteの内部が良好で、内部にフィットしていることは明らかです。 Igniteノードに基づいて、大規模なエンタープライズ規模で非常に興味深いソリューションを構築したり、少なくとも興味深いアイデアを取り入れたりできることは直感的に明らかです。 この記事を読んだ後、読者がIgniteが提供するツールを使用して、本当に複雑で重要なトポロジを構築する方法についてのアイデアを形成したことを願っています。

参照資料

GitHubテストケースコード