さくらのクラウドと、レッドオーシャン戦略

ブルーオーシャン戦略。
まだ開拓されておらず競争が無い新たなマーケットをブルーオーシャンと呼び、価格をはじめとした血みどろの戦いをしなければならないマーケットをレッドオーシャンと呼びます。
なら、レッドオーシャンを泳ぐより、ブルーオーシャンを泳いだほうが良いじゃないかということ。
これは欧州経営大学院教授のW・チャン・キムとレネ・モボルニュが著したビジネス書で述べられたもので、日本ではランダムハウス講談社から「ブルー・オーシャン戦略 競争のない世界を創造する」として出版されています。
例えば、10分1000円のQBハウスは他の理容店と血みどろの戦いをしているように見えつつ、スピードという差別化要因によって顧客数と業績を伸ばし、実はブルーオーシャンのプレイヤーなのだということが示されています。
これ以上の内容については当該書籍に任せるとして、先日#cloudmixや#yakocloudにて私が発言した「さくらのクラウドにおいて、レッドオーシャンを泳ぎきるというのが戦略」という事について述べてみたいと思います。

さくらのクラウドは、昨年11月に開催されたクラウドエキスポにおいて「何の変哲もないIaaS型クラウドを圧倒的なコストパフォーマンスで提供する」というキャッチで発表をしました。
IaaS型クラウドにおいては、これから競争が激化することが考えられ、各社高付加価値化による差別化を考えている中にあるわけですが、当社はあえて「低付加価値戦略」というのを提起したいと思っています。

アメリカの国立標準技術研究所が発表した「クラウド定義」というものがありますが、それに対する「さくらのクラウド(IaaS)」の解は以下のとおりです。

  • マルチテナント

  • 当社の用意するシステムを共用しコストをシェアして頂くことで、安価かつ大規模、高信頼なシステムを利用頂けます。
  • すばやい増減

  • 数十秒でサーバやストレージを用意したり、解約したりできます。
  • オンラインアクセス

  • 日本一のバックボーン容量の回線を経由し、高速かつクライアントに依存しないアクセスを保証します。
  • 見える化

  • 利用状況を常に把握でき、適切なシステムサイズを判断できます。
  • セルフサービス

  • お客様自身でサーバは当然のこと、ネットワークを含めて自由に設計ができ、全て自動化されています。

私たちの解は、高性能で安定性の高いサーバを安価に提供され、それを自由にネットワーク化でき、使いやすいコンパネ or API で即座に増減できればいいじゃないかというものです。
これはクラウドの定義からまったくぶれていないつもりです。
自動でスケールアップしないし、サーバの中身を管理しないし、メールの大量配信機能も無ければ、CDNも備わっていません。いわば付加価値と呼ばれるものを一切付けず、必要なもの「だけ」を用意したのが「さくらのクラウド(IaaS)」です。
「必要なときに必要なだけ」がクラウドだったはずが、「付加価値」「高機能」というキーワードを元に、必要の無いものに費用を負担させられるのが今のクラウドを取り巻く状況だと思っています。
事業者から見ても、いろいろとライセンス料や運用コストを払って付加価値を用意し、開発コストを払って高機能を付けながら、結局値段競争に入ってコストが回収できないかもというつらいところです。
そもそも付加される価値や機能の多くは事業者間で似通ったことになっており、結局差別化要因にならないということも併せてつらいところです。
むしろ、付加価値を用意せずに、パートナーがAPIを通じて価値・機能を付加して、ともにビジネスが成長する状況にしたいと思っていますし、付加価値向上にヒト・モノ・カネを突っ込むよりは、パートナーに手厚い技術サポートをしたほうが良いと考えています。

こう見ると、私たちのような「高性能、高安定性、低価格」+「拡張性」に徹した日本のIaaSは少なく、タイトルではレッドオーシャンと書きましたが、実際には意外とブルーオーシャンだと考えています。
当たり前のもの(ちゃんとしたもの)を安価に売るというのは、日本のお家芸だと思います。
日本らしいクラウドというのは世界中で売られる車のように、決して品質が悪いわけでもなく、極めてコストパフォーマンスに優れたものにすべきだと思っています。

この戦略は当たり前のように見えますが、みんなやっていないし、少なくとも大規模低コストデータセンター、自社製基盤システム、万単位のサーバの運用ノウハウなど、他社がまねたとしても数年はかかるでしょうし、その間にしっかりとシェアをとり、本当にレッドオーシャンになったときに先行者として強みを持つという形が「本当の戦略」です。
恐らくは、スケールの大きいIaaS事業者と、それを活用する付加価値に強みを持つインテグレーターに二分されるのでしょう。当社としては前者が目標です。

ところで、cloudmixではトイレットペーパーの例を出しました。
「トイレットペーパーを半額にしたからといって、倍の数を買うでしょうか?買わないですよね」という話でした。
もし気合を入れて倍使ったら、お尻が痛くて大変です。
そういった日用品(コモディティ)市場においては、高付加価値化で顧客単価を上げ、トップラインを増やすというのが当然の戦略です。
食料品なども一緒で、とにかくお尻も胃袋も倍の数/量にはなりません。
ましてや、ウォシュレット(シャワートイレ)の登場や、ダイエットの流行など、決して追い風ではありません。

ただ、サーバは安価になればもっと買ってくれるというという世界が待っています。
例えばさくらのVPS 980は、専用サーバ7,800円/月の新規契約を奪いましたが、従来の10倍以上の新規申し込みを受けており、1年で2万を超えるインスタンスが稼働中(解約を差し引いた純稼動数)ですし、上位プラン比率も高まってきました。
コンピューティングリソースが更に安価に、更に使われる世界がくると思っていますので、価格が下がることは市場の縮小を意味するものではないと思うのです。
(といいつつ、月額千円を切るようなIaaSを出すツモリはなく、「絶対価格」を下げることに意味は無いと思いますが...)

elleair.jpg
ところで、私の嫁がタイムリーに「トイレットペーパー買いすぎたー!」と言ってきました。
Amazonの定期便で見積もりを誤ったようで、まだ在庫があるのに送ってきたという話です。
そこで「いっぱいつかわな無くならへん。」と一言。「いや違うやろ」と突っ込み。場所以外困ること無いから、無理して使わなくていいだろうと。
しかしまあ、自宅のトイレットペーパー在庫を増やさせる or 定期的に送りつける戦略は、日用品における良い回答かもと思った瞬間でした。
クラウドではなく、我が家の日用品から攻めてくるとは、恐るべきAmazonさん。機関の陰謀ですね。

と、オチがついたところで。

ちなみに、IaaSだけでなくPaaSやSaaSに対する戦略もありますが、それは機会が来たときにということで。個人的にはPaaSがさくららしさを表現できるステージだと思っています。

