Amazon RDS / Amazon Aurora パフォーマンスチューニングとモニタリング

2024/5/25 第34回 中国地方DB勉強会 in 広島

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS / Amazon Aurora パフォーマンスチューニング とモニタリング Yoshinori Fujiwara Sr. Solutions Architect Amazon Web Services Japan G.K. 2 0 2 4 / 5 / 2 5 第 3 4 回 中 国 地 ⽅ D B 勉 強 会 i n 広 島
2. © 2024, Amazon Web Services, Inc. or its affiliates. ⾃⼰紹介 藤原 吉規 🧑🚒 デジタルサービスソリューション部 シニア ソリューションアーキテクト デジタルネイティブビジネスのお客様に 技術⽀援しています。 2 Production 環境で運⽤経験のあるデータベース 1. 2000〜 SQL Server 7.0-2000, MySQL 3.23.x, PostgreSQL 7.3.x 2. 2005〜 Oracle 9i-10g EE RAC, DB2 9.1 3. 2010〜 MySQL 5.1-5.5 on Amazon EC2, Amazon RDS for MySQL 5.5-5.6, Amazon Aurora MySQL 5.6, Amazon DynamoDB, Amazon ElastiCache for Memcached/Redis, etc.. (Amazon S3, Amazon CloudSearch, Amazon Redshift, Amazon SQS, Amazon SNS) 4. 2016〜 現職
3. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Light Part: モニタリング 3
4. © 2024, Amazon Web Services, Inc. or its affiliates. モニタリング: アジェンダ 1. Amazon RDSの概要と重要なデータベース管理タスク 2. モニタリング計画とパフォーマンスガイドラインの策定 3. モニタリングツールのご紹介 4
5. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS の概要と 重要なデータベース管理タスク 5
6. © 2024, Amazon Web Services, Inc. or its affiliates. 6 Purpose-built
7. © 2024, Amazon Web Services, Inc. or its affiliates. Purpose-built databases 7 Amazon Aurora Amazon RDS Amazon DynamoDB Amazon DocumentDB Amazon Timestream Amazon Neptune Amazon ElastiCache Amazon Quantum Ledger Database (Amazon QLDB) Amazon Keyspaces (for Apache Cassandra) リレーショナル 参照整合性、 ACID トラン ザクション、 schema-on- wirte キーバリュー ⾼スループット、 低レイテンシの read/write, 制限のない拡張性 ドキュメント ドキュメントを 格納し、クエリ 利⽤により任意 の属性に対して ⾼速にアクセス インメモリ キーを利⽤して マイクロ秒の レイテンシで クエリ グラフ 時系列 時間経過に 従って計測 される データを収集、 蓄積、処理 台帳 データ間の関係 性を⾼速、容易 に作成、探索 ワイドカラム 完全、不変かつ 検証可能な、 アプリケーション データに対する すべての変更履歴 従来の アプリケーション、 ERP、CRM、 会計 トラフィックの 多いウェブアプリ、 e コマース システム、リアル タイム⼊札 コンテンツ管理、 カタログ、 ユーザー プロファイル キャッシュ、 セッション管理、 ゲームの リーダーボード、 地理空間 アプリケーション 不正検出、 ソーシャル ネットワーク、 レコメンデーション エンジン IoT アプリケーション、 イベント トラッキング 記録システム、 サプライチェーン、 ヘルスケア、 トランザクション AWS サービス 主な ユースケース スケーラブルで、 可⽤性が⾼い、 マネージドな Apache Cassandra 互換サー ビス 低レイテンシな アプリケーションの 構築、 Cassandra ベースの アプリケーションを クラウドに移⾏ Amazon MemoryDB for Redis (for LiveAnalytics) (for InfluxDB)
8. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon Relational Database Service (RDS) 8 データベースエンジンが選択可能な フルマネージド・リレーショナルデータベースサービス 容易な管理 可⽤性と耐久性 ⾼い拡張性 ⾼速で安全 インフラストラクチャの プロビジョニング、 データベースのインストール、 メンテナンスは不要 マルチAZデータレプリケー ション、⾃動バックアップ、 スナップショット、 ⾃動フェイルオーバー 数クリックでデータベー スのコンピュートとスト レージを拡張可能; アプリケーションのダウ ンタイムは最⼩限 SSDストレージと保証された プロビジョンドI/O; 保存時、 転送中のデータ暗号化 Amazon Aurora MySQL PostgreSQL Oracle SQL Server IBM Db2
9. © 2024, Amazon Web Services, Inc. or its affiliates. Managed Database による管理タスクの効率化 9 スキーマのデザイン クエリの作成 パフォーマンスの最適化 ⾃動化されたフェイルオーバー バックアップとリカバリ 分離とセキュリティ コンプライアンスへの準拠 数クリックでスケール ⾃動化されたパッチ適⽤ 拡張モニタリング OS、DBのインストール お客様 AWS データベース管理者は、データベース構築、 バックアップ、リカバリ、⾼可⽤性の確保、 パッチ適⽤など定型で時間のかかるデータ ベース管理タスクから解放されます。
10. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. モニタリング計画と パフォーマンスガイドラインの策定 10
11. © 2024, Amazon Web Services, Inc. or its affiliates. なぜモニタリングが重要なのか モニタリングは信頼性、可⽤性、パフォーマンスを維持する上で重要です。 • データベースのボトルネックを特定し、ワークロードをチューニングするため • プロアクティブなスケールアップやサイジングの判断をするため • 構成の⽐較や、アプリケーションの変更を把握するため • インシデントを検知するため • なるべく早く対処を⾏う • 調査し、将来的な影響を和らげていく 11
12. © 2024, Amazon Web Services, Inc. or its affiliates. モニタリング計画の考え⽅ 1. 何のためにモニタリングする︖ 2. 何のリソースをモニタリングする︖ 3. どのくらいの頻度でモニタリングする︖ 4. 何のツールを使⽤する︖ 5. 誰がモニタリングタスクを実⾏する︖ 6. 問題が発⽣したときに誰に通知する︖ 12 このあとお話しするポイント
13. © 2024, Amazon Web Services, Inc. or its affiliates. パフォーマンスのベースラインの策定 負荷条件やタイミングを変えながら、例えば以下のメトリクスなどから パフォーマンス測定し、ベースラインを確⽴します。 ü ネットワークスループット ü データベース接続数 ü 読み取り、書き込み、メタデータのいずれかのオペレーションの I/O ü DB インスタンスのバーストクレジットバランス ü etc.. 13
14. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. モニタリングツールのご紹介 14
15. © 2024, Amazon Web Services, Inc. or its affiliates. データベース監視のアーキテクチャ 15 Notifications Monitoring Statistics Database Engineer / Admin Application Engineer Performance Monitoring Workshop for RDS PostgreSQL and Aurora PostgreSQL: https://catalog.us-east-1.prod.workshops.aws/workshops/31babd91-aa9a-4415-8ebf-ce0a6556a216/en-US
16. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS で利⽤可能なモニタリングツール 16 ツール できること 設定⽅法 Amazon CloudWatch Hypervisor 等の各種メトリクスを60 秒間隔で取得・確認可能 • デフォルト有効 拡張モニタリング OSレイヤーの各種メトリクスを1、5、 10、15、30、60秒間隔で取得・確認 可能 • インスタンス作成時、作成後に有効/無効を指定 (デフォルト有効) Amazon RDS Performance Insights データベース内の性能情報を蓄積・視 覚化し、最⼤2年過去に遡ってワーク ロード分析が可能 • インスタンス作成時、作成後に有効/無効を指定（デフォルト有効） DB ログファイル DB インスタンスによって⽣成された ログファイルの閲覧、ダウンロード、 Amazon CloudWatch Logs 統合が可 能 • ⼀般ログ、エラーログなどはデフォルト有効 • DB エンジン固有の機能(スロークエリログ、監査ログなど)の有効化が 可能 • ログローテーション、ログ保持期間は DB エンジンに依存 RDS イベント通知 RDS 環境の変更イベントの取得が可能、 Amazon SNS, Amazon EventBridge と連携が可能 • デフォルト有効 • 最⼤過去 14⽇間のイベントを取得可能
17. © 2024, Amazon Web Services, Inc. or its affiliates. トップダウンからの分析 17 リソース監視 データベースの状況確認 さらに内部構造への確認 ・Throughput ・Latency ・Utilization – CPU,IOPS,Memory ・Database availability ・Authentication failure ・Slow running queries ・wait event ・IO throttling ・Cloud Watch Dashboard with Enhanced Monitoring ・DB Engine Logs ・DB Engine Performance Views
18. © 2024, Amazon Web Services, Inc. or its affiliates. トップダウンからの分析 18 リソース監視 データベースの状況確認 さらに内部構造への確認 ・Throughput ・Latency ・Utilization – CPU,IOPS,Memory ・Database availability ・Authentication failure ・Slow running queries ・wait event ・IO throttling ・Cloud Watch Dashboard with Enhanced Monitoring ・DB Engine Logs ・DB Engine Performance Views CloudWatch によるリソース監視 Performance Insights による分析 拡張モニタリング、 DB ログ、DB Perfomance View による詳細分析
19. © 2024, Amazon Web Services, Inc. or its affiliates. まとめ • Amazon RDSのモニタリングは 信頼性、可⽤性、パフォーマンスを維持する上で重要なタスクです • モニタリングをする上で計画とガイドラインの作成が必要です • モニタリングツールは複数あり、問題が発⽣した際の対処する為に 網羅的な利⽤を推奨します 19
20. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Light Part: パフォーマンスチューニング 20
21. © 2024, Amazon Web Services, Inc. or its affiliates. アジェンダ 1. RDS/Aurora におけるパフォーマンス分析の課題 2. Amazon RDS Performance Insights 3. パフォーマンス管理プロセス 4. Performance Insights を⽤いた解析⽅法 21
22. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. RDS/Aurora におけるパフォーマンス 分析の課題 22
23. © 2024, Amazon Web Services, Inc. or its affiliates. システムパフォーマンスの重要性 23 システムを安定的に稼働させるためには、パフォーマンス、可用性、セキュリ ティなどの非機能要件を担保する必要があります。パフォーマンスが劣化する ことでシステムはスローダウンを引き起こし、様々な問題を引き起こします。 ユーザエクスペリエンスが低下し、高速な他社サイトに乗り換えら れてしまう 頻発するスローダウンにより、自社サイトの評判が下がり、顧客の 信頼性の回復に多大な投資が必要となる パフォーマンス問題が足枷になり、アーキテクチャ/開発者の柔軟な スケールに弊害が発生し、ビジネス拡大ができなくなる
24. © 2024, Amazon Web Services, Inc. or its affiliates. データベースによって引き起こされるパフォーマンス問題 24 システムパフォーマンス問題の原因は、様々な要因が組み合わさって発生する が、データベースに関連する問題であることが多いため、データベースがパ フォーマンス問題の一部を占めることがよくあります。 膨大なデータ量 アプリケーション レイヤーの増大 予測不可能な トラフィック数 実行計画の変動
25. © 2024, Amazon Web Services, Inc. or its affiliates. RDS/Aurora におけるパフォーマンス分析の課題 25 OS やデータベースの様々はメトリクスの組み合わせを効率的に分析 するのは経験豊富なDBAが必要 細かい粒度のパフォーマンスデータを長期間にわたり、収集、管理 していくのは運用コストが高い パフォーマンスの異常検出、通知の仕組みを構築するコストが高い 現在、何十万ものお客様が Amazon RDS/Aurora を利用していますが、アプリ ケーションの規模や複雑さが増すにつれて、お客様が運用やパフォーマンスの 問題を迅速に検出し、解決することは難しくなってきています。
26. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS Performance Insights 26
27. © 2024, Amazon Web Services, Inc. or its affiliates. 課題解決のためにどのようなツールが求められているか 27 経験豊富なDBAが不在 パフォーマンス情報の継続的な 取得や可視化の運用コスト パフォーマンスの異常検知や 通知の構築コスト パフォーマンス分析の 課題 誰でも簡単に使えるツール ボトルネック解析に必要な 情報を収集・可視化 シンプルな画面構成 求められているツール Amazon RDS Performance Insights
28. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS Performance Insights の特徴 28 (*1) 7⽇分は無料で利⽤可能。有料で2年間の保持が可能 (*2) Db2 を除く全てのデータベースエンジンに対応していますが、⼀部のバージョンやインスタンスタイプではPerformance Insightsはサポートされていません https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PerfInsights.html シンプル データベースロード (AAS)を使って、単 ⼀のコアKPIでパ フォーマンス監視、 分析 簡単 数クリックでパ フォーマンスKPIの 取得からダッシュ ボードへの表⽰をデ プロイ可能 ⾃動 特別な設定やメンテ ナンスは不要。また 最⼤2年(*1)は問題 のあった時点に遡っ て分析が可能 ⾼機能 Amazon RDSがサ ポートする6つのデー タベースエンジン全 て(*2)で同じ操作感 で利⽤可能
29. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS Performance Insights の特徴 29 p 対応エンジン ü Aurora PostgreSQL ü Aurora MySQL ü RDS PostgreSQL ü RDS MySQL ü RDS MariaDB ü RDS Oracle ü RDS SQL Server MySQL, MariaDBでは、db.t2.micro, db.t2.small, db.t3.micro, db.t3.small db.t4g.micro, db.t4g.small インス タンスクラスでPerformance Insightsはサポートされていま せん p 主要な機能 ü “データベースロード” チャート ü “カウンターメトリクス” チャート ü “Top N ディメンション” テーブル • 分析軸: 待機、SQL、ホスト、ユーザー ü 7日間のデータ保持期間(デフォルト) • パフォーマンス履歴の保存期間を 1 か月から 24 か 月まで指定することができます。1 か月以上の保存 は、プロビジョニングされたインスタンスに対し て 1 か月あたり vCPU ごとに料金が発生します。 カウンターメトリクス ：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights_Counters.html CloudWatchに発行されるメトリクス ：https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Cloudwatch.html Performance Insights API Reference ：https://docs.aws.amazon.com//performance-insights/latest/APIReference/Welcome.html 料金表 : https://aws.amazon.com/jp/rds/performance-insights/pricing/
30. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS Performance Insights ダッシュボード 30 データベース内のパフォーマンスデータを蓄積してボトルネックを特定 データベースのロード • 平均アクティブセッション数(AAS) • CPU時間と待機イベント内訳 • RDS/Aurora全てのエンジンをサポート カウンターメトリクス • OSのリソース情報(CPU、Memoryなど) • DBの統計情報(セッション数など) ボトルネックの分析軸 • ボトルネックの原因の待機 • ボトルネックとなっているSQL • 性能影響の高いホスト、ユーザー
31. © 2024, Amazon Web Services, Inc. or its affiliates. Amazon RDS Performance Insights ダッシュボード 31 ズームイン ズームインすると粒度の細かいAverage Active Sessions(AAS)に自動変更
32. © 2024, Amazon Web Services, Inc. or its affiliates. カウンターメトリクス 32 【カスタイマイズ性】 任意のメトリクスを カスタマイズ可能 各種リソースを同一ビューで分析可能 【柔軟な解析期間】 解析したい期間を任意に指定可能 【メトリクス】 OSレイヤーのメトリクス DBレイヤーのメトリクス
33. © 2024, Amazon Web Services, Inc. or its affiliates. データベースロード 33 データベースのパフォーマンスを評価するためのKPI データベースロード → アクティブなセッション数(Active Sessions) アクティブなセッションとは - データベースのセッションは“アクティブ” / “アイドル”のステータスがある - さらに、アクティブなセッションは”CPU使用中”、”他の処理を待機中”の2つのステータス データベースロードとは - 1秒おきに”アクティブ”なセッションの詳細な情報をサンプリング - ステータス(CPU使用中、待機中(待機イベント(*1))、SQL文、接続元ホスト、接続ユーザー - 言い換えると1秒間(*2)の”Average Active Sessions”とも言える *1 各データベースの待機イベントの情報はAppendixを参照(参考となるリファレンスを掲載) *2 データベースロードを選択する期間により平均を取得するための間隔は変動(最小で1秒間の平均値となる)
34. © 2024, Amazon Web Services, Inc. or its affiliates. データベースロード = Average Active Sessions 34 6 3 データベースロード = On CPU + Waiting
35. © 2024, Amazon Web Services, Inc. or its affiliates. アクティブセッションの状態をブレークダウン 35 6 3 データベースロード
36. © 2024, Amazon Web Services, Inc. or its affiliates. さらに”待機イベント”でブレークダウン 36 6 3 データベースロード
37. © 2024, Amazon Web Services, Inc. or its affiliates. データベースロードで問題の発⾒ 37 6 ü データベースロード(AAS) ~= 0 基本的にデータベースが使用されていない Max vCPU 2 On CPU IO Read IO Write ü データベースロード(AAS) > # of vCPUs パフォーマンス問題の可能性がある ü データベースロード(AAS) >> # of vCPUs パフォーマンス問題 パフォーマンス問題の有無は、データベースロードが インスタンスの最大vCPUを超えているかどうかが基準
38. © 2024, Amazon Web Services, Inc. or its affiliates. Top N Dimension テーブル 38 待機イベントの原因になっている SQL を特定できる 各 SQL の秒間の「コール数」、「取得行 数」、「レイテンシ」を確認し、パフォーマ ンスインパクトの大きさを確認できる 選択する事で SQL の全文も確認する事が 可能 トップ SQL 以外にもタブの切り替えで、「トップユーザー」 や「上位のデータベース」への切り替えが可能
39. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. パフォーマンス管理プロセス 39
40. © 2024, Amazon Web Services, Inc. or its affiliates. データベースのパフォーマンス管理サイクル 40 モニタリング (監視) ディスカバリー (発見) アナリシス (分析) レゾリューション (解決) 各レイヤーでデータベー スのパフォーマンス KPI、分析に必要な詳細 なデータを収集 データベースでパフォー マンス問題が発生してい るのか否か、またその度 合いを検知 検知した問題についてモ ニタリングで取得した詳 細データを使って原因を 分析すると共にチューニ ング計画を立てる チューニング計画にお けるゴールの定義にも とづいてチューニング を実施
41. © 2024, Amazon Web Services, Inc. or its affiliates. モニタリング (監視) ディスカバリー (発見) アナリシス (分析) レゾリューション (解決) Amazon RDSのパフォーマンス管理(課題と改善) 41 • CloudWatch • CloudWatch Logs • 拡張モニタリング • 独自プログラム • OSレイヤーやDBの 特定の統計情報で問 題を発見 • 広範なパフォーマン ス問題を発見するの は困難 • どの程度リソースが 不足、余剰なのかの 見積もりが困難 • ボトルネックが曖昧 なため、SQLやデー タベースのチューニ ングが困難 • Amazon RDS Performance Insights • OSに加えて、デー タベースレイヤーの KPIを見ることで的 確に問題の有無を判 断可能 • 待機イベントベース のKPIによりボトル ネックが明確、また チューニング目標を 設定しやすい • ボトルネックと チューニング目標を 明確にし、目的に向 かって効率的な チューニングを実施 (* Performance Insight 以外で実施)
42. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Performance Insights を⽤いた解析⽅法 42
43. © 2024, Amazon Web Services, Inc. or its affiliates. Performance Insight を⽤いた解析プロセス例 43 ディスカバリー (発見) アナリシス (分析) OS リソース 本プロセスが全てのDB解析プロセスを網羅しているわけではありませんが、よくある解析例を紹介します。 DB メトリクス DBログ and and • CPU • メモリ • ネットワーク • IO (ディスク) • キャッシュ ヒット率 • コネクション数 など リソースが使えて いない場合 DB アクセス が遅い クライアントからの NWレイテンシー ロック競合 Write Heavy Performance Insights APクライアントからの実行時間と DB内のクエリ実行時間の差分を確認 データベースロード 問題あり Performance Insights データベースロード（待機イベン ト）により、CPU やメモリなどの OS メトリクス、DB メトリクスを 押し上げている原因を探る Performance Insights トップSQLを見て、支配的な 待機イベントを押し上げてい るSQLを特定
44. © 2024, Amazon Web Services, Inc. or its affiliates. よくある解析例 44 DB サーバの CPU が高騰し、全体的なスローダウンが発生 DB サーバの IO レイテンシが劣化して、全体的なスローダウン が発生 Write Heavy により全体的なスローダウンが発生
45. © 2024, Amazon Web Services, Inc. or its affiliates. CPU ⾼騰のケース 45 ディスカバリー (発見) アナリシス (分析) カウンターメトリクス CPU使用率（Wait) Disk Queue Length CPU 使用率のカウンターメトリクス上で IO wait が高く、 ディスクのキュー長も高いため、IOによる待機が発生 CPUがほとんど使えておらず、 IO:DataFileRead といったIO系 の待機イベントが支配的
46. © 2024, Amazon Web Services, Inc. or its affiliates. IO ⾼騰のケース 46 ディスカバリー (発見) アナリシス (分析) カウンターメトリクス CPU使用率（Wait) Disk Queue Length CPU 使用率のカウンターメトリクス上で IO wait が高く、 ディスクのキュー長も高いため、IOによる待機が発生 CPUがほとんど使えておらず、 IO:DataFileRead といったIO系 の待機イベントが支配的
47. © 2024, Amazon Web Services, Inc. or its affiliates. 待機イベント 47 IO高騰の際に発生する物理読み込みの待機イベント例 エンジン 待機イベント Oracle db file scattered read（テーブルフルスキャン） db file sequential read（インデックススキャン） Aurora PostgreSQL IO:DataFileRead RDS PostgreSQL DataFileRead Aurora MySQL io/table/sql/handler RDS MySQL io/table/sql/handler RDS MariaDB io/table/sql/handler RDS SQL Server PAGEIOLATCH_SH
48. © 2024, Amazon Web Services, Inc. or its affiliates. Write Heavy のケース 48 ディスカバリー (発見) アナリシス (分析) カウンターメトリクス CPU使用率（Total) CPU 使用率のカウンターメトリクスやその他の OS メトリ クスでボトルネックが見られない しかし、クエリレスポンスタイムが遅延している状況と なっている事が多い。 ・ ・ ・ CPUがほとんど使えておらず、 Iwrite Heavy の際に出る待機 イベントが支配的
49. © 2024, Amazon Web Services, Inc. or its affiliates. 待機イベント 49 Writeヘビーの際に発生する待機イベント例 エンジン 待機イベント Oracle log file sync Aurora PostgreSQL IO:XactSync RDS PostgreSQL IO:WALWrite, IO:WALSync, LWLock:WALWrite Aurora MySQL io/aurora_redo_log_flush RDS MySQL synch/cond/sql/MYSQL_BIN_LOG::COND_done synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log RDS MariaDB synch/cond/sql/THD::COND_wakeup_ready RDS SQL Server WRITELOG
50. © 2024, Amazon Web Services, Inc. or its affiliates. チューニング⽬標値 50 チューニングの優先 度 • 待機時間の多いイベ ント? • 最も遅いSQL? • システム全体の中で 問題の比率の高いア プリケーション? • ビジネス要件? チューニング目標 • 2倍、4倍、100倍の パフォーマンスが必 要? • そもそもデータベー スとしてチューニン グの限界はどこなの か? パフォーマンスインパクトの 大きい待機イベントは? パフォーマンスインパクトの 大きいSQL文は? パフォーマンスインパクトの 大きい接続元ホストは? パフォーマンスインパクトの 大きい接続ユーザーは? データベースロード (Average Active Sessions) からデータベース全体の ワークロードの問題点を 発見
51. © 2024, Amazon Web Services, Inc. or its affiliates. DB のパフォーマンス最適化 51 OS アプリケーション デバイス クエリの パフォーマンス管理 Performance InsightsでSQL やSQLの実行プランに起因す る問題だと特定したあとの話 ▷ モニタリング (監視) ディスカバリー (発見) アナリシス (分析) レゾリューション (解決)
52. © 2024, Amazon Web Services, Inc. or its affiliates. まとめ 52 1. モニタリングやパフォーマンス解析ツールの導入が重要 システムが複雑になるにつれ、お客様の運用やパフォーマンスの問題を迅速に検出し、 解決することは難しくなってきており、パフォーマンスにおけるモニタリング、解析 ツールの導入の必要性が向上している 2. Performance Insights を用いた解析方法 Peformance Insights の機能の紹介と解析プロセス/方法について本セッションでは紹介 しました。よりパフォーマンスの問題が発生した際の対応に役立てていただきたい。 3. 性能問題には適切なボトルネックの特定と対処が必要 性能問題が発生した際に、問題の発生原因となっている適切なボトルネックを特定し、 それに対するチューニング目標値を定めて対応する必要がある。
53. © 2024, Amazon Web Services, Inc. or its affiliates. © 2024, Amazon Web Services, Inc. or its affiliates. Deep Part: リレーショナル DB 設計 失敗知識 53
54. © 2024, Amazon Web Services, Inc. or its affiliates. リレーショナル DB 設計失敗知識 1. SaaS テナント毎に Database や Schema を分割し 100万 Table 問題が発⽣ • SaaS テナント毎に DB ユーザーを作成、1万テナントであれば 1万ユーザーを作成 • テナント毎 DB/ユーザー分割により接続プーリングが⾏えず、リクエスト毎に都度接続しパフォーマンス低下 • Table 毎に⽣成される Performance 統計情報の取得や集計・解析が困難に • ⼤量の DB 分割により論理レプリケーションも実現困難に 2. アプリ機能⽤途ごとに DB ユーザーを分割しておらず、Performance 統計情報/ログの可視性を確保できない 3. 時系列にデータ増加する Table をパーティション分割しておらず、過去データを退避できずストレージコストが課題に • VARCHAR や TEXT カラムを多⽤した、⼤福帳型履歴 Table • ログデータ保存のために TEXT や JSON カラムを使⽤した Table 4. プライマリキーにインクリメンタルな ID 以外を利⽤ (UUID version 1 など) し、クエリパフォーマンス低下 5. アプリ機能毎の Table/データ更新順序が統⼀されていないため、デッドロックが発⽣ 6. DDL ex: CREATE temporary TABLE をリクエスト毎に並列実⾏し、カスケード障害に発展 54
55. © 2024, Amazon Web Services, Inc. or its affiliates. Performance 統計情報やスロークエリログは “クエリ成功時” に記録、失敗したクエリは記録されない 55 https://repost.aws/ja/knowledge-center/rds-postgresql-running-queries https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora- mysql-troubleshooting-workload.html#CHAP_Troubleshooting.AuroraMySQLOOM
56. © 2024, Amazon Web Services, Inc. or its affiliates. 100 万の Database Table 56 © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 失敗知識から学ぶ︕ クラウドアプリ設計で避けるべき 事例とその対策 藤原 吉規 A - 5 シニア ソリューションアーキテクト アマゾン ウェブ サービス ジャパン 合同会社 https://speakerdeck.com/twingob/shi-bai-zhi-shi-karaxue-bu-kuraudoapurishe-ji-debi-kerubekishi-li-tosonodui-ce
57. © 2024, Amazon Web Services, Inc. or its affiliates. Thank you! © 2024, Amazon Web Services, Inc. or its affiliates.