今回はインフラエンジニアの守備範囲について書いてみます。

このテーマは筆者のここ最近ずっと考えていることで，セミナーなどでも話したことが何度かあるので聞いたことがある人もいるかもしれません。

以前は一般的なインフラエンジニアの作業内容と言えば，ケーブリングやサーバの設置，OSインストールと環境構築，バックアップなどのメンテナンスやセキュリティ対策，あとはチューニングとトラブル対応というものが多かったと思います。この中で，環境構築とチューニングという部分が，今回のトピックです。

memcachedビフォー・アフター

これは完全に筆者の私見ですが，memcached登場以降，インフラとアプリのクロスオーバーというものがひとつの転換期を迎えたと思います。もちろん0－100という話ではないですが，それまではアプリケーションはアプリケーション，インフラはインフラという線引きがわりと明確でした。

今ではもはやマネージドホスティングというのは相当一般的になりましたが，当時はまだデータセンターというとコロケーションやハウジングがほとんどで，インフラエンジニアの仕事というとフィジカル面（ケーブリングやラックマウント，目視など）と，あとはサービス監視と電源のoff/onというくらいのものが多かったと思います。

ただ筆者が当時運営していたデータセンターは，インフラエンジニアが比較的上位のレイヤまで関与するという方針だったため，相対的に言えば他のデータセンターよりクロスオーバーは起こっていた，また起こりやすかったと言えます。

そのデータセンターでは，だいたい線引きとしては，サーバ（ここではMySQLやApacheなどのサービスのこと）関連のインストール（とそれにまつわる設定⁠）⁠，configまでがインフラエンジニア，それを利用するのがプログラマ，という感じでしたが，サーバ関連に強いプログラマだと，インストールというかconfigure/make時のオプションやconfigにも関与しているケースもありました。

たとえばわかりやすい例だと，mod_rewriteをガリガリと使うようなケースでは，サーバの設定とアプリの挙動を揃える必要があるので，そのあたりでの連携は必須になるわけですが，まあ連携とクロスオーバーはちょっと違うかもしれません。

いずれにせよ，ちょっと簡単なアプリというかWebサービスを作るくらいなら，セットアップされたサーバがあれば，あとは特に何も気にせずプログラムを書いていく（せいぜいDBの接続情報まわりを気にするくらい）でもいいのかもしれませんが，ある程度以上の規模や機能のサービスを手がける場合，インフラエンジニアとプログラマ（アプリ開発者）というのはクロスオーバーしてくるというのが筆者の持論です。

パフォーマンスへの要求がクロスオーバーを加速する

そして，この状況を加速させる（させた）要因がさらに2つ（いやもっとあるかもしれませんがここでは2つ）あると思います。それがWebサービスの双方向性の急拡大とクラウドの登場です。

まずWebサービスの双方向性ですが，その昔（昔？）Web2.0という名前で呼ばれていたのとまあ近いかもしれません。双方向性をソーシャル性と言い換えてもいいと思います。ここ数年でWebサービスは急速にソーシャル性を増しているのは間違いないところです。

以前はWebサービスというのは基本的にread（閲覧）が多いものでした。ところがソーシャルというのは個々が情報発信することで作られる世界ですから，以前とは比較にならない量のwrite（書き込み）があたりまえのようになってきました。

そのはしりは2chだと思いますが，そのあとブログがありSNSがあり，そしてTwitterなどのソーシャルサービスや，またECやニュースサイトもクチコミやレビューなしというのは考えられない（は言いすぎですかそうですか）ようになってきています。

またそもそも，ソーシャル性が高まることでサイトに訪問する頻度が高くなり同じUUでもPVが増えたり，そもそもUU自体が増えたりしていることや，Ajaxなどを利用した便利で複雑なUIの登場でPVあたりのアクセス数が増えたりなど，全体的にネットの活用度（＝アクセス数）が増えていることもあります。

そして，サイト自体がpersonalizeされることで，ユーザごとに異なる内容が表示される，すなわち同じUU／PVでもデータへのアクセス量が増えてもいます。ほんの10年前までは，ほとんどのWebサイトは誰が見ても同じ内容を表示するもの（違うのはマイページくらい）でしたが，いまやかなりの割合のサイトがユーザごとに異なる内容を表示するようになっています。

その代表格がSNSやTwitterのようなソーシャルサービスです。このように，ソーシャル性の拡大によってwriteが増えている，サイトへのアクセス数が増えている，データへのアクセスが増えているなどの変化が起こり，Webサービスに要求されるパフォーマンスというのは以前とそれこそ桁が違うようになっています。

たとえば5年前と今とで，平均して1PVで発生するデータへのアクセス数は，10倍とかそれ以上になっているかもしれません。あくまでデータベースではなくてデータですが。

2つ目のクラウドですが，ここでいうクラウドはTVのCMでやっているなんだかよくわからないクラウドのことではなく，AmazonのAWSに代表されるようなIaaS，GAEのようなPaaS，あとはHadoopなどの分散アプリケーションのことを指しています。

すでにソーシャルゲームのプレイヤーにとっては，IaaSというかAWSをどう活用するかは生命線になってきていますし，ソーシャルゲーム以外でも最近増えているGroupon系のいわゆるフラッシュマーケティング（と言っていいかどうかは議論の余地がありますが）的なサイトなど，アクセスがスパイクするようなサイトではいかにフレキシブルにリソースを増減させられるかがそのままサイトのクオリティとコストに直結してきます。

また分散（分散じゃなくてもですが）KVSをどう活用するか，KVSほどではないですがMR（MapReduce）をどう活用するかが，いまのサイトの構築におけるかなりホットなトピックであるのは間違いのないところです。

そういう意味では，曖昧模糊としたクラウドというワードは便利でもあり本質を見失う可能性もあるので，両刃の剣ではありますが，これはまあ今後落ち着いていくと思います。

この2つ，主にソーシャル化によるWebサービスにおけるデータアクセスの爆発的な増大と，それを受け止めるクラウドというワードで表現される各種技術の登場と進化が，インフラとアプリをクロスオーバーさせていくのだと，筆者は考えています。

アプリを設計，開発する際に，そもそもインフラのことがわかっていないとパフォーマンスに優れたサイトを作れない，またその逆でプログラムのことをわかっていないとパフォーマンスに優れたインフラを作れない，という時代になってきています。

前述したソーシャルゲームやGroupon系のサービスを手掛ける現場では，もはやそれが当然のようになってきていますが，それら以外のサービスにおいてもこの流れはどんどん拡がっていくことでしょう。