クラウドネイティブ時代にOpsの役割はどう変わる？　これからのインフラエンジニアに求められるスキル

さくらインターネット田中氏のサーバ運用経験

新野淳一氏（以下、新野）：本日モデレーターをさせていただきますPublickeyの新野と申します。

今日はCloud Native Talk Night 第4回、本当はリアルでやる予定だったんですが、今日はオンラインで、アイティメディアの会議室からお送りしております。

私が司会で、田中さん、藤原さん、青山さんの3名と一緒に、だいたい60分ぐらいディスカッションをして、そのあとみなさんからの質問を受けて答えていこうと思います。

というわけで、さっそくパネリストを紹介していきたいと思います。僕の横にいらっしゃるのがさくらインターネットの田中さんです。よろしくお願いします。

田中邦裕氏（以下、田中）：よろしくお願いします。

新野：さくらインターネット社長の田中さんは知っている人がたくさんいると思うんですけど、今日のテーマは「運用」ということで、簡単に今のお仕事と、どんな運用を経験してきたのか教えていただけませんか？

田中：はい。では、あらためまして、田中と申します。さくらインターネットの代表をしています。

24年前にさくらインターネットを創業したんですけれども、最初はエンジニアでしたので、運用というと、ラッキングをして、サーバが落ちるとデータセンターに駆けつけるというオーソドックスな……。

新野：要するに、自分でラックを立てて、サーバを入れて、構築して運用していたと。

田中：そうです。運用して、電源も用意して、空調も用意してやっていました。

新野：お客さん向けのサービスもソフトウェアで用意しなきゃいけないわけじゃないですか。ご自分で用意されたということですか？

田中：全部そうですね。当時PCサーバは一般的じゃなかったので、自分でパソコンを買ってきて、組み立てて、セットアップして、テストして、OSをインストールして、ラッキングして、もうすべてのプロセスをやっていましたね。

新野：なるほど。それが24年前で、今は社長さんじゃないですか。いつまでご自身で運用されていらっしゃいました？

田中：実際の運用というのをどう定義するかですけど、データセンターでのラッキングは、10年前はもうほぼしていなかった感じですね。ただ、サーバが落ちるとメンテナンスをするみたいなことは5〜6年ぐらい前まではやっていました。

新野：ああ、そうですか（笑）。それは社長になってからもやっていたんですか？

田中：私は2000年に1回社長を辞めて、2007年からまた社長をやっていますけど、ずっとですね。

新野：ちなみに田中さん、運用は好きですか、嫌いですか？

田中：サーバが落ちるのをメンテナンスしにいくのは嫌でしたけど、コードの維持管理みたいなものは好きでしたね。

新野：またあとで詳しくお話をおうかがいしようと思います。

パブリッククラウドの事業装着

新野：その隣がリクルートテクノロジーズ、藤原さんです。よろしくお願いします。

藤原涼馬氏（以下、藤原）：よろしくお願いします。

新野：藤原さんも、今どんなお仕事をやっていらっしゃるのか教えていただけますか？

藤原：リクルートテクノロジーズというところで、主にAWSやGCPなど、パブリッククラウドを中心に事業の装着を進めています。KubernetesであったりAmazon ECSであったり、いろいろなパブリッククラウドのサービスを組み合わせつつ、運用の負荷を下げるにはどうしたらいいかとか、そもそも走り出しの構築を素早くやるにはどうしたらいいかといったことに日夜格闘している感じです。よろしくお願いします。

新野：まさに今、新しい運用の仕方を模索しつつ実行しているという感じですよね。

藤原：そうですね。先ほどの（田中氏の）お話を聞いていて思ったんですけど、考えてみたら、パソコン組み立てたことないなって。

新野：あらら。

田中：そうなんですね。

藤原：あとはプロダクションでサーバのラッキングもしたことがなくて。前職は研究員だったので、研究室のサーバルームでラッキングをしたりすることはあったんですけど、「プロダクション品質のサーバのラッキングとか配線って何なんだろう」といったことはノウハウとしてはまったく持っていません。

新野：ただ、クラウドネイティブって、技術的にもここ2〜3年のトレンドなわけじゃないですか。それ以前の運用は経験したことがあるんですか？

藤原：それ以前の運用という意味だと、リクルートテクノロジーズに転職した直後ですね。その時期に最初に配属されたのがオンプレミスのデータセンターの運用管理みたいなところで、主にVMwareスタック系のもので構築されたサーバやストレージの運用であったり、あとは実際にサービス側の要求ですね。例えばリクナビなどのサービスの要求に対して「こういうふうにやっていきましょうか」みたいなつなぎをやっていたり。

