RocketMQ は何度も改良されてきました - Hello の分散メッセージガバナンスとマイクロサービスガバナンスの実践

[[406933]]

背景

Hello は、二輪旅行 (Hello Bikes、Hello 電動アシスト自転車、Hello 電気自動車、Xiaoha Battery Exchange)、四輪旅行 (Hello Hitchhiking、All-Network Ride-hailing、Hello Taxi) を含む総合的なモバイル旅行プラットフォームへと進化し、ホテルや店内共同購入など、多くの地域生活エコシステムを模索しています。

会社の事業が成長し続けるにつれて、トラフィックも増加しています。生産現場での重大な事故の多くは、突然のトラフィックの急増によって引き起こされることが多いことがわかりました。したがって、トラフィックを管理および保護し、システムの高可用性を確保することが特に重要です。

この記事では、メッセージトラフィックとマイクロサービス呼び出しのガバナンスにおける Hello の落とし穴と蓄積された経験を共有します。

ガバナンスについて話しましょう

始める前に、ガバナンスについて話しましょう。私の個人的な理解は次のとおりです。

ガバナンスは何を行っているのでしょうか?

環境を良くしましょう

何が十分ではないのかを知りたいですか?

過去の経験ユーザーからのフィードバック業界比較

それが常に良いものかどうかをまだ知る必要がありますか?

監視、追跡、アラーム通知

状況が悪いときに、どうすれば状況を改善できるでしょうか?

管理措置と緊急時対応計画

分散メッセージガバナンスプラットフォームの構築
RocketMQ の実用的な落とし穴と高可用性マイクロサービスガバナンスプラットフォームを構築するためのソリューション

背景

裸のウサギMQ

同社は以前、RabbitMQ を使用していました。 RabbitMQ を使用する際の問題点は次のとおりです。多くの事故は、RabbitMQ クラスターの現在の制限によって引き起こされました。

過剰なバックログを解消すべきか、それとも解消しないべきか?これは質問です、考えてみます。
バックログが多すぎるとクラスターフロー制御がトリガーされますか?それは本当にビジネスに影響を及ぼします。
過去 2 日間のデータを利用したいですか?再度送ってください。
カウントに接続されるサービスはどれですか?もう少しお待ちください。 IPを探しに行かなければなりません。
大きなニュースなど、使用上のリスクはありますか？これについては推測するしかない。

裸のサービス

かつて、複数の企業が 1 つのデータベースを共有していたときに障害が発生しました。夕方のラッシュアワー時にトラフィックが急増し、データベースがダウンしました。

データベースを最高構成にアップグレードしましたが、問題は解決できませんでした。再起動後、速度は落ちましたが、すぐにまたハングアップしてしまいました。このサイクルは苦しみながら、ピークが過ぎるのを静かに待つという形で続きました。

考え：メッセージとサービスの両方に包括的なガバナンス対策が必要

分散メッセージガバナンスプラットフォームの構築

デザインガイド

どれが主要な指標で、どれが二次的な指標でしょうか?これが情報ガバナンスの主な問題です。

設計目標

基盤となるミドルウェア (RocketMQ/Kafka) の複雑さを隠し、一意の識別子を通じてメッセージを動的にルーティングすることを目的としています。同時に、リソース管理、検索、監視、アラーム、検査、災害復旧、視覚的な運用と保守を統合した統合メッセージガバナンスプラットフォームを構築し、メッセージミドルウェアの円滑で健全な運用を実現します。

メッセージガバナンスプラットフォームを設計する際に考慮すべき点

使いやすいAPIを提供
セキュリティリスクなしでクライアントの使用状況を測定するための重要なポイントは何ですか?クラスターの健全性を測定するための重要な指標は何ですか?それらを視覚化するための一般的なユーザー/操作および保守操作は何ですか?これらの不健康な問題に対処するための対策は何でしょうか

できるだけ簡単に使える

デザインガイド

複雑な問題を単純化することはスキルです。

最小限の統合API

2 つのメッセージミドルウェア (Kafka/RocketMQ) をカプセル化する統合 SDK を提供します。

1つのアプリケーション

トピックコンシューマーグループの自動作成は、実稼働環境には適していません。自動作成は制御の喪失につながる可能性があり、ライフサイクル管理全体とクラスターの安定性に悪影響を及ぼします。申請プロセスは管理される必要がありますが、できるだけシンプルにする必要があります。たとえば、1 つのアプリケーションがすべての環境で有効になり、関連するアラームルールが生成されます。

クライアントガバナンス

デザインガイド

