さくらインターネット創業日記

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

Tue, 22 Feb 2011 19:57:38 +0900

本日、双日株式会社によるさくらインターネット株式のTOBが発表されました。また、当社取締役会はTOBに対して賛同意見を出しております。さくらインターネット: 双日株式会社による当社普通株式に対する公開買付けに関する賛同意見表明及び同社との業務提携契約書の締結のお知らせ双日: さくらインターネット株式会社株式に対する公開買付けの開始に関するお知らせ今北産業で表現すると

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

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

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

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

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

Thu, 06 Jan 2011 18:50:00 +0900

最近、携帯無料ゲーム（ソーシャルゲーム）の宣伝を見ない日はありません。このソーシャルゲームですが、よく知人から「なぜ無料でできるの？本当に無料なの？」と聞かれます。そういう時には、「課金を承諾しない限り、ソーシャルゲームは永遠に無料で遊べる」と回答しています。 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出稿を減らしたとたん、堰を切ったように批判を始めるような気もしています。私個人としてもソーシャルゲームは好きですし、ソーシャルゲーム提供者の皆さんはデータセンターの大きな需要家でもありますので、上記のようなことを克服してソーシャルゲームが健全に広がっていくことが必要だと思います。

ウェブアプリで文字コードを簡単かつ確実に判別する方法

Wed, 15 Dec 2010 13:35:29 +0900

最近、某とあるサイトにて文字化けが起こるという申告が増えてきました。理由は2つあって、ひとつは携帯（AU）からのアクセスが増えてきたということ、もうひとつは海外からの利用が増えてきたことです。いちおう明示的にUTF-8と指定しているのですが、ＡＵさんはShift-JISで送ってきたり、中国語のよく分からないクライアントはGB2312で送ってきたりして、文字判別は一筋縄にはいきません。今回は、文字化けを防ぐ改造に当たってやったことを書きたいと思います。文字化けの話はGoogleででも検索をさて文字コードを自動判別するという技術は色々あって、よく利用されるのは特定の文字コードでしか利用されない文字を探し当て、判別するというものです。言わずと知れた漢字コード変換コマンドである nkf でも、上記の方法で非常に精度の高い自動判別を行ってくれます。ただ、これには大きな問題があります。それは「短い文字列だと判別できない」ということです。某とあるサイトでは、単語を入力してロゴを作るというウェブサービスを提供していますが、入力される文字列が短いことからうまく自動判別がうまくいきません。そのため今回取った対策は、submitされるフォームデータと共に判別用文字列を送るというものです。例えば「文字」という文字列をUTF-8で送ると%E6%96%87%E5%AD%97となり、Shift-JISで送ると%95%B6%8E%9Aとなります。ですので、判別用文字列がどのような文字列になって送られてきたかを見ると、他のフォームデータの文字コードを知ることが出来るというわけです。それでは実際のプログラムです。 detectstrのところが、判別用文字列を埋め込んだところです。ちなみに「文字」というのを利用した理由ですが、日本語のみならず、中国語簡体字、中国語繁体字においても同じ形だからということです。例えば自動という文字の場合は、簡体字で動という文字が異なるコードになってしまいますので利用できません。なお最初は「日本」という文字を判別用文字列にしていたのですが、hiddenで日本という文字列が入っていると中国の利用者の方からいらぬ誤解を受けたり都市伝説化するのも嫌なので、途中で変えました。送信側プログラム




名前:

受信側プログラム


 "%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);

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

ddコマンド実行途中に、何バイトコピーできたかを見る方法

Thu, 09 Dec 2010 08:17:37 +0900

知り合いと話していた際に、「ddコマンドでディスクをコピーしているとき、scpのようにプログレスバーが表示できたらいいのに」という話を聞きました。意外と知られていないのですが、USR1シグナルを送ることで途中経過を表示させることが可能です。 [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を利用する際は大きなファイルのことが多いので、途中で経過が見えるだけでもストレスが減るのではないでしょうか。ちなみに私は、上記の出力を元にプログレスバーを表示するスクリプトを作りました。

なぜもめる？日本におけるドメイン登録独占の影響

Thu, 04 Nov 2010 16:11:05 +0900

先日、GMOの熊谷社長が自身のブログ上において、JPRSさんがレジストラ業務を開始することについての公開質問を掲載されました。株式会社日本レジストリサービス（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 更新)

