PR
連載 [第2回] :
  CI/CD Conference 2021レポート

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

2021年10月7日(木)
松下 康之 - Yasuyuki Matsushita
CI/CDのゴールに、リリースリスクの最小化のためにフィーチャーフラグを使ったトレジャーデータのセッションを紹介する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

継続的リリースの利点

継続的リリースの利点

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

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

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

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

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

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

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

デザインレビューの概要

デザインレビューの概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後のまとめ。リリースにリスクの最小化が重要

最後のまとめ。リリースにリスクの最小化が重要

リリースとデプロイの明確な区分け、リリースを価値として顧客に届けるための方法論としてフィーチャーフラグを有効に使った手法など、自動化だけがCI/CDの目的として語られがちな状況に一石を投じたセッションと言えるだろう。

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

設計/手法/テストイベント
第5回

CI/CD ConferenceからAWSのアドボケイトによる「単一コードベース」を勧めるセッションを紹介

2021/10/21
CI/CD Conferenceから、AWSのアドボケイトによる複数のコードベース運用を止めるための手法を解説したセッションを紹介する。
開発ツールイベント
第4回

CI/CD Conference 2021からCircleCIによる調査レポートの解説を紹介

2021/10/18
CircleCIのエンジニアがState of DevOps Reportの要約を紹介。
開発ツールイベント
第3回

CI/CD Conference 2021 MicrosoftとGitHubの連携をMSKKのアーキテクトが解説

2021/10/11
CI/CD Conference 2021にて、マイクロソフトのアーキテクトがGitHubの買収から現在までの経緯、そしてGitHub Actionsの機能を解説した。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています