初心者でも分かる！AWS Aurora MySQLの基本と始め方

はい、承知いたしました。AWS Aurora MySQLの基本と始め方について、初心者の方にも分かりやすく、約5000語の詳細な説明を含む記事を作成します。記事本文を直接表示します。

初心者でも分かる！AWS Aurora MySQL の基本と始め方

はじめに：データベースって何？なぜクラウド？そしてAuroraとは？

インターネットのサービス、スマホアプリ、オンラインショッピング。これらの裏側には必ず「データベース」が存在します。データベースとは、私たちが扱う様々な情報を整理して、必要に応じて素早く取り出したり、新しく追加したりするための仕組みです。例えるなら、大量のファイルがきちんと整理された巨大な図書館のようなものです。

従来、多くの企業や開発者は、自分たちのコンピューターやサーバー室にデータベースサーバーを設置し、運用・管理していました。これを「オンプレミス」と呼びます。オンプレミスのデータベースは、自分たちで全てをコントロールできる反面、様々な大変さがありました。

初期費用と維持費用: サーバーを買う、設置する、電気代がかかる、冷却する必要がある、といった物理的なコスト。
運用・管理の手間: ソフトウェアのインストール、設定、日々の監視、定期的なバックアップ、バージョンアップ、セキュリティ対策など、専門知識を持った担当者が常に管理する必要があります。
スケーリングの難しさ: アクセスが増えてデータベースの負荷が高まったとき、すぐに性能を上げるのは大変です。新しいサーバーを用意したり、設定を変更したりと時間がかかります。逆に、負荷が減っても、一度導入した高性能なサーバーのコストはかかり続けます。
可用性と耐久性: 災害や機器の故障でデータベースが停止すると、サービス全体が止まってしまいます。これを防ぐためには、予備のシステムを用意するなど、複雑な対策が必要です。

このような課題を解決するために登場したのが「クラウドデータベース」です。Amazon Web Services (AWS) のようなクラウドプロバイダーが、物理的なサーバーやネットワーク、そしてデータベースソフトウェアの基本的な運用・管理を肩代わりしてくれます。利用者はインターネット経由で必要なデータベースを必要な分だけ利用し、使った分だけ料金を支払います。

AWSが提供するリレーショナルデータベース（表形式でデータを管理する一般的なデータベース形式）のサービスは「Amazon Relational Database Service (RDS)」と呼ばれます。RDSは、MySQL、PostgreSQL、Oracle、SQL Server、MariaDBなど、様々な種類のデータベースエンジンをマネージドサービスとして提供しています。これにより、ユーザーは面倒な管理作業から解放され、アプリケーション開発に集中できるようになります。

そして、今回ご紹介する「AWS Aurora」は、このAmazon RDSファミリーの中で、特に高い性能、可用性、耐久性、そしてコスト効率を実現するためにAWSが独自に開発したデータベースエンジンです。特にMySQLおよびPostgreSQLと高い互換性を持っており、既存のMySQLやPostgreSQLデータベースを比較的簡単にAuroraに移行できることも大きな特長です。

本記事では、特に利用者の多い「AWS Aurora MySQL」に焦点を当てて、その基本的な仕組み、なぜ優れているのか、そして実際にどのようにして使い始めるのかを、初心者の方にも分かりやすく詳細に解説していきます。

AWS Aurora MySQL とは？

AWS Aurora MySQL は、AWSが開発したリレーショナルデータベースエンジンで、標準的なMySQLデータベースと比較して、最大で5倍のスループット（処理性能）を発揮すると言われています。同時に、商用データベースに匹敵する高い可用性と耐久性を備えています。

しかし、「互換性がある」と言われても、具体的に何が違うのでしょうか？そして、なぜそんなに高性能なのでしょうか？その秘密は、Auroraのユニークなアーキテクチャにあります。

Aurora のユニークなアーキテクチャ

従来のデータベースは、データベースエンジン（計算処理を行う部分）とストレージ（データを保存する部分）が一体化しているか、密接に連携するように設計されていました。これに対し、Auroraは計算処理を行うデータベースインスタンスと、データを保存するストレージシステムを完全に分離しています。

この分離アーキテクチャが、Auroraの多くのメリットの源泉となっています。

共有ストレージボリューム:
- Auroraでは、データベースのデータは、複数のアベイラビリティーゾーン（AZ: AWSリージョン内の独立した物理的なデータセンター群）にまたがって自動的に分散・複製される、単一の共有ストレージボリュームに保存されます。
- このストレージは、ユーザーが必要とするにつれて自動的にスケールアップ（容量が増える）します（最大128TB）。ユーザーは事前に容量を見積もったり、容量不足に悩んだりする必要がありません。
- データの耐久性は非常に高く設計されており、6つのデータのコピーが3つのアベイラビリティーゾーンに分散して保存されます（6-way replication）。これにより、単一または複数のAZに障害が発生してもデータが失われるリスクを極めて低く抑えられます。
- 従来のデータベースのように、各データベースインスタンスがそれぞれデータのコピーを持つ必要がないため、ストレージ容量を節約できます。
ログベースのストレージシステム:
- Auroraのストレージは、データの変更を「ログ（書き込み記録）」として記録することに特化しています。従来のデータベースのように、トランザクション（一連の処理）ごとに大量のデータをディスクに書き込むのではなく、ログだけを書き込みます。
- この「ログを書き込むだけ」という処理は非常に高速です。これにより、書き込み処理の性能が劇的に向上します。
- データの整合性や回復は、このログを処理することで実現されます。
計算処理とストレージの分離のメリット:
- 高速なフェイルオーバー: データベースインスタンス（リーダー/ライターインスタンス）に障害が発生した場合、別の待機しているインスタンスがすぐに共有ストレージボリュームに接続し、引き継ぎます。データ自体は共有ストレージにあるため、データコピーや復旧処理の時間が大幅に短縮され、サービスの停止時間を最小限に抑えられます（通常30秒以内）。
- 安価で高速なリードレプリカ: 読み込み専用のインスタンス（リードレプリカ）を追加することで、読み込み処理の負荷を分散し、アプリケーション全体の性能を向上させることができます。Auroraのリードレプリカは、プライマリーインスタンスと同じ共有ストレージボリュームを参照するため、データの複製に時間がかかりません。そのため、リードレプリカは非常に高速に追加・削除でき、レプリケーション遅延（プライマリーへの書き込みがレプリカに反映されるまでの時間）も非常に短いです（通常10ミリ秒未満）。最大15個までリードレプリカを作成できます。
- スケーラビリティ: 計算能力が必要な場合は、インスタンスタイプを変更したり、リードレプリカを追加したりすることでスケールアップ・アウトが容易に行えます。ストレージは自動的にスケールします。
- コスト効率: ストレージと計算が分離しているため、必要なストレージ容量と計算能力をそれぞれ独立してスケーリングできます。また、リードレプリカはプライマリーインスタンスと同じストレージを共有するため、レプリカが増えてもストレージ費用は変わりません（厳密にはI/O課金は変わりますが、ストレージ容量自体の課金は変わりません）。

