「任意のコストでサバイブ」モードでのウサギの操作（RabbitMQ）

「 会社 」-通信事業者PJSCメガフォン

「 Noda 」はRabbitMQサーバーです。

「 クラスタ 」とは、3つの場合、全体として動作するRabbitMQノードの組み合わせです。

「 等高線 」-RabbitMQクラスターのセット。作業のルールは、それらの前のバランサーで決定されます。

「 バランサー 」、「 hap 」-Haproxy-ループ内のクラスターの負荷を切り替える機能を実行するバランサー。 並列で実行されるHaproxyサーバーのペアが各ループに使用されます。

「 サブシステム 」-ウサギを介して送信されるメッセージの発行者および/または消費者

「 SYSTEM 」-サブシステムのセット。当社が使用する単一のソフトウェアおよびハードウェアソリューションであり、ロシア全土に分布していますが、すべての情報が流れ、主な計算と計算が行われる複数のセンターがあります。

SYSTEM-地理的に分散したシステム-ハバロフスクとウラジオストクからサンクトペテルブルクとクラスノダールまで。 アーキテクチャ上、これらは接続されたサブシステムの機能で分割されたいくつかの中央の輪郭です。

テレコムの現実における輸送のタスクは何ですか？

簡単に言うと、サブスクライバーのアクションごとに、サブシステムの反応が続き、イベントおよび後続の変更について他のサブシステムに通知されます。 メッセージは、サブスクライバー側だけでなく、会社の従業員側およびサブシステムからもSYSTEMを使用したアクションによって生成されます（非常に多くのタスクが自動的に実行されます）。



テレコムのトランスポートの機能：非同期トランスポートを介して送信される、さまざまなデータの大きな、間違いのない大きなストリーム。



一部のサブシステムは、メッセージフローの重いために別のクラスターに存在します。たとえば、クラスターにリソースが残っていません。たとえば、5〜6千メッセージ/秒のメッセージフローでは、送信されるデータの量は170〜190メガバイト/秒に達します。 このような負荷プロファイルでは、このクラスターに他の誰かを着陸させようとすると悲しい結果につながります。すべてのデータを同時に処理するのに十分なリソースがないため、ウサギは着信接続をフローに追い込み始めます-単純な公開プロセスが開始され、すべてのサブシステムとシステムのすべての結果が全体。



輸送の基本要件：

1. 車両のアクセシビリティは99.99％でなければなりません。 実際には、これは年中無休の運用要件と、緊急事態に自動的に対応する機能に変換されます。
2. データの安全性の確保：トランスポートで失われたメッセージの割合は0になる傾向があります。

たとえば、呼び出しを行うという事実では、いくつかの異なるメッセージが非同期トランスポートを通過します。 同じ回路に存在するサブシステム向けのメッセージもあれば、中央ノードへの送信用のメッセージもあります。 同じメッセージが複数のサブシステムで要求される可能性があるため、ウサギでのメッセージの公開の段階で、メッセージはコピーされ、異なるコンシューマーに送信されます。 また、場合によっては、ハバロフスクの回線からクラスノダールの回線に情報を配信する必要がある場合に、メッセージのコピーが強制的に中間回線に実装されます。 送信は、中央の受信者に対して、メッセージのコピーが作成される中央の輪郭の1つを介して行われます。



サブスクライバーのアクションによって引き起こされるイベントに加えて、サブシステムを交換するサービスメッセージはトランスポートを通過します。 したがって、数千の異なるメッセージングルートが取得され、一部は交差し、一部は分離して存在します。 トランスポートマップのおおよそのスケールを理解するには、異なる輪郭上のルートに含まれるキューの数に名前を付けるだけで十分です：中央回線600、200、260、15 ...およびリモート回線80-100 ...



このようなトランスポートの関与により、すべてのトランスポートノードの100％のアクセス可能性に対する要件は、もはや過度に思えません。 これらの要件の実装に進んでいます。

タスクを解決する方法

RabbitMQ自体に加えて、 Haproxyは負荷のバランスを取り、緊急事態への自動応答を提供するために使用されます。



私たちのうさぎがいるハードウェアとソフトウェア環境についてのいくつかの言葉：

