wtatsuruの技術方面のブログ

はてなスタッフ id:wtatsuru です。日常ブログはこちら https://tatsuru.hatenablog.com/

SREは意思決定を助けてくれる

この記事は Mackerel Advent Calendar 2023 の10日目です。ちょっと出遅れてしまった、けど投稿日は無理やり調整しています。
今年のネタは今年のうちに供養するため、今年9月に開催された SRE NEXT 2023 というイベントで発表した内容の紹介です。発表資料はこちら。
speakerdeck.com

SREの考え方は最近だいぶ浸透してきたなと感じます。今年の SRE NEXT での発表も、大企業での導入事例や実際に運用・改善してきたふりかえりなど、実践的な内容が多くなってきてますね。いいことです。
一方で、世間を見渡すと、まだ導入の時に苦労していることも多いなと思います。普段 Mackerel を開発しているので、余計にそういう声が聞こえやすい立場でもあるかもしれません。SREの考え方っていうは組織に導入するものなのでトップが理解してると導入が楽ですが、そのためには何が嬉しいか、何が変わっていくのかもっと語られる必要があるかなと感じています。

信頼性は大事なので数字で語りたい

ユーザー視点での信頼性が大事、というのはプロダクトを作ってたら当然そう考えると思うんですよ。そのための判断も活動もチームは日々やっていると思います。
そんなプロダクト作りでは、日々いろいろなイベントが起きますし、いろんな判断による心の体力はガリガリ削られていきます。「こんどの新機能リリース、先日の障害の恒久対策、今ちょっとずつ遅くなってるAPIの調査、どれが大事か」などの状況はよくありますね。これを勘と経験と度胸で決めいってもいいんですが、大変だし他人に渡せない。何か判断軸が欲しくなります*1。
信頼性はどれくらい必要なのか、低下の時のアクションは。計測して数字で語ることで判断軸を共有できるし、改善も可能になります。数字で語るためのフレームワークが SLI/SLO になるわけですね。

SLO は意思決定すべきポイントを明確にする

SLO のプラクティスは、誰がどのタイミングで意思決定すべきかを明確にしてくれます。エラーや性能劣化についてチームで判断して対応すべきかどうか考えられる。ビジネスと接続するSLIの見極めと目標設定をうまくやることが次の仕事になる。大変な仕事であることはあまり変わりませんが、意思決定すべきポイントはここだ、と示してくれます。

信頼性や開発生産性を高められるって話はしてなくてうまくバランスを取るのが楽になる、と言ってます。これは普段判断することを仕事にしてる人はめちゃくちゃ嬉しいはず。少なくとも私はここが一番嬉しかったポイントです。

信頼性を高める活動はもちろん大事です。SREの別のプラクティスとして言われる、トイルの削減やソフトウェアによる運用の自動化は、プロダクトや開発・運用環境が良くしていくために取り入れるべきプラクティスですね。この辺は改めてSREって言われなくても取り組みやすいところかなと思います。

ちなみに発表中でも紹介していますが、 2023 State of DevOps Report  |  Google Cloud では信頼性が足りない組織はそんなに多くないという結果になっています。なんとなく感覚に合うと思いませんか。

詳しくは動画で

動画もあるようなので、資料と合わせて当日の様子はこちらをどうぞ。*2
www.youtube.com


以上、Mackerel Advent Calendar の10日目でした。
11日目は id:ryuichi1208 さんです。

宣伝コーナー

来週の Mackerel Meetup #15 Tokyo でも SRE のセッションやります。自分とは違う切り口で語ってもらえると思うので興味ある方はぜひ来てください、懇親会で語りましょう。
mackerelio.connpass.com

*1:ハードワークでなんとかなるならそれで問題ないかと思います

*2:自分が喋ってる動画なんて怖くて見られないので、内容は確認してません。

ISUCON13に参加した（マルチタスクマスタリーサーバーズ） #isucon

ISUCON13 に id:polamjag id:Gurrium と「マルチタスクマスタリーサーバーズ」というチームで参加しました。
isucon.net
スコアは28,232点で全体70位です。もうちょっと伸ばしたかったなー、結構悔しさは残りました。リポジトリはGitHubに公開しています。
github.com
id:polamjag とは前に何度か出たことがありますが、id:Gurrium とは初めてかつ仕事上の絡みも少ないのもあり、例年に比べてしっかり（集まって1.5日くらいは＋個人手ではもう少し）練習して臨んだのでした。それだけにもうちょっと上位に手をかけられるくらいに頑張りたかったなーというところですが、ここが今の実力なんだろう、また1年精進します。

やったこと