このアーキテクチャが、従来のデータベースの限界を超えた性能、可用性、耐久性を実現しているのです。

なぜ標準 RDS MySQL ではなく Aurora MySQL を選ぶのか？

RDSには標準のMySQLエンジンもあります。これに対して、なぜあえてAurora MySQLを選ぶのでしょうか？主な理由は以下の点です。

圧倒的な性能: 標準RDS MySQLの最大5倍のスループットは、高負荷なWebサービス、ゲーム、大規模なエンタープライズアプリケーションなどで求められる高速なデータ処理を可能にします。特に書き込み性能（Insert/Update/Delete）が重要なワークロードで差が出やすいです。
高い可用性と耐久性: 障害発生時のフェイルオーバーが非常に高速（通常30秒以内）であること、データの耐久性が6way複製により極めて高いことは、ミッションクリティカルなシステムにとって大きなメリットです。標準RDS MySQLのMulti-AZ構成でもフェイルオーバーは行われますが、Auroraの方が一般的に高速です。
優れたスケーラビリティ: リードレプリカの追加・削除が高速で、最大15個まで作成できるため、読み込みトラフィックの急増に柔軟に対応できます。ストレージも自動拡張されるため、容量管理の手間がありません。
コスト効率: ストレージが共有されているため、リードレプリカを多数配置する場合のストレージコストが標準RDS MySQLよりも低くなる可能性があります。また、従量課金モデルにより、使った分だけ支払うため、初期投資を抑えられます。ただし、AuroraはI/Oリクエスト数にも課金されるため、ワークロードによっては標準MySQLの方が安くなる場合もあります。
管理の容易さ: RDS共通のメリットですが、ソフトウェアパッチ適用、バックアップ、復旧、障害検出、修復といった管理タスクの多くをAWSが自動で行ってくれます。Auroraはこれらの処理をさらに効率化しています。

ただし、Auroraにも考慮すべき点があります。

コスト: 一般的に、同等のインスタンスタイプで比較すると、Auroraの方が標準RDS MySQLよりもコストが高くなる傾向があります。特にI/Oリクエストが多いワークロードでは、I/O課金が大きくなる可能性があります。小規模なアプリケーションや開発・テスト環境では、標準RDS MySQLで十分な場合も多いです。
互換性: MySQLとの高い互換性がありますが、完全に100%ではありません。特定のMySQLの機能やプラグイン、ストレージエンジン（InnoDB以外など）はサポートされていない場合があります。移行前に互換性を確認する必要があります。
ロックイン: AuroraはAWS独自の技術に基づいているため、他のクラウドやオンプレミスに簡単に移行することはできません。

これらの点を踏まえ、高い性能、可用性、スケーラビリティが求められるワークロードであれば、Aurora MySQLは非常に強力な選択肢となります。小規模なアプリケーションやコスト最優先の場合は、標準RDS MySQLも検討する価値があります。

Aurora MySQL の主な機能の詳細

Aurora MySQLのキーとなる機能を、もう少し詳しく見ていきましょう。

高性能 (High Performance):
- 前述のログベースのストレージシステムと、書き込み処理を最適化する独自の仕組みにより、標準MySQLと比較して高い書き込みスループットを実現します。
- リードレプリカによる読み込み負荷分散と、非常に低いレプリケーション遅延により、読み込みが主体のワークロードでも高い性能を発揮します。
- パフォーマンスインサイト (Performance Insights) という機能を使うと、データベースの負荷状況や遅延の原因となっているクエリなどを詳細に分析でき、性能問題の特定と解決に役立ちます。
高可用性 (High Availability):
- プライマリーインスタンスに障害が発生した場合、通常30秒以内にリードレプリカの1つ、または新しくプロビジョニングされたインスタンスが新しいプライマリーとして昇格します。これは、ストレージが共有されているため、データの同期にかかる時間が不要だからです。
- リードレプリカは、プライマリーインスタンスと同じようにデータベーストラフィックを処理できます（読み込みのみ）。プライマリーが利用できなくなった場合、アプリケーションはリードレプリカに切り替えることで、読み込み処理を継続できます。
- 複数のアベイラビリティーゾーンにインスタンスを配置することで、単一AZの障害からも保護されます。
高耐久性 (High Durability):
- データは3つのAZにわたって6重に複製されます。
- ストレージシステムは、自己修復機能を持ち、ディスクセグメントの障害を自動的に検出して修復します。
- 継続的なバックアップ（ポイントインタイムリカバリ）がデフォルトで有効になっており、特定の時点（最大35日前まで）の状態にデータベースを復元できます。スナップショットによるバックアップも取得可能です。
スケーラビリティ (Scalability):
- ストレージの自動スケール: 最小10GBから最大128TBまで、必要に応じてストレージ容量が自動的に増加します。ユーザーが手動で容量を拡張したり、事前に大容量を確保したりする必要はありません。
- リードレプリカによるスケールアウト: 最大15個のリードレプリカを追加することで、読み込みトラフィックを分散できます。リードレプリカは数分で追加・削除が可能です。
- インスタンスタイプの変更によるスケールアップ: データベースインスタンスのタイプを変更することで、CPUやメモリのリソースを増強し、計算能力を向上させることができます。インスタンスタイプの変更は、一時的な停止が必要な場合があります。
- Aurora Serverless: 特定のワークロード向けに、使用量に応じてデータベースの処理能力（ACUs – Aurora Capacity Units）が自動的にスケールするモードも提供されています（Aurora Serverless v1/v2）。v2はよりきめ細やかなスケーリングが可能です。これにより、アクセスが予測不能な場合や、断続的に大量のアクセスがあるような場合に、コスト効率良くデータベースを運用できます。今回は初心者向けとしてプロビジョンドインスタンスを中心に解説しますが、Serverlessという選択肢もあることを覚えておきましょう。
コスト (Cost):
- 主に以下の要素で課金されます。
  - DBインスタンス時間: データベースインスタンス（プライマリーおよびリードレプリカ）を実行している時間に対して課金されます。インスタンスタイプによって料金が異なります。
  - ストレージ: 使用しているストレージ容量に対して課金されます。自動スケールされるため、実際に使用している容量に対して支払います。
  - I/O リクエスト: データベースがストレージに対して行う読み書きのI/Oリクエスト数に対して課金されます。Aurora独自の課金体系です。ワークロードによってはこのコストが大きくなる可能性があります。
  - バックアップストレージ: 自動バックアップや手動スナップショットの容量に対して課金されます（一定容量は無料枠あり）。
  - データ転送: データベースからインターネットなど外部へのデータ転送に対して課金されます。
