AWSクラウドプラクティショナー資格取得のための学習用備忘録(データベースサービス)

RDS

AWSで使用できるデータベースサービスは複数あるが、
ここで重要なのは「適切なデータベースサービスを選択する」ということ。
どんなシステムにも、どんなデータにも、最適な対応ができる万能なデータベースサービスというものはない。

例えば、アプリケーションでは、1つのデータを処理するために行にアクセスすることが多くなる。
それに対してレポートなどの集計処理では、複数のデータをまとめて計算するために列にアクセスする。
もっと単純に、キーにアクセスしてその値を取得するだけの場合もある。
1つ1つの処理においてもアクセス方法が違う。
これらすべてに最も適したデータベースサービスというものはなくて当然。

「必ずこのデータベースを使用する」と決めつけるのではなく、システムやデータの要件に応じて必要なデータベースサービスを選択することが重要。

RDSの概要

RDSはAmazon Relational Database Serviceの略。
AWSで簡単にリレーショナルデータベースを使用することができる。
使用するデータベースエンジンは次の6つ。

・Amazon Aurora

・MySQL

・PostgreSQL

・MariaDB

・Oracle

・Microsoft SQL Server

★オンプレミスで使われているデータベースエンジンをそのまま使うことができる

RDSとEC2の違い

Amazon Aurora以外は、EC2に各データベースエンジンをインストールして使用することももちろん可能。
EC2にデータベースエンジンをインストールして使用することと、
RDSの違いこそがRDSの特徴であり、RDSを使用するメリット。
RDSとEC2の違いだけではなく、オンプレミスでデータベースエンジンを運用する場合もあわせてその違いを確認する。

オンプレミスでデータベースサーバーを構築する場合、
電源、空調、ネットワーク回線、ラックスペースの管理をすべて顧客が担当しなければならない。
これをEC2で起動したサーバーにデータベースエンジンをインストールする場合、
物理要素やハードウェアとOSのインストールまでは、AWSに任せることができる。
しかし、OSのモジュールに脆弱性が見つかった場合はパッチの適用が必要。
そしてデータベースのインストール、マイナーバージョンのバージョンアップ、
バックアップ、複数のAZをまたいだ高可用性の確保、
スペック変更時のデータベースソフトウェアの調整・設定などは顧客が行う必要がある。

RDSでデータベースエンジンを使用すると、これらの管理タスクは顧客にとって不要となる。
主に次の3つの管理タスクから解放される。
そのため顧客は、アプリケーションのためにSQLクエリを最適化するなど、開発に注力できるようになる。

・メンテナンス

・バックアップ

・高可用性

メンテナンス

RDSを使用すると、顧客はOSを意識する必要がなくなる。
OSが顧客のコントロールから外れる。顧客はOSを選択する必要も設定する必要もなくなる。

OSのメンテナンスは週に1回、顧客が設定した時間に自動的に行われる。
データベースのマイナーバージョンアップグレードは、自動適用するかどうかを顧客が選択できる。
自動適用する場合は、同じく指定した時間に自動的にアップグレードされる。

★OS、データベースエンジンのメンテナンスをAWSに任せることができる

バックアップ

RDSでは、デフォルトで7日間の自動バックアップが適用されている。
顧客がバックアップ用のコマンドやサードパーティ製品を用意しなくても、
バックアップはRDSインスタンスを作成したときに設定済み。
バックアップの期間は0~35日間まで設定でき、指定した時間にバックアップデータが作成される。

35日を越えてバックアップデータを保持しておく必要がある場合は、手動のスナップショットを作成できる。

自動バックアップも手動スナップショットもRDSのスナップショットインターフェイスからアクセスできるが、
実体はS3の機能を利用して保存されている。
RDSのバックアップスナップショットの耐久性は非常に高いと言える。

スナップショットの復元からインスタンスを起動することができる。
復元によって、日次で作成されたバックアップ時点のインスタンスを起動できる。

ポイントタイムリカバリー

自動バックアップを設定している期間内であれば、
秒数までを指定して特定の時点のインスタンスを復元できる。
また、過去直近では5分前に戻すことができる。

このポイントタイムリカバリーは、トランザクションログが保存されていることによって可能になっている。
RDSの起動が完了したタイミングで自動でトランザクションログは保存され始める。

★データベースのバックアップを管理しなくて良い

