Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zabbix で Mastodon を監視する Sidekiq / Redis を中心に Mastodon 健康診断

1,986 views

Published on

2017年7月15日 オープンソースカンファレンス2017 Hokkaido セミナー資料
講師:鷲北 賢(さくらインターネット株式会社 さくらインターネット研究所 所長)
対象者:マストドンサーバー監視に興味のある方
前提知識:サーバー、ネットワークの監視に関する基礎的な知識

最近一部界隈でにわかに注目された分散型ミニブログソフトMastodon(マストドン)を監視する際のポイントについて、世界最大規模のインスタンスの一つ mstdn.jp での経験をもとに解説。

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Zabbix で Mastodon を監視する Sidekiq / Redis を中心に Mastodon 健康診断

  1. 1. ZabbixでMastodonを 監視する Sidekiq/Redisを中心にMastodon健康診断 2017/7/15 さくらインターネット株式会社 さくらインターネット研究所 鷲北 賢 (C) Copyright 1996-2017 SAKURA Internet Inc
  2. 2. 自己紹介 • 鷲北 賢(わしきた けん) • 1998年4月入社 • バックボーンのお守りからサービス開発まで ─ 初期の専用サーバ、データセンター構築 ─ オンラインゲームプロジェクト ─ CTO兼取締役、などなど • 2009年より、さくらインターネット研究所 所長 ─ 仮想化技術の研究(Linux KVM) ─ さくらのVPS開発ヘルプ • 2011年より、さくらのクラウド・プロデューサー兼務 • @ken_washikita@mstdn.jp • https://facebook.com/ken_washikita 2
  3. 3. さくらインターネットとは • インターネットインフラの提供を事業ドメインとし、 大阪、東京、北海道の3都市にデータセンターを展開 3 1996年12月に現社長の田中邦裕が、 舞鶴高専在学中に学内ベンチャーとして創業。 1999年8月に株式会社を設立。10月には、 第1号となるデータセンターを本町に開設。 2005年10月に東京証券取引所 マザーズ市場に上場。 2011年11月、北海道石狩市に国内最大級の 郊外型大規模データセンターを開設。 石狩データセンター開設2011 東証マザーズ上場2005 さくらインターネット創業1996 ・最初のデータセンター開設 1999 ・株式会社を設立 2015年11月に東京証券取引市場第一部に 市場変更。 東証一部に市場変更2015 会社概要 商 号 さくらインターネット 本 社 所 在 地 大阪市北区大深町4丁目20番 設 立 年 月 日 1999年8月17日 (サービス開始は1996年12月23日) 上 場 年 月 日 2005年10月12日(マザーズ) 2015年11月27日(東証一部へ市場変更) 資 本 金 22億5,692万円 従 業 員 数 連結495名 (2017年3月末)
  4. 4. 石狩データセンター 4 東京ドーム約1個分の敷地面積(51,448㎡) 札幌から車で20~30分とアクセスも容易
  5. 5. 石狩データセンター 5 最終完成イメージ 計5棟、最大6,800ラック規模
  6. 6. さくらインターネットのサービス 6
  7. 7. マストドンとは? 7
  8. 8. Mastodon • Twitterライクな分散型SNS ─ 誰もが自由に作れるインスタンス ─ インスタンス内だけでなく、外部ユーザ をフォローできる(リモートフォロー) ─ リモートフォローにより「連合」が形成 ─ リモートTL、連合TLが形成される • 日本でのブーム ─ 4月10日のASCII総研の記事をきっかけ にブームが発生 ─ 世界最大級のインスタンスが国内に乱立 する事態に(mstdn.jp、Pawoo、 friends.nico) ─ 全世界ユーザの半数が日本人という状況 8
  9. 9. インスタンス分布の分析(mastodon.xyzによる) 9
  10. 10. インスタンス分布の分析(Shodanによる) 10
  11. 11. さくらインターネットの取り組み • mstdn.jpへの支援 ─ 話題となったMastodonインスタンスを支援することで結果 的に当社のMastodon関連の取り組みが注目された • スタートアップスクリプトの提供 ─ 難しいMastodonのインストールを「さくらのクラウド」か らクリック1つでインストールできる「スタートアップスク リプト」の提供を開始した • 当社エンジニアによるインストール手順等の情報発信 ─ 当社のオウンド・メディアや外部サービスを使って、 Mastodonのインストール記事を発信し認知を広めた 11
  12. 12. 2017年4月14日 12
  13. 13. 社内Slackより… isidai 10:06 @m-yokota mstdn.jp やってる nullkalさん、相互フォローで 知り合いだったので、無償化されている僕のさく らのクラウドアカウントをユーザー切り出して貸 し出しました。 負荷が落ち着いた頃に自宅サーバに戻るなりVPS に行ってもらうなりしようと思っていますが、そ れまではクラウドに預かってもらって宜しいで しょうか。 m-yokota 10:08 @isidai はい、ぜひぜひ! 13
  14. 14. 社内Slackより… isidai 10:06 @m-yokota mstdn.jp やってる nullkalさん、相互フォローで 知り合いだったので、無償化されている僕のさく らのクラウドアカウントをユーザー切り出して貸 し出しました。 負荷が落ち着いた頃に自宅サーバに戻るなりVPS に行ってもらうなりしようと思っていますが、そ れまではクラウドに預かってもらって宜しいで しょうか。 m-yokota 10:08 @isidai はい、ぜひぜひ! 14 わずか2分で支援決定
  15. 15. 動きが速かった理由 • スタートアップを支援するのはさくらの文化 ─ スタートアップ支援は制度化されている ─ 過去にもmixi、GREE、メルカリを支援 ─ 学生や学校等にもインフラ支援などを実施 • このあたりの詳しいお話は 「自宅サーバーからさくらのクラウドへ! mstdn.jpとの2週間をさくらの2人に聞く」 という記事をご覧ください http://asci.jp/elem/000/001/477/1477028/ 15
  16. 16. 2017年4月18日 16
  17. 17. Mastodonスタートアップスクリプト リリース • Mastodonのスタートアップスクリプトが完成 ─ スタートアップスクリプトとは?  サーバの作成と同時に実行されるスクリプト  プレ・インストールなどの作業を実施できる  WordPressサーバのワンボタン作成などが人気 • Mastodonスタートアップスクリプトの特長 ─ 新規ドメインを取得すれば、残りの作業は全自動 (起動までは15分~30分) ─ サーバ作成、メール設定、DNS設定、Let’s Encrypt設定 ─ Mastodonインストールまでが全自動 • リリースしたらアクセス殺到 ─ 公開したら20分でサーバがダウン ─ あわててスケールアップして対応 17
  18. 18. 18
  19. 19. 当社エンジニアから情報発信が増えてきた • 自主的に情報発信を行うエンジニアが出てきた ─ Dockerで雑にMastodonを起動する方法 http://qiita.com/zembutsu/items/fd52a504321dd5d6f0b8 エヴァンジェリスト ─ さくらのVPSで自分のMastodonサーバを最速でつくる方法 http://qiita.com/hekki/items/c3f42c31632105389c79 VPSチームのプログラミング担当プロデューサー ─ さくらのVPSでmastodonをセットアップするAnsibleプレイブック https://github.com/hnakamur/mastodon-ansible-playbook Webアクセラレーターチーム担当プログラマ • 社長がブログ書いた ─ マストドンと北朝鮮危機にみるインターネットの本質的価値 http://tanaka.sakura.ad.jp/2017/04/mastodon-north-korea-internet.html 19
  20. 20. そろそろ 本題に いきましょう 20
  21. 21. 監視の基本 21
  22. 22. Mastodonをどう運用するか? • 監視・運用ってどういうこと? ─ サーバやアプリケーションの動作を監視し、異常を検知し たらなるべく早く対処したい ─ たとえば、エラーが発生したらすぐに対応したい ─ でも、一日中ブラウザとにらめっこしているわけにはいか ない ─ ツールを使って自動化しよう 22 • 見える化ってどういうこと? ─ 異常と正常を区別するのは、 実に難しい ─ データを集め、エラーを体験 し、そのときの状況から「こ ういうときは異常なんだな」 という知見を集める ─ そのために「見える化」が必 要
  23. 23. サーバの監視 • サーバが動いているか?(基本メトリック) ─ アクセス監視(ping) ─ ポート監視(HTTPS、SSH) • ハードウェアの状態は?(基本メトリック) ─ OS監視(CPU負荷、メモリ使用量、ディスク空き容量) ─ ネットワーク監視(トラフィック量、レイテンシ) • アプリケーションの状態は? ─ ページ監視  about/moreをチェックし、ユーザ数/toot数/接続インスタンス 数を見る  ログインやホーム画面、TLを見てみる  APIリクエストを投げて応答を確認する • ミドルウェアの状態は? ─ 構成要素のメトリックを採取、分析する 23
  24. 24. Zabbix • オープンソースの監視ツール • 利点 ─ 使いやすい(慣れている) ─ 監視→条件による発報→通知のフローが作りやすい  標準テンプレートにより多くのメトリックが監視可能  自作テンプレートも比較的簡単に作れる ─ 条件を設定し、発報(通知)をプログラムできる ─ 異常検知を通知するほか、障害対応自動化も可能 • 欠点 ─ グラフデザインは好みが分かれる ─ データストアが非効率(処理が重い) ─ 過去データを溜め込むのに向いていない 24
  25. 25. ダッシュボードの例 25
  26. 26. グラフの例 26
  27. 27. 基本メトリックの例 27
  28. 28. ミドルウェアの監視 28
  29. 29. Mastodonの内部構成図 29 Pixiv Night #04 大規模Mastodonインスタンスを運用するコツ / Inside Pawoo Mastodon infrastructure by Harukasan (https://speakerdeck.com/harukasan/inside-pawoo-mastodon-infrastructure) より抜粋
  30. 30. Mastodonの内部構成図 30 Pixiv Night #04 大規模Mastodonインスタンスを運用するコツ / Inside Pawoo Mastodon infrastructure by Harukasan (https://speakerdeck.com/harukasan/inside-pawoo-mastodon-infrastructure) より抜粋
  31. 31. 監視対象ミドルウェア • nginx ー Webサーバ ─ これが止まるとアクセスができなくなる • PostgreSQL ― データベースサーバ ─ すべてのデータが詰まっている ─ 負荷が集中しやすい場所だが、Mastodonでは実はそれほど でもない • Sidekiq ― メッセージハンドラ ─ 多数のメッセージを整理し、処理するためのミドルウェア ─ tootを交換するMastodonの仕組みの要(かなめ) ─ データベースよりも負荷が集中する場所 ─ RedisはSidekiqを利用する際に必要になるミドルウェア 31
  32. 32. Sidekiq 「大規模Mastodonインスタンスを運用するコツ」より引用: • MastodonのメッセージパッシングはSidekiqで行われる ─ トゥートの配信 ─ ストリーミング ─ リモートインスタンスへの配信 • 1トゥートごとにフォロワーの数だけenqueueされる • フォロワーが多いユーザーだとやばい • そうかやばいのか… 32
  33. 33. じゃあ Sidekiqを重監視だ! 33
  34. 34. Sidekiq: Processed/Failed [job/sec] 34
  35. 35. Sidekiq: Processed/Failed [job/sec] 35 • Processed ─ Sidekiqが処理したメッセージ数を毎秒に換算して表示 • Failed ─ Sidekiqが処理中に失敗したメッセージ数を毎秒にして表示
  36. 36. Redis: Commands Processed [cps] & Latency [msec] 36
  37. 37. Redis: Commands Processed [cps] & Latency [msec] 37 • Commands Processed ─ Redisが処理したコマンド数を毎秒に換算して表示 ─ Sidekiqメッセージ数に比例する(一致はしない) • Latency ─ Redisが処理に要した時間をサンプリングして計測 ─ busy具合の指標として計測 ─ 個人的には、偏差が大きく参考にならないと悩み中
  38. 38. Sidekiq: Latency/Queues 38
  39. 39. Sidekiq: Latency/Queues 39 • Sidekiq Latency ─ Sidekiq処理のレイテンシ ─ 理想的には常にゼロであってほしい数字 • Sidekiq Queues ─ 処理中のメッセージ数 ─ これもできるだけ少ないのが理想 ─ これが増えているときは、たいてい何かおかしなことが起 こっている
  40. 40. 可視化された異常の例(1-1) 40
  41. 41. 可視化された異常の例(1-2) 41 • Sidekiq Queue(Push)が詰まった ─ 原因ははっきりしない ─ リモートインスタンスの都合かもしれないし ─ こちら側の問題かもしれない • 一時的にFailedカウントも上昇 ─ グラフにはっきり現れている • しかしサービスに与えた影響はどうか? ─ 特に不具合があったとは考えにくい ─ 短時間で収束している ─ あったとしても、主にリモート側における問題
  42. 42. 可視化された異常の例(2-1) 42
  43. 43. 可視化された異常の例(2-2) 43
  44. 44. 今後取り組みたいテーマ • メトリックの動きから、異常を検知するロジックを組 み立てる ─ ZabbixのTrigger機能を用いて、検知機能をプログラムする • 異常を検知したら、通知する ─ メールやSlackメッセージで警告を飛ばすようにする ─ これまで気づけなかった異常に、すばやく対応できるよう になる ─ これまで一人で運用していた部分を、みんなで分担できる ようになる • 決まりきったワークフローをプログラム化する ─ 「このエラーのときは××をリブートする」といった処理な らスクリプト化できる ─ こうして障害処理を自動化し、手放し運転できるようにし ていく 44
  45. 45. Zabbix Template公開しました • zbx-templates-mstdn ─ https://github.com/ken-washikita/zbx-templates-mstdn • まだTrigger等は入っていません • ご質問はご遠慮なくどうぞ @ken_washikita@mstdn.jp 45
  46. 46. 最後に 46
  47. 47. ○○人のインスタンスの運営には、どれぐらいのスペックが必要? • よくいただくご質問です ─ が、実はよく分かりません • ユーザ数は、サーバ負荷にあまり影響を与えません ─ CPU負荷は主にtoot数によって決まります  tootが多くなるほど、メッセージ数が増え、CPUとトラフィックに 高い負荷がかかります  少ない人数でも短いメッセージを大量にやり取りするケースでは高 負荷・大量トラフィックになりがちです ─ ディスク容量はリモートフォローにも左右されます  デフォルトでは、リモートユーザが持っているメディアファイルも コピーしてしまいます  相手がメディアファイルを大量に持っていると、ディスクを消費し、 大量トラフィックに繋がります 47
  48. 48. 1core/1GB/20GBディスクで始める場合 • ドメインブロック機能 ─ 1万人以上のメジャーイ ンスタンスはメディア ファイル拒否にしておく ─ ディスクを節約できて断 然オトク • 500人ぐらいまでならこ のスペックでなんとかい けると思います 48 • 1000人になるとつらいかも… • 足りなくなったらスケールアップ!(←重要)
  49. 49. おしまい 49

×