Browse Month: December 2009

The Art of モバゲー Capacity Planning

さて、2009 年も残すところ、あとわずかとなりましたが、今日はモバゲー版のキャパシティプランニングを考えてみましょう。モバゲー版は、まだ実際にはサードパーティ製のアプリが公開されていない状況だとは思いますが、開発サイトが公開されています。モバゲー版も、mixi モバイルアプリ版と同様に、パートナー企業のみが開発できるようになっています。

まず、モバゲーの規模を知るために、 月次推移のご報告(平成21年10月度)を見てみましょう。この資料から、2009 年 10 月時点での PV は、次のようになっています。

  • 会員数: 1527 万人
  • 月間 PV: 約 238 億 PV
  • 単純平均して、日間にすると約 8 億 pV、秒間にすると約 9,259 PVになります

次に、モバゲーの成長速度を計るため、月次推移のご報告(平成21年8月度)を見てみましょう。この資料から、2009 年 8 月時点での PV は、次のようになっています。

  • 会員数: 1220 万人
  • 月間 PV: 約 198 億 PV
  • 単純平均して、日間にすると約 6.6 億 PV、秒間にすると約 7,638 PVになります

そうすると、2009 年 10 月から三ヶ月前経過した 2010 年 1 月には、最低でも次の数字になっていると推測されます。

  • 会員数: 1800 万人
  • 月間 PV: 約 280 億 PV
  • 単純平均して、日間にすると約 9.3億 PV、秒間にすると約 10,802 pv になります

さすがは、モバゲーというだけあって、mixi のモバイル版よりはかなり規模が大きいです。

モバゲーの場合も夜の時間帯に約 3 倍のリクエストがあるとなると、モバゲー本体で秒間あたり約 3 万 PV になります。

モバゲーアプリはまだ公開されていないので、モバゲーの会員数のうちいったいどのくらいのユーザがモバゲーアプリが使うかは分かりませんが、すべての会員がアプリを使うことは当り前ですがありません。

おそらく、約 2 割のユーザが使って、アクセスが集中する時間帯で約 3 倍になると仮定すると、おおよそ次のくらいの規模になりそうです。

  • 会員数: 約 350 万人
  • 月間 PV: 約 60 億 PV
  • 日間 PV: 約 2 億 PV
  • 秒間最大 PV: 約 6,000 PV

モバゲーも mixi 版と同様にかなりの規模になることが分かりました。

いよいよ今年から、日本でも OpenSocial 対応を表明していたサイトが続々と実際にそれぞれのプラットフォームを公開してきました。OpenSocial 対応のアプリを開発しているのは、前でもエントリしたとおりいわゆるベンチャー企業が多いので、これだけの大きなトラフィックをいかに低コストでかつ確実にさばけるかがアプリの成功の鍵を握っていると思います。

個人的には、このような大きなトラフィックをさばくということに、とても大きな関心と興味があるので、来年はさらにもうすこし踏み込んでいかにして低コストでかつ確実にさばくか考えていきたいと思います。

それでは、よい年をおむかえください!

The Art of Mixi-mobile-appli Capacity Planning

2009年も残すところあと僅かになりました。今年のネット業界にはたくさんのことが起きましたが、国内でもっともインパクトがあったのは日本最大の SNS サイト mixi がついに OpenSocial 対応になったことだと思います。

今日現在、PC 版とモバイル版の2種類が提供されており、PC 版は企業と個人、モバイル版は企業のパートナー契約を結んだ会社のみ開発して公開できるようになっています。

さて、mixi のモバイル版が公開された直後は、アクセス殺到にて軒並みモバイル版のアプリケーションを提供しているパートナー企業のサーバに大きな負荷がかかって、ほとんどの mixi のモバイルアプリが使えない状況になったのは記憶に新しいです。3日で約60万人ユーザも集める人気アプリも数多く登場した様子です。

今日は、もし仮に僕が 2010年1月1日に mixi モバイル版アプリを提供することになったことを想定して、インフラ面からどのくらいのアクセスをさばくことができれば問題がないかどうか調べてみました。

まず、そのために mixi の規模感を知るために、mixi から提供されている 2009年度第2四半期 決算説明資料 を参考にしてみると、次の数字が分かります。

  • ユーザ数: 1792 万人
  • モバイル版月間 PV: 114.4 億 PV