- 標準RDS MySQLと比較して、ストレージ容量当たりの単価は低いですが、I/O課金があるため、総額はワークロードに依存します。リードレプリカが多い構成ではAuroraが有利になりやすい傾向があります。
セキュリティ (Security):
- VPC (Virtual Private Cloud) 内にデータベースを配置し、ネットワークアクセスを制御できます。
- ストレージレベルでの保存データの暗号化を容易に設定できます (AWS KMSと連携)。
- SSL/TLSを使用して、クライアントとデータベース間の通信を暗号化できます。
- IAM (Identity and Access Management) と連携し、AWSアカウント内のユーザーやサービスがAuroraリソースにアクセスする際の権限を細かく制御できます。
- RDSのセキュリティグループ機能を使用して、データベースへの接続元IPアドレスやポートを制限できます。
管理の容易さ (Ease of Management):
- AWSマネジメントコンソール、AWS CLI、SDKなどを通じて、データベースの作成、変更、削除、監視などの操作を一元的に行えます。
- 自動バックアップ、ポイントインタイムリカバリ、スナップショット機能により、データ保護が容易です。
- ソフトウェアパッチ適用やバージョンアップをAWSが管理します。
- Amazon CloudWatchと連携し、CPU使用率、接続数、スループットなどの様々なメトリクスを監視できます。
- RDSイベント通知を利用して、データベースの重要なイベント（フェイルオーバー、メンテナンス開始など）をEメールやSMSで受け取ることができます。

Aurora アーキテクチャの理解（もう少し詳しく）

前述のアーキテクチャについて、もう少し踏み込んで理解することで、なぜAuroraが特定の状況で高速なのか、なぜ可用性が高いのかが分かります。

従来のデータベース vs Aurora の書き込み処理のイメージ:

従来のデータベース（例: 標準RDS MySQL + EBSボリューム）:
1. アプリケーションからの書き込みリクエストを受け取る。
2. トランザクションログに書き込む (WAL – Write-Ahead Logging)。
3. メモリ上のデータを更新する。
4. データファイルに変更を書き込む（これは非同期で行われることが多いが、最終的にデータをディスクに永続化する必要がある）。
5. 複数の処理がディスク書き込みを待つことが、書き込み性能のボトルネックになりがち。
6. 耐久性を高めるには、同期的にディスクに書き込む必要がある場合があり、さらに遅くなる。
Aurora MySQL:
1. アプリケーションからの書き込みリクエストを受け取る。
2. ストレージシステムに対して、ログレコードを送信する。 Auroraのストレージシステムは、このログレコードを受け取り、3つのAZの6つのデータセグメントに複製する処理を行います。
3. プライマリーインスタンスは、ストレージシステムから「ログレコードが十分な数のデータセグメントに複製された」という確認を受け取ると、その書き込みを完了と判断します。
4. データページの変更をストレージに書き込む処理は、プライマリーインスタンスではなく、ストレージ側で非同期に行われます。
5. これにより、プライマリーインスタンスはディスクI/Oの完了を待つ必要が少なくなり、次の書き込みリクエストを素早く処理できます。書き込み処理のボトルネックが大幅に緩和されます。

従来のデータベース vs Aurora のリードレプリカのイメージ:

従来のデータベース（例: 標準RDS MySQLリードレプリカ）:
1. プライマリーインスタンスがデータに変更を書き込む。
2. その変更内容（バイナリログなど）をレプリカに送信する。
3. レプリカは受け取ったログを自分のストレージに適用する。
4. このログの転送と適用に時間がかかると、プライマリーとレプリカの間でデータの遅延（レプリケーション遅延）が発生する。
5. レプリカごとにフルデータコピーとストレージが必要。
Aurora MySQL リードレプリカ:
1. プライマリーインスタンスは、共有ストレージボリュームにログレコードを送信する。
2. リードレプリカは、同じ共有ストレージボリュームを直接参照する。
3. レプリカは、プライマリーが書き込んだ最新のログレコードをストレージボリュームから読み取り、自身のバッファプール（メモリ）に適用する。
4. データの物理的なコピーではなく、変更ログの適用だけで済むため、レプリケーション遅延が極めて短い。
5. レプリカはストレージを共有するため、レプリカを増やしてもストレージ容量の費用は変わらない（ただし、I/Oリクエスト課金は発生）。

このアーキテクチャの違いが、AuroraがMySQL互換でありながら、性能、可用性、スケーラビリティの点で優れている理由です。

AWS Aurora MySQL を始めるための実践ガイド

ここからは、実際にAWSアカウントを使ってAurora MySQLクラスターを作成し、接続するまでの手順を、初心者向けに詳細に解説します。