新野：なるほど。そのへんはまさに、今のメインストリームになっている運用ですよね。ありがとうございます。またあとで詳しくお話をおうかがいしたいと思います。

クラウドネイティブな運用にシフトする顧客が増えている

新野：では、私から一番遠いところにいるのが、IBMの青山さんです。よろしくお願いします。

青山真巳氏（以下、青山）：よろしくお願いします。

新野：IBMの青山さんも、今どんな仕事をしていらっしゃって、どんな運用に関わっていらっしゃったのか教えてください。

青山：私もだいぶ長くインフラのデータセンターにいましたので、サーバのラッキングなどはやっていました。

新野：あ、やっていた年代ですね。

青山：はい。ケーブルをいかにきれいにまとめるかが生きがいみたいな感じでやっていたぐらいから、本当にずっとインフラをやってきています。そのあと、流れで運用しながら設計することもあったんですけど、サーバの仮想化技術が出てきたらサーバの仮想化をやって、それがだんだんパブリッククラウドになって、今はクラウドネイティブで、お客様に提案したり設計を作ったりというところをやっています。

新野：ということは、どちらかというと、ご自身でもIBMで運用担当などの仕事をしてきた？

青山：お客様のアウトソーシングをお受けする部門にいたので、長らくやっていました。

新野：それを活かして、今は逆にお客さんにコンサルしたりもするわけですか？

青山：そうですね。今だとクラウドネイティブとかInfrastructure as Codeとか、どう使うといいかというようなことで、コンサル的なことをやらせていただいています。

新野：ちなみに、いま青山さんから見えている範囲で、お客さんの中で「うちはクラウドネイティブな運用をやりたいんだよね」というお客さんって、どれぐらいいます？

青山：「かなりたくさん」と申し上げたいですね。

新野：（かなりたくさんの会社が）興味を持っていらっしゃるということなんですか？

青山：そうですね。やはりお呼びいただくことも多くなっていますし、「ここのお客様は長らくデータセンターでオンプレでやっているからやらないかなぁ」と思うようなところでも、もうクラウドネイティブにいきたいというお客様はけっこうあります。

新野：それはある意味今日の本質的なところかもしれないんですけど、何を魅力に感じて「IBMさん、うちクラウドネイティブ入れたいんだけど」と言ってくるんですかね。

青山：そうですね、私たちがお話しするのは可搬性とか、あとは「DXを実現するためにはやはりクラウドネイティブの考え方じゃないと」ということをお話しして、そこに魅力を感じていただいているのかなと思います。

新野：ありがとうございます。

クラウドネイティブ時代の運用はこれまでとどう違うのか

新野：最後、私は司会の新野といいます。「Publickey」というブログをやっていて、けっこう積極的にクラウドネイティブ系の記事も書いていて、最近も、GoogleのCloud Runや、GitHubでCI/CDができるようになったとか、クラウドネイティブ系の記事を書いていたりします。このCloud Native Talkでは、第1回、第3回と今回の司会をさせていただいております。

というわけで、さっそく今日はどんなことをディスカッションしていくかというアジェンダをご紹介したいと思います。アジェンダは3つ用意しております。

1つ目は、みなさん今日のパネリストの共通項は、いわゆるトラディショナルな運用を経験した上で、今なんらかのかたちでクラウドネイティブな運用に関わっていらっしゃるので、そのあたりの違いから聞いていこうというのが1つ目のアジェンダで、クラウドネイティブ時代の運用はどう違うのかというお話をおうかがいしていきたいと思います。

おそらくなんらかの違いがあるだろうというお話になると思うので、その違いから、新しい運用担当にはどういうスキルが必要なんだろうというお話を、2つ目のアジェンダで聞いていこうと思います。

3つ目は、そういうスキルを持った運用担当をこれから育てるには、あるいは育ったとしてそういう人たちを活かす組織、あるいはクラウドネイティブ的な運用のためにどういう組織がいいのかというお話をいろいろなレイヤーでおうかがいしていきたいと思っています。

というわけで、さっそく1つ目のアジェンダです。田中さんからおうかがいしていきたいと思います。

