クラスター相互作用の進化。 ActiveMQとHazelcastの実装方法

過去7年間、チームとともに、Miro製品のコア（以前のRealtimeBoard）をサポートおよび開発してきました。クライアントサーバーとクラスターの相互作用、データベースとの連携です。



ボードにはさまざまなライブラリを備えたJavaがあります。 すべては、Mavenプラグインを介して、コンテナーの外部で起動されます。 パートナーのプラットフォームに基づいているため、データベースやフローの操作、クライアントとサーバーのやり取りの管理などが可能です。 DB-RedisとPostgreSQL（同僚が、あるデータベースから別のデータベースに移行する方法について書いています ）。



ビジネスロジックの観点から、アプリケーションには以下が含まれます。

• カスタムボードとそのコンテンツを操作します。
• ボードのユーザー登録、作成、管理の機能。
• カスタムリソースジェネレーター。 たとえば、アプリケーションにアップロードされた大きな画像を最適化して、クライアントの速度が低下しないようにします。
• サードパーティのサービスとの多くの統合。

2011年、私たちが始めたばかりのとき、Miro全体が同じサーバー上にありました。 すべてがそこにありました：サイトのphpが変更されたNginx、Javaアプリケーション、およびデータベース。



製品が開発され、ユーザーの数とボードに追加されたコンテンツが増加したため、サーバーの負荷も増加しました。 サーバー上のアプリケーションの数が多いため、その時点では何が正確に負荷を与えているのか理解できず、したがって最適化できませんでした。これを修正するために、すべてを異なるサーバーに分割し、Webサーバー、アプリケーションとデータベースサーバーで。



残念ながら、しばらくすると、アプリケーションの負荷が増大し続けたため、問題が再び発生しました。 次に、インフラストラクチャを拡張する方法について考えました。







次に、クラスターの開発とJavaアプリケーションとインフラストラクチャのスケーリングで発生した問題について説明します。

インフラストラクチャを水平に拡張

メモリとCPUの使用、ユーザークエリの実行にかかる時間、システムリソースの使用、データベースの操作などのメトリックを収集することから始めました。 メトリックから、ユーザーリソースの生成は予測不可能なプロセスであることが明らかでした。 プロセッサを100％読み込み、すべてが完了するまで数十秒待つことができます。 ボードに対するユーザーのリクエストにより、予期しない負荷が発生することもありました。 たとえば、ユーザーが1000個のウィジェットを選択し、それらを自発的に移動し始めた場合。



システムのこれらの部分をどのように拡張するかについて考え始め、明らかな解決策を見つけました。



ボードとコンテンツを使用して作業を拡張します 。 ユーザーは次のようにボードを開きます：ユーザーはクライアントを開きます→開きたいボードを示します→サーバーに接続します→サーバーでストリームが作成されます→このボードのすべてのユーザーが1つのストリームに接続します→ウィジェットの変更または作成はこのストリーム内で行われます ボードでのすべての作業はフローによって厳密に制限されていることがわかります。つまり、これらのフローをサーバー間で分散できます。



ユーザーリソースの生成をスケーリングします 。 サーバーを取り出してリソースを個別に生成すると、生成のためのメッセージを受信し、すべてが生成されたことに応答します。



すべてがシンプルなようです。 しかし、このトピックをより深く研究し始めるとすぐに、間接的な問題をさらに解決する必要があることがわかりました。 たとえば、ユーザーの有料サブスクリプションの有効期限が切れた場合、ユーザーがどのボードであるかに関係なく、これをユーザーに通知する必要があります。 または、ユーザーがリソースのバージョンを更新した場合、すべてのサーバーでキャッシュが正しくフラッシュされていることを確認する必要があり、適切なバージョンを提供します。



システム要件を特定しました。 次のステップは、これを実行する方法を理解することです。 実際、クラスター内のサーバーが相互に通信し、それに基づいてすべてのアイデアを実現できるシステムが必要でした。

箱から出して最初のクラスター

