about DevOps…

最近よく DevOps という言葉を聞くようになりました。まだ日本語での記事が少ない[*1]ので、自分なりに DevOps について書いてみます。

([*1]現在のところ、唯一といっていい DevOps についての日本語での情報。paperboy&co. の CTO 宮下剛輔さんのまとめとスライド)

私が最初に DevOps という言葉を聞いたのが、(現在は OpsCode VP of Training & Services である) John M Willis さんの PodCast でした。(IT Management & Cloud Podcast)

開発(Dev)での Agile Development の流れを受けて、2007年前後から、運用(Ops) でも、Agile Operations, Agile Infrastructure という流れがあったようです。(2006年8月に登場した Amazon EC2 のような IaaS 型の Cloud Computing はこの考え方から生まれたと言ってよいでしょう。本件のちほど考察)

2009年6月に開催された、Velocity 2009 での John Allspaw さんの講演で DevOps が注目され、話題になりました。(ビデオ / スライド)

以下、議論を分かりやすくするために、 Web Apps, Web Services の事業者に話をフォーカスします。(Web Service 以外については後述)

Agile Development は、Steve Blank 氏のいう Scalable Startup 段階での、Customer Development における手法に適しています。

Continuous Deployment
Continuous Learning
Self Organizing Teams
Minimum Feature Set
Pivots

そこで興味深いのは、Web Service においては、Startup 段階を超え(Transition)、ビジネスモデルを確立した後も、Agile でなければならないという事です。

これは Web Service 自体のマーケットが激しく変化し続けているからにほかなりません。

agile and iterative で Web Service を実現するにはどうしたら良いのでしょうか? また、急速に成長(スケール)するにはどうしたら良いのでしょうか?

それを実現するためには、開発(Dev)、サーバ運用(Ops)、データベース管理(Dba)、ネットワーク管理(Net)、セキュリティ管理(Sec) etc に関わる全ての人々が、ビジネスを成功させるという目的を持って協調しなければなりません。(もちろん、これはエンジニアだけの話ではありません。セールス、マーケティング、マネージメントも同様です)

マーケットが変化し続けるビジネス分野で、agile and iterative を維持しつつ、成長するビジネスに取り組むか。これが、DevOps という言葉で言われる、Cultural and Professional Movement なのです。

Velocity 2010 での OpsCode の CTO Adam Jacob さんの DevOps についてのビデオを見てください。

Cultural and Professional Movement

(DevOps はツールなどの技術の話ではない。文化として、プロとしての運動である)

Traditional Systems Operations -> WebOps

