Cluster
Node.js v0.6 の新機能として cluster モジュール が導入されました．cluster モジュールは，HTTP を含めた TCP 接続を複数の子プロセス (ワーカプロセス) で処理することにより，特にマルチコア環境でのスループット (リクエスト／秒) を向上するための機能です． しかし，ドキュメントにはその使い方が書かれているだけで，どのように実現されているかは書かれていないので，ここで簡単に紹介しておきます． Node.js のクラスタ機能は v0.5.10 で突然コマンドラインオプションとして導入されましたが，直後の「東京 Node 学園祭 2011」が行われた頃にはコマンドラインオプションは廃止されて cluster モジュールによって API が提供されるようになり，その翌週の v0.6.0 リリース数時間前にはその API が変更されるというドタバタぶりでした
Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
[追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod
Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes
＊息抜きがてら書いていたら長くなってしまった。。 ＊当たり前ですが、あくまで個人的な考えです。 ＊ころころ変わるかもしれません。 Node の基本的な知識についての話は色々なところで出始めて、 じゃあこーいう場合はどうするの？ みたいな話が出始めたりもするようになってきた気もします。 正直、自分にもまだ分からないことだらけです。 そもそも自分はそこまでスケールに関するアーキテクチャや、OS の低レイヤに精通しているとは言えないので、 これを期に Node は何が得意で何が不得意なのか、スケールさせるために考えないといけないこと、などを自分なりにまとめて、 ついでに、これまで学んできた周辺のアーキテクチャに関する知識も混ぜて、色々思考実験をしてみたいと思っています。 だから WebSocket にブラウザが対応してないとか、そんな複雑なサーバ群本当に運用できるのかとか、 そういう話は無しに、
node.js アプリの負荷分散構成を考える - KrdLab's blog
node.js の負荷分散について考えてみました (フェイルオーバは考慮できていません)．個人レベルなので 1 台のハード上に仮想マシンを 5〜6 個立ち上げて実験しています． 見出し はじめに cluster で負荷分散 寄り道：cluster の仕組み 例えばこんな全体構成 おわりに はじめに node.js は設計上，大量のコネクションを省リソース (プロセス・スレッドをバカスカ生成しない) でさばきます．おそらく想定されているのは I/O バウンドな処理であり，この場合は基本的に非同期で処理されるため，I/O 待ちで他のリクエスト処理がブロックすることはまずありません． node.js は「サービスをつなぎ・組み合わせるためのハブ」的な位置づけが一番しっくりくるように感じます *1． ただ， 大量のリクエストをさばかなければならない ロジックが重くてコールバック処理に負荷がかかって
LVSで実現するロードバランサ - KLablabWiki
環境構築 それでは実際に、Linuxベースのロードバランサを構築していきます。最近では標準でIPVSをサポートしているディストリビューションが多いので、必要なパッケージをインストールして少し設定するだけで動作させることができる便利な世の中になってきています。 今回使用するソフトウエアについて Debian GNU/Linux3.1(sarge) ディストリビューションはDebianを使用します。 IPVS対応カーネル ロードバランサの基本機能であるIPVSはカーネルの内部に実装されています。そのためIPVSに対応したカーネルが必要になります。Debian付属のカーネルイメージ（2.6.8-3）でも利用できますし、自前で再構築してもかまいません。カーネルを再構築する際の注意点については後述します。 ipvsadm IPVSを制御するためのツールです。仮想サーバグループの追加やリアル
書籍・雑誌記事 - KLablabWiki
このサイトはKLab株式会社が開発したソフトウェアやノウハウ、実験的なサービスを公開していきます。 RSS Feed
ロードバランサの冗長化 - KLablabWiki
ロードバランサを冗長化する keepalivedにはVRRPという機能があります。ロードバランサを2台用意してこの機能を使うと、なんらかのトラブルで1台がダウンしても、もう1台のロードバランサが自動的に役割を引き継いでくれるようになります（この動作を「フェイルオーバ」といいます）。 この章ではkeepalivedのVRRP機能を使い、前章の構成で単一故障点だったロードバランサを冗長化する方法を紹介します。 VRRPとは 実際に使ってみる前に、VRRPとはどのようなものかを簡単に説明します。 VRRPはVirtual Router Redundancy Protocolの略で、RFC3768で定義されています。VRRPでは物理ルータ固有のIPアドレスとは別に「仮想ルータアドレス」[1]というIPアドレスを設定します。仮想ルータアドレスは、複数の物理ルータのどれか1台に割り当てられます。仮
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
