【初心者向け】Aurora(PostgreSQL)について学んでみた

AWS（Amazon Web Services）は、多彩なサービスを提供していますね。「Amazon Aurora」は、AWSが提供する独自のリレーショナルデータベースサービスで、高い可用性とパフォーマンスを兼ね備えています。多くの企業で利用されている本サービスについて、本記事ではそのアーキテクチャや特徴を詳しく解説し、初心者の方でも理解できるように説明していきます。

Amazon Auroraとは

Amazon Auroraは、Amazonが提供するリレーショナルデータベースサービスで、MySQLおよびPostgreSQLと互換性があります。従来のデータベースよりも高いパフォーマンスを実現し、スケーラビリティや可用性が向上しています。Auroraは、データの自動バックアップやマルチAZデプロイメントによる耐障害性など、企業にとって重要な機能を多数提供しており、様々な用途に適しています。

アーキテクチャ

ストレージの特徴

Auroraでは、ログ構造化ファイルシステム（LFS）を採用しています。これは、データとメタデータの書き込みを効率的に行うためのファイルシステムの一種です。従来の方式との違いについて解説します。

Log-structured分散ストレージシステム

従来のファイルシステムの方式
従来のファイルシステムでは、データを書き込む際に、ディスク内のランダムな場所に保存します。ファイル自体と、そのファイルを管理するメタデータ（位置や権限など）は別々の場所に保存されるため、それぞれに対して個別に書き込みが必要になります。

この結果、ディスクヘッドがデータやメタデータの異なる場所に移動する（シーク）ためにディスクアクセスが遅くなり、ランダムな場所にデータを書き込むことで書き込み性能が低下し、パフォーマンスが制限されます。

このようにディスクのパフォーマンスは主にディスクヘッドの移動（シーク）に依存していることが一般的です。

Log-structured File System (LFS) の方式

ログ構造化ファイルシステム（LFS）は、データとメタデータの書き込みを効率的に行うためのファイルシステムの一種です。LFSでは、データとメタデータの書き込みを連続したログ形式でディスクの「末尾」に追加します。データは常にシーケンシャル（*1）に書き込まれるため、ディスクヘッドの移動を最小限に抑えることができます。
（*1）シーケンシャル：REDOログが順番通りにディスクに書き込まれること

LFSの特徴：

シーケンシャル書き込み：データを順番に末尾に追加するため、ディスクヘッドが頻繁に移動することなく、書き込みが効率的に行われます。
メモリキャッシュの活用：データやメタデータを一度にまとめてキャッシュに保存し、ディスクに一括で書き出します。これにより、一度のディスクアクセスで多くのデータを書き込むことが可能です。
書き込みパフォーマンスの向上：ディスクI/Oの大半を占める書き込み処理が高速化し、全体のスループットが向上します。

従来の方式と比較すると、LFSはディスクヘッドのシークを最小限に抑え、特に書き込みが多いシステムでパフォーマンスを向上させる仕組みとなっています。

データの分散

データの6つのコピー

Auroraは、データを3つの異なるアベイラビリティゾーンに分散します。各アベイラビリティゾーンには2つのデータコピーが保持されるため、リージョン全体で合計6つのデータコピーが存在します。

機能	説明
AZ全体＋1の障害からの保護	個別のストレージボリュームが障害を起こしても、少なくとも3つのAZでデータが複製されているため、常にデータにアクセス可能です。
バックアップ	データはアプリケーションに影響が出ないように、継続的にAmazon S3にバックアップされます。

耐障害性

Auroraではクォーラムモデルという仕組みを採用しています。クォーラムモデルは、データベースシステムにおいて、データの整合性を保つために必要な最小限のノード数を定義する仕組みです。これにより、一定数のノードが正常に応答することで、データの読み書きが正確に行われ、システム全体の可用性が向上します。

Auroraでは、データの読み書きを行う際に、一定数のノードが正常に応答する必要があります。たとえば、6つのノードからなるクラスタでは、書き込みの際には4つのノードが応答する必要があり、読み込みの場合は3つのノードが応答が必要です。

この仕組みによって、仮に1つや2つのノードがダウンしても、残りのノードが正常に動作し続けるため、システム全体が機能し、高い可用性を実現しています。

書き込み	読み込み
4/6ノードクォーラムが必要	3/6クォーラムが必要

リードレプリカとエンドポイント

特徴

