RDS の負荷が高い場合に AWS で取りうる具体策 N 連発 emi クラウド事業本部 コンサルティング部 

自己紹介 2 ⚫ 最近やっていた・いること ⚫ Terraform を用いた AWS リソース構築支援 ⚫ AWS Control Tower を用いたマルチアカウント環境での AWS Security Hub、Amazon GuardDuty 展開 ⚫ AWS リソース負荷軽減、構成検討 ⚫ コスト最適化アセスメント ⚫ Amazon QuickSight や Amazon Athena を利用した データ分析・可視化 ● 名前（ニックネーム） ○ 木谷 映見（emi） ● 部署 ○ クラスメソッド株式会社 ○ クラウド事業本部コンサルティング部 ● 趣味 ○ コーヒー、ドーナツ、サウナ、 ホットヨガ、漫画、音楽など AWS Certified Cloud Practitioner バ ッ ジ AWS Certified AI Practitioner バ ッ ジ AWS Certified Solutions Architect - Professional バ ッ ジ AWS Certified DevOps Engineer - Professional バ ッ ジ AWS Certified Advanced Networking - Specialty バ ッ ジ AWS Certified Machine Learning - Specialty AWS Certified Security - Specialty バ ッ ジ AWS Certified SysOps Administrator - Associate バ ッ ジ AWS Certified Developer - Associate バ ッ ジ AWS Certified Solutions Architect - Associate バ ッ ジ AWS Certified Data Engineer - Associate バ ッ ジ AWS Certified Machine Learning Engineer - Associate バ ッ ジ AWS Certified Cloud Practitioner バ ッ ジ AWS Certified AI Practitioner バ ッ ジ AWS Certified Solutions Architect - Professional バ ッ ジ AWS Certified DevOps Engineer - Professional バ ッ ジ AWS Certified Advanced Networking - Specialty バ ッ ジ AWS Certified Machine Learning - Specialty AWS Certified Security - Specialty バ ッ ジ AWS Certified SysOps Administrator - Associate バ ッ ジ AWS Certified Developer - Associate バ ッ ジ AWS Certified Solutions Architect - Associate バ ッ ジ AWS Certified Data Engineer - Associate バ ッ ジ AWS Certified Machine Learning Engineer - Associate バ ッ ジ 最近はカフェインを控えています 

目次 3 • 諸注意 • RDS の負荷の見方 • ケース 1：恒常的な過負荷 • CPU・メモリ負荷が高い • 読み込み負荷が高い • 書き込み負荷が高い • I/O 負荷が高い • データ構造・運用見直し • ケース 2：突発的なスパイク • ロックの多発 • スロットリング • オートスケーリング • 両方のケースに有効 

諸注意 

諸注意 5 • 便宜上ケースごとに記載していますが、実際には「読み込み負荷にも 書き込み負荷にも効果がある」など、複数のケースに有効な方法もあ ります。 • 設定手順までは解説していませんが、「負荷が高いな？」と思ったと きに思い出してもらえるようなヒントになれば嬉しいです。 がついているのは 対応したことがあるものや 検討の土俵でかなりいい線 までいったものです 

RDS の負荷の見方 

RDS の負荷の見方 7 • CloudWatch Database Insights を確認 こんな感じの待機の棒グラフが出る どの SQL 文でどれくらい待機が 発生しているか出る [登壇レポート] JAWS-UG朝会 #74 「Performance Insights 廃止から Database Insights 利用へ」という内容で登壇してきました #jawsug #jawsug_asa | DevelopersIO https://dev.classmethod.jp/articles/transition-from-performance-insights-to-database-insights/ Performance Insights から Database Insights への移行ガイド：どのモードを選ぶべきか？ | DevelopersIO https://dev.classmethod.jp/articles/performance-insights-to-database-insights/ RDS Performance Insights が 2025 年 11 月 30 日に CloudWatch Database Insights へ統合されるみたいです | DevelopersIO https://dev.classmethod.jp/articles/eol-performance-insights/ 

RDS の負荷の見方 • CloudWatch Database Insights を確認 CloudWatch メトリクスも見える 詳細なメトリクスは 「すべてのメトリクス」 もしくは RDS コンソールで該当のインスタン スの詳細を開き「モニタリング」タブ より確認可能 [登壇レポート] JAWS-UG朝会 #74 「Performance Insights 廃止から Database Insights 利用へ」という内容で登壇してきました #jawsug #jawsug_asa | DevelopersIO https://dev.classmethod.jp/articles/transition-from-performance-insights-to-database-insights/ Performance Insights から Database Insights への移行ガイド：どのモードを選ぶべきか？ | DevelopersIO https://dev.classmethod.jp/articles/performance-insights-to-database-insights/ RDS Performance Insights が 2025 年 11 月 30 日に CloudWatch Database Insights へ統合されるみたいです | DevelopersIO https://dev.classmethod.jp/articles/eol-performance-insights/ 