いつもの15分スプリントで スプリント会 会場 · Issue #4 · tatsuru/isucon13 · GitHub

  • 最初の1時間は計測、デプロイ、問題観察など
  • 12:37 index貼る + アイコン304 で 7244点
  • 15:01 userstream, livestream の N+1 剥がす、DB分離で 24213点
  • 17:43 PowerDNS をファイル配信にして 27053点
  • 17:55 再起動試験して28232点

自分で手を動かしたのは最初のデプロイ・計測系とproxy、DB、DNS周り。アイコン配信考えるところ（実装は違う）、あとは他の2人の作業をペアで見るなど。
15時にスコアが跳ねたタイミングはたしか11位くらいで結構いい感じだったし、ここまでは作戦と動きも悪くなかった。自分の作業には余裕があったから他の2人の作業とコードもちょいちょい見に行ってたのが良かったかもしれない。

午後はあまりスコアが伸ばせてない。DNS水責め攻撃をちゃんと対策しようと思ってPowerDNSの設定をファイル配信に変更したんだけど、できたのが17:30過ぎでギリギリだし、サーバーも2台しか使えずに終わってしまったのがくやしい。チームとしても stats 関連や reaction の N+1 などは最後まで不具合が残ってしまって一通り revert することになったのが一番もったいなかった。自分もハマってたのであんまりフォローしに行ったり、ちょっと落ち着いてペアでみよう、みたいな話を持っていく気持ちの余裕も少なかった。

ちなみにpowerdnsをbindファイルに移行した ことで最後の名前解決数は178412と、DNS捌いたで賞に近いところには行けたのがちょっと満足です。launch=bindにして、zoneファイルは初期化とユーザー追加タイミングで更新とリロード。捌くほど負荷が上がるのは知ってたけど、結局最後まで負荷が上がり続けてCPUは食ってしまうし、攻撃を捌いても当然スコアは伸びないわけなのですが。

スコア履歴

あとはただの感想

問題設定自体は、オープニング動画の演出含めて面白かったしフロントエンドも最初チラッと見てよくできてるなとも思ったけど、開いてるとポーリングだけでめちゃくちゃCPU食うので結局ほとんど見ずに終わってしまったけど。
kazeburoさんだからDNS水責めってのは絶対予想できたなー。いやそんなわけないだろうとも思ってたんですが。おかげで攻撃の厄介さは知ってたし、対策もなんとなく思い浮かびはしたので、あとは実装しきる力<<パワー>>だけですね。攻撃相手にレスポンス遅延させる、みたいなこと思いつきはするけどシュッとやれないもんな。
ベンチマーカーは順調な時は快適だったけど、止まってた時はちょっと困ってたかも。デバッグや仕様チェックはベンチマーカーで回してるからね。運営は（やったことあるので想像つくんですが）めちゃくちゃ大変だと思うのですが、いいイベントだと思うので継続は応援したいです。

さくらのクラウドシェルで mackerel-agent を動かす

さくらのクラウドシェルというのが出ていたので遊んでみます。ログインしなくても使えますが外向きの通信ができないので、会員ID持ってる人はログインして遊んだ方が楽しめます。
www.sakura.ad.jp
起動するといい感じのシェルが立ち上がります *1 。sudo もできる

シェル周りちょっと手が加わってる感があり快適です。Ubuntu で普通に apt が動くので色々入れられます。

さくらのクラウドシェルは、ブラウザから無料で利用できるオンラインのシェル環境です。開発者向けの環境がプリインストールされているため、使い慣れたツールをすぐに利用できます。

さくらのクラウドシェル | さくらインターネット

mackerel-agent を入れてみる

というわけで入れてみましょう。Mackerel のスタートガイドのここにあるコマンドコピペして入れてみます

（API Keyうつってますが削除済みです）

systemd がなかったので今回はとりあえず手で起動

無事にホストが登録されました

他の使い方

外向きの通信が通るということでネットワーク経路見るのは便利ですね。さくらクラウドにインスタンス上げなくてもいいので調査などちょっと捗りそう。

go や terraform など入ってるので、チュートリアルレベルのやつをサクッと動かすのはすぐにできます。ただし、重ためなリポジトリを持ってきてビルドとテストを回したりするとすぐ20分経過してコンテナ落とされるので、あんまりしっかりした作業は向かない感という感触でした。

ちなみに

ログイン画面へのリダイレクトがめっちゃよかったです。誰でもここを通るはずの場所に配置しとくのがうまいな。

*1: 環境変数$SHELLの使い方を間違っていませんか？ - Unengineered Weblog の方法使いました

AWS Solution Architect Professional を取得した（3.5年ぶり2回目）

