いまさら聞けないRDSのお話し

はじめに

こんにちは、園田です。

前回に引き続き、「いまさら聞けない」シリーズを開催したいと思います。
いまさら聞けないシリーズの第3弾は「RDS」になります。

今回はみんな大好きリレーショナルデータベースのAWSマネージドサービスであるRDSについて語ります。
前回同様、基本から応用（？）まで幅広く記載していくつもりです。

なお、公式資料としてはAWSさんからBlack Beltシリーズが詳しくサービス説明をしています。URLを載せておきます。
いつも通り、AWS Black Beltは見ずに園田がAWSのサービスについて紹介したいと思います。

RDSってなに？

まずは、RDSの説明から実施しましょう。
RDSはAmazon Relational Database Serviceの略になります。

なのでリレーショナルデータベース（以下、RDB）になります。

ちなみにAWSでは以下のように色々なDBサービスがありますが、その中で最もメジャーなのがRDSになります。
簡単に各種類のDBを見てみましょう。

簡単といいましたが、たくさん種類があるので説明は簡単でも読むのは大変です。
実際にはRedshiftの中にもRedshiftサーバレスとか、DynamoDBの中にもグローバルテーブルとかDAXがあることを考えると、恐ろしい種類のDBがあることが分かります。

いっぱいあって大変ですね。

DBがいっぱいあって大変なんですけどー

こんなにたくさんDBがあって大変なので1つにして欲しいんですけどー。
という事を思う人もいるかもしれませんね。

これだけ種類がたくさんあるのはAWSの思想によるものです。
思想というと分かり難いので、まずはこれの対極となる製品でもご紹介しましょう。

その製品とはみんな大好き、Oracleの「Exadata」になります。
Exadataいいですよね。Exadataがあれば大体何でもできます。（グラフ指向とか無理ですけど）

DWHは列指向になるため、基本DWHではオンライントランザクションは向いていません。
一方RDBは行指向となるため、オンライントランザクションには向いていますが、大量のデータを取り扱うには時間が掛かります。
そのため、ユーザがデータの特性を考え、DBを変えるのが一般的ですが、Exadataの場合はExadataにお任せすることが出来ます。
要するに考えなくてもイイ感じ使えるわけです。

その一方でExadataのネックは価格です。Exadataが色々やってくれる分、お値段に上乗せされています。

AWSでは
「それぞれの環境において、最適なサービスは実現したい要件により異なり、ユーザがそれを選択するのが最もパフォーマンスが出る」と考え、様々なサービスを提供しています。

そのため誤ったサービスを使ってしまうとパフォーマンス的な問題（併せてコスト的な問題）が出てしまいますが、一方できちんとアーキテクチャを考慮し正しいサービスを選択することで、高パフォーマンス・低価格が実現できるという思想になります。

AWSを使うという事は「アーキテクチャをきちんと知ること」、「考えること」を要求されるわけです。
めんどくさい話ですね。

RDSってどんなサービスなの

AWSの思想を理解した所で、RDSのお話に戻りましょう。
RDSはAWSがマネージドサービスとして提供しているRDBのサービスになります。

要するにRDSを作成するとDBがインストールされている状態になっている。という事ですね。
DBの種類はこんな感じで選択が可能です。

AuroraはAWSが開発したDBとなります。
Oracleについてはstandard、Enterpriseのどちらのエディションも利用可能です。（Enterpriseはライセンス持ち込みのみ対応）

大体メジャーなRDBは網羅しているのではないでしょうか。
以前、Db2は対応していませんでしたが、アップデートにより対応しました。

このようにDBを選択して構築する形になるため、構築完了後は既にDBがインストール、初期設定が実施されている状態となり、いきなりSQLコマンドでDBにログインが可能です。

簡易に確認したい場合、cloud shellをVPC内部で起動し、mysqlコマンドなどDBへの接続コマンドを実行することで接続確認が可能です。意外と稼働確認にも便利です。cloud shell

初期設定についてですが、SQLでアクセスするとDBが出来ている状態（create dbコマンドが実行された状態）となっています。DB名はRDS作成時に使用した名称となっています。

