はじめに

こんにちは。（⁠株）ミクシィの吉野です。私は、システム本部運用部インフラグループ基盤技術チームに所属し、業務のひとつとしてインターネット回線をサービスインフラに提供するといった仕事をしています。インフラグループ内には基盤技術チーム以外にもサーバチームとネットワークチームがあります。彼らがサーバやネットワークなど各レイヤの専門家であるのに対して、基盤技術チームはレイヤにとらわれない幅広い業務を行っています。

サービスのトラフィックは日々変化していきます。一口に「変化」と言っても、リクエスト数やコンテンツサイズなどの量的な変化や、リクエストとレスポンスの比率の変化、誰と通信しているかの通信先の変化といったパラメータがあり、これらが新機能のリリースやユーザの利用環境の進歩によって変化していきます。

その中でも、mixiアプリのような新しい概念のサービスの登場や、スマートフォンの普及といったできごとは、トラフィックを大きく変化させます。そこで今回は、mixiサービスとインターネットをつなぐ上位回線ネットワークにおいて、mixiがこのような変化にどのように対応してきたのか、その変遷を紹介していきます。サービスを止めずにインフラの整備を進める醍醐味やコンテンツサイトの成長過程の一端を感じていただければ幸いです。

上位回線のマルチホーム化

いまさら言うまでもないことかもしれませんが、インターネットは複数のネットワークが相互に接続して成り立っています。それぞれのネットワークはAS（Autonomous System：自律システム）と呼ばれており、それぞれを識別する番号（AS番号）が付いています。これらの各ASがお互いに知っている経路を教え合うことで、インターネットの通信は成り立っています。この「経路を教え合う」ことを「ピア」と言い、その通信にはBGP（Boarder Gateway Protocol）というプロトコルが使われています。

普段意識することはないと思いますが、みなさんが普段利用されているISPもすべて、何らかのASに所属しています。同様にmixiのようなコンテンツ事業者も何らかのASに所属しています。このようにASに所属しインターネットに接続するには、シングルホームとマルチホームという2種類の方法があります。

シングルホームとマルチホーム

シングルホームとは、家や会社でISPと契約したり、データセンターからインターネットの接続を購入するような場合で、すでに存在するASにぶら下がる形を言います（図1⁠）⁠。この場合はIPアドレスをぶら下がったASから借り受けているため、複数のASに所属することはできません。したがって、提供元のASに障害が発生すると、インターネットに接続できなくなります。

これに対してマルチホームとは、自身がASとなり、複数のASと相互接続することを言います。ISP事業者やデータセンター事業者そのものは、このような接続形態をとってサービスがほかの特定のASに依存しないようにしています。マルチホームの場合には、接続先のASの1つに障害が発生しても別のASを経由してインターネットへ接続することができます。この場合のIPアドレスは、どのASにも属さない自社所有のIPアドレスとなります。

mixiサービスの上位回線は当初、契約している各データセンター単位でシングルホーム回線を用意していました。しかしこれではデータセンター事業者のネットワークがダウンした場合に、そのデータセンターからインターネットへの出口がなくなり、サービスを継続することが難しくなります。また、各データセンターのトラフィックはサービスやユーザの状況によって変化していきますので、偏りが生じます。たとえば、あるデータセンターの上位回線は60％使用しているのに、別のデータセンターでは20％しか使用していない、といったことが発生し、上位回線を効率良く利用するためだけにサービスを他方のデータセンターに移動するといった煩雑な対応が必要となります。

これを解消するために、mixiでは自社のASとIPアドレスを取得し、2009年3月に上位回線のマルチホーム化を行いました（図2⁠）⁠。

mixiのマルチホーム構成

マルチホーム化により、いずれかのデータセンター事業者のネットワークがダウンした場合でも、もう片方に自動的に迂回させることができるようになりました。また、各上位回線の利用割合が不均一になった場合でも、BGPでトラフィックの割合を調節できるようになりました。さらに、IPアドレスを自社で所有していますので、上位回線事業者を自由に変更したり増減することができます。ちなみに、AS番号は38651です。

図2のネットワーク設計を簡単に説明すると、まず、BGPを話せるルータが2台あります。この2台のルータがBGPを使って構成しているネットワークを、上位ASとの境界部分なのでmixiでは「ボーダネットワーク」と呼んでいます。

その2台のルータがそれぞれ、OSPF（Open Shortest Path First）という内部ネットワーク用の経路制御プロトコルを使って、デフォルトルートを配下のL3スイッチに広報（ブロードキャスト）します。これにより、BGPルータの片方が故障した場合には、もう片方のBGPルータにデフォルトルートが切り替わるようになっています。このOSPFで構成された個所は、内部ネットワークのうち自社所有のグローバルIPで構成されている部分のため、mixiでは「グローバルネットワーク」と呼んでいます。