CentOSをサーバーとして活用するための基本的な設定

Fri, 10 Sep 2010 17:34:00 +0900

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

本解説は特にさくらのVPSに限ったものではなく、CentOS全般を対象にしています。
さくらのVPSのデフォルトでは、多くのデーモンを停止済みにしているほか、selinuxもdisabledとなっています。

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

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

#Port 22 Port 10022

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

# 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 #

PermitRootLogin without-password

PasswordAuthentication no

次に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

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

chkconfig acpid 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

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

#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

selinuxを無効にします

SELINUX=disabled

これで設定は完了です。再起動を行うことで、全ての設定変更が反映されます。 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をインストールしていた時のこと、アップデートをしている間に裏でクラックされていたなんて笑えない話もありました。最近のパッケージはそれなりに初期状態からしっかりしていますが、周りの人に迷惑をかけないためにも、きっちりとサーバ管理を行われることをお願いします。

さくらのVPSにFreeBSDをインストールする

Sat, 04 Sep 2010 12:05:56 +0900

さくらインターネットでは、先日より「さくらのVPS」を提供開始し、予想を上回る大ヒットサービスとなっています。特徴を言い始めるとキリがありませんが、国内の格安VPSとしては初めてKVMの完全仮想化を実現し、インストールできるOSの可能性は大きく広がっていることも大きな特徴の一つでしょう。そのようなことから、近日中にも、Ubuntu、Debian、Fedora、FreeBSDなどの様々なOSを、コンパネ上から自由にインストーラーを起動できるように準備を進めております。ただ、本日は「正式対応まで待てない！」という人のために、さくらインターネットの1ユーザとしての立場からFreeBSDのインストールを試した際の作業メモを公開します。なお、完全に無保証ですし、あくまでも1ユーザ（ちゃんと自分で支払ってますよ）としての立ち位置でのメモですので、くれぐれもサポートなどに問い合わせを頂かないよう理解頂ければ幸いです。それでははじめていきましょう。手順は、スワップパーティションを削除してFreeBSDのインストールイメージを展開し、GRUBからインストーラーを起動し、インストールを行うというものです。

設定情報をメモする

ホスト名	www30xxu.sakura.ne.jp
デフォルトルータ	59.106.176.1
IPアドレス	59.106.176.xx
ネットマスク	255.255.254.0
ネームサーバ	210.188.224.10 210.188.224.11

nameserver 210.188.224.10

nameserver 210.188.224.11

59.106.176.xx

255.255.254.0

59.106.176.1

www30xxu.sakura.ne.jp

OSを初期状態に戻す

https://secure.sakura.ad.jp/menu/service/?mode=S1010

スワップパーティションを削除

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
#LABEL=SWAP-vda3         swap                    swap    defaults        0 0 ← ここをコメントアウト

スワップパーティション跡にOSのインストールイメージを展開
GRUBを変更

title FreeBSD Install
        rootnoverify (hd0,2)
        chainloader +1

VNC（リモートデスクトップ）を起動

https://secure.sakura.ad.jp/vpscontrol/main/vnc

@utaaniさん

再起動してインストーラーを起動

通常通りにインストールを行う

無事インストール完了！

さくらのVPSと互換の実験環境ではWindows（XP / Vista / Server 2008）のインストールもできましたので、もしかしたら可能かもしれませんね。 ※ただしWindowsのデスクトップ向けOSは仮想環境で動かせるライセンスが無いようですので、インストールして利用してしまうとライセンス違反になりますからご注意ください。以上、FreeBSDのインストールでした。しつこいようですが、公式にはFreeBSDは使えないことになっていますので、その点はご理解いただければ幸いです。今後、公式なOSインストール機能も予定しており、IPアドレス逆引きや、IPv6対応、上位プラン（できればCPU占有プラン）などのアナウンスもできるかと思いますので、全ての環境をさくらのVPSでということも可能になります。これからも、さくらインターネットおよびさくらのVPSを、どうぞよろしくお願いします。

さくらのＶＰＳ提供開始にあたり

