「切ったら壊れます」と言われたのに、あえて二重に送る理由
世界最大級のスポーツイベントを支える国際放送センターでは、すべてのカメラ映像が意図的に同じ内容のまま2つの独立した経路で同時送信されている。片方を「赤」、もう片方を「青」と呼び分け、まったく別のスイッチ・ルーターを経由させる。受信側は両方のストリームを受け取り、シーケンス番号とタイムスタンプが一致する2つのパケットのうち、先に到着した方だけを映像として採用し、後から届いた方はそのまま捨てる。
一見すると帯域の無駄遣いに思えるこの設計は、実は「失敗が許されないシステム」における標準的な作法だ。そしてこの発想は、Kubernetesの高可用性設計の根幹にある考え方と驚くほど一致している。本記事では、放送業界の冗長化手法を入り口に、Kubernetesがどのようにして「壊れても気づかせない」システムを実現しているのか、そして自前で構築する場合とマネージドなKuboに任せる場合で何が変わるのかを解き明かす。
名前を知らなかっただけで、これは業界標準だった — Seamless Protection Switching
この「二重送信・早着優先」という手法には正式名称がある。SMPTE ST 2022-7、通称Seamless Protection Switching(無瞬断保護切替)だ。SMPTE 2022規格の解説（Wikipedia）によれば、ST 2022-7はRTPデータグラムレベルでの無瞬断な保護切替を規定した仕様であり、IP化が進む放送インフラの信頼性を担保する目的で策定された。
具体的な仕組みは、ST 2022-7の技術解説記事が詳しい。送信側のスプリッターが同一ペイロードを持つRTPストリームを複製し、物理的に独立した2つのネットワークパスへ流す。受信側のスイッチャーは両方のパスから届くパケットをそれぞれ別バッファで受け取り、RTPヘッダのシーケンス番号とタイムスタンプで同期を取りながら、一方の経路が劣化・断絶した瞬間にもう一方のバッファへ自動的に切り替える。バッファサイズは「最速の経路と最も遅延した経路の差」を吸収できるだけの大きさに設計される。
重要なのは、この設計思想が「故障しないシステムを作る」ことを目指していない点だ。むしろ「故障は必ず起きる」という前提に立ち、故障が起きた瞬間に視聴者が気づかないレベルで切り替えを完了させることをゴールにしている。この考え方は、放送業界に限らず、金融取引システムや航空管制システムなど、ミッションクリティカルなインフラで広く採用されている冗長化の基本思想であり、Kubernetesの高可用性設計にもそのまま当てはまる。この思想をゼロから自前のクラスタに実装するのか、それとも標準搭載したKubo On-Premiseのような選択肢に乗るのかは、次のセクションで具体的に見ていく。
Kubernetesも同じ賭け方をしている — Pod分散配置とAZ冗長化の正体
Kubernetesの高可用性設計は、まさに「複製を用意し、壊れた方を切り捨てる」という同じ賭け方の上に成り立っている。放送センターが映像を赤・青の2経路に分けたように、Kubernetesはワークロードを複数のアベイラビリティゾーン(AZ)にまたがって分散配置する。
その中核を担うのがPod Topology Spread Constraintsだ。Kubernetes公式ドキュメントによれば、topologyKeyにtopology.kubernetes.io/zoneを指定し、maxSkew: 1を設定することで、ゾーン間のPod数の差を最小限に抑えながら自動的に分散配置できる。これは「複数の経路に同じ映像を流す」放送センターの発想と本質的に同じで、1つのゾーンが丸ごと落ちても、残りのゾーンにいるレプリカがサービスを継続する。
もう一つの重要な仕組みが**PodDisruptionBudget(PDB)**だ。Kubernetes公式のPDB設定ガイドでは、minAvailableやmaxUnavailableを指定することで、ノードのメンテナンスやアップグレードといった「意図的な中断」の際にも、最低限のレプリカ数を維持し続ける仕組みが解説されている。放送センターの受信バッファが経路切り替え中も映像を途切れさせないのと同様、PDBはクラスタ運用中のPodの可用性を保証する「保険」として機能する。
さらに、Pod affinity/anti-affinityに関する公式ドキュメントが示すように、requiredDuringSchedulingIgnoredDuringExecutionを使えば同一AZへのPodの集中配置を強制的に回避できる。クラウドベンダー側もこの思想を製品レベルで実装しており、Amazon EKSの可用性に関する公式ドキュメントによればEKSのコントロールプレーンは最低2つのAPIサーバーインスタンスと3つのetcdインスタンスを複数のAZにまたがって稼働させている。同様にGoogle Kubernetes Engineのリージョナルクラスタに関するドキュメントでも、コントロールプレーンとワーカーノードの両方を複数ゾーンに複製することで単一ゾーン障害への耐性を持たせる設計が標準機能として提供されている。
こうした仕組みを自前で正しく組み合わせるには、AZの構成理解・トポロジー設計・PDBの計算ロジックなど、決して小さくない専門知識が必要になる。ここが多くのインフラエンジニアがマネージドK8sサービスに可用性設計を任せたくなる理由でもある。K3sベースのKuboであれば、Rancher管理基盤によってマルチクラスタ・マルチAZの構成状況を可視化しながら、こうした冗長化設計を最初から組み込んだ状態で本格的なKubernetesクラスタを運用できる。
「予備を持つ」コストと、DIY運用が見落としがちな落とし穴
冗長化は「性能を上げる」ための投資ではなく、「保険をかける」ための投資だ。放送センターが平常時には使われない予備の経路にも常に帯域を割り当て続けているように、KubernetesのマルチAZ構成もAZ間のデータ転送コストや、常時起動している予備レプリカ分のコンピュートリソースを消費し続ける。これは通常運用時には「無駄」に見えるが、障害発生時にその価値が一気に顕在化する種類のコストだ。
そしてDIYでの冗長化構築には、見落としがちな落とし穴も多い。典型的な失敗は、トポロジー分散の設定を入れずにレプリカ数だけを増やしてしまうケースだ。この場合、複数のPodが偶然同じAZに集中して配置されてしまい、「レプリカは3つあるのに、1つのAZ障害で全滅する」という本末転倒な事態が起こり得る。PDBのmaxUnavailableを厳しく設定しすぎて、ノードのアップグレード自体が進まなくなるという別種の落とし穴も実務ではよく報告されている。
さらに根が深い問題として、2025年10月に発生した大規模クラウド障害の事例が挙げられる。マルチAZ構成の限界を分析した記事によれば、この障害はネットワーク負荷を監視するコアデータベース製品の不具合に端を発し、米国東部リージョン発で世界中に影響が波及した。記事は「複数のAZにリソースを分散していても、IAMやアカウント管理などリージョン中央集約型のサービスに依存している限り、リージョンレベルの障害の影響を受ける」と指摘している。つまり、マルチAZ設計はAZ単位のインフラ障害には強いが、その土台となるリージョン全体の制御システムの障害までは救えない。放送センターの二重化が「経路」の冗長化であって「放送センターそのもの」の冗長化ではないのと同じ構造の限界がここにある。
だからこそ、可用性設計は「一度組んだら終わり」ではなく、AZ構成・PDB設定・障害シナリオを継続的に見直す運用が欠かせない。この継続的な設計・監視・調整の負荷を自社だけで抱え込むか、可視化された管理画面で構成状況を常に把握できるKubo Cloudのようなマネージドサービスに委ねるかは、チームの規模とリソース配分次第で判断すべき選択肢になる。
まとめ
放送センターが同じ映像を2回送り、後から届いた方を黙って捨てるのは、無駄遣いではなく「壊れる前提」で設計された合理的な保険だ。Kubernetesのtopology spread constraints・PodDisruptionBudget・マルチAZスケジューリングも、同じ「複製を用意し、壊れた方を切り捨てる」という思想の上に成り立っている。
この設計を正しく組むには専門知識と継続的な運用コストが必要になる一方、K3sベースで本格的なKubernetesの冗長化機能を備えたKuboのようなマネージドサービスを使えば、可用性設計そのものを最初から任せることもできる。自前でゼロから組むか、実績のある設計に乗るか——まずはお問い合わせから、自社のワークロードに合った冗長化のかたちを相談してみてほしい。