他チームと協業してVerdaを使い、Kubernetesクラスタを開発する　LINEのVKSチームの活動と課題

国際色豊かなVKSチーム

Pickel Christopher氏：私はクリス・ピッケルです。私はLINEのVerda Departmentで、シニアソフトウェアエンジニアです。京都オフィスに所属しており、入社して4年になります。

日本で自己紹介する時、「私のことはこういうふうに覚えてください」と言います。ピクルスではなく、ピッケルです。私はピクルスではありません。ピッケルです（笑）

ということでVerdaついてですが、私はVerdaプラットフォーム開発Kチーム、VKS（Verda Kubernetes Service）の開発をしているのでVKSチームと呼ばれるチームに所属しています。VKSチームはVerdaの中でも一番国際色豊かだと思います。9人のメンバーがいて、京都・東京・ソウルに点在しています。

出身国も6ヶ国にわたっています。アメリカ、イギリス、ロシア、インド、韓国、日本なので、（つまり）アメリカン、イギリス、そしてインディアンイングリッシュのネイティブスピーカーがいるチームです。

Kubernetesを使いたい4つの理由

我々はKubernetesクラスタを開発しています。私たちがなぜKubernetesを使っているのかですが、その理由は大きく4つあります。

まずスケジューリングについてのメリットです。いろいろなマシンがある時、サーバーを特定のマシンにマニュアルで割り当てる必要はありません。ノードを、そしてサーバーを作ってくれるわけです。そしてKubernetesがどこにリソースを充てたらいいのかを考えていきます。

2番目です。スケーリングでリソースが必要であれば、Kubernetesのほうでどこにそれを追加できるのかスケジューリングしてくれます。

3番目はロールアウトです。これはサーバーをアップデートしなければならない時に、最低限のレプリカを用意して仕様に応じてスケジューリング、またはスケールアップとダウンをしてくれます。

そして4番目の理由、ルーティングです。例えばスケジューリング、スケーリング、ロールアウトを実行している時、Kubernetesにインバウンドのトラフィックが入ってきた時も、きちんとルーティングしてくれるように設計しています。

大きく４つの理由をお話ししましたが、Kubernetesはこれ以上のことをやってくれるわけです。

VKSチームのKubernetesの活用状況

我々はDedicated Clusters modelを採用しています。すなわち、Kubernetesを使いたいというチームがあれば、チームごとにクラスタを専用に割り当てています。

その反対がマルチテナンシーということで、複数のチームが1つのクラスタを共有します。こちらのほうがリソースを効率的に使えるわけですが、いろいろなチームが別々のソフトウェア、フィーチャーを使っているので、なかなかニーズを満たすのが難しいわけです。

現在、Kubernetes 1.24のサポートを追加しました。チームによってはすぐに使いたい、あるいはもうちょっと待ちたいチームもあるわけですが、やはり2つの方法をサポートしているので、両方のチームのニーズを満たすことができます。

現在は5つのゾーン、そして800以上のクラスタをサポートしています。Verda VMの15パーセントがVKSノードとして使われているのでかなり大部分を占めていますが、まだまだこれから拡張できるのではないかと思っています。

Kubernetesの優れているところは、いろいろなインフラに対応しているところです。マイナスな点は、バッテリーが搭載されていないため、すぐには使えないという点です。つまり、いろいろな準備をしないと使えないということです。マシンの調達、ネットワーク、ストレージ、そして他のインフラの準備をしなければなりません。

VKSはVerdaのプライベートクラウドの一部なので、とにかくすべてにVerdaを使っていくことが我々の課題になります。

他のチームと協業してフル機能を備えたKubernetesクラスタを提供するようにしています。コンピューティングリソースに関しては、VerdaのOpenStackを担当しているチームと連携します。ネットワークはVerdaのネットワークを担当するチームと連携します。ストレージは韓国にあるVerdaストレージチームと連携します。そしてオブザーバビリティに関しては、他のLINEのチームと協業しています。

コンピューティングのニーズの基本的なものですが、マシンをKubernetesノードとして使うということです。ほとんどはOpenStack VMを使っていますが、現在は自動化したプロビジョニングに割り当てはしていません。また、OpenStackImage、フレーバーのマネジメントも行っていて、リソースを効率的に使うようにしています。

ネットワーキングですが、ネットワークのプラグイン、例えばFlannel、Calicoなどのサポートもしています。インバウンドのトラフィックに関しては、ネットワークを担当するチームがLoadBalanceを開発しました。我々はKubernetesのコントローラーを開発したので、これを統合しました。

アウトバウンドのトラフィックに関しては、コントローラーを開発して統合しています。将来的にはIngressの実装も開発しているので、これもサポートしていきたいと思っています。

ストレージのRead Write Once Persistent Volumeですが、（これは）VerdaストレージチームのBlock storageサービスと一緒にサポートしています。

また、共有のファイルストレージに関してはRead Write Menyをサポートしていて、両方ともパブリックオープンソースコントローラーを使っています。

Observabilityは3つあると思います。まずはMetricsです。これはPrometheus Instanceを実行するということです。そしてLogsはFluentdコレクタを使っています。トレーシングに関してはまだサポートしていませんが、検討中ではあります。

VKSチームの3つの課題

3つの課題ですが、新しいバージョン、古いバージョン、そしてオンコールのタスクです。

まず新しいバージョンに関してですが、数年前にVKSをランチャー上に開発しました。その時はそれで十分だったんです。システムをリリースして、サービスをすぐに開発できましたが、現在のニーズと完全にマッチしていないわけです。

ランチャーでしようとしているフィーチャーはない。そしてKubernetesはとにかく進化しているし、新しいバージョンをリリースし続けています。ご存じだとは思いますが、KubernetesはDocker支部のサポート終了を発表しました。

現在サポートしていないランチャーバージョンを使っているので、クラスタAPIなどを使って、クラスタのライフサイクルを標準的な形式でサポートし、管理していきたいと考えています。

なので、ランチャーをアップグレードするか、あるいはクラスタAPI上にまた再構築するのかと検討し、結局後者にしました。

古いバージョンですが、現在1.13から1.24のKubernetesをサポートしているので、かなりいろいろなバージョンをサポートしています。これを同時にずっとサポートし続けるのは難しいと思っています。

しかしながら、ユーザーのクラスタをアップデートするのは我々も大変です。そして、ユーザーにお願いしてもなかなかやってくれません。また、アップグレードしてユーザーのクラスタが壊れてしまうような危険性もあります。

オンコールのタスクですが、我々のチームでは24×7のオンコールタスクがあります。幸いにも、あまり業務時間外に連絡を受けることはありませんが、チームになったらこのタスクを担う可能性があるので、あらかじめ伝えておきたいと思います。

業務時間内にたくさんの仕事が発生することがあります。それはなぜかと言うと、あまり自動化ができていないからです。他のチームでも自動化されている部分はかなり限定的だと思います。

VKSチームの今後の取り組み

今後ですが、まずクラスタAPIに移行したいと思います。それ以後はもっとインテグレーションをして、そしていろいろなフィーチャーをユーザーに提供して、もっと我々のサービスを使ってもらいたいと思っています。