livedoorポータルサイト等のインフラを担当している片野です。
今回は若干いまさら感がありますが、弊社にて運用している自作サーバをご紹介します。
（検証機以外は弊社内で組み立ててないので、正確には自作してないんですがｗ）

■背景

去年は特に自作サーバが盛り上がっていましたし、早い段階で「うちも作るか!」という展開はあったんですが、弊社では以下のような事情もあり、着手していませんでした。

・自社データセンタでの運用なため、その他顧客と運用が大きく変わるようなサーバを投入すると運用が煩雑になる。
・ポータルのサービスだけでも3000台近いサーバがあり、規模的にも運用に手がかかるサーバを入れるのは非現実的。
・ボリュームメリットが出せるため、コスト面での自作メリットはそれほど大きくない。
・そもそも自作で間に合う台数じゃないｗ

（人的な）運用コストや調達コスト面ではあまりメリットがないのですが、ある事情により、年末辺りから自作サーバを再検討していました。

その事情とは…


ラックの電力が足りない


まあ、どこの企業様も悩みは同じだと思うのですが、1ラック辺りに詰め込むメモリ量やストレージ量で考えると、サーバベンダ機ではとにかく電力がネックになります。

というわけで、以下のような条件で設計を進めました。

・サーバ用CPUは電力が高い（値段も）。省電力なCPUを使いたい。
・仮想化して効率良く使うにはメモリ16GBは欲しい。
・安く容量を増やせるストレージが欲しい。→3.5インチが有利
・ホットスワップは必須。
・電力的に詰め込むのが不可能なので、1Uハーフにはこだわらない。
・蓋なしのケースはダメ。ラックに固定できること。燃えそうだったり、感電しそうなケースももちろんダメｗ

■特徴

下記サーバが弊社で数ヶ月前から運用している自作（パーツの）サーバです。


※2010年5月現在で100台ほど稼働中。


今投入しているスペックは、基本的に以下のような構成です。

・CPU：Athlon II X4 605e
・Mem：16GB
・HDD：250GB（RAID1）

詳細は写真から判断頂ければ。
全然特殊なパーツはないですが。


性能と電力で言うとAM3が非常に優秀なので、今は省電力モデルのAthlonやPhenomを使ってます。
（省電力モデルのXeonもあるけど高すぎたので）　

下表は弊社でメインに使っているサーバベンダ機との比較結果です。

サーバ	処理リクエスト数	負荷時消費電力	処理リクエスト数/Watt
X3250(Core2Duo x1, 8GB)	355 req/s	110 W	3.23 req/W
X4150(Core2Quad x2, 24GB)	962 req/s	230 W	4.18 req/W
自作サーバ(AthlonII X4 605e x1, 16GB)	495 req/s	91 W	5.44 req/W
自作サーバ(PhenomII X4 945 x1, 16GB)	662 req/s	115 W	5.76 req/W

Xeonと比較すると電力的にかなり有利なのが分かると思います。


ケースは2Uハーフです。
2Uハーフを選択している理由としては、下記のような点です。

・パーツ選定の制約が少なく、ケースの使い回しが効く。
・3.5インチHDDが使えるので、容量単価が有利。

1Uハーフでないとマウントできないような台数は電力的に入らないため、パーツ選定の自由度を優先して敢えて2Uハーフにしています。

また、既存サーバのラックレールに乗るように微調整がしてあります。
（ラックマウントしやすい形にすることでオペさんに怒られないライフハックｗ）

大量にあるラックレールを使い回せてエコです!

■今後の課題

・Atom＋2TBHDDでストレージサーバ構築

検証はしていますが、まだ投入はしてません。
ストレージは増加する一方ですし、コスト削減は至上命題ですね。


・Phenom II X6の検証

まだ発売されていませんが、95W版の6CorePhenomは電力的に優秀そうなので気になってます。
より電力的に美味しいCPUへ随時交換して行きたいので、省電力Xeonも含め、色々と検証はしています。


