http://tanaka.sakura.ad.jp さくらインターネット創業日記: 2011年3月アーカイブ

2011年3月アーカイブ

先日発生した東北地方太平洋沖地震に際し、公的機関等のウェブサイトへのアクセスが集中し、サーバへの接続に支障が出ることが増えています。
そういった事態を解消すべく、ICT関連各社により負荷低減のための無償支援を致しております。

※50音順
※問い合わせ先は以下に記しています。

今回はその一例として、キャッシュサーバやミラーサーバを使った負荷低減方法を紹介いたします。
なお、この方法はサイト管理者の方の協力があれば非常に効果が高いものですので、接続の良くないサーバなどがありましたら、管理者の方に本ページを紹介頂ければ幸いです。

まず、アクセスが増えて接続できない状態を解説します。
以下の図のように、利用者からのアクセスが増えて、ウェブサーバや回線が圧迫されるために、アクセスが出来なくなります。

キャッシュサーバを使わない場合

それに対して、キャッシュサーバという専用のサーバを中継させることにより、負荷を軽減させるというのが今回の方式です。
以下の図のように、利用者からのアクセスをキャッシュサーバで受け付け、そのアクセスを取りまとめてウェブサーバに接続します。

キャッシュサーバを使う場合

利用するに当たっては、上記の事業者側でキャッシュサーバに登録を行い、サイト管理者様はドメイン名に割り当てられたIPアドレスをウェブサーバからキャッシュサーバへ変更するだけです。

以下のように、既存のウェブサーバをミラーする方法も提供可能です。

ミラーサーバを使う場合

担当の技術者の方へ

ご利用頂くには、ゾーン情報の変更をおすすめしています。
キャッシュサーバ、ミラーサーバのみを開設することも可能ですが、大元のウェブサーバのトラフィックが減らせない限り、有効性が低減されてしまいます。
Aレコード、もしくはCNAMEレコードを編集頂ければ幸いです。

お問い合わせ先は以下のとおりです。

※メールアドレスについては、at の部分を@に置き換えてください。

現状を少しでも解消するため、全面的な協力をさせて頂きますので、担当者の方にお知らせ頂ければ幸いです。

先日、東北地方において、大地震が発生致しました。
被災された方には、心よりお見舞い申し上げます。

この事態にあたり、インターネットサイトの多くがダウンしたり、繋がりにくい状態になっており、さくらインターネットにおいてもそのようなサイトをお手伝いすべく、大きな帯域の提供や、ミラーサーバ運用などを行っております。
既に、3月12日に私のTwitterを通じて公表しており、たくさんのサイトをお預かり致しておりますが、Twitterのみの情報となっておりましたので、改めて以下に掲載させていただきます。

  • サーバがなくて困っている方へ

  • さくらのVPSであれば、申し込み後、直ぐに無料で利用が開始できます。(だいたい30分くらい)
    ただし、無料期間中は2Mbpsの帯域制限がありますので、カスタマーサポート宛、もしくは私のTwitter @kunihirotanakaを通じて制限解除の依頼をいただければ、無料期間中でも帯域制限を解除致します。

    http://vps.sakura.ad.jp

    申し込みの際には、「振込み」を選んで頂ければ、料金がかかることはありません。
    ※クレジットカードを選択すると、2週間後に課金が開始されてしまいます。

    あと、1.5G 4G 8G の3プランは在庫が逼迫し始めていますので、512MBもしくは1GBのプランを選択頂ければ幸いです。

  • とりあえずホームページを立ち上げたい方

  • さくらのレンタルサーバについても、無料で利用が開始できます。(同じく30分くらい)
    この際に、アクセスが増えすぎると503エラーが出てしまいます。
    ついては、上記のVPSと同様に、問い合わせをいただければ制限を緩和致します。

    なお、申し込まれる際には、比較的アクセス耐性が強いプレミアムプランをおすすめします。

    http://www.sakura.ne.jp

  • ミラーサイトを作りたい方

  • ※これは、さくらインターネットで公式にサポートしているものではありません。

    http://tanaka.sakura.ad.jp/mirror/において、ウェブサイトのミラーを行っています。
    災害関係のサイトを運営されている方で、アクセスに問題がある場合には、上記のミラーシステムをご活用頂くことで、少しでもサーバ負荷を抑えられます。