satoru.net様からの質問と回答について

  • 投稿日:
  • by

さくらインターネット、HDD故障時に有償請求という記事において、satoru.net様より私の見解を求むと連絡頂きましたので、このエントリーを書かせて頂きます。
詳しくは上記のリンクからご覧頂くとして、経緯だけまとめてみます。

1. お客様の専用サーバのHDDにおいてIO Errorが発生したため、当社へ連絡を頂く
2. 当社側で、すぐにハードウェア交換をご提案する(無償対応)
3. HDD以外のハードウェア交換をしたものの、HDDが認識しなかったため、HDDの交換とOS再インストールをご提案する(無償対応)。
4. その上で、壊れたHDDを接続することもご提案する(5,250円の有償対応)。
5. 壊れたHDDの接続を無償で出来ないのかという連絡を頂く
6. データについては保証しかねるので、(サルベージ等に係る作業については)有償で対応させて頂きたいとご連絡。

この対応について、前述のブログ記事とともに、私のツイッターアカウントへmention頂いたというものです。

この件について、satoru.net様と各種ソーシャルメディアで述べられていることに対する、私≒さくらインターネットの見解は以下の通りです。

  • 当然のことながら「不良HDDを提供した」というつもりはない。(HDDが結果として故障することは一般に知られており、エイジングは行っているものの、絶対に故障させない保証は非常に困難です。)
  • バックアップサービスやRAIDなども用意しており、(お願いベースですが)バックアップは行って頂きたい。
  • データセンターのサーバでは、通常のパソコンのようにホイっとセカンダリを接続できるものでもない(専用サーバラック内ではセカンダリHDD用の場所が確保できず、旧HDD接続サービス用のサーバを用意しています)。
  • 旧HDD接続サービスは約款に記載したうえ、ウェブ上において金額、フローとも紹介している。
    案内: http://www.sakura.ad.jp/function/maintenance/hdd-attach.html
    約款: http://www.sakura.ad.jp/agreement/[a]yakkan3_dedicated.pdf
  • ただし、HDD接続は当社側でしかできない作業であり、無償で行ったほうがよいと思う。

私としても、ハードウェアの無償交換等は当然と考え行っておりますが、データの復旧にかかわる部分についてはバックアップやRAID、冗長化などを行って頂いているお客様がおられる以上、そのコストを基本価格に転嫁したくないというのが本音です。
しかし同時に、現地でしかできない作業については、出来るだけ無償化したいという想いもあります。
このような中、今回の件については、当社が行わなければお客様側でどうしようもないというものであり、リブートなどと同様に無償化するべきだと考えました。

ということで、satoru.net様のブログ記事で提案頂いた形で、旧HDD接続サービスについては、これまでは有料だったものを、明日から無料(一週間)へと変更することとしました。
急遽決めたことなので、約款やウェブサイト等の修正はこれから行います。
satoru.net様についても、返金 or 充当等の対応をさせて頂きます。

最後に言い訳がましいのですがやはり述べておきたいのは、今回の対応についてはHDD故障の責が当社にあるという認識ではなく、あくまでも現地でしか出来ない作業をなるべく無償にして、お客様の金銭的なご負担を少なくしたいという想いからです。
さらっと「無償にしました!」とだけ書いてもよかったのですが、私の見解、想い、背景、判断基準などを知ってもらいたいと思って、長々と書かせて頂きました。

なお、ご意見頂きました satoru.net様には、ご利用頂いていることに対する感謝はもちろんのこと、貴重なご意見を頂きました事に大変感謝しております。
今後とも、様々な事柄について改善に努めたいと思いますので、さくらインターネットをよろしくお願い致します。

ウェブ開発者のための、1時間でできるLAMP環境構築術(CentOS編)

  • 投稿日:
  • by
  • Category:

最近、さくらのVPSやServersmanなど格安のVPSサービスや、Amazon Web ServicesやNiftyクラウドに代表されるクラウドサービスなどの台頭により、以前よりもサーバを使うことのハードルが下がりました。
そのためウェブ開発者がサーバの運用に関わる機会が増えていますが、ApacheやMySQL、PHP(Perl)などのいわゆるLAMP環境を作るには、意外と手間がかかることに気づかされます。
そこで、今回は1時間で出来るサーバセットアップを目標に、LAMP環境構築のチュートリアルとまとめました。

この手順においてはCentOSの基本的な設定が完了しているものとします。
参考:CentOSをサーバーとして活用するための基本的な設定(さくらインターネット創業日記)
なお、この記事はCentOS 5 もしくは CentOS 6 の64ビット版をベースに書いていますので、これ以外のOSの場合には適宜読み替えて下さい。

CentOS 最新版へのバージョンアップ

今回の作業を行うにあたって、対象サーバがCentOS 5.5であったため、yum upgradeを実行して CentOS 5.6へバージョンアップしました。
現在(2012/5/7)の最新バージョンは、CentOS 5.7 もしくは CentOS 6.2 です。バージョンアップを行うと、それぞれ最新版のCentOSへとアップデートされます。
すでにCentOS 最新版の場合には以下の作業は行わなくてもかまいません。

[root@ ~]# rpm -qa | grep centos-release
centos-release-notes-5.5-0
centos-release-5-5.el5.centos
[root@ ~]# yum upgrade -y
Loaded plugins: fastestmirror
Determining fastest mirrors
色々出てくる
Total download size: 162 M
Downloading Packages:
色々出てくる
Importing GPG key 0xE8562897 "CentOS-5 Key (CentOS 5 Official Signing Key) " from /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[root@ ~]# rpm -qa | grep centos-release
centos-release-notes-5.6-0
centos-release-5-6.el5.centos.1 ← CentOS 5.6へとアップグレードされた


yumのリポジトリ追加

yumとは各種ソフトウェアをパッケージという単位にして、簡単にインストール・アンインストールするための仕組みのことです。
リポジトリを追加することによって、パッケージのダウンロード元サイトを増やし、インストールできるソフトウェアのバリエーションを増やすことが可能です。
標準のリポジトリではPHPの最新バージョンなどが用意されていませんので、今回は Fedora EPEL 、remi、RPMForge という3つのリポジトリを追加します。

はじめに、Fedora EPELのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

CentOS 6 の場合

