The Utopia Toneを支えるKubernetes基盤

The Utopia Toneを支えるKubernetes基盤

Tags
Kubernetes
Linux
Network
DJ
Container
Server
The Utopia Tone
Published
Author
DDlia
Description
映像伝送も照明制御も全てKubernetesに載せましょう!
この記事は,TUT Advent Calendar 2025 10日目 の記事です.昨日は,ニッコーくんの「美味しいチャイを作るチャイよ〜^^」でした.
% ここに記事を貼る

はじめに

音楽技術部4年目の小野寺です。B1(2022年)の10月頃に音楽技術部の前身の総合文化部音楽技術部門に入部し、以来技術班として活動していました。
音楽技術部技術班では,技科大祭でネットワーク・サーバ基盤の運用を行っており,この記事ではその再構築作業をご紹介します.
 
(技科大祭でのテクノ部ブース入口では概要を展示していました!)
 
💡
おことわり:前提知識がなくても読めるように厳密な言葉の定義とは異なる説明をしている部分があるかもしれないですが,温かい目で見てください.
 

宣伝

以前に書いたTechnoTUT関連の記事を置いておきます.
 
去年の記事
一昨年の記事
 

音楽技術部のネットワーク・サーバ基盤とは?

音楽技術部では「The Utopia Tone」というDJイベントを学内のコモンズ1という場所で不定期にやっています.
「The Utopia Tone」を開催するにあたって前日の夜中にコモンズ1を魔改造するわけですが,当然全てを自分たちで設営する必要があります.
 
びふぉー
notion image
notion image
あふたー
notion image
notion image
暗幕を取り付けて,ステージを作って,DJシステムを設置して,照明を取り付けて,プロジェクタやディスプレイを取り付けて,カメラもたくさん置いて,ミキサーで音を調整してというのを一夜の間に行います.
 
お客さんから見えるところにあるのは,DJシステム・スピーカー・照明・スクリーン・ディスプレイあたりですが,暗幕の裏側,通称「Techブース」にはこれらを制御したり連携したりする装置がたくさん置いてあります.
 
Techブースの一部(メディアブース)
Techブースの一部(メディアブース)
 
Techブースは,「照明」・「メディア」・「ネットワーク」の大きく3つの分野から構成されています.

照明

同期のSくんがTouchDesignerで開発した照明制御ソフトウェアで,制御信号をLANケーブル・光ファイバー(IPネットワーク)を介してサーバに送り,サーバで別の制御信号に変換してライトの色や明るさを変えています.ムービングライトという首が回るライトには加えて回転角度とかを伝えてます.
照明機器の接続構成 by @KerorinNF222
照明機器の接続構成 by @KerorinNF222
加えて,LANケーブル・光ファイバー(IPネットワーク)でDJシステムからサーバを介してBPM(曲のテンポ)を引っこ抜いてきたり,DJシステムから出ている音を取ってきて音声信号の解析をすることで,自動で色情報などを生成し自動制御ができるようになっているみたいです.実際に技科大祭では無人稼働をしているときもありました.すごい!

こちら開発しました(してます) touchdesigner上でスペクトラムのデータで色を取得し、色んな手段で取得したBPM設定で拍数ごとの動作を制御しています

DDlia
DDlia
@ddLi907

現在の #ユートーン の照明は自動制御モードでお届けしております

Image
10
Reply

メディア

会場内にカメラを置いていろいろな画角で撮った映像や,DJ裏の映像を集約し,リアルタイムで映像を加工しながら会場内のスクリーン・DJブースのブースディスプレイに送ったり,録画を行ったりしています.映像のやりとりには,HDMIといった映像ケーブルを一切使っておらず,LANケーブル・光ファイバー(IPネットワーク)のみでやっています.
 
