RDSは「壁の中」でしか喋らないDB 🔒
RDSを触り始めて最初に驚いたのが、
VPC内からしかアクセスできないという前提。
EC2からRDSにつなぎたいだけなのに、
セキュリティグループでアクセス許可を出してあげないと門前払いされる。
「同じAWSの中なら勝手につながるでしょ」と思っていたので、
ここで一つ、AWSの世界観を学んだ気がする。
通信も、データも、暗号化できる 🔐
暗号化には2つのレイヤーがある。
-
通信の暗号化
APサーバ⇔RDS間をSSL/TLSで守る
→ 盗聴・改ざん対策 -
データの暗号化
DB作成時にKMSと連携して暗号化
ここで地味に重要なのが、
データを暗号化すると、関連する周辺データも芋づる式に暗号化されるという点。
- バックアップ
- スナップショット
- ログ
- リードレプリカ
「暗号化＝DB本体だけの話」だと思ってたら、全部巻き込まれるんだ…
ACID特性は「信頼できるDB」の条件
リレーショナルDBが守っている4つの性質。
| 特性 | 内容 |
|---|---|
| 原子性 | 処理が「全部成功」か「全部失敗」 |
| 一貫性 | データの整合性が常に保たれる |
| 独立性 | 同時実行しても互いに干渉しない |
| 耐久性 | 完了した処理は障害後も消えない |
排他的に処理されるからこそ、
安心してお金や在庫のデータを預けられる。
RDS Proxyは「受付の先にいる交通整理係」
RDS Proxyは、DB接続をプーリングして効率化するフルマネージドサービス。
Auroraにも対応している。
サーバレス構成のように接続の確立と切断が激しく発生する環境で真価を発揮する。
主な機能はこの3つ。
-
接続プーリング
一度確立した接続を使い回してリソース節約 -
フェイルオーバー
DBインスタンス障害時に自動でフェイルオーバー -
セキュリティ
Secrets Managerと統合し、DB認証情報を安全に管理
毎回律儀に接続を張り直すのではなく、
「もう繋がってる人がいるから、その回線使って」とさばいてくれるイメージ。
ブルー/グリーンデプロイという「保険付き切り替え」
- ブルー：今動いている現行環境
- グリーン：変更を適用した新環境
いきなり本番を書き換えるのではなく、
別環境を用意してから切り替える。
問題があればブルーに戻せばいいだけなので、
DBの変更のような「後戻りが怖い作業」との相性がいい。
RDS Customは「手を伸ばせるRDS」
通常のRDSは中身をブラックボックスとして扱うが、
RDS Customは一歩踏み込んで、
- OSアクセス
- DB管理権限
まで触らせてくれる。
サードパーティ製品の機能を使いたいケースにも対応。
その代わり、
- インフラ管理
- バックアップ
はAWS側が引き続き担当してくれる。
「自由度は上げたいけど、面倒は見てほしい」という、
ちょっと欲張りな要望に応えるサービスという印象。
まとめメモ ✍️
- RDSはVPC内接続が前提、SGでの許可が必須
- 暗号化はDB作成時に設定、関連データも巻き込んで暗号化される
- ACID特性がリレーショナルDBの信頼性を支える
- RDS Proxyは接続プーリングでリソースを節約
- ブルー/グリーンデプロイは安全な切り替え手段
- RDS Customは管理権限を持ちつつAWSにも支えてもらえる中間的存在
普段何気なく使っているRDSも、
裏側では結構ちゃんと役割分担されているのが分かってきた。