AWS Solution Architect Professional 試験に合格しました。前回が 2019/11 だったので3年半弱ぶり。3年で失効なので実はちょっと切れてたんだけど、ちょうど試験が更新されるタイミングだったのもあって待ってから受けてみた。無事に合格してほっとしている。


前に受けた時の記録はこれ。
wtatsuru.hatenadiary.com
前回の記憶はだいぶ曖昧なんだけど、前にも増してガバナンスやセキュリティ、組織でAWSを使うための基盤作りを行うための問題に寄ってたなという印象は持った。

勉強

いつも通り会社で有志を集めて勉強会を企画してやっている。毎週多少意識が向くようにしつつ、日程を決めるためのきっかけにした。結局直前に詰め込みはすることになる。
試験が更新されたばかりということもあって教材は揃ってないので、準備はほぼ全て公式の AWS Skill Builder と関連する Blackbelt Seminar でやった。
aws.amazon.com
Skill Builder すごくいいんだけど、一つだけ不満が。有料サブスクの支払いがAWS連携しかない？かつ、連携しようとすると root アカウントでのログインを求められてしまうところ。rootアカウント非推奨じゃないのと思うし、会社の経費で出そうとすると大変。以前のようにカードで払いたいな。

ISUCON12予選に参加しました

ISUCON12に、id:tkzwtks id:yashigani_w と「デジタルトランスフォーメーションズ」というチームで出場してきました。最終スコアは4159で本選進出ならずという結果でした。
isucon.net
id:tkzwtks id:yashigani_w の2人は同じ会社で一緒に働いて長いんですが、同じチームで仕事したことはほぼなかったので、なかなか楽しい体験だったなと思います。問題も運営もすごく良かったので感謝です。
それはそれとして、本戦いけなかったのはだいぶ悔しい。なかなか向き合えなくて、この記事を1週間書けなかったのでした。なんとか7月中には書いたよ。

ふりかえり

正しさの追求の気持ちが足りないかも、というのを終わった後に会社の他のメンバーと話してて感じた。
プロダクションコードならこんなの絶対やらないでしょ、というところも意図があると考えて後回しにしがち。謎の採番を見ても放置したり、flock を温かい目で眺めたり。性能は悪くないかもしれないが、SQLite のままじゃ自分の土俵で戦えない。もっと理想に近づけていく、最強になる気持ちを取り戻したい。

  • 作戦はそこまで間違ってなかった、と思う。状況は見えてたし、やってたところは外してない。
  • 手の速さと正確さは課題
    • インフラ領域だと、デプロイまでは「いつもの」のはずなのに2時間かけてる。メモリリークの原因切り分けられなかったのは敗北感が強い...。
    • スコアキャッシュのとこの実装も遅かったし、もっとシャッと書けると手数増やせたなと。正しいことを素早くやろう。
  • チームとしての雰囲気がよかった
    • 15分スプリントで頻繁に見直し、毎回掛け声を上げる。うおお。
    • 対面なら雰囲気は見えるので、中盤など多少インターバル長くても行ける気はする。
  • 対面作業の強さを思い出した
    • 任意のペア作業可能が瞬時にできるようなディスプレイ配置、顔が見えるので詰まってることもわかる。ホワイトボードで状況共有。
    • チーム作業はリモートに比べて圧倒的に有利だなと改めて実感した。

自分の流れの振り返り

リポジトリはこちら。
github.com

  • 15分スプリントを持ち込んだ。ふりかえりにも便利ですね スプリント会 · Issue #3 · tatsuru/isucon12-yosen · GitHub
  • まずはインフラ担当として序盤の整備 インフラ作業スレ · Issue #7 · tatsuru/isucon12-yosen · GitHub
    • 起動、計測、デプロイあたりの環境を整える。docker-compose だけどアプリしか使ってないのでそのまま放置。
  • 昼の作戦会議
    • ランキング改善のための余計なデータ削減。SQLite はそのまま使う。
  • サーバー分散やら全体の作戦整理、時々ペアでバッグ
    • SQLite 使う、キャッシュ入れるなど予想できるので後半でサーバー分散はちょっと気を使うだろうという見立て
    • このタイミングでMySQLは分けたり、ちまちました作業はやっといた
  • 最終スコアをキャッシュして速くするってやつをやりかける
    • 他が詰まってたので別ラインでキャッシュするコードを書いてた。最終的には出さなかった。
  • 最後はメモリ詰まって落ちるやつを見てた
    • 初期データ削減後、ベンチマーク走行中にメモリが急速に膨らんで死ぬ状況に悩まされる。bisect して行っても再現したりしなかったりしてつらい。
    • csv入稿が増えて同時リクエストが溜まると詰まるっぽかった。1.5時間溶かした