システムの最初のバージョンは、使用したパートナープラットフォームに既に部分的に実装されているため、選択しませんでした。 その中で、すべてのサーバーはTCPを介して相互に接続され、この接続を使用してRPCメッセージを1つまたはすべてのサーバーに一度に送信できました。



たとえば、3つのサーバーがあり、それらはTCPを介して相互に接続されており、Redisにはこれらのサーバーのリストがあります。 クラスターで新しいサーバーを起動します→Redisのリストに自分自身を追加します→リストを読み取ってクラスター内のすべてのサーバーを確認します→すべてに接続します。







RPCに基づいて、キャッシュをフラッシュし、ユーザーを目的のサーバーにリダイレクトするサポートが既に実装されています。 ユーザーリソースを生成し、何かが発生したことをユーザーに通知する必要がありました（たとえば、アカウントの有効期限が切れた）。 リソースを生成するために、任意のサーバーを選択して生成要求を送信し、サブスクリプションの期限切れに関する通知のために、メッセージが目標に到達することを期待してコマンドをすべてのサーバーに送信しました。

サーバー自体がメッセージの送信先を決定します。

問題ではなく機能のように聞こえます。 ただし、サーバーは別のサーバーへの接続のみに焦点を合わせます。 接続がある場合、メッセージを送信する候補があります。



問題は、サーバー番号1が、サーバー番号4が現在高負荷になっていることを認識していないため、十分に迅速に応答できないことです。 その結果、サーバー＃1のリクエストは、処理速度が遅くなります。

サーバーは、2番目のサーバーがフリーズしていることを知りません

しかし、サーバーの負荷が高いだけでなく、一般的にフリーズした場合はどうなりますか？ さらに、それはもはや生き返らないようにハングします。 たとえば、使用可能なメモリをすべて使い果たしました。



この場合、サーバー＃1は問題が何であるかを知らないため、応答を待ち続けます。 クラスター内の残りのサーバーも、サーバー4の状況を認識していないため、サーバー4に多くのメッセージを送信し、応答を待ちます。 サーバー番号4が死ぬまでです。







どうする サーバーステータスチェックをシステムに個別に追加できます。 または、「病気の」サーバーから「健康な」サーバーにメッセージをリダイレクトできます。 これにはすべて、開発者の時間がかかりすぎます。 2012年には、この分野での経験がほとんどなかったため、すべての問題に対する既製の解決策をすぐに探し始めました。

メッセージブローカー。 Activemq

サーバー間の通信を正しく構成するために、メッセージブローカーに移行することにしました。 ActiveMQを選択したのは、特定の時間にコンシューマで受信メッセージを構成できるためです。 確かに、この機会を利用したことがないため、たとえばRabbitMQを選択できます。



その結果、クラスターシステム全体をActiveMQに移行しました。 それが与えたもの：

1. すべてのメッセージがキューを通過するため、サーバーはメッセージの送信先を自分で決定しなくなりました。
2. フォールトトレランスが構成されました。 キューを読み取るには、1つではなく複数のサーバーを実行できます。 それらの1つが落ちても、システムは動作し続けます。
3. サーバーは役割のように見え、負荷の種類によってサーバーを分割できました。 たとえば、リソースジェネレーターはメッセージを読み取ってリソースを生成するためのキューにのみ接続でき、ボードを持つサーバーはボードを開くためのキューに接続できます。
4. RPC通信、つまり 各サーバーには、他のサーバーがイベントを送信する独自​​のプライベートキューがあります。
5. サブスクリプションをリセットするために使用するトピックを介して、すべてのサーバーにメッセージを送信できます。

スキームは単純に見えます。すべてのサーバーがブローカーに接続され、サーバー間の通信を制御します。 すべてが機能し、メッセージが送受信され、リソースが作成されます。 しかし、新しい問題があります。

必要なサーバーがすべて横たわったらどうしますか？

サーバー＃3がメッセージを送信して、キュー内のリソースを生成したいとします。 彼はメッセージが処理されることを期待しています。 しかし、何らかの理由でメッセージの受信者が1人もいないことを彼は知りません。 たとえば、エラーにより受信者がクラッシュしました。



