この記事は GMOインターネットグループ Advent Calendar 2025 14日目の記事です。
はじめに
こんにちは。GMOペパボ株式会社 EC事業部でエンジニアをしている大浦です。社内では「ユーキャン」と呼ばれています。小学生の頃はハンドルネームに†をつけていました。
普段は、ECサイト・ネットショップをかんたんに構築・開設できる「カラーミーショップ byGMOペパボ」というサービスの開発に携わっています。
今回は、マイクロサービスのリリースプロジェクトを進める上で使った「ダークローンチ」という検証手法について紹介します。
マイクロサービスにした機能
カラーミーショップには「テンプレート」と呼ばれる機能があります。この機能を使うと、独自の記法を用いてショップのテンプレートを記述することで、自由にショップのデザインをカスタマイズできます。
今回、このテンプレート機能のレンダリングシステムを別のマイクロサービスに切り出すことになりました。そこで、この機能をユーザーに影響を出さずに切り出した方法を説明します。モチベーションについても次の節で触れます。
どのようなマイクロサービスの切り出しを行ったか
今までは、ショップページに表示する値を計算するためのロジックと、それを元にレンダリングするロジックが「colorme-entrance」と呼ばれる一つのPHPアプリケーションに密結合になっている状態でした。
上記の状態だと、レンダリングロジックで使っているPHPパッケージのバージョンを上げる場合、表示する値を計算するためのロジックが依存しているパッケージとの兼ね合いも考える必要があります。そのほかさまざまな依存により、柔軟な開発が難しい状態でした。
そこで以下の図のように、レンダリングロジックをマイクロサービスとして別のアプリケーションに分離することにしました。以降、この記事では切り出したマイクロサービスを「entrance-renderer」と呼びます。
entrance-renderer にレンダリングロジックを分離することで、colorme-entrance はレンダリングロジックと疎結合になり、レンダリングに必要な値を投げるだけで良くなりました。関心が分離し、それぞれの責務に集中できるようになったため、アップデートやリプレースを行う場合も、お互いの依存を考慮することなく行うことが可能になります。例えば entrance-renderer だけGoでリプレースすることも可能になります。
では、この切り出しをどのように行うと安全にリリースできるでしょうか。今回はレンダリングロジックの特性も踏まえ、「ダークローンチ」という手法を採用しました。
本番環境を使う検証手法、ダークローンチとは
ダークローンチとは、実際のユーザートラフィックを複製して新システムにも流し、その応答をユーザーに返さずに裏側で検証する手法です。ユーザーに影響を与えることなく、本番環境での性能やエラーを安全に確認できます。
参考: ダーク ローンチとは何か : CRE が現場で学んだこと https://cloud.google.com/blog/ja/products/gcp/cre-life-lessons-what-is-a-dark-launch-and-what-does-it-do-for-me
今回は、現在トラフィックが流れている全てのショップにおいて、新旧のレンダリングロジックの結果を内部で比較し、結果が変わらないことを目指しました。
なぜダークローンチを選んだのか
テンプレートレンダリングは、その特性上、入力パラメーターの幅が大きく、いろいろなケースが想定されます。例えば、カラーミーショップではレンダリング時に利用されるショップや商品の情報を表す変数を提供していますが、当然ショップごとに異なるでしょうし、時間経過で内容が変化していきます。また、テンプレートにはレンダリングのためのカスタムロジックを記述することもできます。
こうした特性を考えると、現実的な時間で全てのパターンを網羅するE2Eテストを書くことは不可能でした。これに対し、ダークローンチは実際に本番環境を走っているトラフィックを検証に用いるため、多くのパターンを試すことができます。
entrance-renderer の実装・リリース計画
まずは entrance-renderer を新しいアプリケーションとして開発し、開発環境にデプロイしました。また、colorme-entrance の実装にも手を加え、既存のレンダリングクラスと、新しく作成した entrance-renderer 用のクライアントの共通のインタフェースを導入しました。この工夫により、置き換えや比較がしやすくなりました。
そして、比較のための実装を備えたレンダリングクラス ComparisonRenderer を用意し、それをレンダリングに用いることでダークローンチを行えるようにしました。これを使うと何ができるか、実際にコードに書いてあるコメントを引用して説明します。
/**
* 新旧レンダリングロジックの結果を比較するデコレータークラス
*
* 動作フロー:
* 1. 新レンダラーを実行
* 2. 旧レンダラーを実行
* 3. 結果を比較して標準エラー出力に記録
* 4. 旧レンダラーの結果をユーザーに返却（既存の動作を維持）
*/
つまりこのレンダリングクラスを使うと、内部では新しいレンダリングと既存のレンダリングの両方を走らせますが、実際にユーザーへのレスポンスに使うのは既存のレンダリングの結果になります。ユーザーから見たら何も変わらないため、ダークローンチを実現できるのです。
図にすると、下記のようになります。
また、新レンダリングと旧レンダリングで差分があった場合に、以下のような差分が出力されます。
[04-Nov-2025 17:28:39] WARNING: "=== RENDERER COMPARISON DIFFERENCE DETECTED ==="
[04-Nov-2025 17:28:39] WARNING: "Method: fakeMethod"
[04-Nov-2025 17:28:39] WARNING: "Account ID: fake-account-id"
[04-Nov-2025 17:28:39] WARNING: "Template: fake-template"
[04-Nov-2025 17:28:39] WARNING: "Timestamp: 2025-12-14 00:00:00.000000"
[04-Nov-2025 17:28:39] WARNING: "New Length: 500"
[04-Nov-2025 17:28:39] WARNING: "Old Length: 10000"
[04-Nov-2025 17:28:39] WARNING: "Line Count Diff: -300"
[04-Nov-2025 17:28:39] WARNING: "Char Count Diff: -5000"
[04-Nov-2025 17:28:39] WARNING: "First Different Line: 1"
[04-Nov-2025 17:28:39] WARNING: "--- Detailed Diff ---"
[04-Nov-2025 17:28:39] WARNING: "--- /tmp/old_EYfz2l 2025-12-14 00:00:00.000000000 +0900"
[04-Nov-2025 17:28:39] WARNING: "+++ /tmp/new_nxAe3p 2025-12-14 00:00:00.000000000 +0900"
[04-Nov-2025 17:28:39] WARNING: "@@ -503,4 +503,4 @@"
[04-Nov-2025 17:28:39] WARNING: " });^M"
[04-Nov-2025 17:28:39] WARNING: " });^M"
[04-Nov-2025 17:28:39] WARNING: " </script>^M"
[04-Nov-2025 17:28:39] WARNING: "-<script src="https://shop-pro.jp/hoge.js"></script>^M"
[04-Nov-2025 17:28:39] WARNING: "\ No newline at end of file"
[04-Nov-2025 17:28:39] WARNING: "+<script src="https://shop-pro.jp/fuga.js"></script>^M"
[04-Nov-2025 17:28:39] WARNING: "\ No newline at end of file"
[04-Nov-2025 17:28:39] WARNING: "--- End of Diff ---"
[04-Nov-2025 17:28:39] WARNING: "==============================================="
このログを確認することで、どのテンプレートにおいて、どのような差分があったかを確認できます。この差分から、レンダリング結果に差分がある原因の考察に繋げることができます。
差分検出のための実装ができたので、フィーチャーフラグを用いて、レンダリングリクエストのうち1%のみをこの ComparisonRenderer を使ってレンダリングするようにし、ユーザーのトラフィックを使って検証を行いました。
ダークローンチを行って判明したこと
開発環境で手で確認した限りでは、entrance-renderer の実装は問題なく動いていると思っていました。しかしダークローンチによって、新旧のレンダリングに差分が出てしまうケースを発見することができました。例えば以下のようなケースです。
テンプレートのパースがうまくいっていなかったレンダリングが、ユーザーからのリクエストパラメータに依存しているパターンその他、colorme-entrance が依存している外部アプリケーションの対応不備
上記のようなケースを一つ一つ潰していき、最終的には1日ダークローンチをしていても差分が出力されなくなりました。ダークローンチを活用することにより、ユーザーに影響を出さずにプロジェクトを進めることができています。
おわりに
今回はダークローンチを用いて安全にマイクロサービスをリリースする方法についてお話しました。
ダークローンチは、テストでは網羅しきれないパターンがある場合に有用な手法です。特に今回のウェブサイトのテンプレートのように、パラメータの値の幅が大きいものは、実際の本番トラフィックを使った検証により、自信を持ってリリースに臨むことができます。
ご覧いただきありがとうございました。昨年のアドベントカレンダーでもテストに関する記事を書いていますので、ぜひそちらもご覧ください。
