2020年の振り返り
2020年が終わるので久しぶりにブログを書いてみた。
1Q
Railsからはちょっと離れて、去年の10月くらいから始めたGoでgRPCのAPI Gatewayもどきを実装するのを主にやっていた。
業務で使うのが初めてだったことと、チームで慣れているひともいなかったので、とにかく小難しいことはやらずに困ったら愚直に実装して、あとから直そうと思ったときに直しやすくできればいいなということを考えていた。
3月くらいにちょっと手が空いたので、Reactを使ってかんたんなプロトタイプアプリを作る機会があった。
フロントエンドについては全く経験がなかったので最初は何もわからなかったが、公式のチュートリアルも結構充実しているし、すごくシンプルなものの実装だったので、そんなに困ることはなかったきがする。
2Q
(徒歩3分くらいしか移動していないが、)引っ越しをした。
4月中旬に急に高熱が出てすごくしんどいことがあり、もしかして罹ってしまったのかな？と思ったが、当時はよっぽど重症じゃないと検査してもらうこともできなかったので、自宅で寝てたら数日で治った。
熱が出るまでは、ほとんど出社している人がいなかったのと、オフィスまで自転車で5分だったこともあり、結構な頻度で出社していたのだが、これ以降は念の為に出社を控えるようにした。
家にちゃんとしたデスクがなかったので、 THE TABLE / パイン × White Steel – by KANADEMONO の足をSquare_Barにしたやつを、180cm x 65cmでオーダーして購入した。
あと、ヤフオクで中古のミラチェアを購入した(手数料込みで45,000円くらい)。
揺れもあんまりしないし、机が広く使えるようになったので、オフィスと同じかそれよりも良いくらいに仕事環境を整えることができた。
仕事では、1Qに引き続きプロトタイプをちょっと実装したり、GoでAPI Gatewayもどきを実装していた。
API Gatewayもどきは終盤だったので、テストの実装とか本番環境の準備とかを行っていた。
6月にずっと品薄だったリングフィットアドベンチャーを手に入れることができた。
なんだかんだで11月くらいまでは、週6くらいやっていたきがする。
1日50Kcalくらいを目安に適当にアドベンチャーをやっていただけなので特に体型が変わったり見た目上は変化を感じることはなかったけど、グルグルアームとかバンザイツイストをやると肩がスッキリする気がするので、筋トレというよりはストレッチ的な効果は結構ある気がする。
3Q
7月は有給消化をして退職し、8月から今の会社で働き始めた。
情勢が情勢なので、入社日くらいしか出社はしていなくて、あとはほぼフルリモートで仕事をしている。
今まではいわゆるサーバサイドエンジニアな仕事が多かったけど、今の仕事ではSREのような、コードを書くことがメインというよりも、インフラ基盤を整えて運用をどうするかを検討したり調査することをやり始めた。
今までの仕事でdocker-composeやECSはちょっと使っていたけど、Kubernernetesは使ったことがなかった(し、よっぽどじゃない限りはWebアプリならKubernetesはオーバースペックだと思っていた)ので、キャッチアップから始めた。
ちょうど第2版が出た Kubernetes完全ガイド 第2版 - インプレスブックス を買って読んでみたら、網羅的に把握することができたのでKubernetes触りたての人にとって良い本だと思った。
4Q
3Qに引き続きSREぽい仕事をやっている。
コードを書くよりも、(使用するOSSとか、運用するWebアプリの)コードを読んで理解するという時間が増えたので、新鮮だし楽しくやっている。
ドキュメントが揃っているととてもありがたいし、ドキュメントどおりに動かしたつもりなのに何かがおかしい…と思ったときはソースコードを読みに行くのをやっている。
Kubernetes自体もちょっとは慣れてきた気はするので、Kubernetesに使われている状態からKubernetesを使っている状態になりたい。
幸いPlayStation 5の購入に成功したので、ローンチタイトルのMarvel's Spider-Manを買ってみた。
正直これはあんまりハマれなかったけど、PlayStation Plus特典でついてきたペルソナ5がとても面白くて、気がついたら100時間以上遊んでいた。
1周目は初見だったのでとりあえずNORMALをクリアすることをやって、65時間くらいかかった。
2週目はセーブデータを引き継いでHARDでやって、45時間くらいかかってクリアすることができた。
ストーリーの後半はちょっと疲れちゃう区間があったけど、UIがおしゃれだし操作もサクサクできるし、なにより曲がとても良かったのでとても楽しめた。
2021年は
明日から本気だす で2020年はこういうのをやりたいな～と書いたものの、結局全然意識する機会もなく特に捗りもしなかったので、目標を決めて進めるのが下手だなと思ってしまった。
ただ、今の仕事で使うこともありコンテナ技術まわり(特にKubernetes)は深い理解が必要だと思ったので、そこについては来年こそ進めたい。。。
特に最近の仕事ではインプットする量に対してアウトプットする量がかなり少ないと感じているので、できれば何らかの形できちんとアウトプットしたい。
あと、ボルダリングももうちょっとレベルアップしたい気持ちはあるが、週1しかやってないせいか伸びを感じられなくなってしまっているので、できれば週2くらいは通いたい。
ISUCON10予選に「Railsへの執着はもはや煩悩(ry」で参加したけどダメでした
ISUCON10の予選に参加しました。
今年は@cnosukeさんと@aibouさんと、「Railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」というチームで参加しました。 この3人でのISUCON参加は初めてでしたが、cnosukeさんとは毎年参加していることと、aibouさんは前の職場が同じだったということもあり、またcnosukeさんとaibouさん同士も知り合いだったので、とてもスムーズに進められました。
先週にISUCON8の予選問題を使ってリハーサルを行ったのですが、カンを取り戻す意味で非常に良かったです。
(今回の予選問題については、きっと公式の方で解説をだしてくれると思うのでそれを見ていただきたく。)
なんとなくの役割分担として、cnosukeさんがAPIのコード変更を行い、aibouさんがDB周りのチューニングを行い、自分はgit管理したりと雑多な対応やデプロイ実行などをしていました。
APIを眺めてて、chairテーブルとestateテーブルを両方さわるエンドポイントがほとんどなかったので、基本戦略として1号機がベンチマークの受付と静的ファイルを処理し、2号機がchairsに関するAPIとchairテーブルの処理、3号機がestatesに関するAPIとestateテーブルの処理を行う方針で行くことにし、それからイロイロ遅いところを改善していこう、ということを決めていましたが、最終的に815点(最高点でも845点なので多分誤差)に留まってしまいました。
競技用リポジトリのgit logを眺めつつやったことをざっくり振り返ってみると、
| 時刻 | やったこと | メモ |
|---|---|---|
| 09:15 | 集合 開始時刻が12:00になることが分かったので暇つぶし。 |
散歩したりNFLを見たりひたすら楽してロマサガ3リマスターを見たりしてた。 |
| 12:20 | 競技開始 | 初手でとりあえずベンチマークを走らせようとしたが、 混雑していて難しかったので先にソースを読んだりをすることにした。 |
| 12:41 | webappや、schemaをダンプしたものをgitリポジトリに突っ込んだ。 | |
| 13:36 | new relic導入 | |
| 13:37 | 初期スコアが500くらいだった気がする。 | |
| 14:20 | POST /initializeの処理を分けた |
このときに1号機がベンチマークの受付と静的ファイル、 2号機がchairsに関するAPIとchairテーブルの処理、 3号機がestatesに関するAPIとestateテーブルの処理を行う方針を決めた。 |
| 14:49 | ほとんどのAPIを2号機と3号機に分散させるようにした。 | |
| 15:03 | GET /api/recommended_estate/:id だけはestateとchairの両テーブルを触っていたので、 3号機に処理させつつ、chairを引いてくる処理だけ2号機にAPIを生やすことにした。 |
|
| 15:49 | unicornをpumaに置き換えた。 | |
| 15:52 | テーブルにインデックスがなかったので、いい感じに貼ってもらった。 | 今回は書き込み処理がほとんどなかったので、インデックスをたくさん貼っても書き込み処理で詰まることはないだろうという読み。 |
| 16:25 | chairとestateのテーブルを正規化し、DB処理の高速化を図った。 | が、完走しなくなってしまったのでバグ調査。 |
| 19:00 | estateテーブルのrange indexが効くようにrentの値でpartitionを切った。 | |
| 19:28 | GET /api/recommended_estate/:idでDBで重いソートが走っていたのでRuby側でやらせようとしたが、なぜか完走してくれなくなってしまった。。。 |
のでrevert |
| 19:37 | インデックスを更に追加。 | |
| 19:57 | テーブル正規化のバグが取れて完走するようになった。 | |
| 20:46 | そういえばbotのアクセスは503で弾いていいんだということを思い出したので、急遽nginxの設定を変更。 | |
| 20:55 | 最終スコア815で終わり。 |
これ以外にもmysql, nginx, pumaの設定ファイルをいじったりしていましたが、ほとんど効果はなかったです。
chairとestateがきれいに処理が分けられるので、それぞれ2号機と3号機に分担させたという方針は良かったと思うのですが、APIもDBも載せてしまっていたので、もしかしたらDBだけを担当させるようにしていたらもうちょと伸びたのかな、、、と終わってから思いました。
new relicを眺めて、一番処理に時間がかかっているAPI、次に時間がかかっているAPIをそれぞれ担当を分けて対応していく感じで進めていたので、(ちょっとコンフリクトしたことはありましたが)そんなに大きくトラブったこともなく、わりと進めやすかったと思います。
直前にチームで練習したおかげか思っていたよりもスムーズに取りかかれたけど、なかなかスコアが上がらずで悔しかった、、、 #isucon
— まてぃ (@rkmathi) 2020年9月12日
結果が出ず残念ではありますが、問題もわかりやすくとても楽しい予選でした。
今回のISUCONは参加チームがとても多く、しかも例年と異なり1日で全チームの予選を行うため、サーバを用意していただいたり運営するのがとても大変だったのではないかと思います。
最後になりましたが、運営の皆さま本当にありがとうございました！！
kind(kubernetes in docker)を動かしてみる
k8sを動かしてみたいと思ったので、kindを使ってローカルで動かす環境を作ってみた。
まずは単純なWebアプリが動くようになれば良いと思ったので、rackアプリケーションを動かす感じにした。
手元のマシンはUbuntu 20.04なので、それにkindとkubectlとかをインストールしてイロイロ試行錯誤したら、とりあえず動くものができた。
↑のリポジトリのREADMEに動かし方は書いてある。
kindのIngressのドキュメントを読んでみたが、これであっているかがまだわかっていない。
あと、今の作りだとdocker imageになにか変更を加えるたびに毎回docker build してkind load docker-imageしてをやらないといけないので、ちゃんとした開発を行うなら、docker imageとコードの分離を行わないと辛そうだなと思った。 (git-syncなるものがあるということを聞いたので、それをいい感じに使うのが良いのかも。)
コードレビューの意義
忘れそうなので下書き
僕の中での、「コードレビューを行うことの意義」は、ざっくりと
- 1 ロジックやデータ構造が明らかに間違っているコードが、メインラインに取り込まれることを防ぐため。 (最後のチェックポイント)
- 2 改善の余地があるコードをレビューでフィードバックすることで、レビュイーの勉強を促すため。 (レビュイーの学習)
- 3 レビュワーが、他の人のコードを意識して読むことによって、レビュワー自身の勉強になるため。 (レビュワーの学習)
があると思っている。
1 は、「diffと周辺のコードだけ」を見ることで明らかに間違っているコードを見つけることであって、全体的な動作や他システムとの結合部分を確認・担保するのまでは、レビュワーにさせるのは負担が大きすぎるため、それはレビュイーの責任だと思っている。
それよりも大きなコードの追加・修正があるなら、レビュイーは相談したりdesign docを書いたりして、コードを書く前に「今から実装しようとしているモノの方向性は正しいのか？」を確かめたほうが良いと思う。
また、コードをすべて書き終わってからコードレビュー依頼を投げるのではなく、実装途中や中身がTODOコメントの状態でレビューを投げて議論を行い、早いうちにすり合わせたほうが、後から大きくやり直すことは少なくなると思う。
2 は、(僕自身がそうだったからなのだけど、)慣れていない言語・フレームワークだと、自分ひとりで勉強するのは限界があるので、慣れているメンバーからレビューしてもらうことで、レビュイーのスキルアップが早く大きく見込めると思う。
より実践的な言語・フレームワークの書き方を教えてもらえたりすれば、そのPRで修正するのもできるし、何らかの理由で見送る場合だとしても、次からはより良いコードが書けるようになる。
3 は、(これも僕自身がそうだったからなのだけど、)他の人が書いたコードを読むと、「そういう書き方があったのか」とか「前に他の書き方をしちゃったけど、レビューしたこのコードの方が見通しがいいな」みたいな発見があるので、これもコードレビューの意義としてあるのではないかと思う。
じゃあ、上に書いた 1 2 3 のような効果を得られる、効果的なレビュワーはどうするのが良いか？というのは、
- 担当範囲が近い人 (1の効果)
- 自分よりシニアだと思う人 (1, 2の効果)
- 自分と同じくらいか自分よりジュニアだと思う人 (3の効果)
にお願いするのが良いのかなと思う。
3人にお願いしないといけないわけではなく、↑の条件を満たせるなら2人でも良いだろうと思う。
2020年にやること
思いついた順に
ボルダリング で赤レベルを登れるようにする
黄色→若葉→ピンク→紫→茶色→赤→...とレベルが別れてて、今だと紫中位くらいまでしか登れないので、今年前半で茶色、年末くらいには簡単な赤が登れるようにしたい。
腹筋を割る
12月にふと思いついてやってみたプランクが、最初は20秒が限界だったのに2分くらいは維持できるようになったのでそれを続けつつ、腹筋が割れるくらいにはしておきたい。
Rustをやる
今まではRuby→C++→Goはやってきたので、今年は積ん読状態になってる実践Rustを進めたりツールを作ってみたりしてRustに慣れる。
コンテナ技術を理解する
なんとなく使ってるdockerの下のlxcだったり、束ねて使うk8sだったりを理解してどういうシチュエーションで使うのかをわかるようにする。
