Mackerelテクニカルサポートの裏側と醍醐味/support-engineer-night3-mackerel

 Mackerelテクニカルサポートの裏側と醍醐味/support-engineer-night3-mackerel

サポートエンジニアNight vol.3 presented by TREASURE DATA “PLAZMA” ( https://techplay.jp/event/676489 )での登壇資料です。

Dffbff07156358d0b83f728a3b3b0b8c?s=128

Daisuke Inoue

July 18, 2018
Tweet

Transcript

  1. 2.

    2 今⽇私がお話しすること 1. いろいろご紹介 • ⾃⼰紹介 • 担当サービス・Mackerel についての紹介 •

    私の職種・CRE についての紹介 2. Mackerelテクニカルサポートの裏側と醍醐味 〜 学びの深かったサポートケースのご紹介 3. まとめ
  2. 3.

    3 ⾃⼰紹介 • 井上⼤輔 • @a_know(Twitter)/ a-know(Hatena, GitHub) • 株式会社はてな

    シニアエンジニア • Mackerelチーム CRE • 略歴 – 製造系システムエンジニア:約6年 – Webアプリケーションエンジニア:約5年 – 現職:約2年 〜
  3. 6.

    6 $ cat /proc/meminfo MemTotal: 1015472 kB MemFree: 81576 kB

    MemAvailable: 82920 kB Buffers: 0 kB Cached: 94076 kB SwapCached: 27000 kB Active: 419108 kB Inactive: 391240 kB Active(anon): 359752 kB Inactive(anon): 366444 kB Active(file): 59356 kB Inactive(file): 24796 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2097148 kB SwapFree: 1857868 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 708588 kB Mapped: 23396 kB Shmem: 9924 kB Slab: 79900 kB SReclaimable: 31160 kB SUnreclaim: 48740 kB KernelStack: 5920 kB PageTables: 10372 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 2604884 kB Committed_AS: 1375884 kB VmallocTotal: 34359738367 kB VmallocUsed: 10772 kB VmallocChunk: 34359709948 kB HardwareCorrupted: 0 kB AnonHugePages: 92160 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 90112 kB DirectMap2M: 958464 kB 公式エージェントソフトウェア (mackerel-agent) Push (API・ HTTPS) Parse
  4. 10.

    10 CREについてのご紹介・主な業務 l CRE = Customer Reliability Engineer l CRE

    としての Mackerel チームでの業務は多種多様! ü 顧客活動(プリセールス/ポストセールス) ü テクニカルサポート/カスタマーサポート(カスタマーサクセス) ü 技術⽂書の作成・メンテナンス ü 開発への参加(コードを書く、開発チームのスクラムイベントに参加 など) ü etc.
  5. 15.
  6. 17.

    17 l 「Amazon EC2 の t2 インスタンスにおいて、CPU クレジットが 枯渇しているのでは?」 steal値⾼騰の原因として私が想像したこと(よくある話)

    T2 インスタンスは、ベースラインを超えてバーストする能⼒がある CPU パフォーマンスのベースライン を提供する、バーストパフォーマンスインスタンスです。ベースラインパフォーマンスとバースト機能は、 CPU クレジットにより管理されます。T2 インスタンスは、アイドル状態のときに CPU クレジットを 蓄積し、アクティブなときに CPU クレジットを使⽤します。 -- https://aws.amazon.com/jp/ec2/instance-types/t2/
  7. 18.

    18 l 各 t2 インスタンスは「ベースライン」というCPUパフォーマンスの 基準値が定められている l ex. t2.micro だと

    10% l CPUクレジットを消費することで、このベースラインを超えてCPU リソースを利⽤することができる l ベースライン以上のCPUリソースが必要であるにも関わらず、CPU クレジットが枯渇している場合には、その性能はベースラインにまで 抑えられ、確保できなかったCPUリソースは steal として計上される t2 インスタンスの特性
  8. 19.

    19 l お問い合わせはいずれも t2 インスタンス環境での事象 l 後から考えると、これは "たまたま" であった…… l

    「今現在は⼤した処理をおこなっていなくても、それより以前に重い 処理を実⾏するなどして今はCPUクレジットが枯渇していて、ベース ラインのパフォーマンスしか発揮できない状態になっているのでは」 l 「CPU クレジットの状態を確認してほしい」と連絡 そのときの私が考えたこと
  9. 20.

    20 l 枯渇していない(クレジット満タン)! l ⼀気に焦る! l t1 世代では他テナントの影響を受けて、今回のような現象が起こることもある、 とは聞いたことがあるが...... l

    「その他に steal が⾼騰する可能性がある状況って⼀体……?」 l いろいろ調べてみたりしたが原因を特定するに⾄れず、Mackerel チームのアプリケーションエンジニア(id:itchyny, id:syou6162)に 調査を依頼 確認してもらった結果……
  10. 22.

    22 l そもそもCPU使⽤率はどこから取得・計算しているか l 取得元は /proc/stat l 8番⽬の数値が steal の値

    l これらは基本的にパフォーマンスカウンタ・カウンターメトリック。 増加していくのみ l mackerel-agent ではこの値の差を毎分取り、使⽤率としての計算に⽤いている どんなバグだったのか?
  11. 24.

    24 l バグレポート Ø https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608 l 解説記事 Ø https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a- paravirtualized-xen-guest/

    l Linuxカーネルに当てられたパッチ Ø https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5 e25f5db6abb96ca8ee2aaedcb863daa6dfcc07a 今回の事象の原因
  12. 25.

    25 l 何事にも(特にコードで動作しているものであればなおさら)、どん なに不可解な現象に⾒えても必ず理由がある l (当たり前のことなのですが)Linuxカーネルもコードで出来ている l とことん突き詰めていく姿勢が⼤事 l 仕組みを理解し(今回のケースだと

    /proc/stat の値をもとに CPU 使⽤率が計算さ れている、といったこと)、 l ⽬の前で起きている事象がどういうものか・原因として考えられるものはなにか・ 少なくとも原因ではないことはなにか、といったことをひとつずつ切り分けていく ことが⼤事 今回のサポートケースからの学び
  13. 28.

    28 l とあるお客さまから、以下のようなお問い合わせが。 ü 「⼤した処理はおこなっていないサーバーなのに、loadavg (ロードアベレージ)が定期的に上昇する」 ü 「mackerel-agent をインストールしてからこの事象が発⽣する ようになった」「mackerel-agent

    に原因があるのではないか?」 • loadavg : 実⾏待ちの(実⾏キュー内にある)プロセスの数とディスクのI/O 待ちのプロセスの数の合計値 • 定期的:約7時間周期 • もちろん cron ジョブも設定されていない 学びの深かったサポートケース・その② 〜 ロードアベレージの周期的な上昇
  14. 29.

    29 ü mackerel-agent のメトリック取得・送信は毎分。 ü ログ監視・プロセス監視などのチェック監視は実⾏間隔(interval)を指定 することもできる Ø が、これらに指定可能な最⼤値は60分 ü

    それ以外に周期的になにかをおこなう、といったものはない...... ü 「mackerel-agent をインストールしてからこの事象が発⽣するように なった」というよりは、「mackerel-agent を導⼊したことで、それまで に発⽣していたこのような事象がグラフとして⾒えるようになった」 (mackerel-agent を起因とする現象ではない)のでは......? 私が考えたこと
  15. 31.

    31 ü お客さまから追加の情報が。 Ø 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣するようだ」 Ø ますますわからない! ü そんなこんなしていると、別のお客様からも同様のお問い合わせが。 Ø

    このまま⾃⼒でなんとかしようと粘っても、問題解決までの所要時間をいたずらに伸 ばしてしまうばかり Ø もし mackerel-agent の実装に問題があっての現象だとしたら、その修正着⼿ までも遅れてしまう Ø 全くわからないし、これ以上⾃分だけであれこれしても解決のいとぐちすら⾒つから なさそうなので、アプリケーションエンジニア(id:itchyny)にも⾒てもらうことに 私がやったこと
  16. 33.

    33 l (詳しくはブログ記事をぜひ⾒ていただきたいのですが......) l Linux の loadavg とはどんな値か? Ø run

    queue 上のプロセス (running or runnable process) とディスクI/Oやロック 待ちのプロセス (uninterruptible process) の総数の、指数移動平均値 ロードアベレージとは・その算出のしくみ
  17. 34.

    34 l そして、loadavg の値は定期的に更新されている Ø 更新間隔は `5*HZ+1` ごと Ø `HZ`

    はカーネルのタイマー周波数 `CONFIG_HZ` 、1秒に何tick増えるか、 という値 l つまり、loadavg は5秒と1tickごとに更新される、ということ Ø この「1tick」が、約7時間(厳密には6時間57分)ごとにloadavgが上昇する現象の 原因! ロードアベレージとは・その算出のしくみ
  18. 35.

    35 l 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣ するようだ」 l mackerel-agent は、1分ごとに、プラグインのプロセスを開いている l loadavg の再計算が5秒ぴったりから少しだけズレている・そのズレが

    蓄積することで、以下のタイミングが定期的に⼀致する! l 【mackerel-agent】プラグインによるメトリック収集を開始するタイミング l 【Linuxカーネル】loadavgの再計算のタイミング そして判明していく原因
  19. 37.

    37 l 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣ するようだ」 l mackerel-agent は、1分ごとに、プラグインのプロセスを開いている l loadavg の再計算が5秒ぴったりから少しだけズレている・そのズレが

    蓄積することで、以下のタイミングが定期的に⼀致する! l 【mackerel-agent】プラグインによるメトリック収集を開始するタイミング l 【Linuxカーネル】loadavgの再計算のタイミング そして判明していく原因
  20. 38.

    38 l `HZ` が1000の環境では、loadavg は5.001秒ごとに更新されるので…… u 1回⽬の更新:(最初の更新から)5.001秒後 u 2回⽬の更新:10.002秒後 u

    3回⽬の更新:15.003秒後 u ・・・ u 5000回⽬の更新:25005.000秒(6時間56分45秒)後 u 5002回⽬の更新:25015.002秒(6時間56分55秒と0.002秒)後 u 5003回⽬の更新:25020.003秒(6時間57分00秒と0.003秒) l mackerel-agent のメトリック収集間隔は毎分 l (0.003秒ずれてはいるものの、)mackerel-agent がプラグインプロセスを開く タイミングと loadavgの再計算のタイミングが重なる=計上される値が上振れる! もう少し具体的に
  21. 39.

    39 l なぜ loadavgの更新間隔はぴったり5秒間隔の更新ではないのか? l 気になるこのあたりの事柄についても、先程の Mackerel 公式ブログ (Author id:itchyny

    )に詳しく記載されているので、ぜひ⾒てみて ください! なぜ?? https://mackerel.io/ja/blog/entry/tech/high-loadavg-every-7-hours
  22. 43.

    43 ü Mackerel には、のようなサポート 窓⼝問い合わせフォームがあります Ø ここを通じて⽇々様々なお問い合わせを 受け付けている Ø 受付内容は

    slack 連携機能により slack チャンネルにも共有されるようになって いる 学びの深かったサポートケース・番外編 〜『わからない』問い合わせ内容
  23. 48.

    48 l こちらに⾒えているものが、利⽤される⽅にとって「そのまま」⾒えている とは限らなかったりする l 逆もしかり…… l 開発側・利⽤者側、それぞれ双⽅に異なるバイアスが掛かっていたりする こともある l

    それを敏感に感じ取り、うまくサービスに反映させられるかどうかで、 使い勝⼿やサービスに対する信頼性も⼤きく変わる(と思っています) 今回のサポートケースからの学び
  24. 52.

    52 なぜ『CRE』として働くのか? l 「サーバー監視サービス・Mackerel」のテクニカルサポートに携わるということは、 「サーバー」を取り巻く技術に向き合う、ということ。 Ø エンジニアとしての成⻑機会も多い l Mackerel を採⽤いただいているお客さまは、いずれもそうそうたる企業ばかり

    l そんな各社のインフラ運⽤の最前線の状況(⼯夫していることや悩みなど)を、⽇頃の コミュニケーションから知ることができる l そして、解決のためのお⼿伝いができる・様々な提案をおこなうことができる Ø 他者の⼿助けができる = 対象について⼀定以上の理解ができている Ø そうなる過程で多くのインプットができる(せざるを得ない!) l ……といったことを、今⽇のお話からも感じ取ってもらえていれば嬉しいです