リモート会議では、反応してくれる人が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畳くらいの個室を確保できる分譲賃貸マンションで、いいところが見つかった。

作業環境作り

作業環境

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

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

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

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

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

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

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

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

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

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

結果

家でめっちゃ集中して仕事ができるようになった。食事・ゲーム・テレビみたいな空間と地続きの作業場だとどうしても気持ちを切り替えられなかったりだらだら休憩してしまいがちだったのが、場所を分けることでだいぶ切り替えがやりやすくなっている。連休明けなどは仕事しすぎてしまうが、まあそこは調整すればいいかな。
悩みとしては、昼夜のごはんの準備が大変なことくらいか。以前と比べて徒歩圏内の飲食店が少し減ったり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つのレビューとか作業がちょうどよく終わる感じでよかった
  • 本番で順に試したことで、やれたことに対して試行錯誤の時間がちょっと長かった気がする

#isucon #ISUCON10 pic.twitter.com/dKXyzHkFfp

— 民生用カメラ (@polamjag) 2020年9月12日

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

The Amazon Builders' Library がなかなか面白い

タイトルが全て。みんな読んでみてほしい（主語がでかい）。
aws.amazon.com
Amazon が自社のシステムを構築する中で構築してきたノウハウを集めた場所。以前 Cloud Design Pattern みたいなものがあったけど、より背景事情を深めつつ洗練されている印象。昨年末に発表されてから素早く翻訳されており、日本語で読めるコンテンツとしてはかなりよいものだと感じた。
内容についてっは、分散システムがなぜ難しいのか、ということから始まり、タイムアウトやキャッシュ戦略、ヘルスチェックなど特定のトピックでの課題について深めていく形。ときどきに出てくる用語や現象について個別項目の知識はインターネットに散在しているが、メリットだけでなくどういうリスクとトレードオフなのか、どのレイヤで考えるのか、まで伝えてくれており、知見の結晶という感じ。コンテンツの追加が楽しみだ。
ちなみに分散システム自体の知識はあまり解説してくれず、AWS Developer Blog にちょっとリンクが貼ってあったりする程度。この辺の前提知識は、今だとOreillyの本かな。

分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

AWS Solution Architect Professional を取得した

ちょっと機会があったので、AWS Solution Architect Professional という認定を取得した。この試験自体は知っていたが、資格試験系全体にあまり興味がないのもあり、スルーしていた。実際に受けてみて、知識の確認・補完としては悪くないと思ったので書いておく。
AWS 認定ソリューションアーキテクト – プロフェッショナル

AWS Solution Architect Professional ってなに

公式の説明はこんな感じ。一般的な「アーキテクト」の能力（の一部）を評価する、という印象。

認定によって検証される能力

• AWS で、動的なスケーラビリティ、高可用性、耐障害性、信頼性を備えたアプリケーションを設計し、デプロイする
• 提示された要件に基づくアプリケーションの設計とデプロイに適した AWS のサービスを選択する
• AWS で複雑な多層アプリケーションを移行する
• AWS でエンタープライズ規模のスケーラブルな運用を設計し、デプロイする
• コストコントロール戦略を導入する

https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/

サンプル問題 があるので、まずはこれを見るのがイメージしやすい。典型的な課題やユースケースを出し、AWSを使って解決する最適な手段を選択肢の中から選ぶ感じ。前提が多いものもあり、1つの企業内でやってる自分なんかだと、普段はあまり縁のない状況も多くあった。
ちなみにAWSの認定ってざっくり言うけど、実はいろいろあるらしいというのも今回知ったところ。
AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS

実際に受けてみた感触

だいたい10月から準備し始めて、11月はじめに試験を受けた。試験を受ける、そのために勉強するという体験がそもそも大学院入試以来で、緊張やらペースづくりからどうやっていこうねという状態からスタートした。
自分の性格的に漫然と過ごしていてもまず勉強しないので、最初に試験に申し込んで締切を作ってからスタート。締め切りを作るのだいじ。その後の対策としてやったことは、おおよそこの3つ。

• 会社で勉強会をして強制的に時間をつくる。
• 模試と対策講義を見て傾向を知る。
• AWS が出している Blackbelt Seminar の資料を眺めて足りない知識を補完する。

