インターネットトラフィックが増大していく中で、通信環境の維持・向上に向けてIPv6の利用が広がりを見せています。IPoE接続でIPv4もサポートする技術をはじめとしたIPv4aaS（IPv4 as a Service）の普及もあり、IPv6は多くの環境で一般的に利用されるようになってきています。この状況を踏まえ、2022年12月に「 IPv6 Summit in TOKYO 2022 」が開催されました。   Jストリームからは、プロダクト企画部のN.T.さんが登壇し、「CDNにおけるIPv6対応とコンテンツ配信2022 〜CDN最新動向〜」というテーマで講演を行いました。当日は、2022年3月に実施したＪストリームのCDNをIPv6対応させた際の実体験をもとに、IPv6対応で苦労した点や技術的成果についてお話しました。またIPv6普及の背景となるコンテンツ配信の最新動向についてもあわせて解説しました。今回の記事では、本講演を振り返るイベントレポートをお届けします。 N.T．プラットフォーム本部 インフラエンジニア（新卒入社・16年目）   学生の時からストリーミングに興味があり、自分で配信サーバを作ってライブ配信していました。自宅にサーバやネットワーク機器があり、そんな中で生活しています。2021年からは、動画プラットフォーム(J-Stream Equipmedia)やCDNサービス(J-Stream CDNext)などの自社開発プロダクトを取りまとめる部署に所属しています。 2022年からは、 一般社団法人IPoE協議会でのIPv6地理情報共有推進委員会 幹事を務めています。 利用技術：BGP / OSPF / IPv6 / DNS / Cisco IOS / JUNOS / FRR / KVM / VMWare / シェルスクリプト / Ansible / Docker / raspberry pi / お家サーバ / GPU / NDI / SRT / ffmpeg コンテンツ配信の基本構成とIPv6対応 ――CDNとは？ CDNとは、データを効率よく最適に配信する仕組みのことです。エンドユーザーの近くにキャッシュサーバと呼ばれるCDNの配信サーバを多数設置し、オリジンサーバに置かれている大元のデータをキャッシュサーバが一時的に複製（キャッシュ）することで、エンドユーザーに配信するという仕組みになっています（図1）。   CDN設計で難しいとされるポイントは、大きく2つあります。ひとつは、いかにコンテンツをキャッシュしてキャッシュサーバから直接エンドユーザーに配信するかという点、そしてもうひとつは、ネットワーク的に一番近いキャッシュサーバへいかにエンドユーザーを誘導していくかという点です。 【図1】CDNの概念図 エンドユーザーは、インターネットを経由してキャッシュサーバへアクセスします。その際、キャッシュサーバでコンテンツがキャッシュされていれば直接配信し、キャッシュされていなければオリジンサーバへコンテンツを取りに行くという動作になります。オリジンサーバは、コンテンツプロバイダやCDN事業者がストレージと配信サーバというものを用意している場合が多いです。昨今は、「動画配信プラットフォーム」という形で動画配信サーバを含めたサービス提供する形も増えています。   一方、キャッシュサーバは、エンドユーザーへコンテンツを配信する役割を担います。ここでは、例えば、国内限定配信の場合であれば海外ユーザーからのアクセスを弾いたり、地域判別やセキュリティなどに関する様々なアプリケーション処理がなされます。Ｊストリームの場合、複数台の物理サーバで構成されたキャッシュサーバを1つのクラスタとして、各POPに配置しています。またPOPのインターネット接続には2種類あり、ひとつは自社のAS番号を持ち運用している拠点がありIXとISPを繋いでいるものです。もう一つは、大手データセンター事業者の中に置いているキャッシュサーバとなります。   そして、Ｊストリームが2022年３月に行ったCDNのIPv6対応ですが、エンドユーザーにとって一番手前となる部分、つまりキャッシュサーバをIPv6対応させました（図２）。 【図２】コンテンツ配信の基本構成とＪストリームでのIPv6対応部分について ――IPv6対応においてCDNを活用するメリットとは？ IPv6対応においてCDNを活用するメリットは、やはり簡単にIPv6対応が実現可能であるところだと思います。エンドユーザーから見ると、実際にコンテンツが配信されるのはキャッシュサーバからになりますので、そこがIPv6対応していればエンドユーザーとの通信は基本的にIPv6化できます。逆にオリジンサーバとの通信はIPv6でもIPv4でもできるという形で、あまり今の環境を変えずにIPv6対応ができるメリットがあります。   また、動画の美しさや、動画が再生中に止まることなくスムーズに視聴できるというような配信の視聴品質（QoE）が向上するのもエンドユーザーにとっての大きなメリットです。一方、ISP側のメリットとしては、設備投資を削減できる点が挙げられます。 【図3】CDNの活用によるIPv6対応の実施イメージ CDNをIPv6対応させるポイント ――CDNのIPv6対応における4つの側面 ここでは、CDNのIPv6対応における4つの側面について解説したいと思います（図4）。 まず一つ目がネットワークです。この部分は多くの機械がIPv6に対応していますので、あとは設定を行っていくだけで大きな問題はありません。 2つ目がキャッシュサーバです。具体的には、サーバへIPv6のアドレスを付与するのですが、Ｊストリームでは大量のサーバを保有しているため、ロードバランサーや間のネットワークもIPv6対応させる必要がありました。このあたりは、今回IPv6対応に際して、新たに設計を変えた部分で、よりシンプルでスケールアウトしやすい構成にできたなと実感しています。 そして3つ目が、ロードバランサーです。ロードバランサーはいわゆるGSLBと呼ばれているDNSベースのものと、ローカルのロードバランサーがあります。ＪストリームはGSLBを使ってIPアドレスベースでトラフィックコントロールを行っているため、たとえば“IXで繋がっているISPさんに対して、このサーバを返す”といったロードバランスルールのIPv6対応も必要になりました。 そして4つ目が、アプリケーションです。ここはかなり苦労した部分です。アクセスログの処理や国内外判別、ACL（アクセスコントロールリスト）などの部分で、IPv6対応のための再設計と再開発が必要になりました。 【図4】CDNとしてのIPv6対応における4つの側面 上記4つの中で最もポイントだったと思うのは、ロードバランサーとアプリケーションの部分です。よかった点、特に大きな成果だと思われる点としては、ロードバランサーの構成をシンプルにしたことです。IPv4の場合はアドレスの数がかなり限られているため、アドレス節約のためにアドレス共有やLBを使ったロードバランスが必須となります（図５-左図部分）。     しかしIPv6はアドレス空間が広いというメリットがあるため、IPアドレスの共有を廃止し、ロードバランサーを介さずにソフトウェアベースでバランシングする形に再設計しました（図5-右図部分）。これによってかなりスケールアウトしやすい構成にすることができています。ボトルネックになってしまいがちなロードバランサーを外せたのは、かなり大きな効果だったと考えています。 【図5】IPv6のメリットを生かしたネットワーク構成イメージ 一方で、苦労したのがアプリケーションサービスです。CDNに付随するアプリケーションサービスは、アドレス長が変わるため再設計・再開発が必要になりました。例としては、国内外判別というIPアドレスベースのジオコントロールシステムを再設計です。   これはまず、IPv6に対応したジオデータベースを探すところからのスタートでした。とはいえ、現在は複数の事業者がIPv6対応のジオデータベースを提供しているため特に問題はないかと思います。また、Ｊストリームは IPoE協議会にも参画しており 、より正確な地理情報データベースの構築にも協力しています。   その後、ジオIPの判定モジュールやアクセスログを処理するバックエンドシステムなどのIPv6対応を行い、負荷試験を実施しました。すると想定よりも処理に時間がかかったため、処理システムのサイジングを変更するなどの処置が必要になりました。   このような試行錯誤の末、ＪストリームにおけるCDNの付随部分もIPv6対応ができ、2022年3月より本格対応開始というゴールに到達しました。 コンテンツ配信2022 ――コンテンツ配信2022における2つの注目点 ここからは、少し話題を変えまして、昨今の配信ビジネスの動向や技術的な進化についてお話ししたいと思います。 特に注目すべき点としては、2つあります。   一つ目に挙げるのは、トラフィック増加です。トラフィックの増加やピーク性の強まりを、配信事業者として強く感じています。特にライブ配信です。今までインターネットでライブ配信できるコンテンツはある程度限られていましたが、昨今はOTT事業者がコンテンツを買ってインターネットで流すことが一般的になりました。その結果、1Tbpsを超えるような配信が日常的に起きています。   そして2つ目が、視聴品質（QoE）です。コンテンツは非常にリッチになってきているため、QoEをいかに担保していくかが大きな課題となっていると感じます。 【図6】コンテンツ配信2022における2つの注目点 ――CDN事業者、OTT事業者に求められる「ネットワークの中立性」 総務省から出ているトラフィックの集計データによると、やはりコロナ禍で急激に増加し、その後も上昇を続けている状況です（※1）。この上昇が続くと、トラフィックを配信する側だけでなく、受ける側の負担もかなり増えていくことが予想されます。ネットワークの中立性についての研究は2018年くらいから国内でも活発に行われていますが、我々CDN事業者やOTT事業者は、この“ネットワークの中立性”を考慮した設備投資やトラフィックコントロールが求められていると考えています（図7）。 【図7】トラフィックの増加とCDNに求められる役割 ――トラフィック増加対策としての「マルチCDN」 トラフィックが増えてくると、一つのCDNだけでは安定した配信が難しくなります。そこで最近注目されているのが、マルチCDNというソリューション。我々は、通信品質を考慮してCDNをセレクトしていく仕組みを持っています。   詳しく説明すると、動画の視聴プレイヤーにビーコンが仕込まれており、各CDNに配置されたビーコンをダウンロードした際にスループットやダウンロード時間が分かるようになっています。これをビッグデータ処理し、エンドユーザーがアクセスする際にどのCDNに割り振るかを選択する仕組みになっています。そのスコアを見てみると、ISPやケーブルテレビの事業者間、また地域によってスコアに差が出てきています（図8）。ただし一般的な話としては、QoEについてはやはりIPv6タイプのほうが有効であると考えています。 【図8】マルチCDNと通信品質を指標としてCDNセレクター ――もう一つの新しい技術「オープンキャッシング」 「オープンキャッシング」とは、簡単に言うと特定のISPのみをカバーしたCDNのことです。各ISPの中に共有のキャッシュサーバを置き、これを束ねたCDNです（図9）。この場合、全部のISPにキャッシュを置くことはできないため、カバレッジがある別のCDNを併用する形になり、マルチCDNの構成になっていきます。そして、もちろんオープンキャッシングに関してはIPv6対応していますので、先ほどのQoEの話も織り込み済みです。   オープンキャッシングについては、国内ネットワーク各社と共同でJストリームも2023年1月より実証実験を実施予定です（※2）。 【図9】オープンキャッシングのイメージ図 オープンキャッシングの特徴はいろいろありますが、まずは複数のコンテンツプロバイダが共有するキャッシュサーバということ。簡単に言うとCDNの一種になります。このキャッシュサーバが特定のISPの中に置かれる形となるため、ISP側は自分達のネットワークの中だけにコンテンツ配信ができるようになります。   また、CP/CDN側のメリットとしては、まずIPv6に対応している点。そしてキャッシュの分散配置が可能になるため、最終的にはQoEの向上や配信遅延の削減ができるようになります。その一方、これまでのキャッシュの仕組みとは違い、カバレッジが100%にならないため、マルチCDNの制御が必要になります。   一方、ISP側のメリットとしては、キャッシュを自分達のネットワークの中に置けるため、上位回線のコスト削減やQoE向上が可能になることが挙げられます。 ――「ISPに優しいコンテンツ配信」と「IPv6対応による視聴品質の向上」の両立 CDNの一番のメリットは、キャッシュを分散配置してエンドユーザーの近くからコンテンツを流せることです。これにより、ネットワークの公平性や視聴品質を担保できると考えています。     図10に「ISPに優しいコンテンツ配信」と「視聴品質向上」の両立に関する構成概念図を記載しました。これまでは、東京/大阪のIXや地域IXなどISPの近いところに設置するキャッシュサーバと、東京・大阪を中心とした大規模なデータセンター事業者からトランジットを経由して配信するという２パターンでした。しかし、今後はISP内に細かく設置するオープンキャッシングを用いることで、大規模配信とQoEの向上が両立が可能になります。 【図10】「ISPに優しいコンテンツ配信」と「視聴品質向上」を両立させた構成概念図 ――おわりに コンテンツ配信は、今後ますます盛り上がることが予想されます。コンテンツ配信IPv6時代におけるCDNについて、Ｊストリームでの差別化の方向性は、単純なコンテンツ配信だけは難しいと考えています。ジオコントロールやアドレスベースのACLをIPv6対応することでより高度なサービスができるよう注力していきたいと思います。 注：　 ※1： 総務省｜報道資料｜我が国のインターネットにおけるトラヒックの集計・試算 ※2： 新しい Cache “オープンキャッシング” の実証実験開始（プレスリリース） 　※Ｊストリームコーポレートサイトへリンクします ※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。 【関連情報】 IPv6 Summit in TOKYO 2022 公式サイト 一般社団法人IPoE協議会公式サイト（IPv6地理情報共有推進委員会ページ）

