Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018

papix
March 03, 2018

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018

papix

March 03, 2018
Tweet

More Decks by papix

Other Decks in Programming

Transcript

  1. Web
    サー
    ビスを監視するときに
    僕達が考えたこと
    by id:papix (@__papix__)
    株式会社はてな

    View full-size slide

  2. 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
    も修行したい...

    View full-size slide


  3. 僕達が考えたこと」
    シリー
    ズ第三弾
    YAPC::Hokkaido
    「API
    をPerl
    で作る時に僕達が考えたこと」
    YAPC::Kansai
    「Perl
    のWeb
    アプリケー
    ションをデプロイする時に僕達が考え
    たこと」
    YAPC::Okinawa
    「Web
    サー
    ビスを監視するときに僕達が考えたこと」 ←NEW!

    View full-size slide

  4. 想定している聴衆
    初心者向けを想定した内容です:
    "Web
    サー
    ビスの監視"
    について思いを馳せたことのない学生さん
    Web
    サー
    ビスの監視についての知見が欲しい/
    意見交換がしたい,

    にWeb
    アプリケー
    ション開発に従事するエンジニア
    このトー
    クをきっかけに, 「Web
    サー
    ビスの監視」
    について思いを馳せて
    みましょう!

    View full-size slide

  5. もくじ
    なぜ僕達は"
    監視"
    をするのか
    監視する時に有用なメトリック達
    どこまで検知して,
    通知する?
    Web
    サー
    ビス開発の現場での監視
    おまけ:
    まず初めてみる?
    おうち監視!

    View full-size slide

  6. Web
    サー
    ビスを監視するときに
    僕達が考えたこと
    by id:papix (@__papix__)
    株式会社はてな

    View full-size slide

  7. なぜ僕達は"
    監視"
    をするのか

    View full-size slide

  8. サー
    ビスに這い寄る障害達
    Web
    サー
    ビスには様々
    な障害が起きる:
    ネットワー
    ク/
    サー
    バの不調...
    爆発的アクセス増による高負荷...
    バグやオペレー
    ションミス...
    どれだけ優秀な人員を揃えても,
    どれだけ設備投資をしても,
    どれだ
    け慎重にオペレー
    ションしても,
    障害は必ず起きる

    View full-size slide

  9. 障害対応のサイクル
    障害対応は次のように対応される:
    障害の検知
    調査と解決
    事後対応と振り返り

    View full-size slide

  10. 障害の検知
    障害が発生したことに気づく段階
    ドッグフー
    ディングをしていて
    ユー
    ザからのお問い合わせ
    Twitter
    などのSNS
    でのユー
    ザの声
    "Web
    サー
    ビスの監視機構"
    から通知が届いて
    このトー
    クでは,
    この"
    監視"
    の部分にフォー
    カスを当てて
    話をします
    なるべく迅速に気付きたい
    "
    予兆"
    の段階で気づければ,
    実際にユー
    ザに影響が出る前に対
    処できる

    View full-size slide

  11. 調査と解決
    発生している障害の原因を調べ,
    解決するために修正やオペレー

    ョンをする段階
    憶測ではなく,
    事実に基づいて原因を見つける
    焦りがちだけれど,
    障害の対応が更なる障害を生み出さないよ
    うに,
    丁寧に
    ペアプロ/
    ペアオペなどで作業を進めていくのも有効
    このトー
    クで話す"
    監視"
    によって得られる情報は,
    このフェイズでも
    非常に役立ちます

    View full-size slide

  12. 事後対応と振り返り
    暫定対応で障害を解決した場合,
    その恒久対応が必要
    また,
    再発防止策となる実装,
    オペレー
    ションも考慮しないとい
    けない
    似たような障害が発生した時に備えて,
    障害の原因や対応を振り返
    り,
    共有することも重要
    社内障害情報共有のススメ
    http://developer.hatenastaff.com/entry/2018/02/19/180000

    View full-size slide

  13. なぜ僕達は"
    監視"
    をするのか
    障害の迅速な確認
    Web
    サー
    ビスに問題があった時, 1
    秒でも早く気付き,
    対応出来
    るようにする
    障害対応の道標
    監視の結果から手がかりを得て, 1
    秒でも早く障害を解決するこ
    とを目指す

    View full-size slide

  14. 障害対応の道標 ~
    推測するな,
    計測せよ~
    ISUCON
    でよく聞く言葉
    元はRob Pike
    氏(
    現Google, Go
    の開発者)
    の発言だそう:
    ルー
    ル1:
    プログラムがどこで時間を消費することになるか知ること
    はできない。
    ボトルネックは驚くべき箇所で起こるものである。

    たがって、
    どこがボトルネックなのかをはっきりさせるまでは、

    測を行ったり、
    スピー
    ドハックをしてはならない。
    ルー
    ル2:
    計測すべし。
    計測するまでは速度のための調整をしてはな
    らない。
    コー
    ドの一部が残りを圧倒しないのであれば、
    なおさらで
    ある。

    View full-size slide

  15. 障害対応の道標 ~
    推測するな,
    計測せよ~
    「Web
    サー
    ビスの開発/
    保守/
    運営」
    でも同様
    日頃から, Web
    サー
    ビスやそれを構成するインフラを監視する
    その情報が,
    問題発生時の助けになる
    医者の手術と一緒
    人体という複雑なシステムと立ち向かう為に,
    心拍数,
    血圧,

    温などを計測しながら手術をする
    Web
    サー
    ビスもまた複雑なのである...

    View full-size slide

  16. Web
    サー
    ビスの障害対応
    確認が必要な範囲がとにかく広い
    ネットワー
    ク,
    インフラ,
    ミドルウェア,
    アプリケー
    ション...
    全てのレイヤー
    を手探りで調べるのは非効率
    監視とその結果で,
    怪しい範囲を絞り込むことができる
    もちろん,
    そこから一気に原因を特定できる時もある

    View full-size slide

  17. Web
    サー
    ビスに必要な"
    監視"
    とは?
    個人的には,
    以下の5
    要素が重要:
    管理
    可視化
    蓄積
    検知
    通知

    View full-size slide

  18. 管理
    「Web
    サー
    ビスを構成する各種インフラ(
    サー
    バ/
    ミドルウェア)
    を紐付け
    て,
    役割や状況を明示する」
    これによって, Web
    サー
    ビスがどのように構築され,
    どのように稼働
    しているか一目瞭然となる
    加えて,
    これを"
    管理台帳のマスター"
    として,
    日々
    のオペレー
    ション
    に活用することもできる
    監視だけじゃない!
    デプロイにMackerel
    を使う話
    http://tech.mercari.com/entry/2016/11/14/120000

    View full-size slide

  19. 可視化
    「Web
    サー
    ビスとそれを構成する各種インフラの状態を,
    数値(
    メトリッ
    ク)
    として取得/
    表現し,
    統一されたインター
    フェイスで確認できる」
    これによって, Web
    サー
    ビスを構成する各種インフラの状態を,
    数値
    で言及することが出来るようになる
    障害対応で切羽詰まっている時に, 「
    詰まっていそう」「
    負荷高そ
    う」
    といった,
    抽象的な言葉は混乱を呼び起こす可能性がある
    更に,
    統一されたインター
    フェイスで,
    複数のインフラの状況を一気
    に見る/
    見比べることができる
    結果として, Web
    サー
    ビスの様子が一目瞭然になる

    View full-size slide

  20. 蓄積

    可視化のために取得したメトリックを蓄積し,
    時系列に並べて,
    表やグラ
    フで表現出来るようにする」
    これによって,
    可視化した値の特異点がグラフィカルに認識できる
    ようになる
    Web
    サー
    ビスに何か問題があれば,
    表は急激な凹凸を示す
    加えて, Web
    サー
    ビスとそのインフラの日常の傾向を追いやすくな

    日中はアクセスが増える/
    深夜は減る,
    など...

    View full-size slide

  21. 検知

    可視化のために取得したメトリックに応じて, Web
    サー
    ビスやそれを構
    成するサー
    バ/
    ミドルウェア等が異常かどうかを識別する」
    これによって, Web
    サー
    ビスやサー
    バ/
    ミドルウェア等のインフラ要
    素に対して「
    異常な状態」
    を定義できる
    メモリ使用率が80%
    を越えたら警戒状態, 90%
    を越えたら異常
    状態,
    など...
    この定義を定めるのが非常に難しい(
    後述)

    View full-size slide

  22. 通知

    検知した内容を適切に通知して,
    調査や対応を促す」
    これによって,
    開発者が常時監視していなくても,
    異常状態が発生し
    たことを認知することができる
    常時監視しなくても良いとは言え,
    誰かが気付けるような体制
    を構築することは重要
    その辺りは「
    運用」
    の話でもあるので,
    今回は割愛

    View full-size slide

  23. "
    監視"
    を実現するツー
    ル達
    それぞれ特長や,
    得意/
    不得意がある
    SaaS
    かOSS

    push
    型かpull
    型か

    View full-size slide

  24. SaaS
    かOSS

    SaaS
    管理/
    可視化/
    蓄積の仕組みがWeb
    サー
    ビスとして提供される(

    ルマネー
    ジド)
    大抵の場合,
    監視するサー
    バの台数によってコストが線形的に
    増加する
    OSS
    各自でサー
    バを用意して,
    その上に監視の仕組みを構築する(

    ルフホスティング)
    構築/
    運用コストが必要だが,
    監視するサー
    バの台数によって線
    形的にコストが増えることはない
    とはいえ, SaaS
    でもセルフホスティングが可能なものもあり, OSS
    でもフルマネー
    ジドなものもある

    View full-size slide

  25. push
    型かpull
    型か
    監視するサー
    バから,
    どのようにしてメトリックを収拾するか
    push

    各サー
    バから,
    メトリックを蓄積するサー
    バに投げる
    pull

    メトリックを蓄積するサー
    バが,
    各サー
    バにリクエストを投げ
    て取得する

    View full-size slide

  26. 具体例
    DataDog
    Mackerel
    NewRelic
    Prometheus
    Zabbix

    このトー
    クでは,
    例として筆者が使い慣れているMackerel
    を中心に取り
    上げます

    View full-size slide

  27. 監視する時に有用なメトリック達

    View full-size slide

  28. 監視する時に有用なメトリック達
    "
    監視"
    の仕組みを導入することで, Web
    サー
    ビスとそのインフラに
    関連する様々
    なメトリックを可視化/
    蓄積できる
    しかし,
    ただ単に"
    監視"
    するだけでは意味がない
    それらのメトリックの意味,
    傾向を掴まなければ,
    いざと言う時
    に役に立たない

    View full-size slide

  29. 監視する時に有用なメトリック達
    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

    View full-size slide

  30. l
    o
    a
    d
    a
    v
    g
    5
    言わずと知れた「
    ロー
    ドアベレー
    ジ」
    5
    は5
    分間平均(
    一般に, u
    p
    t
    i
    m
    e
    や w
    コマンドでは1/5/15
    分平
    均のロー
    ドアベレー
    ジが見れる)
    さっくり言えば, 「
    システム全体の負荷の様子」
    を示す
    実行待ちプロセス数と, I/O
    待ちプロセス数の合計
    = CPU
    等に余裕があれば,
    すぐに実行されるプロセス数

    View full-size slide

  31. l
    o
    a
    d
    a
    v
    g
    5
    の見どころ
    負荷が高まれば,
    その分 l
    o
    a
    d
    a
    v
    g
    5
    も上昇する
    システムやサー
    ビスの特性によっては,
    常にロー
    ドアベレー

    が高い場合もある
    瞬間的な値ではなく,
    その数値の傾向を見るのが重要
    急増した後,
    減少の幅が少ない場合
    一定のペー
    スで増加を続けている場合

    View full-size slide

  32. c
    p
    u
    CPU(
    演算処理装置)
    の使用率を表す
    用途ごとに細かく利用率が見れる:
    意味
    user
    カー
    ネル以外(
    アプリケー
    ション)
    が利用したCPU
    時間の割合
    (nice
    は含まない)
    system
    カー
    ネルが利用したCPU
    時間の割合
    iowait I/O
    待ちによってCPU
    が利用されていない時間の割合
    idle CPU
    が使われていない時間の割合(iowait
    は含まない)

    View full-size slide

  33. c
    p
    u
    意味
    nice
    優先度(nice
    値)
    が指定されたアプリケー
    ションによるCPU

    間の割合
    irq
    ハー
    ドウェア割り込みによるCPU
    時間の割合
    softirq
    ソフトウェア割り込みによるCPU
    時間の割合
    steal
    ゲストOS(
    仮想マシン)
    が割り当て待ちとなった時間の割合
    guest
    ゲストOS(
    仮想マシン)
    によるCPU
    時間の割合

    View full-size slide

  34. 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
    なども見る必要がある

    View full-size slide

  35. c
    p
    u
    の見どころ
    ロー
    ドアベレー
    ジと同じく,
    システムやサー
    ビスの特性によって値
    は変わる
    CPU
    利用率を可視化/
    蓄積し,
    日頃から傾向を掴んでおくことが
    大事(
    後述)
    また, CPU
    利用率が低い(= i
    d
    l
    e
    が多い)
    ことは,
    それもまた一種の
    問題である
    CPU
    利用率が低い =
    サー
    バを効率的に利用できていない

    負荷低すぎはもはや障害じゃないのか」
    http://mikeda.hatenablog.com/entry/2015/02/01/195102

    View full-size slide

  36. 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
    利用されてない物理メモリの容量

    View full-size slide

  37. 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
    も考慮されている

    View full-size slide

  38. 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
    サー
    ビスが稼働するサー
    バでは,
    基本的に「
    スワップは発生
    させない」
    ように意識するべき
    メモリの利用量が漸増している場合,
    メモリリー
    クなど発生してい
    ないか調査する必要がある

    View full-size slide

  39. d
    i
    s
    k
    ディスクの読み書きに関するメトリック
    単位はIOPS(= 1
    秒辺りに処理できるI/O
    の数)
    ディスクのIOPS
    性能は明示されていることが多い
    Amazon Elastic Block Storage(EBS)
    でも, IOPS
    性能が違うデ
    ィスクを選ぶことができる

    View full-size slide

  40. d
    i
    s
    k
    の見どころ
    IOPS
    の余裕がなくなると,
    ディスクの書き込み/
    読み込みが詰まる
    RDBMS(MySQL
    など)
    が動くサー
    バでは特に重要
    IOPS
    の日頃の増減傾向と,
    今後起こりうる瞬間的なIOPS
    増(Web


    ビスにとってはアクセスの急増)
    に耐えれるかどうかを見極める
    中長期的な視点で監視し,
    手を打つことが重要

    View full-size slide

  41. 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
    のことらしい
    これもまた,
    インフラ提供者によってネットワー
    ク帯域に上限が定
    められている
    クラウドの場合,
    更に課金額にも影響が出る

    View full-size slide

  42. i
    n
    t
    e
    r
    f
    a
    c
    e
    の見どころ
    Nginx
    やApache
    が動くプロキシサー
    バ,
    コンテンツを配信するサー
    バでは t
    x , r
    x
    が増えがち
    コンテンツを配信するサー
    バであれば, CDN
    を通すなどで対策
    出来る
    急激な t
    x / r
    x
    の増加があれば,
    瞬間的なアクセス増やDoS
    攻撃な
    どの可能性がある

    View full-size slide

  43. 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
    が増えて
    いく

    View full-size slide

  44. f
    i
    l
    e
    s
    y
    s
    t
    e
    m
    の見どころ
    ディスクの空き容量をすぐに増やせない場合も有り得るので,
    ある
    程度の利用率を越えたら警告するようにしておく
    定期的に u
    s
    e
    d
    の増加量を確認し,
    警告が出て,
    危険な領域に達
    する前に最大容量を増やせるのがベスト
    u
    s
    e
    d
    が急激に増えている場合, Web
    サー
    ビスやミドルウェアのロ
    グの出力設定を変更している場合などもある
    ログがより詳細に出るようになって,
    大量のログがディスク上
    に保存されている状態

    View full-size slide

  45. 監視する時に有用なメトリック達
    ここまで紹介した6
    つのメトリック以外にも, Web
    サー
    ビスやそれを
    構成するインフラの監視に有用なメトリックがあります
    アクセスログ(
    アクセス数,
    ステー
    タスコー
    ドの割合,
    レイテン
    シ)
    外形監視
    uptime
    サー
    ビス/
    ミドルウェアに特化したメトリック

    View full-size slide

  46. アクセスログ
    Nginx
    など,
    プロキシのアクセスログからメトリックを取得する
    Mackerel
    なら:
    https://github.com/mackerelio/mackerel‑agent‑
    plugins/tree/master/mackerel‑plugin‑accesslog

    View full-size slide

  47. アクセスログ
    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%
    の秒数

    View full-size slide

  48. アクセスログの見どころ
    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
    が上限に達した
    場合,
    レイテンシに影響が出て来る

    View full-size slide

  49. 外形監視
    実際にWeb
    サー
    ビスにリクエストを行い,
    期待するレスポンスが得
    られるか確認する
    レスポンスのステー
    タスコー
    ドなどを確認

    View full-size slide

  50. 外形監視の見どころ
    外形監視の結果が異常であれば,
    即ち現在進行系でユー
    ザに影響が
    出ているということ
    とはいえ,
    ネットワー
    クの状態等で偽陽性となることもある
    レスポンスタイムが遅くなっているなら,
    レイテンシの様子なども
    見て調査を検討する必要がある

    View full-size slide

  51. uptime
    Linux
    などのOS
    が,
    どれくらいの時間稼働しているかを示す
    Mackerel
    なら:
    https://github.com/mackerelio/mackerel‑agent‑
    plugins/tree/master/mackerel‑plugin‑uptime

    View full-size slide

  52. uptime
    の見どころ
    uptime
    が0
    になるということは, OS
    が再起動されたということ
    つまり,
    サー
    バが再起動されたということ
    意図しない再起動であれば,
    調査をする必要がある

    View full-size slide

  53. サー
    ビス/
    ミドルウェアに特化したメトリック
    Mackerel
    の場合,
    プラグインでサー
    ビス/
    ミドルウェアに特化したメ
    トリックを取得できる
    https://github.com/mackerelio/mackerel‑agent‑plugins
    Nginx/Apache/h2o
    といったプロキシ, MySQL/PostgresSQL
    といっ
    たRDBMS, Redis/Memcached
    といったKVS, AWS
    の各サー
    ビスな
    どを対象にしたプラグインが提供されている

    View full-size slide

  54. 任意のメトリックを取得したい! ~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
    などで公開していることがある

    View full-size slide

  55. どこまで検知して,
    通知する?

    狼少年にならないために~

    View full-size slide

  56. 正しく検知する難しさ
    Web
    サー
    ビスを監視する時に一番難しいのは, 「
    検知の条件」
    を組み
    立てる部分では...?
    Web
    サー
    ビスやそれを構成するインフラが,
    異常な状態であれ
    ば必ず検知したい(
    当たり前)
    日常的に発生するピー
    ク,
    サー
    ビスの成長による(
    想定の範囲内
    の)
    負荷の上昇は異常な状態としたくない
    障害として検知する条件を...
    厳しくすると,
    実際には問題がないのに,
    障害として検知され,
    通知が行われてしまう(=
    狼少年検知)
    緩くすると,
    実際に障害が発生するのに,
    それを検知できなくな
    ってしまう
    一般には「
    厳しくしすぎて,
    狼少年通知が多発する」
    パター
    ンが多い気がします...

    View full-size slide

  57. 狼少年検知

    狼少年」
    の寓話

    狼が来た!」
    と嘘をついて騒ぎを起こし続けて,
    遂に本当に狼が
    来た時に, 「
    狼が来た!」
    と言っても誰も相手をしてくれなかった

    狼少年検知」
    Web
    サー
    ビスやそのインフラのメトリックに問題がないのに,
    異常があると検知され,
    その通知が飛ぶ状態が続くと,
    それに慣
    れてしまう
    本当に対処するべき問題とその通知が,
    問題がない通知に埋も
    れてしまう

    View full-size slide


  58. 狼少年検知」
    を防ぐには?
    検知の条件/
    通知の条件を定期的に棚卸しする

    狼少年」
    にならないように,
    異常状態として検知条件を緩和す
    る(
    メトリックがより高い数値になったら通知をするようにす
    る)
    前述の通り,
    緩和しすぎると逆に異常状態であることに気づけ
    なくなってしまう
    逆に, Web
    サー
    ビスやインフラの整備で,
    平常時のメトリックの値が
    低く推移するようになったら,
    通知条件を厳格化する必要がある
    棚卸しに活かすためにも,
    サー
    ビスの負荷の傾向を追う必要がある

    View full-size slide

  59. サー
    ビスの負荷の傾向を追う
    メトリックが常に同じ値を示し続けることはない
    様々
    な単位で凹/
    凸のピー
    クがある
    サー
    ビスの負荷(
    メトリックの変化)
    の傾向を把握することが重要
    通知の条件を見直す材料になる
    メトリックに異常値が発生したときの判断材料になる

    View full-size slide

  60. 年単位の傾向
    年単位のイベントによって負荷が変動することがある
    例:
    年末年始のLINE,
    メー
    ル送信

    あけおめメー
    ル」
    を送受信するので,
    負荷が高まる

    View full-size slide

  61. 月単位
    月単位のイベントによって負荷が変動することがある
    例:
    月末/
    月初
    Web
    サー
    ビスに月単位のイベントが存在するとき,
    それによっ
    て負荷が高まる可能性がある

    View full-size slide

  62. 日単位
    週単位のイベントによって負荷が変動することがある
    例: B2B
    サー
    ビスであれば,
    週末や祝日は負荷が低まる
    企業向けのサー
    ビスなので,
    企業が休業であることの多い休日
    は利用することが少ない

    View full-size slide

  63. 時間単位
    時間単位のイベントによって負荷が変動することがある
    例:
    昼休み
    ブログなどは,
    昼休みに閲覧するユー
    ザが多いので, 12
    時前後に
    ピー
    クが現れる
    例:
    深夜帯
    深夜帯は日中に比べて負荷が低まることが多い(
    ユー
    ザが寝て
    いるので)

    View full-size slide

  64. 検知からの通知
    メトリックの変化を検知できれば, Web
    サー
    ビスの問題発生をいち
    早く気づくことができる
    しかし,
    可視化されたメトリックを四六時中眺め続けているの
    は現実的ではない

    適切に」
    通知をして,
    メトリックから問題を検知した時に気づ
    けるようにしないといけない

    View full-size slide

  65. 監視の結果を通知したい! ~Mackerel
    では?~
    メトリックの値が一定値を越えたり,
    外形監視の結果に問題があっ
    た時, Warning/Critical
    の通知を送ることができる
    対応している送付先:
    メー
    ル, Slack, HipChat, PagerDuty,
    ChatWork, TypeTalk, OpsGenie, Reactio, Yammer, LINE,
    Twilio
    Twilio
    を使うことで,
    電話での通知も対応することができ

    Webhook
    の送信にも対応しているので,
    独自の通知サー
    ビスと
    連携することも可能

    View full-size slide


  66. 通知をしない」
    という選択肢
    メトリックが異常値になり,
    異常状態と検知されることが明らかな
    場合,
    一時的に通知をOff
    にすることも有効
    瞬間的に高負荷になることが事前に明らかになっている場合
    プレスリリー
    スが出る,
    テレビ/
    ニュー
    スで紹介される等...
    Mackerel
    なら...
    監視ルー
    ル単位で時間指定ミュー
    トをおこなえるようになりま
    した ほか
    https://mackerel.io/ja/blog/entry/weekly/20180219

    View full-size slide

  67. Web
    サー
    ビス開発の現場での監視

    はてなブログの場合~

    View full-size slide

  68. はてなブログ
    今年でリリー
    スから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
    も活用中

    View full-size slide

  69. Mackerel
    を活用した取り組み ‑ PWG
    Performance Working Group
    毎月1
    回開催
    (
    はてなブログ担当の)Web
    オペレー
    ションエンジニアも参加
    Mackerel
    のグラフを見ながら,
    パラメー
    タの変化を確認
    対応が必要なものはGHE
    にIssue
    を立てて着手
    たくさんのホスト/
    メトリックがあるので,
    重要度の高いものをダッ
    シュボー
    ドにまとめている

    View full-size slide

  70. ダッシュボー
    ドの様子

    View full-size slide

  71. グラフアノテー
    ション
    "
    可視化"
    の観点で非常に便利な機能
    デプロイの度にアノテー
    ションを残す
    Description
    として,
    そのデプロイに紐付いたPull Request

    URL
    を記載
    グラフに急激な変化があった時,
    その原因となったPull Request
    を推
    測しやすい

    View full-size slide

  72. グラフアノテー
    ションの様子

    View full-size slide

  73. サー
    ビスメトリック
    よくあるサー
    ビスメトリックははてなブログでも投稿しています
    ステー
    タスコー
    ドの割合,
    レスポンスタイム...

    View full-size slide

  74. デプロイにかかる時間
    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

    View full-size slide

  75. 更新が必要な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

    View full-size slide

  76. おまけ:
    まず初めてみる?
    おうち監視!

    View full-size slide

  77. まず初めてみる?
    おうち監視!
    「Web
    サー
    ビス監視」
    のツー
    ル/
    サー
    ビスは,
    身近なところから試して
    みよう
    契約しているVPS
    とか, Mac
    とか...
    一方で, "
    自宅の監視"
    から試してみるのも手です!

    View full-size slide

  78. 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"
    の上で動かすなどの手もある

    View full-size slide

  79. mackerel‑plugin‑nasne

    View full-size slide

  80. mackerel‑plugin‑nasne
    https://github.com/ayumu83s/mackerel‑plugin‑nasne
    ソニー
    のHDD
    レコー
    ダー, "nasne"
    を監視するplugin(Go
    製)
    録画に成功/
    失敗した番組の数, HDD
    の残り容量などを監視でき

    View full-size slide

  81. mackerel‑plugin‑nature‑remo

    View full-size slide

  82. mackerel‑plugin‑nature‑remo
    https://github.com/papix/mackerel‑plugin‑nature‑remo
    スマー
    トリモコン"Nature Remo"
    を監視するplugin(
    拙作, Go
    製)
    Nature Remo
    にある,
    温度/
    湿度の測定機能の結果をMackerel
    に投稿できる

    View full-size slide

  83. Netatmo
    温度,
    湿度,
    気圧,
    二酸化炭素,
    騒音を測定できるガジェット
    10
    分毎に値が更新, API
    経由で取得できる

    View full-size slide

  84. Netatmo
    はてなでは...
    社内の各フロアに設置されていて,
    一定の数値を越えるとSlack
    に通知が飛ぶ

    View full-size slide

  85. さいごに

    View full-size slide

  86. さいごに
    以下のテー
    マについて話しました:
    なぜ僕達は"
    監視"
    をするのか
    監視する時に有用なメトリック達
    どこまで検知して,
    通知する?
    Web
    サー
    ビス開発の現場での監視

    View full-size slide

  87. さいごに
    Web
    サー
    ビスが公開され,
    利用者がいる以上,
    障害は必ず起きます
    その時に備えて, "
    監視"
    についてしっかり取り組む必要がある
    Web
    サー
    ビスの特性,
    利用しているインフラ/
    ミドルウェアの特性,
    開発チー
    ムの特性など,
    様々
    な変数によって最適な"
    監視"
    は変わる
    変化を恐れず,
    試行錯誤をしていきましょう!
    知見を共有して,
    より良い"
    監視"
    を目指していきたいものです...

    View full-size slide

  88. おわり
    ご清聴ありがとうございました!

    View full-size slide

  89. あわせてよみたい
    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/

    View full-size slide