DevOpsとは開発チーム自身が運用できるようにすること
いまさらですが、DevOpsとは何か、具体的には何に取り組むべきなのかについて整理しました。DevOpsとは、サービスの継続的な改善を実現するために、Dev自身がサービスの運用ができるよう、Opsは運用作業のツール化を進めていく取り組みです。そして、DevOpsエンジニアやSREなど、新たな役割への転換が求められます。
DevOps = 開発と運用の協業？
Velocity 2009というイベントで、写真共有サイトFlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（ ビデオ / スライド ）という講演を行います。この講演ではWebサービスの運用における開発チームと運用チームの協業が語られています。両者が同じ目線に立つためにツールを活用するとともに、カルチャーも変えていこうというような呼びかけでした。
この話の前提は開発チームと運用チームの仲が悪い、というものです。それぞれの役割はこうなっていました。
- 開発チームはコードを書いて、リリースモジュールを作成し、運用チームに引き渡す
- 運用チームは、そのモジュールをサーバにデプロイし、稼働させる
開発チームは新しい機能を早く提供することに責任を持ち、運用チームはサービスを安定稼働させることに責任を持ちます。もし、サービスに障害が発生すれば、まず運用担当者に連絡がいき、その原因が開発チームにあることがわかれば開発チームに連絡が行きます。
このため運用チームは新機能のリリースに慎重になります。なぜなら、システムを安定稼働させるのに一番簡単な方法は「新機能を追加しないこと（＝何も変えないこと）」だからです。そこで、運用チームは開発者からリリースモジュールを受け取る際に受入基準を設けて、これが満たされない限りリリースを拒否するようなことをします。しかし、Webサービスのように素早い機能追加が価値となるシステムでは「運用に引き渡すまでに時間がかかる」のは大きな問題になります。
そこで開発チームと運用チームがツールを共有し、なによりもお互いが尊重しあうことで、よりよいWebサービスの運営が可能になるのではないか、といったことが投げかけられていました。
この講演は大きな反響があり、インスパイアされた人々がDevOps Daysを立ち上げ、2009年にベルギーのヘントで最初のイベントが開催されました。これをきっかけに「DevOps」という言葉が大きく広がることになります。
このころのDevOpsは「開発チームと運用チームが協業する」といったメッセージ性が強かったように思います。しかし、「DevOpsとは開発チームと運用チームが密接に協業する」という認識は誤解を招きそうです。
NoOpsあるいはPaaS
2011年にリサーチ会社Forester ResearchのVPだったMike Gualtieri氏が「I Don’t Want DevOps. I Want NoOps.（DevOpsはいらない、NoOpsだ）」というブログを公開します。非常に良い内容だったのですが「NoOps」という言葉が強かったため炎上してしまいます。
NoOpsを理解するには、2012年にビデオストリーミングサービスNetflixのクラウドアーキテクトAdrian Cockcroft氏が「Ops, DevOps and PaaS (NoOps) at Netflix」というブログがよいです。このブログはNetflixにおける具体的な取り組みを紹介しながら、DevOpsやNoOpsをうまく説明しています。概要は以下の通りです。
DevOpsとは何か？
これまでの話を整理すると以下の図になります。
左は従来の「開発者チームは運用チームに引き渡して運用してもらう」という考え方。これに対して右は「運用作業をツール化することで開発チームが運用する」という考え方になります。このツールの提供を行うのはDevOpsエンジニアという役割です。この結果、データセンターのいるようなオペレーターは不要（NoOps）になるのです。
なお、こうしたインフラ構築や運用作業のツール化が可能になったのはクラウドサービスなどによるインフラの仮想化と、それによるIaC（インフラのコード化）が要因となります。
というわけで、私の思うDevOpsの定義は以下の通りです。
- 開発チームは、担当するサービスの開発作業だけではなくインフラ構築や運用作業を行う
- 開発チームがセルフサービスでインフラ構築や運用作業をするためのツールを整備する
- 本番運用における障害は開発チームに対して直接的に通知される（ので、障害復旧の自動化を努力）
逆にDevOpsではないのは、以下のような状態です。運用チーム自身が楽になるための自動化はとても良いことですが、それはDevOpsとは異なると思っています。
- 運用チームは、色々なサービスを運用するために作業の自動化を推進する
- 開発チームは、コードを書くだけで、そのあとのことが自動化されても気にしていない
DevOpsでは何に取り組むべきか？
まず取り組むべきなのは組織内で「開発チームがインフラ構築も運用もやる」という前提を共有することです。これがないことにはすべての作業の目的を間違えることになります。
開発チームが運用したほうが効率的なのは以下のような点です。これらは取り組みを進めていく中で成熟していきます。
- インフラ作業や運用作業をしたいときに調整に時間がかからない
- PaaS/SaaSの選択や、インフラ構成によるスケールアウトなど、設計の選択肢が広がる
- 自分たちで運用するので保守性の高い仕組みになっていく
具体的には以下のようなことから取り組むのが楽だと思います。
- Dockerを使い、アプリケーションの実行環境をコンテナ化する
- パブリッククラウドサービスを使い、PaaS/マネージドサービスだけを利用する（VM利用禁止）
- IaCツールを使い、インフラ構築を行う
- CIツールを使い、ソースコードレポジトリからコンテナレジストリへのプッシュを自動化する
- CDツールを使い、コンテナレジストリからデプロイまでを自動化する
- モニタリングサービスを使い、ログ監視とAPMを行い、開発者に通知を飛ばす
- 各種ツールを組み合わせて、障害からの自動復旧や予防的なスケール変更を可能にする
もちろん、これらすべてを開発チームだけでやり切る必要はありません。運用チームなり、DevOpsを支援するチームが開発チームを横断して取り組みを推進していきます。
DevOpsが進んでいくと、システム全体の回復性、管理力、可観測性を高めることができます。これによって開発チームは、より楽に運用を行えるため、新機能の提供に集中できます。また、インフラ構成の管理コストが大幅に下がるためサーバ台数を増やすことが容易になります。そのため機能単位でサービスを分割する、いわゆるマイクロサービスの実現が可能になっていきます。
まとめ
DevOpsとは「開発者自身がサービスのインフラ構築から運用までやったほうが効率的だ」という前提に基づき、様々な運用作業のツール化を推進しているものと考えています。これらのツール化にはDevOpsエンジニアという新たな役割が必要になります。
多くの日本企業では「開発チームが運用する」という前提を組織で共有することが最大の壁になりそうです。これは部署の役割を変革し、新しい職種への転換を要求するからです。一方で、これを実現するためには開発部門と運用部門の協業が必要です。そういう意味ではDevOpsが「開発と運用の協業」というのは本質的なことなのでしょう。
