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