Home

tap dev blog

Pound+KeepAlivedでロードバランサ+冗長化

  • ロードバランサと冗長化のテストを行いました。
  • ロードバランサ2台とバックエンドサーバー3台(下図のような感じ)
      インターネット
        |
        |
 -------------------------------
     |                       |
     | 192.168.100.12        | 192.168.100.13
 ==========              ==========
 |   LB   |              |   LB   |
 ==========              ==========
     |                       |
     |                       |
 ----------------------------------------------------------
     |                       |                           |
     | 192.168.101.5         | 192.168.101.6             | 192.168.101.7
 ===========             ===========                 ===========
 |   web   |             |   web   |                 |   web   |
 ===========             ===========                 ===========

ロードバランサには、L7スイッチを行わせたいのと、HTTPSラッパを行わせたいので、採用する選択肢としては、

  • Apache mod_proxy , mod_proxy_balancer
  • Pound
  • squid
  • Ultra Monkey L7

などがあります。それぞれ、次のような特徴があります。

  • Apacheは、十分な安定性と拡張性があります。ただし、少々重い点があります。
  • Poundは、軽量かつセキュアです。ただし、フェイルオーバー機能が一切無い点と、TCPコネクション回りが少々雑です。
  • squidはProxyなので、バランサ機能に乏しいところが問題です。
  • Ultra Monkeyは、もともとレイヤ4のバランサですが、L7はレイヤ7対応しました。最近はやりな感じですが、まだ新しいので、実例に乏しいのが問題です。

今回は、これらのことを踏まえて、Poundを採用することにしました。課題のフェイルオーバー機能ですが、自分で Keepalived+LVS+Pound構成にして、VRRPによるフェイルオーバー機能を実装することにしました。

レイヤ4スイッチとレイヤ7スイッチのちがい(スイッチというよりバランサ)

レイヤ4スイッチは、「TCP層でのスイッチング」です。TCP層ですので、IPを見て振り分けることができます。また、SYNフラグ等を見て、通信のはじまりや終わりといったことをチェックしたり、それによりパケットブロックを行う等が可能です。ただし、HTTPプロトコル層(アプリケーション層)までは組み立てを行わないので、HTTPのヘッダを見たりして振り分けすることはできません。もちろんHTTPSの変換等も行えません。これに対し、レイヤ7 スイッチは、最上位層のアプリケーション層まで組み立ててから振り分けを行うので、HTTPのヘッダを見たり、URLによる振り分けを行ったりすることができます。

一般的には、レイヤ4での振り分けを行うバランサをロードバランサと呼び、レイヤ7での振り分けを行うバランサをリバースプロキシ+ロードバランサというみたいです。リバースプロキシ自体は、レイヤ7での応答を代理する(※proxy:代理)だけの機能です。通常、プロキシサーバーはイントラネット上のリクエストを代理送信するものですが、逆に、リクエストの受信を代理で受け付けて、必要な処理を行うものを「逆代理」なのでリバースプロキシというようです。

Poundにフェイルオーバー機能を上乗せする

今回はテストですので、単純にいきました。(HTTPSは使わず、HTTPのみで通信。L7スイッチの特徴を使わない。)頭の二台をマスタ+ホットスタンバイ構成でなく、DNSラウンドロビンにより二台とも動かして、リソースを無駄にしない(単にバランサがボトルネックになるのを防ぐ)ために、要求性能としては、次を定義します。

  • 公開側のIPアドレスはどちらのIPでもアクセスがいつでもできる。(片側のバランサが落ちたときは、もう一方がIPアドレスを引き継ぐ)
  • 停止時間はできるだけ短めに(最大5秒)
  • 再起動は単純にできる
  • Poundが応答しないときも、切り替えたい。 IPアドレスの引継があるので、このあたりはKeepAlived+LVSを用いて、公開IPはバーチャルIP(VIP)とすることにしました。

ここで、問題が発生します。

    Poundは、起動時にIP&portにソケットをつなぐ。

    このため、はじめに一方のVIPをListenするようにして起動したら、あとから別のVIPを引き継いでも、PoundはそのIPからのアクセスを受け付けてくれない。

というわけで、VIPを引き継ぐタイミングで、再起動して、両方のIPをListenするようにします。(別のconfigを読ませて立ち上げる。)

