Yard 編集部

☸️

Kubernetes Meetup Tokyo #69 イベントレポート

公開

2025-02-06

文章量

約4057字

Yard 編集部

フォロー

Yardの編集部が、テック業界の最新トレンドや知見について発信します。

はじめに

Kubernetesでメールの大量配信をしている話 (SAKURA internet 深町公法氏)

Kubernetes x k6 で負荷試験基盤を開発した話 (Sansan株式会社藤岡大輝氏)

LT1. Kubernetes OperatorでGKEのカスタムコンピューティングクラスの機能を自作してみた (tryuuu)

LT2. PreStopによるSleep中に何が起きているか：安全なRollingUpdateの実施のために (na2na)

LT3. Kubernetes DNSでハマった話 ~ Spring Boot編 ~(musaprg)

LT4. Kubernetes History Inspector を触ってみた (bells17)

感想

参考リンク

イベントレポート

Kubernetes

Insight

はじめに

2025年2月5日にオンラインで開催された「Kubernetes Meetup Tokyo #69」のレポートです。

通常はオフラインとオンラインのハイブリッド開催を行っている同ミートアップですが、今回もオンラインのみでの実施となりました。

Kubernetesの最新事例や、実運用のなかで得た知見を共有する場として、多数の参加者が集まり、盛り上がりを見せていました。

Kubernetesでメールの大量配信をしている話 (SAKURA internet 深町公法氏)

さくらインターネットの深町公法氏による、Kubernetes を利用してメールを大量配信するシステムを構築・運用した事例が紹介されました。

もともと数十万件規模のメール配信を行う旧システムがレガシー化し、配信時間の長さやサーバー老朽化などの課題があったところを、Kubernetes 上に刷新。

Kafkaを活用したマイクロサービス的な実装で並列度を高め、

数十万件規模の送信を約26分で完了（以前は8時間程度）
将来のスケールアウトや部分的なアップデート・メンテナンスが容易

などの成果を得たとのことでした。Kafkaのパーティションを分割し、それぞれのコンシューマが重複なく処理する仕組みによって、大幅な高速化を実現。最終的には、古い配信システム比で約20倍の速度向上を達成したという具体的な数値が印象的でした。

Q&Aの主なポイント

Kafkaパーティション数の拡張運用中に性能が足りなくなればパーティションを増やし、対応するコンシューマ数（=Pod数）を増やす方針。
クラウドとオンプレ混在構成一部ノードを社内データセンターのベアメタル、追加ノードをクラウドVMに置くハイブリッド構成だが、物理的に近くにあるため通信遅延はそれほど問題になっていない。
メール配信時のDNS・SMTPにおける遅延対策送信先が無効なドメインの場合は一定時間リトライし、結果的に送れなければ破棄する。Kubernetes上のPodでは複雑な制御はせず、外部のゲートウェイで対処している。

Kubernetes x k6 で負荷試験基盤を開発した話 (Sansan株式会社藤岡大輝氏)

Sansanの藤岡大輝氏より、Kubernetes基盤上にk6-operatorを導入し、負荷試験のプラットフォームを開発・運用している事例が紹介されました。複数サービスがある環境の負荷試験を共通化し、開発者がワンクリックで試験を実行できるようにしたことで、以下のメリットを得たとのことです。

開発リードタイムの削減（特に研究部門など、エンジニア以外のメンバーでもテストが可能に）
負荷試験に対するハードルが低下し、「リリース前だけではなく、機能追加ごとに小まめに負荷試験を回せる」 文化が定着
k6の拡張機能（k6 extension）を自作し、AWSのSecretManagerからシークレットを取得するなど、柔軟なシナリオを実装可能
テスト結果のダッシュボード連携（Datadogなど）によりリアルタイムにパフォーマンスを可視化

また、「Kubernetesを使うことで負荷試験実行ノードもスケールでき、ローカルマシンのスペックに依存しない」点が大きな利点になっているとのことでした。さらに、GitHub Actionsと組み合わせて、アプリのリポジトリに最低限のワークフローを追加するだけで試験可能という仕組みは、とても実運用に役立つという声がありました。

Q&Aの主なポイント

K6のシナリオ管理方法

