はじめに
本コラムでは、Webシステムのパフォーマンスチューニング（性能改善）について解説します。
大勢の人が利用する大規模ECサイトや、ユーザアクセスが集中しやすいキャンペーン系サイトなど、利用者数が多いコンシューマ向けWebサイトは、運用年数とともにデータ量が増え、性能問題が顕在化しパフォーマンスチューニングを必要とするケースがあります。
また、システム開発における試験工程にて非機能要件で定めた性能要件を満たせず、パフォーマンスチューニングの必要に迫られる場合もあります。
そういった場面において、性能改善をどう進めればいいか分からない、という方に向け解決手法を紹介します。
パフォーマンスチューニングの基本
性能問題には以下のように様々な種類があります。
＜性能問題の種類＞
・処理時間の遅延
・スループットの低下
・デッドロックによる性能低下
・非効率なキャッシュによる性能低下
・スケーラビリティ検討不足による課題の顕在化
・リソース管理不足による課題の顕在化
どのような種類の性能問題においても、基本的には以下の流れで進めていきます。
【1】 性能問題の事象を正しく把握する
【2】 情報分析により原因を推測する
【3】 将来を見据えた対策を行う
【4】 効果を測定し、追加対策の要否を判断する
本コラムでは、具体例として“処理時間の遅延”問題を取り上げて対策方法を説明します。
【1】性能問題の事象を正しく把握する
最初に、どういった性能問題が起きているのか、それがどこで発生しているのかを正しく把握する必要があります。
処理時間の遅延に関する問題には、“特定の画面だけ表示に時間がかかる”、“商品検索結果の表示が遅い”という画面上で容易に確認できるものから、“バッチ実行がなかなか終わらない”など、ログ等を確認しないと把握しにくいものまで、様々な事象があります。
こういった性能問題は、開発メンバーからの報告やちょっとした相談等、ささいな連絡から発覚することがほとんどです。まずは起こった事象を正しく把握するために、連絡内容を基にログの事実確認から着手します。思い込みや勘違いの可能性がないか、現場環境特有の事象でないかを含めて確認することがポイントです。
例えば、画面表示の応答時間に関するものは、ブラウザの検証ツールを利用して計測しなおすことから始めましょう。Google ChromeでもMicrosoft EdgeでもキーボードのF12ボタンで開発者ツールを呼び出すことができ、ネットワークタブでどのリソース読み込みに時間がかかっているかを確認できます。
また、AWS X-RayやDatadogなどのAPM（Application Performance Monitoring）ツールを利用すると、様々な指標をWeb画面上から確認できるため、強力な情報収集ツールとして機能することでしょう。
【2】情報分析により原因を推測する
事象の事実確認ができたら、改善策の検討に取り掛かる前に、もう少し情報を収集して原因を分析します。
情報収集には、以下のように様々な観点があります。
①その事象がいつから発生しているのか
②リリースやシステム構成変更などの環境変化があったのか
③アクセス数や関連するデータ量が急激に増えていないか
④外部から攻撃などを受けていないか
⑤外部連携システムのAPI（Application Programming Interface）連携などで通常よりも時間がかかっていないか
⑥CPUやメモリなどリソース使用量に変化がないか
発生事象に応じて関連性が高いものから優先的に確認します。例えば、それまでは問題なく使用できていたWeb画面の表示が突然遅くなった場合には、環境変化や外的要因に起因する事が多いため②⑤④③の順に確認していきます。一方バッチ処理の遅延時には、発見から時間経過していることもあるため①②③⑥の順に確認していきます。
そうすることで、少ない工数で原因を特定でき、そこから有効的な対策案を導出できます。
ちなみに、DBへのクエリ応答時間がボトルネックだと特定できた場合、Amazon RDSを利用している環境では、Performance Insights という分析ツールが利用できます。
このツールを利用すると応答時間が遅くなっているクエリ（SQL）やリソースを多く消費しているクエリを簡単に見つけることができます。
Amazon RDS での Performance Insights
(https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.html)
【3】将来を見据えた対策を行う
特定できた原因について対策を行う際、すぐに取り組めるものと時間をかけて恒久的に取り組むべきものがあります。
・すぐに取り組めるもの・・・DBへのインデックス追加、キャッシュ機構の導入、など
・恒久的に取り組むもの・・・非同期化、アーキテクチャの見直し、など
DBへのクエリ応答時間がボトルネックの場合、DBへのインデックス追加で解決するような事象であればよいのですが、それだけでは完全に解決しないものもあります。例えば、NoSQL系DBを利用している場合、各製品の特長を生かす改善策が必要になってきますし、データ構造そのものを見直す必要性も出てくるかもしれません。
また、DBアクセスに起因するもの以外では、大きな実装方針変更を検討した方がいい場合もあります。
具体的には、キャッシュ機能の導入、メッセージキューなどでの非同期化、スケーリングを考慮したPub/Subモデルに基づくアーキテクチャの採用、利用しているフレームワークの見直し、システム構成のモダナイゼーションなどが対策候補案としてあがってきます。
ただし、現実的にはコストや時間的な制約により選択肢が絞られます。候補案の中から現実的で最良な対策案を選択する際に重要な判断ポイントがあります。
それは“将来を見据える”ということです。
サービスやシステムがおかれている現況を正しく理解し、将来像に合った対策案を選択することによって、長期的に安定した運用保守が実現しやすくなります。
【4】効果を測定し、追加対策の要否を判断する
対策が完了した後は検証環境などで、事象が改善されているか時間を計測しましょう。
その際、注意点として、本番環境と同程度のデータ量やマシンスペックで計測する必要があります。
性能問題が解決したかどうかは、事前に設定した目標値を達成したかどうかが判断基準となります。
目標値がない場合でも、処理時間の遅延問題であれば当初よりも時間短縮などが図れれば成功と言えるでしょう。
ただし、そこで止めていいのか、追加で他の対策を講じる必要があるかどうかは、プロダクトオーナー、開発責任者などのステークホルダーと相談、協議が必要となります。
追加対策が必要との判断が下れば、また1から順に対応を進めていくことになります。
さいごに－どこまでやるか、どうやってやるか－
富士ソフトには性能問題を解決できるエンジニアが多数在籍しています。
性能問題は様々な原因があり、対応策もケースバイケースであることがほとんどですが、本コラムにて紹介した手順を踏むことで解決可能です。
今回紹介した“将来を見据えた”対策提案については、富士ソフトのBizDevOpsサービスが得意とする領域であり、お客様のコスト面を考慮しつつ、事業成長を実現するための性能改善をご提供可能です。
ぜひ、お気軽にご相談ください。
※BizDevOpsとは、企業のビジネス（Business）、開発（Development）、運用（Operations）の3つの部門が連携してビジネスの生産性向上を目指す概念です。