どうしてLANケーブル・光ファイバー(IPネットワーク)で映像をやりとりするかというと,安く作れるからですね.テレビ局とかで使っているような映像機材は数万・数十万・数百万円ととんでもなく高価ですが,中古のネットワーク機器は1台3000円程度で買うことができます.
ケーブルもLANケーブルは安価で100mまで通信できますが,長距離のHDMIケーブルは高価です. 同じ30mのケーブルでもLANケーブルは1700円,HDMIケーブルは21600円します.
 
某LEDの先輩から「機材が高価なら自分たちで自作すればいいじゃない!」という教育を受けているので,LANケーブル・光ファイバー(IPネットワーク)で映像をやりとりするためのあれこれも用意しています.
8万円くらいの機材と似たようなことを余っているPCを活用して25~110円ほど(DVD代)でできるようになっています.

ネットワーク基盤とコンピュート基盤

照明・メディアのところで「LANケーブル・光ファイバー(IPネットワーク)」というのがたびたび出てきたと思いますが,この本体の部分がネットワーク基盤です.会場内の機器同士が相互にお話しして連携できるようにします.
各機器がお話しし合えることで,照明の例のように自動制御ができるようになりますし,VJさんのBPM(テンポ)を自動操作してお助けすることもできたり,PAさんのiPadとミキサーの会話をできるようにしたり,メディアブースで出てきた映像のやりとりも安価にできるようになります.
いろいろな機器が連携をとることで演出が一体となり,お客さんはより没入感のある音楽体験を楽しめるようになります.
ミキサー(一番上)とネットワーク装置の一部
ミキサー(一番上)とネットワーク装置の一部
今年の春に新規導入した装置たち
今年の春に新規導入した装置たち
コンピュート基盤は,このネットワーク基盤に接続されていて,会場内の機器に様々な情報を提供します.
DJシステムから曲情報(BPM・曲名・アーティスト名・波形など)を引っこ抜いてきたり,照明信号の変換,カメラ映像の中継,伝送映像の接続管理,故障機器がないかの監視,さらにはネットワーク基盤の基盤の部分(名前解決,DNS)をやっています.部員が開発したアプリケーションを動かすこともできます.
notion image
notion image
ラックの上に載っているのは東京・秋葉原にある神田明神のITお守りです.

ネットワーク基盤とコンピュート基盤の再構築

技科大祭に向けて9月末にネットワーク・サーバ装置の大規模な再構築作業を行っていました.

何を変えたの?

一言で言えばコンピュート基盤を全てKubernetesに移行しました!
 
よくわからないですね.
 
もともとはサーバが2台あって,それぞれ別々の方式(Proxmox VEとKubernetes)で動いていました.それを一度全て破壊して,サーバを1台増やして,3台全てを同じものに統一してしまおうという計画です.ついでにせっかく再構築をするのでネットワークも全て破壊して,興味ある人集めて作り直そうというのをやりました.
 

作業の様子

部室での作業はB1・B3の若人たちと8人くらいで3日かけて行いました. Day 1はオンラインで集まってネットワークトポロジの設計,Day 2は機器の分解メンテナンスから入って,ネットワーク機器へのコマンド投入,サーバへのLinuxのインストールをやりました. Day 3はKubernetesのインストール・クラスタリングとこれまで動かしていたアプリケーションのクラスタへの投入をやって,後日少し大変な既存機能の移行を私と部員Hとでやってました.
 
Day1: 設計(オンライン)
notion image
 
Day 2: 機器を取り外して,
notion image
 
ラック整備
notion image
 
そして分解清掃 (これはレイヤ3スイッチの内部)
notion image
ごっつい電源と最近話題のMicronのメモリが載っていますね
 
組み立て完了
notion image
 
