デブサミで垣間見たGoogleのDevOpsの凄さは人的要素の徹底排除にある

連載 :

イベント・セミナー2017

2017年3月17日(金)

デブサミ2017でGoogleの中井悦司氏が登壇。Googleが考えるDevOpsの理想形についてGoogleパブリッククラウドサービスをベースに解説を行った。

ソフトウェア開発者のためのイベント、デブサミ2017（Developers Summit 2017）が2017年2月16、17日の両日、都内で開催された。今回は多くのセッションから「Googleのインフラ技術から考える理想のDevOps」と題されたセッションを紹介する。これは昨年までレッドハットでエバンジェリストとして活躍していた中井悦司氏が担当したセッションで、Googleの社内システムを通じてDevOpsのあるべき姿を紹介するものだ。

SREの書籍を紹介するグーグル合同会社クラウドソリューションアーキテクトの中井悦司氏

このセッションで中井氏はGoogleが考えるDevOps、つまり開発と運用を連携させる際の注意点を実際にGoogleが提供するパブリッククラウドサービスを例に挙げながら解説を行った。理想のDevOpsを実現するためにGoogleが考えるポイントを、Googleのインフラチームが書き上げた「Site Reliability Engneering（SRE）」の書籍を紹介した上で解説するというものだ。実際には、Google Cloud Platformの各種サービスのアーキテクチャーなどをすでに公開されている論文などを元に解説し、それがGoogleとしてのDevOpsの理念の上に構築されているということを伝えたかったようだ。

なお、同書は無料で公開されているので、興味を持たれた方はぜひ読んでみよう。
Site Reliability Engineering（書籍）

組織の内側から見た印象として中井氏が強調していたGoogleのソフトウェア及びインフラチームの哲学は、おおむね以下のようになるだろう。

ある問題を解決する時に常識にとらわれずに解を求めること
鬼のような合理性と洞察力
スケールすることが大前提
とにかくゼロから作り上げる
世界で誰もやったことがないような規模で発想する

Googleでは、俗に言うインフラチーム、Google的にはSite Reliability Engneering（SRE）チームの人材採用のポイントとして「ソフトウェア開発エンジニアと同等の能力、つまりプログラミングができること」に加えて「インフラストラクチャーを構築できること」が求められるという。さらに「運用という作業に50％以上の時間を使わないこと」も求められる。これは実際に稼働する時間の半分以上を「運用を自動化するためのコードなどを書くこと」つまりソフトウェアの開発を行うことが要求されることを意味している。その上で、お互いが理解しあうことが必要と語る。

GoogleのDevOpsのポイントはお互いを理解した上で依存をなくすこと

また中井氏のセッションでは強調されなかったが、Googleが公開しているSRE関連のインタビューによれば、Googleでは「運用のためにヘッドカウントがリニアに必要となるサービスは必ず失敗する」という経験則があるという。つまり、成長に合せて運用に携わる人員が増えていくサービスはダメだ、ということである。さらに、「人員の数が増えると品質は低下する」とも断言している。

またSREには「エラーバジェット」と言う数値が設定され、それを超えないように運用を安定化させるという。つまり99.9%の稼働率であれば、年間に8時間強のダウンタイムが「発生しても良い」という上限を設けて、その値を超えないようにテストを行い、システムを冗長化するという目標だ。これはエンタープライズにおいても参考になる発想で、あるシステムを実装する際に1年間に何時間、そのシステムが止まっても許されるのか？　をビジネスから発想して、それを開発と運用にチームに落とし込むというものだ。

さらに稼働率の目標を達成するために、つまりエラーバジェットを超えないようにするために「ダウンタイムとダウンタイムの間隔を伸ばすこと」と「リカバリーに必要な時間を減らすこと」の2つの軸でシステムの運用を自動化する必要があると、このインタビューでは語られている。この辺りの評価軸も、エンタープライズが自社IT基盤を構築する上で参考になる考え方だろう。

ここから読み取れるのはGoogleにとっての運用とは、「人間のインタラクションを極力少なくしてソフトウェアで解決する」ことだと言える。

SREに関するインタビュー

このセッションに参加して「じゃぁ、オレたちもGoogle式のDevOpsをやってみよう」と思う参加者は皆無だろうが、上述のエラーバジェットという考え方は大いに参考になるだろう。

このセッションを聴いて、今後ITに関するイノベーションが起きるのは、GoogleやFacebook、Twitterなどの巨大なサービスを提供している「エンドユーザー」に限られるのではないか？　という印象を受けた。これはなによりも自分たちが顧客としてサービスを開発することで、ソフトウェアやプラットフォームに対する挑戦が日夜繰り返され、それが最終的にオープンソースとして公開されることで市場に受け入れられ、さらにソフトウェアとして鍛えられていくというサイクルがすでに完成しているように思えたからだ。Googleが盛んに自社サービスに関する論文や解説記事を公開すること、自社のコンテナーオーケストレーターであるBorgをKubernetesとして公開したことなどをみると、商用ソフトウェアベンダーがユースケースや顧客を想定してソフトウェアを開発し、それを販売するというモデルは、エンタープライズ向けでは限界かもしれない。レッドハットのようにオープンソースソフトウェアのサポートを生業にする、もしくはオープンソースソフトウェアをパッケージングして品質を保証するサービスなどが独立系のソフトウェアベンダーの「この先生きのこる戦略」のように思えてならない。

Googleの中井氏のプレゼンテーション