夏サミ2014 【B-4】LMQでお手軽分散システム開発のスライドです

1. LMQ でお手軽
分散システム開発
Developers Summit 2014
Summer
@yosisa

2. 自己紹介
— 田中 義久
— Software Engineer
— Go / Python / Erlang /
Swift
— Internet Initiative Japan
Inc.
— Twitter: @yosisa
— GitHub: @yosisa
— Qiita: @yosisa

3. 社内での開発スタイル
— 新監視システム開発チーム
— メンバー6人
— GitHub Enterprise
— 内製の CI サーバ
— Docker / GCE

4. LMQLightweight Message Queue
https://github.com/iij/lmq

5. LMQ
メッセージキュー written in Erlang
— プロセス間のデータの受け渡しに使う
— REST 風の HTTP API で Put / Get
— キューなのでデータを保持する

6. LMQ の目指すところ
— 使いやすい
— 運用しやすい
— 十分に速い
— メッセージをロストしない

7. 開発の動機

8. より良い
監視システム
を作る

9. 旧来の監視システム (1)
監視データをローカルに格納している。
例えば、N 回連続で監視失敗したらアラート
をあげる設定の時、ローカルにある過去の監
視データが無いと正確な判定ができない。
一度割り当てた監視ターゲットを別ホスト
に移すのが難しい。

10. 旧来の監視システム (2)
監視の系を二重化して障害
に備えている。
通知が二重に出るのを防ぐ
ために、集約処理をするプ
ログラムがある。

11. 旧来の監視システム (2)
複数のアラートが起きた時
に、通知が多数でるのを防
ぐために、30秒∼10分間
の間でアラートを集約して
いる。
集約プログラムにデータ
が流れてくると、再起動が
できなくて、メンテナン
スが難しい。

12. 旧来の監視システム (3)
監視・解析・アラート担当
と、集約・通知担当の二段
構成。
✘監視の生データを別の用
途に使う
✘システムの一部だけリプ
レースする

13. 旧来の監視システム (4)
もう8年くらい動いてる。
つまり、ベースのコードは相当古い。
テスト？なにそれおいしいの？
建て増しに次ぐ建て増しでカオス。
亜種がたくさんあってカオス。
Perl と C で書かれてて＼(^o^)／

14. まとめると

15. もうこれ以上
面倒
みたくない！

16. ＼(^o^)／
— メンテナンスがすごく大変
— 設計や実装が古くて時代にそぐわない
— デプロイが職人芸と化していて、デプロ
イしたくないからコード書きたくない
— でも新たな要求はやってくる

17. でも新たな
要求は
やってくる

18. なら
作るしか
ないじゃない

19. 新監視システム
毎分 10万 IPアドレスを監視できて、
監視ホストを追加するだけでスケールして、
プロセスの再起動に気を遣わなくてよく、
容易に機能追加できる拡張性のある、
近代的な開発手法で作られた、
そんな監視システム

21. おわかりいただけただ
ろうか？

22. 大規模監視システムを支える
LMQ

23. LMQ の特徴

24. LMQ の特徴
— HTTP REST API
— シングル構成 / 冗長構成が可能
— 名前をつけて複数のキューを作成できる
— キューの自動生成
— タイムアウトベースのメッセージ再送
— 時間ベースのメッセージ集約

25. Erlang/OTP の特徴
— 関数型言語
— 軽量プロセスモデル
— Shared Nothing
— プロセス間のメッセージパッシング
— マルチコアを有効活用
— ネットワーク系の機能が Built-in

26. RabbitMQ との違い

28. Getting
Started

29. インストール
Erlang/OTP R16B01 以上が必要
$ git clone https://github.com/iij/lmq.git
$ cd lmq
$ make rel

30. 起動
$ rel/lmq/bin/lmq start
動作確認
$ rel/lmq/bin/lmq ping
pong

31. Basic API

32. Put API
POST /messages/:name
キューにメッセージを追加する
POST /messages/greeting HTTP/1.1
content-type: text/plain
Hello, world!
HTTP/1.1 200 OK
content-type: application/json
{"accum": "no"}

33. Get API
GET /messages/:name
キューからメッセージを取り出す
GET /messages/greeting HTTP/1.1
HTTP/1.1 200 OK
content-type: text/plain
x-lmq-message-id: e93fd6b1-d408-4ecb-9f6b-
d3eeebce34c1
x-lmq-message-type: normal
x-lmq-queue-name: greeting
Hello, world!

