こんにちは。プラットフォーム開発チームの松村です。

はちゃめちゃに寒い今日この頃ですが、この時期に入浴剤をいれてお風呂に入るのが好きです。泡が出るような固形タイプもいいですが、各地の温泉地とかがモチーフになってる昔ながらの（？）粉タイプが好きです。にごり湯だとなおよし。

さて、今回はリリース管理のための仕組みであるリリーストグルの運用をどのように整備したかというお話をしようと思います。

先日の SRE Kaigi で弊社SREの宮後がした発表の中でも紹介がありましたが、ニーリーではリリースプロセス改善の一環でリリーストグルの運用改善に取り組みました。この記事ではこの取り組みをもう少し掘り下げて紹介していきたいと思います。

宣伝ですが、発表ではこれ以外の話も含めてリリースプロセス改善全体の話が横断的に紹介されています。そちらの方もぜひご覧ください！

そもそもリリーストグルとは

もしかするとフィーチャートグル（あるいはフィーチャーフラグ）という言葉に馴染みがある方もいるかもしれません。フィーチャートグルとは、特定の機能の ON / OFF を動的なトグルで管理する手法のことです。実装側でトグルを参照して処理を分岐させておくことで、機能のON / OFFを再リリースなしに素早く切り替えることができます。以下の記事などが詳しいです。

martinfowler.com

フィーチャートグルの中でも、リリースの管理に用いられるものを特にリリーストグルと呼びます。大きな機能を一度にリリースしようとすると大規模なコンフリクトやビッグバンリリースを引き起こしてしまいますが、トグルを利用しつつ開発途中の機能を未公開の状態で少しずつデプロイすることでリリースのタイミングを制御しつつこれらを回避することができます。

同じプロダクトに対して複数の開発が並行しているニーリーでもリリーストグルは大いに活用されています。リリーストグルはDBで管理されており、APIを通じてフロントエンドアプリケーションにも共有されています。

運用面の課題

そんなリリーストグルですが、運用上の課題もいくつか抱えていました。

「リリーストグルの運用が大変」という話は実際にトグルを利用している開発チームから伝え聞いていたのですが、そこまでリリーストグルを活用していないプラットフォームチーム内では運用の大変さの解像度がそこまで高くありませんでした。

そこで、運用改善に向けてまずは開発チームへのアンケートによるヒアリングからスタートすることにしました。ヒアリングしたところ、以下のような課題があることが分かりました。

トグルの状態が把握しにくい

リリーストグルの状態はDBで管理されているので、現在の値は各環境のDBに分散しています。そのため全体としてはどういうリリース状態になっているのかという把握が困難でした。

また、開発自体も複数のチームで並行して行われており、別チームが管理しているトグルの状態は把握しにくいという問題もありました。

ローカル環境の同期が大変

各環境へのリリーストグルの追加自体はCIで行われていますが、ローカル環境は各自で管理する必要があります。前のセクションの課題もあってトグルの追加や値の更新などを把握するのは難しく、自力で共用環境との同期をとっていくのは負担でした。

使い終わったリリーストグルが溜まっていってしまう

リリーストグルの削除に関するルールがなく、リリーストグルが溜まっていっている点も課題となっていました。

実装の分岐が残り続けることによってコードの可読性が下がってしまったり、コンポーネントごと差し替えている場合には変更を加える箇所の特定が難しくなってしまったりとコードに悪影響を与えていました。

運用のための仕組み整備

これらの課題に対して、運用を補助する以下のような仕組みを用意していきました。

リリーストグルダッシュボード

まず、リリーストグルの情報を横断的に把握できるよう、各環境のリリーストグル情報を集約したダッシュボードを用意しました。

社内にBigQuery + Redashによるデータ分析基盤があったので、集計と可視化のためのツールはこれを採用しました。既存の仕組みを流用することができたので、ほとんど開発もいらずライトに実現することができました。データ基盤にはDBの日次の時系列データを集計する仕組みもあったので、トグルの状態変化を調べたいという要求もクリアできました。

BigQueryのデータソースは各環境ごとに分けて管理されており、集約するには異なるデータソースをまとめる必要がありました。これにはRedashのQuery Results Data Sourceという、Redash上の他のクエリ結果に対してクエリをかけることができる機能を活用しています。

各環境のテーブルに対してそれぞれデータを整形するクエリを用意し、それらのクエリを参照してjoinさせることで環境横断のデータテーブルを構築しています。ダッシュボードの各ビュー用のクエリはその集約用のクエリを参照して用意しています。

リリーストグルに関する通知

次に、リリーストグルの運用を補助する仕組みとして各種通知の整備を行いました。これもRedashのアラートを活用してラクに整備することができました。

リリーストグルの状態変化に気がつけるよう、追加・更新・削除されたトグルを検知してSlackに通知を飛ばしています。やや目的外利用な感も否めないですがそこはご愛嬌ということで…アラート回復の通知が多少邪魔だったりしますが更新には気がつけるようになりました。

リリーストグルの削除に関する運用もアラートを活用して行っています。トグルの更新日時から使用済みのリリーストグルを判定し、その数が一定の閾値を上回ったらアラートを発火させるように設定しました。また、アラートが発火したタイミングで各チームにリリーストグルの状態を見直してもらうようにルールを整備しました。

使用済みリリーストグルに関するアラートはリリーストグル管理ツールである Unleash を参考に用意した仕組みです。 Unleash には Technical Debt という機能があり、使用されていないトグルを判別してその数や割合を確認することができます。

この機能から、リリーストグルの管理状態に関する指標をもとに意思決定するのはどうだろう？ということを考え始めました。リリーストグルは残った状態のままでも機能自体にあたえる影響は少ないため、削除の優先度がなかなかあがりにくいというのが実情です。きちんと削除を回していくためには削除のきっかけを作ってあげることが必要だと思います。 SLO的な考え方にも触発され、適切なアラーティングの元でリリーストグルの管理状態を一定の水準に保つという運用を思いつきました。

ローカル環境用のリリーストグル管理ツール

実際にリリーストグルの更新に気がついたとして、差分を確認しながら同期のための作業を行うのはやはり面倒です。そこで、ローカル環境のリリーストグルの状態を開発環境と同期するためのスクリプトを用意しました。踏み台サーバー経由で開発環境のDBへアクセスし、取得したリリーストグルの状態通りにローカル環境のDBを書き換える仕組みです。