ケース 1：恒常的な過負荷 9 • 諸注意 • RDS の負荷の見方 • ケース 1：恒常的な過負荷 • CPU・メモリ負荷が高い • 読み込み負荷が高い • 書き込み負荷が高い • I/O 負荷が高い • データ構造・運用見直し • ケース 2：突発的なスパイク • ロックの多発 • スロットリング • オートスケーリング • 両方のケースに有効 

ケース 1：恒常的な過負荷 CPU・メモリ負荷が高い 

ケース 1：恒常的な過負荷：CPU・メモリ負荷が高い 11 対策 改善方法 コスト増 改修規模 補足 インスタンスタ イプの変更 スペックが高い インスタンスタ イプに変更する ことで負荷を改 善 中～大 インスタンスタ イプを上げるた めコスト増 小 アプリケーショ ン改修不要 CPU 性能が高い Graviton ベース インスタンスへ 移行することも 効果が期待でき る。コスト削減 にもなる。 ネットワーク負 荷が高い場合も 効果がある。 Amazon Aurora をプライマリとレプリカのインスタンスタイプが異なる構成で運用できますか | DevelopersIO https://dev.classmethod.jp/articles/tsnote-amazon-aurora-instance-types-01/ 

ケース 1：恒常的な過負荷 読み込み負荷が高い 

ケース 1：恒常的な過負荷：読み込み負荷が高い 13 対策 改善方法 コスト増 改修規模 補足 リードレプリカ 追加によるスケ ールアウト リードレプリカ で読み込み負荷 を分散。リード レプリカに負荷 がかかってもプ ライマリ DB での 書き込み処理に 影響はない。 中～大 リードレプリカ のインスタンス タイプが大きい ほどコスト増。 リードレプリカ の台数が増える ほどコスト増。 中 Select など読み込 みクエリをリー ドレプリカに流 す処理はアプリ ケーション側で 開発する必要が ある。 RDS で複数のリード レプリカを作成する とリーダーエンドポ イントが複数できる ため分散の仕組みを 検討する必要がある。 Aurora であれば 1 つ のリーダーエンドポ イントが自動で複数 台のリードレプリカ にアクセスを分散で きる。 レプリカラグがわず かに発生する場合が ある。データのレプ リケーションにわず かに負荷がかかる場 合がある。 Amazon Aurora をプライマリとレプリカのインスタンスタイプが異なる構成で運用できますか | DevelopersIO https://dev.classmethod.jp/articles/tsnote-amazon-aurora-instance-types-01/ 

ケース 1：恒常的な過負荷：読み込み負荷が高い 14 • マルチ AZ 構成の見直し • AZ を跨ぐとわずかに負荷がかかる。AZ を跨ぐ可能性がある場合は負荷試験を行 いシステムのパフォーマンスに影響があるか計測する • 水平スケーリングする場合、リードレプリカを複数作成する、マルチ AZ クラスタ ー構成を取るなどの選択肢がある • リードレプリカを複数台作成する場合エンドポイントが複数存在する 状態になるため、アプリケーション側でクエリをルーティングするよ うロジックを組む必要がある • クエリルーティングをするための 3rd Party 製品を導入する手もある 

ケース 1：恒常的な過負荷：読み込み負荷が高い 15 対策 改善方法 コスト増 改修規模 補足 Aurora レプリカ での Auto Scaling Aurora Auto Scaling ポリシー を設定し、読み 込み負荷の増加 に応じて自動的 にリードレプリ カを追加。負荷 が下がると自動 削除。 中～大 リードレプリカ 追加分のコスト が発生 中～大 Aurora 以外のエ ンジンの場合、 移行が必要 瞬間的なスパイ ク対応には不向 きだが、アクセ ス数が徐々に増 加する恒常的な 読み込み負荷に 有効。 レプリカをオートスケールさせるAmazon Aurora Auto Scalingの導入ポイントをまとめてみた | DevelopersIO https://dev.classmethod.jp/articles/how-to-configure-amazon-aurora-auto-scaling/ 

ケース 1：恒常的な過負荷：読み込み負荷が高い 16 対策 改善方法 コスト増 改修規模 補足 クエリキャッシ ュ / 結果キャッ シュの活用 ElastiCache 等の導 入でよくアクセ スされるクエリ 結果をキャッシ ュしておき読み 込みクエリが RDS にルーティング される回数を減 らす 中～大 ElastiCache のイン スタンスタイプ が大きいほどコ スト増 大 キャッシュを利 用するようにア プリケーション を改修する必要 がある 更新頻度が高い データの場合は 効果が薄い 

