Cloudflareが全ユーザにデフォルトでHTTP/2を適用、大企業ユーザのみオプトイン

SAN FRANCISCO, CALIF. - SEPT 29, 2010
TechCrunch Disrupt Startup Battlefield Final Round: CloudFlare
Expert Judges: Marissa Mayer (Google), Ron Conway (SV Angel), Roelof Botha (Sequoia Capital), Jason Goldman (Twitter)
Photo by Max Whittaker

HTTPプロトコルの新しい上位規格HTTP/2は、今年の前半にやっと確定した。でもそれは、アプリケーションレベルというよりインターネットのインフラに関わる規格なので、早急には普及しない。しかしこのほど、ユーザ数のたいへん多いWebサイト最適化サービスCloudflareが、デフォルトでは全ユーザ(無料ユーザとProユーザ)にこの新しいプロトコルを使うことになったため、一挙に採用が進むと思われる。なお、大規模ユーザには、オプトインのオプションがある。

CloudFlareのCEO Matthew Princeによると、今回の同社の決定によって、Alexaの上位サイト100万のうちのHTTP/2採用サイトの75%が、CloudFlareによってHTTP/2化したサイトになる。

“インターネットの低レベルプロトコルは1998年以来変わっていないから、弊社がこの、インターネットの未来を担うプロトコルを推進する大きな力になれることを、たいへん喜んでいる”、とPrinceは述べる。

 

Cloudflareがひそかにこのサービスを開始したのは先週のことで、今では400万のユーザと世界中の70箇所のデータセンターが、無事にプロトコルの切り替えを行った。“ユーザを地域やタイプで細かく分割しながら、徐々に段階的に進めたので、全ユーザにグローバルに可利用になった時点では、問題なく動くことが事前に分かっていた”、とPrinceは語る。

HTTP/2はかなりの部分が、GoogleのSPDYをベースにしている。それは接続を大幅に高速化し、今のHTTP/1.xと違って、大量のオブジェクトをブラウザへ並列でストリームすることが、ずっと容易に極小のオーバヘッドでできる。

Cloudflareは、今でもSPDYをサポートしている。Princeによると、SPDYをいきなり完全にHTTP/2に切り替えると、むしろスピードが劣化するからだ。 “一部のプロバイダはSPDYを破り捨ててHTTP/2に乗り換えたが、今だにSPDYを使い続けているブラウザも多いのだ”、とPrinceは述べる。

では、HTTP/2をHTTP/1.xによる接続と比べると、どれだけ速いのか? Cloudflareによると、同社のネットワーク上ではページロードタイムが平均3秒速くなった。ただしSPDYとHTTP/2の差は、あまりないそうだ。

CloudFlareは、同社のBusinessおよびEnterpriseクラスの顧客には、HTTP/2のデフォルト提供をしていない。Princeによると、インフラのコントロールを完全に企業が手中に収めていたいという意向のユーザには、強制的なデフォルトではなく、オプションで提供していく、ということだ。しかし来年以降は、これらのクラスも含めて新規ユーザの全員をデフォルトでHTTP/2にしていく予定だ。

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

本誌Disruptからの成長企業CloudFlareが$110Mの巨額を調達、Microsoft、Google、Baidu、Qualcommが投資に参加

screen-shot-2015-09-22-at-9-30-24-am

Webサイトのパフォーマンス向上/最適化のための各種サービスを提供するCloudFlareが、Fidelityがリードするラウンドにより1億1000万ドルを調達した。このラウンドに参加したのは、Baidu、Google、Microsoft、Qualcommなどテク業界の大物揃いだ。完了したのは昨年12月だが、公表は今日(米国時間9/22)まで延ばされた。これで同社の資金調達総額は1億8000万ドルあまりとなる。

この急成長を続けているスタートアップは、今では30か国以上で操業し、本誌TechCrunchが得た情報によると、インターネットの全トラフィックの約5%を処理している。同社はこの前、2013年の後半に、5000万ドルのラウンドを確保した

