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

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

• マルチテナント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバ切り替えに先立って、該当するホスト名の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秒間）は待つのが懸命です。

2. rsyncのインストール

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

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

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

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

なお、今回のコピーにあたって、いくつかのファイルとディレクトリを除外しています。除外したファイルは、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


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

4. 新サーバを再起動します。

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

5. 旧サーバのhttpdやsendmailなどを停止します。

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

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

6. もう一度、旧サーバから新サーバへrsyncを使ってファイルをコピーします。

旧サーバがサービスを停止したことを確認して、再度コピーを行います。
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


7. DNSのAレコードを新サーバに向けるとともに、TTLを元に戻します。

新しいサーバに向けてIPアドレスを変更します。
それと同時に、先ほど60にしたTTLをもとに戻します。

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

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

8. 旧サーバの解約を行います。（毎月20日が解約締切りなので要注意）

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

以上が移行手順です。

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

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

今北産業で表現すると

• 約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人はお金を払わずに楽しんでいるわけです。
（女性比率が多いというところも気になりますが、今回は華麗にスルーします）

出典: Venture Now

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

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

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

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

次に売上の観点から。
携帯無料ゲームの売上は、大きく分けるとアイテムと広告の２つからもたらされますが、ほとんどはアイテムからもたらされます。
ということで、上記の例で言うと６人に１人だけが売上をもたらしてくれます。
それでは、６人のうち５人は邪魔なユーザなのでしょうか？
いえいえそれは違います。
結論から言うと、有料ユーザが楽しくプレイできるよう、無料ユーザが「無償の労働」を行なってくれているのです。
ここでいう無償の労働とは「フリー」（クリス・アンダーソン著、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出稿を減らしたとたん、堰を切ったように批判を始めるような気もしています。

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

文字化けの話はGoogleででも検索を

さて文字コードを自動判別するという技術は色々あって、よく利用されるのは特定の文字コードでしか利用されない文字を探し当て、判別するというものです。
言わずと知れた漢字コード変換コマンドである nkf でも、上記の方法で非常に精度の高い自動判別を行ってくれます。
ただ、これには大きな問題があります。それは「短い文字列だと判別できない」ということです。
某とあるサイトでは、単語を入力してロゴを作るというウェブサービスを提供していますが、入力される文字列が短いことからうまく自動判別がうまくいきません。

そのため今回取った対策は、submitされるフォームデータと共に判別用文字列を送るというものです。
例えば「文字」という文字列をUTF-8で送ると%E6%96%87%E5%AD%97となり、Shift-JISで送ると%95%B6%8E%9Aとなります。
ですので、判別用文字列がどのような文字列になって送られてきたかを見ると、他のフォームデータの文字コードを知ることが出来るというわけです。

それでは実際のプログラムです。
detectstrのところが、判別用文字列を埋め込んだところです。
ちなみに「文字」というのを利用した理由ですが、日本語のみならず、中国語簡体字、中国語繁体字においても同じ形だからということです。例えば自動という文字の場合は、簡体字で動という文字が異なるコードになってしまいますので利用できません。
なお最初は「日本」という文字を判別用文字列にしていたのですが、hiddenで日本という文字列が入っていると中国の利用者の方からいらぬ誤解を受けたり都市伝説化するのも嫌なので、途中で変えました。

送信側プログラム

<form action="test.php">
<input type="hidden" name="detectstr" value="文字" />
名前: <input type="text" name="name" />
<input type="submit" value="送信" />
</form>


受信側プログラム

<?php
$charsetList = array(
  "utf-8"  => "%E6%96%87%E5%AD%97",
  "sjis"   => "%95%B6%8E%9A",
  "euc-jp" => "%CA%B8%BB%FA",
  "jis"    => "%1B%24BJ8%3Bz%1B%28B",
  "Big-5"  => "%A4%E5%A6r",
  "HZ"     => "%7E%7BNDWV%7E%7D",
  "EUC-KR" => "%D9%FE%ED%AE",
  "GB2312" => "%CE%C4%D7%D6",
);
$charset = NULL;
foreach( $charsetList as $key => $val ){
  if( @$_GET["detectstr"] == $val ){
    $charset = $key;
    break;
  }
}
if( !$charset ) die("Couldn't detect a character set");
$name = mb_convert_encoding( @$_GET["name"], "UTF-8", $charset );

print htmlspecialchars($name);


