RabbitMQ can scale out!!(jp ops-workshop-3)

Copyright © NTT Communications Corporation. All rights reserved.Copyright © NTT Communications Corporation. All rights reserved.

RabbitMQ can scale out !!OpenStack RPC messaging analysis

Copyright © NTT Communications Corporation. All rights reserved.

Mahito Ogura <[email protected]>

NTTコミュニケーションズ

技術開発部クラウドコアTU

本業：主夫、副業としてIT芸人の活動

● インフラ構築（Chef, Ansible）● アプリケーション開発（Ruby）● OpenStackとか分散ミドルとかコンテナ

● 採用のお手伝いとか各種イベント業, etc...

About me

2

mailto:[email protected]


Agenda● Background

● Goal / Action

● RabbitMQ verification

● OpenStack messaging inspection

● Instance increasement load testing

● Conclusion

● Reference


● ２年ほど前にCanonical社から「1万VMでMessageQueue（以下MQ）がボトルネッ

クとなりそれ以降のVM作成が困難」とのレポートがあった

○ OpenStack SummitやOps MeetupにおいてもMQの性能問題は話題に上がっており、

Nova Cellの利用や、一部のコンポーネントを別 MQに分けるなどの対策が知られている

○ 一方で、OpenStackで多く利用されているRabbitMQクラスタを複数運用する場合、

安定性の面で課題があると言われている

● OpenStackの大規模化においてMQがボトルネックになりうるかの検証、ならびに、

ボトルネックの解消や安定運用に繋がる方式の検討を行った

Background


Goal:

● 1 RabbitMQ Clusterで多数のVMを収容可能にする

Action

● RabbitMQ 性能 / 機能検証

● OpenStack 内部メッセージング解析 / 負荷試験

● OpenStack 上におけるMQ改善方式の検証

Goal / Action



● Goal / Action

● RabbitMQ verification● OpenStack messaging inspection


● Conclusion

● Reference


RabbitMQはPivotal社が開発するAdvanced Message Queuing Protocol(AMQP)を使用したオープンソースのメッセージ指向ミドルウェアである。

RabbitMQクラスタではQueueをミラーリングすることで高可用性（HA）を実現している。

ミラーリング設定(ha-mode)には以下の３つがある[1]

● all：Queueはクラスタの全てのノードにミラーされる。

● exactly：Queueはクラスタ内のノードに指定数分だけミラーされる。クラスタ内のノードが指定

数よりも少ない場合は、クラスタ内のすべてのノードにミラーされる。

● node：Queueはノード名で指定したノードにミラーされる。

RabbitMQ is

[1]：https://www.rabbitmq.com/ha.htmla


RabbiMQクラスタ

Can RabbitMQ scale out with “exactly” mode ?RabbitMQクラスタはQueueをクラスタ内に分散させることでRead/Writeの分散を行う。

複数QueueへのRead/Writeが存在する場合、処理が各ノードへ分散するため，１ノード

あたりの負荷が軽減しクラスタ全体として性能向上すると考えられる。

今回はexactly(mirror = 2)に設定し、可用性を担保した上でスケールアウト可能か検証

を行った

client

2

4

6 スケールアウト

client

1

3

4

5 6

23

5

1

単一ノード


“HA = exactly” can scale out下記図の通り，exactly(mirror=2)の設定においてスケールアウトが可能である

クラスタのノード台数が増えるごとに処理性能が向上することを確認できた[1]

図1：Node=5 図2：Node=6 図3：Node=7

[1]：message受付ノードに負荷が集中するのを避けるため、Load Barancerを置いて負荷分散を行った上で性能測定を行った


“HA = all” can NOT scale outallではノード数が増えると大幅に性能低下する

● all設定ではスケールアウトしない

○ ミラーリングに大きくコストがかかっていると思われる

図2：Node=5, HA-mode=all図1：Node=2, HA-mode=all


