KubeCon + CloudNativeCon Europe 2023 参加レポート

OGP

こんにちは。SRE部ECプラットフォーム基盤SREブロックの亀井です。

4月18日から4月21日にかけてKubeCon + CloudNativeCon Europe 2023（以下、KubeCon）が行われました。今回弊社からはZOZOTOWNのマイクロサービス基盤に関わるメンバー2名で参加しました。

本記事では現地の様子や弊社エンジニアが気になったセッションについてレポートしていきます。

KubeCon EU 2023の概要

昨年10月にデトロイトで行われたKubeCon NAの様子についてはこちらの記事をご覧ください。

今回参加してきたKubeConはオランダのアムステルダムで現地＋オンラインのハイブリッド開催でした。10,000人以上が現地で参加しており、これはヨーロッパ開催のKubeCon史上最大であり、ヨーロッパで最大のオープンソースカンファレンスになるとのことでした。

この形式での開催は新型コロナウィルス感染症（COVID-19、以下コロナ）のパンデミック以降3度目の開催であり、ついにマスク着用が義務化ではなく推奨となりました。

KubeConではキーノートやセッション、LTなどを通してKubernetesに関する最新のアップデートの紹介や、実際にKubernetesを採用した企業の幅広い運用ノウハウを聞くことができます。以降では参加してきた社員がそれぞれ気になったセッションについて取り上げてご紹介します。

参加メンバーによるセッション紹介

Flux Beyond Git: Harnessing the Power of OCI

SRE部ECプラットフォーム基盤SREブロックの巣立（@ksudate）です。

Weaveworks社のStefan ProdanとHidde BeydalsによるOCIに関するFluxの最新動向についてのセッションでした。

冒頭では、Fluxに関連するコントローラーやエコシステムの概要が紹介されました。その中で、CloudFormationのスタックをFluxで管理するAWS CloudFormation Template Sync Controller for Fluxは個人的にとても気になっています。

https://github.com/awslabs/aws-cloudformation-controller-for-flux

本題のOCI(Open Container Initiative)についてです。

従来のFluxでは、クラスター構成をGitから、コンテナイメージをイメージレジストリからPullしてくる必要がありました。

GitOps Workflow

（Flux Beyond Git: Harnessing the Power of OCI より引用）

しかし、クラスタ構成とコンテナイメージの両方をコンテナレジストリを使って管理することでシンプルになります。

この構成を実現する方法として、OCIアーティファクトが紹介されました。

また、cuelangやjsonnetなどを利用している場合、Gitリポジトリには最終的なKubernetesマニフェストが含まれていない場合があります。

そのような場合、OCIであればCIで生成済みのマニフェストをOCIアーティファクトとして公開できます。

GitOps Workflow using OCI

（Flux Beyond Git: Harnessing the Power of OCI より引用）

実際にFluxでは、OCIRepositoryと呼ばれるCustom Resourceを利用する事でこれが可能になります。

OCIアーティファクトをイメージレジストリへPushするためのfluxcliのコマンドも用意されています。

flux push artifact
flux pull artifact
flux list artifacts

その他にもGitと比較した場合のOCIのメリットが紹介されました。

例えば、OCIはAPIベースで操作できるのに対して、GitはAPIベースで操作できません。

APIベースでOCIアーティファクトを保存・取得・更新できるため、Gitに比べて扱いやすくなります。

Benefits of OCI

（Flux Beyond Git: Harnessing the Power of OCI より引用）

また、OCIアーティファクトの検証方法についても、触れていました。 OCIではSigstore Cosignを利用しており、GitのOpenPGPと比べて管理が楽になります。

OCIの登場により、FluxはさらにGitをSSoTとして扱うことが可能になりました。より詳しくは、公式ドキュメントも併せてご覧下さい。

Unlocking the Potential of KEDA: New Features and Best Practices

亀井です。

このセッションではKEDAプロジェクトについて概要と直近の変更点・ベストプラクティスが紹介されていました。

KEDA（Kubernetes-based Event Driven Autoscaling）はKubernetes上でイベント駆動（何かのイベントに応じて処理を行う仕組み）のオートスケールを実現するオープンソースプロジェクトです。

イベントソースを監視して、Horizontal Pod Autoscaler（以下、HPA）などの標準的なKubernetesコンポーネントを拡張しPodの数を動的に調整できます。サポートするスケーラーはAzure Functions、Apache Kafka、RabbitMQ、Azure Service Bus、NATS、AWS SQSなど60を超えます（ref. サポートしているスケーラー一覧）。

下図がアーキテクチャです。ScaledObjectカスタムリソースで、スケーラーや条件といったトリガーとスケールの内容を定義します。KEDAの各コンポーネントがスケーラーを監視し、HPAなどのKubernetesコンポーネントと連携しPodの数を動的に調整します。

KEDAアーキテクチャ

（Unlocking the Potential of KEDA: New Features and Best Practices 資料9ページより引用）

セッションでは下記の4つの直近の変更点が紹介されていました。

Architecture Changes
- 安定化のため外部スケーラーとの通信に関する構成
Certificate Management
- TLS1.3で暗号化されるコンポーネント間通信の証明書管理
Validation Webhooks
- ScaleObject Custom Resourceのvalidation
Prometheus Metrics

特に気になった変更点は「Prometheus metrics」でPrometheusメトリクスを公開するようになったことです。スケーラーの状況やコンポーネントのエラー数といったメトリクスが取得可能です（ref. すべてのメトリクス）。本番サービスでKEDAを運用するハードルが下がる大きなアップデートだったのでは無いでしょうか。

また、次の3つのベストプラクティスが紹介されていました。

Polling Interval & Metrics Caching
- 外部スケーラーへのクエリ実行間隔の考え方とキャッシュ機能について
HPA Scaling Behavior
- HPAのスケーリング動作を制御するオプションについて
Kubernetes Metrics
- KEDA運用にあたって関連するKubernetes Metricsについて

ZOZOTOWNでは、人気商品の販売やセールなどが定期的に行われております。そのタイミングでアクセスがスパイクするのですが、HPAに頼ったオートスケールでは間に合わないことが多々あります。事前にHPAのminReplicasを増やすなどしてPodのスケールを行っているのですが、都度作業しておりtoilになっています。

KEDAを使うことで、人気商品の販売やセールといった予定をイベントソースとしてスパイク前にオートスケールができそうに感じました。Kubernetesにおけるオートスケールの新たな選択肢として、今後も動向を注視し導入の検討を進めて行きたいと思います。