ヌーラボが Mackerel に移行した３つの理由

Presentation Slides at Mackerel Meetup#2 Tokyo http://mackerelio.connpass.com/event/8458/

Transcript

1. Mackerel  Meetup#2  Tokyo #mackerelio 2014/09/24(⽔水)  @株式会社フリークアウト ヌーラボが  Mackerel  に移⾏行行した３つの理理由
2. 染⽥田  貴志 SOMEDA  Takashi @tksmd 株式会社ヌーラボ エバンジェリスト
3. API  Meetup  Tokyo  #3 http://api-‐‑‒meetup.doorkeeper.jp/events/14087 •  9/26(⾦金金)  19:00〜～21:00 •  @NTTコミュニケーションズ  汐留留
4. Mashup  Awards  10 http://mashupaward.jp/companies/24 •  コラボレーションカテゴリで  API  提供中！ •  昨年年のヌーラボ賞は「博多よかとこ遊びにこんね賞」
6. JAWS  Days  2013 国内を中⼼心に  約3000クライアント  が利利⽤用するプロジェクト管理理ツール タスク管理理機能に加え、 •  WebDAVによるファイル共有 •  GitやSubversionのリポジトリホスティング などを提供。 http://www.backlog.jp
7. 全世界  約135万ユーザ  が利利⽤用するオンラインのドローツール 基本的なドローツールの機能に加え •  複数のユーザで同時に編集出来るリアルタイムコラボレーション •  Google+  Hangouts  と連携して、ビデオチャットとあわせて利利⽤用可能 といった、コラボレーション機能が充実。 http://cacoo.com/
8. 今年年正式版をリリースしたばかりの新しいチャットサービス •  ヌーラボの各サービスとの連携 •  豊富で使いやすい  API  の提供 http://typetalk.in/
9. ヌーラボサービス向けのシングル・サインオンサービス •  サービス間のプロフィールの共有 •  アプリケーションラウンチャー •  複数のバックログスペースへの統⼀一的なアクセス
10. 本⽇日のお話 1.  Mackerel  に移⾏行行した３つの理理由 2.  ヌーラボでの  Mackerel  の使い⽅方 3.  まとめ
11. 1.  Mackerel  に移⾏行行した３つの理理由
12. 背景 •  インフラエンジニアがいない  (絶賛募集中！） •  昨年年から運⽤用するサービスが２つから４つに http://www.flickr.com/photos/stuart_̲spivack/3850975920/
13. https://speakerdeck.com/nulabinc/yun-‐‑‒yong-‐‑‒devopsshi-‐‑‒ dai-‐‑‒wosheng-‐‑‒kinukutameni
14. インフラ運⽤用体制の変更更 •  アプリ開発者が基本的なインフラ作業も担う体制へ •  インフラ全般を⾒見見るスタッフは基本仕組みづくりに注⼒力力 Backlog Cacoo Typetalk Nulab  Account 開発 Backlog  の開発 チームが担当 Cacoo  の開発 チームが担当 Typetalk  の開発 チームが担当 Nulab  Account  の 開発チームが担当 インフラ 構築 インフラ 運⽤用 インフラ 全体改善 インフラ全般を⾒見見るスタッフが担当 以 前 は 数 ⼈人 で こ こ を す べ て ⾒見見 て い た
15. 実際やってみたところ •  構築系の作業 •  Ansible  /  Fabric  などの導⼊入で⾃自動化を推進 •  概ね構築系はできるようになった •  運⽤用系の作業 •  リリースなどの定型化したものは◦ •  トラブルシューティングなど定型化しにくい ものに課題はまだある •  モニタリングの重要性なども共有しきれてな いものも
16. モニタリングツール 外部からの死活監視 サービス AWS  (RDS,  ELB,  etc…) EC2 CloudWatch AWS  の各種リソースの監視 OS  やミドルウェア のリソース監視 内部の導通監視 傾向監視 mon
17. 1.  インストール、運⽤用が簡単 •  依存ライブラリ問題 •  ライブラリの競合 •  バージョンアップ問題 •  プラグイン動かなくなる •  構成変更更時のマスター設定 •  serf  とか使えばできるけれども •  ノード増えるとマスターの負荷があがる
18. Mackerel  なら •  1バイナリなので依存関係に悩まない •  マスターの管理理の必要がそもそもない $ ldd -r /usr/local/bin/mackerel-agent not a dynamic executable $ yum deplist mackerel-agent Loaded plugins: priorities, update-motd, upgrade-helper package: mackerel-agent.noarch 0.12.2-3 dependency: /bin/sh provider: bash.x86_64 4.1.2-15.17.amzn1 dependency: /sbin/chkconfig provider: chkconfig.x86_64 1.3.49.3-2.10.amzn1 dependency: /sbin/service provider: initscripts.x86_64 9.03.40-2.29.amzn1
19. 2.  サーバ⼊入れ替えにやさしい •  ホストベースのツールだと、⼊入れ替え前 後の傾向の変化を追いにくい •  ホスト名同じにするなどの⼯工夫 •  ⼊入れ替え台数が多くなると全体の傾向を 追うことそのものが難しい •  ⼼心の⽬目で変化の傾向をつかむ
20. Mackerel  なら •  ロールの重ね合わせで前後の傾向の変化は簡単に把握できる •  hostid  が異異なるので、仮に同じホスト名でもモニタリング の独⽴立立性は保てる
21. 3.  API  での操作が可能 •  エージェントしかデータを登録できない •  ログ集計結果などは⼀一度度ファイルに吐き出し てから再度度プラグインで読む •  構成変更更時にマスタの設定ファイルを変 更更しないといけない •  serf  とか使えばできるけれども
22. Mackerel  なら •  API  経由でエージェント以外からも簡単 にメトリクスを登録できる •  API  経由でホスト情報を変更更できるので、 変更更対象に注⽬目した処理理のみで完結する
23. 他の選択肢と⽐比較して •  少⼈人数で運⽤用している現状、問題を解決できても、 それが運⽤用のハードルをあげるものは選びにくい •  モニタリングそのものの運⽤用よりも、モニタリング を活⽤用して⾃自分たちのサービスの運⽤用をよりよくす ることが重要
24. 2.ヌーラボでの  Mackerel  の使い⽅方
25. JVM  のモニタリング •  ヒープの領領域、GC  カウント、GC  タイムなど •  カスタムメトリックで実現
26. JVMのモニタリング値の取得 •  jstat •  簡単、⼿手軽 •  バッチで⼀一気に値を取りにくい •  JMX •  ミドルウェアの値なども取れる •  起動オプションの設定が必要 •  取得側は基本  Java  で書く •  どっちも沢⼭山実⾏行行すると結構重い
27. jolokia http://www.jolokia.org/ •  JMX  のブリッジ •  プロトコルは  HTTP、フォーマットは  JSON
28. 設定と実⾏行行例例 -javaagent:/usr/java/jolokia/jolokia-jvm-1.2.0- agent.jar=discoveryEnabled=false $ curl -s -o - -X POST -d '{"type":"read","mbean":"java.lang:name=PS Scavenge,type=GarbageCollector","attribute":"CollectionCount"}' http://localhost:8778/jolokia/ | jq . { "value": 62143, "request": { "type": "read", "attribute": "CollectionCount", "mbean": "java.lang:name=PS Scavenge,type=GarbageCollector" }, "status": 200, "timestamp": 1411542268 }
29. プラグインでの実⾏行行 $ sudo ./jvm7_gccount_ps.py jvm7_gccount_ps.young 4 1411547309 jvm7_gccount_ps.old 0 1411547309 mackerel-‐‑‒ agent カスタム プラグイン mackerel.io 1.  プラグイン呼び出し  (/etc/mackerel-‐‑‒agent/mackerel-‐‑‒agent.conf  ) 2.  sensu  形式での出⼒力力 3.  API  経由でメトリクスを登録
30. ちゃんとピークもとれてます
31. ログのモニタリング •  nginx  のリクエストタイム、ステータスコードなど •  fluent-‐‑‒plugin-‐‑‒mackerel  で実現
32. fluent-‐‑‒plugin-‐‑‒mackerel •  Mackerel  へのメトリクス送信 •  Mackerel  の  hostid  を付与する処理理もあり〼 https://github.com/tksmd/fluent-‐‑‒plugin-‐‑‒mackerel fluentd fluentd-‐‑‒plugin-‐‑‒mackerel mackerel.io 1.  プラグイン呼び出し 2.  API  経由でメトリクスを登録
33. 設定例例 http://qiita.com/tksmd/items/1212331a5a18afe520df <match raw.nginx> type datacounter count_interval 1m count_key status input_tag_remove_prefix access tag nginx.status outcast_unmatched yes # patternX: X(1-20) pattern1 2xx ^2\d\d$ pattern2 3xx ^3\d\d$ pattern3 4xx ^4\d\d$ pattern4 5xx ^5\d\d$ </match> <match nginx.status> type mackerel api_key <あなたの API キー> hostid_path /var/lib/mackerel-agent/id metrics_name http_status.${out_key} out_keys nginx_2xx_count,nginx_3xx_count,nginx_4xx_count,nginx_5xx_count </match>
34. アラートの通知 •  Mackerel  でのアラートを  Typetalk  に通知 •  Webhook  と  Hubot  で実現
35. hubot-‐‑‒mackerel-‐‑‒notifier •  はてなさんオフィシャルの  hubot  スクリプト •  アラートの通知とホストの  URL  の取得をサポート https://github.com/mackerelio/hubot-‐‑‒mackerel-‐‑‒notifier
36. •  通知先の  room  をサービス毎に切切り替え if alert && host state = if alert.isOpen then "Open" else "Closed" role = host.roles[0] + service = role.fullname.split(/:/)[0] + switch service + when “Backlogtool”,“Backlog” then room = aaa + when "Cacoo" then room = bbb + when "Typetalk" then room = ccc + when “" then room = ddd + else room = eee msg = "[Mackerel] #{state} #{alert.status}: #{alert.monitorName} at #{host.name} (#{host.status}) #{role.fullname} #{alert.url}" robot.messageRoom room, msg
37. 3.  まとめ
38. Mackerel  に移⾏行行した３つの理理由 •  インストール、管理理が簡単 •  サーバ⼊入れ替えにやさしい •  API  での操作が可能
39. ヌーラボでのMackerelの使い⽅方 •  jolokia  による  JVM  の監視 •  fluentd-‐‑‒plugin-‐‑‒mackerel  によるログ監視 •  hubot  を使った  Typetalk  への通知  
40. 最後にもう⼀一つ ぶっちゃけていいますと…
41. はてなさんが⾃自社で使ってる というのが最⾼高の事例例
42. プロダクトとして良良くしたいと いうモチベーション
43. 何が起こると嫌なのかも よくわかってる
44. ご清聴 ありがとうございました ツイッター、やってます。 @nulabinc