[root@ ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm

※download.fedora.redhat.comに繋がらない場合には上記の通りdl.fedoraproject.orgに変更すればダウンロードできます。

上記のファイルが無くなっている場合には、次のURLからepel-release-で始まるファイルを探してダウンロードして下さい。
http://dl.fedoraproject.org/pub/epel/5/x86_64/ (CentOS 5)
http://dl.fedoraproject.org/pub/epel/6/x86_64/ (CentOS 6)

次にremiのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm

CentOS 6 の場合

[root@ ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

上記と同様に、ファイルが利用できない場合には、以下のURLからダウンロードして下さい。
http://rpms.famillecollet.com/

最後に、RPMForgeのダウンロードを行います。

CentOS 5 の場合

[root@ ~]# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

CentOS 6 の場合

[root@ ~]# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

上記と同様に、ファイルが利用できない場合には、以下のURLからダウンロードして下さい。
http://dag.wieers.com/rpm/packages/rpmforge-release/

それでは、3つのリポジトリを追加します。

CentOS 5 の場合

[root@ ~]# rpm -Uvh epel-release-5-4.noarch.rpm remi-release-5.rpm rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

CentOS 6 の場合

[root@ ~]# rpm -Uvh epel-release-6-7.noarch.rpm remi-release-6.rpm rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm


リポジトリが追加できたら、それぞれのリポジトリをいったん無効化します。
具体的に言うと、設定ファイルのenabledという項目を0に変更し、yum実行時に明示的に指定されない限り、新たに追加したリポジトリが利用されないようにします。
ちなみに、remiはもともとenabled=0となっているので、Fedora EPELとRPMForgeのみviコマンドで編集します。
※意図せず、標準外のリポジトリ(今回追加したリポジトリ)が使われないための対策です。

vi /etc/yum.repos.d/epel.repo

[epel]
name=Extra Packages for Enterprise Linux 5 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=0 ← 1を0に変更
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

vi /etc/yum.repos.d/rpmforge.repo

[rpmforge]
name = RHEL $releasever - RPMforge.net - dag
baseurl = http://apt.sw.be/redhat/el5/en/$basearch/rpmforge
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled=0 ← 1を0に変更
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

これでリポジトリの追加作業は完了です。

パッケージのインストール

それでは、パッケージのインストールを行います。
次のコマンド一発でインストールが開始され、途中で「y」を2回入力すれば、一気にLAMP環境を作られます。
今回は、追加したリポジトリが利用されるよう、--enablerepo オプションを付けています。

[root@ ~]# yum --enablerepo=remi,epel,rpmforge install httpd-devel php-devel php-pear mysql-server phpmyadmin -y
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

・・略・・

Total download size: 42 M
Downloading Packages:

・・略・・

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 00f97f56
remi/gpgkey | 1.3 kB 00:00
Importing GPG key 0x00F97F56 "Remi Collet " from /etc/pki/rpm-gpg/RPM-GPG-KEY-remi

Running rpm_check_debug

今回インストールしたモジュールを一覧にしました。

モジュールアーキテクチャバージョンリポジトリ
apr-develx86_641.2.7-11base
apr-util-develx86_641.2.7-11base
cyrus-sasl-develx86_642.1.22-5base
db4-develx86_644.3.29-10base
expat-develx86_641.95.8-8.3base
httpdx86_642.2.3-45base
httpd-develi3862.2.3-45base
httpd-develx86_642.2.3-45base
libeditx86_6420090923-3.0_1rpmforge
libmcryptx86_642.5.8-4extras
libtool-ltdlx86_641.5.22-7base
mysqlx86_645.5.11-1remi
mysql-libsx86_645.5.11-1remi
mysql-serverx86_645.5.11-1remi
mysqlclient15x86_645.0.67-1remi
openldap-develx86_642.3.43-12base
perl-DBD-MySQLx86_643.0007-2base
perl-DBIx86_641.52-2base
phpx86_645.3.6-3remi
php-clix86_645.3.6-3remi
php-commonx86_645.3.6-3remi
php-develx86_645.3.6-3remi
php-mbstringx86_645.3.6-3remi
php-mcryptx86_645.3.6-3remi
php-mysqlx86_645.3.6-3remi
php-pdox86_645.3.6-3remi
php-pearnoarch1.9.2-3remi
phpmyadmin.noarch2.11.11.3-1rpmforge

これで、インストールは完了です。


Apacheの設定 - モジュール編

それでは、Apacheの設定に移ります。
Apacheの設定は、/etc/httpd/conf/httpd.conf というファイルを編集して行いますが、モジュールの設定と、同時接続数の設定に分けて、順に見ていきましょう。

まずはモジュールの設定です。Apacheの場合、さまざまな機能を「モジュール」という形で用意しています。
モジュールを増やせばたくさんの機能を利用できますが、その反面メモリを大きく消費してしまうという問題があります。
CentOSのデフォルト状態では、ほぼ全てのモジュールが有効になっているため、必要以外のモジュールを除外する必要があります。

例えば、一切モジュールを消さないデフォルトの状態だと、1プロセスあたり5MB程度のメモリを消費していることが分かります。

#  ps aux|grep -v Ss|grep '[h]ttpd'|head -1
apache 22523 0.0 0.4 257548 5036 ? S 12:27 0:00 /usr/sbin/httpd

これを適切に設定しなおすと、4MB程度まで減らせます。
1プロセスあたり1MB省略できれば、200プロセスで200MB削減できることになりますし、実際にリクエストを受け付けているプロセスの場合はさらに消費メモリの差が出ることになります。

#  ps aux|grep -v Ss|grep '[h]ttpd'|head -1
apache 24715 0.0 0.4 161716 4228 ? S 19:46 0:00 /usr/sbin/httpd

とはいえ、どのモジュールが必要なのかが分かりにくいので、モジュールの一覧と、私の勝手な重要度をまとめました。
重要度は、◎、○、△、+、の4種類で分類しており、一覧にある重要度のタイトルをクリックすると、フィルターすることも可能です。
◎=必須
○=あったほうが良い
△=必要ならあればよい
+=必要性なし

モジュール名コメント
mod_auth_basicベーシック認証
mod_auth_digestダイジェスト認証
mod_authn_file認証にテキストファイルを利用する
いわゆる.htpasswdを使う場合は必要
mod_authn_alias
mod_authn_anon匿名ユーザを認証する
mod_authn_dbm認証にDBMファイルを利用する
mod_authn_default
mod_authz_hostホスト/IPアドレスでのアクセス制限
Orderや、Allow from ?? を使う場合は必須
mod_authz_userユーザ名でのアクセス制限
mod_authz_ownerファイル所有者でのアクセス制限
mod_authz_groupfileグループでのアクセス制限を行う(テキストファイル)
mod_authz_dbmグループでのアクセス制限を行う(DBMファイル)
mod_authz_default
mod_ldapLDAP用の基本モジュール
mod_authnz_ldapLDAPでのアクセス制限
mod_includeSSIを提供
SSIを利用する場合は有効にする
mod_log_configログ保存
アクセスログをとるためには必須
mod_logio送受信バイト数のログ保存(このモジュールがなければ保存できない)
mod_envCGIやSSIでの環境変数を設定する
必要なければ無効でかまわない
mod_ext_filterデータ返送時に外部プログラムを経由させる
mod_mime_magicファイルの内容をベースにMIMEタイプ決定
mod_expiresExpireヘッダをセットする
mod_deflateデータ返送時に圧縮する
mod_headersリクエスト、レスポンスヘッダを制御する
必要なければ無効でかまわない
mod_usertrackクッキーでユーザ追跡を行う
mod_setenvif環境変数の制御を行う
無効でもかまわないが、標準の設定ファイルで利用されており、有効にするのが無難
mod_mime拡張子をベースにMIMEタイプを決定
mod_davWebDAVを提供
mod_status/server-statusにてサーバ状態を表示する(URLは変更可能)
mod_autoindexディレクトリへのアクセス時にファイル一覧を作成する
mod_info/server-infoにてサーバ設定を表示する(URLは変更可能)
mod_dav_fsWebDAVを提供
mod_vhost_aliasバーチャルホストを簡単に生成
mod_negotiationクライアントに適したファイルを自動判別する(.jaなど)
mod_dirディレクトリの取り扱いを行う(index.htmlの取り扱いなど)
mod_actions特定の拡張子へのリクエストに応じてCGIを実行する
mod_speling大文字小文字を同じように扱えるようにする
mod_userdirユーザのホームディレクトにアクセスできるようにする(チルダ形式など)
mod_aliasAliasやRedirectを利用できるようにする
mod_rewriteRewrite機能を提供する
mod_proxyProxyを提供する
mod_proxy_balancerProxy時に負荷分散機能を提供
mod_proxy_ftpProxy時にFTP接続機能を提供
mod_proxy_httpProxy時にHTTP接続機能を提供
mod_proxy_connectProxy時にCONNECT機能を提供
mod_cacheキャッシュを提供
mod_suexecsuexecを提供
mod_disk_cachecache_moduleにおいて、ディスクキャッシュを提供
mod_file_cache静的ファイルをメモリにキャッシュさせる
mod_mem_cachecache_moduleにおいて、メモリキャッシュを提供
mod_cgiCGIを提供
mod_versionクライアントへのレスポンスにApacheバージョンを挿入する


※注意点
以下のモジュールを無効にすると、標準の設定ファイル(/etc/httpd/conf/httpd.conf)のまま起動するとエラーとなります。

  • mod_authz_hostを無効にした場合には、OrderやAllowなどの項目(例えば332行目など)をコメントアウトする必要があります
  • mod_proxyを無効にした場合には、以下ようにコマンドを実行し拡張設定ファイルを無効化する必要があります
  • # mv /etc/httpd/conf.d/proxy_ajp.conf /etc/httpd/conf.d/proxy_ajp.conf.stop
  • mod_autoindexを無効にした場合には、IndexOptionsから始まる関連項目(例えば592行目?657行目)を全てコメントアウトする必要があります
    もしくは以下のとおり、<IfModule>で括ってしまう方法もあります
  • vi /etc/httpd/conf/httpd.conf
    <IfModule mod_autoindex.c>
    IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable
    ・・略・・
    IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
    </IfModule>

ちなみに、私はいつも以下のモジュールを有効にしています。
なお、mod_autoindex と mod_proxy を無効化していますので、前述のとおり設定を変更しなければエラーとなって起動しません。

LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule status_module modules/mod_status.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so


Apacheの設定 - 同時接続数編

それでは、Apacheの同時接続数の設定を見ていきましょう。
ここで基本を押さえておきたいのですが、Apacheにはpreforkとworkerという大きく分けると2つの方式があります。
preforkはサーバ1つ(1プロセス)で1つのリクエストを処理し、workerはサーバ1つで複数のリクエストを処理できます。
一見、workerのほうが良いように見えますが、workerはマルチスレッドで実装されていることから、ライブラリ全てがマルチスレッドに対応している必要があります。
ただ、PHPを使う場合にはライブラリ全てがマルチスレッド対応か否かを検証することは難しく、余計なトラブルを避けるためにもpreforkを利用するのが賢明であるといえます。
ということで、今回はpreforkを使う前提で説明を行います。

標準のhttpd.confでは、以下のように設定されています。

<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

これらを順に見てみましょう。

  • StartServers
  • Apache開始時に立ち上げておくべきサーバ数。
    Apache起動直後は、ここで指定した数のサーバが立ち上がる。
  • MinSpareServers
  • アイドル中のサーバ数の下限。アイドル中とは、リクエストに対して即座に対応できる状態(つまり処理していない)のこと。
    ここで指定したサーバより少なくなった場合は、新たなサーバを立ち上げる。
    この数値が小さすぎると、急激にアクセスが増えたときに、リクエストに受けきれなくなる。
  • MaxSpareServers
  • アイドル中のサーバ数の上限。
    ここで指定したサーバより多くなった場合は、余計なサーバを終了させる。
    この数字が大きすぎると、アクセスが落ち着いている状態でもサーバが終了されず、メモリが無駄に消費されることになる。
  • ServerLimit
  • 後述するMaxClientsに指定できる数字の上限を指定する。
    MaxClientsを256より大きな数字にするとき以外は、特に変更の必要はない。
  • MaxClients
  • サーバ数の上限。
    ここで指定した数以上のサーバは立ち上がらない。
  • MaxRequestsPerChild
  • 処理できるリクエストの上限数。
    処理したリクエストがここで指定した数を超えると、該当サーバは終了される。

文字ではなかなかピンと来ない方も多いと思うので、グラフでまとめてみました。
このグラフでは見やすくするため、MaxClients 30、StartServers 10、MinSpareServers 5、MaxSpareServers 20としています。

apache-20110514.png

1起動直後であり、StartServersで指定された10サーバが立ち上がっている
210サーバが接続中でアイドル状態のサーバが0となったため、MinSpareServersに指定された5サーバが追加される
320サーバが接続中で上記と同じくアイドル状態サーバが0となったため、さらに5サーバが追加される
4アイドル状態のサーバが0になったものの、MaxClientsで指定された30サーバになったため、新規サーバは追加されない
5-7MaxClientsを超える数の接続がきたため、30の上限を超えるリクエストは、空きが出るまでまで待たされる
9-10アイドル状態のサーバ数は5以上20以下であり、新たなサーバの起動や、余剰サーバの終了処理は行わない
1130サーバがアイドル状態となったため、MaxSpareServersで指定された20サーバにすべく、10サーバが終了させられた


それでは、実際にどのような数字を設定すればいいか、考えて見ましょう。
一番重要なのはMaxClientsです。これが決まれば、上記の法則を見て他の値も決定してください。
たくさんのリクエストを受け付けるためには、大きな数値にすればよいと考えられがちですが、メモリやCPU能力が十分でなければ、むしろパフォーマンスが低下します。
経験則では、PHPを稼動させるApacheは1サーバあたり10MBから30MB程度のメモリを消費します。
例えば、Apacheで利用するメモリ容量を500MB程度に抑えたければ、20から40程度の数値にしておくのが無難です。

以下の例は、MaxClientsが256のときと、20のときで、どのように挙動が変わるかをabで図ったものです。

# ab -c 100 -n 2000 http://49.212.??.??/phpmyadmin/

MaxClientsが256の場合は、スワップを大きく消費しているほか、ロードアベレージも大きく上がっており、SSHのレスポンスについても非常に悪化していました。
それに対し20の場合は、それほど負荷の上昇は見られず、計測時間、秒間処理数、リクエストにかかる秒数の全てにおいて、改善していることが分かります。
要は、無理に同時に処理する数を増やすより、少々待たされる状態が出たとしてもサーバ能力を超えない範囲にしたほうが、結果としてレスポンスは良くなるということです。
サーバ負荷が高く、レスポンスが悪化した場合は、MaxClientsを増やすのではなく、減らすことをまず考えた方が賢明です。

MaxClientsスワップロードアベレージ計測時間秒間処理数リクエスト
256859MB79.2655.40秒36.10/秒2.73秒
2011MB5.4635.66秒56.08/秒1.74秒


1サーバあたりのメモリ使用量(ps結果のRSS)は10MB程度でしたので、100サーバだと1GB程度消費するのに対し、20サーバだと200MB程度で済みます。結局のところ、Apacheで使用する容量÷10MB?30MB程度で考えるのが良いでしょう。

参考までに、私が1GBメモリ、2コア程度のサーバ(さくらのVPS 1Gプラン相当)でいつも行っている設定は以下のような値です。

<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 15
ServerLimit 256
MaxClients 40
MaxRequestsPerChild 1000
</IfModule>


Apacheの起動

Apacheを起動するには、serviceというコマンドを利用します。
以下のように打ち込んで、問題なければ正常に起動します。

# service httpd start
Starting httpd:                                            [ OK ]

なおエラーが出る場合には、モジュールを削ったときの設定ファイル変更を忘れている可能性があります。
設定ファイルの問題の際には、エラーメッセージとともに行番号が書かれていますので、再確認して下さい。


MySQLの設定と起動

それでは、MySQLの設定と起動を見てみましょう。
MySQLの設定については /etc/my.cnf を編集することで可能ですが、あらかじめ最低限の設定はされているので、ひとまず起動をして管理者パスワードの設定を行います。

MySQLを起動するには、serviceコマンドを利用します。

# service mysqld start
Initializing MySQL database:  Installing MySQL system tables...
OK
Filling help tables...
OK

・・中略・・

[ OK ]
Starting mysqld: [ OK ]

無事に起動できれば、[ OK ] と表示されます。

次に設定を移ります。
設定には専用のスクリプトが用意されているので、そちらを利用します。

# /usr/bin/mysql_secure_installation

・・略・・

Enter current password for root (enter for none): ← デフォルトではパスワードが無いので、そのままリターン
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

Set root password? [Y/n] y ← 「y」と入力してリターン
New password: ← rootパスワードとして設定したい文字列を入力してリターン
Re-enter new password: ← もう一度入力してリターン
Password updated successfully!
Reloading privilege tables..
... Success!


By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y ← 「y」と入力してリターン
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y ← 「y」と入力してリターン
... Success!

By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y ← 「y」と入力してリターン
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y ← 「y」と入力してリターン
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

これで、MySQLが利用できるようになりました。


phpmyadminの設定

ここまでで、Apache、PHP、MySQLの全てが利用可能になりました。
最後に、phpmyadminの設定を行いましょう。

まずは、phpmyadminの設定ファイルを変更します。
変更するのは、blowfish_secret という項目だけです。以下のようにご自身で決めたランダムな文字列を入れてください。

vi /usr/share/phpmyadmin/config.inc.php

$cfg['blowfish_secret'] = 'dfj29jwIO1w19jjsdw219Ujdsjlk'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

次に接続元のIPアドレスを追加します。
以下のように、/etc/httpd/conf.d/phpmyadmin.conf を編集し、Allow from を追加します。

vi /etc/httpd/conf.d/phpmyadmin.conf

<Directory "/usr/share/phpmyadmin">
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Allow from 59.106.??.??
</Directory>

設定ファイルの編集が終われば、Apacheに設定ファイルを再読み込みさせれば完了です。

# service httpd reload
Starting httpd:                                            [ OK ]

ブラウザからアクセスをすると、無事phpmyadminの画面が表示されました。
ユーザ名に root と入力し、パスワードには先ほどの文字列を入力します。

20110514-phpmyadmin.png


自動起動設定と、再起動

これで、LAMP環境の設定がひとまず完了し、利用可能な状況となりました。
しかし、これで安心してはいけません。
再起動した場合には、ApacheもMySQLも自動で起動せず、アクセスが受け付けられない状況となります。

自動起動するかどうかを確認するためには、chkconfigコマンドを利用します。
3という項目がoffの場合には、再起動時にApacheやMySQLが自動起動されません。

# chkconfig --list|grep -E "httpd|mysql"
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
mysqld          0:off   1:off   2:off   3:off   4:off   5:off   6:off
# chkconfig httpd on
# chkconfig mysqld on
# chkconfig --list|grep -E "httpd|mysql"
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
mysqld          0:off   1:off   2:on    3:on    4:on    5:on    6:off
#

これで再起動をすれば、全ての作業が完了です。
再起動しなくても問題ありませんが、再起動された時に自動で全てのソフトウェアが起動するかどうかを確かめるためにも、再起動を強くお勧めします

時間としては1時間程度で済みましたでしょうか?
最近では、クラウドの機能が増えたことによりこういった作業を必要ないという人もいますが、ウェブ開発者のたしなみとして、これくらいはできるべきだと思います。
慣れれば10分くらいでできますし、数十台程度であれば平行で作業すれば30分もあれば出来ます。

ということで、皆さんもぜひがんばってチャレンジしてみてください。
なお皆さまからも「ここはこの方がいい!」とかあればぜひご指摘頂ければ幸いです。

2012/5/7 CentOS 最新版に対応すべく修正しました。

大災害時におけるアクセス負荷を軽減させるキャッシュサーバ提供について

  • 投稿日:
  • by

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

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

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

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

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

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

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

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

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

ミラーサーバを使う場合

担当の技術者の方へ

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

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

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

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

東北地方太平洋沖地震に対するサーバインフラ支援について

  • 投稿日:
  • by

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

この事態にあたり、インターネットサイトの多くがダウンしたり、繋がりにくい状態になっており、さくらインターネットにおいてもそのようなサイトをお手伝いすべく、大きな帯域の提供や、ミラーサーバ運用などを行っております。
既に、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で上位プランに移行するための手順

  • 投稿日:
  • by
  • Category:

さて、本日からさくらの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ライフをお送り下さい。

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

  • 投稿日:
  • by

※掲載直後に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をデフォルト値に戻すことを忘れないようにしてください。

格安の低価格VPSを比較する

  • 投稿日:
  • by
  • Category:

最近、IaaS型クラウドの流行の裏で、VPSがひそかな人気を集めています。
VPSは、クラウドのような従量課金やAPIアクセス、柔軟なリソース増減はできませんが、その分安価な価格設定が行われることが多く、数ヶ月以上利用するのであればクラウドよりも非常に安価で高いパフォーマンスを得られることが特徴です。
また、コントロールパネルで起動、停止、再起動などの操作や、OS再インストールなど、クラウドで言うところの「セルフサービスによる」という部分は多くのVPSで実現されており、さくらのVPSに限ってはコンソールをホストOS経由で直接アクセスできるなど、物理サーバの置き換え用途としても十分に利用できる内容となってきました。
さらに、申し込みから利用開始まで数分から数十分程度で行えるなど、従量課金ではないことと解約が手動となる点を除けばIaaS型クラウドに決して劣るものではありません。

ただ、たくさんのVPSが各社から提供され、なかなか選べないよという方も多いのが実情です。
今回は、さくらのVPSのほか、話題を呼んでいる日本ラッドさんのSaaSes Osukini Serverと、DTIさんのServersman@VPSを取り上げ、それぞれのVPSについて比較をしてみました。
いちおう公平に書くようにしましたが、色眼鏡で見ていただいても結構です。m(_ _)m

それでははじめに各社の仕様をまとめてみます。

プラン名 さくらのVPS Osukini Server Serversman@VPS
512 1G 1.5G 4G 8G LT ST GT XT Entry Standard Pro
初期費用(円) 0 2,980 4,980 9,980 19,980 6,000 6,000 10,000 14,000 0 0 0
月額(円) 980 1,480 1,980 3,980 7,980 450 980 1,980 4,980 490 980 1,980
年払い割引 1か月分割引 なし なし
試用期間 2週間 2週間 記載なし
(キャンペーン対応)
メモリ容量 512MB 1GB 1.5GB 4GB 8GB 512MB 1GB 2GB 4GB 256MB 512MB 1GB
HDD容量 20GB 30GB 50GB 120GB 240GB 50GB 100GB 200GB 400GB 10GB 30GB 50GB
SWAP設定 ×
リモート
コンソール
× ×
固定IP v4
v6 × ×
追加IP ×
月額500円
×
1個

3個
IP逆引き
制限あり
仮想化プラットフォーム KVM完全仮想化 Xen完全仮想化 OpenVZコンテナ
OS CentOS
Debian
Ubuntu
Fedora × ×
FreeBSD × ×
現在のキャンペーン
今なら初期費用半額 今なら最大2か月分を無料に
その他の制約等 試用期間中は2Mbps制限
試用期間中はOP25Bあり

VPN設定不可
iptablesエントリ数の上限あり
※Serversman@VPSは、ウェブサイト上にて最大メモリの表記がありますが、あくまでも保障メモリで比較しています。


これではわかりにくいので、一番の関心事であろう価格について、それぞれ初年度にいくらかかるかを比較してみましょう。
また、メモリ1MBあたりの単価、HDD 1GBあたりの単価も見てみます。

プラン名 さくらのVPS Osukini Server Serversman@VPS
512 1G 1.5G 4G 8G LT ST GT XT Entry Standard Pro
年間の利用額(円) 10,780 19,260 26,760 53,760 107,760 11,400 17,760 33,760 73,760 5,880 11,760 23,760
メモリ1MBあたり(円) 21.0 18.8 17.4 13.1 13.2 22.3 17.3 16.5 18.0 23.0 23.0 23.2
HDD 1GBあたり(円) 539.0 642.0 535.2 448.0 449.0 228.0 177.6 168.8 184.4 588.0 392.0 475.2


ここで、グラフ化してそれぞれのプランがどのような位置にあるのかを見てみます。
まず、メモリの容量を横軸にした価格帯です。
VPS価格比較
導入費用が絶対価格で最も安いのはServersman@VPSのEntryプランですが、概ね価格帯は似通っているといえます。
低スペック帯では唯一256MBモデルを出しているServersman@VPSが安価であり、512MBあたりでは3社とも同様の価格となり、高スペック帯ではさくらのVPSがもっとも安価ということがわかります。

次に、HDD容量を横軸にした価格帯を見てみましょう。
VPS価格比較
総じていえるのは、Osukini Serverが飛びぬけて大容量であるということでしょう。
例えば、1万円の場合にさくらのVPSは20GB、Serversman@VPSは30GBのところ、Osukini Serverは50GBと大幅に大きいことがわかります。

ちなみに、キャンペーン適用した価格はどうなのか?1年を超えると結果は違うのでは?との質問もあったので、いちおうグラフを作りました。正直なところずっとキャンペーンをしている事業者は不公正だし信用できないので加味する必要性を全く感じませんが、信頼性がないとか言われても嫌なので参考までに。

結果的には大して変わりませんでした。
結局、低スペック帯ではServersman@VPSが価格優位なこと、SaaSesが価格に対してHDDが大容量なこと、高スペック帯ではさくらのVPSが価格優位なこと、それぞれ変わることはありません。
ただ、Serversman@VPSは期間が長くなると価格メリットが薄れてくるようです。

それでは気をとりなおして、最後にベンチマーク比較を見てみましょう。
既にこれらのVPSサービスの利用者の方がunixbenchで計測されていますので、その情報を見てみたいと思います。
それぞれ、「さくらのVPS unixbench」「Saases unixbench」「serversman unixbench」とGoogleで検索して出てきたページから抜粋しています。

VPS性能比較
これを見ると、さくらのVPSが1200から1500程度、Serversman@VPSがEntryで200から400程度、Standardで400?800程度で、Osukini ServerがLTとSTともに600程度です。
unixbenchだけでは結果はわかりませんが、数字を見る限りさくらのVPSが飛びぬけて性能がよいのは間違いなさそうです。

ただ、性能だけを見ても仕方が無いので、価格性能比をマッピングしてみましょう。
VPS性能比較
やはり性能についてはさくらのVPSが良いですが、興味が惹かれるのはServersman@VPSです。Osukini Serverが価格が上がっても性能が変わらないのに対し、Serversman@VPSはプランごとに性能が変わっているうえ、TurboモードをONにすることによる性能の向上が見られます。
完全仮想化の場合はゲスト空間が利用者に全て委ねられるのに対し、OpenVZの場合はCPU性能をコントロール出来るというのが寄与しているものと思われます。

それでは、ここでまとめにしたいと思います。
比較を実際にしてわかったのは、各社各様に特徴があるなというところで、本当はさくらのVPSを推したいところですが、そうは甘くないようです。
ということで各社の特徴をまとめてみました。

  • さくらのVPS
    • 高スペックプランになるほど、コストパフォーマンスがよくなる
    • リモートコンソールが利用できる
    • サーバ性能が飛びぬけて良い
    • 利用できるOSが多い
    • 初期費用が無い(980プランのみ)
  • Osukini Server
    • HDD容量が飛びぬけて大きい
  • Serversman@VPS
    • IPv6が利用できる
    • IPv4が複数利用できる(StandardとProのみ)
    • 低スペックプランがラインナップされ、最も安い
      (過去のキャンペーン適用者で、Entryを月105円で利用できてる人もいるらしい)
    • 運が良ければ保障以上のメモリを使える(但しプロセスがしばしばkillされる)
    • 初期費用が無い

私の結論としては、

  • スペックや性能が低くてもとにかく安くということでは、Serversman@VPS
  • HDD容量が欲しければ、Osukini Server
  • HDD容量はそこそこで良く、月に980円以上出せるのであれば、さくらのVPS
というところでしょうか。

なお上述のとおり、ある程度の値段になると、Osukini Serverか、さくらのVPSという選択肢しかなく、スワップが利用できることも考えると、本格運用の場合には Osukini Server か、さくらのVPSの2択かなと思います。
本当はさくらのVPSだけを推したいところでしたが、さすが岡田さんだけあってOsukini Serverも良くできているという印象です。

また今後、Amazon Web Servicesや、Linodeなども取り上げる予定ですが、皆さんからもご意見などいただければ幸いです。

双日株式会社による当社株式のTOBについて

本日、双日株式会社によるさくらインターネット株式のTOBが発表されました。
また、当社取締役会はTOBに対して賛同意見を出しております。

さくらインターネット: 双日株式会社による当社普通株式に対する公開買付けに関する賛同意見表明及び同社との業務提携契約書の締結のお知らせ
双日: さくらインターネット株式会社株式に対する公開買付けの開始に関するお知らせ

今北産業で表現すると

  • 約30%の株式を持つ筆頭株主の双日株式会社が、約10%の買い増しを行い、約40%まで出資比率を引き上げる。
  • これにより、双日株式会社が約40%、私個人の資産管理会社(株式会社田中邦裕事務所)が約10%、私個人が5%となり、過半数(約55%)が安定株主となる。
  • 双日株式会社は、株式会社田中邦裕事務所と株主間協定を結び、さくらインターネットを子会社化する

ということです。

以下に、質問の多そうなところをまとめておきます。

  • 双日株式会社は現在約30%の株式を持つ筆頭株主であり、TOB成立後も引き続き約40%の株式を持つ筆頭株主です。
  • 株式会社田中邦裕事務所は株主間協定を結ぶだけでTOBに参加しません(一切株式の売却をしません)ので、TOB成立後も第2株主として残ります。(株主間合意書に基づく)
  • 取締役は、特に両者が合意しない限り、当社が4名、双日株式会社が2名を指定しますので、現在の経営体制から特に変更はありません(業務提携契約書に基づく)
  • サービスについては、今までどおりの体制で運営を続けますので、戦略を含めて特に変更はありません
  • 双日株式会社、株式会社田中邦裕事務所、私個人の持分は、合計で約55%にとどまり、東京証券取引所の上場は今までどおり維持します
  • TOB成立後は、サービス・営業分野における事業提携、海外展開における事業提携、インフラ分野での事業提携、技術分野での事業提携を目指します。

唐突な話で、皆さんにはご心配をおかけしたこともあるかと思いますが、双日株式会社はそもそも以前から筆頭株主でありますし、同社派遣の2名の社外取締役と共にサービスの拡充に努めてきた経緯があります。
1/3以上の株式を取得する際にはTOBをしなければならないという金融商品取引法上の定めもあり、大げさなことになっていますが、上述のように特に大きな経営体制の変更はありませんので、ご安心頂ければと思います。
今後は、当社の得意とする既存サービスの拡充に加え、一般企業向けサービス拡充を通じて、さらなる成長を目指しております。

今後ともどうぞ宜しくお願い致します。

無料の携帯ソーシャルゲームが成り立つ訳

最近、携帯無料ゲーム(ソーシャルゲーム)の宣伝を見ない日はありません。
このソーシャルゲームですが、よく知人から「なぜ無料でできるの?本当に無料なの?」と聞かれます。
そういう時には、「課金を承諾しない限り、ソーシャルゲームは永遠に無料で遊べる」と回答しています。

Venture Now に掲載されていた「ソーシャルメディア利用動向、女性ユーザーが積極的。GREE課金は男性の倍」によると、このプラットフォーム会社の課金ユーザ比率は男性の11.8%、女性は21.2%で、平均すると16.8%しか課金されていません。
つまり6人のうち5人はお金を払わずに楽しんでいるわけです。
(女性比率が多いというところも気になりますが、今回は華麗にスルーします)
20101230-social.jpg
出典: Venture Now

それではなぜ無料が成り立つのでしょうか?
今更感もある話ですが、改めて原価と売上という2つの観点から見てみたいと思います。

まず原価の観点から。
ソーシャルゲームの原価は何があると思いますか?
ざっくりというと、広告宣伝費、開発費、インターネットインフラ費(サーバ費用)、課金手数料、サポート費用です。
このうち、ユーザの数と関係なくかかるのが広告宣伝費と開発費で、ユーザの数に連動するのはサーバ費用と課金手数料、サポート費用です。
無料の場合は課金手数料はかかりませんので、実質的にユーザの増加によって増えるのはサーバ費用とサポート費用です。
それではサーバ費用やサポート費用はいくらかかるのでしょうか?
これは正確に出せるものではありませんが、何とか計算してみましょう。

まずサーバ費用ですが、潜在ユーザも含めて1ユーザがひと月に平均1000ページビューのアクセスをするとして計算します。
ひと月に1000万ページビューまでさばけるサーバのコストが月々3万円だとすると、30,000円×1000PV÷10,000,000PV=3円/月程度となります。
サポート費用ですが、2,000万人のユーザを200人でサポート、管理すると仮定して計算します。実際にはもっと少ない人数だと思います。
1人月を60万円だとすると、60万円×200÷2,000万人=6円/月程度となります。

ここで出てきた合計9円/ユーザ/月という数字について、それ自体には意味はありませんが、言いたいのはユーザーが1人増えようが、コスト増が「無視できるほどに小さい」ということです。
このように、携帯無料ゲームにおける1ユーザあたりの原価は驚くほどに安いので、無料ユーザが増えたところで原価はそれほど多くはありません。
ちなみに、旧来型のゲームの場合は、カードリッジを作ったり、販売店にマージンを払ったりしなければなりませんから、無料で提供するということは出来ませんが、ソーシャルゲームの端末はいつもの携帯ですし、ゲーム自体もオンラインで提供するため、前出のようなコストを掛けなくて済むというのも大きいでしょう。

次に売上の観点から。
携帯無料ゲームの売上は、大きく分けるとアイテムと広告の2つからもたらされますが、ほとんどはアイテムからもたらされます。
ということで、上記の例で言うと6人に1人だけが売上をもたらしてくれます。
それでは、6人のうち5人は邪魔なユーザなのでしょうか?
いえいえそれは違います。
結論から言うと、有料ユーザが楽しくプレイできるよう、無料ユーザが「無償の労働」を行なってくれているのです。
ここでいう無償の労働とは「フリー」(クリス・アンダーソン著、NHK出版)によって述べられているもので、無料のものを手に入れる代償として労働力をタダで提供する行為のことです。
ソーシャルゲームで言うなら、がんばって釣りをしたり、街を作ったりといった作業を通じて、ゲームの活性化のために奉仕を行っているということです

釣りゲームにおいても、みんなが釣れるようでは面白くありません。
すぐに折れてしまう釣竿でゲームをする無料ユーザがいるからこそ、よく釣れる折れない釣竿の価値が上がり、有料ユーザとして「お金を払おう」という気を起こさせるわけです。
直接の売上こそ有料会員からもたらされるものですが、有料会員が楽しくゲームが出来るのは、無料ユーザのおかげなのです。
もちろん、無料ユーザも楽しんでいるわけですし、無料ユーザ同士であればフェアな戦いがされることになります。
そもそも会員の多くは無料ユーザなわけですから、恐らく大部分ではフェアなゲームが行われているということです。

ここで、提供者と、ユーザのベネフィットを整理してみます。

提供者・・・有料会員は売上をもたらし、無料会員は報酬を渡さずともゲームを盛り上げてくれる
有料ユーザ・・・自分が強い世界でゲームを楽しめる(特権者≒貴族?になれる)
無料ユーザ・・・タダでゲームを楽しめる

このように、無料ユーザと有料ユーザの絶妙な関係性と、ユーザあたりのコストが非常に安いことから、多くのユーザが無料だったとしてもビジネスが成り立つわけですし、むしろ無料ユーザがいないとビジネスが成り立たないと言ってもいいのかもしれません。
ちなみに、2,000万人会員がいたとして6人に1人、すなわち330万人が1,000円払ったとすると月々33億円、年間では400億円の売上が上がることになります。
多くのユーザが無料とはいえ、いかに大きな売上が上がるかがおわかり頂けるでしょう。

ただし、このビジネスモデルを成り立たせるために必要なことが1つだけあります。
それは会員数です。
上記の原価の計算の際に示した数字は、あくまでも数千万人単位のユーザがいることを前提にしました。
サーバについても、サポート体制についても、最低かかるコストはありますし、上記の例でいうとユーザが1人だけだったとしても60万円/月のサポートコストを負担しなければなりません。

また、先ほどの例では言及しなかった開発費や広告宣伝費についても、大量のユーザで割るからこそ無視できる存在になっています。
よく「釣竿なんてコンピュータ上だけのもんなんやから、原価0円やろ」という声を聞きますが、これは当たってるとも言え、しかし外れているともいえます。
釣竿というアイテムを投入するに当たって、ゲームバランスや顧客満足などを検討したり、それを開発したりというコストはタダではありません。例えばアイテム投入に当たって、会議や開発などで1人月60万円×0.5人月がかかったとしたら、一本の釣竿を作るのに30万円かかることになります。それを100万人に売れば1本30銭の原価ですが、100人にしか売れなければ1本3,000円の原価ということになります。
このように、いかにたくさんの人に利用してもらうかが重要であり、その中から生まれる潜在的な有料ユーザをたくさん抱えることが必要となるのです。

ところで、私は今までゲーム機器を購入したことが無いのですが、一時期はGREEのハコニワをプレイしていた(無料ユーザとして)こともありますし、最近はコロプラに凝って(月に1,000円くらい払う)います。
ハコニワは無料、コロプラは有料で楽しんでいますが、どちらも機器購入などの手間もなく、手軽に遊べるのが非常に印象的でした。
ハードルを下げ、多くの人を呼びこみ、そのなかの一部でもお金を払ってくれればよいというモデルによって、提供者側としても莫大な売上を上げることが出来ますし、利用者側としても手軽にゲームが楽しめます。その、双方にメリットがあるということがソーシャルゲームの普及の源泉なのでしょう。
(もちろん、パケット定額制で、使っても使わなくても電話料金が変わらない時代になったというのも大きいでしょう)

ただ良いことばかりでもないようです。
ここ最近、携帯無料ゲーム(ソーシャルゲーム)に関する苦情が増えている旨の記事が新聞などで取り上げられはじめました。
特に課金ということへの理解度が低い未成年に対する高額課金が取りざたされており、教育や、課金へのハードルの必要性も語られるようになりました。
かくいう私も、昔はパソコン通信(Niftyserve)で5万円くらい使ってしまったこともありますが、ソーシャルゲームの場合は無料だと思い込んでいることもあるでしょうし、昔と違って端末が小さく親が把握しにくく、対象となる人の数が多いことも相まって、当時のパソコン通信と比べて問題は大きいといえます。
(子供が「分からないふり」して課金を承諾してるんじゃないかという指摘もありますが・・・)

なお、「実は無料じゃなかった」問題は以前から知れた話ですが、ソーシャルゲームのプラットフォーム会社はいまやCM出稿の上位に食い込む大口ユーザであり、なかなか踏み込めない「聖域」のようです。
ですので、プラットフォーム会社がCM出稿を減らしたとたん、堰を切ったように批判を始めるような気もしています。

私個人としてもソーシャルゲームは好きですし、ソーシャルゲーム提供者の皆さんはデータセンターの大きな需要家でもありますので、上記のようなことを克服してソーシャルゲームが健全に広がっていくことが必要だと思います。