チームメンバーとの相互リンク

yashigani.hatenablog.com
blog.tkzwtks.net

Mackerel の2021年

Mackerel のプロダクトマネージャーをしている　id:wtatsuru です。

Mackerel この記事は Mackerel Advent Calendar 2021 25日目の記事となります。昨日は id:ryuichi1208 さんによる Mackerelに入門して半年経ったので感想ややったことなど - 地方エンジニアの学習日記 でした。今年から始めてプラグインまで作っていただいててすごい。

今年も Advent Calendar に色々な記事が集まりました。中の人の話から、長年使っていただいてる方、また今年から使い始めたという話まで。Advent Celendar 最後の記事として、いくつかトピックを取り上げつつ今年のMackerelを振り返っていこうと思います。

まず今年 Mackerel で反響が大きかったものとして、 Terraform Provider のリリースが挙げられます。Advent Calendar でも、利用例 やデバッグ方法 などが紹介されていました。Mackerel は元々 mkr monitors コマンドなどでコード管理のサポートはしていたのですが、現代の IaC ツールとしては少し物足りないものでした。元々有志の方が一部作っていただいていた実装があったため、作者の方にお声がけして公式実装としてリリースしたものです。監視ルールの管理などで特に便利なものとなっていますので、ぜひご利用ください。
mackerel.io


SLI/SLOへの取り組みもいくつか紹介いただきました。世間的にも実践例が増えてきた分野ですね。SLO の運用をやろうとすると最初に考えることが多いのですが、shimesaba はそういったスタートを助けてくれるすごく良いツールです。
techblog.kayac.com
はてな、Mackerel本体の運用でもSLI/SLO運用は実践しており、足りないパーツを補いつつ、ある種の型を提供していきたいと考えています。17日目の以下の記事では、社内での運用事例を紹介しています。社内での運用事例は、今年夏のデブサミでも発表していますのでぜひご覧ください。 はてな「Mackerel」のSREに学ぶ、開発パフォーマンスと信頼性のベストバランスとは？【デブサミ2021夏】 (1/2)：CodeZine（コードジン）
mackerel.io
このパーツの一つとして、ログをメトリック化して扱うツールも実験的に公開しています。過去にはOS上で動くプラグインという形式での提供が多かったのですが、今回は AWS上で動く Terraform module という形式で公開しています。
susisu.hatenablog.com

メトリックといえば、以前はホストの退役後もそのロールでカスタムメトリックのデータが利用できるようになりました。地味な部分ですが、コンテナ環境などホストが頻繁に入れ替わり前後で変わらずロール全体での傾向を見ておきたい、長期的な傾向が知りたい、というケースでもお使いいただけます。
mackerel.io

そのほか内部の話としては、フロントエンドフレームワークのReactへの置き換えも徐々に進んでいます。見た目にはほぼ影響がないのですが、一部表示が速くなるなどの改善も出ています。普段使いするサービスとして快適に使ってもらえるように取り組んでいきます。
developer.hatenastaff.com

クラウドを前提とした運用環境が定着してきて、SREの実践についても徐々に事例が増えつつあります。Mackerel としても、徐々にそういった環境へのサポートを強化し、道筋を提供していきたいと考えています。引き続きMackerelをよろしくお願いします。

Apple Silicon MacBook のCPU使用状況をMackerelで可視化する

これは Mackerel Advent Calendar 2021 の5日目の記事です。昨日は @sogaoh さんによる
[Day.04] Mackerel で かんたん AWS SES の bounce rate 監視 でした。

はじめに

先日、仕事用マシンを Apple Silicon 搭載の MacBook Pro 14インチ (2021) に更新しました。2018年の13インチからの乗り換えだったんですが、快適さに驚いています。リモートワークでビデオ通話を含む多くのツールを同時に動かすことも多いんですが、引っ掛かりを感じることがほとんどなく過ごせています。


熱効率も優れていて、バッテリーの持ちもかなり良いというのが体感です。普通にコード書くだけなら8時間持ちます。あまりに発熱しないので冬場は寒いという欠点も報告されています*1

f:id:wtatsuru:20211205185925p:plain
コードを書いてる時のバッテリの減り方

M1チップのこのバランスは、高効率コアと高性能コアという2種類のコアを組み合わせて実現されています。普段は電力あたりの効率の良いコアで大部分を処理し、必要な時のみ高性能コアを使用するようです。2020年に発売されたM1チップでは高効率4コア＋高性能4コアだったのが、2021年のM1 Pro/Max では高性能2コア＋高効率8コアとかなり極端になってきています。
pc.watch.impress.co.jp

