はじめに

はじめまして。（⁠株）ミクシィのシステム本部 運用部でアプリ運用を担当している小池知裕です。mixiのシステムの運用／管理業務に従事しています。本連載では、3回にわたってmixi.jpでのシステム運用業務の裏側を紹介します。

ミクシィの運用部のシゴト

最初に、（⁠株）ミクシィの運用部という組織について簡単に説明します。運用部には「アプリ運用」「⁠インフラ」「⁠バックオフィス」の3つのグループがあり、それぞれ「ソフトウェア面での運用／管理／改善」「⁠ハードウェア面での運用／管理／改善」「⁠購買／資産管理」の業務を担当しています。

そのほか、同じシステム本部には技術部があり、さまざまな研究開発を行う研究開発グループやmixiの大規模障害で有名になった、たんぽぽグループなどがあります。

本連載では、筆者が所属するアプリ運用グループで、mixiサービスのソフトウェアをどのように運用／管理／改善しているかについて取り上げます。

突然のアクセス集中

mixiは突発的な高負荷（アクセス集中など）がときどき発生します。たとえば毎年12月31日の大晦日から新年1月1日に切り替わる瞬間などです。各携帯キャリアなどでも毎年のように広報される「0時付近での通話やメールなどでの新年のご挨拶はお控えください」と言われるアレです。

そこで今回は、「⁠毎年1月1日0時0分になった瞬間にアクセス（書き込み）が爆発的に増える現象」を例にして、ここ数年でどういった障害が起きてきたのか、どう対策したのか、そしてどういう結果になったのかを時系列で紹介します。

なお、本稿では「1月1日0時0分になった瞬間」のアクセス集中を「あけおめアクセス」という名で呼びますが、社内用語などではありません。あくまでも個人的にそう呼んでいるだけです。

例年の傾向と対策

2008年の年末

2008年当時は、まだmixiと言えば日記で、コンテンツは日記が大部分を占めていました。そして、毎年1月1日0時0分になった瞬間に多くの利用者が一斉に日記を書いていました。

われわれも当然のことながら、その「あけおめの瞬間」に投稿される日記のアクセス集中対策を行っていました。具体的には、日記のIDを管理する「ID Generatorの改善」です。

• ID Generatorの改善：ID管理用のAPIを用いて大量のクライアントからの接続を行わないように改善

もう少し詳しく説明をします。mixiではすべての日記にIDを付与して管理しており、日記の投稿時にそれらを採番してデータベースに保存していました（これは今も変わっていません⁠）⁠。

create table idpot (
  id bigint unsigned NOT NULL default '0'
);

リスト1のテーブル（idpot）に対して、日記が投稿されるたびに次のクエリで更新を行い、idの値を次々と更新していきます。

UPDATE idpot SET id=LAST_INSERT_ID(id+1);

そして、更新されたidの値を日記のユニークなIDとして保存します。その日記のIDを管理しているテーブル（リスト1のidpotテーブル）が、あけおめアクセスでの大量アクセスによって多数のクライアントから一斉／大量にMySQLに接続したためエラーになっていました。そこで、図1のようにMySQLへの接続本数を減らすように「ID Generatorの改善」を施しました。

2009年1月1日はどうだったのか？

話は翌年に進みます。図1の対策を取っていましたが、残念ながら2009年1月1日0時過ぎにアクセス集中のため日記投稿でエラーが発生してしまいました。

ID管理用のAPIを用いて多数のクライアントからの接続数をコントロールしていても、さらに多くのアクセスが発生したため、MySQLの性能を超えてエラーが発生してしまったためでした。

そして、あけおめアクセスの改善はさらに翌年に継続されます。

2009年の年末

mixiボイスがインディーズから正式機能としてリリースされ、mixiボイスの投稿数が上昇していましたが、1月1日0 時0 分の日記投稿はまだまだ多いはずだと予想していました。

