【AWS】「RDS」の設定手順、Aurora、インスタンスの設定確認、スナップショット

RDSとは？

AWSのフルマネージドなRDBSのサービスになります。フルマネージドなので構築や運用等は全てAWS側がやってくれるのでアプリの最適化等のコア機能の実装に集中することが可能です。また、RDBSの設計に関してもAWSエンジニアのDB設計のベストプラクティスが適用されています。

RDSの特徴

イメージ図

可用性が高い

障害等があってもサービスが停止しない。マルチAZを簡単に構築することで実現できます。

パフォーマンスが良い

リードレプリカを簡単に構築することで実現しています。

運用負荷を軽減してくれる。

自動バックアップ

S3に対して1日1回バックアップ(スナップショット)を自動取得します。
スナップショットを元にDBインスタンスを作成します。(リストア)

自動スナップショット

1日1回

トランザクションログ

5分毎

保存期間

0〜35日間

なお、手動スナップショットの取得も可能です。

自動アップデート

メンテナンスウインドウで指定した曜日の時間帯にアップデートを自動で実施します。

自動監視

データベースの各種メトリクスを1分間隔で取得して、マネジメントコンソール上で閲覧が可能です。

スケーリングができる。

インスタンスタイプを変更してスケールアップやダウンができる。
一時的にインスタンスタイプを多いくしてその後に戻すことは可能。
コマンドライ(AWS CLI)ンやAPIからストレージ数をクリックしてもできる。
ストレージサイズは拡張できますが、縮小はできません。（データが入っていくことになるので。）

データベースシャーディング

この機能を利用して、RDSの書き込み処理をスケーリングします。具体的には、ID0〜1000まではRDS1を使い、1001〜2000まではRDS2を使うといったような挙動になります。

RDSのデメリット

バージョンが限定される

最新版はすぐには使えません。

キャパシティに上限があります。

OSへのログインができない。

ファイルシステムへのアクセスができない。

IPアドレスを固定できない。

一部のRDBMSの機能が使えない。

個別パッチが適用できない。

AWS側でパッチは適用していくことになります。

DBインスタンスの暗号化

RDSでは資源を暗号化しています。

暗号化対象

DBインスタンス
自動バックアップ
リードレプリカ
スナップショット

暗号化方式

AES-256暗号化
AWS KMSによる鍵管理
リードレプリカも同じ鍵を利用
インスタンス作成時にのみ設定可能
スナップショットのコピーの暗号化/リストアが可能

RDSで利用可能なRDBS

MySQL
PostgreSQL
Oracle
Microsoft SQL Server
Amazon Aurora
MariaDB

Auroraの特徴

特徴

クラウドネイティブなRDBMS
シンプルさとコスト効率が高い
MySQL、PostgreSQLと互換性がある。
利用した分だけ支払う。
フルマネージド
年々、ハードウェア性能やRDBMS自体の性能も上がってきている。

設計思想

スケールアウト、分散、マルチテナントデザイン
AWSサービスを活用したサービス指向アーキテクチャ
自動化されたタスク（完全マネージド）

アーキテクチャ

他のAWSサービスを利用している。

Lambda function

Lambdaイベントをストアドやトリガーから実行

Identity and Access Management(IAM)

IAMを利用してデータベースユーザの認証

S3

S3データをロード、S3を利用したバックアップデータの保存やリストア

CloudWatch

システムメトリクスやログをCloudWatchへアップロードしている。

ストレージ

SSDを利用したシームレスにスケールするストレージ

10GBから64TBまでダウンタイムなしにシームレスにスケールアップできる。
従量課金性
Peer-to-peer gossipレプリケーション

標準で高可用性を実現

1AZがダウンしてしまったとしてもAuroraは継続運用できる。

3AZに6つのデータのコピーを作成する。
2ディスクが利用不可でも読み書き可能
3ディスクが利用不可でも読み込みは可能

Log structured Storage

redoログを複数の小さなセグメントに分割
Log pageによってData pageを作成

設定グループ

RDSは開発者自身がSSHでDBサーバーに接続して設定変更を行うということができません。設定変更は下記の設定グループという項目で行います。

設定グループ	説明
DBパラメータグループ	DB設定値を制御（DB同時接続数等）
DBオプショングループ	RDSへの機能追加を制御（MEMキャッシュを使用する等）
DBサブネットグループ	RDSを起動させるサブネットを制御

