今日、ユーザーには、 ウェブ サイトの読み込み時間が5秒遅れ、応答時間が8秒を超える場合でも、大きな損失が発生する可能性があるほどのさまざまなレベルのアプリケーションが提供されます。 たとえば、2013年には、Googleのわずか5分間のダウンタイムにより、同社は約545,000ドルを失いました。 同様に、2016年1月、ソフトウェアの更新によりNestサーモスタットが機能しなくなり、多くのユーザーが冷たくなり、後に ソーシャルメディアで問題について怒鳴りました。 また、 アマゾンウェブサービスの 停止により、毎秒1100ドル相当の企業の売上損失が発生したのは、それほど昔のことではありません。
カナリアテスト、その意味、利点、および欠点を見て、その重要性を正当化できるようにします。
セットアップからテスト実行までわずか数分で実行できます。
カナリアテストとは何ですか?
カナリアテスト、カナリアリリース、カナリアデプロイは、 リスクを最小限に抑えながら継続的デリバリーを可能にする手法の代わりに使用される用語です。 このプロセスでは、テストのために選択したユーザー グループにソフトウェア更新プログラムをロールアウトします。 この方法は、過去に炭鉱で有毒ガス検知器として使用されていたカナリアの鳥にちなんで名付けられました。 カナリアは人間よりも有毒ガスに敏感であるため、低曝露レベルですぐに病気になったり死亡したりします。 これは、鉱山労働者が手遅れになる前に鉱山を避難させ、危険から逃れるのに役立ちました。
ロールアウト戦略
同様に、カナリアテストでは、カナリアは最新のソフトウェアアップデートを体験するユーザーの小さなグループであり、そのフィードバックは、開発チームが新しいリリースをすべてのユーザーが利用できるようにするか、変更を迅速にロールバックするかを決定するのに役立ちます。 カナリアテストは、少数の選択されたユーザーのみがルーティングされる別の本番環境で実行される並列変更の適用であり、大部分は古い本番環境に保持されます。 このユーザーの移行は、すべてのユーザーが新しいバージョンに移行するまで続きます。 これは、イノベーションをサポートし、マスレベルでの混乱のリスクを軽減する段階的なアプローチです。
ロールバック戦略
新しいバージョンが非常に誤っていることが判明した場合、本番環境での変更を元に戻すのではなく、 ユーザーエクスペリエンスに大きな脅威をもたらします。ユーザーは安定した古いバージョンにリダイレクトされます。 その間、開発チームはバグ修正に努めています。
選ばれたユーザーは誰ですか?
次の質問は、ソフトウェアアップデートの影響を受けるユーザーは誰になるのかということです。 カナリアユーザーを決定するには、次のようなさまざまな方法があります。
- 彼らは社内またはリモートに分散したテストチームである可能性があります
- 特定の地域から (地理的に分散したユーザーの場合)
- 単一のブランドが最初、複数のブランドの場合
引用できるカナリアテストの最良のアプリケーションはFacebookです。 Facebookは「複数のカナリア」戦略で働いています。 社内の従業員のみが最初に新しい変更にさらされ、すべての機能トグルがオンになって問題を早期に検出します。
カナリアテストの利点は何ですか
何か他のもの と比較するものがない限り、何かの利点を測定することはできません。 したがって、はい、カナリアテストはA / Bテストやブルーグリーンテストと混同されることがよくあります。 しかし、それは両方の長所です。 その理由を見てみましょう。
A/B テスト
実装上、A/B テストはカナリアテストに似ています。ユーザーの50%には、新機能「B」を備えたアプリケーションのアップグレードバージョンが提供されます。残りの 50% のユーザーは、ベースライン機能 “A” を使い続けています。次に、機能リリースの結果を監視して、 期待に反する結果. ただし、A / Bの焦点は、機能が顧客にとってどれほど有用であるかを確認することです。 カナリアテストはリスク軽減のために実行されますが。
ブルーグリーン展開
ブルーグリーン展開は、エンド ユーザーのダウンタイムと中断を排除することに重点を置いています。 変更は、テストが完了すると、すべてのユーザーを古い運用環境から移行するアイドル状態の運用環境で行われます。 ただし、カナリアテストでは、影響を受けるユーザーの量は最初は最小限に抑えられます。
カナリアテストは、A / Bテストとブルーグリーンデプロイの両方の長所であると結論付けることができます。 カナリアデプロイアプローチの利点は、次のようにリストできます。
- イノベーションを支援し、アジャイル開発を促進し、新機能を簡単に展開できるようにします。
- ダウンタイムゼロを保証します。
- これにより、否定的な結果が発生した場合に変更をすばやくロールバックできます。
- これにより、ユーザベース全体にリリースする前に、新しいリリースに送信されるトラフィックを決定するための条件の高レベルの設定が可能になります。
- これにより、複数のチームが本番環境で個々のマイクロサービスを同時にテストできます。
- ブルーグリーン展開とは異なり、追加の環境をテストするためにリソースを拡張する必要はありません。 マイクロサービスごとのリソース戦略がテストに採用されているためです。
- 新しいバージョンの動作は、まったく新しい容量テスト環境を設定する代わりに、運用環境の負荷をゆっくりと増やすことで監視できます。
- これにより、運用環境に複数のバージョンをデプロイできます。 これにより、チームは新しいリリースをテストするために必要な自由度、柔軟性、および速度を得ることができます。
カナリアデプロイとロードビュー
大衆のユーザーエクスペリエンスを損なうことなく、パフォーマンステストの最良の結果を得ることができます。 必要なのは、カナリアデプロイのプラクティスと、パフォーマンステストのメトリックをサポートする優れたテストツールだけです。 カナリア アプローチを使用すると、 LoadView などの高度なソリューションを使用して、パフォーマンス テスト ケースの実行を自動化できます。 これは混乱して複雑に聞こえるかもしれません。 しかし、例の助けを借りてそれを理解しようとしましょう。 たとえば、シングルページアプリケーション(SPA)であるNetflixは、新機能を開発し、カナリアユーザーにリリースします(7,50,000、つまり、2020年の統計に基づく1,500万人の5%)。
現在、DevOpsチームは、このような膨大な数のユーザーを手動で監視することはできません。 したがって、 LoadView は魔法の杖のように機能し、DevOps とテスト チームは数百から数千の 同時ユーザーをスピンアップしてアプリケーションに対して負荷と ストレス テストを行い、その適用された負荷の下でアプリケーションがどのように実行されるかを確認できます。
さらに、 EveryStep Web レコーダー スクリプト ツールを備えた LoadView が魅力的な 選択肢 であるのは、 ロード テスト SPA をサポートしていることです。 SPAロジックは、例えばJMeterのような多くのツールでサポートされていないJavaScript 技術 に依存しています。 JMeterはプロトコルレベルでのみ機能し、ブラウザでは動作しないため、クライアント側のパフォーマンスの多くはパフォーマンステストの結果から除外されます。 EveryStep レコーダーを使用すると、ユーザー シナリオとパスの作成が簡単で、実際のブラウザーを利用できます。 パスを記録し、テストシナリオを設定するだけです。 それは本当に簡単です。
カナリア展開/テストの課題
すべてのコインには2つの側面があります。 カナリアのデプロイ/テスト方法には短所があると言う人もいますが、その課題として次の点を述べる方が適切です。
- DevOpsチームは、ソフトウェアの複数のバージョンを並行して管理する必要があります。 したがって、同時バージョンの数は最小限に抑えることをお勧めします。
- ソリューションソフトウェアがユーザーのデバイスにインストールされている場合、新しいバージョンのアップグレード時に新しいバージョンを完全に制御することはできません。
- カナリアリリース中はデータベース管理が困難になります。
- カナリアテストの実装には、インフラストラクチャとアプリケーションの効果的かつ堅牢な監視のための多大な努力が必要です。
- 各増分リリースの監視には時間がかかり、ターゲット リリース日に影響を与える可能性があります。 カナリアテストには数時間かかる場合があります。
結論:カナリアテスト
結論として、カナリアのデプロイ/テストアプローチは、ダウンタイムなしで実際のユーザーでソフトウェアの新しいバージョンのパフォーマンステストを行うことになると、リスク軽減の次の親友になると推測できます。 Ian Molyneaux 氏が著書「The Art of Application Performance Testing: From Strategy to Tools」
で述べているように、「エンドユーザーが ウェブ サイトからのパフォーマンスの低下に気付いた場合、次のクリックは your-competition.com になる可能性が高い」。それを起こさせないでください。 クライアントと顧客が優れたユーザーエクスペリエンスを得ていることを確認してください。