● スケールアウト

○ HA-modeがexactlyの設定においてスケールアウトが可能

● RabbitMQクラスタのノード増設の挙動

○ 増設を行った場合、新規キューは増設ノードに配置される可能性があるが、

既存キューはリバランスが行われないため増設ノードに配置されない

■ リバランスには手動でのリバランス、もしくは、クラスタの再構築が必要

● リバランスにより容量の多いキューのミラーリングは高負荷が発生する

○ 増設後にクライアントもしくはLBで増設ノードへの接続先更新等の処理が必要

Results of RabbitMQ verification 1/2


● RabbitMQクラスタのノード減設の挙動

○ 耐障害性は高く，検証においてはキューが完全に消失することはなかった

○ 減設時にメッセージロストが通常時より増加する点は注意が必要

■ クライアント側でのエラーハンドリングが必要

● RabbitMQクラスタの障害時の挙動

○ クラスタノード減設時と同様の挙動

○ 障害に伴うノード減により既存キューのリバランスは発生するが、増設と同様に復旧によ

るノード増によるリバランスが発生しない

■ リバランスには手動でのリバランス、もしくは、クラスタの再構築が必要

Results of RabbitMQ verification 2/2



● Goal / Action


● OpenStack messaging inspection● Instance increasement load testing

● Conclusion

● Reference


OpenStack messaging inspectionOpenStackではコンポーネント間や、コンポーネント内のサービス間のやりとりにおいて

MQを利用したメッセージングを採用している。

OpenStackのメッセージングは大きく分けると以下の２タイプである

● API起因メッセージング

○ ユーザリクエスト

○ 定期メッセージングからの呼び出し

○ etc…

● 定期メッセージング

○ ステータス確認 /更新等

○ etc...

図1：NovaとCinderにおけるメッセージング


OpenStackの中で使われているMQのメッセージング種別は以下の3つ

作成されるQueueの目安

● “サービス名”のQueue● fanout用の“サービス名_fanout_<<uuid>>”のQueue● “サービス名 .ホスト名”のQueue● callのリプライ用の ”reply_<<uuid>>”のQueue

Messaging kinds in OpenStack

メッセージング種別メッセージング対象リプライの有無

cast 1 : 1 なし

call 1 : 1 あり

fanout 1 : n なし


ユーザリクエストや、定期メッセージングからの呼び出しにより通信が発生する

Type 1: API call messaging

16

nova-apiQueue

<conductor>

RabbitMQ

nova-conductor

Queue<scheduler>nova-scheduler

Queue<reply_xxx>

Queue<compute.”host”>nova-compute

①

②

③

④⑤

① ”conductor”へのcast

② ”scheduler”へのcall

③ ②へのreply

④ 特定のcomputeノードへのcall

⑤ ④のreply

図1：インスタンス作成の流れ


Periodic task in OpenStackOpenStackのサービス内では定期的に実行されるタスクが存在する。それらの中には

RPCにより他サービスへのメッセージングを行うものも存在する。

主要コンポーネント（Nova, Neutron, Cinder, Glance, Keystone）では以下の通り

● Nova：24（RPCあり23, RPCなし：1）● Neutron：2（RPCあり：2）● Cinder：2（RPCあり：1, RPCなし：1）● Glance：なし

● Keystone：なし


内部で定期的にAPIコールやDBアクセス、他サービスへの通信が発生する

Type 2: Periodic task messaging

18

nova-compute

Queue<conductor>

RabbitMQ

nova-conductor

Queue<reply_xxx>

nova-scheduler

Queue<scheduler>

①

②

③

① ”conductor”へのcall

　 Databaseへのアクセス

② ①へのreply

③ ”scheduler”へのcast図1：スケジューラへのインスタンス情報同期の流れ

Database


Results of OpenStack messaging inspection 1/2OpenStackのメッセージングは大きく分けて「API起因」と「定期実行」の2種類が存在す

