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

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

Transcript

1. 1 Mackerel テクニカルサポートの裏側と醍醐味 2018-07-18／サポートエンジニアNight vol.3 株式会社はてな 井上 ⼤輔（a-know / @a_know）
2. 2 今⽇私がお話しすること 1. いろいろご紹介 • ⾃⼰紹介 • 担当サービス・Mackerel についての紹介 • 私の職種・CRE についての紹介 2. Mackerelテクニカルサポートの裏側と醍醐味 〜 学びの深かったサポートケースのご紹介 3. まとめ
3. 3 ⾃⼰紹介 • 井上⼤輔 • @a_know（Twitter）/ a-know（Hatena, GitHub） • 株式会社はてな シニアエンジニア • Mackerelチーム CRE • 略歴 – 製造系システムエンジニア：約6年 – Webアプリケーションエンジニア：約5年 – 現職：約2年 〜
4. 4 Mackerel（マカレル）？
5. 5 Mackerel • サーバー死活監視 • パフォーマンスモニタリング • アラート・通知 • インフラ統合管理 • etc.
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
7. 7 公式エージェントソフトウェア （mackerel-agent） Push （API・ HTTPS） plugin ・ ・ ・
8. 8 簡単なインストール
9. 9 私の職種・CRE についての紹介
10. 10 CREについてのご紹介・主な業務 l CRE = Customer Reliability Engineer l CRE としての Mackerel チームでの業務は多種多様！ ü 顧客活動（プリセールス／ポストセールス） ü テクニカルサポート／カスタマーサポート（カスタマーサクセス） ü 技術⽂書の作成・メンテナンス ü 開発への参加（コードを書く、開発チームのスクラムイベントに参加 など） ü etc.
11. 11 はてな・Mackerel の CRE のミッション l （「主な業務」のような活動を通じて）お客さまの、サービスに 対する信頼性の向上を図る l 『技術プロダクト』であるMackerelのカスタマーサクセスを、 エンジニアとして・エンジニアリングを活かして推進する l カスタマーサクセスの効率化をエンジニアリングで実現する
12. 12 なぜ『CRE』なのか？ l ⼀⾔では⾔い尽くせない、いろんな考え、モチベーションがありますが…… l その中でも⼤きなものが、「これまでのような、"⾃分⾃⾝が開発業務などをおこなう ことによる成⻑" とはちょっと違った "エンジニアとして成⻑" ができそうだったから」 ということがあります l このお話の最後に、改めて触れたいと思います
13. 13 と、いうことで l Mackerel の CRE としてこれまで n千件のサポートをやってきた中でも 特に、悩まされた・学びの深かった（成⻑につながった）サポートケースを いくつか、ご紹介します
14. 14 学びの深かったサポートケース・その① 〜 CPU の steal 値の⾼騰
15. 15 l 複数のお客さまから、以下のようなお問い合わせが。 ü 「⼤した処理はおこなっていないサーバーなのに、CPU使⽤率が フルに⾼騰してしまっている」 ü 「内訳をみると、⾼騰しているのは steal のようだ」 l この情報で、みなさんはどのような状況を想像されるでしょうか......？ 学びの深かったサポートケース・その① 〜 CPU の steal 値の⾼騰
16. 16 l ハイパーバイザ型の仮想環境において、ゲストOSに対し、ハイパー バイザから⼗分なCPUリソースを割り当てられていなかった場合に、 ゲストOS側でカウントされるもの CPU 使⽤率・steal とは
17. 17 l 「Amazon EC2 の t2 インスタンスにおいて、CPU クレジットが 枯渇しているのでは？」 steal値⾼騰の原因として私が想像したこと（よくある話） T2 インスタンスは、ベースラインを超えてバーストする能⼒がある CPU パフォーマンスのベースライン を提供する、バーストパフォーマンスインスタンスです。ベースラインパフォーマンスとバースト機能は、 CPU クレジットにより管理されます。T2 インスタンスは、アイドル状態のときに CPU クレジットを 蓄積し、アクティブなときに CPU クレジットを使⽤します。 -- https://aws.amazon.com/jp/ec2/instance-types/t2/
18. 18 l 各 t2 インスタンスは「ベースライン」というCPUパフォーマンスの 基準値が定められている l ex. t2.micro だと 10% l CPUクレジットを消費することで、このベースラインを超えてCPU リソースを利⽤することができる l ベースライン以上のCPUリソースが必要であるにも関わらず、CPU クレジットが枯渇している場合には、その性能はベースラインにまで 抑えられ、確保できなかったCPUリソースは steal として計上される t2 インスタンスの特性
19. 19 l お問い合わせはいずれも t2 インスタンス環境での事象 l 後から考えると、これは "たまたま" であった…… l 「今現在は⼤した処理をおこなっていなくても、それより以前に重い 処理を実⾏するなどして今はCPUクレジットが枯渇していて、ベース ラインのパフォーマンスしか発揮できない状態になっているのでは」 l 「CPU クレジットの状態を確認してほしい」と連絡 そのときの私が考えたこと
20. 20 l 枯渇していない（クレジット満タン）！ l ⼀気に焦る！ l t1 世代では他テナントの影響を受けて、今回のような現象が起こることもある、 とは聞いたことがあるが...... l 「その他に steal が⾼騰する可能性がある状況って⼀体……？」 l いろいろ調べてみたりしたが原因を特定するに⾄れず、Mackerel チームのアプリケーションエンジニア（id:itchyny, id:syou6162）に 調査を依頼 確認してもらった結果……
21. 21 Linux カーネル、steal パフォーマンスカウンタに おけるバグ！ 調査結果
22. 22 l そもそもCPU使⽤率はどこから取得・計算しているか l 取得元は /proc/stat l 8番⽬の数値が steal の値 l これらは基本的にパフォーマンスカウンタ・カウンターメトリック。 増加していくのみ l mackerel-agent ではこの値の差を毎分取り、使⽤率としての計算に⽤いている どんなバグだったのか？
23. 23 l 増加のみを前提としているパフォーマンスカウンタにおいて、この値 が減少するバグがLinuxカーネルに存在していた Ø これにより、差分の計算時にオーバーフローを起こし、stealの使⽤率の⾼騰 （しているように⾒える現象の発⽣）につながった l Mackerelのサポート窓⼝への連絡時点ですでに bug fix はされていた Ø カーネルのアップデートを案内、それにより解決してもらうことができた どんなバグだったのか？
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 今回の事象の原因
25. 25 l 何事にも（特にコードで動作しているものであればなおさら）、どん なに不可解な現象に⾒えても必ず理由がある l （当たり前のことなのですが）Linuxカーネルもコードで出来ている l とことん突き詰めていく姿勢が⼤事 l 仕組みを理解し（今回のケースだと /proc/stat の値をもとに CPU 使⽤率が計算さ れている、といったこと）、 l ⽬の前で起きている事象がどういうものか・原因として考えられるものはなにか・ 少なくとも原因ではないことはなにか、といったことをひとつずつ切り分けていく ことが⼤事 今回のサポートケースからの学び
26. 26 学びの深かったサポートケース・その② 〜 ロードアベレージの周期的な上昇
27. 27 Linuxのloadavgが約7時間ごとに上昇する現象の原因 ‒ Mackerel 公式ブログ https://mackerel.io/ja/blog/entry/tech/high-loadavg-every-7-hours このブログエントリについてのお話です
28. 28 l とあるお客さまから、以下のようなお問い合わせが。 ü 「⼤した処理はおこなっていないサーバーなのに、loadavg （ロードアベレージ）が定期的に上昇する」 ü 「mackerel-agent をインストールしてからこの事象が発⽣する ようになった」「mackerel-agent に原因があるのではないか？」 • loadavg : 実⾏待ちの（実⾏キュー内にある）プロセスの数とディスクのI/O 待ちのプロセスの数の合計値 • 定期的：約7時間周期 • もちろん cron ジョブも設定されていない 学びの深かったサポートケース・その② 〜 ロードアベレージの周期的な上昇
29. 29 ü mackerel-agent のメトリック取得・送信は毎分。 ü ログ監視・プロセス監視などのチェック監視は実⾏間隔（interval）を指定 することもできる Ø が、これらに指定可能な最⼤値は60分 ü それ以外に周期的になにかをおこなう、といったものはない...... ü 「mackerel-agent をインストールしてからこの事象が発⽣するように なった」というよりは、「mackerel-agent を導⼊したことで、それまで に発⽣していたこのような事象がグラフとして⾒えるようになった」 （mackerel-agent を起因とする現象ではない）のでは......？ 私が考えたこと
30. 30 ü キレイに約7時間周期で起きていたので、次の⾼騰が疑われそうなタイ ミングで実⾏中プロセスリストなどを出⼒していただくよう依頼、その 提出を受けた ü 提供いただいた情報を確認するも......、、 Ø 怪しいプロセスなし！ Ø わからない......なにも......。。 私がやったこと
31. 31 ü お客さまから追加の情報が。 Ø 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣するようだ」 Ø ますますわからない！ ü そんなこんなしていると、別のお客様からも同様のお問い合わせが。 Ø このまま⾃⼒でなんとかしようと粘っても、問題解決までの所要時間をいたずらに伸 ばしてしまうばかり Ø もし mackerel-agent の実装に問題があっての現象だとしたら、その修正着⼿ までも遅れてしまう Ø 全くわからないし、これ以上⾃分だけであれこれしても解決のいとぐちすら⾒つから なさそうなので、アプリケーションエンジニア（id:itchyny）にも⾒てもらうことに 私がやったこと
32. 32 Linux カーネルのロードアベレージ算出の仕様！ 調査結果
33. 33 l （詳しくはブログ記事をぜひ⾒ていただきたいのですが......） l Linux の loadavg とはどんな値か？ Ø run queue 上のプロセス (running or runnable process) とディスクI/Oやロック 待ちのプロセス (uninterruptible process) の総数の、指数移動平均値 ロードアベレージとは・その算出のしくみ
34. 34 l そして、loadavg の値は定期的に更新されている Ø 更新間隔は `5*HZ+1` ごと Ø `HZ` はカーネルのタイマー周波数 `CONFIG_HZ` 、1秒に何tick増えるか、 という値 l つまり、loadavg は5秒と1tickごとに更新される、ということ Ø この「1tick」が、約7時間（厳密には6時間57分）ごとにloadavgが上昇する現象の 原因！ ロードアベレージとは・その算出のしくみ
35. 35 l 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣ するようだ」 l mackerel-agent は、1分ごとに、プラグインのプロセスを開いている l loadavg の再計算が5秒ぴったりから少しだけズレている・そのズレが 蓄積することで、以下のタイミングが定期的に⼀致する！ l 【mackerel-agent】プラグインによるメトリック収集を開始するタイミング l 【Linuxカーネル】loadavgの再計算のタイミング そして判明していく原因
36. 36 公式エージェントソフトウェア （mackerel-agent） Push （API・ HTTPS） plugin ・ ・ ・
37. 37 l 「mackerel-agentにプラグインを設定しているときにこの事象は発⽣ するようだ」 l mackerel-agent は、1分ごとに、プラグインのプロセスを開いている l loadavg の再計算が5秒ぴったりから少しだけズレている・そのズレが 蓄積することで、以下のタイミングが定期的に⼀致する！ l 【mackerel-agent】プラグインによるメトリック収集を開始するタイミング l 【Linuxカーネル】loadavgの再計算のタイミング そして判明していく原因
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の再計算のタイミングが重なる＝計上される値が上振れる！ もう少し具体的に
39. 39 l なぜ loadavgの更新間隔はぴったり5秒間隔の更新ではないのか？ l 気になるこのあたりの事柄についても、先程の Mackerel 公式ブログ （Author id:itchyny ）に詳しく記載されているので、ぜひ⾒てみて ください！ なぜ？？ https://mackerel.io/ja/blog/entry/tech/high-loadavg-every-7-hours
40. 40 l 何事にも（特にコードで動作しているものであればなおさら）、どん なに不可解な現象に⾒えても必ず理由がある l （当たり前のことなのですが）Linuxカーネルもコードで出来ている l とことん突き詰めていく姿勢が⼤事 今回のサポートケースからの学び
41. 41 l まるで成⻑していない......（反省！） l 正直なところ、とても難しい l 詳細かつ丁寧な解説記事を読んでもすぐには理解できないほどに...... l 今後は独⼒で解明 ＆ ⾃分がこのようなブログ記事を書けるように 頑張りたい つまり同じ！
42. 42 学びの深かったサポートケース・番外編 〜『わからない』問い合わせ内容
43. 43 ü Mackerel には、のようなサポート 窓⼝問い合わせフォームがあります Ø ここを通じて⽇々様々なお問い合わせを 受け付けている Ø 受付内容は slack 連携機能により slack チャンネルにも共有されるようになって いる 学びの深かったサポートケース・番外編 〜『わからない』問い合わせ内容
44. 44 l ある⽇、このようなお問い合わせが。（再現・⽂⾔は変えてあります） 学びの深かったサポートケース・番外編 〜『わからない』問い合わせ内容
45. 45 l そんな項⽬はないはず……？ け、件名？
46. 46 l ここの部分？！ もしかして！
47. 47 l Mackerelチーム専属のデザイナーとも 共有して、すぐにのような形に改善 l この変更以降、同様のお問い合わせは 今のところなし 改善しよう！
48. 48 l こちらに⾒えているものが、利⽤される⽅にとって「そのまま」⾒えている とは限らなかったりする l 逆もしかり…… l 開発側・利⽤者側、それぞれ双⽅に異なるバイアスが掛かっていたりする こともある l それを敏感に感じ取り、うまくサービスに反映させられるかどうかで、 使い勝⼿やサービスに対する信頼性も⼤きく変わる（と思っています） 今回のサポートケースからの学び
49. 49 l 今⽇ご紹介したものは、⽇々のお問い合わせの中でも特に特徴のある ものでした l 他のエンジニアに頼ってばかりなように⾒えたかもしれませんが…… l 最初はわからなかったものでも、今ではスイスイ回答できるようになった、という ものも（もちろん）たくさんあります l エスカレーション率は5%未満 l 今では、むずかしそうなお問い合わせがあると少しワクワクしてしま う⾃分もいます 以上、3件のサポートケースのご紹介でした
50. 50 まとめ
51. 51 ü ⼊社以降、私が直⾯したサポートケースのうちの難解なもの（学びの 深かったもの）のいくつかをご紹介しました ü こうして寄せられる様々な（そして不可解な（ように思える））事象と その原因を、いっしょに取り組み、思考のプロセスと共に明らかにして くれる同僚エンジニアがいる ü それにより、今⽇も私はありがたい学びにありつけられています Ø 「学び」を⾃⾝の⾎⾁に変えられるかどうかは⾃分次第！ 今⽇のお話のまとめ
52. 52 なぜ『CRE』として働くのか？ l 「サーバー監視サービス・Mackerel」のテクニカルサポートに携わるということは、 「サーバー」を取り巻く技術に向き合う、ということ。 Ø エンジニアとしての成⻑機会も多い l Mackerel を採⽤いただいているお客さまは、いずれもそうそうたる企業ばかり l そんな各社のインフラ運⽤の最前線の状況（⼯夫していることや悩みなど）を、⽇頃の コミュニケーションから知ることができる l そして、解決のためのお⼿伝いができる・様々な提案をおこなうことができる Ø 他者の⼿助けができる ＝ 対象について⼀定以上の理解ができている Ø そうなる過程で多くのインプットができる（せざるを得ない！） l ……といったことを、今⽇のお話からも感じ取ってもらえていれば嬉しいです
53. 53 l 「サポートエンジニア」（はてな・Mackerel では「CRE」）というお仕事は、 「お問い合わせ内容をもとに、エンジニアやデザイナーと会話しつつサービス やドキュメントなどをどんどん改善していく」という、このロールならではの やりがいもあります l お客さまからのフィードバックをもとに、サービスがどんどん良いものに 変わっていく様を⾒ていると、サービスは “⽣きている” んだなということを 実感します l それをお客さまにも実感していただけるとうれしい！ そういうところにも 喜びを感じられる働き⽅だと思っています このようなロールとして働くことへの思い