AWSデータベースサービスの構成要素について理解する

## はじめに
クラウド環境でシステムを構築する際、ウェブサーバーに続いて重要となるのが、データベースサーバーの構成です。前回の記事「AWSウェブサーバーの構成要素について理解する」では、EC2インスタンスやアプリケーションロードバランサーなど、ウェブサーバーの構成要素について解説しました。

https://qiita.com/ARISA1115/items/590d38210548ae15272e

データベースは、あらゆるアプリケーションの要となる重要なコンポーネントです。今回は、その基盤の上に構築するAmazon RDS、Aurora、DynamoDBなど、AWSのデータベースサーバーの構成要素についてまとめました。これらの要素を適切に選択・設計することで、高可用性があり、スケーラブルで、運用負荷の少ないデータ基盤を構築できるようになります。

:::note warn
**お願い**
実務未経験者がアウトプット学習を目的として執筆しているため、説明やインフラ構成図の設計、リソースの配置等に誤りがある可能性がございます。より正確な理解のためにも、ご指摘・ご助言をいただけますと幸いです🙇‍♀️
:::

## なぜAWSデータベースサーバーを理解する必要があるのか
クラウドでは、データベースを物理サーバーなしで利用するため、RDSやAuroraなどのマネージドサービスが使われます。これらは「目に見えない仮想環境」で動いているため、その特性や設定方法を正しく理解することが重要です。適切なデータベースの選択や構成ができないと、システムの遅延や高額な料金、データ消失といった問題が発生する可能性があります。

AWSのデータベースサーバー構成を正しく理解することで、次のようなメリットが得られます：
- #### 高可用性
    - マルチAZ配置や万が一データベーサーバーに障害が発生しても、別の地域（AZ）に
    ある待機システムが自動的に引き継ぐため、復旧が早い
    - リードレプリカ機能を使えば、メイン（Primary）のデータベースに負担をかけずに
    読み取り処理を分散することが可能
    
- #### 拡張性（スケーラビリティ）
    - リードレプリカやシャーディングなどの手法を活用して、読み取りや書き込みの負荷を分散

- #### 運用管理の自動化
    - バックアップ、メンテナンス、パフォーマンスモニタリングなどが自動化され、
    データベース管理者（DBA）の負担を軽減できる

データベースはアプリケーションの心臓部であり、適切な設計と運用がサービス全体の成否を左右します。AWSデータベースサービスの特性とメリットを理解することで、より強固で効率的なデータ基盤を構築できるようになります。

## AWSデータベースサーバー構成の全体像

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958955/6bb5d315-c20a-44ee-ac8b-16d511a51e66.png)

:::note info
本構成のポイント
- Primary-Secondary RDS構成により、DBの障害発生時も自動フェイルオーバーでサービス継続が可能
    - Primary → Secondary：レプリケーションによるデータの同期
    - Secondary → Primary：ヘルスチェック、同期確認の応答など
- RDSインスタンスをプライベートサブネットに配置し、直接のインターネットアクセスから保護
- 管理者はSSM接続でVPCエンドポイントを経由してEC2にセキュアなアクセスが可能
- EC2とRDS間の通信がVPC内のプライベートネットワークで完結し、データの安全性を確保
:::

このように、AWSではデータベースサーバーをセキュアかつ高可用性のある構成で配置できます。



## 各データベースサーバー構成要素
### Amazon RDS (Relational Database Service)
Amazon RDSは、AWSが提供するクラウド上でデータベースサーバー（DBインスタンス）を構築・管理できるマネージドサービスです。通常、データベースを運用するにはOSのセットアップやデータベースソフトのインストール、バックアップ、セキュリティ対応まで自分で行う必要があります。

RDSはデータベースではなく、**データベースサーバー**です。RDSは、中に保存される情報（＝データベース）ではなく、データベースを動かすためのコンピュータ（サーバー）とソフトウェアを提供するサービスです。

RDSで利用できる主なデータベースエンジンには6種類あり、以下の通りです：

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958955/3c15cb4a-bc11-4e90-9166-9debba1c51da.png)


これらのエンジンは各データベースエンジンが持つ標準機能やSQL構文をそのまま利用できるため、既存のアプリケーションをクラウドに移行する際の互換性の問題が少なくなります。