とても大規模な環境です。

そして、先月のニュースで「mixi利用時間急増、Yahoo!に次ぐ2位に mixiアプリ効果 – ITmedia News」というものがありました。このニュースによれば、利用時間が2倍になって、ユニークユーザ数がそれほど変わっていないことが分かります。

mixi のユーザ数、モバイル版の PV の伸び率を調べるために、2009年度第1四半期 決算説明資料をみてみると、次の数字が分かります。

  • ユーザ数: 1741 万人
  • モバイル版月間 PV: 109.9 億 PV

この数字から、四半期あたりの伸び率が次のように分かります。

  • ユーザ数: +約50 万人
  • モバイル版月間 PV: +約5 億 PV

これらの情報から、2010 年 1 月の mixi モバイル版本体は次のような規模感になります。さきほどのニュースからユーザ数はそのまま比例して増えていく、月間 PV は2倍で増えていくことを想定しています。

  • ユーザ数: 約 1817 万人
  • モバイル版月間 PV:  約 120 億 PV

mixi モバイルアプリなので、mixi モバイル版本体より月間 PV は増えないはずです(当り前ですが…)。

モバイル版月間 PV を、日/秒あたりの PV にすると、次のようになります。

  • モバイル版日間 PV: 約 4 億 PV
  • モバイル版秒間 PV: 約 4,629 PV

mixi のユーザが全員モバイル版アプリを利用することにはなりません。現在、モバイル版アプリで一番ユーザ数の多いアプリはまちつく!mixi版 (2,258,452)で約 230 万人くらいになっています。そうすると、モバイル版アプリの利用者は、現時点で多くても約 1/9 くらいになります。

これらの情報から、mixi モバイル版アプリの場合、急激に人気になったことを想定すると、次のくらいの規模感になります。

  • モバイル版日間 PV: 約 4,500 万 PV
  • モバイル版秒間 PV: 約 520 PV

上の秒間は平均的な値です。mixi などのウェブアプリケーションは、必ずもっとも利用される時間帯があるはずです。おそらく、22時から24時あたりでないかと勝手に想像して、なんとなく直感で通常の3倍のリクエストが来ると想定すると、次のような規模感になります。

  • モバイル版日間 PV: 約 4,500 万 PV
  • モバイル版秒間 PV: 約  1,500 PV

この数字が、もっとも人気になった場合の数字になりそうです。mixi モバイル版アプリは、いわゆる人数の少ないベンチャー企業が開発しているのがほとんどなので、最初から上の規模感をさばける環境を準備するにはけっこうなコストがかかりそうです。とはいっても、上の数字はもっとも人気になった場合の数字なので、必ずしも最初から上の規模感をさばけるインフラを準備しておく必要はないはずですが、最高で上のぐらいの規模感になりそうだということがおおよ想像できます。もちろん、実際に公開してみないことには人気が出るのか出ないのか、どのくらいのリクエストが来るのかは分かりませんが、こうして mixi から提供されている情報やニュースなどでおおよその規模感を把握することができるので、とりあえずなんとなくすこしのインフラを準備して公開するよりはよっぽどましだと思います。

次は、同じようにモバゲーも調べてみたいと思います。

自作サーバカンファレンスを振り返って

先月、自作サーバカンファレンスが開催されたので遊びにいってきました。自作サーバカンファレンスのレポートは、はてブで確認するといいと思います。また、動画も公開されているようなので、興味のある人はチェックするとよいと思います。

自分のサービスで、自作サーバを使うメリットとデメリットを考えてみました。

