はじめに

こんにちは。（⁠株）ミクシィ 運用部アプリ運用グループの小池知裕です。前々回はmixi.jpの大規模トラフィックの裏側を、そして前回はmixi.jpシステムの監視について紹介しました。今回はmixi.jpを支える日々の運用／管理業務そのものにフォーカスを当ててお話しします。

“アプリ運用”という部署の業務

Webサービスにおいて一般的な「運用／インフラエンジニア」と呼ばれる方の業務は、多くの場合、データセンターでの作業（サーバのラッキングやネットワーク機器との配線／設定など⁠）⁠、ネットワークの運用、メンテナンスも含まれることが多く、また企業やプロジェクトによってはサービスの開発者が運用業務を兼務している場合もあるでしょう。

ミクシィのアプリ運用は、“⁠アプリ⁠”という名称がついていることからもわかるとおり、（⁠ミドルウェアも含めた）アプリケーションサーバの運用／管理を主に行っています。その一方で、アプリ運用のメンバーは、いわゆるmixi.jpのサービス開発や企画立案などは行いません。さらにルーチンワーク的な運用業務だけではなく、突発的なアクセス急増や過負荷にシステムが耐えられるような準備や改善を行ったりもしています。

以上のことを総合すると、筆者の所属するミクシィのアプリ運用グループは「mixi.jpを支えるサーバ群のミドルウェア以上のアプリケーションの運用／管理／改善を専門で行う部署」ということになります。

このように分業された運用専門部署を持つWebサービスは比較的珍しいことだと思います。そういったこともあり、今回紹介するアプリ運用という業務については、すべてのWebサービスの運用／管理を業務とする方にそのまま当てはまらない部分も多々あるかと思います。しかし、日々Webサービスの運用業務を行う際の何らかのヒントや、「⁠なるほどmixi.jpの運用は普段こういったことをしているのだな。ふむふむ」といったところを感じてもらえれば、筆者としては喜ばしいです。

mixi.jp を支えるサーバ運用の哲学

まず、日常の業務を紹介する前にmixi.jpサービスで用いられているサーバ群の特徴（図2）を整理します。

これらのサーバをタイプ別に、データセンタ内の数ラックを1単位としたユニットにまとめてラッキングしています。なぜこのようにサーバを3タイプに分けているのでしょうか。理由はいくつかありますが、次のようなメリットを意識しているためです。

• 4,000台以上のサーバの管理コストの低減
• サーバの設計／選定を簡略化できる
• OSなどドライバの調査／検証のコスト低減

mixi.jpでは局所的な適材適所によるサーバリソースの効率的な利用よりも、運用コストが低減できることを重視して、このような運用方法を選択しています。

また、mixi.jp の基本的なシステム構成はreverse proxy 配下にWebアプリケーションサーバ、そしてDBサーバ（memcached含む）がある3層の構造になっています（図3⁠）⁠。

このような構成になっているメリットのひとつとして、

• Webアプリケーションサーバ／DB（memcached）の増減がしやすい

という特徴があります。つまりアプリ運用グループがサーバを増強／入れ替えするのに適した構成と言えます。

それでは運用業務の事例にて具体的に紹介していきたいと思います。

日常の業務の一例（構築）

まず最初に、日常の運用の業務についての事例として「サーバの設定作業」を挙げます。

mixi.jpでは大量のサーバの設定変更やミドルウェアのアップデート作業を行います。当然ながら1台ずつログインして設定ファイルの編集やインストールの作業をするわけにはいきません。ミスの危険性も多くなりがちで何より手間（運用コスト）がかかります。

こういったサーバの各種設定ファイルやミドルウェアの更新はmixi.jp内のリポジトリサーバに独自RPMパッケージを作成し、それらRPMパッケージを各サーバに配布／更新することで作業を行っています（図4⁠）⁠。

このような方式で行うことにより、大量のサーバの更新作業が容易、設定ファイルやミドルウェアの一括管理が可能という「運用コストの低減」が実現されています。

非日常の業務の一例（障害対応／増強）

逆に、日常的でない業務として、障害時の対応を紹介します。障害と一口に言っても、

• アプリケーションのバグによるもの
• サーバのハードウェアの故障／障害によるもの
• 急激なアクセス増加／過負荷によるもの
• その他の要因によるもの

と、さまざまなものがあります。

急激なアクセス増加／過負荷については問題個所やボトルネックの解消を繰り返し行うことで改善を行っていることは本連載の第1回で紹介しました。

では「サーバの故障」による障害についてはどうでしょうか？ mixi.jpは4,000台以上のサーバを保有しています。これだけ台数が多いとサーバのハードウェア故障も多々あります。そのような場合には、サービスから外し、故障したサーバは廃棄しています。端的にいえば「サーバは使い捨て（消耗品）感覚で運用」を行っています。ちょっともったいないような気もしますが、次のような理由から「サーバは故障したら廃棄」の運用フローを選択しています。

• 故障したサーバにかえって余計なコスト（手間や時間／電気代）がかかる
• 1～2年程度で今までより同じ価格帯で高スペックなサーバが発売される → 入れ替えしたほうが得

また、サーバの増強や入れ替えに関して、4,000台以上のサーバを保有していると書きましたが、その保有サーバのすべてがサービス提供に用いられてはいません。あらかじめある程度の数のサーバを余剰を持ってラックに積んで設定をしておき、必要になった場合（増強や障害での入れ替え）にすばやくサービスに入れられるようにしています。

このようにサーバを故障交換用以外の目的であらかじめ準備をすることも、「⁠サーバの無駄のない活用」より「運用コストの低減」を重視して選択されたポリシーになります。

まとめ

さて、今回を含め3回の連載を通して、mixi.jpにおける「システム基盤構築記」ということで突然のアクセス集中とその対策、システムの監視、日常の運用業務を紹介しました。

第1回では年末年始の対策として、図5のようなジョブキューシステムの改善内容を説明しました。また、第2回では運用監視するためのOSSも紹介しました。Webサービスの運用管理業務は多岐にわたりますが、どのようなことが求められているのか少しだけでも感じていただけましたでしょうか。

普段あまり意識されていないサービスの運用業務ですが、この連載をきっかけにWebサービスの運用業務について読者の皆さまの何らかのヒントになれば幸いです。