サポート

CIでのパフォーマンス・テスト:リリース後の速度低下を防ごう

Joseph Wynn

2019年6月19日水曜日

高速なウェブサイトの作成に膨大な時間を費やしてしまった経験はありますか?新機能、微調整、重要なトラッキングスニペットの追加はすべて山積みになり、速度が低下します。その後「パフォーマンス重視」の許可が与えられ、対策を繰り返すとウェブサイトは再び高速になりました。しかし、数ヵ月後、再び減速し始め……と、このサイクルが繰り返されます。

そもそもパフォーマンスの低下を防ぐ方法があるとしたら?パフォーマンス要件を満たしている場合にのみ本番コードの変更を許可する、ある種のパフォーマンスゲートウェイのようなものでしょうか?パフォーマンスが低下した場合にビルドを中断するということについて話し合った時だと思います。

より高速なウェブサイトの秘訣は?ビルドを止める!

もし「ビルドを止める」ことがあなたにとって海外的な考え方であるならば、説明させてください。CI(継続的インテグレーション)は、合理化されたソフトウェア配信への第一歩です。十分に自動化されたテストを行えば、独立した変更を構築し、他のものを破壊することなく統合することができます。自動テストのいずれかが失敗すると、ビルドが止まり、変更を統合できなくなります。

この概念は、テスト環境またはステージング環境への変更の自動展開(連続配信)、より自動化されたテストの実行、および人が手を加えない本番環境への変更の展開(継続的な導入)によって、さらに拡張できます。

合格基準としての性能

CIとの関連で自動テストと言えば、機能テスト、つまり機能が期待通りに機能するかどうかをテストすることを指します。通常、パフォーマンスは機能に影響しないため、多くの場合、受け入れ基準のリストには含まれません。しかし、パフォーマンスの低下を防止することが目標である場合、パフォーマンスは、合格基準において必要機能ではないものとする必要があります。 パフォーマンスが標準に達していない場合は、ビルドを中断して変更が反映されないようにすることができます。

 

パフォーマンスがCIパイプラインに適合する場所

では、CI/CDパイプラインのどこにパフォーマンス・テストを置くのでしょうか。簡単に答えると、変更されるのは、統合環境またはテスト環境にデプロイされた直後です。通常、パフォーマンス・テストは統合テストおよび受け入れテストを同時に行う必要があります。もう少し複雑に答えると。パフォーマンス・テストを正確に行うためには、統合環境を本番環境にできる限り近づける必要があります。次に、統合環境でパフォーマンス・テストを実行する際に考慮すべき事項を(完全に網羅しているわけではありませんが)簡単に示します。

  • キャッシュは事前にウォームアップする必要があります。通常、本番環境のキャッシュ・ヒット率は高く、これはパフォーマンス・テスト中に複製する必要があります。
  • システムリソースが制約となる場合は、パフォーマンステストを単独で実行することをお勧めします。統合テストまたは負荷テストと同時に実行すると、リソースの競合が発生し、パフォーマンスに悪影響を及ぼす可能性があります。
  • ネットワーク・レイテンシーは、パフォーマンス・テストに影響します。CDN経由で本番環境にアクセスする場合は、同じCDNを使用して統合環境を実行してみてください。

ビルドを中断することなくCIのパフォーマンスを向上

わかっています。この記事のタイトルには、速くするためにはビルドを中断する必要があると書かれています。実際には、多くのソフトウェアデリバリチームはこれを行う立場にありません。私が一緒に仕事をしてきたほとんどの利害関係者は、重要な機能やバグ修正をブロックすることは、パフォーマンステストに失敗するからといって受け入れられないと感じていました。

しかし、ありがたいことに他の選択肢もいくつかあります。まずは、ビルドを止めてスピードを維持するという最重要目標から見ていきましょう。

 

パフォーマンスの低下を食い止める

パフォーマンステストが完了するまでビルドはブロックされ、パフォーマンステストが失敗するとビルドも失敗する可能性があります。このオプションは、他の作業を継続する前にパフォーマンスの問題を解決する必要があるため、すべてのレベルから100%の賛同を得たチームでのみ機能します。

長所

  • パフォーマンスを第一級の許容基準として扱う。
  • チームが作業のパフォーマンスを管理するための完全なフィードバックループを作成します。
  • パフォーマンスの低下は、本番稼働前に検出されます。

短所

  • ビルドタイムが増加します。
  • チーム全体からの賛同が必要です。

パフォーマンスの低下を報告しますが、ビルドを中断しません

パフォーマンステストが完了するまでビルドをブロックできますが、これは必須ではありません。パフォーマンステストの失敗は報告されますが、ビルドは失敗しません。このオプションは、パフォーマンスの低下を真剣に考えている強力なパフォーマンス文化を持つチームに有効です。パフォーマンスの問題がビルドを妨げたり、重要な作業を遅らせたりすることはありませんが、優先順位の高いものとして扱われ、タイムリーに対処されます。

長所

  • チームがパフォーマンスの低下を修正するための実用的なフィードバックループを提供します。
  • パフォーマンスの低下は、本番稼働前に検出できます。
  • 本番環境への導入を妨げることはありません。

短所

  • パフォーマンスの低下を防ぐために強力な規律が必要です。

レポートを作成せずにパフォーマンス・テストを開始

パフォーマンス・テストはビルドの一部として起動されますが、何もブロックしません。このオプションは、パフォーマンスのモニタリングを始めたばかりのチームや、発生した後退を修正するのではなく、定期的な「パフォーマンススプリント」を行うことを好むチームに適しています。

長所

  • パフォーマンス低下の原因となったビルドを遡及的に特定することに使用できます。
  • チームメンバーの同意は不要です。
  • 後で簡単に他のオプションに変更できます。

短所

  • パフォーマンスの低下を防ぐために、強力な規律が必要です。
  • パフォーマンスを「持っていると良い」機能と考えたり、完全に忘れたりすることが容易になります。

 

SpeedCurve CLIを使用したパフォーマンスの監視

SpeedCurveは最近正式なCLIとNodeをリリースした。このAPIは、CI/CDパイプラインの一部としてのパフォーマンス・テストの実行を単純化します。以下にいくつかのコマンド例を挙げて、その使い方を説明します。

 

オプション1:

パフォーマンスの低下を回避します。

パフォーマンステストを実行し、完了するまで待機します。完了すると、

パフォーマンスパジェットのステータスと、ゼロ以外の終了コードで終了(存在する場合のみ)。パジェットが破壊されました。

⇒speed curve deploy–check-budgets

オプション2:

パフォーマンスの低下を報告していますが、ビルドを中断しないでください。

パフォーマンステストを実行し、完了するまで待機します。次に「パジェット」を使用します。

コマンドを実行すると、すべてのパフォーマンスパジェットのステータスがJSONとして出力されます。

⇒ speedcurve deploy –wait

⇒ speedcurve budgets –json

オプション3:

レポートを作成せずにパフォーマンス・テストを開始します。

パフォーマンステストを実行しますが、完了まで待機しません。–noteフラグ

では、SpeedCurve内の配置に注釈が付けられ、次の場合にこのビルドを識別できるようになります。

パフォーマンスの低下を後日見直せます。

⇒speedcurve deploy –note v2.48.0-b28bc40

 

SpeedCurveのCLIを自分で試してみたい人は、GitHubプロジェクトのインストール手順と使用例を見てください。SpeedCurveのアカウントを持っていない場合は、無料トライアルを開始すると数分以内にページのテストを開始できます。

関連記事

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

CAPTCHA