田中さんは、さっきのお話ですと、トラディショナルな運用を経験した上で、今は社長という立場で、ある意味クラウドサービスを提供している事業者としても運用を見ていらっしゃると思うので、トラディショナルな運用とクラウドネイティブな運用はどのあたりが違うと思いますか？　レイヤーとして、インフラレイヤーが違う、ミドルウェアレイヤーが違う、アプリケーションのレイヤーが違うなどいろいろあると思うんですけど。

田中：基本的に、物理環境があるかないかというのは、極めて大きな差だなと思います。

新野：田中さんにとっての物理環境って何でしょう？

田中：2種類あって、まずはデータセンターみたいな、本当にラッキングしに行く、自分が物理的に動くという意味の物理と、もう1つは物理環境を触るということですね。

環境だけだったらリモートがあるので専用サーバとつながるわけなんですけれども、単に物理環境をリモートから使っているだけじゃなくて、やっぱり物理なんですね。ハードウェアが壊れるし、それを前提に冗長化をしようとかHA構成しようというのは、昔のやり方ですよね。運用といえば、それが片方壊れると「今度交換しましょう」というのが運用だったのが、今は変わったと。

新野：なるほど。例えば、昔だと「冗長構成とかは物理でなんとかしましょう」という時代だったのが、今は違うじゃないですか。ソフトウェアで組んで冗長性を高めようという。やはりそういう違いは感じますか？

田中：そうですね。基本的に粒度が細かくなっているかなという感覚は持っていて。昔はサーバが高かったですし、1台買ったら何百万円、月々借りても何万円ですよね。それを2つ借りて。その上に多機能だったわけです。

ただ、粒度がすごく細かくなっていって、粒度ごとにちゃんと維持ができるようにするという運用に変わってきました。例えば、フロントエンドのキャッシュみたいなものを複数に分けて、その後ろにはまた複数あって。

落ちたサーバがあったら、もう1回別のサーバを立ち上げ直すとか、そこにつなげ直すというのが今の運用ですよね。

新野：なるほど。今おっしゃったのは、マイクロサービス的なアプリケーションの運用だと粒度が変わってきて運用が変わってくるという理解でいいですか？

田中：そうです。そのため、アプリケーションレイヤーまである程度手を入れないと、当然マイクロサービスなんてできないわけですよね。いわゆる「疎結合か密結合か」という話もあると思うんですけれども、だんだん疎結合になって1つのパーツが小さくなっていくと、アーキテクチャが違うわけなので、違うインフラを使うために違うアプリケーションの作り方をしないといけない。そこまでを含めて運用だと言う方もおられますね。

インフラエンジニアもコードを書く必要が出てきた

新野：なるほど。またあとで詳しく聞きたいと思います。藤原さん、今の田中さんのお話だと、クラウドネイティブ的なアプリケーションって、マイクロサービス的に細かくサービスが分かれていて、それを支えるインフラがあって、それを運用するのはこれまでと違うというお話だったと思うんですけど、やはり違いますか？

藤原：大きい見方と細かい見方の2つの見方があると思っています。先ほどアプリケーションの話で粒度がどんどん細かくなっていったという話があったと思うんですけど、アプリケーションに関しては明らかに粒度が細かくなってしまった。マイクロサービス化されていくなかで、より細かい粒度でデプロイすることによってアジリティを上げていこうといった方向性がアプリケーションのレイヤーで見えてきました。

逆に、じゃあインフラレイヤーはどうなんだろうというと、少し混ざっている部分があって、Immutable Infrastructureの考え方でいくと、パブリッククラウドなどがどんどん出ていくなかで、既存の環境が動いているものがあって、「もう1セット同じものをドンと確保しましょう」という事柄が現実として可能になってきた。

新野：ブルーグリーンデプロイメントみたいな感じですね。

藤原：そうです。そんな感じで、「リソース的にそんなの無理じゃん」というような、例えば自分が新卒だった10年前だったら信じられないようなことができるようになったという。

新野：普通、「切り替えたいからもう一揃えサーバを買ってくれ」とは言えないですよね。

藤原：それが現実的にできるようになってきたというのが大きく変わった部分かなと思います。

新野：それによって、例えば運用の手法やノウハウも変わってきますよね。

藤原：運用の手法やノウハウという意味でいくと、やはりソフトウェア的な部分が割合としてすごく増えてきたので、インフラのエンジニアやオペレーションのエンジニアであっても、ある程度コードを書く必要が出てきました。

アプリケーションロジックのコードを書くというよりは、どちらかというとAnsibleやKubernetesなどの宣言型のコード、設定ファイルに近いものだと思ってもらうといいんですが、そっちのほうをインフラやオペレーションのエンジニアが書くことが増えてきたかなと思っています。