★バックアップ期間中の任意の特定期間のインスタンスを起動できる

高可用性

Web層やアプリケーション層で負荷分散やAuto Scalingによる高可用性を実現していても、
データベースサーバーが1つしかなければ、
データベースサーバーに障害が発生した際にシステムの機能は停止する。
データベースサーバーは、いつ壊れてもおかしくないというDesign for Failureの設計原則に基づいて、
単一障害点(SPOF)とならないように設計しなければならない。

RDSのマルチAZ配置をオンにすると、AZをまたいだレプリケーションが自動的に行われる。
マスターに障害が発生した際のフェイルオーバーも自動で行われる。
レプリケーション用のユーザー作成やレプリケーションそのものの設定、
レプリケーションのための管理を行う必要はない。

マルチAZ配置を選択するだけで、複数のAZでデータベースのレプリケーションが始まる。

マスターとスタンバイの間でレプリケーションが実行され、
マスターに障害が発生した際には自動的にフェイルオーバーされる。
フェイルオーバーされると、スタンバイデータベースがマスターになる。

異なるデータセンターの間で数ミリ秒以内のレイテンシーの専用線を用意して
データベースのレプリケーションを行う。
これをオンプレミスで実現するには、多くのコストと労力が必要。
RDSを使用すれば、マルチAZ配置という選択肢を有効にするだけで実現できる。

Amazon Aurora、MySQL、PostgreSQL、MariaDBではリードレプリカを作成することができ、
リードレプリカにより、読み込みの負荷をマスターデータベースから軽減できる。
他のリージョンにリードレプリカを作成することもできる。
クロスリージョンリードレプリカという。

★マルチAZ配置を使用することでデータベースの高可用性を実現できる

★レプリケーション、フェイルオーバーはRDSの機能によって自動的に行われる

Amazon Auroraの概要

Amazon Auroraは、AWSがクラウドに最適化して再設計したリレーショナルデータベースエンジン。
MySQL、PostgreSQLのデータモデルをサポートしている。
これは、MySQL、PostgreSQLのインターフェイス機能を持っているということ。
もう少し噛み砕いて言うと、MySQLまたはPostgreSQLを使用しているアプリケーションは
Auroraをそのまま使用できる可能性が高いということ。

Auroraを利用する主なメリットは次のとおり。

・バックアップが非常に強固

・スタンバイにアクセスできる(リードレプリカがマスター昇格する)

・リードレプリカは15個作成できる

・RDS MySQLに比べて5倍の性能

・ディスク容量を見込みで確保しなくても自動で増加する

★Amazon AuroraはMySQL/PostgreSQL互換の、クラウドに最適化されたリレーショナルデータベース

DMS

オンプレミスからAWS、またはAWSからAWSへデータベースの移行をする場合、
従来のやり方ではリスクも時間も多くかかる。
AWSでこの課題を解決するために用意されているサービスがAWS Database Migration Service、略してDMS。

例えばオンプレミスの従来のデータベースからRDSにデータを継続的に移行できる。
移行時のシステムダウンタイムも最小限に抑えることができる。
同じデータベースエンジンでも、異なったデータベースエンジンでも移行ができる。
移行先のスキーマ作成もSCT(Schema Conversion Tool)で自動作成できる。

★DMSはデータベース間でデータを移行できるサービス

★DMSによりオンプレミスからAWSへの継続的なデータ移行を行い、システムのダウンタイムを最小限にできる

DynamoDB

Amazon DynamoDBはNoSQL型の高いパフォーマンスを持ったフルマネージド型のデータベースサービス。
フルマネージド型という言葉で表しているのは、顧客が管理する範囲がさらに少なくなるということ。
例えばデータベースサーバーのOSも、データベースエンジンも、テーブルの破損なども、気にしなくてよくなる。
顧客がDynamoDBを使用するときはテーブルの作成から始める。
データベースサーバーとしてインスタンスを作成する必要がない。
最低限の設定では、テーブル名とプライマリキーを決めれば使い始めることができる。

DynamoDBを使用するときに顧客が選択するのは、リージョン。
AZは顧客が意識しなくても使用できる。
DynamoDBにテーブルを作って、そこにアイテムと呼ばれるデータを保存すると、
自動的に複数のAZの複数の施設で同期され保存される。
最初からマルチAZな環境になっているということ。

