Slide 1
Slide 1 text
Web
サー
ビスを監視するときに
僕達が考えたこと
by id:papix (@__papix__)
株式会社はてな
Slide 2
Slide 2 text
papix
株式会社はてな アプリケー
ションエンジニア (2017
年2
月～)
｢
はてなブログ｣
をつくっています
アカウント類
はてな: i
d
:
p
a
p
i
x
Twitter: @
_
_
p
a
p
i
x
_
_
GitHub: p
a
p
i
x
CPAN: P
A
P
I
X
ブログ: h
t
t
p
s
?
:
/
/
p
a
p
i
x
.
h
a
t
e
n
a
(
b
l
o
g
.
(
c
o
m
|
j
p
)
|
d
i
a
r
y
.
j
p
)
/
趣味はPerl
と, (
交通機関を利用した)
旅行など
去年JGC
修行を完遂しました,
折を見てSFC
も修行したい...
Slide 3
Slide 3 text
｢
僕達が考えたこと｣
シリー
ズ第三弾
YAPC::Hokkaido
｢API
をPerl
で作る時に僕達が考えたこと｣
YAPC::Kansai
｢Perl
のWeb
アプリケー
ションをデプロイする時に僕達が考え
たこと｣
YAPC::Okinawa
｢Web
サー
ビスを監視するときに僕達が考えたこと｣ ←NEW!
Slide 4
Slide 4 text
想定している聴衆
初心者向けを想定した内容です:
"Web
サー
ビスの監視"
について思いを馳せたことのない学生さん
Web
サー
ビスの監視についての知見が欲しい/
意見交換がしたい,
主
にWeb
アプリケー
ション開発に従事するエンジニア
このトー
クをきっかけに, ｢Web
サー
ビスの監視｣
について思いを馳せて
みましょう!
Slide 5
Slide 5 text
もくじ
なぜ僕達は"
監視"
をするのか
監視する時に有用なメトリック達
どこまで検知して,
通知する?
Web
サー
ビス開発の現場での監視
おまけ:
まず初めてみる?
おうち監視!
Slide 6
Slide 6 text
Web
サー
ビスを監視するときに
僕達が考えたこと
by id:papix (@__papix__)
株式会社はてな
Slide 7
Slide 7 text
なぜ僕達は"
監視"
をするのか
Slide 8
Slide 8 text
サー
ビスに這い寄る障害達
Web
サー
ビスには様々
な障害が起きる:
ネットワー
ク/
サー
バの不調...
爆発的アクセス増による高負荷...
バグやオペレー
ションミス...
どれだけ優秀な人員を揃えても,
どれだけ設備投資をしても,
どれだ
け慎重にオペレー
ションしても,
障害は必ず起きる
Slide 9
Slide 9 text
障害対応のサイクル
障害対応は次のように対応される:
障害の検知
調査と解決
事後対応と振り返り
Slide 10
Slide 10 text
障害の検知
障害が発生したことに気づく段階
ドッグフー
ディングをしていて
ユー
ザからのお問い合わせ
Twitter
などのSNS
でのユー
ザの声
"Web
サー
ビスの監視機構"
から通知が届いて
このトー
クでは,
この"
監視"
の部分にフォー
カスを当てて
話をします
なるべく迅速に気付きたい
"
予兆"
の段階で気づければ,
実際にユー
ザに影響が出る前に対
処できる
Slide 11
Slide 11 text
調査と解決
発生している障害の原因を調べ,
解決するために修正やオペレー
シ
ョンをする段階
憶測ではなく,
事実に基づいて原因を見つける
焦りがちだけれど,
障害の対応が更なる障害を生み出さないよ
うに,
丁寧に
ペアプロ/
ペアオペなどで作業を進めていくのも有効
このトー
クで話す"
監視"
によって得られる情報は,
このフェイズでも
非常に役立ちます
Slide 12
Slide 12 text
事後対応と振り返り
暫定対応で障害を解決した場合,
その恒久対応が必要
また,
再発防止策となる実装,
オペレー
ションも考慮しないとい
けない
似たような障害が発生した時に備えて,
障害の原因や対応を振り返
り,
共有することも重要
社内障害情報共有のススメ
http://developer.hatenastaff.com/entry/2018/02/19/180000
Slide 13
Slide 13 text
なぜ僕達は"
監視"
をするのか
障害の迅速な確認
Web
サー
ビスに問題があった時, 1
秒でも早く気付き,
対応出来
るようにする
障害対応の道標
監視の結果から手がかりを得て, 1
秒でも早く障害を解決するこ
とを目指す
Slide 14
Slide 14 text
障害対応の道標 ～
推測するな,
計測せよ～
ISUCON
でよく聞く言葉
元はRob Pike
氏(
現Google, Go
の開発者)
の発言だそう:
ルー
ル1:
プログラムがどこで時間を消費することになるか知ること
はできない。
ボトルネックは驚くべき箇所で起こるものである。
し
たがって、
どこがボトルネックなのかをはっきりさせるまでは、
推
測を行ったり、
スピー
ドハックをしてはならない。
ルー
ル2:
計測すべし。
計測するまでは速度のための調整をしてはな
らない。
コー
ドの一部が残りを圧倒しないのであれば、
なおさらで
ある。
Slide 15
Slide 15 text
障害対応の道標 ～
推測するな,
計測せよ～
｢Web
サー
ビスの開発/
保守/
運営｣
でも同様
日頃から, Web
サー
ビスやそれを構成するインフラを監視する
その情報が,
問題発生時の助けになる
医者の手術と一緒
人体という複雑なシステムと立ち向かう為に,
心拍数,
血圧,
体
温などを計測しながら手術をする
Web
サー
ビスもまた複雑なのである...
Slide 16
Slide 16 text
Web
サー
ビスの障害対応
確認が必要な範囲がとにかく広い
ネットワー
ク,
インフラ,
ミドルウェア,
アプリケー
ション...
全てのレイヤー
を手探りで調べるのは非効率
監視とその結果で,
怪しい範囲を絞り込むことができる
もちろん,
そこから一気に原因を特定できる時もある
Slide 17
Slide 17 text
Web
サー
ビスに必要な"
監視"
とは?
個人的には,
以下の5
要素が重要:
管理
可視化
蓄積
検知
通知
Slide 18
Slide 18 text
管理
｢Web
サー
ビスを構成する各種インフラ(
サー
バ/
ミドルウェア)
を紐付け
て,
役割や状況を明示する｣
これによって, Web
サー
ビスがどのように構築され,
どのように稼働
しているか一目瞭然となる
加えて,
これを"
管理台帳のマスター"
として,
日々
のオペレー
ション
に活用することもできる
監視だけじゃない!
デプロイにMackerel
を使う話
http://tech.mercari.com/entry/2016/11/14/120000
Slide 19
Slide 19 text
可視化
｢Web
サー
ビスとそれを構成する各種インフラの状態を,
数値(
メトリッ
ク)
として取得/
表現し,
統一されたインター
フェイスで確認できる｣
これによって, Web
サー
ビスを構成する各種インフラの状態を,
数値
で言及することが出来るようになる
障害対応で切羽詰まっている時に, ｢
詰まっていそう｣｢
負荷高そ
う｣
といった,
抽象的な言葉は混乱を呼び起こす可能性がある
更に,
統一されたインター
フェイスで,
複数のインフラの状況を一気
に見る/
見比べることができる
結果として, Web
サー
ビスの様子が一目瞭然になる
Slide 20
Slide 20 text
蓄積
｢
可視化のために取得したメトリックを蓄積し,
時系列に並べて,
表やグラ
フで表現出来るようにする｣
これによって,
可視化した値の特異点がグラフィカルに認識できる
ようになる
Web
サー
ビスに何か問題があれば,
表は急激な凹凸を示す
加えて, Web
サー
ビスとそのインフラの日常の傾向を追いやすくな
る
日中はアクセスが増える/
深夜は減る,
など...
Slide 21
Slide 21 text
検知
｢
可視化のために取得したメトリックに応じて, Web
サー
ビスやそれを構
成するサー
バ/
ミドルウェア等が異常かどうかを識別する｣
これによって, Web
サー
ビスやサー
バ/
ミドルウェア等のインフラ要
素に対して｢
異常な状態｣
を定義できる
メモリ使用率が80%
を越えたら警戒状態, 90%
を越えたら異常
状態,
など...
この定義を定めるのが非常に難しい(
後述)
Slide 22
Slide 22 text
通知
｢
検知した内容を適切に通知して,
調査や対応を促す｣
これによって,
開発者が常時監視していなくても,
異常状態が発生し
たことを認知することができる
常時監視しなくても良いとは言え,
誰かが気付けるような体制
を構築することは重要
その辺りは｢
運用｣
の話でもあるので,
今回は割愛
Slide 23
Slide 23 text
"
監視"
を実現するツー
ル達
それぞれ特長や,
得意/
不得意がある
SaaS
かOSS
か
push
型かpull
型か
Slide 24
Slide 24 text
SaaS
かOSS
か
SaaS
管理/
可視化/
蓄積の仕組みがWeb
サー
ビスとして提供される(
フ
ルマネー
ジド)
大抵の場合,
監視するサー
バの台数によってコストが線形的に
増加する
OSS
各自でサー
バを用意して,
その上に監視の仕組みを構築する(
セ
ルフホスティング)
構築/
運用コストが必要だが,
監視するサー
バの台数によって線
形的にコストが増えることはない
とはいえ, SaaS
でもセルフホスティングが可能なものもあり, OSS
でもフルマネー
ジドなものもある
Slide 25
Slide 25 text
push
型かpull
型か
監視するサー
バから,
どのようにしてメトリックを収拾するか
push
型
各サー
バから,
メトリックを蓄積するサー
バに投げる
pull
型
メトリックを蓄積するサー
バが,
各サー
バにリクエストを投げ
て取得する
Slide 26
Slide 26 text
具体例
DataDog
Mackerel
NewRelic
Prometheus
Zabbix
※
このトー
クでは,
例として筆者が使い慣れているMackerel
を中心に取り
上げます
Slide 27
Slide 27 text
監視する時に有用なメトリック達
Slide 28
Slide 28 text
監視する時に有用なメトリック達
"
監視"
の仕組みを導入することで, Web
サー
ビスとそのインフラに
関連する様々
なメトリックを可視化/
蓄積できる
しかし,
ただ単に"
監視"
するだけでは意味がない
それらのメトリックの意味,
傾向を掴まなければ,
いざと言う時
に役に立たない
Slide 29
Slide 29 text
監視する時に有用なメトリック達
Mackerel
のエー
ジェントをLinux
のサー
バに導入した際に自動的に
取得される, Linux
のシステムメトリックを紹介します:
l
o
a
d
a
v
g
5
c
p
u
m
e
m
o
r
y
d
i
s
k
i
n
t
e
r
f
a
c
e
f
i
l
e
s
y
s
t
e
m
Slide 30
Slide 30 text
l
o
a
d
a
v
g
5
言わずと知れた｢
ロー
ドアベレー
ジ｣
5
は5
分間平均(
一般に, u
p
t
i
m
e
や w
コマンドでは1/5/15
分平
均のロー
ドアベレー
ジが見れる)
さっくり言えば, ｢
システム全体の負荷の様子｣
を示す
実行待ちプロセス数と, I/O
待ちプロセス数の合計
= CPU
等に余裕があれば,
すぐに実行されるプロセス数
Slide 31
Slide 31 text
l
o
a
d
a
v
g
5
の見どころ
負荷が高まれば,
その分 l
o
a
d
a
v
g
5
も上昇する
システムやサー
ビスの特性によっては,
常にロー
ドアベレー
ジ
が高い場合もある
瞬間的な値ではなく,
その数値の傾向を見るのが重要
急増した後,
減少の幅が少ない場合
一定のペー
スで増加を続けている場合
Slide 32
Slide 32 text
c
p
u
CPU(
演算処理装置)
の使用率を表す
用途ごとに細かく利用率が見れる:
意味
user
カー
ネル以外(
アプリケー
ション)
が利用したCPU
時間の割合
(nice
は含まない)
system
カー
ネルが利用したCPU
時間の割合
iowait I/O
待ちによってCPU
が利用されていない時間の割合
idle CPU
が使われていない時間の割合(iowait
は含まない)
Slide 33
Slide 33 text
c
p
u
意味
nice
優先度(nice
値)
が指定されたアプリケー
ションによるCPU
時
間の割合
irq
ハー
ドウェア割り込みによるCPU
時間の割合
softirq
ソフトウェア割り込みによるCPU
時間の割合
steal
ゲストOS(
仮想マシン)
が割り当て待ちとなった時間の割合
guest
ゲストOS(
仮想マシン)
によるCPU
時間の割合
Slide 34
Slide 34 text
c
p
u
の見どころ
ロー
ドアベレー
ジと同じく,
負荷が高まればCPU
利用率も高まる
サー
バ上で動作するアプリケー
ションやミドルウェアの負荷が
高まれば u
s
e
r
の割合が増える
アプリケー
ションやミドルウェアによるI/O
がディスクのI/O
性
能に追いつかない場合, i
o
w
a
i
t
が増える
Xen
やKVM
などの仮想化環境を使っていて,
その負荷が高まれ
ば s
t
e
a
l
や g
u
e
s
t
なども見る必要がある
Slide 35
Slide 35 text
c
p
u
の見どころ
ロー
ドアベレー
ジと同じく,
システムやサー
ビスの特性によって値
は変わる
CPU
利用率を可視化/
蓄積し,
日頃から傾向を掴んでおくことが
大事(
後述)
また, CPU
利用率が低い(= i
d
l
e
が多い)
ことは,
それもまた一種の
問題である
CPU
利用率が低い =
サー
バを効率的に利用できていない
｢
負荷低すぎはもはや障害じゃないのか｣
http://mikeda.hatenablog.com/entry/2015/02/01/195102
Slide 36
Slide 36 text
m
e
m
o
r
y
メモリの利用量を表す
Mackerel
では, u
s
e
d + b
u
f
f
e
r
s + c
a
c
h
e
d + f
r
e
e =
t
o
t
a
l
を前提とする
意味
total
物理メモリの総容量
used
利用している物理メモリの容量
cached
ペー
ジキャッシュに使われている物理メモリの容量
buffers
バッファに使われている物理メモリの容量
free
利用されてない物理メモリの容量
Slide 37
Slide 37 text
m
e
m
o
r
y
の見どころ
Linux
では,
利用可能なメモリがあれば,
ペー
ジキャッシュ( c
a
c
h
e
d )
とバッファ( b
u
f
f
e
r
s )
のために積極的に利用される
アプリケー
ションによってメモリが必要になった時に開放され
る
そのため, "
メモリの利用率"
を考えるなら, u
s
e
d / t
o
t
a
l
で
考える必要がある
Linux kernel 3.14
以降では, M
e
m
A
v
a
i
l
a
b
l
e
というパラメー
タがあ
る
開放不可能な c
a
c
h
e
d / b
u
f
f
e
r
s
も考慮されている
Slide 38
Slide 38 text
m
e
m
o
r
y
の見どころ
一方,
スワップのメトリックとして, s
w
a
p t
o
t
a
l , s
w
a
p u
s
e
d ,
s
w
a
p c
a
c
h
e
d
がある
スワップは多くの場合HDD/SSD
上に作られる
物理メモリに比べて速度が遅いため,
スワップの発生 =
パフォ
ー
マスの低下と言える
特にWeb
サー
ビスが稼働するサー
バでは,
基本的に｢
スワップは発生
させない｣
ように意識するべき
メモリの利用量が漸増している場合,
メモリリー
クなど発生してい
ないか調査する必要がある
Slide 39
Slide 39 text
d
i
s
k
ディスクの読み書きに関するメトリック
単位はIOPS(= 1
秒辺りに処理できるI/O
の数)
ディスクのIOPS
性能は明示されていることが多い
Amazon Elastic Block Storage(EBS)
でも, IOPS
性能が違うデ
ィスクを選ぶことができる
Slide 40
Slide 40 text
d
i
s
k
の見どころ
IOPS
の余裕がなくなると,
ディスクの書き込み/
読み込みが詰まる
RDBMS(MySQL
など)
が動くサー
バでは特に重要
IOPS
の日頃の増減傾向と,
今後起こりうる瞬間的なIOPS
増(Web
サ
ー
ビスにとってはアクセスの急増)
に耐えれるかどうかを見極める
中長期的な視点で監視し,
手を打つことが重要
Slide 41
Slide 41 text
i
n
t
e
r
f
a
c
e
ネットワー
ク帯域の利用状況を表す
t
x
が送信, r
x
が受信,
単位は K
B
/
秒
ちなみに t
x
は t
r
a
n
s
m
i
t , r
x
は r
e
c
e
i
v
e
のことらしい
これもまた,
インフラ提供者によってネットワー
ク帯域に上限が定
められている
クラウドの場合,
更に課金額にも影響が出る
Slide 42
Slide 42 text
i
n
t
e
r
f
a
c
e
の見どころ
Nginx
やApache
が動くプロキシサー
バ,
コンテンツを配信するサー
バでは t
x , r
x
が増えがち
コンテンツを配信するサー
バであれば, CDN
を通すなどで対策
出来る
急激な t
x / r
x
の増加があれば,
瞬間的なアクセス増やDoS
攻撃な
どの可能性がある
Slide 43
Slide 43 text
f
i
l
e
s
y
s
t
e
m
ディスクとその使用量を表す
s
i
z
e
はディスクの最大容量, u
s
e
d
はディスクの使用量
例えばRDBMS
が動くサー
バでは,
デー
タが蓄積される毎に u
s
e
d
が
増えていく
言うまでもなく,
ディスクの空き容量がなくなると書き込めな
くなるので,
その前に最大容量を増やす必要がある
また,
ミドルウェアなどのログの書き込みでも u
s
e
d
が増えて
いく
Slide 44
Slide 44 text
f
i
l
e
s
y
s
t
e
m
の見どころ
ディスクの空き容量をすぐに増やせない場合も有り得るので,
ある
程度の利用率を越えたら警告するようにしておく
定期的に u
s
e
d
の増加量を確認し,
警告が出て,
危険な領域に達
する前に最大容量を増やせるのがベスト
u
s
e
d
が急激に増えている場合, Web
サー
ビスやミドルウェアのロ
グの出力設定を変更している場合などもある
ログがより詳細に出るようになって,
大量のログがディスク上
に保存されている状態
Slide 45
Slide 45 text
監視する時に有用なメトリック達
ここまで紹介した6
つのメトリック以外にも, Web
サー
ビスやそれを
構成するインフラの監視に有用なメトリックがあります
アクセスログ(
アクセス数,
ステー
タスコー
ドの割合,
レイテン
シ)
外形監視
uptime
サー
ビス/
ミドルウェアに特化したメトリック
Slide 46
Slide 46 text
アクセスログ
Nginx
など,
プロキシのアクセスログからメトリックを取得する
Mackerel
なら:
https://github.com/mackerelio/mackerel‑agent‑
plugins/tree/master/mackerel‑plugin‑accesslog
Slide 47
Slide 47 text
アクセスログ
Access Num
1
分間辺りの総リクエスト数と,
ステー
タスコー
ドごとのリクエ
スト数
ステー
タスコー
ドは100
の位ごとにまとめられる. A
c
c
e
s
s
R
a
t
e
も同様
Access Rate
1
分間辺りのステー
タスコー
ドの割合
Latency
A
v
e
r
a
g
e ...
リクエストにかかった秒数(
レイテンシ)
の平均
9
0 P
e
r
c
e
n
t
i
l
e ...
レイテンシの下位90%
の秒数
9
5 P
e
r
c
e
n
t
i
l
e ...
レイテンシの下位95%
の秒数
9
9 P
e
r
c
e
n
t
i
l
e ...
レイテンシの下位99%
の秒数
Slide 48
Slide 48 text
アクセスログの見どころ
A
c
c
e
s
s N
u
m
Web
サー
ビスへのアクセス数が増えれば, T
o
t
a
l C
o
u
n
t
が増
えていく
A
c
c
e
s
s R
a
t
e
デプロイ後など,
バグがあれば H
T
T
P 5
x
x P
e
r
c
e
n
t
a
g
e
が上昇
しがち
L
a
t
e
n
c
y
高負荷によって, CPU
利用率が増えたり, IOPS
が上限に達した
場合,
レイテンシに影響が出て来る
Slide 49
Slide 49 text
外形監視
実際にWeb
サー
ビスにリクエストを行い,
期待するレスポンスが得
られるか確認する
レスポンスのステー
タスコー
ドなどを確認
Slide 50
Slide 50 text
外形監視の見どころ
外形監視の結果が異常であれば,
即ち現在進行系でユー
ザに影響が
出ているということ
とはいえ,
ネットワー
クの状態等で偽陽性となることもある
レスポンスタイムが遅くなっているなら,
レイテンシの様子なども
見て調査を検討する必要がある
Slide 51
Slide 51 text
uptime
Linux
などのOS
が,
どれくらいの時間稼働しているかを示す
Mackerel
なら:
https://github.com/mackerelio/mackerel‑agent‑
plugins/tree/master/mackerel‑plugin‑uptime
Slide 52
Slide 52 text
uptime
の見どころ
uptime
が0
になるということは, OS
が再起動されたということ
つまり,
サー
バが再起動されたということ
意図しない再起動であれば,
調査をする必要がある
Slide 53
Slide 53 text
サー
ビス/
ミドルウェアに特化したメトリック
Mackerel
の場合,
プラグインでサー
ビス/
ミドルウェアに特化したメ
トリックを取得できる
https://github.com/mackerelio/mackerel‑agent‑plugins
Nginx/Apache/h2o
といったプロキシ, MySQL/PostgresSQL
といっ
たRDBMS, Redis/Memcached
といったKVS, AWS
の各サー
ビスな
どを対象にしたプラグインが提供されている
Slide 54
Slide 54 text
任意のメトリックを取得したい! ～Mackerel
では?～
既存のプラグインで取得できないメトリックであれば, Go
言語でプ
ラグインを作り,
メトリックを取得して投げればよい
g
o
-
m
a
c
k
e
r
e
l
-
p
l
u
g
i
n
というヘルパー
がある
https://mackerel.io/ja/docs/entry/advanced/go‑mackerel‑
plugin
とはいえ,
フォー
マット(Sensu
のフォー
マットと同じ)
が同じであれ
ば, Shell Script
やPerl, Ruby
などで実装しても構わない
公式のプラグインリポジトリ以外にも,
ユー
ザがそれぞれプラグイ
ンをGitHub
などで公開していることがある
Slide 55
Slide 55 text
どこまで検知して,
通知する?
～
狼少年にならないために～
Slide 56
Slide 56 text
正しく検知する難しさ
Web
サー
ビスを監視する時に一番難しいのは, ｢
検知の条件｣
を組み
立てる部分では...?
Web
サー
ビスやそれを構成するインフラが,
異常な状態であれ
ば必ず検知したい(
当たり前)
日常的に発生するピー
ク,
サー
ビスの成長による(
想定の範囲内
の)
負荷の上昇は異常な状態としたくない
障害として検知する条件を...
厳しくすると,
実際には問題がないのに,
障害として検知され,
通知が行われてしまう(=
狼少年検知)
緩くすると,
実際に障害が発生するのに,
それを検知できなくな
ってしまう
一般には｢
厳しくしすぎて,
狼少年通知が多発する｣
パター
ンが多い気がします...
Slide 57
Slide 57 text
狼少年検知
｢
狼少年｣
の寓話
｢
狼が来た!｣
と嘘をついて騒ぎを起こし続けて,
遂に本当に狼が
来た時に, ｢
狼が来た!｣
と言っても誰も相手をしてくれなかった
｢
狼少年検知｣
Web
サー
ビスやそのインフラのメトリックに問題がないのに,
異常があると検知され,
その通知が飛ぶ状態が続くと,
それに慣
れてしまう
本当に対処するべき問題とその通知が,
問題がない通知に埋も
れてしまう
Slide 58
Slide 58 text
｢
狼少年検知｣
を防ぐには?
検知の条件/
通知の条件を定期的に棚卸しする
｢
狼少年｣
にならないように,
異常状態として検知条件を緩和す
る(
メトリックがより高い数値になったら通知をするようにす
る)
前述の通り,
緩和しすぎると逆に異常状態であることに気づけ
なくなってしまう
逆に, Web
サー
ビスやインフラの整備で,
平常時のメトリックの値が
低く推移するようになったら,
通知条件を厳格化する必要がある
棚卸しに活かすためにも,
サー
ビスの負荷の傾向を追う必要がある
Slide 59
Slide 59 text
サー
ビスの負荷の傾向を追う
メトリックが常に同じ値を示し続けることはない
様々
な単位で凹/
凸のピー
クがある
サー
ビスの負荷(
メトリックの変化)
の傾向を把握することが重要
通知の条件を見直す材料になる
メトリックに異常値が発生したときの判断材料になる
Slide 60
Slide 60 text
年単位の傾向
年単位のイベントによって負荷が変動することがある
例:
年末年始のLINE,
メー
ル送信
｢
あけおめメー
ル｣
を送受信するので,
負荷が高まる
Slide 61
Slide 61 text
月単位
月単位のイベントによって負荷が変動することがある
例:
月末/
月初
Web
サー
ビスに月単位のイベントが存在するとき,
それによっ
て負荷が高まる可能性がある
Slide 62
Slide 62 text
日単位
週単位のイベントによって負荷が変動することがある
例: B2B
サー
ビスであれば,
週末や祝日は負荷が低まる
企業向けのサー
ビスなので,
企業が休業であることの多い休日
は利用することが少ない
Slide 63
Slide 63 text
時間単位
時間単位のイベントによって負荷が変動することがある
例:
昼休み
ブログなどは,
昼休みに閲覧するユー
ザが多いので, 12
時前後に
ピー
クが現れる
例:
深夜帯
深夜帯は日中に比べて負荷が低まることが多い(
ユー
ザが寝て
いるので)
Slide 64
Slide 64 text
検知からの通知
メトリックの変化を検知できれば, Web
サー
ビスの問題発生をいち
早く気づくことができる
しかし,
可視化されたメトリックを四六時中眺め続けているの
は現実的ではない
｢
適切に｣
通知をして,
メトリックから問題を検知した時に気づ
けるようにしないといけない
Slide 65
Slide 65 text
監視の結果を通知したい! ～Mackerel
では?～
メトリックの値が一定値を越えたり,
外形監視の結果に問題があっ
た時, Warning/Critical
の通知を送ることができる
対応している送付先:
メー
ル, Slack, HipChat, PagerDuty,
ChatWork, TypeTalk, OpsGenie, Reactio, Yammer, LINE,
Twilio
Twilio
を使うことで,
電話での通知も対応することができ
る
Webhook
の送信にも対応しているので,
独自の通知サー
ビスと
連携することも可能
Slide 66
Slide 66 text
｢
通知をしない｣
という選択肢
メトリックが異常値になり,
異常状態と検知されることが明らかな
場合,
一時的に通知をOff
にすることも有効
瞬間的に高負荷になることが事前に明らかになっている場合
プレスリリー
スが出る,
テレビ/
ニュー
スで紹介される等...
Mackerel
なら...
監視ルー
ル単位で時間指定ミュー
トをおこなえるようになりま
した ほか
https://mackerel.io/ja/blog/entry/weekly/20180219
Slide 67
Slide 67 text
Web
サー
ビス開発の現場での監視
～
はてなブログの場合～
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
はてなブログ
今年でリリー
スから6
年
今すぐ登録→ h
t
t
p
s
:
/
/
b
l
o
g
.
h
a
t
e
n
a
.
n
e
.
j
p
/
r
e
g
i
s
t
e
r
Web
アプリケー
ションエンジニア5
人(+
アルバイト)
で開発中
3
人が京都オフィス, 2
人が東京オフィスのリモー
ト体制
インフラはAWS
もちろんMackerel
も活用中
Slide 70
Slide 70 text
Mackerel
を活用した取り組み ‑ PWG
Performance Working Group
毎月1
回開催
(
はてなブログ担当の)Web
オペレー
ションエンジニアも参加
Mackerel
のグラフを見ながら,
パラメー
タの変化を確認
対応が必要なものはGHE
にIssue
を立てて着手
たくさんのホスト/
メトリックがあるので,
重要度の高いものをダッ
シュボー
ドにまとめている
Slide 71
Slide 71 text
ダッシュボー
ドの様子
Slide 72
Slide 72 text
グラフアノテー
ション
"
可視化"
の観点で非常に便利な機能
デプロイの度にアノテー
ションを残す
Description
として,
そのデプロイに紐付いたPull Request
の
URL
を記載
グラフに急激な変化があった時,
その原因となったPull Request
を推
測しやすい
Slide 73
Slide 73 text
グラフアノテー
ションの様子
Slide 74
Slide 74 text
サー
ビスメトリック
よくあるサー
ビスメトリックははてなブログでも投稿しています
ステー
タスコー
ドの割合,
レスポンスタイム...
Slide 75
Slide 75 text
デプロイにかかる時間
1
回のデプロイに要した時間を記録
c
a
r
t
o
n
_
i
n
s
t
a
l
l ...
ライブラリインストー
ルにかかった時間
d
e
p
l
o
y
_
u
p
d
a
t
e ...
ファイルの配布にかかった時間
r
e
s
t
a
r
t ...
プロセス再起動にかかった時間
可視化することで問題点を洗い出し,
改善することができる
詳しくは:
はてなブログのデプロイを約6
倍高速化したはなし
http://this.aereal.org/entry/2016/12/16/170000
Slide 76
Slide 76 text
更新が必要なnpm
パッケー
ジ
y
a
r
n o
u
t
d
a
t
e
d
で取得した更新が必要なnpm
パッケー
ジの数を投
稿し, Mackerel
で可視化
詳しくは: ｢
更新が必要なnpm
パッケー
ジを可視化する｣
http://developer.hatenastaff.com/entry/2017/06/06/163000
Slide 77
Slide 77 text
おまけ:
まず初めてみる?
おうち監視!
Slide 78
Slide 78 text
まず初めてみる?
おうち監視!
｢Web
サー
ビス監視｣
のツー
ル/
サー
ビスは,
身近なところから試して
みよう
契約しているVPS
とか, Mac
とか...
一方で, "
自宅の監視"
から試してみるのも手です!
Slide 79
Slide 79 text
EdgeRouter X
米Ubiquiti
製のルー
タ
Amazon
で1
万程度で購入できる割に高性能
VPN
が設定できたりするので,
ネットワー
ク周りの技術の入門
にも有用
MIPS
の上にEdgeOS
が載っている
EdgeOS
はVyatta(
ネットワー
ク機器向けDebian
ベー
スのLinux
OS)
の派生版
故に, G
O
O
S
=
l
i
n
u
x , G
O
A
R
C
H
=
m
i
p
s
l
e
でビルドすれば,
m
a
c
k
e
r
e
l
-
a
g
e
n
t
やGo
製のMackerel
プラグインが動く!
Perl
も5.14.2
が入っている
他, "Raspberry Pi"
の上で動かすなどの手もある
Slide 80
Slide 80 text
mackerel‑plugin‑nasne
Slide 81
Slide 81 text
mackerel‑plugin‑nasne
https://github.com/ayumu83s/mackerel‑plugin‑nasne
ソニー
のHDD
レコー
ダー, "nasne"
を監視するplugin(Go
製)
録画に成功/
失敗した番組の数, HDD
の残り容量などを監視でき
る
Slide 82
Slide 82 text
mackerel‑plugin‑nature‑remo
Slide 83
Slide 83 text
mackerel‑plugin‑nature‑remo
https://github.com/papix/mackerel‑plugin‑nature‑remo
スマー
トリモコン"Nature Remo"
を監視するplugin(
拙作, Go
製)
Nature Remo
にある,
温度/
湿度の測定機能の結果をMackerel
に投稿できる
Slide 84
Slide 84 text
Netatmo
温度,
湿度,
気圧,
二酸化炭素,
騒音を測定できるガジェット
10
分毎に値が更新, API
経由で取得できる
Slide 85
Slide 85 text
Netatmo
はてなでは...
社内の各フロアに設置されていて,
一定の数値を越えるとSlack
に通知が飛ぶ
Slide 86
Slide 86 text
さいごに
Slide 87
Slide 87 text
さいごに
以下のテー
マについて話しました:
なぜ僕達は"
監視"
をするのか
監視する時に有用なメトリック達
どこまで検知して,
通知する?
Web
サー
ビス開発の現場での監視
Slide 88
Slide 88 text
さいごに
Web
サー
ビスが公開され,
利用者がいる以上,
障害は必ず起きます
その時に備えて, "
監視"
についてしっかり取り組む必要がある
Web
サー
ビスの特性,
利用しているインフラ/
ミドルウェアの特性,
開発チー
ムの特性など,
様々
な変数によって最適な"
監視"
は変わる
変化を恐れず,
試行錯誤をしていきましょう!
知見を共有して,
より良い"
監視"
を目指していきたいものです...
Slide 89
Slide 89 text
おわり
ご清聴ありがとうございました!
Slide 90
Slide 90 text
あわせてよみたい
Mackerel
サー
バ監視[
実践]
入門
http://gihyo.jp/book/2017/978‑4‑7741‑9213‑0
Mackerel
でみる Linux
システムメトリック項目の見方・
考え方
http://blog.a‑know.me/entry/2017/02/02/215641
突然IT
インフラを任された人のための…
監視設計入門
https://www.koemu.com/etc/yapcasia2014/