運用面での課題はありますが、サーバベンダ機にはないメリットもありますし、何よりパーツ選定は楽しいので（笑）
今後も適材適所で使い分けていく予定です。

どうも、はじめまして。DATAHOTELサービスでフルマネージドホスティングのオペレータをやらせて頂いておりますDO(ドゥー)といいます。

テックブログなるものではございますが、私が技術を語るなどとは... オペレータとして培ったこれまでの経験から、「まぁ難なく」という範囲内でひとつこの場をお借りして少しだけ語らせて頂ければ、と思っております。

マネージメント

「まぁ難なく」と言ったところで、まず私の業務内容の範囲がどれだけあるのかお話ししないといけませんよね。業務内容をひと言で言いますと、サーバのマネージメント。単にマネージメントと言いましても、その分野は多岐に亘りサーバのセットアップから始まり、プラットフォームやアプリケーションの構築やパラメータの調整、顧客の運用を手助けするための提案、また安定運用をご提供する為の監視、障害発生時の復旧作業など、様々な分野のマネージメントを行っているのです。

また障害発生時の復旧作業ひとつにおいても、障害発生箇所によってその対応内容は変わってきます。今回は障害がハードウェアで発生した際の復旧作業内容について少しだけお話させて頂きたいと思います。

Standard Server (標準機)

まずはハードウェアで大本となるサーバについてご説明を。一般の方などは見たこともなければ「サーバってビールの？」といった感覚...にはならないと思いますが、実際どの様なものかはわからないと思いますのでライブドアで使用しているサーバの中でも最もスタンダードな2機種のサーバを簡単にご紹介したいと思います。

<< IBM製 System x 3250 M2 >>



IBMと聞いてピンときた方も中にはいらっしゃるのではないでしょうか。そうです。ノートPCのThinkPadで有名なあのIBM社製のサーバです。Webサーバとしてもメールサーバとしても、もちろんDBサーバとしても使用可能なとても使い勝手の良い機種の一つです。

<< サン･マイクロシステムズ製 Sun Fire X4150 >>

こちらはサン･マイクロシステムズ社製のサーバ。前面にある8つの小窓がHDD搭載ドライブで、IBM社製のサーバよりも一段階スペックが高い機種となります。スタイリッシュなボディが格好良く、個人的にはxseries3250 M2よりこちらの方が好みだったりします。ただし総重量がかなり重いのが難点... 2009年後期の時点で、ライブドアデータホテルで一番推奨している機器になります。

どちらのサーバも長細く平たい形をしていますが、データセンターに設置してあるスタンダードなサーバは、大抵この様な形をしています。もちろん何倍もの厚さがあるサーバや皆さんがご自宅で使用しているデスクトップ型PCをサーバとして使用することもあります。

障害のカギ

さて、話は戻りましてサーバの障害について。やはり｢形あるものいつか壊れる」わけでありまして、時にうんともすんとも言わなくなる場合があります。そんな時はもちろんサービスは行えなくなっており、早急な復旧対応が必要とされます。

どこに問題が発生しているのか？
メモリなのかHDDなのか、それとも機器本体の問題なのか？
はたまたHDDと基盤を繋ぐコードの問題なのか・・・？

早急な対応を求められる私たちにとっては、この切り分けがカギとなります。

サーバからの...

そしてそのカギを握るのが、サーバから発せられたダイイングメッセージ。サーバがダウンする寸前に残してくれているこのメッセージはかなり重要で原因の切り分けには必要不可欠なものになります。例えば以下のメッセージ。


何やら英語と記号の羅列の様に見えるこのメッセージですが、内容を良く見ますと『hard error reading』の文言が。訳さなくとも何となく「読めない」と言う意味であることがわかりますよね。サーバで読み書きが行われているのはHDDになりますので、この場合はHDD障害であることが推測されます。

