10 CREについてのご紹介・主な業務 l CRE = Customer Reliability Engineer l CRE としての Mackerel チームでの業務は多種多様！ ü 顧客活動（プリセールス／ポストセールス） ü テクニカルサポート／カスタマーサポート（カスタマーサクセス） ü 技術⽂書の作成・メンテナンス ü 開発への参加（コードを書く、開発チームのスクラムイベントに参加 など） ü etc.
11 はてな・Mackerel の CRE のミッション l （「主な業務」のような活動を通じて）お客さまの、サービスに 対する信頼性の向上を図る l 『技術プロダクト』であるMackerelのカスタマーサクセスを、 エンジニアとして・エンジニアリングを活かして推進する l カスタマーサクセスの効率化をエンジニアリングで実現する
12 なぜ『CRE』なのか？ l ⼀⾔では⾔い尽くせない、いろんな考え、モチベーションがありますが…… l その中でも⼤きなものが、「これまでのような、"⾃分⾃⾝が開発業務などをおこなう ことによる成⻑" とはちょっと違った "エンジニアとして成⻑" ができそうだったから」 ということがあります l このお話の最後に、改めて触れたいと思います
15 l 複数のお客さまから、以下のようなお問い合わせが。 ü 「⼤した処理はおこなっていないサーバーなのに、CPU使⽤率が フルに⾼騰してしまっている」 ü 「内訳をみると、⾼騰しているのは steal のようだ」 l この情報で、みなさんはどのような状況を想像されるでしょうか......？ 学びの深かったサポートケース・その① 〜 CPU の steal 値の⾼騰
17 l 「Amazon EC2 の t2 インスタンスにおいて、CPU クレジットが 枯渇しているのでは？」 steal値⾼騰の原因として私が想像したこと（よくある話） T2 インスタンスは、ベースラインを超えてバーストする能⼒がある CPU パフォーマンスのベースライン を提供する、バーストパフォーマンスインスタンスです。ベースラインパフォーマンスとバースト機能は、 CPU クレジットにより管理されます。T2 インスタンスは、アイドル状態のときに CPU クレジットを 蓄積し、アクティブなときに CPU クレジットを使⽤します。 -- https://aws.amazon.com/jp/ec2/instance-types/t2/
19 l お問い合わせはいずれも t2 インスタンス環境での事象 l 後から考えると、これは "たまたま" であった…… l 「今現在は⼤した処理をおこなっていなくても、それより以前に重い 処理を実⾏するなどして今はCPUクレジットが枯渇していて、ベース ラインのパフォーマンスしか発揮できない状態になっているのでは」 l 「CPU クレジットの状態を確認してほしい」と連絡 そのときの私が考えたこと
20 l 枯渇していない（クレジット満タン）！ l ⼀気に焦る！ l t1 世代では他テナントの影響を受けて、今回のような現象が起こることもある、 とは聞いたことがあるが...... l 「その他に steal が⾼騰する可能性がある状況って⼀体……？」 l いろいろ調べてみたりしたが原因を特定するに⾄れず、Mackerel チームのアプリケーションエンジニア（id:itchyny, id:syou6162）に 調査を依頼 確認してもらった結果……
22 l そもそもCPU使⽤率はどこから取得・計算しているか l 取得元は /proc/stat l 8番⽬の数値が steal の値 l これらは基本的にパフォーマンスカウンタ・カウンターメトリック。 増加していくのみ l mackerel-agent ではこの値の差を毎分取り、使⽤率としての計算に⽤いている どんなバグだったのか？
25 l 何事にも（特にコードで動作しているものであればなおさら）、どん なに不可解な現象に⾒えても必ず理由がある l （当たり前のことなのですが）Linuxカーネルもコードで出来ている l とことん突き詰めていく姿勢が⼤事 l 仕組みを理解し（今回のケースだと /proc/stat の値をもとに CPU 使⽤率が計算さ れている、といったこと）、 l ⽬の前で起きている事象がどういうものか・原因として考えられるものはなにか・ 少なくとも原因ではないことはなにか、といったことをひとつずつ切り分けていく ことが⼤事 今回のサポートケースからの学び
29 ü mackerel-agent のメトリック取得・送信は毎分。 ü ログ監視・プロセス監視などのチェック監視は実⾏間隔（interval）を指定 することもできる Ø が、これらに指定可能な最⼤値は60分 ü それ以外に周期的になにかをおこなう、といったものはない...... ü 「mackerel-agent をインストールしてからこの事象が発⽣するように なった」というよりは、「mackerel-agent を導⼊したことで、それまで に発⽣していたこのような事象がグラフとして⾒えるようになった」 （mackerel-agent を起因とする現象ではない）のでは......？ 私が考えたこと
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の再計算のタイミング そして判明していく原因
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の再計算のタイミングが重なる＝計上される値が上振れる！ もう少し具体的に
48 l こちらに⾒えているものが、利⽤される⽅にとって「そのまま」⾒えている とは限らなかったりする l 逆もしかり…… l 開発側・利⽤者側、それぞれ双⽅に異なるバイアスが掛かっていたりする こともある l それを敏感に感じ取り、うまくサービスに反映させられるかどうかで、 使い勝⼿やサービスに対する信頼性も⼤きく変わる（と思っています） 今回のサポートケースからの学び
49 l 今⽇ご紹介したものは、⽇々のお問い合わせの中でも特に特徴のある ものでした l 他のエンジニアに頼ってばかりなように⾒えたかもしれませんが…… l 最初はわからなかったものでも、今ではスイスイ回答できるようになった、という ものも（もちろん）たくさんあります l エスカレーション率は5%未満 l 今では、むずかしそうなお問い合わせがあると少しワクワクしてしま う⾃分もいます 以上、3件のサポートケースのご紹介でした
51 ü ⼊社以降、私が直⾯したサポートケースのうちの難解なもの（学びの 深かったもの）のいくつかをご紹介しました ü こうして寄せられる様々な（そして不可解な（ように思える））事象と その原因を、いっしょに取り組み、思考のプロセスと共に明らかにして くれる同僚エンジニアがいる ü それにより、今⽇も私はありがたい学びにありつけられています Ø 「学び」を⾃⾝の⾎⾁に変えられるかどうかは⾃分次第！ 今⽇のお話のまとめ
52 なぜ『CRE』として働くのか？ l 「サーバー監視サービス・Mackerel」のテクニカルサポートに携わるということは、 「サーバー」を取り巻く技術に向き合う、ということ。 Ø エンジニアとしての成⻑機会も多い l Mackerel を採⽤いただいているお客さまは、いずれもそうそうたる企業ばかり l そんな各社のインフラ運⽤の最前線の状況（⼯夫していることや悩みなど）を、⽇頃の コミュニケーションから知ることができる l そして、解決のためのお⼿伝いができる・様々な提案をおこなうことができる Ø 他者の⼿助けができる ＝ 対象について⼀定以上の理解ができている Ø そうなる過程で多くのインプットができる（せざるを得ない！） l ……といったことを、今⽇のお話からも感じ取ってもらえていれば嬉しいです
daisukeinoue
imsaku
masakamayama
takatsunobuhiro
herumi
ritou
mottox2
mochico
ama_ch
kyonmm
tomzoh
bonotake
nori_shinoda
schacon
eileencodes
eitanlees
lemiorhan
roundedbygravity
mraible
michaelherold
maltzj
rocio
aarron
chrisshort