なお、現在新規に受付しているサーバは全て大阪にあります。
よって、停電の影響はありません。
東京電力管内のサーバを一つでも減らせるよう、協力頂ければ幸いです。

現在、既に多くのサイトにご協力させて頂いておりますが、まだまだアクセスの出来ないサイトも多くございます。
ついては、この情報を広く伝えていただき、ひとつでもアクセスに問題がなくなれば幸いです。

現在、他の団体にも広がっています。
ぜひ、多くの皆さんにお伝え頂ければ幸いです。

さて、本日からさくらのVPSの上位プランが提供開始されました。
昨年9月に980円で提供を開始した際には大変大きな反響を頂き、既に9,000件を超えるお客様にご利用頂いていますが、さらに高いスペックが欲しいというご意見に答えるため、8GBまでのハイスペックプランをご用意しました。

ただ、クラウド型IaaSと違って移行作業が必要という制限があるため、今回は上位プランへの移行方法をまとめてみました。

手順は以下のとおりです。

  1. DNSのTTLを60にします。(これは事前に余裕を持って行って下さい)
  2. 新旧両方のサーバにrsyncをインストールします。
  3. 旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  4. 新サーバを再起動します。
  5. 旧サーバのhttpdやsendmailなどを停止します。(ここから7が完了するまでの間は外部からサーバ停止状態に見えます)
  6. もう一度、旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  7. DNSのAレコードを新サーバに向けるとともに、TTLを元に戻します。
  8. 旧サーバの解約を行います。(毎月20日が解約締切りなので要注意)

それでは開始しましょう。
今回は、CentOSをベースに話をすすめますが、多くのOSで同じ手順が使えます。

