Amazon Auroraについてまとめてみました。

# はじめに
こんにちは、山田です。
現在携わっている案件で、Amazon Auroraを使用する機会があったため、Amazon Aurraについて学習しました。
今回学習したことを忘れないように、記事にまとめていきます。

# Amazon Auroraとは
Amazon Auroraとは、クラウド向けにAWSが構築したデータベースです。
RDSを作成する際に、データベースエンジンの１つとしてAuroraを選択できます。

# Auroraの特徴
Auroraの特徴としては、主に以下の点が挙げられます。

**・Aurora DBクラスターは、1つ以上のDBインスタンスと、データを管理するクラスターボリュームで構成される。
・インスタンスとストレージとボリュームが分離している。
・読み込み処理およびフェイルオーバーが可能なAuroraレプリカが作成可能。
・データボリュームは、3AZに2個ずつ、計６個のコピーが作成され、高い障害性を持つ。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/9423b60b-0837-0675-985a-5137ca0da089.png)

# Auroraの可用性について
Auroraではストレージとインスタンス機能が分離しているため、クラスター上のインスタンスに障害が発生した場合もデータは安全に保持されます。

## クラスターボリュームの可用性
Auroraの6個のコピーのうち、2つに障害が発生した場合は**書き込み読み取り**に影響はないです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/2586ef6e-f6d0-7037-15d6-cfac7625353a.png)

3つに障害が発生した場合は、**読み込み**のみ継続して可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/e2c7491e-ad04-baa5-5133-6e48f1137caf.png)
## インスタンスの可用性
Auroraレプリカは通常のRDSのスタンバイインスタンスとリードレプリカの両方の役割を持ちます。
プライマリのインスタンスに障害が発生すると、Auroraレプリカがプライマリに昇格しフェイルオーバーします。
フェイルオーバーの時間に関しては、多くの場合は**60秒未満**とされています。
Auroraレプリカが複数個ある場合は、以下の優先度に従ってレプリカを昇格させます。

**①指定した優先度が高い(0に近い)リードレプリカ
②優先度が同じ場合はサイズの大きいリードレプリカ
③優先度とサイズが同じ場合は任意のリードレプリカ**

以下の場合だと、優先度1のインスタンスがプライマリに昇格します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/2d5d4120-77e8-dc9f-ae2c-12594109759f.png)

## クラスターキャッシュ管理
クラスターキャッシュ機能を有効にすると、レプリカにキャッシュ情報が同期されるため、フェイルオーバー時のパフォーマンスの影響を最低限に抑えられます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/46d28672-6c27-4a77-a42d-68c4598b57ab.png)

## Auroraグローバルデータベース
通常、Auroraクラスターは単一リージョン内に構築しますが、複数のリージョンにまたがるグローバルデータベースを構築することもできます。
グローバルデータベースに関しては、以下の特徴があります。

**・セカンダリリージョンは、読み込み専用となる。
・リージョン間のデータコピーはAuroraの機能で自動的に実行される。
・リージョン間のデータコピーは通常1秒未満で実行され、リージョン間のフェイルオーバーは通常１分未満で実行される。**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/0ab150a2-2c30-0ef9-8571-639ce548bf2b.png)


## Auroraマルチマスタークラスター
 Auroraマルチマスタークラスターを使用すると、クラスター内のすべての複数のインスタンスは読み書き可能になります。
利用にあたっては、以下の制約があります。

**・MySQLが対象
・インスタンス数は最大2つ
・インスタンスの停止不可
・通常のクラスターより書き込みパフォーマンスが落ちることがある
・バックトラック機能の利用不可**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/a5cdceb3-3298-e48b-adf9-5ee0c7ccb21f.png)

# Auroraパフォーマンス
Auroraのパフォーマンスに関しては、通常RDSと共通する部分が多くあります。
RDSと異なる点について記載していきます。

## ストレージ
Auroraのクラスターボリュームは、データ量に応じて自動的に増加し、**最大128TB**まで増やすことができます。

## Auroraレプリカを使用してパフォーマンス向上
読み込み性能向上も目的で、Auroraレプリカを使用できます。
最大で**15個**作成することができます。