ストリーミング(動画や楽曲のインターネット配信)は、今や日常生活に溶け込んだサービスになっていますが、今回、その歴史について紹介したいと思います。 【執筆者紹介】 鍋島　公章　プラットフォーム本部　エグゼクティブマネージャー 　/　メディアコンサルタント 1995年、米国駐在時にWebサーバの大規模キャッシングについての研究開発を行って以来、インターネットにおける各種メディアの大規模配信について、サービス立ち上げ、研究開発、運用と全方面について関わる。 ストリーミングの現状 まず、動画について国内市場規模(2021年)を見ると、物理レンタルの731億円に対し、ストリーミングを使ったビデオレンタルであるVoDは4,863億円（※1）となっており、圧倒的にストリーミングが大きくなっています。また、ビデオレンタル実店舗の閉業（※2）も進んでおり、ビデオを借りるための一番手軽な方法はストリーミングという時代です。   そして、音楽については、日本ではまだCDの方がマーケットとして大きい状況(CD等約1,279億円に対して音楽配信895億円）（※3）ですが、世界全体を見ると、CD等の物理媒体はすでに音楽市場全体の19.2%しか占めておらず、音楽配信はその3倍以上である65.0%（※4）を占めています。日本ではコレクションとしてのCD所有文化があるため、ストリーミングは音楽産業の主流とはなっていませんが、世界を見るとストリーミングが音楽産業の主流です。   このように、ストリーミングは日常生活に溶け込んだサービスになっています。またトラフィックという視点でも、ネットトラフィックの6～7割程度はストリーミングといわれており（※5）、電気通信業(国内約15.2兆円 ※6)の需要を支えるサービスとなっています   ただし、ストリーミングも急に普及したわけでなく、いろいろありました。今回は、この歴史を振り返りたいと思います。 ストリーミングの歴史 商用ストリーミングの開始（1995～） 商用インターネット接続が始まったのが1995年ごろですが、それとほぼ同時に、米国ではラジオ局のインターネット配信が始まりました。また、国内を見るとイベントのネット配信がこの時期に行われています。単発ものとしては、坂本龍一ツアー(1995,1997)、村山総理大臣念頭所感(1996)が代表例で、現在も続くシリーズとしては、甲子園全国野球大会の中継(1997～)が有名です。また、1997年には、国内ストリーミング企業としてJストリームが創業しました。また、アダルト向けコンテンツサービスであるX Cityがストリーミングを始めました(新しいメディアはまずアダルトからという流れです）。 音楽配信・VoD黎明期（1999年～） ライブ中心に進んでいたストリーミングですが、1999年ごろから新しい動きがはじまります。まず、1999年に、国内初の有料音楽配信サービスであるbitmusicが始まりました。ただし、このころのサービスは、現在主流である楽曲のストリーミング視聴ではなくダウンロードサービスでした。しかし、このインターネット向け音楽配信は10年ぐらい不調でした。一方、ガラケー向けの音楽配信は、2001年にはじまり、2010年ぐらいをピークに1,000億円を超えるマーケットまで成長しました。     動画については、2002年に幾つかのVoDサービスが始まりました。そして、2004年ごろに黒字化を達成するサービスが出ています。ただし、現在のようなサブスクリプションではなく、単話やシリーズ毎の都度課金です。 インターネット黒歴史の時代（2005年ごろ） 一方、2005年ごろはインターネットトラフィックの約半分がP2Pトラフィック（※7）であり、交換されるコンテンツのほとんどが違法な映画や音楽ファイルであったといわれています。また、ユーザー投稿型のサービスとして、YouTubeが2005年、ニコニコ動画が2006年に開始されましたが、これらについても違法アップロードされたコンテンツが多い状況でした。つまり、この頃は、インターネットを流れるコンテンツについて「違法コンテンツ＞正規コンテンツ」という状況で、インターネットは不正コンテンツの流通のためにあるといわれていた時代です。インターネットの黒歴史であったといえます。 本格的な始動（2007年～） 2007年ごろから、現在まで続くサービスが開始されます。まず、2007年、NetflixがコアビジネスをDVDの配送レンタルから、VoD型に切り替えました。そして、2008年には、フジテレビが見逃し配信を開始し、NHKもNHKオンデマンドを開始、そして、Spotifyが音楽サブスクリプションを開始しました。さらに、2010年にはラジオのネット配信であるradikoが開始されています。 そして、主要サービスに（2018年ごろ） 本格的なストリーミングサービス始動時期から約10年が経過した2018年、国内でも有料動画配信の市場規模がビデオレンタルを超えました(1,542億円に対し1,980億円 ※2)。そして、一時期は違法コンテンツの巣窟だったYouTubeについても、タレント事務所やレコード会社による正規チャンネルの増加、ユーザが制作したコンテンツの本格化などが進み、正規コンテンツが増え、広告サービスとして黒字化しています。 これから ビデオレンタルについては、マーケットを置き換えてしまったストリーミングですが、まだまだ伸びる余地があります。例えば、通信と放送の融合による放送コンテンツの通信伝送、日本ではなかなか進んでいないマーケットですが、米国ではCATVのインターネット化(vMVPD)という形で、約1,400万世帯（※8）が通常のインターネットを使い、CTV（コネクテッドTV）やスマートフォンなどを使いCATVを見ています。 そして、現在の国内テレビ広告の市場規模は1.8兆円程度（※9）ですが、ストリーミング広告はまだ0.4兆円程度（※10）しかありません。しかし、ストリーミングは、20代以下において、テレビよりも接触時間が長いメディア（※11）となっています。つまり、この世代が成長するにつれ、接触時間の長いストリーミングに広告費がシフトしていくと考えられます。さらに、ストリーミングは、そのインタラクティブ性やパーソナライズ性を活用することにより、広告のみならず販促マーケット(市場規模約15兆円、広告の2倍程度)の取り込みも可能な技術です。 まとめ ストリーミングは、現在、日常に溶け込んだサービスとなっていますが、産業としてまだまだ伸びる余地があります。しかし、ストリーミングのマーケットや技術を理解している人材は決定的に足りていません。新しく飛び込む価値のあるマーケットだと思います。 注： ※1　映像ソフト市場規模及びユーザ動向調査2021、一般社団法人　日本映像ソフト協会 https://www.jva-net.or.jp/report/annual_2022_5-9.pdf ※2　JVAレンタルシステム加盟店数推移、日本映像ソフト協会 https://www.jva-net.or.jp/report/joiningshop.pdf ※3　生産実績・音楽配信売上実績　過去10年間　合計、日本レコード協会 https://www.riaj.or.jp/f/data/annual/msdg_all.html ※4　 Industry Data、 International Federation of Phonogram and Videogram Producers https://www.ifpi.org/our-industry/industry-data/ ※5　インターネットトラフィック最新事情2022、Interop Conference 2022 https://f2ff.jp/introduction/6151?event_id=conf-2022-06 ※6　2021年情報通信業基本調査、経済産業省 https://www.meti.go.jp/press/2021/03/20220329005/20220329005.html ※7　インターネット政策懇談会第5回資料 ISPを取り巻く状況と提案、社団法人日本インターネットプロバイダー協会 https://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/internet_policy/pdf/080627_2_si5-2.pdf ※8　Total U.S. vMVPD subscribers pass 14M in Q3、FIERCE Video https://www.fiercevideo.com/video/total-us-vmvpd-subscribers-pass-14m-q3 ※9　2021年 日本の広告費、電通 https://www.dentsu.co.jp/news/release/2022/0224-010496.html ※10　2021年国内動画広告の市場調査、サイバーエージェント https://www.cyberagent.co.jp/news/detail/id=27195 ※11　メディア利用の生活時間調査、NHK放送文化研究所 https://www.nhk.or.jp/bunken/yoron-jikan/column/media-2021-02.html

2017年から2018年にかけて、社会問題として注目されたマンガ海賊版サイト「漫画村」をご記憶の方も多いと思います。第三者が著作権者の許諾を取らずにコンテンツを配信する海賊版サイトは年々増加し、2021年にタダ読みされたマンガの総額は1兆円を超えると試算されています。（※1）   2022年7月に函館で開催されたJANOG（※2）50では、海賊版サイト・技術検証チーム（以下、技術検証チーム）による「マンガ海賊版サイトの技術要素と対策法」と題するプログラムが行われました。技術検証チームの一人として、Ｊストリームのインフラエンジニアも登壇しました。   当日は、2018年以来の海賊版サイトに関する動きを振返るとともに、海賊版対策・技術検証チームによる技術的な調査や活動内容が共有されました。   マンガ海賊版サイトでは、CDNを巧みに悪用していることがわかってきています。そこで、今回は、当日のプログラムへ登壇したN.T.さんにインタビューを行い、技術検証チームの活動概要、海賊版サイトにおけるCDN活用の現状、そして今後について話を聞きました。 N.T．プラットフォーム本部 インフラエンジニア（新卒入社・16年目）   学生の時からストリーミングに興味があり、自分で配信サーバを作ってライブ配信していました。自宅にサーバやネットワーク機器があり、そんな中で生活しています。2021年からは、動画プラットフォーム(J-Stream Equipmedia)やCDNサービス(J-Stream CDNext)などの自社開発プロダクトを取りまとめる部署に所属しています。 利用技術：BGP / OSPF / IPv6 / DNS / Cisco IOS / JUNOS / FRR / KVM / VMWare / シェルスクリプト / Ansible / Docker / raspberry pi / お家サーバ / GPU / NDI / SRT / ffmpeg 『漫画村』以降も増加を続ける、近年のマンガ海賊版サイトの動向 ――まず、今回、JANOG50へ登壇した技術検証チームについて、うかがいたいと思います。この活動はいつから開始されたものなのでしょうか？ 活動の開始は2022年4月からになります。マンガ海賊版サイトの対策はそれ以前から行われてきましたが、技術検証チームの発足にあたり、「CDN事業者として技術検証チームへ参加してもらえないか」とＪストリームにもお声がけいただきました。というのも、マンガ海賊版サイトの多くはCDNを利用し違法コンテンツを配信しているという事実があったためです。 JANOG50での様子 技術検証チームは、現在私含め5名です。決してクローズドなものではなく、幅広い技術的知見やアイデアを随時大歓迎しています。 ――なぜマンガ海賊版サイトにCDNが使われているのでしょうか。 CDNとは、そもそも画像や動画などの大容量のデータを効率よく配信する仕組みです。CDNでは、オリジンサーバのコンテンツデータをキャッシュします。それにより、オリジンサーバの場所に関係なく、キャッシュサーバから高速な配信が可能になります（図1）。 【図1】CDNのイメージ図（当日発表資料より） ――本来CDN技術は、コンテンツを高速に配信するために合法的に活用されてきましたが、その技術がマンガ海賊版サイトで悪用されてしまったのですね。 不本意ですが、その通りです。しかも、マンガ海賊版サイトは、広告ビジネスが成立してしまうほどの存在になってしまっています。   例えば、海賊版サイトAの2021年11月の月間訪問者数は、1億8000万でした（図2）。1ページあたりのファイルサイズは、18.59ＭＢで、データ月間流量は15.48PＢになります。このように大規模なアクセスのあるサイトでは、オリジンサーバのみで運用していたのではコスト的に到底見合いません。そこで、多数の配信サーバで構成されたCDNを使うことで、オリジンサーバの負荷を減らし、効率的なコンテンツ配信を実現させているのです。配信品質とコスト最適化を両立させるための役割を、ある種CDN技術が担ってしまっているわけです。 【図2】マンガ海賊版サイトの規模感例（当日発表資料より） ――素朴な疑問なのですが、海賊版サイトの問題は動画や音楽など、電子データであれば、コンテンツを問わず起こり得ます。なぜマンガの海賊版サイトだけがこれだけ大きな問題になっているのでしょうか？ 動画はデータ量やトラフィックが多く、オリジンサーバのコストや配信コストがかさんでしまうので、もし海賊版サイトを運営しても収益性が低いのだと思います。   加えて、YouTubeをはじめとした動画共有サイトは10年以上の年月をかけて、著作者に対する配慮や対策を続けてきたことも、大きな差となっていると感じています（※3）。   一方、マンガ海賊版サイトはデータ量やトラフィックが少なく、現状では歯止めがかけられる方法が少ない。このあたりが大きな違いだと思います。 ――近年起きた大きな事件として、2018年にはマンガ海賊版サイト『漫画村』の運営者が逮捕されました。現在はどのような被害が出ているのでしょうか？ 『漫画村』が運営されていた当時は、有名なマンガ海賊版サイトは数えるほどでしたが、運営者が逮捕されたことで海賊版サイトの認知が広がり、逆に状況は悪くなっています。   『漫画村』が閉鎖された後も国内外で多数の海賊版サイトが生まれ、いまではGoogleなどの検索サイトで比較的簡単にマンガ海賊版サイトにたどり着くことができます。 CDN技術調査で見えてきたマンガ海賊版サイトの巧妙な手口 ――マンガ海賊版サイトのシステム構成はどのようになっているのでしょうか。 マンガ海賊版サイトの基本的な構成は、海賊版マンガの画像ファイルを置くオリジンサーバがあり、それを受けてCDNキャッシュサーバ、負荷分散を行うGSLBがあり、エンドユーザーへ届くという形です。マンガ海賊版サイトの多くは、平均200ページ以下で、10TB以下のものが多いと考えています。現在1,000以上のサイトが乱立している状況です（図3）。 【図3】マンガ海賊版サイトの基本構成イメージ（当日発表資料より） ――1,000以上とはかなりの数ですね。 これには、大きく2つの要素が影響しています。一つは、CDN利用に対する障壁の低さです。マンガ海賊版サイトでは、特定のCDN事業者が利用されていることがわかっています。そのCDN事業者では、利用者の身元確認はメールアドレスのみと甘く、流量や機能を無料で利用できる範囲が広いんです。悪用しようとした人物は、身元を明らかにせずとも、簡単にCDNを利用できてしまいます。   2つ目の要素は、多くの海賊版サイト用のCMSテンプレートの存在です。仮に摘発されたとしても、テンプレートを使ってすぐに新しいサイトを作り、次々と別のサイトへ移動して摘発を免れていると想像できます。 ――話をうかがうと、マンガ海賊版サイト側は、CDNをはじめとした技術的な知識や儲けのノウハウを持っている印象ですね。 CDNのことはかなり理解していると思います。例えば、調査活動の中でわかったこととしては、とあるマンガ海賊版サイトで使われているJavaScriptのプログラムを確認したところ、マンガ画像ファイルを複数のCDNへ割り振るような制御をしていました。先述のCDN事業者の無料枠を悪用しながら、複数のCDN契約を行い、キャッシュサーバでアクセス分散させているのです。そうすることで、マンガ海賊版サイトは、大規模なアクセス集中があった場合でも、オリジンサーバへの負荷を回避し、コスト抑制をさせること可能になります。 ――逮捕をきっかけに海賊版サイトは下火になったと思っていましたが、逆に勢いを増しているのですね。 オンプレミスでのCDN構築・運用から得られる知見を問題の解明に活かす ――これらの違法サイトに対して、技術検証チームはどのような活動をしているのでしょうか？ 活動は、大きく分けて「調査・対策・啓蒙」の3つを主軸にしています。JANOGでの発表時には、登壇者4名が各自の担当部分を中心に情報共有と問題提起を行いました。 まず「調査」ですが、海賊版サイトの運営者がどういうシステムやネットワークを使い、どのような手段で儲けているのかなどを調査しています。   次に「対策」は、裁判や広告パブリッシャ―への協力・連携の他、検索などのシステム面での対応などが挙げられます。事業者間での海賊版サイトのキャンペーンや、検索サイトでの啓蒙バナー設置などの展開を行ってきていただいた例などもあります。   最後に「啓蒙」ですが、エンジニアを含めたインターネットユーザー全般に「海賊版サイトは深刻な問題なんです」と伝え、「一緒に解決してくれませんか？」と協力を呼びかける活動です。今回のJANOGへの登壇も啓蒙活動の一環です。   実は今回のインタビューでは、各登壇者の方のお話を詳しくご紹介することも考えていたのですが、一緒に登壇された さくらインターネットさんが、全体レポート をまとめてくださっているので、ぜひそちらをご覧いただければと思います。具体的な啓蒙活動内容やCDN以外の調査活動、そして調査結果に基づくサイトの同一性判別や広告パブリッシャ―との連携といった対策活動まで、とてもわかりやすく、簡潔に書かれたレポートです。 ――Jストリームとしては3つのうち、どこに比重を置いているのでしょうか？ 現在は「調査」と「啓蒙」に比重を置いています。特に「調査」は普通にインターネットを使っている方々には見えない領域であり、とても地道な活動ですね。 JANOG50でのCDNに関する発表の様子 ――Jストリームのアセットやノウハウが調査へ活かせたケースはありますか？ Ｊストリームは、オンプレミスで自社のCDN構築と運用を行っています。そのメリットを今回の活動へ役立てることができました。   例を3つほどあげますと、一つは、CDN構築を詳しくわかっているため、マンガ海賊版サイトの仕組み理解について仮説が立てやすい点ですね。Ｊストリームには、インフラエンジニア以外にもフロントエンド、バックエンドをはじめとした幅広いエンジニアが所属しています。様々な職種の開発メンバーと話す中で得られたヒントは、多数ありました。   二つ目は、調査で必要なサーバやネットワークを社内調達しやすいことです。調査においては、自社が持つオンプレミスのインフラ環境を柔軟に利用することができました。   そして、三つ目が、大規模なコンテンツ配信における、数多くの実績をもとにした肌感ですね。Ｊストリームでは、幅広い業種や利用シーンでご利用いただいています。また、自社CDNは構築だけでなく、運用も社内エンジニアが行っています。ですので、調査データからキャッシュのヒット率を見れば、サイトの規模感がおおまかにわかります。これはマンガ海賊版サイトの相手を知る上で重要な情報です。   Ｊストリームが持つ環境や知見を活かし、自社だからこそできる役割を担い、大きな社会問題の解決に向けた取組みだという実感がありますね。 ――とてもやりがいが感じられることですが、解決が難しい問題ですね。「IT業界として今後こうするべき」という方針はあるのでしょうか？ この問題は特定の国の、特定の事業者だけが動いて解決する問題ではありません。国や企業の垣根を超えて、様々なエンジニアが知恵を出していく必要があると思います。   インターネットは様々な技術者が公共の利益を考えて構築してきたものです。だから、今回の海賊版サイト問題にも「各事業者が協力しましょう」「業界内でガイドラインを作って対応しよう」という方向性で進んでいます。技術検証チームもワールドワイドにインターネットコミュニティで協力を呼びかけてきました。   今回、JANOGで問題提起をしましたが、技術検証チームとしては、この問題は他のカンファレンスでも数多く話していきたいと考えています。また、今後は海外への発信なども必要になるのではという話もしています。 CDN業界へ恩返しがしたい ――ここまでお話を聞いていると、とても地道で時間もコストもかかる活動だと感じました。Jストリームはなぜ「マンガ海賊版サイト」の対策活動に参加しているのでしょうか？ Jストリームは、1997年に世界初の動画配信専門会社として誕生し、CDN事業を長年手がけてきました。国内CDN事業の先駆者としての自負もあれば、社会的責任もあると思います。マンガ海賊版サイト問題については、CDNが悪用されていることが明白な以上、我々も最大限の貢献をしていく必要があると思います。それは、技術的な貢献ももちろんですが、社会から「漫画海賊版サイトは放置できない問題である」という社会の空気を作ることにもつながると思います。 JANOG50での質疑応答の様子 ――なるほど、「社会の公器」としての責任について話しているのですね。最後に、N.T.さん個人のモチベーションについて教えてもらえますか？ 私はCDNでコンテンツ配信をやりたくてこの会社に入りましたし、今までIT業界で働かせてもらった恩があります。対策活動はそういったことに対する恩返しだと思っています。   インターネットというエコシステムは誰かが取りまとめるものではなく、様々なエンジニアがそれぞれ知恵を出して努力しながら構築されてきたものです。私はそういったエコシステムのなかで育ってきたので、少しでも業界の発展のために尽くしたい。Ｊストリームも同じ想いで、IT業界が今後も繁栄していくための活動ととらえています。ですから、今回私が担当している活動も、社内では業務の一環であるという理解のもとで行っています。 ――IT業界の一員として、エコシステムに貢献したいという想いがあったのですね。とても地道な活動ですが、コンテンツ業界やIT業界が繁栄していくために重要な取組みであることを再認識しました。対策活動により、解決の道がさらに開けていくことを期待しています。 注： ※1： 文化庁著作権科の調査書より https://www.bunka.go.jp/koho_hodo_oshirase/hodohappyo/pdf/93713501_01.pdf   ※2：JANOGとは、JApan Network Operators’ Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです   ※3： 利用許諾契約を締結しているUGCサービス一覧 https://www.jasrac.or.jp/news/20/ugc.html ※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。 【関連情報】 マンガ海賊版サイトの技術要素と対策法 JANOG50 Meeting 　JANOG公式サイト※当日の講演資料も公開しています JANOG50「マンガ海賊版サイトの技術要素と対策法」レポート 　さくらインターネット株式会社「さくらのナレッジ」

エンジニアのF.O.です。 普段はＪストリームの自社CDNサービスであるJ-Stream CDNextの開発・運用チームに参画しています。CDNのEdgeサーバの機能追加や、お客様向けの管理コンソールの開発、日常的に発生するメンテナンス作業など、幅広くサービス運用に関わっております。 この講座では、図解をしながら、わかりやすくCDNの仕組みとそこで使われている技術を解説していきたいと思います。  動画配信や大規模ファイル配信に特化したCDNの機能 第1回では、CDNの基本的な仕組みやメリットについて解説しました。CDNは様々な機能を持っています、動画の場合はどのような機能を使えば有効なのか迷うこともあるのではないでしょうか？ 第2回は動画配信のセキュリティーを高めたり、大容量はファイル配信を効率化するためのCDNの機能について解説していきます。 認証配信 認証配信の技術を使うことで、動画コンテンツを配信したいユーザーを制限することができます。 動画コンテンツへのアクセス権をユーザー単位で認証サーバーで管理することで、指定したユーザーのみに動画コンテンツの再生を許可するトークンを発行し、視聴を制限します。また、動画ファイルの暗号化を組み合わせることで、より高度なセキュリティーを実現しています。 利用シチュエーション 視聴にチケットの購入が必要であったり、会員制のWebサイトで、会員になったユーザーにのみ動画を公開したい場合など、動画コンテンツを配信したいユーザーを限定したい場合に有効です。 仕組み 今回は、現在の動画配信でよく使用されている、「HLS配信」の場合を例に解説します。 ※HLS：HTTP Live Streaming   ①ユーザーから動画再生要求があった場合、「会員管理サーバ」は動画コンテンツ配信用の認証トークンをユーザーの端末（動画プレイヤー）に返却します。 ②端末は「認可サーバ」にアクセスし、認証トークンを使用して「Master Playlist」や「Media Playlist」を取得します。 ③端末は「Master Playlist」や「Media Playlist」に記載のURLにしたがいCDNから暗号化された動画ファイル（TSファイル）を取得します。 ④端末は暗号化された動画コンテンツファイルを複合し動画を再生します。 Geolocation制限 ジオロケーション（Geolocation）とはユーザーの位置情報を扱うことのできる技術です。 地球、土地を表す単語「Geo」と位置、場所を表す単語「Location」を組み合わせた造語になります。ジオロケーション技術を使うことで、ユーザーの地理的な位置を取得して利用する制御が可能になります。 位置の検出には、GPSを利用した方法や無線LANのアクセスポイントなどの電波強度を利用した方法など様々な方式が存在しますが、ここではインターネット上のIPアドレスを利用した方法を解説します。 ジオロケーションを使用することでCDNにおいても、位置情報を利用した制御が可能です。 利用シチュエーション 例えば、著作権上の理由などで配信する動画コンテンツについて、日本国内のユーザーにのみに視聴を許したい、海外からの視聴を国別で制限したい。といった時など、動画コンテンツを配信したい地域を限定したい場合に有効です。 仕組み ①ユーザーの位置情報を検出するための情報としてアクセス元のIPアドレスを取得します。 ②CDNのシステム内にはこのIPアドレスと国や都市を紐づけた辞書データを保有しており、ユーザーのアクセス元のIPアドレスと照会することで、ユーザーがアクセスしている国や都市を特定します。 ③特定した国や都市の情報を元にアクセスの許可もしくは拒否を制御します。 ※辞書データは定期的に更新されており、IPアドレスと位置情報の流動的な対応変更が発生してもCDN上のシステムに反映されるようになっています。また、辞書データをシステム内部に持つことで高速な位置の判定を実現しています。     RangeCache ファイルサイズの大きい動画コンテンツをダウンロードさせるような配信方式の場合、RangeCacheの技術を利用することで、動画コンテンツを小さいサイズに分割してCDNにキャッシュさせることができます。 ユーザーが必要とするファイルの一部分のみを小分けにしてオリジンにリクエストしキャシュできるため、初回（１人目）のアクセスですぐにキャッシュが生成され、次回（２人目以降）のアクセスでキャッシュを利用できるようになり、キャッシュの利用効率が上がり、オリジンサーバ側の負荷を低減することができます。 また、mp4のプログレッシブダウンロード再生では、動画の途中にシーク移動した場合でも、動画全体を読み込む必要がなく、部分的な読み込みで再生できるようになるため、ダウンロードの待ち時間を削減することができます。 利用シチュエーション 例えば「.mp4」の動画ファイルを直接ダウンロードさせたいといった、ファイルサイズの大きいコンテンツを配信したい場合に有効です。 動画ファイル以外にもサイズの大きい「.zip」圧縮ファイルなどの配信などにも利用できます。 仕組み ①HTTPのRangeヘッダフィールドを利用して取得するデータの範囲（サイズ）を指定してオリジンサーバにコンテンツを要求します。 ②オリジンサーバから指定したデータの範囲のコンテンツを取得します。 ③指定した範囲で分割されたコンテンツをCDNにキャッシュします。 ④ユーザーはCDNから分割されたコンテンツのデータを連続的に取得することで、元のサイズの動画を視聴することができます。 ※オリジンサーバー側でRangeリクエストがサポートされている必要があります。     ※記載内容は、公開当時のものです。その後、状況が変化していることがあります。 【関連情報】　※別サイトのＪストリームコーポレートサイトへリンクします。 J-Stream CDNext サービス紹介ページ　

前編 では、3人のエンジニアに登場してもらいライブエンジニアの業務内容、魅力について語りました。後編では、よく質問いただく「ライブエンジニアの働き方」について、3人が一問一答いたします。 Q1：ライブ現場対応に関する1か月の稼働はどのくらいですか？ Y.I. 株主総会や学会シーズンや年末などの繁忙期と通常期はありますが、一人あたりの現場対応は通常期で月10回くらい、繁忙期で月12回です。   現場判断でなく、組織として社員の稼働数を決め、パートナー企業の協力体制含めた業務コントロールを行っています。正直、以前は1週間出ずっぱりということもありましたが、今はなくなってきましたね。 Q2：現場は何名くらいの体制で動くのでしょうか？ K.N. 案件全体でいうと、まず最少で、ライブエンジニアが1名とライブディレクター1名の計2名体制です。案件により営業担当や顧客対応担当が同行することもあります。     医薬業界系での一般的なWeb講演会ですと、ライブエンジニアは1、２名で対応することが多いです。映像のスイッチングと音声のミキサー調整、ライブエンコーダーの監視などを一人で設定・設営します。ここは、役割分担が明確な映像制作業界とは大きく違うところですね。     大規模であったり、複雑な構成になるものは増員します。例えば、複数会場で出演者が大勢いたりとか、あとは会場以外の場所から出演者がいてオペレーションを遠隔操作するようなケースです。この場合は、現地の映像伝送、遠隔の会場操作、音声管理などで必要な箇所に専任エンジニアがつくことになります。 Q3：一人でのエンジニアリング業務は、正直、荷が重くありませんか？ T.H. 一人で何役もこなすのは、責任も重大ですし、緊張しますので楽なことではありません。でも組織だけでなく、個人にとってもメリットは大きいんですよ。一人ひとりがオールラウンドに成長するからこそ、逆に案件全体を理解しながら各工程のつながりを考えて確実に進めることができます。   そして、「この案件一人じゃ無理だな」という判断も各自で的確にできます。その場合は、組織全体で再考します。それにより組織全体でのスピード感もあげることができます。 Q4：案件があるときは、終日現場対応に集中するのでしょうか？ Y.I. 案件次第です。 近郊の案件であれば、フレックス勤務で時間調整もしつつ午前中の業務をこなし、夕方ぐらいに現場に入りライブ対応を行い、20時か21時には撤収して帰宅。医薬業界系の講演会ですと、基本的に18時や19時くらいからのスタートが多いです。それ以降の遅い開始であればシフト出社みたいなこともあります。   遠方になると、移動が入りますので一日がかりになりますね。朝、飛行機に乗って、夜ライブ対応が終わりホテル宿泊し、翌朝戻るというのが基本的なスケジュールになります。コロナ禍での現場対応では、感染対策としてタクシー移動が推奨されていました。   月にもよりますが、出張はコンスタントにありますね。国内だけでなく海外出張もあります。各地のパートナー会社さんとも連携していただきながら、遠方の案件対応も効率的にできるような動きも進めています。 Q5：マニュアルやナレッジ共有はどの程度されていますか？ K.N. ライブ現場の基本的な仕様やサーバ設定などはマニュアル化し、OJTで確実に習得していきます。例えば、基本の機材構成であったり、冗長化の仕組みなどです。エンコーダーやサーバは必ず冗長化をしていて、メインが落ちてもバックアップを継続するので、視聴者側には瞬断することなくライブ映像を届けられるようにしています。   全案件に共通するような大きなルールは即座に変わるものではありませんが、絶えず現場での情報共有は行われています。個人レベルで共有していたものが、その後公式マニュアルに反映されることも多々あります。現場でのヒヤリハットと対処法、現場のチェックシートとかも、随時手を加えています。   本部全体には、ライブエンジニアをはじめ多様なエンジニアが所属しており勉強会も活発です。幅広い職種の専門家がいますので、学びのテーマも様々です。周知や参加はもちろん、講師への立候補も含め職種の垣根はありません。その他、自己研鑽や資格取得への補助制度や交流型のビジネススキル勉強会などもあります。 Q6：普段のミュニケーションはどのような感じですか？ T.H. まず、業務関連でのコミュニケーションですが、テレワークの導入でWebでの会議やコミュニケーションが進み、スピード感は上がっていると思います。毎週ある部会は、今は完全オンラインです。そのため、移動しながら「聞く専門」で情報のキャッチアップすることも多いです。出社メンバーともTeamsとかでやりとりして、移動先など外からでも問題なく進められています。   雑談を含めたコミュニケーションについては、結構活発だと思います。ライブエンジニアだけで集まって機材構成についてディスカッションしたり、ノウハウ共有することは多いですね。私自身も、新規性のある案件レポートや、見積もりや図面などをTeamsなどで共有していますね。   コロナ禍前は、ライブ機材倉庫がコミュニケーション広場みたいなものでした。大阪勤務の私も東京出張の際は本社の倉庫に入って、倉庫メンバーと「元気？」「新しい機材入ったの？ もう触った？」みたいな話をよくしていました。   その他にも本部全体での懇親会などもあり、最近はオンライン開催も取り入れたりしています。 Q7：社内の雰囲気はどうですか？ T.H. 本部全体の雰囲気としては、教えたがりでコミュニケーション好きな人が多いですね。 私が入社した時に、同じ部署にネットのスペシャリストがいまして、質問したら山ほど回答が出てくるのですが、当時の自分には内容の八割方わからなくて。。。 でも根ほり葉ほり聞くと、その人は言葉を何度も変換して丁寧に教えてくれ、私の疑問が解消するまで徹底的に付き合ってくれました。同じようなマインドを持つ人は多いと思います。 その同僚は、今は部門が違いますが、最近では「 J-Stream Cloud 」という自社の共通開発基盤の構築にも関わっています。当時とても助けられた記憶があります。 Q8：入社してからライブエンジニアになるまでのフローを教えてください。 Y.I. 新卒入社ですと、まず1、2年目は現場のオペレーションを一人できることを目指します。具体的には、機材の準備から始まり、メンテナンス、機材組み上げなどをOJTで経験していきます。内容により社内で行うOJTもあれば、メンターと一緒に現場へ赴き行うものもあります。6月に本配属後、10月にはライブエンジニアとして一本立ちです。   知識だけでは現場は乗り切れませんので、最初の1カ月はみっちりOJTです。私は新卒入社してライブエンジニアを担当しましたが、特に最初は大変でした。週の半分くらいは現場に出て、機材のことなどを実務面から覚えていきました。   3、4年目になると、先輩から引き継いだ案件や定例案件などを中心に自身の担当案件を持つようになります。仕様に関する打ち合わせや会場の下見も一人で行います。   5年目以降からは、新規案件を一から要件定義するところから担当します。そのほかにも、新しい機材やシステムの導入や検証なども手掛けます。   中途入社の場合は、必ずしも上記の通りとは限りません。前職までの経験やスキルを最大限生かせるように、担当業務や実施体制を適宜相談しながら進めていきます。   私やK.Ｎ.さんも動画配信については未経験の新卒入社でした。毎年新入社員も配属され、随時中途社員も加わっていますので、すぐになじんで業務のスタートを切ることができると思いますよ。   現在、ライブエンジニア、ディレクター、プロデュースなどのライブ現場を担当する社員は新卒・中途含め約30名で、女性も活躍しています。 ――今回は、前後編の2回にわたりライブエンジニアについてご紹介しました。珍しい職種の一つだと思いますが、ライブエンジニアの魅力とやりがい、そして未来を作るために動き出している楽しさを少しでも感じていただけたらうれしく思います。

IntstagramやTikTokをはじめ、いまはスマホアプリでも簡単にライブ配信ができる時代。 Ｊストリームでは1997年の創業時から企業向けにライブ配信サービスを提供しているが、そこではライブエンジニアという存在が重要な役割を担っている。今回はライブエンジニアの役割と仕事の魅力、現場でのこだわりについて、ライブに魅了された三人のエンジニアに語ってもらった。 同時14会場、Zoom連携、海外中継… デジタルマーケティングシフトでビジネス向けライブは高度化・複雑化 ―― 今日はライブエンジニアに関するインタビューです。コロナ禍の影響もあり、ビジネスシーンでもインターネットライブの活用が急拡大しています。まずは、Jストリームにおけるライブエンジニアの業務内容を教えてください。 Y.I. ライブエンジニアは、ライブ配信にかかわる技術周り全般を担い、大きく3つの業務があります。   一つ目はオペレーション業務です。図1はＪストリームのライブ配信サービスの全体像です。この図でご説明しますと、ライブエンジニアは、ライブ現場で映像や音声ソースを受け取りエンコードし、ストリーミング配信するためのデータ転送部分を担います。   具体的には、必要な機材や会場設営を含めた環境手配、サーバ設定、エンコーディング、サーバへのデータアップロードなどです。映像ソースは一会場からの場合もあれば、複数の会場から受け取り、切り替えながら配信することもあります。   【図１】Ｊストリームライブ配信サービスの全体像 Y.I. 二つ目は、仕様策定業務です。お客様や営業・ライブディレクターから挙げられた新規性の高い要望に対して技術的仕様や解決方法を考え、確定させます。   三つ目の業務が、新技術への対応です。これには自社のライブサービスに付随した検証も含みます。 ――最近ではどんな現場があるのですか？ T.H. エンターテインメントのイメージが強いインターネットライブですが、実は、ビジネス系での活用は非常に多いんです。Ｊストリームで一番多いのは医薬業界での講演会です。医薬業界でのデジタルマーケティングシフトのなかで、ライブ講演会は重要なコンテンツのひとつになっています。   医薬業界では、遠隔操作で複数の病院の手術室と会場を結び配信するような事例もあります。また先日は、 医学系学会の総会で最大14会場分のライブ配信の現場を担当しました 。私は、現場統括として、パートナー企業さんにも協力いただきながら、すべての会場のプログラムを滞りなくライブ配信できるようディレクションを行いました。 K.N. ライブ配信と一言で言っても、現場の様子は一律ではありません。会場はホテルや会議場、スタジオなど様々ですし、海外出張して対応することもあります。   全国各地をZoomやTeamsなどを使い全国各地をつなぐような案件も増えているんですよ。 年間2,600件の実績をもとに日々強化を続ける「失敗しないライブ」体制 ――ライブ現場対応を手掛ける会社さんは数多くあります。Ｊストリームならではの強みや特徴はどこでしょうか。 Y.I. 一言で表現するならば「失敗しないライブ」のための体制と環境を社内で完結させていることです。3つの特徴をあげて、もう少し詳しくご説明したいと思います。   まず最初に挙げる特徴は、ライブ現場対応だけではなく自社構築したインフラを保有していることです。ＪストリームではCDN(Content Delivery Network)というネットワークのコンテンツ配信を最適化できるインフラを持っています。大型のライブや、SNSなどで瞬間風速的にアクセス集中する状況に対しても、CDNを活用することでサーバをダウンさせることなく、スムーズなライブ配信を続けることができます。自社でCDNを構築している企業は、全国でも数少ないです。   ライブエンジニアはインフラ構築した自社のエンジニアと直接相談したり、質問をしたりして、確実に必要な設定を行います。「ライブ現場は完璧だったが、視聴トラブルが起きた。どうもインフラに問題が発生したようだがよくわからない」――実は、こういう例は少なからずあります。しかし、Ｊストリームならばライブ配信全体フローのどこに原因があるのかを究明して、スピード感を持って解決することができます。   次に、社内に幅広い領域のエンジニアがいることです。私たちライブエンジニアのほかに、動画技術、フロントエンド、バックエンド、インフラ、ログ解析をはじめとしたさまざまな専門家がいます。そのため、難易度の高い案件や新規性の高い案件であってもスムーズに社内で連携して対応することが可能です。 T.H. 三つ目の特徴としては、膨大な実績に基づくノウハウです。   20年以上にわたって積み重ねられたライブ現場で「失敗しないための」ノウハウをまとめ、組織として安定した品質を維持できるようにしています。実績には、世の中の誰もが知るような国際的なイベントや、前例のない案件も多数含まれています。   Ｊストリームでは、現在、年間2,600件以上のライブ配信実績があります。私が中途入社した時に一番驚いたのはそこでした。扱う案件の大きさと数の桁が違うなと。そこから得られる経験とノウハウは貴重な会社の財産です。Ｊストリーム全体での実績と一人の経験値では、比べ物になりません。   お客様がＪストリームをご用命いただく大きな理由のひとつが、「ライブ配信を落とさない、途切れさせない」ということです。その期待に応え、どんな大規模な案件であろうと、複雑な現場であろうと、確実にライブ配信できる仕様に落とし「失敗させない」ことは、実はとても高度なことだと自負しています。 ――話をうかがうと、ライブエンジニアには現場対応に関すること以外にも幅広い知識が必要そうですね。 Y.I. そうですね。ライブの現場に関することだけでなく、その裏側のインフラ部分や開発に関する幅広い知識が求められますね。海外も含むような案件では、自社CDNと海外パートナーのインフラと連携するようなこともあります。特殊な案件や大規模な配信については、インフラエンジニアと相談しながら必要なネットワークの手配も行います。   お客様と直接対面しているエンジニアは私たちライブエンジニアですから、責任は重大です。前例がないケースを含め難易度の高い現場が多いですから、きっちり詰めて形に確実に進めていくことが必要です。 T.H. 配信となると、抑えるべきポイントは映像作りだけではないですしね。   ただし、「ネットワークや開発の知識はない」という方も、心配する必要はないと思います。実際、私もそうでした。後述しますが、マニュアルや教育フロー、ノウハウ共有も頻繁に更新しており、20年以上のノウハウが蓄積されています。   育成スピードもあがってきており、実力をつけて若いうちから大手企業の案件を手掛けるチャンスもたくさんあります。Ｊストリームには、制作会社やイベント会社からの転職組も多いんですよ。 K.N. ライブ配信はまだまだ成長領域ですから、映像やイベントというコンテンツのところだけの現場経験ではなく、インフラへの理解があることは、キャリア面においても価値ある経験だと思います。 ライブを極めるほか、インフラや開発など幅広いキャリアパスを歩める環境 ――キャリアの話も出てきましたので、詳しくうかがっていきたいと思います。ライブエンジニアでの経験を経て、その後のキャリアパスにはどのような選択肢があるのでしょうか。 Y.I. 大きくは、ライブのプロデュースへ進む方向性と、開発へジョブチェンジする方向性がありますね。開発へのジョブチェンジは、同業他社ではなかなかないＪストリームのユニークなところかもしれません。   ご紹介しましたように、Ｊストリームには幅広いエンジニア職種がありますので、インフラ部門へ異動したり、バックエンドやフロントエンドエンジニアとして開発部門での経験を積むことも可能です。 ――ジョブチェンジは、特殊なことではないんですか？ K.N. ジョブチェンジについては、組織も可能な限り柔軟に考えてくれています。   実は、私は新卒入社でライブエンジニアからライブディレクターになり計3年したところで、2020年よりインフラ部門へジョブチェンジしています。   ライブ現場担当としてインフラ部門とやりとりする中でサーバ設定などに興味を持ち、自分のキャリアの幅を広げたいと異動願いを出しました。 T.H. 私は、中途入社で5年間、ライブエンジニアとライブディレクターを経験し、1年間開発部門へ異動しました。ジョブ型で採用されたので、正直、よく行かせてもらえたなと思いました。   異動を希望したきっかけは、現場を進めるうえでお客様から新しい技術要素への相談を受け、開発部門への問い合わせが増えたことでした。問い合わせ先の開発部門では、回答にしても、仕様にしても万全の用意をしてくれるわけです。でも「用意されたものに乗っかっているだけなのでは」という気持ちが強くなり、それでは自信が持てないなと、開発への異動を決意しました。 ――異動は、せっかく積んだ知識や経験を手放す損失だとは思いませんでしたか？ T.H. むしろプラスです。 ライブエンジニア業務範疇ではDockerやKubernetesを触ることも知ることもありません。Ｊストリームでは、モダン開発への移行を進めており、動画に限定せず、世の中のトレンドに沿った標準的な技術での開発経験を積むことができます。開発のトレンドがわかると、それをライブに応用したり、ライブ現場での問題解決のヒントにすることができます。     実は、私は開発経験を経てその後、再度ライブ現場へ戻ってきました。開発部門業務を行っているなかで、「作りたいもの」よりも「使えるもの」という意識が強い自分に気が付きまして。 機材や会場の環境など今ある状況を、目的に沿って最大限機能させるためにはどう活用するかーーこれは、ライブ現場対応で目の前のお客様の声を直接うかがうなかで培った、自分らしいユーザー視点なんだと思いました。「自分は、お客様の前に立って、案件をプロデュースしていくのが好きで楽しいんだな」と再認識したんです。 ――ライブ現場での経験をもとに、それぞれがＪストリームという環境を生かしてキャリアの幅を広げているんですね。 お客様の大切な1件1件のライブのために、組織も個人も変革の時に ――さて、前編最後では、ライブエンジニアの未来について伺いたいと思います。 Ｊストリームのライブエンジニアの3年後はどうなっていると思いますか？ Y.I. 現状のライブ案件には2種類の現場があります。 ひとつは仕様が定型化され運用比重が高い現場、そしてもうひとつは新規性が高く仕様策定の比重が高い現場です。   前者については、より多くの需要に応えられるよう、すでにパートナー企業との連携を含め進めています。ここでのＪストリームのライブエンジニアの役割としては、プロデュース側に近くなります。 後者については、ライブ配信業界における「DIT」のような役割ですね。 T.H. 映像業界では、DIT（Digital imaging technician）という職業があります。映像制作の風上から風下まで全部をコンサルティングするような役割です。数多くの実績のあるＪストリームならばライブ配信業界におけるDITの立場を担えると考えています。   多様化・高度化する案件に対して、目的やコンテンツに最適なエンコーダーや構成、プレーヤー選択等を行い、新規性の高い案件ニーズに的確に応えていければと思います。 K.N. 新規性の高い案件で得た知見をマニュアル化して汎用的なものにしていったり、新機能やサービス開発を手掛け新たなサービス提供へつなげていく。前者と後者がうまく循環していくことで、お客様にとってライブコミュニケーションが、より便利で、身近なものになるといいですね。   ライブ需要の増大で、Ｊストリームとして多くのライブ現場ニーズにお応えするためには、ライブエンジニアの立ち位置も変わらざるを得ません。   まだないライブエンジニアの新しい形を自分たちが一から定義して、開拓し、形にしていく途中ですので、「こんな未来を作りたい」という方にはぜひ仲間に加わっていただきたいですね。 ――言葉のはしばしから、「皆さん、ライブが好きなんだな」という空気が伝わってきます。 Y.I. 好きですね。自分が配信した映像や音声をお客様が確認され、リアクションを直接目の当たりにすると、やはりライブエンジニアの仕事はいいな、楽しいなと再認識します。 T.H. ライブ当日、現場へ到着すると、最初はお客様も緊張されていて、「無事終わるかな」と心配されていることもあります。   お客様の心配を払拭できるように、1件1件の現場について深く考えて仕様に落とし、計画を立て、動く。   終わった後は、お客様がそれこそネクタイを緩めたり、ジャケットを脱いだりして、リラックスした雰囲気で「ありがとうございました」と会場を後にされる姿を見られるのは喜びですね。   年間2,600件なんて言っていますが、ひとつひとつがお客様の大事なライブです。これからもひとつひとつを確実に、精度高く対応していきます。 ―― 後編 では、スケジュールや体制、ナレッジ共有、普段のコミュニケーションなど、具体的な働き方についてうかがいたいと思います。ありがとうございました 【関連情報】　 Ｊストリーム導入事例：ライブ配信サービス

はじめまして、エンジニアのF.O.です。 普段はＪストリームの自社CDNサービスである CDNext の開発・運用チームに参画しています。CDNのEdgeサーバの機能追加や、お客様向けの管理コンソールの開発、日常的に発生するメンテナンス作業など、幅広くサービス運用に関わっております。 この講座では、図解をしながら、わかりやすくCDNの仕組みとそこで使われている技術を解説していきたいと思います。 第１回目は CDNの仕組みと技術の基礎 についてご紹介します。 CDNとは？ CDNとは「Content Delivery Network」 の略です。その名前から想像できる通り、多数のコンテンツ配信サーバと配信ネットワークによって構成されたシステムを利用することで、インターネットを利用するユーザーに対して効率よく高速に動画・画像・文字データなどの「コンテンツ」を配信する仕組みです。 普段インターネットで何気なく閲覧しているWebサイトや動画サイト、またはスマートフォンのアプリなど、多様な用途において実はCDNの技術が使われています。 CDNの構成 CDNを用いた配信では主に、「オリジンサーバ」「キャッシュサーバ」「ロードバランサ」で構成された仕組みを用います。元のデータを保有する「オリジンサーバ」から配信サーバ拠点にある「キャッシュサーバ」にデータをキャッシュし、キャッシュしたデータをオリジンサーバに代わりユーザー向けに配信します。 「キャッシュサーバ」は複数のサーバを束ねたクラスタ構成になっており、配信サーバ拠点に設置されています。CDNの配信サーバ拠点はPOP（Point of Presence）とも呼ばれ、例えば関東や関西といった地理的に離れた場所や、ネットワーク的に配信効率が良い場所にあるデーターセンターを拠点として複数展開されています。 CDN関連用語の解説 オリジンサーバ 配信するデータの元となるオリジナルのコンテンツ（動画・画像・文字データなど）を格納しているサーバ   データセンター 物理サーバ機器やネットワーク機器をまとめて設置・収容している施設 電源・空調・インターネット接続といったIT機材に必要な設備が用意されている 火災や地震などの災害が発生しても被害が最小限になる対策を施した建物構造となっている CDNでは関東や関西など地理的に離れた複数の拠点にデータセンターを分散して利用している   キャッシュサーバ 動画や画像などオリジンサーバから配信されるデータを複製し格納している ユーザーからリクエストがあった場合にはオリジンサーバに代わってエンドユーザーに応答する   GSLB（Global Server Load balancer） 地理的に分散する複数の拠点間でサーバのロードバランシングを行う広域負荷分散システム   DNS（Domain Name System） ドメイン名(example.comなど) とコンピューターが接続に使用する数字の IP アドレス (203.0.113.0など) を相互に変換するシステム ユーザーからのリクエストは各ユーザーが利用している（例えばプロバイダーが提供する）DNSサーバを経由してCDNへ誘導される   IX（Internet Exchange Point ） インターネットプロバイダーとデータセンターの相互接続ポイント CDNではデータセンターから複数のIXに接続されインターネット事業者と経路交換を行っている   ユーザー PCやスマートフォンなどの端末でコンテンツを視聴するエンドユーザー コンテンツ配信の高速化 CDNを利用しない場合 CDNを利用する場合 CDNを利用することで、ユーザーにコンテンツを高速に提供することができます。   CDNを使用しない環境では、オリジンサーバにユーザーからのリクエストが集中してしまいます。そのため、オリジンサーバの処理能力を超えるようなリクエスト数があった場合に処理待ちが発生してしまい、結果的にコンテンツの配信が遅延したり、オリジンサーバからエラーが返され閲覧できないといった問題が発生する場合があります。   一方で、CDNを使用した環境では、ユーザーからのリクエストの大半はCDNのキャッシュサーバへ向けられ、キャッシュサーバが保持しているキャッシュを各ユーザーに返します。キャッシュサーバは複数台のサーバが用意されており、分散してデータの送信を行うために大量のリクエストを受け付けることができます。通信回線においても大容量のデータを送信できる回線設備になっているため、コンテンツを高速にユーザーまで配信することが可能になります。   また、オリジンサーバはキャッシュサーバにコンテンツをキャッシュする時のみにデータの送信が限られるため、オリジンサーバの負荷が軽減されます。このことからオリジンサーバのスペックが低い場合でもCDNを利用することで配信のパフォーマンスが改善されます。

企業のクラウド活用が進む中、Ｊストリームでは20年以上にわたりオンプレミスでのネットワーク構築にこだわってきた。 「何があろうともサービス提供を継続できる仕組みを作る――そのために思い込みをゼロにして、どうしたらできるかを考える。予測して、調べて、選定して、セットアップして、つなげて……要は全てをコントロールしたいんですよ」。 そこで自身の技術力が試される、と彼らは語る。今回は「ゼロベース思考」で設計し続ける2人のエンジニアに、オンプレミスでのネットワークの魅力について聞いた。 どんな不具合も調べあげ、解決し、事業継続性を担保する ―― Ｊストリームでは自社構築ネットワークにこだわり、動画配信サービスを提供してきました。まずは自社のインフラの特徴からうかがいたいと思います。 N.T. はい、Ｊストリームが持つ動画関連のインフラは、ネットワークやストレージ、サーバなど汎用的なものから、ハードウェアエンコーダや映像伝送など動画に特化したものまで幅広く取り揃えています。     国内でも珍しいのですが、CDN（Content Delivery Network）というコンテンツ配信の仕組みを独自に構築し、大規模な配信にも耐えられるようにしています。多数の配信サーバで構成されたCDNでは、コンテンツを一時的にキャッシュし、オリジンサーバにかわりエンドユーザーへ配信しますが、キャッシュヒット率の向上にも日々取り組んでいます。     自社インフラ環境の最大の特徴は、ほとんどをオンプレミス（自社設備）で運用している事です。もちろんクラウドを使用する事もありますが、重要になる部分はすべてオンプレミスであり、それを運用するインフラエンジニアも基本的に社員で構成されています。   T.K. 動画配信のネットワークといっても、Ｊストリームで扱っているような大規模なものは極めて数少ない存在です。また、動画配信は、一般的なWebサービスと比べ大容量のデータとなるので、クラウドでは厳しい部分が多々出てきます。 N.T. Ｊストリームがオンプレミスを重視しているのは、常に正しくエンドユーザーにファイルを送れるようにするためなんです。物理層からアプリケーション層まですべてのレイヤーを自分たちでコントロールできるからです。   事業継続性担保のためには、どんな不具合でも自分たちで調べて解決できないといけないという考えがＪストリームには強くあります。   T.K. やはりオンプレミスの柔軟性は、トラブルシュートにおいて圧倒的な解決スピードの差を生みますからね。   Ｊストリームのネットワークはあくまでも顧客サービスであり、プロダクトを支えるインフラなので、単純にネットワーク技術という観点だけでなく、自社プロダクトを通じてそれがどう使われるのかというビジネス側の視点抜きには存在しません。   そのため、使用される想定シーンを理解した上で事前に準備をし、整えておく必要があります。それでも、想定外のアクセスがきて円滑に処理することが求められことがあります。   N.T. 例えば、テレビ連動のコンテンツなどの跳ね上がり方は一気にきます。   いろいろな予測をして、さまざまな仕組みを作ったりはしていますが、それでも想定の10倍以上のアクセスが瞬時に集中することもあります。その際には、クラウドの特徴であるオートスケールなどの機能では間に合わないことがあります。   オンプレミスならば、そこを救えます。社会へのソリューションとしてどうあるべきかを考え、「解決のためのエンジニアリング」という使命感を持って取り組める環境が、ここにはあると思います。 広帯域接続した複数のデータセンターへ配信サーバを配置し、ネットワークを分散制御 ―― コンテンツの大容量化が進んでいますが、現状、どのような対応を進めているのでしょうか。 T.K. 動画のビットレートが広帯域化しています。動画を保存するストレージは、今では数TBが一週間で消費されている状況です。コンテンツ配信は、まさに増えるトラフィックとの闘いです。 その中で、24時間365日で使われるネットワークをいかに使いこなし、継続的に分散制御していくかが肝になると考えています。 オンプレミスでのネットワーク構築は、複数のデータセンターを契約しています。ここでのポイントは、配信サーバを分散配置していく事です。また、各データセンターで数十Gbpsから数百Gbpsという広帯域のインターネット接続をして、大量のアクセスに対応させています。   N.T. 分散させたサーバを制御する仕組みも必要になりますが、こちらは今はGSLBを用いたロードバランス技術を活用しています。あとは、BGPを用いた動的ルーティングの技術、Ansibleを用いた複数台数のサーバの自動セットアップや構成変更などですね。   それらを使ってボトルネックなくトラフィックを転送し、どこがボトルネックになるか予想し排除していきます。ベテランでもめったに手掛けることのないようなことも数多くあります。入社してから、私も初めての経験にたびたび遭遇し、まさにインフラエンジニアとしての技量が日々試されているなと感じます。   T.K. Ｊストリームのインフラエンジニアは、データセンターや回線の選定から、ルータやサーバ選びなど物理的な面から対応しています。それらを接続性（ユーザーカバレッジ）、コスト、サービス品質など複数の要素で選定をしていくのは、仕事の醍醐味ですね。     どこのデータセンターを使うか、その際の回線はどうするか、そこに置くサーバをどう構築するかまですべて任せられており、これまでの経験を生かして自社のインフラ全体を見られますしね。 ストレージの部分も大切になりますね。アプライアンスだけでなく、自分たちでスケールできるソフトウェアも視野に入れて検討しています。   ――構築を進める際は、ネットワークとサーバの両方の技術が求められるんですね。 T.K. そうですね。「ネットワークだけ」「サーバだけ」といったどちらかのみの知識では不十分で、その点では、ジェネラリストとプロフェッショナルの両方の感覚が求められると思います。 ネットワーク技術には波があり、その時の状況に応じて色々と判断が必要になります。サーバを並列でつなげたほうが効率を高められるのか、1台の持つ性能を高めたほうがいいのか、集中と分散の試行を繰り返しながら、その時のベストを選択する必要があります。     N.T. ルータにしても、PCみたいな小さなものの方が適した場合もあります。その選定や見極めに関しても、性能だけでなくコストも考えてより良い成果を出していけることが必要ですね。 それを継続して行うことで、技術力と市場競争力の両方を持つネットワークサービスを実現することができます。そこがＪストリームならではの面白さであり、難しさでもあると思います。 ――高トラフィックを効率的に捌く仕組みは、どのようにしているのでしょうか。 N.T. これは広域負荷分散と呼ばれるものですが、フローに沿って仕組みを説明していきますと、まず、ユーザーの誘導ですね。これは、日常的にルーターのフロー情報から、エンドユーザーをどのデータセンターに誘導するかを自動的に処理しています。   xFlowのデータを基にGSLBを制御するのですが、フルルートの情報すべてをGSLBに登録する事はできません。   そこで誘導のキーとなるDNSサーバに関連するデータを抽出したり、配信トラフィックの多いAS番号に限定するなど、より最適な配信ができるように誘導をチューニングします。   T.K. 具体的には、DNSベースの広域負荷分散の仕組みを構築し、エンドユーザーの利用するキャッシュDNSサーバのIPアドレスやAS番号などの情報を基に最適な配信サーバに誘導します。   CDNの領域ではキャッシュファイルをいかに制御しキャッシュヒットさせるかが肝になりますが、一般的なWebサーバ用のミドルウェアだけでは細かいキャッシュファイルが扱えない為、自分たちでミドルウェアを書いたりKVS(Key-Value Store)を駆使して動的サイトでも高いキャッシュヒット率を実現しています。   N.T. 膨大なデータを配信するCDNだからこそ、オンプレミスのメリットは大きいですね。高トラフィックをどう上手く捌いていくか――大容量データを分散させ複数のデータセンター、ISPで負荷分散するためのコントロールであったり、さらにはトラブルシュートの原因の解明であったり、このあたりがCDNに関わる仕事の特に面白いところだと思います。 大トラフィックを効率的に捌く広域負荷分散の仕組み コンテンツ配信技術のノウハウを凝縮させ、自社の主力サービスへ昇華 ――長年のコンテンツ配信の積み重ねの中から、インフラ技術をメインにした自社プロダクトも誕生していますよね。 T.K. はい、2015年に提供を開始したJ-Stream CDNext（ジェイストリーム・シーディーネクスト、以下CDNext）というCDNの自社プロダクトです。CDNextは、Web画面上からCDNを管理運用できるもので、現在、自社の主力プラットフォームサービスのひとつです。   CDNextは、長年のCDN個別案件や実証実験等での経験やノウハウをベースにプロダクトへ昇華させたものです。「高度なCDN技術をより手軽に、柔軟に、多くの方に活用いただけるように」というコンセプトのもとに、使いやすさやサポートも重視してサービス提供しています。   CDNextの管理画面 契約企業は柔軟に各種配信が制御でき、設定内容はキャッシュサーバへ迅速に反映される T・K CDNextのエッジサーバを置くデータセンターには、ToRスイッチにサーバが数台、このセットで100Gbps程度のトラフィックを配信できるようになっています。   ハードウェアの能力を無駄なく使い切るために、配信サーバのOSやミドルウェアをチューニングしていますので、設備が少なく、引っ越しもしやすい構成にしています。     ＪストリームではGSLB（広域負荷分散装置）を多段に利用してサービスを作っているので、いつでも簡単にデータセンターの引っ越しもできます。   また、サーバは自動セットアップで簡単に増やせるようにしています。     N.T. 機能追加や新しいサービス立ち上げ時には、サービス開発担当部署と連携し、サービス開発側での考えをもとにネットワーク担当側で最適な設計を考えます。また、トラブルや障害発生時は、サービス開発側とネットワーク担当側でそれぞれのレイヤーを調べて解決に要する時間を最小限に抑えられるような体制をとっています。   ――インフラ技術をメインにしたソリューションには、その他にはどのようなものがあるのでしょうか。 N.T. 他にもマルチCDNの採用なども挙げられます。これは、可用性や地理的な配置、パフォーマンス、コストといったビジネスニーズに応じて、2つ以上のCDNから最適なものを選択し、負荷を分散させる仕組みです。大規模イベントなどの場合に推奨している考え方です。 マルチCDNでは、提携している他社CDNとトラフィックを融通する事もあります。URLの差異などがあり仕様が異なるので、多段に組み合わせる事でCDN毎の仕様の差異を吸収しています。 APIを連携させる事で、自社のCDNを使っているように見せたりするようなことも可能です。その場合にはトラフィックデータを見ながら、珍しく手動でロードバランサの設定を変更していくのですが、いつもとは違うトラフィックパターンを見ているとそれを自分自身でコントロールしている実感がありなかなか面白いですね。 日本のネットワークの最適化を考え、未来を創る取り組みに携わる  ――増大し続けるインターネットトラフィックですが、最適化問題を解決するために、2020年12月には、地域IXの実証実験を行いましたよね。実験の目的はどのようなことにあったのでしょうか。 T.K. ネットワークは広帯域化していますが、首都圏・関西圏に集積するコンテンツ事業者の送出の増大が顕著で、周辺地域のインターネット事業者の大きな課題となっていました。すべてのトラフィックを東京と大阪に集めるのはコストや耐障害性の上で課題が残ります。やはりユーザーの近くに配信サーバを分散しておく必要があります。その解決に向けた取り組みでした。   日本は狭いと言っても広いから、何でも東京を介するのではなく、例えば九州へのトラフィックは九州から配信でできるようにしておかなければならない。そこで福岡にデータセンターを借りて地場のISPさんと契約することで、もっとダウンロードを早く、動画配信が途切れず、よりよい画質で視聴ができるように工夫していきました。   N.T. CDNもそうですが、自分は地域分散や広域分散をどう進めていくか。私自身、そこにとても興味がありましたので、携われたことは嬉しいです。オンプレミスのネットワーク構築には複数のデータセンターに分散して配信サーバを配置していく事がポイントで、それには分散させたサーバを制御する仕組みがキーになりました。 また、どのIXと繋げばよいか、どこで繋ぐかなど、検討すべきポイントは多岐にわたります。   現場では数msを積み重ねるような検証も多々ありますが、それによって大きなファイルならばダウンロード時間がぐんと短くなったりとか、サイト表示時間が短縮されたりとか。 ひとつひとつは大きな変化ではないかもしれませんが、それらが積み上げられた時に、日本のネットワークの最適化につながっていく。地道なことですが、まさにインターネットの未来を創ることに我々も携わっているんだという社会的な存在価値を感じられる瞬間ですね。 ――新しい取り組みだけに、どういう課題設定をし、何を重視し、検証すべきか、まさにここでもゼロから考えながらですね。 N.T. 実証実験に際しては、実験の意義を常に意識します。今回で言えば、大都市圏とは違った発想で考え、どう接続させていくかが求められました。   例えば、コストとユーザーの誘導においては、地方なので、東京よりもアクセスしてくるユーザは少ないです。そこで、コストを抑えるために地方拠点ではフルルート運用はやめました。AS番号も別で取得し、ある意味チャレンジできる環境にするという取組みも行いました。   T.K. ピアリング最優先で、地域ISPとの積極的ピアリングをしたんですよね。 N.T. そうですね。今はピアリングのトラフィックだけを地方拠点に誘導する方針で、障害時に拠点ごと切り離せるようにし、実運用の中で効果測定中です。私たちはデータセンターを複数抱えていますが、それをどのようにネットワーク接続していくか、そのやり方や考え方は無限にあるはずなので、これから入ってくる新しい仲間の考えも是非取り入れてみたいと思っています。   データ量を一切気にせずに開発できる環境。 成果を社会や業界へ還元  ――最後に、Ｊストリームでエンジニアとして働くことのメリット、ベネフィットについて、開発環境や組織面からうかがいたいと思います。 T.K. エンジニアとして嬉しいことの一つ目は、まず、データ量のことを一切気にせずに開発ができることです。クラウド環境では、データトラフィックの料金などを気にしながら開発する事になるし、インスタンスの落とし忘れで膨大な請求が来てしまうなどの心理的な面もありますよね。 動画の場合、長時間ストリームを流したままで検証したり、大容量の4K/8K映像を基にエンコードテストなどをすることも多くあります。そのため、大容量データが流れ続けても気にせずにネットワークやストレージなどのインフラを組んである開発環境が必須になります。そこを専門のインフラエンジニアが直接見ているので、開発を手掛けるエンジニアにとっての恩恵は他社と比べてもすごくあるのではないかと思います。     N.T. 二つ目は、インフラエンジニアが開発環境の構築に専念できることです。以前は全エンジニアが技術部という一つの枠の中にいましたが、組織変革の一環により環境が整備されました。   現在は、私たちのようにユーザーには見えない物理的なレイヤーを開発するチームから、CDNのキャッシュエンジンやプライベートクラウドを作るようなバックエンドチーム、アプリケーションとして目に見える部分を開発するフロントエンドチームと、専門の担当領域を分かれて活躍できるような組織体制になっています。   T.K. 立場が違ってもお互いの意見を交換・理解し合い、それぞれの役割を果たしていこうという組織の空気があると思います。   N.T. 動画配信はいろいろな技術を知らないとできないので、興味の幅が広いエンジニアが多い点が影響しているんでしょうね。社内は、インフラの他、動画技術、ライブ配信、フロントエンド、バックエンドなど多様なプロフェッショナルが存在します。   T.K. 上のレイヤーの開発者の直面している課題があったとしても、下のレイヤーの開発者もそれを意識して取り組んでいこうという意識が強いですよね。   N.T. メリット・ベネフィットの3つ目ですが、自社の専門性を業界や社会に生かせている実感を得られることですね。CDNって一般的に言われるんですけど、実際にどういう風に動いているのか案外知られていないんです。 ですので、JANOGですとか外部講演なども会社として積極的に取り組んでいます。私も1月に開催されたJANOGで、他社の方と一緒に登壇しました。 中で自ら作っている人がまとめて発表することで、よくわかったという反応を得られたり、議論が広がっている様子を目の当たりにすると、自分も貢献できているんだという喜びを感じられますね。 ――広がり続ける動画活用の中、インフラ領域での新しい課題も次々と出てくるかと思いますが、引き続きの活躍をお願いします 。 ※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。 【関連情報】　※別サイトのＪストリームコーポレートサイトへリンクします。 J-Stream CDNext サービス紹介ページ　 仙台および福岡で地域IXにおけるトラフィック流通効率化の実証実験を実施（プレスリリース）

J-Stream Equipmedia（ジェイストリーム・イクイップメディア。以下、EQ）は、OVP(Online Video Platform)と呼ばれるSaaS型サービスで、2012年のサービス提供開始から今年で10年目を迎える。動画領域では4-5年で主要技術が一変することも珍しくないなか、サービス開発の裏側では日々技術の変革が起きている。今回は、2人のフロントエンドエンジニアにEQの新機能追加や開発への想いについて聞いた。 時代とともに変化し続けきた動画配信。コロナ環境下では、1.8か月での新機能リリースも ――皆さんが手掛けているEQは、サービス提供開始から10年目ということで、過去、多くの機能追加などもありました。まずは「EQとは何か？」というところから始めたいのですが、今回は、エンジニア情報サイトという特性上、エンジニア切り口で、EQ の機能や特徴紹介をお願いできますか。 K.N. EQは2012年からサービス提供を開始した自社開発のSaaS型OVPプロダクトです。管理画面上から動画ファイルをアップロードして配信できる形式に変換する「トランスコード」部分と、それをWebブラウザやアプリなどで視聴する「プレイヤー」部分の、大きく二つの機能から成り立っています。 この大きな二つの機能の他、ライブ配信を行うEQ Liveや、視聴分析を行うEQ VA（Video Analytics）など複数のサービスで成り立っている、動画配信に関する機能を網羅した総合的なプラットフォームです。 開発に際しては、様々なデバイスへ対応する為、デバイスの仕様や知識はもちろん、複数のコーデックや配信方式などを理解する必要があります。また、ユーザー企業のご担当者が、動画に詳しくなくても迷わず理解できるよう、設定方法や見え方などのUI/UXへの知識やスキルも必要です。 技術的な面白さという点では、エンコードに関してはスピードや高画質化、プレイヤーに関しては字幕や広告挿入といったことがあげられます。同時に開発の根幹としては、ユーザー企業の声を反映し改善していく「プロダクトの成長」という部分に携わります。キャリアパスとしてはプロジェクトマネージャーやディレクター、プロデューサーなどを目指す方にも最適な部署であると言えますね。   K.I. 今回の2人は主にフロントエンド部分の開発を担当していますが、時代の変化に応じて日々サービスも変化させています。   コロナ禍への対応としては、企業や団体において動画活用が急速に広がりました。ご契約企業からも、より簡単なライブ配信機能に関する要望が多く寄せられました。そのような中、昨年5月には、後述します社内の共通開発基盤を手がける「J-Stream Cloudチーム」と連動して、開発期間1.8か月での疑似ライブ機能の新規リリースも行いました。 K.N. 疑似ライブは文字通り「疑似的なライブ」を行う為の機能です。オンデマンドファイルを時間設定する事で、時間になるとライブ形式で収録済みの動画が配信されるというものです。 コロナ環境下においては、感染症拡大防止の点から、多くの企業が働き方を変える中で、コミュニケーション不足の課題が急増しました。その中で、ライブ配信の持つ速報性や臨場感が注目されたのですが、技術面の不安から導入に二の足を踏むケースも多かったのです。 というのも、通常、ライブ配信とは、その性質上コンテンツの制作と配信を同時に行うものです。制作だけでも生放送となるとさまざまな段取りがあり、多くの手間を要します。映像や音声のスイッチングやPAなどを考えると配信の部分まで気が回らなく、気がづいたら配信が止まっていた、といったことも一般的にはよくある話です。 しかし、ビジネスでの活用ということを考えると、「うまく配信できませんでした」では済みません。冗長化も含め幅広く考えていくと、ライブ配信は、実は簡単な事ではありません。 K.I. K.N.さんは新卒で入社し、ライブエンジニアとして現場対応を行っていた経験もあるので、そのあたりの感覚が鋭いですよね。プロダクトの開発に異動してからも、現場担当だった経験に基づいて具体的で実践的な企画をたくさん考えてくれています。 K.N. 自分が以前所属していたライブの部署は、「プロフェッショナルライブ」というサービスで、現場の制作から配信までをライブエンジニアが請け負う高難易度のミッションでした。一方、EQでのライブのコンセプトは「動画が初めての企業にとっても、手軽に簡単に利用できる」という逆のものです。このコロナ禍において、ライブ配信も「手軽に簡単に活用できる」ように、EQへ実装させる事は極めて重要かつ緊急性の高いミッションでした。   疑似ライブ機能自体は、要件定義から1.8か月程、実装自体は1か月ぐらいで実現しました。当時の開発体制は、Ｊストリームもテレワークを導入していたため、全員がリモートワークでした。初めての体制ではありましたが、OODA思想の元、アジャイル開発方式にて実際に動くものを作り、それをSlackやTeamsで共有しながら進め方をチームで協議して進めていきました。結果、当社としても異例のスピードでのリリースを実現することができました。   ――異例のスピードでのリリースが実現できたのは、体制面での工夫以外にも何か他にも要因があったからなのでしょうか？ K.I. 社内共通基盤を使用したという要因は大きいですね。REST APIをベースとした社内用クラウド「 J-Steam Cloud 」の活用です。疑似ライブ機能の追加では、「J-Stream Cloud」の中にある「Composer」という機能を核に開発を進めました。一から機能を作り上げる必要はなく、EQでの使い方や状況にあわせてComposerをどう取り込んでEQに組み込むか。いかに開発工数を少なくするかに焦点を当てて設計を行えたことが大きいですね。   K.N. 機能をフェイズ分けして、お客様からの要望を段階的にリリースできた点も大きかったですね。「J-Stream Cloud」のモジュール化により、機能追加やアプリケーション改修の際に既存システムへの影響が少なかった事で検証にかかる工数も大幅に削減できました。   K.I. EQは10年近く続いているサービスなのでレガシーな部分も残ってはいますが、「J-Stream Cloud」に合わせてモダンな共通開発環境への移行も進めています。今後はこれくらいのスピードが当たり前になるくらいに開発体制を整備していきたいですね。 潤沢なインフラと幅広い技術領域を生かし、顧客の声をもとにエンジニアリングの幅を広げる ――Ｊストリームで開発をする面白さは、どんなところですか？ K.I. 大きく3つほどあるのですが、ひとつはネットワークの環境が太いところですね。動画を扱っているので、当然検証などでも大きな帯域が必要になります。ましてや4K/8Kなどの動作確認にはそれなりの回線が必要です。 またエンジニアが自由に使える仮想環境なども多く用意され、それらもVagrantなどを使用して好きなものを使えます。グローバルIPを付与する事もできるので、LTE回線での確認なども気軽にできる環境もあり、それも合わせるとかなりエンジニア的にはストレスフリーな環境ですね。 K.N. 開発自体は主にPHPを用いて構築されています。ただこの辺りも昔からあまり変更されていない部分ですので、JavaScriptやTypeScript、Reactを用いてフロントの刷新なども進めています。サービスバックエンドとしてはPHPのCakePHPからLaravelフレームワークへの変更を進めています。 以前はあえてレガシーであり続けることで、使い慣れた操作感を無くさないようにという運営ポリシーもあったのですが、より良い使用感などを実現する為に、また開発効率の向上なども含めてどんどんとモダン開発に移行を開始しています。この辺りも前述のように開発環境の整備が進んだことで実現しています。 K.I. 二つ目としては、幅広い職種のエンジニアと一緒に仕事ができる事かと思います。プレイヤーのスペシャリストもいれば、動画のエンコードが得意なバックエンドエンジニア、ネットワークが得意なインフラエンジニアなど多種多様なエンジニアがいます。 動画ファイルの処理をしているサーバでは字幕再生、自動翻訳、スマホ画面の回転、倍速再生など色々な処理を行っているのですが、一部クラウドでのSaaS機能を利用しつつもほとんどを自社開発できているのは、多様なスキルを持ったエンジニアがいる恩恵です。 動画はある意味では特殊な知識になりますので、普通の開発ではそんな事まで知らないだろうなんてことも段々身についてくる。そうすると「なんだか自分もテクニカルな事をやっているなぁ」なんて思えてきて、気持ち良くなってくるんですよね（笑）   その点では、私はＪストリームにきてからCDNについてかなり詳しくなりましたね。EQの解析機能では、CDNで大量のログを収集し、種類ごとに加工してデータベースに加工しています。動画の視聴ログは、重要なデータ資産として注目される中、細かなデータを得るために日常的にCDNに触れられた経験は有意義だったなと思います。 K.N. 社内では「EQチーム」と便宜上言う事もありますが、各チームで閉じているわけでもなく、バックエンドの社内クラウドチームやインフラ部などとも密に連携しコミュニケーションも活発に行っています。SREの考え方を浸透させつつ、技術的な部分に関してはみんなで話をしながら進めています。 K.I. 前職ではフロントエンドだけの会社で、実はＪストリームに入る前はインフラやサーバなどはよくわかりませんでした。言語としてはJavaScriptやC#がメインだったので、入社後に一人で煮詰まっていた時期もあったんですが、バックエンドのエンジニアから「この処理はこれ一行でできるよ」といわれて愕然としつつも、自分がまだ踏み込めてない領域を知ったんです。そんなことが頻繁にありますから面白いですよ。 業務で知ったことを自己学習し、また業務に生かすという事を繰り返せるので、エンジニアとして成長できているなという実感はとてもありますね。今まではフロントエンドやアプリケーションのスペシャリストとしてキャリアを積んできましたが、フロントエンドを極める為には実はそれなりにバックエンドも知らなければいけない。フルスタックまではいかなくても、ある程度全体を見られるようになるのは重要だと感じました。 K.N. Ｊストリームで開発経験を積む面白さの三つ目は、お客様の声をダイレクトに聞けることだと思います。これは、自社の開発のベースでもあり、他社の開発と差別化を生む大きなものだと思います。 EQはB2B向け動画プラットフォームとしては国内最大級の規模で導入実績があり、現在までの累計アカウントは2,000以上になります。その顧客の声の中に次の開発のヒントが多く含まれていると思っています。メディアやコンテンツプロバイダ、一般企業など多くの企業から幅広い使われ方をされており、様々なデータがとれます。 マーケティングの観点からも、行動解析としてちゃんとログを取り問題などを早めに分析する。どの機能がどう使われているかを分析しつつそこに集中して開発を行っていく。なんとなくこの機能が流行っているから等で進めるのではなく、SLIやSLOをベースにプロダクト全体の健康状態をみながら考えていく事を徹底する。それらをエンジニア主導で動かせるように運営体制を作り始めています。   自分も以前はライブエンジニアとして全国を飛び回っていたのですが、その際にライブの現場でお客様から直接お話を聞ける機会もありました。疑似ライブなどの開発に関しても、独特の緊張感など現場の空気を知っているからこそ、開発の意義を納得して開発できたりもしました。 K.I. エンジニアが技術だけの事を考えていればいい時代ではなくなってきています。加えて動画は「配信できて当たり前」の世の中です。新しいサービスの企画や顧客のニーズに応えるにも、最適な技術を選んで形にするという点では、エンジニアの視点がますます重要になってきています。EQを作っているＪストリームのフロントエンドエンジニアは、その視点を養い、ビジネスとしても成長できるために必要な環境が揃っているのではないかと思います。 「他社に先駆けてやろう」、というのが ‟自社らしさ”  ――Ｊストリームの開発に対する姿勢とかスタイルについては、どのように感じていますか？ K.I. 私の中で一番鮮明に記憶しているのは、FlashからHTML5への移行ですね。そのインパクトは凄かった。当時はFlash全盛期で、EQの動画配信でも多くのFlash技術を採用していました。これを、サービスを止めることなくHTML5を使用したHLS配信に置き換えていきました。 当時は国内でHTML5対応をしているサービスやプロダクトなんてほとんどありませんでした。そんな中他社に先駆けて「やろう！」と決断をしたのはＪストリームらしいなと思います。 既存の数十万以上に及ぶ膨大な動画ファイルをFlash形式からHLS形式へ変換する仕組みを作り、それらを問題ないか検証をしていきました。地味に大変でしたね（笑） K.N. この時はまれにみる大規模な技術の仕様変更という事もあり、お客様にどうわかりやすく伝えるかも議論をしましたね。お客様にとっては変わらないように見えても、裏側の仕組みは大きく変わっていますから。それをどう伝えればいいのか…と。 K.I. その時の経験を生かして新たな開発のヒントにしているものもありますね。   他社がやっているからうちもやろう、というのももちろん必要だとは思いますが、Ｊストリームらしさとしては、そういう「他社がやってないからこそやろう」という開発を増やしていきたいですね。今もフロントエンドのSPA化や、iOSやAndroidのアプリ開発体制の拡充なども進めていますし、常に現状で満足せずより良いプロダクトへ進化させ、動画配信のパイオニアとしての意識を大事にしていければと思います。 K.N. EQチームでの開発は、いろんな技術を集めて組み合わせ、どうやってサービスを提供していくか、プロダクトマネージャーやプロデューサーに通じる力を身につけていけると思います。これからもお客様の声に耳を傾け、開発の最前線として最適なサービスを提供するプロダクトを運営していきたいと思います。 ――次なる展開に向けていろいろとアイデアは広がっているようですね。今後のEQの成長を楽しみにしています。 【関連情報】 J-Stream Equipmedia サービス紹介ページ 　 ※別サイトのＪストリームコーポレートサイトへリンクします。

レガシーな開発環境を脱却するために、モダン開発をベースにして構築された全社共通の開発基盤「J-Stream Cloud(ジェイ-ストリームクラウド）」。その存在は、開発スピードと柔軟性を大幅に向上させ、開発体制に大きな変化をもたらしている。今回、構築を手がけた2人のエンジニアに話を聞いた。 開発環境構築のキーは、マイクロサービス、インフラのコード化 ――今回のテーマは「J-Stream Cloud」ですが、これは以前はなかったものですよね。どういう経緯で作ることになったのか、まずは、その辺りから話を聞かせてください。 T.S. 「J-Stream Cloud」は自社のプロダクト開発やサービス開発を支える共通開発基盤です。2018年頃から着手し、現在も日々改良を重ねています。   アジリティ面の特徴としては大きく２つあります。一つはSubversionからGitLabへ移行しモダン開発ベースでのマイクロサービス構成にて開発スピードと高い柔軟性を実現している事。もう一つは、DockerやKubernetesによるコンテナ技術やAnsibleなどを用い、Infrastructure as Codeをベースとすることで、CI/CDの概念によるインフラの構築や運用を自動化できる事です。   各機能をモジュール化し、それぞれをステートレスに設計する事で機能の依存性をできるだけ分離し、スケール性も確保しています。それと同時に、共通する部分は汎用的に作りこむ事で、どこかのプロダクトで作った機能をそのまま他のプロダクトでも再利用できるようにしています。 M.S. 構築に関して使用されている技術は、着手当時から現在も色々変遷を重ねています。初期はRuby on RailsをベースにREST APIを実装していました。これは基本的なフレームワークのルールをより厳格なRailsによって社員に浸透させる狙いもありました。現在はある程度MVCなどの概念も理解が進んできておりますので、次の段階としては、将来的な機械学習などAI分野への進出を見越してPythonなどの言語への変換を進めています。   とはいえ、インタプリタ言語だけではもちろん高速な処理などは追いつきませんので、APIの内部処理として動く各マイクロサービスではJavaやGolangなどのコンパイル系言語も取り入れています。この辺りはnginxやRedisなどのミドルウェアも組み合わせて開発していますので、一般的な開発経験があればすぐに取り掛かれるようにという部分に焦点をあてて標準化させています。   「J-Stream Cloud」構築の背景には、Ｊストリームに特化した開発者ではなく、日本や世界で通用する開発者への成長を促す狙いがあります。いかにＪストリームで育ったエンジニアが他でも通用するか、また他で活躍しているエンジニアがそのままＪストリームで活躍できるか。オンプレミスのインフラや動画領域の経験など、コアコンピタンスな部分はどうしても特殊性は残りますが、それ以外のアーキテクチャはそれらの経験有無に影響されないので、スタートはきりやすいと思います。   ――マイクロサービスアーキテクチャの導入により、開発者目線ではどう変わりましたか？ M.S. つい5-6年前までは、まだサービス単位でモノリシックに開発されていたので、とても触るのが怖かったですね。機能が密結合されており、何かを触ると他の部分で想定外の動作になるなど、どこまで影響があるのか誰も把握できない状態でした。   一つのコンテンツをアップすると同期されたタスクが同時に動き出すため、データベースからエンコードまで全レイヤーを見ることができないと開発できませんでした。もちろん技術的にもですが、非言語化された「過去の経緯」や「作成者の想い」なども知らないといけない属人的な開発スタイルに縛られていたともいえますね。   マイクロサービス化によって、新しい機能を追加する際に既存のコードを触る機会が大幅に減りました。大きなクラスを触っていたら想定外のところでそのメソッドが呼び出されていてバグが出るなどのリスクも無縁になりましたので、過去の経緯を気にせず単機能の開発に集中できるようになり、みんな積極的に機能開発を行うようになりました。 T.S. ステートレスなマイクロサービス化によって、スケールインやスケールアウトも容易になりました。また、CI/CDの整備によってデプロイリスクも軽減されましたので、開発者の心理として安全に集中した機能開発を行えるようにもなり、チャレンジする傾向が強くなってきましたね。チャレンジの数を増やせれば、成功の可能性も増やすことができる。そうやって技術者目線での新しい試みを増やすことが、会社としての強みを増やす事に直結しているんです。   リスクもそうですが、マイクロサービス化されたそれぞれの機能は再利用が容易なのも大きいですね。サービスごとに同じような機能を作る「車輪の再発明」のような事は、とても多く発生していました。同一サービスの開発チーム内でも、バックエンドエンジニアとインフラエンジニアが同じようなサーバを作っていたりもしましたしね。全社員が使用できる共通開発基盤にすることで、再利用が基本的な考え方となり、大幅に開発スピードは向上しました。 M.S. 疎結合な開発体制が整ったことで、「動画のトランスコードに詳しい」というようなスペシャリティも発揮できやすくなるので、尖った特技なども活かしやすくなったかと思います。いろんな特技を持った人が参加する事で、小さな単位での機能レベルから底上げを図り、やがては大きな技術的変遷への対応、世の中のニーズへ決め細かくこたえられる。動画という技術の移り変わりの激しい領域だからこそ、マイクロサービス化は必然だったように思います。     今はリリース環境とステージング環境をKubernetes上で構築し、人的ミスを回避できるようにCI/CDによる自動化を取り入れています。導入当初はJenkinsなども使用していましたが、いまはArgoCDに変更するなど日々改善を続けています。   T.S. 以前は、最初の一歩が重たい感じでしたよね。実機のサーバを調達して、開発するときにはtopコマンドなどでリソースの空きを確認し、historyなどを見ながら恐る恐る触る感じです。開発が終わってデプロイする際にも目視チェックなどを行っており、人的ミスが無いようにすごく神経を使っていました。それに比べれば、重たかった一歩はずいぶんと軽くできたのではと思います。   M.S. インフラのコード化に関しても、現在はフロントエンドやバックエンドの開発者が自分たちでサーバやミドルウェアの構築、テストやデプロイまでをコードで表現します。自動化などのメリットもそうですが、インフラエンジニアと開発者がコードを通じてやりたいことを相互に理解できるよう共通言語化されたのが大きいですね。コミュニケーションロスもなくなりました。   T.S. 環境を作るまでの時間が圧倒的に短くなりましたね。コンテナなら、自分たちの開発端末にDockerをインストールしておけばそこでスクラップ＆ビルドを行い、納得できるまでコンテナのビルドチューニングを行える。そこで作ったコンテナはそのままステージングやリリース環境のKubernetes上でも使用される。Vagrantからlibvirtを使用してKVMの仮想サーバ自動生成も気軽にできるので、さっと動かしてみてダメなら壊して簡単にやりなおせます。   何かを思いついたら自分の隙間時間を使ってちょっと試してみる。ダメなら壊す。また思いついたら触ってみる。開発者にとってのチャレンジって構えて行う「大きな何か」ではなく日常的に繰り返す「小さなひらめき」ですから、それを後押しし実現できる開発環境が必要なんです。   技術変化の激しい動画領域で開発スピードを上げていく ――動画領域の開発では、「J-Stream Cloud」はどのようなメリットがあるものなのでしょうか？ T.S. 一番は、技術や世の中のトレンドに素早く対応できることです。動画領域は技術変化が特に激しく、主流となる技術が4～5年で一変する事も珍しくありません。大きなシステムを作ってしまうと一部だけを変えようにも、全く関係のないところで想定外のバグが出たりなどで、世の中の変化のスピード的についていけない。 「J-Stream Cloud」では、例えばHLS配信においてもPlaylist作成部分を分離してあります。前段の処理をそのまま生かしつつ、Playlistのレンダリングの時点でMPEG-DASH用のPlaylist作成処理だけを追加しHLSと置き換えるイメージですね。そうすれば、そのままMPEG-DASH配信だけでなく、CMAFなど新しい規格にもすぐに対応が可能です。それらの機能をAPIで提供していますので、パラメータでHLSやMPEG-DASHかを選んでもらえればすぐに新しい機能をプロダクトに提供できます。 M.S. コロナ環境下では動画活用が急速に拡大しました。中でもインターネットライブをもっと手軽に使いたいという企業ニーズが一気に高まり、私たちも緊急開発を多く行いました。その中の一つに疑似ライブ（収録動画をタイムスケジュールに沿ってライブ配信する事）機能がありますが、これは自社プロダクトである「J-Stream Equipmedia（ジェイストリーム・イクイップメディア）」へごく短期間で追加できました。（※関連記事は こちら ）   これはそもそも前述したようにレンダリングを別にしたエンジンを作っていたというのもあり、そこにフレーム制御でのカット機能を盛り込むことで機能の再利用を行った事によります。また当然、プロダクトの開発者であるフロントエンドエンジニアが全く動画について調べなくても良かったという、標準的なスキルによる分業化という事も大きいです。 T.S. 動画由来のメリットという点では、動画データは滞納トラフィックが起こりやすいためスケールを考慮する必要があるのですが、その場合でも処理の重い部分だけをスケールする事でリソースの節約を行う事が可能になりました。必要な処理だけをいくつも複製できるので、一つのコンテナで障害が発生しても別のコンテナで処理を続行するなど、障害回避の構成を作るうえでも役立っていますね。 ――Ｊストリームでの開発の面白みとは？ T.S. Ｊストリームのユニークな点は、オンプレミスの基盤と設備を持っている事です。動画配信と開発を同時にやっている会社は日本でも数少ないですからね。オンプレミスで一から自分で作る楽しさは格別です。   とはいえ、オンプレミスだけでやっていると全体スピードとしては落ちてしまう。「J-Stream Cloud」の構築ではまずはクラウドベースでスタートさえスピードアップを図りながら、徐々にオンプレミスへの移行を計画しています。インフラを柔軟に操作できるようになると、エンコードアクセラレーターなどの独自ハードウェアの組み込みや、キャリア網を使用したエッジコンピューティングなど、様々な利点がもっと出てくると思っています。   M.S. クラウドとオンプレミス、どうハイブリッドにしていくかですよね。クラウドの障害時にはオンプレミスに、またオンプレミスの障害時にはクラウドに逃がすなどを考慮すると、ハイブリッド化は必須になると思います。またクラウドも当然マルチクラウドであるとより堅牢になります。   5Gなどを見据えると、各キャリアのネットワークに合わせたインフラ設計も必要です。マルチクラウドでありマルチキャリアな汎用プラットフォームは、インフラを含めた設計が必須になりますし、それができるポジションにいるのがＪストリームの良さですかね。 T.S. 直近の課題はそのあたりですね。まずは現在動いている物理サーバをなるべくたくさんコンテナに移行し、コンテナで動くことがまず当たり前の仕組みを作っていけるとよいのではと考えています。 データ処理、双方向配信、MEC……「J-Stream Cloud」の成長の方向性とは？ ――今後、「J-Stream Cloud」へどのような機能拡充を考えていますか？ M.S. コロナ環境下での動画配信ニーズの高まりの中で、ライブやトランスコードなどの機能拡充の必要性を感じています。もちろんこれらの基本機能に関しては機能拡張を進めていければと思っていますが、ライブやトランスコードに関する詳細なフィードバックを提供できるように、高度な学習や予測なども取り入れていきます。今は配信するだけではなく、結果を問われる時代ですからね。   T.S. データ処理基盤ですね。現在でもCDNプロダクトの「J-Stream CDNext（シーディーネクスト）」ではKafkaやHadoopなどを使用してログの大規模処理を行っていますが、それはあくまで結果を可視化するだけのもので、学習や予測などの領域には手を出せていませんでした。Pythonをベースとした機械学習や深層学習などのエッセンスを取り入れていき、AIの活用を前提とした基盤を作れれば、面白いデータが出せるのではと思ってるんですよ。 M.S. ちょうど今、昨年入社の新卒メンバーにメインとなってもらい、ログ処理の基盤機能開発を進めている所です。彼の機械学習領域の経験を生かしてデータ部分を作ってもらっています。APIの使用データをPandasで読み込んだ後、scikit-learnなどで決定木にかけることでどういうパターンの際にどういうパラメータが望ましいかなどを自動判別するなど、徐々にAIの活用部分を増やしていければ面白いですね。 T.S. それ以外では、新たな配信方式への対応ですね。動画配信のプロトコルや仕様はここ10年で大きく変わりました。昔はFlashによるRTMPベース、今はHTTPベースのHLS配信方式がデファクトで使われていますが、ここ数年はWebRTCを使うとリアルタイムな双方向配信だけでなく、大規模な配信なども対応できるようになってきています。そういう動きに対して素早く対応できる体制や仕組みを作っていきたいと思っています。   双方向はやってみたいですね。1対多で配信者と視聴者が分かれている大規模配信はどこでもやっているけど、今は双方向性のあるものが求められています。見ている人がチャットで参加出来たり、音声通話でジョイント出来たりなどは昔からありますが、それ以外にも見るだけではなく参加できる為の様々なアクションを増やしていきたい、その為の機能開発を増やしていけると面白いでしょうね。 M.S. 私はSREについて本格的に取り組みたいですね。監視を細かく行い、月にどれくらいエラーや障害が発生しているかを把握できるようにする。それで「何％まで抑えていこう、これくらいまでなら大丈夫だからもっとチャレンジしよう」と具体的に進めていければと考えています。   機能追加に関しても、今までは営業主体で顧客ニーズに応えるという、開発主体という視点で考えるとやや後手なところがありましたが、SREをベースにSLI(Service Level Indicators)を定義し、開発側からも先手を打って主体的に動けるためのデータを揃える事で、よりチャレンジの目標を明確にできるようにしたいですね。   あとは5G関連でのMECであったり、H.266などの配信フォーマットを実証実験してみたり、…となるとやはりマルチクラウド環境ですかね。 T.S. Ｊストリームは動画配信ネットワークから始まったこともあり、インフラの強い会社だという印象が強いのですが、共通の開発環境として「J-Stream Cloud」ができたことで開発力も確実に上がってきている。「J-Stream Cloud」構築の経験を通じて、開発環境がエンジニアにもたらす影響力を強く感じました。   新しい機能を作ることがメインだから、結構チャレンジしていかないといけないし、それをできる為の環境がそろっている、と。 M.S. ロールバックもできるから楽ですしね。   試行錯誤で悩んだ時も、APIを叩けばJ-Stream Cloudがポンと新しいコンテナを立ち上げてくれますから、安心してチャレンジしてもらいたいですね！ ――今後の基盤拡充にも期待しています。ありがとうございました。 ※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。