Tokyo Gas KubeCon EU 2025 Recap@Kubernetes Meetup Tokyo #70

Kubernetes Meetup Tokyo #70 でお話しした資料です。
KubeCon EU 2025 Recap
Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure?

Session: https://sched.co/1txEX
YouTube: https://www.youtube.com/watch?v=9U3WMez9q74

Transcript

1. 東京ガス株式会社 杉山 祐介 KubeCon EU 2025 Recap: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure?
2. 自己紹介 2 名前 杉山祐介 / Yusuke Sugiyama 所属 東京ガス株式会社 経歴 SI -> 内製 -> AWS(SA) -> 2022年10月より現職 好き Suicaのペンギン / ファッション @yus_sugiyama 2回目の KubeCon 参加！
3. 882.6 東京ガスグループについて 3 渋沢栄一が東京瓦斯会社を創立 連結売上高 2 6,368 都市ガス小売お客さま件数 東京だけでなく、 全国、世界に事業展開 バリューチェーンの上流から下流まで事業展開 エネルギー販売 エネルギーソリューション エネルギー製造・供給 原料調達・輸送 電力小売お客さま件数 415.2 総資産 3 8,551 家庭にも企業にも サービス提供 電力もガスも つくっている 世界から 自社船で安定調達 日本全国に 再エネ電源等を 開発・保有 北米や東南アジアを中心に 海外プロジェクトも多数 1885 （明治18年） 年 文明開化の街と人々の暮らしをあかりで照らす 億円 兆 兆 億円 万件 ※2025年3月末時点 万件 約 約
4. Keynoteでの一枚 4 CNCF End User として東京ガスのロゴを発見 個人的に一番テンションが上がった瞬間でした（嬉しかった） 記念に撮影も
5. セッション概要 5 タイトル Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? Solo.io と New York Times とのセッション。 shced: https://sched.co/1txEX YouTube: https://www.youtube.com/watch?v=9U3WMez9q74
6. セッション参加理由 6 同じエンドユーザーサポーターでもある New York Times 社におけるサービスメッシュ活用の 実例を知るとともに、数年前までは Cilium を採用していたチームが、なぜ Istio も導入したのか、 どのようなジャーニーを歩んだのかリアルな声を聞きたかったため。 当チームでも Istio を採用している。 まだ利用していない Ambient についても インサイトが得られるかもしれない・・・？
7. Istioとは 7 Service Mesh. Simplified. Easily build cloud native workloads securely and reliably with Istio, with or without sidecars. 引用元: https://istio.io/ 2016年に Google、IBM、Lyft によって設立 され、Kubernetes や Prometheus などと共 に Cloud Native Computing Foundation の Graduated Project として位置付けられてい ます。 引用元: https://istio.io/latest/about/service-mesh/
8. セッション振り返り
9. NYT社の課題感 9 過去にどうやってルーティングしていたか。 たとえばサービスAがサービスDに通信した いとき。これまではマルチリージョンを前提 とした構成で考え、Gateway とアプリケー ションの実装に頼っていた。 そのため、アプリケーション開発チームに負 担を強いる形となっていた。 その負担を解決することがプラットフォーム チームとしてのミッション。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
10. サービスメッシュの導入へ 10 以下を満たすためにメッシュが必要。 - サービス間トラフィックを細かく制御 - カナリアリリースを実現 - クラスターやサービスのフェイルオー バーを処理 - アプリケーション開発チームがトラ フィックルーティングのロジックをクラ イアント側に保有しない 他にも mTLS の導入、オブザーバビリティな ど、各開発チームに依頼することなく、プ ラットフォームチームで解決したい。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
11. これまでのジャーニー 11 当初マルチテナントクラスターを構築したと きには Cilium を導入。Cilium Cluster Mesh を採用して全てフラットな構成にした。 当初は Cilium のサービス機能、Cluster Mesh を使うことを考えていた。 しかし、この時点で「 Istio のサービスメッ シュが必要だ」と内部でディスカッションし たうえで、導入を決意。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
12. Istioのコストとゲームチェンジャー 12 Istio は「無料」で手に入るわけではなく、 「コスト」が掛かる。 コントロールプレーン、データプレーンの稼 働はもちろん、サイドカーとしてのプロキ シーも必要。 これらは明確な「オーバーヘッド」であった。 そこに現れたゲームチェンジャーが Ambient Mesh である。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
13. Ambient Mesh 13 Ambient Mesh: 運用の簡素化、アプリケーション互換性、イ ンフラコスト削減を目的とした新しい Istio データプレーンモード。 サイドカープロキシーを省略可能。 Namespace 内に Waypoint Proxy と呼ばれ るものを使用して構成。 今ロールプレーンがクラスター内の ztunnel を構成してL7処理が必要なトラフィックを Waypoint Proxy 経由で転送。 引用元: https://istio.io/latest/blog/2022/introducing-ambient-mesh/ Sidecars mode Ambient Mesh
14. Ambient Mesh Testing 14 NYT 社のように、何百ものノード、何千も の Pod を運用しているチームにとって、本 当に必要なものが Ambient Mesh だった。 チームでのテスト結果も期待通り。 e.g. レイテンシの削減では平均で 4.98ms -> 3.7ms に短縮され、約25%の改善。 マイクロサービスやサービスメッシュ構成で は、数ミリ秒の差でも大きな影響を与える。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
15. 移行戦略 15 Namespace 単位での段階的な移行が可能と いうのも大きなポイント。 Istio の サイドカー方式のデータプレーンと、 Ambient の 新しいデータプレーンの両方を 同時にインストールし、そのうえで、 Namespace ごとに段階的に移行を実施。 この方法で、徐々に Ambient に移行しなが らテストを重ねることができた。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
16. うまくいかなかった話 16 もちろんうまくいかなかった点も。 さらに、マルチクラスタではまだ期待どおり 動作しない。 これはコミュニティと共に Ambient のマル チクラスタ対応に向けて、取組中とのこと。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
17. マルチクラスターへの対応 17 （Solo.io から説明） Ambient にも、従来の Istio サイドカー方式 と同じレベルのマルチクラスタ対応が提供さ れる予定。特に注目すべき点は、マルチクラ スタ通信のトラフィックがすべて ゼロトラ ストトンネル (ztunnel) を通過するようにな ること。通信先に Waypoint があれば、トラ フィックは East-West Gateway を経由して Waypoint に到達し、必要な認可ポリシーや L7ポリシーが適用された後に、目的のサー ビスへ届く。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
18. 質疑応答で気になったもの 18 Q: 最初に Cilium CNI と Cilium Cluster Mesh を使われていたとおっしゃってましたが、なぜそのまま Cilium Service Mesh を使わなかったのですか？今ならその選択肢もアリだったのでは？ A: 実は、私自身も最初は Cilium Service Mesh を使いたいと思っていたんです。 ですが、当時の Cilium Service Mesh では独自の CRD（カスタムリソース定義）を作るのではなく、 Kubernetes の Service オブジェクトにアノテーションをつける形でした。それでは、グローバルサービスや ローカルサービスの指定などが十分に柔軟にできなかったのです。マルチクラスタでトラフィックをシフトした り、リトライ処理、カナリアデプロイメントなど、我々のニーズを満たすには不十分でした。また、当時の Cilium は Gateway API との統合も進んでいませんでした。そこで Istio を併用することにしました。今は Cilium CNI（ネットワーク）と Istio（サービスメッシュ）を組み合わせて使っています。それぞれが補完し あっていて、Cilium は L3/L4 のフローログやネットワーク可視化 (Hubble) を提供してくれますし、Istio は L7 のルーティングやセキュリティ制御を担ってくれます。将来的には統合するかもしれませんが、今のところこ の構成がうまくいっています。 引用元: https://www.youtube.com/watch?v=9U3WMez9q74 (セッション動画より筆者が意訳・編集したものです)
19. チーム課題との関わり
20. サービスメッシュは必要なのか？ 20 当初は EKS と ALB の仕様を鑑みて、Istio Ingress Gateway を導入したかったのが大きい。 そしてサービス間通信も確実に必要な未来が見える（今はまだ直接呼ばなくても良い） 上記の理由より、初期リリースから導入していた。しかし挙動に悩まされるのも事実。 現在、新規事業の設計中。 事業ドメインで分けたクラスターを新規構築。
21. 実際に何が起きているか 21 NYT社「Sidecar だと、アノテーションで起動順を制御したり、503エラーに悩まされたり、 Webhook のインジェクションタイミングに気を遣う必要がありましたよね。Ambient ではそうした 問題が一切発生しません。」 KubeCon London 出発前に Istio Upgrade を実施 →本番環境で定期的に503エラーが発生するように… メンバー「ロンドンの杉山さん？」 杉山「ごめんなさい」 悩まされたくない！！！ （ホテルや会場で必死にログ見てました・・・ 引用元: https://www.youtube.com/watch?v=9U3WMez9q74 (セッション動画より筆者が意訳・編集したものです)
22. 今後目指したい姿 22 個人的に Gateway API + Ambient Mesh が Istio 利用時には欠かせない要素だと受け止めている。 （少し早すぎたかもしれない…） 前述したように事業ドメインで分けたクラスター同士の通信も発生する見込み。 クラスター通信をどうするか悩んでいたので、Istio も対応するようであれば積極的に Ambient Mesh に切り替えていきたい。 この情報は知らなかったため非常にありがたかった。 できればこの構成にしていきたい。 画像出典: Journey at the New York Times: Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? - Lin Sun, Solo.io & Ahmed Bebars, The New York Times
23. Q: 最初に Cilium CNI と Cilium Cluster Mesh を使われていたとおっしゃってましたが、なぜそのまま Cilium Service Mesh を使わなかったのですか？今ならその選択肢もアリだったのでは？ A: 実は、私自身も最初は Cilium Service Mesh を使いたいと思っていたんです。 ですが、当時の Cilium Service Mesh では独自の CRD（カスタムリソース定義）を作るのではなく、 Kubernetes の Service オブジェクトにアノテーションをつける形でした。それでは、グローバルサービスや ローカルサービスの指定などが十分に柔軟にできなかったのです。マルチクラスタでトラフィックをシフトした り、リトライ処理、カナリアデプロイメントなど、我々のニーズを満たすには不十分でした。また、当時の Cilium は Gateway API との統合も進んでいませんでした。そこで Istio を併用することにしました。今は Cilium CNI（ネットワーク）と Istio（サービスメッシュ）を組み合わせて使っています。それぞれが補完し あっていて、Cilium は L3/L4 のフローログやネットワーク可視化 (Hubble) を提供してくれますし、Istio は L7 のルーティングやセキュリティ制御を担ってくれます。将来的には統合するかもしれませんが、今のところこ の構成がうまくいっています。 再掲：Cilium + Istio.. . 23 オブザーバビリティの観点から VPC CNI だけでなく Cilium 導入も試したいと考えていた。 しかしこれ以上 OSS を増やすと、チームとして耐えられないのが事実。 （NYT社のプラットフォームチームメンバー数を聞いて尚更痛感） 引用元: https://www.youtube.com/watch?v=9U3WMez9q74 (セッション動画より筆者が意訳・編集したものです)
24. まとめ 24 ゲームチェンジャー Istio Ambient Mesh： サービスメッシュが必要なチームにとってオーバーヘッドを減らすことが出来る Ambient Mesh は まさにゲームチェンジャーと呼ぶべき存在。 しかし、そもそもサービスメッシュ自体が必要な理由を明確にするべき。 今はまだ小さいチームで事業とエコシステム双方へ貢献するために： 数多くの OSS が存在する中、活用するだけで手一杯の状況が見えてきた。 エンドユーザーサポーターや KubeCon Japan のサポーターなど、金銭的な貢献はしつつも、 まだその先に行けていないのが事実。 そのような状況において、世界で先行する企業の事例を参考にアーキテクチャを考えられるのは 非常にありがたいことであると共に、当チームも積極的にシェアしていきたい！ 自社事業とエコシステム双方への貢献を引き続き目指す！