DevOpsとは何か

――DevOpsという言葉についてどう思いますか？　DevOpsは実体のある概念でしょうか？　それとも中身のないバズワードでしょうか？

ディボウィッツ氏　人々は言葉を造りたがるのだと思います。物事にレッテルを貼りたがるのです。しかし、この言葉の考え方は役に立つと思います。

　私が初級管理者だった1990年代末から2000年代初めにかけて、こういわれたことがあります。「上級管理者と初級管理者の違いは、上級管理者はコードを読み書きできることだ」と。確かに管理者がコードを読み書きできれば便利だと合点がいきました。私はコンピュータサイエンスの学位を持っていて、膨大なコードといつも格闘するのは面白くなさそうだと思っていましたが、それが便利なことは分かったのです。こうした当時の考え方が、現在見られる考え方の源流のようなものではないでしょうか。そして人々は今、この考え方やその実践をDevOpsと呼びたがっているわけです。

　結局のところ、運用管理の担当者はコードを読み書きできる必要があります。サポートしているアプリケーションを理解できなければならないことが理由の1つです。さらに、システムの規模が拡大すると、コードを書けなければ運用管理を効果的に自動化することができないという理由もあります。

　マシンごとに手動でログインするのでは、すぐにうまくいかなくなります。こうしたやり方で対応できるシステム規模はたかが知れています。数万台のマシンを抱えていたら、1台ずつSSH（Secure Shell）でログインしてコマンドを実行していくわけにはいきません。ですが、それを自動化できれば、そうした環境を効率的に運用できます。

　DevOpsの定義は人によって少しずつ違うでしょうが、そこが肝心な点です。私としては、実は呼び名は何でも構いません。要するに、「自分が担当している仕事の上手なやり方のこと」だと思っています。それをDevOpsと呼ぶ人々がいるわけです。

開発者による構成管理作業を可能にしたChef

――DevOpsの考え方になじみがない人へのアドバイスをいただけますか？

ディボウィッツ氏　最大のポイントは発想の転換です。例えばレガシーインフラを扱っていると、このように考えがちです。「自分の担当はDNSサーバとメールサーバで、AのサーバにログインしてBのことをしなければならない」。しかし、こうした発想では規模の拡大についていけません。いつか、必要なDNSサーバが5台、メールサーバが10台、Webサーバが30台になり、さらにはそれらが数百台、数千台規模になる可能性があるのです。

　そこでサーバではなく、環境について考えることが必要になります。自分の環境の望ましい状態を、何らかの便利な方法を使ってどう表現するかを考えるのです。その便利な方法があれば、「自社の環境の望ましい状態」の定義を外部に移し、自分の環境の全要素をいつでも高速かつ簡単に、自動的に再生成することが可能になります。

――そうした表現方法の1つとして、今日の講演で「データとしての構成」について言及していましたが、これは具体的にはどのようなものですか？

ディボウィッツ氏　「データとしての構成」とは、システム管理の設定やパッケージの配置を表すハッシュなどのことです。システム管理者がシステムやシステムグループの構成作業の一部をソフトウェア開発者に任せたい場合、開発者がシステム管理の方法を知らなくても、また、Chefや「Puppet」「CFengine」など、管理者が使っているツール全てを知らなくても、そうした情報があれば、自らの環境でアプリケーションに必要な構成の一部を、彼らにとってなじみ深いツールを使って管理できるようになります。この「なじみ深いツール」とはコードとデータです。開発者は皆、コードとデータで作業しているのです。

カナウアティ氏　この例をさらに説明すると、開発者は「共有メモリを増やす必要がある」といったことは知っておく必要があるかもしれません。しかし、例えば「アプリケーションがLinuxマシン上で稼働している、Linuxシステムの/etcディレクトリにはsysctlファイルがある、sysctlファイルに設定を記述したら、それを有効にするためのコマンドを実行する必要がある」ということは知らなくても構いません。

　つまり“データとしての構成”は、例えば「共有メモリを増やす必要があること」をファイルで示し、開発者がそのハッシュのごく一部を変更するだけで、必要な構成管理作業が自動的に行われる仕組みを提供するものです。開発者はこのような仕組みを好みます。システム管理のことを知らずに済むからです。彼らは、共有メモリを増やす必要性だけを知っていればよいのです。

――構成自動化ツールの比較評価を行いましたか？

ディボウィッツ氏　はい。われわれはPuppet、Chef、Spineを評価しました。Spineは聞いたことがないでしょうが、私がオンラインチケット販売会社のTicketmasterで働いていたときに、開発に使ったツールです。

　われわれはまずスタッフに、3つのツールそれぞれの有望度を評価させ、各自に、自分が最も高く評価したツールではなく、最も低く評価したツールを提供しました。そして、自分に提供されたツールが選定されるように、社内PRとカスタマイズに精いっぱい努めるよう求め、数週間にわたって操作習得とカスタマイズの準備に当たらせました。

　この期間を経て、3つのツールごとにスタッフが合流し、われわれはそれぞれについて、数種類の機能と、かなり複雑なわれわれのSSH設定を実装しました。続いて各ツールのコード、スタッフ1人1人による各ツールの試用体験、われわれのモデルへの各ツールの適合度を評価しました。

　3つのツールのどれを使っても、目的の作業を行えました。ですが、われわれのケースでは、Chefの柔軟性がわれわれのワークフローニーズに最適でした。Chefでは、Rubyのパワーをフルに活用して、自社のシステム構成を表現、変更できるだけでなく、Chef自体を拡張したり変更したりすることもできます。われわれは、Chefの内部要素であるnode.saveに手を加え、Chefの動作を変更しました。

　われわれは、思いのままにChefに変更を加えることができたので、このツールに合わせてワークフローを変える必要はありませんでした。 Chefのもう1つの魅力的な特徴として、全てがクライアントで行われることから、サーバモードで使うかどうかを選択できたことも挙げられます。他のツールではこうはいかなかったと思います。