[{"data":1,"prerenderedAt":307},["ShallowReactive",2],{"blog-ja-broadcast-redundancy-kubernetes-high-availability-design":3,"blog-related-ja-broadcast-redundancy-kubernetes-high-availability-design":258,"blog-ja-broadcast-redundancy-kubernetes-high-availability-design-alt":246},{"id":4,"title":5,"author":6,"body":7,"date":240,"description":241,"extension":242,"image":243,"locale":244,"meta":245,"navigation":246,"path":247,"seo":248,"stem":249,"tags":250,"__hash__":257},"blog\u002Fblog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design.md","FIFAワールドカップの中継は、なぜ絶対に途切れないのか。放送業界の二重伝送に学ぶKubernetesの本当の高可用性設計","Kubo Team",{"type":8,"value":9,"toc":227},"minimark",[10,14,19,26,29,39,42,45,49,55,63,66,74,77,81,87,90,95,136,152,156,165,180,184,190,193,202,205,209,212,220],[11,12,13],"p",{},"Kubernetes 高可用性を「レプリカを増やせば安心」と考えていないだろうか。放送業界がワールドカップ中継で実践している\"二重伝送\"の発想を手がかりに、Topology Spread ConstraintsやマルチAZ設計が本当に意味することを解き明かす。",[15,16,18],"h2",{"id":17},"_1-なぜワールドカップの映像は一度も止まらないのか","1. なぜワールドカップの映像は一度も止まらないのか",[11,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fbroadcast-redundancy-kubernetes-high-availability-design\u002Fsection01.webp",[11,27,28],{},"サッカーワールドカップのような世界規模の中継では、複数のスタジアムに設置された数十台のカメラの映像が、国際放送センターへとリアルタイムで集約される。この伝送の裏側で使われているのが、IPネットワーク上で映像を冗長化する国際規格「SMPTE ST 2022-7」だ。",[11,30,31,38],{},[32,33,37],"a",{"href":34,"rel":35},"https:\u002F\u002Fwww.elecard.com\u002Fpage\u002Fst2022-7",[36],"nofollow","Elecardの技術解説","によると、この規格は送信側で同一のRTPストリームを複製し、完全に独立した2つの経路へ同時に送り出す。受信側はシーケンス番号とタイムスタンプで両ストリームを突き合わせ、片方にパケットロスや遅延が発生しても、瞬時にもう一方から補完する。切り替えは「知覚できないレベル」で行われ、視聴者はもちろん、現場のオペレーターすら異常に気づかないことも珍しくない。",[11,40,41],{},"ここで注目したいのは、この二重化が単に「ケーブルを2本引く」ことではない点だ。スイッチやルーター、電源系統まで含めて経路そのものを完全に分離することで初めて、片方のインフラ全体が丸ごと落ちても中継が続く、という信頼性が成立する。",[11,43,44],{},"Kubernetesの世界で「高可用性」という言葉を使うとき、多くのエンジニアが思い浮かべるのは「レプリカを複数用意する」ことだ。しかし放送業界が実践しているのは、それよりもずっと厳格な基準——止まったことにすら気づかせないレベルの冗長化である。この違いを理解することが、Kubernetesの高可用性設計を見直す第一歩になる。",[15,46,48],{"id":47},"_2-レプリカ3つで高可用性は思い込みにすぎない","2. 「レプリカ3つ」で高可用性、は思い込みにすぎない",[11,50,51],{},[22,52],{"alt":53,"src":54},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fbroadcast-redundancy-kubernetes-high-availability-design\u002Fsection02.webp",[11,56,57,62],{},[32,58,61],{"href":59,"rel":60},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2026\u002F01\u002F20\u002Fkubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey\u002F",[36],"CNCFの2026年次調査","によれば、コンテナ利用企業のうち82%が本番環境でKubernetesを運用している。裏を返せば、それだけ多くの本番システムのKubernetes 高可用性設計が、実は不十分なまま稼働している可能性があるということだ。",[11,64,65],{},"Kubernetesのデフォルトスケジューラは、明示的な制約を設定しない限り、リソースに空きがあるノードへ機械的にPodを配置する。その結果、「レプリカ3つ」という数字だけを見て安心していても、実際には同一ノード、あるいは同一アベイラビリティゾーン(AZ)に集中配置されてしまうケースが起こりうる。そのゾーンで電源障害やネットワーク分断が発生すれば、3つのレプリカが同時に落ちる。",[11,67,68,73],{},[32,69,72],{"href":70,"rel":71},"https:\u002F\u002Fitic-corp.com\u002Fitic-reports-surveys\u002F",[36],"ITICが2024年に実施した企業調査","では、従業員1,000人を超える大企業の97%が「年間平均で1時間のダウンタイムが10万ドル超のコストを生む」と回答しており、90%の企業では1時間あたり30万ドルを超えると報告されている。「レプリカを増やしたから大丈夫」という思い込みのまま本番運用を続けるリスクは、決して小さくない。",[11,75,76],{},"放送業界が経路そのものを分離するように、Kubernetesでも「どこに配置されているか」を制御しない限り、本当の意味での高可用性は実現しない。",[15,78,80],{"id":79},"_3-放送業界の経路分離思想をkubernetesに翻訳する","3. 放送業界の「経路分離」思想をKubernetesに翻訳する",[11,82,83],{},[22,84],{"alt":85,"src":86},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fbroadcast-redundancy-kubernetes-high-availability-design\u002Fsection03.webp",[11,88,89],{},"放送業界の「経路分離」に相当する仕組みは、Kubernetesにもすでに用意されている。",[91,92,94],"h3",{"id":93},"topology-spread-constraints-ゾーンをまたいだ経路分離","Topology Spread Constraints — ゾーンをまたいだ経路分離",[11,96,97,102,103,107,108,111,112,115,116,119,120,123,124,127,128,131,132,135],{},[32,98,101],{"href":99,"rel":100},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fscheduling-eviction\u002Ftopology-spread-constraints\u002F",[36],"Kubernetes公式ドキュメント","によれば、",[104,105,106],"code",{},"topologySpreadConstraints","は",[104,109,110],{},"maxSkew","(ゾーン間でのPod数の許容偏差)、",[104,113,114],{},"topologyKey","(ノード単位なら",[104,117,118],{},"kubernetes.io\u002Fhostname","、ゾーン単位なら",[104,121,122],{},"topology.kubernetes.io\u002Fzone",")、",[104,125,126],{},"whenUnsatisfiable","(制約を満たせない場合に配置を拒否する",[104,129,130],{},"DoNotSchedule","か、妥協して配置する",[104,133,134],{},"ScheduleAnyway","か)の3要素で構成される。",[11,137,138,143,144,147,148,151],{},[32,139,142],{"href":140,"rel":141},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fha-resiliency-amazon-eks-apps\u002Fspread-workloads.html",[36],"AWSの実践ガイド","では、",[104,145,146],{},"maxSkew: 1","かつ",[104,149,150],{},"topologyKey: topology.kubernetes.io\u002Fzone","を指定し、レプリカを複数のAZへ均等に分散させる構成が推奨されている。これはまさに、放送業界が同一ストリームを独立した経路へ振り分ける発想と同じだ。",[91,153,155],{"id":154},"pod-anti-affinityとpoddisruptionbudget-二重の安全網","Pod Anti-AffinityとPodDisruptionBudget — 二重の安全網",[11,157,158,159,164],{},"Topology Spread Constraintsに加え、同一ノードへの集中配置を避けるPod Anti-Affinityを組み合わせることで、ノード単位・ゾーン単位の両方で分散を担保できる。さらに",[32,160,163],{"href":161,"rel":162},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fpods\u002Fdisruptions\u002F",[36],"Kubernetes公式のPodDisruptionBudget解説","にある通り、ノードのメンテナンスやクラスタアップグレードといった「意図的な停止(voluntary disruption)」に対しては、最低限稼働させるPod数をPodDisruptionBudgetで保証できる。一方、ハードウェア故障やカーネルパニックのような「意図しない停止(involuntary disruption)」はPodDisruptionBudgetでは防げず、Topology Spread Constraintsによる事前の分散配置でしか対処できない。この2つは役割が異なるため、両方を組み合わせて初めて放送業界レベルの冗長性に近づく。",[11,166,167,168,173,174,179],{},"K3sは",[32,169,172],{"href":170,"rel":171},"https:\u002F\u002Fdocs.k3s.io\u002F",[36],"CNCF認定の軽量Kubernetesディストリビューション","であり、これらの標準機能をそのまま利用できる。ただし、マルチAZ・マルチクラスタ構成を自前で設計・運用するには、ネットワーク設計からモニタリング体制まで相応の専任リソースが必要になる。",[32,175,178],{"href":176,"rel":177},"https:\u002F\u002Fkubo.hexabase.io\u002F",[36],"Kubo","はK3sベースでありながらRancher管理基盤による可視化を標準搭載しており、こうした分散配置の状態をクラスタ横断で確認しながら運用できる。",[15,181,183],{"id":182},"_4-本当に切り替わるかを試さないha設計は設計ではない","4. 「本当に切り替わるか」を試さないHA設計は設計ではない",[11,185,186],{},[22,187],{"alt":188,"src":189},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fbroadcast-redundancy-kubernetes-high-availability-design\u002Fsection04.webp",[11,191,192],{},"放送の現場では、本番前に必ずフェイルオーバーの動作確認が行われる。片方の経路をあえて切断し、実際に「気づかれずに」切り替わるかをテストして初めて、本番投入の判断が下される。",[11,194,195,196,201],{},"Kubernetesの高可用性設計でも同じ検証が欠かせない。",[32,197,200],{"href":198,"rel":199},"https:\u002F\u002Fchaos-mesh.org\u002F",[36],"CNCFのIncubatingプロジェクトであるChaos Mesh","は、Pod障害・ネットワーク遅延・パケットロスといった実際の障害をKubernetesクラスタ上で意図的に注入できるツールだ。Topology Spread ConstraintsやPodDisruptionBudgetを設定しただけで満足せず、実際にゾーン障害を模したPodChaos・NetworkChaosを流し込み、レプリカが本当に生き残るか、サービスが継続するかを検証して初めて、設計は「本当の高可用性」と呼べる状態になる。",[11,203,204],{},"設定を書いて終わりにするか、実際に壊してみて確認するか。この一手間の差が、放送業界が体現する「気づかせないレベルの信頼性」とKubernetesクラスタとの間にある距離を埋める。",[15,206,208],{"id":207},"_5-まとめ-気づかせないレベルの可用性をどう実現するか","5. まとめ — 「気づかせない」レベルの可用性をどう実現するか",[11,210,211],{},"放送業界の二重伝送が教えてくれるのは、高可用性とは「壊れても動く」ことではなく「壊れたことに気づかせない」ことだという発想の転換だ。Kubernetesにおいても、レプリカ数を増やすだけでなく、Topology Spread ConstraintsとPod Anti-Affinityで配置そのものを分散させ、PodDisruptionBudgetで意図的な停止から守り、Chaos Mesh等で実際に壊して検証する。この一連の設計を積み重ねて初めて、放送業界レベルの信頼性に近づける。",[11,213,214,215,219],{},"とはいえ、マルチAZ・マルチクラスタの分散配置を自前で設計し、日々の可視化・検証まで運用し続けるのは決して軽い負荷ではない。",[32,216,218],{"href":176,"rel":217},[36],"Kubo Cloud","なら、K3sベースの本格的なKubernetes機能をそのままに、Rancher管理基盤によるマルチクラスタの可視化を標準搭載した状態で、月額48,000円〜からこうした高可用性構成を組み始められる。",[11,221,222,223,226],{},"まずは自社クラスタのTopology Spread Constraints設定を見直すところから始めてもいいし、ゼロからマルチAZ構成を組むなら",[32,224,178],{"href":176,"rel":225},[36],"で始めてみるのもいい。「気づかせないレベルの可用性」は、思い込みではなく設計と検証の積み重ねでしか手に入らない。",{"title":228,"searchDepth":229,"depth":229,"links":230},"",2,[231,232,233,238,239],{"id":17,"depth":229,"text":18},{"id":47,"depth":229,"text":48},{"id":79,"depth":229,"text":80,"children":234},[235,237],{"id":93,"depth":236,"text":94},3,{"id":154,"depth":236,"text":155},{"id":182,"depth":229,"text":183},{"id":207,"depth":229,"text":208},"2026-07-20","Kubernetesの高可用性は「レプリカを増やす」だけでは実現しない。放送業界のSMPTE ST 2022-7二重伝送技術を手がかりに、Topology Spread ConstraintsとマルチAZ設計の本質を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fbroadcast-redundancy-kubernetes-high-availability-design\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design",{"title":5,"description":241},"blog\u002Fja\u002Fbroadcast-redundancy-kubernetes-high-availability-design",[251,252,253,254,255,256],"kubernetes","k3s","high-availability","topology-spread-constraints","sre","managed-kubernetes","IG1PztPBhMnchO3fVc2Oe0pD_n-RT438q-njFL-v_8o",[259,266,274,282,291,299],{"path":260,"title":261,"description":262,"date":263,"tags":264},"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","2026-08-05",[252,251,253,265,255],"multi-az",{"path":267,"title":268,"description":269,"date":270,"tags":271},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[252,251,272,273,256],"kubevirt","networking",{"path":275,"title":276,"description":277,"date":278,"tags":279},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[252,251,280,281,256],"resource-management","capacity-planning",{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[251,252,288,289,290,256],"microservices","service-mesh","latency",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[251,252,297,298,256],"ai-inference","cncf",{"path":300,"title":301,"description":302,"date":303,"tags":304},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[252,251,305,306,256],"edge-computing","hybrid-cluster",1786354647786]