設定投入(イメージ)
写真を撮っていなかったので,今年3月の写真で...
写真を撮っていなかったので,今年3月の写真で...
コマンドを投入していって,ネットワークを分けたり(VLANを切ったり),住所(IPアドレス)を振って疎通がとれることを確認してます.あとは動的経路制御(RIP・BGP)とかをやってます. (豊橋駅から栄駅に行くのに,「名古屋方面の列車に乗らないといけない」という情報を知っていないと静岡方面・飯田方面にとりあえず行ってみるかその場で床になるかで迷子になりますよね.それを名古屋駅や金山駅が「栄駅はうちの近くにあるよ〜」と豊橋駅にお話しして,東海道線を使うか新幹線を使うか名鉄名古屋本線を使うか,または名古屋駅と金山駅のどちらで乗り換えるのが良いのかを,最適経路を計算して勝手に案内してくれる,みたいなことをやっています.仮に車が橋桁にぶつかって運転を見合わせても,別の迂回経路に切り替わります.)
 
コマンドと聞くと難しそうに聞こえるかもしれないですが,日本語のコマンドリファレンスを読みながらポチポチ入れていくので,3系必修の講義でやるIPネットワークの基礎知識が分かれば難しくないです.難しい内容についてはちゃんと解説もしてくれています.
 
最終的に出来上がったネットワークを図に起こしたのがこれです.
notion image
notion image
 
