はじめに

初めまして，（⁠株）ミクシィの中野和貴です。私はシステム本部運用部インフラグループネットワークチームという部署で働いており，ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50～55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや，その後のインフラ事情を紹介していきます。

日々大量のトラフィックが流れるmixiのネットワークですが，大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。

ミクシィのネットワーク構成と問題の発覚

mixiでは主要なネットワーク機材にはお金をかけていますが，サービス規模からどうしてもラック数が多くなってしまうため，エッジスイッチには安価で故障率の低いものを選定して使用していました。ここが今回の話の焦点となります。

ではまず，mixi全体のネットワーク構成から話を進めていきましょう。mixiのネットワークは図1に示しているように，ごく一般的な構成で成り立っています。コアスイッチやボーダルータのような主要スイッチの間は10Gbps，コアからエッジへは1Gbpsでの接続です。

ある日，部内でスループットが頭打ちになってしまっているポートがあるという話が出てきました。対象ポートのトラフィックグラフを見てみると，確かにピークタイムでTCPの制御が働き，トラフィックが頭打ちしてしまっているようです。そこでさらに調べてみると，けっこうな数のポートが同様の傾向を示していることが判明し，詳しく調査を始めることとなりました。

またしても原因はmemcached？

そもそも対象となったポート配下にいるサーバは，何の用途でサービスに投入されていたのでしょうか。確認したところ，すべてmemcachedサーバとしてサービスに投入されていました。memcachedといえば，2010年8月にmixiで発生した大規模障害の原因であったのは記憶に新しいところですが，これとは別にネットワーク側でもちょっとした問題が発生していたのです。

通常時では起こらないトラフィックの頭打ちがなぜピークタイムだけ起こるのか。単純に考えればピークタイム時のトラフィックがスイッチの性能限界を超えてしまっているからということで片付いてしまうでしょう。しかしながら，この現象が起こっているときのエッジスイッチの総スループット量はSNMP（Simple Network Management Protocol）から取得したグラフを見ると600Mbps強でした。仮にすべてのトラフィックがショートパケット（64バイト）だと仮定しても，アップリンクが1Gbpsあれば，約760Mbpsがスイッチの上限値となります（※⁠）⁠。ですので今回の事象の答えとしては適切ではありません。

※）

スイッチの処理限界理論値は「アップリンクポートのbps×（パケット内のデータ長÷パケット長⁠）⁠」で求まります。今回の値をあてはめると，1000000000×（64÷84）＝761.9Mbpsとなります。

バーストトラフィックとは

では，結局何が原因で問題が発生していたのでしょうか。結論から書いてしまうと，スイッチの性能限界を超えたトラフィックが流れたことによりパケットがドロップされていたためでした。しかし，グラフを見る限りスイッチ性能を超えたトラフィックが流れていないのは先ほど説明したとおりです。この矛盾はどこから出てきたのでしょうか。その答えはmemcachedの応答タイミングから考えることができます。

memcachedはご存じのとおりメモリ領域にデータとオブジェクトを置き，リクエストを高速に処理する分散メモリキャッシュシステムです。mixiサービス内のmemcachedは数十ms間隔でリクエストに対して応答を行っているのですが，ここが今回問題となった点です。

memcachedはリクエストに対して1つのmemcachedからのみ応答があるわけではなく，複数台のサーバから応答が返ってきます。そのため，多量のリクエストがある場合は相当数のサーバからほぼ同時にレスポンスが返ってくることになります。しかもこれが数十ms間隔で継続的に発生します。このような状態のトラフィックグラフは図2のようになります。

このように，瞬間的に突出した流量を示すようなトラフィックをバーストトラフィックと言い，これが発生しているときにスイッチの限界性能を超えてしまうため，パケットが頭打ちしていたのです。

この問題の厄介な点は，数ms単位でのサンプリングをしなければバーストトラフィックを発見できないところです。数ms単位でのサンプリングはアナライザのような高価な機器が必要となってしまい，非常にコストがかかります。SNMPを使ってトラフィックグラフを生成しているだけでは気づくことができません。私たちも推測をもとに，協力会社とアナライザを使って検証した結果やっとこの原因を究明することができました。

バーストトラフィックへの対処

このように原因がバーストトラフィックによるものだと判明したわけですが，次は対処法を考えなければなりません。memcachedをカスタマイズして応答タイミングをずらすなどの方法を使っている会社もあるようですが，mixiではネットワーク側からのアプローチでこの問題に対処するという方針で解決を図りました。

これにはいくつか理由があります。まず，いくら応答時間をずらすなどのアプローチで原因解決をしても，スイッチポート配下のmemcachedサーバ数が増大していった時点でバーストトラフィックの発生する可能性は増えてきてしまう点。次に，mixiの運用部は少人数であるため，アプリケーション側での対応を実施すると運用しきれなくなることが懸念された点。最後に，そもそもサービスネットワークのグランドデザイン自体が数年前のもののため，今後のサービス規模拡大やサーバの性能向上によるトラフィックの増大も視野に入れると，memcached部分のネットワークにだけ対応しても中長期的に見ればほかのシステム部分でも起こり得る問題になるのではと考えたからです。

これらの方針に加えて，そもそも最近のトラフィックの増大から1Gbpsでのネットワークに限界を感じていたこともあり，コアからエッジまでの間を10Gbpsでつなぐ新設計へと移行することにしたのです。

この力技な解決法だけでもこのバーストトラフィックの問題は解消できます。しかし，今後長期的に使えるネットワークにしていくにはこれだけでは足りません。今後CPUの処理性能向上や省電力化が進むにつれ，1ラックあたりのサーバ搭載密度は上がっていきます。そうすると必然的にラック単位でのトラフィック量が上がっていき，上位スイッチ側のポート単位でのトラフィック量が増えていきます。そうなると，現状でのサーバ搭載密度では解決できていたバーストトラフィックが，中長期的に見ればまた問題になってしまう可能性があるからです