DevOps概念図の3.5次元的解釈

はじめに

みなさん、こんにちは。株式会社カサレアルの植草です。

｢DevOps｣は2008年の｢アジャイルカンファレンス｣の中で議論が始まったと言われており、その翌年からは毎年世界中の様々な都市で｢DevOps Days｣と呼ばれるイベントが行われているほど、多くの人が関心を持たれているテーマかと思います。

一方で私自身、私自身、弊社が提供するトレーニング「クラウドネイティブ道場」の企画・開発をする中で、他の人に｢DevOps｣を端的に説明できないのではないかという疑問を感じたことから、改めてDevOpsに対する解釈をまとめたいと思います。

※クラウドネイティブ道場：クラウドネイティブ関連技術・ツール群の中から代表的なモデルケースを通じ、実際に体験していただくことのできるトレーニングコースです。

本ブログでは、その結果としてたどり着いた私自身のDevOpsに対する解釈をまとめたいと思います。

目次

・サイクルの時間軸
・リリース先となる環境のバリエーション
・おわりに

サイクルの時間軸

一般的なDevOpsの概念図として、図１のような絵を見たことがある方という方は多いと思います。

Dev(開発側の一連のプロセス)からOps(運用側の一連のプロセス)へ流れ、そしてまたDevに戻っていくというDevOpsの循環の概念図です。

改めてこの図を眺めていた時、「なぜ、この循環の輪はねじれているのか？」という疑問が湧いてきました。

(図１ 一般的なDevOpsの概念図)

少々大袈裟な表現ですが、図1の｢一般的なDevOpsの概念図｣を、分解してみようと思い立ち、図2左上の絵にあるハサミの所でこの輪を切り、さらに左下のようにまっすぐ伸ばしてから、ねじらずにつないでみました。

結果として図2右下のようになります。

(図2　一般的なDevOpsの概念図の分解)

図3で、元の概念図の輪と分解して作り直した輪を見比べてみましょう。

(図3　輪をねじっている理由の考察)

このままではまだ両者の明確な違いが浮かばなかったので、実際の現場での開発運用をイメージしながら改めて見比べてみた時、1回のリリースに複数のコード修正が含まれる事に気付きました。

極めて当たり前の事ではありますが、コードの追加・修正するきっかけとなる要望や問題への対応は独立しており、優先順位などはあるとしても、いずれも出来るだけ早く対応してもらいたい事項だと思います。

多くの場合、開発側ではその修正をメンバーに割振り、並行して対応しているのではないでしょうか。

このようにDev側では一周のサイクルの中で複数の要望や問題の対応が含まれている一方で、Ops側ではあがってきた複数の要望や問題の対応を、リリース作業に伴うサービス停止時間や作業リスクを最小化するために、まとめて１回でリリースしていたりします。

このままでは、Dev側で優先度の高い事項を最初に対応しても、サイクル全体の完了を待たなければ結果的にリリースされず、タイムリーにエンドユーザーへ還元できない事になります。

(図4　DevとOpsのサイクルの違い)

整理すると、課題や要望の対応をどんどん進めて行きたいDev側と、サービス停止時間や作業リスクの最小化のためにリリースをある程度の期間を踏まえて計画的に行いたいOps側では、サイクル1周にかかる／かけたい時間に違いがある事を再認識できました。

図4の左右の輪を見比べると、ねじれていない輪ではサイクル1周のDev側で扱う複数の課題や要望の対応をまとめた１つのものと考えざるを得ませんが、ねじれた輪ではOps側でまとめたリリースを1回行う間に、Dev側では複数回サイクルが回るイメージも持つことができそうです。

このイメージを歯車で考えるとDev側が小さい歯車、Ops側が大きい歯車となり、二つの歯車がかみ合って回っているイメージになります。

最新の課題や要望の対応を少しでも早く、ユーザーに還元するためにはOps側の歯車をいかに小さくできるかがポイントになりそうですが、Ops側としてもリリース作業に伴うサービス停止時間や作業リスクとのトレードオフになっているようです。