以上、いかがでしたでしょうか。
少々セコいですが、簡単かつ確実に行える対策です。
ただ、フォームの送信元と送信先の両方のプログラムに手を入れることになりますので、それが出来ない環境では別の方法をとる必要がありますのでご注意を。

[root@wwwxxxxu ~]# dd if=/dev/zero of=/dev/null &
[1] 31092
[root@wwwxxxxu ~]# kill -USR1 31092
7764899+0 records in
7764898+0 records out
3975627776 bytes (4.0 GB) copied, 6.02001 seconds, 660 MB/s
[root@wwwxxxxu ~]# kill -USR1 31092
25123042+0 records in
25123041+0 records out
12862996992 bytes (13 GB) copied, 17.8137 seconds, 722 MB/s
[root@wwwxxxxu ~]# kill -USR1 31092
43986419+0 records in
43986418+0 records out
22521046016 bytes (23 GB) copied, 31.3739 seconds, 718 MB/s
[root@wwwxxxxu ~]# kill 31092
[1]+ Terminated dd if=/dev/zero of=/dev/null
[root@wwwxxxxu ~]#

ddを利用する際は大きなファイルのことが多いので、途中で経過が見えるだけでもストレスが減るのではないでしょうか。
ちなみに私は、上記の出力を元にプログレスバーを表示するスクリプトを作りました。

株式会社日本レジストリサービス（JPRS）さんへの公開質問です

内容を今北産業でいうと、

独占的にJPドメインを扱っているJPRSさんが、
誰でも参入できるgTLDドメインの扱いをはじめる表明をしたため、
同じくgTLDを扱っており競合になるGMOさんが「フェアでない」という声を上げた。

ということです。

私も「フェアでない」と思っていますし、JPRSユーザ会という場においても「JPRSさんがgTLDドメインの取扱いをやらないほうがいい理由」を話しました。
しかし、多くの中小事業者はJPRSさんにgTLDドメインを取り扱ってもらいたいという考えでしたし、そもそも今回のろしを上げたGMOさんはその場に出席すらしていませんでした。

そういった経緯もあり、今回の件についてこれ以上の指摘は無意味だろうということで、特に関わるつもりもありませんでしたが、さまざまな方から私へのさぐりが多く、考えを聞かせてくれというメールも多いので、自分の考えについて経緯を踏まえながら書かせて頂くことにしました。
長文ですが、お時間があればお付き合いください。

はじめに

まずはじめに、レジストリとレジストラについて解説をします。

ドメイン名の登録というのは、複数の人に重複して登録されないよう一意性が重要になります。
そのため、トップレベルドメイン（TLD）ごとにデータベースは必ず１つである必要があり、単独の一社で管理されています。このデータベースを管理する事業者のことをレジストリを言います。
そして、レジストリのデータベースを利用して、実際にドメインの登録を行う事業者のことをレジストラと言い、TLDごとにたくさんの事業者が存在します。
さくらインターネットはレジストラではありませんが、GMOさんをはじめ、ライブドアさんやファーストサーバさんなど、国内にも多くのレジストラが存在します。
レジストリとレジストラを分けるのは非常に煩雑ですが、その煩雑さを乗り越えてでも参入の平等や競争環境の創出を目指して、先人たちが大変な苦労を乗り越えて分離モデルを作り上げました。

しかし、分離モデルは.com / .net / .info のようなグローバルなTLD（gTLD）において行われているのが大半で、国別ドメイン（ccTLD）においてはレジストリとレジストラが分離されていないことも多く、日本のドメインである.jpにおいては指定事業者というレジストラに順ずる事業者はあるもののJPRSというレジストリ事業者の権限が非常に大きいのが現状です。

そのような環境下に置いて、独占状態による競争の無さからドメインが高額であるとの指摘が多く、事あるごとに議論が続いてきました。
また、JPRSさんにおいては、レジストリを独占的に行いながら、ユーザへ直販するJPDirectというレジストラ機能も行っており、gTLDのようなレジストリ・レジストラ分離は行われていません。おまけにJPRSさんが、.comや.netといったgTLDのレジストラも開始するということになり、大きな問題に発展しています。

今回は、.jpが独占的であるということと、ドメインが高額であるということに加え、他ドメインのレジストラを行うことに対する問題点を書きたいと思います。

独占的であるということについて