サーバはグローバルネットワーク配下のサーバファームに接続されており、それぞれのサーバのデフォルトルートはL3スイッチに向いています（このグローバルネットワーク部分にもいくつかの冗長設計がされていますが、今回は上位回線ネットワークの話ですので割愛します⁠）⁠。

これを作ったときにはまだ勉強不足で、いくつか不備がありました。たとえば、アクセスコントロールリスト（以下、ACL）に関する問題です。mixiではインターネットからの不正なアクセスを防ぐために、ルータとL3スイッチの間にIP ACLを記述して、不正な通信をブロックしています。

グローバルネットワークでは内部サーバ同士が通信を行う場合がありますが、通常はこれらの通信にIP ACLは適用されないため、問題になることはありません。しかし、何らかの障害やオペレーションミスでOSPFによるトラフィックの迂回が発生した際に、そういった通信がいったんボーダネットワークを迂回してグローバルネットワークに戻ってくるケースが発生し得ることがわかりました。この場合、不正なアクセスを防ぐためのACLが内部サーバ同士の正常な通信にも適用されてしまい、通信できなくなります（図3⁠）⁠。なお、この問題は該当する通信でサービスに直ちに影響するものがなかったため、その後の構成変更で改善していくこととし、この段階では放置することにしました。

mixiアプリによるトラフィックの変化

Webサービスではよくあることですが、新しい機能のリリースによってトラフィックの傾向が突如として変わることがあります。図4はmixiアプリモバイル版リリース時のmixiサービスのトラフィック総量を示したグラフです。急激に伸びている個所がリリースで、前日のトラフィックの1.5倍に達しています。こういう日があるからコンテンツ事業者はやめられません。ドキドキわくわくです。

このときは、量的な変化だけでなく、リクエストとレスポンスのトラフィック比率にも大きな変化が見られました。

一般的にWebサービスでは、ユーザから受け取る通信よりも、ユーザに返す通信のほうが大きなトラフィック量になります。コンテンツの投稿量よりも閲覧量のほうが多いためです。mixiの場合も、mixiアプリが始まる以前までは、ユーザから受け取るトラフィックよりもユーザに返すトラフィックのほうが5倍くらい多い状態でした。それがmixiアプリの提供により大きく変化し、現在ではおよそ3倍以下の比率になっています。

受け取るトラフィックが増えたのは、ユーザとの通信ではなく、外部のサイトとの通信が増えたことが主な要因です。mixiアプリでは、ソーシャルアプリケーションプロバイダ（以下、SAP）から提供されているWebアプリケーションを、mixi側のシステムで中継してユーザに表示する必要がある個所があります。この中継を行うために、SAPが提供しているWebアプリケーションコンテンツをmixi側のシステムでいったんすべて受け取ってからユーザに送る必要があり、そのために受け取る側のトラフィックが増大したのです（図5⁠）⁠。

この変化は、回線の効率利用を考えると悩ましい課題の一つとなります。従来は受け取るトラフィックは送り出すトラフィックに比べて5分の1程度だったため無視することができ、ユーザに送り出すトラフィックの回線利用効率だけを考えてトラフィックの制御を行っていればよい状況でした。これが受け取る側のトラフィックが増えたことにより、両方を考慮してトラフィックの制御を考えないといけなくなりました。

また、各SAPはmixiと連携してコンテンツを提供するパートナーとなりますので、各SAPのWebアプリケーションが置かれているサイトとの通信品質の確保や、通信コストの低減といった課題も出てきました。

このSAP側サイトとの通信品質とコストに対する対策として、データセンター事業者との直接ピアを積極的に実施しています。mixiのASと各データセンター事業者のASを直接接続することで、途中にほかのISP事業者を介すことなく通信できるため、通信障害の切り分け範囲を狭めることができ、上位回線ISPのトラフィックコストも低減することができます。

ネットワークの階層化

このような構成で1年弱ほど運用していく中で、いくつかの問題点も出てきました。

たとえば、OSPFで構成されているグローバルネットワークで障害が発生した際に、BGPで構成されているボーダネットワークにまで影響が出ることです。ボーダネットワークとグローバルネットワークで運用者が違うことも、この問題を複雑にしました。ボーダネットワークは一次オペレーションや監視を外部に委託していた一方、グローバルネットワークは自社で運用していたのです。

このような、他方の障害やメンテナンスがもう一方に影響を与える構成をなんとか改善したいと考え、いろいろな方の意見を参考にして検討した結果、現在はグローバルネットワークの機器にプライベートASと呼ばれる内部利用AS[1]を設定し、ボーダネットワークとはOSPFを使わずにBGPで接続する構成にしました。これにより、ボーダネットワークとグローバルネットワークのOSPFによる相互依存がなくなり、さらには運用者の異なる複数のグローバルネットワークを、ボーダネットワークに収容することもできるようになりました。

