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インチからの乗り換えだったんですが、快適さに驚いています。リモートワークでビデオ通話を含む多くのツールを同時に動かすことも多いんですが、引っ掛かりを感じることがほとんどなく過ごせています。

今日から M1 MacBook Pro に変えて仕事してるのだけど、ビデオ通話しながら Google Docs を複数開いて miro に絵を描きつつ裏で docker build する、みたいな荒い使い方しても普通に快適に過ごせてて人生が変わりました

— tatsuru (@tatsuru) 2021年11月30日

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

コードを書いてる時のバッテリの減り方

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

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

アクティビティモニタでみられるかっこいい画面

計測してみた

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

コードを書いているときの様子

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

重た目の作業をしている様子

次に、もうちょっと重たい処理をしている想定の環境を作ってみます。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%)

クロックも一緒に取ってます

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

まとめ

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

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

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

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認定 データベース-専門知識』 (Compass Booksシリーズ)

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

実際受けてみて、各種データベースエンジンの特徴や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 さんは海外で発信されたものをただ翻訳するのではなく、日本の顧客に向けての内容を発信する。

メルカリエンジニアブログを書き続けるために、マネージャーと今後1年で露出したい量を話して目標を握るっていうのいいな。
マネージャーが露出量を増やすインセンティブはなんだろう。全社の目標から降りてきてるのかな。
#DevReljp #DevRel #DevReljpC

— tatsuru (@tatsuru) 2021年11月13日

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

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

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

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