3つのアベイラビリティゾーンで最大15個の昇格可能なリードレプリカ
Auroraでは、複数のアベイラビリティゾーンにデータを分散し、最大で15個のリードレプリカを作成できます。これらのリードレプリカは、必要に応じてプライマリインスタンス（ライター）に昇格することが可能で、書き込み負荷に対応できる柔軟な設計がされています。
リードレプリカはAuto Scalingによる自動増減が可能です。
リードレプリカはAuto Scalingに対応しており、トラフィックの増減に応じて自動的にレプリカの数を調整します。負荷が高い時にはリソースを増やし、低い時にはリソースを抑えることで、効率的な運用が可能です。
低遅延なREDOログベースの物理レプリケーション（通常20～40ミリ秒のレプリカラグ）
Auroraは、REDOログを使用した物理レプリケーションにより、20～40ミリ秒の低遅延でデータの同期を行います。ほぼリアルタイムで最新のデータをリードレプリカから読み取ることができ、高速なデータ参照が可能です。
フェイルオーバーの優先順位を構成可能です。
Auroraでは、フェイルオーバー時にどのリードレプリカがプライマリインスタンス（ライター）として昇格するかを事前に優先順位付けして構成できます。障害発生時にも最適なインスタンスが自動的に選ばれ、迅速にサービスを復旧させることが可能です。
ライターとリーダーはカスタムエンドポイントの一部になることが可能です。
Amazon Auroraでは、インスタンスに接続するためにエンドポイントを使用します。これには以下の種類があります：
- ライターエンドポイント：Auroraクラスタ内のプライマリインスタンス（ライター）に接続するためのエンドポイントです。書き込み処理を担当するインスタンスにのみ接続されます。フェイルオーバー時に自動的に更新され、常に最新のライターインスタンスに接続可能です。
- リーダーエンドポイント：クラスタ内の複数のリードレプリカに接続するためのエンドポイントです。読み取り専用インスタンスにアクセスし、複数のリードレプリカへ自動で負荷分散を行います。特定のリードレプリカに接続するための個別エンドポイントも設定可能です。
- カスタムエンドポイント：特定のインスタンスグループ（リーダーやライター）に対する接続をカスタマイズするためのエンドポイントです。例えば、特定のリードレプリカ群に接続するよう設定することができ、柔軟な負荷分散や接続管理を実現します。アプリケーションごとに異なるカスタムエンドポイントを設定し、特定のデータベース処理を制御可能です。

従来のレプリカとAuroraリードレプリカの違い

MySQL/PostgreSQLとAmazon Auroraは、リードレプリカのスケーリングにおいて異なるアプローチを取っています。

まず、MySQL/PostgreSQLでは、論理レプリケーションを使用してソースデータベースとリードレプリカ間のデータ同期を行います。これは、データベースの差分変更を適用する形式で、レプリカにソースと同等の書き込みが発生するため、独立したストレージが必要となります。結果として、ワークロードによってはレプリカラグ（同期の遅れ）が発生しやすく、大規模なリードスケーリングが難しくなる場合があります。

一方で、Amazon Auroraは物理レプリケーションに基づいたアーキテクチャを採用しており、レプリカには書き込みが発生せず、共有ストレージを利用することでデータの整合性を保っています。このアプローチにより、通常20〜40ミリ秒のレプリカラグと低遅延でスムーズなリードスケーリングが可能です。

MySQL/PostgreSQLのリードスケーリング

論理レプリケーション：MySQL/PostgreSQLでは、データ変更が「差分」として論理的に伝達され、リードレプリカに書き込みが発生します。
独立したストレージ：リードレプリカはそれぞれ独立したストレージを持ち、ソースインスタンスからデータを同期します。
レプリカラグ：データの変更が順次反映されるため、ワークロードによっては大きなレプリカラグが発生し、最新データへのアクセスが遅れる可能性があります。

Amazon Auroraのリードスケーリング

物理レプリケーション：Auroraでは、データの変更をブロック単位で直接リードレプリカに反映させるため、リードレプリカには書き込みが発生しません。これにより、処理負荷が大幅に軽減されます。
共有ストレージ：Auroraでは、リードレプリカとライターインスタンスが同じ共有ストレージを利用しており、全てのインスタンスが常に最新のデータにアクセスできます。これにより、データ同期の必要がなくなり、効率的なデータ管理が可能です。
低いレプリカラグ：Auroraのレプリカラグは通常20～40ミリ秒程度と非常に小さく、これは物理レプリケーションによる効率的なデータ同期とPage Cache Update（リードレプリカのメモリ内のデータを最新に更新するプロセス）により実現されています。このPage Cache Updateによってわずかな遅延は発生しますが、それでも非常に低いレプリカラグを保っています。

