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 <m.ogura@ntt.com>
NTTコミュニケーションズ
技術開発部クラウドコアTU
本業：主夫、副業としてIT芸人の活動
● インフラ構築（Chef, Ansible）
● アプリケーション開発（Ruby）
● OpenStackとか分散ミドルとかコンテナ
● 採用のお手伝いとか各種イベント業, etc...
About me
2

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

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
2
3
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 out
allではノード数が増えると大幅に性能低下する
● 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

OpenStack messaging inspection
OpenStackではコンポーネント間や、コンポーネント内のサービス間のやりとりにおいて
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-api
Queue
<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 OpenStack
OpenStackのサービス内では定期的に実行されるタスクが存在する。それらの中には
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/2
OpenStackのメッセージングは大きく分けて「API起因」と「定期実行」の2種類が存在す
る。
API起因、定期実行ともに共通のキューを利用するためキューの数はノードやサービス
の増加がない限り増えない
メッセージの流量はAPI call数やインスタンス、ブロックデバイス、ルータなどのリソース
や、サービスノードの数に比例して増減する
メッセージサイズはインスタンスやブロックデバイス、ルータの数などに比例して増加す
る

Results of OpenStack messaging inspection 2/2
Novaへの最大メッセージ流量見積もり(msg/s)
メッセージサイズはインスタンス数やルータの数などに比例して増加する

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に対する増加は顕著である。

Conclusion
● RabbitMQのクラスタ機能と、HA機能を組み合わせることで、
可用性を持ちつつスケールアウト可能なMQクラスタを構築できる
○ キューのRead/Writeをクラスタ内で分散させる負荷分散のため、特定のキューに対する性能上限
を迎えた場合はスケールアップでの対応が必要
● OpenStackのメッセージングはAPI callと定期タスクにより発生し、その流度やメッ
セージサイズはサービス数やインスタンス数に比例して増減する
○ 特にnova-computeがDBアクセスのために、nova-conductorに投げるMessageが増加する。
● RabbitMQのHA: exactlyでの運用に関する情報が少ないため、
今後は大規模化・長期安定化試験などによリ問題がないかの確認が必要

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のパフォーマンスとスケーラビリティが問題

[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_agent
Message: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へのコネクション数を増やす

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de NTT Communications Technology Development

Más de NTT Communications Technology Development (20)

Último

Último (9)

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