Wed, 01 Sep 2010 16:30:00 +0900

本日より、さくらインターネットの新しい柱となる仮想化サービスの第一号として、さくらのＶＰＳを販売開始することとなりました。さくらのＶＰＳお申し込み受付開始のお知らせ皆様からは「えっさくらがＶＰＳをやるの？」という声も多く頂いており、その反響の大きさに驚いています。そもそも、昨年あった＠ＩＴの取材においては「劣化専用サーバとなるＶＰＳはやらない」と豪語しており、同業者の会合でも「さくらはＶＰＳやらない」と宣言していました。大阪・堂島に、さくらインターネットの秘密を見た ?自前だからできる本当の差別化 http://www.atmarkit.co.jp/ad/sakurainet/200905/doujima.html その理由としては、仮想化を行うより、専用サーバでとことん安くしたほうが良いのではないかという考えがあります。コンソール機能や再起動などはＩＰＭＩ（Keyboard VGA Mouse = KVM）によって専用サーバでも実現できますし、さくらの専用サーバについては、翌営業日納品も実現していますから、仮想サーバで無いとできないと思われていることも実現が進んできています。また、仮想化することはオーバーヘッドを生むことにもつながり、ＣＰＵパワー度無駄にする側面もあります。しかし、仮想化には代えがたい優位性があることも事実です。例えば、専用サーバアドバンスドプランのQuadCore Xeon×２ＣＰＵ構成の場合、初期費用無料で月額35,800円ですが、仮想化して8分割すれば1コアあたり4,475円となります。低価格専用サーバはAtom Z530を4,500円程度+初期費用で提供予定でしたが、ATOMの1コアとXeonの1コアだと仮想化のオーバーヘッドを考えてもXeonのほうが高速であり、さらには安価に提供できるという状況になってしまいます。私自身がやっている某サイト（とある櫻花の画像生成）においても、データベースやリバースプロキシ、画像配信などを、仮想化を使って複数のサーバに分けて運用することにより、アクセス急増時も効率よくサーバ運営が出来たという経験があり、比較的安価にサーバ分割が出来る仮想化の利便性を知ることになりました。結局、既存形態のサービスに固執するがあまり、さくらインターネットが本来強みとしていたＩＴリテラシの高いユーザへのサービスへの魅力が薄れ、そのようなユーザが海外のクラウドや格安ＶＰＳへ流出し始める状況に至ります。このような事から、仮想化の推進を行い、さらにＶＰＳやＩａａＳへの拡大を進めていくことを決断し、第一号としてさくらのＶＰＳを提供開始することとなりました。 4月末に「ＶＰＳやるぞ。でも全て自社開発で」と突然言い出してから、2カ月程度でベータ提供にこぎつけたのは社員の頑張りのおかげでもあり、大変感謝しています。今後は、専用サーバのさらなるスペックアップと並行して、仮想化による柔軟性や手軽さを追求したサービスを拡大していきます。なお、さくらのＶＰＳの登場で既存の専用サーバが売れなくなるのではという意見もあります。この意見については当然の事ですし確かに大きな影響があると考えていますが、今回のＶＰＳを始めるにあたってはそのような影響を一切無視してサービスづくりを行いました。専用サーバが売れなくなるのであれば、それは専用サーバの魅力が薄れていただけの話であり、その様なサービスは遅かれ早かれ他社（または海外）に駆逐されるだけだと考えています。先にシェアを取っている会社は常に既存の売り上げとのバランスを考えがちです。しかし、さくらのレンタルサーバにしても、専用サーバプラットフォームＳＴにしても、常に既存の売り上げに固執せず、新しい柱を創ることへ注力してきました。ですので、今後も性能、品質、サポート、価格など全ての面に妥協することなく、さくららしいサービスを創っていくことを皆さんにお約束します。ところで、さくらインターネットでは石狩へのデータセンター建設を進めております。クラウド化する中で、インフラのコストパフォーマンスはさらに重要になってきており、高いコストパフォーマンスを実現できる理由としてのインフラ追求はますます必要です。しかしながら、重要なのはインフラだけでなく上に乗るサービス自身もだと考えています。今後は、インフラに、サービスに、全てのレイヤーを自前で行えるという強みを伸ばし、さらなるサービス拡充に努めてまいりますので、今後ともよろしくお願いいたします。

