コンサルティング事業 2021.02.25

“本番環境でしか”起きないバグへの処方箋

・本番環境でしか起きないバグは、本番環境とテスト環境との差分が原因
・どこに差分があるかをチームで認識を持っておくだけでもリスク検知に役立つ
・差分を完全に無くすことは難しい
・被害を抑えるためにカナリアリリースなどのリリース戦略がある

こんにちは。コンサルティング事業部の米丸です。

■リリースって怖くないですか?

WEB開発におけるリリース。これまでの努力が報われる瞬間であるとともに、結果によっては一変して地獄の一日に変わる瞬間でもあります。

特に、本番環境でしか起きないバグが発生して泣かされることは少なくないと思います。テスト環境で念入りに検証を重ねに重ねても、それをあざ笑うかのようにあらわれる悪魔、「本番でしか起きないバグ」

この類のバグが起きる原因は、一言で言うと、本番環境とテスト環境の差分にあると言えます。データやインフラ、アプリケーションなどが異なる状態にあることで、テスト環境では見つからなかった問題が本番環境では起きてしまいます。

以前、当時のチームでの期間内に発生したバグの要因を調査したところ、全体の半数が、この本番環境とテスト環境の差分によるものであったことがあります(残りの半分は設計漏れなどテスト検証時に見つけるべきものでした)。その時に調査・対処したことをまとめてみました。

①どんな差分があるかを分類する

まずは、敵を倒すには敵を知るところから、ということで、本番環境とテスト環境との差分にはどんな分類にわけられるかを整理してみました。

●アプリケーションの差分

WEBサーバに上がっているプログラミングファイルや設定ファイルに差分がある場合です。以前、人力でファイルをアップしていた時代では起こりがちな問題でしたが、デプロイの自動化やサーバの仮想化が進んだ現在では、一般的にも少なくなっている気がします。弊チームでも、ファイル反映は半自動化しているため、アプリケーションの差分はバグの主要因ではありませんでした。

●インフラ構成の差分

予算的な都合で、本番相当のインフラ構成のテスト環境が用意できない場合があります。本番では冗長化されWEBサーバやDBサーバが複数台あるのに対し、テスト環境は非冗長化で1台構成である、とか、テスト環境だけサーバ1台にWEBサーバやSMTPサーバなど複数役割を持たせている、といったことです。

問題になる例

負荷分散装置のスティッキー設定(ユーザーのアクセスを初回アクセスしたサーバに維持する設定)が漏れていて、WEBサーバ上の一時ファイルを参照するような処理の場合に、一時ファイルが無いサーバにアクセスが途中で切り替わることで、本番環境だけエラーになる。(テスト環境ではサーバが1台しかないため切り替わらずエラーにならない)

●外部連携システムの差分

ASPなど外部システムと連携する場合、本番同士、テスト環境同士で繋がれることが通常かと思います。このとき、連携先システムのテスト環境が本番相当の機能でなかったり、あまり使われない機能であればテスト環境用の外部システムがそもそも存在せずモックで代用していたり、ということがありえます。

●データの差分

データ量は圧倒的に本番環境のほうが多くなりやすく、データ量が少ないテスト環境ではうまく動いていた処理も、本番では遅すぎてとても利用に耐えない、ということが起こりえます。また、歴史的経緯や過去の不具合などにより想定外のデータが本番には存在する場合があります。リニューアル前の仕様で登録された仕様書に載っていないインデックス値とか。。一方で個人情報などセキュリティの観点から、本番環境のDBをコピーしてきてテスト環境に用いるようなことはもちろんできず、本番環境とテスト環境の差分を埋めることは簡単にはできません。

●アクセス量の差分

アクセス量も本番環境の方が多く、テスト環境で本番相当のアクセスを再現するのは簡単ではありません。また、botなどから想定外のアクセスをされることもあります(botなのでエラーになっても問題ではありませんが)。数人が同時アクセスすることでエラーになるような事象は、テスト環境では見つけにくいことがあります。

他にもあるかもしれませんが、この5つの分類をもとに、本番環境とテスト環境のどこに差分があるか、サイトごとの状況を整理してみました。チーム内で共通認識を持っておくだけでも、事前にリスクをつぶせる可能性があがりますし、また万が一リリース後に問題が起こった場合も対処がスムーズになります。当時のチームでは、リリース前に関係者で集まりリスクをあげるタイミングを設けていて、その際に「環境の差分による問題が起きうるか?」という問いを用意しておくだけでリスク検知に役立っていたなと、経験上感じています。

②できるだけ差分を無くす

言わずもがなですが、本番環境とテスト環境の差分を無くすことが根本解決になります。

