オンライン書店のBK-1で「堀さんと宮村くん」なる書籍の予約受付がはじまってます。
まだamazonにも載ってないけど、これはweb漫画の「堀さんと宮村くん」の書籍化と考えて間違いなさそう。(追記：今はamazonにも載ってますね！)
何話まで収録されるのか、あの画質（笑）はそのままなのかなどいろいろと気になります。
漫画は本で読まないとねって人はどうぞ。
Google、webkitベースのオープンソースWebブラウザ「Google Chrome」
ＩＴの雄GoogleがSafariと同じwebkitベースでオープンソースのウェブブラウザ「Google Chrome」をWindows用にβリリースしました。
早速いれてみましたので、感想を。
良い点：
- とにかく描画が速い！Firefox3よりも体感はずっと速い。これは一見の価値あり。Safariと同じwebkitベースなんですけどちょっぱやなのは描画エンジン以外に、先読みを駆使したり、再描画をできるだけ減らしたりといった細かな部分で稼いでいる気がします。
- JavaScriptが速い！GMAILなどのJavaScriptを多用したサービスを利用するときに顕著に現れます。
Firefox3と比べていまいちな点：
- ブックマーク関係が貧弱。ブックマーク・履歴などが統合されているのはFirefoxと一緒ですが、便利なタグ機能がないこと、ブックマークの管理ができないこと、Chromeのツールバー(Omni box)では単語の検索の上位にブックマークの単語やタグが出てこないことがいまいちです。
- アドオン機能がない。Firefoxの魅力であるアドオン機能がchromeにはないです。特にadBlockPlusなどの広告遮断系は広告を収入源としているGoogleにはつらいかも。
- 細かい設定がない。「とにかく動いてるまま使えよ」的で、ユーザが設定できる項目が少ないです。
- プライバシーの問題。ツールバーがGoogle Suggestと連動しているのですが、それにともない、ツールバーに入力した単語が（たとえ実際に検索してなくても）全てGoogleに送られるようです。また、ブラウザはインストール時に全て一意のＩＤがふられており、「誰がどんな単語を検索したか」「誰がどのＧＭＡＩＬやiGoogle,GoogleReaderの利用者か」が簡単に知られてしまいます。これを気持ち悪いと考える人は使わないほうがいいかもです。
こんな感じです。主観的には、速いのはすごいと思いましたが、いまいちな点がいまいちなのでしばらくは様子見かなーと思いました。皆さんはどうでしょうか？IE7を使っている人は入れてみるとその速さに驚くと思いますよ。
関連する投稿
冗長化したWebシステムの構成の基本(サービスを止めない技術)
安価なサーバを沢山並べることで容易に性能を上げられるＮ＋１処理にも弱点があります。それは、Ｎ＋１台のサーバが独立して動作するために、データの一貫性を保てないのです。
一貫性を保たなくてはいけないデータとはたとえばＥＣサイトのセッション情報やMixiの日記データ、証券会社のお金の情報などです。
これらは逐一情報が更新されていき、かつ常に一貫性が保たれなくてはいけません。
よってこれらの情報の管理（すくなくとも書き込み権の管理）は１台のサーバが行わなくてはなりません。よって、ＤＢサーバ（のマスター）やファイルサーバなどはＮ＋１構成ではなく、ＨＡ構成をとらざるを得ません。またＮ＋１を実現するための負荷分散装置自身もＮ＋１にするわけにはいきませんから、ＨＡ構成（ＡＣＴ－ＳＢＹ）になります。
全体として、冗長化を考慮した典型的なＷｅｂシステムは基本的には以下の図のような構成になります。
ＨＡ構成のネットワーク図(基本）
関連する投稿
負荷分散もしくはN+1冗長化(サービスを止めない技術)
サーバの冗長化方式で、ＨＡ方式ともうひとつ有名な方法が、負荷分散もしくはＮ＋１冗長化といわれるものです。
厳密には負荷分散とN+1冗長化は違うんですけど、実現手段が同じ場合が多いです。
これはどういうものかといいますと、なにかのサービス(ここではＷｅｂサーバを動かすHTTPDだとします）を実行するサーバが、たとえば６台必要だとしますと、予備含めて７台用意します。そして、そのサーバとインターネットの間に、「負荷分散装置（ロードバランサー）」と呼ばれる機械をはさみます。
負荷分散装置はインターネットに対して、入り口となるひとつのＩＰアドレスを用意します（VIP:Virtual IPなどといいます)。クライアント（この場合はブラウザ）からVIPに向かってやってきたＨＴＴＰリクエストは、負荷分散装置であて先を７台のサーバに書き換えられて、サーバに分散させて送りつけます。
リクエストを受けたサーバは応答をクライアントに返そうとします。そのとき、負荷分散装置はサーバのデフォルトGATEWAYになっているので、応答パケットは負荷分散装置を通ります。負荷分散装置に到達した応答パケットは応答主のＩＰアドレスを負荷分散装置のＶＩＰに書き換えて、クライアントに返します。
こうすることで、負荷分散装置はクライアントから見ると一台のサーバに見えますが、実際の処理は７台のサーバで分担することになります。
これによって、１台のサーバではしんどい処理をあたかも１台のサーバが処理しているかのように沢山のサーバにやらせることができます。
ここまでは性能の話で、冗長化の話ではありません。ここで、７台のサーバのうちの１台が故障してサービスできなくなったとします。そのとき、負荷分散装置はサーバをポーリングして、反応しなくなったサーバを負荷分散対象からはずすのです。
これによって、７台のサーバのどのサーバがダウンしてもサービスはほとんど止まることなく動き続けることができるのです。
すばらしいですね。
負荷分散装置はHTTPリクエストのＴＣＰヘッダを解釈して、分散しますので、IPレベル(OSI7階層モデルで第三階層)でのネットワーク制御機器であるルーターをL3スイッチ(L3SW)というのにならい、L4スイッチといいます。また高機能な負荷分散装置はTCPヘッダだけでなく、URLのパスやクッキー、ＨＴＴＰリクエストの内容を理解して分散先を制御します。このような負荷分散装置をL7スイッチといいます。（L5,L6スイッチというものはTCP/IPの世界では普通存在しません。念のため)
商用の負荷分散装置では、F5ネットワークスのBIG-IP、ファウンドリーのServerIron、ノーテルのAceDirectorなどが有名です。一般的にこれらの装置は目の玉が飛び出るほど高いです。
商用の機器を使わずに負荷分散を実現する方法として、Linux上で動くL4スイッチ機能であるLVSを用いる方法があります。また、apacheのmod_proxyモジュールを使って、HTTPリクエストをL7レベルで負荷分散する方法もメジャーです。
負荷分散装置はインターネットの矢面に立つことが多い機器ですので、ファイアーウォールなどを用意せずにＬｉｎｕｘなど脆弱性が広く知れ渡っている機器を使う場合には十分なセキュリティ対策が必要です。
関連する投稿
Posted in サービスを止めない技術
Tagged AceDirector, BIG-IP, linux, LVS, N+1, ServerIron, サーバ, 冗長化, 負荷分散
Leave a comment