[本] 4Gbpsを超えるWebサービス構築術



これは買っておかないとイカンだろう、と思いまして購入致しました。


■Chapter1 Webサービスの概要と要素技術
1-1 コンシューマ向けWebサービス
1-2 ブログ
1-3 検索
1-4 写真共有
1-5 ソーシャルブックマーク(SBM)
1-6 動画、音声配信
1-7 SNS
1-8 Webサービスの開発と運用
■Chapter2 キューイング
2-1 キューイングとは
2-2 キューイングシステム
■Chapter3 DBキャッシング
3-1 高負荷下で起こりうる問題点
3-2 DBキャッシングシステム
■Chapter4 HTMLキャッシング
4-1 データキャッシングの仕組み
4-2 キャッシングツール
4-3 リバースプロキシ
4-4 Squid Cache
4-5 livedoorブログシステムでの実装例
■Chapter5 検索サービスの技術
5-1 検索エンジンの仕組み
5-2 オープンソースの全文検索システム
5-3 OrchestraとKanade
5-4 ライブドアでの利用例
■Chapter6 入出力パフォーマンス
6-1 入力のパフォーマンス
6-2 出力のパフォーマンス
6-3 キャッシュの利用と管理への考察
■Chapter7 分散ストレージ
7-1 Webサービスにおけるストレージ戦略
7-2 分散ストレージ
■Chapter8 モバイルの技術
8-1 日本のモバイル事情
8-2 テンプレート
8-3 画像
8-4 絵文字
8-5 メール配信
8-6 モバイルにおけるそのほかの技術
■Chapter9 ネットワークを取り巻く技術
9-1 ネットワークの運用
9-2 ルーティングオペレーション
9-3 L3スイッチとVLAN
9-4 トラフィックエンジニアリング
9-5 ネットワーク運用の問題点と課題
■Chapter10 Webサービスの性能評価
10-1 Webサービスの性能
10-2 RDBMSのチューニング
10-3 アプリケーション
10-4 運用時の性能監視

#目次はdankogai氏のページからコピペ(^-^;)

これはすばらしい。
というのは、やはり扱っているレイヤが非常に広い所が評価できる。
とりあえず、Perlが嫌いな人間も、Webアプリを作っているなら一度読め、というぐらいのものである。

特にChap6.7.9.10は一度目を通しておくべき。


本の紹介はそれぐらいにして、おじいさんの感想を。

Chap1.Webサービスの概要と要素技術


よく使っているモノのうち、Webメールがないです(T-T;)
若干語っておくと、WebメールはWebサービスの中ではかなり初期から存在してます。
どのプロバイダも、ほぼ標準装備してますね。

一昔前は、大体ベタなHTMLで作成されていたのですが、少し前はFlashで作られたり、Ajaxを活用して作られたりしてます。
特性なんですが、ディスク使用容量はかなり大きいです。
しかも、年々すごい勢いで使用量が増えていくというシロモノ。
一人で、XGBとかいう世界に突入してもおかしくない・・・

かなり頭が痛い所です。
外部公開しているわけではないので、更新系ばっかりに負荷がかかるという点がさらに悲しい(T-T;)

Chap2. キューイング


この章をみて、買う事を決意しました(^-^;)
というのは、あまりキューイングについて実戦に即した事をかいているのは見かけなかったからですが。

Perlでは、Gearman、TheSchwartz、Gungho が有名ですが、最近はQ4Mも早いと評判。

あれ?
livedoor readerって、Q4Mじゃなかったでしたっけ??
おじいさんの記憶違いかな。昨年のshibuya.pmでmalaさんがしゃべっていたような。



まあ、誌面の都合上、GearmanとTheSchwartzなんでしょうね。
ちなみに、Q4Mは・・・サイボウズの方が作成されてるはずですが。

 http://developer.cybozu.co.jp/kazuho/

Chap3.DBキャッシング


わはは。memcached最強!みたいな感じですねえ。

Chap4.HTMLキャッシング


この辺りを間違えると、とんでもない事が発生します。
まじめに大変です。
とりあえず、静的なコンテンツは基本リバースプロキシで追い返さないと、やってられないです。
さらに、この辺をBIG-IPなんかで散らさないと、冗長性が・・・

Chap5.検索サービスの技術


まあ、まじめな話数百万レコード級の日本語をSQLのLIKE演算子で検索しちゃうと、死ぬって事はわかりきってるはなしで。
やったことがありますが。。

そういうのに対応するのが全文検索エンジンなんですよね。

個人的にはSenna+MySQLを評価してます。
以前、Luceneを評価した際に、なんか日本語の場合には検索漏れが見つかったので、うーむ(^-^;)と悩んだことがあります。たぶん、使った形態素解析がタコだったのではないかと。。

ちなみにここには書かれていませんが、全文検索のインデックスは激しく容量を食います。
こういうサービスだと元の容量がTB単位でしょうかね。
そうすると、インデックスだけで、1/2とかの容量ですから、やっぱりTB単位とかであっても不思議じゃあないです。
容量には気をつけましょう。

Chap6.入出力サービス



「googleのレスポンスが0.5廟遅くなると、PVが20%減る。Amazonのレスポンスが0.1秒遅くなると売り上げが1%減る」という話があります

うーむ、痛い(^-^;)

Chap7.分散ストレージ


NFS、高いです。
結局ん所、自分トコで分散ストレージの開発ですか。
似たような苦労はどこのポータルでも同じような苦労してるんじゃないかと。

ただ、NFSってのはDBじゃあないですから、その辺は苦労します。
当然IOエラーが発生しますし、DBじゃないので、トランザクションという概念がありません。
複数のファイルを更新する場合はめちゃめちゃ面倒になります。
途中でぶっ壊れたりしますし、金があるなら、DBを使うことをお勧めしますよ、ハイ。


Chap8.モバイルの技術


絵文字周りは、CNETに乗っている小形さんの記事も参照。

 もじのなまえ
  http://d.hatena.ne.jp/ogwata/
 絵文字が開いてしまった「パンドラの箱」第1回--日本の携帯電話キャリアが選んだ道
  http://japan.cnet.com/column/pers/media/story/0,2000058034,20389042,00.htm

後、携帯の場合はキャリアゲートウェイから来ている、という点に注意です。
その辺の知識がないと障害解析でまるでわからん、という事が発生しかねないという事を頭に置いといてください。

Chap9.ネットワークを取り巻く技術


この辺りの知識って、アプリだけを見ているとわからないんですよね。
ASがどうだとか、トランジットがどうだとか。
読むべし。

Chap10.Webサービスの性能評価


アプリケーションの速度評価には、Devel::NYTProfなんかを使うんですが、これはPerlに特化してるわけで。
通常は、JMeterとか、LoadRunnerとかを使うのではないかと思うのですよ。

 JMeter
  http://jakarta.apache.org/jmeter/

それと、サーバ負荷はMRTGが、と思ったら、cactiはその代替になるんですねえ。
へー、って感じです。

 cacti
  http://www.cacti.net/

で、ライセンスはGNUなんですね(^-^;)


まとめというか、読後の感想なのですが、一度読んでみると、得られるモノが必ずある、そんな本でした。
さて、会社に持って行って、同僚のMに回さないと。。。

ブログ気持玉

クリックして気持ちを伝えよう!

ログインしてクリックすれば、自分のブログへのリンクが付きます。

→ログインへ

なるほど(納得、参考になった、ヘー)
驚いた
面白い
ナイス
ガッツ(がんばれ!)
かわいい

気持玉数 : 0

この記事へのコメント

この記事へのトラックバック