ヤフーにおけるKubernetesを活用したPlatform Engineeringの取り組み

こんにちは。システム統括本部 クラウドプラットフォーム本部の早川です。

私が所属する部署では、ヤフー社内のサービス開発者向けのプライベートクラウドを開発、運用しています。昨年の後半頃から「Platform Engineering」という言葉が聞かれるようになってきていますが、私たちは以前から、その理念に近い取り組みを行っています。

本記事では、「Platform Engineering」の概要と、私たちがKubernetesを活用して実現しているプラットフォーム開発、運用の取り組みについて詳しく紹介します。私たちの経験と知見が、これからプラットフォームの開発に取り組む皆様の一助になれば幸いです。

Platform Engineeringとは何か、なぜ必要なのか

Platform Engineeringは、Gartner Hype CycleのSoftware Engineeringカテゴリで2022年に初めて登場した概念で、IDP（Internal Developer Platform）と呼ばれる開発プラットフォームを自組織の開発者（注）向けに提供し、生産性と開発体験を高めようという試みです。

読者の皆さんの中には、開発タスクの共通部分を切り出して「共通プラットフォーム」や「汎用基盤」を構築する、と言ったような取り組みを耳にしたり、実際に参加したことがある方もいらっしゃるかもしれません。このような取り組みは、一定以上の規模の組織では以前から行われていたことですが、最近になって「Platform Engineering」という形であらためて注目されるようになりました。

では、「Platform Engineering」と、従来の「共通プラットフォーム」との違いは一体何でしょうか。

※注：本記事では、システムの開発者/運用者と言ったときの開発者、つまりアプリケーションの設計実装を中心に担当するエンジニアを指して「開発者」と表現します

Platform Engineeringは近年のサービス開発者が抱える課題を解決する

ITシステム開発のここ十数年ほどのトレンドを振り返ると、DevOps、マイクロサービスアーキテクチャ、継続的デリバリーといったパラダイムが登場し、現場に取り入れられてきているということが見えてきます。これらのパラダイムに共通しているのは、システムを素早く高頻度でアップデートし、エンドユーザーに迅速に価値を届けることを目指している点です。

これらの取り組みはさまざまな現場に採り入れられ効果を上げるようになりましたが、一方で開発者にとっては、責任範囲の拡大や習得すべきスキル/ツールの増加が課題になっていると言われています。

たとえばDevOpsを実践するとなると、開発者はアプリケーションの開発に加えて運用周りにも関わることになり、すべて運用チームにお任せというわけにはいかなくなります。また、マイクロサービスアーキテクチャを採用したシステムを開発、運用するには、多数のアプリケーションを管理ために追加のコストが発生しますし、アプリケーション群が複雑に関係しあって問題が発生すると、トラブルシュートの難易度も上がります。さらに継続的デリバリーを実践するとなると、デプロイメントパイプラインの作成と保守、リリースステージごとの環境の整備などが必要で、これのためにさまざまなツールに習熟する必要があります。

Platform Engineeringで提唱されているIDPは、近年の開発者が直面しているさまざまな障壁や手間を低減し、本来の開発に集中できるようにするものと位置づけられているわけです。

従来型「共通プラットフォーム」の一歩先へ

しかし、開発者の生産性を高めるというだけでは、従来の「共通プラットフォーム」と大きな違いはないように感じられるかもしれません。実際Platform Engineeringでは、開発者にとって本当に価値のあるIDPを作るためのポイントについて、もっと踏み込んだ言及がされています。

この記事でそのすべてを紹介するわけにはいきませんが、とくに私が重要だと考えている点として、以下の3点があります。

• IDPが高品質であること
• IDPが継続的に改善、成長すること
• IDPによって自組織のリアルな課題を解決できること

IDPが高品質であること

IDPが提供する機能は、アプリケーション開発者にとって便利で、使いやすいものでなくてはいけません。一言に「便利で使いやすい」と言っても、具体的にどういった水準を満たせばいいのかわかりにくいところですが、Platform Engineeringでは「利用者がやりたいことをセルフサービスで完結できること」という言い方でこれを表しています。

