成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

Copyright © VOYAGE GROUP, Inc. All Rights Reserved.
#srenextC
成長を続ける広告配信プラットフォームの
モニタリングを改善してきた話
株式会社 VOYAGE GROUP
fluct SRE
みっさん

View Slide

#srenextC
自己紹介（みっさんです）
株式会社 VOYAGE GROUP 2016 年入社
fluct の SRE (当初はインフラ本部) に所属
好きなこと: 地道な作業
好きなキャラクター: リラックマ

View Slide

#srenextC
今日話したいこと
- やりがちな監視の話
- アラートの話
- モニタリングツールを選んだ時の話

View Slide

#srenextC
やりがちな監視の話

View Slide

#srenextC
こういう経験はありませんか？

View Slide

#srenextC
2016年の監視
ここに広告を出す
システムがあってじゃな
低レイテンシと安定性を生むアーキテクチャ - SSPの現場に学ぶ、高可用性のつくり方: https://employment.en-japan.com/engineerhub/entry/2019/07/12/103000

View Slide

#srenextC
2016年の監視
ここを監視して...

View Slide

#srenextC
2016年の監視
ヨシ！

View Slide

#srenextC
2016年の監視
アッ！

View Slide

#srenextC
2016年の監視
アッ！ ※ 実際にはサーバは爆発していません

View Slide

#srenextC
2016年の監視
広告は出てるぞ！？

View Slide

#srenextC
やばそうだけど大丈夫そう...！汗

View Slide

#srenextC
というような
経験をしたことがある方は
いませんか！

View Slide

#srenextC
CPU 使用率 100%
まぁ大丈夫（広告出てる）
やばい（広告出てない）
⇨
⇨
急いで調査
急いで調査
⇨
もっと急いで対応
⇨
ゆっくりでいい

View Slide

#srenextC
大丈夫かどうかすぐに分からない

View Slide

#srenextC
fluct ではどうやって
すぐに大丈夫かを判断しているのか？

View Slide

#srenextC
fluct における大丈夫かの判断基準
広告が見えているかどうか

View Slide

#srenextC
なんで？

View Slide

#srenextC
神ゲー攻略 https://kamigame.jp/

View Slide

#srenextC
1
Bid Request

View Slide

#srenextC
2
1
※RTB と呼ばれる仕組み
Bid Request

View Slide

#srenextC
2
3
1
Bid Request

View Slide

#srenextC
2
3
1
4
Bid Request

View Slide

#srenextC
2
3
1
4
Bid Request
月間 300億
インプレッション
4

View Slide

#srenextC
複数のメディアのPVと
同じ数のリクエストを
受けているようなもの
月間 300億
インプレッション
2
3
1
4
4 1
Bid Request

View Slide

#srenextC
fluct が大事にしていること
広告が見えるというのが大事！
fluct のサービスが正常である証

View Slide

#srenextC
CPU 使用率 100%
⇨
⇨
急いで調査
急いで調査
⇨
もっと急いで対応
⇨
ゆっくりでいい

View Slide

#srenextC
CPU 使用率 100%
⇨
⇨
急いで対応
急ぎじゃない
高レベル（あらゆる要素を含んでいる）低レベル（何か１つだけ）
緊急度: 高緊急度: 高かも？

View Slide

#srenextC
広告が見えない時（大きく分けて2つ）
システムの都合
広告提供元の都合

View Slide

#srenextC
広告が見えない時（大きく分けて2つ）
システムの都合
広告提供元の都合
これらの都合を防げるなら防ぎたい
そうはいかない時もあるので
少なくとも気づけるようにしたい！

View Slide

#srenextC
2020年の監視
もっと外側を
重点的に！

View Slide

#srenextC
押さえておきたいこと（その1）
監視は外側（高レベルなもの）から

View Slide

#srenextC
しかし、fluct では外側の監視を足しても
決して良いと言える状況ではなかった！

View Slide

#srenextC
アラートの話

View Slide

#srenextC
アラート通知が...
- Alert -> OK -> Alert -> OK ... を繰り返す
- 毎日同じタイミングに Alert が来て、その後 OK になる
- これは大丈夫なやつなのでといってスルーされる