RDS内でcreate dbコマンドを実行することでいくらでもDBを作成することが出来ますが、基本はマネジメントコンソール上のRDSと実際のDBを1対1にしておいた方が管理性に優れると考えるのでDBを作ることは個人的にはお勧めしません。
（作ってもいいけど、きちんと管理しようね）

RDSの可用性について

可用性ですが、シングル（１台構成）、マルチ（冗長構成）を構築時選択可能です。（後でも変更可能です）
それぞれのSLAはこんな感じです。

まとめるとシングルは99.5%/月、マルチは99.95%/月となります。
可用性が必要なときはマルチ（冗長構成）にしておきましょう。

シングルとマルチの差異

シングルは1台構成、マルチは2台構成となり、機器の構成が異なるのですが、機器の構成以外にも以下のような差異があります。

メンテナンス時の動作の差異

細かい点ですが、メンテナンス時に動作も異なります。
シングルの場合、対象に対しバージョンアップを実施するため、数分（大体5分程度ですかね。DBの種類によって異なります。）DBが利用不可となります。
※ Auroraのみアーキテクチャが異なります。こちらはDBがMysqlやPostgreSQLの場合です。

一方マルチ構成（「DB A（プライマリ）」、「DB B（セカンダリ）」）の場合、

という動作となります。

使えない時間は「2．プライマリ、セカンダリの入れ替え」の時間帯のみとなります。
要するにメンテナンス時間が短いという事です。

なお、プライマリ、セカンダリは入れ替わったままです。戻したい場合は、手動でマスターをリブートする必要があります。

RDSのいいところ

EC2の上にDBを作成するのと比較して、RDSのいいところを挙げていきましょう。
AWSのBlack Beltだとこんな感じで記載されていますね。

ブラックベルトは置いておいて園田が考えるメリットでも記載しておきましょう。
大きく分けて3つです。

ちょっとだけ費用が掛かりますが、何かあった際の保険として必ず有効にしておきましょう。
ちなみにPerformance InsightsはDBの種別とインスタンスタイプによっては利用できないものがあるので必ずこちらを確認しておきましょう。

意外と色々見れたりします。例えば、以下を確認できます。

こんなツールが標準で使えるなんて良い時代になったものです。

Amazon Auroraってなに？

AWSが作ったDBエンジンになります。
さすがにいまさら新規というのは難しいので、MySQLまたはPostgreSQLと互換という形になっています。

どうしてもoracleを使いたい、とかSQLサーバを使いたい、といった要件が無い場合はAmazon Auroraを使いましょう。
AWSが開発しているのでサポートも手厚くなります。

また、基本Oracle等のDBが所謂オンプレミスにて利用することを想定しているのに対し（オンプレミスしかなかったので当たり前ですけど）、Amazon Auroraはクラウド上（AWS上）で利用することを前提としています。

そのため、オンプレミスのようにリソースに制約があるとか、ハードウェアの構成は色んなパターンがある、などの前提をすっ飛ばし無限のリソースがあるクラウド上ではどのようなアーキテクチャが最適か、という視点で作られています。

その結果、

など、旧来のDBエンジンでは難しかったことを実現しています。

まぁ、新規でRDBを作る必要がある際は、Auroraが良いです。
AWSのメリットを一番享受できます。

終わりに

という訳で、「いまさら聞けないRDSの話」でした。
結構RDSも長かったですね…。

とはいえ、ただのRDBなので、正直そんなに難しくないですね。
前提知識も要りませんし。

最後にAmazon Auroraの話をしましたが、既存のDBが悪いという訳ではなく色々制約がある中で最善をつくしたアーキテクチャ設計がクラウドの出現により前提が覆されているというのは面白い話だなと思っています。

昔はDBと言えばOracle、100歩譲ってもSQL Serverとか。所謂RDBしかなかったのに、気がつけばRDB以外の色んなDBが利用されるようになっていますね。

DBエンジニアも昔より深い知識と経験が求められる時代になったんだと感じます。
時代に置いて行かれないように頑張って勉強しましょう。

ではまた、別の記事でお会いしましょう。