:::note warn
**Amazon Auroraについて**
Auroraも、RDSで利用できるエンジンの一つですが、独自設計と高性能な特徴を持っています。そのため、このあとの「Amazon Aurora」の項目でまとめています。
:::

### Amazon Aurora
Amazon Auroraは、AWSが提供する高性能なリレーショナルデータベースエンジンです。MySQLやPostgreSQLと互換性があるため、既存のアプリケーションやSQL構文をほぼそのまま利用できます。

#### 特徴
1. **高性能**
- データベースへのクエリ応答速度が非常に速く、同じ時間内に処理できるデータ量は、MySQLの最大5倍、PostgreSQLの最大3倍に達する
- データは3つのAZに跨る6つのストレージノードに分散保存されており、並列処理による高速化が可能
- 計算処理を行うDBインスタンスと、データを保存するストレージ層を分離して管理できるため、必要に応じて個別にスケーリングでき、全体の処理性能が向上する
- I/O処理は非同期かつ最適化されており、ディスクアクセスの待ち時間が大幅に削減可能

2\. **クラスター構成**
- 書き込み専用の主サーバー1台と読み取り専用の副サーバーの最大15台で構成される
- 検索などの読み取り処理を複数の副サーバーに分散させて負荷を軽減
- エンドポイント管理により、常に最適なサーバーにアクセスが可能

3\. **高可用性**
- サーバーに障害が発生した場合でも自動的にフェイルオーバーし、
サービスの稼働を継続する
- 1年中ほとんど止まらず、常に使い続けられるように設計されており、
可用性が99.99%（いわゆる“フォーナイン”）を実現
＝1年間に約52分しか停止しないレベル

4\. **自動スケーリング**
- 負荷に応じて自動的にスケールアップ・スケールダウン
- ストレージは最大128TBまで自動拡張できる
- Aurora Serverlessオプションで完全な自動スケーリングも可能

Auroraは一般的なRDS MySQLやPostgreSQLよりコストは高いものの、性能、可用性、運用の自動化を考慮すると、大規模サービスや企業向けアプリケーションに適したデータベースサービスとなっています。特に高いトランザクション処理能力と読み取りスケーリングが必要なワークロードに最適です。

### Amazon DynamoDB
Amazon DynamoDBはAWSが提供するサーバーレスNoSQLデータベースサービスです。
「**スキーマレス**」という特徴を持っており、データの形に決まりがないため、柔軟に情報を保存できます。イメージとしては、必要なときに自動で棚が広がっていくようなデータベースです。

### Amazon ElastiCache
Amazon ElastiCacheは、インメモリキャッシュを提供するサービスで、読み込みパフォーマンスを大きく向上させたい場合に有効です。

以下、2種類のエンジンに対応しています：

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3958955/db7d2ffd-4c66-499a-8bfc-2f5ae11c2451.png)

## まとめ
AWSには、用途に応じて選べる多様なデータベースサービスが用意されています。
各サービスの特徴を正しく理解し、最適な構成を選ぶことで、高可用性かつ
スケーラブルなデータ基盤を実現できます。

https://docs.aws.amazon.com/rds/

https://aws.amazon.com/jp/rds/mariadb/

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html

https://aws.amazon.com/jp/rds/features/read-replicas/

https://aws.amazon.com/jp/dynamodb/

https://aws.amazon.com/jp/elasticache/

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.htmlｇ

https://xn--o9j8h1c9hb5756dt0ua226amc1a.com/?p=3404

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-18_AWS_Summit_Online_2020_DAT01.pdf

https://classmethod.jp/articles/aws-db/

https://qiita.com/Mr_Kim/items/d50977dc7af01c5d0ebb

https://business.ntt-east.co.jp/content/cloudsolution/ih_column-76.html

https://www.ashisuto.co.jp/db_blog/article/amazon-rds.html

https://www.sbbit.jp/article/cont1/95514

https://blog.father.gedow.net/2015/11/05/amazon-aurora-benchmark/

https://kinsta.com/jp/blog/memcached-vs-redis/#:~:text=%E5%8B%A7%E3%82%81%E3%81%97%E3%81%BE%E3%81%99%E3%80%82-,Memcached%E3%81%A8%E3%81%AF,%E5%8F%AF%E8%83%BD%E3%81%AB%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%A7%E3%81%99%E3%80%82