Day 3: サーバーの構築(写真なし)
Day 2の終わりにDebianをインストールしておいた3台のサーバにKubernetesを入れていきます.KubernetesはGoogleが開発したコンテナオーケストレーションツールで,全世界で使われています.身近だとイオンとかPayPayとかメルカリとか.
プロダクショングレードのコンテナ管理基盤
KubernetesはK8sとしても知られており、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。 管理や検出を容易にするため、アプリケーションを論理的な単位に分割し、コンテナをグルーピングします。KubernetesはGoogleでの15年にわたる経験を基に構築されており、コミュニティのアイディアや慣習との最善の組み合わせを取っています。 惑星規模のスケーリング Googleが週に何十億ものコンテナを実行することを可能としているのと同じ原則に沿ってデザインされているため、Kubernetesは運用チームの人数を増やさずに規模を拡大することができます。 いつまでも使える ローカルのテストであろうとグローバル企業での開発であろうと、Kubernetesの柔軟性はあなたの要求がどれだけ複雑になろうとも問題なく、矛盾無く、簡単にアプリケーションを提供できます。 どこでもK8sを実行できる Kubernetesはオープンソースであるため、オンプレミスやパブリッククラウド、それらのハイブリッドなどの利点を自由に得ることができ、簡単に移行することができます。 Kubernetesをダウンロードするには、ダウンロードセクションを訪れてください。 150以上のマイクロサービスをKubernetes上に移行する挑戦 By Sarah Wells, Technical Director for Operations and Reliability, Financial Times ビデオを見る 今後のKubeCon + CloudNativeConイベントに参加する India(ハイデラバード、8月6日〜7日) North America(アトランタ、11月10日〜13日) Europe(アムステルダム、2026年3月23日〜26日) Kubernetesの機能 自動化されたロールアウトとロールバック Kubernetesはアプリケーションや設定への変更を段階的に行い、アプリケーションの状態を監視しながら、全てのインスタンスが同時停止しないようにします。更新に問題が起きたとき、Kubernetesは変更のロールバックを行います。進化を続けるDeploymentのエコシステムを活用してください。 サービスディスカバリーと負荷分散 Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。 ストレージオーケストレーション ローカルストレージやGCP、AWSなどのパブリッククラウドプロバイダー、もしくはNFS、iSCSI、Gluster、Ceph、Cinder、Flockerのようなネットワークストレージシステムの中から選択されたものを自動的にマウントします。 Secretと構成管理 Secretやアプリケーションの構成情報を、イメージの再ビルドや機密情報を晒すことなくデプロイ、更新します 自動ビンパッキング 可用性を犠牲にすることなく、リソース要件やその他の制約に基づいてコンテナを自動的に配置します。リソース利用率の向上と、リソースの節約のために、クリティカルなワークロードとベストエフォートなワークロードを混在させます。 バッチ実行 サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを置き換えることもできます。 自己修復 Kubernetesは、クラッシュしたコンテナを再起動し、必要に応じてPod全体を置き換え、広範な障害に対してストレージを再アタッチし、ノードレベルでも自己修復を行うためにノードオートスケーラーと統合することができます。 IPv4/IPv6デュアルスタック IPv4およびIPv6のアドレスをPodとServiceに割り当てる 水平スケーリング シンプルなコマンドやUIを使って、あるいはCPU使用率に基づいて自動的に、アプリケーションをスケールアップやスケールダウンします。 拡張性を考慮した設計 アップストリームのソースコードを変更することなく、Kubernetesクラスターに機能を追加できます。 ケーススタディ "私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。 " 続きを読む
プロダクショングレードのコンテナ管理基盤
 
 
「コンテナ」というのは,アプリケーションとそれを動かす環境をセットにしたものです.Dockerが良く知られていますね.
サーバ仮想化技術とコンテナ技術の違い: コンテナサービス | NEC
仮想化技術には、コンテナ技術のほか、サーバ仮想化技術があります。短期間でのアプリケーション開発とリリース、フィードバックによる継続的な開発と運用など、DXに対応した開発に求められるシステム環境の構築は、サーバ仮想化技術でも可能です。実際、サーバ仮想化技術を活用してお客さまのビジネスニーズに合わせたアプリケーション開発とシステム運用を実施する例は多数あります。 サーバ仮想化技術は、サーバ上で仮想化ソフトウェア(ハイパーバイザー)を実行し、その上の仮想マシン(VM)ごとにゲストOSやアプリケーション、ミドルウェアなどのアプリケーション実行環境を設定・管理します。仮想マシン上のアプリケーションを実行する際、ゲストOSから起動するので時間がかかることや、複数のゲストOSがCPUやメモリー、ストレージなどのサーバ資源を利用するため、リソースの無駄が生じる場合もあります。 それに対し、コンテナ技術は、コンテナ管理ソフトウェアを実行し、サーバ上のOSを仮想化します。アプリケーションは、コンテナ管理ソフトウェアによって、コンテナごとに管理されるため、スピーディな起動が可能です。 また、コンテナ技術では、コンテナ管理ソフトウェアによって、サーバ上のOSが仮想化されるため、アプリケーションの実行環境を管理する際、OSの管理が不要になります。つまり、アプリケーションの実行環境は、ミドルウェアのみを管理すればいいというわけです。また、サーバ資源は、1つのOSが利用するのでCPUやメモリーなどの負荷が小さく、リソースの無駄が少ないといったメリットがあります。
Kubernetesでは複数のコンテナを複数のサーバで自動的に管理してくれます.自動的に管理してくれると言っても,どんなことができるの?となると思うのでいくつか紹介します.
  • 自動配置(スケジューリング):複数のサーバのうち,どのサーバにどのアプリケーションを配置するかを自動で決定します.サーバ使用状況を見て最適なものを選びます.
  • 自己回復(セルフヒーリング):異常なアプリケーションを自動的に再起動して直そうとします.
  • 負荷分散(オートスケーリング):負荷に応じて自動的にアプリケーションを増減します.
Kuberenetesには「このアプリケーションはこの状態であるべき!」と宣言的に設定を投入し,自動配置・自己回復・負荷分散をしながら自動で維持してもらいます.例えば,エアコンの設定温度を23度に設定すると,エアコンは室温を測定して,暑ければ冷やし,寒ければ温めて23度を維持しようとします.それと同じように,Kubernetesは「このアプリケーションは3個動いているべき」と設定すると,サーバの状態を監視して,何らかの原因でアプリケーションが2個に減っていたら自動で1個増やして3個に戻します.
他にもサーバ・ネットワークの状態をコードで管理できたり,ローリングアップデートといってアプリケーションが使えなくなる時間なしにアップデートをかけれたり(TechnoTUTの伝統芸で本番中に開発してることもあるので結構重要!)もできますが,ここでは省略します.
 
