フロンドエンド環境のバージョンアップにカナリアデプロイを利用する

フロンドエンド環境のバージョンアップ

フロンドエンド環境の様々なライブラリのアップデートに追従するのは結構大変な作業だったりする。自分たちもREACT＋Typescript＋NodeJSでフロンドエンド環境を構築しているサービスがあり、日常的にライブラリのアップデートを実施したいけど、バージョンアップに伴う破壊的な変更がないか、既存コードの改修が必要か、本当にサービスに影響がないとビジネス側に言い切れるか、等々様々な要因により簡易にバージョンアップする文化はなかなか根付かない。

忘れた頃に、恐る恐るnpm outdated, npm auditコマンド発行して、うげぇぇぇとなるのはフロンドエンド界隈のあるあるだと思う。

ビジネス側はサービスに影響なく、でも、技術負債が出ないように各ライブラリのEOL管理しつつバージョンアップを適宜実施しなさいとか、結構しんどいことを言う(愚痴)。

フロンドエンド環境のインフラにK8sを採用すれば、安価に新環境を用意できる。かつ、新環境側ですべてのバージョンアップした環境を用意して、ロードバランサを介したトラフィック分割で切替を実現すれば、安全にバージョンアップができ、バージョンアップを定期的に行うという文化が根付くのではないかと考えた。

カナリアデプロイ

ロードバランサを介したトラフィック分割を行い、旧環境・新環境の2つの環境を用意し、切り替える。一括切り替えを行うのがブルーグリーンデプロイで、カナリアデプロイは、アプリケーションの新バージョンをリリースする際に、一部のユーザにのみ展開し、新環境が問題ないことを確認した上で、徐々に全体に展開することができる。

旧環境:新環境＝99%:1% のようにトラフィック按分する。徐々に比率を変えてリリースする。

不具合が内包されていても、影響範囲を縮小できる。
発生時にはトラフィック按分を0%にすればよい。
ユーザ影響を最小限で、安全に新機能をリリースできる。エンジニア的にもインシデントは出さないように努めるというのは根底にあるが、全体の1%であればという心理安全性も働く。

アジャイル的な開発リリースというよりも、多くのユーザを抱えていて、ウォーターフォール的に開発し動作確認をしっかりした上で、リリースするといったユースケースに向いている。

GoogleCloud環境とかで、わりとスタンダートに使われているっぽい。POD単位で切り替えができるからフロンドエンド環境の切替手法に用いるのに適していると考える。

Create a new revision with the new version of the application on CloudRun. Split traffic between this version and the version that is currently running.

採用事例を探す

CDNで切り換える手法がいくつか出て来た。CDN使っている場合はキャッシュが効いてオリジンの変更反映に時差が出るので、切替・切戻で影響が出るかも知れない。継続して確認したい。