読者です 読者をやめる 読者になる 読者になる

べにやまぶろぐ

技術寄りの話を書くつもり

夏サミ 2014 『LMQでお手軽分散システム開発』聴講メモ #natsumi

夏サミエントリー最後は IIJ さん発のメッセージングキュー LMQ の講演メモです。アジャイルのイベントかと見間違うかの Room B にあって突然のキューでしたが、興味深く拝聴させていただきました。

田中 義久 氏〔インターネットイニシアティブ

※ 聞き逃し or 理解が追いついていなくて?になっているところがあります。ご了承ください。

  • 基幹?システム開発チーム
    • 内製 CI サーバ や Docker / GCE を活用
  • LMQ : Light Weight Message Queue
    • Erlang で書かれたメッセージングキューシステム
    • REST 風 HTTP API を提供
    • 使いやすく・運用しやすく・十分に速くメッセージをロストしない
  • 古い監視システムを刷新し、新しい監視システムを作る上で必要だった
    • N 回連続で監視失敗したらアラートを上げるようなユースケースを考えたとき、過去の履歴を管理するのが難しかった
    • 監視系統を二重化しているがそのままだと二重に通知がきてしまうので最後に集約処理して通知したい、が(集約処理が挟まるため)再起動できなくてメンテナンスが難しかった
    • 監視・解析・アラートが密結合してしまっていた
    • 8年くらい前に作られたコードでメンテナンス性が悪かった
  • 結論として古い監視システムの面倒はこれ以上見られない(デプロイが職人芸になっていてデプロイしたくないからコード書きたくない)
  • 毎分10万 の IP アドレスを監視できて監視ホストを追加するだけで勝手にスケールするような監視システムを作りたい
    • 例えば 監視 - 解析 - 通知 の間にキューを挟む
  • 大規模監視システムを支えるメッセージングキュー
    • HTTP REST API
    • シングル・冗長構成両方が可能
    • 名前を付けて複数のキューを作成可能
    • キューを自動生成(事前に宣言する必要なく)できる
    • タイムアウトベースでメッセージを再送できる
    • 時間(タイムウィンドウ)ベースの集約処理
  • RabbitMQ との違い
    • LMQ は設定不要、RabbitMQ はコードで宣言
    • LMQ の配送方式は pull、RabbitMQ は push
    • LMQ の再送処理は タイムアウトベース、RabbitMQ はコネクション切断
    • LMQ のプロトコルは HTTP、RabbitMQ は AMQP
  • 使い方
    • HTTP なのでロードバランサやリバースプロキシも使える?
    • メッセージのやりとりは POST で入れて GET で取得する
    • ReplyAPI : キューに入っているタスクの状況を確認できる
    • (名前が)パターンにマッチする全てのキューにメッセージを追加したりできる
    • statsd に対応している
    • accume という時間窓を指定してメッセージを集約可能
    • MessagePack も扱える
    • キューの名前のパターンについてデフォルトプロパティを設定しておくと、新たに立ち上げたキュー(の名前がマッチした場合)そのプロパティが自動的に適用される
    • キューが稼働している最中に動的に集約する・しないなどの設定を変えることが出来る
  • クラスタリング
    • マスターレス : キューの操作ごとに同期する
    • 性能はシングル put で 20,000 ops/sec, get が 10,000 ops/sec ほど
    • マルチ put で 5,500 ops/sec, get が 4,500 ops/sec ほど
  • ユースケース
    • プロセス間連携
    • バッチ処理 : 1秒間集約させるだけでも(エラーなどの)メッセージがバーストした際の負荷を押さえられる。また、集約した状態で ElasticSearch のバルク API をたたく等すると後段にも優しい
    • hook handler : GitHub などからの web hook を Web サーバーではなくキューで受けたりすると、hook 処理のタスクがこけても(またキューに戻るので)メッセージをロストすることなく処理を再試行することができる
    • デスクトップ通知 : LMQ の URL がわかっていれば個人の PC からキューにメッセージを取りにいけるので、キュー経由で NAT を超えてインターネットから個人の PC に対して通知を行うことができる

動的にスケールすることを目指しているだけあって、名前ベースでのキューのコンフィグレーションや宣言せずにキューを使うことを許すなどは RabbitMQ より使いやすそうな印象を受けました。あとキュー内のタスクの状態を問い合わせられたり、集約できたりするのも強力そうです。とはいえ一番面白いのは HTTP を喋るというあたりで、RESTful に操作できたり GitHub みたいな Web サービスとの連携も簡単にできてしまうというのもいろいろと活用方法がありそうに感じました。