同様のメッセージで

こんなメッセージが出力されていることもあります。先ほどのメッセージより読解が困難ですが、"I/O"の意味がわかってしまえば一目瞭然。「I」はInput、「O」はOutputであり入出力を意味しています。そして「SCSI」というのがそもそもHDDの種類を表していますので、こちらもHDD関連の障害と推測されます。

HDD障害以外でのハードウェア障害を示すメッセージではこの様なものもあります。

『scsi』や『dead』と言った文言から推測するとHDD周りかと思いがちですが、こちらは xseries3250 M2独特のハードウェア不具合であり、現在IBM社による原因解明が進められています。ライブドアではエンジニアの検証により暫定対応としてファームウェアのアップデートで回避可能であることが判明していますが、この様な事態が発生しても、障害時には早急な復旧対応が必要とされます。

この他にも、メモリの障害であったりkernelやRAIDカードの不具合であったり、またアプリケーションによるswap領域の枯渇であったりと、様々なダイイングメッセージが出力されています。と言っても、発生する障害全てにおいて都合よくエラーメッセージが出力されている、ワケではないのですが...。

蘇生

何かしらのメッセージが残されていれば、例えばHDDエラーであればHDD交換を、メモリの不具合や認識不良であったら、メモリやサーバ自体の物理交換を、xseries3250 M2の様な独特の障害であれば、それに見合った対応方法を、と言うように、その障害に応じた蘇生法を実施しなくてはなりません。

時にはメッセージの出力が全くなく、切り分けや対応に時間を要してしまう場合もありますが、障害発生時は切り分けから完全復旧まで、より短い時間で最小限の被害に抑えられるよう最善の復旧対応を行う、といったマネージメントを行っています。

毎日がマネージメント

今回はハードウェア障害時のマネージメントについてお話しましたが、障害ひとつ取っても、アプリケーション周りの障害であったり、ネットワーク回線の障害であったりと様々な障害と向き合わなければなりません。また先にも述べているように、日々私たちは様々なマネージメントサービスを行っており顧客の求めるサービスレベルに一歩でも近づける様にマネージメントとは？と、自問自答しながら業務に励んでいます。サーバマネージメントに少しでも興味がある方は、是非「livedoor DATAHOTEL」サービスで一緒に頭を悩ませてみませんか？　また私たちオペレータに運用サービスを任せてみたい、というお客様はどしどしお問合せ頂けます様お願い致します。

データホテルへのお問合せはコチラ↓


他にもこんな人が働いています!!
スタッフの声
DATAHOTELのスタッフ紹介

お疲れ様です、スエヒロです。

先日発売されました、弊社技術陣が執筆した「4Gbpsを超えるWebサービス構築術」、お手に取って頂けたでしょうか？

ウェブサービスの負荷対策、分散技術など、実用的な話が盛りだくさんの本書ですが、本日は実際に稼働しているサービスのサーバスケールアウト方法を、弊社サービス「livedoor ニュース」を例にしてご紹介したいとおもいます。

0. 問題点の把握

2003年オープンしました「livedoor ニュース」ですが、当時はアクセス数、データ量も少なかったため、サーバ1台で運用していました。


静的な画像やcss、javascriptへのリクエストを処理するapache（80ポート）と、動的コンテンツへのリクエストを処理するmodperl組み込みのapache（8080ポート）を切り分け、mod_rewriteでリバースプロキシし、リクエストをながしています。リバースプロキシに関しては「mod_rewrite を利用したリバースプロキシ環境の作り方」こちらを参考にどうぞ。

しかしこの構成ですが、ウェブサービスとして運用する上で、以下のような問題点があります。

1. ウェブサーバ、DBサーバの冗長性
2. 各サービスの負荷に対するスケーラビリティ
3. データの増加に対するスケーラビリティ
4. データ自体の冗長性

