マネージド Kubernetes に切り替える 6 つの理由

マネージド Kubernetes サービスは、多くの企業がクラスターのキーを渡すほどに成熟しています。ここでは、この傾向の背後にある主な推進要因のいくつかを特定します。

Kubernetes クラスターをマネージド プロバイダーに引き渡すことは、子供を大学に送り出すような気分になります。最初は怖いかもしれませんが、最終的には家事の負担が大幅に減ります。

[[438099]]

3 大パブリック クラウド プロバイダーである Amazon Web Services (AWS)、Google Cloud、Microsoft Azure が提供するマネージド Kubernetes オプション、つまり Kubernetes as a Service (KaaS) は、ここ数年で大きく進歩し、顧客が YAML 構成ファイルの詳細を理解したり、自動スケーリング、更新、クラスター管理について心配したりすることなく、コンテナー化されたワークロードを実行およびオーケストレーションできるようになりました。

「企業が戦略的に重要なことを考える際、最初はそれを自社で運用しようという傾向がある。しかし、時間が経つにつれて、企業がその環境に慣れてくると、それでは競争上の優位性が得られないだけでなく、ベンダーの方が自社よりもうまく運用する可能性が高いことに気づく」と、開発者向けアナリスト会社レッド・モンクの共同設立者、スティーブン・オグレイディ氏は語る。 「すべての企業がこの道を進むのでしょうか？まだそうではありませんが、意欲と進むべき方向は明らかです」と彼は付け加えた。

マネージド Kubernetes サービスを検討すべき 6 つの理由をご紹介します。

管理オーバーヘッドを削減

まずは明白な理由から始めましょう。 「はっきり言って仕事量は減っている」と旅行技術会社アマデウスの技術プラットフォームおよびエンジニアリング担当上級副社長、シルヴァン・ロイ氏は言う。 「Kubernetes は私たちのために運営されています。これは重要なことです。なぜなら、[Kubernetes] を運営するために必要な人材をすべて揃えるという課題があるからです。」

同様に、建設会社 Strabag のエンジニアの小グループは 2006 年からコンテナを独自に運用しており、過去 4 年間で自己管理型のオープンソース Docker および Kubernetes セットアップに移行しました。現在、同グループは、既存のアプリケーションを最新化して基盤となる Kubernetes クラスタの管理を Google Cloud に引き渡すか、特にオンプレミスのデータを転送する必要がある場合に、開発者がクラウド内または Anthos サービスを使用したハイブリッド設定で新しいアプリケーションを実行できるようにすることで、クラスタ管理を可能な限り自動化することを目指しています。

「この旅は、引き継ぎに適したタスクを引き継ぐことです」と、Strabag のクラウド サービス チームの責任者である Mario Kleinasser 氏は述べています。

同様に、金融データ大手のブルームバーグでは、「SRE（ソフトウェア信頼性エンジニアリング）チームやKubernetesのリリースサイクルを管理するチームがない場合、アプリケーションの実行に注力しKubernetesの管理を望まない企業にとってはベンダーを活用するのが合理的です」と、ブルームバーグのコンピューティングインフラストラクチャ責任者であるアンドレイ・リブカ氏は述べている。

現在、ブルームバーグは Kubernetes ワークロードのほとんどをオンプレミスで実行していますが、必要に応じて 3 大クラウド ベンダーすべてを使用してワークロードを管理し始めています。

専門家の数は減ります

Kubernetes 管理スキルは、特に独自の YAML 構成ファイルを作成する場合は、習得が難しく、費用もかかります。 Kubernetes クラスターを手動で調整できる人材がいる場合は、クラスター管理をより日常的なワークロードにオフロードすることで、その人材を解放して社内プラットフォームや特に重要なワークロード、または扱いにくいワークロードの管理に専念させることができます。

「こうした技術に人材を引き付け、確保するのは容易なことではなく、明らかに課題だ」とアマデウスのロイ氏は語った。

信頼性の向上

つまり、大規模なクラウド ベンダーは、エンジニアリング チームの規模、顧客展開の幅広さ、それらの展開の基盤となるテレメトリへのアクセスにより、Kubernetes クラスターを管理するのに、多くの場合、お客様自身よりも有利な立場にあります。

「ベンダーの方がうまく運用できる可能性が高い」とレッドモンクのオグレイディ氏は言う。 「ベンダーはテレメトリの利点があり、すべての顧客がそれを実行しているのを確認できます。一方、単一の企業が独自のモデルのみで作業するのとは異なります。」

たとえば Bloomberg は、2015 年のアルファ版だった頃に Kubernetes に移行し、必要な継続的インテグレーション、監視、テストが実証された後、2017 年に本番環境に移行しました。ブルームバーグのエンジニアは、オンプレミスのアプリケーション用のKubernetesクラスターを主にまだ自ら管理していますが、ワークロードがパブリッククラウドで実行されている場合は特に「信頼性の観点から」、マネージドオプションを使用することがますます理にかなっているとRybka氏は述べています。

アップグレードやパッチの心配は不要