View Slide

#srenextC
アラート通知が...
- Alert -> OK -> Alert -> OK ... を繰り返す
- 閾値を見直しましょう
- 毎日同じタイミングに Alert が来て、その後 OK になる
- 定期的なのは問題あり
- これは大丈夫なやつなのでといってスルーされる
- 大丈夫ならアラートじゃないよね！（整理しましょう）

View Slide

#srenextC
ちなみに fluct では（通知先）
- Slack にはいくつかチャンネルがある
- #fluct_alert
- 直ちに対応すべきもののみ通知
- #fluct_alert_ops
- インフラ向けの通知
- #fluct_syslog
- 動作の記録的な感じ（チャンネル名の通り）

View Slide

#srenextC
その他、アラート通知を整理して得られたもの

View Slide

#srenextC
その他、アラート通知を整理して得られたもの
SRE以外のメンバーもアラートを気にするようになった

View Slide

#srenextC
アラートは整理しましょう
整理と言ってもここらへんのニュアンス
（洗練、育てる、面倒を見る、さらに強く、充実、いい感じ）

View Slide

#srenextC
整理と言っても
- なかなか定期的にやれない
- 前やったけれど忘れたから、またやり直し
- めんどくさい
- つらい
- 寝たい
- などなど...

View Slide

#srenextC
いつやるの？

View Slide

#srenextC
いつやるの？
- fluct では
- 障害が起きた時
- 人は主にこの時に動く
- 監視システムを置き換えた時
- 新しい仲間が増えた時

View Slide

#srenextC
いつやるの？
- fluct では
- 障害が起きた時
- 人は主にこの時に動く
- 監視システムを置き換えた時
- 新しい仲間が増えた時
チャンス！

View Slide

#srenextC
次はツールを見直したいと思った

View Slide

#srenextC
モニタリングツール選んだ時の話

View Slide

#srenextC
なんで見直すの？
- ツールは入れ替えていくもの
- 古いとメンテナンスされなくなることもある
- サービスや規模に合わない
- 新しいものが好き
ツールが悪いとかの話ではない

View Slide

#srenextC
2016年入社した時点で監視はすでにあった
オンプレと AWS のハイブリッド構成だが
今回はオン
プレの監視について

View Slide

#srenextC
Agent Master
※ Master, Agent 構成のものには
枠
線をつけています
外形監視
+
Latency
ping
push(interval: 5m)
pull(interval: 5m)
サーバメトリクス
保存
アラート通知
2016年の監視

View Slide

#srenextC
PandoraFMS
Demo online Pandora FMS Community http://pandorafms.org/online-demo/

View Slide

#srenextC
用途や特徴（PandoraFMS）
- PandoraFMS
- ホストの自動追加（削除はなかった）
- 保存先の MySQL が辛い
- 複数ホストをまとめてグラフで見れない
- 5分おきに収集していた

View Slide

#srenextC
SmokePing
SmokePing Latency Page for Octopus https://oss.oetiker.ch/smokeping-demo/?target=Customers.OP.octopus

View Slide

#srenextC
用途や特徴（SmokePing）
- SmokePing
- Latency 計測
- 外形監視（ただし、定期的に人が見るという運用）

View Slide

#srenextC
Munin

View Slide

#srenextC
用途や特徴（Munin）
- Munin
- 一覧で見れる（PandoraFMS で出来ないので）
- RRD から画像を定期的に生成しているので表示が速い

View Slide

#srenextC
2016年の監視の用途や特徴
- SmokePing
- Latency 計測
- 外形監視（ただし、定期的に人が見るという運用）
- PandoraFMS
- ホストの自動追加（削除はなかった）
- 保存先の MySQL が辛い
- 複数ホストをまとめてグラフで見れない
- 5分おきに収集
- Munin
- 一覧で見れる（PandoraFMS で出来ないので）
- RRD から画像を定期的に生成しているので表示が速い

View Slide

#srenextC
実は入社前に
サーバが倍以上に増えていた

View Slide

#srenextC
やりたいことは
もっと解像度を上げて
ナイスなダッシュボードが欲しい

View Slide

