[AWS]RDSの構築まとめとEC2内PostgreSQLからの移行

とある案件での話。

**システム構成とやりたいこと**

![postgreSQL移行.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59542/2aed6285-881e-5f53-b7c8-a1faa010755f.jpeg)


- EC2内にRailsアプリケーション(rails4.2)が存在し、同EC2内のPostgreSQLを参照している状態。
- PostgreSQLは同EC2内のESへ非同期での反映を行っている(searchkickというgemで勝手にいい感じにやってくれている)。
- 上記システムはテスト環境だが、Staging環境、本番環境と構成が違う(PostgreSQLではなく、RDSを使っている)。
- 大きなトラブルが発生したときにテスト環境で原因究明するために、環境揃えましょうということになり、PostgreSQLをRDSに置き換えたときのまとめ。


# やったこと
1. EC2からRDSへ接続できるセキュリティグループ(※1)作成
2. RDS構築(※2)
  →RDSへアクセスするEC2へSSHログインして、psqlで疎通確認
  - ``psql -h <RDS構築後に発行されるエンドポイントのURL> -U <従来のテスト環境でのPosgtresマスターユーザー> -d <従来のテスト環境でのPostgres DB名> -W`` (＋パスワード入力)
3. EC2へログインし、Railsアプリケーションで読み込んでいるPostgreSQL接続設定を変更する
  - ユーザー名: RDS構築時に設定したマスターユーザー
  - パスワード名: RDS構築時に設定したマスターユーザーのパスワード
  - ホスト名: RDS構築後に発行されるエンドポイントのURL
4. DBの作成とマイグレーション
  - DBの作成：新規の場合、以下のコマンドを打たなくてはならなかったが、RDSを構築した時点でやっている状態なので不要
      - ``RAILS_ENV=integration bundle exec rake db:create``
  - DBのマイグレーション
      - ``RAILS_ENV=integration bundle exec rake db:migrate``
5. DBへ初期データをセット
  - ``RAILS_ENV=integration bundle exec rake db:seed_fu``
6. ESに初期データを反映
  - ``bundle exec rails runner 'User.reindex' -e integration``

# ※1 セキュリティグループ作成
- VPCのAWSマネジメントコンソール画面へアクセス
- 以下の設定で空っぽのセキュリティグループを作成

項目|値
---|---
セキュリティグループ名|任意
説明|テスト環境用のEC2からテスト環境用のRDSへのアクセスを許可
VPC|テスト環境用EC2が所属するVPC IDを選択

- 作成したセキュリティグループに対してさらに以下の設定を施す

項目|値
---|---
タイプ|PostgreSQL
プロトコル|タイプの選択により勝手にTCPになる
ポート範囲|タイプの選択により勝手に5432になる
ソース|[EC2が所属するセキュリティグループを指定](https://github.com/mechamogera/MyTips/wiki/EC2%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AESource%E3%81%AB%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%82%92%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%9F%E5%A0%B4%E5%90%88%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E7%A2%BA%E8%AA%8D)
説明|なし

# ※2 RDS構築
- RDSのAWSマネジメントコンソール画面へアクセス
- 以下の設定でRDSインスタンスを作成(基本的にstaging環境と揃えた)


項目|値
---|---
エンドポイント|<自身で設定不可能な項目>
ポート|staging環境と同様
アベイラビリティーゾーン|staging環境と同様
VPC|EC2と同じVPCにする
サブネットグループ|EC2と同じVPCにする
サブネット|<自身で設定不可能な項目>
VPCセキュリティグループ|「セキュリティグループ作成」で設定したやつ
パブリックアクセシビリティ|staging環境と同様
認証機関|<自身で設定不可能な項目>
証明機関の日付|<自身で設定不可能な項目>
DBインスタンスID|ただの表示名なのでわかりやすい名前でOK
エンジンバージョン|staging環境と同様
DB名|従来のテスト環境で使っていたユーザー名
ライセンスモデル|staging環境と同様
オプショングループ|staging環境と同様
ARN|<自身で設定不可能な項目>
リソース ID|<自身で設定不可能な項目>
パラメータグループ|staging環境と同様
削除保護|staging環境と同様
インスタンスクラス|staging環境と同様
vCPU|<自身で設定不可能な項目>
RAM|<自身で設定不可能な項目>
マスターユーザー名|従来のテスト環境で使っていたユーザー名
IAM db 認証|staging環境と同様
マルチ AZ|staging環境と同様
セカンダリゾーン|staging環境と同様
暗号化|staging環境と同様
ストレージタイプ|staging環境と同様
IOPS|staging環境と同様
ストレージ|テスト時に本番環境のDBをリストアしたかったので多めに
ストレージの自動スケーリング|staging環境と同様
Performance Insights が有効|staging環境と同様
マイナーバージョン自動アップグレード|staging環境と同様
メンテナンスウィンドウ|staging環境と同様
DBのパスワード(確認不可)|8文字以上で設定(RDSの仕様)


# 用語まとめ
用語|意味
---|---
VPC|Virtual Private Cloud。AWS内の他と切り離された仮想NWのこと
サブネット|VPC内にprivateなサブネットとpublicなサブネットを設けることができる。private-public間では通信OK、privateなサブネットに所属するインスタンスへは外部からのアクセス不可能、publicなサブネットに所属するインスタンスへは外部からのアクセス可能
サブネットグループ|2つ以上のサブネットの集合であり2つ以上のAZを含む必要がある サブネットA-AZ1 サブネットB-AZ2、サブネットC-AZ2→OK!みたいな。RDSの場合、サブネットグループを割り当てる必要がある。シングルAZ構成のRDSの場合は、更に実際に配置するAZをサブネットグループに含まれているAZから一つ選択してやる必要がある。マルチAZ構成のRDSの場合は逆に選択できない。
セキュリティグループ|VPC内のインスタンス1つ1つに割り当てるファイアウォール設定。インバウンド(そのインスタンス以外からそのインスタンスへのアクセス)、逆のアウトバウンドともに設定できる。セキュリティグループを作っておいて、これをインスタンスに付与していく形。
パラメータグループ|これはDBエンジン(PostgreSQLとかMySQLとか)レベルの話。まず、パラメータというのはDBエンジンに対する根本的な設定項目であり、例えば性能関連の設定があったりする。DBエンジンごとに当然設定項目は違う。設定できる項目については、各DBエンジンのリファレンスを見に行くしかない。



# その他
- [別アカウント間のRDS移行](https://qiita.com/WisteriaWave/items/436a4b78db9090f01d58)