September 7, 2021
日本最大のコンピュータエンターテインメント開発者向けカンファレンス『Computer Entertainment Developers Conference 2021 (CEDEC 2021）』（8月24日 ～ 26日、オンライン開催）にて、8月25日に弊社CEOの島田憲治が登壇しCI/CD プラットフォームである「Harness」を中心に講演しました。その内容を紹介します。
https://cedec.cesa.or.jp/2021/session/detail/s6103b09d63a14
8月25日(水) 14:50 〜 15:15
「次世代のデジタルオペレーション CI/CDからモニタリングまで」
HarnessのCEOのJyoti Bansal氏はエンジニアとしての経験を基にアプリケーション性能監視サービスを提供するAppDynamicsを2008年に起業（シスコシステムズが買収）した経験を持つアントレプレナー。常にDevOpsの最前線にいて、複雑なソフトウェアシステムを構築・運用し、スケールさせるために様々な苦労を経験したという。
DevOpsでは短期間に頻繁に実世界へコードを投入することでコードの淘汰と進化を図り、市場への適応度を高めていく。この中で実世界への導入というソフトウェア配信の部分のツールが未成熟だった。「AppDynamicsの頃でさえ、年間約４億円をDevOpsにかけながら、安定にデプロイできたのは月に１回程度だった」という。これは他社でも同様で、「あるFortune 500の金融サービス会社ではソフトウェア配信関連の作業に、55人のDevOpsエンジニアと約1500人の開発者のほぼ全員が少なくとも10％の時間をかけ、年30～33億円のコストがかかっていた。それでも失敗率は非常に高く15％に達していた」という。失敗した場合に作業をロールバックするのに90分ほどかかるため、投入頻度も2週間に1回を上回ることはなかったそうだ。
こうした状況を改善するCI/CDサービスが、Bansal氏が2017年に創業したHarnessだ。
ソフトウェア配信の進化は、Harness以前を含め３つの世代に分けて説明できる。
「第1世代のソフトウェア配信システムは実は「チケット管理型」システムで、配信リクエストチケットを受けて、運用チームの誰かが展開を行っていました。開発者は開発部門ではなくOpsチームにリクエストし、Opsが配信を管理し、不具合があれば開発者に差しもどすという形のフローでした。この形は近年の分散型のシステム開発では非効率でスケールできませんでした」。
「最近使われている第2世代のシステムは、DevOpsエンジニアのチームを組織して配信用スクリプトを作成させ、そのスクリプトを管理しながらソフトウェア配信プロセスを自動化する形です。開発者は開発中のコードをOpsに渡すことはありませんが、デプロイメントスクリプトの構築と保守をDevOpsチームに依頼します。Opsエンジニアは配信プロセスを命令型のスクリプトで書いていて、問題は、スクリプトの部分がスケールしないことでした」。
そして、第３世代のソフトウェア配信サービスは、すべてのスクリプトの作成と管理を自動制御する「インテリジェントソフトウェア配信」である。
「配信プロセスを、Opsチームが作っていた命令型のスクリプトではなく、開発者が普段使う宣言型のプログラミングのやり方で、HowではなくWhat、つまりプロセスをどう動かすかではなく、何を実現したいかを宣言できるようにするのです。何千行ものスクリプトが必要な場合でも、それは例えば20行の宣言型YAMLで実行できるはずです」。
「そして開発者が、配信システムにやりたいことを伝えれば、システムが品質とパフォーマンスの目標を達成しながらソフトを配信します。配信用のスクリプトを書けるプロがいなくても、開発者がセルフサービスで配信できるようになるのです。数日または数週間かかっていたマイクロサービスや新しいパイプラインのセットアップも数時間で実行できるはずです。さらに配信プロセスを変更や修正の苦労も軽減できます」。
さらに重要なのは、データに基づいてインテリジェントな意思決定を行う機能だ。
「デプロイメントを単純化する際に最も難しいのは、デプロイが実問題なく機能しているかどうかをインテリジェントに把握することです。すべてを理解するためは、人間の専門家に頼らなければなりません」。
「最近のシステムでは、監視システムやログを通じ、ユーザーの利用状況やUXやセキュリティに関する様々なデータを収集できますが、それらはソフトウェア配信ツールや配信プロセスの制御ロジックからは完全に切り離されています。データも膨大で、現実的には機械学習の支援なしではこれらが活用できません」。
「データを機械学習させ、ソフトウェア配信プロセスと結びつけることで、過去の実行に基づいて本番環境の問題を予測できるようになり、ある変更の影響を自動的に検証できます。カナリアテストなどがはるかに簡単になるのです。そしてテスト方法の選択と実行を最適化して、パイプラインで実行するテストを高速化できます。ロールバックも自動化できます。入手できる全データを基に（Harnessの）インテリジェントな意思決定を任せることで、ソフトウェア配信ツールとソフトウェア配信プロセスのレベルを引き上げられます」。
開発者がソフトウェア配信を制御できるようにするには、開発者の体験に合わせてそれを使いやすいようにする必要もある。ソフトウェア配信のパイプラインの編集・構築の作業を、開発者が慣れているコーディング作業と似たエクスペリエンスにすることだ。
「開発者が（ソフトウェア配信ツールを）セルフサービスとして採用するには、開発者に求められる苦労を完全になくす必要があります。（Harnessでは）パイプラインとその構成要素をパラメータ化する機能を備えています。これは、コード内の関数とクラスをパラメータ化して再利用できるようにするやり方と非常によく似ています。そしてプロセスを再利用可能なテンプレートとして実装できるようにしています」。
こうしたセルフサービス化の一方で、開発者がセキュリティや品質基準、コストなどを順守できているかを確認する仕組みも必要になる。Harnessでは、セキュリティ・コスト・ガバナンスに関する基準を「ガイドレール」として提供する。
「規定のガイドレールに準拠していない状況を検出してそれに対応できるようにすれば、開発は大きく変貌します。本当の意味でのセルフサービスなインテリジェンスソフトウェア配信を実現でき、すべてがシンプルになり、スケーラブルになります」。
「最後になりますが、パイプラインに組み込まれたセキュリティやコストやガバナンスのガイドレールと、開発者の権限、の間のバランス調整を行う必要があります。その結果、エンジニアリングチームが何も壊すことを恐れずに迅速に行動できるようになります。組織としても問題が起きないことを確信できます。こうして、ソフトウェア配信に関しては全員がGoogleやFacebookのようなエリートパフォーマーになれるはずです」。