TechnoTUTでこのKubernetesを使うのですが,おそらくDJイベントでKubernetesクラスタを運用するのは世界初の試み(たぶんね)です.世界初,いい響きだよね.
 
構築で踏んだ手順は以下にまとめています.そこのA.I.Techのなんとかすしろーるさん,ぜひ!
 
3台のサーバをクラスタリングといって,合体してひとまとまりにします. このひとまとまりのことをクラスタと呼びます.クラスタは,それぞれがお話しして協力し合いながらアプリケーションを動かしていきます.
コンピュータが相互にお話しするにあたって,一般にホスト名という名前を割り当てる必要があり,ここで3台のサーバの名前を決めなければならないのですが,B1・B3の若人たち(部員S,部員K)が良い感じにつけてくれました.技科大祭でも展示してたね.
notion image
notion image
 

トラブル①:サーバの突然死

notion image
後日,設定を流し込んでいると,突然通信が切れてその後全く接続できないようになるトラブルが起きました.
 
通信用の部品が高負荷で悲鳴を上げているっぽい.調べてこれを入れて解決しました.
 

トラブル②:アプリケーションが起動しない!(技科大祭前日)

技科大祭前日,サーバの電源を付けてもアプリケーションが一切起動してこない事件が発生しました.事件発覚時点で15時,前日設営は17時までです.残り2時間でサーバの復旧からアプリケーションテストまで完了させる必要があります. (本来は13時~17時の4時間ですが,実行委員さんに9時~17時の8時間に延長していただいています)
技術班のネットワーク・サーバ部門では,ネットワークとサーバの運用だけではなく,実質的にVJ環境のセットアップ(会場内の映像伝送)からメディア(配信,録画),その他の班に属さない部分の設営,他の班からの設営のあらゆる問い合わせについて回答を行うサポートセンターを兼任しています.設営がまだの部分を組み立てながらテストを回していき,様々な班から飛んでくる問い合わせに回答しながら(結構大変なので,イベントごとに設営時の機器への自動設定投入の仕組みづくりを進めています),サーバの復旧作業を進めていきます.
 
再構築RTA,はじまるよ~~~
 
動かなくて急遽クラスタの破壊と再構築をしている図
動かなくて急遽クラスタの破壊と再構築をしている図
一度クラスタを破壊して,クラスタを組みなおしてもアプリケーションが動きません.
 
困った...
 
よく調べてみると使っているソフトウェア(CRI-O とMultus CNI)との相性が良くないらしい,一時的に /etc/cni/net.d/00-multus.conf を削除することで直りました.復旧時点で17時手前,テストを当日の朝に延期してなんとかなりました.

アプリケーションの移行

ネットワークの再構築の際に,住所の振り直し(愛知県豊橋市という住所が急に北海道旭川市になるみたいなこと)をやったので,サーバの中で動いているアプリケーション(コンテナ)に対しても住所を振りなおす必要があります.
基本的にはKubernetesが自動でやってくれて,もともとKubernetes上で動かしていたものはすんなりと動きました.こういうのとかこういうのとか.
ただし,Sony製のカメラから無線で映像を引っこ抜いてくるアプリケーションが少し複雑なことをしているので手動で対応する必要がありました.
DNSキャッシュポイズニングやDNSスプーフィングと呼ばれる攻撃手法で正規のサーバではない偽のサーバに接続させることでカメラから映像を取り出しているのですが,偽のサーバに誘導する際に教える住所を設定ファイルに直書きしていたので修正しなければなりません.この変更は部員Hがやってくれました.
 
また,TechnoTUTでは,サーバ内でBeat Link Triggerというアプリケーションを動かし,DJシステムであるXDJ-XZから情報を引っ張り出しています.
 
どうしてサーバ内で動かすかというと,複数台のPCで一斉に起動するとトラブルになるからですね.VJさん2人とLJさんと...とそれぞれで立ち上げていくと最悪DJ機器をやっつけて音を止める可能性もあります.どうしてダメなのかはA.I.Techのなんとかすしろーるさんの記事を覗いてみてください.
 
