ビジネススピードと信頼性を両立させる システム基盤構築記[by mixi]

第1回 2011年「あけおめアクセス」の対策と結果

この記事を読むのに必要な時間:およそ 2 分

はじめに

はじめまして。⁠株)ミクシィのシステム本部 運用部でアプリ運用を担当している小池知裕です。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を付与して管理しており,日記の投稿時にそれらを採番してデータベースに保存していました(これは今も変わっていません)⁠

リスト1 idpotテーブル

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の改善」を施しました。

図1 2008年から2010年の対策

図1 2008年から2010年の対策

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に変更を行いました。

著者プロフィール

小池知裕(こいけともひろ)

(株)ミクシィ システム本部 運用部 運用グループ アプリ運用チーム

コメント

コメントの記入