Scaling Your Amazon RDS Instance Vertically and Horizontally

Marie Yap はアマゾン ウェブ サービスのソリューションアーキテクトです。

Amazon RDSは､マネージド型サービスとして、リレーショナルデータベースのスケーリングを処理し、データベースがアプリケーションやアプリケーションの増加する要求に対応できるようにします。

このブログ記事では、RDS インスタンスを縦横に拡大縮小する方法について説明します。ほぼ同じ数の読み取りと書き込みを使用するアプリケーションの増加する要求に対応するために、垂直方向に拡大縮小することができます。また、読み取りが重いアプリケーションの場合は、水平方向に拡大縮小することもできます。

垂直スケーリング
データベースの高い負荷を処理するために、ボタンを押すだけでマスターデータベースを垂直方向にスケールアップできます。現在、RDS MySQL、PostgreSQL、MariaDB、Oracle、または Microsoft SQL Server インスタンスのサイズを変更する際に、18 種類以上のインスタンスサイズを選択できます。Amazon Aurora では、5 つのメモリ最適化インスタンスサイズを選択できます。インスタンスタイプを幅広く選択することで、データベースサーバーに最適なリソースとコストを選択できます。

以下は、RDS インスタンスをスケールアップする際の考慮事項です。

• スケールを変更する前に、商用エンジン (SQL Server、Oracle) の正しいライセンスを取得していることを確認してください (特に、ライセンス持ち込み (BYOL) が必要な場合)。重要なことは、商用エンジンの場合はライセンスによって制限されていることです。ライセンスは、通常 CPU ソケットまたはコアに関連付けられています。
• 変更をいつ適用するかを決めます。変更をすぐに適用するか、インスタンスで指定されたメンテナンス期間中に変更を適用するかを選択できます。
• ストレージとインスタンスのタイプは切り離されています。データベースインスタンスを上下にスケールしたときは、ストレージサイズは同じままで、変更の影響を受けません。DB インスタンスを個別に変更して、割り当てられたストレージスペースを増やすか、ストレージタイプを変更して (一般目的 SSD からプロビジョニング IOPS SSD などに) パフォーマンスを向上させることができます。
• スタンバイデータベースが最初にアップグレードされた後で、新しくサイズの変更されたデータベースでフェイルオーバーが発生するため、Multi-AZ 環境でスケールアップする場合のダウンタイムは最小限に抑えられます。シングル AZ インスタンスは、スケール操作中は使用できません。

インスタンスのタイプを変更するには、RDS コンソールの [インスタンスの操作] メニューから [変更] を選択します。

次に、新しい DB インスタンスクラスを選択します。

最後に、変更をすぐに適用するかどうかを決定します。変更をすぐに適用するには、[変更] ページの一番下にある [すぐに適用] チェックボックスを選択します｡変更をすぐに適用しないと、定義した優先メンテナンスウィンドウ中に変更がスケジュールされます。

水平スケーリング
マスターデータベースを垂直方向に拡張するだけでなく、読み取りレプリカを使用してデータベースを水平方向に拡大することによって、読み取りが重いデータベースのパフォーマンスを向上させることもできます。RDS MySQL、PostgreSQL、MariaDB には最大 5 つのリードレプリカがあり、Amazon Aurora には最大 15 のリードレプリカがあります。

リードレプリカを使用すると、マスターデータベースと同期する読み取り専用コピーを作成できます。より良いパフォーマンスを得るために、リードレプリカをユーザーにより近い別の AWS Region に配置することもできます。また、リードレプリカをマスターに昇格させることで、リードレプリカを使用してデータベースの可用性を高め、災害時の迅速なリカバリーを行うことができます。ただし、リードレプリカは、Multi-AZ が提供する高可用性と自動フェイルオーバー機能の代替となるものではありません。

現在、RDS リードレプリカは、クエリまたは接続の透過的なロードバランシングをサポートしています。各レプリカには固有のドメインネームサービス (DNS) エンドポイントがあり、アプリケーションはレプリカエンドポイントに接続してロードバランシングを実装できます。では､アプリケーションで RDS リードレプリカを認識させる方法のオプションを見てみましょう。

アプリケーションがネイティブの MySQL ドライバを使用している場合は、アプリケーションに大きな変更を加えることなく、読み取り/書き込み分割と読み取り専用のエンドポイントロードバランシングを実行できる MySQL Connector があります。たとえば、PHP アプリケーションをお持ちの場合は、MySQL ネイティブドライバの PHP Mysqlnd レプリケーションとロードバランシングプラグインを使用できます。

MySQL Connector を使用することに加えて、アプリケーションとデータベースサーバの間にロードバランサを追加することができます。アプリケーションに単一のデータベースエンドポイントが表示されるように､この追加を行います｡このアプローチでは、アプリケーションのデータベース接続文字列を絶えず更新することなく、ロードバランサの背後にあるリードレプリカを透過的に追加または削除できるより動的な環境が可能になります。また、スクリプトを使用してカスタムヘルスチェックを実行することもできます。

図に示すように、トランスポートまたはレイヤ 4 ロードバランサを MySQL Connector とともに使用できます。現在、Elastic Load Balancing (ELB) ロードバランサは、RDS インスタンスへのトラフィックのルーティングをサポートしていません。したがって、多くの人が使用するオープンソースのソフトウェアベースのロードバランサである HAProxy などのオプションを検討することもできます。このソリューションでは、1 つのポートで読み込みクエリを受信し、もう 1 つのポートで書き込みクエリを受信するように HAProxy を構成できます。

もう 1 つの選択肢は、レイヤ 7 の SQL 対応ロードバランサを使用することです。複雑なルールを使用してデータベースにクエリを転送することができます。このタイプのロードバランサは、マルチステートメントで読み書きスプリットを適切に実行する方法を理解する､MySQL Connector よりも洗練された機能を備えています。このソリューションは、分散データベース環境でスケーリングの問題を処理するため、アプリケーション層のスケーリングを処理する必要がないため、アプリケーション自体にはほとんど変更が加えられません。これを実現するには、MaxScale、ProxySQL、MySQL Proxy などのオープンソースソリューションと商用ソリューションがあります。そのうちのいくつかは AWS Marketplace にあります｡

まとめ
要約すると、アプリケーションの増加するニーズに対応するために、RDS 構成を拡張または縮小することができます。RDS はデータベースのスケーリングに大いに役立つため、お客様はアプリケーションやアプリケーションにより集中できるようになります｡