国際色豊かな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に移行したいと思います。それ以後はもっとインテグレーションをして、そしていろいろなフィーチャーをユーザーに提供して、もっと我々のサービスを使ってもらいたいと思っています。