「さくらのVPS」を使ってみる

Sat, 17 Jul 2010 13:13:27 +0900

先日、「さくらのVPS」のベータテストが開始されました。私も個人的にさくらのレンタルサーバを利用しているので、7月14日にフライングして申し込みしました。（最終テスト中だったようで、社員にまじめに怒られてしまいましたが・・。スイマセン）まず基本仕様

CPU 2コア
メモリー 512MB
HDD 20GB
ネットワーク 100Mbps(いちおうの上限)
リモートコンソール付き
再起動、再インストールは、セルフサービスでコンパネから可能

ホスト側は、QuadCore Xeonで、1Gbpsにて上位スイッチに接続し、10Gbpsでさくらインターネットの基幹ネットワークに接続しています。（クローズドベータテスト中に400Mbps位出たという記事もありましたが、さすがに対策する予定です）ハイパーバイザーは、巷の格安VPSで多く利用される、VirtuaozzoやOpenVZ、Xenの準仮想化と異なり、KVMで完全仮想化になっています。完全に512MBの実メモリを割当しますから、ホストOS側でスワップされずパフォーマンスが低下しないですし、ゲスト環境側でスワップを用意することも可能です。実メモリは、ゲストで必要とするメモリ容量の1.5倍?2倍程度を搭載しています。というのは、ホストOSのメモリの2/3以上をゲストに割り当てると、過負荷時のレスポンスが急激に悪化したり、不安定になったりということが言われており、当社でも再現されているので、余裕を持った設計にしています。さらに、ホストOSのメモリの余裕を持たすことで、ディスクI/Oも劇的によくなります。ゲストOSのスワップ時でも、ホストOSのキャッシュに入っていれば、メモリの延長上といえるかもしれません。このように、100Mbpsインターフェース、20GBのHDD、2 CPU、512MBメモリといっても、同種のVPSサービスとは一線を画します。その上で、「格安VPS」といえる価格帯で出す予定にしていますので、海外にも増してメリットのあるサービスになるのではと考えています。と、宣伝はここまでにして、早速利用してみます。まず、私が行ったのは、sshの公開鍵を設置してrootログインできないようにすることです。申し込み直後は、ほぼ最新のパッチを当てて出荷されますので、いきなりクラックされることは考えなくてもよいと思いますが、なんとなく不安です。（対策として、ネットワークをシャットダウンしたまま出荷するオプションを用意するなど、検討の余地があると考えています。）ということで、ssh-keygenを行い、/etc/ssh/sshd_configにrootでのパスワードログインを禁止します。

[root@www10xxu ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
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:
1b:f0: root@www10xxu.sakura.ne.jp
[root@www10xxu ~]#

/etc/ssh/sshd_config
変更前
PermitRootLogin yes
変更後
PermitRootLogin without-password

[root@www10xxu ~]# service sshd restart

次に無駄なデーモンをoffにします。さくらのVPSの初期状態において脊髄反射で感じるのは「思いのほか空きメモリが少ない！」ということです。 ps -aux結果

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  10348   688 ?        Ss   Jul15   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S<   Jul15   0:03 [migration/0]
root         3  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S<   Jul15   0:01 [migration/1]
root         6  0.0  0.0      0     0 ?        SN   Jul15   0:00 [ksoftirqd/1]
root         7  0.0  0.0      0     0 ?        S<   Jul15   0:00 [watchdog/1]
root         8  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/0]
root         9  0.0  0.0      0     0 ?        S<   Jul15   0:00 [events/1]
root        10  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khelper]
root        15  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kthread]
root        20  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/0]
root        21  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kblockd/1]
root        22  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kacpid]
root        90  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/0]
root        91  0.0  0.0      0     0 ?        S<   Jul15   0:00 [cqueue/1]
root        94  0.0  0.0      0     0 ?        S<   Jul15   0:00 [khubd]
root        96  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kseriod]
root       168  0.0  0.0      0     0 ?        S    Jul15   0:00 [khungtaskd]
root       169  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       170  0.0  0.0      0     0 ?        S    Jul15   0:00 [pdflush]
root       171  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kswapd0]
root       172  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/0]
root       173  0.0  0.0      0     0 ?        S<   Jul15   0:00 [aio/1]
root       317  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kpsmoused]
root       361  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/0]
root       362  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata/1]
root       363  0.0  0.0      0     0 ?        S<   Jul15   0:00 [ata_aux]
root       373  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kstriped]
root       386  0.0  0.0      0     0 ?        S<   Jul15   0:04 [kjournald]
root       407  0.0  0.0      0     0 ?        S<   Jul15   0:00 [kauditd]
root       435  0.0  0.1  12672   764 ?        S