.jpにはレジストリは１社しかありません。前述の通りJPRSさんが行っています。
その上、thick registryと呼ばれる、whoisや個人情報の管理までレジストリが行う「大きなレジストリ」形態をとっているため、さくらインターネットやGMOさんのような事業者はJPRSさんに取次ぎしているだけで、ドメインの管理を行ったり、価格をコントロールしたりする権限は極めて少ない状況です。
このような環境下に置いて、コスト体質であるとか、経営の決定プロセスが開かれていないとか、莫大な利益を上げ特定の株主が配当を受け取っているとか、多くの指摘がなされています。

ただ、国別TLD（ccTLD）において特定の団体の力が強い状況は日本以外でもありますし、結論から先に言うと「特定の人に利益が生まれるような状態で無く、信頼性の高い運営が行われているのであれば、独占状態も消極的に受け入れても良い」と考えています。
JPRSさんの役員には天下りなど、いわゆる給与泥棒に当たるような役員はいないはずですし、経営陣は健全見えます。
コストが高いという点についても、世界的に見て大変信頼性の高いDNSシステムを構築していますし、ドメインに関する研究開発に資金を拠出しているのも事実です。

特定の会社名は出せませんが、「自分がやれば.jpはもっと安く出来る」と仰っているとある会社においては、数度にわたりドメインの根幹であるDNSシステムに障害を発生させ、数日にわたってダウンさせるという事態に至っています。
その際には同じネットワーク（LAN）かつ近傍（同じ？）のラックにプライマリ・セカンダリのネームサーバを設置していたということが露呈して、たいへん問題になりました。

DNSが止まると、いくらネットワークやサーバが頑丈でもインターネットは利用できないに等しい状態になります。事実、他国のドメインにおいて何度か止まってしまって苦い経験をしたこともあります。
それだけ重要なインフラなわけですから、JPRSさんの運用体制については大変信頼しています。

ただ、配当に関してはやめたほうが良いのではないかと思っています。
かくいう当社もJPRSさんの株主であり、毎年少なくない配当を受け取っています。
しかし当社は配当をもらうために資金を拠出したのではなく、信頼性の高いjpドメイン運営を続けるための安定株主として拠出したわけですし、かつJPRSさんがおかしなことになってしまったときにモノを言う権利を留保するために拠出したわけです。
JPRSさんの株主では大手事業者のほかに、現経営陣も大株主になっておられます。
現経営陣が自分のために配当しているわけでないのは良く知っていますが、経営者はストイックなまでの清廉潔白さが必要だと私は考えています。
なので、少しでもうがった見方をされるような経営判断は、積極的に回避すべき考えます。

また、経営陣についても定期的に見直すくらいの気概は必要かと思います。
少しだけJPRSさんの擁護をするなら、JPRS設立当初は事業性も非常に不安定で、世間で言われるほど確実性の高い事業計画でもなく、その当時に役員になり、身銭を切って出資した人たちは賞賛されるべきであると思います。
ただ、公益性の高い独占企業の経営者は極めて透明性の高い行動をするべきだと思いますし、勝手な言い分であることは承知の上で改善をお願いしたいところであります。

高額であるということについて

次に高額であるということに対する話ですが、私はjpドメイン名が絶対的に高いとは思っていません。
以前は値下げ論者でしたが、「相対的に高い」「絶対的に高い」という尺度において、後者だけで物事を見ても意味が無いと思います。
jpドメインが相対的に高いのは、jpドメインの数が相対的に少ないからだけです。

先日、.jpが世界でもっとも安全との調査がありました。
コレにはJPRSさんの努力はあるでしょうけれど、実際には.jpがそれなりに高いのと、日本国内のユーザに限定していることが影響しており、少し高いけど信頼性の高い.jpドメインという方向性は成功しているように見えます。

「.jp」は世界で最も安全なccTLD、McAfeeの調査で2年連続
http://internet.watch.impress.co.jp/docs/news/20101028_403080.html

またJPRSさんでは、「大きなレジストリ」体制を活用し、インターネット全体に影響を与えてしまうような失敗設定に対して積極的に修正依頼を行ったり、DNSSECなどの新技術に対して積極的に取り組んだりと、世界的に見ても熱心で手厚い登録事業者であることは間違いありません。

企業にとって、汎用JPの卸価格である年間2,250円は本当に微かなコストだと思います。
安いドメインが必要ならgTLDをとればいいだけですし、.jp以外の選択肢があるわけですから、相対的な値段にこだわっても意味がありません。
さくらインターネットのレンタルサーバにおいては、jpドメインの倍以上のgTLDが管理されていますし、私自身も.jpドメインはgTLDより高いので、信頼性の必要なドメインでしか.jpは利用していません。

