2022年8月に転職してからの1年間を振り返る
2022年7月末に前職を退職し、8月から働いての1年間を雑に振り返ります。
転職してからの1年の密度は相当濃かったと思っています。
忘れてしまわないうちにここに記録しておきます。
時系列は適当です。
やってきたこと
大体四半期ごとに振り返ります。
2022年8月 ~ 12月頃
- 転職先へ初出社
- 最初のうちは、中途社員の研修を受けつつ、ウォーミングアップ
 - https://moneyforward-dev.jp/entry/2022/08/31/overrapped-attakee/
 
 
- エラーを追いつつプロダクトへの理解を深める
- ECS上のsidekiqのローリングアップ時の挙動を調査していた
 - https://moneyforward-dev.jp/entry/2022/11/30/flow-of-sidekiq-stop/
 
 - プロダクトのメンテイン/アウトの手順を整備
- 手順の検証をしつつ、本番作業の手順書を整備していた
 - 初の作業となることが多く、緊張感がかなりあった
 - ここで本番作業手順を確立しておいたことが、後々の移行で役立った
 
 
- エラーバジェットの運用
- 様子を見つつ、エラーバジェットポリシーを策定
 - 関係者と合意形成を図った
 
 - この四半期はなかなか成果が出せなかった
- 思った通りに進捗が出ない。詰まることが多い。とかなり苦しんでいた
 - 評価もあまり期待できず、あれ?転職したけど大丈夫かな?なんて気持ちになっていた
 - 精神的には余裕が無い状態ではあったものの、初転職はこんなものかなと思って自分を納得させていた
 
 - 英語学習が始まる
- ここで受けたTOEICの点数は430点程度
 - 過去に何回テストを受けても点数が伸びなくてほぼ諦めていた
(全く勉強していないのが悪い) 
 - 基盤移行/アカウント移行という大きめプロジェクトが動き出す
(ここから約1年間はほぼこれに注力していた)- 成果が出せていなかったのもあり、最初は移行作業の一部を担当して進めていた
 - まずは現行のアーキテクチャやCI/CDの調査を進めた
 
 
2023年1月 ~ 4月
- 年明けから移行プロジェクトが本格的に動き出す
- 割と問題なく進められていたため、当初よりも色々任せてもらえる範囲が広がった
 - 段々と出来ることが増えていったのを実感する時期だった
 - ここから、移行プロジェクトのリードの振る舞いも出来るようになってきた
 
 - まずはアプリの基盤移行を進めた
- 主にTerraformやk8sを触って移行に必要なリソースを作成
完全にyaml職人と化していた。 - 移行事例を調べつつ、全力で活用(真似)した
 
 - 主にTerraformやk8sを触って移行に必要なリソースを作成
 - ある程度構築が進んできたところでアーキテクチャ上の問題が発生
- 1つのnamespaceにサービスをまとめていたところ、ArgoCDのmigrationの挙動がいけてない感じになった
 - 長所/短所、手戻りのコスト等を比較した結果、namespaceを分割する意思決定を下した(つまり手戻り)
 - この辺は、問題発生からアラートを上げて対応するまでのスピードが早かったのが良かった
 
 - 別の緊急対応に稼働が取られる
- 構築のスケジュールがどんどんビハインドしていく
 - リスケを決意
 - 今思えば悪く無い決断であった。中途半端に急いで障害を起こすよりもトータルのコストは安い
 
 
- TOEICの点数、全然上がらない
- 420 → 480へ
 - 2, 3ヶ月くらい勉強したのに500点を超えずに涙目
 
 - ようやく移行の構築がひと段落したので切り替え当日に向けて準備を進める毎日
- 移行用のダッシュボードを準備
新旧のメトリクスが切り替わらない = 切り替えがうまく出来ていない を確認出来るようにした - stgリハでは、k6を使って負荷をかけてみたのが案外良かった
 - 移行用のダッシュボードが上手く機能していることを確認。満足
 
 - 移行用のダッシュボードを準備
 - 切り替え1週間前くらいに、LBの設定がミスっていることに気付いて急ぎ修正
- ヒヤリハット案件だった
 - 切り替え時の確認観点を整理する際に、アーキテクチャを図示したり、シーケンスに書き起こしたり、視覚的に全体像を把握するようにしていたので気付けた
 
 - 切り替え本番
- 切り替えは思っている以上に一瞬で終わった
 - 無事に何事も無く切り替え完了。Route53の荷重ルーティングって便利
 - 移行用ダッシュボードを準備したのも良い方向に働いた。問題がないかどうかリアルタイムで確認出来るのは大事
 
 - 4月ギリギリ駆け込みでTOEICが500点を超える
 - 移行作業をほぼ一人でリード出来たのが評価された。素直に嬉しい。
 
2023年5月 ~ 10月
- アプリの基盤移行が完了したので、次はクラウドサービスのアカウント移行を進めた
 - 移行後の後対応で稼働が取られて、アカウント移行が思うように進まない