クライアントの使用が標準化されているかどうかを監視し、それを管理するための適切な対策を見つける

シーン再生

シナリオ 1: 瞬間トラフィックとクラスタフロー制御

現在のクラスターの Tps が 10,000 で、瞬時に 20,000 以上に増加すると仮定します。このトラフィックの急激な増加により、クラスターフロー制御が発生する可能性が高くなります。このようなシナリオでは、クライアントの送信速度を監視し、速度と急峻さのしきい値が満たされたときに送信をスムーズにする必要があります。

シナリオ 2: 大きなメッセージとクラスタジッタ

クライアントが数百 KB または数メガバイトのメッセージなどの大きなメッセージを送信すると、IO 時間が長くなり、クラスターのジッターが発生する可能性があります。このようなシナリオを管理するには、送信されたメッセージのサイズを監視する必要があります。私たちは事後検査を通じて大きなメッセージを持つサービスを特定し、メッセージのサイズを 10 KB 未満に抑えるためにサービスを圧縮または再構築することをユーザーに推奨します。

シナリオ3: クライアントのバージョンが低すぎる

機能が反復されるにつれて、SDK バージョンもアップグレードされます。機能の変更に加えて、変更によってリスクも生じる可能性があります。古いバージョンを使用する場合、機能がサポートされない可能性があることと、セキュリティ上のリスクがある可能性があることが問題になります。 SDK の使用状況を把握するために、SDK のバージョンを報告し、検査を通じてユーザーにアップグレードを促すことができます。

シナリオ4: 消費トラフィックの除去と回復

消費者トラフィックの削除と復元には通常、次の使用シナリオがあります。1 つ目は、アプリケーションをリリースする前にトラフィックを削除する必要がある場合です。もう 1 つは、問題を特定するときにトラブルシューティングを行う前にトラフィックを削除することです。このシナリオをサポートするには、クライアントで削除/再開イベントをリッスンして、消費を一時停止および再開する必要があります。

シナリオ5: 送信/消費時間の検出

メッセージを送信/消費するにはどのくらいの時間がかかりますか?時間の消費を監視することで、パフォーマンスが低いアプリケーションを特定し、ターゲットを絞った変革を促進してパフォーマンスを向上させることができます。

シナリオ6: 調査と位置決めの効率化

問題のトラブルシューティングを行う際には、送信されたメッセージ、メッセージの保存場所、メッセージが使用された日時など、メッセージのライフサイクルに関連する情報を取得する必要があることがよくあります。この部分は、msgId を通じてメッセージ内のライフサイクルを連結するために使用できます。もう 1 つの方法は、リンク識別子と同様に、メッセージヘッダーに rpcId/traceId を埋め込んで、メッセージを 1 つのリクエストにまとめることです。

ガバナンス対策の改善

必要な監視情報

送信/消費速度送信/消費時間メッセージサイズノード情報リンク識別バージョン情報共通ガバナンス対策

定期検査: 追跡情報により、検査を通じて危険なアプリケーションを見つけることができます。たとえば、送信/消費時間が 800 ミリ秒を超える、メッセージサイズが 10 KB を超える、バージョンが特定のバージョンより小さいなどです。
送り平滑化：例えば、瞬間流量が10,000に達して2倍以上に増加したことが検出された場合、予熱により瞬間流量を平滑化できます。
消費フロー制御: サードパーティインターフェイスでフローを制限する必要がある場合、消費フローを制限できます。この部分は、高可用性フレームワークと組み合わせて実装できます。
消費の削除: 削除イベントをリッスンして、コンシューマークライアントを閉じて復元します。

トピック/消費者グループのガバナンス

デザインガイド

トピックコンシューマグループのリソース使用状況を監視する

シーン再生

シナリオ1: 消費の遅れがビジネスに与える影響

一部のビジネスシナリオは消費の蓄積に非常に敏感ですが、一部のビジネスはバックログに敏感ではなく、後で追いつく限り消費することができます。たとえば、自転車のロックを解除するには数秒かかりますが、情報集約に関連するバッチ処理シナリオはバックログの影響を受けません。消費バックログ指標を収集することで、基準を満たす申請を担当する学生にリアルタイムアラートが送信され、消費状況をリアルタイムで把握できるようになります。

シナリオ2: 消費/送信速度の影響

送信/消費速度がゼロに低下しますか?シナリオによっては、速度をゼロまで下げることができません。ゼロになると、ビジネスが異常であることを意味します。速度指標を収集することで、しきい値を満たすアプリケーションに対してリアルタイムのアラートが発行されます。

シナリオ3: コンシューマーノードがオフライン

