様々なエンジンが選べる「Amazon RDS」
RDBMSをAWSに移行するには、オンプレミスのRDBMSのイメージをそのまま「Amazon EC2」の仮想サーバーに載せる方法がある。この場合はEC2で動く仮想サーバーのroot権限が得られるので「自由度は高く、従来と同じような運用ができます」と話すのは、アシスト クラウド技術本部の神山太一氏だ。
しかしながら、この方法では運用管理はオンプレミスとほとんど変わらず、管理におけるスキルやコストは従来通りとなる。対してAmazon RDSはマネージドサービスのため「DBA（データベース管理者）のわずらわしいタスクをAWSにオフロードできます」と神山氏。データベースの構築、可用性の確保、バックアップの実装などが容易で、専門的なスキルもそれほど必要ない。反面、マネージドサービスには制限もあり、従来のオンプレミスの運用を変える必要も出てくるという。
Amazon RDSは、MySQL、PostgreSQL、MariaDB、SQL Server、Oracle Database、そしてAurora（MySQLおよびPostgreSQLに対応）など、現在（2022年7月時点）では7つのエンジンが選択でき、オンプレミスやAmazon EC2ベースで運用するよりも管理タスクをAWSにオフロードできる範囲は大きくなる。
Amazon RDSの中身は、仮想サーバーのAmazon EC2とブロックストレージの「Amazon EBS」の組み合わせだ。Auroraを除くエンジンに関しては、次の構成をとることができる。プライマリインスタンスを1つのAZ（アベイラビリティーゾーン）で構成し、レプリカは別のAZにスタンバイ・インスタンスとして作成可能だ。この場合、レプリカはAWSの機能を用いた同期レプリケーションとなり、フェイルオーバー先としてしか利用できないという。ただ、別途リードレプリカ・インスタンスを5つまで作ることができ、こちらはデータベースエンジンの機能を用いる非同期レプリケーションとなる。
RDBMSをクラウドに最適化したAurora
Auroraは「AWSがRDBMSをクラウド時代に最適化し、再設計したものです」と神山氏。従来のRDBMSはすべての要素を1つのエンジンにまとめたモノリシック構成だが、Auroraはスケーラビリティ、可用性、耐久性の観点から「コンピュートレイヤーとストレージレイヤーを個別のエンジンとして明確に分離しています」とのこと。
AuroraはPostgreSQLとMySQLの2つが選択でき、現在（2022年7月時点）Aurora PostgreSQLはオープンソース・ソフトウェア（OSS）のPostgreSQLバージョン10、11、12、13、14と強い互換性を保持している。そのため「SQL、クライアントアプリケーション、プロシージャーや拡張モジュールなどをそのままPostgreSQLからAuroraに移行できます」と神山氏は述べる。
また、3つのAZに対し読み書き可能なWriterインスタンス、読み取り専用のReaderインスタンスを構成可能である。Readerインスタンスは3つのAZに対し最大15個まで追加でき、Writerインスタンスに障害が発生した際は、Readerインスタンスが即時にWriterインスタンスに昇格し可用性を確保するという。
そして、Auroraの最大の特長がクラスターボリュームだ。これはストレージレイヤーの機能で、3つのAZに2つずつ、合計6つのデータコピーを冗長化して保持する論理的な“共有ディスク構成”となる。
Auroraの非機能要件面での優位性
AuroraにはRDBMSで重要な非機能要件である可用性、パフォーマンス、拡張性、耐久・耐障害性、運用・保守性の5つの優位性を有している。これらは分離されたコンピュート、ストレージレイヤーからもたらされ、通常のRDSと大きく違うところだ。異なるAZを用い分散型の共有ストレージに冗長化してデータコピーを保持、データコピーのサブセットに読み込み・書き込みを行う“クォーラムモデル”で高耐久なストレージを実現しているという。
クォーラムモデルでは、6分の3の読み込みクォーラム、6分の4の書き込みクォーラムを採用している。 そのため、AZの障害に加えて、別のAZのデータ破損が起きてもリード処理を継続でき、 ライト処理ではAZに障害が発生し冗長化された2つのデータにアクセスできなくてもトランザクションを継続可能だ。 加えて、データのリード/ライト処理で一部のストレージレイヤーに遅延が発生してもI/O性能は失われない。
なお、Auroraでは通常のRDSよりも多くのデータコピーを持つため、I/Oオーバーヘッドが大きくなる懸念もあるかもしれないが、それにも工夫がなされている。一般的にRDBMSでは、メモリ上のダーティバッファをディスクに書き出すためのチェックポイントがボトルネックとなりやすい。しかし「Auroraは、そもそもこのチェックポイントの概念が存在しません」と神山氏。
PostgreSQLでは、共有バッファがチェックポイントでストレージに書き出され、これがI/Oの負荷となる。一方AuroraではWALのみを非同期かつ並列に書き込み、スループットの向上を図っているという。「WALを使い常にストレージレイヤーでデータは更新されます。これにより、6つのデータコピーを保持していても通常のRDSと比べI/Oが過多になるなど、パフォーマンスが悪化することはありません」と神山氏は説明する。
Auroraでは、Protection Groupと呼ばれる10GB単位の論理ブロックでストレージノードにデータを格納する。この区分けされた10GBの論理ブロックの中で、3つのAZに冗長化し複数ストレージノードでデータを管理する。Protection Groupは最大12,800個まで持つことができ、多数のストレージノードでストライピングしてデータを管理できる。また、データの欠損、破損はP2P（Peer to Peer）のゴシッププロトコルにより各ストレージノード間で自動修復され、ノード障害にも新たなストレージノードがアサインされてデータが同期されるため、管理者がリカバリをする必要はない。
AWSが公開しているベンチマークテストでは、OSS（オープンソースソフトウェア）のPostgreSQLと比較して、Auroraは同時接続数が増加するにしたがってリニアにスループットが向上し、2,048の同時接続数ではOSSに比べ約3倍のスループットとなる。
「RDS for PostgreSQL」のリードレプリカは、WALを用いた論理レプリケーションのため、マスターのワークロードによってはラグが大きくなることも懸念される。しかしながらAuroraはページキャッシュ更新リクエストによるレプリケーションで、かつレプリカ側で一切の書き込みを行わないため、遅延範囲も20～100ミリ秒と少なく収まる。加えて、共有ディスクのため、フェイルオーバー時にコミットしたデータの消失もない。
また、ページキャッシュをデータベース機能と分離して管理することで、インスタンス障害やインスタンスの再起動時などにもページキャッシュ情報がクリアされず、迅速な再開が期待できるという。さらにチェックポイントの概念がなく、常にストレージノードでロールフォワードが行われるため、リカバリ時にも更新ログは最小となり、多くの場合60秒以内という高速クラッシュリカバリも可能となっている。
なお、Auroraではデータ量が増加すると128TBまでProtection Groupが自動増加する。そのため、Auroraの設定画面にはストレージサイズの項目がないのだ。
商用データベース並みの高い非機能要件を求めるならAuroraを
こうしたメリットの多いAurora PostgreSQLは、どのように選べば良いのか。Auroraは商用データベースの10分の1のコストで、高い要求に応えるRDBMSをマネージドサービスで提供することを目指している。一方でRDS for PostgreSQLは、OSSのPostgreSQLをマネージドサービスで提供するものだ。現状のPostgreSQLでワークロードが安定しているならば、わざわざAuroraに載せ替える必要はない。
「軸としては非機能要件の可用性、パフォーマンス、耐障害性などを課題としてもっていて、それらを改善したい場合、または商用データベースのコストを圧縮したいが、非機能要件を落としたくないといった場合であればAuroraが検討できるでしょう」と神山氏。またAuroraは一定規模のワークロード向けであることから、インスタンスクラスは基本的にLarge以上しか提供されていないといった通常のRDSとの違いもある。
コストは、同じ構成ならAuroraのほうが高くなるが、標準で様々な機能が含まれており、通常のRDSより小さい構成でも十分な機能、性能の実装も可能だ。また、商用データベースからの移行の際は利用コストが圧縮できるものの、改修コストが別途かかる点には考慮が必要となる。そのためAWSでは、スキーマコンバージョンツール（AWS Schema Conversion Tool）を用意しており、移行コストの試算機能も提供しているとのこと。
なお、2022年4月には、サーバーを意識せずにワークロードの実装ができる「Aurora Serverless v2」がリリースされた。v1は機能も十分でなく本番では使いにくいという声も多く聞かれたが、v2ではコンピュートリソースのオンデマンドな自動スケールアップ/ダウンに対応し、マルチAZ構成もとれるなど、通常のAuroraとほぼ同等の機能が提供されている。また、通常のAuroraと混在利用も可能となり、リードレプリカだけをServerlessにすることもできる。「Auroraを利用するならば、Serverlessの活用も検討してみるべきだ」と神山氏は薦める。
アシストでは2009年からPostgreSQLのプロダクトサポートを開始しており、PostgreSQLのエンタープライズ版であるEDBも数多く販売している。PostgreSQLの十分な実績とノウハウがあり、それをベースにAuroraの技術支援も多数行っているため、「RDBMSをAuroraへとの検討をしているならば、是非アシストに相談して欲しい」とのことだ。
初めてのAWS利用から更なるAWS活用まで、アシストがご支援します！
AWSアカウントの開設やAWSインフラの構築、AWS環境を安全に適切にご利用いただくためのAWS利用ガイドラインの策定など、これからAWSを利用される方や既にAWSを利用されている方まで、AWSを活用いただくための支援を多数ご用意しています。
AWSネイティブなサービスだけでなく、パッケージ・インテグレーターとして長年培ったノウハウをもとに、パッケージを含めた最適なシステム構築のご提案をさせていただきます。
また、エンタープライズ環境を中心にデータベース関連のご支援を多数実施してきたノウハウがあるため、AWSへのDBやDWH環境のマイグレーションにも強みがあります。
AWSの頼りになるパートナーをお探しの方は、ぜひアシストのAWSサイトをご確認ください。
