大量にあるKubernetesをどのように運用するか　ヤフーの運用自動化の仕組み

監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み

相良幸範氏（以下、相良）：「監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み」という題で、ヤフーの勝田と相良が発表いたします。

このセッションでは、ヤフーのKubernetesを紹介し、Kubernetesクラスタの監視・運用について基礎を振り返ります。その後、ヤフーにおいて大量のクラスタをどう効率的に運用して安定稼働を実現しているか紹介します。

内容は、このようになっています。

私は左側の相良です。SIerで10年近くR&Dの部署や全社の技術集約部署でプライベートクラウド基盤ソフトの開発をしていました。OpenStackを使ったキャリア向けの大規模プライベートクラウドの設計などもやっていました。去年（2019年）ヤフーに移って、今はヤフーのKubernetesのSREやCREをやっています。

勝田さん、お願いします。

勝田広樹氏（以下、勝田）：同じくヤフーの勝田と申します。今回紹介いたします「Kubernetes as a Service」の初期からのメンバーで、もう気づけばヤフー8年目となりました。Kubernetesは3年目で、いくつか社外講演をしたり、CKA・CKADも取得しています。

趣味が旅行とカラオケと書いたのですが、昨今の状況からどちらも封じられてしまっていますので、リモートカラオケをやってくれる方がいたらぜひご連絡ください。

Zoom発表、初めてで緊張していますが、よろしくお願いいたします。後半でお話しいたします。

ヤフーのKubernetes

相良：では、中身に移りたいと思います。大量クラスタ監視ということで、まずはヤフーでどのくらいKubernetesを運用しているのかという話からしたいと思います。

ヤフーは2017年の夏にKubernetesを本番運用で使い始めて、それから徐々にクラスタ数が増えていっています。2018年から2019年でグッと300台強は増えていて、またその次、2019年から今年5月で、少し若干前ですけど、こちらもほぼ1年……1年から2ヶ月少ないですが、今年も同じぐらいの300台ぐらいは増えるんじゃないかなという感じです。今では、680以上のクラスタを運用しています。

その他にも、利用規模の数字を紹介します。利用チームは210プロジェクト以上。Kubernetes Clusterは先ほど話したように680以上。Kubernetes Clusterを構築しているノード数は1万3,000以上。これはVMです。それからKubernetes Cluster上で動いているPodの数は12万となっています。これだけの規模のKubernetesをだいたい20人ぐらいのチームで運用しています。

クラスタの構成

次に、Kubernetes Clusterの一つ一つのクラスタの構成を簡単に紹介します。

LBが2つに分かれていて、管理系のMasterのLBと、サービストラフィックを制御しているIngressのLBに分けて運用しています。下側にノードを書いていますが、Masterとetcd、そしてIngressとWorkerを、それぞれ分けて運用しています。

IngressとWorkerを分けているのは若干ポイントになっています。Kubernetesは、けっこうバージョンアップが発生するんですけれども、ローリングアップデートしていくときにLBからIngressを切り離して1台1台バージョンアップしていく必要があります。

そのときに、もしIngressをWorkerと一緒に乗っけて運用していると、Workerの台数分だけ切り離しの時間がかかってしまってローリングアップデートに時間がかかります。そこでIngressは外に切り出して数を少なく1台1台でリソースをたくさん使えるようにして、ローリングアップデートの時間を短縮しています。

Kubernetes as a Service

ヤフーのKubernetesの運用の仕組みも少し紹介しておきます。ヤフーではKubernetesを払い出すKubernetes as a Serviceという仕組みを使って、たくさんのKubernetes Clusterを運用しています。Kubernetes as a Serviceのソフトウェアは、OpenStackのAPIを実行してKubernetes Clusterを生成します。後でまた詳しくご紹介します。

先ほどのスライドでお話ししたKubernetes as a Serviceですけど、ゼットラボで開発を行なっていただいていて、ヤフーで受け入れをしています。ヤフーのインフラとインテグレーションしたあとにヤフーのサービス開発チームにKubernetes Clusterとして提供しています。この流れも後で詳しくお話しします。

ヤフーで使っているKubernetes as a Serviceですけど、これについてはもう別のイベントで話していて、もし興味がある方がいらっしゃれば、こちらのイベントのアーカイブを参照していただけると幸いです。もしもすでにこのイベントもう見たよとかYouTubeで見たよという方がいれば、コメント欄で反応いただけると発表者がとても喜びます。よろしくお願いします。

ここ3年のKubernetesの問題点

ヤフーではKubernetes Clusterをもう3年ぐらい運用しているんですが、3年間運用していくなかで、さまざまな問題が出てきました。下はそのインフラ、マシン部分であったり、上側に寄ってくるとアプリケーションやサービス寄りのものになっていきます。それぞれを時系列でプロットすると、このような問題が発生してきました。

最近では、右側に書いてあるたくさんのKubernetes Clusterを運用しているなかで、どうやってそれぞれのクラスタで発生するログを集約して社内のログ基盤に転送するかといった問題や、セキュリティ基盤とどう連携していくかという問題、また、ステートフル機能の提供など、最近対応していました。

さまざまな問題、先のスライドで直面してきたと話したのですが、今日はそちらにはフォーカスしないので、もし興味があればこちらのイベント（YJTC 2019 in Shibuya）ですでに発表済みなので、これも参照してもらえると幸いです。

Kubernetes運用の全体像

では次に、大量クラスタを少人数で運用する仕組みについてお話しします。運用の話をするので、まずは「そもそも運用ってどんな作業があるの？」というところからお話ししたいと思います。