「livedoor ニュース」ではサービス規模や負荷状況を考慮しつつ、以下のような内容で冗長性とスケールアウトしやすい環境を構築していきました。

1. 各サービスの分離

まずは各サービスをサーバごとに起動するよう分離します。下記の通り、静的ファイルを扱うwww01.apache、動的リクエストを処理するapp01.modperl、データベースのdbm.mysqlをそれぞれサーバに分離します。


memcachedなどのキャッシュアプリケーションを、比較的メモリに余裕のあるサーバ（この場合www.apache）などで起動して運用するなどの選択肢も出てきます。

2. ウェブサーバの冗長化とスケーラビリティ

次にボトルネックになりやすいのが、動的コンテンツを返すmodperlです。アクセスの集中により高負荷になったり、ソケット数が不足するようなケースです。apache、modperlを冗長化しつつ、容易にスケールアウトできるように以下のような構成に変更します。


wwwNNの部分はロードバランシングを行いリクエストを振り分ける形になります。スケールアウトさせる場合は、wwwNN、apacheとappNN.modperlを増設させる形になります。

またapache2.1から利用できるmod_proxy_balancerというapacheモジュールのバランサを利用することでwwwサーバとappサーバを1:1ではなく、1:多に構成することができます。


この構成は、www系の負荷が高い場合、modperl系の負荷が高い場合、それぞれにスケールアウトが可能ですので、より柔軟に対応できます。「livedoor ニュース」ではwww系の負荷はそれほど高くないので、サーバ1台にapache、modperlを起動し、apache（80） -> modperl（8080）でlocalhostにリバースプロキシしたものを、複数台並べてバランシングしています。

3. DBサーバの冗長化とスケーラビリティ

DBまわりの構成を変更します。更新、参照の負荷分散、データ自体の増加に伴うスケーラビリティと考慮する要素が多いDBサーバまわりですが、「livedoor ニュース」はCGM系のコンテンツに比べるとDBサーバの利用に以下のような特徴があります。

- ユーザの入力によるデータの増加が比較的少ない
- 更新系のクエリより参照系のクエリが圧倒的に多い

ということで、参照系へのスケーラビリティを考慮した以下のような構成になっています。


mysqlのレプリケーション機能を利用した、シングルマスタマルチスレーブ構成になっています。参照系の負荷があがりスケールアウトさせる場合は、スレーブサーバを追加する作業となります。
マスターが障害を起こして復旧が難しい場合は、スレーブサーバのマスター昇格という対応になります。

また「livedoor ニュース」では一部アクセス集計等のロギングをDBを利用して実装しています。必然的に更新系のクエリが多くなりますが、他のテーブルとのJOINの必要がない機能なので、ロギングまわりのテーブルのみ別サーバのmysqlに移しています。

4. 画像サーバの分離

「livedoor ニュース」では記事の写真があるため、画像ストレージの実装も行っています。こちらもCGM系のコンテンツでは、ストレージ領域のクラスタリング、負荷分散など注意するポイントが多いですが、「livedoor ニュース」では比較的緩やかにストレージの利用領域が増加するので、アップロードされた記事画像を各サーバにコピー、同期してウェブサーバ側でバランシングを行っています。


スケールアウトする場合はサーバを追加して画像の同期、バランシングの対象に追加という作業になります。さらに画像の総量が増加した場合は、ファイルごとにサーブさせるサーバを変更するなどの実装が必要です。

この方法とは別に、ストレージ利用を前提に、ディスクのみを増強した低スペックのサーバを用意して画像をサーブ、その前にsquidをおいてリクエストを処理といった方法も考えられるかと思います。

5. 検索エンジンの分離

全文検索も実装としては比較的ボリュームの大きい機能ですので分離します。「livedoor ニュース」では検索エンジンにSUFARY、Torittonと利用してきましたが、現在は「Kanade」という弊社で実装された検索エンジン利用しています。別サーバで「Kanade」を起動し、httpごしにデータをやり取りしています。