ケース 1：恒常的な過負荷：読み込み負荷が高い 17 対策 改善方法 コスト増 改修規模 補足 マテリアライズ ドビュー（イン デックス付きビ ュー）の導入 頻繁に参照され る集計結果や結 合結果をあらか じめ別テーブル （マテリアライ ズドビュー）と して保存。 定期的に更新し、 クエリ実行時は その結果を直接 参照する。イン デックスを付与 することで検索 速度をさらに向 上。 中～大 ストレージ増 加・更新処理負 荷 大 アプリ側クエリ の参照先変更・ 更新処理の追加 更新頻度が高い データ場合は頻 繁に更新する必 要がある 

ケース 1：恒常的な過負荷：読み込み負荷が高い 18 対策 改善方法 コスト増 改修規模 補足 Amazon RDS Optimized Reads の有効化 Optimized Reads を有 効化（最適化読み込 みをサポートするエ ンジン・インスタン スタイプを選ぶだ け）。一時テーブ ル・一時ファイルに 落ちるクエリの処理 を、EBS ではなくロ ーカルNVMe（イン スタンスストア）に 逃がす仕組み。これ により読み取りクエ リが 1.5～2 倍程度 高速化 小～中 インスタンスタ イプ変更による コスト上昇程度 小 設定変更または インスタンスタ イプ変更のみ I/O 負荷の改善に も効果あり。 SSD 領域のインス スタンスストア に上限があるた め、クエリが重 過ぎすとストレ ージ不足になる 可能性あり。 ベストプラクテ ィスに則ってワ ークロードの確 認やパラメータ チューニングが 必要。 [アップデート] RDS 最適化読み込み(Optimized Reads)がリリースされました | DevelopersIO https://dev.classmethod.jp/articles/rds-optimized-reads/ RDS Optimized Reads のベストプラクティス https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-optimized-reads.html#rds-optimized-reads-best-practices 

ケース 1：恒常的な過負荷 書き込み負荷が高い 

ケース 1：恒常的な過負荷：書き込み負荷が高い 20 対策 改善方法 コスト増 改修規模 補足 書き込みトラフ ィックが高い OLTP ワークロー ドを DynamoDB へ分離 トランザクショ ン集中による RDS 負荷軽減のため、 リアルタイム更 新が多い処理を DynamoDB などの スケーラブルな NoSQL へ移行。 負荷分散が自動 化され、RDS の書 き込み/読み込み 両方の圧迫を緩 和。 中～大 DynamoDB のコス ト増、データ移 行コスト増 大 アプリケーショ ンロジック・デ ータアクセス層 の改修 整合性要件が緩 い処理（ログ、 セッション、カ ウント）に適し てしている。 NoSQL 設計やデ ータ移行計画が 必要 

ケース 1：恒常的な過負荷：書き込み負荷が高い 21 対策 改善方法 コスト増 改修規模 補足 非同期化・バッ チ処理化 アプリケーショ ンから直接 RDS へデータ書き込 みするのではな く、SQS キューに 一度投入してか ら順次 Lambda な どを経由してゆ っくり書き込み 処理する。 中 SQS・Lambda な どの構築・運用 コスト 小～中 アプリの書き込 み処理を非同期 化する変更が必 要 即時性が不要な 処理に有効。 遅延許容性とエ ラーハンドリン グ設計が必要。 

ケース 1：恒常的な過負荷：書き込み負荷が高い 22 対策 改善方法 コスト増 改修規模 補足 シャーディング （Aurora PostgreSQL Limitless Database の活用 など） 書き込み負荷を分散 するため、データを 顧客 ID・地域・日付 などのキーで分割し、 複数の DB ノードに 分散配置する。 Aurora PostgreSQL Limitless Database の ような自動スケーリ ング型アーキテクチ ャを採用することで、 アプリケーションか らは単一 DB のよう に扱いながらもスケ ーラビリティを確保 できる。 中～大 ノード増加に伴 う DB コスト増、 データ分割・再 構成の移行工数 が発生 大 アプリケーション側 の接続・データアク セスロジック修正が 必要な場合が多く、 移行期間も長期化し やすい。 Aurora PostgreSQL Limitless Database を 活用する場合はシャ ードテーブル、レフ ァレンステーブルな ど独自の概念を理解 し使う必要がある。 水平分割（シャ ーディング）に よりスケーラビ リティを高め、 スループットの 上限を突破でき る。Aurora PostgreSQL Limitless Database を利用すること で、従来の手動 シャーディング より運用負荷を 低減。 【セッションレポート】Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜（AWS-40） #AWSSummit | DevelopersIO https://dev.classmethod.jp/articles/aws-summit-2024-aws-40/ [レポート] Aurora PostgreSQL Limitless Database のアーキテクチャについて学べる LT「Serverless scaling with Amazon Aurora PostgreSQL Limitless Database」 #DAT338 #AWSreInvent | DevelopersIO https://dev.classmethod.jp/articles/reinvent2024-serverless-scaling-with-amazon-aurora-postgresql-limitless-database-dat338/ Amazon Aurora Limitless Databaseの利用費を試算してみる | DevelopersIO https://dev.classmethod.jp/articles/calculateamazon-aurora-limitless-database-costs/ 

