Facebookのインフラを支えるということ--担当バイスプレジデントに聞く - (page 2)

　しかし、メインスタックはほとんど変わっていません。われわれは、PHPコードで動くウェブフロントエンドを導入しています。長い間、基本的には独自のコンパイラと、独自のランタイムシステムを記述しています。効率を高めるには、そうする必要があると分かったからです。われわれは、自社のインフラをできるだけ効率的で費用対効果の高いものにしておきたかったので、「HipHop for PHP」と呼ばれるものを開発し、2年以上前にオープンソース化しています。われわれはそのフロントエンドの新しいバージョンを、毎日9億人のユーザーに送り出しています。

　バックエンドには、さまざまなものがあります。われわれのウェブフロントエンドは1つですが、数多くのさまざまなバックエンドサーバとやり取りし、無数の違ったデータオブジェクトの読み込みや参照をしています。そうしたデータの処理やソート、ランク付け、プライバシーのチェック、フィルタリング、さまざまな分析を行う必要があります。その後、ページを作成して、ユーザーのデスクトップや携帯電話に1秒足らずで戻さなければなりません。どんなときでも、違った種類の試みが無数に行われている可能性があるのです。われわれはこうした考え方を、勢いを失わないようにして繰り返し述べています。

--開発中の新製品や新機能が処理能力の変更を必要とする場合、人々はあなたのところに来ます。どのようなやり方をしているのでしょうか。

Parikh氏：Facebookには、処理能力とパフォーマンスを担当するチームがあります。このチームの仕事は、すべてのエンジニアリングチームと共同で作業しながら、彼らのニーズを理解しようとすることです。現在このチームにいるのは、スプレッドシートをあれこれ使って仕事をする、アナリストやビジネス担当者ではありません。コードやパフォーマンス、分散システム、アーキテクチャを理解している、本当のエンジニアたちです。そのため彼らは、システムの仕組みや、想定されている機能を十分に理解しています。

　人々がこのチームのところに来るのは、サーバを増やす必要があるときに限りません。処理能力を増やすことはできますが、そのために必ずしもサーバを増やすわけではありません。面白い話があります。あるエンジニアチームが処理能力担当チームのところに来て、「サーバが8000台必要です」と言いました。処理能力担当チームは「そうですか、なぜでしょう」と尋ね、そのエンジニアチームが何をしようとしているのか理解するために時間を取りました。一連の議論とレビューを終えてみると、（判明したのは）必要なサーバは8000台ではなく、わずか16台だということでした。

--あなたが後方で計画を立案する役割を担っていることを踏まえてお尋ねしますが、今から1年後のFacebookはどうなっている可能性があるでしょうか。

Parikh氏：製品の面でFacebookがどうなっていくのかについては、あまりお話しすることができません。

　インフラの面では、われわれは効率的で費用対効果の高いインフラの構築を続けていこうとしています。ただし、われわれが望んでいるのは、収集している全データを管理し、利用できるようになることです。われわれは「（Apache）Hadoop」に多額の投資をしています。現在Hadoopにあるわれわれの最大のクラスタは100ペタバイトを超えています。つまりわれわれにとっては、スケールアウトして、この増加し続けるデータに対処する方法が問題なのです。100ペタバイトはそう遠くない将来に数エクサバイトになります。数年後には、100ペタバイトはわれわれとって当たり前のものになるでしょう。

--それにどう備えますか。

Parikh氏：われわれは文字通り毎日、解決策を見つけようとしています。製品のニーズが変わり、ユーザーが10億人に達しようとしており、全世界的にモバイル利用が増加する中で、われわれはこの問題について試行錯誤し、日々何らかの調整を行っています。

--Facebookのエネルギー消費量はどのくらいですか。

Parikh氏：それは公表されていません。

ノースカロライナ州フォレストシティに開設されたFacebookのデータセンター
提供：Facebook