アプリエンジニアとインフラエンジニアの壁をぶち壊せ　「線をどこに引くか」ではない“責任境界”の考え方

アプリエンジニアとインフラエンジニアの関係の変化

星野真知氏：「開発者と運用者の壁をぶち壊せ！　InnerLoopとOuterLoopとは？」というところで、VMwareの星野から解説します。

（スライドを示して）さて、このCloud Operator Daysですが、（参加者は）インフラエンジニアの方々が非常に多いと思っています。

アプリとインフラエンジニアの関係は、昔と比べて非常に変わっていると思います。それこそクラウドがなかった10年前は、インフラエンジニア、アプリエンジニアという言葉が象徴するように、インフラのところに責任境界点を設けていました。

アプリの方々はシステムにおける機能要件に当たる部分を実装して、インフラの方々が例えばパフォーマンスであったり、可用性もしくはセキュリティ、特に昔はセキュリティといったらネットワークファイアウォールが中心だったので、そういった実装をするのが一般的だったと思っています。

ところが、時代はだいぶ変わってきてしまいました。（スライドを示して）すべてがすべてとは言いませんが、多くのお客さんはこうなってしまっていると思っています。

何が起きたのか。アプリの方々は、インフラの方々が設ける制約に、非常に苦労をし始めたわけです。どうにかより自由な空間はないものなのかと、インフラの方々に束縛を受けない世界、クラウドを求めてしまったわけです。

クラウドに行ったアプリの方々は、基本的にインフラの方々の制約を受けず、自由にアプリを作れるようになってきました。今、多くの現場で起きていることは、インフラの方々がいわゆる塩漬け環境、仮想マシンのガバナンスのみを見るようになってきてしまって、クラウドの開発においてはなにか制約などを設けることは基本的にできません。

それをやると、またアプリの方々に怒られてしまいます。そんなことが起きていることがすごく多いと思っています。

境界線の変化で起きた「環境がスケールしない」問題

この関係がすごく悪いのかというと、そうじゃないと言う人もけっこう多いと思うのですが、1個大きな問題が出ています。

（スライドを示して）この絵は、Amazonさんが提供しているWordPressサーバーのベストプラクティス構成図です。アプリの方々、それからインフラの方々が設ける制約。それは何だったかというと、非機能要件におけるものが煩わしくてどんどんクラウドに行くわけですが、決して非機能要件から逃れるわけではありません。

これはAmazonさんが明確に言っています。彼らが提供するのはあくまでプリミティブ、原始的なもの、いわゆる絵にある一つひとつのオブジェクトまでであると言っています。そこからはユーザーたちが自由に作れると言っているのですが、それはつまり、クラウドに行く方々が自分で設計してやらなければいけないということです。

こういったところから、クラウドにおいても非機能要件が我々を阻み、その結果、アプリの方々が設計すると、どうしても環境がスケールしないという問題です。これは特にグローバルを先に、少しずつ日本などでも起きています。

「境界線をどこに引くか」という議論は間違っている

（スライドを示して）我々VMwareはこれをどう考えているのかというと、やはりもともとあった、「アプリは機能要件、インフラは非機能要件」という関係に戻すべきだと思っています。

戻し方はどうするのかというと、インフラエンジニアをクラウドに連れていくことだと思っています。例えばコンテナのような技術を使って、ガバナンスが利かせやすいプラットフォームを作っていきます。非機能要件の責任を取っていきます。

アプリの方々は、走っているクラウドなどを意識せず、昨今多い非機能要件、特にセキュリティの責任をインフラの方々にオフロードしながら、どんどん開発に集中する環境を作っていくことが重要だと我々は思っています。

これを実現する上で、今コンテナを検討されている方がけっこう多いと思っています。（スライドを示して）この絵は、ハードウェアは抜いています。OSの下にハードウェアやファームウェアがあると思ってください。OSがあって、コンテナランタイム、いわゆるDockerやKubernetesがあって、その上にコンテナ、ベースイメージ、OSS（Open Source Software）、アプリという観点があります。

（スライドを示して）今までの我々インフラ・アプリエンジニアの感覚だと、アプリエンジニアとインフラエンジニアの責任境界点は、ここに引いちゃう方々が、けっこう多いと思っています。ここに引くと、例えばコンテナの中にもOSの要素が入っています。コンテナの中にも、アプリケーションとOSSのライブラリがあります。そこに脆弱性が出た場合、これは誰の責任なんでしょうね？