「セルフサービスで完結できる」を実現する方法をイメージしてみると、かなり本格的な取り組みが必要になることがわかるのではないでしょうか。適切なユーザーインターフェースを用意して、利用者がその誘導に従うことによってやりたいことを実現できるようにしたり、ドキュメントを整備しておいてそれを参照しながら作業を進められるようにする必要があるでしょう。もちろん、あらゆる利用ケースをセルフサービスにすることは現実的ではありませんので、サポート窓口を用意しておいて適切に利用者を誘導する、といったことも検討する必要があります。

IDPが継続的に改善、成長すること

IDPは作って終わりではなく、改良したり、不具合を直すといったことを継続的に続ける必要があります。

開発者がプラットフォームを利用し始めると、それは自分たちのシステムが依存する、なくてはならない存在になります。そんなプラットフォームのメンテナンスが行われないのでは不安を伴いますし、トラブルが発生したときに対処できない恐れも出てきます。

何より、わくわくするような新しい機能やアップデートが提供されることで、よりプラットフォームを利用するモチベーションを高めることにもなるでしょう。

IDPによって自組織のリアルな課題を解決できること

さらに、IDPは自組織に固有の課題を解決するものでなくてはなりません。汎用的すぎるプラットフォームは、自社向けのプラットフォームならではの価値を生み出せないからです（パブリッククラウドをそのまま使えばこと足りてしまう、と言ってもよいかもしれません）。

たとえば、プラットフォーム上に開発されたアプリケーションの管理権限を、社内の開発者が設定する場面を考えてみてください。仮に組織固有のポリシーがあって、それに準拠した権限を必ず設定する必要があるのならば、デフォルトでそれを設定しておけば開発の手間の解消になります。また、組織固有の要件を満たすことで、IDPとしての価値を作り出しているといえます。

上記は少し単純な例でしたが、実際には開発者の声をヒアリングするなどして組織固有の課題や要件を発見し、プラットフォームの機能で解決していくという取り組みが必要です。

以上のようなポイントをすべて満たすのは簡単なことではありませんが、ヤフーでは私の所属チームを含め、プラットフォームの開発や運用に携わるさまざまな部署がその実現を目指して努力しています。

Platform Engineeringの重要パーツとしてのKubernetes

ヤフーでは、さまざまなプラットフォームを開発者向けに提供していますが、それらの多くで、ベース技術としてKubernetesを採用しています。

プラットフォームのためのプラットフォームとして、Kubernetesは以下のような優れた特徴を持っています。

• コンテナオーケストレーターのデファクトであり、多様なワークロードを動かす基盤として成熟した機能を持っている
• CloudNativeと呼ばれる技術領域のさまざまなソフトウェアと組み合わせることで、機能を追加していける
• 使いやすい拡張ポイントが整備されており、カスタマイズ性が高い

とくに3番目のカスタマイズ性は、Platform Engineeringのポイントである「IDPにおいて自組織固有の課題を解決する」ということを実現する上で重要です。

Kubernetesの拡張機能のひとつ「カスタムコントローラー」

Kubernetesはさまざまなカスタマイズ方法がありますが、その中でも「カスタムコントローラー」はとくに出番が多い手法です。

カスタムコントローラーは、Kubernetesのマニフェストファイルの内容にしたがって所定の処理を行うコンポーネントです。実はPod、DeploymentといったKubernetesの標準機能もそのような仕組みで実現されているのですが、独自の処理を実装してKubernetesに追加して利用するものをカスタムコントローラーと呼びます。

たとえば、クラスタ上にNamespaceが作成されたときに、そのNamespace内のKubernetesオブジェクトに対するアクセス権を自動設定するということを考えてみます。このようなカスタマイズをするには、Namespaceの新規作成イベントを検知して、そのNamespace内にRBAC設定を作成するカスタムコントローラーを実装すればよいわけです。

この例では、権限の設定を行うRBACリソースをKubernetes内に作成していますが、カスタムコントローラーが行う処理はKubernetesクラスタの外のシステムに対して行っても問題ありません。後で紹介するヤフーのプラットフォームでは、Kubernetesに対するアクセス制御をクラスタ外の権限管理システムと連携して行う構成をとっており、Namespaceの作成時にその権限管理システム上の情報を更新するコントローラーを実装しています。

