wtatsuruの技術方面のブログ

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

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 2021id:hayajo_77 による terraform-provider-mackerel のデバッグ手法 - Qiita です。Terraform provider のデバッグってなかなか見る機会がないので楽しみですね。

AWS Certified Database Specialty を取得した

会社で資格取得補助が出るのを利用して、毎年AWS認定資格を取っている。一昨年にSolution Architect Professional、去年は(書いてないけど)Security Speciality を取得していた。今年は Database Speciality を取得した。
wtatsuru.hatenadiary.com

証明書が発行できるようだ。面白いから全部並べてみた。

AWSはそれなりに使ってきたので、実務で扱った知識の体系化と、ついでに抜けてるところ・新サービス知識なんかの補完ができるといいなと思って受けている。会社としてはAPNパートナーに認定技術者が必要という事情というのはあるので自分が率先して受けているという意味もあるの。
Databaseはよく扱うし、知識としても大事かなと思ったところだったのでちょうど良い。最近触っている分野に近いところということで Data Analytics もサンプル問題を見てみたのだけど、整ったBigQueryとDataStudio環境に甘やかされてる身にはちょっときつくて、もう少し手を動かしてからじゃないと身にならないと感じた。

勉強については、おおよそいつも通り。
まずサンプル問題と模試をまず受けて足りないところを把握して、Blackbelt 見て知識を補完して行く。ペースづくりと体系化のために本を読む。模試についてはいつも答え合わせが難しくて苦労してたんだけど、AWSから新しく出た模試は、解答と解説が出て最高だった(というか模試に要求したい水準が満たされるようになった)。
https://explore.skillbuilder.aws/learn/course/external/view/elearning/9159/aws-certification-official-practice-question-sets-japanese

試験はリモートでも受けられるようだったが、自宅の机を片付けるというのがハードル高かったので普通に試験センターで受けた。回数は減ってるけど普通に開催されてたのでありがたい。英検の日とかぶってたのでちょっと混んでたくらい。

実際受けてみて、各種データベースエンジンの特徴やAWSの周辺サービスとの接続については理解が深まった気がする。特に、Auroraは自分でガッツリ使った経験は薄くて知識も古かったのでアップデートされてちょうど良い。ただし、Database Speciality についてはちょっと知識に寄っているというか、単なる知ってるかどうか問題が多くてクイズ要素が少ないなと感じた。SAPは設計クイズの総合格闘技って感じだし、Security Speciality はKMSパズルが楽しかった覚えがある。Databaseの方はどうしても可能かどうか 0/1 問題が多くなりがちだったな。

来年はSAPの期限が切れるから更新するか、DevOps Professional に乗り換えるのもありかな。

DevRel/Japan CONFERENCE 2021 に参加した

スポンサーとして参加させてもらったのでブースに立ってました。バーチャル開催なので oVice で場所をもらって机に立ってる感じ。
devrel.tokyo
ブースの方を盛り上げるのはなかなか難しかったな。バーチャルスペースは ask the speaker の方が盛り上がりやすそうだったので、登壇を狙ってアウトプット増やすほうがいいかもしれない。

カンファレンス本体は Youtube 配信だけど、合間に Spatial Chat, oVice, Remo と移り変わっていったのはなかなかおもしろい試みだった。参加者として知らない人とうまく話すみたいなのは、まだ難しさを感じる。仕事でもこのへん試す機会はあるのだけど、知り合い同士で使ってるとそれなりにうまくいくので、リアル空間の模倣では解決できない課題を感じる。

セッションも裏で見ていた。最初にやってたライティングのセッションは、技術記事を精力的に発信してる企業の話が特徴が出ててなかなかおもしろかった。テクニカルライティング周りは最近じわじわ盛り上がってきてる印象がある。
メルカリさんは全社戦略からチームとの連携がしっかり取れてる、つなぐ役割が置かれている。クラスメソッドさんは逆に、どんどんレビューなしで出して、みんなでわいわいフィードバックする文化で担保されている。New Relic さんは海外で発信されたものをただ翻訳するのではなく、日本の顧客に向けての内容を発信する。


後半で印象に残ったのは採用の話。開発者向けのサービスを扱う職種としてどこもプログラミング経験くらいは必須にしているようだけど、やはり認知が少なくて、採用は苦労していそう。情報技術をベースに置きつつ周辺領域をあわせて活かすキャリアの認知をもっと広げていく必要はあるって認識はどこも共通だった。サイボウズさん DevRel 20人いるってことでうらやましい。
エンジニアキャリアを生かしたキャリアを考える時に、手を動かすことをメインにしない場合の技術の磨き方、キャリアの継続性はなかなか難しいと感じる。ブースでも似た話をしていたのだけど、開発者と行き来する人もいるらしい(周囲の人を見ても少しイメージは湧く)。専門性を生かした総合職的なに柔軟に立ち回る生き方、T型なのかダブルメジャーなのかいろいろ呼び方考え方あると思うけど、組み合わせを絞るとぴったりはまるモデルケースはなくなるんだろうな。

