顧客からデータベースアクセスのパフォーマンスが出ない、という相談があり、若手に説明する機会があったのでデータベースのパフォーマンスチューニングに関しての勘所をまとめました。
はじめに
データベースというとDWHやデータレイク、CSVファイル、SQLite等が幅広く含まれますが、チューニングのアプローチが異なる場合があるため、本記事ではRDBMSを対象とします。
(考え方は応用できると考えてます)
STEP1:ゴールを決める
まず、ゴールを決めます。
とにかくパフォーマンスをあげる、という目的でない限りは処理に対してのパフォーマンス要件(許容時間)があるはずです。無制限にパフォーマンスチューニングをしてもコストがかかるので、はじめに目標の処理時間=ゴールを決めます。
たとえば、週次の帳票出力アプリで出力ボタンをクリックしてからデータが表示されるまでといったスループットが要件の場合もありますが、特定のSQLの応答時間といった要件もあるかと思います。基本的には前者が要件になることが多いと考えてます。
STEP2:対象や状況を確認する
いつ(常に、時々等)・どの操作(処理)でのパフォーマンスが問題かを確認します。
新規のシステム以外はパフォーマンスが悪化したタイミングがあるはずです。
利用者が増えた、同一ネットワーク上のサーバーが増えた、データ量が増えた等のシステム上の変化も重要なインプットになります。
STEP3:原因を特定する
次に問題個所の切り分けを行い、原因を特定します。
切り分けはデータ処理、通信の経路上にあるリソース(アプリケーション・ネットワーク・サーバ・OS・ミドルウェア等)を以下の観点で確認していきます。
- ネットワーク
アプリケーションとデータベースとの経路上のFW、ルーター等のネットワーク機器、ネットワーク帯域 - サーバ
CPU、メモリ使用量・ディスクのIOPS、ディスクとサーバとの通信帯域 - OS
カーネルパラメータ、他プロセス - データベース
RDBMS製品のキャッシュ設定、各パラメータ、テーブルのインデックス、データサイズ(レコード件数)、ストアドプロシージャ、データ断片化、統計情報 - クライアント
クライアントのマシンスペック、RDBS用クライアントの設定 - アプリケーションコード
コネクションプール、データ取得時のロジック - SQL
実行計画、テーブル結合
STEP4:対処
原因がわかればそれに応じた対応をすることになりますが、原因不明の場合はバグの可能性もあるのでRDBMSのバージョンをもとに掲示板やサポートを活用して確認しましょう。
もちろん、テストをお忘れなく。
おわりに
オンプレでは本番環境と同構成の検証環境を準備することは様々な要因で難しかったのですが、クラウドではスナップショットやバックアップを使用することで、チューニング問題が発生したデータベースの状態を再現しやすくなったため、テストは楽になったと思います。
クラウドでは自動スケールするデータベースサービスもあるので今後はチューニングするということ自体が減っていくかもしれませんが、概念を知っておくことで他にも応用ができるので是非覚えておきましょう。
土山 和也(日本ビジネスシステムズ株式会社)
ユーザーサポート、開発、運用、構築業務を経験し、現在はアーキテクトとして提案・プロジェクト支援に従事。専門はデータベースでDBA歴十数年。Azure/AWSを担当。
担当記事一覧