
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
星野真知氏:「開発者と運用者の壁をぶち壊せ! InnerLoopとOuterLoopとは?」というところで、VMwareの星野から解説します。
(スライドを示して)さて、このCloud Operator Daysですが、(参加者は)インフラエンジニアの方々が非常に多いと思っています。
アプリとインフラエンジニアの関係は、昔と比べて非常に変わっていると思います。それこそクラウドがなかった10年前は、インフラエンジニア、アプリエンジニアという言葉が象徴するように、インフラのところに責任境界点を設けていました。
アプリの方々はシステムにおける機能要件に当たる部分を実装して、インフラの方々が例えばパフォーマンスであったり、可用性もしくはセキュリティ、特に昔はセキュリティといったらネットワークファイアウォールが中心だったので、そういった実装をするのが一般的だったと思っています。
ところが、時代はだいぶ変わってきてしまいました。(スライドを示して)すべてがすべてとは言いませんが、多くのお客さんはこうなってしまっていると思っています。
何が起きたのか。アプリの方々は、インフラの方々が設ける制約に、非常に苦労をし始めたわけです。どうにかより自由な空間はないものなのかと、インフラの方々に束縛を受けない世界、クラウドを求めてしまったわけです。
クラウドに行ったアプリの方々は、基本的にインフラの方々の制約を受けず、自由にアプリを作れるようになってきました。今、多くの現場で起きていることは、インフラの方々がいわゆる塩漬け環境、仮想マシンのガバナンスのみを見るようになってきてしまって、クラウドの開発においてはなにか制約などを設けることは基本的にできません。
それをやると、またアプリの方々に怒られてしまいます。そんなことが起きていることがすごく多いと思っています。
この関係がすごく悪いのかというと、そうじゃないと言う人もけっこう多いと思うのですが、1個大きな問題が出ています。
(スライドを示して)この絵は、Amazonさんが提供しているWordPressサーバーのベストプラクティス構成図です。アプリの方々、それからインフラの方々が設ける制約。それは何だったかというと、非機能要件におけるものが煩わしくてどんどんクラウドに行くわけですが、決して非機能要件から逃れるわけではありません。
これはAmazonさんが明確に言っています。彼らが提供するのはあくまでプリミティブ、原始的なもの、いわゆる絵にある一つひとつのオブジェクトまでであると言っています。そこからはユーザーたちが自由に作れると言っているのですが、それはつまり、クラウドに行く方々が自分で設計してやらなければいけないということです。
こういったところから、クラウドにおいても非機能要件が我々を阻み、その結果、アプリの方々が設計すると、どうしても環境がスケールしないという問題です。これは特にグローバルを先に、少しずつ日本などでも起きています。
(スライドを示して)我々VMwareはこれをどう考えているのかというと、やはりもともとあった、「アプリは機能要件、インフラは非機能要件」という関係に戻すべきだと思っています。
戻し方はどうするのかというと、インフラエンジニアをクラウドに連れていくことだと思っています。例えばコンテナのような技術を使って、ガバナンスが利かせやすいプラットフォームを作っていきます。非機能要件の責任を取っていきます。
アプリの方々は、走っているクラウドなどを意識せず、昨今多い非機能要件、特にセキュリティの責任をインフラの方々にオフロードしながら、どんどん開発に集中する環境を作っていくことが重要だと我々は思っています。
これを実現する上で、今コンテナを検討されている方がけっこう多いと思っています。(スライドを示して)この絵は、ハードウェアは抜いています。OSの下にハードウェアやファームウェアがあると思ってください。OSがあって、コンテナランタイム、いわゆるDockerやKubernetesがあって、その上にコンテナ、ベースイメージ、OSS(Open Source Software)、アプリという観点があります。
(スライドを示して)今までの我々インフラ・アプリエンジニアの感覚だと、アプリエンジニアとインフラエンジニアの責任境界点は、ここに引いちゃう方々が、けっこう多いと思っています。ここに引くと、例えばコンテナの中にもOSの要素が入っています。コンテナの中にも、アプリケーションとOSSのライブラリがあります。そこに脆弱性が出た場合、これは誰の責任なんでしょうね?
我々がいろいろお客さまと会話する中で、コンテナに行きたくないというお客さまの中には、この問題を指摘する方がけっこう出ています。
インフラエンジニアが本来責任を持つべきところに対して、責任が持てなくなってしまう。なので、コンテナをするのを躊躇しているお客さまがけっこう多いと思っています。
じゃあどこに線を引くべきだったのか、線をもうちょっと上に上げるべきだったのか、下に下げるべきだったのか。今我々は、その議論が間違っているとだんだん思い始めています。
(スライドを示して)こういった横線でアプリ・インフラエンジニアの責任を引くのではないやり方として今日紹介するのが、InnerLoopとOuterLoopという考え方です。
VMwareは、2022年1月に発表した「Tanzu Application Platform」という製品とともに、この考え方を出しています。
いわゆる開発者の方々が何が欲しいかというと、やはり自由です。そしてスピードです。InnerLoopと呼ばれているところは、基本的にガバナンスを利かせず、開発者に対してどんどんスピードを中心とした開発ができる環境を提供する。
InnerLoop。だんだん開発のイテレーションが早くなっていきます。ところが(その回転が)だんだん落ち着いてくると大きくなってきて、ゆっくりになってきて、例えばいよいよ本番環境にデプロイするとなった時。この大きくなった流れを、OuterLoopといっています。この大きな流れの時に初めて、インフラエンジニアの方々が非機能要件を入れていく、セキュリティなどを入れていく。
このように今後は新しくループをもとに責任境界を引いていくのが、いいのではないかというのが我々の考え方です。
イメージが湧かないと思う方に(向けて)、もう少し具体的なイメージをお見せします。
(スライドを示して)この絵は、一つひとつの箱が別のKubernetesクラスタだと思ってください。1個のクラスタではないです。なので今は4つあります。ネットワーク分断というところから、InnerLoopとOuterLoopに分けています。
開発者の立場になってみましょう。開発者の方々がまず何が欲しいかというと、一番左のノーガバナンスです。基本的には自由にデプロイできる、速さ優先、壊れても問題ないところにどんどんアプリを開発していきます。
この作業がある程度落ち着いてきてループが大きくなってきた時、ソースコードのコミットをしていきます。ここで重要になってくるのは、InnerLoopの門番の役割をしているビルドクラスタです。
このビルドクラスタは、受け取ったソースコードをもとに、標準コンテナを作ってくる、脆弱性検査を作ってくる、Kubernetesなのでデプロイ用のYAMLファイルを作っていく。こういったものを作ることやっていきます。
開発者はここで終わりです。彼らが認識するのは、あくまで自分の開発クラスタとビルドクラスタです。ネットワークが分断された、アクセスできない先にあるのが、いわゆるインフラの方々が守るOuterLoopの世界です。この世界では、InnerLoopから生まれたYAMLファイルやコンテナを受け取って自動的にデプロイします。
例えばデータがAmazonのRDSなどにある場合には、それと連携する仕組みであったり、もしくはセキュリティエージェントを入れたり、セキュリティを常にチェックする仕組みを入れていきます。ステージングクラスタ、プロダクションクラスタと分けていますが、基本的にやることは一緒です。こうすることによって、インフラの方々がセキュリティを強化する空間を作っていくことになってきます。
今までの「アプリとOSの間のどこに線を引こうという」考え方が、だいぶ変わっていて、Kubernetesはクラスタが非常に簡単に複製がしやすいものという特徴を利用して、このように新しい境界線を引いていく考え方がもとになっています。
そのため、例えば(スライドの)一番左の開発クラスタは、安価なノーサポートの非商用のKubernetesを使ってやってもいいし、右に行ってガバナンスが強くなってくるほど、商用クラスタや、いわゆる商用セキュリティ製品を入れていきます。
多くの方々が、1つのKubernetesクラスタに開発も本番も運用もいろいろ入れて、だんだんしがらみが増えてきて悩んでいると思っていますが、そういった悩みを解決する、1つの解答にもなっていると思っています。
(次回に続く)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10