- 03-5820-1777平日10:00〜18:00
- お問い合わせ
コラム
[AWS]RDS概要(AWSでリレーショナルDBの使用)
はじめに
AWSでRDBを使用する方法は3通りあります、１つはEC2を立上げデータベースソフトウェアをインストールする方法、もう1つはECSを使用してコンテナ上にDBをインストールする方法、もう１つがAWSが提供するRDSというサービスを使用してサーバレスで運用する方法です。
今回はRDSの概要をまとめて行こうと思います。
RDSとは
RDSとはAWSが提供する様々なデータベースソフトウェアに対応したフルマネージメント型のリレーショナルデータベースです。
データベースソフトウェアをインストールや管理する必要がなく、サーバレスのサービスとして提供してくれます。
冗長構成などを簡単に実現する機能、バックアップをスケジュールして実行してくれる機能等もあるので、非常に便利なサービスだと思います。
対応しているデータベースのソフトウェアは以下のものがあります。
- MySql
- Oracle
- Microsoft SQL Server
- PostgreSql
- MariaDB
- Amazon Aurora
RDSの制約
- バージョンが限定されている
- 最新バージョンが直ぐに使用できない
- サーバOSにアクセスできない
- サーバはAWS側で管理しているので、使用者はOSにアクセスできない
- 容量に上限がある
- AWS上で上限が定められているが通常のシステムでは問題ない
- IPアドレスが固定できない
- IPアドレスでのアクセスではなく、ドメイン指定でのアクセスになる
- 機能の一部が使用できない
- DBによっては全ての機能を使用できない可能性がある
- パッチは適用できない
- パッチ適用はAWS側でするので、使用者側ではできない
上記の様な制約がある為、構築・運用が容易（大部分がAWS側）というメリットがある反面、AWS提供の範囲内での利用制限があるというデメリットも存在します。
しかし、後の項に示すようにRDSを使用しない時には環境構築が大変だったものが容易に実現出来ます。
RDSのAWS内の環境
RDSはVPC、AZ、サブネットを指定してその内部に作成されます。
AZやサブネットが複数選択されている場合は、そのいずれかに作成されます。
マスター・スレイブ構成
RDSはマネージド型なので高可用性に優れていますが、さらにマルチAZによってRDSを2つ作成し同期レプリケーションし、マスターが停止した場合、自動的にスレイブのDBに切り替えるフェイルオーバーを実現するマスター・スレイブ構成を構築し、さらに高可用性に優れたシステムにする事も容易に出来ます。
リードレプリカ
RDSは読み取り専用DBのリードレプリカを設置する事が出来ます。
Auroraは最大15台、その他のDBは最大５台まで増やす事が可能です。
マスターDBからリードレプリカへのレプリケーションは非同期で行います。
この機能により読取り処理のアクセス集中を防ぐ為、リードレプリカを増設し負荷分散をします。
クロスリージョンレプリケーション
複数のリージョンにまたがって RDS を建てる仕組みのことです。
異なるリージョンにリードレプリカを作成し、負荷分散しつつマスターがダウンした時はリードレプリカをマスターに昇格させる事が可能です。
これは、マスターがあるリージョンやAZに障害が起こった時に有効です。
しかしクロスリージョンをするには幾つか制約があるみたいです。
- 転送時間遅延
- Oracle、Microsoft SQL Serverは対応してない
- 料金が高くなる
- マスター・スレイブ構成が出来ない
など（他にもあるかも）
スナップショット
現在のDBをスナップショットとして保管する事が出来ます。
スナップショットはAWS上で管理され、復元をする事が出来ます。
手動で取得と自動バックアップでの取得の2通りの方法があります。
自動バックアップ
自動バックアップは、定期的な間隔でDBのバックアップを取る機能です、
バックアップ機能はスケジュールした間隔でDBのスナップショットを取る機能と、トランザクションログを取る機能があり、スナップショットとトランザクションログを組み合わせて、最新で直近5分前のDBに戻す事が出来ます。
暗号化
暗号化対象
- データベースインスタンス
- リードレプリカ
- スナップショット
- 自動バックアップ
暗号化方式
- AES-256 暗号化
- AWS KMSなど
スケーリング
RDSはDB作成後もスケーリングを調整しパフォーマンスを向上させる事が可能です。
パフォーマンスを向上させるには、DBインスタンスのサーバのメモリ・CPUを増強する方法と、処理機器・サーバ台数の増強する方法の2つが存在します。
DBインスタンスのサーバのメモリ・CPUを増強
・設定可能項目
| 設定可能項目 | 説明 |
|---|---|
| インスタンスタイプ | インスタンスの得意分野を決定する |
| インスタンスサイズ | インスタンスのCPU、メモリの性能を決定する |
| ストレージタイプ | ストレージのタイプ(SSD又はHDD)、IOPSなどを決定する。 |
| ストレージサイズ | ストレージの容量を決定する。 |
・インスタンスタイプ例
| タイプ | カテゴリ | 説明 |
|---|---|---|
| T2 | 汎用 | ベースラインレベルの CPU パフォーマンスを提供し、 ベースラインを超えてバーストする機能を備えています。 マイクロサービス、テストおよびステージングデータベース など、さまざまなデータベースワークロードに適しています。 |
| T3 | 汎用 | ベースラインレベルの CPU パフォーマンスを提供する 次世代のバースト可能な汎用インスタンスタイプで、 いつでも必要な時間だけ CPU 使用率をバーストさせる 機能を備えています。 T3 インスタンスはバランスの取れたコンピューティング、 メモリ、およびネットワークのリソースを提供し、 使用中に一時的なスパイクが生じる中程度の CPU 使用率 を持つデータベースワークロード向けに設計されています。 |
| R4 | メモリ最適化 | メモリ負荷の高いデータベースワークロード向けに最適化 されており、RAM GiB あたりのメモリ価格が R3 よりも安価です。 |
・インスタンスサイズ例
インスタンスサイズはインスタンスタイプ毎に値が変わります。インスタンスタイプに対する指定可能なサイズの例を以下に示します。
T2 インスタンス
| モデル | コアカウント | vCPU* | CPU クレジット/時間 | メモリ (GiB) | ネットワークパフォーマンス (Gbps) |
| db.t2.micro | 1 | 1 | 6 | 1 | 低～中 |
| db.t2.small | 1 | 1 | 12 | 2 | 低～中 |
| db.t2.medium | 2 | 2 | 24 | 4 | 低～中 |
| db.t2.large | 2 | 2 | 36 | 8 | 低～中 |
| db.t2.xlarge | 4 | 4 | 54 | 16 | 中 |
| db.t2.2xlarge | 8 | 8 | 81 | 32 | 中 |
T3 インスタンス
| モデル | コアカウント | vCPU* | CPU クレジット/時間 | メモリ (GiB) | ネットワークパフォーマンス (Gbps) |
| db.t3.micro | 1 | 2 | 12 | 1 | 最大 5 |
| db.t3.small | 1 | 2 | 24 | 2 | 最大 5 |
| db.t3.medium | 1 | 2 | 24 | 4 | 最大 5 |
| db.t3.large | 1 | 2 | 36 | 8 | 最大 5 |
| db.t3.xlarge | 2 | 4 | 96 | 16 | 最大 5 |
| db.t3.2xlarge | 4 | 8 | 192 | 32 | 最大 5 |
R4インスタンス
| モデル | コアカウント | vCPU | メモリ (GiB) | ストレージ | ネットワーキングパフォーマンス (Gbps) |
| db.r4.large | 1 | 2 | 15.25 | EBS のみ | 最大 10 |
| db.r4.xlarge | 2 | 4 | 30.5 | EBS のみ | 最大 10 |
| db.r4.2xlarge | 4 | 8 | 61 | EBS のみ | 最大 10 |
| db.r4.4xlarge | 8 | 16 | 122 | EBS のみ | 最大 10 |
| db.r4.8xlarge | 16 | 32 | 244 | EBS のみ | 10 |
| db.r4.16xlarge | 32 | 64 | 488 | EBS のみ | 25 |
詳細はhttps://aws.amazon.com/jp/rds/instance-types/を参照
処理機器・サーバ台数の増強
・リードレプリカの増設
読取り処理のアクセス集中を防ぐ為、リードレプリカを増設し負荷分散をします。
- Auroraは最大15台、その他のDBは最大５台まで増やす事が可能
- マルチAZやクロスリージョンの設定可能
- インスタンスタイプやストレージタイプを異なるものに設定可能
複数リージョンに跨ぐ構成
・キャッシュ機能の利用
キャッシュサービスを利用してメモリ上からデータ取得をする事によりDBへの負荷を軽減する事が出来ます。
登録する際も即時性が高くないデータはキャッシュに保管しておいて、順次登録する機能を作成して負荷を軽減する事も出来ます。
キャッシュサービスは主に以下のものを利用します。
| 機能名 | 説明 |
|---|---|
| ElastiCache | クエリ処理結果をインメモリDBに保持して高速処理を可能にするAWSサービス。 |
| Memcached | MYSQLのオプション機能にあるMemcachedを利用 してインメモリキャッシュを利用する。 |
ElastiCacheの使用例（データ取得）
ElastiCacheの使用例（データ登録） 登録時の負荷を軽減したい場合など
・Amazon Auroraへの移行
MySQL又はPostgreを高性能なAuroraへと移行することで、パフォーマンスを向上させることが可能です。
Auroraは高い並列処理でクエリ実行を高速化する事が可能で、リードレプリカを最大15台作成する事が可能です。
正し、移行するには互換性があるバージョンである必要があります。
最後に
RDSの概要をまとめてみましたが、RDSの利点は様々はデータベースを使用でき、複雑な構成を簡単に構築でき、状況に応じてスケーリングをする事も出来るのが非常に便利なサービスだと思いました。
通常のシステムであれば使用するメリットは大きいと思いますが、料金との兼ね合で採用するかの判断が必要ですね。
料金については、他の記事でモデルケース毎の料金をシミュレートしてみたいと思います。
続けてお読みください
この記事をシェアする
お電話でのお問い合わせ
03-5820-1777（平日10:00〜18:00）