書籍
データベース
選定手順
STEP1 ： WHAT、WHY、HOW を明確にする
- WHAT：どんなワークロード(用途・要求)があるか
- WHY：移行のビジネス上の目的は何か
- HOW：どのように目的達成を観測するか
STEP2 ： ワークロードの機能要件を見極める
STEP1 で絞ったいくつかのデータベースがワークロードの要件を満たすかどうかをひとつずつ確認し比較する。
場合によっては複数の AWS サービスを組み合わせたり、コストがほかよりもかかったりする可能性もある。
STEP3 ： 最も重要なワークロードやデータ型やデータアクセスパターンを洗い出す
世間一般のユースケースとも照らし合わせ、どのデータベースがよいか評価する。
STEP4 ： データベースの非機能要件を定義する
可用性や性能、セキュリティなどの非機能要件を「必須」と「可能であれば」に分ける。
例：
▶ 可用性
- バックアップ要件
- レプリケーション
- フェイルオーバー
- PITR(Point-in-time-Recovery)
- クエリの制限
- 即座にクロージングするか
▶ 性能
- キャッシュされたデータが頻繁に使用されるか
- 書き込みのノードを水平スケールする必要があるか
- 読み取りのスループットが必要か(その倍位はリードレプリカを用意する)
- トランザクションの同時実行数は高い(10,000 以上)か
- 別リージョンにもデプロイされるか(リージョン間のデータ整合性は求められるか)
▶ セキュリティ
- データ保護
- 認証・認可
- 個人情報などの暗号化が必要なカラムがあるか
- リアルタイムの監査ログが必要か
▶ そのほかの運用
- データベースの監視項目が KPI や SLA、SLO の計測に使用できるか
- 自動的に拡張するか
- スキーマの自動管理が必要か
- 無停止でのアップグレードが必要か
Amazon RDS
一般的には、Amazon RDS が提供するデータベースエンジンをそのままクラウドで利用したい場合は、RDS を選択する。
RDS は EC2 と同様、仮想サーバ上で実行される。EC2 でもデータベース構築は可能だが、RDS と違って自動スケーリングや高可用性、OS・データベースソフトウェアの自動パッチの適用などはユーザーが設計・実装・運用する必要がある。
EC2 で構築するデータベースサービスより RDS にメリットがある部分は以下の通り。
- 既存環境と同じデータベースが使えて、移行の問題も低減できる
- 非機能要求の実装・運用が楽
- 保守・運用コストを削減できる
通常、RDS を利用するほうがメリットは大きいが、以下のケースでは EC2 やオンプレミスでのデータベース構築を検討するべき。
- ハードウェアや OS、ミドルウェア、ソフトウェアなど、RDS では管理できない領域を変更したい
- RDS ではサポートされていないパラメータをチューニングしたい
- 開発環境などの利用で費用を削減したい
RDS では、アプリケーションからの接続を処理する際にメモリや CPU を消費する。
また、RDS の最大接続数は、パラメータグループ内の「max_connections」で管理されている。デフォルトでは、インスタンスクラスを基準とした計算式が設定されていて、手動による変更は推奨されていない。
そのため、同時接続数が上限に達しそうな場合、より高性能なインスタンスに変更して最大接続数を増やすか、RDS Proxy の利用を検討する。
RDS Proxy
接続元のアプリケーションと接続先の RDS お間に設置し、アクセスを中継するフルマネージドサービス。
メリット
- 高性能なインスタンスに置き換えずに済み、コストや運用工数を抑えられる
- フェイルオーバーにかかる時間を短縮できる
- セキュリティの向上 (接続先の RDS に対して IAM ベースの認証を強制できるため)
デメリット
- IP アドレスの枯渇
- セッション固定(ピン留め)による影響
IP アドレスの枯渇
接続先の DB インスタンスクラスとインスタンス数に基づいて必要に応じて自動的に容量を増減し、場合によっては多くの IP アドレスを使用する。これにより IP アドレスが枯渇すると RDS Proxy がスケールできず、クエリ遅延の発生やコネクション失敗につながる。
接続先が 1DB インスタンスの場合の確保すべき IP アドレスは下記の通り。
| DB インスタンスクラス | サブネット内の最少 IP アドレス数 |
|---|---|
| db.*.xlarge 以下 | 10 |
| db.*.2xlarge | 15 |
| db.*.4xlarge | 25 |
| db.*.8xlarge | 45 |
| db.*.12xlarge | 60 |
| db.*.16xlarge | 75 |
| db.*.24xlarge | 110 |
セッション固定(ピン留め)による影響
通常、RDS Proxy は複数のクライアントセッションが同じバックエンド接続を共有することで効率化を図る。しかし、トランザクションなどの操作が行われると、特定のセッションがバックエンド接続に固定され、接続共有ができなくなる。
その結果、パフォーマンスの低下などの影響を及ぼす。
このセッション固定による影響を防ぐには、CloudWatch メトリクスで「DatabaseConnectionsCurentlySessionPinned」を監視し、プロキシがうまく機能しているかどうかをチェックするとよい。
Amazon Aurora
Aurora を使用すると、簡単にデータベースのクラスタとレプリケーションを実装・管理できる。
データベースが MySQL や PostgreSQL で、さらに高い可用性やスループットを達成したい場合は、Aurora を選択するとよい。
構成
Aurora クラスタは、1 つ以上の DB インスタンスと 1 つのクラスタボリュームで構成される。
DB インスタンスには読み取り/書き込みの両方を行う DB インスタンスである「プライマリ DB インスタンス」と、読み取りのみサポートしている「Aurora レプリカ」がある。
RDS で Aurora 以外のエンジンを使用する場合と比べると、インスタンスとストレージが分離されている点が大きく異なります。
レプリケーションとフェイルオーバー
Aurora クラスタのプライマリ DB インスタンスに書き込みが発生すると、通常 100 ミリ秒以下の遅延で Aurora レプリカ側でも書き込まれたデータを参照できるようになる。
そのため、読み取り負荷の高いアプリケーションでは Aurora の利用を検討するとよい。
Amazon DynamoDB
DynamoDB はフルマネージド型の NoSQL データベースである。
NoSQL は「NO SQL」ではなく、「Not Only SQL(SQL だけではない)」を意味し、データを XML 形式や JSON 形式などのドキュメントとして扱う。
スケーラビリティや可用性の高さが特徴で、データサイズが増大しても性能が変わらず、突破的なアクセス負荷への対応も容易である。
学習コストはあるが、費用削減・管理工数削減を目指すクラウドシフトでは利用を検討してみるのがよい。
キャパシティモードとテーブルクラス
DynamoDB には「オンデマンドキャパシティモード」と「プロビジョニング済みキャパシティモード」がある。