2024年12月8日

初めて対応したインフラの改修の流れ

1.現状確認

どんなAWSリソースが現状使われているかわからなかったので本番環境とステージング環境を確認した。 だいぶ前に作られていたAWS構成図はあったがそのAWS構成とは異なる部分もあったので、きちんと更新していかないと調査の工数がかかったり不要な作業が発生してしまう。

2.要件確認

要件を確認して目的を明確にすることで、対応期間の設定と自分の対応する範囲を決める。 今回の目的は既存のAPIサーバーを分離させて、サービスの安定化を図ること。 (できればそれぞれのサービスでコストを把握したい。それをするのであれば、別のAWSアカウントで分離させてAWSリソースを管理させる必要がある。今回は技術的かつ対応期間にそこまでできなさそうなので断念した。)

3.AWS構成図作成及びコスト算出

1と2で現状とやることを明確にしたので、目的を達成するために何をどうするのかを決める。 既存のAWSリソースを使うこと、新たにAWSリソースを作成することなど。 その際に今後かかるコストもAWSの公式を見ながら、概算ではあるが1月当たりの金額を算出する。 1時間単位や1月単位の課金となるので、1月あたりに変換した。

4.AWS構成とコストの合意

作成したAWS構成図を先輩エンジニアにレビューしてもらう。 構成的に問題なさそうであれば、非エンジニアの方に今回対応する内容を簡易的に説明する。 その際にかかる費用について問題ないかを確認する。 もし、費用がかかりすぎてしまう場合はAWS構成を変更して費用を少なくできないかを考える。(今回は費用は問題がなかった。)

5.ステージング・本番作業

ステージング環境の手順書、本番環境の手順書をそれぞれ作成して、対応。 実際にサーバーを分離する作業の時間を短縮するために、事前に作成できそうなAWSリソースは作成してしまう。 作業に影響ある方々へのスケジュール連絡と作業方針の事前連絡は必ずやる。 別のサービスに影響がないことも確認する。 ユーザーがなるべく使っていない時間帯かつ何かあってもすぐに対応できる時間帯を選んで作業を行う。