• すべてのウサギサーバーは仮想であり、パラメーターは8〜12 CPU、16 Gb Mem、200 Gb HDDです。 経験からわかるように、90コアと多数のRAMを備えた不気味な非仮想サーバーを使用しても、大幅に高いコストでわずかなパフォーマンスの向上が得られます。 使用バージョン：3.6.6（実際には-3.6の最も安定）アーラン18.3、3.7.6アーラン20.1
• Haproxyの要件ははるかに低く、2 CPU、4 Gb Mem、haproxyバージョンは1.8安定です。 すべてのhaproxyサーバー上のリソースの負荷は15％CPU / Memを超えません。
• 動物園全体は、全国の7つのサイトにある14のデータセンターにあり、単一のネットワークに統合されています。 各データセンターには、3つのノードと1つのハブのクラスターがあります。
• リモート回線の場合、中央回線ごとに2つのデータセンターが使用されます.4。
• 中央回線は相互に、またリモート回線と相互作用し、リモート回線は中央回線のみで動作し、相互に直接接続していません。
• 同じサーキット内のハプスとクラスターの構成は完全に同一です。 各回線のエントリポイントは、複数のA-DNSレコードのエイリアスです。 したがって、これを防ぐために、各ループで少なくとも1つのハプと少なくとも1つのクラスター（クラスター内の少なくとも1つのノード）が使用可能になります。 2つのデータセンターにある6台のサーバーで同時に障害が発生する可能性は非常に低いため、受け入れ可能性は100％に近いと想定されます。

これはすべてこのように考えられて実装されているように見えます：











今、いくつかの設定。





フロントの最初のセクションは、メインクラスタにつながるエントリポイントを説明します。2番目のセクションは、予備レベルのバランスを取るように設計されています。 バックエンドセクションですべてのバックアップウサギサーバーを単純に説明する場合（バックアップ手順）、同じように機能します-メインクラスターに完全にアクセスできない場合、接続はバックアップに行きますが、すべての接続はリストの最初のバックアップサーバーに行きます。 すべてのバックアップノードで負荷分散を保証するために、ローカルホストでのみ使用できるフロントをもう1つ導入し、それをバックアップサーバーに割り当てます。



上記の例では、2つのデータセンター内で動作するリモート回線のバランスについて説明しています。srv-rmqサーバー{01,03,05}-データセンターNo. 1に住んでおり、srv-rmq {02,04,06}-データセンターNo. 2にあります。 したがって、4コーダソリューションを実装するには、対応するウサギサーバーの2つのローカルフロントと2つのバックエンドセクションを追加するだけです。



この構成でのバランサーの動作は次のとおりです。少なくとも1つのメインサーバーが稼働している間、それを使用します。 メインサーバーが利用できない場合、予備で作業します。 少なくとも1つのプライマリサーバーが使用可能になると、バックアップサーバーへのすべての接続が切断され、接続が復元されると、それらは既にプライマリクラスタに落ちます。



この構成の操作経験は、各回路のほぼ100％の可用性を示しています。 このソリューションでは、サブシステムが完全に合法かつシンプルである必要があります。切断後にウサギと再接続できるようにするためです。



そのため、任意の数のクラスターに負荷分散を提供し、クラスターを自動的に切り替えました。今度はウサギに直接アクセスします。



実践が示すように、各クラスターは3つのノードから作成されます。これは、最適なノード数であり、可用性/フォールトトレランス/速度の最適なバランスを保証します。 ウサギは水平方向にスケーリングしないため（クラスターのパフォーマンスは最も遅いサーバーのパフォーマンスに等しい）、CPU / Mem / Hddの最適なパラメーターが同じであるすべてのノードを作成します。 サーバーをできるだけ近くに配置します。この場合、同じファーム内に仮想マシンをファイリングします。



前提条件に関しては、サブシステムの一部で、受信したメッセージを保存するための要件の最も安定した動作と実現が保証されます。

