序文
ユーザー検索コンポーネントとログ管理プラットフォームは、プッシュサービスの重要な部分です。ElasticSearch（略してES）は、オープンソースの分散検索エンジンとして、上記の要件をより適切に満たすことができます。ESの使用を長年繰り返してきた後、特にデータ量が増え続ける場合、クラスターの管理方法、クラスターの安定性の維持、クラスターのパフォーマンスの最適化など、豊富な経験を積み重ねてきました。
この記事では、ElasticSearchアーキテクチャの進化について、大規模クラスターの課題、GProxyが複数のクラスターをサポートする方法、および現在の動作条件の3つの部分から説明します。
著者| Xiaoyao、ItweetプラットフォームのR＆Dディレクター、シニアJavaエンジニアNanyang
01
プッシュESサービスの概要
ESを使用したプッシュのビジネスシナリオは、主にユーザー情報とログストレージの追加、削除、変更、保存です。これは、プッシュをサポートするコアサービスの1つであり、その特徴は次のとおりです。
●データの高速更新：ユーザーのポートレートやその他の情報をリアルタイムで更新する必要があります
●複雑なクエリ条件：複数のディメンションをサポートして補完および補完し、組み合わせた条件を検索します
●大量のクエリデータ：プッシュタスクでは、数千万のデータをクエリする必要がある場合があります
ESを選択する主な理由は3つあります。
●ほぼリアルタイムのインデックスを提供し、最短で1秒以内に書かれたドキュメントを検索できます
●複雑な条件のクエリをサポートし、さまざまな検索条件を満たすことができます
●分散機能は、水平方向の拡張と高可用性の要件をより適切に満たすことができます
また、ES関係者や地域社会は非常に活発で、周りには多くの生態系製品があり、遭遇した問題は基本的にうまく解決できます。
02
大規模クラスターの課題
個々のプッシュクラスターの進化
上の図は、ESクラスターの進化を推進するプロセスを示しています。ワンプッシュは以前にESを使用していました。最初はバージョン0.20.xを使用し始めましたが、当時はクラスターが小さかったのですが、後でソースなしでクエリ結果をスクロールするために、インデックスソースを分離してバージョン0.90.xにアップグレードしました。次に、ソースクエリ機能をサポートしないバージョン1.2.0の公式リリースで、クラスターのマージを実行しました。その後、公式の新機能のいくつかを使用するために、1.4.xおよび1.5.xバージョンにアップグレードしました。
この時点で、クラスターサイズはすでに非常に大きく、バージョンを1回アップグレードするのは不便であり、その後の新機能はあまり魅力的ではないため、公式の2.xバージョンをスキップして、長い間アップグレードしていません。しかし、クラスターの規模が大きいため、解決が難しい問題が多く発生し始めました。分割してアップグレードする必要があり、公式バージョンもバージョン5.xに更新されました。1.xから5.xへのアップグレードはサポートされていないため、データゲートウェイの使用を検討しました。アップグレードと再起動の問題を解決するために、クラスターも上記のアーキテクチャの最後のバージョンに進化しました。
大規模なクラスターの問題
大規模なクラスターも多くの問題を引き起こします。以下は、使用中に発生した比較的難しい問題の一部です。
●最初の問題は、JVMメモリが高いままになる傾向があることです。
ESメモリは、セグメントメモリ、フィルタキャッシュ、フィールドデータキャッシュ、バルクキュー、インデックスバッファ、およびクラスタ状態バッファのいくつかの部分を占めます。セグメントメモリはセグメントファイルの増加とともに増加し、大規模なクラスタのメモリ使用量は避けられません。
フィルタキャッシュとフィールドデータキャッシュは多くのシナリオで使用されないため、パラメータ設定を通じて無効にします。バルクキューとインデックスバッファは比較的固定されており、メモリは増え続けず、パラメータを調整する必要はありません。クラスター状態バッファーは、当時は難しい問題でした。マッピングを設定する方法は、configディレクトリにdefault_mapping.jsonファイルを構成することでした。このファイルは、書き込まれたすべてのドキュメントと一致し、フォーマット分析を実行します。ES処理後、メモリに保存されます。 ParserContextのコピーがにキャッシュされます。タイプの数が増え続けると、メモリ使用量のこの部分は使い果たされるまで増加します。新しいタイプにインデックスが付けられていない場合、それは増加しません。
メモリ不足の問題が発生した場合、下図に示すようにダンプファイルを分析したところ、ParserContextの占有が原因であることがわかりました。当時、それを完全に解決する良い方法はなく、再起動してParserContextをクリアする唯一の方法は、しばらくの間一時的に解放することでした。ただし、ドキュメントを継続的に書き込むと、メモリ使用量のこの部分が再び増加します。
●2番目の問題は、特大のフラグメントと特大のセグメントです。
デフォルトでは、ルーティングの基礎としてdocidを使用し、ハッシュアルゴリズムを使用してドキュメントをさまざまなシャードにハッシュします。このように、ドキュメント数が少ない場合はフラグメントサイズは比較的均一ですが、ドキュメント数がある程度増えるとフラグメントのサイズギャップが大きくなります。各スライスの平均サイズが100gの場合、ギャップは最大20gに達する可能性があります。このとき、最大セグメントしきい値制限に達するセグメントの数も非常に多く、時間のかかるセグメントのマージにつながります。
●3番目の問題は、ディスクIOが高いことです。
スクロールを使用してドキュメントをクエリすることがよくあります。セグメントファイルが大きいと、ファイルディスク検索の効率が低下します。さらに、マシンのメモリの大部分はESノードのJVMによって占有されているため、ファイルシステムがメモリを使用してセグメントファイルページをキャッシュすることは困難です。これにより、スクロールクエリがディスクファイルを直接読み取り、IOがいっぱいになります。監視の観点から、クラスターのIOは基本的に常に満杯です。
さらに、多くの隠れた危険があります。
1つ目は、拡張のボトルネックです。クラスター内のシャードのプリセット数は元々十分でしたが、複数の拡張後、インスタンスの数はシャードの数と同じになります。インスタンスが拡張された後、クラスターはシャードを新しいものに割り当てません。インスタンス。第二に、元のマシンのディスク容量が徐々に不足しています。ESのデフォルトのウォーターマークは85％であり、フラグメントは到達後にランダムにジャンプし始め、回復が困難です。
その後、調整が困難になり、再起動とリカバリが非常に遅くなります。アップグレードして再構築すると、インデックスも非常に遅くなります。
最後に、クラスターの堅牢性も影響を受けます。ドキュメントの数が増えると、プレッシャーが高まり、障害が発生する可能性が高くなります。インスタンスに障害が発生すると、プレッシャーは他のノードに分散され、ビジネスに認識がもたらされます。
03
GProxyのソリューション
上記の問題については、次の機能を提供できる解決策を見つけたいと考えています。
1.アップグレード中のビジネス使用に影響を与えることなく、クラスターバージョンをスムーズにアップグレードできます。
2.大きなクラスターを小さなクラスターに分割することにより、ビジネスが分割され、クラスターへのプレッシャーが軽減されます。
3.クラスターデータの複数のIDCホットバックアップを提供し、さまざまな場所での複数のアクティビティのデータレイヤーサポートを提供します
ただし、以前のアーキテクチャでは、ビジネスサービスはESクラスターに直接アクセスするため、結合が厳しく、これらの要件を達成することがより困難になります。そのため、ストレージクラスターのより柔軟な運用と保守をサポートする中間層プロキシを追加することにより、ストレージクラスターとビジネスサービスクラスターを分離するプロキシベースのアーキテクチャを選択しました。
上の図は、3層アーキテクチャであるGProxyの全体的なアーキテクチャです。
●最上位層はビジネス層であり、プロキシと対話するだけで、etcdを介してプロキシのサービス検出を実現できます。
●中央にはGProxyレイヤーがあり、リクエストの転送とクラスター管理を提供します
●下部には複数のESクラスターがあります
GProxyには、いくつかのコンポーネントが含まれています。
●etcd：ルーティングルール、クラスター情報、プロキシサービスアドレス、移行タスクなどを含む、可用性の高いメタ情報ストレージデータベース。
●SDK：ESのネイティブSDKを拡張し、プロキシサービスの検出やスニファーメカニズムを介した融合などの機能をカプセル化します
●プロキシは軽量のプロキシサービスであり、拡張が非常に便利で、起動後にetcdにアドレスを登録できます。
●ダッシュボードは、クラスター全体の管理サービスであり、運用および保守担当者によるクラスターの管理と監視を容易にするWebインターフェイスを提供します。
●移行サービスは、異なるクラスター間の移行機能を提供します
サービスの検出とルーティングのルール
上記の全体的なアーキテクチャでは、解決すべき問題がさらに2つあります。
1.ビジネスサービスはどのようにプロキシを検出しますか、つまりサービス検出の問題
2.プロキシがリクエストを転送するクラスタ、つまりルーティングの問題
サービスの発見
etcdは、可用性の高い分散キー値データベースであり、操作が簡単なhttp apiを介して相互作用するため、サービス検出とメタデータストレージを実現するためにetcdを選択します。
プロキシはステートレスサービスであり、起動と初期化が完了すると、アドレスをetcdに登録します。etcdのリースメカニズムを通じて、システムはプロキシの存続ステータスを監視できます。プロキシサービスが異常で、リースを定期的に更新できない場合、etcdはプロキシサービスを削除して、通常のビジネスリクエストに影響を与えないようにします。
ElasticSearchによって提供されるsdkはスニファーインターフェイスを予約し、sdkはスニファーインターフェイスを介してバックエンドアドレスを取得できます。etcdからプロキシリストを定期的に取得し、etcdの監視メカニズムを介してサービスのオンラインとオフラインを監視し、内部接続リストを時間内に更新するスニファーインターフェイスを実装しました。ビジネス側は、あまり変更を加えることなく、ネイティブSDKを元の方法で使用できます。SDKにスニファーを挿入するだけです。
ルーティングルール
プッシュプッシュビジネスシナリオでは、各アプリプッシュに必要なデータは全体として見なすことができるため、アプリのディメンションに従ってリクエストをルーティングすることを選択し、各アプリプッシュに必要なデータはクラスターに保存されます。
ルーティング情報はetcdに格納され、形式はappid-> clusterNameなどの対応です。そのような対応がない場合、プロキシはappidをデフォルトのクラスターに割り当てます。
プロキシが起動すると、最新のルーティングテーブルがプルされ、etcdの監視メカニズムを介してルーティングテーブルの変更が監視されます。
ルーティング関係の変更は、移行操作によって実現されます。以下は、移行プロセスの概要です。
移行プロセス
各アプリはクラスターに属しています。クラスターの負荷が分散されていない場合、管理者は移行サービスを使用して、アプリのディメンションに従ってクラスター間でデータを移行できます。
移行プロセスは、データの同期とルーティングルールの変更の2つのステップで構成されます。データ同期では、完全データと増分データの2つのデータを同期する必要があります。
1.完全なデータはElasticSearchのスクロールAPIを介してエクスポートされます
2. ElasticSearchは増分データを取得する方法を提供しないため（増分データ取得を実現するためのmysqlのbinlogプロトコルと同様）、プロキシ二重書き込みを使用して増分データ取得を実現します。
移行サービスはデータ同期を担当し、データ同期が完了した後にダッシュボードに通知し、ダッシュボードはetcdのルーティング関係を更新します。プロキシは、監視メカニズムを介して新しいルーティング関係を取得し、内部ルーティングテーブルを更新します。この時点で、アプリの新しいリクエストは新しいクラスターにルーティングされます。
複数のIDCデータのホットバックアップ
プッシュの実際のビジネスシナリオでは、プッシュはエンタープライズレベルのサービスであり、高いサービス可用性が必要です。プッシュでは、外部サービスを提供するために複数のコンピュータールームがあり、各アプリは1つのコンピュータールームに属します。コンピュータルームレベルの障害に対処するには、データのマルチIDCホットバックアップを実行して、コンピュータルームに障害が発生した後、顧客の通常の使用に影響を与えないように、障害のないコンピュータルームに顧客の要求をルーティングできるようにする必要があります。
データのホットバックアップにはクラスターディメンションを使用し、各クラスターのデータは別のコンピュータールームにバックアップされます。要求を受信した後、プロキシはクラスターのホットスタンバイ情報に従ってリアルタイムで増分データをMQに書き込み、別のコンピュータールームのコンシューマーサービスはMQの増分データを継続的に消費して、対応するクラスターに書き込みます。ダッシュボードサービスは、すべてのIDCホットバックアップタスクのステータスを制御する役割を果たします。
パフォーマンス
中間層を導入すると、必然的に一定の性能低下が発生します。GO開発を選択する理由は、損失を可能な限り最小限に抑えるためです。最終的なパフォーマンス結果は次のとおりです。
上の図からわかるように、QPSは約10％減少し、平均遅延はES呼び出しとプロキシ自体の平均遅延の合計にほぼ等しくなります。パフォーマンスは10％低下しますが、より柔軟な操作および保守機能が提供されます。
現在の操作
GProxyサービスがオンラインになった後、ESバージョンのアップグレード（1.5から6.4へ）が正常に完了し、元の大きなクラスターが複数の小さなクラスターに分割されました。アップグレードと分割のプロセス全体はビジネス側の影響を受けず、GProxyが提供するロスレスロールバック機能により、操作がより確実になります（データの移行には非常に注意する必要があります）。
GProxyのサポートにより、パラメーターの最適化やクラスター間の圧力バランスなど、DBAの日常のES操作および保守操作がより便利になります。
結論
Go言語を使用することで、同社は独自にGproxyを開発し、大規模なElasticSearchクラスターに存在する問題を解決し、上位レベルのビジネスに安定した信頼性の高いデータストレージサービスを提供しました。さらに、GeTuiは引き続き独自のテクノロジーを磨き、検索とデータストレージの分野で調査を続け、ElasticSearchのアプリケーションシナリオを拡張し続け、データストレージの高可用性を確保する方法に関する最新のプラクティスを開発者と共有します。