これだけでは、最後の「再起動を単純に」が問題となりますので、元に戻るときにも再起動させて(1方のVIPのみ引き離すと、Poundは自動的にシャットダウンする)、Poundに1方のVIPのみをListenさせるように切り替えることにしました。

次に、Poundの応答ですが、KeepAlivedには、VRRP機能でのサービス監視機能がありません。というわけで、自分でサービス監視もスクリプトを書いて行うことにしました。

あとは、実装するだけです。VIPの引継は、KeepAlivedに行わせますので、KeepAlivedからのトリガか、自分で作るサービス監視からのトリガで、Poundを再起動させることにします。

仕様実現のためのまとめ

  • Keepalivedが起動する。
    • 自動的に現状の状態を把握してVIPを誰が持つのか決定する。(KeepAlived(VRRP)+LVS)
    • 自分が持っているVIPから、poundにVIPをListenさせる設定にてpoundを起動する。
    • poundが起動したら、poundが止まっていないかどうかの監視スクリプトを開始する。
  • poundが異常停止してしまったとき
    • 監視スクリプトが異常に気づく。
    • 自分が最後の一台である(すべてのVIPを保持している)場合は、poundを再起動する。
    • 自分が最後の一台でない場合は、keepAlivedとpoundを落として、他のサーバーにまかせる。(keepAlivedが落ちると、他のサーバーのkeepAlivedがフェイルオーバーを始める。)
  • 他のサーバーのkeepAlivedが落ちたとき(VRRP信号が送られてこなくなったとき)
    • KeepAlivedが勝手に気づく。
    • フェイルオーバーを始める。
    • フェイルオーバーが終わったら、poundを、引き継いだVIPを含めた自分が保持するVIPをすべてListenするようにして、再起動する。
    • 以前の監視スクリプトを落とす。
    • poundが起動したら、poundが止まっていないかどうかの監視スクリプトを開始する。

実際の工程

まずは、2台のみという形で設定を行います。三台以上にする場合は、ちょっと工夫が必要かもしれません。

  • KeepAlived.conf (192.168.100.12をMasterとして持つ側のもの)
  • ! Configuration File for keepalived
    # フェイルオーバーした際のalertメールを送るための設定(無くても可)
    global_defs {
        # メールの送り先
        notification_email {
            hogehoge@hoge.co.jp
        }
        # メールの送信元アドレスと、メールサーバー
        notification_email_from KeepAlived@hogehoge.co.jp
        smtp_server 1.2.3.4
        smtp_connect_timeout 30
        router_id LVS_DEVEL
    }
    
    # VIP:192.168.100.12の設定
    #[vrrp_instance ][好きな名前]
    vrrp_instance VI_1 {
        # マスタサーバー
        state MASTER
        # VIPを割り当てるNIC
        interface eth0
    # ネットワークが混雑していて、スイッチがARP信号を処理できない場合は、ARPを少し送らせて送信する設定。
    # 無くても動く。動作が変な場合(VIPを引き継いだのに、外部から認識できない現象が出たら、こいつを設定。)
    # 弊害として、VIPの引継完了が遅くなる。(デフォルトは引き継いだら即ARP信号の送信。)
    #    garp_master_delay 1
        # 仮想ルーターのID(VRRP信号を共有する他サーバーのインスタンス間で共通にする。)
        virtual_router_id 51
        # 優先度(MasterはBACKUPよりも高く設定。)
        priority 101
        # なんだろこれ?
        advert_int 1
        # VRRP信号を受け取る際のパスワード等(同じvirtual_router_idならば、同じにする。)
        authentication {
            auth_type AH
            auth_pass k@l!ve1
        }
        # このインスタンスで管理するVIP(同じvirtual_router_idなら、同じにする。※NICは同じ必要ない。)
        virtual_ipaddress {
            192.168.100.12/28 dev eth0
        }
    # マスタノードは、何も要らない。
    #    notify_master "/usr/local/lbcheck/poundstart.sh 1"
    }
    
    # VIP:192.168.100.13の設定
    vrrp_instance VI_2 {
        state BACKUP
        interface eth0
    #    garp_master_delay 1
        virtual_router_id 52
        priority 100
        advert_int 1
        authentication {
            auth_type AH
            auth_pass k@l!ve2
        }
        virtual_ipaddress {
            192.168.100.13/28 dev eth0
        }
        # notify_masterは、マスターノードになったときに起動するスクリプトを指定。
        notify_master "/usr/local/lbcheck/poundstart.sh all"
        # notify_backupは、バックアップノードになったときに起動するスクリプトを指定。(初期起動時は、上の設定よりBACKUPなので、必ずこれが起動する。)
        notify_backup "/usr/local/lbcheck/poundstart.sh 1"
    }
    
  • KeepAlived.conf (192.168.100.13をMasterとして持つ側のもの)
  • ! Configuration File for keepalived
    
    global_defs {
        notification_email {
            hogehoge@hoge.co.jp
        }
        notification_email_from KeepAlived@hogehoge.co.jp
        smtp_server 1.2.3.4
        smtp_connect_timeout 30
        router_id LVS_DEVEL
    }
    
    # VIP:192.168.100.12の設定(BACKUPなので、priorityを下げ、stateを変える。)
    vrrp_instance VI_1 {
        state BACKUP
        interface eth0
    #    garp_master_delay 1
        virtual_router_id 51
        priority 100
        advert_int 1
        authentication {
            auth_type AH
            auth_pass k@l!ve1
        }
        virtual_ipaddress {
            192.168.100.12/28 dev eth0
        }
        notify_master "/usr/local/lbcheck/poundstart.sh all"
        notify_backup "/usr/local/lbcheck/poundstart.sh 2"
    }
    
    # VIP:192.168.100.13の設定
    vrrp_instance VI_2 {
        state MASTER
        interface eth0
    #    garp_master_delay 1
        virtual_router_id 52
        priority 101
        advert_int 1
        authentication {
            auth_type AH
            auth_pass k@l!ve2
        }
        virtual_ipaddress {
            192.168.100.13/28 dev eth0
        }
    }
    