RDSのパラメータグループの種類をまとめます。

値	設定値例	説明
log_bin_trust_function_creators	1	MySQLのダンプファイルを利用してインポートできる設定になります。

RDS構築

マルチAZ（アベイラビリティゾーン）を実現するために複数のアベイラビリティゾーンにサブネットが作成されている必要があります。マルチAZについては下記の記事で解説しています。

EC2側の設定：セキュリティグループの作成

外部からのDBのアクセスを許可します。

インバウンドルール

タイプ

MySQLであれば「MYSQL/Aurora」を選択します。

ソース

アクセスを許可するIPを指定します。セキュリティグループを指定しても良いです。（例えば、Webサーバで設定しているセキュリティグループを指定すればそのセキュリティグループで許可しているIPからはアクセスできるようになります。）

RDS側の設定1：サブネットグループ

任意のサブネットグループを作成してその中に、複数のアベイラビリティゾーンに存在するサブネットをそれぞれ追加します。

RDS側の設定2：パラメータグループ

DBの設定値を編集します。設定項目は数100と非常に多いです。

パラメータグループファミリー

設定したいMySQLのバージョンを指定します。（例：mysql8.0等）

グループ名

パラメータグループの名前を設定します。

パラメータの項目名

変更可能

trueとなっているものは変更できます。

適用タイプ

staticであればRDSインスタンスを再起動しないと設定反映されないです。dynamicであれば再起動なしに動的に設定反映されます。

RDS側の設定3：オプショングループ

デフォルトで作成されていますが、自分で新しくオプショングループを作成するようにしましょう。なぜならデフォルトの設定ではなく自分で作成したオプショングループに設定内容を反映させていくのがセオリーのためです。

RDSでDB作成

データベース設定

「簡単作成」を選べますが、DBのバージョン等が選べないので「標準作成」で良いでしょう。

エンジンのオプション

MySQL等使用したいRDBMSとバージョンを選択します。

テンプレート

練習用だったら「無料利用枠」で良いでしょう。

DBインスタンス識別子

RDSのインスタンスの名前(データベースの名前)になります。

認証情報の設定

マスターユーザー名

データベースのマスターユーザー名になります。

マスターパスワード

マスタユーザーのパスワードを設定します。

DBインスタンスサイズ

標準クラス(mクラスを含む)

本番環境ではこちらを使います。

メモリ最適化クラス(rクラスとxクラスを含む)

バースト可能クラス(tクラスを含む)

サイズは小さいですが一番安いです。学習等の用途ではこちらを使うようにしましょう。

ストレージ

ストレージタイプ

学習用であれば「汎用(SSD)」が無難でしょう。

ストレージ割当

学習用であれば20GBあれば大丈夫でしょう。

ストレージの自動スケーリング

DBへの負荷が上がると自動でストレージをパワーアップします。本番用であれば設定した方が自動スケーリングは設定した方が良いですが、学習用であれば設定は不要でしょう。

可用性と耐久性

マルチAZ配置

マルチAZにすると可用性は非常に上がるのですが料金も爆上がりするため学習用であれば「スタンバイインスタンスを作成しないでください」を選択すると良いでしょう。

接続

Virtual Private Cloud(VPC)

自身で作成したVPCを指定しましょう。

追加の接続設定：サブネットグループ

自身で作成したサブネットグループを選択しましょう。

追加の接続設定：パブリックアクセス可能（パブリックアクセシビリティ）

VPCの外からRDSに接続することがあるかの設定項目です。ありなら接続可能、なしなら接続不可にすることが可能です。本当はあまり良くないですが、自分のPCからRDSに直接接続したい場合等にはこの設定をオンにします。

追加の接続設定：VPCセキュリティグループ

上記手順で作成したセキュリティグループを選択します。

データベース認証

IAMで認証をしない場合等はパスワード認証を設定しておけば良いでしょう。

追加設定

データベース名

データベース名を設定できます。

DBパラメータグループ

上記で設定したパラメータグループを指定します。

オプショングループ

上記で設定したパラメータグループを指定します。

バックアップ

自動バックアップの有効化

