about DevOps…

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

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

([*2] DevOps の教科書と言われている “Web Operations”  が日本語訳されました。必読!)

私が最初に DevOps という言葉を聞いたのが、(現在は OpsCode VP of Training & Services である / DTO Solutions に最近移籍した/が最近 enStratus に参加した) John M Willis さんの PodCast でした。(IT Management & Cloud Podcast) (2009年11月にベルギーで行われた初のDevOpsイベント devopsdays ’09 Belgium に参加するぞ・参加したぞ話でした)(Michael Cote さんか RedMonk を辞めて Dell に行ったので 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 についてのビデオを見てください。(OpsCode の CTO は  Christopher Brown さん[EC2 のアーキテクト]に代わった)

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 が無ければ成り立ちません。

  • The application is the infrastructure.
  • The infrastructure is the application.

さて、 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 はニセモノですね）

Configuration

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

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

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

Orchestration

IaaS 型の Cloud での必須事項は、API が提供されている事です。 Infrastructure を code のようにプログラミングできる事が極めて重要です。(これが出来ない IaaS 型の Cloud Computing はニセモノですね 再）

Puppet や Chef といった CM Tools を利用して、Infrastructure の Configuration を行います。

また、この仕組みを利用する事により、Scale out や  Scale in といった動的な構成変更や、障碍対応を自動的に行います。 (Automation and Orchestration)

ここで重要なのは、System Architecture を Automation and Orchestration を前提とする事です。

こういった、一連の Orchestration を可能とする、RightScale のような、Cloud Computing Management Tool を利用するのもいいでしょう。

application code の deployment も nanite、 capistrano、 ControlTier といった Control Tool を利用するのもいいでしょう。

このような Dev と  Ops のプロセスも、もちろん協調しないといけません。Tool の連携も重要です。

Measurement

Sharing

Dev と Ops の対立の最も多い原因は障碍に関する事ではないでしょうか。

それには、精緻な Monitoring と Visualize が有効になるでしょう。

障碍をいち早く発見 (MTTD, Mean Time To Detect)、いち早く復旧 (MTTR, Mean Time To Resolve) できる事に焦点を置いた設計をすべきです。復旧に関しては、簡単に rollback で出来るような、非常ボタン的な仕組みを必ず入れておくのも有効です。

また、Application からも、OS や サーバが出すのと同様に Metrics データを出すようにすべきです。これも Monitoring と Visualizeにより有効に利用します。

Dev と Ops で状況を共有する仕組みもまた重要です。Deployment に関して、Dev の開発プロセスと Ops のデプロイプロセスの情報をそれぞれが共有できるようにすべきです。

Culture

Web Apps, Web Services は Software だけでは成り立ちません。Infrastructure も含めた総合的なサービスです。そのための仕組みは、現在では様々に提供されています。(DevOps Toolchains)

最後にもう一度強調しておきますが、Tool をつかえば良しというわけではありません。Dev と Ops は ビジネスを成功させるという目的をもって、共に行動しなくてはなりません。文化を作るというより、先ず行動を変えなくてはなりません。

さぁ、始めましょう！

私が去年書いた未発表スライド

DevOps or: How I Learned to Stop Worrying and Love the Cloud

↑のスライドは “Dev > Ops” のフェーズに閉じてしまっているので、DevOps の現在を俯瞰したスライドを↓にはっておきます。

DevOps Note 20120224

View more presentations from Hirokazu MORIKAWA

このプレゼンを publickey の Junichi Niino さんが分かりやすくまとめてくれました。

(未完成。いろいろ推敲中…)

appendix:

John Allspaw (twitter) (blog)

Andrew Clay Shafer (twitter) (blog)

Adam Jacob (twitter)

John M Wills (twitter)

Damon Edwards (twitter) (blog)

Patrick Debois (twitter) (blog)

PodCast:

Conference / UnConference:

日本語での情報:

Misc:

2010年6月に行われた DevOps Day USA 2010 での話

DevOps の日本語訳は “運用のウハウハ” (c) zembutsu にしました。(嘘)