すべての待機時間の間、サーバーはリクエストとともに多くのメッセージを送信します。これがメッセージのキューが表示される理由です。 したがって、稼働中のサーバーが表示されると、蓄積されたキューを最初に処理する必要があり、時間がかかります。 ユーザー側では、これはユーザーがアップロードした画像がすぐには表示されないという事実につながります。 彼は待つ準備ができていないので、彼はボードを去ります。



その結果、リソースの生成にサーバーの処理能力を費やし、結果を必要とする人はいません。







どうすれば問題を解決できますか？ 監視を設定できます。これにより、何が起きているかが通知されます。 しかし、監視が何かを報告した瞬間から、サーバーが悪いことを理解する瞬間まで、時間が経ちます。 これは私たちには合いません。



もう1つのオプションは、サービス検出、またはどのサーバーがどのロールで実行されているかを知るサービスのレジストリを実行することです。 この場合、空きサーバーがない場合は、すぐにエラーメッセージが表示されます。

一部のサービスは水平方向にスケーリングできません

これは、ActiveMQではなく、初期のコードの問題です。 例を示しましょう：

Permission ownerPermission = service.getOwnerPermission(board); Permission permission = service.getPermission(board,user); ownerPermission.setRole(EDITOR); permission.setRole(OWNER);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ボード上のユーザー権限を操作するサービスがあります。ユーザーはボードの所有者またはその編集者になります。 取締役会にいることができる所有者は1人だけです。 あるユーザーから別のユーザーにボードの所有権を譲渡したいシナリオがあるとします。 最初の行では、ボードの現在の所有者を取得し、2行目では、編集者であったユーザーを取得し、現在は所有者になります。 さらに、現在の所有者はEDITORの役割を、元の編集者はOWNERの役割を置きます。



これがマルチスレッド環境でどのように機能するかを見てみましょう。 最初のスレッドがEDITORロールを確立し、2番目のスレッドが現在のOWNERを取得しようとすると、次のようになります-OWNERは存在しませんが、2つのEDITORがあります。