まず、コンソール（mingetty）はこんなに要らないので、減らします。 /etc/inittabを以下のように編集

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
#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

デーモンも減らします。

[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig haldaemon off
[root@www10xxu ~]# chkconfig yum-updatesd off
[root@www10xxu ~]# chkconfig acpid off
[root@www10xxu ~]# chkconfig messagebus off

これで再起動すれば、ずいぶんとメモリの空きができます。再起動後に確認すると、使用中は150MBとなっていました。もう少しがんばれば、もっと削減できそうです。なお、unixbenchも実行してみました。 index scoreは1540.6ですので、そこそこ速いのではないでしょうか。

   #    #  #    #  #  #    #          #####   ######  #    #   ####   #    #
   #    #  ##   #  #   #  #           #    #  #       ##   #  #    #  #    #
   #    #  # #  #  #    ##            #####   #####   # #  #  #       ######
   #    #  #  # #  #    ##            #    #  #       #  # #  #       #    #
   #    #  #   ##  #   #  #           #    #  #       #   ##  #    #  #    #
    ####   #    #  #  #    #          #####   ######  #    #   ####   #    #
   Version 5.1.2                      Based on the Byte Magazine Unix Benchmark
   Multi-CPU version                  Version 5 revisions by Ian Smith,
                                      Sunnyvale, CA, USA
   December 22, 2007                  johantheghost at yahoo period com
1 x Dhrystone 2 using register variables  1 2 3 4 5 6 7 8 9 10
1 x Double-Precision Whetstone  1 2 3 4 5 6 7 8 9 10
1 x Execl Throughput  1 2 3
1 x File Copy 1024 bufsize 2000 maxblocks  1 2 3
1 x File Copy 256 bufsize 500 maxblocks  1 2 3
1 x File Copy 4096 bufsize 8000 maxblocks  1 2 3
1 x Pipe Throughput  1 2 3 4 5 6 7 8 9 10
1 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10
1 x Process Creation  1 2 3
1 x System Call Overhead  1 2 3 4 5 6 7 8 9 10
1 x Shell Scripts (1 concurrent)  1 2 3
1 x Shell Scripts (8 concurrent)  1 2 3
2 x Dhrystone 2 using register variables  1 2 3 4 5 6 7 8 9 10
2 x Double-Precision Whetstone  1 2 3 4 5 6 7 8 9 10
2 x Execl Throughput  1 2 3
2 x File Copy 1024 bufsize 2000 maxblocks  1 2 3
2 x File Copy 256 bufsize 500 maxblocks  1 2 3
2 x File Copy 4096 bufsize 8000 maxblocks  1 2 3
2 x Pipe Throughput  1 2 3 4 5 6 7 8 9 10
2 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10
2 x Process Creation  1 2 3
2 x System Call Overhead  1 2 3 4 5 6 7 8 9 10
2 x Shell Scripts (1 concurrent)  1 2 3
2 x Shell Scripts (8 concurrent)  1 2 3
========================================================================
   BYTE UNIX Benchmarks (Version 5.1.2)
   System: www1010u.sakura.ne.jp: GNU/Linux
   OS: GNU/Linux -- 2.6.18-194.8.1.el5 -- #1 SMP Thu Jul 1 19:04:48 EDT 2010
   Machine: x86_64 (x86_64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5319.4 bogomips)
          x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   CPU 1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (5290.9 bogomips)
          x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   10:15:43 up 1 day, 19:18,  2 users,  load average: 0.02, 0.02, 0.00; runlevel 3
------------------------------------------------------------------------
Benchmark Run: Sat Jul 17 2010 10:15:43 - 10:43:56
2 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables       14188657.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3011.2 MWIPS (9.8 s, 7 samples)
Execl Throughput                               1775.5 lps   (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        709457.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          210832.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1449865.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1955338.6 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 259909.8 lps   (10.0 s, 7 samples)
Process Creation                               8795.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4125.4 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1416.6 lpm   (60.0 s, 2 samples)
System Call Overhead                        3385128.4 lps   (10.0 s, 7 samples)
System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   14188657.9   1215.8
Double-Precision Whetstone                       55.0       3011.2    547.5
Execl Throughput                                 43.0       1775.5    412.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     709457.6   1791.6
File Copy 256 bufsize 500 maxblocks            1655.0     210832.6   1273.9
File Copy 4096 bufsize 8000 maxblocks          5800.0    1449865.3   2499.8
Pipe Throughput                               12440.0    1955338.6   1571.8
Pipe-based Context Switching                   4000.0     259909.8    649.8
Process Creation                                126.0       8795.8    698.1
Shell Scripts (1 concurrent)                     42.4       4125.4    973.0
Shell Scripts (8 concurrent)                      6.0       1416.6   2361.0
System Call Overhead                          15000.0    3385128.4   2256.8
                                                                   ========
System Benchmarks Index Score                                        1157.7
------------------------------------------------------------------------
Benchmark Run: Sat Jul 17 2010 10:43:56 - 11:12:10
2 CPUs in system; running 2 parallel copies of tests
Dhrystone 2 using register variables       27985122.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     5992.4 MWIPS (9.7 s, 7 samples)
Execl Throughput                               7332.5 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        218518.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           63801.8 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        502186.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                             3771938.1 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 775819.3 lps   (10.0 s, 7 samples)
Process Creation                              20049.5 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   9979.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1579.2 lpm   (60.0 s, 2 samples)
System Call Overhead                        5635202.3 lps   (10.0 s, 7 samples)
System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   27985122.2   2398.0
Double-Precision Whetstone                       55.0       5992.4   1089.5
Execl Throughput                                 43.0       7332.5   1705.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     218518.6    551.8
File Copy 256 bufsize 500 maxblocks            1655.0      63801.8    385.5
File Copy 4096 bufsize 8000 maxblocks          5800.0     502186.1    865.8
Pipe Throughput                               12440.0    3771938.1   3032.1
Pipe-based Context Switching                   4000.0     775819.3   1939.5
Process Creation                                126.0      20049.5   1591.2
Shell Scripts (1 concurrent)                     42.4       9979.2   2353.6
Shell Scripts (8 concurrent)                      6.0       1579.2   2632.1
System Call Overhead                          15000.0    5635202.3   3756.8
                                                                   ========
System Benchmarks Index Score                                        1540.6

と、雑多にまとめてみました。なお、ただいまベータテスト中で、追加予定機能は山のようにあるので、状況を見ながらアップデートして行きたと思います。ツイッターでもさまざまな要望を頂いていますが、ぜひ参考にさせていただきたいので、コンパネ上の「ご意見・ご要望」もご活用ください。

「さくらのVPS」はじまります

Sat, 17 Jul 2010 10:17:38 +0900

バレンタインデーのラックチョコ以来、ずいぶん更新をサボってしまいましてすいません。最近、ツイッターで意見や感想を吐き出してしまうので、なかなかブログの更新ができておりませんでした。どうも、考えが成熟する前に、小出しでつぶやいてしまうのがアカンです。ブログで書くからウェブサイト更新をしなくなり、ツイッターでつぶやくからブログを書かなくなり、次はどうなるのでしょうか・・。さて、さくらインターネットでは9月より「さくらのVPS」と称してVPS（仮想専用サーバ）サービスを始めることを発表し、さる7月15日よりクローズドベータテストを開始することになりました。ただ、十分だろうと考えていた200ユーザ（急遽300ユーザに拡大）の枠があっという間にいっぱいになってしまい、すべての方に試用頂けていないことを深くお詫びいたします。ついては、ベータテストのユーザ数を増やすべく、サーバーやラック、ネットワークの準備を進めることにしましたので、8月初旬より追加で募集が可能な見込みです。今回のVPSを開始するにあたり、社内外から「さくらはVPSやらないんじゃなかったっけ？」という話をいただきました。とある記事では、「劣化専用サーバとしてのVPSには競争力はない」などと豪語し、周りからは「さくらはVPSをやらない」と言われてきましたが、サーバ再起動やOS再インストール、コンソールといった、VPSならではの管理機能を搭載してリリースすることにしました。今後、専用サーバにIPMIを搭載して、VPS同様に管理機能をサポートする予定であり、ハイスペックな専用サーバと、リーズナブルなVPSをハイブリッドで提供していくことにしています。併せて時間課金などのシステム強化を行い、仮想サーバをベースとしたIaaSや、KVSなどのPaaSを拡大させて、さくらインターネットらしいクラウドサービスにしていく予定にしています。さくらインターネットでは、先日発表した石狩データセンターによって米国と同様のコスト構造を手に入れるとともに、上記のようなクラウドサービスによるサービスの柔軟性を達成したいと考えています。また、東京都心の1,000ラック以上を活用し、クラウド、ホスティング、ハウジングのハイブリッドサービスを追及していく予定です。これらによって、海外にも通用し、日本国内においてはさらに優位性を発揮できる強いさくらインターネットを作り上げていきます。

ラックマウント型のバレンタインチョコ

Wed, 17 Feb 2010 13:37:40 +0900

先日はバレンタインデーでしたが、女性社員から、ある意味手作りなチョコレートをもらいました。みる人が見ればわかる、そうラック型の箱に入ったチョコです。ちなみに、ラックは手作りで、中にはチロルチョコが入っています。以下は、ラックが並んだところ。壮観ですね。ただ、チョコはラックに乗っかっているだけなので、うっかりするとポロっと落ちてしまいます。実際のデータセンターでも、ラックにマウントしていないお客様を見かけますが、サーバーがポロっと落ちたとなるとシャレになりませんから、地震対策用具などを活用して事故の無いようにお気を付け下さい。ところで、嫁さんからは蛙チョコを貰いました。リアルです。

遅いHappy New Year!

Tue, 16 Feb 2010 00:11:55 +0900

先日、「さくらインターネットのサバ手ぬぐいが出来ました」を紹介しましたが、それに触発されて絵心を発揮する社員が増えてきました。その中で、私の似顔絵の入った新年あいさつのはがきを作ってきたつわものがおり、せっかくなので紹介しておきます。ちなみに、なぜ電車の運転士かというと、私が電車好きであることをした上でのことだと思われます。猫はうちでやってる、さくらのレンタルサーバのキャラだと思いますが、何とも胡散臭い仕上がりになっています。本当は先月紹介されたのですが、なにはともあれ今年もよろしくお願いいたします。

kumofsを使う

Mon, 18 Jan 2010 17:00:22 +0900

最近KVS（Key-Value-Storage）が流行っていますが、うちの研究所においても「えとらぼ」さんと共同でkumofsの研究をしています。色々とバギーなところも多いのですが、最新パッチを頂きながら、それなりに成果が出てきたようです。 kumofsの詳細については、さくらインターネット研究所に任せることにして、今回は一般にソースが公開されたこともあるので個人的にインストールした際のログを紹介します。 1. まず関連する諸ライブラリのインストール libtoolのインストール # yum install libtool OpenSSLのインストール # yum install openssl-devel BZip2ライブラリのインストール（tokyo cabinetインストールのために必要） # yum install bzip2-devel 2. msgpackのインストールダウンロード http://msgpack.sourceforge.jp/ 私は、msgpack-0.4.0.tar.gzをダウンロードしました。ここで注意！私の環境で ./configure && make した際、インストールは無事完了したものの、いざライブラリを使おうと思うと、__sync_sub_and_fetch_4が無いとのエラーが出ました。 kumofsの./configureをconfig.logより

configure:19500: checking for main in -lmsgpack configure:19524: gcc -o conftest -O4 -Wall -O4 -L/usr/local/lib/ -mtune=i386 conftest.c -lmsgpack -lcrypto -lz -lpthread -lstdc++ >&5 /usr/local/lib/libmsgpackc.so.2: undefined reference to `__sync_sub_and_fetch_4' collect2: ld returned 1 exit status configure:19530: $? = 1

__sync_sub_and_fetchというのは、マルチスレッド環境下においてアトミックな加算処理を行うためのgcc組み込み関数ですが、なぜか_4が付いてしまっています。これはgccの仕様で、引数の型を見て、その型のビット長を付けるためだと分かりました。例えば今回の場合、4バイトなので「_4」をつけられています。まあ、これはいいのですが、-march=i686をつければgccの挙動が変わるとのことなので、msgpackの./configure前には CFLAGSとCPPFLAGSにセットしておくことで回避しました。 # tar xvfz msgpack-0.4.0.tar.gz # cd msgpack-0.4.0 # export set CFLAGS=-march=i686 # export set CPPFLAGS=-march=i686 # ./configure # make # make install ※参考になったサイト仙石浩明の日記: __sync_bool_compare_and_swap_4 とは何か？ ? glibc をビルドする場合は、 gcc の --with-arch=i686 configure オプションを使ってはいけない 3. tokyo cabinet のインストール http://1978th.net/tokyocabinet/ 私は、バージョン1.4.41をダウンロードしました。 # tar xvfz tokyocabinet-1.4.41.tar.gz # cd tokyocabinet-1.4.41/ # ./configure # make # make install 4. kumofsのインストールダウンロードは、古橋さんのサイトからできます。 http://d.hatena.ne.jp/viver/20100118/p1 私は、githubよりkumofs-0.3.0 をダウンロードしました。次に /usr/local/lib がライブラリに含まれるよう、環境変数をセット。（私の場合、新しい環境だったので、これがないと cannot find -lmsgpack となりました） # export set LDFLAGS=-L/usr/local/lib 早速ビルドを開始 # ./bootstrap # ./configure # make # make install とりあえず、インストールは完了したようです。早速起動と行きたいところですが、また時間を見つけてクラスターを組んでみたいと思います。なお、うちの研究所では型落ちのサーバを山のように用意して、実験をしているようですので、パフォーマンスなど実際のレポートは、そちらを期待してください。私のほうでは、とりあえず画像生成サイトなど、個人的にやっているいくつかのサイトのバックエンドを、kumofsにしてみようかと思っています。 Apache用のmod_kumofsとかを作って、kumofsに格納されたバリューを、直接クライアントに返すなんてこともやってみたいところです。将来的には、mysqlのように、共用サーバやクラウドでのインスタンス貸しをしてみたいものですね。

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

Fri, 01 Jan 2010 00:00:00 +0900

皆様あけましておめでとうございます。旧年中は大変お世話になり、ありがとうございました。公私共に、飛躍の年にしたいと思いますので、どうぞよろしくお願いいたします。皆様にとってよい一年になることを、祈念しています。

とある櫻花の画像生成（ジェネレーター）

Wed, 23 Dec 2009 10:29:24 +0900

いろんな人たちから「何やってんだ（笑）」と言われつつも、とある櫻花の画像生成が完成しました。 http://to-a.ru 元ネタは言わなくてもお分かりいただけるでしょうが、某禁書目録や某超電磁砲のタイトル風画像を作れるだけのサイトです。ちなみに、「とある画像の自動生成」というサイトが既にあるのですが、Silverlightベースなのでクライアントのインストールが必要ですし、そのほかにも改良したいところが多かったので、自分で作りました。改良したところ

サーバでの生成方式に変えた
グラデーションの粒度を細かくした
すべての文字にアンチエイリアスをかけた
フォントを極太明朝に変えた（HG明朝Ｅ）
サーバへの保存機能を設けた
とある???で、3文字入力を可能にした→ ex. とあるラジオの超電磁砲

今回は、ＰＨＰ＋ＧＤで書いたのですが、文字に斜めの滑らかなグラデーションをかけるのは意外と難しく、文字データとグラデーションを別個で作って、独自のルーチンで合成するということをしました。 ImageMagickのレイヤーを使えば簡単だと言う情報をさまざまな人から寄せられたのですが、「プログラマたるもの制約の中で最高のアウトプットを出さんとあかん」ということで、ＧＤのままです。（といいつつ、「ここまで作ったしＧＤでいいや」ってのが本音ですｗｗ）まず、グラデーションを生成するコード。