EC2で稼働していたWebサーバを5日(嘘はついてない)でFargateに置き換えた話

# あらすじ

とある日とあるサービスのアクセスが増加し、Webサーバの台数が足りなくなりました。
当時の対応者は手動でその時点のAMIを作成し、新しいサーバを起動してLBの配下においたもののHealth Checkが通らず混乱をきたしておりました。
Security Groupの設定が足りておらずということに気づいて指摘して直ったですが、私はつらみを二度と味わわせたくない、そもそもこんな手作業する必要ないと思い、Fargateへの移行を提案したのでした。

# 最初に結論

何においても全体像を把握して計画を立てることは大事ですね。
![keikaku1.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42333/f9ddc1c2-3aed-c116-c969-1d16952c10d4.jpeg)


# 最初の関門

「よしじゃあ最優先でFargate化を進めよう！」となるかというと、当時このあたりを担当できるメンバーは他の仕事もあり集中して取り組める環境ではありませんでした。
![isogashii.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42333/86c97126-0309-9171-aeb1-db586d30bc6a.jpeg)

しかしあるとき **なんでか5日くらいまとまった時間が取れる時があったので** そこで取り掛かることにしました。
逆に言うと5日で終わらなければ移行不可、さて我々に実行ができるのか・・・！

# 最初にやったこと

**流石にすべての作業を5日間の中でやる必要はない** (タイトル詐欺)ので、事前に準備しておくこと、事後に行うことをそれぞれわけて、5日間でやらなければいけないことを洗い出しました。

下記のようにマインドマップみたいなものを作成して洗い出してみたのですが、もっとMECEにできるようなものを使ったほうがいいかもしれないです。(今回はこれで困りはしませんでしたが)

![IMG_2609.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42333/7a577d45-e7e1-1ccf-0afb-da6606697143.jpeg)
(省庁には劣る黒塗り度)

これを書いてから必要な作業を洗い出しました。
この図を例にして書くと下記になります。
※実際はこれを書き下しているときに思いついたりしたものも追記したりしてます
※最初からこちらを書いてもよいです

* stg構築
* 本番構築
* スケジュールを立てる
    * MUSTとWANTに分ける
    * 切り戻して順を考える
        * ALBで振り分ける
* テスト
    * 負荷試験
* バッチ
    * バッチ洗い出し
* メンテ画面
* コスト
* デプロイ
    * CI
    * 切り戻し
* 監視
* マニュアル化(ドキュメント)
* 競合
* ログ
* セキュリティ
* BaseImage

こうして書き下したものからMUSTとWANTにわけ、そのMUSTの中でも5日間にやる必要なものとそうでないものにわけました。

* MUST
    * 事前
        * スケジュールを立てる
        * Docker/Fargateの学習
    * 5日間の中でやる
        * ローカルで今のサービスをコンテナで動かす
        * ネットワーク調査
        * stg構築
        * ログ調査、設定
        * デプロイ、マイグレーション方法検討、構築
        * AutoScale検討、構築
        * セキュリティ設定確認
        * 本番構築
        * 本番移行(一部)
        * テスト
    * 事後
        * バッチ移行
        * メンテ画面
        * 全部移行
        * コストカットのためEC2の削除
* WANT
    * stg複数作る
    * chat-ops
    * CI
    * IaC

# 実際に立てたスケジュール

* 1日目
    * ローカルで今のサービスをコンテナで動かす
* 2日目
    * ネットワーク調査
    * stg構築
    * ログ調査、設定
* 3日目
    * デプロイ、マイグレーション方法検討、構築
    * AutoScale検討、構築
* 4日目
    * セキュリティ設定確認
    * 本番構築
* 5日目
    * 本番移行
    * テスト
    * 様子見
* 全体で行う
    * ドキュメントを随時まとめる
* 5日間以降に検討して取り掛かるもの
    * stg複数作る
    * chat-ops
    * CI
    * IaC
    * バッチ移行
    * メンテ画面
    * 手動バッチ移行

# 肝だった点
![kimo.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42333/23835ba6-6ebd-1844-ac48-469c28e3cecc.jpeg)

## 最初に全部移行しない

今回結果だけみると最初から全部移行しても問題なかったのですが、Webサーバを(なるべく同じバージョンのものを選んだとは言え)丸々置き換えたので何か発生しうるのではないか？(発生する根拠はないが、逆に言うと何も発生しない確信もなかった)と考えたため、最初は「とある条件のリクエストだけFargateのターゲットグループに向ける」ということを行いました。

これはAWSのALB様々で、このあたりの制御が簡単にできることが5日間での移行を後押ししてくれたことに間違いありません。

そして1ヶ月位の間で徐々に条件を緩くして「何も発生しないな！」というのを確認してすべてFargateに移行しました。

## ざっくりでいいのでスケジュールを立てる

用意された期間での移行が実際に可能そうか確認できたことと、 **5日間の中でやるべきことの見極め** ができたことが良かったかなと思います。
実際5日目は余裕で終わったので、WANTを先取りしたり、早く上がって飲みに行ったりしました！

# 付録：技術的に躓いた点ピックアップ

![nayamu.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42333/a1eef13b-406c-a190-a992-caef9fc10dcb.jpeg)

* reapedって出て落ちる
    * Health Checkに通らないと落とされる
* LoadError: libruby.so.2.5: cannot open shared object file / bundler: failed to load command: unicorn_rails / kgioがないとか
    * 時間短縮になると思い bundle install してからCOPYしていたが、コンテナ上で bundle install しないといけない
* B/GデプロイのTargetGroupがよくわからなかった
    * ALBに優先度1と0にして最初は2つつける。