性能試験環境は、本番環境に近いハードウェアやネットワーク構成を用意し、実際の利用を想定した負荷をかけるための環境だ。更新したシステムを公開する前にストレステストを実施し、性能低下やボトルネックを発見できる。

　一方で、本番環境に近い規模のインフラをもう1つ用意すれば、クラウドサービスの利用料は増加する。システムの構成やデータを本番環境と一致させ続けるための運用工数も必要だ。

　Pelotonの性能試験環境には、次のような問題があった。

• 本番環境と重複するインフラコストがかかる
• 分散システムやデータの違いにより、本番環境を正確に再現できない
• 環境の維持や更新が複雑になる
• 開発者が機能開発に使える時間を奪う

　Pelotonでサイト信頼性エンジニアリングを担当するアレックス・ナイダーバーグ氏（ディレクター）によると、環境間の差は、キューやデータベース、サービス間の連携方法だけではない。試験に使用するデータにも違いが生じる。

　わずかな差であっても、性能試験の結果に「混在したシグナル」が生まれ、実際の本番環境とは異なる情報を基に判断することになる。ユーザーの行動を想定してテストデータを作る過程でも、設計者の仮定が入り込む。

　本番環境と性能試験環境を同一に保つための費用は、インフラ料金だけではない。システムや機能を変更するたびに、2つの環境を同期させるエンジニアの作業も発生する。

　Pelotonは、性能試験環境への投資に十分な効果がないと判断し、環境そのものを廃止した。現在、エンジニアはローカル環境で開発し、本番環境に近いステージング環境をリリース前の最終確認に使用している。大規模な負荷試験は本番環境で実施する。

コストを「財務部門の課題」から「性能指標」に変える

　Pelotonは性能試験環境をなくす際、コスト最適化を財務部門だけの課題として扱うことをやめた。クラウドコストを、遅延や稼働率と同様に、エンジニアが継続的に観測し、改善する指標と位置付けた。

　同社は、コスト効率と開発効率を関連付け、エンジニアリング上の問題として分析する。個々のサービスやコンポーネントにかかる費用は、特定の管理者だけが確認するのではなく、開発組織全体に公開する。

　Pelotonのエンジニアリング担当シニアディレクター、タク・カリーム氏は、同社が目指す情報共有の仕組みを「情報の冷蔵庫ではなく、情報の炉をつくる」と表現する。

　情報を1つの保管場所に閉じ込め、必要な人が探しに行くのではない。常に更新される情報を見える状態にし、誰もがコストや性能を基に意思決定できるようにする考え方だ。

　オンコールを担当するエンジニアは毎週集まり、担当サービスの性能とコスト効率を確認する。この会議には経営層や他のエンジニアも参加できる。各チームは改善事例を共有し、別のチームが同じ方法を利用できるようにする。

年最大のアクセス集中をどう乗り切るのか

　Pelotonが毎年、特に警戒するのが、米国の感謝祭に開催するライブレッスン「Turkey Burn」だ。同イベントはPelotonの年間最大のアクセス集中を引き起こす。2025年には、約3万4500人が同一のレッスンに同時参加した。

　Turkey Burnのタイミングで十分な処理能力を確保できなければ、ユーザーがレッスンに参加するまでに3～8分程度の遅延が生じる可能性がある。Pelotonは、このような遅延を許容できない。

　そこで同社はアクセスの急増に備え、目標とする負荷水準までインフラを事前に拡張する。そこで使用するのが、社内ツールの「Auto Left」と、オープンソースのKubernetesクラスタ自動拡張ツール「Karpenter」だ。

　クラスタの空き容量がトラフィックの増加によって不足した場合、2つのツールを連携させ、AWSの仮想マシンサービス「Amazon Elastic Compute Cloud」（Amazon EC2）インスタンスを2分未満で増設する。

　Pelotonは、データベースへの長時間のクエリによって処理能力が圧迫されることを防ぐ「Gatekeeper」も開発した。市販の監視ツールやクラウドサービスと、自社の要件に合わせた社内ツールを組み合わせている。

　ツールの開発方針についてカリーム氏は、「購入できるものは作らないが、購入できないものは作る」と説明する。標準的な機能で要件の80％を満たし、残る20％を自社開発で補う考え方だ。

正常時ではなく「壊れたとき」の動作を設計する