34. Reply API
POST /messages/:name/:msgid?reply=:type
メッセージの処理結果を通知する
type は ack, nack, ext の3種類
— ack: 正常終了 -> メッセージを削除
— nack: 継続不能 -> メッセージを戻す
— ext: 処理に時間がかかっている
-> タイムアウトをリセット

35. Reply API
POST /messages/:name/:msgid?reply=:type
POST /messages/greeting/e93fd6b1-d408-4ecb-
9f6b-d3eeebce34c1?reply=ack HTTP/1.1
HTTP/1.1 204 No Content

36. Reply API
POST /messages/:name/:msgid?reply=:type
POST /messages/greeting/e93fd6b1-d408-4ecb-
9f6b-d3eeebce34c1?reply=ack HTTP/1.1
HTTP/1.1 404 Not Found

37. Multi Queue API

38. Multi Queue API
個々のキューを指定する代わりに、パターン
にマッチする全てのキューを対象にする
API。
パターンは正規表現で指定する。

39. Put all API
POST /messages?qre=:regexp
パターンにマッチする全てのキューにメッセ
ージを追加する。
対象のキューはあらかじめ存在している必要
がある。

40. Put all API
POST /messages?qre=:regexp
POST /messages?qre=.* HTTP/1.1
Content-Type: application/json; charset=utf-8
{"text": "added via multi queue api"}
HTTP/1.1 200 OK
content-type: application/json
{
"greeting": {"accum": "no"}
}

41. Get any API
GET /messages?qre=:regexp
パターンにマッチするいずれかのキューから取得
GET /messages?qre=.* HTTP/1.1
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-lmq-message-id: 7cdfc909-ae9c-4704-bfa2-fd99612103e8
x-lmq-message-type: normal
x-lmq-queue-name: greeting
{"text": "added via multi queue api"}

42. ステータス

43. ステータス確認
$ rel/lmq/bin/lmq-admin status
All nodes: lmq@127.0.0.1
Active nodes: lmq@127.0.0.1
greeting 1 messages 968 bytes
accum: 0.0, retry: 2, timeout: 30.0
統計情報
$ rel/lmq/bin/lmq-admin stats
greeting
push rate: 1min 0.00, 5min 0.00, 15min 0.02, 1day 0.20
pull rate: 1min 0.00, 5min 0.00, 15min 0.00, 1day 0.00
retention time: min 0.000, max 0.000, mean 0.000, median 0.000

44. StatsD / Graphite / InfluxDB
StatsD へのメトリクス送信に対応
Graphite や InfluxDB に統計情報を集約する
ことが可能

45. タイムアウト

46. タイムアウト
LMQ はメッセージが Get されてからの時間
を管理している。
timeout 値を超えると、そのメッセージが正
しく処理できなかったとみなしてキューに戻
す。
キューに戻ったメッセージは、他のクライア
ントから Get できるようになる。

48. メッセージの集約

49. メッセージの集約
一定時間内に特定のキューに Put された全て
のメッセージを集約して、時間経過後に1つ
のメッセージとして Get できるようにする機
能のこと。
複数のコンテンツを含む以外は、通常のメッ
セージと変わらない。
キューのプロパティを設定して有効化。

51. メッセージの集約
POST /messages/accum:seq HTTP/1.1
Content-Type: application/json; charset=utf-8
{"id": 1}
HTTP/1.1 200 OK
content-type: application/json
{"accum": "new"}
POST /messages/accum:seq HTTP/1.1
{"id": 2}
HTTP/1.1 200 OK
content-type: application/json
{"accum": "yes"}

52. メッセージの集約
GET /messages/accum:seq HTTP/1.1
HTTP/1.1 200 OK
content-type: multipart/mixed; boundary=fdaef3d8-934e-4272-
b886-3f3212942f3b
x-lmq-message-id: fdaef3d8-934e-4272-b886-3f3212942f3b
x-lmq-message-type: compound
x-lmq-queue-name: accum:seq
--fdaef3d8-934e-4272-b886-3f3212942f3b
Content-Type: application/json; charset=utf-8
{"id": 1}
--fdaef3d8-934e-4272-b886-3f3212942f3b
Content-Type: application/json; charset=utf-8
{"id": 2}
--fdaef3d8-934e-4272-b886-3f3212942f3b--

