2017年7月15日 オープンソースカンファレンス2017 Hokkaido セミナー資料 講師：鷲北 賢（さくらインターネット株式会社 さくらインターネット研究所 所長） 対象者：マストドンサーバー監視に興味のある方 前提知識：サーバー、ネットワークの監視に関する基礎的な知識 最近一部界隈でにわかに注目された分散型ミニブログソフトMastodon(マストドン)を監視する際のポイントについて、世界最大規模のインスタンスの一つ mstdn.jp での経験をもとに解説。

1. ZabbixでMastodonを
監視する
Sidekiq/Redisを中心にMastodon健康診断
2017/7/15 さくらインターネット株式会社 さくらインターネット研究所 鷲北 賢
(C) Copyright 1996-2017 SAKURA Internet Inc

2. 自己紹介
• 鷲北 賢（わしきた けん）
• 1998年4月入社
• バックボーンのお守りからサービス開発まで
─ 初期の専用サーバ、データセンター構築
─ オンラインゲームプロジェクト
─ CTO兼取締役、などなど
• 2009年より、さくらインターネット研究所 所長
─ 仮想化技術の研究（Linux KVM）
─ さくらのVPS開発ヘルプ
• 2011年より、さくらのクラウド・プロデューサー兼務
• @ken_washikita@mstdn.jp
• https://facebook.com/ken_washikita
2

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
東京ドーム約1個分の敷地面積（51,448㎡）
札幌から車で20～30分とアクセスも容易

5. 石狩データセンター
5
最終完成イメージ
計5棟、最大6,800ラック規模

6. さくらインターネットのサービス
6

7. マストドンとは？
7

8. Mastodon
• Twitterライクな分散型SNS
─ 誰もが自由に作れるインスタンス
─ インスタンス内だけでなく、外部ユーザ
をフォローできる（リモートフォロー）
─ リモートフォローにより「連合」が形成
─ リモートTL、連合TLが形成される
• 日本でのブーム
─ 4月10日のASCII総研の記事をきっかけ
にブームが発生
─ 世界最大級のインスタンスが国内に乱立
する事態に（mstdn.jp、Pawoo、
friends.nico）
─ 全世界ユーザの半数が日本人という状況
8

9. インスタンス分布の分析（mastodon.xyzによる）
9

10. インスタンス分布の分析（Shodanによる）
10

11. さくらインターネットの取り組み
• mstdn.jpへの支援
─ 話題となったMastodonインスタンスを支援することで結果
的に当社のMastodon関連の取り組みが注目された
• スタートアップスクリプトの提供
─ 難しいMastodonのインストールを「さくらのクラウド」か
らクリック1つでインストールできる「スタートアップスク
リプト」の提供を開始した
• 当社エンジニアによるインストール手順等の情報発信
─ 当社のオウンド・メディアや外部サービスを使って、
Mastodonのインストール記事を発信し認知を広めた
11

12. 2017年4月14日
12

13. 社内Slackより…
isidai 10:06
@m-yokota
mstdn.jp やってる nullkalさん、相互フォローで
知り合いだったので、無償化されている僕のさく
らのクラウドアカウントをユーザー切り出して貸
し出しました。
負荷が落ち着いた頃に自宅サーバに戻るなりVPS
に行ってもらうなりしようと思っていますが、そ
れまではクラウドに預かってもらって宜しいで
しょうか。
m-yokota 10:08
@isidai はい、ぜひぜひ！
13

14. 社内Slackより…
isidai 10:06
@m-yokota
mstdn.jp やってる nullkalさん、相互フォローで
知り合いだったので、無償化されている僕のさく
らのクラウドアカウントをユーザー切り出して貸
し出しました。
負荷が落ち着いた頃に自宅サーバに戻るなりVPS
に行ってもらうなりしようと思っていますが、そ
れまではクラウドに預かってもらって宜しいで
しょうか。
m-yokota 10:08
@isidai はい、ぜひぜひ！
14
わずか2分で支援決定

15. 動きが速かった理由
• スタートアップを支援するのはさくらの文化
─ スタートアップ支援は制度化されている
─ 過去にもmixi、GREE、メルカリを支援
─ 学生や学校等にもインフラ支援などを実施
• このあたりの詳しいお話は
「自宅サーバーからさくらのクラウドへ！
mstdn.jpとの2週間をさくらの2人に聞く」
という記事をご覧ください
http://asci.jp/elem/000/001/477/1477028/
15