そんなことを言われると、実際どっちをどれくらい使ってるか気になりますよね。macOS上ではアクティビティモニタで見ることができます。これがめちゃくちゃ格好いいのですが、出せる時間幅が短いしリアルタイムでしか見ることができない。計測してちゃんと振り返るため、Mackerelに記録しておきましょう。

f:id:wtatsuru:20211205190210p:plain
アクティビティモニタでみられるかっこいい画面

計測してみた

実際にプラグインを作ってCPU利用率を計測してみました。使ったのは 10コアM1 Maxの構成で、CPU0とCPU1が高効率コア、残りが高性能コアです。高効率コアはE-Cluster、高性能コアはP0-ClusterとP1-Clusterとしてグルーピングされており、グループ単位でも利用率を取得しています。>

f:id:wtatsuru:20211205190339p:plain
コードを書いているときの様子

まずは普通にコードを書いている様子を見てみます。エディタでコードを書きつつ、横でTwitterと音楽を流し、ブラウザでちょこちょこ調べ物もしています。高効率コアの方でおおよその処理が完結していそうで、たまにブラウザ使ったりビルドしてたりするタイミングで高性能コアの方が跳ねているようです。

f:id:wtatsuru:20211205190539p:plain
重た目の作業をしている様子

次に、もうちょっと重たい処理をしている想定の環境を作ってみます。Google Meet でビデオ通話しつつ、スプレッドシートとGoogle Docs を複数開き miro のボードをいじる、裏でちょっとツールを動かす、という以前のマシンなら重くて辛い作業です。高性能コアのうち P0-Cluster は割と常時稼働して、たまにP1-Clusterがサポートしているが、P1-Clusterはまだ余裕があるので重い処理もう一つくらい流しても大丈夫そうですね。E-Cluster の方もそれなりに余裕があり、UIのレスポンスも快適なままです。この程度ではパワーを使いきれないということか...。

実装

プラグインの実装には、macOS のツールである powermetrics(1) を使っています。このツールでハードウェアレベルの状態を取得することができます。プラグインでは実行タイミングで1秒間サンプリングし、Mackerelに投げています。rootが必要なので動かすのにちょっと気を遣うのですが（手元では cron で起動して mkr thorw で投げてる）他にいい取得方法をご存知の方いたら教えてください。
github.com
また、上の章では CPU上での専有率 residency を使用率っぽく使ってますが、実際は動作クロックごと変動するため微妙に違う概念です。powermetrics の出力（下記）を見ると雰囲気がわかると思います。プラグインでは一応平均クロックも一緒に出してるので、一緒に参照してみてください。

E-Cluster Power: 84 mW
E-Cluster HW active frequency: 1411 MHz
E-Cluster HW active residency:  47.64% (600 MHz: 1.7% 972 MHz:  46% 1332 MHz: 7.9% 1704 MHz:  17% 2064 MHz:  27%)
E-Cluster idle residency:  52.36%
E-Cluster instructions retired: 1.03631e+09
E-Cluster instructions per clock: 1.04806
CPU 0 frequency: 1363 MHz
CPU 0 idle residency:  62.88%
CPU 0 active residency:  37.12% (600 MHz: .10% 972 MHz:  19% 1332 MHz: 3.3% 1704 MHz: 7.6% 2064 MHz: 7.2%)
CPU 1 frequency: 1395 MHz
CPU 1 idle residency:  63.87%
CPU 1 active residency:  36.13% (600 MHz: .05% 972 MHz:  17% 1332 MHz: 2.9% 1704 MHz: 8.2% 2064 MHz: 7.6%)
f:id:wtatsuru:20211205191613p:plain
クロックも一緒に取ってます

他にもコンポーネントごとの電力消費量なども見えるので、RAMが電力食いすぎってのがよくわかります。この辺も時間があったらプラグインに追加していこうかな。

まとめ

新しい MacBook Pro が快適だという記事でした。リモートワークでオンラインのコラボレーションツールを使うことも増え、マシンスペックに対する要求も上がってると思うので、快適になっていくのはすごく助かります。Intelもヘテロジニアスなアーキテクチャを出してきそうなので、今後も色々と楽しみですね。

明日の Mackerel Advent Calendar 2021 は id:hayajo_77 による terraform-provider-mackerel のデバッグ手法 - Qiita です。Terraform provider のデバッグってなかなか見る機会がないので楽しみですね。

*1:https://twitter.com/tkzwtks/status/1466327505430724609

はてなで一緒に働きませんか？