新野：パブリッククラウド・オンプレミス関わりなく、同じようにインフラエンジニア・運用エンジニアはコードをわかっていなければいけなくなってきているというイメージでいいですか？

藤原：オンプレとパブリッククラウドで程度の差はあると思いますが、それは間違いなくあると思います。

新野：実は私もそういう話を聞いたことがあって、パブリッククラウドの時代になったら、運用担当者がサーバを担がなくて済むようになったので、女性の運用担当者が増えてきたという。それはありますか？

田中：それでいうと、その逆の話があって、「データセンターの求人ってなぜ男性しかいないの？」って聞いたんですよ。それも、だいたい30代の男性を求めるわけなんですね。これってやっぱり悪しき習慣だなと思って。「いや、別に70〜80代の人でも働けたらいいんじゃないの？」という話をした時に、「重いものを担げません」「いや、それは女性もそうでしょ」みたいな話になって、いまだに男性が物を担ぐことを前提にしているきらいがあるんですよね。だって、「リフトがあればそれでいいんじゃん」って。

それで、実際にリフトを置きました。けっこう高いんですけれども、人件費に比べたらこんなん、何年も使えば元を取れるんじゃないかという話になるんですけれども、どうしても人で作業するという前提がいまだにあるんだろうなと思います。

新野：そういう部分が隠蔽されてコードに置き換わってくる、自動化されてくるというのは、クラウドネイティブの運用の大きな違いと言えそうですよね。

監視の仕方などの運用にも変化が

新野：青山さんにも同じ質問をしたいと思いますが、クラウドネイティブになってトラディショナルな運用とどう変わってきたと思いますか？

青山：いま藤原さんからあったように、インフラエンジニアもコードを書けなければいけないというふうになってきているんですけど、かつ、コードでImmutable InfrastructureやInfrastructure as Codeという考え方で運用していくと、監視の仕方も変わってきています。

かつ、監視した結果に対してどういうアクションをするかというところも、私たちがデータセンターにいた頃は、現地に駆けつけてログインして悪いところを探してPDして直すというところまでをやっていたんです。PDするところはリモートからかもしれないですが。でもいまは、そのあとに「直す」のではなくて、Immutable Infrastructureの考え方だと「作り直す」に変わるじゃないですか。だから、監視の仕方が違うし、その結果に対するアクションも変わってきているなとすごく感じています。

新野：なるほど。それは例えば、昔だと「なんかアプリケーションが遅くなった」というときに、遅くなったのはネットワークが混んでいるのか、データベースが急に遅くなったのか、なにかストレージが片肺になっているのかを調べて修理しに行かなければいけなかったのが、変わってきたということですよね。

青山：原因はもちろん突き止めなければいけないと思うんですけど、突き止めたら正しい状態に戻って作り直すという世界に変わってきているのかなと。

新野：藤原さんはたぶんそういう世界を経験してきたと思うんですけど、やっぱりそこは違いますか？

藤原：そこは違うと思いますね。以前は、サーバが壊れたからといってすぐに予備が用意できるわけでもないので、原因を追究した上で、直せるなら直すし、直せないなら予備機が来るまで待ったと思うんですが、今はひとまず復旧が優先されるということが比率としてはすごく上がったなと感じます。

それとは別に、「別途、原因の追究はよそでやりましょう」となることがすごく増えてきたなとは感じますね。

新野：インフラ、ミドルウェアから下のレイヤーの管理がコードになってくると、今までは大きな組織だとストレージ専門の運用、データベースを運用してくれる人、ネットワークを運用構築してくれる人、と分かれていたわけじゃないですか。でも、コードで全部それが書けるようになると、分ける必要がなくなってきますよね。青山さん、どうですか？

青山：私はずっとインフラをやってきている中で、アプリケーションのところはある程度はわかっていなければいけないけど、前はそこまでわかってなくてもよかったんです。でも、インフラの人もコードを書くようになって、こういう世界で運用していくと、アプリケーションがどう動くのかというところも理解してコードを書かなければいけない。そこが少し変わってきているのかなと思います。

よく言う「アプリとインフラの境界が曖昧になっている」ということもそうですけど、インフラエンジニアもアプリをより理解して運用していかなければいけなくなったという世界に変わってきているかなと感じます。