まずは、メリットは、id:stanaka さんのオープンニングキーノートで述べられていますが、この点について考えてみます。

  • 自分のサービスにあった自分好みの自作サーバとしてカスタマイズできる
  • この点についてはまさにそのとおりで、自作サーバをするうえでの最大のメリットであると言えるでしょう
  • たしかにベンダー製サーバは、BTO である程度、搭載部品を選択できても、無駄な部品が搭載されていることは確かなことです
  • SSD を搭載して大胆な構成がとれる
  • 例えば最近 DELL でも SSD を搭載できるモデル(PowerEdge R510)が登場してきているため、SSD だけでは自作サーバを使うメリットはなくなってきている状況だと思います
  • 複数の NIC、冗長電源、IPMI (一部のサーバには必要)は不要
  • たしかにほとんどのサーバには複数の NIC は不要なケースが多いです
  • 僕は DELL サーバをメインで使っていますが、たしかに NIC 4 つとか搭載されていても使っていませんし
  • 冗長電源は、DELL の場合はカスタマイズでなしにすることができます
  • IPMI は個人的にはないと困る機能です、もしサーバに何らかのトラブルが発生してデータセンター現地にいって該当のサーバにディスプレイをつないで作業する工数と IPMI 経由で作業する工数を比べると、はるかに後者の工数のほうが少ないはずです
  • コスト安
  • はてなさんのウェブサーバスペックで、サーバ1台あたりの単価は8万円程度
  • それ以外に発生するコストとしては、サーバの部品調達と組み上げコストが発生します
  • さらに台数が増えることで管理コストが増大します、台数が増えてもある程度管理コストを増やさない仕組みが必要そうです

次に、デメリットを考えてみましょう。

  • 1台あたりのスペックが低い
  • はてなさんのサーバスペックは、CPU Core2Duo 4core、8GB RAM(ECCなし)、ハードディスク x 1、のスペックで 1U ハーフ、消費電力は 1.1A くらいになっています
  • 1U あたりで考えると、この2倍のスペックになりますが、この2倍のスペックになってやっと現在のベンダー製サーバと低標準スペックになりますし、消費電力は 2.2A になることを考えると若干消費電力が大きくなるといえます
  • 自作サーバの場合は、ラックあたりに多くの自作サーバを詰め込む傾向になってきます
  • 自分達でトラブルを解決する必要がある
  • ハードウェアの相性トラブルなどを自分達で解決できなければなりません
  • 例えば DELL なら、無料電話サポートでエンジニアを派遣して解決してもらうこともできますし、部品(CPU やマザーボードなど)が壊れた場合は通常で3年間は無料で交換してくれます(部品は、都内だと5時間くらいで配達してくれます)

メリットとデメリットがあるので、あとはどちらを選択するのかが大事だと思う。

個人的には、自作サーバを導入するなら、次の環境が必須だと思った。

  • インフラチームなる、サーバだけ見ている人たちがいる
  • 自作サーバでのサービス運営を容認してくれる企業文化

ということで、今の僕の環境は一人でアプリケーション開発とインフラを見ているので、インフラチームがないという点でとても不可能だと思った。

最後に、個人的に自作サーバを入れるところは、やっぱりストレージサーバかなと思う。ストレージサーバは、容量を増やすことでいっきに価格も変わってくるし、管理ツールはベンダー独自のものを使わなければならないという状況が多い様子だから。

いずれにしても、自作サーバだけではやっぱり無理な部分もあって、自作サーバとベンダー製サーバあるいはクラウド、要所要所でもっとも適したものを使っていくというが大事だと思う。

例えば、はてなさんはかなりベンダー製サーバとのコストも気にしている様子だったので、自作サーバだけに特化せずに大きな視点で物事を見ることも、とても大切だと思う。

僕は、ベンダー製サーバを選定して運用している経験しか今のところないので、これからも情報共有できるととても幸せだと思う。

かなり遅くなりましたが、個人的な自作サーバカンファレンスを振り返っての感想でした。サーバって、本当に奥が深いですね。

Building a More Efficient Ruby Interpreter

Ruby Enterprise Edition の中について、Google TechTalk で公開されています。

約36分ほどと、Google TechTalk の中では短い部類に入りますので、興味のある人はチェックしてみるとよいでしょう。

# wordpress 2.9 では、YouTube などの動画サイトの URL を張り付けるだけで動画をブログに貼ることができるので、とても便利ですね。

facter 一覧

facter バージョン 1.5.7(現時点での最新版)で、ソースコードレベルから一覧をまとめてみます。

architecture: ハードウェアの種類です。hardwaremodel の値を利用して、ハードウェアの種類を取得します(i386 or x86_64 or amd64)

Cfkey: /usr/local/etc/cfkey.pub の値です(おそらく、CfEngine  のときに使われていた値だと思われます)

domain: ドメイン名です。hostname の値から取得しています。

ec2: EC2 のシンボル名(ID) です。

facterversion: Facter のバージョンです。

fqdn: FQDN(ホスト名.ドメイン名)です。