また、前年の結果を踏まえて、再度、日記のID Generatorの改善を行いました。具体的には「API方式でのアクセスを止め、ID管理用のテーブルをストレージエンジンのInnoDBではなく、MyISAMとすることでパフォーマンスの向上を図る」というものです。

現在、MySQLで用いられるストレージエンジンとはInnoDBが主流であり、mixiでもほとんどすべてのMySQLサーバではInnoDBで運用しています。InnoDBはMyISAMになかった次のようなメリット（機能）があります。

• 行単位のロック
• 大量のデータのあるテーブルのパフォーマンス向上
• トランザクション機能

ただし、先述したように「ID Generator」は非常に単純なテーブル／クエリであり、データも常に1件しかないテーブルです。そのためこれらの高機能な部分が仇となっていました。われわれはこれらの機能は「ID Generator」には不要と判断し、思いきってストレージエンジンをMyISAMに変更を行いました。

では、2010年1月1日はどうだったか？

テーブルをMyISAMにする作戦は功を奏し、無事になんとか1月1日を過ごすことができました。「⁠接続数を制限してもダメなら、MySQLそのもののパフォーマンスを上げればいいじゃない」という戦略は無事に成功したのでした。

2010年の年末

日記の大量アクセスを乗り切ったのもつかの間、昨年（2010年）にはmixiのアクセス負荷はmixiボイスが主役の座を勝ち取っていました。

mixiボイスは気軽につぶやける手軽さが魅力のサービスで、日記よりもあけおめアクセスが厳しいものになると予想されました。そのため、すでに日記／ボイスなどに負荷分散を目的として導入していた「ジョブキューシステム」の改善に着手しました（図2⁠）⁠。

改善前は、ボイスだけでなく日記やフォトでも同じ1つのジョブキューシステムを汎用的に使用していました。それを「mixiボイス用キュー」「⁠日記用キュー」というように、それぞれ専用のキューを用意し、キューにかかる負荷の減少やアクセス増加時の影響を最小限に抑えるように工夫しました。

ちなみにmixiで採用されているキューシステムは奥一穂（@kazuho）さんの開発された、MySQLのPluggable StorageEngineとして動作する「Q4M」を採用しています。

今年（2011年）の1月1日は……

そして今年、2011年はこれまでの改良の甲斐もあって、新年の大量なアクセスにも関わらず、mixiはダウンすることなく、ユーザの「あけおめ！」つぶやきをしっかり受け止めることに成功しました。

これらのボイス投稿数がどのくらい爆発的なアクセス増加だったかというと、図3（年またぎ）と図4（平常時）のグラフを比較していただければわかりやすいかと思います（図3と図4の縦軸の数値は異なります⁠）⁠。

まとめ

今回はシステムに対するアクセス高負荷の一例として、年末年始のアクセス急増とその対策について2008年から振り返る形で紹介しました。

実は、こういった負荷の集中は、年末年始の「あけおめアクセス」時だけはありません。mixiボイスのつぶやきの気軽さも手伝って、たとえば、日本代表が優勝した「AFCアジアカップ」などのスポーツイベントや「東京に雪が積もった」というだけでも、いつもの倍のアクセス数になることもあります。

そして3月11日に発生し、いまだ東北地方に深い爪痕を残している東日本大震災の発生直後においてもmixiボイスの投稿数は通常時（平時の金曜日14時～15時）のおよそ8倍のアクセス数を記録しました。

アクセス数の急増は年末年始のように経験的に起こることが予想できるものもありますが、いつ起こるか予測不可能な突発的なことも多いです。まだまだユーザ数も増加する中で、常日頃からシステムがアクセス急増に耐えられるよう改善を続けていく必要があると感じています。

また、このようなシステムの改善には終わりがなく「これをやっておけば大丈夫」ということはありません。日々の運用／改善の業務がとても重要になってきます。われわれはこれまで以上に2,300万の会員が日常的に利用するプラットフォームとして、日々安定的な運用と改善を行っていきたいと考えています