新野：その話はたしかによく聞きますね。「アプリケーションがこうだからアプリケーションに合わせたインフラを用意する」というのが、クラウドネイティブの時代だとより密接に行われるような。

青山：そうですね。

新野：田中さんは、打ち合わせのときにそういう話をしていらっしゃいましたよね。

田中：そうですね。あと重要なのは「インフラって何なのか？」ということがやっぱりあります。さくらのある部門では土地だったりするわけですし、ある部門だと本当にクラウドリソースだったりするわけなんですけれども、いずれにせよ境界面が非連続になっているところがあるので。

新野：境界面が非連続というのはどういうことですか？

田中：インフラって依存関係がすごく多いので、例えばクラウド自体をインフラだと捉える人もいれば、その上に例えばコンテナ環境とかを作っていて、そのコンテナ環境自体がインフラだと思っている人にとってみれば……。

新野：Kubernetesのマネージドサービスとか、そういうやつですね。

田中：そうですね。Kubernetesのクラスタを作ったりして、それを自社で運用されている会社も多いわけですよね。

ということは、そこを運用している人はインフラを使っているけどインフラの運用者ではないし、その人が実はその上でコンテナを使っている人と一緒だったりするかもしれないし、誰が運用して誰がそれを使っているのかが曖昧になっている部分なのかなと思いますね。

DevとOpsのより密接な関係

新野：アプリと運用の人が密接に連携しなければいけないということで、青山さんにおうかがいしたいんですけど、いわゆる「DevOps」という言葉があるじゃないですか。お客さんと接するときにはやはりそういうことを意識してお話ししたりするようになるものですか？

青山：少なくとも以前よりは意識していますね。やはりOpsがあるからDevがある、両方が本当に密接に関わっているのがクラウドネイティブの世界だと思うので、「アプリをこう動かすから運用管理はこうしていかなければいけない」ということや、アプリのリリースのタイミングや仕方などをインフラの運用管理側で考えることが必要になってくるので、かなり意識してお話ししているような気がします。

新野：藤原さん、いかがですか？　まさにそれをやらなければいけない現場のような気がしますが。

藤原：そうですね、DevとOpsというふうに考えたときに、やはり最後は規模とかそういったものに依存するかなと思っています。私の場合はリクルートが提供する新規系のサービスを担当することが多いんですが、それでパブリッククラウドを使うことが多いんです。

そうなってきたときに、やはりDevの人と1〜2人ぐらいOpsの人が入って一緒に開発していくことが多いんですけど、そのなかでOpsの人とDevの人のコミュニケーションはどうやってとったらいいかというところ。

自分自身はオンプレも少しやったし今パブリッククラウドをやっていますが、アプリケーションの作り方もオンプレミスでやる場合とパブリッククラウドでやる場合でぜんぜん構造も違ってきているし、インフラのそれぞれのレイヤー間の結合度合いも違うので、やはりオペレーションの人たちの動き方がガラッと変わるなというのは実感として感じています。

新野：なるほど。そうすると、DevとOpsがコミュニケーションを密接にやることが求められるとして、どんなコミュニケーションをとっているんですか？

開発とOpsのコミュニケーションって、「落ちたからなんとかしてくれ」「いや、お前のコードが悪いんだろう」みたいなのを想像しがちじゃないですか。でも、そうじゃないんですよね？

藤原：そうじゃないです。ちょっと変わってきているのは、私の場合なので一般的かどうかはわからないんですけど、「こういうビジネス要件があります。アプリケーションとしてこんな機能を実現したいです」となったときに、Devの人に全部お願いするのではなくて、「パブリッククラウドで構築するのであればこういうアーキテクチャはどうですか？」というかたちで、運用管理性やデプロイ容易性を考えた上でOps側から提案することのほうが多いです。

新野：やはりOpsの人はそこまで踏み込んでアプリケーションと関わっていくということですよね。

藤原：あと、オンプレからなぜそう変わっていったかという部分で思うのが、オンプレミスってある程度縛られる部分があるじゃないですか。ハードウェアだったり、その上の仮想化レイヤーだったり。

そこがパブリッククラウドだったら、ある程度自由に組める部分があって、いわゆる局所最適化みたいなことがすごくやりやすくなっているから、Ops側から「こういう構成どうですか？」という攻めの提案ができるようになってきたのはあるかなと思います。

新野：そういう提案ができるのはOpsの中でもすごく優秀なイメージがあるので、そういうOpsに求められるスキルという、2つ目のアジェンダにいきたいと思います。