項目	MySQL/PostgreSQL	Amazon Aurora
レプリケーションの種類	論理レプリケーション：データ変更が差分として伝達され、リードレプリカに書き込みが発生	物理レプリケーション：データの変更をブロック単位で反映し、リードレプリカに書き込みが発生しない
ストレージ	独立したストレージ：リードレプリカは独立したストレージを持ち、ソースインスタンスからデータを同期	共有ストレージ：リードレプリカとライターインスタンスが同じストレージを利用し、常に最新データにアクセス可能
レプリカラグ	レプリカラグが大きくなる可能性があり、最新データへのアクセスが遅れることがある	非常に低いレプリカラグ（通常20～40ミリ秒程度）

クラッシュリカバリ

従来のデータベース実装

最後のチェックポイントからログを適用していきます。
MySQLの場合、処理はシングルスレッドで多数のディスクアクセスが必要です。
T0(*)でクラッシュが発生すると最後のチェックポイントからのログを適用する必要があります。
(*)TO：クラッシュが発生した時点

Amazon Aurora

クラッシュリカバリをコンピュートのレイヤではなく、すべてストレージのレイヤーで実施します。
つまり、リカバリ中か否かは関係なく、T0でクラッシュが発生するとredoログの適用を並列・分散・非同期で継続的にログレコードを再生します

Auroraのコンポーネント

Amazon Aurora DB クラスター

Amazon Auroraの管理単位です。
Writerインスタンス、Readerインスタンス、クラスターボリュームの総称です。

種類	説明
Writer インスタンス (プライマリ)	読み込み、書き込みを行うインスタンスです。
Reader インスタンス	読み込み専用のインスタンス（15台まで作成可能）です。
クラスターボリューム	3つのAZ間でレプリケートされる仮想ボリュームです。WriterインスタンスもReaderインスタンスも同じクラスターボリュームを利用します。

Aurora エンドポイント

Auroraの接続先を示すURLです。

パフォーマンス

Amazon Auroraが高パフォーマンスを発揮する理由は、従来のデータベースとは異なる仕組みにあります。

従来のデータベースでは、データがクラッシュなどの障害から復旧できるように、データ変更の履歴をREDOログに記録します。このREDOログの書き込みでは、データが変更されるたびに、その変更内容をログに記録し、万が一の障害時にそのログを元にデータの整合性を保ちながら復元します。通常、このREDOログは順番に（シーケンシャルに）書き込まれるため、処理に時間がかかることがあります。また、チェックポイント（*）という特定のタイミングでデータの状態を保存し、障害発生時にその時点までの変更を記録したログを適用して復旧を行います。このシーケンシャルな処理や頻繁なI/Oが、従来のデータベースのパフォーマンスに影響を与えることがあります。

一方、Auroraではチェックポイントがなく、I/O処理が少なくなるため、パフォーマンスが安定します。また、REDOログは非同期・非順序で書き込まれるため、ログ書き込みが高速化され、データ処理が効率的です。Auroraでは、この非同期処理により、ログをすばやく保存しつつ、必要に応じて高速でデータを復旧することが可能です。

（*）チェックポイント：チェックポイントは、データベースが定期的にデータをディスクに保存するセーブポイントです。クラッシュ時に、この時点までのデータが確実に復元できるようにします。

従来のデータベース	Amazon Aurora
チェックポイントの有無	チェックポイントが存在し、I/O処理が多くなる
REDOログの書き込み方式	シーケンシャルなREDOログの書き込みが必要

Auroraの独自機能

Query Plan Management

Oracle DatabaseにおけるSPM（SQL Plan Management）にあたる機能です。
データベースがクエリを効率よく実行できるように、最適な実行計画（クエリプラン）を管理し、パフォーマンスの安定性を保つための機能です。

ユースケース

パフォーマンス低下を防ぐための事前予防
開発環境で、パフォーマンスに悪影響を与えるSQL文を見つけて、手動または自動でクエリの実行プランを記録します。
開発環境で承認された実行プランを、本番環境にインポートします。
本番環境では、この承認されたベースラインの実行プランを強制的に使用します。
本番で新しくキャプチャーされたプランが効率的かどうかを分析し、必要であれば承認します。
パフォーマンス低下時の事後対応
アプリケーションの実行プランを固定して維持しつつ、新しいプランを引き続きキャプチャーします。
アプリケーションのパフォーマンス低下を監視して分析します（例: Performance Insightsを使用）。
現在使用しているベースラインプランが問題なら、それを無効にして別の承認済みプランに切り替えます。
必要に応じて、pg_hint_plan拡張を使って実行プランを手動で調整することも可能です。