16. 2017年4月18日
16

17. Mastodonスタートアップスクリプト リリース
• Mastodonのスタートアップスクリプトが完成
─ スタートアップスクリプトとは？
 サーバの作成と同時に実行されるスクリプト
 プレ・インストールなどの作業を実施できる
 WordPressサーバのワンボタン作成などが人気
• Mastodonスタートアップスクリプトの特長
─ 新規ドメインを取得すれば、残りの作業は全自動
（起動までは15分～30分）
─ サーバ作成、メール設定、DNS設定、Let’s Encrypt設定
─ Mastodonインストールまでが全自動
• リリースしたらアクセス殺到
─ 公開したら20分でサーバがダウン
─ あわててスケールアップして対応
17

18. 18

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

21. 監視の基本
21

22. Mastodonをどう運用するか？
• 監視・運用ってどういうこと？
─ サーバやアプリケーションの動作を監視し、異常を検知し
たらなるべく早く対処したい
─ たとえば、エラーが発生したらすぐに対応したい
─ でも、一日中ブラウザとにらめっこしているわけにはいか
ない
─ ツールを使って自動化しよう
22
• 見える化ってどういうこと？
─ 異常と正常を区別するのは、
実に難しい
─ データを集め、エラーを体験
し、そのときの状況から「こ
ういうときは異常なんだな」
という知見を集める
─ そのために「見える化」が必
要

23. サーバの監視
• サーバが動いているか？（基本メトリック）
─ アクセス監視（ping）
─ ポート監視（HTTPS、SSH）
• ハードウェアの状態は？（基本メトリック）
─ OS監視（CPU負荷、メモリ使用量、ディスク空き容量）
─ ネットワーク監視（トラフィック量、レイテンシ）
• アプリケーションの状態は？
─ ページ監視
 about/moreをチェックし、ユーザ数／toot数／接続インスタンス
数を見る
 ログインやホーム画面、TLを見てみる
 APIリクエストを投げて応答を確認する
• ミドルウェアの状態は？
─ 構成要素のメトリックを採取、分析する
23

24. Zabbix
• オープンソースの監視ツール
• 利点
─ 使いやすい（慣れている）
─ 監視→条件による発報→通知のフローが作りやすい
 標準テンプレートにより多くのメトリックが監視可能
 自作テンプレートも比較的簡単に作れる
─ 条件を設定し、発報（通知）をプログラムできる
─ 異常検知を通知するほか、障害対応自動化も可能
• 欠点
─ グラフデザインは好みが分かれる
─ データストアが非効率（処理が重い）
─ 過去データを溜め込むのに向いていない
24

25. ダッシュボードの例
25

26. グラフの例
26

27. 基本メトリックの例
27

28. ミドルウェアの監視
28

29. Mastodonの内部構成図
29
Pixiv Night #04
大規模Mastodonインスタンスを運用するコツ / Inside Pawoo Mastodon infrastructure by Harukasan
（https://speakerdeck.com/harukasan/inside-pawoo-mastodon-infrastructure） より抜粋

30. Mastodonの内部構成図
30
Pixiv Night #04
大規模Mastodonインスタンスを運用するコツ / Inside Pawoo Mastodon infrastructure by Harukasan
（https://speakerdeck.com/harukasan/inside-pawoo-mastodon-infrastructure） より抜粋

31. 監視対象ミドルウェア
• nginx ー Webサーバ
─ これが止まるとアクセスができなくなる
• PostgreSQL ― データベースサーバ
─ すべてのデータが詰まっている
─ 負荷が集中しやすい場所だが、Mastodonでは実はそれほど
でもない
• Sidekiq ― メッセージハンドラ
─ 多数のメッセージを整理し、処理するためのミドルウェア
─ tootを交換するMastodonの仕組みの要（かなめ）
─ データベースよりも負荷が集中する場所
─ RedisはSidekiqを利用する際に必要になるミドルウェア
31