検索の処理が重くなってきた場合、スケールアウトは検索サーバ側の増強を行うだけですので「livedoor ニュース」本体側のサーバには影響はでません。

6. 仮想化

上記1から5のようなサーバの増強プロセスで運用してきましたが、サーバ台数がある程度の規模になってくると、サーバ台数の増加に伴う運用負荷の上昇、サーバリソースの一層の効率的利用といった問題がでてきます。そこで「livedoor ニュース」ではアプケーションサーバをxenによる仮想化を行なっています。仮想化による利点は、

- サーバの増設削減に伴う作業コストの低下
サーバを増やす場合は、セットアップ済みのイメージをコピーしてインスタンスを起動。

- サーバリソースの効率的利用
1サーバで複数のインスタンスを起動。CPU、メモリを各サービスで効率的に利用。

- 物理サーバの削減
上記をもとにした物理サーバの削減、ラックスペースの確保。

といったものがあります。

上記のような仮想化、冗長化、スケーラビリティを含めた、サービスイン時の最小構成は以下のようなものが考えられます。



以上のような内容で「livedoor ニュース」は運用されています。
実際にはスケールアウトだけでなくサーバ1台あたりのスペックアップも同時に行いつつサーバの増減を適宜調整しています。

また以下のような、コンテンツの内容、規模的に対応していない実装（する必要がない）もあります。

- データベースのマルチマスタ化（readが圧倒的に多い）
- 画像の分散ストレージ（画像の総容量がそもそも少ない）
- キューイング（非同期が必須なアプリケーションの処理がすくない）

このあたりはオーバスペックな実装にならないように簡単な構成で済ましている部分もあります。

ということで、サーバのスケールアウトについて話してきましたが、このような作業は通常の運用業務に比べると、そもそも作業する機会が少ないので、なかなかノウハウが溜まりにくく、ナレッジも共有しにくい箇所かと思います。上記あたりの話も含めてウェブサービスの構築術のイロハをもっと知りたいという方はぜひ、

4Gbpsを超えるWebサービス構築術
著者：伊勢 幸一
販売元：ソフトバンククリエイティブ
発売日：2009-08-21
クチコミを見る


こちらをご覧下さい。
#本当に色々書いてあるので参考になると思います。

以上、宜しくお願い致します。

自己紹介