事前準備：AWSアカウント

AWSサービスを利用するには、まずAWSアカウントが必要です。まだお持ちでない場合は、AWS公式サイトから無料で作成できます。クレジットカード情報の登録が必要ですが、一定期間・一定のリソースは無料で利用できる「AWS無料枠」があります。Auroraも、特定のインスタンスタイプや利用量に制限がありますが、無料枠の対象となる場合があります（詳細はAWS公式サイトで確認してください）。ただし、無料枠を超過すると料金が発生するため、注意が必要です。

AWSアカウントを作成したら、マネジメントコンソールにログインできることを確認しておきましょう。

ステップ１：AWSマネジメントコンソールにログインし、RDSサービスへ移動

AWSマネジメントコンソールにログインします。
画面上部の検索バーに「RDS」と入力し、表示された「RDS」サービスをクリックします。または、左上のサービスメニューから「データベース」の下にある「RDS」を選択します。
RDSのダッシュボード画面が表示されます。

ステップ２：データベースの作成を開始する

RDSダッシュボード画面で、左側のナビゲーションペインまたは中央のボタンから「データベース」を選択します。
「データベースを作成」ボタンをクリックします。

ステップ３：データベース作成方法とエンジンオプションの選択

データベース作成画面が表示されます。ここでは、様々な設定を行います。

データベース作成方法の選択:
- 通常は「標準作成」を選択します。「簡単作成」もありますが、詳細な設定を理解するためにも「標準作成」がおすすめです。今回は「標準作成」で進めます。
エンジンのオプション:
- 利用したいデータベースエンジンを選択します。ここでは「Amazon Aurora」を選択します。
エディション:
- Auroraには「Amazon Aurora (MySQL 互換エディション)」と「Amazon Aurora (PostgreSQL 互換エディション)」があります。今回はMySQL互換版を使うので、「Amazon Aurora (MySQL 互換エディション)」を選択します。
- さらにエディションとして「Amazon Aurora MySQL (Standard)」または「Amazon Aurora MySQL (Serverless)」があります。初心者の方は、まずインスタンスサイズを固定して費用を管理しやすい「Amazon Aurora MySQL (Standard)」を選択するのが一般的です。Serverlessはアクセスパターンが予測しにくい場合などに検討します（今回はStandardで解説します）。
エンジンのバージョン:
- 利用したいMySQL互換エンジンのバージョンを選択します。特別な理由がなければ、最新のメジャーバージョンと、その中の最新のマイナーバージョンを選択するのが推奨されます。新しいバージョンには、性能改善やセキュリティパッチ、新機能が含まれていることが多いです。

ステップ４：テンプレートの選択 (オプション)

開発/テスト用か本番環境用か、用途に合わせたテンプレートを選択できます。

本番稼働用: 高可用性 (Multi-AZ)、パフォーマンス、耐久性などの設定が最適化されています。
開発/テスト用: コストを抑えた設定になっています。
無料利用枠: 無料利用枠の対象となる設定に自動的に調整されます。初めて試す場合はこれを選ぶと良いでしょう。

用途に合わせて選択してください。選択したテンプレートによって、後続の設定のデフォルト値が変わります。

ステップ５：DBクラスター識別子と認証情報の設定

ここは非常に重要です。データベースにアクセスするための名前とパスワードを設定します。

DBクラスター識別子:
- このAuroraクラスターの名前を決めます。AWSアカウント内で一意である必要があり、英数字とハイフンが使用できます。後で見たときに何のデータベースか分かるような名前をつけましょう（例: my-aurora-cluster-dev, production-web-db）。
マスターユーザー名:
- データベースの管理者（rootユーザーに相当）のユーザー名を設定します。デフォルトは admin ですが、セキュリティのためにデフォルトから変更することを推奨します。
マスターパスワード:
- マスターユーザーのパスワードを設定します。非常に複雑で推測されにくいパスワードを設定してください。大文字、小文字、数字、記号を組み合わせた8文字以上のパスワードが推奨されます。このパスワードは、データベースへの初期接続に必要になりますので、忘れないように安全な場所に控えておきましょう。
- 確認のため、もう一度同じパスワードを入力します。

ステップ６：インスタンス設定

データベースインスタンスのサイズ（性能）を選択します。

DBインスタンスクラス:
- データベースインスタンスのCPU、メモリ、ネットワーク性能などを決定する「インスタンスタイプ」を選択します。
- プルダウンを開くと、「バースト可能クラス (tクラス)」と「標準クラス (rクラス, xクラスなど)」があります。
- バースト可能クラス (tクラス): CPUクレジットを使用して、一時的に高いCPU性能を発揮できます。開発/テスト環境や、継続的な高負荷がかからない小規模なワークロードに適しています。コストは比較的安いです。例: db.t3.medium
- 標準クラス (rクラス, xクラス): 持続的に高いCPU性能と大容量メモリを提供します。本番環境や、常に高負荷がかかるワークロードに適しています。性能に応じてコストが高くなります。Auroraでは db.r* や db.x* ファミリーが推奨されます。例: db.r6g.large, db.r5.xlarge
- 初心者で試す場合は、無料利用枠対象のインスタンスタイプ (db.t3.micro など) を選択するか、「開発/テスト用」テンプレートを選択していればデフォルトで適切なものが選ばれていることが多いです。本番環境の場合は、ワークロードに必要なリソースを見積もって選択する必要があります。最初は少し小さめのインスタンスタイプで開始し、必要に応じてスケールアップすることも可能です。
- インスタンスタイプの横に表示されているのは、そのインスタンスの「世代」と「サイズ」を示しています。数字が大きいほど新しい世代で高性能・高効率な傾向があります。large, xlarge, 2xlarge とサイズが大きくなるほど、CPUコア数やメモリ容量が増加します。

ステップ７：可用性と耐久性

高可用性構成にするかどうかを設定します。