DevRel領域重要だと思うけど、日本でなかなか認知されてないので、広まっていってほしい。

リモート会議では、反応してくれる人が1人いると進めやすい

今日、会社で読書会をしていて出た話題。
リモートの会議、とくに人数が多い場合、各自のマイクをミュートするのがマナーになっている。2人以上話せないし、キーボードを叩く音などノイズになる可能性もあるので、それ自体は筋が通っていることだと思う。
全員ミュート状態で1人で喋っていると、反応がわからなくて結構しんどい。ちょっとウケを狙えるかなってこと言っても当然無音。滑ってるなら滑ってるって知りたいし、それならそれで対処しようがあるが、ただひたすらしーんとしている。一人でリズムを作って虚空に向かって喋り続けるのはきつい。
これが1人反応を返してくれる状態だと全然違う、という話題が出てすごく共感した。相手の反応を見て反応できるしリズムも作れる。何か反応がほしいなと思ったら話しかけることもできる。めちゃくちゃ救われたことがいくつも思い出される。
こういうことやってくれるのは、フォロワーシップの高い人だったり、肩書を持った人、その場の成功の一端を担っている役割の人が振る舞うケースが多いように思う。自分が知らないだけで、裏でこっそり依頼しておく、仕込んでおくのは定番になっているのかもしれない。
しかし会議がリモートで進みやすいなら、役回りを明示的に設けてみても面白いかもしれない。相槌役、ツッコミ役、そういう役回り。試してみようかな。

ISUCON11 予選に参加しました #isucon

ISUCON11予選に、去年と同じヌルポインターマリアユニバースというチームで id:polamjag id:Pasta-K と出場しました。
isucon.net
最終スコアは36971 でした。リポジトリはこちらです。
github.com

問題・競技環境が素晴らしかった

まず、今回の出題は本当にすごくよかったです。出題者の方、おつかれさまです。
問題は、シンプルな割にボリュームが多く、ボトルネックが移りかわるすごくいい問題だし、見てて面白かったです。実装も綺麗で読みやすかったのがよかったです。
ベンチマーカーのトラブルもちょっとあったとはいえ、全般的にほぼ待ち時間なくて快適。全体的に最高です。

個人のふりかえり

いい問題だっただけに、点数を出せなくて個人としての反省点は多い。
まず、手数が足りなかった。ボリュームが多かったけど、手を動かす速度に課題あったなーという感じ。凡ミス多かったり、ログとかデプロイとかやるだけのことものんびりやってしまった。最近業務で手を動かしてないし、ちょっとずつ鈍ってきている可能性がある。
作戦ミスもあったかなー。書き込み叩き落としてるのがおかしい・ポイントが多いとスコアが何倍にもなることはわかってたし、データ量も多い。結局叩き落とす数を減らせなかったので、大技をそこに集中してもよかった。

何をやったの

今回も15分スプリントでやりました。変化する状況はスプリント会に詳しいです https://github.com/tatsuru/isucon11-qualify/issues/3
自分の視点を中心に思い出してます。酒を飲んでるので微妙な前後はあるかも。

  • 基本的には今回もインフラ担当、あとは他2人がペア作業するあいだの司令塔っぽいこととかファシリとか。
  • Cfn適用、計測環境、デプロイ設定、あたりの設定。MariaDBMySQLで設定値が違うところで若干ハマる
    • すぐできそうなSQL改善して17000くらい
  • サーバ分散。DBヘヴィなこと、ISUからの投稿先を指定できることもあって、分散すると大事だろうとなったので早めに着手
    • チームメンバが condition の調査も始めてる
  • この辺で昼休み
    • 2台構成で動いてる
    • ここから、アプリケーション側は condition に手を付け始める。参照側のチューニングからやってたけど、今振り返るとMySQLを脱出するところをやるべきだったポイント。
  • 3台構成にした
    • DB動かしたときにちょっと不具合出してハマった
    • このへんで30000弱
  • 小細工
    • dropProbability 一気に下げてみたり
    • conditional get 実装したり(効いてなかった...)
    • dropProbability 0.75 にして 36000
  • デバッグの手伝いしつつ作戦考える
    • 画像がDBに入ってるのでファイルに書くやつハマってた。エラーログ見づらかったりしたのでデバッグ手間取ってたので一緒に見た。Go に慣れてなさがあってちょっと無駄にした...
    • 後でどうせやるやつを入れてた。でかいやつはgzipInnoDB はデータサイズ見えたので buffer pool と trx_commit を調整するいつものやつ
    • リクエスト状況見て次の作戦考えてた
  • 画像をファイルに書くの成功
    • 苦戦したけど成功
    • DBが暇になって、バランスが結構変わった
  • 1時間前になってベンチマーカー停止
    • あんまり分散できてないのでDBネックを解消する手を作ってた。アプリが片方暇なので仕事のバランス調整準備
    • クライアントキャッシュきいてないねっての直したり
  • ベンチマーカー復活、分散作戦考えていく
    • 負荷が変わらない前提でホストの分散具合を調整していく
    • チームメンバは大技として trend の N+1 に取り組む
  • 最後のあがき
    • ログ切ったりモニタリング止めたり、dropProbability 調整したり
    • 最後5分で db.SetMaxOpenConns(10) のままだったのを見つけたので100にしてみる
    • 最後のベンチ、速くなった気がするけど制限時間に終わらなかったのでスコアわからず

