CI/CD ConferenceレポートトレジャーデータのCI/CDのポイントはリリースリスクの最小化

連載 [第2回] :

CI/CD Conference 2021レポート

2021年10月7日(木)

CI/CDのゴールに、リリースリスクの最小化のためにフィーチャーフラグを使ったトレジャーデータのセッションを紹介する。

CI/CD Conference 2021からトレジャーデータの国分崇志氏のセッションを紹介する。これは、AWS上で展開されているトレジャーデータのデータプラットフォームにおけるサービスのデプロイとリリースを継続的に行うために、SREエンジニアとして国分氏が実施した改善を解説するものだ。「数時間かかる週一リリースを毎日何度も爆速でできるようにするまで」というストレートなタイトルが示すように、継続的リリースができる体制に至るまでの道筋を解説している。

セッションを行うトレジャーデータの国分氏

CI/CD導入前後の差を説明

最初に、国分氏が入社した当時のトレジャーデータのリリースフローが紹介された。当時はマニュアルでリリース作業が行われており、リリースマネージャーが変更や機能追加を個別に選択していたこと、定期実行される結合テストの結果を受けて、SSHですべてのサーバーにログインして必要なインフラをChefでデプロイしていたことなどを振り返った。

CI/CDが実装される前のマニュアル作業による方法を紹介

この方法には人手による操作が多いために、リリースの頻度が減ってしまっていたという弊害があったという。またChefによるデプロイも、依存関係などの原因で失敗することで手戻りが多かったことを挙げた。

マニュアル作業によるデプロイフローの弊害

当時のトレジャーデータのシステム規模は、本番で動いているサービスが約600だったという。これはAWSのオートスケーリングを利用していたサービスの数ということだが、本番のサービスはほぼオートスケーリングを利用していたので、かなり正確な値ということだろう。

当時のリリースの指標はこんな感じ

待ち時間が2時間から24時間、デプロイに必要となる時間は約40分であり、リリースの頻度も週に1回が精一杯だったという。

CI/CD導入前のサービスリリースの状況

それに対して現在はテスト時間が10分、デプロイのための時間は5分、リリースの回数は週に28回程度となっている。継続的なリリース、自動的なリリースが行われているのが定量的に見てとれる。

継続的リリースの利点

継続的に開発されたソフトウェアやパッチをリリースできることによる利点として、ユーザーからの要望を本番に反映するまでの必要時間が削減でき、これによって顧客満足度が向上したこと、リリースを頻繁に行えることで、もし不具合があったとしても影響を受ける部分が限られ、リスクを下げられること、そしてリリース待ちの時間が減り、以前のようなリリースマネージャーとの調整の時間と労力が減ったことを挙げた。

そして継続的リリースを行うために必要なこととして、リリースリスクの最小化、オペレーションの自動化、デプロイの高速化の3つを挙げた。この3つの中で最も重要なのはリリースリスクの最小化であり、自動化、高速化はその後で実施する発想でも良いと語った。

継続的リリースで最も大事なのは「リスクの最小化」

リリースリスクを最小化するために

ここからはリリースリスクの最小化のために行ったことを解説する内容となった。

最初のポイントはデザインレビューである。ここではスケールできるアーキテクチャーにすること、障害発生ポイントをなるべく減らすこと、サービスとして満たさなければいけない要件をチェックリストとして活用すること、セキュリティチームによる情報漏洩などのチェックポイントについてレビューを受けることなどを挙げた。機能面だけではなく性能などの非機能要件やセキュリティにフォーカスしたレビューを行うなどの項目は、エンタープライズ企業においても参考になるのではないだろうか。

デザインレビューの概要

このスライドではタイムアウト、リトライ、サーキットブレーカーなどを使って、リリースしたサービスや連携する外部サービスにおいてトラブルが起こったとしてもユーザー側に与える影響を極力抑えるための工夫を解説した。

障害は発生するという前提で、それをどうやって回避するのか？を考える

またGoogleのSRE本の中でも語られているサービスレベルオブジェクティブ（SLO）とエラーバジェットについても取り入れていることを紹介し、サービスそのものを評価するための指標として定量的に使うことを解説した。

SLOとエラーバジェットの考え方を採用

そしてここから、筆者が考えるこのセッションの重要なポイントの解説に入った。重要だと思う理由は、デプロイとリリースの違いを明確に意識しているからだ。デプロイはあくまでもデベロッパーの書いたコードが本番環境に配備されること、それに対してリリースはユーザーから見て機能が使えるようになったこと（もしくはバグが直ったこと）という認識があるからこそ、フィーチャーフラグを使ってユーザーにとって機能をどうやって使わせるか？という発想になる。

デプロイとリリースを分けてフィーチャーフラグで機能をオンオフする

ただしフィーチャーフラグも使いすぎるとテストの工数が増えるため、ある程度使い方にコツが必要だというのが要点のようだ。

段階的リリースのためのフィーチャーフラグ

このスライドには、フィーチャーフラグをサービスとして提供しているLaunchDarklyのロゴが追加されている。これは、トレジャーデータがLaunchDarklyのフィーチャーフラグサービスを使っているということを暗に示しているのだろう。

また本番環境におけるアラートについても言及し、設定した目標値であるSLOだけではなくSLOを阻害する要因となる要素についてもメトリクスを採取して、予防することが大事だと説明した。

エラーだけではなくSLOを損なう要因を監視すること

またこれまで定期的にまとめて実行されていた結合テストを、メインブランチへのコミットをトリガーにして自動実行されるように方法を変えたことを解説した。

デプロイを行うツールも検討中

デプロイを行うツールに関しても言及し、自社開発のデプロイツールが未だに使われている中で、今後のメンテナンスコストが増えることを考えると、すでにオープンソースとして公開されているツールなどに乗り換えることで、コミュニティのエコシステムを利用する発想もあることを紹介した。ここでは候補の一つとして、Netflixが開発しGoogleなどが貢献しているSpinnakerが紹介された。

ここからはリリースの自動化、デプロイの高速化などについてもトレジャーデータの事例をベースに説明を行った。デプロイが高速で完了しなければいけない理由は、デベロッパーは常に次の開発に取り組んでおり、デプロイに時間がかかればかかるほど、開発完了とリリースがずれてしまうことで手戻りが発生してしまうことを避けるためだと語った。

このセッションの最後のまとめとして、最も重要なのはリリースによって発生するリスクを最小化することで、自動化、高速化についてはその後にやればよいという考え方を確認してセッションを終えた。