- CI/CDフローの改善
 - 検証環境のドメイン名移行
 - 基盤移行に伴う各種手順の整備、エンジニアへの展開 等
 
 - ビルド/デプロイがめっちゃ楽になったようで、プロダクトチームからも感謝された。素直に嬉しい。
- 目に見えてデプロイ頻度が上がっていた
 - これだけでも移行した甲斐があった
 
 - アカウント移行のスコープ、移行方式等、諸々を整理
- 予想以上にやることが増えているのが見えてきた
 - 一人で捌き切れない(当初目標としていたスケジュールに乗らない)のが分かった
 - チームのメンバーにも移行作業(構築、切替)に協力していただけることに
(めっちゃありがたかった) 
 - アカウント移行の全体計画、スケジュール調整をしつつ、移行に協力してくれたメンバーにもタスクをアサイン
- プロジェクト管理は前職の経験が生きた気がした
 - 複数人で並列作業できるだけで、目に見えて進捗のスピードが上がった
 - 集団の力はマジで凄い。マンパワー最強なり
 
 - この頃にTOEIC 660点を達成
- 一旦の目標の700点には達しないので涙目
 - でも確実に点数は伸びている
 
 - S3、Cloudfront、Redis、RDSの移行を進めた
 - S3
- 無停止で切り替えたかったけど無理だった
 - クロスアカウントでレプリケーションを貼って移行した
 
 - Cloudfront
- 無停止で移行できた
 - 先に新、旧のリソースを作っておき、当日にアプリケーション側の向き先を切り替えるだけ
 
 - Redis
- Redisのデータを引き継ぐ方針
 - その分、移行手順が長くなった
 - 無停止は無理と判断
 
 - RDS
- もちろんデータ移行はマスト。事前の検証にめっちゃ時間を使った
 - 夜間のシステム停止時間をなるべく抑えるために、いくつかの案を用意
 - アカウント間でクロスレプリケーションを貼って、DBを移行
- 事前準備がそこそこ大変
 - システム停止時間を極力短くするならばこの案
 - トータルの手順で考えてみると、割と時間がかかることが分かったので結局は後述の案に
 
 - スナップショットをコピーして、DBを移行
- やっていることはシンプル
 - システムを止めて、DBをコピーして、移行先アカウントでDBを復元、アプリケーションの向き先を切り替えて、システム再開
 - DBのスナップショット作成、スナップショットコピー、Clusterの復元時間がランダム過ぎて発狂していた。10分〜3時間くらいの時間幅があった
 - 最終的にはこっちの案で移行することに
 
 
 - この辺りは、1ヶ月間毎週夜間メンテナンス。体への負荷が大きかった
 - 合間でSRE NEXT 2023へプロポーザル提出
- 先輩に「出してみたら?」と背中を押されて提出を決意
 - 正直、自分なんかが… という気持ちでいっぱいだった
 - ありがたいことにプロポーザルは採択された
 - こっからは業務をしつつ、資料の準備も並行して進めた
 
 
- SRE NEXT 2023発表当日
- 20分間の発表ってめっちゃ長い。学会発表を思い出してしまった
 - といいつつ、いざ資料を準備してみると、時間が足りなくて焦るという
 - とりあえず、憧れの場で発表させていただけたことに感謝
 
 
- 移行と登壇が一区切りついた
 - メトリクスのチューニングとコスト削減に取り組む
 - 9月末にようやくTOEIC 720を達成
- 点数がここまで伸びたのは、正直驚いている
 - 毎日1時間以上勉強して良かった
 - 日々の勉強って大事
 
 - まだまだやることはたくさん
 
感想
- 移行の話は、別途どっかでブログにまとめたい
- 多分同じ悩みを抱える方が多い気がする
 
 - 約10ヶ月でTOEICの点数が430点から720点に上がった
- うろ覚えだが、430 → 480 → 510 → 620 → 660 → 720 みたいな変化だった
 - 最終的な目標は英語で会話できるようになること
 - 正直まだまだ全然話せない
 - 英語の道のりは長い
 
 - 移行プロジェクトを経験できたのは大きかった
- スケジュール管理
 - 移行方式検討 / 課題対応
 - タスク分散による平行作業
 - 2022年までに経験してきたこととは、また違う経験ができたのが2023年であった
 
 - 物事はなるべくシンプルになるように扱う
- 頑張って考えるのもいいが、その結果複雑な仕組みになってしまうのは本末転倒
 - シンプルな方が嬉しいことが数多くある
- 理解されやすい
 - 運用しやすい(秘伝のテクニックに頼ることがなくなる)
 - 結果的に、ミスやエラーの可能性も減る
 
 - 当たり前だけど大事なことなので胸に刻もう
 
 
これから
- プログラミングから遠ざかってる感あるので、趣味でも触る
 - k6もっと詳しくなる
 - 毎日英会話レッスンを欠かさずに
 - 来年も程よく忙しくなりますように…
 - 旅ブログをサボりがちだったので適度に書き殴ろう
 
																	
																	
																	
																	
																	
																	
											
						
						
						
												
						
						
						
												
						
						
						
												
										
					
									