AWS移行の全記録
■概要
以前、オンプレで動いていた古い予約システムをAWSへ移行したのでその内容です。
AWS環境は存在しなかったため、アカウント作成からはじめました。
コンサル会社と契約し、なるべく良い形で進めました。
１１サービスを一気に移行しました。
※サイト規模として、PVは75000/1h。DBのデータ量は100GB。
| 変更項目 | 移行前 | 移行後 |
|---|---|---|
| 環境 | オンプレミス | AWS |
| php | php5.2 | php5.3 |
| DB | mysql 5.1, PostgreSQL9.1.11 | mysql 5.5, PostgreSQL9.5.18 |
| APサーバー | Apache 2.2 | Apache 2.2 |
| sessionサーバー | tokyo tyrant | ElastiCahe(Redis) |
| CDNサーバー | Akamai | Akamai |
| webサーバー | オンプレ x 13 | ec2 x 10 |
サーバー代は150万円/月から、AWS移行後は60万/月まで下がりました。
やったこと
・クラウドの選定。コンサル会社選定
・環境構築＜EC2、RDS、ElastiCache、S3、ELB、VPC・SG・NSネットワークまわり＞
・開発環境整備＜デプロイの自動化など、開発効率UP施策＞
・RDSデータ移行
・アプリ設置
・負荷テスト
・リリース
・運用監視
◆クラウドの選定、コンサル会社選定
AWS、GCM、Azureの中から、コンサル会社複数社に対して見積もりを取り検討。
結果、AWS + クラスメソッドに選定。
Q, C, Dで比較をしましたが、他の企業に比べ全体的に優れていました。
◆インフラ環境構築
EC2、RDS、ALB、NatGatewayなどなどを使う、普通の構成
今までバラバラだったネットワーク関連をルール化して管理
またソースにたどり着くまでにALB、Akamaiを経由することで、ソース側の改修が必要になります。
詳細はこちらの記事にまとめています：
https://qiita.com/ryokwkm/items/cd885d8ef72176587466
DNSをお名前.comから、Route53に移行
route53のゾーンをあらかじめ作っておき、本番移行時にそちら切り替えました。
◆開発環境整備
自動化できるものを以下のように自動化＆ルール化。
デプロイを手動から自動へ
Jenkins + deployerを使ってボタン１つでデプロイできるようにした。
ソースの管理をGitLabからGitHubへ
GitHubでGitHub-Flowを採用して開発、Masterマージにはプルリク承認後でないとマージできない制限をかけた。
GitLabは当時の開発ベンダーが用意したものを使用していましたが、動作が重くなり通常使用に耐えなかった。
◆データ移行
Postgresは、dump＆リストア
Mysqlは、レプリケーションでデータを移行
その他のファイルは rsyncコマンドで持っていき、その後aws s3 sync コマンドでS3へ移動させました。
rsyncは差分だけを持っていきますので、事前に一度実行しておくことで当日は短時間で移動できます。
詳細はこちらの記事にまとめています：
https://qiita.com/ryokwkm/items/0230f547a666b2441d51
◆アプリ設置
ここが一番苦労しました。
・今までサーバーごとにバラバラだったシステムのドキュメントルートを統一（ルール化）
・ソース内の環境依存部分の修正
・ロードバランサーが挟まったことによる修正
・DBの接続先をprivateドメインへ変更
詳細はこちらの記事にまとめています：
https://qiita.com/ryokwkm/items/c6e35d28f8fec72ad3ce
◆負荷テスト
loadRoidというSaasツールを採用
Sonyが作ったという、手軽に負荷試験が行えるツールです。
現在はアルファ版で、なんと無料で使用できます。
負荷試験といえばJMeterという無料ツールがありますが、EC2から実行すると結局実行する側のEC2代がかかってしまいます。
◆運用監視
これまで障害が発生した場合は、
Mackerel -> Twilioで電話 & Slackへ通知 -> リモートデスクトップで作業
という運用だった（DB負荷などで障害がよく起きていた）
AWS移行したことで障害はほとんどなくなったが、運用監視の会社に入ってもらった。
障害発生時のフローを決めておくことで、障害が起きても復旧まで行ってもらえます。