hardwareisa: プロセッサーの種類です。uname -p の出力です。

hardwaremodel: ハードウェアの種類です。uname -m の出力です。

hostname: ホスト名です。hostname コマンドの出力です。

id: id です。whoami コマンドの出力です。interfaces: NIC の種類です。eth0,eth1 のように取得できます。

ipaddress: ip アドレスです。ifconfig コマンドの出力から 127. で始まる以外の最初の IP アドレスを取得します。その他の IP アドレスは、「ipaddress_NIC」で取得できます。

iphostnumber: OSX のみ有効な値で、MAC アドレスを取得しているようですが具体的な値は不明です。

kernelmajversion: カーネルのメジャーバージョンです。例えば、「2.6」のような値になります。

kernel: カーネルの種類です。uname -s の出力です。

kernelrelease: カーネルのバージョン+リリース番号です。uname -r の出力です。

kernelversion: カーネルのバージョンです。kernelrelease の – の前の値を取得しています。

lsbmajdistrelease: ディストリビューションのメジャーバージョンです。

lsb: LSB(Linux Standard Base) の値です。

macaddress: MAC アドレスです。

macosx: Mac OS X のシステムプロファイラから取得できる値です。具体的な値は不明です。

manufacture: ハードウェアの製造業者です。dmidecode コマンドから Manufacturer: の値を取得しています。

memoryfree: メモリと空き容量です。

memorysize: メモリのサイズです。

netmask: サブネットマスク値です。各 NIC ごとのサブネットマスク値は「netmask_NIC」で取得できます。

network: ネットワークアドレスです。各 NIC ごとのネットワークアドレスは「network_NIC」で取得できます。

operatingsystem: オペレーティングシステムの種類です。/etc にオペレーティングシステムのリリース情報から判断しています。

operatingsystemrelease: オペレーティングシステムのバージョンです。

path: 環境変数 PATH の値です。

physicalprocessorcount: 物理的な CPU の数です。/proc/cpuinfo から算出しています。

processor: プロセッサの種類です。具体的な値は不明です。

productname: 機種名です。

ps: ps コマンドです。Linux だと、ps -ef となっておかしい値になります。

puppetversion: インストールされている Puppet  クライアントのバージョンです。

rubysitedir: site_ruby の場所です。

rubyversion: ruby のバージョンです。

selinux: SELinux の状態です。無効なときは、false になります。

sshdsakey/sshrsakey: SSH のホスト鍵です。

swapfree: スワップの空き容量です。

swapfize: スワップのサイズです。

timezone: システムのタイムゾーンです。

uniqueid: 一意な ID です。hostid コマンドの出力です。

uptime: システムの起動時間です。/proc/uptime の内容です。

uptime_days: 起動日数です。

uptime_hours: 起動時間数です。

uptime_seconds: 起動秒数です。

virtual: 仮想環境の種類です。仮想環境ではないときは「false」になります。Xen、OpenVZ、VMware に対応しています。

こうしてみると、facter ではかなりの値を取得できるようになっています。

facter 変数だと、puppet 以外にもシェルスクリプトや ruby プログラムから簡単に参照できるので重宝しそうです。

techlifecookpad -puppet- フィードバック編

先日、techlifecookpad -puppet- のフィードバック編です、とはいっても一点だけです。

資料の中で、次のようなカスタム facter を定義していましたが、なんと facter 1.5.7 には manufacture 変数が用意されていました。

if $bios_vendor == “dXXX Inc.” {

include dell

}

用意されている manufacture を使うと、次のようにまったく同じにできます。

if $manufacture == “dXXX Inc.” {

include dell

}

facter の該当のソースコードを読むと、僕が作ったカスタム facter と dmidecode(8) コマンドを使っていたので処理的にはまったく同じです。

ただし、仮想環境上の場合、manufacture 変数すら表示されないので要注意しましょう。

とはいっても上のコマンドはまったく問題なくとおりますが、facter コマンドで facter 変数一覧の中では表示されないので気がつかない可能性もあるという意味です。

デフォルトに組み込まれていることは知らなかったのが恥ずかしい限りなので、次回は facter 一覧をまとめてみます。

koan を使ってコマンド一発で Xen DomU をインストールする

koan を使って、コマンド一発で Xen DomU をインストールする方法を紹介します。

1. cobbler のサーバで DomU として使う system を作成する