1. ウサギを使用した作業は、amqp / amqpsプロトコルを介してのみ（バランシングを介して）行われます。 ローカルアカウントでの承認-各クラスター内（および、回路全体）
2. サブシステムはパッシブモードでウサギに接続されます：ウサギのエンティティ（キュー/エシェンダイ/バインドの作成）の操作は許可されず、アカウント権限のレベルで制限されます-単に設定する権利を与えません。
3. 必要なすべてのエンティティは、サブシステムではなく中央で作成され、すべてのクラスターで同じ方法で行われます-バックアップクラスターへの自動切り替え、およびその逆を行うため。 そうでない場合は、状況を把握できます。リザーブに切り替えましたが、キューまたはバインドが存在せず、接続エラーまたはメッセージの欠落のいずれかを選択できます。

ウサギの直接設定：

1. ローカルホストはWebインターフェイスにアクセスできません
2. WebへのアクセスはLDAPを介して整理されます。ADと統合し、ウェブカメラで誰がどこに行ったかを記録します。 構成レベルでは、ADアカウントの権利を制限します。特定のグループに属している必要があるだけでなく、「見る」ためだけの権利も与えます。 監視グループで十分です。 また、ADの別のグループに管理者権限を掛けているため、トランスポートへの影響の輪は大幅に制限されています。
3. 管理と追跡を容易にするには：
   
   すべてのVHOSTで、すべてのキューに適用するレベル0のポリシーをすぐに切断します（パターン：。*）：
   
   
   
   
   • ha-mode：all-すべてのデータをクラスターのすべてのノードに保存します。メッセージの処理速度は低下しますが、安全性と可用性は保証されます。
   • ha-sync-mode：automatic-クラスターのすべてのノードでデータを自動的に同期するようにクローラーに指示します。データの安全性と可用性も向上します。
   • queue-mode：lazy-おそらくバージョン3.6以降のウサギに登場した最も有用なオプションの1つ-HDD上のメッセージの即時記録。 このオプションは、RAMの消費を劇的に削減し、ノードまたはクラスター全体の停止/フォール中のデータの安全性を高めます。
   
   
   
4. 構成ファイルの設定（ rabbitmq-main / conf / rabbitmq.config ）：
   
   
   
   
   • セクションrabbit ： {vm_memory_high_watermark_paging_ratio、0.5} -メッセージをディスクにダウンロードするためのしきい値50％。 lazyがオンの場合、たとえばlazyを含めることを忘れるレベル1のようなポリシーを作成すると、保険としての役割を果たします。
   • {vm_memory_high_watermark、0.95} -ウサギはRAM全体の95％に制限します。ウサギのみがサーバー上に存在するため、より厳しい制限を導入しても意味がありません。 5％の「幅広いジェスチャー」なので、OS、監視、その他の便利なものはそのままにしておきます。 この値は上限であるため、誰もが十分なリソースを持っています。
   • {cluster_partition_handling、pause_minority} -ネットワークパーティションが発生したときのクラスターの動作を説明します。3つ以上のノードクラスターの場合、このフラグをお勧めします-クラスターが自身を回復できるようにします。
   • {disk_free_limit、 "500MB"} -500 MBの空きディスク容量がある場合、すべてが簡単です-メッセージの発行は停止され、減算のみが使用可能になります。
   • {auth_backends、[rabbit_auth_backend_internal、rabbit_auth_backend_ldap]} -ウサギの承認順序：最初に、ローカルデータベース内の超音波の存在を確認し、存在しない場合はLDAPサーバーに移動します。
   • rabbitmq_auth_backend_ldapセクション-ADとの対話の構成： {servers、["srv_dc1"、 "srv_dc2"]} -認証が行われるドメインコントローラーのリスト。
   • ADのユーザー、LDAPポートなどを直接説明するパラメーターは純粋に個別であり、ドキュメントで詳細に説明されています。
   • 私たちにとって最も重要なことは、ウサギのWebインターフェースへの管理とアクセスに関する権利と制限の説明です：tag_queries：
     
     [{管理者、{in_group、 "cn = rabbitmq-admins、ou = GRP、ou = GRP_MAIN、dc = My_domain、dc = ru"}}、
     
     {監視、
     
     {in_group、「cn = rabbitmq-web、ou = GRP、ou = GRP_MAIN、dc = My_domain、dc = ru」}
     
     }] -この設計は、rabbitmq-adminsグループのすべてのユーザーに管理権限を提供し、rabbitmq-webグループに監視権限（アクセスの表示に最低限必要）を提供します。
     
     
   • resource_access_query ：
     
     {のために、
     
     [{permission、configure、{in_group、 "cn = rabbitmq-admins、ou = GRP、ou = GRP_MAIN、dc = My_domain、dc = ru"}}
     
     {許可、書き込み、{in_group、 "cn = rabbitmq-admins、ou = GRP、ou = GRP_MAIN、dc = My_domain、dc = ru"}}、
     
     {許可、読み取り、{定数、true}}
     
     ]
     
     } -設定および管理者グループにのみ書き込む権限を提供します。ログインに成功した他のすべての人に、権限は読み取り専用です-Webインターフェースを介してメッセージを読み取ることができます。
     
     