我々がいろいろお客さまと会話する中で、コンテナに行きたくないというお客さまの中には、この問題を指摘する方がけっこう出ています。

インフラエンジニアが本来責任を持つべきところに対して、責任が持てなくなってしまう。なので、コンテナをするのを躊躇しているお客さまがけっこう多いと思っています。

じゃあどこに線を引くべきだったのか、線をもうちょっと上に上げるべきだったのか、下に下げるべきだったのか。今我々は、その議論が間違っているとだんだん思い始めています。

InnerLoopとOuterLoopという考え方

（スライドを示して）こういった横線でアプリ・インフラエンジニアの責任を引くのではないやり方として今日紹介するのが、InnerLoopとOuterLoopという考え方です。

VMwareは、2022年1月に発表した「Tanzu Application Platform」という製品とともに、この考え方を出しています。

いわゆる開発者の方々が何が欲しいかというと、やはり自由です。そしてスピードです。InnerLoopと呼ばれているところは、基本的にガバナンスを利かせず、開発者に対してどんどんスピードを中心とした開発ができる環境を提供する。

InnerLoop。だんだん開発のイテレーションが早くなっていきます。ところが（その回転が）だんだん落ち着いてくると大きくなってきて、ゆっくりになってきて、例えばいよいよ本番環境にデプロイするとなった時。この大きくなった流れを、OuterLoopといっています。この大きな流れの時に初めて、インフラエンジニアの方々が非機能要件を入れていく、セキュリティなどを入れていく。

このように今後は新しくループをもとに責任境界を引いていくのが、いいのではないかというのが我々の考え方です。

InnerLoopとOuterLoopの具体的なイメージ

イメージが湧かないと思う方に（向けて）、もう少し具体的なイメージをお見せします。

（スライドを示して）この絵は、一つひとつの箱が別のKubernetesクラスタだと思ってください。1個のクラスタではないです。なので今は4つあります。ネットワーク分断というところから、InnerLoopとOuterLoopに分けています。

開発者の立場になってみましょう。開発者の方々がまず何が欲しいかというと、一番左のノーガバナンスです。基本的には自由にデプロイできる、速さ優先、壊れても問題ないところにどんどんアプリを開発していきます。

この作業がある程度落ち着いてきてループが大きくなってきた時、ソースコードのコミットをしていきます。ここで重要になってくるのは、InnerLoopの門番の役割をしているビルドクラスタです。

このビルドクラスタは、受け取ったソースコードをもとに、標準コンテナを作ってくる、脆弱性検査を作ってくる、Kubernetesなのでデプロイ用のYAMLファイルを作っていく。こういったものを作ることやっていきます。

開発者はここで終わりです。彼らが認識するのは、あくまで自分の開発クラスタとビルドクラスタです。ネットワークが分断された、アクセスできない先にあるのが、いわゆるインフラの方々が守るOuterLoopの世界です。この世界では、InnerLoopから生まれたYAMLファイルやコンテナを受け取って自動的にデプロイします。

例えばデータがAmazonのRDSなどにある場合には、それと連携する仕組みであったり、もしくはセキュリティエージェントを入れたり、セキュリティを常にチェックする仕組みを入れていきます。ステージングクラスタ、プロダクションクラスタと分けていますが、基本的にやることは一緒です。こうすることによって、インフラの方々がセキュリティを強化する空間を作っていくことになってきます。

今までの「アプリとOSの間のどこに線を引こうという」考え方が、だいぶ変わっていて、Kubernetesはクラスタが非常に簡単に複製がしやすいものという特徴を利用して、このように新しい境界線を引いていく考え方がもとになっています。

そのため、例えば（スライドの）一番左の開発クラスタは、安価なノーサポートの非商用のKubernetesを使ってやってもいいし、右に行ってガバナンスが強くなってくるほど、商用クラスタや、いわゆる商用セキュリティ製品を入れていきます。

多くの方々が、1つのKubernetesクラスタに開発も本番も運用もいろいろ入れて、だんだんしがらみが増えてきて悩んでいると思っていますが、そういった悩みを解決する、1つの解答にもなっていると思っています。

（次回に続く）