る。

API起因、定期実行ともに共通のキューを利用するためキューの数はノードやサービス

の増加がない限り増えない

メッセージの流量はAPI call数やインスタンス、ブロックデバイス、ルータなどのリソース

や、サービスノードの数に比例して増減する

メッセージサイズはインスタンスやブロックデバイス、ルータの数などに比例して増加す

る


Results of OpenStack messaging inspection 2/2Novaへの最大メッセージ流量見積もり(msg/s)

メッセージサイズはインスタンス数やルータの数などに比例して増加する



● Goal / Action



● Instance increasement load testing● Conclusion

● Reference


Environment弊部で公開しているOpenStackのStaging環境においてインスタンスを1~1,000 インス

タンスまで作成を行い各キューへのメッセージングの流量やメッセージのサイズの計測

を行った。

● nova-compute：13 node

● RabbitMQ v3.2.4：3 node (HA：ALL)


Number of Messages & Message size

1時間におけるメッセージ数、メッセージサイズ累計はインスタンスの増加に比例して増

加することが分かる。特にconductorに対する増加は顕著である。



● Goal / Action




● Conclusion● Reference


Conclusion● RabbitMQのクラスタ機能と、HA機能を組み合わせることで、

可用性を持ちつつスケールアウト可能なMQクラスタを構築できる

○ キューのRead/Writeをクラスタ内で分散させる負荷分散のため、特定のキューに対する性能上限

を迎えた場合はスケールアップでの対応が必要

● OpenStackのメッセージングはAPI callと定期タスクにより発生し、その流度やメッ

セージサイズはサービス数やインスタンス数に比例して増減する

○ 特にnova-computeがDBアクセスのために、nova-conductorに投げるMessageが増加する。

● RabbitMQのHA: exactlyでの運用に関する情報が少ないため、

今後は大規模化・長期安定化試験などによリ問題がないかの確認が必要



● Goal / Action




● Conclusion

● Reference


Reference : OpenStack Summit Barcelona● RabbitMQ at Scale, Lessons Learned

○ Ciscoが1つのRabbitMQクラスタで800+ compute nodeを運用しているという話

○ HAはALLでRabbitMQは3台構成

○ KernelとErlang VMとRabbitMQをチューニングすれば 800+ nodeも対応可能とのこと

● Chasing 1000 Nodes Scale○ デフォルトの設定ではCPUロードがさばけなくコアを増やして対応した

○ CPUとRAMを十分に設定した場合MySQLやRabbitMQはボトルネックではない

○ nova-schedulerのパフォーマンスとスケーラビリティが問題

https://www.youtube.com/watch?v=bpmgxrPOrZw

https://www.youtube.com/watch?v=bpmgxrPOrZw

https://www.youtube.com/watch?v=XURkQ3biF6w

https://www.youtube.com/watch?v=XURkQ3biF6w


[1]：https://bugs.launchpad.net/neutron/+bug/1528895[2] : https://bugs.launchpad.net/neutron/+bug/1430999

Reference : Error while processing VIF ports

事象：OVS Neutron agentのエラーが多発

Module:neutron.plugins.openvswitch.agent.ovs_neutron_agentMessage:Error while processing VIF ports

原因：Neutronのupdate_device_up処理がRPCリクエストの

　時間内に完了せずタイムアウトを迎えるため[1][2]

対処：RPCタイムアウトの時間を伸ばす

　（修正パッチは現在対応が停止中）


Reference : Remote error: DBConnectionError

事象：DBコネクションエラー

Error during ComputeManager.update_available_resource: Remote error: DBConnectionError (OperationalError) (2003, "Can't connect to MySQL server on 'x.x.x.x' (113)") None None

原因：インスタンスが増加に伴いDBへのコネクションが枯渇

対処：DBへのコネクション数を増やす

Technology

RabbitMQ can scale out!!(jp ops-workshop-3)