監視スクリプト(含pound起動スクリプト)例

  • 今回は、4つにわけました。
    • 192.168.100.12の応答のみを監視するスクリプト(応答が無かったら、keepalivedを落とす)
    • 192.168.100.13の応答のみを監視するスクリプト(応答が無かったら、keepalivedを落とす)
    • 両方のVIPの応答を監視するスクリプト(応答が無かったら、poundを再起動する。)
    • 上記3つのスクリプトを停止したり起動したりするスクリプト
  • 特に最後のスクリプトを作った理由は次の通りです。
  • 監視スクリプト自体は、3つのうち1つだけしか起動しないはずの、排他的無限ループ永久監視なので、起動する際に、他の2つが起きていたら、落とさなければならない。ただし、もしなんらかの原因で、自分自身が多重起動していた場合、落とすことができないので、無限ループでない起動スクリプトから起こして、必ず二重起動をさせないようにする。

  • また、両方のVIPの監視スクリプトは、フェイルオーバーされて、2VIPを持った場合のための監視です。この場合、フェイルオーバーさせる相手がいないので、自分だけで解決しなければならないことから、pound再起動を行うようにしました。
  • なお、poundは、2つ起こして、各VIPを担当させる手もあったのですが、poundはコネクション管理がうまくないことから、二重起動があまり好ましくないと判断したため、必ず1つだけ起動させるようにしました。(二重起動のメリットは、フェイルオーバーしても一方のコネクションは切れずに済むことです。このタイプでもいいかもしれません。また、二重起動の際は、pound停止スクリプトを自分で書かなければいけません。)
  • 一方の応答のみを監視するスクリプト(dpoundstart1.sh)
#!/bin/bash
####
#とりあえずフェイルオーバースクリプト。
####
MyVIP="192.168.100.12"
CheckFile="index.html"
LBCheckDIR="/usr/local/lbcheck"
cfgFile="pound1.cfg"

#または、
#MyVIP="192.168.100.13"
#CheckFile="index.html"
#LBCheckDIR="/usr/local/lbcheck"
#cfgFile="pound2.cfg"

#まずは、poundを再起動。
/etc/rc.d/init.d/pound stop
sleep 1
/usr/sbin/pound -f $LBCheckDIR/$cfgFile
#起動して直後の監視は、失敗することがあるので、少し待つ。
sleep 2

#次に、自身のpoundが動いているかどうかチェック。止まっていたら、後ろを実行。
m_URL="http://$MyVIP/$CheckFile"

while true ; do
    # 1秒おきに監視を実行
    sleep 1
    AP=`/usr/bin/curl -s --head $m_URL | head -n 1 | cut -f 2 -d ' '`
    if [ "200" != "$AP" ]; then
        /etc/rc.d/init.d/keepalived stop
        /etc/rc.d/init.d/pound stop
        exit
    fi
