こんにちは、プログラマのkinoppydです。私の働いているプロダクト基盤チームでは、現在全プロダクト横断従業員検索システムを作成しており、旧システムとのリプレースを行っています。その際に我々が採用した、†ダークローンチ†という手法を皆さんにお伝えしますので、ぜひ参考にしてください。
ダークローンチとは？
ダークローンチとは、リリース手法の一つです。すでに稼働しているサービスのトラフィックをコピーして、新たにリリース予定のサービスに対してそのトラフィックを流し、レスポンスを記録しつつ破棄するという形のリリースです。すでに稼働しているサービスから見ると、トラフィックをコピーされる以外は何も変わりません。ダークローンチは、実際のサービスのトラフィックを利用することで、シナリオテストよりも遥かに実態に即したテストが可能であり、かつ既存のユーザーに一切の影響を与えないことがポイントとなっています。
他にも解説のページがあるので、詳細はリンク先を読んでください。
似たリリース戦略にカナリアリリースやA/Bリリースというものがありますが、どちらも本番環境の数%を検証用の環境に置き換える必要があります。それに対してダークローンチはユーザーから見ると完全に現状と変わらないレスポンスを得られる、トラフィックの全てでテストを行えるので網羅率が高い、というメリットがあります。反対に、ダークローンチは本番と同等のトラフィックを捌き切る必要があるので、検証用の環境で本番と同等のインフラが必要とされ、コスト面でデメリットがあります。
ダークローンチを実施する際、トラフィックのコピーを行い本番と新環境に振り分けてくれるツールをシャドープロキシと呼びます。シャドープロキシにはFluentdを使ってアクセスログからリクエストを再現し新環境に送る方法や、Nginxの拡張を使って直接コピーを送信する方法などがあります。今回我々が使用しているシステムは、Apollo FederationというGraphQLを束ねるシステムだったため、その大本であるApollo Routerに付随するco-processorというサイドカー機能を使いました。実装はExpressです。Apollo Federationに関しては、こちらの記事も御覧ください。
ダークローンチの実施
ダークローンチの実施にあたり、我々のチーム内での検討内容と実施方法を紹介します。
プロダクト連携チームでのダークローンチ戦略採用理由
プロダクト連携チームでは、以下の理由からダークローンチ戦略を採用しました。
- テスト対象が、既存のシステムとほぼ同等のレスポンスを期待される置き換えシステムのため
- 新システムの正常動作確認が、レスポンスを比較するだけでできる
- シナリオテストだけでは網羅できない複雑性がある
- 検索システムなので、ユーザーのクエリは無限大
- 思いがけない見逃しや組み合わせなどを考えるより、本番のクエリを模倣したほうがよい
- 書き込みがあるシステムではない
- 検索システムなので、書き込みが発生しない
- 同時に、自分自身のデータベースをもつ必要もなく、インフラ構築が比較的容易
- まだ社内で広範囲に使われているシステムではなく、インフラが小規模
- 現状、CloudRunが1台で十分に動いている
- 一方で、検索ロジックそのものは分散して動いているため、新しいインフラでどの程度耐えられるのかは未知数
- どの程度既存とスピード差があるかもダークローンチの指標に出来る
- パフォーマンスの比較もできる
- 実際のレスポンスと、ダークローンチしたシステムのレスポンスの時間を比較できる
新システムを、本番のクエリで検証できることが大きな採用理由です。あとはついでですが、インフラの妥当性チェックと簡易的なパフォーマンスの比較もできるのが嬉しいです。
連携チームでのダークローンチの効果測定は、レスポンスの正しさ
通常であれば、ダークローンチの実施は非常に入念な準備が必要です。目的によりますが、多くのダークローンチではエラーレートの計測やSLOを満たすパフォーマンスを発揮するかどうかを、ダッシュボードやログ分析などの手法で行います。そのために、トラフィックに対して新旧どちらのシステムが処理したものなのかを判別できるようにタグ付けし、専用の分析ダッシュボードを用意する、レスポンスが異なる場合のトレースを行えるようなクエリを用意する、などの準備が必要になります。
今回、プロダクト連携チームが必要としたのは、検索システムのクエリとレスポンスに対する同一性です。もちろんパフォーマンス計測も実施はしますが、あくまで検索結果の比較がプライマリターゲットでした。そのため、用意するためのパーツも非常に小さく、本来のダークローンチよりも遥かに少ない手順で実施することができました。
スプレッドシートを利用した全件記録
実施したダークローンチの構成図は以下のとおりです。
検索サービスの本番/検証のレスポンスの記録を行うシャドープロキシには、Apollo Routerと連携してして動いているco-processor（Apollo Routerの各動作に連携しているサイドカーコンテナ）からGoogle Spreadsheetのwebhookにアクセスすることで実現しています。
スプレッドシートに以下のGoogle Apps Script（以下GAS）を設定します。
function doPost(e) {
const postContent = e.postData.getDataAsString()
const json = JSON.parse(postContent)[0]
const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet()
sheet.appendRow([json.id, json.stage, json.value, json.timestamp, json.subdomain])
}
sheet.appendRow している内容は、このwebhookにアクセスする際に送るJSONに合わせて修正してください。
GASを設定したら、このスクリプトをWebアプリケーションとしてデプロイします。
あとは、co-processorの方から、このwebhookのURLに対して、JSONを送ることでどんどんスプレッドシートに結果が記録されていきます。
分析には、同じくGASを使います。どんな分析をしたいかはチームによって異なると思うので例は挙げませんが、我々は「リクエスト、本番のレスポンス、新システムのレスポンスを１セットとして、リクエストのクエリに対してそれぞれのシステムが返した結果を比較する」というスクリプトを書きました。
これにより、非常に低コストでダークローンチの検証用データストアと、分析用スクリプトを実行する環境を得ることができました。
スプレッドシートを使った分析の欠点
スプレッドシートは非常に低コストで用意できる素晴らしいデータストアですが、問題もあります。
例えば、webhookへのアクセスとGASにそこそこの時間がかかるため、同時に大量のリクエストを実施すると、時々取りこぼしが発生します。データ連携チームではある程度の取りこぼしを許容しましたが、確実にすべてを記録する必要がある性質のシステムだと、この問題は無視できません。
また、ログ分析などに比べて欠落している情報が多いため、スプレッドシート単体では高度な分析には向きません。今回はレスポンスと実行時間の２点だけを重点的にチェックするだけだったため問題はありませんが、SLOなどをきちんと計測したい場合は不向きでしょう。
まとめ
ダークローンチは、既存のシステムと新システムを並行動作させながらトラフィックのコピーを双方に流し込みます。これによって、本番と完全に同等な条件で新システムをテストできます。また、旧システムのレスポンスのみがユーザーに届くため、テストの影響がユーザーの不利益になることがないという特徴を持っています。
データ連携チームでは、新システムの性能評価のためにスプレッドシートのwebhookを使いダークローンチの実施を行いました。結果、GASを利用した分析で、シナリオテスト時に見落とされていた問題などを発見することができました。
We Are Hiring!
プロダクト連携チームでは、SmartHR内の様々なプロダクトをつなぐための開発を、こんな感じにダークファンタジー感を出しながら頑張っています。ぜひ皆さんも、SmartHRの開発に参加して、汝のうちに秘めたる闇の力を解き放ってみないか？
