Aurora
1. サービス概要¶
Amazon Aurora は、高いパフォーマンスと可用性を兼ね備えた RDB（リレーショナルデータベース）サービスである。
AWS によるフルマネージドである点や、MySQL/PostgreSQL 互換のエンジンを選択できる点などが特徴で、従来の商用データベースに比べて優れたコストパフォーマンスとスケーラビリティを提供する。
主なユースケースとして、
- 大規模アプリケーションのオンライン処理
- 急激にアクセスが増加する EC サイト
- 金融システムなどミッションクリティカルな業務
が挙げられる。 レイテンシの低い読み取り負荷にも対応可能で、OLTP と OLAP のハイブリッド環境として活用されるケースもある。
2. 主な特徴と機能¶
2.1 MySQL/PostgreSQL 互換エンジン¶
Aurora では、MySQL 互換エンジンと PostgreSQL 互換エンジンから選択可能である。
アプリケーション側のドライバや SQL 文を大きく修正することなく、Aurora に移行できる点が魅力である。
2.2 高速で信頼性の高いストレージ¶
Aurora はストレージ層を分散・自動スケーリングする仕組みを持ち、最大 64TB まで拡張可能である。
6 つのコピーを 3 つの AZ に分散配置することで、障害に対する耐久性とスケーラビリティを両立する。
2.3 セミスレーブ機能 (Aurora Replica)¶
Aurora Replica を利用することで、読み取り専用インスタンスを増設し、読み取り負荷を分散可能である。
最大 15 個のレプリカを作成でき、プライマリインスタンスの障害時には自動フェイルオーバー機能により数秒でレプリカが昇格する。
2.4 Aurora Serverless¶
Aurora Serverless を利用すると、使用状況に応じて自動的にキャパシティをスケールし、アイドル時にはコストを最小限に抑えることが可能である。
突発的なアクセス増加があるアプリケーションや、ピーク時以外は負荷が少ないワークロードに適している。
2.5 高い可用性とバックアップ¶
Aurora はスナップショットや Point-in-Time リカバリをサポートし、継続的バックアップも実現する。
また、マルチ AZ 構成が標準機能として組み込まれており、高い耐障害性を持ちながら運用が可能である。
3. アーキテクチャおよび技術要素¶
- クラスター概念を中心に、プライマリインスタンス（ライト/リード）＋ Aurora レプリカ（リード専用）を構成
- ストレージは自動スケーリングし、6 つのコピーを 3 つの AZ に分散配置
- 障害が発生した場合は、Aurora レプリカがプライマリにフェイルオーバーし、サービス継続
- Aurora Serverless を選択することで、負荷に応じた自動スケーリングを行いコストと運用負荷を最適化
Aurora のストレージレイヤーが独立しており、コンピュートレイヤー（DB インスタンス）を追加・削除しても、一貫したデータビューを保てる設計になっている。
4. セキュリティと認証・認可¶
Aurora は他の RDS 系サービス同様、強固なセキュリティを提供する:
- VPC 内配置: セキュリティグループやネットワーク ACL を利用したネットワーク制御
- 暗号化: AWS KMS による暗号化（暗号化されたストレージ、スナップショットなど）
- AWS IAM 連携: IAM を介したデータベース認証（IAM Database Authentication）に対応
- ログ監査: Access Log や Slow Query Log を有効化可能、CloudWatch Logs などで分析
5. 料金形態¶
Aurora の料金は以下の要素に基づく:
- DB インスタンス時間: インスタンスサイズと稼働時間の従量課金
- ストレージ使用量: 使用した分だけスケーラブルで、GB 単位の従量課金
- I/O リクエスト: 書き込み操作に応じた追加料金（MySQL 互換版の場合など）
- Aurora Serverless: Capacity Unit 時間ごとの従量課金方式で、アイドル時コストを抑制
6. よくあるアーキテクチャ・設計パターン¶
Aurora を活用する主要パターンは以下の通りである:
- 高スループット OLTP: 大量トランザクション処理が求められる EC サイトや金融業務でのメインデータベース
- ハイブリッド分析: アプリケーションでのオンライン処理と、Aurora レプリカを活用した分析クエリの同時実行
- Aurora Serverless: スポット的にアクセスが増減する Web アプリや開発/検証環境でのコスト最適化
- 災害対策（DR）構成: クロスリージョンレプリカやスナップショットを使い、万一の障害リスクに備える
7. 設定・デプロイ手順（ハンズオン例）¶
- AWS コンソールで「RDS」を開き、「データベースの作成」を選択
- エンジンとして「Amazon Aurora」を選択し、MySQL もしくは PostgreSQL 互換エディションを指定
- インスタンスタイプや DB クラスター設定を決定（例: db.r6g.large など）
- VPC・サブネット・セキュリティグループを設定し、パブリックアクセスの可否を指定
- マルチ AZ や Aurora レプリカの有無を選択し、オプションを適宜設定
-
「作成」をクリックし、DB クラスターが起動し次第、エンドポイント経由で接続テスト ###8. 試験で問われやすいポイント ####8.1 エンジンの違い(MySQL/PostgreSQL 互換)
-
MySQL 互換: トラフィック高い OLTP ワークロードに最適、MySQL 用ツールとの互換性が高い
- PostgreSQL 互換: 拡張機能や SQL 標準順守度が高く、分析系や開発で人気
- 選択基準: 既存アプリの互換性やエコシステムを考慮して決定
8.2 ストレージの仕組み¶
- 分散ストレージ: データを複数 AZ に跨って 6 重化するため耐障害性が高い
- 自動スケーリング: 使用量に応じてストレージサイズを拡大、事前プロビジョニング不要
8.3 レプリカとフェイルオーバー¶
- Aurora Replica: 読み込み専用ノードを追加し、読み取り性能を水平拡張
- フェイルオーバー: プライマリ障害時にレプリカが自動昇格してダウンタイムを最小化
8.4 Aurora Serverless の特徴¶
- 自動スケール: 負荷に応じて DB 容量が動的に増減
- アイドルコスト削減: 負荷が少ない時期は料金を抑えられる
- ユースケース: テスト・開発環境やアクセス急増の予測が困難なシナリオ
8.5 セキュリティとネットワーク¶
- VPC 配置: セキュリティグループでインバウンド/アウトバウンドをコントロール
- 暗号化: KMS 連携による暗号化を容易に設定
- 監査ログ: クエリログやスローログを CloudWatch Logs に出力可能
8.6 試験で頻出となる具体的な問われ方と答え¶
- Q: Aurora のストレージはどのように拡張する？
- A: 自動スケーリングで最大 64TB まで拡張し、6 つのコピーを 3AZ に保持。
- Q: Aurora レプリカの目的は？
- A: 読み取り専用ノードで読み込み負荷を分散し、プライマリ障害時のフェイルオーバー先になる。
- Q: Aurora Serverless が適しているのはどんなワークロード？
- A: ピークが予測困難、または長時間アイドル状態になるアプリケーションでコストを最適化したい場合。
- Q: MySQL 互換版と PostgreSQL 互換版の選択基準は？
- A: 既存アプリのドライバ互換性や SQL 機能要件、PostgreSQL 拡張機能の利用有無などを考慮。
- Q: Aurora の料金体系で特に注意すべき点は？
- A: インスタンス時間、ストレージ使用量、I/O リクエスト、そして Serverless の場合は Capacity Unit 時間。