コンシューマーノードがオフラインになった場合は、アプリケーションの担当者に通知する必要があります。これには、ノードがオフラインになったときにアラーム通知をリアルタイムでトリガーできるように、登録ノード情報を収集する必要があります。

シナリオ4: 送信と消費の不均衡

送信と消費の不均衡はパフォーマンスに影響を与えることがよくあります。ある相談の際、クラスメートがメッセージを送信するためのキーを定数に設定していたのを覚えています。デフォルトでは、キーをハッシュすることによってパーティションが選択され、すべてのメッセージが 1 つのパーティションに入ります。どうやってもパフォーマンスは向上しませんでした。さらに、各パーティションの消費バックログを検出し、過度の不均衡が発生した場合にリアルタイムのアラーム通知をトリガーする必要があります。

ガバナンス対策の改善

必要な監視情報

送信/消費速度送信パーティションの詳細各パーティションの消費バックログ消費グループバックログ登録ノード情報共通ガバナンス対策

リアルタイムアラーム: 消費バックログ、送信/消費速度、ノード切断、パーティションの不均衡に関するリアルタイムアラーム通知。
パフォーマンスの向上: 需要を満たせない消費バックログがある場合は、プルスレッド、消費スレッドを増やしたり、パーティション数を増やしたりすることでパフォーマンスを向上させることができます。
セルフサービストラブルシューティング: 時間範囲によるメッセージライフサイクルの多次元検索、msgId 検索、リンクシステムなどの多次元検索ツールを提供します。

クラスターのヘルス管理

デザインガイド

クラスターの健全性を測定するためのコア指標は何ですか?

シーン再生

シナリオ 1: クラスターのヘルスチェック

クラスターのヘルスチェックは、「クラスターは正常ですか?」という 1 つの質問に答えます。この問題は、クラスターノードの数、クラスター内の各ノードのハートビート、クラスターの書き込み Tps 水位、およびクラスターの消費 Tps 水位を検出することで解決できます。

シナリオ 2 クラスターの安定性

クラスターフロー制御は、多くの場合、クラスターのパフォーマンスが不十分であることを反映し、クラスタージッターによってクライアントの送信タイムアウトが発生することもあります。クラスター内の各ノードのハートビート時間消費とクラスター書き込み TPS 水位の変化率を収集することで、クラスターが安定しているかどうかを把握できます。

シナリオ3: クラスターの高可用性

高可用性には主に、特定の可用性ゾーンが利用できない、またはクラスター内の一部のトピックとコンシューマーグループが異常であるなどの極端なシナリオを対象とした対策が必要です。たとえば、MQ は、同じ都市の可用性ゾーン間でのマスター/スレーブクロスデプロイメント、トピックとコンシューマーグループの災害復旧クラスターへの動的な移行、マルチアクティブなどを通じて解決できます。

ガバナンス対策の改善

必要な監視情報

クラスターノードの数、クラスターノードのハートビート時間、クラスター書き込み Tps 水位、クラスター消費 Tps 水位、クラスター書き込み Tps 変化率、一般的なガバナンス対策

定期検査：クラスター Tps 水位とハードウェア水位の定期検査。
災害復旧対策: 同じ都市内のアベイラビリティーゾーン間でのマスター/スレーブのクロスデプロイメント、災害復旧の災害復旧クラスターへの動的な移行、およびマルチリージョンのアクティブ/アクティブ。
クラスターのチューニング: システムバージョン/パラメーター、クラスターパラメーターのチューニング。
クラスター分類：事業ラインによる分類、コア・非コアサービスによる分類。

最も重要な指標に焦点を当てる

これらの主要指標のうち最も重要なものはどれですか?クラスター内の各ノードのハートビート検出、つまり応答時間 (RT) を選択します。 RT に影響を与える可能性のある理由を見てみましょう。

アラームについて

監視指標のほとんどは、会社の統合アラームシステムにプッシュされるしきい値アラームをトリガーする第 2 レベルの検出、会社の検査システムにプッシュされるリアルタイム通知検査リスク通知、および毎週の概要通知です。

メッセージングプラットフォームアイコン

アーキテクチャ図

ダッシュボードアイコン

多次元: クラスター次元、アプリケーション次元完全集計: 主要指標の完全集計

RocketMQの実際的な落とし穴と解決策

アクションガイド

私たちは常に落とし穴に遭遇しますが、遭遇したときにはそれを埋めていきます。

1. RocketMQ クラスターの CPU の不具合

問題の説明