まとめ

問題は成功、個人としては反省。1年間つらい気持ちで過ごしそうな気がする。精進しよう。
ちなみに去年はこちら
wtatsuru.hatenadiary.com
このブログISUCONばっかりになってるな

リモート勤務用の部屋を作った

3月頃から自宅勤務をメインにしており、2年くらいはリモートメインになりそうな状況になった。チームメンバもだいたいリモート作業していて、仕事を進める上でそんなに不自由はしていない。しかしこれまで自宅に作業スペースがなく、ソファで仕事していてあまりいい状態でなかったので、この機会に仕事用・作業用の部屋を作った。
pr.hatenastaff.com

まずは引っ越し

会社の近くに住むメリットがなく、また作業場所を作ろうにも物理的に場所がなかったこともあり、まずは引っ越しをした。
10年以上それなりの都会に住んでたので、いきなり離れすぎることに対する不安もあり、会社からある程度の距離に収まる(電車で1時間以内)範囲から探した。ちょっと郊外のベッドタウンで駅徒歩10分ちょい、5畳くらいの個室を確保できる分譲賃貸マンションで、いいところが見つかった。

作業環境作り

f:id:wtatsuru:20201104192727j:plain
作業環境

まずは机。会社で教えてもらった、かなでもののデスクを注文した。部屋のサイズぴったりで注文できて、ちょうどいい位置に配線孔もつけてくれる。揺れないしっかりしたつくりで、いまのところすごく気に入っている。最近話題の昇降デスクも考えたが、会社においてある昇降デスクを全く使ったことがないので今回は見送った。
THE TABLE / 杉無垢材 × Black Steelkanademono.design

椅子は、会社で使ってるオカムラのヴィスコンテを中古で調達した。入社した日にそこに置いてあったから使ってるんだけど、背筋が伸びるしちょっと座面が広いので気に入っている。

ディスプレイはDELLのU3219Q。USB-Cで給電と出力できるのが必須で、会社で使ってる27インチからもうちょっと広いやつにしてみようかなという挑戦。まだ慣れなくて、端っこの方にはウィンドウ置かずに使ってる。プライムデー前後にちょっと安くなってたタイミングで購入して、エルゴトロンのアームにつけて使ってる。

キーボードとトラックパッドは、これまで使ってたHHKB BTとMagic Trackpad 2。会社に置いてあるHHKB Hybrid Type-S のほうが静かなので、こちらを家で使おうかなと思ってる。

Apple Magic Trackpad 2 - スペースグレイ

Apple Magic Trackpad 2 - スペースグレイ

  • 発売日: 2018/05/16
  • メディア: Personal Computers

リモートの会話は有線のイヤホンでやっている。スピーカー置いたりマイク置いたりしてデスクがごちゃごちゃしてくるのもなんか微妙だなと思って、いったん無しで過ごしている。困ったら考える。

結果

家でめっちゃ集中して仕事ができるようになった。食事・ゲーム・テレビみたいな空間と地続きの作業場だとどうしても気持ちを切り替えられなかったりだらだら休憩してしまいがちだったのが、場所を分けることでだいぶ切り替えがやりやすくなっている。連休明けなどは仕事しすぎてしまうが、まあそこは調整すればいいかな。
悩みとしては、昼夜のごはんの準備が大変なことくらいか。以前と比べて徒歩圏内の飲食店が少し減ったりUberEatsの選択肢がちょっと狭まったのもあり、自炊の効率化などもう少し考えていきたい。

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