53. メッセージの集約
GET /messages/accum:seq?cf=msgpack HTTP/1.1
HTTP/1.1 200 OK
content-type: application/x-msgpack
x-lmq-message-id: e227d532-01e7-42a0-b1bc-bea8efc710e4
x-lmq-message-type: compound
x-lmq-queue-name: accum:seq
����content-type�application/json; charset=utf-8�
{"id": 1}
���content-type�application/json; charset=utf-8�
{"id": 2}

54. キューのプロパティ

55. キューのプロパティ
各キュー毎に動作をカスタマイズする仕組
み。
— timeout: メッセージが再送されるまでの
時間
— retry: メッセージの再送回数
— accum: メッセージを集約する時間

56. デフォルトプロパティ
パターンにマッチするキューのプロパティを
まとめて設定する仕組み。
大量のキューを使い分ける時に、個別に設定
しなくてすむ。
パターンは正規表現で記述する。

57. Property API

58. Get Queue Property
GET /properties/:name
GET /properties/greeting HTTP/1.1
HTTP/1.1 200 OK
content-type: application/json
{
"accum": 0,
"retry": 2,
"timeout": 30
}

59. Update Queue Property
PATCH /properties/:name
PATCH /properties/greeting HTTP/1.1
Content-Type: application/json; charset=utf-8
{"accum": 30}
HTTP/1.1 204 No Content

60. Reset Queue Property
DELETE /properties/:name
DELETE /properties/greeting HTTP/1.1
HTTP/1.1 204 No Content

61. Get Default Properties
GET /properties
GET /properties HTTP/1.1
HTTP/1.1 200 OK
content-type: application/json
[
["^accum:", {"accum": 30}]
]

62. Set Default Properties
PUT /properties
PUT /properties HTTP/1.1
Content-Type: application/json; charset=utf-8
[
["^accum:", {"accum": 30}]
]
HTTP/1.1 204 No Content

63. Set Default Properties
PUT /properties
GET /properties/accum:notify HTTP/1.1
HTTP/1.1 200 OK
content-type: application/json
{
"accum": 30,
"retry": 2,
"timeout": 30
}

64. Reset Default Properties
DELETE /properties
DELETE /properties HTTP/1.1
HTTP/1.1 204 No Content
GET /properties HTTP/1.1
HTTP/1.1 200 OK
content-type: application/json
[]

65. クラスタリング

66. クラスタリング
障害対策に2つ以上の LMQ ノードを使って
クラスタを組むことができる。
マスターレスの実装。
キューの操作毎に sync する。

67. クラスタリング
クラスタに参加
$ rel/lmq/bin/lmq-admin join lmq@lmq1.example.com
クラスタから離脱
$ rel/lmq/bin/lmq-admin leave

68. Performance

69. Single

70. Cluster

72. Demo

73. ユースケース

74. プロセス間の連
携

75. プロセス間の連携
Producer と Consumer を
疎結合にできる。
どちらのプロセスも、いつ
でも再起動できる。
Consumer をサーバのよう
にする必要がない。
Consumer のキャパシティ
を超えても、Producer に
影響しない。

76. プロセス間の連携
Producer / Consumer を自
由に増減できる。
Consumer を増やすだけで
負荷分散できる。

77. PubSub 風

78. PubSub 風
Notifier は event:.* パター
ンを使って1度だけ Put す
ればよい。
Event Handler は
event:<hostname> から
Get する。
Event Handler が一時的に
down していても取りこぼ
さない。

79. バッチ処理

80. バッチ処理
流れてくるメッセージをあ
る程度まとめてから処理で
きる。
1秒間まとめるだけでも、
後段の処理が 60回/分 にな
り、バースト時の負荷を抑
えられる。
ex: メール、IRC、
ElasticSearch

81. Webhook
Receiver

82. Webhook Receiver
hook handler を HTTP
Server にする必要がな
い。
handler の数を調整するだ
けで、直列処理 or 並列処
理を選択できる。
handler が fail しても、
hook 情報を失わない。

83. Desktop 通知

84. Desktop 通知
直接疎通がなくても、
LMQ に疎通があるもの同
士で通信できる。
NAT 配下や動的 IP 化にあ
ることの多い Desktop 環
境で、サーバからの通知を
受け取れる。

85. まとめ

86. まとめ
LMQ はプロセスを役割毎に分割しやすくす
る。
LMQ を経由するポイントでシステムを拡張
しやすくなる。
複雑なシステムを、がんばって運用しなくて
いい。

87. Thank you
https://github.com/iij/lmq