アクセス方法に関しては、以下の2種類が設定可能です。
**①読み込みエンドポイント：読み込みエンドポイントを指定すると、各レプリカに分散したアクセスが可能
②カスタムエンドポイント：特定のインスタンスにアクセス可能**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/875f5e6c-6f0f-e5ea-e69a-c8d5fb4279df.png)

## Aurora Serverless
Aurora Serverlessは、DBインスタンスのサイズ指定不要で、CPUやメモリなどのキャパシティを自動で管理してスケールアップ/ダウンしてくれます。
スケーリングに関しては、Auroraキャパシティユニット(ACU)と呼ばれる単位を増減することにより、自動スケーリングを実施しています。

ユースケースは以下の通りです。
**・利用頻度の少ないアプリケーション
・利用頻度の増減が激しいアプリケーション
・夜間利用しない開発環境**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/9a11c5f4-0e54-ee87-7ae5-9c4886c86d13.png)

# Aurora監査機能
AuroraにはAdvancedAuditingという、監査機能が存在します。
ログのパラメータに関しては以下のものが存在します。

|パラメータ|内容|
|---------|----|
|**CONNECT**|ユーザー情報を含む接続の成功、失敗、切断の記録|
|**QUERY**|すべてのクエリの記録|
|**QUERY_DCL**|QUERYのうちGRANT、REVOKEなどのデータ制御言語に限定した記録|
|**QUERY_DDL**|QUERYのうちCREATE、ALTERなどのデータ定義言語に限定した記録|
|**QUERY_DML**|QUERYのうちINSERT、UPDATEなどのデータ操作言語に限定した記録|
|**TABLE**|クエリ実行の影響をうけたテーブルの記録|

# Auroraバックアップ
Auroraには、自動バックアップ機能があり、このバックアップは設定した保持期間、**継続的かつ増分的**に取得されます。
保持期間に関しては、1~35日で指定でき、S3に保存されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/47632c08-e2db-72c4-8d1f-93601ae94d2f.png)

## Auroraクローン
クローンでは、データストレージのコピーは行われず、インスタンス部分のみが行われるため、高速に同じデータを扱うクラスターを作成できます。
ソースまたはクローン先のクラスターでデータの書き込みがあると、新しいストレージが割り当てられます。よって多くの書き込みがある場合ではこのクローン機能は使用しません。
クローンは、別のAWSアカウント、別のVPCに共有することが可能です。ただし、VPCのサブネットは同じアベイラビリティゾーンである必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/8190ce01-cab7-bc22-498b-7d389be7ce07.png)

## バックトラック
バックトラックは、Auroraの**巻き戻し機能**です。
バックトラックにより以下のような操作が可能になります
**・直前で実行したDELETE処理などの取り消し
・直前の操作前に戻して、その時間でどのようなデータの変更があったかを調べる**

バックトラック機能を有効にするには、ターゲットバックトラックウィンドゥという時間を設定する必要があります。
この時間はデータをどれほど前に戻せるかの時間です。

バックトラックに関しては、以下の制限があります。
**・時間の上限は72時間
・バックトラックはクラスター作成時またはスナップショット復元時に有効にできる
・バックトラック処理中はDBインスタンスがわずかに中断する
・Aurora MySQLでのみ使用可能**

# 障害挿入クエリ
AWSが管理するインスタンスやストレージのに障害は通常利用者が意図的に発生させてテストすることはできません。
このテストを可能にするのが障害挿入クエリです。以下の状況をシミュレートできます。

**・DBインスタンスの障害
・Auroraレプリカの障害
・ディスク障害
・ディスク輻輳**

DBインスタンスの障害を発生させる場合は、次のようなSQL文を実行します。

```
ALTER SYSTEM CRASH [INSTANCE or DISPATCHER or NODE]
#NODEはインスタンス、ディスパッチャーの両方が対象になります。
```

# 最後に
Amazon Auroraについて自分なりにまとめてみました。
Amazon Auroraに関しては、中々触れる機会がないので、今回記事にまとめることによって知識が深まった気がしてます。
今回記載した内容が、今後Auroraを使用する人の参考になればと思います。