CloudFlareがローンチしたのはTechCrunch Disrupt SF 2010で、いわばわれわれが毎年…今年も…力を注いでいるイベントの同窓生だ。同社は財務状況に関して気持ち良いぐらいオープンで、黒字に転じたのは2014年、今の粗利率は75%だそうだ。

これほどの利益を上げている企業が、国際展開を急ぐのは、おかしいかもしれない。でも同社は、グローバルな成長も著しく、しかも必要とする資金がいつでも得られるという、超健康な体質だ。

今度の新しい資金調達は、テク業界のバブルがささやかれている時期に行われた。今では多くのジャーナリストがバブルを口にし、投資家たちを不安がらせている。しかし1億1000万ドルは大金だが、Uberの10億ドルクラスの調達を見れば、バブルというよりも正常の範囲内だろう。

同社の国際展開にはいつも、ある種の要件が伴っている。たとえば今回Baiduからの投資を受け入れたことは、偶然ではない。中国はWebにとって巨大な市場だが、そこでビジネスをするのは、そのほかの国ほど単純ではない。だから政府の受けの良い地元の巨大テクノロジ企業とのパートナーシップは、悪い戦略ではない。

先週CloudFlareが発表したように、同社はBaiduとのパートナーシップにより中国市場に参入する。今ではCloudFlareは中国のBaiduの17のデータセンターにプレゼンスがあり、その数は2016年にはさらに増えるという。

CloudFlareのCEO Matthew Princeはプレスリリースの中で、“ビジネスには不可避なものがある”、と言っている。Webは今やデスクトップのインターネットだけでなく、膨大な量で成長しているモバイルもあるから、それもある意味当然だが、ここで言われている不可避性は、ビジネスよりもむしろ市場を指している。CloudFlareは競合の渦中にあり、今の成功のみが明日の成長を支える、と。

絶えず成長していなければならない、という厄介な問題。