#srenextC
良くしたいと思ったこと
- 解像度
- 5分単位を最低1分単位に
- フラッピングとかは見えづらい
- 昔は負荷を気にしていたけれど、今は割とリソースが潤沢
- ナイスなダッシュボード
- 見やすい調査しやすい
- 重ねて見れる
- 1年の範囲で見てもあまり重くない

View Slide

#srenextC
モニタリングシステム（ツール）の変遷
設立: 2008年入社: 2016年4月 2016年10月 2017年12月 2019年今
圧倒的な歴史
#srenextC
サーバメトリクス
外形監視

View Slide

#srenextC
ツールは総合的に判断(一通り触ってみる)
- 判断基準
- お金
- Pull, Push
- メトリクスコレクタとデータベース
- ダッシュボード
- アラート通知

View Slide

#srenextC
お金
SaaS? OSS?

View Slide

#srenextC
お金
SaaS? OSS?
- 試算してみて問題なさそうなら、SaaS がおすすめ！
- 人件費やその他費用（通信費等）も考慮する

View Slide

#srenextC
Pull & Push
Pull Push
- バッファの観点から Push 型を採用した
- 調査や傾向のためにできるだけ取りたい
Agent によっては
バッファがある
Pull 型 Push 型
DataBase
Agent
Agent
DataBase, Server

View Slide

#srenextC
メトリクスコレクタとデータベース
- 候補（これはトレンドから）
- Database
- Prometheus (Pull 型向け)
- InfluxDB (Push 型向け)
- Collector
- Node exporter (Pull型向け)
- Telegraf

View Slide

#srenextC
データベース
- メトリクスの保存は TSDB (Time Series Data Base) が良い
- 用途として最適
- 決め手は扱える型だった
- InfluxDB の特徴
- 文字列を扱える、Schemaless
- アクセスログやアプリケーションログの監視・調査を見据えて
- Retention Policy
- データの保持期間を指定できる
- Continuous Query
- 継続的にクエリを実行して結果をテーブルに保存できる

View Slide

#srenextC
メトリクスコレクタ
- InfluxDB と親和性の高い Telegraf を選択
- Buffer を持っている
- Input, Output の概念がわかりやすい
- Input, Output の Plugin の数が豊富
- Input 170 種類以上
- Output 30 種類以上
- Binary 置けば動く（セットアップしやすい）
- rpm や deb もある
Input Output
どこから何を取るかどこに何を投げるか

View Slide

