大規模なネットワークに小さなラジオ局を構築する方法

この記事では、さまざまなタスク用にさまざまなLinuxシステムでicecastを迅速に構成する方法については説明しません。 いや この記事では、放送ラジオ局をグローバルネットワークに導入するための1つの小さなプロジェクトの小さな歴史を強調したいと思います。 どのような問題に直面する必要があり、どのようにそれらを解決しましたか。

だから。 少し先史時代-私たちの故郷、モスクワの首都に本社を置くいくつかの放送音楽ラジオ局のラジオがあります。 ラジオ局自体は首都のFMバンドで放送しており、視聴者がいて、リスナーに非常に満足しています。 しかし、不運-2012年の中庭で、インターネット放送の方向性はそれほど不安定ではなく、あまり発展していません。 それから、もし興味があれば、猫にようこそ、1つのメインの枠組みの中で多くの言葉と小さな物語があります。

問題の声明は、ホールディング全体のゼネラルディレクターとラジオ局自身の多くのプログラムディレクターの両方にとって長い間延期されました。 しかし、小さな問題がありました-保有はこのサービスを収益化する方法をまったく見ていませんでした。収益化がないため、クレイジーなソリューションを構築する予算はありません。 タスクが期限切れになる理由-当時（2012年春）の既存のサービスは、信頼性、品質、利便性の要件を満たしていませんでした。 2012年の春、技術部門とITサービスのリーダーシップが変わりました。 私の運命と同僚は、この会社のITサービスを管理する機会を「与えました」。
だから。

予備状況

社内のインターネットブロードキャストは、少数のサーバーセットによって提供されました。

• 1つの配布サーバー（FreeBSD、ドープされたicecast、thanscoder、3 Gbitイーサネット、M IX Butlerova）
• モスクワのスタジオコンプレックス（本社）にインストールされた2台のエンコードサーバーと、メイン配信サーバー（Windows XP、icecast、edcast）へのMP3ストリームのアナログ/ AESソースのエンコード

さらに、MP3信号は完全に直接送信されませんでした-各ラジオ局について、5つあり、256 kbit / sのストリームが形成され、エンコードのローカルアイスキャストサーバーで公開されました。さらに（64、96、128、320）。 それはサーバー側で、クライアント側ではすべてがさらに悪化していました-原則としてフラッシュ/ htmlクライアントは存在しませんでした、ラジオ局のウェブサイトに投稿された小さなFAQ、ストリームへの接続方法、およびクライアントのすべての「なめる」が終了しました。 この設計が少なからず機能することを追加する必要があります。ほぼ毎日、3〜3.5万人のリスナーに到達すると、ホールのメインラジオ局のフローに「中断」が見られました。原則として、「中断」は1日に数回発生しました。 障害の理由は異なり、トランスコーダーが上昇し、何らかの理由でサーバーがリモートマウントポイントなどを認識しないと判断します。 要するに、それは明らかにやるべきことでした。
この経済全体のサポートを提供したエンジニアに宛てた私の論理的な質問に、なぜすべてが構築されるほど「論理的ではない」のでしょうか？ 通常の答えが続いた-まあ、それは歴史的に起こりました。 ノボシビルスクの外部アウトソーシング従業員がアイスキャストの「仕上げ」に従事していたことに注意する必要があります。 彼は偉大な人物であり、FreeBSDを広く知っており、CまたはC ++で書いていますが、マルチメディアについてはあまり理解していませんが、ネットワーク上で大規模な放送プラットフォームを構築する方法を確かに知りませんでした。 そして彼はそれを必要とせず、彼はそれのためにお金を払いません。 さらに、時間差は、要するに、一般部門が技術部門の責任者と一緒に私たちのオフィスに入り、「ネットワーク上の何かがiPhoneで動作しないので、もう何かをしよう」と言った瞬間に転換点が過ぎました。 。 彼に答えることは何もありませんでした。まあ、彼は本当に遊びません。