done

o 両方の応答を監視するスクリプト(dpoundstartall.sh)

#!/bin/bash
####
#一台が止まっている危険状態でのスクリプト。(pound停止時は、poundを再起動)
####
MyVIP1="192.168.100.12"
MyVIP2="192.168.100.13"
CheckFile="index.html"
LBCheckDIR="/usr/local/lbcheck"
cfgFile="poundall.cfg"

#しばらく置く。
#まずは、poundを再起動。
/etc/rc.d/init.d/pound stop
#ネットワークが安定するまで待つ
sleep 1
/usr/sbin/pound -f $LBCheckDIR/$cfgFile
#起動して直後の監視は、失敗することがあるので、少し待つ。
sleep 2

#次に、自身のpoundが動いているかどうかチェック。止まっていたら、後ろを実行。
m_URL1="http://$MyVIP1/$CheckFile"
m_URL2="http://$MyVIP2/$CheckFile"
while true ; do
    #スクリプトは1秒おきにチェック。
    sleep 1
    AP1=`/usr/bin/curl -s --head $m_URL1 | head -n 1 | cut -f 2 -d ' '`
    AP2=`/usr/bin/curl -s --head $m_URL2 | head -n 1 | cut -f 2 -d ' '`
    if [ "200" != "$AP1" ] ; then
        #poundを再起動。
        /etc/rc.d/init.d/pound stop
        /usr/sbin/pound -f $LBCheckDIR/poundall.cfg
    elif [ "200" != "$AP2" ] ; then
        #poundを再起動。
        /etc/rc.d/init.d/pound stop
        /usr/sbin/pound -f $LBCheckDIR/poundall.cfg
    fi
done

o 監視スクリプトを起動したり停止したりするスクリプト(強制Kill)

#!/bin/bash
LBCheckDIR="/usr/local/lbcheck"