勉強については、AWS自体はずっと（初めてAWSについて発表 してからでも8年だ）見てるし、その間にいろいろ変化も見てきた・会社でも使用を広げてきたので、多少知識を補完すればいけるかなという目論みがあり、実際に模試を受けてもそんなに悪くはなかったので、この作戦は悪くなかったと思う。
勉強して一番役に立つと感じたのは、実際にリリース情報やサービスの概要は見ていて「何をするものか」をなんとなく把握していても、「どんなユースケースでハマるか」の肌感がない領域の知識を得られること。頭の片隅に置いておいて損はないタイプの知識だと思う。自分で構築・運用しているものや、社外で近い領域の人からインプットをもらう機会があればいいが、そうでない領域についてもある程度網羅的に得られる機会があるのはよかった。自分の場合は長らく触れていなかった AWS Organization のフル機能だったり、手を動かすのをサボっていたSQS Kinesiis あたりの非同期処理の設計。ただし、やっぱり自分で触ってないと実感はこもらないので試験対策だけで勉強する部分ばかりになるとちょっとつらいし、ある程度の知識・経験は前提として持っている方が役立てるものだと思う。
他には、「AWSでやるならどうするか」という観点で考え続ける機会が得られる点はよかったかな。現実の課題を解決する上ではもう少し自由に手段を考えるのだけど、現代においてはまずクラウドプラットフォーム上で取りうる最善を考えた上で、それでもやりづらいところのみ作り込む・足りない要望を出す、という順は悪くないと思うので、こういう縛りプレイはよい方向に転がるはず。まあしかし、ソースコードを変更できないとか、理不尽な組織構造が前提になった問題にあたると、さすがにそこを変更しようよという気持ちになることもあるのだけど。
良くも悪くもコンソールを触ることすらなく勉強できる範囲なので、スキルの確認という意味ではあくまで参考にする程度かなというのは全体の感想。

勉強内容

自分の場合の事例。

• 社内の勉強会を週1で開催する。だいたい1-2時間くらい時間を確保。
• まずはひとつ下の Solution Architect Associate (SAA) を受けてみることに。
  • 黒い本 徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 を読んで勉強。どういう領域が出題されるか、体系的に書いてある感・安心感を得られるのが書籍のいいところ。
  • 模試を受けて感触を得る、足りない部分を把握する。模試ではどこが間違ったか教えてくれないので、せめて迷ったサービスについてはメモっておくと後で勉強しやすい。
  • AWS INNOVATE というオンラインカンファレンスでちょうどセッションやってたので見て雰囲気をつかむ。これはまさに学校の受験対策という風情でよかったので、AWS様にはぜひとも復活させてほしいコンテンツです。
• SAA本試験
  • テストセンターに行って受けた。オンラインで開催する試験を行う専用の会場で、手荷物を預けた状態で専用のPCが並んでいる部屋に案内され、そこで受験する。最近は漢検なんかもこういう場所で受けるらしい、知識が20年前で止まってて全く知らなかった。
  • 小さくて解像度の荒いディスプレイを見続けてちょっとつらかった。
  • 867/1000で合格。時間はわりと余ったが、見直しなどせずにサッと出てきてしまった（よくない）。
• Solution Architect Professional (SAP) に向けて勉強。
  • AWS INNOVATE に Professional 対策講座があったので見ておく。Associateと同様、まさに試験対策という趣でよかった。
  • 模試を受けてみる。85%。Design for New Solutions という分野が弱いことがわかった、この辺は↑にも書いた通り手を動かすことをサボってた分野でもある。
  • INNOVATE と模試で弱いなと思ったサービスの Blackbelt Seminar を読んでいく。日本語のスライドだと1つ10分くらいでサクサクいけるとテンポよく読んでいける。
  • AWS公式のコース にある該当ホワイトペーパーに行けるのでそれも読んでみたが、2,3読んだところで飽きた。自分にはあまり合わない、楽しさが足りなかった。
• SAP本試験
  • 別会場、土日であることもあってかSAAの時より人が多かった。隣にいるのは気にならないが、正面の席を立つ人など視界内で動かれるとさすがにちょっと気になる。
  • 今度はディスプレイが少し大きいものの、相変わらず解像度低くて荒いし、アスペクト比もなんか変な気がした...。
  • Associate のノリでゆっくり問いてたら時間がなくなり、結局最後ギリギリになってしまった。180分集中するのはだいぶ疲れる。
  • 結果は合格。837/1000
• 内容について
  • 試験内容については、守秘義務があるので細かいことは言えない。
  • 日本語で受けたものの、翻訳に違和感を感じたらすぐに英語で読むようにした。これはよかったと思う。
  • 回答方針は「出題者の気持ちになって考える」がよいと感じた。多少前提条件が足りなくてもクラウドのプラクティスに乗るのが善という価値観に立ってみる。

まとめ

AWSの認定を受けてみた。知識の確認と補完にはそれなりによいとは感じる。AWSのイベントで認定者ラウンジとか見たので、次は使ってみよう。