最初に考える必要があります

管理者なら誰でもicecastを見て、何を考えるべきかを教えてくれるでしょう。ここでは「ファイル」する必要があります。 しかし、これは私たちの場合ではありません。 私たちは「歴史的に」破壊されているため、これらの馬小屋を通常のレベルに引き上げる必要があります。 その時に存在した主な問題：

• 低レベルの冗長性-実際、単一のシステムコンポーネントは冗長ではありませんでした
• 少なくともある種の負荷分散のシステムの欠如-すべてのフローが1つのサーバーに、すべてのクライアントが1つのサーバーに。 そして、彼がそれらを保持しているかどうかを確認します。
• 多数の未診断障害
• icecastとFreeBSDコアカスタマイズのドキュメントが不十分であるため診断が困難です+古くなった製品（ある種のシャギーバージョンのFreeBSD）+ TCP / IPスタックの「正しく」実装されていない形式のこの製品に関する問題たくさんのセッションでロードする
• FM信号処理の完全な欠如-これは、PMでの説明やコメントが必要な場合、ラジオ環境では非常に専門的でないと見なされます
• ラジオ局のウェブサイトで直接再生するためのフラッシュ/ HTMLクライアントの欠如
• 監視システムの欠如

要するに、それがどこにあるのかを掘り下げてみましょう。今、どのようにしてそれが何らかの合理的な見方につながるのでしょうか。

考えるのをやめる-それは「ギャッシュ」する時間です

ソリューションは体系的なものでした-ITマネージャーがそれほど専門化されていないタスクに直面したときに頭に浮かぶのは、正しいことですが、お金のために外部委託しましょう。 手元が特にきれいではない一部のマネージャーも、アウトソーシングのコストに関心を寄せていますが、それについては話していません。 上司と私は両方の決定を一度に検討しました。 または私たちは自分でそれをやって、どのように、または私たちはそれをアウトソーシングすると、質問が発生します-どのくらいの費用がかかりますか？ したがって、ネットワークへのブロードキャストを第三者に提供し、このタスクを永遠に忘れるのにどれだけの費用がかかるかを計算するとすぐに、アウトソーシングの問題は自然に解決しました。 そのようなサービスを提供する企業は、ラジオ市場の大企業が決してやって来ないようなサービスの価格を公に提示しますが、これは事実です。 モスクワのトップ10にある最大のラジオ局でさえも、これらの条件下で確実に降伏することができますが、それでもかなりの費用項目であり、通常の収益化はありません。 放送と収益化の両方を一度に提供するサービスはさまざまなタイプの広告を配置する形で提供されますが、サービスの価格さえ非常に高く、投資収益率の問題は非常に深刻であるため、NOと言われました。 特に手頃な方法で運用費用を削減するために私たちを雇ったので、私たちはそれを選ぶことはできません。ここではすべてがまったく逆になります。 要するに、私たちはこの考えを放棄しました。
自分で構築する-方法は？

• 冗長性-icecast-khのレベルで組み込みのバランシングメカニズムを使用して、配信サーバーの数を4に増やします。 エンコードソフトウェアを仮想化プラットフォームに組み込みます。 エンコーダーから最初の配布レベルのアイスキャストを取り出し、別の仮想マシンに配置します。 セントラルオフィスでインターネットチャネルを予約します
• バランス調整-マウントポイントのicecast-khの充填に応じて負荷を調整します
• Omnia AX / Eをエンコーディングソフトウェアとして使用することが提案されています。これにより、エンコーディングとFMオーディオ処理の両方のニーズを解決できます。
• メインの配信サーバーでのトランスコーディングの完全な拒否。サーバーは完全に準備が整ったストリームを受信し、配信するだけです。
• サーバー上のFreeBSDの完全な拒否と、ある種のLinuxへの移行（最終的に、Ubuntu 12.04 LTSを選択しました）
• 近隣の部門がサイトでプレイするためのフルフラッシュ/ htmlクライアントを作成し、iOS + Andriodモバイルプラットフォーム用のクライアントを開発する
• MP3だけでなく、モバイルオペレーターのネットワークでリッスンするためのAACv2 +ストリームも顧客に提供します。
• イベントごとにファイルを変更する機能を備えたアクティブな監視システムのインストール