if [ $# -ne 1 ] ; then
    exit;
fi

#監視サービスが動いていたら、killする。
C_Service=`ps -ef | grep $LBCheckDIR/dpoundstart | grep -v grep`
if [ -n "$C_Service" ] ; then
    for m_i in `ps -ef | grep $LBCheckDIR/dpoundstart | grep -v grep | awk '{print $2}'` ; do
        kill -9 $m_i
    done
fi
# 引数の指示通り、監視スクリプトを起動する。
if [ "$1" = "1" ] ; then
    $LBCheckDIR/dpoundstart1.sh &
elif [ "$1" = "2" ] ; then
    $LBCheckDIR/dpoundstart2.sh &
else
    $LBCheckDIR/dpoundstartall.sh &
fi

poundのコンフィグファイルについて

  • pound.conf は、3種類用意していますが、ほとんど同じものです。
  • とりあえず、 pound.conf の設定可能内容を先に書いておきます。
  • #User        "nobody"
    #Group       "nobody"
    #RootJail    "/var/pound/jail"
    #次の行は、Deamontoolsで動かすときは1にする。
    #Daemon         1
    #LogLevel       4
    #Alive          30
    #次は、下のリスナ設定で各値に上書きされる。
    #Client         5
    #TimeOut                60
    #Grace          30
    #このへんは使わない?
    #SSLEngine
    #Control
    #LogFacility    LOG_DAEMON
    #DynScale       0
    
    ## HTTPに関する設定
    #受付側(リスナ)
    #ListenHTTP
    #    Address 192.168.100.12
    #    Port    80
    #    Client  5
    #    xHTTP
    #    CheckURL
    #    Err414
    #    Err500
    #    Err501
    #    Err503
    #    MaxRequest 200M
    #    HeadRemove
    #    AddHeader
    #    RewriteLocation
    #    RewriteDestination
    #    Loglevel
    #    Service
    #End
    
    ## HTTPSに関する設定
    #受付側(リスナ)
    #ListenHTTPS
    #    Address 1.2.3.4
    #    Port    443
    #    Cert    "/etc/pound/pound.pem"
    #    Client  5
    #    ClientCert
    #    Ciphers
    #    CAlist
    #    xHTTPVerifyList
    #    CheckURL
    #    CRLlist
    #    NoHTTPS11
    #    Err414
    #    Err500
    #    Err501
    #    Err503
    #    MaxRequest 200M
    #    HeadRemove
    #    AddHeader
    #    RewriteLocation
    #    RewriteDestination
    #    Loglevel
    #    Service
    #End
    
    ##ここから、バックエンドサーバーに関する設定
    ##例と使えるもの一覧
    ## Image server
    #Service
    #    URL ".*.(jpg|gif)"
    ##    HeadRequire
    ##    HeadDeny
    ##    DynScale
    ##    Redirect
    #    Emergency
    #        Address 192.168.0.11
    #        Port 80
    #    End
    #    Session
    ##        Type {IP|BASIC|URL|PARM|COOKIE|HEADER}
    ##        #IP:IPが同じものは同じ場所に振る
    ##        #BASIC:BASIC認証が同じものは、同じ場所に振る
    ##        #PARM:URIパラメーターが同じものは同じ場所に振る。
    ##        #URL:URLに入っているパラメータ(下のIDで指定)が同じものは同じ場所に振る。
    ##        #COOKIE:COOKIEに入っているパラメータ(下のIDで指定)が同じものは同じ場所に振る。
    ##        #HEADER:HEADERに入っているパラメータ(下のIDで指定)が同じものは同じ場所に振る。
    ##        #ID    "sessid"
    ##        #次のTTLは必須。セッションが無効になるまでの時間。
    ##        TTL    180
    #    End
    #    BackEnd
    #        Address 192.168.0.10
    #        Port    80
    #        #Priorityはデフォルト5、最大9。優先したいサーバーは高くする。
    #        #HTTP以外のポートやアドレスでこのサーバの死活監視を行う場合必要。
    #        #HAport 192.168.100.1 50
    #        Priority 5
    #    End
    #End
    
    
  • 実際の pound1.conf
  • User        "nobody"
    Group       "nobody"
    
    ListenHTTP
      Address 192.168.100.12
      Port    80
      Client  5
    End
    
    Service
      BackEnd
        Address 192.168.101.5
        Port 80
      End
      BackEnd
        Address 192.168.101.6
        Port 80
      End
      BackEnd
        Address 192.168.101.7
        Port 80
      End
    End
    
  • 実際の pound2.conf
  • User        "nobody"
    Group       "nobody"
    
    ListenHTTP
      Address 192.168.100.13
      Port    80
      Client  5
    End
    
    Service
      BackEnd
        Address 192.168.101.5
        Port 80
      End
      BackEnd
        Address 192.168.101.6
        Port 80
      End
      BackEnd
        Address 192.168.101.7
        Port 80
      End
    End
    
  • 実際の poundall.conf
  • User        "nobody"
    Group       "nobody"
    
    ListenHTTP
      Address 192.168.100.12
      Port    80
      Client  5
    End
    
    ListenHTTP
      Address 192.168.100.13
      Port    80
      Client  5
    End
    
    Service
      BackEnd
        Address 192.168.101.5
        Port 80
      End
      BackEnd
        Address 192.168.101.6
        Port 80
      End
      BackEnd
        Address 192.168.101.7
        Port 80
      End
    End
    

まとめ

今回は、最も簡単にpound+keepAlivedでのロードバランサ冗長化ですが、意外と簡単にできました。

今度は、この環境がどのぐらいのアクセスをさばけるのか実験してみたいと思います。

実験結果次第では、市販のロードバランサの置換を考えられるかもしれません。次回は、「はじめてのyumレポジトリ作成」を投稿したい思っています。

ほんとは・・たぶん最もよい手段は・・

poundのソースを見て、VRRP機能を付加することだと思います。(ちょっと敷居が高い・・)そのうち考えます。

あけましておめでとうございます

P1020433.JPG

技術的な記事がなかなか投稿できておりませんが、折りを見てポツポツとでも投稿していきたいと思っております。

本年も、どうぞよろしくお願いいたします。

弊社社長が還暦を迎えました

IMG_1169

弊社内のことではございますが、このたび、弊社社長井上が還暦を迎えることとなりました。これもひとえに、皆様方の暖かいご支援あってのことだと、社員一同、大変ありがたく思っております。

これからも株式会社タップを何卒よろしくお願い申し上げます。

dnsmasqを使って検証用にMXレコードを強引に指定する方法

メール送信の際、MTAはDNSに登録されているMXレコードを参照して宛先サーバを見つけることになりますが、稼働中ドメインのメールサーバを移行する場合、テスト段階でMXレコードを書き換えるというわけにはいきません。ですので、新しく設定したメールサーバがきちんと外部からのメールを受信できるかを確かめるとなると、telnetで直接接続してどーたらこーたら(*1)とか結構じゃまくさいです。

タップ開発チームとしてはじゃまくさいのは嫌ですので、できればさくっとメールクライアントから送信テストができると嬉しいのになあと思って色々考えました。で、考えた結果、社内DNSとして使っているdnsmasq(*2)にMXレコードが設定できれば解決するんじゃないかと思いついたので、やってみて、成功した、というお話です。

dnsmasqっていうのは、かなり端折って言いますと、BINDより何倍も手軽なDNSプログラムです。社内サーバの名前解決用にちょっとDNSサーバ立てたいなーって感じの時なんかには、自分の/etc/hostsファイルを参照する仕組みなので、設定もすごく簡単です。詳しくはいい記事を見つけましたので、このページなんかを見てみてください。

で、今までは名前解決用にしか使ってなかったそのdnsmasqなんですが、man眺めてたら、

-m, --mx-host=<mx name>[[,<hostname>],<preference>]

みたいな感じで、どうやらMXレコードも設定できるようなのでやってみました。

今回のポイントは以下の通りです。

  • 現在のメールサーバはns.mc-compass.com(157.205.227.133)
  • 新しいメールサーバはxxx.tapweb.co.jp(157.205.227.xxx)(*3)
  • dnsmasqサーバのIPアドレスは192.168.2.211
  • dnsmasqサーバのsmtpを使って送信テストをする

では、いってみます。以下のコマンドは、すべてdnsmasqサーバ(192.168.2.211)のサーバ上で実行しています。

まず、現在のDNSの設定状況をdigコマンドで確かめます。

# dig tapweb.co.jp mx

; <<>> DiG 9.4.3-P3 <<>> tapweb.co.jp mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43904
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;tapweb.co.jp.                  IN      MX

;; ANSWER SECTION:
tapweb.co.jp.           5627    IN      MX      10 ns.mc-compass.com.

;; AUTHORITY SECTION:
tapweb.co.jp.           117750  IN      NS      dns11.aics.ad.jp.
tapweb.co.jp.           117750  IN      NS      dns12.aics.ad.jp.
tapweb.co.jp.           117750  IN      NS      dns13.aics.ad.jp.

;; ADDITIONAL SECTION:
ns.mc-compass.com.      5627    IN      A       157.205.227.133

;; Query time: 2 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Wed Sep  2 19:19:37 2009
;; MSG SIZE  rcvd: 147

こんな感じで、MXレコードは、ns.mc-compass.com(157.205.227.133)っていうサーバに設定されていることが分かります。

続いて、dnsmasqの設定です。MXレコードを設定するには、/etc/dnsmasq.confファイル内に、下記のような設定を加えます。

# vi /etc/dnsmasq.conf
mx-host=tapweb.co.jp,xxx.tapweb.co.jp,50

書いたら再起動。

# /etc/init.d/dnsmasq restart
Shutting down dnsmasq:                                     [  OK  ]
Starting dnsmasq:                                          [  OK  ]

ここで、resolve.confに自分自身を設定します。

# cat /etc/resolv.conf 
nameserver 192.168.2.211 # 自分のアドレス

で、もう一度MXレコードを確認してみると、

# dig tapweb.co.jp mx

; <<>> DiG 9.4.3-P3 <<>> tapweb.co.jp mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 512
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;tapweb.co.jp.                  IN      MX

;; ANSWER SECTION:
tapweb.co.jp.           0       IN      MX      50 xxx.tapweb.co.jp.

;; ADDITIONAL SECTION:
xxx.tapweb.co.jp.    6323    IN      A       157.205.227.xxx

;; Query time: 0 msec
;; SERVER: 192.168.2.211#53(192.168.2.211)
;; WHEN: Wed Sep  2 19:21:52 2009
;; MSG SIZE  rcvd: 81

やった!新しいサーバがきちんと参照できています。

ということで、このマシン上で、

# cat 'test' |mail omura@tapweb.co.jp

などとしてやれば、新しいサーバ(xxx.tapweb.co.jp)にメールが届くかどうかのテストができるというわけです。

今後は、新しいメールサーバの仕組みなどについても紹介できればと思っています。

*1: 例えば、この辺参照→http://ash.jp/net/telnet_smtp.htm

*2: http://www.thekelleys.org.uk/dnsmasq/doc.html

*3: 執筆時は設定中のため伏せています

My Open Archive開発合宿&Kyoto Engineer BootCampに協賛します

株式会社タップでは、この度、2009/9/12(土)〜13(日)にかけて京都で行われる、My Open Archive開発合宿&Kyoto Engineer BootCampに協賛することにしました。

My Open Archiveとは、名古屋の坂東慶太さんが、「埋もれた学術論文を掘り起こす!」という理念のもと、2年近くに渡って地道に活動されているWEBサービスです。

坂東さんは、もともと弊社で提供しているWEBアプリケーション「進学アクセスオンライン」のユーザということもあり、実はかなり古く(*1)からのおつきあいがあります。また、なんだか色々と話が合うので(*2)(*3)(*4)(*5)(*6)、僕自身も個人的に応援させていただいていました。

で、今回、

  • スタッフが全国に散らばっており、意思疎通がはかりにくい
  • 最近色々と熱い京都で何かエンジニアを巻き込んだイベントをしたい
  • もうすぐMy Open Archive2周年なんですよねー

など、色々な話をしているうちに、じゃ、うちが協賛しましょうか、うちのスタッフにも大きな刺激になると思いますので、とか話しているうちに話がまとまった、というわけです。

僕は個人的にMy Open Archiveのスタッフとなっていますので、12、13日両日参加、弊社開発スタッフは、12日夜のKyoto Engineer BootCampに参加させていただく予定です。

日頃、それほど積極的に外部のエンジニアと接触をもつことがない弊社開発スタッフも、今回のBootCampに参加させていただくことで、必ずや大きな刺激を得ることができるはずだと確信しています。

BootCampでは、

My Open Archiveの新機能リリースを発表する他、参加エンジニアによるライトニングトーク(LT)も行います。

とのことですので、僕もがんばってLT参加するつもりです。テーマは今のところ「SaaSで提供する法人向けWEBアプリの裏側」みたいな感じのことを考えています。BootCampの方は、追って一般公募があるみたいですので、興味のある方は是非お申し込みを!

では、また。

twitterはじめます

twitterはじめました。

http://twitter.com/tapweb

どうぞよろしくおねがいします。

サーバ構成などの話とデータセンターの引越計画

第1回目の記事。何を書こうかいろいろ考えたのですが、まずは、うちのサービスを提供しているサーバ環境などを簡単にご紹介したいと思います。

サーバの数や内訳などは以下のようになっています。(2009年8月現在)

  • サーバ約40台
    • うちDBサーバ(mysql)約15台
    • WEBサーバ約15台
    • 負荷分散装置(F5 Big-IP)2台
    • メールサーバ約4台(postfix、qmail、siellaエンジンなどを利用)
    • 指紋認証サーバ1台
    • その他のサーバ約5台
  • OSはほとんどがRedHat Linux
    • バージョンはES3〜ES5が混在
  • 関東某所のデータセンターにて運用

データセンターの利用を始めてから約5年が経ちますが、当初は1/2ラックだったのが現在では3ラック。なかなか感慨深いものがあります。

ところで、実は、現在利用させていただいているデータセンターが近々閉鎖することが決まっており、2010年夏をめどにサーバの引越を計画しています。もちろん、現存のサービスを停止するわけにはいきませんので、全体構成の見直しも含めて、相当綿密な計画が必要となってきます。どのような形で引っ越すのか、いくつかのオプションを現在比較検討中です。

まだ検討を始めている段階ですが、これはかなりのノウハウが蓄積できるぞ、と感じています。せっかくですので、公開できるものについては、できる限りこのブログで公開できればいいなと考えています。

8月からはサーバエンジニアとして新しいメンバーも入社してくることになっているのですが、タップでは引き続き、僕たちと一緒に働いてくれるスタッフを募集しています。

弊社はまだまだ規模の小さな会社ですが、運用しているサービスの規模は大きいです。ですので、ある程度の規模のサービスに、上流下流問わずにがっつり携わってみたいと考えている人にとっては、とてもやりがいのある仕事ではないかと思います。

少しでも興味をもたれた方は、採用情報のページをご覧の上、お気軽にお問い合わせください。

開発チームブログはじめます

どうぞよろしくお願いいたします。

Home

Search
Feeds

Return to page top