ケース 1：恒常的な過負荷 I/O 負荷が高い 

ケース 1：恒常的な過負荷：I/O 負荷が高い 24 対策 改善方法 コスト増 改修規模 補足 ストレージタイ プ変更（gp3 → io1/io2） 高い IO 性能を提 供するストレー ジタイプに変更 する。書き込み 遅延のボトルネ ックを解消でき る。 中 ストレージ変更 によるコスト増 小 ストレージタイ プの変更のみ Provisioned IOPS SSD。ミッション クリティカルで 高い I/O 性能が求 められるワーク ロード向け。 Amazon RDS のパフォーマンスまたはダウンタイムに影響する要因 | AWS re:Post https://repost.aws/ja/knowledge-center/rds-performance-impact 

ケース 1：恒常的な過負荷：I/O 負荷が高い 25 対策 改善方法 コスト増 改修規模 補足 バッファプール のパラメーター チューニング （innodb_buffer _pool_instances 等） メモリ上のキャッシ ュ領域（バッファプ ール）にテーブルデ ータやインデックス ページを載せておく ことで、ディスク I/Oを減らす。 バッファプールの大 きさや再起動時のダ ンプ・ロード設定 （innodb_buffer_pool _dump_at_shutdown / innodb_buffer_pool_l oad_at_startup）を 調整する。 中 メモリ使用量増 加によるコスト 上昇 小 パラメータ変更 のみ DB レイヤーでの チューニング。 バッファプール を増やし過ぎる と OS メモリに影 響 

ケース 1：恒常的な過負荷 データ構造・運用見直し 

ケース 1：恒常的な過負荷：データ構造・運用見直し 27 対策 改善方法 コスト増 改修規模 補足 過去データの退 避（S3・Athena 等で分析） 古い履歴データ を S3 などにアー カイブし、トラ ンザクション系 を軽量化。スト レージサイズ増 大やインデック ス肥大化を防ぐ 小～中 S3・Athena 等の ストレージコス ト発生 中 ETL や移行スクリ プト作成が必要。 Athena での検索 機能をアプリケ ーションに埋め 込む場合は SDK 等を使用して作 り込みが必要。 Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存 - Amazon Aurora https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html 

ケース 1：恒常的な過負荷：データ構造・運用見直し 28 対策 改善方法 コスト増 改修規模 補足 パーティション 分割する 日付・顧客単位 などでパーティ ションを分割し、 クエリ時のスキ ャン量を減らす 小 DB レイヤー内で のテーブル分割 のみ 中～大 既存テーブル構 造を変更する必 要がある場合は 改修規模大。 アプリケーショ ン側で SQL 修正 が必要なケース もあり。 パーティション 分割：アプリか らは 1 テーブル として見える DB 内部の分割方法 

ケース 2：突発的なスパイク 29 • 諸注意 • RDS の負荷の見方 • ケース 1：恒常的な過負荷 • CPU・メモリ負荷が高い • 読み込み負荷が高い • 書き込み負荷が高い • I/O 負荷が高い • データ構造・運用見直し • ケース 2：突発的なスパイク • ロックの多発 • スロットリング • オートスケーリング • 両方のケースに有効 

ケース 2：突発的なスパイク ロックの多発 

ケース 2：突発的なスパイク：ロックの多発 31 対策 改善方法 コスト増 改修規模 補足 クエリのチュー ニング 更新系クエリの バッチ処理を分 割する、不要な SELECT ... FOR UPDATE の削減、 インデックスの 最適化などによ りロック競合を 緩和する。 中～大 調査・検証・DBA 工数発生 中～大 アプリ／SQL修正 やスキーマ見直 しが必要な場合 あり ロック件数はメトリ クスで確認できる。 長時間トランザクシ ョン・全件更新・イ ンデックス欠如など が主因。Database Insightsで時間のかか るクエリを特定し、 EXPLAIN コマンドで 実行計画を確認。イ ンデックス未使用や 全件スキャンが原因 の場合はクエリやス キーマを見直す。 

