新卒がZabbix3でサーバ監視を冗長化!?h2oにも移行した！

1. 新卒がZABBIX3でサーバ監視を
冗長化!?H2Oにも移行した！
ITI GROUP
INFRA SRE TEAM
HIKARU MIYAZAWA

2. ・３・
AGENDA
1. 自己紹介
2. ZABBIX3.0で監視を冗長化した経緯
3. H2Oを採用してよかったこと
4. ZABBIX×H2O
5. まとめ

3. ・３・
HIKARU MIYAZAWA
・2016/10∼2017/3
株式会社ITIのインターン、
インフラの業務を経験
・2017/4∼今まで
株式会社ITI入社 インフラSREチーム
趣味：ドラム、健康オタク、ゲーム、
好きなテキストエディタ：Sublime Text

4. ・３・
ZABBIX3.0で監視を冗長化した経緯
▸ 弊社監視サーバはzabbix2.2、自社で構築,運用
▸ 6月にさくらのメンテナンスが発表
▸ メンテナンス中は監視を継続できない
▸ この機会にせっかくなので2台体制で冗長化

7. ・３・
ZABBIX3.0
▸ 完全無料でオープンソースの
監視ソフトウェア
‣ LAMP環境＋zabbix-serverで動く
▸ 監視対象サーバには、
zabbix-agentをインストール
▸ 弊社の監視対象サーバ：200台∼

8. ・３・
好きに監視、通知！自由！
スクリーンで可視化
→リアルタイムで障害状況把握
Slackやチャットワークへの
通知設定も簡単

9. ・３・
GMO ConoHa の採用理由
▸ AWS側の障害の影響を受けない
▸ Zabbixのスペック要件を満たしつつ安い！(2GB,3コア,1700円/月)
▸ DiskはSSDで50GB ※追加Diskは高いです(毎月/2400円)

10. ・３・
OSとミドルウェア
▸ CentOS6.9(Final)
▸ Apache2.2.15
▸ MySQL5.7.19
▸ PHP7.0.18
▸ zabbix-server3.0.10-1
▸ (zabbix-agent3.0.10-1)

11. ZABBIXインストールは
簡単なので
割愛させていただきます！

12. ・３・
既存のZABBIX監視サーバの設定を新サーバにも反映
▸ ZABBIX別バージョン移行時の注意
▸ ・トリガーの条件式の変更
▸ ・不採用になったアイテム
▸ ・障害時アクションの設定がexport出来ない
▸ ・exportしたxmlファイルは書き換えが必要

13. そしてうまく
いったのか！？

14. ▸ さくらのメンテナンス前に冗長化完了
▸ 見えていた課題
▸ DBの定期的なバックアップ
▸ zabbixはDBが生きていれば容易に復旧できる。
・３・
祝！監視冗長化！！

15. ・３・
メンテナンス3日前の一コマ
▸
▸ 僕「定期的にDBをバックアップするシェル,書けました！」
▸
▸ あだちんさん「テストしてみた？
ちょっと確認してみよう」(カタカタ)

16. ▸ mysqldump -u user -x -p --all-databases
< mysqldump.sql
ん？

17. —all-databases
< mysqldump.sql
あ……

19. ・３・
お分かり頂けただろうか
▸ mysqldump -u user -x -p --all-databases < mysqldump.sql
▸ 空っぽをぶち込む
空っぽ
ZABBIXのDB

21. ・３・
本来はこれ
▸ mysqldump -u user -x -p --all-databases > mysqldump.sql
▸
空っぽ
ZABBIXのDB

22. 次の日、あだちんさんが
午前中で直しました。(早すぎ)
(自分は有給でしたww)

23. ・３・
スクリーンの作成
▸ 要望：障害時に監視データをグラフですぐに見たい！
▸ やります！任せて下さい！あれ？
▸ 弊社の監視対象ホストは200以上
▸ 1ホストにつき12個の監視項目
▸ 手動でポチポチする場合
▸ 200ホスト×12項目×4クリック＝9600…約一万回の作業…

24. ・３・
正直しんどい…

25. ・３・
効率よくやろう！

26. ・３・
ZABBIXの設定はIMPORT/EXPORTできる
Zabbixの設定（一部）
・グループ
・テンプレート
・ホスト
・ネットワークマップ
・イメージ
・スクリーン
XMLorJSON形式

27. ・３・
スクリーンこんな感じです

28. ・３・
スクリーンのXMLと実際のWEB上

29. ・３・
XMLファイルを自動生成するSHELLを作成

30. ここで問題
が！

