カナリアの森をサーバーに作ってしまった話

Fukuiと申します。
ハードコアパンクと公園遊具をなんとなく愛し続けているおっさんです。

今日はGYOMUハックAdvent Calendarの１０日目としての記事です。みなさんの記事が素晴らしすぎるので、ちょっとハードルを落とした話をしてみようと思います！



　仕事は社内情シス


ＳｏＲと呼ばれるあのドイツのERPから、ＳｏＥの代表のSalesforceまでいろいろなシステム領域を担当しています。いろいろなことをやっていますが、現在はそのなかでAgileとかDevOpsという新しめのアプローチもいくつかのプロジェクトの中で試しています。限られたメンバーの力を最大限に生かしながら、いろんな工夫をしてビジネスの課題を解決してゆくという面ではＧＹＯＭＵハックとは非常に親和性の高いアプローチだと思っています。特にＳａａＳの場合は親和性が高いアプローチで、Salesforceの学習コンテンツ「Trailhead」でもAgileアプローチのコースがあったりします。

今回は私のAgile試行チームでやらかしてしまった失敗を解説つきで話します。みなさんはそんな失敗しないでくださいね。でも失敗こそが最大の学びというのがAgileの基本的な考え方なのですので、チャレンジしたからやらかした・・・というのは悪いことではないでしょう。




カナリアリリースとは？

　DevOpsやAgileアプローチの中の技法でカナリアリリースというものがあります。カナリアリリースは新機能や新しいバーションのプロダクトをいきなり本番環境のユーザ全体にリリースするのではなく、一部のユーザにのみ小規模に提供することによって、新バーションによる悪影響のリスクを最小限に抑えながら、できるだけ早いフィードバックを得ようというデリバリーの手法です。一般的なリリース時のリスクとされる悪影響として考えられるのは、システム負荷の急上昇、不具合による業務混乱、新しいバージョンがウケ無かったときに利用者からの批判が炎上してしまうなどの事態で、ちょっと自信が無いとき、利用者の利用頻度や利用行動が読みきれないときにはこのカナリアリリースというアプローチは非常に便利なアプローチです。
　最近はＧＣＰのサービスなどで「アクセスしてきたユーザのうち、１０％のユーザーに新バーションを提供する」「カナリアリリースしたプロダクトのモニタリングと承認ワークフローを提供する」みたいなカナリアリリース向けの機能なんかもちらほら見かけるようになってきています。そういえば最近ラスベガスで行われたＡＷＳのイベントでもこのサービスが発表されていたようです。まさにカナリアリリースはこれからが旬のアプローチと呼べます。

　ちなみに何故カナリアと呼ぶかと言うと、むかし炭鉱とかの過酷な環境で作業員の生命をおびやかす有毒ガスを人的被害が出る前にすばやく検知するために、環境変化に弱いカナリアを籠に入れて持ち歩いて作業場所の「有毒ガスセンサー」としたことがはじまりです。センサーにされてしまうカナリアさんはとても気の毒なのですが、ガスのセンサーがない時代には人命を守る大事な手法だったのだと思います。そういえば最近テレビで見ましたが、２０年ほど前、地下鉄サリン事件を起こしたオウム真理教の山梨県の施設（サティアンとか言われていた建物群）への警察の一斉捜査で機動隊の人たちもサリンを恐れてカナリアの籠を持って突入したときの映像が記憶にあります。



カナリアリリースをやってみた対象

　こういうアプローチは長年のシステム開発の経験から、「プレリリース」とか呼びながら、いろいろ工夫してやってきていました。とはいえ今GoogleやＡＷＳで提供され始めたカナリアリリース向けの機能なんか存在もしていないし、社内システムにおいてはフィードバックをくれそうな特定のユーザーで試したいということもあり、非常に雑ではありますが、独自の方法で我々はこれを実施していました。