Database Cloning

データベースのコピーを作成する為の機能です。データそのものを物理的にコピーするのではなく、元のデータベースを「参照」する形でクローンを作成します。クローンされたデータベースは元のデータベースとは独立して操作できます。クローン内での変更は元のデータベースに影響を与えず、逆に元のデータベースでの変更もクローンに影響を与えません。

特徴

クローン作成の効率:
クローンは即時作成され、データの完全なコピーはされません。
実際にクローンにデータが書き込まれる際に、オリジナルデータのコピーが行われます。
最大クローン数:
最大で15個のクローンを作成可能です。

ユースケース

テスト環境用:
実稼働DBのクローンを作成してテスト環境を構築します。
データベース再編成:
データベースの再編成やメンテナンス作業を行います。
本番影響回避:
本番システムに影響を与えることなく、データ分析やスナップショットを保存する際に利用します。

Aurora Serverless

特徴

コンピューティングキャパシティーが自動管理されるAmazon Aurora
オンデマンドで起動し、利用状況に応じてスケーリングします。
利用されていない場合は自動停止し、スケール時のクライアント接続の中断はありません。秒課金（ただし、1分が最低利用料金です）。

ユースケース

不定期利用のアプリケーション
開発・テスト用途
リクエスト予測が難しい場合
※スケールアップ時にインスタンスの停止が発生するため、安定的な運用が求められる場合や定常的にリクエストが予測できる場合はプロビジョンドのAuroraの利用がおすすめです。

Cluster Cache Management

Cluster Cache Managementは、ライターとほぼ同期されたウォームキャッシュを持つレプリカへフェイルオーバーする機能です。
この機能が有効化されており、優先順位が最も高いレプリカにフェイルオーバーされます。

Aurora Global Database

Amazon Auroraクラスターを複数のAWSリージョンにまたがって構築できる機能です。
ストレージのレイヤーでの物理レプリケーションを行うため、論理レプリケーションと比較してスループットが高く、遅延が少ないです。

AuroraとRDSの検討ポイント

Aurora MySQL/PostgreSQLの強み

可用性・パフォーマンス・運用性を重視したい
クローンなどAurora独自の機能を利用し、快適に運用・開発をしたい

RDS for MySQL/PostgreSQLの強み

コストの考え方

料金モデルの違い

DBインスタンスの料金はRDSの方が若干安いです。
RDSはIOPSのピークを考慮してプロビジョニングする必要があります。
AuroraはストレージへのI/Oリクエスト数にも、使った分だけ課金されます。（RDS、Auroraいずれも、チューニングによるIO削減でコスト削減につながります）

アーキテクチャ/パフォーマンスの違い

RDSはMulti-AZのスタンバイインスタンスにアクセスできません。
- スタンバイインスタンスの利用効率： RDSのMulti-AZ構成では、スタンバイインスタンスが主に障害時のフェイルオーバーのために用意されますが、通常の運用時にはそのスタンバイインスタンスに直接アクセスすることができません。つまり、スタンバイインスタンスは待機状態にあり、リソースが活用されないまま維持されるため、実質的に使用されていないリソースに対してコストが発生します。この「利用されないリソース」にコストがかかるという非効率が存在するため、重要なポイントとなります。
- Auroraとの比較： Auroraの場合、リードレプリカ（読み込み専用のレプリカ）に対してもアクセス可能であり、負荷分散に役立ちます。つまり、スタンバイ状態にあるリソースも読み込みワークロードに使うことができ、リソースの効率的な利用が可能です。結果として、パフォーマンス向上やコスト削減につながるため、RDSとの比較でコストの面でも差が生じます。
Auroraのリードレプリカは、通常のRDSのレプリカよりも多くのリソースを読み込みワークロードに割り当てることができ、インスタンスを集約できる可能性があります。

機能の違い

Aurora独自の機能（クローン、QPMなど）を利用して、運用・開発コストを削減できる可能性があります。

まとめ

本記事では、Amazon Auroraのアーキテクチャやストレージの特徴、データの分散、耐障害性、リードレプリカなどの重要なポイントを解説しました。Auroraは、その高いパフォーマンスと可用性により、データベースの選択肢として非常に魅力的です。今後、データベースを選定する際には、Auroraの特性を活かした運用ができるかどうかを考慮することが重要です。ぜひ、Auroraを利用してデータベース管理の効率化やパフォーマンス向上を実現してみてください。