アップグレードとパッチ適用は、Kubernetes を管理する人にとって最もやりたくない作業の 2 つです。そのため、ホスティング プロバイダーは、これらのタスクをユーザーの負担から取り除くことを優先しています。

「Kubernetes のパッチ適用、更新、管理を自分で行うのは、複雑で煩雑で、まったく差別化につながらない重労働です」と、AWS のコンピューティング サービス担当副社長 Deepak Singh 氏は述べています。

クラウドの勢いを維持する

パブリック クラウド ファースト戦略を推進している組織にとって、マネージド サービスをさらに導入することは、推進力を高めるのに役立ちます。

Amadeus は最近、まさにそれを実現するために Microsoft と契約を結びました。 「彼らは素早く動いており、私たちはその恩恵を受けたいので、毎回より多くのマネージド サービスを使用することを検討しています」とロイ氏は語った。 「それがこの勢いから利益を得る方法だと私は思います。」

現在、ベンダーは Kubernetes のベスト プラクティスに関する知識と経験を、GKE Autopilot のような簡素化されたパスを採用して、より独自のバージョンの Kubernetes サービスに変換しています。

「オートパイロットを補助輪と考える人もいるだろうが、私はシートベルトだと考えている」とグーグルの主席エンジニア、ケルシー・ハイタワー氏は語った。 「車は同じ速度で走れますが、デフォルトでより安全です。これは万全の構成です。人々は常にベストプラクティスと、どのような決定を下すべきかを尋ねてきますが、オートパイロットはそれを提供します。」

同様に、AWS のシン氏は、同社は Kubernetes を大規模に実行することから学んだことを活用し、その「運用体制を EKS に構築する」ことに長けていると述べた。「これにより、サービス プロバイダーとして、これらのマネージド サービスにすぐに組み込むことができるようになります。」これが、この傾向が加速するもう一つの理由です。 ”

しかし、このようなサービスでは当然ながらベンダーロックインの懸念が生じます。 「オートパイロットはより困難です。ベンダー間で切り替える人がいないのに、なぜミドルウェア レイヤーとして Kubernetes に注目するのかと誰かが私に質問したことを覚えているからです。その答えは、やめることができるという選択肢でした」と RedMonk の O’Grady 氏は語ります。 「ベンダー固有のオプションに頼れば頼るほど、[離脱の可能性]がなくなるため、企業にとって選択が難しくなります。」

オープンソースであり、移植性がある

ホスティング プロバイダーは、移植性を高めてロックインを回避するために、使用する Kubernetes ディストリビューションが一般的なオープン ソース バージョンに可能な限り近いことを保証したいと考えているオープン ソース コミュニティと顧客の信頼を獲得する必要があります。

「Kubernetes が登場したとき、人々はそれがおとり商法であり、オープン コミュニティからのベンダーの土地強奪であり、オープン コアへと進化するのではないかと懸念していました。それが証明されるまでに 5 ～ 6 年かかりました」と Google のハイタワー氏は語ります。

同様に、AWS のシン氏は、EKS が Kubernetes のオープンソース ディストリビューションと密接に連携し、「違いを生むような奇妙な魔法が存在しない」ことが一部の顧客にとって重要だと述べた。 AWS は最近、これを実証する方法として、GitHub で EKS ディストリビューションをオープンソース化しました。

Kubernetes の共同創設者であり、VMware Tanzu のチーフエンジニアである Joe Beda 氏は、「ロックインについて話さずにこの会話をするのは難しい」と認めています。彼は、こうした購入の決定をする人は誰でもリスクを適切に評価するよう促した。

「移転する可能性はどのくらいありますか？ 移転する場合、そのコストはいくらですか？ どの程度のコード書き換えが必要で、どの程度の再トレーニングが必要ですか？ こうした投資を行う人は、要件、リスク、トレードオフを理解する必要があります」とベダー氏は述べた。

一方、CNCF は、認定ベンダーに関係なく、あるインストールから次のインストールへの相互運用性を保証する、認定された Kubernetes 適合プログラムを実行します。

では、なぜ誰もがこれをやらないのでしょうか?

Amadeus や Bloomberg のような大規模で複雑な組織では、機密データのセキュリティ問題、扱いにくいローカル依存関係、独自のクラスターを手動で調整したい過度に保護的なプラットフォーム チームなど、マネージド サービス プロバイダーに引き渡すことに不安を感じるワークロードが常に存在する可能性があります。

「パーツを自分で管理したい人は、データプレーンを心配している。彼らは、特定の領域でのカスタマイズや専門化を必要としている。彼らは、管理されたコントロールプレーンを気にしていない」と、Google のハイタワー氏は語った。

しかし現実には、Kubernetes を自分で運用する理由はますます説得力を失いつつあります。

「おそらく、誰も埋没費用として帳消しにしたくない既存の投資とみなしているか、あるいは、ある一連のワークロードやビジネスに関して保守的な組織上の懸念があるのでしょう」と、RedMonk の O'Grady 氏は言う。 「あるいは、インフラの一部が戦略的なものとみなされ、自分の管理下から外れてしまうのではないかという不安もあります。しかし、同僚がそれを実行しているのを見ると、その不安は消え、より多くの人がそのメリットに気づくようになります。」