要は選択の問題です。
「信頼性はそこそこほしいが、手厚い管理体制はいらないし、やっぱり安いほうがいい」ということなのか、「少々高くても、しっかりとした管理体制があり、信頼性は高いほうがいい」ということなのか、どちらかです。
ドメインには、少々止まっても安ければよいという個人ユーザから、100万円払っても良いから止めてもらったら困るという大手サイト管理者まで居ます。
私の個人ドメインと、mixi.jpだと価値の差は歴然ですが、ドメインにはこの２者が入り乱れているのが難しいところで、単純に安ければよいという議論ではないと思います。
もちろん配当減らしてドメイン値下げせよというのは理解できます（ただ配当やめても1割も下がりません）が、そもそもドメイン数がgTLD並に存在しない限り大幅な値下げは難しいと言わざるを得ません。

余談ですが、大幅な値下げが行われた際に懸念していることがあります。
それは、解約ドメインなどに対する広告掲載です。
gTLDの場合、ドメインを解約するとほぼ間違いなく広告業者に食い物にされます。
多くのウェブサイトでは、更新をやめても1日に100件程度はアクセスがあるそうなので、1ヶ月で3,000件となり、0.1%がクリックされたとして年間36クリックとなります。1クリックが50円だとすれば、これだけで1800円の収入となります。
ただ、.jpドメインだとドメイン自体が高いので、上記のようなビジネスモデルが成り立ちません。
ドメインが安くなってほしいという考え方の裏には、解約ドメインなどに対する広告によるビジネスを成り立たせたいという勢力も少なからず居るのを知ってもらえればと思います。
さくらインターネットではやましい商売をしたくないので上記のような行為はしていませんが、試算では年間数千万円近い利益が出るということが分かっており、収益性の高いビジネスであるのは事実です。

JPRSさんがレジストラをやる件について

これは、どちらかというとGMOさんの意見に賛同するところで、結論から言うとJPRSさんはレジストラをやるべきではないと考えています。
実際、JPRSユーザ会という場において、「ドメイン名の管理を行う"レジストリ"と、ドメインの登録販売を行う"レジストラ"は別々に運用するのが世界の潮流であり、便利だからといってJPRSがやっていい問題ではない。」という話をしました。
むしろ、JPRSこそレジストリ・レジストラ分離の議論の対象なわけですから。

しかしながら、ドメインの扱いの少ない事業者からは、「大手事業者と違って我々は海外のレジストラと代理店契約をするのは面倒だし、ドル建支払いも手間。ぜひ国内事業者であるJPRSさんにやってもらえば便利」という話が出ました。

なので私は「国内でも、GMOさんや、ファーストサーバさん、ライブドアさんなど、多くのレジストラがあり、そこと代理店契約すればいいのでは？」と言いました。

それに対して「なぜ当社がGMOさん、ファーストサーバさん、ライブドアさんからドメインを買わなければならないんだ！」という返答です。

私は「なら、なぜ当社がJPRSさんからJPドメインを買わなければならないんだ！」と言いそうになりましたが、グッとこらえて意見するのをやめました。

私自身は現在の独占状態は良い事ではないと思いつつも、その体制によって信頼性の高いJPドメインが維持されている状況は迎合しても良いと考えています。

ただ以下の図のように、レジストリとレジストラが兼業していても単独のドメインに専念するか、完全に分離を行い複数のレジストリとレジストラが契約を結ぶのが通常ですので、今回のレジストリとレジストラを兼業しつつ別のドメインも取り扱うJPRSさんのモデルは大変いびつに見えますし、世界的に見てもほとんど例がありません。

JPドメインは、8割の登録が2割程度の事業者によって行われています。
さくらインターネットやGMOさんをはじめとした、たくさんのドメインを取次ぎしている事業者によって８割のドメインが登録されていますが、社数で言うと２割でしかなく、意見を言う上ではマイノリティです。

事業者のJPドメイン取次ぎランキング

マジョリティである小口の取次ぎ事業者の方々は、自分たちの業務が楽になるからとJPRSさんにgTLDのレジストラをやることを要求していて、それは理解できる部分も多いのですが、「なぜ、レジストリ・レジストラという２つの存在があるのか？」という、理念的なことは共有しておいたほうが良いと思っています。

繰り返しになりますが、私は.jpの独占状態は消極的に受け入れて良いと思っています。
しかし、gTLDのレジストラを兼務するのであれば、.jpのレジストリとレジストラの分離問題に対して根本的な議論を再開すべきだと考えています。