データの可用性と安全性を最大化する（ウサギ自体の構成ファイルと設定のレベルで）構成済みクラスターを取得します。 これにより、ほとんどの場合、データの可用性と安全性を確保するという要件を実装します。



このような負荷の高いシステムを運用する際に考慮すべき点がいくつかあります。

1. キューを作成するときにパラメーターをハングさせるのではなく、政治家がキューのすべての追加プロパティ（TTL、有効期限、最大長など）を整理することをお勧めします。 変化する現実に合わせてその場でカスタマイズできる、柔軟にカスタマイズ可能な構造になっています。
2. TTLを使用します。 キューが長いほど、CPU負荷が高くなります。 「天井を突破する」のを防ぐには、max-lengthを使用してキューの長さを制限することをお勧めします。
3. ウサギ自体に加えて、多くのユーティリティアプリケーションがサーバー上で回転していますが、奇妙なことに、CPUリソースも必要です。 食いしん坊のウサギは、デフォルトで、利用可能なすべてのカーネルを占有します...それは不快な状況であることが判明する可能性があります：ウサギのブレーキに簡単につながる可能性のあるリソースの闘争。 この状況は、たとえば次のように回避できます。アーラン起動パラメーターの変更-使用するコアの数に強制的な制限を導入します。 これを次のように行います。rabbitmq-envファイルを見つけ、SERVER_ERL_ARGS =パラメーターを探して、+ sct L0-Xc0-X + SY：Yを追加します。 Xはコア1の数（カウントは0から開始）、Y-コア1の数（1からカウント）です。 + sct L0-Xc0-X-カーネルへのバインディングを変更します。+ SY：Y-アーランによって起動されたシェダーの数を変更します。 したがって、8コアのシステムの場合、追加されるパラメーターは次の形式になります：+ sct L0-6c0-6 + S 7：7。 このようにして、ウサギに7コアのみを提供し、OSが他のプロセスを起動することにより最適に動作し、アンロードされたカーネルにハングすることを期待します。

結果として生じる動物園の運営のニュアンス

どの設定からも保護できないのは、記憶喪失したベースです-残念ながら、ゼロ以外の確率で発生します。 このような悲惨な結果は、グローバルな障害（たとえば、データセンター全体の完全な障害-負荷が別のクラスターに切り替わるなど）ではなく、同じネットワークセグメント内のより多くのローカル障害によって引き起こされます。



さらに、怖いのはローカルネットワークの障害です。なぜなら、 1つまたは2つのノードの緊急シャットダウンは致命的な結果につながることはありません-単にすべての要求が1つのノードに送られ、覚えているように、パフォーマンスはノード自体のパフォーマンスに依存します。 ネットワーク障害（通信の小さな中断は考慮していません-痛みはありません）は、ノードが相互に同期プロセスを開始し、その後数秒間何度も接続が切断される状況につながります。



たとえば、ネットワークが複数回点滅し、5秒を超える頻度で（Hapov設定でそのようなタイムアウトが設定されている場合、それらを確実に再生できますが、有効性を確認するには、失敗を繰り返す必要があります。



