サービスイン時のインフラ構成について
新しいサービスは基本的にリリース日マストで短納期で進むことが多いです。
私が携わっているサービスもアプリケーションの開発ボリュームが多く短納期だったため、サービスイン時はインフラ準備に極力工数をかけず、EC2 1台にlaradockでWebアプリケーションを公開する構成でした。
Route 53 → VPC → EC2 (laradockでローカルのmysqlにデータを保存)
いわゆるノーヘル状態。かなり男らしい構成ですね。
EC2が壊れたらデータも消し飛びます。
サービスインより3ヵ月
サービスも徐々に成長してきて、データ量も少しずつ増えてきました。
初期はphpmyadminで手動で不定期でバックアップを取ってましたが、
流石に怖くなってきたので、RDSを導入してデータベースをバックアップできるようにしました。
Route 53 → VPC → EC2 → RDS(multi-AZ)
データベースを外だしすることで少しだけ安心になりました。
RDSを導入するメリット
- EC2から切り離されているので、耐障害性、冗長性、セキュリティが良い
- AWS上で簡単に設定、運用、およびスケールできる
- バックアップやバージョンアップを自動化できる(7日分バックアップを取るようにしました)
デメリット
- お金がかかること
現状のサーバー費用に16,804円/月が追加でかかる
初期スペックはこちら
db.t2.medium
0.104USD * 24時間 * 30日 × 2台 = 16,804円
https://aws.amazon.com/jp/rds/mysql/pricing/
RDS移行までの簡単な手順を以下にまとめました。
0.宣言
まずメンバーに何故、対応が必要か同意をえる。
費用、対応期間、対応方法を明確にする。
1. 現行のデータダンプを取得
phpmyadminを使っていたので
特に説明する必要はないと思いますが..以下コマンドでphpmyadminを起動
docker-compose up -d phpmyadmin
ブラウザアクセスできるように
- AWSのセキュリティグループでphpmyadminに利用するポートを解放
- phpmyadminにアクセス
- データベースを指定してエクスポートを実行
2. RDSのインスタンスを立ち上げ
以下の記事を参考にさせていただきました。
https://qiita.com/na0AaooQ/items/7c69a88c80f1efb4cad3
- エンドポイントは後で必要になるのでコピーしておきましょう
3. ダンプファイルをdockerの/tmp/配下にコピー
docker psでコンテナIDを確認
897bc331c76a laradock-mysql "docker-entrypoint..." 6 weeks ago Up 6 weeks 0.0.0.0:3306->3306/tcp laradock-mysql_1
-
docker cpコマンドでダンプファイルをコピー
docker cp 〇〇.sql 897bc331c76a:/tmp/.
4. mysqlコンテナにbashではいり、リストアコマンドを実行
docker-compose exec mysql bash
mysql データベース名 -h エンドポイント* -u ユーザー名 -p < 〇〇.sql
5. laradockの.envファイルを修正し本番切りかえ
.envファイルのホスト名を
ローカルのデータベース → RDSのエンドポイントに
以上、割と簡単にできました。
サービスイン時はとにかく見た目の部分が優先になってきてしまいますが、
インフラって重要ですね。
アクセスが増えてきたらELBも入れたほうがいいでしょうが、まだまだですね。