なぜそう
私の意見では、大量のストリームを運ぶアイスキャストの前にロードバランサーを配置しようとする試みはまったく意味がありません。 サーバーに比較的弱いプロセッサと少量のRAMを備えたギガビット通信チャネルがある場合、Icecastはクライアントをプルするだけで完全にブロックします。 それで、あなたは何のバランスをとりますか？ 複数のギガビットストリーム、および単一障害点で何をすべきか？ なんて方法-ポートチャネルがある場合、スイッチを使用してネットワークレベルでのみバランスをとります。 3つのギガビットチャネルを使用すると、2.7ギガビ​​ット/秒、4つすべてに対して4つのチャネルなどを使用できます。 サーバー間の負荷分散により、マウントポイントに過負荷がかからないように、Icecast自体で実装できます（KHバージョン）。 実際には、icecastが128 kbit / s MP3の1つのマウントポイントで3200〜3500を超えて保持しないことが判明しました。理由は、プロセッサコアの高負荷です。 実際、Icecastはデフォルトで1つのコア上の1つのマウントポイントを処理します。 システム内のコアの数よりも多くのマウントポイントがある場合、それらはコアによって分離され始めますが、再び、均等ではなく、1つのコア上のマウントポイントによって分離されます。 プロセッサがあまり高速でない場合は、1つのマウントポイントに3,000を超える数のプロセッサを同時にロードしないでください。トリックを使用できます。同じサーバーの隠しマウントポイントに異なる名前で転送します。 通常のアイスキャストでは、この「ひねくれた」ロジックは正常に機能します。 KHバージョンでは、別のマウントポイントに異なるソースが必要です。
第二に、ブロードキャストタスク用の巨大なサーバーを作成することは、プラットフォーム全体の水平成長の可​​能性を絶対に考慮しないことを意味すると信じています。これは完全に真実ではありません。 したがって、水平スケーリングのオプションが選択されました。
プロプライエタリなソフトウェアでコーディングしたかったのは、FM処理とエンコードの個別のコンポーネントの形で庭を囲みたくなかったからです。 別のプラスは、いくつかのエンコーダをテストした後、AXIAが圧縮品質に関して無料のものと異なることが明らかになったことです。 ラメなどと比較して 彼女は良く聞こえます。 「なぜ？」を長い間説明したくありません。後ほど、またはコメントで。

「リール」を始めます

彼らがすぐに直面したこと-リスナーの数、さらに、1日、1日、1週間などの間に同時に蓄積されたリスナーの数を何らかの方法で測定する必要があることが明らかになりました 明確化の過程で、このようなさまざまなフローを残すことと、それらの多くが非常に「厚い」（たとえば320）ことが明らかになりました。 これは最初の重大な障害であり、プログラムディレクターや他のトップを説得するのは、過去にこのタスクの実装を担当する通常のエンジニアよりもはるかに簡単でした。 「聴衆」の心の状態は、客観的な現実を理解することを拒否しました。 私たちは洗濯でそれをしなかったので、それは多くの血がかかり、多くの感情的な傷を残しました。 しかし、神に感謝します。 私たちはすべてを整理し始めました。 5つのラジオステーションごとに次の標準ストリームに到達しました-128および64 kbit / s MP3、56および48 kbit / s AACv2 +。
長い間、彼らはメインの配信サーバーに触れず、内部インフラストラクチャを整理しました。 最後に、2013年の春のある日、私と私の部下は午前中にM IXを駆け巡り、すべてが崩壊し、すべてがさらに上昇しました。 かなりうまくいきました。 icecast-khと組み合わせてLinuxを導入することの利点はすぐに明らかになりました-同じ負荷の下で実際にプロセッサの負荷が低下し始めました。 差は最大20％でした。 これはたくさんあります。 さらに、すぐに4台のサーバーに負荷を分散させ、日中に単一のDNSレコードに接続し始めました。
開発部門は通常のプレーヤーを取得するのが難しいため、DNSのラウンド＆ロビンメカニズムで負荷分散を補完することにしました。 彼は確かに最も信頼できる人ではありませんが、それについてはまだです。

