Googleのサービスに納得いかないので自分で作って良いのかの葛藤を5年間くらい続けている
一般的にすでに十分大きくて開発コストのかかっている既存サービス(Googleほにゃらら）と同じようなシステムを開発することは、勝てっこないし無駄な労力で良くない、素直に迎合すべきこととされていると思う。この考えのせいで葛藤して判断が遅れているのが非常につらい。
例えば検索や地図やブラウザなどはGoogle、クラウド基盤はAWS、小さいツールでいうと動画変換はffmpegで画像変換はimage magick、形態素解析は～機械学習は～WEBフレームワークは～など定石ともいえるツールであふれていて、それをうまく組み合わせて使うのが賢いといわれている。
とはいっても、どうやっても既存サービスでは解決できない事があったり、不便・不都合が我慢ならない場合があるし仕事に支障が出ることは多い。そもそもなんで他人がつくったサービスを無理して使わないといけないのかと我に返るときがある。本当に簡単なものであればさっさと自分で作るのだけれども、それなりに手がかかるものの場合、「流石にGoogle様等の作った業界標準サービスを使わないのはダメだよなぁ」、となってしまう。しかし素朴なつくりであれば、案外作れるものがあると思う。実際作れるのだけれども、諦めてしまう。諦めるための理由を見つけようとしているだけなのかもしれない。
当然、大手しかサービスが無いわけではない。マイナーな良サービスはある。でもきっとそれにも欠点はある。どうせ自分で作れるレベルなのなら、自分が求めるものを自分で作ったほうがいい。
現場に出て5年間くらいずっと葛藤しているが、ほとんどのサービスについて「作るべき」だとようやく思い始めた。（手が動くかどうかは別）しかしここまでくるのに何年間もかかったのが残念すぎる。大学のころに色々手を付けておくべきだった。
やはり諸々自信が無い。自分の中で”十分に理解が深まった”と思えるような分野がほとんどない。でももう人生の時間は限りあるし、わからなくても手を動かさないと負け。実際は自分の思っているより”他人より”理解できている。
ここでは、流石にそろそろ自分で作るかと思っているサービス（すでにGoogleがやっている）を挙げていく。
自分でも作れんじゃね？サービス
1. Google Analytics（Webアクセスログ集約基盤）
いわゆるウェブサイトのアクセス数分析をするためのツールの定番で、これさえ入れておけばいい、という扱い。
既存のGoogle Analyticsの問題点
・構造が複雑すぎる。ユーザー・集客・行動・コンバージョンというカテゴリで多くの情報が取り扱えるということになっているが、デフォルトだとほとんどのデータが格納されていない。無数にある管理画面から正解（意味のあるデータが格納されている項目）を見つける高難易度ゲームとなっている。
・基本的にデータの反映が半日から1日程度かかる。今日の数字を知るのは明日の昼過ぎ、となる。アクセス数などを知りたいのは基本的にイベント中もしくはその直後なので、役に立たない。
・リアルタイムの値が直近30分のみの一部の値しか閲覧できない。フィルターを掛けて一部のみを見ることもできない。
・基本的だと思うイベントがデフォルトだと取得できない。ユーザーのクリックしたボタンやvideoタグの再生数など。Google Tag Managerなどで追加のイベントを発火させる必要がある。
・上記は有料のGoogle Analytics 360でも同じ
・2023年7月に旧来のバージョンであるUAを終了すると言っているのに、上記の問題はGA4（次のバージョン）でも改善する見込みがない、どころかGA4ではダッシュボードの閲覧がさらに難解になっており、直観的に基本的な値を見ることすらできなくなった。
どう対抗するか
・とにかく素朴につくる。
・超大量アクセスは想定しない。
・現場で必要なもののみを取得する。必要な情報を数秒おきに収集すれば良い。
デファクトスタンダードというGAのメリットを享受していない組織において、きっと同じ感想をGAに抱いているならば、絶対にメリットが多い。
懸念点
・プライバシーポリシー周り、既存サービスが戦ってきたものを考慮する必要がある。ただし彼らとは違って別のサービスと顧客情報をやり取りするためのサービスではなく、あくまで1stパーティデータを集めるだけなので難易度は低い。
・とはいっても大量アクセスに耐えないといけない。ブラウザの動作も軽くしないといけない。QUICなど新しいプロトコルを使いたいところだけれども、今スムーズに実装できる手段は限られるかもしれない。
2. Google AdManager・Google Admob（アドサーバ）
WEB広告サービスはどれも地獄。とにかく単純化が必要。ネットワーク広告を1から立ち上げるのは困難だが、自社の純広告くらいはちゃんと掲出したいということで、アドサーバを構築したい。例えば広告を設定したもののちゃんと表示されない、というときに正しく理由を表示できるアドサーバは存在しない。
さらに動画広告を正しく表示するためのVASTタグの構築などができるサービスはとても少なく困ることが多い。
アプリについても同じで、ネットワーク広告をネイティブアプリに表示するためのAdmobはマルチバイト文字に対応してないに等しいなど問題が多い。
昔ホリエモンが1人で広告サービスを作ったとかあるけれども、本来1人で作れるもの。Googleに頼るデメリットはとても多い。
3. Google検索（検索エンジン）
ご存じの通り、昨今の検索エンジン（笑）は、純粋なAND検索ができなくなった。特にマルチバイト文字圏の単語は勝手に1-gramで文字を分解して、すべての言葉がヒットしてしまう＝Googleの表示したい項目が表示されるだけの、超恣意的サービスになっている。
この検索システムの劣化は、Google検索だけでなく、他の検索エンジン、Googleのサービス内（Gmailなど）、アメリカ発のサービス全般で見られる傾向となっている。
そこで、純粋にAND検索ができるような検索エンジンを作るだけで人気が出ると考えている。
ただ、Google・Bingがここまで必死に”まともに検索しないように”する理由もあるのだと思う、世の中にウェブサイトが多すぎて計算コストが非常にかかるのか？そもそも検索エンジンというのがどういう理屈で動いているのかを理解していない（インデックスを作っているから速く検索できるのだとは習った）が、ちゃんとした計算リソースと知識が組み合わされば、シンプルな検索エンジンはできると思っている。
ちなみにすでに手を出したツール
1. 動画配信サービス(限定公開のみのYouTube、Vimeoなどと同じ）
これは業務上必要だったので部分的に構築済み。
素朴な方法がHLSしかないので、配信遅延が大きい・配信安定性が低い。
分かりやすいサービス(JstreamやBrightcove、Vimeoなど）はクオリティ・カスタマイズ性が気になるし、何でもできるサービス（AWS Elemental MediaLive）は高価だし設定が煩雑すぎる。
2. CRM＝顧客管理ツール （salesforceの一部機能）
顧客登録・ログイン・管理・メールマガジン などの機能
かなり組織によって使い方が違うツールなので、本当に既存商品を使うのが難しい。
3. Webメディア（の基盤）
そもそもローカルでWebメディアを作るってのは初めは抵抗が大きかった。実際は結構普通のことらしい。そしてネイティブアプリや様々なシステム連携を考えると1から作るほうが良かった。
とにかく
Googleなど既存サービスに頼っているとつらいことが多い。すぐに作るためにさっさとデキるエンジニアに投げたい。広島にはエンジニアが居ない。
映画「Winny」を見て、自分が通過した息絶え絶えの分散システムを思い出す
映画Winnyを見た。映画としての評価は80点くらい。
ノンフィクションということで、一連の訴訟を「惨事」として正義を日本国民に訴えるにしては映画ってのはコスパ悪いなと思う。ほかに良い主張方法も無いか。
自分の考えと当時の雰囲気
今考えるとこの映画の主張に賛同するのだけれども、当時無罪が決まった後も、世間だけじゃなくて敬意を持つ大学もファイル共有ソフトを使わせないために躍起になっていたし、誰もがファイル共有ソフトを悪としていたし、P2P＝悪だった。自分も当時は仕組みをよく理解していないから、”？そうなのか～？”という感じだった。
まぁ裁判の争点になっていた通りすべての技術が善というわけではないし（これも基準が難しい。ブラクラ・個人情報抜き出すツール・ランサムウェア..）当時自分が判断できなかったのも仕方ないかなと思う。
ライツホルダー的立場に立つと、今やYouTubeとかTwitterとかInstagramとかでいくら著作権違反しても取り締まれない世界になっているわけで、YouTubeのほうが圧倒的に巨悪なサービス。（著作権違反報告は権利者しかできず、非常に煩雑な作業が求められるし、まともにサービス側が対応しない場合もある。オンラインサロンなどのコンテンツは確認しようがない。）
どちらかというと、昨今ライツホルダーがYouTubeに迎合しているのが許せない。（楽曲をYouTubeに上げちゃうレコード会社、ゲーム映像をYouTubeにだけ解禁するゲーム会社など。
研究・学問として
この”Winny叩き”から関連技術の発展が阻害されたといわれる。大学生のころ（2012-2016）自分は結構実感した方だと思う。というのも学部の研究室が「分散システム学」だった。見事にP2P技術を現実で活用することはあきらめて、数式やシミュレーション上でいじいじしているだけの学問になっていた。まるでP2Pは枯れた技術かのように扱われていた。（教授の本棚にはWinnyの本が並んでいる）
自分がWebRTCを使ってそれなりに実用的な方向性を示したのだけれども、結局それを利用した理論研究ばかり進んでいるらしい。まぁこれは学術界全体の問題だけれども、分散システムで面白い技術はまだまだ可能性があるはず。
ネットワーク学的に
世の中サーバークライアントしかないのではというくらい、学ぶ技術でP2P通信の知識が得にくい。まぁ普通のクライアント端末でも同じように通信できるんだということを忘れてしまうくらい、クライアント間の通信というのは効率が悪いぞというイメージを植え付けられた気がする。大学院にかけて、CDNなどクラウドサービスがいかに優れているかを語られることが非常に多い。どの回線でもダウンリンクのほうが優遇されているし、
P2P嫌いがマルチキャスト嫌いに発展している？
Winnyに直接関係はないが、世の中がサーバクライアント方式にこだわるがあまり、マルチキャスト・ブロードキャストの知名度・利用頻度が異常に低くなっているのではないかということを気にしている。
ARPやmDNSなどで生きてはいるけれども、本当はもっとマルチキャスト・ブロードキャストは活用されていても良いのではないかと思っている。基本的にマルチキャストはルータを通過しないのが難しいところ。ルーターで特殊な設定をしてスルーさせるなどしなければいけない。でもまとめて複数端末と通信できる（パケットを投げつけられる）ことに強い魅力を感じる。
妄想した技術
特に昨今の大量データ伝送が求められる時代、強いサーバーがさばくのではなく、分散システムで対応するべきではないのか。
マルチキャストでいうとフレッツキャスト( https://www.ntt-west.co.jp/smb/plan/flets_cast/ )のような技術が本当はもっと発展すべきだったし、遠い技術だけれどもWinny事件がなければ発展していたのでは？と思う。ケーブルテレビとかでは活用されているのかもしれないけれども、もっとカジュアルに開発できてほしい。
もちろんガッツリ分散システムを構築すれば、さらにローコストでコンテンツ配信が可能になるはずである。
業務で出会う特殊ネットワークプロトコル
かなり驚く技術として、NDIという映像伝送プロトコルがある。HD画質だと110MbpsでLAN内にブロードキャストでパケットをばら撒く。
受信したい映像をmDNSで特定して自分でつかみに行くというもの。非常にシンプルで良い。が、簡単に帯域が埋まってしまうのでむやみに使うとある種のテロ。もはや気持ちいい。
映像音声機材にもネットワーク通信が不可欠になっており、機材間の通信トラブルを理解するには結構な今まで教えてもらえなかった知識が必要になる。そして自分でP2Pを用いて開発したくなることが増えてくる。
進んでいるP2P技術はいろいろある（外国では）
AirPlayやオンラインFPSゲームなどのほか、ビデオ通話ツール各種は当然サーバ経由の通信は最終手段となっていて、基本はユーザー間でP2P通信する。プロトコルが良ければP2P通信のほうが良いに決まっている。
日本発でうまく活用している事例は少ないのではないかと思う。Splatoonとかは稀有な例という認識。
裁判ものとして
この映画は裁判モノとしてみるとかなりクオリティが高かったように思える。弁護士役の吹越満さんの演技が弁護士しぐさをうまく再現していたのがとてもよかった。裁判進行が非常に丁寧に描かれていた。
おわりに
映画を見て、分散システム・淘汰された技術について色々思い出した。
作品中にも描かれていたけど、本質的には分散システムを構成しつつも安全性や権利保護を実現するなどのほうが大事というか、それを実現すれば世の中に認められるという話だが、そこまでしなくても、GoogleなどITの悪はたくさんあるわけで、とにかく面白いことをしていいし、それを日本政府が邪魔するようなことは今後起きないでほしい。
多少、目に見えて著作権違反されるツールであったとしても、分散システムで世界のサーバリソースを削減したり電気代を減らしたほうがSDGsだと思う。
最終的なこの映画のテーマは、「世の中の不条理は多々あるがITも例外じゃない」、「ITにおいても正義は勝つというわけではない」というものだという理解をした。悲しい気持ちになるばかり。でもまぁ、色々思い出したし、良い映画だった。
知名度とセキュリティ
大学で口酸っぱく言われたコンピュータセキュリティ、実際に気にしなければいけないセキュリティってなんだったんだろうと思うことがよくある。
現実のセキュリティ
結局ユーザーレベルでは、フィッシング詐欺くらいしか現実的な脅威はない。本当に悪意を持って標的型攻撃されたら、社員個人が経験でなんとか対処するしかない。今まで学んだことは無力だし、何だったのだとがっかりする。（ツッコミは色々あると思うけれども）
いわゆるユーザーレベルのセキュリティ対策のビジネスにはすべて懐疑的である。
知名度無いのに脅威に怯えること
では、アプリケーション開発者やサーバ管理者レベルではどうかというのが今回のテーマで、結論から言うと、知名度次第で必要なセキュリティ対策レベルは変わる。「つまり知名度が無いてめぇらは厳密にセキュアなサービスを作る前に使い物になるモノを作れ」ということである。
大学の情シス系教員は頻繁に「大学は毎日何千件と、こんなにたくさんの攻撃を受けています！なのでサービスが不安定になることもあります！大変でしょ～！！」と言って学生を脅していた。この言葉を真に受けてサーバ管理や公開サービスの運営にナーバスになるのは本当に愚かで、国立大学レベルの知名度のあるドメインならそりゃ狙われるかもしれないけど、無名のドメインを持つサービス（個人が趣味で取得したものや、特に機密情報を持たない中小企業）が気にするものではないのである。というかもはや、基本的な対策さえしていれば多少のセキュリティホールを狙われない。そもそもあなたの無名サービスに誰も興味が無い。
逆にあなたの運営するサービスや商品を異国のハッカーに知ってもらうほど知名度を上げるにはどれだけの苦労が必要かと考えるとわかりやすい。もし簡単に異国まで届くほど知名度を上げられるならばどれだけビジネスが楽になるか。
肩の力を抜いたウェブサービス運営
考え方を変えて、そもそも知られていないという前提に立つと、次のような大胆な運用ができる
ウェブサーバの運用
公開ウェブサーバに機密ファイルを置いてもリンクが無ければ、勝手に流出することはないし、わざわざパスワードをかけたり厳密なアクセス権限に応じた表示をする必要はない。多少であればステージング環境をわざわざ使わなくても良い。当然公開サーバでエラーを起こしてもサーバが多少落ちても大して誰も困らない。（プライドの問題が大きい）
拠点間通信
いちいちVPNを張る必要はない。ましてやふつうのID＋PW認証の仕組みがあればそれを突破・DDOSしようとするモチベーションのある人間はいない。AIもいない。
ウェブアプリケーションの運用
ハックすることでユーザーにメリットがある場合、チートをしようとする人なんていない。多少チートされても運用でカバーすればいいという前提で作ると、非常にシンプルになる。
変な使い方をしてサービスがダウンしてもそのユーザーが困るだけ。いたずらにマイナーサービスを落とすために頑張るような暇な人はめったにいない。
おわりに
本当にセキュアな環境が求められる仕事というのは、ほんの一握りの人だけだと思うので、多くのエンジニア・ウェブ制作者はもっと、適当にかつ、意味のある仕事をするべきだと思う。
本当に「これだけはやっておけ」というようなセキュリティ対策の具体的な取り組みがあるのならば教えてほしいが、しかしどうせこれも人によって判断がわかれる。
ウェブサービス運営者はセキュリティをできる限りガチガチに対策して、JPCERTの通知に日々びくびくして、パッチ対応で毎日を消費するという日々の過ごし方を選ぶのもありかもしれないけれども、皆さんの現実的なセキュリティ対策というのももっと共有できる世界になってほしい。
テレビ局のカメラの何がすごいのか
テレビ局のカメラの凄さについて、専門家ではないが、紹介したい。昨今民生用カメラも高品質なものが増えていたり、YouTuberなどが高価なカメラを導入することも増えているが、何が違うのか、何がすごいのか。
いわゆるスタジオや中継現場で利用する巨大なレンズをもつカメラ「システムカメラ」は、カメラ・レンズ併せて1台数千万円程度するのは普通である。報道現場などで使うショルダーカメラ、いわゆる「ENGカメラ(Electronic News Gathering) 」はオプション等含めて500万円くらいはすると思われる。一方で、YouTuberなども買い始めた高級ミラーレス一眼レフカメラや高級ハンディーカムは高くても50万円—80万円ほどであろう。
その差額は何なのか？保証のレベル？カモられてる？無駄にレンズデカい？
結論からいうと、プロ用として求める機能をきちんと実装しているので、
妥当な値段と言える。（必要かどうかは置いておいて）
以下、大きな違いを列挙する。
色々なメーカーはあるが、レンズはキヤノン、システムカメラ本体はikegami、ENGカメラはソニーのものを基準に述べる。
【レンズ】ズーム倍率
たとえば野球中継で必要な倍率をカバーするこのレンズ⇓
https://cweb.canon.jp/bctv/lineup/4k/4k-d/uj111/index.html
26.6kgもするが、8.3mmから1850mm までカバーする。最短撮影距離は3m。
センサーは2/3型なので、フルサイズカメラの35mm換算だと33mm-7400mm・・・は？
※一般的に普通の構図で撮るには50mm ズームレンズでは300mm程度あるのがふつう。
【レンズ】ブリージング ピント調整の再現
普通のズームレンズでは、ピント調整の操作を行うだけで画角が変わってしまう現象（ブリージング）がある。シネマカメラ用のレンズではブリージングが発生しないような工夫がされているが、システムカメラ用のレンズでも基本的には発生しない。
静止画撮影においてはブリージングは問題にならないが、動画撮影において発生すると若干気になる現象である。
また、ズームした状態でピントを合わせて何度かズームアウト・インの操作を行ってもピント面は変わらない。超遠くの観客席に急にズームインをしてもガチっとピントが合うというテクニックでの撮影も可能となる。
【レンズ】純粋なクオリティ（開放での画質）
昔はそうではなかったかもしれないが、4K撮影に耐えうるためというのもあり
レンズ自体の純粋のクオリティ、解像度の高さなども、民生用の機材とは一線を画す。（定量化が難しい）純粋に解像感＝細部を見たときの画質の良さ が異なる。
取り回しの良さ
業務用三脚へのマウント対応や、ENGの場合本体を肩に乗せることができることなどによる安定性がある。用途を絞れば「ジンバル」や、小型アクションカメラのほうが勝る場面も多いが、ENGであればほとんどの場面に対応できる。
【システムカメラ】リモートでの画質調整が可能
リモートでアイリス（F値）や感度、ガンマ値などを変えることができる。そのような操作をする役割を一般的にVE(=Video Engineer)と呼び、カメラと対になる受信端末はCCUと呼ばれる。セットでの導入が必要である。
そしてリモートで画質の調整をすることで、現場ではカメラワークとズームの管理に集中することができ、高品質の映像制作が可能となる。
また、映像・管理以外の信号のほかにインカム音声・タリー・電源もまとめて1つのケーブルで伝送することができるなど、ワークフローに配慮した仕様がある。
⇓システムカメラの例
https://www.ikegami.co.jp/archives/menu1/uhk430
【ENGカメラ】何でも撮れる
内蔵NDフィルタ・内蔵エクステンダー があることで、どのような環境でも適切な撮影が可能。
レンズにもよるが、近くの物撮りから、少し遠くを撮る取材などにも対応可能。現場で何があるかがわからないような場面において非常に適している。
そのほか、業界用の記録媒体への対応（XDCAMレコード機能）や、
端子の充実（SDI・XLRなどに標準対応）による色々な映像・音声機材と連携が容易であることなどが挙げられる。
⇓ENGカメラの例
https://www.sony.jp/xdcam/products/PDW-850/index.html
▲放送用機材のデメリット
高いことなどを除くと、センサーサイズが小さいことによる”ボケが弱い”ことがある。デメリットと思う人は業界には少ないが、最近は安いシネマカメラが出ているのでそのようなカメラを使うこともできるし、静止画用のスチールカメラで動画撮影をすることで、ボケがよく出た演出が多用される。一方日本の放送用機材はセンサーサイズが小さく、ボケを求めない方針にあることが多い。（テレビ局の海外支局の映像はボケが激しいことが多い..）
あと、民生用機材でもできることが多いのに、大げさなカメラを使うことは必要なのかという議論もある。民生用機材もだが、昨今では"iPhoneでいいのでは"、という話にもなってくる。現状に即した機材選択が大事である。
状態更新・状態遷移の難しさ
コンピュータのシステムの話で、単にキャッシュってめんどい、という話だが、情報科学を学んだときにあまり深刻に考えていなかったが重要な問題だと思うので述べる。
状態更新・状態遷移のシチュエーションと最新状態の参照について
データソースAと、Aを活用する（たとえば表示する）アプリケーションC
があり、ユーザーはCをある頻度で利用するとする。（たとえばツイートの蓄積されているサーバがAで、WEB版ツイッターのインターフェースがC）
もしいくらでもAへのアクセスが可能であれば、Cへのアクセスの度に随時Aへ取得リクエストをかければよい話だが、一般的にAは例えば外部のAPIであったり、DBサーバだったり、ファイルストアだったり計算サーバだったりする。はたして”いくらでもAへのアクセスが可能”だろうか。実はそのような場面は結構少ない。CとAが同じ物理サーバでかつ、参照コストがかからない（高速アクセス可能なローカルストレージを参照など）場合などであれば問題ないが、そうでない場合が多い。
そして至極当然のことだが、これらの対応のために、データソースAが返すべきレスポンスを蓄積して高速・低コストに返す「キャッシュB」が生まれることになる。キャッシュBを介すことで、大量アクセスに対応できたり高速にレスポンスできたり、そもそも静的に保存しているため計算コストが安く済むなどの利点がある。
しかし、キャッシュを導入するということは、キャッシュ保持時間＝更新頻度というものがついて回る。つまり”常に最新の値を取得できる”ということが無くなり、情報最新性への妥協であったり、時差を考慮したシステムの開発が必要になる。
概念として、そして巨大サービスにおいてそのようなものがあるのは学生のころから知ってはいた(DNSやWebブラウザのキャッシュなど）が、いざシステムを開発・運用するとなったときに、この問題は至る所で壁となる。
更新頻度≒更新遅延
一般的にデータの受け渡し・状態遷移の伝播は１段階ではない。多段階になり、そのホップ数が多いほど、更新頻度が低くなる。最新データの取得を希望する場合、更新遅延が長くなるともいえる。今回は主にこの、最新データの取得を希望する場合・リアルタイム性が求められるサービスをつくっている立場から述べる。
複数のホップ数があることをかみ砕くと、
１ホップ目、２ホップ目、の更新頻度がT1,T2,...Tn であった場合、最終的な最大の更新遅延はT1+T2+...+Tnとなる。最小の更新遅延は max(T1,T2,...,Tn)となり大したことないが、タイミングを正確に合わせない限り、最大の更新遅延を引くことは多々ある。ご覧の通りホップ数が増えるごとに最大の更新遅延はどんどん伸び、ユーザー体験は損なわれていく。（一方サーバ管理者はサーバ機能の細分化ができてうれしいことが多い）たとえば最新のニュース記事を見たいのに２０分後にならないと見られない、というようなことが起きる。
どのような場合に、更新頻度が長くなるのか、いくつか例を挙げる。
例１ 外部RSSを参照して、記事の情報を取得する
取得先RSSは静的なファイルではなく動的に生成する場合、レスポンスに時間がかかるし、何より先方のサーバに著しく負担をかけるためアクセス頻度を下げろという要求をされていることもある。
→更新遅延はあっても更新頻度は確保できる という場合もあるが、それすら妨げられる。→先方のシステムが悪いともいえる。
例２ 自社の記事管理CMSから、最新の記事５件を取得する
コンテンツ蓄積とともにDBは肥大化していくことや、低頻度のアクセスを想定した廉価なクラウドサービスを利用していることが影響し、高頻度でのアクセスは避けたい・低廉な仮想サーバのためレスポンスに数秒かかることが多々ある。それらの理由からバッファをもって５分単位での更新にするなど。
→DBの設計の難しさの話と、オンプレ至上主義の話につながるが、現実的に出会うことの多い問題である。そして安易に５分単位で更新時間を決めることの是非も・・
例３ いわゆるふつうのCDN
CDNはキャッシュそのものであるから当然ではあるが、CDNを介したデータ取得ということは、TTLが決められており、その事前設定した時間だけ更新頻度が遅くなる。ただ、CDNを使う目的はあくまでアクセスの分散であるから、別に更新頻度を下げる・古い情報の露出を許容しているからというわけではない。
→例えば誤った情報の修正・ネガティブキャッシュの存在など、キャッシュ機能が運用の邪魔をすることがあり、その場合キャッシュの開放（パージ）や、インデックスファイルのみTTLを短くするなどの方法をとるが、リアルタイム性を求めるサービスとCDNの相性の悪さがあることは主張したい。
例４ 大きなファイルを取得する・計算する必要がある場合
ちょっと毛色は違うが、大きなファイルを名前を変更せずに更新する事を考えると、リモートサーバから取得している途中はファイルとして破綻しているので、使い物にならない。なので最近のウェブブラウザの挙動でも見られるが、一時ファイルとして別名でダウンロードを行い、ファイル完成後にリネームを行い上書きすることが必要になる。ダウンロードにかかる時間が遅延時間に直結するのはもちろんのこと、この「ダウンロード中のアクセス」を正しく対応しなければ、システムのエラーにつながるのも注意したい。一方でサーバ（Linuxなど）の「リネーム」は”十分一瞬”に終了するからユーザーに影響を与えることはない、のは興味深い。”リネーム中にアクセスしたからファイル破損扱いになった！”ということは起きうるのかもしれないが、十分に無視できる事象といえる。
◆私の驚き
単に情報＝データを”すぐに”別の場所＝サーバから持ってくるというのがこんなにも困難なことだったのかということに驚く。そしてそれは世の中ほとんどすべてのサービスに影響するものになるから、もっとこれに関する学問やアーキテクチャの議論があっても良いのではと思う。いや、当然すでにあるのだろうけれども少なくとも学生の時にこんなこと考えもしなかった。
◆色々経験を経ての教訓
・システム（データフロー）をシンプルにすること。役割などの区別から、多段階での処理をしがちである。一般的に複雑な問題は分割せよと言われている。しかし更新遅延を考えるとそうも言ってられない。一番問題を簡単化するのは、データフローをシンプルにすること。
・あらゆる段階において高速なレスポンスを求めること。普通のサービスで異常が起きても無いのに数秒もかけてレスポンスしているのは異常だし、避けるべき。細かなアルゴリズムの工夫や無駄な処理の削減できることは多々ある。動画像処理やAIなどで計算時間がかかるものもあるが、かなり考慮したシステム設計が必要になる。
・キャッシュサーバの保持時間はあまやかしてはいけない
”キャッシュサーバだから保持時間が長いのは当然でしょ笑”というような甘えた設計では、多段階でデータの受け渡しをすることでかなりのボトルネックになってしまう場合がある。しっかりと処理能力を鑑みて、CPUにはがんばってもらって、できるだけ短い保持時間にするべきである。一見保持時間がいくら長くても良いだろうと思っていても、システムの遠いところで影響を与えることがある。
◆おわりに
かなり自分の関わっているプロダクト（コンテンツ管理とその表示WEBインターフェース、他社APIとの連携 など）を基準に偏った内容で、前提設定が足りない部分が多々あると思うが、具体例などはいくらでも出せるので、気になったことがあれば答えられる。
放送現場で使われる有線映像伝送方式・ケーブルの種類
4年半ほど働き、"相場"というものがわかってきて、そろそろ放送現場で使われている技術を語れるようになってきたので、今回、映像伝送方式についてまとめつつ紹介する。
無線・IPは今回含めない。前提として無線より圧倒的に有線のほうが安定するという考えのため有線接続は現場でもまだまだ多用される。IPは有線より方式が乱立しており、さらにIPネットワークの知識も必要で輻輳などの難度の高い障害対応が求められるため、特に流動性の高い映像現場においては有線接続がまだ幅を利かせている。
SDI (Serial Digital Interface)
THE 業界標準。なのにネット上に情報が少ない。
とにかく無劣化無圧縮な信号を銅線（*1同軸ケーブル）を用いて伝送する。
シンプルな接点が接触すれば映像が伝わるので、安定性が高い。加えて遅延もほぼ無く、伝送情報量が多くデジタルで劣化がない。何より100メートルほど伝送できるのでSDIで対応できない場面が少ない。超長距離伝送する場合を除いて、現場での利用率は圧倒的である。
解像度
規格によって周波数が違い伝送できる容量が異なる。地上波レベルはHD-SDIで伝送可能なので、HD-SDIが一番普及している。4Kを伝送するには12G-SDIが必要になる。
- HD-SDI 1.4Gbps の伝送帯域で、HD=1920x1080 を30フレームまで送れる。地上デジタル放送レベルではこれで十分。（地デジは*2 1440x1080 59.94i）
- 3G-SDI 2.9Gbpsの伝送帯域で、HDを60フレームまで送れる。
- 6G-SDI 5.9Gbpsの伝送帯域で、4K=3480x2160を30フレームまで送れる。
- 12G-SDI 12Gbpsの伝送帯域で、4Kを60フレームまで送れる。（BS4K放送は60fpsが基本）
伝送距離
規格とケーブルの品質による（同軸ケーブルは大きく分けて3C・5C等があり、ケーブルの太さと取り回しやすさのトレードオフになっている）が、HD-SDIでは約110メートル程度、12G-SDIでは70メートル程度まで伝送できる。現場回りでの配線は問題ないが社屋の端まで引っ張るには足りないため、リピーター（リクロック）を介したり、あきらめて光ファイバーでの伝送で対応する。最近は基本的には室間は光ファイバーでの伝送をするのが吉（そうなると中身はIPになることもある）
端子
BNCが多く使われる。取り外しには回転が必要で外れにくく非常に便利。
もっと多く普及しているテレビアンテナ用のケーブルに使われるF端子がすべてBNCに入れ替わればよいと思う。
マイナーな端子として、コンパクトに端子を設置するためにDIN・mini-BNC・Micro BNCというものがある。DIN以外はめったに見かけない。
また、BNCの中でも圧着方法は多彩で、それぞれ細かく性能（周波数帯による伝送距離など）が異なる。
音声
無劣化で16チャンネルの音声を伝送可能。
5.1ch=6chの音声とステレオ音声を合わせて伝送できるため8chまでは使われることがあるということもあり、8chまではサポートする機材がある。
HDMI (High-Definition Multimedia Interface)
民生用機材において圧倒的な普及率を誇るため、無視できない規格。SDIとHDMIが混在することが多々あり、*3互いの変換がまた問題となる。
多くのバージョンが存在するため、高解像度の映像を扱う場合はケーブル選定に注意が必要。音声や制御信号も含み、これ1本で多くのことに対応可能できる。
欠点は伝送距離が短いことと、SDIに比べると仕様が複雑であること、何より端子が19ピン・外れやすいなどで安定性が低いことである。
民生用のため著作権保護(HDCP)機能や、機器間の認証・信号が規定されている。
解像度
スタンダードHDMIでは1080iまで、ハイスピードHDMIでは1080pまで、さらに4K・8Kと規格に応じて高解像度・HLGに対応可能となる。
伝送距離
一般的に5メートル以内とされるが、光ファイバーで数十メートルに延長する商品も存在する。
端子
HDMI-Aという一般的な形式に対して、Mini HDMIと呼ばれる HDMI-C端子、Micro HDMIと呼ばれる HDMI-D端子が存在する。小型カメラの多くはMicro HDMI端子を備えている。
いくつかの端子種類が存在するため煩雑なうえ、対応端子によってはさらに接合部が不安定であるので、より確実な接続ができるHDMI-A端子が歓迎される。
音声
仕様上は8chまで対応できるらしいが2chまで対応する機材しかほとんどない。
光カメラケーブル（多治見・LEMO）
完全に業務用。電源やインカム、システムカメラの映像伝送に用いられる。電源・制御は銅線で、映像は光ファイバーで伝送する。各2本ずつ合計6本が束ねられており、このケーブル1本があればすべてが完結する。
200メートル以上は伝送でき、スタジオのシステムカメラとしてはもちろん、中継現場などで多く用いられる。接続部に光端子（フェルール面）があるため微小な汚れでも伝送に障害が発生する。
その他
放送業界では基本的には使われないがまだまだ存在する。
UVC(USB Video Class)
USBで映像を伝送する規格。もともとはWebカメラからPCに映像を送るためのものだったが、仮想WEBカメラ的に映像をPCに送るために、上記の映像規格をUVCでPCに入力する需要が増えており、変換コネクタが多く販売されている。
多くのブラウザや一般的なアプリケーションで扱うことができるため汎用性は高い。フォーマットはMJPEGが基本だがサポートされるフォーマットも増えている。
映像と音声が異なる仕組みで入ってくるため絵と音がずれることが多い。
音声はUSB Audio Class(USB Audio Class)。
DVI (DVI-D DVI-I DVI-A)
18-24のピンを用いて映像を伝送する。PCモニターでよく利用される。
フルHDから4Kまで対応できるが、アナログ信号も使うことがあり、互換性のため様々な端子がある。基本的にはDVI-Dを想定していればよい。音声は通さない。
Display Port （Thunderbolt)
8KまでのPCの様々な解像度に対応する。伝送距離が短い。音声は伝送できる。
HDMIと同じくバージョンが多数あり、ケーブルの選定が難しい。Thunderbolt端子がカバーするプロトコルにも含まれる。昨今のThunderbolt4対応のUSB Type-Cケーブル周りで普及が進んでいる。
VGA(D-SUB・RGB)
古いコンピュータはだいたい対応している、世の中で一番普及している映像ケーブル。15ピンの端子で 2048x1152 （フルHDよりちょっと大きいのでモニタとしては十分）まで表示できる。しかしアナログ。音声は伝送できない。
使わないので説明を省略
コンポジット S端子、RCA
SD画質までしか対応していない（規格が作られていない）ため、ほとんど見かけないが、端子がついているモニタなどは多い。余った端子を有効活用したいときには考えるがSD画質なので萎える。
コンポーネント端子 D端子(D1～D5)
D5はフルHDを伝送できるため一部現場で見かけることもある。端子などの機材がまったく存在しないので触ることはない。
動画ビットレート感覚
動画のビットレートは、動画視聴環境・満足度に大きく影響するものの、評価軸が画質となるため主観で判断するしかなく、それ故あまり語られることが少ない。
テレビのマスター機器の設定は地デジの仕様・MPEG2ノウハウの不足があり頻繁に変えられないことから難しいが、動画配信となるとH264であるし、しがらみもなく、ビットレートを任意に定めることができる。ただし、映像素材品質・映像素材種類・配信環境・エンコーダ圧縮性能・解像度・受信環境・求められる安定性をもとに適切なものを選ばなければならない。結局のところは自分の”ビットレート感覚”に頼らざるを得ない。
世の中のビットレート
まずは、世の中で流れている動画ビットレートの相場を知るべきである。ということで調べた世の中のビットレート（自分・拾ってきたもの）を以下羅列する。
実測：地上波TS MPEG2
BS11 18Mbps MAX 22Mbps
BS民放系 13Mbps MAX 15Mbps
BSプレミアム 15Mbps MAX 18Mbps
地デジ本放送 13Mbps MAX 16Mbps
地デジカラーバー 2.4Mbps
地デジムービングカラーバー 5.5Mbps
参考:BS4K・8K HEVC(H.265)
4K MAX 30Mbps
8K MAX 100Mbps
動画ウェブ配信 H.264 fullHD 30f
YouTube 9Mbps
Amazo Prime 16Mbps
ベースバンド
HDMI 60p 3.2Gbps
HD-SDI 60i 1.4835Gbps
自分のビットレート感覚は
HLSの技術的問題は別途述べるとして、基本的にはビットレートは低いに越したことはない。
ちなみに今自分の設定するH264 720p30F の配信サービスにおいては、QVBRでMAX 500kbps 1.5Mbps 2Mbps の3ストリームとしている。
主観ではあるが、2Mbpsほどあれば動きが相当激しくなければ十分の地デジを上回る画質となり十分であると考える。つまりは地デジレベルを目指さなければ1.5Mbpsくらいで充分。
（もし10Mbpsくらいで投げられれるならば、最高の画質になりそう）
これはエンコーダの品質が優れているからであって、市販のエンコーダやPCでの配信(OBSなど)では、同等の画質を再現するには+1Mbpsほど必要であると思われる。
受信環境の話
いわゆる”ギガ”の消費のためには低ければ低いほどいいが、一番重要なのは、動画が停止しないこと、バッファ状態にならないことである。実際の状況を想定すると、4G回線の非CA状態であれば10Mbps以上出る。ただし昼12時台や夕方18時台の混雑時間帯には2,3Mbpsくらいになることは想定され、さらに格安SIMの状況や通信制限状態(128kbps)もありうる。流石に128kbpsは無理なので、格安SIMが時間帯によっては際限なくスピードが落ちることを想定すると、500kbpsやそれより低いビットレートを用意することは重要と思える。さらに、そこまで基準を下げておけば、残念なWi-Fi環境などにおいても役立ちそうである。
今後の課題
先に挙げたビットレートを定めるための条件を改めてみて、まだ自分の中でさっぱり解決できていないこととしては、エンコーダ圧縮性能・画質の定量評価、解像度とビットレートの関係がある。画質の定量評価は、永遠の悩みだとはおもうが、解像度とビットレートの関係（同じ1.5Mbpsで360pと720pではどちらがいいのか、など）は、動画を見る画面の大きさにも依存するところがあり、まだ答えが出ていない。