データ容量は無制限で、使用している容量のみが課金対象となる。
性能は顧客が決めることができる。
書き込みと読み込みのキャパシティユニットを設定する。
キャパシティユニットはオートスケールさせることもできる。
モバイル、ゲーム、IoT、大規模なWebシステムのバックエンド、サーバーレスアーキテクチャ、
ジョブステータスの管理、セッション管理、クリックストリームデータなど、様々なユースケースで使用されている。

★DynamoDBはフルマネージドなデータベースサービス

★リージョンを選択して使うことができる

DynamoDBとRDSの違い

DynamoDBとRDSの大きな違いは、RDSはリレーショナルデータベースで、DynamoDBはそうではないということ。DynamoDBは非リレーショナルデータベースやNoSQLと言われたりする。
RDSではトランザクションをコミットにより確定できるので、
例えば空席予約など厳密な確定処理をすることに向いている。
しかし、大量のデータ更新や読み込みを必要とする処理には向いていない。
これはスケーリングの特徴が異なるため。

RDSは主に垂直スケーリングによりスケールアップすることができる。
基本的には1つのインスタンスで処理を行うので厳密な処理をすることができるが、大量のアクセスには向いていない。

これに対して、DynamoDBは水平スケーリングができる。
大量のアクセスがあってもパフォーマンスを保ったまま処理ができる。
ただし、厳密なトランザクションを必要とする処理や、複雑なクエリには向かない。

データの特徴も違う。

RDSはSQL型のテーブル形式。列が固定で行に対してアクセスする。
もし新しい列を増やす場合は、列を追加してからレコードを挿入する必要がある。
各列の最大長も固定されていて、それを超えることはできない。
SQL型のテーブルでは、SQLを使ってレコードにアクセスすることができ、
基本的にどの列に対しても検索を行うことができる。

DynamoDBはNoSQL型のテーブル形式。
1つのデータはアイテム(項目)として扱う。
キーとして設定している属性と値さえあれば、それ以外の属性は動的で自由。
検索対象はキーとして設定している属性のみ。
このように不定型な入れ物に自由に情報を格納して、キーを検索のためのインデックスして扱うイメージで、
データを管理することができる。

★データの特徴やシステム要件に応じて適したデータベースサービスを選択する

★中規模程度のアクセス量で、整合性や複雑なクエリを必要とする場合はRDSを選択する

★大規模なアクセス量で、単純な自由度の高いデータモデルを扱う場合はDynamoDBを選択する

その他のデータベースサービス

データベースサービスとしては次のものもある。

・Amazon Redshift：高速でシンプルなデータウェアハウスサービス。
データ分析に使用する。大規模なデータ分析にも対応している

・Amazon ElastiCache：インメモリデータストアサービス。
オープンソースのRedis、Memcachedのマネージドサービスとして使用できる。
RDSやElasticCacheのクエリ結果のキャッシュに使用したり、アプリケーションのセッション情報を管理する用途で使われている

・Amazon Neptune：フルマネージドなグラフデータベースサービス。
関係性や相関情報を扱う。
SNS、レコメンデーション(提案)エンジン、経路案内、物流最適化などのアプリケーション機能に使用される

まとめ

RDS

・オンプレミスで使われているデータベースエンジンをそのまま簡単に使うことができる

・RDSを使うことでエンジニアはインフラ管理から解放され、本来やるべき開発に注力できる

・OS、データベースエンジンのメンテナンスをAWSに任せることができる

・データベースのバックアップを管理しなくて良い

・バックアップ期間中の任意の特定時間のインスタンスを起動できる

・マルチAZ配置を使用することでデータベースの高可用性を実現できる

・レプリケーション、フェイルオーバーはRDSの機能によって自動的に行われる

・Amazon AuroraはMySQL/PostgreSQL互換の、クラウドに最適化したリレーショナルデータベース

・DMSによりオンプレミスからAWSへの継続的なデータ移行を行い、システムのダウンタイムを最小限にできる

・中規模程度のアクセス量で、整合性や複雑なクエリを必要とする場合はRDSを選択する

DynamoDB

・DynamoDBはフルマネージドなデータベースサービス

・リージョンを選択して使うことができる

・データの特徴やシステム要件に応じて適したデータベースサービスを選択する

・大規模なアクセス量で、単純な自由度の高いデータモデルを扱う場合はDynamoDBを選択する