マルチAZ配置:
- 複数AZを作成: はい (DB インスタンスのレプリカ)
  - これを選択すると、プライマリーインスタンスに加えて、別のAZに読み込み専用のリードレプリカが自動的に1つ作成されます。このリードレプリカは、プライマリーに障害が発生した場合に自動的に昇格して新しいプライマリーとなります。これにより、高い可用性が実現されます。本番環境では「複数AZを作成」を選択することが強く推奨されます。
  - Standardエディションでは、この設定が「DB インスタンスのレプリカ」という表現になっています。Serverless v2の場合は、Multi-AZ構成がデフォルトであり、インスタンス数を指定する形式になります。
- 単一AZ:
  - 単一のAZにのみインスタンスが配置されます。コストは抑えられますが、そのAZに障害が発生した場合にデータベースが利用できなくなります。開発/テスト環境など、可用性をそこまで重視しない場合に選択します。

ステップ８：接続

データベースへの接続設定を行います。

ネットワークタイプ:
- 特別な理由がなければ、デフォルトの「IPv4」を選択します。
VPC (Virtual Private Cloud):
- データベースを配置するVPCを選択します。AWSアカウント作成時にデフォルトVPCが作成されていることが多いです。通常はそのデフォルトVPCを選択するか、自分で作成したVPCを選択します。データベースは、外部から直接アクセスできないVPCプライベートサブネットに配置するのがセキュリティ上のベストプラクティスです。
サブネットグループ:
- VPC内のどのサブネット（ネットワーク区分）にデータベースを配置するかを定義したグループです。自動的に適切なサブネットグループが作成されるか、既存のものから選択します。Multi-AZを選択した場合、選択したサブネットグループには複数のAZにまたがるサブネットが含まれている必要があります。
パブリックアクセス可能:
- 「はい」を選択すると、データベースがインターネットから直接アクセス可能になります。 これはセキュリティリスクを高めるため、特別な理由（学習目的で自宅から直接繋ぎたいなど、本番利用以外）がない限り「いいえ」を選択することを強く推奨します。 本番環境では「いいえ」を選択し、VPC内のEC2インスタンスや、VPN接続、Direct Connectなどを介してアクセスするのが一般的です。
- 今回は、初心者の方がローカル環境から接続して試すために、一時的に「はい」を選択するシナリオも解説しますが、あくまで学習目的限定と考えてください。本番環境では絶対に「いいえ」です。
VPCセキュリティグループ:
- データベースインスタンスへのネットワークトラフィック（どのIPアドレスやどのサービスからのアクセスを許可するか）を制御するファイアウォールのようなものです。新しいセキュリティグループを作成するか、既存のものを使用します。
- 「新規作成」を選択した場合、新しいセキュリティグループの名前を入力します。このセキュリティグループで、後ほどデータベースに接続するためのルール（通常はMySQLのポート番号である3306番へのインバウンドアクセス許可）を設定する必要があります。
- 「既存の選択」を選択した場合、使用したいセキュリティグループを選びます。
- ローカル環境から接続する場合（パブリックアクセス「はい」の場合）： 新規作成を選び、後でそのセキュリティグループに対して、あなたのグローバルIPアドレスからの3306番ポートへのインバウンドアクセスを許可する設定を追加します。IPアドレスは「現在使用中のIP」などのオプションで簡単に設定できますが、自宅などの動的IPの場合は変わる可能性があるので注意が必要です。
- VPC内のEC2などから接続する場合（パブリックアクセス「いいえ」の場合）： 新規作成を選び、後でそのセキュリティグループに対して、接続元となるEC2インスタンスに割り当てられているセキュリティグループからの3306番ポートへのインバウンドアクセスを許可する設定を追加します。これが最も一般的な安全な接続方法です。
アベイラビリティーゾーン:
- 特定のAZを指定することもできますが、通常は「優先なし」でAWSに自動選択させるのが推奨されます。

ステップ９：データベース認証情報

デフォルトの認証情報管理方法を選択します。

データベース認証情報:
- 「認証情報の管理に AWS Secrets Manager を使用する」というオプションがあります。セキュリティ上はSecrets Managerを使うのが推奨されますが、初心者の方はまずシンプルに「マスターパスワード」で管理するので問題ありません。今回はマスターパスワードを使用する前提で進めます。

ステップ１０：追加設定

その他の詳細設定を行います。

データベースポート:
- MySQLの標準ポートは3306です。特別な理由がなければデフォルトの3306のままにします。
データベース名:
- クラスター作成時に、最初のデータベース（スキーマ）を1つ作成できます。ここで名前を指定すると、その名前で空のデータベースが作成されます（例: mydatabase）。後からSQLコマンドでデータベースを追加することも可能です。必要なければ空欄でも構いません。
DBクラスターパラメーターグループ:
- データベースエンジンの詳細設定（パラメータ）を定義したグループです。デフォルトのパラメーターグループは変更できませんが、コピーしてカスタムパラメーターグループを作成し、様々な設定を調整できます（例: 文字セット、タイムゾーンなど）。初心者の方はまずデフォルトのままで問題ありません。
DBインスタンスパラメーターグループ:
- 各DBインスタンスに適用されるパラメーターグループです。通常はDBクラスターパラメーターグループの設定がインスタンスに継承されますが、インスタンス固有の設定を行いたい場合にカスタムグループを使用します。初心者の方はデフォルトのままで問題ありません。
暗号化:
- 保存データを暗号化するかどうか。本番環境では必ず有効化することを推奨します。 デフォルトで有効になっていることが多いです。有効化する場合、使用するKMSキーを選択または作成します。
バックアップ:
- バックアップ保持期間: 自動バックアップを何日間保持するかを設定します。最大35日まで設定可能です。本番環境では少なくとも7日以上、要件に合わせて適切な期間を設定しましょう。
- バックアップウィンドウ: 自動バックアップが実行される時間帯を指定します。通常、システムの負荷が低い時間帯を指定します。
モニタリング:
- Enhanced Monitoring: より詳細なOSレベルのメトリクスを収集できます。トラブルシューティングに役立ちますが、追加料金が発生します。必要に応じて有効化を検討します。
- Performance Insights: データベースの負荷状況やボトルネックとなっているクエリを詳細に分析できます。強力な機能ですが、追加料金が発生します。無料枠もありますが制限があります。開発や運用で性能問題に直面した場合に非常に役立ちます。
ログのエクスポート:
- エラーログ、スロークエリログなどをAmazon CloudWatch Logsにエクスポートできます。ログ分析や監視に役立ちます。必要に応じて有効化します。
マイナーバージョン自動アップグレード:
- データベースエンジンのマイナーバージョンアップグレードを自動で行うかどうか。有効化すると、メンテナンスウィンドウ中に自動で適用されます。セキュリティやバグフィックスが含まれるため、通常は有効化が推奨されます。
メンテナンスウィンドウ:
- AWSが自動メンテナンス（マイナーバージョンアップグレードやセキュリティパッチ適用など）を行う時間帯を指定します。システムへの影響が少ない時間帯（例: 深夜や早朝）を指定しましょう。「期間を指定」で曜日と開始時間を設定できます。
削除保護:
- 有効化することを強く推奨します。 有効にすると、誤ってデータベースクラスターを削除してしまうことを防ぎます。本番環境では必須の設定です。