クラスターは、このような繰り返しを1回または2回耐えることができますが、それ以上の可能性はすでに最小限に抑えられています。 このような状況では、倒れたノードの停止は節約できますが、手動で停止する時間を持つことはほとんど不可能です。 多くの場合、結果は「ネットワークパーティション」というメッセージでクラスターからノードが失われるだけでなく、キューの一部のデータがこのノードだけに存在し、残りのノードと同期する時間がなかった場合の画像もあります。 視覚的に-キュー内のデータはNaNです。



そして今、これは明確な信号です-バックアップクラスタに切り替えます。 切り替えは幸運をもたらします;メインクラスターでウサギを止めるだけで数分です。 その結果、輸送の作業能力の回復が得られ、事故の分析とその解消に安全に進むことができます。



損傷したクラスターを読み込みから削除するには、さらなる劣化を防ぐために、最も簡単なのは、ウサギを5672以外のポートで動作させることです。ウサギを通常のポートで監視しているため、たとえば5673ウサギの設定では、クラスターを完全に無事に起動し、その操作性と残っているメッセージを復元しようとすることができます。



いくつかの手順でそれを行います。

1. 障害が発生したクラスターのすべてのノードを停止します-hapは負荷をバックアップクラスターに切り替えます
2. RABBITMQ_NODE_PORT = 5673をrabbitmq-envファイルに追加します-ウサギが起動すると、設定は強化されますが、Webインターフェースは15672で動作します。
3. 早急に死亡したクラスターのすべてのノードで新しいポートを指定し、それらを開始します。

起動時にインデックスが再構築され、ほとんどの場合、すべてのデータが完全に復元されます。 残念ながら、ディスクからすべてのメッセージを物理的に削除しなければならないクラッシュが発生し、構成のみが残されます-ディレクトリmsg_store_persistent 、 msg_store_transient 、 キュー （バージョン3.6の場合）またはmsg_stores （バージョン3.7の場合）はデータベースのあるフォルダーから削除されます。



このような急進的な治療の後、クラスターは内部構造を保持しながら起動されますが、メッセージはありません。



そして、最も不快なオプション（一度だけ観察）：ベースへの損傷は、ベース全体を完全に削除し、クラスターを最初から再構築する必要があるほどでした。



ウサギの管理と更新の利便性のために、rpmの既製のアセンブリは使用されませんが、ウサギはcpioを使用して分解され、再構成されます（スクリプトのパスを変更します）。 主な違いは、インストール/構成にルート特権を必要とせず、システムにインストールされず（再構築されたウサギはtgzに完全にパックされている）、どのユーザーからでも実行できることです。 このアプローチにより、バージョンを柔軟にアップグレードできます（クラスターを完全に停止する必要がない場合-この場合、バックアップクラスターに切り替えて更新し、シフトされたポートを操作に指定することを忘れないでください）。 同じマシン上でRabbitMQの複数のインスタンスを実行することも可能です-オプションのテストには非常に便利です-バトル動物園のアーキテクチャコピーを展開できます。



スクリプトのcpioとパスのシャーマニズムの結果として、ビルドオプションがありました：2つのrabbitmq-baseフォルダー（元のアセンブリ-mnesiaフォルダー）とrabbimq-main-ここに、ウサギとアーラン自体のすべての必要なスクリプトを入れました。



rabbimq-main / binには、ウサギとアーランのスクリプトへのシンボリックリンクと、ウサギの追跡スクリプトがあります（以下の説明）。



rabbimq-main / init.d-ログが開始/停止/回転するrabbitmq-serverスクリプト。 libでは、ウサギ自体。 lib64で-アーラン（ウサギのアーランのバージョンのみを使用）



新しいバージョンがリリースされたときに結果のアセンブリを更新するのは非常に簡単です-新しいバージョンからrabbimq-main / libおよびrabbimq-main / lib64の内容を追加し、binのシンボリックリンクを置き換えます。 更新が制御スクリプトにも影響する場合-それらのパスを変更します。



このアプローチの確実な利点は、バージョンの完全な連続性です。すべてのパス、スクリプト、制御コマンドは変更されないため、バージョンごとにドーピングすることなく、自己記述ユーティリティスクリプトを使用できます。



