はじめに
こんにちは。(株)ミクシィ 運用部アプリ運用グループの小池知裕です。前々回は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にて採用される理由になります。ここまでで読者のみなさんにはお気づきだと思いますが,mixi.jpではシステム運用に関して「運用コストの低減(運用しやすさ)」というポリシーを採用しています。それでは運用業務の事例にて具体的に紹介していきたいと思います。

