転職ドラフトのインフラをオンプレミスからAWSに移行した話

はじめに

こんにちは2021年に転職会議から転職ドラフトの事業部に異動したyamitaniです。
異動前は転職会議でDB改善などの負債改善をメインにしてました。

made.livesense.co.jp

転職ドラフトでも改善活動を頑張っています。

何について話すか

今回はオンプレ環境で動作している転職ドラフトのサービスをAWS環境に載せ替えた話をします。
載せ替えたときの状況や判断をメインに記載します。
アーキテクチャとかAWS関連の細かい技術のお話はありません。
プロダクトの状況、サイト規模や運用状況によって、色々と判断が変わると思いますが、オンプレからクラウド環境に移行する際の参考になれば幸いです。

移行方針

大規模な変更は避け、現在の形をベースに早期移行を目指す
移行自体をゴールとせず、今後も継続的に改善を行うことを前提とする（コンテナ化等）
基盤改善系のタスクはAWSの移行を待ってから行う

移行自体を最終的なゴールとせず、継続に改善していくことを前提とすることで、メンバーの合意を得て目標スコープを絞ることにした。

なぜその方針にしたのか

一番のリスクは移行期間が伸びることによって、不確実性が増すことだと考えています。
実は年初計画のロードマップではAWSの移行の話は全く存在していませんでした。2月半ばからAWS移行の話が突然立ち上がり始めました。
また、過去に転職会議のAWS移行を経験しています。転職会議ではAWS移行の準備と並行してマイクロサービス化が進んでいて、当初計画から大きくシステム構成に変更が加わった事も経験しています。

そのような過去の経験から、移行期間がながければながいほど、他のプロジェクトが予想外の方向に行ったり、移行準備中に新規開発されたものの差分を埋めたりと状況が大きく変わります。
なので、移行に必要なもの・対応を最小限に絞り、移行期間を最小限にすることでリスクを最低限に抑えることにしました。

ただし、スコープを絞ることは重要なものの、AWS移行後に変更が難しいものに関してはしっかりとした対応が必要です。

サイト規模や条件

感覚値で記載してます。ざっくり認識するぐらいで大丈夫です。

サイト規模は小 ~ 中の間くらい
アクセス頻度は少ない方
参考までに12月回の転職ドラフトの開催情報です。
https://twitter.com/tensyoku_draft/status/1470982852766543879
- 参加企業数 244社
- 参加ユーザー数 498人
  10 ~ 100倍などアクセスが突然スパイクするケースはほぼない。
アーキテクチャ
- モノリシック
重要度
- 小（最悪サイトが落ちても社会インフラに影響を与えることはない）

そもそもの課題

5年間サイト運営を続けた結果、開発環境を含め、色々と改善が必要な箇所が出てきてしまっている。
クラウド環境に載せ替えてから改善したほうが色々とやりやすいことから、AWS移行から始めることにした。

もっとたくさん課題はありますがAWS移行に関係がありそうなものをピックアップしてます。

オンプレ環境で動いているため、スクラップ＆ビルドの試行錯誤がやりずらい
開発チームで対応できそうな事もインフラチームに作業依頼することが多い
オンプレ環境はインフラチームの管轄、自由度高く開発したいため、管轄を開発チームで持ちたい
ステージング環境が社内の他サービスと相乗り状態のため、管理が煩雑
アーキテクチャを設計するときに選べる選択肢の幅が狭い
オンプレ環境の場合とAWS環境の場合を比較した場合、新しいエンジニアを誘致しづらい
etc...

※ 開発チーム = 転職ドラフト事業部内のチーム、インフラチーム = リブセンス全社での横断チーム

移行時の検討事項

どこまで最適化するか
- 基本は現行踏襲で最低限の変更のみで移行する
- AWSに最適化する（オートスケーリング対応、コードデプロイ対応）
- モダン化（コンテナ化）
他プロジェクトの進捗状況
- システム構成の変更がありそうなリリースがあるか
- テスト期間がかぶらないか
- リソースに問題がないか
作業期間
- 3ヶ月
- 半年
- 1年