31. ・３・
くっそ遅い
▸ リアルタイムで更新される120個のグラフの表示はやっぱり
重かった。

32. となるとNGINX
がいいのか？

33. ▸ 元DeNAの奥一穂氏が開発。
▸ HTTP/2に対応した爆速のWEBサーバーである
▸ あだちんさん推し(ゆるふわキャンパーさんも)
・３・
H2Oの採用

34. ・３・
HTTP/1.1のどこが悪いの？
‣ 「HTTPパイプライン」
→前回リクエストの完了を待たずに次のリクエストを送信することが可能
‣ 「サーバーはリクエストの順番通りにレスポンスを返さなければならない」
→結局順番待ちが発生し、
遅延していた。

35. ・３・
HTTP/2で何が変わるか
‣ 多重化
・同時に100以上のリクエストを発行可能
・タイミング、レスポンスの順序が関係ない
・複数並列処理
→HTTP/1.1での順番待ちがない
‣ ヘッダ圧縮(HTTP/2のヘッダは大きい300~500B)
例）100回リクエストが来ても、毎回300バイトの
ヘッダを送らなくて済む
→小さなリクエストを何回送っても遅くならない

36. ・３・
そんなHTTP/2を最大限に活かせるか
▸ 実はHTTP/2に対応したからといって、
サーバ側の設定がちゃんとしていないと
いいところを活かせない
▸例えば…

37. ・３・
優先度制御がすごい
▸ 優先度制御
WEBページを表示するのに必要なファイルをどの順番で優先的に読み込むかをきめ
ておく
①HTML②CSS③JS④画像⑤画像⑥画像
▸ クライアント側
→Firefoxは賢い
→Chromeはあるけど全然活かせていない
Safari,IE-Edge,その他のブラウザは優先度の概念すら無し。。
サーバ側でなんとかする。

38. ・３・
優先度制御がすごい
▸ 「http2-reprioritize-blocking-assets」
▸ CSSとJSを最優先でレスポンスを返す
▸ HTMLを返す（この時点で、WEBページのレンダリングが
開始できる）
▸ 画像を返す（並列処理なので順番を気にせず一気に送る）
▸ ※nginxでも頑張れば同じような設定が出来るらしい

39. ・３・
サーバプッシュ
▸ サーバプッシュ
▸ リクエストを先読みして必要なファイルを送る
例）HTMLのリクエスト受けたらCSSもまとめて送る
▸ キャッシュ有無を確認できるので、無駄に送ることはない

40. どうせ設定するの
めんどくさいん
じゃろ？

41. ・３・
なんとチューニングはデフォルトでON
▸ 普通に立ち上げた瞬間から爆速！
▸ チューニングにかけてた時間を他のタス
クに使える

42. ・３・
APACHE 設定ファイル

43. ・３・
H2O 設定ファイル
▸ h2o.conf

44. ・３・
▸ zabbix.conf

45. ・３・
負荷テスト
▸ AWS EC2インスタンスt2.micro
▸ Apache2.4(チューニングデフォルト)
▸ H2O2.2(チューニングデフォルト)
▸ 30万リクエスト、同時接続1000ユーザで検証。
▸ テストツールはGoad

46. ・３・
負荷テスト結果
▸ Apache
1分3.65秒でフリーズ
▸ H2O
約20秒で全リクエストを捌く

47. ・３・
負荷テスト結果
Apache-2.4 H2O-2.2
300,000Requests 300,000Requests
1,000user 1,000user
1m3.65s 20.0s

48. ・３・
負荷テスト結果
Apache-2.4 H2O-2.2
300,000Requests 300,000Requests
1,000user 1,000user
1m3.65s 20.0s
Freeze… Done!

49. 実際にH2Oの
すごさをお見せします

50. ・３・
H2O×HTTP/2のすごすぎる並列処理能力

51. ・３・
ZABBIX3.0×H2O×PHP7.0
▸ H2O
→並列処理で早い、最初からチューニングがされてる
可読性の高い設定ファイル
▸ PHP7.0も早い
▸ 弊社の担当サービスにも導入するきっかけになった。
▸ JoinsJob(ジョインズジョブ),ITプロジェクト名鑑,kiii(受託)

52. ・３・
まとめ
▸ 監視は自社で構築
→コスト大幅ダウン→しかし運用が大変
▸ 監視はAWS以外で冗長化するのがおすすめ
→AWS側のネットワーク障害が起きても困ることはない
▸ これからのWEBサーバはH2Oに変わっていきそう
▸ Prometheusに挑戦したい😁

53. ご清聴
ありがとうございま
した！