とある案件での話。
システム構成とやりたいこと
- EC2内にRailsアプリケーション(rails4.2)が存在し、同EC2内のPostgreSQLを参照している状態。
- PostgreSQLは同EC2内のESへ非同期での反映を行っている(searchkickというgemで勝手にいい感じにやってくれている)。
- 上記システムはテスト環境だが、Staging環境、本番環境と構成が違う(PostgreSQLではなく、RDSを使っている)。
- 大きなトラブルが発生したときにテスト環境で原因究明するために、環境揃えましょうということになり、PostgreSQLをRDSに置き換えたときのまとめ。
やったこと
- EC2からRDSへ接続できるセキュリティグループ(※1)作成
- RDS構築(※2)
→RDSへアクセスするEC2へSSHログインして、psqlで疎通確認
-
psql -h <RDS構築後に発行されるエンドポイントのURL> -U <従来のテスト環境でのPosgtresマスターユーザー> -d <従来のテスト環境でのPostgres DB名> -W(＋パスワード入力)
- EC2へログインし、Railsアプリケーションで読み込んでいるPostgreSQL接続設定を変更する
- ユーザー名: RDS構築時に設定したマスターユーザー
- パスワード名: RDS構築時に設定したマスターユーザーのパスワード
- ホスト名: RDS構築後に発行されるエンドポイントのURL
- DBの作成とマイグレーション
- DBの作成：新規の場合、以下のコマンドを打たなくてはならなかったが、RDSを構築した時点でやっている状態なので不要
RAILS_ENV=integration bundle exec rake db:create
- DBのマイグレーション
RAILS_ENV=integration bundle exec rake db:migrate
- DBへ初期データをセット
RAILS_ENV=integration bundle exec rake db:seed_fu
- ESに初期データを反映
bundle exec rails runner 'User.reindex' -e integration
※1 セキュリティグループ作成
- VPCのAWSマネジメントコンソール画面へアクセス
- 以下の設定で空っぽのセキュリティグループを作成
| 項目 | 値 |
|---|---|
| セキュリティグループ名 | 任意 |
| 説明 | テスト環境用のEC2からテスト環境用のRDSへのアクセスを許可 |
| VPC | テスト環境用EC2が所属するVPC IDを選択 |
- 作成したセキュリティグループに対してさらに以下の設定を施す
| 項目 | 値 |
|---|---|
| タイプ | PostgreSQL |
| プロトコル | タイプの選択により勝手にTCPになる |
| ポート範囲 | タイプの選択により勝手に5432になる |
| ソース | EC2が所属するセキュリティグループを指定 |
| 説明 | なし |
※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エンジンのリファレンスを見に行くしかない。 |