Kubernetes 高可用性を「レプリカを増やせば安心」と考えていないだろうか。放送業界がワールドカップ中継で実践している"二重伝送"の発想を手がかりに、Topology Spread ConstraintsやマルチAZ設計が本当に意味することを解き明かす。
1. なぜワールドカップの映像は一度も止まらないのか
サッカーワールドカップのような世界規模の中継では、複数のスタジアムに設置された数十台のカメラの映像が、国際放送センターへとリアルタイムで集約される。この伝送の裏側で使われているのが、IPネットワーク上で映像を冗長化する国際規格「SMPTE ST 2022-7」だ。
Elecardの技術解説によると、この規格は送信側で同一のRTPストリームを複製し、完全に独立した2つの経路へ同時に送り出す。受信側はシーケンス番号とタイムスタンプで両ストリームを突き合わせ、片方にパケットロスや遅延が発生しても、瞬時にもう一方から補完する。切り替えは「知覚できないレベル」で行われ、視聴者はもちろん、現場のオペレーターすら異常に気づかないことも珍しくない。
ここで注目したいのは、この二重化が単に「ケーブルを2本引く」ことではない点だ。スイッチやルーター、電源系統まで含めて経路そのものを完全に分離することで初めて、片方のインフラ全体が丸ごと落ちても中継が続く、という信頼性が成立する。
Kubernetesの世界で「高可用性」という言葉を使うとき、多くのエンジニアが思い浮かべるのは「レプリカを複数用意する」ことだ。しかし放送業界が実践しているのは、それよりもずっと厳格な基準——止まったことにすら気づかせないレベルの冗長化である。この違いを理解することが、Kubernetesの高可用性設計を見直す第一歩になる。
2. 「レプリカ3つ」で高可用性、は思い込みにすぎない
CNCFの2026年次調査によれば、コンテナ利用企業のうち82%が本番環境でKubernetesを運用している。裏を返せば、それだけ多くの本番システムのKubernetes 高可用性設計が、実は不十分なまま稼働している可能性があるということだ。
Kubernetesのデフォルトスケジューラは、明示的な制約を設定しない限り、リソースに空きがあるノードへ機械的にPodを配置する。その結果、「レプリカ3つ」という数字だけを見て安心していても、実際には同一ノード、あるいは同一アベイラビリティゾーン(AZ)に集中配置されてしまうケースが起こりうる。そのゾーンで電源障害やネットワーク分断が発生すれば、3つのレプリカが同時に落ちる。
ITICが2024年に実施した企業調査では、従業員1,000人を超える大企業の97%が「年間平均で1時間のダウンタイムが10万ドル超のコストを生む」と回答しており、90%の企業では1時間あたり30万ドルを超えると報告されている。「レプリカを増やしたから大丈夫」という思い込みのまま本番運用を続けるリスクは、決して小さくない。
放送業界が経路そのものを分離するように、Kubernetesでも「どこに配置されているか」を制御しない限り、本当の意味での高可用性は実現しない。
3. 放送業界の「経路分離」思想をKubernetesに翻訳する
放送業界の「経路分離」に相当する仕組みは、Kubernetesにもすでに用意されている。
Topology Spread Constraints — ゾーンをまたいだ経路分離
Kubernetes公式ドキュメントによれば、topologySpreadConstraintsはmaxSkew(ゾーン間でのPod数の許容偏差)、topologyKey(ノード単位ならkubernetes.io/hostname、ゾーン単位ならtopology.kubernetes.io/zone)、whenUnsatisfiable(制約を満たせない場合に配置を拒否するDoNotScheduleか、妥協して配置するScheduleAnywayか)の3要素で構成される。
AWSの実践ガイドでは、maxSkew: 1かつtopologyKey: topology.kubernetes.io/zoneを指定し、レプリカを複数のAZへ均等に分散させる構成が推奨されている。これはまさに、放送業界が同一ストリームを独立した経路へ振り分ける発想と同じだ。
Pod Anti-AffinityとPodDisruptionBudget — 二重の安全網
Topology Spread Constraintsに加え、同一ノードへの集中配置を避けるPod Anti-Affinityを組み合わせることで、ノード単位・ゾーン単位の両方で分散を担保できる。さらにKubernetes公式のPodDisruptionBudget解説にある通り、ノードのメンテナンスやクラスタアップグレードといった「意図的な停止(voluntary disruption)」に対しては、最低限稼働させるPod数をPodDisruptionBudgetで保証できる。一方、ハードウェア故障やカーネルパニックのような「意図しない停止(involuntary disruption)」はPodDisruptionBudgetでは防げず、Topology Spread Constraintsによる事前の分散配置でしか対処できない。この2つは役割が異なるため、両方を組み合わせて初めて放送業界レベルの冗長性に近づく。
K3sはCNCF認定の軽量Kubernetesディストリビューションであり、これらの標準機能をそのまま利用できる。ただし、マルチAZ・マルチクラスタ構成を自前で設計・運用するには、ネットワーク設計からモニタリング体制まで相応の専任リソースが必要になる。KuboはK3sベースでありながらRancher管理基盤による可視化を標準搭載しており、こうした分散配置の状態をクラスタ横断で確認しながら運用できる。
4. 「本当に切り替わるか」を試さないHA設計は設計ではない
放送の現場では、本番前に必ずフェイルオーバーの動作確認が行われる。片方の経路をあえて切断し、実際に「気づかれずに」切り替わるかをテストして初めて、本番投入の判断が下される。
Kubernetesの高可用性設計でも同じ検証が欠かせない。CNCFのIncubatingプロジェクトであるChaos Meshは、Pod障害・ネットワーク遅延・パケットロスといった実際の障害をKubernetesクラスタ上で意図的に注入できるツールだ。Topology Spread ConstraintsやPodDisruptionBudgetを設定しただけで満足せず、実際にゾーン障害を模したPodChaos・NetworkChaosを流し込み、レプリカが本当に生き残るか、サービスが継続するかを検証して初めて、設計は「本当の高可用性」と呼べる状態になる。
設定を書いて終わりにするか、実際に壊してみて確認するか。この一手間の差が、放送業界が体現する「気づかせないレベルの信頼性」とKubernetesクラスタとの間にある距離を埋める。
5. まとめ — 「気づかせない」レベルの可用性をどう実現するか
放送業界の二重伝送が教えてくれるのは、高可用性とは「壊れても動く」ことではなく「壊れたことに気づかせない」ことだという発想の転換だ。Kubernetesにおいても、レプリカ数を増やすだけでなく、Topology Spread ConstraintsとPod Anti-Affinityで配置そのものを分散させ、PodDisruptionBudgetで意図的な停止から守り、Chaos Mesh等で実際に壊して検証する。この一連の設計を積み重ねて初めて、放送業界レベルの信頼性に近づける。
とはいえ、マルチAZ・マルチクラスタの分散配置を自前で設計し、日々の可視化・検証まで運用し続けるのは決して軽い負荷ではない。Kubo Cloudなら、K3sベースの本格的なKubernetes機能をそのままに、Rancher管理基盤によるマルチクラスタの可視化を標準搭載した状態で、月額48,000円〜からこうした高可用性構成を組み始められる。
まずは自社クラスタのTopology Spread Constraints設定を見直すところから始めてもいいし、ゼロからマルチAZ構成を組むならKuboで始めてみるのもいい。「気づかせないレベルの可用性」は、思い込みではなく設計と検証の積み重ねでしか手に入らない。