【勉強会】JJUGナイトセミナー_メッセージングミドルウェア特集
2017-09-27 JJUGナイトセミナー_メッセージングミドルウェア特集
RabbitMQ
「実運用して分かったRabbit MQの良いところ・気をつけること」
- ヤフー株式会社 祖父江 翔さん
www.slideshare.net
広告システム
RabbitMQ導入前の課題 ブローカーのないキュー管理の仕組み 接続設定が職人芸 各APIサーバがどこにつなぐかをそれぞれ設定ファイルに持つ 変更時は全サーバに再配信が必要
キュー管理の仕組みに求めたこと - 今までPHPだったものをJavaに移行 - 耐障害性 - Consumer/Producerが容易に追加できる - スループットが高いこと
RabbitMQを採用した理由 - AMQPで動作する、JavaでもPHPでも - クラスタ構築が簡単、スケールアウトも - Consumer/Producerが容易に追加できる - ルーティングの機能がある
BackEndAPIから配信システム連携バッチの間に構築
よかったこと - Java/PHPの混在でも問題なく動作する - クラスタが組めるので１台落ちても問題なし - 接続崎はクラスタにすればいいので設定が楽 - 1クラスタVM3台（8CPU/16GMEM/120GDisk）1000万msg/dayを10クラスタ
注意点
RabbitMQクラスタの前にLBを置いてみた - メッセージが時々見つからなくなる、原因不明 - 整合性が取れない、消えたデータを探して手動リカバリ運用してた - LBがセッションを維持しない仕様だった（しかも変更不可） - JavaのRabbitMQクライアントはLBなくてもバランシング・接続復旧が可能だった - 結果、クライアント側にクラスタを全部指定することにした
プロビジョニング（セットアップ時）でクラスタが応答しなくなった メッセージが大量になると無応答になる 1. ディスクI/O デフォルトではメモリでなくディスクに書く仕様 マスタのみディスク、スレーブはメモリに設定して対応した ただし公式ドキュメントではディスクを推奨、メモリは特殊ケースのみ 2. トラフィック統計の設定 管理プラグインでメッセージの流量を監視するつもりだった デフォルトのBASICモードだとメトリクス取りすぎててパフォーマンスが超落ちる
保守運用面
無停止バージョンアップ 24時間入稿が来るので、MWのバージョンアップでは停止できない 一時的に新旧並列にして対応
ネットワークパーティション 再起動でいけた 公式のドキュメントにも書いてあった、公式に結構書いてある
Kafka
「40分弱でわかるApache Kafka」
Apache Kafkaは分散Pub-Subメッセージングシステムです。 2011年にLinkedInによって公開されて以降ストリーミングデータを扱うプロダクトとしてユースケースを増やし、今ではFortune 500の内3分の1の企業が本番で利用するようになっています。 このセッションではKafkaの特徴、ユースケース、アーキテクチャ、簡単な使い方を紹介します。
ヤフー 森谷 大輔さん
Kafkaをこれから始めたい人向け
スケーラブルな分散pub/sub型メッセージングシステム LinkedInが開発
何が嬉しいか publisherとsubscriberを非同期に分離できる 自由に増やせる、どちらかが止まってもブロックされることがない
標準的なサーバ１台で、10万レコード/秒のread/writeのスループット オートスケールではないが、 レイテンシはEtoEで数ミリ秒（99%tile） 耐障害性、クラスタでレプリケーション、書き込み時のAck 独自のプロトコル、AMQPでなく partition単位で順序保証あり
Kafkaは書き込まれたデータを永続化する 受信者は、どこを読むか（オフセット）をコントロールできる 再送依頼、問題調査、洗い替えなどで、昨日の何時から何時とか、現実的によくある依頼
Producer/Consumer/Broker/ZooKeeper で構成される
Apache ZooKeeper 可用性と信頼性の高い分散コーディネーションシステム クラスタマネジメント、死活管理、ACL情報のストアに利用
Messageは独自フォーマットのバイナリ key/value/timestamp等のメタデータ
BrokerがMessageのストリームにラベルを付ける、任意の名前
不可分散はPartition keyのハッシュ値でpartitionを決定、keyがなければラウンドロビン
partitionは任意のディレクトリパスにファイルとして永続化させる これをログと呼ぶ
ConsumerGroup 複数のConsumerを論理的にグルーピングできる
ユースケース、一般論では データパイプライン ストリーム処理
データパイプライン これまでは、いくつかのデータソースからRDBMSとHadoopくらい それなら問題ない、パイプラインもシンプル 最近は、 データソースがさまざま 突っ込んだデータを機械学習でストリーム処理して入れ直して、とか
ストリーム処理はMapReduceの早い版みたいな データが多すぎて
日次クリックを知りたい、 じゃなくて、 クリック率の急増を見たいとか
ストリームデータ、終わりなく発生し続けるデータ
ETL（Extract/Transform/Load） Transform、ストリーム処理してKafkaに書き戻す 名寄せしたり、データに価値を付与する そのままデータを突っ込むのではない、のが重要
Pulsar
「メッセージキュー「Pulsar」の紹介」
- ヤフー 栗原 望さん
www.slideshare.net
- Pulsarとは、Yahoo!Inc.で開発されたPub/Subメッセージングシステム
- Pub/Subメッセージングの代表的な製品
- Kafka、大量データの高速処理
- RabbitMQ、AMQPサポート、パフォーマンスより信頼性
- ActiveMQ、多くの言語をサポート
Pulsarの背景 ヤフーの全社プラットフォームとしてのMQの提供
求められる要件 １。ハイパフォーマンス、スケーラビリティ PV：2億/day
２。複数サービスが同居できること 1つのMQに複数のサービスが同居できること（＝マルチテナント）
３。複数のDC間でのレプリケーション 複数のDCをまたいでサービスを提供している すべてのDCで同じメッセージを受けて同じ処理をしたい
１。高速でスケーラブル 実績、1000億msg/day、処理時間5ms
２。マルチテナント 同居させても認証認可はちゃんとできる
３。ジオレプリケーション あるDCのトピックにメッセージを送ると、他のDCに複製配信可能
システム構成 Pulsarは状態を持たない Broker Bookie、BookKeeperのストレージノード ZooKeeper、トピックの管理に必要なメタ情報を保存
BookKeeperは分散型ログストレージサービス SSDに先行書き込み、HDDに永続化するアーキテクチャ
Kafka/RabbitMQとの比較
RabbitMQはAMQPべーすなので、柔軟だが複雑
PulsarはクライアントがJava/C++/Python、あとはWebSocketAPIでカバー
PulsarはStorm/Spark/Heronと連携可能 RabbitMQはStorm/Spark/Flinkと連携可能
Pulsarはマルチテナント向き、トピックが階層化されているのと、Quotas：リソース割り当てが可能 Kafkaはトピックの階層化ができない、Quotasは設定可能 RabbitMQはVirtualHostで論理的な分離は可能、Quotas設定不可
メッセージ・講読位置・メタデータ PulsarはBrokerに状態持たない、BookKeeper使う、メタデータはZooKeeper Brokerの負荷分散が容易、スケールも KafkaやRabbitMQはBrokerの設定やら大変
スケーラビリティ PulsarはBookieのおかげでトピック数が膨大でもパフォーマンス落ちない し、スケールアウトできるのも強み Kafkaはトピック数＊パーティション数のディレクトリが作成されるため、 Broker1台あたりの数が膨大だとパフォーマンス落ちる RabbitMQは分散構成の構築が可能だが、組み合わせが複雑 ZooKeeperがないので、メタデータもBrokerが持つ必要が
Pulsarはマルチテナント・スケールアウト・パフォーマンスが強み コンポーネントが多い Kafka、多数の言語サポート、 データ増えた時のパフォーマンス RabbitMQ AMQPの使用が複雑