さらに、カスタムコントローラーに「CRD（Custom Resource Definition）」という機能を組み合わせると、より自由なカスタマイズか可能になります。CRDはPodやDeploymentといったKubernetes標準オブジェクトとは別に、独自に定義したフォーマットのオブジェクトをKubernetesで利用可能にする機能です。これによって任意のオブジェクトをKubernetesに作成し、さらにカスタムコントローラーによってそのオブジェクトの内容に従った任意の処理を行うことができます。つまり、Kubernetesに対する操作を通して実行されることを除けば、ほとんどどんなカスタマイズでも可能だということです。

Kubernetesとカスタムコントローラーの組み合わせは、自由度が非常に高いことがおわかりいただけたでしょうか。Platform EngineeringにおけるIDPでは自組織固有の課題を解決できることが重要と述べましたが、そういった要件を実現する上で、Kuberentesとカスタムコントローラーによる高いカスタマイズ性は、とても有用なのです。

ヤフーのKubernetesベースのPaaSのご紹介

それでは、ヤフーにおけるプラットフォーム開発の取り組みを紹介します。ヤフーには社内向けのプライベートクラウドを開発、運用するための専門の部署があり、多数のプラットフォームを開発者向けに提供していますが、ここでは、私が所属するチームで開発、運用しているWebアプリケーションの実行基盤をご紹介します。

このプラットフォームは、Webアプリケーションにおけるライフサイクル全般（ビルド、デプロイ、監視等）における作業を省力化するもので、一般的にはPaaS（Platform as a Service）というカテゴリに当たります。AWSにおけるAWS App Runner、Google CloudにおけるGoogle Cloud Runに相当するサービスと思っていただくとイメージしやすいかもしれません。

以降、本記事ではこのプラットフォームのことをPaaSと表記します。

ヤフーのPaaSのUX

ヤフーのPaaSのイメージをつかんでいただくために、このプラットフォームの利用を開始して簡単なWebアプリケーションをデプロイするまでの流れを紹介します。

1. GUIからNamespaceを作成する
2. コマンドラインツールをセットアップする
3. アプリケーションをデプロイする

1. GUIからNamespaceを作成する

PaaSの利用者はブラウザでGUIのコンソールにアクセスしてNamespaceを作成することができます。Namespaceはアプリケーションをデプロイするための論理的な区画で、Namespaceごとにアプリケーションを管理する権限を設定したり、アプリケーションが使用するCPU、メモリ量の管理が行われたりします。

2. コマンドラインツールをセットアップする

次に専用のCLIをインストールして、1.で作成したNamespaceにアクセスできるように設定します。弊チームが提供するドキュメントに従ってCLIをインストールし、ログイン等を行うコマンドを実行すると設定が完了します。

この時点ですでにアクセス権の自動設定が働いており、関係者以外はNamespaceにアクセスできない状態になっています。

3. アプリケーションをデプロイする

アプリケーションのマニフェストファイルを作成し、それをCLIでPaaS環境に反映することでアプリケーションをデプロイします。

マニフェストファイルはアプリケーションをデプロイするときの構成情報を記述するファイルです。必要最低限の設定であれば、10行〜20行程度で記述ができます。以下は簡単なサンプルアプリケーションを動作させるマニフェストの一例です（機密保持の観点から、部分的に実際とは異なる文字列を使用しています）。

apiVersion: paas.yahoo.co.jp/v1
kind: App
metadata:
  name: hello-world
  namespace: my-project
spec:
  service:
    autoscale:
      maxReplicas: 10
      minReplicas: 2
    template:
      spec:
        containers:
        - name: nginx
          image: registry.example.com/hello-world:latest
          ports:
          - containerPort: 8080

この例では、あらかじめ用意されたhello-worldという名前のコンテナをPaaS環境にデプロイしますが、開発者自身のアプリケーションをデプロイする場合はそれをコンテナとしてビルドしておく必要があります。 ヤフーのPaaSではコンテナをビルドするツールも内製しており、社内要件に沿ったコンテナを、Dockerfileを新たに作成することなくビルドすることが可能です。

次に、以下の様なコマンドを実行してPaaS環境にマニフェストファイルを適用すると、自分のNamespace内にアプリケーションが起動し、さらにそのアプリケーションにアクセスするためのURLが自動設定されます（CLIの名称は実際のものとは異なります）。

## アプリケーションの起動
$ paasctl apply -f hello-world.yaml

## アプリケーションのURLの確認
$ paasctl get app hello-world
NAME          ENDPOINT                                          READY  REASON  AGE
hello-world   https://hello-world.sandbox.app.paas.yahoo.co.jp  True           6m4s

