Andrew Clay Shafer氏が語る、DevOps、CI、マイクロサービス：Puppet Labs共同創業者

　Andrew Clay Shafer氏は、オープンソースのIT運用自動化ツールであるPuppetを生み出した米Reductive Labs（現Puppet Labs）を、現CEOのLuke Kanies氏とともに創業した人物だ。生粋のプログラマーで、「Infrastructure as Code」の考え方を広めた人でもあり、DevOps、アジャイル開発、プログラミングと組織文化などについて、数々の講演を行ってきた。Reductiveの後には米Cloudscaling、米RackspaceでOpenStackに関与し、現在、米Pivotalでシニア・ディレクター・オブ・テクノロジーを務めている。2014年12月にPivotalジャパンサミット2014のため来日したShafer氏に、DevOps、継続的インテグレーション（CI）、マイクロサービスについて聞いた。

Googleに「SRE」という職種がある理由

―― DevOpsについては、さまざまな解釈が見られます。あなたが考えるDevOpsの意味を、改めて教えてください。

　まず、「サービス中心の世界において、サービスが機能していないならばアプリケーションは存在しないも同然だ」ということを理解すべきです。だからこそ、ソフトウェアの開発と運用の間に、壁があってはならないのです。

　従来型のITの世界では、開発者は物事に変化をもたらすことが仕事であり、運用担当者は物事に安定をもたらすことが仕事でした。しかし、システム運用担当者は、変化こそビジネスへの貢献だということを理解しなければなりません。一方、開発者が、データベースのダウンや運用担当者の睡眠不足につながる判断をするなら、その判断はビジネスに貢献していることにならないと理解すべきです。

Andrew Clay Shafer氏

　現実の状況を改善するための1つのポイントは、運用上の「痛み」をもたらす判断をする人たちに、その痛みを感じさせることです。大規模なWebサービス企業にいる開発者は、みんなポケベルを持っています。「あなたがダメな判断をしたら、その痛みを感じるべきなのはあなた自身だ」というわけです。

　ソフトウエアデリバリには、「プロダクトマネジメント」「開発」「QA」「運用」「顧客」という段階があります。この全ての段階で、物事がストップする可能性があります。

　このため、グーグル、ネットフリックス、フェイスブック、アマゾンなどは、かなり前から「SRE（Site Reliability Engineer）」という職種を置いています。SREとはグーグルの用語ですが、この人たちの重要な仕事は、QAと運用の間に、APIを構築することです。これで、運用より前のプロセスは、開発者のセルフサービスになります。つまり、開発者にとっては運用以降がいわば「プラットフォーム」であり、その前があなたのソフトウエアだということになります。

　継続的インテグレーション（CI）への移行が進むにつれ、手作業のQAプロセスを排除する傾向が強まっています。これには、テストの自動化への強いコミットメントが求められます。

　Amazon.comは11秒ごとにデプロイを実行しているといっています。こうしたレベルになると、人間は判断のみを行い、反復的な作業はマシンにやらせるしかありません。

　DevOpsの関係者は「Infrastructure as Code」という言葉をよく使いますが、インフラをAPIで構成し、プロビジョニングできるのであれば、事実上ソフトウェア開発と酷似してきます。ソフトウエアを提供する際に使ってきた、あらゆるツールやプロセスを、インフラ関連のプロセスに適用できることになります。これも、DevOpsあるいはアジャイルインフラストラクチャの一部です。

DevOpsをめぐる自由と責任

―― 自動化ツールを使い、ソフトウエアライフサイクルの後ろの段階までコントロールしたいと考える開発者は多いと思いますが、これは今後不可避でもあるということですね。

　これにはトレードオフがあります。開発者はある程度の自由を獲得できると同時に、責任を負うのです。従来型のITでは、開発者は運用担当者に（開発を終えたソフトウエアを）投げてしまえます。一方、グーグルやアマゾンでは開発者がコードを本番環境に投入しますが、（運用で）問題が発生したときに、夜中でもたたき起こされるべきなのは、運用担当者ではなく、開発者です。

　先進的な組織のITは、こうしたやり方で運営されています。競争優位の確保に不可欠だからです。ソフトウエアは経済的な戦争です。アマゾンやグーグルは、趣味でソフトウエアを作っているわけではありません。彼らにとっては市場を攻略することが目的です。勝つために、これをやっているのです。

―― 自動化のためのツールを使いこなせばDevOpsが実現できると思いますか？

