おはようございます。最近 AWS CDK ばかり触ってるしのです。
今回は、実際にレアジョブで行なった事例を元に、新しいバージョンのアプリケーションをいかに少ないリスクでリリースするかについてお話します。
概要
やったことは以下のような感じです。
カナリアリリースを行ない、低リスクで新バージョンのアプリケーションをリリースしたい。
↓
要件上、"特定のユーザーにのみ"新バージョンを見せて、他のユーザーは既存のアプリケーションを利用して欲しい。
↓
リクエストの分散自体は ALB の機能で可能だが、"特定のユーザーのみ" を対象にするためのロジックをどこかで持つ必要がある。
↓
アプリケーション側でログイン時に"特定のユーザーのみ" 判定用のCookie を発行する。(ログイン時は必ず既存のアプリケーションへリクエストする)
↓
ALB のリスナールールにて、判定用の Cookie を持つリクエストは新しいバージョン、それ以外は既存のバージョンへ流すルールを設定する
↓
Cookie を発行する割合をアプリケーション側で変更して、徐々に新しいバージョンのアプリケーションを公開していく
経緯
弊社では、最近までメインサービスとなるレアジョブ英会話の大規模リファクタリングを行っていました。
何年も稼働してきた既存アプリケーションから仕様は大きく変更せずに、開発効率の改善などを目的に 1 から作り直すことを機能単位に行なっていました。
その中で、レアジョブ英会話の中でもコア機能となる講師検索機能やレッスン予約のリプレイスは影響範囲が広く、サービスが完全に利用できない状況さえ発生しうるリスクの高いプロジェクトでした。
事前に検証するのはもちろんですが、問題が発生した際のサービス影響を最小限にする工夫が必要でした。
そこで、カナリアリリースで少ないユーザーから徐々に新しいリリースを公開して...とやりたいところですが、問題がありました。
- フロントのデザインが大きく変わっているので、新しい画面を見せるユーザーは固定したい
- 個人ユーザーだけではなく、法人ユーザーなどもいるため、特定のユーザーには既存の画面を見せたい(法人ユーザーはカナリアリリースできない要件があった)
そのため、特定のユーザーにだけ新バージョンを利用して頂くためのロジックが必要になり、Cookie と ALB のリスナールールを組み合わせた段階リリースを行いました。
ロールバックも ALB のリスナールールを変更するだけでよく、また必要な Cookie の値が知られたとしても新しいバージョンのアプリが利用されるだけなので問題ないと判断しました。
その結果として、古の仕様やレアケースなどが起因となる事前の検証で確認が漏れていた不具合をユーザー影響をできるだけ小さくしたまま検知することができました。
実装詳細
以下の画像のように、判定用の Cookie を持っているか・特定のパスか を判定するルールを設けて、マッチすれば新バージョンのアプリを含んだターゲットグループへ Forward します。
このルールを既存のアプリケーションへ Forward するためのルールより優先度を高くして設定します。
その結果、特定の画面について特定の Cookie を持っている場合は新バージョンへ、持っていなければ既存バージョンへリクエストが送られます。
Cookie の付与については user id を指定する形で付与しました。
結論
特定のユーザーにのみ段階的にリリースを行うという話はあまり聞いたことがなかったので、今回お話させて頂きました。 普通のカナリアリリースであれば、AWS が提供している機能で簡単に実現できるのですごいですよね。
今回はロールバックの判断とかメトリクスの監視、ログの監視など正常に動いているかどうかの判断が複雑だったので自動化等はしておりません。
ではこの辺で。ありがとうございました。
パワー
we're hiring!!