アプリが起動してURLが払い出されたら、すぐにアプリケーションにアクセス可能です。

## アプリケーションへのアクセス
$ curl https://hello-world.sandbox.app.paas.yahoo.co.jp
Hello World!

いかがでしょうか。 PaaSを利用すると、とても簡単にアプリケーションをデプロイできることがイメージいただけたでしょうか。

PaaSにおけるKubernetesとカスタムコントローラーの活用法

以上の様なPaaSのUXは、Kubernetesをコンテナ実行基盤として採用し、さらにカスタムコントローラーによるカスタマイズを行うことで実現されています。

PaaSを構成するKubernetesは、外部の権限管理システムと連携してアクセス制御が行われるようになっています。開発者がGUIからNamespace作成を指示すると、Kubernetesクラスタ上にNamespaceが追加され、それを受けてカスタムコントローラーが権限管理システムを自動的に更新します。

以上の一連の自動処理によって、開発者はセルフサービスでPaaSを利用開始でき、さらにアクセス制御による安全性の確保も同時に行われているというわけです。

さらに、エンドポイントURLを自動的に設定する動作では、CRDも使用されています。先に紹介したAppのマニフェストファイルは、ヤフーのPaaSのために独自に定義したカスタムリースで、Kubernetes標準のマニフェストにはない設定を書くことができます。加えて、Appのマニフェストの内容を解釈して処理を行うカスタムコントローラーを実装することで、アプリケーションのURLを生成してDNSにレコードを登録する処理を自動的に行っています。これによって、アプリケーションをデプロイしたらすぐにアクセス可能になる、という使用感を実現しています。

※図では省略していますが、アプリのコンテナを起動したり、コンテナにルーティングするためのネットワークの設定等も行われています。

超大規模基盤への挑戦

ここまで紹介したようにヤフーのPaaSは、アプリケーションを簡単かつ安全にデプロイできるようにいろいろな仕組みを実装をしていますが、それ以外にも弊社固有のさまざまな課題の解決に取り組んでいます。その1つである、超大規模PaaS実現に向けた取り組みをご紹介します。

ヤフーのPaaSでは、開発者とプラットフォーム提供者、双方の運用コスト低減するため、1つのPaaSクラスタで多数のサービスをホストするマルチテナント構成を採用しています。しかし、ヤフーは国内有数といえる規模のサービスを多数抱えているため、単体のKubernetesクラスタでそれらをホストするのは、どうしても限界があります。

そこで、1つのPaaSというクラスタを複数のKubernetesクラスタで束ねて構成することにしています。これによって、Kubernetesクラスタを増やしていくことでKubernetesの規模を超えてスケールさせることができます。

具体的な仕組みはとしては、まず複数のKubernetesクラスタを束ねる役割のメタクラスタを1つ設け、アプリケーションのデプロイなどの操作はすべてメタクラスタで受け付けるようにします。そしてメタクラスタ上にカスタムコントローラーを配置しておき、Appのマニフェストの内容に応じて適切なKubernetesクラスタ上にアプリケーションを起動するようにします。

アプリケーションのデプロイなどの操作を受け付けるのはメタクラスタだけなので、開発者からは1つのクラスタのように見え、実際には裏側で多数のKubernetesクラスタが束になってアプリケーションをホストしているというわけです。このようにして、超大規模なサービスを効率よく運用するという、ヤフーに固有の要件を実現しようとしています。

終わりに

本記事では、近年注目されている「Platform Engineering」という考え方について解説するとともに、ヤフーでの事例についてご紹介しました。Kubernetesとカスタムコントローラーがプラットフォームの開発において重要な技術であり、弊社において本格的にこれに取り組んでいることが伝われば幸いです。

本記事はDevelopers Summit 2023で登壇した内容を元にしています。発表ではPlatform Engineeringやカスタムコントローラーについてより詳しく解説しておりますので、よろしければアーカイブ動画をご覧ください。

弊チームでは、2023年夏のインターンシップ生を募集しています。ここで紹介した取り組みに興味を持っていただいた学生の方は、ぜひ募集ページもご覧ください。

• インターンシップ募集ページ「KubernetesベースのPlatform Engineeringに挑戦」

※Kubernetes Logoは、Creative Commons Attribution 4.0 Internationalライセンス条件の下で、Linux Foundationにより、ライセンスされています。