CloudFlareは明日((米国時間9/23)のDisruptのステージに登場するから、財務や成長、拡張の計画について詳しく聞いてみよう。同社は国際展開とモバイルを成長の方向性として強調している。彼らにとってインターネットは今や、グローバルだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google、ウェブサイト表示の高速化サービス、PageSpeedを閉鎖へ―CloudFlareに敗北?

2015-05-07-google

Googleはウェブサイトの表示を高速化するサービス、PageSpeedを来る8月3日をもってシャットダウンすると発表した。サービスを利用しているデベロッパーはそれまでにDNSやサイトの設定を対応させる必要がある。新規登録はすでに停止されている。

PageSpeedは4年半前にスタートしたサービスで、数多くの最適化テクノロジーを用いてサイトがユーザーに表示されるスピードを向上させていた。これには画像圧縮、キャッシュ最適化、JavaScriptとCSSの処理の高速化、静的データのキャッシュとGoogleのサーバーからの送信などが含まれていた。PageSpeedは後発のCloudFlareに似ているが、CloudFlareのようなセキュリティー向上機能は持っていなかった。

PageSpeed - PageSpeed — Google Developers

GoogleはPageSpeedで提供してきたテクノロジーの大部分をApacheやNGINXのウェブサーバーツールとしてオープンソースで公開しているので、Googleこれらのツールのホスティングを中止した後もデベロッパーは同様の機能をローカルで実現することができる。また多くのウェブサイトのホスティング・サービスがPageSpeedモジュールをサポートしている。GoogleはPageSpeedを運用しているCDNとしてEdgeCastのEdge Optimizerを挙げている。

それではGoogleがこのサービスを停止する理由は何だろうか? Googleは「残念ながら別の分野に注力することが必要な時期となった」とだけ述べている。この分野でCloudFlareの存在が優勢になるにつれ、Googleは1、2年前からPageSpeedの改良に熱意を失っていたように思える。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

データの高速化について現場最先端の6社が語る

このごろは、何ごとに関してもスピードが重視される。つまり、今でも、ネットワークからデータをかき集めるよりもFedExで送ってもらった方が速いことがある。データを飛行機で運んだ方が速いという、うそみたいな事実が、今でも実際にあるのだ。

数テラバイトのデータを転送するだけなら、丸一日とか一晩かかることはない。でもフィーチャーフィルムの収まった複数のハードディスクを単純に“大陸間移動”することと、正しいデータを取り出し、それを分析し、何かのアプリケーションでプレゼンすることは、状況や抱える問題がまるで違う。スマートフォンの爆発的普及や、言葉の違いなどの障壁、3Dプリンタ、データオブジェクトの限りない多様化と集積、などなど、現代は、データ移動と言っても後者のような複雑な処理ニーズを伴うものが、圧倒的に多くなっている。

このようなデータ移動の複雑性に対応するために多くのアプリケーションは、RAMやフラッシュメモリの有効利用に傾いている。ハードディスクは、もはや古いのだ。ハードディスクの機械的な部品は、現代の企業が分析するデータの量や速度に対応できない。データベースも、完全なメモリ常駐型など、新しいものが登場している。スタートアップだけでなくSAPのような伝統的なIT企業も、それらの開発に取り組んでいる。そしてNoSQLデータベースが、今ではデベロッパたちのコミュニティでは人気者になっている。

しかしアプリケーションのパフォーマンスやデータ分析のスピードを左右する要素は、非常に多面的だ。最近FirstMark Capitalの常勤パートナーになったMatt Turckは、先週ニューヨークの同社のオフィスで行ったインタビューで、物のインターネット(Internet of Things, IoT)がデータ転送の総量を爆発的に増大させる、と言った。彼はそのとき、その兆候としてMQTTの登場を挙げた。この、IoTのための通信プロトコルは、The New York Timesによると、“マシンツーマシン通信のための共通語であるだけでなく、データ交換のためのメッセンジャーでありキャリアだ”。

MQTTの作者は、ワイト島にある16世紀に作られた彼の藁葺き小屋をIoTで自動化しようとしているときに、メッセージングのプロトコルが必要だと気づいた。

物といえば、子どもが床に転がして遊ぶ、あのボールなどを連想するが、しかしTurckによれば、それはボールのような無表情なデータ片ではなく、それ自身の社会的な(かけがえのない、他と同じでない)自己同一性を持ち、いずれは何兆ものほかのオブジェクトと接続することになるデータオブジェクトだ。子どもが壁にぶつけてあそぶSpaldeen〔≒スーパーボール、ビックリボール〕のようなものではなく、それは何かのアバターにもなるデータオブジェクトだ。でも、このボールなどさまざまなオブジェクトから渡されるすべてのデータを、全世界規模で想像すると、それが簡単にゼタバイト級のディメンションになってしまうことが、理解できるだろう*。〔*: したがって通信方式はどうしてもメッセージング(==非同期)方式になる。〕

今では、何ものにも増して重要な話題かつ課題と思われる、IoTなどを契機とするデータ通信量の爆発的増大について、一部のエキスパートたちに話を聞いてみた。しかし彼らの視点は未来よりもむしろ、今まさに起きつつあることに向けられている。

MemSQL

4月の終わりにMemSQLは、同社のリアルタイム分析プラットホームを一般に公開した。このプラットホームは、インメモリデータベースと分散インフラストラクチャを使って大量のデータを分析する。そのデータベースは、スピード重視のアーキテクチャだ。

MemSQLのCEOで協同ファウンダのEric Frenkielは、最近の10年間で大規模なデータ保存技術に重要な改善が見られた、と言う。“企業は圧縮した列保存〔参考〕とHadoopを使って大量のデータを保存し、データの保存と分析を行っていない企業に対して競合上優位に立つようになった”、とFrenkielは言う。“しかしビッグデータは、データ量が十分に多くてしかもアクセス可能でないと無益だ。今企業が苦労しているのは、ビジネスの変化の速度にデータ処理のスピードを合わせること、後者を十分に速くすることだ”。

彼によると、企業がますますデータに依存するようになると、増大する一方のデータに正しいタイミングで対応するために、より高速なデータベースを必要とする。“大量データの保持(リテンション)と保存(ストレージ)という問題が解決されると、次の課題はスピードだ”、とFrenkielは言う。“ハードディスクをフラッシュストレージで置換するとある程度速くなるが、しかし本当に必要なイノベーションはデータを保存し分析するソフトウェアの進化だ”。

MemSQLは、データ分析のためのインテリジェンスとして機能するアグリゲータだ。データ分析は複数のノードにわたってオーケストレーションされ、それらがアグリゲータのコマンドを実行する。各データノード自身は何も知らない(処理インテリジェンスを持たない)、単なる歩兵である点がすばらしいのだ、とFrenkielは言う。

“企業が今インメモリコンピューティングに注目しているのは、それがビッグデータ問題を解決するための新しいアプローチだからだ。インメモリコンピューティングは速度という成分を解決するが、しかし、量という成分を満足させるためにはスケールアウトのためのアーキテクチャが同時に必要だ”。

彼によると、今企業は、既存のソリューションを利用しつつ、データウェアハウスを最新の高速化データベースで拡張して、高速なデータ分析により意思決定の高速化を支えようとしている。“これからは、データ分析が高速で、トレンドや異状を速く見つけられる企業が勝つ”、と彼は言う。“大量のデータを分析しなければならない、という状況は今後も変わらないが、今では速度を重視したアーキテクチャにより、重要な発見や洞察がリアルタイムで得られるようになっている”。

Enigma

Engima は、先週行われたDisrupt NY 2013で優勝した。協同ファウンダのHicham Oudghiriによると、スピードのニーズの背後には必ず、データ量の絶えざる増大というニーズがある。しかし彼によると、EnigmaやPalantirなどが抱えるスケールの問題は、多くのスタートアップが日々直面している問題とまったく異なる。

“ふつうスケールというと、ユーザ数が数千、数万、数百万と増えていくことへの対応だ。だから、問題の形は、どの段階でも同じだ”、とOudghiriは言う。“複数のサーバを並列で動かすとか、予備機を増やすといったワンパターンの対応になる。Webサーバの稼働のラウンドロビン化、CloudFlareのようなCDNの利用、Amazonのようなオートスケール方式でトラフィックのピークに対応する、などなどの方法がある。しかしユーザ数ではなくてデータ集約的なアプリケーションでは、問題がまるで逆になる。スケーラビリティの問題はユーザ数ではなくて、一つのクェリのために何十億もの行を調べるという問題になる。さらにしかも、集めてくるデータの形式や性質や内容がそれぞれバラバラで不統一、という問題に遭遇することも多い”。

彼曰く、これらの問題には、サーバの台数を増やすなどの単純な解はない。ただし、データの保存という点では、冗長性が何よりも重要である。

“唯一の正しいモデル、というものはない。SQLかNoSQLかグラフデータベースか、という選択の問題でもない”、とOudghiriは言う。“それらをすべて使うこと、それぞれに適した役所(やくどころ)を与えることが重要だ。そうやって、各方式の持つ利点を最大限に利用しなければならない。データベースを、一つの理想的なシステムと見なすのではなく、それぞれの声が互いを補い合うことによって生まれる“ハーモニー”だ、と考える。一つの問題を解くときに、頭の中にはつねに、効果的に使い分けられる複数の道具がある、という柔軟性がとても重要だ”。

“第二に、RAMが自分の親友だと考えること、パーシステンシ(persistency,データのオフメモリの持続的存続)はサーバのクラスタで実装することが重要だ(サーバはパーシステンシのための装備であり、実稼働はもっぱらオンメモリで行う)。うちでは、検索のスケール(規模拡大)をRAM内で行っている。今は、メモリがとても安いから、それが十分に可能だ。ただしそうなると、RAMに保存したデータのパーシステンシを確実にメンテできるソフトウェアの構築が、重要な課題になる”。

しかし、中には、RAMのコストを問題視する人びともいる。この点について、彼に聞いてみた。

“部分的にSSDも使っているが、非常に水平的な検索(列よりも行指向)では十分に速くない”、とOudghiriは言う。“しかも、SSDは、こっちが事前に予期できないタイミングでパフォーマンスが急に落ちる。それに比べるとRAMはまったくパーシステントではないけど、むしろノンパーシステントだからこそ頼りになる。リスクと、得られる利点との、トレードオフだね”。

10gen

10genの見方は違う。10genは、NoSQLデータベースMongoDBのスポンサー企業だ。10genの技術部長Jared Rosoffは、スピードには少なくとも二つの側面、アプリケーション開発とアプリケーションのパフォーマンスがある、と言う。

“MongoDBのアプリケーション開発が速いことには、異論がない”、とRosoffは言う。“データモデルに柔軟性があり、ドライバが定型化されていることにより、デベロッパの生産性が高く、機能の改良も速い”。

アプリケーションのパフォーマンスに関しては、MongoDBは余っているメモリのすべてを最近使ったデータのキャッシュに使うので、メモリが十分に大きければインメモリの高パフォーマンスが達成される。

しかしRosoffによると、ワークロードが大きくなるとDRAMはけっこう高いものになる。

“でもビッグデータの仕事を完全にインメモリのデータベースでやろうとすると、十分な量のDRAMを使わざるを得ない。問題は、一台のサーバに載せられるRAMの量に限界があることと、RAMの費用そのものだ。MongoDBは、ディスクやフラッシュストレージを使って、一台のサーバの上で相当大きなデータ集合を処理できる。MongoDBの顧客の多くが、SSDやFlashストレージデバイスを使って、比較的安く、インメモリに近いパフォーマンスを達成している。

また、MongoDBの(NoSQLの)ドキュメント型データモデルではデータのローカリティ…局所性…を維持できるので、複雑なデータモデルと違ってディスクI/Oの回数が少ない。これも、ハイパフォーマンスの重要な鍵だ。

SlashDB

SlashDBは、関係データベースのAPIを作る。ファウンダのVictor Olexの説では、ユーザが求めるスピードはデータベースそのもののスピードに帰結する。

“データアクセスの速度は距離(ネットワークのレイテンシ)だけでなく、ファイルシステムやデータベースからデータを取り出すのに要する時間と、その間のデータ変換の量(フォーマットの変換、エンコード、デコード、圧縮など)にもよる。また、データの取り出しの効率は、データ構造の実装にもよるし、間接参照の少なさも重要だ*。とくに今のデータベース上のエンタプライズデータは(そのデータ構造が)、Webを利用する情報システムにとってボトルネックになっている。関係データベースは宣言型(not手続き型)のクェリができるので便利だが、そのためにインメモリでもディスクからでも、必要なレコードを取り出す計算費用が高くなる。逆にNoSQLのようなドキュメント型のデータベースは、一般的に数値キーでデータを取り出す。データを保存するときに数値を割り当てて、数値とデータを対照するルックアップテーブルを作っておくのだ”。〔*: 直接参照は「n番地にあるデータを読め」、間接参照は「n番地にあるデータに書かれている番地にあるデータを読め」。〕

“さまざまなキャッシング技術がデータアクセスのスピード向上に貢献しているが、そこには精度の低下という費用が発生する(目的データがキャッシュにないこともある)。たとえばWebページでは、キャッシュには古い日付のものしかないことが、よくある。でもそれは、実際にデータベースにアクセスして最新データを取り出す処理費用との、トレードオフという問題だ。我慢できるトレードオフ、と言うべきか。キャッシングとWebアプリケーションのレイヤはスケールアウト(out)して同時に複数のサーバを動かせるから、複数のリクエストを並列に処理できるが、しかしデータベースサーバの方は、一台のサーバの容量やプロセッサを増強するというスケールアップ(up)しかできない。SlashDBは企業のシステムにWeb型のサービスを提供している。つまりURLの中にクェリがあり、結果をHTTPのレスポンスで返す、という形のサービスだ。それは複数のノードでも動かせるし、通常のHTTPプロキシにも対応して、頻用されるリクエストをキャッシュしている”。

“データ集約的な処理は主に、サーバサイドのシステムの領分だった。モバイルデバイスの普及で状況はやや変わってきたが、しかしそれでも、人間の情報処理能力は昔と変わらない。一説ではそれは、毎秒60ビットと言われる。だから、それ以上速いスピードでデータを配布しても意味がない、無駄である、という説もあるのだ。Twitterやメールだけは、別かもしれないがね”。

AlchemyAPI

“AlchemAPIはスピードにこだわっている”、とCEOでファウンダのElliot Turnerは言う。“うちの顧客はみんな、情報の時間価値を知っている。だからデータをできるだけ速く処理することとうちの業績は直接結びついている。しかしデータ処理アプリケーションをもっと速く動かすための簡単な秘訣はない。ボトルネックはいろんなところで発生する。データの保存、取り出し、分析など、いろんな局面で”。

“データの分析の効率化にはさまざまな方法があり、GPUによるハードウェアアクセラレーションや、分散コンピューティング、アルゴリズムのイノベーションなどいろいろだ。AlchemyAPIはこれらすべてを組み合わせて利用するとともに、RAMやSSDを多用することによってデータの保存、取り出し、そして処理を高速化している”。

“RAMは着実に価格が下がりつつあるが(http://www.jcmit.com/mem2013.htm)まだSSDよりも一桁高いし、ハードディスクよりは二桁高い。ペタバイト規模のビッグデータを完全にRAM上で処理するのは、ちょっと費用的に無理かもしれないから、うちも含めてRAMとSSDを併用するハイブリッド方式のところが今は多い。でも、テラバイト規模の小さな展開では、徐々にRAMオンリーに変わりつつある。今後さらにRAMが安くなれば、展開規模も大きくできるだろう”。

まとめ

データ処理の高速化の話は、SSDやRAMや最新のデータベース技術だけで終わるものではない。しかし、一つだけ確かなのは、世界が高度に分散したデータメッシュになり、そしてその負荷が日に日に増大するとともに、新しい高速化の方法が必ず必要になることだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


全世界のWordPressサイトに大規模攻撃; デフォルトのアドミンユーザ名’admin’がねらわれている

本誌TechCrunchのように、WordPressを使ってサイトを構成しているところは、管理/編集ページにアクセスする人たちのパスワードが“強いパスワード”であることを、あらためて確認しよう。そしてユーザ名が、”admin”であってはいけないHostGatorCloudFlareからの報告によると、今、WordPressを使っているブログに対する大規模無差別攻撃が行われている。その大半は辞書を使用する力ずくの攻撃で、とくにWordPressがデフォルトで設定する”admin”アカウントのパスワードを見つけようとする。

HostGatorの分析によると、これは高度に組織化された、そして広範囲に分散した攻撃だ。同社の見積もりでは、今のところ約9万のIPアドレスが使われている。CloudFlareのファウンダでCEOのMatthew Princeが今朝語ったところによると、ハッカーたちは約10万のボットをコントロールしている。CloudFlareが実際に見たところによると、攻撃は相手を選ばずで、特定の種類のサイトに偏ってはいない。

知らない人に自分のパスワードを当てられるのも迷惑だが、犯人たちの最終目的はサーバを乗っ取ることだ。CloudFlareの説によると、犯人は現在、比較的ローパワーなホームPCのネットワークを使っているが、そのねらいは“強力なサーバによる大きなボットネットを作って次の攻撃に備える”ことだ、という。ホームPCは、大規模なDoS攻撃の舞台にもなる。しかしサーバを乗っ取って利用すれば、さらに強力な攻撃が可能だ。

今行われている攻撃は、同じくWordPressのサイトをねらった2012年の攻撃に似ている。でもそのときの攻撃は、古いバージョンのTimThumbを探した。これはWordPressのテンプレートの多くがデフォルトで使っている、PHPによる画像のサイズ変更ソフトだ。

CloudFlareとHostGator、およびそのほかのホスティングプロバイダの多くが、顧客を保護するための適切な措置をすでに講じている。強力なパスワードを選ぶことはつねに重要だが、いろいろWordPressプラグインをインストールして、同じIPアドレスや同じネットワークからのログイン回数を制限し、こういう力づくの攻撃を防ぐこともできる。ただしWordPressのファウンダMatt Mullenwegは彼の今日の午後のブログ記事で、ユーザ名を’admin’から別の…ありふれてない…ものに変えることが最良の防御だ、と言っている。犯人は9万ものIPを使っているのだから、特定は困難である、と。あなたのサイトがもしもWordPressを使っていたら、二段階認証をonにして、セキュリティの層を厚くすることもできる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))