私はライブドア（以下LD）で働いております安保サニーと申します。勤務地はLDのデータセンターこと「DATAHOTEL」です。前職はウェブディレクターを2年程やっており、Linuxの黒い画面て何？というレベルから、かれこれ3年が経とうとしてます。つまり技術的には、まだ若輩者です。
livedoorのメインサービスとも言える、「ポータル用サーバ」を、この2年間で1000台以上の台数を作成してきた私が、その流れを紹介したいと思います。
(注）基本的には流れ作業ですｗ

月に何台？

Alexaランキングでもトップ100に入る程のトラフィックを支えるサーバですが、大体ひと月にセットアップするサーバは40〜50台くらいです。ただし毎月増え続けているわけではなく、リプレースや仮想化による圧縮などがあるので、平均すると常に3000台くらいのサーバが、サービスを支えています。

標準的なサーバおよびOS

現在のポータルサーバの主流OSはCentOSです。新規にセットアップされるものの99%が、このOSになります。yumのパッケージ管理がすごく便利です。メモリをいっぱい使うために64bitOSを採用しています。
また筐体に関してはIBM社の「x3250」が主流です。以前は同社の「x306」もしくは、東芝社の「MAGNIA 2200R」でした。「x3250」になってから、DVDによるインストールが可能になり、OSインストールの時間がえらく短縮されました♪
しかし、IBM社のサーバは基本的に起動が遅くイライラします...

ラッキンング、ケーブリング

セットアップオーダーが決まれば筐体とラックがアサインされて、ラッキングおよびケーブリングを開始します。ちなみに1回のオーダー数は1〜40台とさまざま。ケーブリングは美しさが命！ たまに樹海のようなラックや、マングローブ化したラックがあり非常に危険です。またコンソールを繋ぎやすくするため、モニタの接続部分と、USBに引っかからないようにケーブリングを行うのがポイントです。セットアップの台数に限らず、キレイになるようがむばります。（実は、台数が多いほうがやり易いんです。）

スペシャルディスク（DVD）にてインストール

某先輩が作成してくれた「CentOSスペシャルインストールDVD」にてインストール開始です。この「SP DVD」ですが『毎回設定が同じ部分は、かっ飛ばしてしまう』というシロモノ。キックスタートを利用していると思われる。

「通常のインストール」
http://tibbar.dip.jp/~rabbit/centos/install/index.html
みたいな手順でいれてきます。（長いので横着しました）

「SP DVDでのインストール」
+ パーティションを切る
+ IPアドレス、ネットマスクを入力
+ デフォルトゲートウェイとDNSサーバを入力
+ ホストネームを入力

以上簡単DAZE！あとは10分弱まつだけ！

アプリケーションのインストール

こちらもかなりの自動化がされています。 cvsより必要なRPMパッケージをインストールスクリプトをダウンロードして実行するだけで、以下のようなアプリがイイ感じにインストールされます。

- MTA （qmail + popmail + ezmlm）
- Webサーバ（apache + modSSL）
- DNS （djbdns + dnscache）
- DB （mySQL）
- その他必要に応じてphpとかいっぱい（企業秘密）

てな感じでOSだけいれてしまえばあとはらくちんです。

大変なところ

なんでもかんでもうまくいくわけではなく、最初からHDDが壊れていたり、筐体がCPUを誤認識していたり、DVDが傷ついていてインストールできなかったり、GRUBがうまく入っていなくて、起動してこなかったり←これが一番多い。最初のうちは原因が全然わからないので、きつかった...。
サーバルームではネット環境が無いので、ググることもできず...

そして旅立ち

丸1日セットアップにつきっきりでいいっていうのであれば100台くらいいける、すばらしいこの工程によりそうこうして子供達は巣立っていきます。

そして一言、「いいサービスになってがんばれよ！」

こんにちは、栗原です。

今回はlivedoor Blog モバイルのサーバ構成についてご紹介しようと思います。

日本でも最大規模のブログサービスのモバイルサイトがどのようなサーバ構成で稼動しているのか、またその構成を構築していく上で苦労した点や今後どのようにして行こうと考えているかについても説明できたらと思います。


まずは現在のlivedoor Blog モバイルの内部構成について簡単に説明したいと思います。
livedoor Blog モバイルでは、大きく分けて5種類のサーバ群が稼動しています。

ユーザが携帯からブログを閲覧した際にページを生成してレスポンスを返すサーバ群になります。現状はApache(リバースプロキシ)とApache + mod_perl(アプリケーション)を1台のサーバに同居させた形で稼動しており、台数は全部で66台になります。

携帯のサービスではキャリアや端末ごとに画像サイズや形式を変換して表示するため、ユーザがアップした1つの画像につき数種類の画像を生成してやる必要があります。その画像変換処理をするサーバが、この画像変換サーバになります。

現在は、ユーザのリクエストに応じてリアルタイムに画像を変換し(独自Apacheモジュールにて変換)、一度変換した画像は一定期間キャッシュする(memcachedを使用)構成になっています。画像変換サーバはApache + modperlで稼動しており、その台数は16台あります。

上記の画像変換サーバで生成された画像をキャッシュすると共にユーザが閲覧する際にレスポンスを返すサーバが、この画像キャッシュサーバになります。画像キャッシュサーバは、Apache(リバースプロキシ)とbalanceと呼ばれるソフトウェアロードバランサを同居させた形で稼動しています。

このサーバでは、まずユーザからの画像のリクエストをApacheが受け、そこからbalanceを使って前述の後ろに控えている16台の画像変換サーバにメッシュ状に変換を依頼するリクエストの投げています。こちらは合計4台のサーバが稼動しています。

livedoor Blogを使用したことのあるユーザはご存知かと思いますが、livedoor Blog(PCサイト側)ではユーザがブログを書く際にその記事のページなどを静的に再構築する処理があり、その再構築処理をこのリビルドサーバで行なっています。現在は変換依頼をキューとして貯めるためのMySQLと、実際に再構築処理をするためのdaemon(Perlで書かれた独自プログラム)が稼動しています。こちらは合計4台で稼動しています。

ユーザがモブログをした際にメールを受けとり、記事投稿処理をするためのサーバがモブログサーバになります。こちらはMTAとしてqmailが稼動しており、Perlで書かれたプログラムでメールを処理しています。こちらは現在8台で稼動しています。


さて、サーバ構成とその台数について簡単にご紹介しましたが、実際にこの構成でどのくらいのリクエストをさばいているのかが気になるところだと思いますが、その内訳は以下のようになっています。

ユーザブログ及び管理画面のPV：約1200万PV/日
画像閲覧PV：約300万PV/日
モブログ数：約5万通/日

この内訳をみて皆さんはどう感じたでしょうか。現在のlivedoor Blogモバイルでは、画像などのファイル以外、ほぼすべてのページを動的に生成しているためサーバの台数に対する処理数が少ないように感じるかもしれません。しかし、それにはわけがあります。

モバイルサービスではページを閲覧しているユーザの携帯端末やキャリアによって広告やHTMLを適宜出し分ける必要があり、リクエスト毎にページを動的に生成する必要があります。そのためリクエストは必ずアプリケーションサーバ(この場合mod_perl)での処理が必要となります。どうしてもその部分では、PCサイトなどに見られる静的ファイルを前段のリバースプロキシサーバなどでキャッシュして負荷分散をすることができません。

今後は、この部分をmod_perlよりも前のレイヤーであるApache(リバースプロキシ)側でApacheモジュールとして実装するなどして、負荷を分散することも検討しているところです。


今まで運用をしてきて、最も困ったのはモブログです。

当初モブログのサーバでは、ユーザからの投稿メールが来た際リアルタイムにデータベースにデータをインサートし、リアルタイムに再構築(PC側の静的ファイル)をする形式をとっていました。

この方法ですとメールが大量に送られてくる時間帯は必然的にサーバが重くなり、それにひきづられる形で記事データをデータベースに格納する処理や再構築の処理も遅くなります。結果として携帯用のページも再構築して生成されるPC用のページも閲覧できるようになるまで、かなりの時間を要していました。

モブログをするユーザは、モブログを送った後すぐに携帯でそのモブログした記事が投稿されているかを確認する傾向にあるようです。そこで重い処理はキューに入れて後で処理をするという方法を用いて、最低限携帯用のページだけは見られるようするという施策を取っています。

これによりPCサイトのページの再構築の処理は一旦キューに入れておき、記事データだけは先にデータベースに入れておくことで動的な携帯用のページだけは、すぐに見えるようにしてあります。そしてサーバのリソースに余裕がでてきたところで、順次PCサイトのページの再構築を行なっています。

今後は再構築する処理を別サーバにするなども検討しています。


今後行いたいと考えていることはいくつかありますが、その中でもユーザ的にも、システム的にもインパクトのあるものをいくつか上げると

• 画像のインライン表示
• デコメでのモブログ
• 全キャリアでの絵文字対応
• オリジナルデザインのアップロード
• 静的コンテンツ化

などを予定しています。
すべてをすぐに対応ということは難しいかもしれませんが、これらの対応を徐々にしていきたいと考えておりますので、今後ともlivedoor Blog モバイルをよろしくお願い致します。