#srenextC
ダッシュボード & アラート
- まずは公式のオススメを見る
- Dashboard
- Prometheus
- Grafana (https://prometheus.io/docs/visualization/grafana/ )
- InfluxDB
- Chronograf (https://www.influxdata.com/time-series-platform/chronograf/ )
- Alerting
- Prometheus
- Alertmanager (https://prometheus.io/docs/alerting/alertmanager/ )
- InfluxDB
- Kapacitor (https://www.influxdata.com/time-series-platform/kapacitor/ )

View Slide

#srenextC
- Dashboard
- Grafana も Chronograf も重ねて見れる
- おしゃれ
- Alerting
- Alertmanager も Kapacitor も設定ファイルが難しい
- これはどちらかというと文化もある
- Grafana はブラウザからポチポチできる
- バックアップは必要

View Slide

#srenextC

View Slide

#srenextC
Announcing Chronograf 0.3 | InfluxData https://www.influxdata.com/blog/announcing-chronograf-0-3/

View Slide

#srenextC
- Dashboard
- Grafana も Chronograf も重ねて見れる
- おしゃれ
- Alerting
- Alertmanager も Kapacitor も設定ファイルが難しい
- これはどちらかというと文化もある
- Grafana はブラウザからポチポチできる
- バックアップは必要

View Slide

#srenextC
ツールは仲良くなって
ベストな選択を！

View Slide

#srenextC
外側の監視を足したよ

View Slide

#srenextC
2020年の監視

View Slide

#srenextC
外形監視とアクセスログ監視

View Slide

#srenextC
外形監視
- シンプルに SaaS におまかせ
- 管理画面のために NewRelic APM を使うようになった
- New Relic Synthetics で外形監視
- CDN (Javascript) は中身をチェック
- 定期的にブラウザテストも回そうとしている
- 配信サーバも中身をチェック
- /health や /ping といったエンドポイントを用意することもある
- ただし、どちらかというと内側の監視で使う印象
- 例えば、ロードバランサが叩く

View Slide

#srenextC

View Slide

#srenextC
外形監視
- シンプルに SaaS におまかせ
- 管理画面のために NewRelic APM を使うようになった
- New Relic Synthetics で外形監視
- CDN (Javascript) は中身をチェック
- 定期的にブラウザテストも回そうとしている
- 配信サーバも中身をチェック
- /health や /ping といったエンドポイントを用意することもある
- ただし、どちらかというと内側の監視で使う印象
- 例えば、ロードバランサが叩く

View Slide

#srenextC
/**
* ping check
*/
function ping(): bool
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://localhost:8080/xxxxxx');
...
$res = curl_exec($ch);
if (curl_errno($ch)) {
return false;
} else {
return true;
}
}
if (ping()) {
http_response_code(200);
echo "ok";
} else {
http_response_code(500);
}

View Slide

#srenextC
アクセスログのステータスコード監視
- 処理サーバ全台のアクセスログの合計サイズ
- 475 GB / Day
- 13 TB / Month
- 156 TB / Year
- InfluxDB のディスクが足りないので集計したものを保持すれば良
い
- 最大 512 GB
- でも、あまり複雑にはしたくない（監視の監視になりそう）

View Slide

#srenextC
...
Continuous Query
2分で消えるテ
ーブル
1年で消えるテ
ーブル
Retention Policy
CREATE CONTINUOUS QUERY cq_imp_status_code_http ON telegraf RESAMPLE EVERY
1m
BEGIN
SELECT count(*) INTO imp_status_code_http
FROM imp_status_code_http_two_min
GROUP BY time(1m), host, request_path, status_code
END
アクセスログを
パースしたもの

View Slide

#srenextC
...
Continuous Query
2分で消えるテ
ーブル
1年で消えるテ
ーブル
Retention Policy
CREATE CONTINUOUS QUERY cq_imp_status_code_http ON telegraf RESAMPLE EVERY
1m
BEGIN
SELECT count(*) INTO imp_status_code_http
FROM imp_status_code_http_two_min
GROUP BY time(1m), host, request_path, status_code
END
アクセスログを
パースしたもの
261 GB で1年分を保持している

View Slide

#srenextC

View Slide

#srenextC
まとめ
- 監視は外側（高レベルなもの）から
- 内側よりかはすぐに正常かどうかの判断が出来る
- アラートは整理しましょう
- 特に障害はチャンス
- 整理されると見る人が増えた
- ツールは仲良くなってベストな選択を！
- サービス, 規模などの変化に合わせて
- お金とも相談

View Slide

#srenextC

View Slide

#srenextC
こんな人たちがいます
@makoga
VOYAGE GROUP 取締役CTO
日本CTO協会理事
@hagino3000
@suzu_v
fluct 取締役CTO
ajitofm パーソナリティ
#ajitofm

View Slide

#srenextC

View Slide

#srenextC
エンジニア
絶賛募集中

View Slide

#srenextC
ajiting
VOYAGE GROUPでは
AJITOで飲むことをajitingと呼んでいます。
エンジニアイベントに
会場貸出もやってます
@tech_voyage にメンションかDMください
AJITOでエンジニアたちと飲んでみたい！
という方はご連絡ください。
ピザ or 寿司差し⼊れます︕(最⼤
100名分)

View Slide

#srenextC
イベント情報もお知らせします
@tech_voyage
SRE-NEXT 登壇セッションも再演予定
成⻑を続ける広告配信プラットフォームの
モニタリングを改善してきた話
@larufa1

View Slide

#srenextC
まとめ
- 監視は外側（高レベルなもの）から
- 内側よりかはすぐに正常かどうかの判断が出来る
- アラートは整理しましょう
- 特に障害はチャンス
- 整理されると見る人が増えた
- ツールは仲良くなってベストな選択を！
- サービス, 規模などの変化に合わせて
- お金とも相談

View Slide

成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

larufa

Other Decks in Technology

Featured

Transcript