wtatsuruの技術方面のブログ

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

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

Amazon

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

実際受けてみて、各種データベースエンジンの特徴や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適用、計測環境、デプロイ設定、あたりの設定。MariaDBとMySQLで設定値が違うところで若干ハマる
    • すぐできそうなSQL改善して17000くらい
  • サーバ分散。DBヘヴィなこと、ISUからの投稿先を指定できることもあって、分散すると大事だろうとなったので早めに着手
    • チームメンバが　condition の調査も始めてる
  • この辺で昼休み
    • 2台構成で動いてる
    • ここから、アプリケーション側は condition に手を付け始める。参照側のチューニングからやってたけど、今振り返るとMySQLを脱出するところをやるべきだったポイント。
  • 3台構成にした
    • DB動かしたときにちょっと不具合出してハマった
    • このへんで30000弱
  • 小細工
    • dropProbability 一気に下げてみたり
    • conditional get 実装したり（効いてなかった...）
    • dropProbability 0.75 にして 36000
  • デバッグの手伝いしつつ作戦考える
    • 画像がDBに入ってるのでファイルに書くやつハマってた。エラーログ見づらかったりしたのでデバッグ手間取ってたので一緒に見た。Go に慣れてなさがあってちょっと無駄にした...
    • 後でどうせやるやつを入れてた。でかいやつはgzip、InnoDB はデータサイズ見えたので 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

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

オカムラ ヴィスコンテ オフィスチェア メッシュタイプ ハイバック ブラックフレーム アジャストアーム 座面奥行調節 5段階固定 CWH5ZA-FBA1 ブラック

オカムラ ヴィスコンテ オフィスチェア メッシュタイプ ハイバック ブラックフレーム アジャストアーム 座面奥行調節 5段階固定 CWH5ZA-FBA1 ブラック

  • メディア: オフィス用品

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

Dell 4Kモニター 31.5インチ U3219Q(3年間無輝点交換保証/フレームレス/USB Type-C/DisplayHDR 400/IPS非光沢/USB-C,DP,HDMI/高さ調整/回転)

Dell 4Kモニター 31.5インチ U3219Q(3年間無輝点交換保証/フレームレス/USB Type-C/DisplayHDR 400/IPS非光沢/USB-C,DP,HDMI/高さ調整/回転)

  • 発売日: 2018/09/14
  • メディア: Personal Computers
エルゴトロン LX デスクマウント モニターアーム アルミニウム 45-241-026

エルゴトロン LX デスクマウント モニターアーム アルミニウム 45-241-026

  • 発売日: 2010/03/09
  • メディア: Personal Computers

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

HHKB Professional HYBRID Type-S 英語配列／墨

HHKB Professional 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 や副賞あたりの盛り上がり施策も楽しかったですね、あとでじっくり録画見ます。運営の皆様、おつかれさまでした。

ISUCON10予選　ヌルポインターマリアユニバースとして出てギリギリで本戦いけました

ISUCON10、ヌルポインターマリアユニバースというチームで id:polamjag id:Pasta-K と一緒に出てきました。
isucon.net
最終スコアはたぶん2335、なんとか予選突破できました。

振り返り

今回はあまり役割を決めず、時々で臨機応変に動くぞとやってました。結果的にインフラ面はだいたいやることになったし、結果につながったのはよかった。とはいえやった作業自体は簡単なものなので、もうちょっとコードを見られたはずだし、絶対的に足りない気はしてる...。

  • 最初にルールを全員で読んだ
    • これはよかった。スコア算出、ルールの問題についての認識は最後まで問題なかった
  • リポジトリに入れるのをまかせつつ、ログ出したりデプロイ準備したりしてた
    • デプロイ準備は長引いてしまった。問題についての雑談をしながら準備してしまったからで、ここはひたすら作業だとわかってたから思い切って集中してよかった気がする
  • alp の上位を見てどうしようかねーって話ながらランチタイム
    • これはよかった。椅子がドアに入るかどうかのロジック、「なんかありそうだねー」くらいで、ボトルネックじゃないから後回しにするみたいな話を力を抜いてできた
  • 昼過ぎは作業分担。search 高速化は置いといて、low_priced と nazotte の N+1 みたいな、やればいい＋効果高そうなところにはじめから取り組めた。同時に複数台の仕込みも始めた。ついでにINDEXも貼った。
    • 軽そう、効果高そう、みたいなポイントから取り組めてよかった
    • INDEX やればいいしいれないと分からないみたいなやつに早めにと思ってたので、まあよかった
    • 一番効果高い search のところ、全員で会話していいアイデアがなくて、ちょっと後回しになってしまった。最後までいい解は思いつかなかったので、いいのか悪いのか。
  • N+1 を解決するのとDBホストを分けたことで2000くらいまで上がった。このへんで15分スプリントをやった
    • 15分スプリント、1つのレビューとか作業がちょうどよく終わる感じでよかった
    • 本番で順に試したことで、やれたことに対して試行錯誤の時間がちょっと長かった気がする

  • 最後の2時間、search を range じゃなくて id 使うことで高速化するのをお願いしつつ、自分は slave 複数台分散をやった。ついでに query cache と innodb_buffer_pool の増加をやった。スプリントは崩壊した。
    • それぞれハマりがちになって、口数は減った。15分は短いけど、30分くらいで状況共有できたらよかった気がする。
    • slave 分散、sqlx のインスタンスを複数用意しといて使い分けるみたいな器用なことはできなかったが、search だけ振り分けるのをインフラだけの最小工数でできてよかった。準備しかなかったので試す時間を持てなかったのと、実は SELECT ... FOR UPDATE を無視してるのがだめ
    • search の改善はめっちゃでかい必殺技なわりに、着手が遅くなったので結局入れられなかった
    • DBのチューニング、やるべきかどうか微妙だと思ってた buffer_poool と query_cache にもちょっと早めに取り組めた。意外と効果が上がって、盲点だった
  • 最後の1時間で微妙な調整とか nginx 複数台分散のトライをやった。
    • DBのCPUでサチってるので、分散したら速いだろうというのはわかってた。レプリケーションの構成とかシュッとできてすぐ試せたのがよかった（やればできるだろうと油断はしてた）
    • nginx 分散、なんかデプロイでミスってた気がして焦ったけど、なんとか入れられてよかった。レプリ遅延対策で initialize に wait 入れたのもここだった...
    • ベンチマークの結果は安定してたし、ガチャする時間もあってちょっと余裕は合った

詳しくは

リポジトリは公開してるので、詳しくはこれ見てください https://github.com/tatsuru/isucon10q
公開前に deploy key 無効にするとかまずい情報無いことは確認してますが、なんかこれまずそうみたいなの見つけた方はこっそり教えてください。

本線がんばります

Go のコード読むの遅いし、コード書く時間もあまり取れてなかった。
本番はもうちょっとインフラ面が複雑になるかも知れないけど、もうちょっと手を広げられるようにしていきたい

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