RocketMQ スレーブノードとマスターノードの CPU 使用率が頻繁に急上昇し、明らかな不具合が発生しました。多くの場合、スレーブノードが直接クラッシュしました。

システムログにのみエラーがあります

2020-03-16T17:56:07.505715+08:00 VECS0xxxx カーネル:[] ? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00 VECS0xxxx カーネル: java: ページ割り当て失敗。順序:0、モード:0x202020-03-16T17:56:07.505719+08:00 VECS0xxxx カーネル: Pid: 12845、通信: java 汚染されていません 2.6.32-754.17.1.el6.x86_64 #12020-03-16T17:56:07.505721+08:00 VECS0xxxx カーネル: 呼び出しトレース:2020-03-16T17:56:07.505724+08:00 VECS0xxxx カーネル:[] ? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505726+08:00 VECS0xxxx カーネル: [] ? dev_queue_xmit+0xd0/0x3602020-03-16T17:56:07.505729+08:00 VECS0xxxx カーネル: [] ? ip_finish_output+0x192/0x3802020-03-16T17:56:07.505732+08:00 VECS0xxxx カーネル: [] ?

さまざまなデバッグシステムパラメータは、問題を遅くすることはできますが、問題を解消することはできません。不具合は依然として50%を超えています。

解決

クラスター内のすべてのシステムを CentOS 6 から CentOS 7 にアップグレードし、カーネルバージョンを 2.6 から 3.10 にアップグレードすると、CPU の不具合は解消されました。

2. RocketMQ クラスターのオンライン遅延メッセージ障害

問題の説明

RocketMQ コミュニティバージョンはデフォルトで 18 のレイテンシレベルをサポートしており、各レベルは設定された時間にコンシューマーによって正確に消費されます。この目的のために、消費間隔が正確であるかどうかも具体的にテストしましたが、テスト結果は非常に正確であることが示されました。しかし、このような正確な機能には、実は問題がありました。ビジネス上の同僚から、特定のオンラインクラスター内の遅延メッセージを消費できなかったという報告がありました。変だったよ！

解決

「 delayOffset.json 」と「 consumerqueue / SCHEDULE_TOPIC_XXXX 」を他のディレクトリに移動します。これは、それらを削除するのと同じです。ブローカーノードを 1 つずつ再起動します。再起動後、遅延メッセージ機能が正常に送信され、消費されていることを確認しました。

高可用性マイクロサービスガバナンスプラットフォームを構築する

デザインガイド

当社のコアサービスと非コアサービスはどれですか?これがサービスガバナンスの主な問題です。

設計目標

このサービスは、突然のトラフィックの急増にも対応でき、特にコアサービスの円滑な運用を保証します。

アプリケーションのグレーディングとグループ化の展開

アプリケーションの評価

アプリケーションは、ユーザーとビジネスへの影響の評価基準に基づいて 4 つのレベルに分類されます。

ビジネスへの影響: アプリケーション障害によって影響を受けるビジネスの範囲ユーザーへの影響: アプリケーション障害によって影響を受けるユーザーの数
S1：自転車、電動アシスト自転車などの主力事業の基幹リンク、ライドシェアの受発注の基幹リンク、およびこれらの基幹リンクに大きく依存するアプリケーションなど、障害が発生すると外部ユーザーが使用できなくなる、または重大な資産損失が発生する基幹製品。

S2: トランザクションに直接影響を及ぼさないが、フロントエンドビジネスまたはビジネスバックエンド処理の重要な構成の管理と保守に関連する機能。

S3: サービス障害はユーザーやコア製品ロジックにほとんど影響を与えず、主要ビジネスや小規模な新規ビジネスにも影響を与えません。これらは社内ユーザーにとって重要なツールであり、直接業務に影響を与えるものではありませんが、関連する管理機能もフロントエンド業務にほとんど影響を与えません。

S4: 社内ユーザーが使用するシステムで、ビジネスに直接影響しないか、後でオフラインにする必要があるシステム。

グループ展開

S1 サービスは当社の中核サービスであり、保護の中心です。コア以外のサービストラフィックによる予期しない影響から保護する必要があります。

S1 サービスはグループで展開され、安定環境とスタンドアロン環境の 2 つの環境に分かれています。非コアサービスは S1 サービストラフィックを呼び出し、それをスタンドアロン環境にルーティングします。
S1サービスは非コアサービスを呼び出し、サーキットブレーカーポリシーを必要とする

複数の電流制限とヒューズ機能を備えた構造

当社が構築する高可用性プラットフォーム機能

部分電流制限効果図

予熱アイコン

列に並んで待つ

ウォームアップ + キュー