はじめに
この記事では AWSが提供するAmazon RDS（以下、RDS）を学習していく記事です。主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。
Amazon RDSとは
AWSが提供するマネージドなリレーショナルデータベースです。
AWSの公式サイトには下記のように表現されています。
Amazon Relational Database Service
クラウド上のリレーショナルデータベースのセットアップ、オペレーション、スケールを数回のクリックで行います。
Amazon Relational Database Service (Amazon RDS) は、クラウド内でデータベースのセットアップ、運用、およびスケールを簡単に行うことのできるマネージド型サービスの集合体です。MySQL との互換性を持つ Amazon Aurora、PostgreSQL との互換性を持つ Amazon Aurora、MySQL、MariaDB、PostgreSQL、Oracle、SQL Server の 7 つの人気エンジンから選択し、Amazon RDS on AWS Outposts でオンプレミスデプロイが可能です。
どんなサービスかというと。。。
クラウド上でマネージドなリレーショナルデータベースを提供するサービスであり、複数のリレーショナルデータベースエンジンに対応しています。
セットアップや運用、スケールを簡単に行うことができる特徴があり、さらに高可用でスループットが高いサービスです。
マネージドなリレーショナルデータベース？複数のリレーショナルデータベース？セットアップや運用、スケールを簡単に行うことができる特徴？高可用でスループットが高い？
ナニモワカラナイ。。。。では一つ一つ見ていきましょう。
リレーショナルデータベースとは（RDB）
まずはリレーショナルデータベース、RDBとはなんだったかを説明します。
簡単に述べると、表形式のテーブルを1箇所に集めたDBのことです。
基本情報処理技術者試験などでは関係データベースなどと呼ばれていますが、意味は同じです。
※リレーショナル（関係）データベース
なお、表形式のテーブルというのは以下のような見た目をしたものです。
| メニューID | メニュー名 | 値段 |
|---|---|---|
| 001 | カレーライス | 350 |
| 002 | ラーメン | 450 |
| 003 | 餃子 | 120 |
複数のデータベースエンジン
RDBがどんなものか理解できたところで、データベースエンジンについて見ていきましょう。
データベースエンジンというのはそのデータベースの駆動部分、つまりはそのデータベースがどんなプログラムで動いているのかという話です。
ここで押さえておきたいこととしては
データベースそのものはデータの塊であって、塊からデータを取り出すわけですが、塊自身が自分から動くことはありません。
つまり、データを取り出す時はプログラム（エンジン）が必要というわけです。
そして、このエンジンにはさまざまな種類があり、具体的には下記のエンジンにRDSは対応しているということになります。
- Amazon Aurora
- PostgreSQL との互換性を持つ Amazon Aurora
- MySQL
- MariaDB
- PostgreSQL
- Oracle（Oracle Database）
- SQL Server
とりわけ、MySQL、PostgreSQL、MariaDB、Microsoft SQL Server、Oracle DatabaseについてはRDBMSとも呼ばれています。
ただし、実務においてはRDBMSということはほとんどなく、RDBやリレーショナルデータベースもしくは単にデータベースと言われます。
「データベースはなにを使ってますか？」と聞かれたらとりあえず、データベースエンジン（RDBMS）の名前について答えておけば、だいたい通じます。
補足：Amazon Auroraについて
7つのデータベースエンジンの中でも異彩を放つAmazon Auroraですが、
Amazon AuroraはAWSがクラウド利用に最適化したデータベースエンジンおよびサービス名です。
MySQLとPostgreSQLに互換性があり、単純比較ではMySQLの5倍、PostgreSQLの3倍の性能があると言われています。
また、最近ではServerlessの流れを汲んでAurora Serverlessというサーバレスデータベースも提供されています。現在（2023年11月）ではV1とV2が提供されています。
今回はRDSの解説になりますので詳しくは説明しません。別の機会に解説しようと思います。
RDSの特徴
運用面
セットアップや運用、スケールを簡単に行うことができる
上記の通り、RDSの操作はAWSマネジメントコンソールからできます。
さほどすごくないように聞こえますが、オンプレミスでDBを用意した際には専用のコンソールがないので、DB上の作業はCLIで行わなければなりません。
AWSマネジメントコンソールがあるおかげでプルダウンを少し弄るだけで利用したいデータベースエンジンを操作できたり、欲しいストレージ容量を入力して確定を押せば、必要なストレージを確保できます。
なお、適切に設定をすれば、RDSで用意した容量は自動でスケールされますので運用担当者が手動で容量をスケールさせる必要はほとんどありません。
可用性
設定が簡単で運用が自動化できるということがわかりました。では、どれくらいの可用性があるのでしょうか。
RDSをマルチAZ配置とした場合における可用性は最大で99.95%です。ほとんど落ちることがないですが、リージョンに障害があった場合は例外です。
ただし、マルチAZ配置にした場合は各AZへの配置になりますので料金が比較的に高くなってしまいます。要件に応じて検討しましょう。
復習：マルチAZとは
各リージョンには分離された区画があります。これをアベイラビリティーゾーン(AZ)と呼びます。
東京には4つ、大阪には3つ存在します。
耐久性
DBといえば、データの保管庫であることは言うまでもないですが、データが吹っ飛んでしまったら大変です。そこでどれくらいの耐久性を持っているのか見ていきましょう。
RDSには自動バックアップ機能というものがあり、任意のタイミングでバックアップを取得できます。
RDSではこれをポイントインタイムリカバリと呼びます。なお、バックアップは最大で35日間保存可能です。
料金
優秀なサービスであることがわかりましたが、料金はいくらぐらいなのでしょうか。
簡単に述べるとさまざまなデータベースエンジンを備えていることからデーターベースエンジン毎に料金が切られています。
ここではPostgreSQL料金を見ていきましょう。簡単に述べていくと主に以下の要素で決まります。
- デプロイオプション
- マルチAZかどうかまたはマルチAZだとしたらどれくらいおくか、スタンバイにするかなど
- オンデマンドかリザーブドか
- ストレージコスト
- バックアップ
- エクスポートコスト
- データ転送コスト
考え方としてはほぼ管理しなくても良いサーバがN台構築されていて、そのサーバの計算処理能力（インスタンスタイプで決まる能力）や稼働時間に対してかかると考えても差し支えはないと思います。
コンピューティング料金+ストレージ料金+転送料金+その他というイメージです。
利用時の注意事項
メンテナンスウィンドウ
ウィンドウと書いていますが、要するにメンテナンスです。利用するデータベースエンジンによってはアップデートのタイミングでDBを止める期間があります。手放しでは運用できないというのがミソです。
アップデートは自分で実行することができますが、自動で実行することもできます。間違っても利用中にDBをアップグレードしないようにし、メンテナンスに合わせてDBの運用計画を立てましょう。
負荷が高い時は？
データキャッシュを入れましょう。コンソールからAmazon ElastiCacheのキャッシュを追加できます。あらかじめ、過度なアクセスがあると予測できる時は垂直スケールに頼らず、適切なキャッシュサービスを入れて対応しましょう。
まとめ
AWSが提供するマネージドなリレーショナルデータベースサービス、Amazon RDSについて見ていきました。使い方によってはDBの運用を楽にできる反面、RDSとのお付き合いが発生するので計画を立てて運用していきましょう。場合によってはオペレーションを自動化しても良いかもしれません。
また、これから実装するアーキテクチャにRDSが合っているのかという観点も忘れてはいけません。
解説しなかったAmazon AuroraやそのほかにもAWSにはさまざまなDBサービスが存在します。
よく吟味して実装していきましょう。今回は簡単におさらいしていきました。細かいところまで見ていくとまだまだ書き足りないですが、今回は以上です。