　対象としたプロジェクトはＥＲＰの基本的に社内向けのシステム開発。各機能を最小単位にサービス化して、そのサービスを使いまわしながら、ユーザーが直接接する機能を提供するという今でいうマイクロサービス的なアプローチで、普通に提供されるような「〇〇検索機能」とかとはちょっと違った観点で機能を提供する事を試みていました。例えば「自分が取って来た受注が後工程で処理が進んでいるかをリアルタイムで追跡する機能」とか「まとめて処理した受注をいっぺんにチェックする機能」みたいに、ユースケースを明確にした尖がった（変な）機能にパッケージングして提供するというかなり実験的な試みを狙っていました。こういった新しいアプローチなので正直現場に受け入れられるかどうかもわからないし、思ったより使いすぎるとサーバの性能を使い切ってしまう心配もあるという「危険」なアプローチなので大胆なんだけど慎重さも必要というプロジェクトでした。
　このちょっと自信のないプロダクトたちをいきなり全国にいる利用者たちに大々的に提供する自信は無く、いろいろ考えた結果といて「一部の尖がったユーザー」にこっそり使ってもらってフィードバックを得たり、性能の問題を確認したりしようと「カナリアリリース」を考え出しました。
やり方はすごく簡単で作った機能をみんなの目につく「メニュー」には一切載せないで、そのかわりに直接ＵＲＬをフィードバックをもらえそうなユーザー個人に主旨を説明して、こっそり教えるといったもの。今風の自動的なカナリアリリースの仕組みとは程遠い原始的な方法でしたが、確実にターゲットのユーザー層からフィードバックをもらえるので我ながらよい作戦と思っていました。


カナリアの森
　
　この試みは早くから意外とうまくいき、いくつかのプロダクトは安全性を本番環境で確認することができたり、（おかげで厳しいインフラ担当の人たちを納得させられました）そこそこ現場の利用者にウケる事も確認したうえで自信をもって正式リリースをすることができました。やはり実際に使ってもらったフィードバックは的確で必要最低限で効果的な改善が進みました。そのうち「新機能はカナリアで試してから出す」という形がこのプロジェクトではスタンダードになり、若干完成度が低くても素早く提供して素早いフィードバックをもらい、完成度を高めてから本格リリースをするというのが一般的になりました。・・・・・それはそれでいいことだったのですが・・・・・

　このプロジェクトも順調に進み、機能が増えてきたので、あるときメニュー機能をもっと柔軟で使いやすいものに見直そうということになりました。メニューを再構成する作業の中で、サーバーの中のプロダクトを棚卸しすることになったのですが、その時にチームメンバーは気が付いてしまいました。
悲しいことに、カナリアリリースされたプロダクトがちゃんと管理していなかった事が、それがきっかけで発覚してしまいました。恐ろしいことにサーバーの中には「カナリア」だらけ、メニュー化されていないプロダクトであふれていることに気が付きました。まさに「カナリアの森」のようになっていたのでした。ログで調べると、そのカナリアたちはしっかりと試行先での利用実績があり、ＵＲＬ直リンクのまま業務が行われ続けていた事がわかりました。ほかの誰にも気が付かれずにずっと使われていたのです。・・・・もったいない。というか最初はきちんとフィードバックをトレースしていたのですが、量が増えるにつれてその管理が雑になり、忘れ去られたプロダクトがサーバの中に放置されていたのです。

　　　とほほ・・・

　　　あほな話ですみません




大事なこと
　
　ここで反省すべきは計画です。計画というよりもフィードバックループの間隔とか、見切りのタイミングとかをあらかじめしっかりと決めておいて、一定のリズムを守って確実に本番リリースまでもっていく事です。
カナリアリリースももっと一般的になってくると、特定のユーザーを狙って新バージョンを提供し、そのレポートや、全体へのリリースまでをしっかり管理する仕組みができてくるかと思います。
この失敗はともかく、カナリアリリースのアプローチはユーザから有効なフィードバックをもらうには非常に有効な手段です。みなさんも意識して使ってみてはどうでしょう。