先日海釣りへ行って、43.5cmと中々良いサイズの甘鯛を釣りました。
インフラチームの長崎です。
アカウント移行とは
移行と書いてはいますが、既存リソースを旧アカウントから新アカウントへ移す訳ではなく、既存リソースと同様の設定、アプリケーションで新アカウントへ構築していきます。(mvではなくcpのイメージ)
目的は、セキュリティや運用、管理性の向上などがあります。
なぜやったのか
弊社のAWSアカウントの中には、まだAWSの知見がインターネット上にそれほど存在しなかった太古の昔から利用しているものが存在します。
本番、ステージング、開発環境が混在しており、運用の中で設定するリソースを取り違えるリスクがあったり、本番環境があるが故に操作権限を厳しく絞る必要があり、開発環境での検証が制限されたりする事がありました。
これらの課題を解決する為に本番環境はそのままでステージングと開発環境を新たなAWSアカウントへ移行するプロジェクトを推進する事となりました。
大まかな移行の流れ
下記のような順番で対応を進めていく事としました。
- リソース調査
- 移行方針の検討
- 動作確認の検討
- 移行対応
- 動作確認
リソース調査
まずはAWSアカウント内にどんなリソースが存在するかの調査から始めました。 機能毎に下記のようなチェック項目を置きました。
※1
| No. | チェック項目 | 確認単位 | 説明 |
|---|---|---|---|
| 1 | 移行のするかしないか | リソース | 明らかに一時的な検証や開発用途で作成されたものや利用用途が不明なものは移行対象から外します。判断つかないものは関係各所に確認しました。 移行対象はスプレッドシートやエクセル等にリストを作成してメモしました。 |
| 2 | 構築手段は何か(IaC or 手動) | リソース | 弊社では主にterraformを使ってリソースを管理しています。terraformかどうかはリソースタグで判断ができるようになっています。 terraform以外だとCFnかコンソールから構築されたものでした。 |
| 3 | 他アカウントのリソースと通信しているか | 機能 | 他アカウントとのVPC Peeringやルートテーブル設計の参考とする目的で調査しました。 主にルートテーブルの情報から調査を進めました。 |
| 4 | サードパーティ製品との連携はあるか | 機能 | サードパーティ製品側の設定等の必要有無を確認する目的で調査しました。 社内にある機能の説明資料から情報収集しました。 |
| 5 | 移行過渡期に増加するコストはどれくらいか | 機能 | AWS Pricing Calculator を使って概算を出しました。 |
移行方針の検討
「構築手段」と「AWSサービス」単位で移行方針を決定しました。
上記※1の表で記載の通りterraformでのリソース管理をメインとしたい為、CFnやコンソールから作成したリソースはterraformにインポートする方針としました。
AWSサービスは既存リソースと同様の状態とする為に抑えておくポイントの方針決定をしました。
特にデータ移行が必要、既存設定と同じものが作成できない、同時稼働させられないサービスを中心に検討を進めました。
EC2
- 既存リソースからAMIを取得し、新アカウントにコピーする
- キーペアは新規作成
RDS
- 既存DBからdumpを取得し、新規DBへインポートする
※terraform管理上、作成→データを入れる。なのでこの方法を取りましたが、今思えばスナップショットから作成してterraformへインポートする方が簡単だったかなと思ってます。
S3
- バケット名は一意なので、既存のものとは別名にする(IAMポリシー等でバケット名を指定している場合は変更が生じる)
- データ移行はクロスアカウントレプリケーションを利用してコピーする
- 本番環境と共用しているような移行が難しいバケットは、新アカウントからアクセスできるようバケットポリシーを設定する
DynamoDB
- データ移行はcross-account-amazon-dynamodb-replicationを利用して行う
※テーブルのデータ容量が140GB未満なので、この方法を採用しました。
SNS
- 通知がされないようサブスクリプションを外しておく(既存が稼働している間は通知が重複してしまう為)
Security Group
- 他アカウント側のインバウンドルール穴あけ
Route53
- 既存のメインで使っているドメインからサブドメインを切ってホストゾーンを作成する
などなど予め決めておきました。
どれだけしっかり決めといても何かしらうまくいかないところは出てくる想定だったので、それらは動作確認時のエラーから修正する事としました。
動作確認の検討
機能毎に確認観点は少しずつ異なりますが、主に下記の3点の内容を確認する事としました。
- 疎通テスト(連携するリソース同士が通信できる状態か)
- アプリケーションレベルでプログラム動作に問題がないか
- サービスサイトをUIから操作し、エラーが発生しないか
移行対応
NW
一番最初にNWを構築しました。(NWがないとリソース配置できないので必然ですが・・)
弊社では今のterraform管理とする前に作成したVPCやサブネットを使用していたので、機能毎に設計してterraformで新規作成する必要がありました。
機能は多岐に渡り、一つ一つNW構成を確認するのは少し骨が折れる為、機能毎のサブネットはAZで冗長構成を取り、public(インターネットに面している)、protect(NAT経由でインターネットへ出られる)、private(インターネットへ出られない)で定義し、機能に属さないNATGWは単独のサブネットとして作成しました。
こうする事でパッケージ化できて、terraformのNW部分は記述がそのまま流用できるので効率的でした。
※インターフェース型エンドポイントのサブネットだけは、publicやprotectは不要なので、privateのみ作成して設定しました。
※イメージ図
その他リソース
terraform以外の手段で作成されたリソースをterraformに取り込みながら、予め作成したNWへ配置していきました。
動作確認
方針決定した内容で確認していきました。
元々発生したエラーから足りない設定を補足していくつもりだったので修正箇所の判断が付くものが多かったですが、あれ？原因が全然分からん！となったエラーもありました。
ここが移行の中で一番大変だったところかもしれません。後述します。
大変だったところ
リソースのterraformへの取り込み
今後の運用を考えた上で取り込む必要があるので、管理をなるべくしやすくする必要があります。
なので、ただ記述するだけではなくmodule化したり、ファイルを管理するフォルダ構成を変更したりしました。
それら変更に伴って、本番環境側の記述も合わせる必要が出てきたりって事もありました。
なるべく本番、ステージング、開発環境でterraformの記述を統一できるよう注力しました。
動作確認で想定外のエラー
移行元と同じように環境構築していますが、移行中も移行元の環境では開発・リリースが行われているのでそこで差分が生じて、エラーとなるケースが多かったです。
例えば、移行元DBに新しいカラムが追加されたが、移行先DBにそのカラムが取り込めていないが故にエラーが出力されていたり。
原因特定に時間がかかるものは、移行が全て完了した後に再度確認する事とし、あまりエラーの調査に時間をかけすぎないようにしました。
エラーの切り分けでスケジュールが遅延して、移行が進まないという状況は避けたかったです。
(案外忘れがちだった)Route53プライベートホストゾーンへのVPC関連付け
名前解決エラーが出力されて、確認したらプライベートホストゾーンに他アカウントVPCを関連付けてなかったって事がありました。
まとめ
一つのAWSアカウントにリソースを作成して運用しているけど、別アカウントに移行したいと思う場面は結構あるのかなと思っています。
企業毎に扱うAWSサービスも運用方法も違うので参考にできる要素は少ないかもしれませんが
このブログが移行を検討している方の一助になることができたら嬉しいです。
オープンワークでは、一緒に働いてくれるメンバーを募集しています。 www.openwork.co.jp