　性能試験環境を廃止すれば、負荷試験は実際のユーザーが利用する本番環境で実施することになる。そのためPelotonは、全てが正常に動いた場合ではなく、何かが故障した場合にシステムがどのような挙動を起こすかを基準に設計する。

　各チームは、サービスが利用できなくなった場合や、処理能力の上限に達した場合に何が起きるかを検討する。特に、常時利用可能でなければならない機能を「Tier-0」に分類し、優先的に保護する。

　障害発生時にもユーザーが運動を続けられるよう、レッスンの動画や運動メニューなどを端末に一時保存する仕組みも用意する。全機能を維持できない場合にも、主要機能だけを残す「グレースフルデグラデーション」も採用する。

　本番環境で実施する負荷試験は、意図的なシステム障害を起こして耐障害性を検証する「カオスエンジニアリング」の一種でもある。Pelotonは影響が比較的小さい時間帯を選び、予想される最大容量の2.5倍に相当する負荷を戦略的にかける。

　異常を検知した場合は試験を即座に停止し、問題を修正してから再開する。この方法により、処理能力の限界を実際の環境で確認する。

　障害を前提とした設計ができていれば、性能問題に備えて必要以上のインフラを確保する必要もない。実際に必要な処理量と、割り当てるリソースを近づけられるためだ。

本番環境での試験に必要な「5つの前提条件」

　カリーム氏は、性能試験環境の廃止を検討する企業に対し、あらかじめ整備すべき5つの条件を挙げている。

1．確立されたオブザーバビリティの仕組み

　サービスごとの遅延、エラー率、リソースの飽和状態をほぼリアルタイムで把握できなければ、試験を停止すべきタイミングを判断できない。

2．試験を即座に停止できる自動制御の仕組み

　担当者が異常に気付き、別の担当者へ連絡して手動で止める仕組みでは、対応が遅れて実際のユーザーに影響が及ぶ恐れがある。

3．Tier-0サービスの特定

　システム全体に意図的な負荷をかける一方で、絶対に停止させてはならないサービスを明確にする。

4．試験用トラフィックを実際の利用データと区別する仕組み

　負荷試験に使う仮想ユーザーの操作が、利用者数や課金、行動分析の集計に混ざらないようにする必要がある。

5．個人を責めない事後検証の文化の醸成

　試験中の異常や障害が責任追及の材料になれば、チームは失敗を共有しなくなり、学習の機会が失われる。

　ナイダーバーグ氏は、障害が壊滅的かつ元に戻せない結果をもたらすシステムでは、本番環境を実験の場にすべきではないと指摘する。

削減額だけでは判断できない　追跡すべき指標は

　性能試験環境の廃止が成功したかどうかを判断するため、Pelotonはクラウドサービスの利用料だけでなく、運用品質や改善速度も確認している。

　ナイダーバーグ氏は、主に次の指標を追跡すべきだとしている。

• ピークイベント1回当たりの費用と前年比
• 試験によって生じた異常を検知するまでの平均時間
• 負荷試験で発見したスケーリング関連のボトルネック数
• オンコール担当者の負担や働きやすさ
• ボトルネックの発見から修正版の公開までの時間
• 売上高に占めるクラウドコストの割合
• 社内ツールが別のチームでも再利用された割合

　社内ツールの再利用率が低ければ、チームごとに個別の仕組みを作っている可能性がある。こうしたツールが増えれば、将来の保守負債につながる。

いきなり大規模な負荷をかけない

　カリーム氏は、以前は負荷試験を重視し過ぎていたと振り返る。負荷試験で分かるのは、システムの各要素が想定通りに動くという前提の下で、どの程度の処理が可能かということに過ぎないためだ。

　本番環境での試験では、小規模な負荷から始め、問題がないことを確認しながら段階的に拡大する。キルスイッチと異常検知も、試験を開始する前に用意する。

　Pelotonは現在、システムが突発的な障害に対応できるかどうかを確認する試験を毎月実施している。

　同社にとって、インフラの変更自体は最終目的ではない。基盤を安定させ、その存在をユーザーや製品開発チームに意識させないことで、エンジニアが利用者向けの機能開発に集中できる状態をつくることが目的だ。

　性能試験環境の廃止は、大幅なコスト削減につながる可能性がある。一方、監視や自動停止、障害時の縮退運転、組織文化まで含めて設計できなければ、本番環境での試験は単なる危険な実験になる。Pelotonの事例は、削減する環境だけでなく、その代わりにどのような運用能力を持つべきかを示している。