だらだらと書きましたが、私の意見をまとめると
「JPRSの独占状態や多少の高額は、信頼性の裏返しとして受け入れるが、それ以外のドメインにうつつを抜かすな」
ということです。

GMOさんとは根本的な考え方も、理由も全く異なりますが、それでもJPRSさんがgTLDのレジストラをやらない方が良いというのは同じ意見ではあります。
JPRSさんには再考頂くことをお願いしたいところです。

※ちなみに、内容に対してJPRSの東田社長からもコメントが出ているようです。(2010/11/5 20:50 更新)
熊谷会長のブログへのコメント

※レジストリとレジストラの位置づけが混同しているのではとの指摘があり、表記を全面的に見直しました(2010/11/5 23:50 更新)

格安VPSについては、専用カテゴリを用意しています。
ウェブ開発者のための、1時間でできるLAMP環境構築術（CentOS編）も、以下の設定を行った後に併せてご覧ください。

自宅やホスティングなどにおいてCentOSなどのLinuxを利用する人が増えてきました。
最近では格安VPSも増え、さくらインターネットのVPSなど、個人で利用できる安価でパフォーマンスの高いLinux環境が簡単に手に入るようになりました。
このようにサーバを活用する人が増えることは喜ばしい事ですが、いつの間にか乗っ取られていたり、大量のアクセスが来てダウンしてしまったり、自宅のパソコンとの違いに驚く人も多いようです。

今回は、CentOSをサーバとして利用する際に、最初にやっておきたい基本的な設定について解説をします。

それではみていきましょう。

1. まず最初にsshのポート番号を変更します。

ポート番号の変更は必ずしないといけない訳ではないですが、簡単にできる攻撃対策です。
インターネットでは、全世界の22番ポートをくまなく調べ、セキュリティホールのあるサーバが無いかチェックしているロボットがいます。
もちろん、どうしてもあなたのサーバを落としたい！というロボットがいたら別ですが、普通のロボットは無差別なIPアドレスへポート22固定で攻撃をしてきますから、22番ポート以外に変更することは非常に効果があります。

/etc/ssh/sshd_config

#Port 22
Port 10022


今回は10022番ポートに変更しました。
再起動されれば変更が反映されます。

2. 次に公開鍵認証でssh接続するように変更します

sshでは公開鍵を利用してパスワードを使わずに接続することが可能です。
具体的にはクライアントでキーペア（秘密鍵と公開鍵）を生成し、サーバには公開鍵だけを登録することで達成できます。
キーペアの生成方法はクライアントによって異なりますが、teratermの場合でしたら「設定」→「SSH鍵生成」で生成できます。
もしクライアントがLinuxやFreeBSDなどでOpenSSHを利用しているのであれば、以下のようにして生成を行います。

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
・・・・


次に生成された公開鍵をサーバにセットします。

# cat >> ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArg5hePwQQPJKWvlNFGi4TArKI2kB
e4pZNGY/KeEYp3JkmRbcFgThliRmaCVUauCYvSddenbuwF5jytP8py5JtYNaUOnEO
J4JU5298dA1Ul2rrft9B+GcEN1tYL4iJStMi4gkK1234567890/3rD+0bfEv5M6PwgRhy6
gE3LrYw+hpigyi7EChcgtv0e205fDUFcenArrjgGxz9Vw5edz7pHA9dSHLveLanrxNu0p
Ry5KYH49IdSp141TcQXm1xL/l/3erH+pnoG4taDjH3LIdC8BglZzVPbuO5jySW62ciRw
QFguH7hzp/Uily3pbsmy0EtAjIcrZ5SCUe7rXLHlfQ== tanaka@tanaka-PC
^D
#

これで公開鍵を利用したログインが可能になります。

ただ、ここで安心してはいけません。
今の状態は、公開鍵"でも"ログインできる状態なだけで、公開鍵"でしか"ログインできないわけではありません。
これを変更するには、再度sshの設定を変更します。

/etc/ssh/sshd_config

PermitRootLogin without-password


このあとでsshdを再起動すれば、rootログインは公開鍵認証でのみ行えるようになります。

なお、root以外のユーザにおいても公開鍵のみのログインにしたい場合には、以下のような設定を行います。

PasswordAuthentication no


これで、SSHログインは全てのユーザにおいてパスワード認証が無効化されました。

3. 次にiptablesを設定します。