$ sudo cobbler system add –name=<仮想マシン名> –profile=<プロファイル名> –virt-type=xenpv –virt-cpus=1 –virt-ram=2048 –virt-file-size=200 –virt-path=/var/lib/xen/images/<仮想マシン名>.img –virt-bridge=xenbr0

上の例では、準仮想化ドメインとして CPU 数 1、搭載メモリ容量 2048MB、ハードディスク容量 200GB、仮想ブリッジを xenbr0 とした仮想マシンを構築するという意味になる。

2. Dom0 上に koan をインストールする

$ sudo yum instal koan

3. koan コマンドを使ってコマンド一発で仮想マシンをインストールする

$ sudo koan –server= –system=<仮想マシン名> –virt –nogfx –virt-path=/var/lib/xen/images/<仮想マシン名>.img

なぜか system に virt-path が設定されている状態でも koan コマンドに virt-path を指定しないとエラーでインストールできなかった。

4. DomU をインストール後、DomU が自動的にシャットダウンしてしまうので、DomU を起動する

$ sudo virsh start <仮想マシン名>

koan コマンドのパラメータは、次のとおり。

koan –server=hostname [–list=type] [–virt|–replace-self|–display]
[–profile=name] [–system=name] [–image=name] [–add-reinstall-entry]
[–virt-name=name] [–virt-path=path] [–virt-type=type] [–nogfx]
[–static-interface=name] [–kexec]

–virt-name 作成する仮想マシンの名前(省略した場合はプロファイル名が使われる)
–virt-type 作成する仮想マシンの種類(xenpv or xenfv or qemu or vmware)
–virt-ram メモリ容量(MB 単位)
–virt-bridge ブリッジデバイス名
–virt-path 仮想マシンファイルを保存する場所(パーティション、ディレクトリ、LVM ボリュームの設定が可能)
–no-gfx VNC グラフィックスを使用しない(Xen のみ)

koan 超便利です。

# 先日の techlife@cookpad の内容は、これを応用した Xen DomU の自動インストールの仕組みです

Nagios NRPE プラグインを作成する方法

Nagios で、独自に任意の方法で自分のサービスを監視したい場合、NRPE プラグインを作成すると便利です。

僕は、基本的にシェルスクリプトでがんばって作成しています。次のようなシェルスクリプトの雛型を準備しています。

#!/bin/sh

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

echo “Status is OK”

exit $STATE_OK

exit する前に echo すれば、その情報を Nagios の管理画面の Status Information で確認することができます。

この雛型シェルスクリプトを使って、DELL 製サーバのハードウェア RAID の確認とその BBU の状態を監視しているスクリプトを作成しました。

Puppet によるインフラ管理入門

先日のクックパッド LT で公開したのですが、前回の Velocity で行われた Puppet 作者の Luke さんによる Puppet ワークショップの日本語版を許可いただいて翻訳しました。

実はかなり前(Velocity が終わった直後)に翻訳したものなのですが、すっかり公開するのも忘れていたので、LT にあわせて公開しました。

Puppet によるインフラ管理入門

原本は、次のワークショップです。

Introduction to Managed Infrastructure with Puppet: Velocity 2009 – O’Reilly Conferences, June 22 – 24, 2009, San Jose, CA

このワークショップでは、Puppet を実際に触りながら Puppet  の理解を深めていくという内容のワークショップです。

とても Puppet 入門に適している内容だと思いますので、ぜひ会社の中などで Puppet 入門勉強会の資料として使ってもらえばうれしいです!

僕も自分の会社で Puppet 入門勉強会を開催して、そこで資料として使いました。

monit で logrotate する

monit はとても便利でかなせないツールになっている今日この頃ですが、monit にはデフォルトで logrotate するスクリプトがついていません。

monit の logfile を設定すると、monit でチェックしている対象のプロセスを再起動したときなどにログに情報がたくさん出力されているので、logrotate しておいたほうがいいでしょう。

monit の logfile を /var/log/monit に設定した場合は、次のような内容で /etc/logrotate.d/monit を作成します。

/var/log/monit {
missingok
notifempty
size 100k
create 0644 root root
postrotate
/bin/kill -HUP `cat /var/run/monit.pid 2>/dev/null` 2> /dev/null || true
endscript
}

  • 1
  • 2