だいぶプライベートがゴタゴタしていて（主に引越で）今更の話で申し訳ありませんが次世代 Web カンファレンス(以下nextwebconf)のserver_perfで登壇する機会を頂いたのでその事を書いておこうと思います。
まず最初に、登壇者を見た時凄いメンツ過ぎてビビったというのと、それを実現するJxckさんのすごいなと思いました。
スライドなしでトークのみで議論するというイベントなのでぶっつけ本番かというとそうではなく、当然ながら僕にとってserver_perfってなんだろうというのをイベント当日、そして終った後も考え続けました。そういう意味では割と準備にエネルギーがかかったものだと思います。
おかげであやふやだった自分の中でのイメージが、一定のまとまりを得たというのも非常に成果でした。
このエントリはその際に作ったメモの一部を綺麗にしたものです（全部がパフォーマンス関連というわけではないです）
結論というわけではなく、あくまで僕の考えということをご留意ください。
そうえばサーバサイドパフォーマンスってなんだっけ
サーバサイドはともかくとしてパフォーマンスってすごく広い言葉だと思います。
単純にレスポンスが高速になるというのもパフォーマンスでしょうし
唐突の高負荷にも、サービスを落とさずオートスケールしていくのもパフォーマンスだと思いますし、いろいろあります。
この記事では主にレスポンスについて、そしてネイティブというよりブラウザよりです。
そもそもクライアントとサーバの境界線は何処だろう
いきなり昔話ですがWindows95~98がでたあたりのWebは非常に簡単でした。
ブラウザで動くコードは、せいぜい動いてマウスを追跡するスクリプトぐらいで、単純にDC等においてあるマシンから静的なファイルや、はたまたCGIで掲示板などを動作させてtableタグで段組が終わったHTMLを生成してレスポンスしていたと思います。
地図サイトも、今のようにシームレスに動くようなものではなく、クリッカブルマップで座標を変えていくものでした。
当時のブラウザとDCにあるマシンは、クライアントとサーバの関係でした。
しかしJavascriptがどんどん強力になり、少し前にAjax、そして最近ではHTML5/ServiceWorkerが出てきて、今までクライアントであったブラウザの中にサーバのようなものが出てきてからは、スパっとクライアントとサーバを分けることが難しくなってきています。
昔であれば、サーバサイドでかかった時間やファイルサイズ等のサーバサイドだけを見ていればそこまで大きなズレはありませんでしたが
最近ではサーバサイドをいくら速くしても、ブラウザで動くスクリプトがアレであればレンダリングが秒単位で遅れることなんてのも珍しくありません。
パフォーマンスを考える上で相対的にサーバサイドの重要性が下がり、クライアント側の重要度が上がってきているといえるでしょう（もちろんサーバサイドを御座なりにしていいというわけではないです）
言うならがスパっと境界線が引ける状態ではなくserver/clientのどっちに軸足を起きつつ両方見れるかというのが重要になってきているといえます。
また、誰がコントロールするかというのも意識する必要があると考えています。
サーバであればコントロールの主体は僕らなのでスペックやデータのコントロールもしやすいのですが、クライアントのコントロールの主体は必ずしも僕らではなくスペックもバラバラでデータのコントロールもしづらいです。
個人的に考えている次世代のサーバサイドパフォーマンス
クライアントの処理性能はどんどん向上し、PC・モバイルともにNW環境もよくなり、以前に比べて非常に環境がよくなりました。
しかしWebは高速になったでしょうか？
僕は必ずしもそうではないと考えています。
コンテンツがどんどんリッチにヘビーになっているということ、良くなったNW環境をまだ効率的に使えていないと考えています（HTTP/2が普及するといいなぁ）
そのような中で如何にパフォーマンスを考えていくかというと一つのヒントが昨年のAkamai Edge14カンファレンスのビデオ(Meeting the Grand Challenges of the Internet)の中にあると思います。
この中でVOD関連のキーワードとしてMOVING INTO HOMESというのが出てきています。
これは主にVODにおいて爆発するトラフィックについての話なのですが、僕はそれ以外でも言える話だと考えています。
僕にとっての次世代のサーバサイドパフォーマンスを考える上で
- データは何処にあるのか
- データはその場所にいつからあるのか
- そのデータは個別のクライアントにとって最適であるか
が重要だと考えています。
すごく噛み砕くと
- 如何にクライアントの近い場所にデータを置くか
- プリフェッチ・プッシュ・キャッシュ
- クライアントに応じた最適化
です。
如何にネットの環境が良くなろうとも、物理的に近いほうが良いのに決まっています（そして効率のよいプロトコル）
最近はありがたいことにクラウドがあるので、物理的にクライアントの近い場所にインスタンスを置き、そこからレスポンスをするということが大規模サービス事業者でなくても可能になりました。（選択もRoute53で楽になりました）
ただ、全世界で一つのデータソースを元に何かするということはいろいろ考えることがあり難しいです。
そこで重要なのが、クライアントに応じた最適化そしてキャッシュだと考えています。
まずクライアントに応じた最適化ですが、いわゆるFEOをはじめとするManagedな最適化サービスです。(AkamaiのIonやinstartlogicなど）
クライアント側のコードの最適化は複雑化してクライアントの種類（特に端末）も増えてもはや人力で全てのページで100%を目指すというのは辛くなっていると考えています。
そのためFEOのような透過的に最適化を行うロジックが今後も発展すると考えています。
なによりこれが素晴らしいのが最悪キャッシュが出来ない場合でもパフォーマンスの向上を期待できることです。
もちろん大抵の場合はキャッシュと併用できるはずですが・・・
次キャッシュの場合です。
キャッシュで設定するTTLですが、すごく乱暴な話をしてしまえばその期間は物理的に何処にデータを置いてもいいのです。（もちろんクライアントの近くに）
では単純に、CDNやクラウドのいろんなリージョンにキャッシュサーバを立ててしまえば解決でしょうか？
僕はそうは考えていません。
ここでもう一つ重要なこととしてロジックが動くことです。
何故ロジックが動くことが重要かというと、キャッシュを行うというのは本来危険なことで、静的コンテンツならともかく動的コンテンツに対してキャッシュを行う場合は高度な制御(=ロジックが書ける)が必要です。
もちろんキャッシュ用途だけではなく高度なfailoverなどにも使えます。
そういう点では、VarnishのVCL、まだ途上ではありますがNginxのnginScriptはそれに使えると考えています。またCDNでいえばFastlyにも注目しています。
またこのロジックから最適化の仕方をより自由に選べるようになると思っています。
以上を纏めると
- データはどんどんクライアントの近くに置かれるようになる
- 中間経路（CDN等）はよりインテリジェンスになりロジックが動くようになる。
- 経路で実行可能なロジックはキャッシュを効率的に行うためのもの（よりサーバサイド）と透過的にクライアント向けのコードの最適化を行う（よりクライアント向け）二種類がありそう。
- 2つは併用することでより効果を発揮する
と考えています。
新しいミドルウェアや方法論は誰のための銀の弾丸か
確かトーク中に銀の弾丸というキーワードを出したと思うのですが、誤解を招きやすいキーワードなのでここで説明したいと思います。
進歩の激しいこの業界ですから新しいミドルウェア・フレームワークが出てきては消えていっています。
出たてのモノはすごくピカピカでまるで銀の弾丸のようにみえます。
ある意味これは正しくて、もともと銀の弾丸とは狼男とかを倒せる的な意味で、熊や竜も倒せるかというとそうではなく、何にでも効くというわけではないのです。
じゃぁ狼男とはなにかというと開発した会社で抱えている問題で、必ずしもあなたの問題ではないということです。
一言で言うならばワークロードが違うわけです。
僕がここで言いたいのは新しいものを見つけた際にいきなり飛びつくのではなく、何を解決したくてそれが生まれたのか、そのワークロードは？というのを考えるべきではないかということです。
よりManaged・複合化へ
例えばHadoopを使いたい・・・けど自社では運用管理出来ないというので様々なManagedなサービスがありますが、今後も様々なミドルウェアでその動きが出て来ると思います。
そしてそれら単機能のサービスを組み合わせた複合サービスというのがでてくると考えています（AWSのMobilehubもそのようなものと考えています）
それはまるで次世代機能のサービスパックのような感じになるかなと思います。
言い方はいやらしいとは思うのですが、イノベーター理論の各グループそれぞれで次世代は違い、ラガードに行くに従ってどんどんManaged/複合化されていく（より小規模でも使える）と考えています。
個人的なパフォーマンスについての思い
僕は毎年エイプリルフールにすごく憤っています。(Twのログみてみたんですがやっぱ憤ってました)
理由は負荷が来るのがわかっていても何故対策をしないのかということです。
お金の問題というのもあると思いますが、恐らくここになんらかのソリューションが出てくると考えています。
また、パフォーマンス関連で新しいモノが出てきた際にそれだけをやれば良いということではなく基本的なことも忘れないといいなと思います。
以前記事で書いたように割と基本的なことができていないことが多かったりします。
インターネットは歴史の積み重ねでできています。その中でパフォーマンスについてもそうといえます。
もちろん陳腐化して使わないようなもの（HTTP/2であればCSSスプライトなどのように）もありますが、対策の6割以上は過去のナレッジが使えるんじゃないかなと思っています。
ぜひ次世代だけでなく積み重ねについても考えてみるといいんじゃないかなーとか思ったりしてます
最後に
運営の方々登壇者の方々参加者の方々、server_perfセッションのmirakuiさん・cubicdaiyaさん、そしてJxckさん、皆様本当にお疲れ様でした。
他のセッションやセッション後、打ち上げでの話など非常に楽しかったです！
#や っ と ぼ く の n e x t w e b c o n f が お わ っ た ぞ ！
