タグ

ブックマーク / yamaz.hatenablog.com (9)

  • 9/11とAkamai Technologies社 - 最速配信研究会(@yamaz)

    みなさんはAkamai Technologies社をご存知だろうか? http://www.akamai.com/ http://www.akamai.co.jp/ Akamai社は高速なコンテンツ配信を請け負っている会社で,同社の保有する数万台のサーバリソースを利用しての大量の画像や大規模なストリーム配信を得意としている. アメリカではGoogleYahoo!Microsoft,日ではYahoo!Japanやmixiなどたくさんの会社が利用をしていて,インターネットを陰で支える縁の下の力持ちといった会社だ. 同社が提供するFreeFlowやFirstPointと呼ばれる配信サービスはまさにAkamai(ハワイ語でCoolの意味)というにふさわしく,初めてそのバックのテクノロジーを教えてもらったときは目から鱗が落ちる思いだった. ところで9/11は言うまでもなく米同時多発テロが起きた

    9/11とAkamai Technologies社 - 最速配信研究会(@yamaz)
    yyamano
    yyamano 2020/09/11
  • 平文のTCP/IPにおいて転送されたデータの信頼性を期待してはいけない - 最速配信研究会(@yamaz)

    TL;DR 平文のTCP/IPの通信では送信したデータの完全性は期待できないので、経路にはSSL/TLSを使いましょう TCP/IPはUDPと違い、信頼性のある通信を実現するためのプロトコルという説明がよくされる。なのでTCP/IPでやり取りしたデータは1bitの狂いもなく転送先に届くと思われがちだ。TCP/IPが信頼性のある通信を確保してると言われているのは下記の理由による。 1. データが届かなかった場合の再送処理がプロトコルに入っている 2. TCPパケットにペイロードのチェックサムがあり、不具合が検知されると修正もしくは再送される(ただし16bit) 3. IP層の更に下の層にチェックサムがあり、不具合が検知されると修正もしくは再送される(イーサの場合32bit) しかしチェックサムはそれぞれ16/32bitのため、昨今の超大量データを取り扱うにはかなり心もとない。 1. ざっくり

    平文のTCP/IPにおいて転送されたデータの信頼性を期待してはいけない - 最速配信研究会(@yamaz)
    yyamano
    yyamano 2018/03/04
    1.ざっくり1600万〜100億パケットに1回の確率で検知できないエラー(データ化け)が起き得る. 2.数百ギガバイトのインターネット経由の転送でデータ化け
  • 最速配信研究会 - ロードバランサの運用.DSRって知ってますか

    id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン

    最速配信研究会 - ロードバランサの運用.DSRって知ってますか
    yyamano
    yyamano 2018/02/23
  • Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)

    地震速報の話 Iさん:ヤフーの全ページに一気に情報を反映させる仕組みってないかな? yamaz:  広告サーバはどうですかね?設備はもうあるし、クリックや表示カウントもできますよ。 1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ 当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。 Contents Delivery Managementという考え方 弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう?」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネ

    Contents Delivery Managementという考え方 - 最速配信研究会(@yamaz)
    yyamano
    yyamano 2015/03/24
  • RailsとCで広告システムを作って起業した話 - 最速配信研究会(@yamaz)

    4/10清澄白河で開催された大江戸ruby会議01で 「RailsとCで広告システムを作って起業した話」と題して話をしてきた。 speakerdeck.com 詳細はスライドに書いてあるが、弊社は全く後ろ盾などないスタートアップにもかかわらず、異様なまでに濃いrubyistを集めることができていて、発表後「どうやってそんなすごい人を集めることができたのか?」という質問をうけた。 実はこれも秘密はなく、「彼らは当時たまたま求職中であったり、転職したがってることをRails勉強会の後の飲み会で聞いたりしたので即スカウトした」というのが実際の所で、ぶっちゃけたところ運がよかったとしか言えない。 せいぜい教訓めいたことを言うならば「恋愛と同じく、振られた直後に隣にいるというのは割と重要だ」あたりだろうか。 大江戸Ruby会議01はとてもよい会議でした。ほんとはエンジニアを集めるのに札束が踊りまくっ

    RailsとCで広告システムを作って起業した話 - 最速配信研究会(@yamaz)
    yyamano
    yyamano 2011/04/21
  • ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)

    ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し

    ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
  • 2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)

    # タイトルは煽りです. 今週末ドリコムさんでCometとその周辺技術(イベント処理、Erlangなどなど)に関する勉強会が行われるので,ここ最近つらつら考えたり調べたりしてたことを外に出します.yamazはErlangの文法とかにはあまり興味がなく,2000万のプロセスが並列実行できるというそのモデルに興味があるので,とりあえずそこについて. なおいつもにも増して適当なこと書いてるので,適宜マユツバでお願いします.ツッコミ大歓迎. Erlangは1マシンで2000万のプロセスを並列実行させることができるらしい. http://www.atmarkit.co.jp/news/200704/27/erlang.html 私は並列言語はVHDLしか使ったことがなく,しかもVHDLはちゃんと 並列実行を行う要素が回路の形で実在するので,Erlangみたいに 1マシンで並列性を実現することに対して

    2000万個のプロセスを動かすための並列モデル - 最速配信研究会(@yamaz)
  • 「Web2.0とC10Kに関する数々の誤解」の誤解 - 最速配信研究会(@yamaz)

    前エントリWeb2.0とC10Kに関する数々の誤解に関してはいろいろツッコミをいただいた(ありがとうございます). 名無し 『誤読した上にえらそうに微妙な解説するあたり恥ずかしすぎます。』 えらそうで微妙な解説なのはまぁそうなので否定しないが,誤読とはなんのことだろう? こういうときは今はやりの「スルー力」を発揮するのが大人のインターネットかと思ったけれど, 私のBlogが扱う内容は非常に狭く,さらにそれに対して突っ込もうと思う人の 意見はなにかしらの真実が含まれるはずと考えていたところ,下記エントリがあった. 元記事の人は上でいう 3,6 あたりを書いていて,id:yamaz さんは 3 するなら 4 とか常識だろ,と噛みついているように読めました。. なるほど,私の前エントリは@ITの元記事に対して噛みついているように 読めるようだ(言われてみればたしかにそう読める). 実際の所は元記

    「Web2.0とC10Kに関する数々の誤解」の誤解 - 最速配信研究会(@yamaz)
  • 最速配信研究会 - Web2.0とC10Kに関する数々の誤解

    Web2.0 = Ajax/Cometなの?とかプロセスIDは今でも16ビットなの?とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」(クライアント1万台問題)だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに

    最速配信研究会 - Web2.0とC10Kに関する数々の誤解
  • 1