その理由は、同期の欠如です。 ボードに同期ブロックを追加することで問題を解決できます。

 synchronized (board) { Permission ownerPermission = service.getOwnerPermission(board); Permission permission = service.getPermission(board,user); ownerPermission.setRole(EDITOR); permission.setRole(OWNER); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このソリューションはクラスターでは機能しません。 SQLデータベースは、トランザクションを利用してこれを支援することができます。 しかし、Redisがあります。



別の解決策は、クラスターに分散ロックを追加して、同期が1つのサーバーだけでなくクラスター全体の内部になるようにすることです。

ボードに入る際の単一障害点

クライアントとサーバー間の相互作用のモデルはステートフルです。 そのため、ボードの状態をサーバーに保存する必要があります。 そのため、サーバーに別のロールを作成しました-BoardServerは、ボードに関連するユーザーリクエストを処理します。



BoardServerが3つあり、そのうちの1つがメインのものであると想像してください。 ユーザーは「id = 123でボードを開く」というリクエストを送信します。サーバーは、ボードが開いているかどうか、どのサーバー上にあるかをデータベースで調べます。 この例では、ボードは開いています。







メインサーバーは、サーバー1に接続する必要があると応答します。ユーザーは接続しています。 明らかに、メインサーバーが停止すると、ユーザーは新しいボードにアクセスできなくなります。



それでは、なぜボードが開いているかを知っているサーバーが必要なのでしょうか？ 単一の決定ポイントがあるように。 サーバーに何らかの問題が発生した場合、レジストリからボードを削除するか、別の場所で再度開くために、ボードが実際に使用可能かどうかを理解する必要があります。 複数のサーバーが同様の問題を解決する場合、クォーラムの助けを借りてこれを編成することは可能ですが、その時点ではクォーラムを独立して実装する知識がありませんでした。

Hazelcastに切り替える

何らかの方法で、発生した問題に対処しましたが、それは最も美しい方法ではないかもしれません。 次に、それらを正しく解決する方法を理解する必要があったため、新しいクラスターソリューションの要件のリストを作成しました。

1. すべてのサーバーとその役割のステータスを監視するものが必要です。 それをサービスディスカバリーと呼びます。
2. 危険なクエリを実行するときに一貫性を確保するのに役立つクラスターロックが必要です。
3. ボードが特定のサーバー上にあることを確認し、何か問題が発生した場合に通知する分散データ構造が必要です。

2015年でした。 Hazelcast-RAMに情報を保存するためのクラスターシステムであるIn-Memory Data Gridを選択しました。 次に、奇跡的なソリューション、クラスターインタラクションの世界の聖杯、すべてを実行でき、分散データ構造、ロック、RPCメッセージ、およびキューを結合する奇跡のフレームワークを見つけたと考えました。







ActiveMQと同様に、ほぼすべてをHazelcastに転送しました。

• ExecutorServiceを介したユーザーリソースの生成。
• 権利が変更されたときの分散ロック。
• サーバーの役割と属性（サービス検出）;
• オープンボードなどの単一のレジストリ

Hazelcastのトポロジー

Hazelcastは2つのトポロジで構成できます。 最初のオプションは、クライアントサーバーです。メンバーがメインアプリケーションとは別に配置され、メンバー自体がクラスターを形成し、すべてのアプリケーションがデータベースとしてそれらに接続します。







Hazelcastメンバーがアプリケーション自体に埋め込まれている場合、2番目のトポロジはEmbeddedです。 この場合、データとビジネスロジック自体が同じ場所にあるため、使用できるインスタンスが少なくなり、データアクセスが高速になります。







2番目のソリューションを選択したのは、より効果的で経済的に実装できると考えたためです。 Hazelcastデータへのアクセス速度が遅くなるため、効果的です。 おそらく、このデータは現在のサーバー上にあります。 経済的。追加のインスタンスにお金を費やす必要がないため。

メンバーがハングするとクラスターがハングする

Hazelcastをオンにして数週間後、問題が製品に現れました。



最初に、サーバーの1つがメモリを徐々に過負荷にし始めたことを監視が示しました。 このサーバーを監視している間に、残りのサーバーもロードを開始しました。CPU、RAM、そして5分後にすべてのサーバーが使用可能なメモリをすべて使用しました。



コンソールのこの時点で、次のメッセージが表示されました。

 2015-07-15 15:35:51,466 [WARN] (cached18) com.hazelcast.spi.impl.operationservice.impl.Invocation: [my.host.address.com]:5701 [dev] [3.5] Asking ifoperation execution has been started: com.hazelcast.spi.impl.operationservice.impl.IsStillRunningService$InvokeIsStillRunningOperationRunnable@6d4274d7 2015-07-15 15:35:51,467 [WARN] (hz._hzInstance_1_dev.async.thread-3) com.hazelcast.spi.impl.operationservice.impl.Invocation:[my.host.address.com]:5701 [dev] [3.5] 'is-executing': true -> Invocation{ serviceName='hz:impl:executorService', op=com.hazelcast.executor.impl.operations.MemberCallableTaskOperation{serviceName='null', partitionId=-1, callId=18062, invocationTime=1436974430783, waitTimeout=-1,callTimeout=60000}, partitionId=-1, replicaIndex=0, tryCount=250, tryPauseMillis=500, invokeCount=1, callTimeout=60000,target=Address[my.host2.address.com]:5701, backupsExpected=0, backupsCompleted=0}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、Hazelcastは、最初の「死にかけている」サーバーに送信された操作が進行中かどうかを確認します。 Hazelcastは最新の状態を維持しようとし、1秒間に数回操作のステータスを確認しました。 その結果、彼はこの操作で他のすべてのサーバーをスパムし、数分後にそれらがメモリから飛び出し、各サーバーから数GBのログを収集しました。



この状況は数回繰り返されました。 これは、リクエストのステータスをチェックするハートビートメカニズムが実装されたHazelcastバージョン3.5のバグであることが判明しました。 遭遇した境界ケースの一部はチェックしませんでした。 これらのケースに陥らないようにアプリケーションを最適化する必要があり、数週間後にHazelcastは自宅でエラーを修正しました。

Hazelcastに頻繁にメンバーを追加および削除する

次に発見した問題は、Hazelcastのメンバーの追加と削除です。



最初に、Hazelcastがパーティションでどのように機能するかを簡単に説明します。 たとえば、4つのサーバーがあり、各サーバーにはデータの一部が格納されています（図では、色が異なっています）。 ユニットはプライマリパーティション、デュースはセカンダリパーティション、つまり メインパーティションのバックアップ。







サーバーの電源がオフになると、パーティションは他のサーバーに送信されます。 サーバーが停止した場合、パーティションはそこからではなく、まだ生きており、これらのパーティションのバックアップを保持しているサーバーから転送されます。







これは信頼できるメカニズムです。 問題は、負荷のバランスをとるためにサーバーの電源を入れたり切ったりすることが多く、パーティションの再調整にも時間がかかることです。 そして、より多くのサーバーが実行され、Hazelcastに保存されるデータが増えるほど、パーティションの再バランスに時間がかかります。



もちろん、バックアップの数を減らすことができます。 二次パーティション。 しかし、これは安全ではありません。何かが間違いなく失敗するからです。



別の解決策は、サーバーのオンとオフがコアHazelcastクラスターに影響しないように、クライアントサーバートポロジに切り替えることです。 これを試みましたが、RPC要求をクライアントで実行できないことが判明しました。 理由を見てみましょう。



これを行うには、1つのRPC要求を別のサーバーに送信する例を考えてください。 ExecutorServiceを使用すると、RPCメッセージを送信し、新しいタスクで送信できます。

 hazelcastInstance .getExecutorService(...) .submit(new Task(), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タスク自体は、Callableを実装する通常のJavaクラスのように見えます。

 public class Task implements Callable<Long> { @Override public Long call() { return 42; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は、HazelcastクライアントがJavaアプリケーションだけでなく、C ++アプリケーション、.NETなどにもなり得ることです。 当然、Javaクラスを生成して別のプラットフォームに変換することはできません。



1つのオプションは、あるサーバーから別のサーバーに何かを送信して回答を得たい場合に、http-requestsの使用に切り替えることです。 しかし、その後、Hazelcastを部分的に放棄する必要があります。



したがって、解決策として、ExecutorServiceの代わりにキューを使用することを選択しました。 これを行うために、キュー内の要素が処理されるのを待機するメカニズムを独自に実装します。このメカニズムは、境界ケースを処理し、結果を要求元サーバーに返します。

私たちが学んだこと

システムに柔軟性を置きます。 未来は常に変化しているため、完璧なソリューションはありません。 正しく「正しく」機能するわけではありませんが、柔軟にシステムに組み込むことはできます。 これにより、重要なアーキテクチャ上の決定を受け入れることが不可能になるまで延期することができました。



Clean ArchitectureのRobert Martinは、この原則について次のように書いています。

「アーキテクトの目標は、政治を最も重要な要素とするシステムのフォームと、政治的でない詳細を作成することです。 これにより、詳細に関する決定が遅れたり遅れたりします。

普遍的なツールとソリューションは存在しません。 何らかのフレームワークがすべての問題を解決しているように思える場合、おそらくそうではありません。 したがって、フレームワークを実装するときは、どの問題を解決するかだけでなく、どの問題をもたらすのかを理解することが重要です。



すぐにすべてを書き換えないでください。 アーキテクチャの問題に直面していて、すべてをゼロから書くことが唯一の正しい解決策であると思われる場合は、待ってください。 問題が本当に深刻な場合は、簡単な修正を見つけて、システムが将来どのように機能するかを確認してください。 ほとんどの場合、これがアーキテクチャの唯一の問題ではなく、時間の経過とともにさらに見つかるでしょう。 そして、十分な数の問題領域をピックアップした場合にのみ、リファクタリングを開始できます。 この場合にのみ、その値よりも多くの利点があります。