移行作業にあたって
  • コピーにあたってはrootでログインする必要がありますので、sshの設定を適切に行って下さい
  • 新サーバと旧サーバのOSは、必ず同じものにしてください。
    古いサーバが32bit OSで、新しいサーバが64bit OSだと不具合が発生します。
  • 古いサーバと新しいサーバを絶対に間違えないようにして下さい。
    間違えると、全てのデータを失う可能性があります
  • さくらインターネットで正式サポートしているものではありません。
    自己責任で行っていただきますようお願い致します。

  1. DNSのTTLを60にします。

  2. サーバ切り替えに先立って、該当するホスト名のTTLを60に設定します。
    これは、実際に切り替えをするときに、即座に変更されるようにするためです。

    さくらインターネットのネームサーバにおける例は、以下のブログ記事を参照してください。

    さくらインターネットでDNSのTTLを変更する方法

    まず、変更したいドメイン(ホスト名)をdigコマンドで調べます。
    以下の例の場合は、TTLが3600に設定されているので、サーバ移転の3600秒前(1時間前)までに、この操作を行う必要があります。


    [root@localhost ~]# dig vps2.????.jp.

    ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> vps2.????.jp.
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62579
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;vps2.????.jp. IN A

    ;; ANSWER SECTION:
    vps2.????.jp. 3600 IN A 59.106.183.??

    ;; Query time: 3 msec
    ;; SERVER: 210.224.163.4#53(210.224.163.4)
    ;; WHEN: Mon Mar 7 20:09:25 2011
    ;; MSG SIZE rcvd: 47

    [root@localhost ~]#

    無事変更が出来れば、以下のとおりTTLが60になるのがわかります。


    ;; ANSWER SECTION:
    vps2.????.jp. 60 IN A 59.106.183.??

    ※自分のネームサーバでTTLが60になっていたとしても、他のネームサーバではキャッシュされたままの可能性があります。変更前のTTLで示された時間(上記の例だと3600秒間)は待つのが懸命です。

  3. rsyncのインストール

  4. 恐らく、さくらのVPSでのCentOSデフォルトではrsyncがインストールされていると思います。
    rsyncと入力してコマンドがなければ、yum install rsync とすれば結構です。

  5. ファイルのコピー

  6. 今回の手順では、サーバの停止時間を極力短くするために、旧サーバ停止前にコピーを行い、停止後に再度コピーを行うこととしています。
    2回目のコピーは差分だけですので、比較的短時間でコピーが完了します。

    コピーにはrsyncとsshを利用します。
    rsyncのオプションは以下のとおりです。

    オプション動作内容
    -rディレクトリ内容を再帰的にコピーします
    -t更新日時を保持します
    -lソフトリンクを保持します
    -z転送時に圧縮します
    -v饒舌になります
    -o所有者を保持します
    -gグループを保持します
    -pパーミッションを保持します
    -Hハードリンクを保持します
    -AACLを保持します
    -X拡張パーミッションを保持します
    --deleteファイルの削除を容認します
    --exclude除外するファイルの名前を指定します
    --block-size=チェックサムをとる際のブロックサイズを指定します
    -e sshssh経由でコピーします

    なお、今回のコピーにあたって、いくつかのファイルとディレクトリを除外しています。除外したファイルは、IPアドレスの設定を行なっているファイルと、sshのホストキーが含まれているファイル、そしてファイルシステムを指定しているファイルです。
    除外すべきファイルはOSによって異なりますので、ご注意下さい。


    # rsync -rtlzvogpHAX --delete --exclude /dev/ --exclude /proc/ --exclude /sys/ --exclude /var/run/ --exclude /var/lock/ --exclude ifcfg* --exclude ssh
    _host_* --exclude fstab --block-size=4096 -e ssh / 49.212.21.??:/
    root@49.212.21.??'s password:
    building file list ... done

    色々出てくる

    sent 2083607 bytes received 3212 bytes 379421.64 bytes/sec
    total size is 1705349185 speedup is 817.20

    これでコピーが完了しました。
    コピー時間は、どれだけのコンテンツやファイルがあるかにより、大きく変わります。

  7. 新サーバを再起動します。
  8. 新サーバを再起動すれば、古いサーバの設定を引き継いだ形で動作を開始するはずです。

  9. 旧サーバのhttpdやsendmailなどを停止します。
  10. 旧サーバで動作している全てのサービスを停止させます。
    例えば、httpdやsendmail、mysql-serverなどのことです。
    service httpd stop などと入力して、停止させましょう。

    この時点で、外部の人はこのサーバへアクセスできなくなります。

  11. もう一度、旧サーバから新サーバへrsyncを使ってファイルをコピーします。
  12. 旧サーバがサービスを停止したことを確認して、再度コピーを行います。
    2回目なので、さほど時間はかからないと思います。


    # rsync -rtlzvogpHAX --delete --exclude /dev/ --exclude /proc/ --exclude /sys/ --exclude /var/run/ --exclude /var/lock/ --exclude ifcfg* --exclude ssh
    _host_* --exclude fstab --block-size=4096 -e ssh / 49.212.21.??:/
    root@49.212.21.??'s password:
    building file list ... done

    色々出てくる

    sent 2096209 bytes received 920 bytes 220750.42 bytes/sec
    total size is 1705349185 speedup is 813.18

  13. DNSのAレコードを新サーバに向けるとともに、TTLを元に戻します。
  14. 新しいサーバに向けてIPアドレスを変更します。
    それと同時に、先ほど60にしたTTLをもとに戻します。

    ※TTLが60のままだと、キャッシュがされないためにサイトへのアクセスが非常に遅くなります。

    この作業が完了して60秒以上経てば、外部から新サーバへのアクセスが可能になります。

  15. 旧サーバの解約を行います。(毎月20日が解約締切りなので要注意)
  16. 数日間状況を見て、旧サーバの解約を行います。
    なお、さくらインターネットの場合には、解約前月の20日までに解約申請をしなければなりません。
    例えば、3月20日までに解約申請すれば4月末での解約となりますが、これを過ぎると1ヶ月間無駄に支払わなければならなくなるので注意してください。

以上が移行手順です。

是非皆様も上位プランで充実したVPSライフをお送り下さい。

※掲載直後にTTLを0にという記述をしておりましたが、適切ではないのでは無いかという指摘を頂き、TTLを60にと変更しています。ご指摘ありがとうございました。

日々のサーバ運用を行う中で、サーバ移転を行いIPアドレスが変更される機会は少なくありません。
しかし、DNSがなかなか反映されず「浸透しない」とつぶやかれている人をよく見かけます。
これは事前にTTLを小さくしていないために発生する問題ですが、今回はさくらインターネットを例に、DNSのTTLを変更する方法を解説します。
なお、ここで解説しているのは個別のレコード(Aレコード)を変更する時だけであり、ドメイン自体の移転などNSの変更の際に有効な手段ではありませんのでご注意下さい。

