大規模SNSのボトルネックとソリューション：大規模サイトの舞台裏（2/4 ページ）

[藤本真樹，ITmedia]

アクセスコントロール

　非常にボトルネックになりやすいもう1つの項目は、アクセスコントロールです。各個人のプロフィールページのように、1ユーザーだけの情報を表示する場合は特に問題にならないのですが、「友達を検索」のように串刺し検索を行うと、非常に面倒なことになってきます。

　GREEではプロフィールとして年齢、血液型、未婚／既婚、性別、居住地が設定できますが（図2）、それらに対してそれぞれ「公開する／しない」を選択可能で、かつそれらの項目を条件にして検索できるようになっています。そのため、検索が実行されたときには、プロフィールの各項目について「公開する／しない」という情報を参照しつつ検索する必要があります。

　また、日記あるいはフォトデータに関しても、プロフィールのように全体に公開、友達まで公開という形でアクセスを制限できるので、日記の全文検索（あるいは全体の新着情報）のインデックスから「友達まで公開」とされているエントリは外さなければなりませんし、しかもそれらの公開設定はエントリが記述された後に変更される可能性が十分にあるので、そういった状況にも対応する必要があります。

　今後日記エントリごとに公開設定を変更できるようになった場合には、さらに処理が複雑になるでしょう。処理が複雑になるということは、「大規模SNS実現のためのGREEのアプローチ」で解説したように、構築／運用のボトルネックになる可能性が高いといえます。

SNSのボトルネックに対するGREEのアプローチ

図2　フックを利用したイベント通知機構の仕組み

　これら2つの問題について、目下のところGREEでは、「フックを利用したイベント通知機構」を利用して解決しています（図2）。つまり、

• リクエストがあったタイミングでデータを取得する

のではなく、

• データ更新のタイミングであらかじめ必要なデータを非同期に構築しておく

わけです。例えば、ユーザーが日記を更新した場合には、次のような処理が行われます（図3）。

図3　ユーザーが日記を更新した場合に行われる処理

1. 日記エントリ追加イベントをキューに追加する
2. イベント処理システムがそのキューを読み出す
3. 「日記エントリを追加したユーザーの友達のユーザー」全員の「友達の新着日記データ」に当該日記情報を追加する

　これを実現するために、次のような機構を用いています。

1. データを更新するパスを1つに絞る形でアプリケーションを構築して、データ更新部分にフックメソッドの呼び出し処理を追加する
2. フックメソッドでイベントキューの追加処理を行う
3. イベントキュー処理システムが、イベントキューを1つずつ処理する

と、これだけではよく分からないと思うので、次ページからは、日記が書き込まれた場合を例にとって具体的に説明していきます。