はじめに
この記事は自分の学習用の備忘録として作成しています。
何か記事の内容に間違いがあればご指摘ください。
現在、スマホのメモを元に記事を作成していて、画像や構成図などが貼り付けられてないですが、後ほど貼り付ける予定です・
この記事の目的
AWS RDSを使って、インターネットから直接接続できない安全なデータベース環境を構築する流れを整理する。
あわせて、踏み台EC2からRDSへ接続し、SQLでデータベース・テーブル作成・データ登録・参照まで確認する。
最終的なゴール
今回のゴールは以下。
Public Subnet に踏み台EC2を配置する
Private Subnet にRDSを配置する
踏み台EC2からのみRDSへ接続できるようにする
RDSに接続してSQL操作を確認する
構成イメージは以下。
ローカルPC
|
| SSH
v
Public Subnet
|
| 踏み台EC2
|
| MySQL接続 / 3306番
v
Private Subnet
|
| RDS MySQL
ポイントは、RDSを直接インターネットに公開しないこと。
DBは重要なデータを保持するため、Private Subnetに配置し、接続元も踏み台EC2に限定する。
今回作る構成
今回作るリソースは以下。
VPC
├── Public Subnet
│ └── 踏み台EC2
│
└── Private Subnet
└── RDS
セキュリティグループは2つ作る。
jump-sg
- 踏み台EC2用
- SSH接続を許可
db-sg
- RDS用
- jump-sg からの MySQL/Aurora 3306番のみ許可
RDS側のセキュリティグループで、送信元をIPアドレスではなく jump-sg にする。
これにより、踏み台EC2からのDB接続だけを許可できる。
処理の流れ
全体の流れは以下。
1. VPCを作成する
2. Public Subnet / Private Subnet を作成する
3. 踏み台EC2用のセキュリティグループを作成する
4. RDS用のセキュリティグループを作成する
5. DBサブネットグループを作成する
6. RDSインスタンスを作成する
7. Public Subnetに踏み台EC2を作成する
8. 踏み台EC2へ接続する
9. 踏み台EC2からRDSへ接続する
10. SQLでDB・テーブル・データを作成する
11. SELECTで登録結果を確認する
12. 不要なリソースを削除する
手順自体は多いが、やっていることはシンプル。
DBをPrivate Subnetに置く
踏み台EC2だけがDBへ接続できるようにする
踏み台EC2からSQL操作を確認する
RDSとは
RDSは、AWSが提供するリレーショナルデータベースのマネージドサービス。
MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Auroraなどを扱える。
EC2にMySQLやPostgreSQLを直接インストールしてDBサーバを作ることもできる。
ただし、その場合は以下を自分で管理する必要がある。
- OS管理
- ミドルウェア管理
- パッチ適用
- バックアップ
- ストレージ管理
- 冗長化
- 障害対応
RDSを使うと、これらの多くをAWS側に任せられる。
つまり、RDSは「DBを使うための管理負荷を減らすサービス」と考えると分かりやすい。
なぜEC2ではなくRDSを使うのか
アプリケーションのデータは永続化する必要がある。
例えば、ユーザー情報、注文履歴、商品情報、業務データなどは、アプリケーションを再起動しても消えてはいけない。
EC2内にファイルとして保存する方法もあるが、以下の問題がある。
- 検索や更新が複雑になる
- データ整合性を保ちにくい
- EC2が増減する構成と相性が悪い
- バックアップや復旧を自分で考える必要がある
特にAuto ScalingのようにEC2が増減する構成では、1台のEC2内にデータを置くと他のEC2と共有できない。
そのため、アプリケーションサーバとデータベースは分離する。
アプリケーション処理: EC2
データ永続化 : RDS
このように役割を分けることで、アプリケーション側とデータ管理側を分離できる。
なぜRDSをPrivate Subnetに置くのか
DBは重要なデータを持つため、インターネットから直接アクセスできる場所に置くべきではない。
そのため、RDSはPrivate Subnetに配置する。
Public Subnet
- 外部からアクセスされるもの
- Webサーバ
- 踏み台サーバ
Private Subnet
- 外部から直接アクセスさせないもの
- RDS
- APIサーバ
- 内部処理用サーバ
RDSをPrivate Subnetに置くことで、インターネットから直接DBへ接続されるリスクを下げられる。
さらに、セキュリティグループで接続元を制限することで、より安全な構成になる。
なぜ踏み台EC2を使うのか
RDSをPrivate Subnetに配置すると、ローカルPCから直接接続できない。
そこで、Public Subnetに踏み台EC2を配置する。
ローカルPC
↓ SSH
踏み台EC2
↓ DB接続
RDS
踏み台EC2は、管理者がPrivate Subnet内のリソースへアクセスするための中継サーバになる。
今回の構成では、RDSのセキュリティグループで、踏み台EC2からの3306番ポートだけを許可する。
RDS側の許可:
jump-sg → db-sg:3306
これにより、RDSは外部公開せず、踏み台EC2からのみ接続できる。
DBサブネットグループとは
RDSを作成するときには、DBサブネットグループを指定する。
DBサブネットグループとは、RDSを配置できるサブネットの集合。
RDSは高可用性を考慮して、複数のアベイラビリティゾーンにまたがるサブネットを指定する。
今回の例では、以下のようにPrivate Subnetを2つ指定する。
DBサブネットグループ
├── private-subnet-1a
└── private-subnet-1c
重要なのは、異なるAZにあるPrivate Subnetを指定すること。
同じAZ内のサブネットだけでは、AZ障害に弱い構成になる。
そのため、RDSでは複数AZを前提にサブネットグループを作る。
セキュリティグループ設計
今回のセキュリティグループは2つ。
踏み台EC2用: jump-sg
名前: jump-sg
インバウンド:
SSH 22番
送信元: 自分のIPアドレス
学習用では 0.0.0.0/0 にするケースもあるが、本番では危険。
SSHは管理用の入口なので、接続元は必ず絞るべき。
悪い例:
SSH 22番 0.0.0.0/0
良い例:
SSH 22番 自分のグローバルIPのみ
RDS用: db-sg
名前: db-sg
インバウンド:
MySQL/Aurora 3306番
送信元: jump-sg
ここで送信元を jump-sg にするのがポイント。
IPアドレスではなくセキュリティグループを指定することで、jump-sg が付与されたEC2からの通信だけを許可できる。
jump-sg が付いたEC2
↓ 3306番
db-sg が付いたRDS
このように、AWSではセキュリティグループ同士を使って通信許可を設定できる。
なぜこのように構成するといいのか
この構成のメリットは以下。
- RDSをインターネットに直接公開しない
- DB接続元を踏み台EC2に限定できる
- RDSとEC2の役割を分離できる
- セキュリティグループで通信経路を明確にできる
- DB接続エラー時に切り分けしやすい
DBをPublic Subnetに置いて、外部から直接接続できるようにするのは簡単。
ただし、セキュリティ上はかなり危険。
実務では、DBはPrivate Subnetに置き、アプリケーションサーバや踏み台サーバからのみ接続する構成が基本になる。
RDS作成時の主な設定
RDS作成時に見るべき主な設定は以下。
DBエンジン
- MySQL / PostgreSQL / Aurora など
テンプレート
- 本番環境
- 開発/テスト
- 無料利用枠
DBインスタンス識別子
- RDSインスタンス名
マスターユーザ名
- 管理ユーザ
マスターパスワード
- DB接続用パスワード
VPC
- RDSを配置するVPC
DBサブネットグループ
- RDSを配置できるPrivate Subnet群
パブリックアクセス
- なし
VPCセキュリティグループ
- db-sg
特に重要なのは以下。
パブリックアクセス: なし
VPCセキュリティグループ: db-sg
DBサブネットグループ: Private Subnetを含むグループ
ここを間違えると、意図せずDBが外部公開されたり、逆に接続できなかったりする。
RDSの接続情報
RDS作成後、接続に使う情報は以下。
エンドポイント
ポート番号
ユーザ名
パスワード
DBエンジン
接続コマンド例は以下。
mysql -h RDSのエンドポイント -u admin -p
-h にRDSのエンドポイントを指定する。
-u にユーザ名を指定する。
-p を付けると、実行後にパスワード入力を求められる。
接続に成功すると、プロンプトが以下のようになる。
mysql>
この状態になれば、RDSへ接続できている。
SQLで動作確認する
接続後、SQLを実行してDB操作を確認する。
データベース作成
CREATE DATABASE sample_db;
作成されたか確認する。
SHOW DATABASES;
データベースを選択
USE sample_db;
テーブル作成
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(100)
);
データ登録
INSERT INTO users (name, email) VALUES ('Yamada Taro', 'taro@example.com');
INSERT INTO users (name, email) VALUES ('Suzuki Hanako', 'hanako@example.com');
データ確認
SELECT * FROM users;
想定結果。
+----+---------------+--------------------+
| id | name | email |
+----+---------------+--------------------+
| 1 | Yamada Taro | taro@example.com |
| 2 | Suzuki Hanako | hanako@example.com |
+----+---------------+--------------------+
ここまで確認できれば、踏み台EC2からRDSへ接続し、DB操作できている。
接続できないときの切り分け
RDSに接続できない場合、闇雲に設定を変えない。
以下の順番で確認する。
1. RDSのエンドポイントが正しいか
接続コマンドの -h に指定しているエンドポイントが正しいか確認する。
mysql -h RDSのエンドポイント -u admin -p
コピー時に空白が混ざっていないかも確認する。
2. RDSが利用可能状態か
RDSのステータスが 利用可能 になっているか確認する。
作成直後はまだ起動中のため、接続できないことがある。
3. セキュリティグループが正しいか
RDS側の db-sg で、踏み台EC2の jump-sg から3306番が許可されているか確認する。
db-sg のインバウンド:
MySQL/Aurora 3306
送信元 jump-sg
ここが間違っていると、踏み台EC2からRDSへ接続できない。
4. RDSがPublic Accessなしになっているか
RDSをPrivate Subnetに置く場合、パブリックアクセスは なし にする。
ただし、接続元である踏み台EC2は同じVPC内から接続できる必要がある。
5. ユーザ名・パスワードが正しいか
ネットワーク的に到達できていても、認証情報が違うとログインできない。
よくあるエラー。
ERROR 1045 (28000): Access denied
この場合は、ユーザ名またはパスワードを疑う。
6. ネットワーク到達性の問題か、認証の問題かを分ける
エラーによって原因を切り分ける。
ERROR 2003:
DBサーバに接続できない
ネットワーク、SG、エンドポイント、ポートを確認
ERROR 1045:
認証エラー
ユーザ名、パスワード、権限を確認
接続エラーは、ネットワーク問題と認証問題を分けて考えると整理しやすい。
RDSの主要機能
今回のハンズオンでは基本構成が中心だが、RDSには運用で重要な機能がある。
Multi-AZ
Multi-AZは、別のアベイラビリティゾーンにスタンバイDBを用意する構成。
通常時はプライマリDBが動き、障害時にはスタンバイDBへ自動的に切り替わる。
AZ-a: プライマリDB
AZ-c: スタンバイDB
目的は可用性の向上。
本番環境では、単一AZよりMulti-AZ構成を検討する。
リードレプリカ
リードレプリカは、読み取り専用のDBコピー。
検索や参照処理が多い場合、読み取り処理をレプリカに逃がすことで、メインDBの負荷を下げられる。
書き込み:
アプリ → プライマリDB
読み取り:
アプリ → リードレプリカ
注意点として、リードレプリカは基本的に読み取り専用。
書き込み負荷を分散するものではなく、読み取り負荷を分散するための仕組み。
自動バックアップ
RDSには自動バックアップ機能がある。
指定した保持期間内で、特定時点に復元できる。
これをポイントインタイムリカバリという。
例えば、誤操作やアプリの不具合でデータが壊れた場合に、過去の時点へ戻せる可能性がある。
手動スナップショット
手動スナップショットは、任意のタイミングで取得するバックアップ。
作業前や検証前など、状態を保存しておきたいときに使う。
大きな変更前
移行作業前
検証環境作成前
このようなタイミングで取得しておくと、復旧や複製に使える。
パラメータグループ
RDSでは、OSへ直接ログインして設定ファイルを編集できない。
その代わり、パラメータグループでDB設定を管理する。
例：
文字コード
タイムゾーン
接続数
ログ出力設定
EC2上のDBなら設定ファイルを直接編集するが、RDSではパラメータグループを通して管理する。
メンテナンスウィンドウ
メンテナンスウィンドウは、AWS側のメンテナンスやパッチ適用を行う時間帯を指定する設定。
業務時間中にメンテナンスが走ると影響が出る可能性がある。
そのため、深夜や早朝など、影響が少ない時間帯を指定するのが基本。
注意する箇所
RDSをパブリック公開しない
学習目的であっても、RDSを不用意にインターネット公開しない。
パブリックアクセス: なし
DBはPrivate Subnetに配置し、接続元を限定する。
SSHを0.0.0.0/0で開けっぱなしにしない
踏み台EC2のSSHを 0.0.0.0/0 にすると、世界中からSSH接続を試される状態になる。
学習時に一時的に使う場合でも、作業後は削除するか、接続元を自分のIPに限定する。
SSH 22番: 自分のIPのみ
パスワードを紛失しない
RDS作成時のマスターパスワードは、あとから画面で確認できない。
必ず安全な場所に控える。
ただし、GitHubやQiitaの記事には絶対に載せない。
DBサブネットグループは複数AZを使う
DBサブネットグループには、異なるAZのサブネットを含める。
同じAZのサブネットだけでは、可用性の観点で弱い。
良い例:
private-subnet-1a
private-subnet-1c
悪い例:
private-subnet-1a
private-subnet-1a-2
RDS削除時のスナップショットに注意
検証用RDSを削除するとき、最終スナップショットを作るかどうか確認される。
学習用で不要な場合は作成しない。
ただし、本番や重要データがある場合は、削除前に必ずバックアップ方針を確認する。
リソース削除忘れに注意
RDS、EC2、VPCなどを放置すると課金が発生する。
学習後は不要なリソースを削除する。
削除順の例。
1. RDSインスタンス
2. DBサブネットグループ
3. EC2インスタンス
4. VPC
RDSの削除には時間がかかるため、先にRDS削除を開始してから他のリソースを削除するとよい。
今回学んだ切り分け観点
RDS接続で問題が起きた場合は、以下を確認する。
接続先:
- RDSエンドポイントは正しいか
- ポートは正しいか
認証:
- ユーザ名は正しいか
- パスワードは正しいか
ネットワーク:
- RDSは利用可能状態か
- RDSは同じVPC内にあるか
- DBサブネットグループは正しいか
- db-sgで3306番が許可されているか
- 送信元がjump-sgになっているか
接続元:
- 踏み台EC2に接続できるか
- MySQLクライアントが入っているか
保守作業では、この切り分け観点が重要になる。
「DBに接続できない」と言っても、原因は1つではない。
- ネットワーク設定の問題
- セキュリティグループの問題
- エンドポイントの誤り
- 認証情報の誤り
- RDSが起動していない
- クライアント側の問題
このように分解して確認すると、原因を絞り込みやすい。
まとめ
今回、RDSを使ってプライベートなデータベース環境を構築した。
学んだことは以下。
- RDSはAWSのマネージドなリレーショナルDBサービス
- DBはEC2内ではなくRDSに分離して永続化する
- RDSはPrivate Subnetに配置するのが基本
- Public Subnetには踏み台EC2を配置する
- DBサブネットグループでRDSを配置するサブネットを指定する
- RDS側のSGでは、踏み台EC2のSGからの3306番のみ許可する
- RDSエンドポイントを使ってDBへ接続する
- SQLでDB作成、テーブル作成、INSERT、SELECTを確認できる
- 接続できない場合は、エンドポイント、認証情報、SG、サブネット、RDS状態を切り分ける
- Multi-AZ、リードレプリカ、バックアップ、スナップショットは運用で重要
RDSは単にDBを作るサービスではなく、データを安全に永続化し、運用負荷を下げるためのサービスだと理解した。
今後は、Java / Spring Boot / MyBatis からRDSへ接続し、アプリケーション経由でデータ登録・参照できる構成まで進めたい。