さて、DNSの場合は分散してサーバが設置されています。
そのため、DNSの情報が反映されることを「浸透」と表現されることが多いのですが、電子メールのようにサーバを中継してリレーしていくわけではありませんので、決して浸透していくわけではありません。
実際にはネームサーバとクライアントの間のどこかでキャッシュされていて、しばらくの間設定が反映されないために起こる現象です。
DNSは分散されているため、ドメイン管理者側ではどのネームサーバでキャッシュされているかがわかりませんし、当然のことながら世界中のネームサーバのキャッシュをクリアするわけにもいきません。
そのためクライアントによってアクセスが出来なかってもただ待つしかなく、なかなか反映されないとやきもきする事態に陥るわけです。

DNSの仕組み

これを回避する方法はひとつであり、TTLを短くして事前にキャッシュの有効期限を短縮しておくことです。
ただし、TTLは短くても1時間、長ければ24時間以上に設定されていることもあり、事前に余裕を持って行っておかなければなりません。
一番理想的な手順は、作業開始時間から「TTLで示された時間分」だけ先にTTLを変更しておき、サーバ移転と同時にDNSのIPアドレスレコードを書き換え、TTLをもとに戻すという形です。
例えば、デフォルトのTTLが86400と指定されているなら、サーバ移転の24時間前までに作業を行う必要があります。

それではTTLの解説はこれくらいにして、さくらインターネットでのTTL操作を見てみます。

会員メニューにログインし、「契約情報」をクリックします。
会員メニュー: https://secure.sakura.ad.jp/menu/

「ドメインメニュー」へ進みます。

ドメインメニューから、設定変更したいドメインの「ゾーン設定」をクリックします。

ゾーン表示をしている画面で、「変更」をクリックします。

変更したいエントリーのデータをクリックし、フォームにおいてTTLを入力して、「変更」ボタンをクリックします。
「TTLの指定」という項目で、チェックボックにチェックをすればテキストボックスが表示されますので、TTLを60にするときはこの項目に60と入力します。

新しい項目が付加されれば、「データ送信」をクリックして、作業を完了させます。

問題なく完了すれば、データの項目にTTLが表示されます。

ここまでの作業が完了すれば、ほぼリアルタイムにネームサーバ情報が更新されます。
例えば、以下のようにdigコマンドを実行することによってネームサーバの情報が更新されているかどうかを確認できます。
以下の例では、「ANSWER SECTION」という項目にて、「60」と表示されているのがわかります。


# dig test.????.jp. @ns1.dns.ne.jp

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> test.????.jp. @ns1.dns.ne.jp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35987
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;test.????.jp. IN A

;; ANSWER SECTION:
test.????.jp. 60 IN A 210.155.1.1

;; AUTHORITY SECTION:
????.jp. 3600 IN NS ns1.dns.ne.jp.
????.jp. 3600 IN NS ns2.dns.ne.jp.

;; Query time: 1 msec
;; SERVER: 210.188.224.9#53(210.188.224.9)
;; WHEN: Tue Mar 8 16:14:15 2011
;; MSG SIZE rcvd: 89

なお、TTLを個別に指定しない場合には、最小TTLが使用されます。
上記の例では、ゾーン編集画面にて「最小TTL 3600秒」と表示されているので、TTLを0にする前は3600だったことがわかります。
すなわち、サーバによっては3600秒間キャッシュが残ることになりますので、原則論で言うと3600秒間は完全には「浸透」しないことになります。
ちなみに、昔のドメインの場合には86400秒(24時間)というのも多く、自身のドメインがこのような設定の場合には24時間待つ必要があります。

デフォルトのTTLで示された秒数経過後に、サーバの移転を行い、TTLをデフォルトに戻せば作業完了です。
TTLをデフォルト値に戻さなければ、キャッシュが居つまでも無効化されることになり、サイトへのアクセスが非常に遅くなる可能性があります。
その為、作業完了後にはTTLをデフォルト値に戻すことを忘れないようにしてください。

自己紹介

本名:田中邦裕/1978年生まれ
1996年にさくらインターネットを創業しホスティングサービスを開始。 98年に有限会社インフォレスト(2000年に解散)設立後、翌年にさくらインターネット株式会社を設立して社長に就任。
05年に東証マザーズに上場
kunihirotanakaをフォローしましょう

このアーカイブについて

このページには、2011年3月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2011年2月です。

次のアーカイブは2011年5月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

Powered by Movable Type 5.04