(Internet 分野では、ある日から Web というものがはびこり、運用は WebOps になった）

It is not a Job Description

(DevOps は新しい職種の話でもない)

(DevOps は現状では、二種類の捉え方をされている。inclusive な考えと exclusive な考え)
The movement is inclusive

Awesome
Happy
Cool
Built neat stuff!

There are exclusive people

Grumpy
Tool-centric
Us vs Them
I’m a DevOps, you’re a Sysadmin!

Join the inclusive people. We’re neater

inclusive でやろうよ!

Adam Jacob さんが Professional という言葉を使っている事には重要な意味があると思います。Dev や Ops が無くなって(融合して)、DevOps という職種になるのではなく、それぞれの立場でプロとしての仕事を協調して行うという意味です。(Dev, Ops, DBA, Net, Sec etc はそれぞれプロフェッショナルとしての専門性と責任が必要なのです）

[Choose Your Own スライド PDF]

では、DevOps という Cultural and Professional Movement を実現する為には何をすれば良いでしょうか?

これは非常に難しい。

Velocity 2010 での John Rauser (Amazon) さんの Creating Cultural Change についてのビデオをみてください。

どうでしたか? Amazon のような、活発にイノベーションを行っている、いわゆるエクセレント・カンパニーでも(だから）、このような地道な努力・啓蒙をしているのです。

ここで、経営やマネージメントを真剣に考え勉強した事のある人は「あらあら何処かで聞いたことある話だな」と思うでしょう。カーネギーやドラッカー、マズローがいっている事を実践しているのですね。

一旦ここまでのおさらい。

Web Service はマーケットが変化し続けている : agile and iterative Development
ビジネスを成功させるために一丸となる : DevOps = Cultural and Professional Movement

さて、DevOps = Cultural and Professional Movement であるという事を頭に叩き込んだので、これを可能とした技術的背景に移ります。

なぜ今 DevOps なのでしょうか?

なぜ今エンジニアリングでこのような運動がおきているのでしょうか?

Web Apps, Web Services に於いては、冒頭で説明したとおり、agile and iterative でビジネスに取り組む必要があります。開発の分野では、Agile Development という取り組みがあり、開発、テストの分野では成果が出ています。当たり前の事ですが、Web Apps, Web Services は Software だけでは成り立ちません。Dev が開発した Software が動く Infrastructure が無ければ成り立ちません。

さて、 Software を稼働させるには、それを支える複雑な仕組みが必要です。サーバーは? CPU? メモリーは? ストレージは? RAID構成は? NAS? SAN? 何台? ラックは? 耐荷重は? ネットワークの構成は? 電力は? 空調は? セキュリティは?…といった多くの要素の組み合わせになります。
もちろん、この複雑な仕組みは、Software の設計に応じて、基盤も設計し実装すれば良いわけです。

しかし、Web Apps, Web Services に関しては厄介な事が起きます。agile and iterative を要求される事です。

D:「新しいビルドをリリースするので、打ち合わせ通り、DB サーバを2台追加して、共有ストレージ追加してねぇ。で、今日明日中に検証よろしくね」

O:「あれ、手配間に合わないっていったぜ」

D:「これって先週、依頼してたじゃん」

O:「サーバはベンダーからの納品待ち。で、代替案をおたくのマネージャーにいってたでしょ」

D:「んー今出せば受ける機能を実装したので、どうしてもすぐリリースしないといけないんだ。で、当初はアクセスが集中するので(ユーザがザクザク増えてうれしー）一時的にフロントWeb 鯖 5台追加しといてね」

O:「おいおいおいおい。そんなの無理」

D:「なにー。俺たちはビジネスを成功させるために必死に開発してるのに、タイミング逸したら意味ないじゃん。いつもいつもNoばっかり言ってんじゃねーの。何とかしろよ」

O:「む! こっちは安定稼働させるために命張ってんだ。ころころ仕様変更されて事故がおきたらどうする。しっかり設計する時間くれ」

D:「じゃぁ、おめー達のせいでお客様がにげていいのか?」

O:「それとこれとは話がちがう。もっと前もって間違いのない仕様をこっちに渡してくれよ。いつも直前にならないとフィックスしないからこうなるんじゃねーの」

D:「なにー、こっちは新しい開発手法を一生懸命勉強して、スピーディにリリースしようと努力してんだ。テメーたちも努力しろ」

O:「なにぃぃぃぃぃ」
(以下、書けない…)

さて、この架空の会話（生々しいねぇ）で提示された問題点について考えてみましょう。

Web Apps, Web Services は agile and iterative で Continuous Deployment が必須である事は理解したとして、どうやって実現できるのでしょう。

Bootstrapping

上の話で、サーバの手配が間に合わない問題にはどうしたら良いでしょう。

OK OK 事前に余裕を持って設備を購入して準備しておくという手もあります。しかしながら、この対策は、この設備投資に対しての根拠を説明できないと CFO から大目玉を食らうでしょう。(このパターンで成り立つモデルは後述)

さてさて、余分な投資無しに、タイムリーに設備を利用する方法は無いのでしょうか？そうです。ここに、AWS EC2 のような IaaS 型の Cloud Computing の立脚点があるのです。

必要な時にすぐにサーバが使える(On-Demand)、需要がなくなれば捨てられ、課金されない(Pay-as-you-go)。IaaS 型の Cloud はこの Bootstrapping の諸問題を解決してくれます。(これが出来ない IaaS 型の Cloud Computing はニセモノですね）

Conﬁguration

インフラは何時でも手配できるとして、プログラムが要求する環境をつくらないといけません。IaaS 型 Cloud はこの点でも有効です。一度環境をデプロイしたマシンイメージを保存しておいて、必要になればそのマシンイメージからサーバを作成するといった作業が簡単に行えます。(これが出来ない IaaS 型の Cloud Computing はニセモノですね再）

しかし、ここで問題が発生します。プログラムが要求する環境といってもそれはひとつではありません。Web サーバであったり、DBサーバであったり、ファイルサーバであったり、要求される機能によって、サーバの Configuration は様々です。その多種多様なサーバイメージをすべて準備しておくのは利口なやり方ではありませんね。

Puppet や Chef といった Configuration Management tool の出番です。