Aurora MySQLの2系のサポート終了に伴い、Aurora3系への移行が決定しました。それに合わせて、QAチームではAurora2とAurora3で性能に問題がないかを比較検証することになりました。
私は昨年、異業種からキャリアチェンジをしてQAエンジニアになりました。これまでは主にブラックボックステストを担当しており、性能検証は今回が初めての経験でした。
この経験を通じて得た学びと反省点について記録しておきます。
テストの概要と進め方
パフォーマンステストは本番相当のデータ量を用意した環境で実施しました。（本番環境ではありません）
具体的な実施手順は以下の通りです：
- 事前に処理が重いと想定される機能をピックアップしておく。
- Aurora2と3で同じデータ量を使用するため、性能比較検証実施前の状態をスナップショットとして保存しておく。
- アプリケーションで利用するデータベースをAurora2に設定し、手順1で決めた機能の性能検証を実施する。
- 次にアプリケーションで利用するデータベースをAurora2からAurora3に切り替え、手順2で用意したスナップショットを用いてデータベースを復元する。
- Aurora3の状態で、Aurora2と同じ手順で性能検証を再実施する。
- 手順3と5で測定したAurora2と3の結果を比較する。
テストの実施方法
性能比較検証はGoogle Chromeのデベロッパーツールを使用して測定しました。
QAの視点から、ユーザーにとって『使いやすい品質』を維持するため、E2E（エンドツーエンド）のレスポンス時間を重視しました。そのため、ボタンをクリックしてから処理が完了するまでの時間を計測しました。
テスト結果と発生した問題点
テストの結果、特定のデータのインポートおよびエクスポート機能で、Aurora2よりもAurora3のE2Eレスポンス時間が約20%長くなることが確認できました。
計測時間をQAから開発に提供し、E2Eの視点で問題のある機能を報告しました。
この結果を開発チームと共有し、調査を開始してもらいましたが、ここで問題が発生しました。遅延が確認された機能は月に一度しか利用できない仕様であるため、再検証ができませんでした。
さらに、開発チームとしては「どのAPIが遅延しているのか」「どのデータ処理に時間がかかっているのか」を特定したかったのですが、私はE2Eのレスポンス時間しか記録してなく、各APIの処理時間などの詳細なデータを計測していませんでした。
最終的には、当月にリリースされた他の機能によって処理速度が大幅に改善されたため、大きな問題には至りませんでした。しかし準備をしっかりした状態で性能比較検証を行えば、スムーズに開発をすすめられたと思います。
反省点
今回の経験を振り返ると、以下の反省点がありました。
計測だけでなく、調査・改善までを見据えるべきだった
QAの観点からE2Eのレスポンス時間を計測すること自体は正しかったと思います。しかし、問題が発生した際に開発チームが調査しやすいよう、詳細なデータやログを残すべきでした。
実行前の計画不足
テスト実行前に、問題が発生した際の「開発チームの調査プロセス」を十分に考慮していませんでした。その結果、調査がスムーズに進まない原因を作ってしまいました。
今後はどうやって対応していくか
今後は、性能検証を行う際に、単に処理速度を測定するだけでなく、問題が発生した場合にどのように原因を特定し解決するかを意識したデータ収集や設計を心がけたいと思います。
どうやってデータやログを確認するか
具体的には、Google ChromeのデベロッパーツールのNetworkタブを活用していきます。
右クリック→「検証」でデベロッパーツールを開いたあと、Networkタブを選択します。キャッシュの影響をなくすためにDisable cacheにチェックを入れます。
Disable cacheを選択
この状態でリロードすると多くの処理が一覧で表示されます。一覧表示されているままだと見にくいため、フィルター機能を使います。
たとえば、APIの処理時間を測定する場合、Filterの枠に/api/と入力したり、More filtersでFetch/XHRを選択すると絞り込みができます。
フィルター機能で絞り込み
確認したいリクエストのNameを選択すると詳細な情報を確認できます。
詳細な情報としては以下のようなものを確認することができます。
- Headersタブ: リクエストやレスポンスのステータスコードやヘッダー情報を確認可能。通信エラーや遅延要因を特定する際に役立ちます。
- Timingタブ: 通信を開始してから終了するまでの処理順序や各フェーズの時間を確認可能。どの部分に遅延があるかを特定する手助けとなります。
Headersタブ
Timingタブ
時間がかかりそうなAPIや処理を把握しておく
上記でログの確認方法を紹介しましたが、性能比較検証中に詳細なログを残しておかなかった理由の一つは、アプリで使用されているAPIの理解が不足していたためでした。
事前にアプリの機能で処理時間がかかりそうな項目はリストアップできていましたが、その機能がどのAPIを利用しているのか、この機能がなぜ時間がかかるのかといった理解が不足していました。結果として、Networkタブに表示されたデータをうまく読み解けませんでした。
今後は、処理時間がかかりそうな機能をリストアップした段階で、それに関連するAPIの動作や課題を調査し、必要に応じて開発チームに質問することで、必要な情報やログをより適切に残していきたいと思います。
最後に
今回、初めて性能検証を担当する中で、「どのように性能検証を実施すべきか」という点にばかり意識が向き、問題が発生した際にどのような情報が必要かという視点が欠けていました。
この経験を通じて、QAエンジニアとして、単にテストするだけではなく、品質向上のために開発プロセス全体を意識することの重要性を学びました。今後は性能検証を行う際に、ログや記録を残すことを心がけ、開発チームと協力して品質改善に貢献していきたいと思います。
Discussion