ウサギのfall落以来、まれにしか発生していませんが、fall落の場合は（fall落の理由のログを維持しながら）飼育を監視するメカニズムを実装する必要がありました。 ケースの99％でのノードの障害にはログエントリが伴い、痕跡を残してさえ殺すことができます。これにより、簡単なスクリプトを使用してウサギの状態の監視を実装することが可能になりました。



バージョン3.6および3.7では、ログエントリの違いにより、スクリプトがわずかに異なります。











このスクリプト（スクリプト名：check_and_run）を毎分実行するウサギ（デフォルトではrabbitmq）が動作するcrontabアカウントを設定します（最初に、管理者にcrontabを使用する権利を与えるように管理者に依頼しますが、root権限がある場合は自分で行います）：

* / 1 * * * *〜/ rabbitmq-main / bin / check_and_run



再組み立てされたウサギを使用する2番目のポイントは、ログの回転です。



logrotateシステムに縛られていないため、開発者が提供する機能を使用します。init.dのrabbitmq-serverスクリプト（バージョン3.6用）

rotate_logs_rabbitmq（）に小さな変更を加えることにより

追加：

  find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.*.back -maxdepth 0 -type f | xargs -i gzip {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キーrotate-logsを使用してrabbitmq-serverスクリプトを実行した結果：ログはgzipで圧縮され、過去30日間のみ保存されます。 http_api-ウサギがログを置くパスhttp-設定ファイルで設定： {rabbitmq_management、[{rates_mode、Detailed}、{http_log_dir、path_to_logs / http_api "}]}



同時に、 {rates_mode、 detailed }に注意を払っています。このオプションは負荷をわずかに増加させますが、WEBインターフェースのEXCHENGEでメッセージを投稿するユーザーの情報を表示できます（したがってAPIを介して取得できます）。 情報は非常に必要です、なぜなら すべての接続はバランサーを経由します-バランサー自体のIPのみが表示されます。 そして、ウサギと接続するすべてのサブシステムをパズルして、ウサギへの接続のプロパティのクライアントプロパティパラメータを入力すると、誰が、どこで、どの強度でメッセージを発行するかに関する接続レベルの詳細情報を取得することが可能になります。



新しいバージョン3.7のリリースでは、 init.dのrabbimq-serverスクリプトが完全に拒否されました。 操作（ウサギのバージョンに関係なく制御コマンドの均一性）とバージョン間のスムーズな移行を促進するために、再構築されたウサギではこのスクリプトを使用し続けます。 真実は再びです。ローテーション後のログの命名メカニズムが3.7で変更されたため、 rotate_logs_rabbitmq（）をわずかに変更します 。

  mv ${RABBITMQ_LOG_BASE}/$NODENAME.log.0 ${RABBITMQ_LOG_BASE}/$NODENAME.log.$(date +%Y%m%d-%H%M%S).back mv ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.0 ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.$(date +%Y%m%d-%H%M%S).back find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ログのローテーション用のタスクをcrontabに追加するだけです-たとえば、毎日23-00：

00 23 * * *〜/ rabbitmq-main / init.d / rabbitmq-server rotate-logs



「ウサギファーム」の運用のフレームワークで解決する必要があるタスクに移りましょう。

1. ウサギエンティティの操作-ウサギエンティティの作成/削除：ekschendzhey、キュー、バインド、シャベル、ユーザー、ポリシー。 さらに、これを行うことは、すべてのクラスタークラスターでまったく同じです。
2. バックアップクラスタに切り替えた後、バックアップクラスタに残ったメッセージを現在のクラスタに転送する必要があります。
3. すべての回線のすべてのクラスターの構成のバックアップコピーを作成する
4. Contour内のクラスター構成の完全同期
5. ウサギの停止/開始
6. 現在のデータフローを分析するには：すべてのメッセージを送信し、送信する場合はどこに送信するか、または...
7. 任意の基準で通過メッセージを見つけてキャッチする

提供されている通常のrabbitmq_managementプラグインを使用した動物園の操作と音声付きタスクのソリューションは可能ですが、非常に不便です。 そのため、さまざまなウサギ全体を制御するシェルが開発および実装されています。