ステップ１１：コストの確認とデータベース作成

画面下部に、ここまでの設定に基づいた月額費用の見積もり概算が表示されます。この見積もりは参考値であり、実際の利用状況（特にI/Oリクエスト数）によって変動します。内容を確認し、問題なければ「データベースを作成」ボタンをクリックします。

データベースクラスターの作成が開始されます。クラスターの状態が「作成中」から「利用可能」になるまで、通常10分〜20分程度かかります。この間、しばらく待ちます。

ステップ１２：セキュリティグループの設定（パブリックアクセス「はい」の場合）

パブリックアクセスを「はい」にした場合、データベースに接続するためには、先ほど作成または指定したセキュリティグループのインバウンドルールを編集し、あなたの接続元からのアクセスを許可する必要があります。

RDSダッシュボードのデータベース一覧で、作成したAuroraクラスターを選択します。
詳細画面の下の方にある「接続とセキュリティ」タブを開きます。
「VPC セキュリティグループ」のリンクをクリックします。セキュリティグループの設定画面に飛びます。
セキュリティグループ画面で、下部の「インバウンドのルール」タブを選択します。
「インバウンドのルールを編集」ボタンをクリックします。
「ルールを追加」ボタンをクリックします。
タイプ: 「MYSQL/Aurora (3306)」を選択します。
ソース:
- 「マイIP」を選択すると、現在あなたがインターネットに接続しているグローバルIPアドレスが自動で入力されます。これは最も簡単ですが、IPアドレスが変わる可能性がある点に注意が必要です。
- IPアドレスが固定されている場合は、プルダウンから「カスタム」を選択し、ご自身の固定IPアドレスを /32 の形式で入力します（例: XXX.XXX.XXX.XXX/32）。
- 警告: 「任意の場所 IPv4 (0.0.0.0/0)」を選択すると、インターネット上の どこからでも このデータベースポートへのアクセスが許可されてしまいます。これは非常に危険なので、絶対に 本番環境では行わないでください。学習目的でも、可能な限り「マイIP」など、接続元を限定するようにしましょう。**
「ルールを保存」をクリックします。

ステップ１３：データベースへの接続

データベースクラスターが「利用可能」になったら、いよいよ接続してみましょう。接続には、MySQLクライアントソフトウェアが必要です。代表的なものに以下があります。

MySQL Workbench (GUIツール、Windows/macOS/Linux)
DBeaver ( универсальный инструмент для работы с базами данных, поддерживает множество типов баз, GUIツール)
TablePlus (GUIツール, macOS/Windows/Linux)
A5:SQL Mk-2 (GUIツール、Windows)
コマンドラインクライアント (mysql コマンド、Linux/macOS にデフォルトで入っている場合が多い)

ここでは、どのツールでも共通する接続情報とその確認方法を説明します。

RDSダッシュボードで、作成したAuroraクラスターを選択します。
詳細画面の「接続とセキュリティ」タブに、データベースに接続するための「エンドポイント」が表示されています。
- リーダーエンドポイント: リードレプリカへの接続に使います。読み込み処理の負荷分散をしたいアプリケーションは、このエンドポイントに接続します。
- ライターエンドポイント: プライマリーインスタンスへの接続に使います。書き込み処理（INSERT, UPDATE, DELETE）や読み込み/書き込み両方を行うアプリケーションは、このエンドポイントに接続します。Auroraクラスターには必ず1つのライターエンドポイントがあります。
- 注意: アプリケーションから接続する際は、通常はこのライターエンドポイントを使用します。読み込み負荷分散を積極的に行いたい場合は、リードレプリカを追加作成し、リーダーエンドポイントを使用することを検討します。
接続に必要な情報:
- エンドポイント: ライターエンドポイントのアドレス（例: my-aurora-cluster-dev.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com）
- ポート: 3306（または設定したポート番号）
- ユーザー名: マスターユーザー名（ステップ５で設定したもの）
- パスワード: マスターパスワード（ステップ５で設定したもの）
- データベース名 (オプション): ステップ１０で指定したデータベース名（例: mydatabase）

これらの情報をMySQLクライアントに入力して接続を試みてください。

例: コマンドラインクライアントの場合
bash mysql -h my-aurora-cluster-dev.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p
-h の後にエンドポイント、-P の後にポート番号、-u の後にユーザー名を指定します。-p をつけるとパスワード入力が求められます。

接続に成功すれば、Aurora MySQLデータベースを利用する準備ができました！

簡単なSQL操作を試す

接続できたら、簡単なSQLコマンドを実行してみましょう。

“`sql
— 現在接続しているデータベースを確認 (ステップ10でデータベース名を指定した場合)
SELECT DATABASE();

— もしデータベースがまだない場合、新しく作成
CREATE DATABASE mytestdb;

— 作成したデータベースを使用
USE mytestdb;

— 簡単なテーブルを作成
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE
);

— データを挿入
INSERT INTO users (name, email) VALUES (‘Alice’, ‘[email protected]’);
INSERT INTO users (name, email) VALUES (‘Bob’, ‘[email protected]’);

— データを取得
SELECT * FROM users;

— テーブルを削除
DROP TABLE users;

— データベースを削除 (注意: データが全て消えます)
DROP DATABASE mytestdb;
“`
これらのコマンドを実行してみて、データベースが正しく動作していることを確認してください。