(図5　CI/CDパイプラインで目指すこと)

Dev側とOps側ではサイクルを1周する時間に違いがある、つまり時間軸が異なっていることを押さえた上で、両者を確実に連携させるために、サイクル上を流れるものをしっかりと管理する事の重要性にも改めて気づかされました。

DevOpsの話には図5のようにCI/CDのパイプラインがよく出てきますが、このように考えてくると、Dev側とOps側でしっかりとしたバージョン管理やビルド管理を行うことが重要であり、これらの管理は「しくみ」によって行われるべきものであることも頷けます。

私自身、これまでCI/CDパイプラインの主なゴールを｢自動化｣のように考えていましたが、図5のような自動化の先には、課題/要件の管理に紐づけられるバージョン管理やビルド管理がある事も、時間軸の違いを意識できた事で改めて納得できました。

リリース先となる環境のバリエーション

続いて前述の考察で出てきたCI/CDのパイプラインの絵を眺めていて、通常大半の開発プロジェクトでは、リリース先となる環境に複数のバリエーション（環境面）がある事も気になり始めました。

(図6　CI/CDパイプラインのデプロイ先となる環境面)

開発のエンジニアが開発の過程で自身のコードの動作確認に使うなどの｢開発環境面｣、テストを行う｢テスト環境面｣、本番環境となる｢本番運用環境面｣など、プロジェクトによっては用途に合わせて様々な複数の環境面を持っていたりします。

CI/CDパイプラインという言い方から、CIのパイプラインとCDのパイプラインが1本につながったものをイメージしがちですが、実際には図6のように各環境面に合せて少なくともそれぞれ独立したCDパイプラインが存在していた方が良いだろうと考え始めました。

各環境面の使われ方を考えれば、開発環境面やテスト環境面にあるアプリケーションは、当然それぞれ開発中・テスト中のアプリケーションが置かれることになり、未だ開発中・テスト中のアプリケーションを本番運用環境に置く訳にはいかないからです。

(図7　平面的なDevOpsの概念図を立体化)

本ブログの最初に図1で見ていた「一般的なDevOpsの概念図」は二次元の図でしたが、図7の左側の絵のように環境面の層を意識すると二次元ならず、三次元に見えてくるのではないでしょうか。

おわりに

前段までで考えてきた事をまとめると、二次元の絵として認識していた「一般的なDevOpsの概念図」は、環境面の層を意識する事で三次元的に見て取ることができます。

さらに本ブログの前半で考えてきた時間軸の違いを加味すれば、四次元とは言わないまでも3.5次元的に解釈できるのではないでしょうか。

このように考えた事で、CI/CDパイプラインという言い方から、CIのパイプラインとCDのパイプラインが1本につながったイメージに囚われていた所から、CI/CDパイプラインのより現実的な構成イメージに広がりが出てきました。

(図8　CI/CDパイプラインの青写真)

あくまでここまでの考察から書いてみたCI/CDパイプライン構成の言わば青写真となりますが、図8のように考える事ができるでしょう。

このようなパイプラインの主な目的が｢自動化｣に終わるものではなく、本番運用環境における課題/要件の管理に、確実にバージョン管理やビルド管理を紐づけていくことを意識できた事は、私にとってこのような考察を行った大きな成果でした。

そして今、Dev側で対応した最新の要望や問題解決をタイムリーに（できるだけ早く）かつ確実にユーザーに還元していけるように、CI/CDパイプライン・DevOps全体の仕組みを継続的に改善しながら運用していけるように適宜見直しをかけて行きたいと考えています。

振り返れば、当たり前の内容に思えますが、皆様にとってのヒントになれば幸いです。

関連リンク

クラウドネイティブ道場：トレーニング資料ダウンロード

カサレアル公式HP：クラウドネイティブ道場とは

カサレアル公式HP：クラウドネイティブ推進支援サービスご紹介