ダークローンチは最高のライトローンチです

イースターエッグだらけ

以前の職場では、Eコマース企業向けに商品レコメンダーシステムを構築していました。つまり、私たちのAPIは彼らのウェブサイトのあらゆるページで稼働していました。初めての7桁契約となる新規顧客を獲得し、私たちは非常に慎重に対応しました。そのため、当初は3月にルールベースのレコメンデーションで彼らをオンボーディングしました。まだ未熟な機械学習モデルによって、ユーザーエクスペリエンスを損なうリスクを冒したくなかったのです。

その後4月には、機械学習モデルを構築し、広範なオフラインテストと多くの手動QAを実施しました。最終的に、モデルがうまく機能すると確信し、ローンチしたところ、2つの問題が発生しました。

1. 緊急電話： 私たちはすでにレコメンデーションの結果に困惑し、デバッグを試みている最中でしたが、数分後、彼らから緊急の電話がかかってきました。 彼らのウェブサイトのほぼすべてのページに、イースターエッグのレコメンデーションが表示されていました。 なんと、4月にイースターのショッピングデータで学習させたモデルと、モデルIDを誤って設定していたことが判明したのです！すぐにモデルIDを新しいものに切り替えたところ、その問題は解決しました。
2. p90レイテンシの増加判明したのは、モデルで商品説明を特徴量として使用しており、一部の説明が非常に長かったため、特徴量計算時間が増加していたことでした。オフラインテスト中には、ほとんどの場合でモデルのレイテンシが問題なかったため、これは検出が困難でした。この問題に対する即座の有効な解決策はなく、特徴量化を修正してモデルを再テストするまで、基本的にルールベースのシステムに戻さざるを得ませんでした。

結果として、多くの緊急対応に追われ、信頼を大きく失い、顧客を失いかける事態となりました。その後の社内反省会で、#1は単なる手動ミスであったものの、#2のような問題はオフラインではほとんど検出不可能であったことが判明しました。 それ以来、私たちはダークローンチを行うという明るい側面に移行しました！

ダークローンチとは？

ダークローンチとは、実際のプロダクション環境のトラフィックを新しくデプロイされたサービスにリプレイし、その応答をユーザーに返す前に破棄するデプロイ戦略です。サービスが実際に稼働しているかのように振る舞いますが、ユーザーには一切影響を与えません。これにより、新しいサービスにエラーがないか、古いサービスと比較して同等かそれ以上のパフォーマンスを発揮するか、そしてプロダクションの負荷を処理できるかを確認できます。これらすべてが検証されれば、新しいサービスに段階的に切り替えることはほとんど容易になります。つまり、

ダークローンチは、サービスをリリースする上で負担の少ない方法です。

デメリットはごくわずかで、大きな潜在的メリットがあります。

ダークローンチの実施方法

サービスのダークローンチは、本番環境に近いシステムでサービスやモデルをテストする現実的な方法の一つです。しかし、ダークローンチの実施には、開発、監視、インフラの観点から、組織内で多くの準備と成熟度が必要となる場合があります。

1. マイクロサービスアーキテクチャを採用する: 新しいサービスを段階的にテストできるように、API駆動型マイクロサービスアーキテクチャを採用することが重要です。ダークローンチを実行する方法は、本番トラフィックのコピーを新しいバックエンドにリプレイすることです。これは、現在の本番サービスと新しいサービスの両方がマイクロサービスとして利用可能で、通信がREST/gRPCコールを介して行われる場合に最適です。
2. トラフィックフォーク: 多くの場合、アプリケーションのフロントエンドでトラフィックフォークが行われ、本番トラフィックの一部が新しいサービスにルーティングされます。
3. 非同期呼び出し: テストの一般原則は、実際の運用環境に悪影響を与えないことです。ダークローンチでは、実質的に本番トラフィックを複製することになり、バックエンドコールを非同期にしない限り、レイテンシが2倍になる可能性があります。サービスがレイテンシに厳しくない場合は、適切なタイムアウトを設定することも解決策となります。
4. インフラストラクチャ: 理想的には、組織は水平方向に容易にスケールできるインフラストラクチャを構築しているはずです。なぜなら、ダークローンチサービスへのトラフィック割合を増やすにつれて、インフラストラクチャも段階的にスケールする必要があるからです。多くの場合、新しいサービスが真にスケールすることを確認するために、ピーク時の全トラフィックとその先を複製することさえ理にかなっているかもしれません。
5. ロギング: レスポンスとサービスパフォーマンスを比較できるように、新旧のバックエンドサービスからのリクエストとレスポンスをログに記録する必要があります。機械学習モデルの場合、モデルの予測が少なくとも古いモデルと同等であることを確認したいでしょう。これには広範なロギングが必要です。
6. モニタリング: 優れたモニタリングおよび計測ダッシュボードがない場合、ダークローンチはほとんど役に立ちません。そこで新しいサービスの稼働時間、レイテンシ、スケーラビリティ、レスポンスの品質を比較できます。理想的には、異常を迅速に検出し表面化できるように、これはリアルタイムで行われるべきです。

ダークローンチは単なる高度なオフラインテストなのでしょうか？

オフラインテストでは、 システムの動作を、通常は分離された環境で。 エンドツーエンドのシステムをテストできることはほとんどありません 、および 本番環境のような現実的なトラフィックとネットワーク設定を持つ周辺システムの状況と合わせて？これらすべてを70%達成することは、綿密なロギングと非常に複雑なオフラインテストを通じて可能ですが、ダークローンチははるかにシンプルなシステムであることがわかります。これは、通常サービスをローンチして監視するために、いずれにせよ上記のほとんどのステップを実行することになるからです。ダークローンチが成功すれば、新しいサービスの実際のリリースはほとんど些細なことになり、労力対効果の比率は十分に価値のあるものになります。

これを実用的に正当化するのが難しいケースがいくつかあります。例えば、 サービスがステートフルである場合、または実際にデータベースを変更する場合、 その場合、ダークローンチを行うことははるかに複雑になります。私個人の経験では、システムの正確性を確保することが非常に困難になるため、 ダークローンチよりもオフラインテストで済ませる方がほぼ良いと言えます！

ダークローンチについてさらに詳しく知りたい方、またはご自身の経験を共有したい方は、nikunj@truefoundry.comまでご連絡ください！

トゥルーファウンドリー は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させるとともに、モデルのテストとデプロイにおいて完全な柔軟性を提供し、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームが デプロイおよび監視 モデルを15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を提供し、コストを削減し、モデルをより迅速に本番環境にリリースできるようにすることで、真のビジネス価値の実現を可能にします。