Aurora MySQL の管理と運用（初心者向け）

Auroraクラスターを使い始めたら、日々の管理や監視も重要になります。

モニタリング:
- AWSマネジメントコンソールのRDSダッシュボードで、CPU使用率、DB接続数、スループット、ストレージ使用量などの主要なメトリクスをグラフで確認できます。
- CloudWatchと連携して、より詳細な監視やアラーム設定を行うことができます。例えば、CPU使用率が一定時間80%を超えたら通知するといった設定が可能です。
- Performance Insightsを有効にしている場合、どのクエリがパフォーマンスのボトルネックになっているかを視覚的に確認できます。
スケーリング:
- インスタンスタイプの変更（スケールアップ/ダウン）: RDSダッシュボードでクラスターを選択し、「変更」ボタンからインスタンスタイプを変更できます。変更適用時に短時間の停止が発生することがあります。
- リードレプリカの追加/削除（スケールアウト/イン）: RDSダッシュボードでクラスターを選択し、「アクション」メニューから「リーダーの追加」を選択するとリードレプリカを追加できます。不要になったレプリカは削除できます。リードレプリカの追加・削除は比較的短時間で完了します。
- ストレージ: Auroraのストレージは自動でスケールするため、手動での容量変更は不要です。
バックアップと復元:
- 自動バックアップ: デフォルトで有効化されており、指定した保持期間分、特定の時点（ポイントインタイム）に復旧できるようになっています。
- 手動スナップショット: 特定の時点のバックアップを手動で取得できます。重要な変更を加える前などに取得しておくと安心です。
- 復元: RDSダッシュボードでバックアップ（自動バックアップまたはスナップショット）を選択し、「アクション」から「特定の時点に復元」または「スナップショットから復元」を選択します。復元時には、新しいAuroraクラスターとして作成されます。
メンテナンス:
- 「メンテナンスウィンドウ」で設定した時間帯に、AWSによる自動メンテナンス（OSパッチ適用、DBエンジンマイナーバージョンアップグレードなど）が実施されます。必要に応じてウィンドウを変更できます。
コスト管理:
- AWS Billing Dashboardで、Auroraを含むAWSサービスの利用料金を確認できます。インスタンス時間、ストレージ、I/Oリクエスト、バックアップ、データ転送など、どの項目で費用が発生しているかを確認し、予期せぬコスト増加がないか定期的にチェックしましょう。不要なクラスターは忘れずに削除することが重要です。

Aurora MySQL を削除する

学習目的で作成したAuroraクラスターなど、不要になったクラスターは必ず削除しましょう。実行しているだけでインスタンス時間やストレージ、I/Oに対して費用が発生し続けます。

AWSマネジメントコンソールのRDSダッシュボードに移動します。
データベース一覧から、削除したいAuroraクラスターを選択します。
「アクション」メニューから「削除」を選択します。
削除前の最終確認画面が表示されます。
- 最終スナップショットの作成: 削除前に最終スナップショットを作成するかどうか選択します。復旧の可能性がある場合は作成を推奨します。作成する場合はスナップショット名を指定します。
- 削除保護の無効化: ステップ１０で「削除保護」を有効にしている場合、ここでチェックを外して無効化しないと削除できません。これが有効になっているのに削除できない、と焦る初心者の方が多いポイントです。
- 削除による影響についての確認メッセージが表示されます。内容をよく読み、理解した上でチェックボックスにチェックを入れます。
- マスターユーザーのパスワードの入力が求められます（セキュリティのため）。
「削除」ボタンをクリックします。

クラスターの削除が開始されます。状態が「削除中」となり、しばらくすると一覧から消えます。

注意: Auroraクラスターを削除しても、作成した最終スナップショットは削除されずに残ります。スナップショットにも料金が発生しますので、不要なスナップショットも別途削除するようにしましょう。RDSダッシュボードの左側メニュー「スナップショット」から確認・削除できます。

Aurora MySQL のコストに関する補足

Auroraのコストは、標準RDS MySQLと比較して複雑に感じるかもしれません。特に「I/Oリクエスト課金」が独特です。

I/O リクエストとは？
- データベースがストレージからデータを読み取ったり、ログを書き込んだりする際に発生する操作です。
- Auroraのストレージシステムは、書き込み処理をログとして記録することに特化しているため、書き込み処理が高速ですが、その代わりログの書き込み（Log I/O）に対して課金されます。
- 読み込み処理（Read I/O）は、データページがインスタンスのメモリ（バッファプール）にキャッシュされていない場合にストレージから読み取る際に発生します。これも課金対象です。
I/O コストに影響するもの:
- 書き込み頻度: データの更新（INSERT, UPDATE, DELETE）が多いワークロードは、Log I/Oが多く発生するためコストが高くなります。
- 読み込みのキャッシュヒット率: データがインスタンスのメモリにどれだけキャッシュされているか。キャッシュヒット率が高い（メモリから読めることが多い）ほど、Read I/Oは減ります。適切なインスタンスタイプ（メモリ容量）を選ぶことがI/Oコスト削減につながる可能性があります。
- クエリの効率: 非効率なクエリは、必要以上に大量のデータを読み取ったり書き込んだりするため、I/Oリクエスト数を増加させます。インデックスの最適化やクエリの改善は、I/Oコスト削減にも寄与します。
コスト削減のヒント:
- ワークロードに対して適切なインスタンスタイプを選択する。
- 必要以上のリードレプリカを作成しない。
- 不要になったデータベースクラスターはすぐに削除する。
- CloudWatchやPerformance InsightsでI/Oリクエスト数をモニタリングし、異常な増加がないか確認する。
- 必要であれば、スロークエリログなどを分析し、非効率なクエリを特定・改善する。

I/Oコストは、アプリケーションのデータベース利用パターンによって大きく変動するため、実際に運用しながら最適化を図る必要があります。

