コンテナを導入しないと、どのような未来が待っていたのか?【前編】

はじめに

約1年前、私は東京駅前の喫茶店に呼び出された。私を誘ったのは、以前はストレージやクラウド、IoT、AIなど幅広く手掛ける大手電機メーカーの米国のラボ長を務め、現在は帰国してヤフー株式会社の子会社であるゼットラボ株式会社に勤務する坂下幸徳氏だ。

軽く挨拶を交わし席に座ると、坂下氏はいきなり「これからはコンテナとKubernetesだよね」と切り出してきた。「コンテナって、以前DC事業者とかで流行っていたやつですか?」と私。

坂下氏は満足げに「そう、それ」。と頷くと、続けて「Kubernetesがスタンダードになって、これから変わると思わない?」と。

「なんですか? Kubernetesって」。そんな私に1時間半、坂下氏によるコンテナとKubernetesの講義が始まった。正直、半分以上何を言っているのか理解できなかった。

私に言えたのは、「とりあえず、分かりました。そんなにすごいテクノロジーなら、レポートを作ってみますよ」ということだけ。そう言って、別れたのである。

そこから、コンテナ、Kubernetesの勉強を始め、実際にレポートを作成するに至ったのだ。

今回は、そんなきっかけをくれた坂下氏に、対談形式で色々なことを聞いた。モノすごく面白い内容になっているので、ぜひ多くの人に読んでもらいたいと思う。

あまりにも内容が濃いため、前編、後編の2回に分けてお届けする。

※以降では、ヤフー株式会社をヤフー、ゼットラボ株式会社をZ Labと略す。

コンテナのない未来とは

―なぜコンテナを導入しないといけなかったのでしょうか?

• 坂下：いくつかありますが、そのなかで観点の違う要因を2つ紹介しましょう。

  1つ目は、スケールの容易さです。サービスの需要によって求められるスケールが変わるインフラにおいて、増えても減っても対応できる柔軟性が必要でした。「インフラにいかに多くのサービスを詰め込めるのか」も考慮するポイントの1つです。

  2つ目は、エンジニアのモチベーションです。エンジニアは、新しい技術が大好きです。新しい技術を提供し続け、常に新しいモノに触っていく。テクノロジーリフレッシュを繰り返し行っていくことで、エンジニアのモチベーションが向上します。

ゼットラボ株式会社/ヤフー株式会社/SNIA日本支部 技術委員会副委員長 坂下幸徳氏

―逆説的に、もし仮にコンテナを導入していなかったら、どのような未来が待っているのでしょうか。

• 坂下：まず、増大するシステムにインフラの管理者が耐えられなくなっていたと思います。VMでもある程度、管理業務を改善はできますが、コンテナならもっと楽にできます。ただし、VMをコンテナに置き換えただけではダメです。DevOpsを理解し、運用管理方法も育てていく必要があります。

  弊社では、GitHub上にKubernetesでアプリケーションをデプロイする際に利用するManifestファイルを展開し、バージョン管理や履歴管理による属人化からの脱却、CI/CDによる自動化など、運用の仕組み・やり方を変えていきました。そのため、GitHubのような以前は開発側(Dev側)が利用していたツールを運用管理側(Ops側)でも利用しています。

  いくらシステムが大規模になって数が増えようとも、その数に負けない運用管理のやり方を変えていかなければなりません。

  例えば、新しいサービスを開始する時に「インフラが間に合わないからすぐにスタートできない」というのは、ビジネス機会の喪失に繋がってしまいます。そうならないような新しいインフラ、運用管理方法、体制を確立させておく必要があります。

  VMでも頑張ればできるでしょうが、コンテナの方が新しく変えようと試みるベンダー・プロジェクトによるエコシステムの成長は早いと感じています。エコシステムが成長すると利用できるソフトウェアや事例が増えるため、新しい運用管理方法を試すのにハードルが下がります。

  ※Manifestファイル：Kubernetesにアプリケーションなどをデプロイする際に利用する設定ファイル(新しくサービスを作る時にどのようなリソース構成なのかが書かれている)

コンテナ導入における苦労

―コンテナの導入にあたって、苦労したことはなんでしょうか? 技術面や人、組織の問題などいろいろな壁があると思うのですが。