こうして、いくつかのグローバルネットワークをボーダネットワークに収容するようになってくると、今度はボーダのルータのポートコストが無視できない状態になってきました。また、mixiサービスとの連携などにより、グローバルネットワーク同士の通信も発生してくるようになりました。そこで今では、ルータにL2スイッチを接続して、自社内IX（Internet Exchange point）を構築して運用しています。また、ほかの事業者とのピアにもこの構成を使用している部分があります。

最新の状況としては、従来からあるフィーチャーフォンに加えて、スマートフォンでの利用が急激に増えてきています。携帯キャリアによってはフィーチャーフォンとスマートフォンとではASが異なります。そういった点も考慮しながら、ルータの増強や回線の調達を行っています（図6⁠）⁠。

今後の課題

今後の課題としては次のような点があると考えています。

受け取るトラフィックの障害切り分けの難しさ

外部のサイトと連携しているため、連携先との通信に問題があると、mixiサービスの応答性能にも影響を与える場合があります。

連携先との通信障害の原因としては、単純なサーバ故障もあればDNS（Domain Name System）の問題、途中の通信経路上の問題など、さまざまな個所が関連してきます。このうち、サーバやDNSの問題については、独立した別の設備から問題の切り分けを行うなどして、自社の問題なのか、外部サイトの問題なのかを切り分けていくことは、ある程度まで可能です。しかし、通信経路上の障害については、中継しているASのどこに問題があるかといった切り分けが、単純にはできません。

自分から相手に送るパケットについては簡単で、経路をtracerouteコマンドで確認しやすく、BGPの制御で別のASに送り出すことは容易にできます。しかし、相手から自分が受け取る通信に関しては、tracerouteでは経路を確認することができず、BGPによる経路制御も相手方の協力なしには難しいことが多々あります（図7⁠）⁠。

この問題に対して考えている方法としては、SAPが利用していると思われる各データセンター事業者に仮想サーバをそれぞれ借りて、それぞれの仮想サーバからmixiへtracerouteし、その結果を収集するしくみを用意できないかと考えています。各データセンター事業者とどのような経路で通信しているかを確認できるようになれば、経路の途中でパケットが破棄されてしまうようなことが発生したとしても、問題個所の推定がある程度可能になると考えています。

海外クラウドとの通信

mixiでは国内のユーザが大半を占めることもあり、国際トラフィックは微々たるものでこれまで特に問題になりませんでした。ところが最近では海外のクラウドサービスを利用しているSAPも数多くあり、その通信が悩みの種のひとつです。物理的に遠いためサイトのレスポンスに影響を与えたり、国内で直接ピアすることが難しいため通信コストにも影響を及ぼします。

海外との通信は、間接的に業界全体の原価を押し上げることになっていきますので、国内のクラウドサービスがどんどん活用されて、業界としてのコストが下がるとうれしいと思っています。

外部サイトとの連携

ほかのサイトとサービスを連携する際には、無関係なアクセスや不正なアクセスをブロックする目的で、双方が使用するIPアドレスを教え合って、そのIPアドレスからの通信のみを許可する場合があります。

マルチホーム化をしておらず回線提供事業者のIPアドレスを借り受けて運用している場合には、その事業者に問題が生じたときには復旧を待つことしかできません。よってmixiのようなプラットフォームサービスを運用するうえでは、回線に紐づかないIPアドレスで運用することは、とても意義のあることです。

ただ、mixiサービスにおいても、昔から使用しているシステムなどで自社IPへの移行が完全に終わっていないものが残っています。これらも当然自社IPに移行してしまいたいのですが、移行したからといって機能が向上するといったものではないため、調整も作業のモチベーションを維持するのも一苦労です。

また、いずれはIPv6での連携も視野に入れる必要が出てくるでしょう。外部連携接続のサーバをどのようにIPv6で設計していくかも、悩みは深いです。

まとめ

今回はトラフィックの変化とそれに合わせた設備の変遷を紹介しました。

mixiサービスは、2011年3月時点で月間ログインユーザ1,537万人を抱える社会インフラに成長しています。3月の震災においても、地震やアクセス増に影響されずにサービスを止めることなく提供し続けられたことは、我々インフラ運用部門にとっては日々の努力が試される非常に重要なできごとだったと思っています。

24時間365日動いていることが当然と思われている…そんな社会インフラと化したサービスを停止しないように動かし続けながら、じわじわと構成をアップグレードしていくという作業は、工夫のしどころが多くとても楽しいものです。そういった仕事に興味があれば、ぜひ一緒に働きましょう。