Ｊストリーム の技術ブログ
全30件
国際会議に参加するきっかけ 私は、国内のVNE事業者が中心となって組織しているIPoE協議会でIPv6アドレスの地理情報(GeoIP)のデータ構築や利活用を推進する委員会の幹事をしております。今回はインターネットの標準化を行っているIETF の上位組織であるIABの主催 で、地理情報を活用する上での課題や今後必要となる技術などを議論するためのワークショップが開催されたましたので参加してきました。 国際的な場で話す。というのは、なかなか経験できないことで「国際会議で話すぞー！」という前向きな気持ちでがんばりましたが、スピーディーな議論やネイティブな英語の質疑で相当苦労しました。。。 今回のレポートでは、IABって何？ ということから、発表の中身や行われていた議論のポイントを中心に紹介したいと思います。 IP Address Geolocation とは インターネットに接続して動画配信やSNS、メッセージングなどのサービスを利用するためには、インターネット上の住所となるIPアドレスが必要です。 エンドユーザーは、IPアドレスをプロバイダー(ISPやCATV事業者)や所属している会社などから割り当てられていますが、あまり意識することはないのではないでしょうか。 IP Address Geolocation とは、エンドユーザーに割り当てられたIPアドレスが、地理的に「どこ」にあるのかを示すデータベースです。日本では「地理情報」と表現します。 IPv4アドレスは数が限られているため、キャリアグレードナットなどの技術を使って、同じIPアドレスを複数のエンドユーザーが共有しているため、異なる場所にいるエンドユーザーが同じ場所にいるように判別されてしまう問題が顕著化しています。そのため、アドレス数が豊富でアドレス共有が行われていないIPv6アドレスを使った地理情報データベースの構築と利用が必要となっています。 当社も参画しているIPoE協議会の「 IPv6地理情報共有推進委員会 （以下、推進委員会）」では、国内のVNE事業者を中心として、IPv6アドレスの地理情報を収集し、データベース化して利活用を推進しています。 IAB Workshop とは IABとは、「Internet Architecture Board」の略で、インターネット全体のアーキテクチャーについて議論する技術者集団です。13名で構成されます。今回はワークショップという形で、GeoIPに関する利活用の状況や課題点、今後の展望などを広く議論する会でした。IETFやIABを理解するには、JPNICが掲載している「 IETFの組織構造 」も参考にしていただけるといいと思います。 今回参加したのは「 IAB Workshop on IP Address Geolocation 」というワークショップで、オンラインですが3日間の発表と議論が行われました。参加者はMaxMindなどの地理情報を提供している会社、AkamaiやCloudflareなどのCDN事業者、地域レジストリなど、幅広いメンバーが参加していました。 議題としては地理情報の利活用についてやGPSとの連動についてなどの議論が行われてましたが、海外からの参加者はエリアマーケティングの例として「地理情報を使うことで、温かいピザが食べられる！」という話が何度か登場して、ニヤリとしてしまいました。 印象に残っているのは、衛星インターネットを使うユーザーの地理情報をどのように扱うか。という先進的な議論が行われていたことです。また、参加者の多くは欧米の方でアジア圏からの参加者は我々とネパールからだけ。という状況でした。 議論の様子。発表する筆者（写真左から2番目）と推進委員会関係者（同左上） IPv6地理情報の利活用とIPv4アドレス共有の問題点 発表としては、日本国内でのIPv6地理情報の利活用として、エリアマーケティングやECサイト・インターネットバンキングでのフィルタリングへの活用などの事例を紹介しました。また、動画配信におけるコンテンツフィルタングとしての利用について、実証実験の話をしたり、コネクテッドTV（CTV）やセットトップボックス(STV)などのGPSを持たない端末についても地理情報を活用したサービスが提供できる点などを説明しました。 最後に日本でのIPv4アドレス共有の仕組みや実態について紹介し、アドレス共有の問題点として、エンドユーザーを特定するためには、IPアドレスだけでなくポート番号とアクセスする時間が必要となり、地理情報が不正確になっていることを説明しました。IPv6アドレスへの移行により、この問題へ対処することがよいのではないかとの意見を表明してきました。 当日は、IPv6アドレスの地理情報を用いた実証実験についても紹介 質疑としては、災害時の地理情報の利用やGPSを持たない機器についての応用について、新しい取り組みで興味深いという意見をいただきました。また、せっかく複数のISPがまとまってデータベースを作っているのであれば、 RFC8805 に準拠したデータ形式として公開するのがよいのではないか。という意見もいただきました。 RFC8805は、ISPやCATV事業者が自身のネットワーク内のIPアドレスと地理情報を外部に公開するためのフォーマットについて規定しています。今回のワークショップの中でも議題として挙げられており、今後地理情報を提供する上では抑えておくべき技術だと感じました。当委員会としても検討が進められていない部分だったので、有用性や公開の仕方なども含めて対応を進めていきたいと思いました。 議論を通じての感想 私自身、インターネットの標準化に関わってみたい。という目標があったのですが、なかなかハードルが高く、何から始めればいいの？とずっと思っていました。しかし、今回、突然の誘いでIETFに関わる国際会議で話すことができました。目標に一歩近づき嬉しい気持ちとまだまだやらなければならないことが山盛りだなと改めて感じました。 今回のワークショップでは、RFC8805の利活用について活発な議論が行われていました。またAkamaiやCloudflareなとのCDN事業者もロードバランスに利用しているという紹介もあり、活用が進んでいることがわかりました。このように技術の標準化に関する最先端の動向を肌で感じることができとても貴重な経験ができたと実感しています。 また、日本国内での事情や工夫を話すことも大切ですし、標準化された技術を使うことで、世界を見据えた活動を進められればと感じました。 【関連情報】 IPv6地理情報共有推進委員会 https://ipoe-c.jp/wg/IPv6/ IAB Workshop on IP Address Geolocation https://datatracker.ietf.org/group/ipgeows/about/ IETFの組織構造 https://www.nic.ad.jp/ja/tech/ietf/section3.html RFC 8805 – A Format for Self-Published IP Geolocation Feeds https://datatracker.ietf.org/doc/html/rfc8805
2025年11月21日に熊本県玉名市で開催された「QUNOG 33」。 Ｊストリームは、株式会社MIXIと協力し、現地でのライブ配信を担当しました。 現地参加した坂本、阿迦井、高橋の3名が、ライブ配信での技術紹介を含めてイベントレポートいたします。 QUNOG（きゅうのぐ）とは？ インターネットにおける技術的事項、運用に関する事項を議論、検討、紹介することを通して九州・沖縄地域の技術者および利用者に貢献することを目的としたグループです。九州沖縄ネットワークオペレーターズグループの略。 QUNOG(きゅうのぐ) – connpass QUNOG 33の会場となった玉名市民会館 QUNOGは、ネットワーク技術者が集う熱いコミュニティ 坂本 ＪストリームとしてはQUNOGへの配信協力は、QUNOG 29から続けて５回目になりますが、私自身は今回が2回目の参加となります。 常連の企業さんや学生さんも多いのですが、毎回開催地域や会場が変わることで雰囲気も大きく異なり、その土地ならではの特色を感じられるのがQUNOGの面白いところだと思います。 今回の会場は熊本県玉名市でしたが、地域の温かさや参加者の距離感も近くとても刺激的でした。 また、QUNOGは学生の参加比率が高く、彼らのエネルギーが場を明るくしているのが印象的です。他の企業イベントとは違った熱気があり、技術コミュニティとしてとても良い空間だと感じています。 スタート前のスタッフMTG。企業と学生が一緒にイベントを盛り上げる Starlink × iPhoneで挑戦したライブ配信 坂本 MIXI社と共同で行う動画配信協力はこれまでにも何度か実施してきましたが、今回は「機材はMIXI社」「配信プラットフォームはＪストリーム」という分担で進めました。 MIXIさんは毎回チャレンジングな配信構成を提案してくださるのですが、今回は カメラをiPhoneのみで構成し、タブレット端末からリモート制御するという試みを行いました。さらに、Starlink を実際の配信に利用したのも今回のユニークなポイントです。 技術的な挑戦が多く、非常に楽しい現場でした。 Starlinkは会場脇の駐車場に設置 収録カメラには、iPhoneを使用し（写真・上）、カメラワークは、タブレットでリモート操作（写真・右） 坂本 今回は当日のオペレーションを学生さんに直接担当してもらう場面はありませんでしたが、準備や片付けなどを積極的に手伝ってくれました。 普段触れる機会の少ない配信機材についても、MIXIさんや高橋君の説明を熱心に聞いてくれていて、新しい技術に対する前向きな姿勢が印象的でした。 実際のライブ配信現場を体験する機会はそう多くないと思うので、今回の経験が少しでもポジティブな影響を与えるものになれば嬉しく思います。 また、今回たまたま同じホテルに宿泊している学生さんもいました。QUNOGでの発表を控えた学生さんたちが、夜遅くまで休憩スペースでリハーサルを続けている姿を見て、そのひたむきさにこちらも良い刺激を受けました。 配信構成図を興味深そうに眺めながらMIXIさんの説明を聞く学生さんたち 現場で使った機材とオペレーション 現場対応中の様子 高橋 今回のQUNOGでは、発表スライド・カメラ映像・会場の音声をATEM Mini Extremeに入力して画を作り、その画をもう一つのATEM Mini Extremeに分配しつつ、それぞれ別の回線を利用してＪストリームの配信用サーバーへ打ち上げるというシンプルな配信構成を取りました。 そんな中、カメラ映像を２パターン（登壇者席と客席）用意することや、Backup系の打ち上げにはStarlinkを利用する試みを実施しました。 配信の画には、登壇者のスライドを出力する枠と登壇者席を映す枠の２か所があり、客席の映像は必要に応じて登壇者のスライドと切り替えるというオペレーションを行いました。 本番中の切替のタイミングについてはメンバーから「（状況を見ながら、配信卓にいる高橋に）おまかせで。」と言われ、回数こそ多くなかったものの自主的な判断による操作が発生しました。自分たちで配信を運営しているという感覚が得られとても満足でした。 今回の配信機材 高橋 Starlinkを利用した映像送信については、特に苦労することがなく実施することができました。 しかし通信状況を監視していると、断時間が10秒程度と長いことから、ハンドオーバーによるものではないかと想像されます。このタイミングでは、映像の途切れや音声の欠落等が発生する可能性があることが分かりました。（※Backup系での利用のため、実際の配信映像への影響はありませんでした）。Starlinkを利用した配信のテストとしては、有意義な結果が得られたのではないかと思います。 全体を通して大きなトラブルはなく、無事に配信を完了できたことは非常に喜ばしいです。次の機会でも、確実に配信を行いながら様々なチャレンジを続けていきたいと思いました。 エンジニアが広報を担当して見えたこと 自社広報担当として、企業紹介中の様子 阿迦井 今回のQUNOGも九州の様々な大学から多くの学生が参加されていました。みなさん意欲が高く、ネットワークに加えて配信といったところにも興味を持ってくださったように感じられました。 「こういった業界、お仕事もあるのですね！」と言っておられる方もいて、今回のイベントを通して学生さんに新たな気づきや将来の選択肢を提供できたのではと思っています。 広報活動を行うことにより、企業だけでなく学生にとっても良い機会になっているのだと身をもって体感しました。今後もひとつの新たな選択肢として知っていただけるよう広報活動を行っていきます。 人事部のエンジニア採用担当者も参加し、一緒に企業ブースを設置 ライブ配信現場で体感した技術の奥深さと協働の価値 坂本 私が担当しているCDNは配信に深く関わるプロダクトですが、私自身は配信現場や周辺技術にはほとんど経験がありませんでした。そのため、業界団体イベントの実行委員として登壇者のライブ配信を担当することは、普段の業務とは全く異なるチャレンジでした。 最初は機材構成やOBSの設定など、何から手をつければよいか分からない状態でしたが、若手のチームメンバーや社内のライブ配信チーム、協業する他社エンジニアに教えていただきながら、少しずつ理解を深めていきました。 1年を通じて複数回こういった配信イベントでの実行委員として活動する中で、配信の基本的な段取りや機材の扱い方を学び、最終的には自分で構成を組み、OBSで配信できるレベル（初歩）になったと思います。 今回できるようになった背景には、社内外のメンバーの協力があり、サポートを受けながら進められたことは非常に助けになりました。 こうした経験を通じて、「配信の会社」であるＪストリームの強みを現場で実感できたことは大きな学びです。 また、普段はリモートワーク主体ですが、イベント運営を通じて社内外のメンバーと直接協力し、同じ目標に向かって動くことで、チームの一体感や社内理解の深化にもつながりました。 技術コミュニティとともに、次の挑戦へ！ 坂本 今回のようなイベントへの参加は、私自身だけでなく、社内メンバー、他社の方、学生の皆さんにＪストリームの事業・技術・魅力を知ってもらう良いきっかけになっていると感じています。 今後も、より多くの方にＪストリームを知っていただけるよう、活動の幅を広げながら、こうした技術コミュニティへの貢献を続けていきたいと思います。 高橋 今回配信周りのほとんどを担当しました。これまでは広報担当として参加していたため、技術面に関してはメンバーを頼ることが多かったのですが、今回は私が技術担当として、理解しておくべき箇所が急増したため正直プレッシャーはありました。 配信の構成や映像の送信はもちろん、社内の有識者に任せていた視聴ページやCDNの設定に関しても、できるだけこちらで巻き取れるように努めました。 イベントへ参加をすることで、普段の業務に関わるサービスだけでなく、そうでなはないサービスに対しても、さらなる理解や技術・知識を身につけられるように鍛えてもらっている感覚です。 幸い社内には各分野のスペシャリストがいますので、その方々に沢山質問したり、そこで得られた回答を自分なりに解釈したり、ドキュメントにまとめたりしました。 自分の糧になることを地道に続けたことで、成長できていると感じております。 今後も継続ししつつ、イベントには積極的に参加していきたいと思います。 阿迦井 今回、広報担当として初めてQUNOGに参加させていただきました。普段の業務では体験できない配信機材の操作や、他社・学生との協力と貴重な楽しい経験を積むことができました。 普段の業務で配信の内部は触れているものの、配信機材に触れるのは今回が初めてでした。操作や構成で分からないことだらけでしたが、社内外問わず先輩方が細かく教えてくださり進めることができました。 現場だから求められるスピード感に自分で考え主体的に動く、分からないことは社内の先輩方、社外の方とコミュニケーションを取り理解していく。現場から人から学び、分かる・できるが増えていく時間になりました。 現場の配信に携わることで配信への理解が深まり、広報として採用分野に携わることで会社への理解が深まりました。今回で得た経験を今後に活かしていきます。 以上、QUNOG 33に現地参加した坂本、阿迦井、高橋より、イベントレポート ＆ ライブ配信の裏側のご紹介でした。 次回のQUNOG 34は、 2026年2月27日(金) 福岡県福岡市 九州産業大学で開催予定です。Voiceでもまた事前ご案内含め、ご紹介予定です。 どうぞお楽しみに！ 無事ライブ配信を終え、打ち上げ会場へ向かうスタッフ達 【関連記事】 QUNOG（connpass）
JAIPAの集い in 奈良とは 10/23(木)、24(金)の二日間、一般社団法人 日本インターネットプロバイダー協会様の主催による「第60回JAIPAの集い in 奈良」が奈良市の奈良市ならまちセンターで行われました。 今回も188名もの方々に参加いただき、激変する世界のインターネットと地域ISPの議論、海底ケーブルの陸揚げ局、昨今のIルーター等のIoTデバイスのセキュリティ、生成AI、放送通信融合などの話題から、奈良市のGIGAスクール構想に関する取り組みなど、ローカルな話題まで、幅広いプログラムが展開されました。 アーキテクトの高見澤がプログラム委員として参加しましたので、レポートいたします。 プログラム委員とは？－ちょこっとご紹介します プログラム委員の一番の仕事は、文字通り集いの「プログラム」を決めることです。集いでは、全国の地域ISPの方々にホストをなっていただいていますので、地元ネタとしての地域の取り組みやインターネット業界の話題など、その時々のトピックスからプログラムを決めていきます。 また、登壇者との調整やスポンサー集めから、会場の準備や会の進行など、実行委員としてのお仕事もあります。私は会場の音響やテレカン対応を担当しており、当日は慌ただしい一日でした。 イベントでは、スポンサーとしてドリンク提供も行いました 60回目という節目の回として 今回の集いは60回という記念の回となりました。会場では過去の集いの写真をスライド形式の映像を作成し、プログラムの合間や懇親会会場で上映しました。、古株の参加者からは好評をいただきました。 また、JAIPAの初心者向けの「JAIPAの歩き方」というプログラムを株式会社朝日ネット 高橋穣児氏と一緒に行いました。 会場の若手のメンバーに話していただいたり、各部会の部会長さんに部会の様子やJAIPAの楽しみ方などを話していただきました。無茶ぶりに答えていただいた若手からは、インターネット業界の幅広い会社が参加しており、話題が豊富。会社の経営層が多いので簡単にはお話できない方と気軽に話ができ驚いた。次は登壇してみたい。などの生の声をいただくことができました。 登壇者が話すプログラムというよりは、会場を巻き込んだプログラムになり、盛り上がることができました。 「JAIPAの歩き方」で朝日ネット・高橋氏（右）と登壇する筆者（左） 海底ケーブルの陸揚げ局とは もう１つ、私が関わったプログラムは「Telstra x JAIPA スペシャルセッション 志摩る話～特別潜入！陸揚げ局の表と裏側～」です。このプログラムは、普通は見ることのできない海底ケーブルの陸揚げ局について、Telstra JAPANの伊藤さんに解説いただきました。 海底ケーブルの陸揚げ局は、データセンター以上に場所や用途が秘匿されている施設ですので、簡単には入ることができません。そこで、事前に施設の内部を撮影し、その動画に解説のテロップを入れて会場で上映しました。また、撮影にあたっては、Telstra Japanのフィールドエンジニアの方にも同席いただき、陸揚げ局ならではの設備や施設を解説をいただきました。 海底ケーブルはインターネットには欠かせない基盤ではありますが、なかなか仕組みや内部を知る機会は少ないと思います。このセッションでは、ケーブルの名前や配置場所についても、伊藤さんから説明があり、海底ケーブルについての貴重なセッションとなったと思います。 取材や編集にご協力いただいた伊藤さんはじめ、Telstra JAPANの皆様に感謝いたします。 さて、次回は 次回の集いは静岡で行われる予定です。次はどんなプログラムが行われるのかご期待ください。 【関連情報】 第60回JAIPAの集い in 奈良 （一般社団法人 日本インターネットプロバイダー協会様公式サイトへリンクします）
Ｊストリームは、九州産業大学 下川研究室様、株式会社Geolocation Technology様と共同研究とデータ提供・利用に関する契約を締結し、2025年8月より「ジオロケーションデータを用いたトラフィックコントロールの高度化に関する研究」を開始します。本日付けのプレスリリース記事をご紹介します。 本研究の目的は、地域判別とCDN技術を活用して地域内でのトラフィックの折り返しを実現し、それにより、配信品質の向上やネットワークコストの削減効果を検証することです。 本研究成果の適用後イメージ 具体的には、IPアドレスと都道府県情報をマッピングしたジオロケーションデータ※を用いて、地域によって返答するIPアドレスを最適化できるDNSサーバーの判別処理を新規開発します。その判別処理をＪストリームのサービスの一部で適用させ、地域の接続拠点（PoP/Point of Presence)でのトラフィック交換の効果を測定します。 詳細は下記プレスリリースをご覧ください。 「産学連携によるトラフィックコントロールの高度化に関する共同研究を開始」 ※Ｊストリームコーポレートサイトへリンクします
JANOG56のストリーミング Ｊストリームは2025年7月30日（水）～8月1日（金）に島根県松江市で開催されるJANOG56に、ストリーミングサポーターとして参加いたします。JANOGは、数多くのネットワーク技術者が参加して新規技術の紹介や討論を行う大規模な交流の場であり、登壇プログラムのライブ配信も行われます。 Ｊストリームでは機材の設営から配信画面の切り替え等のオペレーションをホストである株式会社インターネットイニシアティブ（以下、IIJ ）さんと一緒に担当します。さらにＪストリーム独自の試みとして、各会場の配信をユーザーが自由に切り替えて視聴できる、マルチアングル配信も提供します。 また、6月にIIJさんと一緒に行ったホットステージの様子は JANOGのニュースレター としても公開されていますので、一緒にご覧いただけると嬉しいです。 「LINK」プロジェクトについて Ｊストリームでは、自社の技術広報や社外とコラボレーション企画の推進を目的とした「LINK」というプロジェクトを2025年4月に発足させました。LINKプロジェクトでは、QUNOGやJANOGのようなネットワーク関連のイベントの協賛・現場対応が、活動の大 きな柱の一つなっています。 今回は、私を含め4名のLINKメンバーが現地に赴きます。動画配信の支援を通してＪストリームの認知を向上し、外部との繋がりを強化することはもちろん、メンバー個々人が、配信やネットワークの知識・技術を吸収して成長できる機会となるように努めてまいります。 マルチアングル配信の見どころ JANOG56では、視聴したい映像を自由に切り替えられる「マルチアングル配信」を実施予定です。マルチアングルいうことで、発表や議論が行われる３会場の映像と会場内の定点映像の4画面を合成し、視聴者は全体表示と、各映像の表示を自由に行き来することができます。 マルチアングル配信のイメージ図 マルチアングル配信を支える技術 マルチアングル配信を実現するための技術仕様を紹介します。各会議場からの映像・音声データは各会場エンコーダーより SRT(Secure Reliable Transport Protocol) を使ってＪストリームの本社まで伝送します。 あわせて会場の定点映像は、スマートフォンのカメラで撮影し、そのまま同じくSRTで伝送します。Ｊストリーム本社にはビデオスイッチャーというデコーダーを設置しており、受信した複数のSRTソースの中からマルチビューワに送信する映像を選択します。 マルチビューワで4アングル分の画を4Kの映像信号に合成し、SDIでエンコーダーに出力します。最後にマルチアングル用の配信サーバーに映像を打ち上げます。 新規開発：Androidエンコーダー 今回の配信では、手軽に、どこでもライブ配信ができるよう開発したAndroid用のエンコーダーを現地に持ち込んで配信をする予定です。 このエンコーダーを使えばAndroidスマートフォンだけでSRTを出力できます。現地に参加される方は、是非スマートフォンエンコーダーを探してみてください。ただ、簡単に見える場所にはないかもしれないですが（笑） マルチアングル配信のイメージ図 JANOG初参加にむけた意気込み 私個人としてのNOGへの参加は、前回の QUNOG 31(沖縄)に続き2回目となります。JANOGは初参加です。 実を言うと、ネットワークの分野に関しては、「難しそう」「普段の生活では意識しない物理機器の知識が必要そう」とハードルの高さを感じており、また、目で見て直感的に理解できるジャンルの方が得意だと感じていたことから、何となく遠ざけてきてしまいました。しかし、このNOGへの参加が関心興味を持つきっかけとなっており、今ではLINKプロジェクトに参加して良かったと感じております。 また、普段は発生しない業務や仕事を経験することができており、自己の成長を感じます。特に、ライブ配信用の機材にじかに触れての設営作業は、配信プラットフォーム上での業務が主である私にとっては新鮮です。その他にも各種手続きや、社外の方とのMTG・懇親会など、ビジネスパーソンとしては慣れておきたい経験をさせてもらっています。(初めての飛行機利用も経験しました 笑) 今回のJANOG56参加にあたって、積極的にイベント運営に関わることで一技術者としてライブ配信により習熟できるようにするとともに、関係者との円滑な連携を図り方・配慮の仕方をメンバーから学びたいと思います。 【関連リンク】 JANOG56 配信チームのご紹介：IIJ × Ｊストリーム × 学生チームで挑むライブストリーミング ※JANOG56公式サイトへリンクします SRT Alliance – Open-source SRT – Secure Reliable Transport ※SRT Alliance公式サイトへリンクします
DNS Summer Dayとは、どういうイベント？ DNS Summer Day 2025は、日本DNSオペレーターズグループが主催し、DNSに関わるエンジニアや事業者が一堂に会するイベントです。Summerというイベント名からもわかるように、毎年「夏」に行われているイベントです。 今回のプログラムでは、新しいDNSキャッシュサーバー実装の検証結果共有、DNSの運用において便利なツールの紹介（オープンソースの実装を紹介するだけでなく、自身で作成したツールの紹介もあった）、DNSサーバーのチューニングや安定運用に関する話題など、DNSに関する技術的な話題を中心に発表と議論が行われました。 今回のレポートでは、当日参加して、特に気になったセッションをいくつかピックアップしました。また、共同セッションで登壇しましたので、あわせてご紹介したいと思います。 DNSに関する最新情報のアップデート Protective DNSという仕組み スポンサーセッション：「NIST 800-81r3で変わるDNSの常識」 DNSに関して、いろいろな切り口で発表が行われましたが、セキュリティーに関する話題で気になったのは、Protective DNS(PDNS)です。 DNSを使った名前解決を行わなければ、インターネット上のWebサイトやサービスを利用することはできません。そのため出口対策として、クライアントが指定するキャッシュDNSサーバー上で不正サイトやサービスへのアクセスをブロックしてしまう、というのがProtective DNSという仕組みです。マルウェアやランサムウェアもDNSを用いた名前解決を利用しているので、効果が高いと感じました。 一方で、この手法は一種のブロッキングとなりますので、社内などの特定の組織内であれば適用可能と思いますが、インターネット全体に適用することは難しいと思います。 ドメイン名のドロップキャッチ セッション：「ドメイン名のライフサイクルマネジメント 〜ちょっと待てぇい！そのドメイン名どうするん？？〜」 一方で「人的なセキュリティー」としては、ドメイン名のドロップキャッチの件が気になりました。イベントなどで一時的に利用するサイトに対して新規にドメイン名を取得し、イベント終了後に更新を行わなかったり、サービス終了により利用していたドメイン名の更新をやめてしまうことで、悪意のある第3者にドメイン名を取得されてしまうことがあります。 その後、第3者に取得されたドメイン名で、フィッシングサイトや海賊版サイトが立ち上げられるというケースがあります。また、一度利用されたいたドメイン名ですので、他のサイトからリンクされていたり、他のサイト内に埋め込まれていたりする可能性があります。 元々ドメイン名を取得した組織は、利用を終了して更新をしなかった場合でも、他者が悪用してしまった場合、インターネット場の利用者が不利益を被ってしまうことが問題です。 当社では、新規にサービスを立ち上げる場合、コーポレートドメイン等のサブドメインとして立ち上げるようにしています。本セッションが指摘するように、万が一の倒産等でドメイン利用終了した場合に伴う発生リスクは、企業として常に意識すべきだと思いました。また、ドメイン利用終了後も、長期的に悪用防止への意識を持ち、定期的に確認を行う必要があり、まだまだ完璧とは言えないと思いました。このようなリスクを多くの方に理解してもらう活動が重要となると感じました。 ECS(RFC 7871)の3社共同検証の結果共有としての登壇 私の発表は「ECS(RFC 7871)の3社共同検証の結果共有〜商用利用を前提とした検証結果の共有〜」と題して、株式会社JPIX、KDDI株式会社と株式会社Ｊストリームの3社で行ったECSの共同検証についてのお話をさせていただきました。 登壇風景_左よりＪストリーム 高見澤、KDDI 今泉氏、JPIX 関氏 当社としてはCDN事業者としてECSを利用することで、ピアリングの有無や東阪の分散だけでなく、地方でのトラヒック交換がうまくできるようになるのではないかと期待していました。ただ実際にECSを動かすためにはISP側のキャッシュDNSサーバーでECSを有効にしていただく必要があります。その観点でIPoE事業を行っているJPIX社、KDDI社と一緒に検証ができたことは、とても有意義でした。 今回の検証を通して、権威DNSサーバーもキャッシュDNSサーバーも複数の実装を試したため、実装上の違いがあることがわかりました。特にScope Subnetの扱い方がDNSサーバーの実装により異なること。また権威DNSサーバー側で細かいprefixを設定してもキャッシュDNSサーバーが要求してくるprefixよりも細かい情報は利用されないことなど、ECSを設計者の意図通りに動かすためのポイントを中心にお話をしました。 ※当日のＪストリーム登壇資料は以下よりご覧いただけます。 ECS(RFC 7871)の3社共同検証の結果共有_DNS Summer Day 2025_20250627_takamizawa by @j-stream_eng 最後に質疑を通して、キャッシュDNSサーバー側のキャッシュヒットの低下は非常に大きな問題ということがわかりました。また全国ISPにおいても、ECSを導入するメリットが享受できる場面は限られているという意見もあり、実際に全国ISPの方やキャッシュDNSサーバーのアウトソーシングサービスを提供している事業者の方からもコメントをいただき、知見が広がりました。 まとめ DNS Summer Day 2025に参加して、DNSというインターネットを構成する重要な機能について、集中的に情報を収集できる貴重なイベントだと思いました。ぜひインフラエンジニアの方々は参加されることをお勧めします。 登壇風景 一方自身の発表としては、ECSという、昨今のDNS界隈のトピックスの1つについて、発表することで、現場のエンジニアの方からの意見をいただけたことは非常に良かったと思います。来年も検証の結果をアップデートだったり、ネタを持って参加できるようにがんばりたいと思いました。 【関連情報】 DNS Summer Day 2025 公式サイト ※当日のセッション資料が一部公開されています。
2025年6月27日 (金) に東京・日本橋で開催される「DNS Summer Day 2025」に弊社アーキテクト高見澤信弘が登壇します。 今回は、KDDI様、JPIX様と一緒に登壇させていただきます。 ■登壇セッション概要 「ECS(RFC 7871)の3社共同検証の結果共有 〜商用利用を前提とした検証結果の共有〜」 時間：15:10-15:40 ■イベント概要 主催：日本DNSオペレーターズグループ（DNSOPS.JP） 開催日時：2025年6月27日（金） 10時～17時50分 参加費：無料（事前登録、先着順） ※オンライン配信あり 詳細URL： https://www.dnsops.jp/event20250627.html DNSOPS.JPでは、インターネットの安定運用にとって重要な基盤技術であるDNS（Domain Name System）について、情報交換、共有、議論、国内外における関係各組織との連携に取組まれています。 本イベントは、 技術の変化と社会的要請の狭間で揺れるDNSの「いま」と「これから」について多角的な視点で議論する場としてハイブリッド開催されます。 ご都合あわれる方は、ぜひご覧ください。
JAIPAの集い in 鳥取とは 5/29(木)、30(金)の二日間、一般社団法人 日本インターネットプロバイダー協会様の主催による「第59回JAIPAの集い in 鳥取」が鳥取市のとりぎん文化会館で行われました。鳥取での集いの開催は初めてとなります。参加者の中には鳥取に初めて来た！という方も。 今回も170名もの方々に参加いただき、鳥取県のデジタル基盤整備の現状や鳥取情報ハイウェイ、ローカル5Gを使ったスポット通信、コネクテッドカーでの通信や遠隔型の自動運転の話まで、幅広い講演が行われました。 アーキテクトの高見澤がプログラム委員として参加しましたので、レポートいたします。 放送100年を意識したプログラム 今回の集いのポイントは、放送ネタを2点入れさせていただいたことです。2025年は日本で放送が始まって100年という記念の年です。当時はラジオ放送ですが、現在はテレビやラジオもインターネットの上で配信される時代となりました。 そんな中で、AbemaTV CTOの山中勇成さんと私で「地域ISPとコンテンツ配信」というセッションを行い、昨今のコンテンツ配信についてざっくばらんにお話をさせていただきました。 また最終日には、「地上テレビジョン放送のブロードバンド等代替に関する検討状況について」と題して、総務省 情報流通行政局 放送政策課 外資規制審査官 細野慶介氏にご講演をいただきました。 「地域ISPとコンテンツ配信」での登壇 私の方からは、2024年のコンテンツ配信を振り返って、マルチCDNやIPv4/IPv6のアクセス割合をはじめとしたデータや地上波サイマル放送との関係性といった視聴動向に関するお話などをさせていただきました。その後、配信拠点の地域分散について、チャレンジとその後の効率化へのシフト、また今後の地域IXとの連携などについて、課題感も交えながらお話しさせていただきました。 地域分散という文脈では、キャッシュサーバーを分散配置しただけでは不十分で、分散されたキャッシュサーバーにアクセスを誘導する必要があります。DNSを利用する場合は、DNSサーバーのIPアドレスをキーにして、誘導するキャッシュサーバーを決めますが、IPアドレスだけではISP毎の制御や東阪などの大きな単位でしか制御ができず、どうしてもコントロールできない場面が出てきてしまうことを紹介しました。 その後、AbemaTVの山中さんから、AbemaTVのご紹介、昨今の配信システム構成と品質測定(QoE)について、ご説明いただきました。 山中さんからは、続けて、過去の大規模配信事例をもとにマルチCDNの実装や品質測定による課題を説明いただきました。例として、スポーツイベントなどのリアルタイム性の高いコンテンツについては、地上波放送が行われない地域においてインターネットコンテンツへのアクセスが集中し、視聴品質の低下が起こっている現状も共有いただきました。 「地域ISPとコンテンツ配信」登壇の様子 会場との意見交換 地域分散や地域IXについて会場から意見をいただきました。地域ISPとしては地域に貢献する取り組みとして、地域Ⅸへの接続が行っていきたいが、中継回線の費用増や冗長化も考えると、コストメリットは薄い。一方で災害対策のためにも地域Ⅸの存続と平時での活用は必須。 より大きな視点では、コンテンツが東京に一極集中してしまっていて、「地方から東京にコンテンツを集めて、東京から配信する」という流れになっているが、「地方から東京に配信する、地方から地方に配信する、そうしないと地方での折り返しのトラヒックが発生しない」という課題も見えてきました。 また、IPアドレスのジオロケーションデータ（そのIPアドレスが、どの地域で利用されているIPアドレスかを紐づけた情報）を用いることで、地域を限定したターゲットマーケティングや広告の出し分け、コンテンツの制御などの活用が行われている事例をお話しました。 地域ISPと協力することで、より正確なジオロケーションデータを集めることができれば、判定ミスの軽減だけでなく、新しい利活用の方向が見えてくるのではないか、という点についても会場と意見交換ができました。 まとめ 放送100年にちなんで、放送とインターネットというプログラムを2件いれましたが、どちらも会場から質問をいただくとともに活発な意見交換をすることができ、ホッとしています。 Ｊストリームでは、地方へのキャッシュサーバーの展開を行ってきましたが、地域IXとの連携だけでなく、地方のコンテンツを地方から世界に配信する動きを推進できれば、災害時だけでなく平時も活用される新しい形の地方分散が実現できるのではないかと感じました。 また、山中さんとのセッションの中で、コンテンツ配信側とISPの間で何らかのコミュニケーションチャンネルがあれば、両者がWin-Winになる関係性が築けるのではないかと感じました。 JAIPAの集いの中で、地域ISPとコンテンツは配信のよりよい関係を作るにはどうしたらいいか、鳥取での活発な意見交換をもとにＪストリームとしても地域分散の次の形、視聴品質の維持と設備の効率化など、新しい視点で考えていきたいと思いました。 【関連情報】 第59回JAIPAの集い in 鳥取 （一般社団法人 日本インターネットプロバイダー協会様公式サイトへリンクします）
以下勉強会が開催されますのでご紹介します（オンライン・無料）。 Japan Stream Engineering Group (JaSEG) 第3回勉強会 2/28（金）14:00～ 「沖縄ネット事情：QoS、QoE、CDN環境」 Japan Stream Engineering Group (JaSEG) ●アジェンダ 「OTT視点：沖縄の網構成、CDN事情、QoS」 スピーカー：鍋島 公章(メディアコンサルタント / Ｊストリーム） 「eスポーツ選手に最適なインターネット回線の検証とネットワーク品質測定」 スピーカー：Okinawa Open Labolatory 株式会社オープンシステムズラボラトリ 佐藤 陽一 氏 NTTコミュニケーションズ株式会社 吉田 正之 氏 株式会社ボスコ・テクノロジーズ 中山 裕貴 氏 詳細および参加リンクは下記ご参照ください。 Japan Stream Engineering Group (JaSEG)
所属するネットワークインフラ部では、2024年11月にBIG-IPに特化した1泊2日での勉強会合宿を行いました。その時の様子をご紹介します。 いんふらっと会とは？ ネットワークインフラ部は、Ｊストリームのサービス基盤となるネットワークインフラ部の構築・運用保守を担当しています。現在の体制は、9名です。 私たちの部では、月1回、全員出社日を設けて「いんふらっと会」という勉強会を実施しています。この会では、Ｊストリームの基礎となる仕組み理解を目的としています。 初の合宿形式で開催 昨年11月に、1泊2日での初の勉強会合宿を軽井沢で行いました。この合宿では、BIG-IPに特化し、2日間にわたり、Ｊストリームで導入・運用しているF5社のBIG-IP製品について学びました。 BIG-IPは、DNSサービスやロードバランサー（LB）として重要な役割を担っています。重要インフラ機器の運用品質向上と、チーム全体の技術力強化は、組織にとって不可欠です。 実施内容 2日間のプログラムは下記のような内容でした。 【Day 1】 BIG-IP LTM 研修 BIG-IP基礎（仮想サーバー/プール設定） ロードバランシング実装演習 トラブルシューティング実践 【Day 2】 BIG-IP DNS(GTM) 研修 高度な構成設定 nPath構成の実装 DNS/LTM連携構成 広域負荷分散の実現 広域負荷分散の実装演習 トラブルシューティング実践 合宿での研修風景 得られた成果 「運用効率の向上」と「技術的知見の深化」において、以下のような成果が得られたと考えています。 ●運用効率の向上 ・新規構築から運用までの一貫した知識習得 → 実機での構築経験による設定意図の理解 ・iHealthを活用したトラブル時の迅速な対応 → 保守サポートに頼らず、ある程度自分たちで解決可能に ・障害時の迅速な原因特定 ●技術的知見の深化 ・AutoLastHopなどの固有機能の理解促進 ・トラフィックコントロール最適化手法の習得 ・冗長構成における信頼性向上策の習得 ・LTM/DNS（GTM）の製品特性の明確化 → CDNサービスにおける最適な構成の理解 参加メンバーの感想 ●BIG-IP-DNSもBIG-IP-LTMも構築手順がないため、担当でない限りイチからBIG-IPを触る（構築する）というのは中々できない貴重な体験でした。 今回の勉強会は成り立ちを知るのに非常にいい経験でした。（T.K.さん） ●LTMとGTMの名称と役割の違いを改めて整理することができ、設定内容からサービス構成のイメージがつかめてCDNext（自社CDNサービス）の理解にもつながりました。（K.Y.さん） ●Ｊストリームと同じ環境を検証環境として提供いただいたので、実機操作がやりやすかった。（K.E.さん） ●初期設定からロードバランシングまで通してのハンズオンにより、 AutoLastHopといった独自の実装も改めておさらいすることができた。（H.I.さん テックリード） ●iHealthを用いたステータス確認で、現在の高負荷問題への効果的な対処方法を習得できた。また、証明書切れの影響とその確認コマンドを学び、現在直面している課題の解決に直接活用できる知見を得た。（D.I.さん） 休憩は、お茶を入れながらわきあいあいと まとめと今後について 今回の合宿では、下記のような成果が期待されるものでした。 ●トラブルシューティング時間の短縮 ●予防保守による障害の未然防止 ●チーム全体の技術力向上 なお、今後のいんふらっと会では、以下を予定しています。 ●運用手順の標準化推進 ●継続的な技術力向上 定期的な勉強会への参加 ●現行のBIG-IPが2027頃 EOSを迎えるため、新OSの検証実施・勉強会への参加 またご紹介できればと思います。 ※在籍年数や役職を含む記載内容は、掲載当時のものです。その後、状況が変化していることがあります。
こんにちは、Voice編集長の久保田です。 11月18日～22日に開催されたZabbix Conference Japan 2024では、Ｊストリーム・ネットワークエンジニアの小山 拓海がDay 4（11月21日）に登壇しました。 当日、小山は、6月にリリースされたばかりのZabbix 7.0について、自社での構築事例紹介を行いました。業界的に情報が少ない状況に対して、技術的な事例共有で業界貢献したいという登壇者の想いでの登壇でした。 登壇終了直後の小山に、今回伝えたかった技術的ポイント、登壇までの経緯や想い、そして、あわせて、キャリアや組織カルチャーなどについても聞きました。 ↓ 当日の登壇資料はこちらです ↓ DR観点に基づき、データセンタ間冗長での構築を実現 ―― 小山さん、まずは、登壇お疲れさまでした！ 登壇を終えて、一言お願いします。 緊張しなかったのか、登壇もスムーズに終わりました。 そのため、登壇した実感があまりないです。 しかし、撮影していただいた写真を見返すと、自分が本当に登壇していたと改めて感じるようになりました。 ―― さて、本題に入る前に、まずは読者の皆さんへ自己紹介をお願いしたく。普段は、どのような業務を担当しているのですか？ 主にサーバやネットワークの設計や構築を担当しています。 サーバについて、別部署からの依頼があると、要件定義から設計、構築までを担当します。 ネットワークに関しても同様で、ネットワークスイッチの導入から構築、通信の設計や設定の反映などを行います。 最近では、オンプレミスでK8s（Kubernetes）の構築も担当しています。 ―― 今回の登壇されたZabbix Conference Japanとは、どのようなイベントですか？ ネットワーク監視ソリューションを提供するZabbix社が、主催するイベントです。開発ロードマップを共有したり、ユーザー事例、関連ソリューションなどの最新情報が発表される場です。 会期は、Webセミナー3日間と会場＋オンライン2日間でZabbix Weekと称されます。2024年は、11月18日～22日に開催されました。 当日の登壇風景 ―― 小山さんの講演趣旨について、聞かせてください。 今回の講演は、「オンプレ環境でのZabbix7.0：構築内容と気づきの共有」というタイトルで、オンプレ環境でZabbix7.0を構築事例紹介を行いました。 Ｊストリームは、オンプレミスでネットワーク構築を行い、企業向けにサービス提供を行っています。多数の視聴者に映像や音声を配信したり、大量のアクセスにも耐えうるCDN（Conetent Delivery Network）により、安定した配信を実現しています。 そのため、利用企業様の事業継続マネジメントを踏まえたネットワーク構築は、重要な責務のひとつです。 Zabbix7.0での構築に際しては、DR（Disaster Recovery / 災害復旧）観点よりデータセンタ間冗長（L3冗長）構成を実現しました。 このようなケースは前例がないものでした。ですので、当日は、「設計」「構築」「運用」について振返り、当社での気づきを共有しました。自社での取組みをお話しすることで、少しでも業界貢献できればという想いがありました。 今回の移行概要（講演資料より） ―― Zabbix 7.0で構築した背景をお聞かせください。 以前は、同じデータセンタ内での冗長化構成を採用していたのですが、ファイアウォールのメンテナンスや回線のトラブルにより、Zabbixの監視ができない事態が発生していました。 さらに、同じデータセンター内であるにも関わらず、フェイルオーバーに時間がかかり、タイムアウトによる切り替わりが成功しなかったという課題も発生しました。 講演では、4つの問題点としてご説明しました。ぜひ公開資料もご覧ください。 構築検討時の「4つの問題点」（講演資料より） ―― 構築における一番のこだわりを教えてください。 データセンタ間冗長を実現したところです。 当社では、データセンタが離れていた場所にZabbixを立てましたが、データの同期はできているため、差分を発生させない仕組みを構築しました。 他の企業様のユースケースを見るとスタンドアロンで構築されており、運用でデータの整合性をカバーされているように見受けられました。 ―― 構築で最も苦労した点は？ DBレプリケーションの検証で、レプリケーションがうまく張れず、2か月ほど検証に苦戦していました。 意図したDBの切り替わりができなく、途中であきらめそうになりました。 ―― その際には、どのように乗り超えたのでしょうか。 DB自体をMYSQLからPostgreSQLに構成変更することで、上記の問題を解決できました。 下記が最終構成です。最終的には、構築検討時に整理した4つの問題点を、すべて解決させることができました。 最終構成図。4つの問題点を解決し、データセンタ間冗長を実現させた（講演資料より） 登壇を通じて拡がる人脈と可能性 ―― 技術面以外のお話も、うかがいたいと思います。Zabbix Conference Janpanは、 2020年の登壇 に続き2回目ですよね。今回の登壇経緯を教えてください。 今夏に開催された JANOG 54 Meeting in NARAでもZabbixをテーマにした内容で登壇を行いました 。 JANOG54の企業ブースにZabbix社の方がいらっしゃり、その場でお声がけいただき、Zabbix Conference Japan 2024への登壇も決まりました。 1回目の登壇の際は自らZabbix社に応募したのがきっかけでした。 当日の登壇風景 ―― 登壇立候補について、会社へ話した際の反応はいかがでしたか？ 最初は、上長にやんわりと「参加します」くらいにしか登壇意思を伝えていませんでしたし、上長としては「本当に出るの？」みたいな印象だったと思います。会社として断られたら、今年の登壇は諦めようと考えていました。 しかし、上長の快諾も得られ、また登壇資料作成で他の社員も協力してくれました。イベント当日は、会場に足を運んでくれた社員もいました。 ―― 通常業務との両立はうまくいきましたか？ うまくいったと思います。 ―― 通常業務との両立のために、どのような工夫をしましたか？ 資料作りは始業前や終業後、休日に作成することも多かったです。 登壇に向けての練習も同様に行いました。 ―― 登壇にかける熱い想いが印象的でした。その想いの源泉は、何でしょうか？ 要件定義や基本設計がされていないシステムが数多く存在をし、引き継ごうにも引き継げない状況がありました。 自分も運用を引き継げないですし、後から入った方も情報がない中で運用は難しいと考えました。 これらを打破するために、設計からきれいに行って、あとから入った方にも困らないシステムの設計を心がけました。 ―― 登壇準備で、苦労したことなどがあれば教えてください。 資料提出1か月前から作り始めました。 構成をどのようにするのかで結構時間を使ったと思います。 ―― 登壇準備での苦労は、どのように乗り越えましたか？。 資料の構成や文章の修正時には、他の社員もコメントしてくれたり、サポートしてくれました。 登壇２日前にはリハーサルも行い、その場でアドバイスや指摘なども受けられました。 ―― イベントでは、いい出会いがありましたか？ はい、ありました。 登壇後には、当日のプログラム終了後に開催された懇親会を含め、「先ほど登壇されてましたよね？」と多くの方から声をかけていただけました。Zabbix社の方からも数名にお声がけいただけました。 「あの構成での構築は、さすがに難しい」と何人かにお話しをいただけたのは、やはりうれしかったです。 その他、参加されている年の近い方とも交流することができ、仕事や技術的な話で盛り上がりました。 切磋琢磨できるチームでの成長 ―― さて次に、組織カルチャーについてもうかがいます。登壇に際して、社内の反応はどうでしたか？ 社内のSlackチャンネルでは、登壇風景の紹介に拍手やいいねをはじめとした多くのリアクションをいただきました。 今回の登壇に少しでも興味を持ってくれたのではないかと、嬉しかったですね。 ―― 小山さんにとって、所属部門であるネットワークインフラ部を一言で表現すると？ 「切磋琢磨できるチーム」です。 ―― その心は？ ネットワークインフラ部は技術的探究心のある方が多いです。問題解決に取り組む際に情熱を持って向き合い、一つひとつを徹底的に突き詰めるところが部としての強みだと考えています。 講演終了後の会場での様子。同じ部のメンバーと ―― Ｊストリームは、コミュニティ活動が活発ですか？ はい、具体例を挙げると、ネットワーク系では、JANOG（日本ネットワーク・オペレーターズ・グループ）、QUNOG（九州沖縄ネットワークオペレーターズグループ）、JAIPA（日本インターネットプロバイダー協会）などネットワークコミュニティに参加されている方が多い印象を受けます。 ―― 小山さんが考える「コミュニティ活動を楽しむコツ」があれば教えてください。 Ｊストリームに入社したてのころから、漠然とどこかのコミュニティに所属したいなと考えておりました。 わからないながらも参加してみることが大切かなと思います。 ―― 今後の抱負をお聞かせください。 コミュニティ活動を通じて、人と人とのつながりも大切だと実感するようになりました。 そのためZabbix Conferenceだけでなく、コミュニティ活動には積極的に参加できるようなエンジニアを目指していきます。 キャリアの面では、「他部署の相談窓口」としてフルスタックエンジニアのようなポジションに立つ人間になりたいと考えております。 ―― 今回の登壇が、次のステップを引き寄せているようですね。今後も活躍を楽しみしています。 ※Ｊストリームでは、コミュニティ活動を重視し、エンジニアの積極的な参加・取組みを奨励しています。 イベント等でＪストリームエンジニアを 見かけたら、ぜひお気軽にお声がけください！ エンジニア組織が目指すもの | 7つの価値観 ※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。 【関連情報】 Zabbix Conference Japan 2024
月刊ニューメディアにＪストリーム鍋島が寄稿しました。 映像メディアのトレンド（特に電波などの旧媒体からネット媒体への遷移）について、2024年のデータ分析の中から、美味しい（重要な）ところだけを紹介しています。 現在、公式サイト上で全文がご覧いただけます。 映像メディアのトレンド2024 国内YouTubeの広告売上は 日テレと同規模か!?（月刊ニューメディア1月号掲載） また、月刊ニューメディア1月号については、同サイト上より他記事もご覧になれます。 月刊ニューメディア | TOPページ 【執筆者紹介】 鍋島 公章 プラットフォーム本部 エグゼクティブマネージャー / メディアコンサルタント 1995年、米国駐在時にWebサーバの大規模キャッシングについての研究開発を行って以来、インターネットにおける各種メディアの大規模配信について、サービス立ち上げ、研究開発、運用と全方面について関わる
12月7日（土）にオンライン開催される「2024年度第51回情報通信学会大会」でＪストリーム鍋島公章が以下発表を行いますので、ご紹介します。 当日は、OTT(プラットフォーム事業者)の登場により大きく変わろうとしている通信および放送インフラについて、OTT の知見を利用し、調査・分析した結果を発表予定です。 【発表概要】 ■発表タイトル 通信・放送インフラの議論における OTT(プラットフォーム)視点の必要性 ―通信・放送を超えた新時代インフラへの道― http://www.jsicr.jp/doc/taikai2024/fall/C3.pdf ■発表時間 13:00～13:35 大会詳細については、同学会サイトをご確認ください。 【2024年度 第51回情報通信学会大会】 ■開催日：2024年12月7日（土） ■会 場： オンライン開催（Zoom Cloud Meetingsを利用） ■学会大会参加費： 正会員及び賛助会員 2,000円 正会員（院生） 1,000円、 非会員 3,000円 非会員（院生）1,000円、学部学生 無料 http://www.jsicr.jp/operation/taikai/index.html 【発表者紹介】 鍋島 公章 プラットフォーム本部 エグゼクティブマネージャー / メディアコンサルタント 1995年、米国駐在時にWebサーバの大規模キャッシングについての研究開発を行って以来、インターネットにおける各種メディアの大規模配信について、サービス立ち上げ、研究開発、運用と全方面について関わる
皆さん、こんにちは。Voice編集長の久保田です。 オープンソースのネットワーク機器監視ソリューションを展開するZabbix社が、11月18日(月)～22日(金)でカンファレンスを開催します。 ■ Zabbix Conference Japan 2024 Webinars：2024.11.18-20 Coference：2024.11.21-22（於：東京・港区） 本イベントでは、Ｊストリーム・ネットワークエンジニアの小山 拓海が、以下日程で登壇します。 ■Ｊストリーム登壇情報 【日時】 Day 4 – 2024.11.21 14:20～14:50 【講演タイトル】 「オンプレ環境でのZabbix7.0：構築内容と気づきの共有 」 【登壇者】小山 拓海 Ｊストリーム ネットワークインフラ部ネットワークインフラ課 小山は、2020年に続いて、Zabbix Conference Japan2回目の登壇です。 また、今年7月に開催されたJANOG54でも登壇し、大変多くの方にお聴きいただきました。下記よりその時の内容も併せてご覧いただけます。 ※JANOG54プログラム紹介 機器監視のためのZabbixを、DB含めてL3冗長化した話 – JANOG54 Meeting in NARA Zabbix Conference Japan 2024の講演視聴は無料ですので、ぜひご都合があう方はご参加ください。 【関連情報】 Zabbix Conference Japan 2024 イベント当日の様子は、またVoiceでもご紹介予定です！
こんにちは、Voice編集長・久保田です。 株式会社リックテレコム様が月刊で発行する情報通信ビジネスの専門誌「テレコミュニケーション」より、新しいCache、オープンキャッシングに関するインタビュー依頼をいただきました。 記事は、10月号に掲載されておりますが、先日、同社 Webメディア「BUSINESS NETWORK」にも 転載・公開されましたので、ご紹介いたします。記事の全文がご覧いただけます。 ■月刊「テレコミュニケーション」10月号/「BUSINESS NETWORK」掲載 ※下記URLより同社サイトへリンクします オープンキャッシングとは何か 動画配信の効率化からトラフィック平準化へ｜BUSINESS NETWORK オープンキャッシングとは、ISPとCDN事業者の新しい形の協力モデルであり、ISPが設置したキャッシュサーバを、CDNの共用型キャッシュサーバとして使用するモデルです。米国の業界団体であるStreaming Video Technology Alliance（SVTA）が標準化をすすめています。 インターネット上でのコンテンツ配信量が増大するなか、ネットワーク全体の負荷軽減は重要な課題であり、新たな仕組みが模索される中での動きです。 インタビューでは、「オープンキャッシング」の仕様・特徴や導入による各事業者へもたらす影響、国内外の導入状況などをお話しいたしました。そのうえで、株式会社JPIX様、ケーブルテレビ株式会社様をはじめとした各社様と弊社にてここ数年かけて進めています共同実証実験についてもご説明させていただきました。 なお、オープンキャッシングに関する取組みについては、JANOG53でも発表し、Voiceにレポートを公開しております。 「日本に上陸した新しいCache、Open Cachingを触ってみた。」JANOG53レポート オープンキャッシングへの取組みは、今後の継続的な活動に際して、随時参加者を募集しています。ご関心のある方は、ぜひお声がけください。 【関連記事】 月刊テレコミュニケーション10月号バックナンバー紹介ページ
JPNIC様ニュースレター（No.87/2024年8月発行）にＪストリーム鍋島が寄稿しました。 CDNというネットとコンテンツの中間的なビジネスを行っている立場から、 サービスの今後について日々分析しているデータを元に、 ストリーミングの現状と今後について概論しています。 現在、公式サイト上で全部がご覧いただけます。 ニュースレター No.87 OTT(ストリーミング)のトレンド2024 – JPNIC 【執筆者紹介】 鍋島 公章 プラットフォーム本部 エグゼクティブマネージャー / メディアコンサルタント 1995年、米国駐在時にWebサーバの大規模キャッシングについての研究開発を行って以来、インターネットにおける各種メディアの大規模配信について、サービス立ち上げ、研究開発、運用と全方面について関わる。
Ｊストリームは、 5月11日（土）に開催された会津大学公認の技術系サークルZli（ジライ）主催の「大LT 2024 春 in Aizu」に協賛しました 。技術LTに登壇した2名のエンジニアより、当日の感想と発表資料の共有です。 ※LT：Lightning Talks（ライトニングトーク）の略で、短いプレゼンテーションのことを指します。 イベント概要 ＜ 大LT 2024 春 in Aizu イベント情報＞ 【日時】 2024年5月11日（土） 12:00開場、13:00開始（予定） 【会場】 会津大学内 【参加対象】 Zli部員限定 今回のイベントには、Zliサークルメンバーの学生の皆さん と協賛企業約60名が参加しました。当日は、LT13:00～18:00＋懇親会という半日かけてのイベントでした。 技術LTその1：YubikeyとNFCでおしゃべりしてみた（並木優祐） プラットフォーム本部 技術開発部の並木です。 会津大学の学生に負けない、かつ公開できる内容ということでだいぶ悩みましたが、 プライベートで YubiKeyを使って 遊んでいた ことを思い出し、今回のLTのテーマにしました。 前半は 一般的なご家庭 にあるインフラ環境の紹介、後半はFIDO対応の 認証器であるYubiKeyにNFCを使ってアクセスし、実際に認証を行ってみる方法を紹介しました。 自宅インフラの紹介に力を入れすぎたため、全体的にかなり駆け足になってしまいましたが、 学生に負けないような内容になっていたと信じています… フロントからバックエンド、インフラ、ハードウェアなどさまざまな分野から濃い内容でのLTが行われており、 今年も レベルの高いLTが多いと感じました。 どれも面白いLTでしたが、個人的には特にshinbunbunさんの「Rustでコンテナランタイムを自作してみた」やkashuさんの「自宅サーバー運用日誌」が面白かったです。 コンテナ技術は当社でも利用していますが、その実態はプロセスの名前空間を分離したもの、例えるならサンドボックスで実行されたプロセスです。 というのはなんとなく知っていましたが、意外と簡単にそれを行えるというのはいい勉強になりました。 また、インフラ周りは当社の最も重要な技術の一つであり、私がプライベートでも遊んでいるものになります。しかし、まさかBGPの話が私の他に出てくるとは思いませんでした（笑） 今回のLT会に参加して、 普段なかなか触らない分野を知ることができ、 ますますいろんなことに触れていきたいと思いました。 来年も機会があれば、もっと濃い内容で挑んでみたいですね 。 当日の登壇風景（並木優祐） 技術LTその2：××な話（べにはら） ネットワークインフラ部 ネットワークインフラ課のべにはらです。 前回やった情報量0タイトルがLT大会では好評でしたので、 今回も引き続き情報量のないタイトルとさせていただきました。 内容は大まかにサーバの冗長化の話となっておりますが、一般の冗長化から一歩踏み出して、 全国規模で配信サービスを展開している弊社ならではの要素が大きく入っているお話となっています。 ネットワーク・サーバどちらの要素も入っており、インフラエンジニアらしい内容になっているかと思いますので、タイトルの謎も含めてぜひお楽しみください！ なお、本当は”ご”家庭紹介も時間をかけたかったのですが、尺とページ数の都合で今回は控えめですw 今回のLT大会は大きく分けて学生枠と社会人枠となっていました。 社会人枠は言ってしまえば皆さんプロでお仕事されている方々なので、レベルが高いのは自然なのですが、 学生枠のLTもそれに負けず劣らず技術力の高いLTが多く、1日中非常に楽しめました。 その中でも特に、社会人LTでは背景に仕事上の課題があるのに対し、学生LTでは背景に「やってみたかった」「興味がある」「楽しそう」というモチベーションが多かったのが印象に残りました。 学生の頃から技術に対して非常に前向きなモチベーションで取り組んでおり、社会人と比べても遜色ないレベルのスキルを習得しているのは素晴らしい、一緒に働きたいなと思いました。 今回のLTはどれも面白かったのですが、一番興味深かったのは「SMTPSでメールを送ろう」のLTです。 タイトルから初学者向けのやってみた系のLTかと思ったら、SMTPのプロトコルの実装を紐解き、プロトコルの仕様に倣ってSMTPクライアントを実装、さらにそのデモも行うという、 なんともエンジニア心を揺さぶられるLTで聴いていてとても楽しかったです。 今回の参加を通して、社会人として学生達に負けないよう精進しつつ、来年も機会があれば是非参加させていただきたいと思います。 その際にはまた情報量0のタイトルで臨みたいと思いますw 当日の登壇風景（べにはら） Zliの皆さん、お疲れ様でした＆ありがとうございました Ｊストリームも楽しくて、実りの多い時間を過ごすことができました。 またぜひお邪魔し、皆さんと交流できればと思います。 Voiceでは、今後もさまざまな社内外イベントをご紹介予定です。ぜひご覧ください！ 【関連情報】 ・ 大LT 2024 春 in Aizu – connpass 詳細ページ
※記載している各登壇者の所属は発表時点のものです。写真はJANOG53ミーティング フォトアルバムより 「Open Caching」という新しいCDNをご存じでしょうか。これは、SVTA(*1）という国際アライアンスによって策定された CDN の仕様です。 インターネット上でのコンテンツ配信量が増大するなか、ネットワーク全体の負荷軽減は重要な課題であり、新たな仕組みが模索されています。2024年1月に開催されたJANOG（*2）53では、「日本に上陸した新しい Cache、Open Cachingを触ってみた。」と題するプログラムが行われました。本プログラムでは、過去、2023年に共同で実施されたOpen Cachingの実証実験結果に関する共有が行われました。 登壇者は、株式会社JPIX 中川 あきら氏、ケーブルテレビ株式会社 石川 英昭氏、Ｊストリーム エンジニア推進室兼プロダクト企画部（アーキテクト） 高見澤 信弘の3名。 中川氏からは「Open Caching全体の話」、石川氏からはISP（Internet Service Provider）視点で、高見澤からはCDN事業者視点でというそれぞれの切り口より発表が行われました。本記事では当日の様子をレポートします。 （本文中敬称略） （*1）SVTA （Streaming Video Technology Alliance）:世界の大手を含むコンテンツ事業者・CDN事業者・ベンダー等が集まるストリーミングビデオの相互運用向上のためのアライアンス。ストリーミングビデオの運用性向上を追求している。 (*2）JANOG：JApan Network Operators’ Groupを意味し、インターネットにおける技術的事項及び、それにまつわるオペレーションに関する事項を議論、検討、紹介することで、日本のインターネット技術者や利用者に貢献することを目的としたネットワーク運用者の集い。 Open Cachingとは 一人目の登壇者・株式会社JPIXの中川 あきら氏から、まず、「Open Cachingとは」「実証実験でOpen Cachingを触ってみての結果」について発表されました。 株式会社JPIX 中川 あきら 氏（写真は、JANOG53ミーティング フォトアルバムより） 冒頭、中川氏より、Open Cachingとは、SVTA という国際アライアンスによって策定された CDN の技術仕様であるとの説明がありました。この仕様は、比較的新しい RFC などを元に策定されています。いずれもオープンな場で策定されたものであり、全体としてオープンでニュートラルな技術が使われていることが特徴です。このSVTAの仕様をもとに、米Qwilt社がOpen Cachingをサービス化させています。 中川氏はOpen Cachingの概要として、その仕組みを以下のように説明しました（図1）。 『Open Cachingでは、Origin ContentをShield、Edgeという2階層のCache Serverから配信する構成になっています。その配信を司るのがOCC（Open Cache Controller）と呼ばれる管制塔です。インターネット上の管制塔からは常時全てのノードのトポロジーや正常性などを把握しており、仮に何らかの理由でEdgeが落ちた場合には、事前の設定に基づき、他のEdgeや上位の Shield （総称して OCN ※Open Caching Nodeと呼ばれる）から配信されるように、OCCが各ノードに自動で司令を出します。 【図1】Open Cachingの概要 上記説明では、管制塔という表現が用いられましたが、管制官にはQwilt社のオペレーターがインターネット経由で各ShieldやEdgeにアクセスできる体制となっています。各CP、ISPは、ダッシュボードによりトラフィックのイン・アウトを確認することが可能になっています（図2）。 【図2】Management Plane 配信のための3ステップとしては、 【1】OriginからOpen CachingへのRedirect 【2】Open Caching内でEdgeへのRouting 【3】コンテンツ配信 となり、Edge1がダウン時は、OCC（Open Cach Controller）よりEdge2が指定されます。全Edgeがダウンした場合は、Shieldから配信されますが、そのコントロールはきわめて簡単であることを特長として挙げていました（図3）。 【図3】配信のための3つのステップ 今回の実証実験を経て、中川氏は、Open Cachingの特長として以下4つにまとめました（図4）。 1)オープンでニュートラル 2)Edge (Cache) をエンドユーザーに近い ISP に設置可能 3)コントロールが簡単 4)API が充実している、他 【図4】Open Cachingの特長 実証実験では、Multi CDNでのAS間切替え、IPv4/IPv6の共存を確認 続けて、中川氏より2023年実施のOpen Caching実証実験に関する概要説明が行われました。実証実験は、春と秋の2回行われました。春は、株式会社JPIXの他にJCOM株式会社、Qwilt社、Ｊストリームが参加。秋は、残項目と追加項目に関しての実験を進めるために、ケーブルテレビ株式会社、株式会社JPIX、Ｊストリームが参加しました。実証実験で確認された主な項目は、下記3つでした。 【1】Multi CDN の動作 【2】Open Caching の動作（DNS・https 、IPv6・IPv4） 【3】品質（QoE）の確認 実証実験では、Open Cachingは総じてスムーズに動いており、Multi CDNでのAS間の切替えも問題なく、IPv4、IPv6の共存も確認できました。また、機器ダウン時の挙動として、各プロトコル（IPv6／IPv4）のトラフィックが正常に迂回されることも確認できました。機器障害時にどのトラフィックがどう迂回されるのか、設計の重要性を実験で再認識したという経験者としての所感共有もありました（図5～7）。 【図5】実証実験の全体構成（Multi CDNの確認） 【図6】実証実験におけるOpen Cachingの構成 【図7】実証実験におけるShield‐Edgeの構成と確認した挙動 ISP視点でのOpen Cachingの利点とは 2人目の登壇者であるケーブルテレビ株式会社の石川 英昭 氏からは、「ISP（Internet Service Provider）視点でのOpen Caching」について語られました。 ケーブルテレビ株式会社 石川 英昭 氏（写真は、JANOG53ミーティング フォトアルバムより） ケーブルテレビ株式会社は、栃木県、群馬県、茨城県、埼玉県の4県6市6町にFTTHエリアを展開しているケーブルテレビ事業会社です。Open Caching利用のきっかけは、2021年に総務省の実証事業でEdgeを導入したことでした。 石川氏からは、Open Cachingの導入経験について Before （2021～2023）/ After（2023～）に分けて説明がありました（図8）。 【図8】今回のプレゼン範囲 石川氏によると、Before時代のEdge導入背景としては、TOCHIGIXでのチャレンジ、上位回線コスト削減（特にトランジット回線）、トラヒックの品質向上（QoE）がありました。2021年時点で、Edge単体の導入により僅かながらの改善が図られていました。しかし、冗長構成や配信規模の拡大、IPv6対応などの新たな課題も見えてきたと言います。そこで、2023年の実証実験では、JPIXに設置をしているQwit Shieldを利用し、次なる検証へと取組んでいくことになりました。 2023年の実証実験では、Edgeダウン時等の冗長構成、およびDual Stack環境での動作検証を確認ポイントに据えたと言います。JANOG登壇当日は、石川氏より、Dual Stack 区間、IPv6-only 区間、 IPv4-only 区間、それぞれの区間で適切なプロトコルが使われていることを確認できたと報告されました（図9、図10）。 【図9】冗長構成・Dual Stackの検証イメージ 【図10】IPv6/IPv4コンテンツ配信の結果 石川氏は、2021年からの2度にわたる経験を振返り、以下のようにまとめました。 ・通常時にShield からEdgeに配信されるトラフィックが IX 経由のため、Transitのトラヒックを削減することが可能になった。 ・Edgeダウン時においても、Shieldからエンドユーザーへの配信がIX経由になるため、Transitの従量課金への影響が出ない。 ・Edgeシングル構成の場合、Shield が Edgeの「予備系」となるため、ISPとしては「冗長構成」を満たすことができた。 ・オリジンコンテンツがIPv4で配信する場合も、Open Caching Nodeからエンドユーザーに対してはIPv6で配信できるため、自社(ISP)のネットワークにおけるIPv4 Trafficの削減を期待できる。 ・複数のISPが Shield を利用することにより、CP 視点では大きなCDNとなるため、CP がコンテンツを流すモチベーションになると考えられる。 CDN事業者にとってのOpen Cachingの利点とは 登壇者の最後は、Ｊストリームの高見澤から、CDN（Content Delivery Network／エンドユーザーに近い場所からコンテンツを配信するためのサーバー群のこと）事業者として「Open Cachingの実証実験を通して、新しいCDNの仕組み導入から得られた知見」が発表されました。 株式会社Ｊストリーム 高見澤 信弘（写真は、JANOG53ミーティング フォトアルバムより） CDNとは、データを効率よく最適に配信する仕組みのこと。エンドユーザーの近くにキャッシュサーバーと呼ばれるCDNの配信サーバーを多数設置し、オリジンサーバーに置かれている大元のデータをキャッシュサーバーが一時的に複製（キャッシュ）することで、エンドユーザーに配信します。高見澤は、CDNのポイントとして大きく以下2点をあげました。 1．キャッシュサーバーをエンドユーザーの近くに置く 2．エンドユーザーに近いキャッシュサーバーにトラヒックを誘導する Open Cachingでは、ISP内に共有キャッシュサーバー（Edge)を設置することで、コスト面の問題をクリアしながら上記1の充実を図ることが可能となります。国内CDN事業者としては、Open Cachingを活用することで、ネットワークの公平性（ISPにやさしい）を担保し、高い視聴品質を保てることをメリットとして挙げました（図11）。 【図11】国内CDN事業者からみたOpen Cachingのメリット 実証実験では、障害試験やIPv6 SingleStackでの配信試験なども実施されました。Edgeとなるキャッシュサーバーの障害時は、Shieldとなるキャッシュサーバーへフェイルオーバーする挙動も確認できました（図12）。 【図12】検証してみてわかったこと また、Open Cachingの品質（QoE）については、 『Request Latencyとしては、動画再生時の”First byte”はOpen Cachingの方が好スコアとなりました。国内においても、距離的に近いOpen Cachingが有利に働く結果となりました』との報告がされました。 一方で、動画の全体的な視聴者エクスペリエンスとしては、全CDNにおいて100（最高スコア）という結果も出ていました。高見澤からは、『両結果を踏まえると、国内のネットワークは優秀ではあるが、Open Cachingを使うことで、よりダイレクトな配信になることによるトラブル発生時の切分けやすさや、キャパシティ強化という点において期待が持てるのではないか』との見解が述べられました。 最後に、高見澤からは、どのようにエンドユーザーを誘導していくのかという「トラヒックの誘導」について語られました。Open Cachingは、各ISP内のキャッシュサーバー （IPアドレス）に対して誘導するため、 DNS方式により誘導しています。 DNSベースでの誘導における課題としては、誘導の精度がキャッシュDNSサーバーベースで決まることです。キャッシュサーバーを地域分散することはある程度できるものの、より高精度な誘導方法を考えておく必要があります。 上記課題に対する解決案として、高見澤からは、ECS（EDNS Client Subnet）というRFC7871で標準化された技術を使用しコントロールする方法が紹介されました。Open CachingのOCCは、ECS対応をしており、ECSはクライアントのIPアドレスやサブネット情報を権威DNSへ伝えることができます。現在、ＪストリームもECS対応を進めており、今後、DNSキャッシュサーバーのリソースへの影響等について検証予定である旨を言及し、報告を終了しました（図13）。 【図13】ECSの動きについて 今回の実証実験に関して中川氏、石川氏、高見澤からは、Open Cachingの活用により、冗長構成やDual Stackへのスムーズな対応、キャパシティ強化など多くの効果が期待できる点が発表されました。そして、今後の課題として、Edgeの上位回線のトラフィック削減率や、ECS対応やIPv6のアドレス集約による高度な誘導の可能性など、実証実験を重ねながら詳細を明らかにしていく方向性が共有されました。 最後に、今後の継続的な活動に際して、参加者を随時募集している旨の呼びかけをして、プログラムは幕を閉じました。 ―― 今後の取組みについては、また、Voiceでもお伝えできればと思います 最後までお読みいただき、ありがとうございました。 当日会場の様子（写真は、JANOG53ミーティング フォトアルバムより） 【関連情報】 JANOG53 プログラム紹介ページ 日本に上陸した新しい Cache、Open Caching を触ってみた。 – JANOG53 Meeting in Hakata 新しい Cache “オープンキャッシング” の実証実験開始(2022.12.07 プレスリリース) ※Ｊストリームコーポレートサイトへリンクします
第３回は CDNの負荷分散にまつわる話 をご紹介します。 広域負荷分散 CDNでは、一部の設備に負荷が偏らないようにしたり、ユーザーに最適な配信サーバを自動的に選択するといった、負荷を分散して効率よくコンテンツを配信する制御が行われています。 ここでは、 「 重みづけラウンドロビンによる制御 」 「 IPアドレスやAS番号による制御 」 「 ユーザーとキャッシュサーバ間の距離(RTT)による制御 」 について解説します。 重みづけラウンドロビンによる制御 配信設備は拠点によって処理性能が異なります、そのため高い性能の設備に少量のリクエスト、低い性能の設備に大量のリクエストが入ると配信効率が悪化してしまう問題があります。 「 重みづけラウンドロビンによる制御 」は、キャッシュサーバクラスター単位でどのクラスタに優先してユーザーからのリクエストを流すかを制御する仕組みです。 例えばA/B2つのクラスタがあった場合、全体の80%をクラスタAに、残りの20%をクラスタBに割り当てることで 、クラスタが受信するリクエスト数を制御します。 このように「重みづけ」によりリクエスト数を分散することで、例えば、大規模な設備には大きい値を設定し、小規模な設備には小さい値を設定するといったことを行うことで、配信設備の処理性能に応じた比率でリクエスト数を分けることができ、効率的な分散処理を実現することができます。 「重みづけ」は、固定値で比率を設定する場合や、データ流量に応じて比率を動的に変化させる場合など、用途に応じて多様な設定手法を用います。 IPアドレスやAS番号による制御 キャッシュサーバが設置されているデーターセンターには通常のインターネット回線とは別に、インターネットエクスチェンジ（IX）を利用した回線が接続されています。IXなどの相互接続点を利用するこことでインターネットサービスプロバイダ（ISP）などのネットワークと相互に 相互に直接接続します。 IXには複数の事業者のAS拠点が接続されており、AS同士の取り決めにより相互接続を行います。 IXを経由した接続については「 パブリックピアリング 」といいます。 一方でAS拠点同士を1:1で直接接続した形態の場合は「 プライベートピアリング 」といいます。 パブリックピアリングを行うことで、専用の回線を用意する必要のあるプライベートピアリングよりもコスト抑えて、相互接続を行うことができます。また、ピアリングによるAS拠点間の直接接続により、通常のインターネット回線よりも低遅延で通信を行うことができます。 CDNでは「 IPアドレスやAS番号による制御 」を行うことで、ユーザーがリクエストした際のIPアドレスやAS番号の情報を利用して、 ピアリングしているインターネットサービスプロバイダからの通信であれば、IXと接続している配信拠点のサーバーに誘導することで 、より低遅延でデータを送信できるように制御しています。 用語解説： ・AS (Autonomous System)：日本語では自律システムと訳される、あるポリシーにより管理運営されたネットワークの集まりを指す。 ・AS番号：ASに割り当てられたユニークな識別番号 ユーザーとキャッシュサーバ間の時間距離(RTT)による制御 CDNを使っていてもユーザーからサーバまでの通信距離が遠いとパフォーマンスに影響が出てしまいます。 ユーザーのPCやモバイル端末から接続先のサーバまでの通信距離が遠いほど通信に必要とする時間が長くなり、一般的に通信速度は低下します。 インターネットの仕組みではデータのサイズが大きいほどを小分けにしてユーザーとサーバ間でデータの送受信が何度も発生するため、一回の遅延が小さい場合でも、積み重ねれば大きな遅延になる場合があります。そのためユーザーからサーバまでの距離がなるべく短いほうがよいわけです。 ユーザーからなるべく距離の短い経路を選択するために「 サーバ間の時間距離(RTT)による制御 」を行います。これは、RTT（round trip time）を利用することで実現されます。RTTとはデータ（パケット）の往復時間のことで、通信にかかる時間をミリ秒単位で計測した結果です。RTTの情報を利用して、ユーザーからどのキャッシュサーバクラスタが最も短い時間で到達できるかを判定することで通信速度のパフォーマンスを向上させています。 例えば、東京のユーザーは関東のデータセンターからデータを取得する、大阪のユーザーは関西のデータセンターからデータを取得するように、自動的に最適なデータセンターに誘導されます。 マルチCDN マルチCDNとは、複数の異なるCDNベンダーを利用できるように配信システムを構築することです。単一のCDNベンダーで配信するよりも以下のようなメリットがあります。 ・ 異なるCDNを複数利用することで、 冗長性が増すために障害に強くなる ・配信負荷をCDNベンダー間で分散できるためキャパシティのより大きな配信ができる ・ユーザーをより最適なCDNに誘導できパフォーマンスの改善ができる ※例えば海外のユーザーは海外に設備を持つCDNに誘導したほうがパフォーマンスがよい 大量の同時接続の発生が予想されるライブ映像配信などでマルチCDNの利用が増えています。 「 マルチCDN 」の環境では、複数CDNベンダーへの誘導を制御するために、マルチCDNセレクターサービスを利用します。 例えば、RUM(Real User Monitoring)方式により、実ユーザーのパフォーマンス計測を行い、分析結果から最適なプラットフォームを自動的に選択する仕組みを提供する「Cedexis」を利用した場合のマルチCDNセレクター構成について説明します。 マルチCDNセレクターは「Radar」「Mux」「Openmix」といったサービスを連携して構築することができます。 ・Cedexis Radar：CDN稼働率・レスポンスタイム・スループットなどを計測 ・MUX：視聴Player のバッファリング数や時間・エラー発生数などを計測 ・Openmix：CDNの振り分けロジックを定義 ユーザーが利用する配信Playerに「Radar」「Mux」のAPIへのコールを組み込むことで、配信Playerから各種配信品質の情報を取得しリアルタイムに計測します。その情報を元にどのCDNベンダーに誘導するのが最適であるか決定されます。このような仕組みにより常に最適な経路を動的に切り替えることが可能となります。 また、オリジンサーバの仕様によっては、複数ベンダーの配信仕様に合わせられないといった問題が発生することがありますが、手前に自社CDNを設置することで仕様の差異を吸収して配信させる工夫を行うことがあります。 【関連情報】 ※別サイトのＪストリームコーポレートサイトへリンクします。 J-Stream CDNext サービス紹介ページ
IPv4枯渇対応により生じる「IPアドレスの一意性」への影響 突然ですが皆さんは自分が使っているIPアドレスはご存知でしょうか。 一般的に皆さんのPCや家からインターネットに抜けていくにはプライベートIPとグローバルIPがあります。プライベートIPはPCの設定を確認すれば知ることができ、グローバルIPアドレスについてもWebで「確認くん」などと調べれば知ることができます。 今回はこの中のグローバルIPに着目します。 グローバルIPは組織ごとに世界で一意なアドレスが振られることで、世界をつなぐインターネット上で住所の役割を担っています。Ｊストリームも、皆さんのご自宅も、フリーWi-Fiも、インターネットに接続される組織はインターネット上で一意なIPアドレスを持っています。 、、、今までは。 実は近年、IPv4枯渇問題への対応としてIPv4 over IPv6技術が普及してきたことにより、1つのグローバルIPを複数の組織で共有するケースが増えてきました。技術的にはMAP-EやDS-Liteと呼ばれる技術です。これらの技術を用いてインターネットに接続している場合、自分と同じグローバルアドレスを持つ組織が複数存在することになります。 グローバルIPは世界で一意であるからこそ、インターネット上の住所としての役割を果たしていましたが、さて同じグローバルIPを持つ組織が複数存在してしまった場合、どうやって相手を特定するのでしょうか。 そこで登場するのがポート番号です。 「IPアドレス+ポート番号」で一意性を担保する近年の方式 まずは、ポート番号についての説明を軽くしておきます。 インターネットにおける殆どの通信は、IPアドレスだけでなく、ポート番号も併用して通信しています。 ポート番号は本来、どんな通信か（Webの通信、メール、ファイルのアップロード、時刻同期、etc.）を判別するのに使われる技術で、1つのIPアドレスにつき65535個のポート番号があります。そのため、1つのグローバルIPにつき65535種類の通信を同時に行うことができる計算です。 ただ、一般の家庭ではそこまで多くの通信は同時に行われることがありません。 そこでMAP-EやDS-Liteでは、ポート番号を小分けにし、複数の組織に割り振ることで、IPアドレスは同一でもポート番号により通信と組織の紐付けを行うことができるようになります。 これにより、IPアドレスを節約しつつ、「IPアドレス+ポート番号」の組み合わせにより組織の一意性を確保できるようになりました。 従来と近年普及している通信方式の動作イメージ ※ 要点を理解しやすくするため、実際の通信経路とは若干異なる図となっております IPv6時代の到来で、アクセスログの記録情報項目も見直す時期に さて、ここで表題の件のアクセスログについて触れてみましょう。 ※ちなみに、Ｊストリームでは、サービス提供に対する配信根拠や課金根拠として、アクセスログを収集しています。そのため、新卒入社社員は部門問わず、新人研修でアクセスログについて学びます。 現在多くのシステムにおけるアクセスログでは、通信元の情報としてIPアドレスを利用しています。なにか問題があった場合などはそのIPアドレスを元に調査を進め、ブラックリストの登録や逆に通信制限の緩和などを行います。 ただ上記の通り、IPアドレスを複数の組織で共有していた場合、対象の組織を一意に特定することができないため、今まで通りの対応では不十分となってしまいます。 例えば、あるIPアドレスから攻撃と思われるアクセスが多発したため、そのIPアドレスからの通信を拒否する設定を行ったとします。対象のIPアドレスが複数の組織で共有されていた場合、うち何も問題を起こしていない組織もこの通信制限に巻き込まれてしまいます。 このように、MAP-EやDS-LiteといったIPv4 over IPv6技術の普及に伴い、アクセスログに記録が求められる通信元の情報も変化してきております。 アクセスログに記録する情報項目について、今一度見直してみる時期が来たのではないでしょうか？ では、本日はこの辺りでお別れといたします。 お読みくださりありがとうございました。