wtatsuruの技術方面のブログ

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

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の選択肢がちょっと狭まったのもあり、自炊の効率化などもう少し考えていきたい。

ISUCON10 本選に出場しました。7位でした。

ISUCON10 決勝にヌルポインターマリアユニバースとして id:polamjag id:Pasta-K と出てきました。スコアは28628の7位。個人としては ISUCON5 以来の本選で、もうちょっと上を目指せたなと悔しさ残るものの、今はこんなもんかなとも思う結果となりました。
isucon.net

当日の様子

リポジトリ公開したので、詳しくはこちらをどうぞ。 https://github.com/tatsuru/isucon10-final

  • 本番までにやることTODO · Issue #1 · tatsuru/isucon10-final · GitHub
    • 事前に予選の振り返り会とアクション出し。わりといいTRY出たものの、やったのはだいたい当日の朝。まあそんなもんだね。
  • 10:50 問題読み会場 · Issue #5 · tatsuru/isucon10-final · GitHub
    • 全員で問題読んで様子を把握。ここまで50分くらい、ほぼ作業せずに様子の把握に集中。
  • 10:55 スプリント会 · Issue #11 · tatsuru/isucon10-final · GitHub
    • 今回のみどころ、15分スプリント開始
  • 12:15 作戦会議 · Issue #10 · tatsuru/isucon10-final
    • コード読み・ログ出しと全貌把握が完了して全体の方向性決めたのがこのあたり。インフラ作業進めつつ dashboard から取り組もう、という動き出し。
    • まだコード全くいじってないしデプロイもしてない。ここまでがもうちょっと早くできたらよかったかな。
  • 14:00頃
    • ペア作業事始めとしてN+1を1つ倒している。効率が悪いので VSCode Live Share やろうぜってのがよかった。
    • インフラ面はデプロイ・ログ分析体制あたりを粛々と入れてる。この辺からスクラムマスター役を全部巻き取る。
  • 15:43頃
    • ペアプロがノッてくる。/api/audience/dashboard の1秒キャッシュ(雑)と50秒フリーズが順調に終わって成果が出始める。
    • インフラ側はベンチ回して負荷や TeamCapacity での変化を見たり、DBチューニングをちょっと入れたり。スコア上げると増える通知周りを次のターゲットにした。
  • 16:55頃
    • 通知周りが一通り完成、サーバー分散準備。
    • 全部入れてTeamCapacity = 20 で2万点くらい。ちょうどいい状態でリーダーボード固定されたので自分たちの位置は認識できた。
    • スプリント会はここで途切れている...
  • 17:30頃
    • 終了30分前、あがくと決めてた最終ライン。
    • サーバー構成の試行錯誤、TeamCapacity 変更あたりを回して調整。スコアの仕組みを見てキャパシティトライしたり、web push 入れたから通知レスポンスは空でいけることに気づけるなど、土壇場でルール把握が効いた。
    • しかし試行錯誤の時間が足りず、最終的には TeamCapacity 65 でやめている。
    • Envoy 突然死を LimitNOFILE=65535 で一発回避したのはナイスだが、焦っててログに残してない。
  • 最後
    • 再起動試験として1台落としたところ、上がってこず焦る。運営チャットで問い合わせたらすぐに再起動してもらえて九死に一生を得る。
    • 最後まで回し続けて微調整。17:58 のベンチで Fail したときは青ざめた...。

振り返り

  • それなりによいスコアで終われた
    • まあ今の実力としてはこんなところじゃないか。トップを狙うにはもうひと押し足りなかった。
  • 15分スプリントがうまくワークした
    • ハマった作業を諦める、適度に休憩する、など人間的な生活を送れている。生活の知恵。
  • インフラ作業と司令塔みたいなのは、それなり。
    • 前半、全体に目がいきすぎてログ分析が疎かになった。全体のボトルネックになっていたと感じる。
    • 後半で粛々と進めつつ、残り2人の進行をサポートするのは悪くなかった。
  • 個人として、テクニカルなスキルは微妙かなぁ...。
    • Commits · tatsuru/isucon10-final · GitHubインフラ作業ログ · Issue #4 · tatsuru/isucon10-final
    • 今回とくにインフラ作業ばかりやってた。Envoy微妙に慣れないけど致命的ではなかったし、作業の精度は及第点、速度もギリギリOKだと思う。
    • デプロイ、サーバー構成なんかは普通にやることやった感じ。3番にDB持っていけば速いだろうというのはわかってたのに、残り時間が少ない+メモリ消費に日和って諦めてしまった、これは猛省。

仕事でエンジニア業から離れて全然手を動かしてないという危機意識から現状の確認をしたいというのが最近ISUCONに出る理由なんですが、今回は手応え半分、危機感半分ってとこです。伝統的なペットの面倒を見る作業は70点、Envoy gRPC あたりで戸惑うというちょっと遅れてる感で -20点。司令塔・マネージャーとしての方が最近の本業で加点してもいいけど、今回コード書いてないので相殺。

サーバ運営や問題はすごくよかったです。サーバートラブルはほとんどなかったし、ベンチマークは快適で競技に集中できる環境でした。問題も、ボリュームと複雑さ、ISUCON運営という意表をついたテーマ、インフラもアプリも工夫の余地が散りばめられていた点、など近年まれに見るよい問題だったと思います。Youtube Live や副賞あたりの盛り上がり施策も楽しかったですね、あとでじっくり録画見ます。運営の皆様、おつかれさまでした。

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