この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
サービスを運用していると、利用者ベースの増加や突発的なアクセス急増に伴い、データベースがボトルネックになって、サービスを提供できないことがありますよね。
アプリにはアプリ固有のスケール方法があるように、データベースにもデータベース固有のスケール方法があります。
AWSのRDBMSである Amazon Auroraを利用している場合に、どういったユースケースでどのようにスケールさせればよいのか、ざっくりとまとめてみました。
内容としては、次のAWS Black Beltのセミナーをベースに、最近のアップデートや個人的な好みを織り交ぜています。
20200929 AWS Black Belt Online Seminar Amazon Aurora MySQL Compatible Edition ユースケース毎のスケーリング手法 from Amazon Web Services Japan
スケールするシステムとは?
理想的なスケールするシステムは、利用負荷の増加に対して安定したレスポンスタイムで負荷に比例したスループットをシステムがでせるようにすることです。 とはいえ、一般的なシステムでは、どこかで性能が頭打ちになり、更に負荷がかかると、性能が劣化します。
システムをスケールさせることで、この閾値をより後ろにずらすことを目指します。
ステートレスに作られたアプリケーションはスケールアウトさせやすいのに対し、 ステートフルなデータベースはスケールさせにくいです。
AWSのようなクラウドを利用すれば、コンピューティングリソースの調達は可能です。 スケールするためのアーキテクチャーの設計の重要性が増しています。
2つのスケール戦略:スケールアップとスケールアウト
スケール手法は
- インスタンスのスペックを上げる垂直方向のスケールアップ
- インスタンス数を増やす水平方向のスケールアウト
の2種類があります。
スケールアップ(垂直方向)
- インスタンス単体のスケーリング
- インスタンスの性能(タイプ)を変更
- インフラ面では構成に変更がない
- アプリケーション面では透過な変更
スケールアウト(水平方向)
- データベース全体のスケーリング
- インスタンス数を増加
- リードレプリカ
- DB分割(シャーディング)
スケーリング検討のステップ
以下の流れでスケーリングさせます。
- ボトルネックを特定
- データベースのチューニング(インデックス、パラメーター、など)
- スケール方法の検討
まずは性能評価を行い、解決すべきボトルネック(課題)がどこにあるのか洗い出しましょう。
チューニング、スケーリング結果を評価する上でも、非常に大事です。
データベースのチューニング
データベースのチューニングでは、DBエンジン固有の方法の他、AWSのサービスのサービスも活用してください。
- インデックス
- クエリの書き換え
- パラメーター
- Amazon RDS Performance Insights : パフォーマンスのチューニングとモニタリングを行う機能
- Amazon DevOps Guru for RDS : ML を使用してパフォーマンス関連の問題を検出、診断、解決
シンプルな構成から始める
まずはプライマリ・レプリカがそれぞれ1台のシンプルなマルチAZ構成から始めましょう。
read/writeのリクエストはすべてプライマリ・インスタンスに流れ、レプリカ・インスタンスはフェイルオーバー先としてのみ存在します。
最初からあれこれ作り込まないようにしましょう。
スケーリング方法
本記事では、比較的導入しやすい以下のスケール方法を紹介します。
- 読み込み
- 書き込み
スケール手法を整理
| スケール手法 | 参照 | 更新 | アプリ影響 | インフラ影響 |
|---|---|---|---|---|
| インスタンスタイプ変更 | ○ | ○ | 透過 | 構成変更無し |
| リードレプリカの利用(アプリ改修) | ○ | アプリ改修 | レプリカをオートスケール対応 | |
| リードレプリカの利用(プロキシ導入) | ○ | 透過 | レプリカをオートスケール対応 プロキシの運用が必要 |
|
| キャッシュレイヤの導入 | ○ | アプリ改修 | キャッシュDBの運用が必要 |
インスタンスタイプを変更するスケールアウトは、簡単に実施できます。ただし、インスタンスタイプには上限があります。
参照のスケールアウトにおいては、アプリケーションを巻き込めるかによって、選択肢が大きく変わります。
順に確認します。
1. 読み込みパフォーマンスのスケーリング
Web系システムでは、相対的に参照の割合が多くを占めるケースが多々あります。
リードスループットが足りない場合は以下を検討しましょう。
- スケールアップ
- 参照系クエリの負荷分散をするために
- リードレプリカの利用
- キャッシュレイヤの利用
1-a. スケールアップ
- インスタンスタイプをスケールアップ
- フェイルオーバー時に備え、プライマリ・レプリカでインスタンスタイプを揃えましょう
1-ｂ. リードレプリカの利用
- リードレプリカへの参照系クエリのオフロード
- Amazon Aurora Auto Scaling
- 負荷に応じてレプリカをスケールアウト
- EC2 ASGと同じく、スケールするまでタイムラグが発生
- 予測可能なイベントに対しては、事前にスケールアウト
- レプリカラグ
- プライマリ・レプリカ間でレプリカラグが発生
- Auroraは共有ストレージへの物理レプリケーション。共有ストレージのページキャッシュの更新のために、小さなラグが発生
- 更新のかかりやすいページはプライマリから参照
- 参照・更新でエンドポイントを切り替える
- DB接続元が更新・参照に応じてエンドポイントをクラスターエンドポイント・リーダーエンドポイントに振り分ける
- アプリケーションの改修、または、プロキシを導入
Amazon Auroraは更新・参照それぞれのエンドポイントを払い出してくれますが、クエリに応じてエンドポイントを振り分けるのはユーザーの責務です。
アプリケーションを改修して振り分ける場合
プロキシを導入して振り分ける場合
参照・更新クエリを振り分けるプロキシとして
- MySQLなら MariaDB MaxScale や ProxySQL
- PostgreSQL なら pgpool-II
などがあります。
1-c. キャッシュレイヤの導入
- インメモリデータベース(Redis/Memcached)への参照系クエリのオフロード
- 生存期間が長く、頻繁に利用される冪等なデータの参照に最適
- 頻繁に更新されるデータの参照やSQLクエリの場合はレプリカを検討
- 参照・更新でデータストア(Aurora/キャッシュ)を切り替える
- アプリケーションの改修
先の参照・更新の振り分けと同じく、Auroraとキャッシュを振り分けるのはユーザーの責務です。
Redisを導入し、さらに更新・参照でAuroraのエンドポイントを切り替えるとなると、シンプル構成に比べてアプリケーションは随分と複雑になりました。
2. 書き込みパフォーマンスのスケーリング
ゲームや業務系システムでは、大量の書き込みが発生します。 ライトスループットが足りない場合は以下を検討しましょう。
- スケールアップ
- データベース分割
2-a. スケールアップ
- インスタンスタイプをスケールアップ
- フェイルオーバー時に備え、プライマリ・レプリカでインスタンスタイプを揃えましょう
2-b. データベース分割
- データベース分割
- ゲーム・SaaS(テナント)で採用が多い
- シャーディング(水平分割)
- データが偏らないようにし("noisy neighbor"含む)、偏った場合の再分散(リシャード)のコストが低くなるようシャーディング法を検討
- ユーザーとシャードのマッピングをどこかで管理
注意:Aurora Multi Masterはスケールアウトに使えない
- Aurora Multi Masterは複数のインスタンスが書き込み可能
- 書き込みの可用性を継続させるもの
- 書き込みのスループットを上げるものではない
Aurora Serverless v2 でスケール手法が変わるかも?
約1年前から、キャパシティがオートスケールする Aurora Serverless v2 がプレビュー提供されています。
v2はシームレスなスケールアップやスパイクにも強いミリ秒のオートスケールなど、v1からは飛躍的に性能・機能が向上しています。 さらには、負荷に応じてキャパシティがオートスケールするおかげで、書き込みの上限に合わせてサイジングしなくて済み、コストを削減できます。
Aurora Serverless v2 が GA になると、Amazon Auroraのスケール手法が大きく変わるかもしれません。
プレビュー申請して検証環境で評価し、フィードバックしましょう。
Amazon Aurora Serverless v2をプレビュー申請する
システムに最適なデータベースは?
システムにより、最適なデータベースは異なります。
今回は RDBMS の Amazon Aurora(MySQL/PostgreSQL)を前提にしましたが、 本当にほしいのはRDBMSではなく
- KVS(Amazon DynamoDB)
- 分析集計・DWH(Amazon Redshift)
- グラフデータベース(Amazon Neptune)
だったりするかもしれません。
用途に合わせたデータベースを選択しているか、ご確認ください。
大前提がずれていると、最適化の努力も水の泡です。
最後に
Amazon Aurora をスケールさせるアプローチをまとめました。
基本に忠実に、シンプルな構成を心がけ、オーバーエンジニアリングは避けましょう。
また、本記事のもとになったAWS Black Beltでは、今回紹介しきれなかった様々なスケール手法も解説されているので、ぜひご視聴ください。
それでは。
2