チェックつけておけばRDSが毎日バックアップを取ってくれるのでチェックしておくと良いでしょう。

バックアップ保持期間

デフォルトでは「7日」になっていますが、大体30日程度保持する設定にしておくと安心でしょう。

バックアップウィンドウ

自動バックアップの開始時間を設定します。UTCで指定するので日本時間で言えば-9時間しましょう。日本時間で朝4時にバックアップを取得したいのであれば19時を指定します。期間は「どれくらいの時間でスナップショットを取るか」の時間を指定します。

モニタリング

拡張モニタリングの有効化

通常モニタリングに比べてさらに詳しい情報をモニタリングするためのモニタリング設定です。有料なので気を付けましょう。

ログのエクスポート

ClowdWatch Logsのログ内容を出力したい場合は設定します。

メンテナンス

マイナーバージョン自動アップグレードの有効化

MySQLの新しいマイナーバージョンが出た際に自動でアップグレードするかを指定します。基本的にはチェックしておくと良いでしょう。

メンテナンスウィンドウ

いつマイナーバージョンをアップグレードするかの設定になります。利用者数の少ない曜日や時間帯を設定すると良いでしょう。

削除保護

間違ってデータベースを削除することがないよう指定できます。学習用等で削除しても問題ない場合はチェックを外しておきます。

概算月間コスト

月にどれくらいかかるかの試算が表示されます。ただ、学習用にDBインスタンスにT2マイクロを指定していた場合は無料枠になるので仮に月に20ドルを超える金額が表示されていてもそこまでかからないと思われます。

DBインスタンスの設定確認

RDSでDBインスタンスを作成すると下記のような設定項目を見ることが可能です。

接続とセキュリティ

接続情報が表示されます。エンドポイントや設定したVPCの情報を閲覧することが可能です。

エンドポイント

RDSの接続先ホストになります。

モニタリング

「CPU使用率」、「空きストレージ容量」等が表示されるのでデータベースの調子がおかしいと思ったらこちらの内容を確認するようにしましょう。

ログとイベント

DBから出力されるログやイベントが出力されます。

設定

DBインスタンス作成時に初期設定した設定情報を色々閲覧することが可能です。設定が意図通りになっているか確認すると良いでしょう。

メンテナンスとバックアップ

バックアップ

自動バックアップが設定されているか確認しましょう。自動で取得したスナップショットは設定した日数で自動で削除されますし、RDSインスタンスを削除したタイミングで削除されます。

スナップショット

「スナップショットの取得」というボタンがあり押せば手動でスナップショットを取得することが可能です。ただ、手動でスナップショットを取得するとそのスナップショットは削除されることがない(RDSインスタンスを削除したとしてもです。)というのが注意点です。スナップショットはわずかでも残っていると料金がかかってしまうので、今後使い道がないのであれば積極的に削除をされることをお勧めします。

スナップショットについて

特徴

設定画面などから手動で作成することが可能です。
デフォルトでは1日1回は自動で取得されるようになっています。

S3へのエクスポート

スナップショットはS3に退避することも可能です。スナップショット自体も料金がかかるのでできるだけ退避させるなり削除するなりの対処をした方が良いです。

スナップショットの保存期間

自動スナップショットの場合

0〜35日まで指定が可能です。またDBインスタンスを削除したら同時に自動削除もされます。

手動の場合

永続的に保存されます。逆に言えば消えないので注意。また、DBインスタンスを削除しても自動で消えません。

取得時の注意点

短時間だがIOが停止します。マルチAZ構成ならスタンバイの方からスナップショットを取得するので問題はないが、単一AZ構成ならアプリケーションのパフォーマンスに影響します。運用負荷の低い時間帯に取得するようにしましょう。

復元方法

現在のDBインスタンスにスナップショットを割り当てるというよりは、新しいDBインスタンスを作る感じになります。

新しいDBエンドポイントに接続するようにアプリケーション側の設定を変えるか、旧インスタンスのエンドポイントを書き換えて、新インスタンスのエンドポイントを元のエンドポイントを同じに変更するかの二択になりますが、基本的にはアプリ側に設定変更がない後者のやり方が望ましいでしょう。

リストアのユースケース

管理者の操作ミス

新しいDBインスタンスになるのでアプリ側は新しいインスタンスにつなぐように設定変更する必要があります。