CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
![Perlで作るモバイルサイトのコツ:第2回](https://cdn-ak-scissors.b.st-hatena.com/image/square/106c7e478be88bc515873fc79870c7b92dd94618/height=288;version=1;width=512/https%3A%2F%2Fcodezine.jp%2Fstatic%2Fcommon%2Fimages%2Fczlogo4fb_ogp.png)
This document discusses various strategies and techniques for managing capacity for web operations. It begins by discussing the importance of measuring current capacity and finding ceilings rather than relying on benchmarks. It then covers topics like forecasting future capacity needs, establishing safety factors, diagonal scaling to improve performance, and dealing with capacity issues through te
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。(編集部) Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
ライブドアテクノロジーセミナーに行ってきましたよ。 id:naoyaさんは LVS++という話 でしたが、自分も 1年ほど前に、某サイトの負荷分散を LVS + Ultra Monkey (heartbeat + ldrectord) でやったので、社内 Wiki に書いてたメモを晒しておきます。 # 今なら heartbeat じゃなくて keepalived が普通なのかも知れず、情報が古めの可能性はあります LVS の Director を 2台で HA 兼 Real Server (httpd) + Real Server 1台 (httpd) DB Server 1台 という構成。 LVS と Real Server を別にするのはちょっとコスト的にもったいなかったため、Director と Real Server を同一マシンに乗せる形に。http://ultramonkey.
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
malloc()といえばC言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.3.2.ds1-22 OS : i386 Linux 本書では、上記の通りi386アーキテクチャの場合について記述しています。
提供されるサービスのポート番号宛のパケットを検出し、それと対応する実サーバに対して、パケットの転送処理を行います。TCPコネクションを、あらためて開設する際のパケット(実サーバとの対応づけがされていないパケットを指す)や、UDPパケットの場合には、転送先の実サーバについてどれにすべきか、スケジュールカーネルモジュールに問い合わせを行ってから処理をします。 パケット転送方法には、以下のような種類があります。 LVS/NAT NATにより宛先IPアドレスを実サーバアドレスに変換して転送する ロードバランサ宛に到着したパケットは、宛先IPアドレスを実サーバのものに変換することで実サーバに転送します。実サーバからクライアントへの応答パケットは、ロードバランサがソースアドレスを、ロードバランサのIPアドレスに変換してクライアントに転送します。この構成では、ロードバランサ側で、IPアドレス変換
固定IPを設定する場合 /etc/sysconfig/network NETWORK=yes HOSTNAME=notepc.deer-n-horse.jp GATEWAY=192.168.0.1 /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=192.168.0.5 NETMASK=255.255.255.0 ネットワークインターフェイス毎に ifcfg-eth1 というようにファイルをふやして行く必要がある。 ファイルだけ用意する場合は eth0 などとして ifcfg-eth[0-9] のファイル名はつけないようにしておけば退避可能。 DHCPでIPを取得する場合 /etc/sysconfig/network NETWORKING=yes HOSTNAME
09/04/16 大幅に修正 複数のネットワークインターフェイスを束ねて冗長性や負荷分散を行う技術を、Linuxではボンディングと呼ばれるドライバにより実現しています。CentOSでボンディングを構成したときのメモ。 CentOS 5.2にてテストしましたがRed Hat系のディストリビューションであれば適用できるかと思われます。 環境 CentOS 5.2 on VMware Server 1.0.6 仮想NIC × 2 ホストマシン搭載物理NIC数: 3 構成してみる ここで、eth0, eth1のようにネットワークデバイスがすでに利用できる状況になっていることが前提となります。 eth0とeth1をボンディングし、ネットワークデバイスbond0を、eth2とeth3をボンディングしネットワークデバイスbond1を生成する場合の手順は以下の通り。 1. /etc/modprobe.d/
bondingとは? 簡単に書くと複数のNICを一つにまとめて、負荷分散や冗長化を行うというものです。 kernelのモジュールである「bondモジュール」をつかうので、bondingといったように呼ばれているらしいです。 注意点 BondingでリピータHUB(いわゆる馬鹿ハブ・ダムハブ)を使用するとコリジョンが多発する為、スイッチングHUBの使用が必要です。 ※ リピーターHUBは受信データを受信中のポートを除く全てのポートから一斉に送信します。 なので、リピーターHUBをつかってbondingをしている端末でデータ送信を行うと、 bondingされているNICデバイス全てに同じデータが送信され(bondingされているNICデバイスはMACアドレスが全部同じになるため)、 問題が発生しちゃうということらしいです。 また、bondingを行うためにはカーネルレベルで対
仕事メモ。 インタラクティブなコンソールアプリケーションだと、STDIN/STDOUT を使ったやりとりが発生します。こういうのをテストするときに、いままでは、 { local *STDOUT; open(STDOUT, '>', 'stdout.txt') do_something(); #STDOUT を使う何か close(STDOUT); } open(my $MY_STDOUT, '<', 'stdout.txt'); #... $MY_STDOUT の中身を読み出してテストする みたいな処理を書いて、ファイルの中身でチェックしてました。(STDIN の場合は逆で、入力データをファイルに書いて、捻じ曲げた STDIN をアプリに読ませる)。 ファイルを噛ませるのが嫌だったのと、ちょっとトリッキーなのが気に入らなかったので、モジュールを使ってもうちょっと優雅に(?)書けないかな、と
シンボルテーブルを操作するときに"no strict 'refs'"で一時的にstrictを無効化することはよくあるが,デバッグしにくいバグが紛れ込む可能性がある。 たとえば,以下のようにアクセサを動的に生成するコードはCPANのそこかしこにある。 sub make_accessor{ my($class, $property) = @_; no strict 'refs'; # simple read-only accessor *{$class. '::' . $property} = sub{ my($self) = @_; return $self->{$property}; } } このようなコードによって生成されたメソッドを,正しくオブジェクトに対して使う分には問題ない。しかし,このメソッドをクラスメソッドとして呼び出すと,グローバル変数${$self}を参照し,その値をハッシ
Re: XSの勉強を始めるためのエントリーポイントは? あまり参考にならないかもしれませんが,私がXSを勉強するにあたっては,CPANのモジュールのソースコードを読むより実際に書いてみるのが一番だと思います。ただし,何か特定の目的があって,そのために関係がありそうなコードを探して読む,ということは非常によくあります。 以下,思いついたことを適当に並べてみます。 自分でコードを書いてみて初めて分かることが少なくない 学ぶのに適した理想的なコードは,そう簡単には見つからない 古い書き方やおかしな書き方をしているコードも大量にあるので,そういうコードをフィルタリングするためにも,いろいろな作者のコードを読んだほうがいい 多くのコードの中から理想的な部分を抜き出して,それを身につけていく 目的とまったく関係ないコードから閃きを得ることも多い perlのソースコードをすぐ参照できるようにしておくのは
NIC(Network Interface Card)にIPアドレスを複数設定する方法です。 Redhat系Linuxの場合 Redhat系linux (FredoraCore CentOS Vine等) のIPアドレス設定ファイルはNICが1個ならば通常/etc/sysconfig/network-scripts/ifcfg-eth0 となります。1枚のNICに複数のIPを設定する場合はこの設定ファイルを流用してIPアドレスを設定していきます。 IPアドレスを追加していくたびに設定ファイルは以下のように増えていきます。 /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1 <--追加IP設定1/etc/sysconfig/network-scripts/ifc
NIC(Network Interface Card)にIPアドレスを設定する方法です。 まずはじめに、IPアドレスの変更は慎重に行いましょう!!失敗するとネットワークに繋がらなくなります。 sshなどでリモートメンテナンスしている際に、設定ミスをするとマシンのある場所まで駆けつけなくてはいけなくなりますよ。 近くにサーバがあるならまだ救われますが、これが遠い場所だったりすると orz ちなみに、私は何度か失敗して痛い目見ました・・・ Redhat系Linuxの場合 Redhat系linux (FredoraCore CentOS Vine等) は、 /etc/sysconfig/network-scripts/ifcfg-eth0 にて、NICにIPアドレスを設定します。 /etc/sysconfig/network-scripts/ifcfg-eth0設定 NIC
gitを使いはじめたのですが、わからないことだらけなのでとりあえずsvnコマンドとの対応一覧。 svn checkout url git clone url svn update git pull svn status git status svn revert path git checkout path svn add file git add file svn rm file git rm file svn mv file git mv file svn commit git commit -a svn log git log 参考:http://www.tempus.org/n-miyo/git-course-trans-ja/svn.ja.html
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く