Aurora MySQL の一般的なユースケース

Aurora MySQL は、その高い性能、可用性、スケーラビリティから、様々な用途で利用されています。

高トラフィックのWebサイトおよびWebアプリケーション: ピーク時にも安定した高速なデータ処理が求められる場合に最適です。
SaaSアプリケーション: 多数のテナント（顧客）が同時に利用する場合でも、高いパフォーマンスと可用性を維持できます。
ゲームサービス: リアルタイム性の高いデータ処理や、突発的な大量アクセスに対応する必要があります。
エンタープライズアプリケーション: 基幹システムなど、高い信頼性と性能が求められるシステムに利用されます。
モバイルバックエンド: 多数のモバイルデバイスからのアクセスを処理するために利用されます。

標準RDS MySQLでは性能や可用性に不安がある場合、Aurora MySQLが強力な選択肢となります。

より深く学ぶために（少し進んだトピック）

Auroraには、今回ご紹介した基本的な機能以外にも、さらに高度な機能やオプションがあります。興味があれば、ぜひ調べてみてください。

Aurora Serverless v2: よりきめ細やかな自動スケーリング。アクセスが断続的で予測が難しいワークロードでコスト効率を発揮します。
Aurora Global Database: 複数のAWSリージョンにまたがってデータベースをレプリケーションし、高速なリージョン間フェイルオーバーや、読み込み処理のローカル分散を実現します。グローバルなアプリケーションに最適です。
Aurora Parallel Query: 読み込みクエリを複数のノードで並列実行し、分析クエリなどの処理速度を向上させます。
Performance Insights: データベースの性能問題を深く掘り下げて分析するためのツール。
RDS Proxy: データベース接続の管理を効率化し、アプリケーション側の接続プールの複雑さを軽減します。多数のクライアントからの接続がある場合などに有効です。
ゼロETL統合: AuroraからAmazon Redshiftなどのデータウェアハウスへ、データのロード処理（ETL）なしにほぼリアルタイムでデータを連携する機能。

これらの機能は、特定の要件を持つアプリケーションにおいて、Auroraのメリットをさらに引き出すことができます。

初心者向けのベストプラクティス

Aurora MySQLを使い始める初心者の方が、安全かつ効率的に利用するための簡単なベストプラクティスをいくつかご紹介します。

マスターパスワードは厳重に管理する: 複雑なパスワードを設定し、安全な方法で管理してください。
セキュリティグループを適切に設定する: データベースへのアクセスは、必要最低限の信頼できるIPアドレスやセキュリティグループからのみ許可するように設定しましょう。特に、本番環境でパブリックアクセスを有効にしたり、「任意の場所」からのアクセスを許可したりすることは絶対に避けてください。
削除保護を有効にする: 特に本番環境で使用するクラスターは、誤って削除してしまわないように削除保護を有効にしておきましょう。
CloudWatchで主要なメトリクスを監視する: CPU使用率、接続数、Free Storage Spaceなど、重要なメトリクスを定期的に確認し、異常があれば早期に気づけるようにしましょう。必要に応じてアラームを設定します。
コストを定期的に確認する: AWS Billing Dashboardで利用料金を定期的にチェックし、予期せぬ費用が発生していないか確認します。特にI/Oコストに注意しましょう。
不要になったリソースは削除する: 学習やテスト目的で作成したデータベースクラスターやスナップショットは、使い終わったら必ず削除しましょう。削除を忘れると課金され続けます。
小さなインスタンスタイプから始める: 性能要件が明確でない場合は、まずは小さめのインスタンスタイプで始めて、必要に応じてスケールアップすることを検討しましょう。
本番環境ではMulti-AZを有効にする: 高い可用性が求められる本番環境では、必ずMulti-AZ配置（DBインスタンスのレプリカ作成）を選択してください。
ドキュメントを参照する: AWSの公式ドキュメントは、Auroraに関する最も正確で詳細な情報源です。困ったときや、さらに詳しく知りたいときは積極的に参照しましょう。

まとめ：Aurora MySQL のメリットと次のステップ

AWS Aurora MySQL は、標準的なMySQL互換でありながら、AWS独自のアーキテクチャにより、従来のデータベースの限界を超える高い性能、可用性、耐久性、そして優れたスケーラビリティを実現したマネージドデータベースサービスです。

最大5倍の性能
通常30秒以内の高速フェイルオーバー
3AZ・6重化による高いデータ耐久性
ストレージの自動スケールと安価なリードレプリカ
AWSによる手厚い管理（バックアップ、パッチ適用、監視など）

これらの特長から、Webサービス、SaaS、ゲームなど、高負荷かつミッションクリティカルなアプリケーションのデータベースとして非常に有力な選択肢となります。

初心者の方にとって、AWSのサービスは最初は少し複雑に感じるかもしれませんが、RDSマネジメントコンソールの「データベースを作成」ウィザードはステップごとに分かりやすくガイドしてくれるように設計されています。本記事の手順に沿って進めれば、最初のAurora MySQLクラスターを立ち上げ、接続できるようになるはずです。

次のステップとして、以下に挑戦してみましょう。

実際にAuroraクラスターを作成してみる: 本記事の手順を見ながら、無料利用枠内で小さなクラスターを作成し、接続できるか試してみましょう。
簡単なアプリケーションから接続してみる: 自分で作成したプログラム（例えばPython, PHP, Node.jsなど）から、作成したAuroraデータベースに接続し、データの読み書きを試してみましょう。
CloudWatchでメトリクスを確認してみる: データベース作成後に、CloudWatchのRDSメトリクス画面で、CPU使用率や接続数などのグラフを確認してみましょう。
不要になったら忘れずに削除する: 試した後は、コスト発生を防ぐために必ずクラスターとスナップショットを削除しましょう。

最初は小さな一歩から始めて、徐々にAuroraの様々な機能やメリットを体験してみてください。AWS Aurora MySQLは、あなたのアプリケーションの可能性を大きく広げてくれる強力なツールとなるはずです。

この詳細なガイドが、あなたがAWS Aurora MySQLの世界に足を踏み入れるための一助となれば幸いです。頑張ってください！