画面の左側、ゼットラボからまずKubernetes as a Service、KaaSと呼びますが、KaaSのソフトウェアをヤフーで受け入れます。その後、ヤフーのKaaSチーム、運用チームは、ヤフーのインフラにそのソフトウェアをインテグレーションします。

例えばヤフーの社内ではOpenStackを使うので、その仕組みに合うようにOpenStackのVMイメージをビルドしたり、それから、社内の認証・認可の仕組み・基盤と連携するように設定したり。また、今日後半に話しますけど、運用系のメトリクスやログやトレースの基盤と連携するよう設定したり、セキュリティの基盤を連携するように設定したりします。

こうして準備したKaaSをデプロイして、KaaSを使って一つ一つのKubernetes Clusterをデプロイしていくことになります。

一番右側にヤフーのサービス開発チームと書いていますが、サービス開発チームのリクエストに応じてKubernetes Clusterを初期デプロイします。

デプロイしたKubernetes Clusterに対して、サービス開発チームはアプリケーションをデプロイして、サービスに関わる監視を実施して、それからサービスのトラフィックに応じてスケールアウトしたりスケールインしたりしてもらいます。

Kubernetesのバージョンアップがあった際は、まずは真ん中のヤフーのKaaSチームで検証などを行なって、利用可能になったらサービス開発チームでアップデートしてもらっています。

ただ、Kubernetesのバージョンアップ、必ずしもそれぞれのサービス開発チームで必要ないよというものもあると思っています。特にセキュリティの問題がなければ、そのままになっていることがあるので、そういったKubernetesに関しては、EOLが来たタイミングで、ヤフーの運用のチームで一斉にバージョンアップしたりしています。

それからその1つ上になってしまいますが、本日後半にお話しするデプロイ後のKubernetes Clusterの監視も、ヤフーのKaaSチームで行なっています。サービスのチームが使っていくなかで出てきた問い合わせに対応したり、問題調査もしたりします。

こうした運用も、たくさんそれぞれ作業があるんですけれども、こういった作業を効率的に行なっていくための仕組みを紹介します。効率的に行なうために「運用自動化」というのがキーワードになってきます。今回は、デプロイ作業に関わる自動化を2つ紹介します。

CIOps/GitOpsによる運用自動化

1つ目はCIOps/GitOpsによる運用自動化です。KaaSのデプロイ作業を例にお話しします。

ヤフーでは、このCIOps/GitOps、主にCIOpsの仕組みを使っていて、まず例えばKaaSのデプロイで新しい機能のKaaSがゼットラボから提供されたとき、ソフトウェアのChange Logs、新機能の項目が書かれたものを見ながら、検証が必要なものであったり、あとは設定の追加や変更が必要ものだったりを確認していきます。

それを設定ファイルとしてGitのリポジトリにプルリクエストして、KaaSのその他のメンバーでレビューを行ないます。そして設定変更が正しいと確認できたら、その変更のプルリクエストをmasterのブランチにマージします。

masterのブランチにマージされることで、連携しているCI/CDの仕組みでその設定内容がKubernetes as a Serviceのソフトウェアに反映されていくことになります。これで新しいKaaSを使えます。

このポイントは、例えば古いスタイルの運用だとExcelとかで設計をまとめていて、Excelのパラメータシートからソフトウェアの設定ファイルを起こして、それぞれの環境に適用しているといったケースもあると思うのですが、それと比べると、ソフトウェアが直接解釈できる設定ファイルを親にすることで、パラメータシートから設定ファイルに内容を移していくときのミスを防げたり、CI/CDで自動でデプロイすることによって、基盤構築作業のミスを防げるといったメリットがあります。

Kubernetes as a Serviceによる運用自動化

こうしてKubernetes as a Serviceをデプロイしたあと、今度はそのKubernetes as a Serviceから個々のKubernetes Clusterをデプロイする部分の効率化について触れていきたいと思います。

先ほどKubernetes as a Serviceのソフトウェアをデプロイしたんですけれども、このKubernetes as a Serviceを使って個々のKubernetes Clusterを効率的に運用しています。

先ほどから何回か触れているんですけど、Kubernetes as a Serviceはゼットラボ社で作ってもらっていて、Kubernetesをフレームワークとしてできています。Custom Resource Definitionの仕組みを使って、基盤を構成するそれぞれの要素をKubernetesの1つのリソースに捉えて、自動で基盤を構築するような仕組みになっています。

例えば、図の真ん中ちょっと右にあるマシンのリソースがあったりして、これでOpenStackのVMを構築したりとか、あとはマシンのノード数を管理しているリソースがあったり、ほかはKubernetesの設定を管理するリソースであったり、あとはLBを管理するリソースだったり、それぞれを状態監視して、健全性も確認することで、1つのKubernetes Clusterを自動で構築するような仕組みとなっています。

構築後も健全性を確認し続けるため、スケールアウトとかスケールインとか、またKubernetesバージョンアップ時のローリングアップデートであったり、あとはハイパーバイザー故障時のセルフヒーリングというものも自動で実現できています。

運用していくなかでちょっとおかしなVMがあったときに、上で動いているPodを退避できれば退避して消してしまえば、またこのKubernetes as a Serviceの仕組みによって新しいVMがデプロイされて自動でKubernetes Clusterに組み込んでくれるので、上側で動いているサービスに影響なくKubernetes Clusterを安定して運用できて、非常に強力な仕組みだと思っています。

このような仕組みを使って運用に関わる作業を減らしています。