・インフラ構成のうち問題が起こりそうなところは本番相当にしておく(冗長化構成とか)
・テスト環境でも外部連携システムはつなげておく/すぐにつなげられるようにしておく
・リニューアル前の古いユーザーを残しておく、探してテストパターンに入れておく

など、できることを考えてみましたが、正直あまり新たにできることはありませんでした。。。
予算の都合やセキュリティ上の理由から、完全に差分を無くすことはどの開発現場でも難しいだろうと思います。

③カナリアリリースの導入

差分を完全には解消できないため、被害を最小限に留めることを目指し、カナリアリリースの考えを導入しました。

●カナリアリリースとは

改修したプログラムをリリースする際に、一度に全ユーザーが利用する環境に変更を反映するのではなく、一部の環境にのみ先行して反映することで、問題があったときの影響を限定的にする方法です。例えば、複数台のWEBサーバを冗長化しているような環境の場合に、1台だけ数時間早くリリースする、といった具合です。複数台のサーバで冗長化しているサイトであれば、比較的取り入れやすい方法だろうと思います。

もともとリリース時は、複数台あるうちの1台のみ先にファイル反映し、一定時間様子を見る運用としていましたが、これをリリース内容のリスクに応じて、数時間や半日、あるいは2~3日程度早くリリースし、入念に様子を見る運用としました。カナリアリリースの導入により、数回、被害を最小限に抑えられたことがあり、また開発者体験としても安心感が高まりました。

ちなみになぜ「カナリア」という名前がついているかというと、そのむかし炭鉱でのガス漏れ事故への対策のため、ガスに敏感なカナリアを鳥かごに持ち込み検知に使っていたことがあり、先行して犠牲になるWEBサーバをカナリアに見立ててそう呼んでいるそうです。カナリアぁ。。

調査の中で、カナリアリリースの他にも、リリース時のリスクを下げる方法として、以下のようなものがありました。それぞれメリットデメリットがあるため、環境にあわせて採用を検討してみてはどうでしょうか。

■リリース時のリスクを下げるリリース戦略

●ダークカナリアリリース

カナリアリリースの派生形で、一般ユーザーには公開されない本番相当の環境を用意し、開発者や関係者のみが一定期間動かして確認を行う方法です。この方法は、当時のチームでももともと取り入れていました。
一般ユーザーは見られない環境のため、もしここでバグが発生しても、実際の被害にはつながらないというのが、この方法のメリットです。ただ、確認できることが限定的なため、これだけではリスクヘッジとしては弱いというのが私の感想です。カナリアリリースとの併用が良いと思います。

●フィーチャートグル

改修した機能にアプリケーション上でON/OFFを切り替えられるフラグを持たせ、リリース後に影響を見ながら段階的にフラグをONにしていく方法です。カナリアリリースと比べ、フラグを仕込む手間がかかりますが、機能を公開する対象を柔軟に設定できることができます。例えば、解約されると困る有料会員には機能を隠し、無料会員にのみフラグをONにして試す、といった具合です。また、問題があった場合はフラグを切り替えるだけで元に戻せるので、即座にロールバックできるというメリットもあります。

●ダークローンチ

ダークカナリアリリースと似ていますが非なるものです。私もこのブログを書く際に調べるまでは混同していましたし、フィーチャートグルをダークローンチと書いているブログもあったりするので、定義は曖昧なのかもしれません。。最終的にGoogleのエンジニアのブログ記事を参考にしました。
ダークローンチではまず、稼働中の既存環境とは別に、改修プログラムを反映した本番相当の新環境を用意しておきます。そのうえで、既存環境へのユーザーからのアクセスを、そっくりそのままコピーして新環境にも流す、ということをします。このとき新環境からのレスポンスはユーザーに見せる前に破棄します。これをすることで、本番相当のアクセス負荷に耐えられるか、リアルなユーザーの多様な操作に正しく機能するか、という観点での確認が行えます。難点としては、仕込みに手間がかかることです。

最後に

本番環境とテスト環境の差分は完全に無くすことはできないと思うので、どこに差分があり、どういったリスクがあるのかを、チームで認識を持っておくのが大事かなと思います。上であげたリリース戦略は、要件があえばいつか試してみたいです。

参考

Cloud First Architecture 設計ガイド

ダーク ローンチとは何か : CRE が現場で学んだこと
https://cloud.google.com/blog/ja/products/gcp/cre-life-lessons-what-is-a-dark-launch-and-what-does-it-do-for-me

この記事をシェアする
事業について詳しく知る

コンサルティング事業について詳しく知りたい方はこちら

コンサルティング事業部SDPグループマネージャーエンジニア

RECOMMEND

おすすめ記事