基本は、sshとhttp以外は通さないようにするのが吉ですし、sshについては自宅や会社、レンタルサーバなどのIPアドレスからのみ接続できるように設定したほうが良いでしょう。
以下の例では、httpのみどこからでも接続できるように設定し、sshは210.224.160.0/19からのみ、それ以外のポートは閉じる設定です。

/etc/sysconfig/iptables

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -s 210.224.160.0.0/19 -m state --state NEW -m tcp -p tcp --dport 10022 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT


4. 次に不要なデーモンをストップします

ここからはパフォーマンスの設定です。
CentOSデフォルトでは、びっくりするくらいのサービスが動いています。これらのほとんどはサーバに必要ないものですので、ざっくりoffにしましょう。

chkconfig auditd off
chkconfig autofs off
chkconfig avahi-daemon off
chkconfig bluetooth off
chkconfig cups off
chkconfig firstboot off
chkconfig gpm off
chkconfig haldaemon off
chkconfig hidd off
chkconfig isdn off
chkconfig kudzu off
chkconfig lvm2-monitor off
chkconfig mcstrans off
chkconfig mdmonitor off
chkconfig messagebus off
chkconfig netfs off
chkconfig nfslock off
chkconfig pcscd off
chkconfig portmap off
chkconfig rawdevices off
chkconfig restorecond off
chkconfig rpcgssd off
chkconfig rpcidmapd off
chkconfig smartd off
chkconfig xfs off
chkconfig yum-updatesd off


5. 要らないコンソールを無効にします

/etc/inittabを以下のようにコメントアウトしましょう。

#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6


6. selinuxを無効にします

selinuxについても、一般的なウェブサーバでは不要でしょうから、offにします。
/etc/sysconfig/selinuxのSELINUX=enforceを以下のように書き換えれば完了です。

SELINUX=disabled


selinuxがoffにすることで、幾分パフォーマンスが向上するそうです。

これで設定は完了です。
再起動を行うことで、全ての設定変更が反映されます。
sshdのポートが変わっていますから、あせらず新しいポートへ接続してみてください。

さて今回、後半に解説したパフォーマンス改善は意外と見落としがちのことです。
今回は512MB搭載した64ビットの仮想環境（VPSでは無い）で実験しましたが、起動時間、空きメモリ共に大きな改善が見られました。
起動時間はチューンナップ前が61秒だったのに対し、チューンナップ後は41秒と3割以上も短縮されました。
メモリの使用量についても、チューンナップ前が219MBだったのが144MBにやはり3割以上も削減されました。

変更前のfree結果

[root@localhost ~]# free

             total       used       free     shared    buffers     cached

Mem:        510008     219440     290568          0      12284     126340

-/+ buffers/cache:      80816     429192

Swap:      1048568          0    1048568

変更後のfree結果

[root@localhost ~]# free

             total       used       free     shared    buffers     cached

Mem:        510008     144544     365464          0      10220     109736

-/+ buffers/cache:      24588     485420

Swap:      1048568          0    1048568

最近では自宅サーバの搭載メモリも増えましたし、さくらのVPSやSaaSesなどスワップが利用できるVPSも増えてきましたので、以前ほどはメモリ不足に悩まされる機会も減りました。
しかし、古いマシンを活用する場合や、OpenVZ系VPSのServersman@VPSなどスワップが利用できないサービスの場合には、メモリ不足に悩まされる方も多いと聞きます。
このようなときに、上記のようなチューンナップを行うことによって、エラーに悩まされることなく利用できるようになるでしょう。

なお、CentOSの場合にはインストール時にDesktopとかServerとか選択せず、X-Window Systemも入れるべきではありません。
また、64bitのOSは高速ですがメモリを多く消費するので、メモリの少ない環境（2GB以下）の場合には32bit版の活用も検討すると良いと思います。

最後になりますが、改めてパフォーマンスと併せてセキュリティに関心を持ってもらえればと思います。
以前友達のパソコンにLinuxをインストールしていた時のこと、アップデートをしている間に裏でクラックされていたなんて笑えない話もありました。
最近のパッケージはそれなりに初期状態からしっかりしていますが、周りの人に迷惑をかけないためにも、きっちりとサーバ管理を行われることをお願いします。

2010/9/10追記
twitter:@tetsuro_n さんからの指摘もあり、ssh公開鍵認証の説明を追加しました。

2011/4/16変更
acpidをoffにすると、VPSなどでホスト側からシャットダウンできなくなるため、onに変更しました。