たばこの吸い殻の山を残していく…まとめ

2013年11月に、この輝かしい会社での私の仕事は終わりました。 私が誇りに思うことと、このタスクの一部として行われていないこと。
4台のサーバーの合計ファームフローは、日中のピーク時に2.5 Gbit / sを超え、月から月へゆっくりと上昇し続けました。 行われたすべての動きの前に、彼は1.2-1.3を超えませんでした。 実際、同社はサービスを受けたいすべての人にサービスを提供したのではなく、最初に間に合った人だけにサービスを提供しました。
予備的な統計によると、週に50万ユニキの指標を「突破」することができました。これらの数字はすでに何らかの形で販売されています。 接続している各ユーザーのコマーシャルを再生するイントロファイルを配置するメカニズムが実行されましたが、すでに失った人と失っていない人を追跡することはできませんでしたが、これは最初の配置体験です。
負荷はサーバー間でより均等に分散し始め、これがサービス品質に影響を与えました。 中断は、実際のネットワーク障害やその他の問題の結果としてのみ発生しましたが、サービス自体の構成の誤りやその他の問題によって引き起こされることはなくなりました。
低ビットレートで高品質のストリームが出現したため、モバイルプラットフォームからクライアントの増加へのクライアント数のシフトが始まりました。 エンジニアとして私を喜ばせます-結局のところ、これは本質的にラジオ局全体の将来の配信モデルです。
内部のアイスキャストが撮影され、すべての配信サーバーへの配信用に単一の内部のアイスキャストが作成されました。また、一部の地域パートナーがバックアップ信号ソースとして使用しました。 これにより私たちは1回または2回以上救われ、地域の専門家は保護区の信頼できるサービスに感謝しました。

私が誇りに思うことはできません。
Omnia AX / Eへの本格的な移行を導入する計画は未だに実現されず、資金調達を完全に拒否しました。 その結果、古い倉庫で見つかったハードウェアFMプロセッサで庭をフェンスで囲みました。 監視の問題は残っていました-財務の拒否、PRTGの実装を決定しました.Nagiosなどには人的資源がまったくなかったため、このタスクにより、サーバーの障害に迅速に対応できず、多数のクライアントが何分も沈黙しないようにすることができませんでした。 配信サーバーのログファイルの分析の通常のシステムを実装することはできませんでした。通常のシステムは、通常のパラメーターに加えて、AQHなどの純粋なメディアデータを計算できると理解されています。 私が知っている唯一のシステムはCasterstatであり、他のすべては主にWebサーバーを処理するために設計されており、あまり適合しません。 ほとんどのモバイルプラットフォームの本格的なプレーヤーは完全には開発されておらず、iOSでのみ終了することができましたが、少なくともタスクは私たちと一緒ではなかったので、少なくともそうでした。
完成度を評価する方法はわかりませんが、主にプレーヤーの開発を担当する部門の問題により、プレーヤーのplsメカニズムに基づく本格的なバランスシステムの導入に成功しませんでした。 しかし、それは問題ではありません。私たちは彼らを責めることも何もありません。
この会社での作業中に技術部門とITサービスが解決した唯一のタスクではないことを理解する必要があります。そのような期間に驚かないでください。 言い訳をしているようです。

マルチメディア分野のITのトピックに誰かが興味を持っている場合は、経験があるので、他のトピックの話を続けることができます。