複数台のPCで使うとまずいならば,1台のPCで立ち上げてその画面をみんなで覗けば良いわけですよね.なのでサーバ内で動かして,手持ちのiPadやPCで覗けるようにしています.
 
覗けるようにするにあたって,デスクトップ環境が必要かつその上でアプリケーションを動かす必要があり,これだけはコンテナではなく仮想マシンで動かしたいとなりました.
KubevirtというKubernetes上で仮想マシンを動かせるようにできるものがあるのでクラスタにインストールします.
DebianのCloudイメージを使って,Kubernetesクラスタ内に仮想マシンを作成していきます.
出来上がったら, sudo apt install task-kde-desktop を実行してデスクトップ環境を入れます. あとはVNCサーバを入れてBeat Link Triggerを入れて,アプリケーションの準備はできました.
これでLinux・MacからVNC接続すれば画面が見える状態にはなりますが,Windowsの標準機能から使えるようにリモートデスクトップ接続できるようにしておきます.別でコンテナイメージを錬成してリモートデスクトップ接続とVNC接続を変換してくれるアプリケーションを動かします.
 
ここでネットワークの問題を考慮する必要があって,DJシステムから情報を引っ張る際はDJシステムと同じネットワークである必要があり,VJさんのPCのBPMを自動操作させるためにも同じネットワークである必要があります.Kubernetesではデフォルトでコンテナ用の別のネットワークを作成しておりそのままでは使うことができません.
同じネットワークというのは,住所が近くないといけないということです.普通は豊橋市内から浜松市内までなど,別の市の人ともお話しできますが,DJ・VJの機器間で使うお話のお約束(通信プロトコル)には特殊なもの(PRO DJ LINK・Ableton Link)もあって,お互い豊橋市内の住所じゃないとお話しできないものがあります.Kubernetesのデフォルトでは豊川市の住所を使っているのでお話しできないのです.
そこで,Multus CNIというプラグインを使います.
何をしてくれるかというと,コンテナに別のLANケーブルを挿してくれます.コンテナ同士で通信する用のネットワークにも,DJシステムのいるネットワークにも,VJさんのPCのいるネットワークにも直接接続できるようになります.例でいうと,豊川と豊橋の境界にお家を建てる,みたいなものです.
そうするとこんな感じでDJシステムから情報を引っ張ってこれます!
XDJ-XZとCDJ-3000で3Deck分引っ張ってこれている
XDJ-XZとCDJ-3000で3Deck分引っ張ってこれている
ブラウザからも使えます
ブラウザからも使えます
これで全てをKubernetesに移行できました!

技科大祭当日

当日は特にトラブルなく元気に動いてくれました.
別のトラブルは発生しましたが...
技科大2日目,VJさんの映像を送るコンピュータが過負荷でサイレント故障?を起こして,ブースディスプレイへの映像伝送が停止しました. (サイレント故障:故障しているのに故障と検出されないこと)
notion image
急遽予備のコンピュータを臨時で設置して,別の経路を用意して対応しました. (ぱっと見は動いているし止められないサービスも動いているので,故障ノードは切り離せなかった)

技科大祭の様子
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
notion image
 

おわりに

今までネットワーク・サーバの構築からメディア周りの運用まで,私と部員Hでやっていることが多かったのですが,9月末の再構築にはB1・B3の若人8人が集まってくれて大変嬉しかったです.(正直少し意外でした)
Kubernetesは気軽に手元のPCでも触れるので,これを機にぜひ!
部員へ:Kubernetesは初期の学習コストが少し高いですが,使えるようになれば便利な上に堅牢に運用ができるものだと思うので,ぜひ部室でいろいろと試してもらえたらと思います.壊してもすぐに全部再構築できるから気軽にね!
 
トップへ戻る