タグ

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

  • 平文の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)
  • ビビりなエンジニアが大企業を辞めて起業した話 - 最速配信研究会(@yamaz)

    この記事は Supership株式会社 Advent Calendar 2016 - Qiita の1日目の記事になります。遅くなりました。 Supership CTO室室長 @yamaz です。 ビビりなエンジニアが大企業を辞めて起業した話を書きます。 スケールアウトを立ち上げる前、私はヤフージャパンに務めていた。 当時私は結構な給与をもらっており、かつそこそこの立場におり、かつ仕事も面白く、普通なら辞めないような立場だった。 だけど思うところがあり、会社を辞めその後会社を作ることになった。今回はそのあたりの話をしようと思う。今から10年ほど前の話だ。 きっかけ きっかけは上司からの命令だった。 「Adsense作って。2人で」 なんとなくそれっぽいものを作ったものの、エンジニアとしての自分に疑問を持つ結果となった。 AdSenseのすばらしさとのギャップ AdSenseはすごいプロダク

    ビビりなエンジニアが大企業を辞めて起業した話 - 最速配信研究会(@yamaz)
    uokada
    uokada 2016/12/06
  • 最速配信研究会 - ロードバランサの運用.DSRって知ってますか

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

    最速配信研究会 - ロードバランサの運用.DSRって知ってますか
  • 広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)

    少し前からだけど,Cookpadやはてなが広告システムエンジニアを募集している. クックパッド|採用情報: 【技術部】アドシステムエンジニア http://info.cookpad.com/?page_id=113 求人情報:広告システムエンジニア - はてな http://www.hatena.ne.jp/company/staff/accountengineer 私個人の経験から,オンライン広告システムというのは検索やインフラ系と並び,インターネット系のシステムの中でもっともエキサイティングな分野の一つだと思っている.それにもかかわらず,狙って応募してくる人はあまりおらず,いつもいつも悔しい思いをしてきていたので,広告システムがいかにおもしろいかをちょっと述べてみたいと思う. その会社で一番アクセスを受けるところなのでおもしろい. 広告システムはそのサイトの全サービス上に配信する必要が

    広告システムエンジニアは絶対におもしろいと思う理由 - 最速配信研究会(@yamaz)
  • selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)

    最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理

    selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
  • RTB用のADサーバこそ最強である必要がある件 - 最速配信研究会(@yamaz)

    明日はアドテック東京というデジタルマーケティングのカンファレンスが行われる。 最近広告配信周りでRTB(RealTimeBidding)というシステムがはやりつつあるが、RTB用のADサーバこそ最強である必要があるということを述べてみたいと思う。 RTBの仕組みというのは簡単に言うと下記のような感じになる。 1. 広告サーバ(SSP)に問い合わせがあった場合、バックに接続されたRTBの広告サーバ(以下RTBサーバ)に対して問い合わせをオークション形式で行う 2. RTBサーバは来たリクエストに対していくらで購入ができるかを返し、SSPは最も高い単価をつけた広告をユーザに返し、表示する(CPMというのは広告単価だと思えばいい) 上記の処理を1つの広告表示のたびに行うので、Real Time Bidding(RTB)というわけだ。RTBのエコシステムにおいては自分の都合のよいユーザのアクセスの

    RTB用のADサーバこそ最強である必要がある件 - 最速配信研究会(@yamaz)
    uokada
    uokada 2011/10/26
  • 「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)

    前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので, このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ

    「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)
  • 1