RocketMQ は何千もの試行錯誤を経て改良されてきました。 Helloの分散メッセージガバナンスとマイクロサービスガバナンスの実践

[[411727]]

背景

Helloは、二輪旅行（Hello Bikes、Hello電動アシスト自転車、Hello電気自動車、Xiaoha Battery Exchange）と四輪旅行（Helloヒッチハイク、全ネットワーク配車サービス、Helloタクシー）を含む総合的なモバイル旅行プラットフォームへと進化し、ホテルや店内共同購入など、多くの地域生活エコシステムを模索しています。

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

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

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

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

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

• 環境を良くしましょう

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

• これまでの経験
• ユーザーからのフィードバック
• 業界比較

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

• 監視と追跡
• アラーム通知

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

• ガバナンス対策
• 緊急時対応計画

目次

1. 分散メッセージガバナンスプラットフォームの構築
2. RocketMQの実際的な落とし穴と解決策
3. 高可用性マイクロサービスガバナンスプラットフォームを構築する

背景

裸のウサギ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 つのリクエストにまとめることです。

ガバナンス対策の改善

必要な監視情報

• 送信/消費速度
• 送信/消費時間
• メッセージサイズ
• ノード情報
• リンクID
• バージョン情報

共通のガバナンス対策

• 定期検査: 追跡情報により、検査を通じて危険なアプリケーションを見つけることができます。たとえば、送信/消費時間が 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 に影響を与える可能性のある理由を見てみましょう。

アラームについて

• ほとんどの監視指標は数秒で検出されます
• しきい値をトリガーするアラームは、会社の統合アラームシステムにプッシュされ、リアルタイムで通知されます。
• 検査リスク通知は会社の検査システムにプッシュされ、毎週の概要通知が送信されます。

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

アーキテクチャ図

ダッシュボードアイコン

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

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

アクションガイド

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

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

問題の説明

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

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

2020-03-16T17:56:07.505715+08:00 VECS0xxxx カーネル:[] ? __alloc_pages_nodemask+0x7e1/0x960
 2020-03-16T17:56:07.505717+08:00 VECS0xxxx カーネル: java: ページ割り当て失敗。順序:0、モード:0x20
 2020-03-16T17:56:07.505719+08:00 VECS0xxxx カーネル: Pid: 12845、通信: java 汚染されていない2.6.32-754.17.1.el6.x86_64 #1
 2020-03-16T17:56:07.505721+08:00 VECS0xxxx カーネル: 呼び出しトレース:
 2020-03-16T17:56:07.505724+08:00 VECS0xxxx カーネル:[] ? __alloc_pages_nodemask+0x7e1/0x960
 2020-03-16T17:56:07.505726+08:00 VECS0xxxx カーネル: [] ? dev_queue_xmit+0xd0/0x360
 2020-03-16T17:56:07.505729+08:00 VECS0xxxx カーネル: [] ? ip_finish_output+0x192/0x380
 2020-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 サービスはコア以外のサービスを呼び出し、サーキットブレーカーポリシーを構成する必要があります。

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

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

部分電流制限効果図

• 予熱アイコン

• 列に並んで待つ

• ウォームアップ + キュー

• 高可用性プラットフォーム図
• すべてのミドルウェアが接続されている
• 動的構成はリアルタイムで有効になります

各リソースとIPノードの詳細なトラフィック

要約する

• 私たちの主要な指標と二次的な指標は何ですか?これが情報ガバナンスの主な問題です。
• 当社のコアサービスと非コアサービスはどれですか?これがサービスガバナンスの主な問題です。
• ソースコードと実際の戦闘は、作業と学習のより良い方法です。

著者について

Liang Yong (Lao Liang) は、「RocketMQ 実践と上級」コラムの共著者であり、「RocketMQ Technical Insider」のレビューに参加しました。 ArchSummit Global Architect Conference および QCon Case Study Group の講師。