ケース 2：突発的なスパイク スロットリング 

ケース 2：突発的なスパイク：スロットリング 33 対策 改善方法 コスト増 改修規模 補足 アプリケーショ ン側リトライロ ジック改善 Exponential Backoff + Jitter により、同時 リトライ集中を防止。 短時間のスパイク時 にリクエストを分散 させ、RDS や API へ の過剰アクセスを緩 和する。 特に SDK を利用しな い HTTP クライアン ト（例：curl、axios、 fetch）などで Data API や外部 API を直 接呼び出す場合に有 効。 小 中 アプリケーショ ンの改修が必要。 API スロットリング （429エラー）や Data API 利用時、一 時的なエラー、ネッ トワークサービスタ イムアウト時などに 有効。インスタンス サイズ拡張や EBS IOPS 強化ほどの恒常 的対策ではないが、 一時的な過負荷・ス パイク・復旧直後の 輻輳を安全にやり過 ごす安価な輻輳緩和 策。 ※AWS SDK にはデフ ォルトでエクスポネ ンシャルバックオフ ＋ジッターが実装済 み 

ケース 2：突発的なスパイク オートスケーリング 

ケース 2：突発的なスパイク：オートスケーリング 35 対策 改善方法 コスト増 改修規模 補足 Aurora Serverless v2 の利用 スパイクアクセ スに対し自動で インスタンスを スケールアップ 中～大 同じメモリあた りの料金であれ ばプロビジョン ドインスタンス よりサーバーレ スインスタンス の方が単価が高 い 中～大 Aurora Serverless v2 に対応してい ないエンジンの 場合、移行コス ト大 恒常的に読み書 きが発生してい る DB の場合はプ ロビジョンドイ ンスタンスの方 が安価 

両方のケースに有効 36 • 諸注意 • RDS の負荷の見方 • ケース 1：恒常的な過負荷 • CPU・メモリ負荷が高い • 読み込み負荷が高い • 書き込み負荷が高い • I/O 負荷が高い • データ構造・運用見直し • ケース 2：突発的なスパイク • ロックの多発 • スロットリング • オートスケーリング • 両方のケースに有効 

両方のケースに有効 

両方のケースに有効 38 対策 改善方法 コスト増 改修規模 補足 RDS Proxy による 接続制御 Connection 数が多 い場合に RDS Proxy 経由で接続 プールを共有化。 アプリケーショ ンからのコネク ション確立を効 率化し、RDS への 過剰接続を防ぐ。 中～大 CPU に応じて RDS Proxy の料金も増 加、従量課金 小～中 RDS Proxy 向けに 接続設定を変更。 アプリケーショ ンからの同時接 続数を吸収・安 定化させる。 Lambda や Fargate などのサーバー レス環境で特に 有効。 

両方のケースに有効 39 対策 改善方法 コスト増 改修規模 補足 スロークエリロ グの監視と定期 チューニング Database Insights、 拡張モニタリン グ、CloudWatch Logs 等を活用し スロークエリを 監視。 定期的なインデ ックス見直し、 実行計画確認、 不要クエリ削減 小～中 監視機能やモニ タリングのコス トが発生 中～大 DB 構造やアプリ ケーション側ク エリ修正を伴う 場合がある 恒常的な負荷・ 突発的なロック いずれにも有効。 一時的な対応で はなく継続改善 として取り組む と良い。 

両方のケースに有効 40 対策 改善方法 コスト増 改修規模 補足 Aurora への移行 既存 RDS （MySQL/PostgreS QL）から Auror a へ移行。Aurora のストレージ分 離構造により、 書き込み時の I/O 負荷を分散。リ ードレプリカの 活用により読み 込みもスケール 可能。 中 Aurora ではない 通常の RDS と比 較しややコスト 増 中～大 Aurora に対応し ていない MySQL・ PostgreSQL 以外の エンジンを使用 している場合、 改修が必要。 Aurora ではコン ピュートとスト レージが分離さ れ、データペー ジの生成処理が ストレージ層に オフロードされ ることで、DB インスタンスの I/O 処理負荷が削 減され、書き込 みスループット が向上する。 Amazon Aurora for Core Banking Systems | AWS for Industries https://aws.amazon.com/jp/blogs/industries/amazon-aurora-for-core-banking-systems/ Amazon Aurora ストレージ - Amazon Aurora https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html 

No content