　自動化はDevOpsのストーリーの一部です。DevOpsに欠かせない要素は、「コラボレーションを促進する文化」「自動化」「計測に基づく活動」、そして「組織の内外で情報を共有すること」です。

　IT業界では、オープンソース活動やメーリングリストなど、あらゆるところで情報共有が行えるようになりました。シリコンバレーでは、勤める会社は違っても、業務時間外に、自分たちの抱える課題について話し合い、解決策を共有することができます。例えば私にはたくさんの友だちがいます。私が何かの問題に遭遇しても、友だちに連絡すれば、多くの場合、1時間で返事をもらうことができます。

マイクロサービスはオブジェクト指向の進化形

―― この文脈で、マイクロサービスについてはどうとらえるべきだと考えますか？

　従来型のモノリシックなアプリケーションでは、全コンポーネントを1つに統合し、一度にデプロイしなければなりません。このこと自体、より複雑なプロジェクトでは、各回のデプロイコストを引き上げてしまいます。だいたい、あなたが担当する機能が完成したとしても、他のコンポーネントの開発が遅れていると、あなたはデプロイできないまま、待たされることになります。

　マイクロサービスでは、デプロイメントのみならず、機能に関しても作業の分離が実現します。私は、次のような表現をすることがあります。

　「オブジェクト指向は、その考え方は優れていたものの、静的なコードに関する話だった。しかし、サービスは常時変化し続けるコードを求める。だから、オブジェクト指向の考え方を、常時変化し続けるコードに適用する。これがマイクロサービスだ」

　大規模で複雑なアプリケーションの場合、ある箇所に変更を加えると、別の箇所で問題が発生することがあります。マイクロサービスでもこれが完全になくなるわけではありません。ですが、全てが同一のJava環境ではないため、コンポーネント相互が、より明確なコントラクトで結ばれるようになります。

　「Conway’s Law」という法則では、「システムの設計は組織の構造の鏡である」とされています。コード相互間のコミュニケーションは、そのコードに関わった人々の間のコミュニケーションのあり方を反映するのです。ネットフリックスのAdrian Cockcroft氏は、このことをよく話しています。

　マイクロサービスのアーキテクチャは、Conway’s Lawを反転させるものです。最適なサービス、最適なコード間の関係を実現するために、開発チームや周辺の人々の関係を設計するべきなのです。

―― アマゾンでもフェイスブックでもない、一般企業の人たちが、DevOpsや継続的インテグレーション、マイクロサービスに興味を持つべき理由を、どう表現しますか？

　あなたの会社が、このような企業と競争するようになるからです。私たちの持ち歩いている携帯電話は、一昔前のスーパーコンピューターを上回る演算能力を備えているだけでなく、データの海に接続しています。ソフトウエアがどうこうという以前に、あらゆる人たちがリアルタイムで情報に接続できること自体が、ビジネスの力学を変えてしまっています。例えばサンフランシスコでは、Uberなどの影響で、既存タクシー運転手1人当たりの月平均ユーザー乗車回数が、2014年にかけて60％も減少しました。

　DevOpsや継続的インテグレーションに興味を持たなければならないということはありません。誰も、生き残らなければならない義務を負っていませんから。こうした企業と競争しないという判断もあり得ます。ですが、不利であることは確かです。

―― それは企業の経営陣が気付かなければならないことですよね？

　ええ、現場の人たちが理解していても、トップからのサポートがなければできません。逆に、トップが理解しているにもかかわらず、中間管理職や現場の人たちのサポートを得られない場合もあります。先ほど、「コラボレーションを促進する文化」がDevOpsに不可欠だと言いましたが、開発と運用の間だけでなく、上下の間にも当てはまると思います。

―― では、自分は理解しているけれど、会社の他の人たちが分かってくれないという人たちに、何かアドバイスはありますか？

　このメッセージを理解する人を見つけ、まずは小さな成功を目指すことです。大規模な組織では、全てを一度に構築するのは無理があります。小さな成功を積み重ね、徐々にこれを広げていく必要があります。

　ガートナーは「バイモーダルIT」という概念を提唱しています。この概念では、既存のアーキテクチャのシステムと新しいアーキテクチャのシステムを並行して走らせ、既存のシステムの一部を少しずつ新しいアーキテクチャに変えていくことが議論されています。

　重要なのは、変えるのに十分な動機や目的が見出せるシステムを移行すべきだということです。組織全体についても同じことが言えます。危機を感じていない組織ではうまくいきません。十分な動機が生まれないからです。