32. Sidekiq
「大規模Mastodonインスタンスを運用するコツ」より引用：
• MastodonのメッセージパッシングはSidekiqで行われる
─ トゥートの配信
─ ストリーミング
─ リモートインスタンスへの配信
• １トゥートごとにフォロワーの数だけenqueueされる
• フォロワーが多いユーザーだとやばい
• そうかやばいのか…
32

33. じゃあ
Sidekiqを重監視だ！
33

34. Sidekiq: Processed/Failed [job/sec]
34

35. Sidekiq: Processed/Failed [job/sec]
35
• Processed
─ Sidekiqが処理したメッセージ数を毎秒に換算して表示
• Failed
─ Sidekiqが処理中に失敗したメッセージ数を毎秒にして表示

36. Redis: Commands Processed [cps] & Latency [msec]
36

37. Redis: Commands Processed [cps] & Latency [msec]
37
• Commands Processed
─ Redisが処理したコマンド数を毎秒に換算して表示
─ Sidekiqメッセージ数に比例する（一致はしない）
• Latency
─ Redisが処理に要した時間をサンプリングして計測
─ busy具合の指標として計測
─ 個人的には、偏差が大きく参考にならないと悩み中

38. Sidekiq: Latency/Queues
38

39. Sidekiq: Latency/Queues
39
• Sidekiq Latency
─ Sidekiq処理のレイテンシ
─ 理想的には常にゼロであってほしい数字
• Sidekiq Queues
─ 処理中のメッセージ数
─ これもできるだけ少ないのが理想
─ これが増えているときは、たいてい何かおかしなことが起
こっている

40. 可視化された異常の例（１－１）
40

41. 可視化された異常の例（１－２）
41
• Sidekiq Queue（Push）が詰まった
─ 原因ははっきりしない
─ リモートインスタンスの都合かもしれないし
─ こちら側の問題かもしれない
• 一時的にFailedカウントも上昇
─ グラフにはっきり現れている
• しかしサービスに与えた影響はどうか？
─ 特に不具合があったとは考えにくい
─ 短時間で収束している
─ あったとしても、主にリモート側における問題

42. 可視化された異常の例（２－１）
42

43. 可視化された異常の例（２－２）
43

44. 今後取り組みたいテーマ
• メトリックの動きから、異常を検知するロジックを組
み立てる
─ ZabbixのTrigger機能を用いて、検知機能をプログラムする
• 異常を検知したら、通知する
─ メールやSlackメッセージで警告を飛ばすようにする
─ これまで気づけなかった異常に、すばやく対応できるよう
になる
─ これまで一人で運用していた部分を、みんなで分担できる
ようになる
• 決まりきったワークフローをプログラム化する
─ 「このエラーのときは××をリブートする」といった処理な
らスクリプト化できる
─ こうして障害処理を自動化し、手放し運転できるようにし
ていく
44

45. Zabbix Template公開しました
• zbx-templates-mstdn
─ https://github.com/ken-washikita/zbx-templates-mstdn
• まだTrigger等は入っていません
• ご質問はご遠慮なくどうぞ
@ken_washikita@mstdn.jp
45

46. 最後に
46

47. ○○人のインスタンスの運営には、どれぐらいのスペックが必要？
• よくいただくご質問です
─ が、実はよく分かりません
• ユーザ数は、サーバ負荷にあまり影響を与えません
─ CPU負荷は主にtoot数によって決まります
 tootが多くなるほど、メッセージ数が増え、CPUとトラフィックに
高い負荷がかかります
 少ない人数でも短いメッセージを大量にやり取りするケースでは高
負荷・大量トラフィックになりがちです
─ ディスク容量はリモートフォローにも左右されます
 デフォルトでは、リモートユーザが持っているメディアファイルも
コピーしてしまいます
 相手がメディアファイルを大量に持っていると、ディスクを消費し、
大量トラフィックに繋がります
47

48. 1core/1GB/20GBディスクで始める場合
• ドメインブロック機能
─ 1万人以上のメジャーイ
ンスタンスはメディア
ファイル拒否にしておく
─ ディスクを節約できて断
然オトク
• 500人ぐらいまでならこ
のスペックでなんとかい
けると思います
48
• 1000人になるとつらいかも…
• 足りなくなったらスケールアップ！（←重要）

49. おしまい
49