[{"data":1,"prerenderedAt":314},["ShallowReactive",2],{"blog-ja-kubernetes-high-availability-broadcast-seamless-switching":3,"blog-related-ja-kubernetes-high-availability-broadcast-seamless-switching":260,"blog-ja-kubernetes-high-availability-broadcast-seamless-switching-alt":249},{"id":4,"title":5,"author":6,"body":7,"date":243,"description":244,"extension":245,"image":246,"locale":247,"meta":248,"navigation":249,"path":250,"seo":251,"stem":252,"tags":253,"__hash__":259},"blog\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching.md","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","Kubo Team",{"type":8,"value":9,"toc":234},"minimark",[10,15,23,31,42,46,52,65,74,87,91,97,104,130,147,172,179,183,189,192,198,207,215,218,221],[11,12,14],"h2",{"id":13},"切ったら壊れますと言われたのにあえて二重に送る理由","「切ったら壊れます」と言われたのに、あえて二重に送る理由",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"カメラ映像が赤経路・青経路の2系統に分岐し、受信側で先着パケットのみが採用される様子","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection01.webp",[16,24,25,26,30],{},"世界最大級のスポーツイベントを支える国際放送センターでは、すべてのカメラ映像が意図的に",[27,28,29],"strong",{},"同じ内容のまま2つの独立した経路で同時送信","されている。片方を「赤」、もう片方を「青」と呼び分け、まったく別のスイッチ・ルーターを経由させる。受信側は両方のストリームを受け取り、シーケンス番号とタイムスタンプが一致する2つのパケットのうち、先に到着した方だけを映像として採用し、後から届いた方はそのまま捨てる。",[16,32,33,34,41],{},"一見すると帯域の無駄遣いに思えるこの設計は、実は「失敗が許されないシステム」における標準的な作法だ。そしてこの発想は、Kubernetesの高可用性設計の根幹にある考え方と驚くほど一致している。本記事では、放送業界の冗長化手法を入り口に、Kubernetesがどのようにして「壊れても気づかせない」システムを実現しているのか、そして自前で構築する場合とマネージドな",[35,36,40],"a",{"href":37,"rel":38},"https:\u002F\u002Fkubo.hexabase.io\u002F",[39],"nofollow","Kubo","に任せる場合で何が変わるのかを解き明かす。",[11,43,45],{"id":44},"名前を知らなかっただけでこれは業界標準だった-seamless-protection-switching","名前を知らなかっただけで、これは業界標準だった — Seamless Protection Switching",[16,47,48],{},[19,49],{"alt":50,"src":51},"経路障害発生時に無瞬断で赤経路から青経路へ切り替わる様子の時系列図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection02.webp",[16,53,54,55,58,59,64],{},"この「二重送信・早着優先」という手法には正式名称がある。",[27,56,57],{},"SMPTE ST 2022-7","、通称Seamless Protection Switching(無瞬断保護切替)だ。",[35,60,63],{"href":61,"rel":62},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSMPTE_2022",[39],"SMPTE 2022規格の解説（Wikipedia）","によれば、ST 2022-7はRTPデータグラムレベルでの無瞬断な保護切替を規定した仕様であり、IP化が進む放送インフラの信頼性を担保する目的で策定された。",[16,66,67,68,73],{},"具体的な仕組みは、",[35,69,72],{"href":70,"rel":71},"https:\u002F\u002Fwww.elecard.com\u002Fpage\u002Fst2022-7",[39],"ST 2022-7の技術解説記事","が詳しい。送信側のスプリッターが同一ペイロードを持つRTPストリームを複製し、物理的に独立した2つのネットワークパスへ流す。受信側のスイッチャーは両方のパスから届くパケットをそれぞれ別バッファで受け取り、RTPヘッダのシーケンス番号とタイムスタンプで同期を取りながら、一方の経路が劣化・断絶した瞬間にもう一方のバッファへ自動的に切り替える。バッファサイズは「最速の経路と最も遅延した経路の差」を吸収できるだけの大きさに設計される。",[16,75,76,77,80,81,86],{},"重要なのは、この設計思想が「故障しないシステムを作る」ことを目指していない点だ。むしろ「故障は必ず起きる」という前提に立ち、故障が起きた瞬間に",[27,78,79],{},"視聴者が気づかないレベルで","切り替えを完了させることをゴールにしている。この考え方は、放送業界に限らず、金融取引システムや航空管制システムなど、ミッションクリティカルなインフラで広く採用されている冗長化の基本思想であり、Kubernetesの高可用性設計にもそのまま当てはまる。この思想をゼロから自前のクラスタに実装するのか、それとも標準搭載した",[35,82,85],{"href":83,"rel":84},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[39],"Kubo On-Premise","のような選択肢に乗るのかは、次のセクションで具体的に見ていく。",[11,88,90],{"id":89},"kubernetesも同じ賭け方をしている-pod分散配置とaz冗長化の正体","Kubernetesも同じ賭け方をしている — Pod分散配置とAZ冗長化の正体",[16,92,93],{},[19,94],{"alt":95,"src":96},"3つのアベイラビリティゾーンにPodレプリカが分散配置され、1ゾーン障害時も残り2ゾーンでサービス継続する構成図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection03.webp",[16,98,99,100,103],{},"Kubernetesの",[27,101,102],{},"高可用性設計","は、まさに「複製を用意し、壊れた方を切り捨てる」という同じ賭け方の上に成り立っている。放送センターが映像を赤・青の2経路に分けたように、Kubernetesはワークロードを複数のアベイラビリティゾーン(AZ)にまたがって分散配置する。",[16,105,106,107,110,111,116,117,121,122,125,126,129],{},"その中核を担うのが",[27,108,109],{},"Pod Topology Spread Constraints","だ。",[35,112,115],{"href":113,"rel":114},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Ftopology-spread-constraints\u002F",[39],"Kubernetes公式ドキュメント","によれば、",[118,119,120],"code",{},"topologyKey","に",[118,123,124],{},"topology.kubernetes.io\u002Fzone","を指定し、",[118,127,128],{},"maxSkew: 1","を設定することで、ゾーン間のPod数の差を最小限に抑えながら自動的に分散配置できる。これは「複数の経路に同じ映像を流す」放送センターの発想と本質的に同じで、1つのゾーンが丸ごと落ちても、残りのゾーンにいるレプリカがサービスを継続する。",[16,131,132,133,138,139,142,143,146],{},"もう一つの重要な仕組みが**PodDisruptionBudget(PDB)**だ。",[35,134,137],{"href":135,"rel":136},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fconfigure-pdb\u002F",[39],"Kubernetes公式のPDB設定ガイド","では、",[118,140,141],{},"minAvailable","や",[118,144,145],{},"maxUnavailable","を指定することで、ノードのメンテナンスやアップグレードといった「意図的な中断」の際にも、最低限のレプリカ数を維持し続ける仕組みが解説されている。放送センターの受信バッファが経路切り替え中も映像を途切れさせないのと同様、PDBはクラスタ運用中のPodの可用性を保証する「保険」として機能する。",[16,148,149,150,155,156,159,160,165,166,171],{},"さらに、",[35,151,154],{"href":152,"rel":153},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Fassign-pod-node\u002F",[39],"Pod affinity\u002Fanti-affinityに関する公式ドキュメント","が示すように、",[118,157,158],{},"requiredDuringSchedulingIgnoredDuringExecution","を使えば同一AZへのPodの集中配置を強制的に回避できる。クラウドベンダー側もこの思想を製品レベルで実装しており、",[35,161,164],{"href":162,"rel":163},"https:\u002F\u002Fdocs.aws.amazon.com\u002Feks\u002Flatest\u002Fuserguide\u002Fdisaster-recovery-resiliency.html",[39],"Amazon EKSの可用性に関する公式ドキュメント","によればEKSのコントロールプレーンは最低2つのAPIサーバーインスタンスと3つのetcdインスタンスを複数のAZにまたがって稼働させている。同様に",[35,167,170],{"href":168,"rel":169},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fregional-clusters",[39],"Google Kubernetes Engineのリージョナルクラスタに関するドキュメント","でも、コントロールプレーンとワーカーノードの両方を複数ゾーンに複製することで単一ゾーン障害への耐性を持たせる設計が標準機能として提供されている。",[16,173,174,175,178],{},"こうした仕組みを自前で正しく組み合わせるには、AZの構成理解・トポロジー設計・PDBの計算ロジックなど、決して小さくない専門知識が必要になる。ここが多くのインフラエンジニアがマネージドK8sサービスに可用性設計を任せたくなる理由でもある。K3sベースの",[35,176,40],{"href":37,"rel":177},[39],"であれば、Rancher管理基盤によってマルチクラスタ・マルチAZの構成状況を可視化しながら、こうした冗長化設計を最初から組み込んだ状態で本格的なKubernetesクラスタを運用できる。",[11,180,182],{"id":181},"予備を持つコストとdiy運用が見落としがちな落とし穴","「予備を持つ」コストと、DIY運用が見落としがちな落とし穴",[16,184,185],{},[19,186],{"alt":187,"src":188},"正しいトポロジー分散設定とゾーン偏在による誤設定を対比する比較図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Fsection04.webp",[16,190,191],{},"冗長化は「性能を上げる」ための投資ではなく、「保険をかける」ための投資だ。放送センターが平常時には使われない予備の経路にも常に帯域を割り当て続けているように、KubernetesのマルチAZ構成もAZ間のデータ転送コストや、常時起動している予備レプリカ分のコンピュートリソースを消費し続ける。これは通常運用時には「無駄」に見えるが、障害発生時にその価値が一気に顕在化する種類のコストだ。",[16,193,194,195,197],{},"そしてDIYでの冗長化構築には、見落としがちな落とし穴も多い。典型的な失敗は、トポロジー分散の設定を入れずにレプリカ数だけを増やしてしまうケースだ。この場合、複数のPodが偶然同じAZに集中して配置されてしまい、「レプリカは3つあるのに、1つのAZ障害で全滅する」という本末転倒な事態が起こり得る。PDBの",[118,196,145],{},"を厳しく設定しすぎて、ノードのアップグレード自体が進まなくなるという別種の落とし穴も実務ではよく報告されている。",[16,199,200,201,206],{},"さらに根が深い問題として、2025年10月に発生した大規模クラウド障害の事例が挙げられる。",[35,202,205],{"href":203,"rel":204},"https:\u002F\u002Fwww.loadbalancer.org\u002Fblog\u002Fmulti-az-resilience\u002F",[39],"マルチAZ構成の限界を分析した記事","によれば、この障害はネットワーク負荷を監視するコアデータベース製品の不具合に端を発し、米国東部リージョン発で世界中に影響が波及した。記事は「複数のAZにリソースを分散していても、IAMやアカウント管理などリージョン中央集約型のサービスに依存している限り、リージョンレベルの障害の影響を受ける」と指摘している。つまり、マルチAZ設計はAZ単位のインフラ障害には強いが、その土台となるリージョン全体の制御システムの障害までは救えない。放送センターの二重化が「経路」の冗長化であって「放送センターそのもの」の冗長化ではないのと同じ構造の限界がここにある。",[16,208,209,210,214],{},"だからこそ、可用性設計は「一度組んだら終わり」ではなく、AZ構成・PDB設定・障害シナリオを継続的に見直す運用が欠かせない。この継続的な設計・監視・調整の負荷を自社だけで抱え込むか、可視化された管理画面で構成状況を常に把握できる",[35,211,213],{"href":37,"rel":212},[39],"Kubo Cloud","のようなマネージドサービスに委ねるかは、チームの規模とリソース配分次第で判断すべき選択肢になる。",[11,216,217],{"id":217},"まとめ",[16,219,220],{},"放送センターが同じ映像を2回送り、後から届いた方を黙って捨てるのは、無駄遣いではなく「壊れる前提」で設計された合理的な保険だ。Kubernetesのtopology spread constraints・PodDisruptionBudget・マルチAZスケジューリングも、同じ「複製を用意し、壊れた方を切り捨てる」という思想の上に成り立っている。",[16,222,223,224,227,228,233],{},"この設計を正しく組むには専門知識と継続的な運用コストが必要になる一方、K3sベースで本格的なKubernetesの冗長化機能を備えた",[35,225,40],{"href":37,"rel":226},[39],"のようなマネージドサービスを使えば、可用性設計そのものを最初から任せることもできる。自前でゼロから組むか、実績のある設計に乗るか——まずは",[35,229,232],{"href":230,"rel":231},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[39],"お問い合わせ","から、自社のワークロードに合った冗長化のかたちを相談してみてほしい。",{"title":235,"searchDepth":236,"depth":236,"links":237},"",2,[238,239,240,241,242],{"id":13,"depth":236,"text":14},{"id":44,"depth":236,"text":45},{"id":89,"depth":236,"text":90},{"id":181,"depth":236,"text":182},{"id":217,"depth":236,"text":217},"2026-08-05","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-high-availability-broadcast-seamless-switching\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching",{"title":5,"description":244},"blog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching",[254,255,256,257,258],"k3s","kubernetes","high-availability","multi-az","sre","DZb24oB-NYytVcXQIQSly0U81BokChCwfTckBdAYiOw",[261,269,279,288,297,305],{"path":262,"title":263,"description":264,"date":265,"tags":266},"\u002Fblog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design","FIFAワールドカップの中継は、なぜ絶対に途切れないのか。放送業界の二重伝送に学ぶKubernetesの本当の高可用性設計","Kubernetesの高可用性は「レプリカを増やす」だけでは実現しない。放送業界のSMPTE ST 2022-7二重伝送技術を手がかりに、Topology Spread ConstraintsとマルチAZ設計の本質を解説する。","2026-07-20",[255,254,256,267,258,268],"topology-spread-constraints","managed-kubernetes",{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[254,255,275,276,277,278],"container-security","image-scanning","sbom","supply-chain-security",{"path":280,"title":281,"description":282,"date":283,"tags":284},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[254,255,285,286,287],"harbor","container-registry","cncf",{"path":289,"title":290,"description":291,"date":292,"tags":293},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[254,255,294,268,295,296],"cost-optimization","aks","finops",{"path":298,"title":299,"description":300,"date":301,"tags":302},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[254,255,268,303,304],"devops","platform-engineering",{"path":306,"title":307,"description":308,"date":309,"tags":310},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[254,255,311,312,313],"opentelemetry","observability","distributed-tracing",1787649512828]