DXの推進に取り組んでいる組織では、ビジネスアジリティ実現のため、アジャイル開発を導入することが増えてきています。しかし、ウォーターフォールからアジャイルに切り替えている現場では、ウォーターフォール型とは異なりアジャイルでは性能担保の実現方式が定まっておらず、品質担保に課題がある場合が多いです。結果ビジネスアジリティに追従できず、継続的なリリースで徐々に性能が劣化していく懸念があります。
これにはいくつか理由があり、まず初めにウォーターフォール時代は性能試験の担保の仕方はシンプルで、商用と同等の環境を整備して負荷をかけ判定でするだけでした。しかし、アジャイルでは以下の2つの特徴から性能担保が課題となってきます。
・継続的な開発
・ウォーターフォールに比べて開発期間が短縮される
現に私たちの組織でも性能試験の需要が減り、性能問題解決が年々増加傾向にあります。本稿では、アジャイル時代に合わせた①リアクティブアプローチと②プロアクティブアプローチによる解決方法をお伝えします。
解決アプローチ
リアクティブアプローチ：高速原因特定・問題解決
全てのスプリントで性能試験を実施することは困難です。段階的に実現できたとしても初めのうちは、数スプリント単位か、重要なリリース時、もしくは未実施でリリースする場合もあるかもしれません。その場合は本番環境での性能問題発生を許容し”高速に改善”するリアクティブなアプローチが有効です。
端的には問題を検知直後に初動の解析及び改善案まで含めることで、性能問題におけるビジネスインパクトを最小限にします。これを仕組みで実現するのが、下記のオブザーバビリティです。
【監視からオブザーバビリティへのシフト】
高速に改善するためには、原因の特定まで高速に行える仕組みが必要です。そのためには従来の何が起きたかを検知する「監視」ではなく、検知後に、そのアラートがいつ、どこで、どのような原因で発生してかまで一気通貫で特定するための「オブザーバビリティ」というアプローチが有効です。オブザーバビリティは従来の監視（Metrics）に加えて、イベントを記録するログ（Logs）やリクエスト内のコンポーネントを関連付けるトレース(Traces)を紐づけ、3つの観点により事象発生から原因の特定までを高速化します。
- DynatraceやNew Relicといった有償のAPM(Application Performance Management)を導入するか、観点ごとにOSS（例：Metrics: Prometheus, Logs: Loki, Traces: Jager）を用いて実現する。
- 監視とは異なり、環境が整えば誰でも原因特定が可能ではないため、オブザーバビリティを熟知し、改善案まで検討できるエンジニアが運用に参画する。
ここでは通常の監視から移行した場合に見落とされがちなMetricsについてもう少し説明します。Metricsは監視ということで一般的なOSリソース監視や死活監視のまま現状維持を考えてしまいがちですが、性能観点で見直す必要があります。ミドルウェア監視や現在のトランザクション数（アクセス先ごとであれば尚望ましい）、Response Time、マネージドサービスであればスロットリングの監視を組み込むべきです。
プロアクティブアプローチ：Performance QA（PQA）チームを組織して対応
アジャイルの性能試験は究極的にはSprint毎に実施できるのが理想です。これはウォーターフォール型と比べて、性能試験をより高速化することを意味し、自動化が一つのゴールとなります。
つまり、従来の性能試験の要素に加えて高速化や自動化という要素が絡んできます。そこで性能専任のエンジニアを既存の横断的なチーム（QA等）に統合し、これらの要素に取り組みます。
以下にPQAが取り組むべき要素を時系列に近い形で記載します。特に自動化は最後に取り組むべき課題です。下記の1～3の項目の前に自動化を実施してしまうと、試験は毎回実施しているが、何が担保されいるのか良くわからないシステムとなってしまうからです。以前、携わった案件ではお客様がすでに機能試験と同様の仕組みで性能試験も自動化を進めていましたが、SLAや評価すべきメトリクスが定義されておらず、自動化を実現しても品質が担保できない状態であったため、SLAの再定義から行い、品質を担保できる状態にした上で、自動化の検討を行いました。
【PQAが取り組むべき要素】
1.スプリントライフサイクル計画
最終的には全スプリントでの試験が理想ですが、それには自動化が前提となります。そのため初期の段階では性能試験のインターバル期間や、重要なリリースで試験を計画したりなど、アジリティやアプリケーションの特性に合わせて実施頻度やタイミングを策定します。
2.SLAの定義と評価方法
遵守すべきSLAを定義し、これをビジネス変化に合わせて定期的に見直します。評価のためには、ランニングコストを考慮しながら、試験環境を本番同等か1/Nの構成を選択します。1/Nの場合はスケール性を考慮したうえでベースラインを定義し測定し、当該ベースラインをもとに机上で検証します。ただし、スケール性はMWやアーキテクチャによって常に線形するわけではりません、そのことをリスクとして考慮し、最低一回はスケール性を確認する試験を行っておくことをお勧めします。
3.性能試験の標準化
各スクラムチームで実施する性能試験の計画、実施、評価までを横断的に標準化します。
4.段階的な自動化の実現
段階的に自動化の範囲を拡張していきます。比較的実現しやすい順としては①試験の実施、②評価、③試験レポート、④負荷モデルの作成、⑤試験シナリオの生成があげられます。ただ④と⑤については大きなリクエストの変化がない場合は、変更頻度が少ないため自動化の恩恵は少なくなるため、対象外とする判断も必要です。
まとめ
アジャイルで陥りがちな性能担保の課題に対する解決アプローチをご説明いたしました。アジャイル開発では、性能担保もアジャイルの名のごとく、高速化が重要なキーとなります。ただし、上記で挙げた要素をすべて網羅しようとするのではなく、まずはリアクティブなアプローチ、次にプロアクティブなアプローチとアジャイル開発と同様に継続的に実施し改善していくことが性能担保の近道となります。