BGP-Meeting-J-Stream-20251127

-- Views

December 02, 25

スライド概要

2025年11月27日に開催された BBIX社主催「BGP Meeting 2025 Winter」での登壇内容です。
セッション「つなぐ、届ける、変える ― コンテンツ配信の最前線トーーク」にて、Jストリーム アーキテクトの高見澤信弘が、他社ゲスト企業の皆さまと登壇しました。

profile-image

1997年の設立以来、動画配信を主軸に事業展開。コーポレートメッセージ「もっと素敵な伝え方を。」を掲げ、テクノロジーを通じて世の中のコミュニケーションをよりよくすることを目指しています。 自社で保有・運営する独自のコンテンツ配信ネットワーク(CDN=Content Delivery Network)を活用した動画配信に加え、長年のノウハウを活かした動画の企画・制作・運用やWebサイト制作、システム開発、動画広告による収益化支援まで総合的なサービスとソリューションを提供。取引実績はメディア、大手企業をはじめ年間1,200社・10,000案件以上です。手がける技術領域は、ネットワークの物理層からアプリケーション層にわたり、日本屈指の大規模配信や最先端案件の実績も多数あります。 エンジニア向けオウンドサイト「Voice」公開中! https://voice.stream.co.jp/

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

BBIX BGP Meeting 2025 Winter 2025年11月27日(木) つなぐ、届ける、変える - コンテンツ配信の最前線ト——ク - 株式会社Jストリーム 2017年9月8日 高見澤信弘 株式会社Jストリーム © J-Stream Inc. All Rights Reserved.

2.

自己紹介 ▶名前:高見澤信弘 ▶出身地:山形県天童市 ▶所属:株式会社Jストリーム (AS24253) ◼ 新卒でJストリームへ入社 ◼ エンジニアリング推進室&プロダクト企画部(アーキテクト) ▶お仕事 • CDN(Content Delivery Network)の企画、構築 • ネットワーク企画 ▶好きなもの • ロードバランサー → お家にBIG-IP • おうち19インチラック勢 • 活動 • IPoE協議会 IPv6地理情報共有推進委員会 幹事 • 海賊版対策実務者意見交換会 海賊版対策技術検証チーム(WG) メンバー © J-Stream Inc. All Rights Reserved. 2

3.

CDN事業者としての立ち位置 ▶顧客のコンテンツを配信する立場 ▶コンテンツやフロント(画面やプレイヤー)はタッチできない ▶配信のための設備を自社で持つので、考え方も変わってくる ▶自社設備の概要 ▶動画配信の歴史と設備の変遷 © J-Stream Inc. All Rights Reserved. 3

4.

CDN基本構成 ▶ オリジンサーバーも展開 ◼ ストレージ、オリジン(Web/動画)、認証等もサーバーも分散配置、プレイヤーも自社開発 ▶ キャッシュサーバー ◼ 1つのPoPに複数台の複数の物理サーバーで構成されたキャッシュサーバー(クラスタ)を複数設置 ◼ PoPは自社AS(ASN:24253)に加えて、複数のデータセンター事業者のネットワーク内にも設置(Edge拠点) ◼ AS拠点は複数IXに接続し、ISP様とピアリング(ピアリング歓迎!) ◼ クラスタをグループ化しており、設定ファイルの管理や誘導方法を変えている(例えば海外配信やSVOD顧客など) ◼ ライブ、オンデマンド、Webなどでキャッシュサーバーは分離していない(サーバー内部でキャッシュ領域などを分割) Internet オリジンサーバー CDN Cache (AS拠点) IX GSLB CDN Cache (Edge拠点) キャッシュサーバー © J-Stream Inc. All Rights Reserved. Internet エンドユーザー 4

5.

キャッシュサーバー構成 ▶ クラスターの構成 ◼ フロントとストアは物理的には1台のサーバーにプロセスを分けるなどして実装している=全サーバーが同一構成になるようにしている →キャッシュサーバーの増設が容易、用途転用(オンデマンド→ライブ)をロードバランスだけで実現可能 ◼ 複数台のキャッシュサーバーノードで1つのクラスタを構成している。増設はクラスター単位で実施 ▶ フロント ◼ ユーザーアクセスを受け、SSL処理やURL変換、トークン認証などなどの処理を担当 ◼ キャッシュ容量は少、メモリでヒットさせる(フロントでキャッシュヒットしないアクセスがストア側に流れる) ◼ フロントサーバーがストアサーバーへアクセスする際にURL毎にアクセスするサーバーをバランシングしている →これにより、ストアサーバーのロードバランスとクラスタ化を実現している ▶ ストア ◼ SSD/NVMeを大量に搭載し、キャッシュヒットさせる ◼ 1台のストア用サーバー(プロセス)は全URLではなく、フロントサーバーでバランシングされた特定URLをキャッシュする ◼ ストアサーバーがオリジンサーバーへのアクセスを行う クラスター SSD/NVMe Memory キャッシュ サーバーノード オリジンサーバー ライブとオンデマンドではキャッシュ ファイルの利用方法(TTL)が異なるので、 利用するストレージ領域も分けている。 ストア URL毎に ハッシュ分散 © J-Stream Inc. All Rights Reserved. フロント キャッシュ サーバーノード 5

6.

システム連携やキャッシュヒット率の考慮も必要 ▶複数のシステムが連携して1つのサービスを提供している場合が多く、通信相手も複数 ◼ オリジンサーバー、DNSサーバーなどのインフラ系のサーバー ◼ CMSや認証システムなどの外部システム ◼ クラウドやPasSの利用 ▶CDN(キャッシュサーバー)は分散だけではパフォーマンスは上がらない ◼ キャッシュサーバーに適切にキャッシュを持たせることが大事 オリジンサーバー 認証システム Internet DNSサーバー CDN Cache エンドユーザー クラウドやPaaS © J-Stream Inc. All Rights Reserved. 6