• 坂下：これもいくつかありますが、ひとつに教育の部分は苦労している面があります。これは現在も続いている課題です。

  Kubernetesを使いこなすのは正直簡単ではありません。これまでのシステム運用はサーバ、ネットワーク、ストレージのレイヤーがバラバラで、それぞれのレイヤーに特化した管理者が個別に管理してきました。しかし、Kubernetesなどにより抽象化のレベルが上がったことで、ある程度、全体を理解し把握しないと管理できなくなりました。

  振り返ると、VMが登場した時も同じでした。より簡単にサーバ・ネットワーク・ストレージが利用できるようになると、管理者は自分の専門外のレイヤーの「モノ」を知る必要が出てきます。また、違う視点だと「モノ」に対する知識だけでなく「こと」への理解も必要になります。ManifestファイルをGitHubで管理し、CI/CDでテストやデプロイを自動化するGitOpsなど新しい運用スタイルについて考え方を理解し、自分の組織に合う運用管理の方法に作り変えていくことが重要です。弊社でも、今現在もまだまだ新しい運用方法に挑戦し続けています。

  ひと言で「運用管理方法を変える」というのは言うのは簡単ですが、日本だとなかなか難しい組織も多いかと思います。それを紐解くには、日本と海外(主に北米)の違いについても触れておく必要があるでしょう。

  大きな違いは「SIerがいるかどうか」です。海外にはほとんどSIerがいない状況です。つまり、企業自身でシステムの責任を全て持たなくてはいけないということになります。そのため、「自分たちの仕事をもっと楽にしていきたい」というモチベーションがあり、それによって新しいテクノロジーを積極的に採用していこうとするのです。

  一方、日本にはSIerが多く存在します。つまり、「インフラ構築から障害などの問題究明に関してはSIerに任せてしまえば良い」という思想が生まれます。IT部門の主な仕事は、サービスデスクのようなユーザーからのリクエストや窓口業務などが中心となってしまい、インフラに関してはSIerに任せるという構図になります。その結果「インフラを積極的に新しく変えよう」という意識が生まれなくなるのです。

  SIer目線で見ると「自分たちの製品・サービスなど『モノ』を導入してもらいたい」というSIerが多いのも現実です。簡単に言うとユーザー企業に「モノ」を売ろうとする。「モノ」中心の運用管理の方法を押し付けます。「ユーザー企業のIT部門の作業を楽にするためのインフラ」という視点が抜けてしまっているのです。

  昔のように「新しいインフラ(ハードウェアやソフトウェア)を導入したら運用が変わる」と本気で思っているSIerが多くいるのが残念です。確かに一部HWの高速化によって処理速度が上がり業務に良い影響を及ぼすということはありますが、それは極々限られた一部のシーンです。IT部門に歩み寄り、新しい「こと」を作り上げることでインフラ管理者の作業を減らしつつ楽しみを増やすことを任せられるSIerが日本では少ないです。

  海外では、コンサル企業が「こと」の提案をうまく行い、ビジネスとして立ち回っています。一方、日本ではSIerがコンサル企業の役割を期待されながらも、「モノ」中心になっているのではないでしょうか。

―ヤフー、Z Labはそのような環境の中で、どう変えていったのですか?

• 坂下：手前味噌なところもありますが、ヤフーにとって、Z Labという子会社の存在は大きいと思っています。ヤフーは様々なサービスを提供する比較的大きな企業体になっています。大企業の常ですが、大きくなるにつれ「先進的なことをする」という発想が鈍化します。そこをZ Labという組織が外から「もっと積極的にやろう!」と声をかけながら、どんどん新しいインフラの考え方を提案していくことができるのは大きいと感じます。

  一般的にインフラの運用チームは、目の前の日々の運用をこなすだけでいっぱいいっぱいなのです。それを分かっていながらも「変えろ」「変えろ」と外から言い続ける。言うだけでなく、やってみせる。Z Labのカスタマーであるヤフーの実現したいことをコンサルのように新しい方法を考えて、提案していく。二人三脚で組織して活動している形を取っています。

  これができるのは、Z Labが100%ヤフーの子会社で、社員は全員ヤフーから出向し、ビジネスは現時点ではヤフーのみだからです。つまり、Z LabはヤフーのためのR&Dカンパニーであり、子会社の形態をとっているためフットワーク軽く小回りが利き、常に新しい技術に向き合い、ヤフーの課題を解決する組織となっているのです。

  海外の企業(特に大企業)では、弊社のように社内向けにコンサルを行うような子会社を作り、ある程度の大きな権限を与えて対応している企業も数多くあります。

―そのような組織体制を、よく思いつきましたね。誰が考え出したのですか?

• 坂下：それは分かりません。私が転職した時には既に組織があったわけですから。ただ、重要なのは組織を作るだけでなく、トップがその組織、チームにどういう権限を与えるのかによるのかなと思っています。あとは、モチベーションの与え方。

  例えば「働き方改革」といった時に、すぐに残業時間を減らそうとなりがちですが、本来は仕事のプロセスを変えて効率良く働くことだと思います。ここは、KPIなど評価しにくい部分なんです。下手にKPIを作ると失敗します。

  「残業時間を減らす＝働き方改革」と本気で思っている組織のトップがいたと仮定して、KPIで残業時間の削減を定めると、単に仕事時間を減らすことだけを行ってしまい、ただただ従業員に負担とプレッシャーがかかり、良い未来はありません。KPIを中心に考えるとそうなりがちです。重要なのは、辿り着きたい未来の働き方から逆算して「何を改善すれば良いのか」を考え、実践することです。

  これをシステムに置き換え考えると、新しいインフラに刷新しようとする場合、組織のトップがトップダウンで画一的に「Kubernetesを使いなさい」と言うのは違うと思います。本来変えなくてもいいモノを変えてしまう必要はないのです。重要なのは、エンジニア自身が本来作りたいインフラや運用管理方法の将来像と、それに近づけるためにコンテナやKubernetesを使うかどうかを考え、選ぶということです。その見極めには、バランス感覚を持って提案・実践していく必要があります。

  インフラの刷新などは相当な痛手(お金も労力も)が伴います。ただ、それを乗り越えればエンジニアにとって、わくわくする未来が待っていると思えるかどうかが成功の鍵ではないでしょうか。組織のトップは、これを実現するために権限やモチベーションをどう与えるかが重要でしょうね。

【後編】へ続く

＊　＊　＊

今回は、日米の違いやSIer、エンジニアの気持ちまで、様々な観点から坂下氏に指摘をいただいた。後編となる次回は、さらにステートフルへの挑戦やフレームワークとしてKubernetesを考えるという視点、エンジニアのワクワクが重要だという話を紹介したい。