ConfigMapマウント/ボリュームクレーム/イメージ埋め込みの3案を比較し、最終的にはイメージ化してECRで管理する形に。

複数ユーザーで同時に複数シナリオを走らせた場合

基本は並列実行を制御しつつ、負荷試験のジョブが増えた場合にノードをオートスケール（例：Karpeneter）することでボトルネックを緩和している。

LT1. Kubernetes OperatorでGKEのカスタムコンピューティングクラスの機能を自作してみた (tryuuu)

Google Cloudが提供している「カスタムコンピューティングクラス」をKubernetes Operatorで再現してみた話。オートスケール時に使いたいマシンタイプやスポット設定等をカスタムリソースで指定し、優先度付きでスケジューリングさせる仕組みを手作りしたという内容でした。

自作実装のポイント

CRDとクラスタオートスケーラーを組み合わせ
ノード起動時に付与されるテイントや、フォールバック時に再度別のテイントを付与する工夫
インフォマ＋ランナブルを使い、ポッドがペンディングに陥ったら自動で別の優先順位へ切り替える実装

GKEの機能を自前オペレーターで再現する深掘りの取り組みが興味深かったです。

LT2. PreStopによるSleep中に何が起きているか：安全なRollingUpdateの実施のために (na2na)

RollingUpdateでPodを終了する際に、preStopフックで数秒スリープを入れてからトラフィックを切り離す手法が一般的に知られているが、「具体的に内部でどのような処理が行われているのか」をソースコードリーディングや実験で調べた結果の紹介でした。

ポイント

Pod削除 → DeletionTimestampが付与
Endpoints(EndpointsSlice)が更新され、readyフラグが外される
kube-proxyがIPTablesの更新をブロッキング実行 → すぐに該当Podがルーティング対象から外れる

スリープ時間を置くことでこの切り離しが完了し、Pod終了までの猶予を確保する
公式ドキュメントにもあまり踏み込まれていない、内部実装の詳細が分かりやすく解説されました。

LT3. Kubernetes DNSでハマった話 ~ Spring Boot編 ~(musaprg)

Kubernetes上でDNSルックアップが多段階に行われる状況で、Spring Bootアプリ（とりわけSpring WebFlux / Reactor Netty）が内部で使用するDNS実装によって挙動が変わった、という興味深いトラブル事例。

Reactor Netty 1系以降はデフォルトで JVM標準のDNS実装ではなく「Netty DNS Resolver」を使用
結果、サーチドメインやプライマリ/セカンダリDNSへの問い合わせ順が異なり、一部がタイムアウト
回避策としてはFQDNを明示的に使う / ndotsの値を調整 / Springの設定でJVM DNS実装に戻す …などを検討

KubernetesのDNSまわりはサーチドメインの多さから「余計な問い合わせが増える」問題もあり、パフォーマンス・正引き失敗など注意が必要という学びが共有されました。

LT4. Kubernetes History Inspector を触ってみた (bells17)

Google Cloud カスタマーサポート発の新ツール「Kubernetes History Inspector (KHI)」の紹介。

Kubernetesのクラスターイベントをログから収集・関連づけて可視化する仕組み
GKE環境（現時点）のみサポートだが、Docker起動するだけでエージェントレスに解析・表示できる
オブジェクトの作成・変更・削除といったイベントをタイムライン表示し、何がいつ行われたかを把握するのに役立つ

クラスタートラブルシューティング時の履歴追跡が簡単になるツールとして注目度が高い。現在オープンソースで開発・コントリビューションも歓迎とのこと。

感想

メール大量配信の事例や負荷試験基盤など、実際にKubernetesを業務利用する中でのリアルな知見が充実しており、非常に参考になったとの声が多かったです。
LTでもオペレーター自作やDNS実装の違いなど、深い技術的考察があり、「Kubernetesでなぜこれが必要なのか」「内部ではどう実装されているのか」など、一歩踏み込んだトピックに関心を持つ参加者が多かった印象です。
次回以降も30分枠登壇やLT登壇の募集が継続されるとのことですので、興味がある方はぜひ「Kubernetes Meetup Tokyo」のコンパスページをチェックしてみてください。