本日はConoHaアドベントカレンダーということで、今回はVPSサービスのConoHa(以下このは)を数年間使ってきて感じたことと、僕が主に進めているOSSプロジェクトである opencocon でこのはを使っている事例とかをお伝えできればと思います。
このはを振り返って:僕が見た、やんちゃで楽しいVPS
僕がこのはを知ったのは2013年頃でしょうか。そこそこリーズナブルで、自由にOS突っこめて、グローバルIP(v4, v6)が使えてということで、普通に遊べるVPSができたなーすげーという感じであったでのですが、何といってもサービスのトップページからして萌えており、デカイこのは先生がどーんと出てくるのが初期のこのはでした。
実は同時期に仕事でVPSを探してたことがあったのですが、「使えそうなのに上司に勧められない」という、すごく独特なポジションを持っていたことを思い出します。一応、なんでそうなんったん?とブースでお伺いしたことがあるのですが、「我々はこれでいきます!と決めたので・・・」という、ある意味正々堂々とした答えを頂いた覚えがあります。
あれから3年、現在は2代目このはになり、全面的にSSDを採用したりOpenStack APIを部分的に使えるようになったり、クレカ無くてもチャージできるようになった等の磨きがかかる一方、以前の萌えトップページは後ろに隠れました。より多くの人に使ってもらうために、色々と成長(意味深)したのでしょう。
ただ、初期からの萌える勢いが残る美雲このはTwitterアカウント(@MikumoConoHa)とかもありまして、これがまた昔からフリーダムでした。時期によって異なる口調、時々繰り出る若い人には絶対判らないネタ、「あーこれ中の人疲れた勢いで書いてるんやろなー」と思う場面、挙句の果てにキャラ崩壊寸前....。今はだいぶキャラ崩壊は無くなってきたようには見えるのですが、やってることが自由なのは相変わらずのようです。
僕がメモしてある、このはの過去の絡みを以下に少し挙げてみますと、こんな感じでしょうか。
<・)
( _ヲ
🔥🔥🔥🔥🔥🔥
Ahiru on Fire
— 美雲このは (@MikumoConoHa) 2015, 8月 21
@shimadah
. ____
/ ´՞ ՞`\
| し |
( ਊ }
\_____/
|| //
m m
🔥🔥🔥🔥🔥🔥🔥🔥
— 美雲このは (@MikumoConoHa) 2015, 9月 28
@shimadah あひるは焼いても いいよ(・ω・)b
— 美雲このは (@MikumoConoHa) 2015, 12月 9
(補足:あひる焼きについては、こちらで解説しています)
もうなんていうか、お互いやりたい放題な感じが...(すんません)。
恐らくこういうプロモーションに賛否は色々あるんでしょうし、たまに、おいやめろと突っ込みたくなるような場面はあるのですが、思えばこういった面もこのはがやんちゃな所以なのかなとも思っていますし、真面目にVPSサービス作ってるだけじゃおもろないんやって言わんとばかりの、提供側の熱意を感じる訳です。やっぱり遊び心あっての本気のWebサービスですよね、多分。
そんなこんなでこのはの雑感を話したところで、私がやっているこのはの活用方法を簡単に紹介したいかと思います。
このはとここん:Linuxディストリ開発にVPS使っています
さて話が変わりますが、私が中心で開発しているOSSにopencocon(おーぷんここん)というのがあります。これは、旧型コンピュータをシンクライアントにする、専用型Linuxディストリビューションです。
動作例:opencoconが動くLibretto 50。(詳しくはこの辺をどうぞ)
詳細はサイトの方を見て頂くとしまして、これは、今まで誰もが一度は考えたけどうまくは実現するのが難しかった、旧型コンピュータでシンクライアントを簡単にしたい!というアイデアを具体化したくて、僕を中心に何年か開発を続けているものです。
このプロジェクトは旧型コンピュータこそ沢山あるのですが、いかんせん肝心の資金に乏しく、僕自身経済的に苦しい時期に立ち上げたプロジェクトでした。当時は公開するための自宅サーバを引ける回線すらなかった程だったのです。そんな中、当時のお名前.com VPSさんのコミュニティ支援制度により、VPSをお借りできたおかげで、なんとかプロジェクトを軌道に乗せることがができました。その流れで、このはの開始時より引き続きコミュニティ支援を頂いており(※)、その間に10以上のリリースをVPSで作っています。
(※現在新規のコミュニティ支援はしてないそうです。ただ、面白い若手を呼び込むためにも、予算がつきましたらまたお願いできればと思っています。)
その際、折角お借りしてるVPS(といっても1台ですが)やし有効に使わんとと思い、いろいろ試した結果、VPSの中で opencocon のビルドを行いつつ、一方でサイトで公開しても問題ないぐらいのスペックだということに気づきました。そこで、以下の図のような開発体制を取ることにしました。
本来は開発と公開マシンを分割した方が良いのですが、現在はひとつのVM内で権限などで線を引くことによりなんとかしています。セキュリティ的には色々と余地があるのでしょうけど、スタートアッププロジェクトとしてはそんなにボコボコVMは立てられません。まさに貧乏プロジェクトという感じでしょうか。 (いずれなんとかしたいものです...orz)
opencocon
は各地でのブース出展を行い、それに向けてこまめにバージョンアップしながら制作を進めている訳ですが、直前までイメージを調整してその成果をCDに焼く
ことがよくあります。ただ、荷物が大変重くてビルド用マシンまで持っていくことができないですし、電源プラグがない環境で半日移動しなければならないケースも多いので、手元でビルドとかはしんどいわけです。
そこで、適当なSSHコンソールに入れるマシンと回線を持参し、そこでSSH越しにこのはのVPSに入り、そこでコーディングとビルドを行い、手元に完成イメージ(ISO等)をダウンロードして動作テストとCD焼きを行う、といったクラウド開発のような手法を取っているのです。こうすることにより、高い(出展)機動力とアーリーリリースを両立(?)できるわけです。
とまぁ、こんな経緯がありまして、現在もopencoconのサイトの横に「Compiled on ConoHa」と表示させて頂いています。
opencocon.orgの右側にあります。これは純粋なリンクでありアフィリエイトではないです。
このはで、ここんを作るベンチマークをやってみた
opencoconのユニークな点のひとつは、組み込みLinuxフレームワーク(OpenEmbedded)ベースであるということです。これは軽量化にものすごく貢献するチョイスなのですが、その代わり opencocon を生成するには、そのすべてをクロスコンパイルする必要があります。ということで、このはが実際にその観点で使えそうなVPSなん?てのを軽くスピードテストしてみようかと思います。
手前味噌なopencoconのイメージを、新このは、旧このは、あとオンプレのマシンでビルドを行い、その速度を簡単に比較してみましょう。
現行の opencocon v9 フルビルドでは、どういうことか時々コンパイル中にコケたりCPUが100%になる等、いくつかの問題を抱えているため、完全に自動化することができない状況あり、計測に適していませんし、何より時間がかかりすぎます。ですので、最低限の初期起動用initrdイメージ(initramfs-crusoe-image)の生成だけを計測することにします。
具体的には、opencocon v9のビルド方法を途中まで進め、以下のシェルスクリプトでビルドを走らせます。
(build.sh)
#!/bin/bash -
set -o nounset
source ./opencocon
startt=`date +%s`
bitbake initramfs-crusoe-image
endt=`date +%s`
echo "TIME : ` expr $endt - $startt `"
さて、比較のために用意したマシンが環境はこちらです。
具体的には、opencocon v9のビルド方法を途中まで進め、以下のシェルスクリプトでビルドを走らせます。
(build.sh)
#!/bin/bash -
set -o nounset
source ./opencocon
startt=`date +%s`
bitbake initramfs-crusoe-image
endt=`date +%s`
echo "TIME : ` expr $endt - $startt `"
さて、比較のために用意したマシンが環境はこちらです。
- その辺で拾った Core Duo ノート
Core Duo T2300 1.7GHz, Memory 1GB, HDD, Debian 8 (これのみ32bit)
- あひる焼き氏に寄贈頂いた Core i7 デスクトップ
Core i7 2600K 3.6GHz, Memoy 12GB, HDD, Ubuntu 14.04 - コミュニティ支援頂いている旧ConoHa
Xeon E5-2670 [3CPU] 2.6GHz, Memory 2GB, HDD, Debian 7 - この計測のためにチャリンチャリン(コインを入れる音)した新ConoHa
Xeon E5-2660 v3 [3CPU] 2.6GHz, Memory 2GB, SSD, Debian 8
他の条件としては、
- ビルドオプションは常に -j2 となっています。
- bitbakeでは各パッケージのソースを各サイトからダウンロードするのですが、この辺りの速度は特に気にしていません(すみません)。ですので、インターネット回線状況によりビルド時間が多少左右されることに留意が必要です。
- ディストリの違いによる動作速度の違いが考えられますが、それ自体はあまり大きくないような気もします。
- このはは共用ですので、コンディションによって一定の速度が出るとは限りません。
- このは以外の2台は、特にVMの中で動かしたとかではありませんので、その辺りも留意が必要です。
- HDD/SSDの空きは十分あるものとします。(おそらくこのレベルでは10GB程度の消費でしょう)
- 1回計測です。本当はあかんけど、これ自体ネタやし手抜きさせてくださいorz
こんな感じにビルドを廻していました。
というわけで、気になる結果はこちら。
- Core Duoノート
13377秒 →約223分 - Core i7 デスクトップ
3749秒 → 約63分 - 旧ConoHa
7261秒 → 約121分 - 新ConoHa
5091秒 → 約85分
こんな結果になりました。
考察ですが、どうもこの手のビルド処理はCPUの速さが最もモノを言うようであり、 CPUのHz数が高い i7 デスクトップがトップをマークしてしまいました。その次に、新このは、旧このは、Core Duoと続きました。
この結果から考えると、じゃあ高速なCPUの自作マシン組んでビルドを行えばいいんじゃない?とお考えの方も多いかと思います。そう言っちゃえばそうなのですが、これは物理マシンなので勿論動作音は大きいですし、さらに言うと家の回線はADSLなので、イメージがさくっとできても、直ぐにアップロードできる、というわけにはいきません。
それに対し、新このはで、計測のために500円をチャージし、4時間ぐらい動かしまして、引かれてるのがだいたい72円ぐらいでしょうか(ジュースよりも安いですね...)。もちろんデータセンターの中なので雷とか故障とか停電を気にする必要がなく、ダウンロード・アップロードともに高速でしょう。これを考えると、速度差を考慮したとしても、ビルドのためにVPSを使うのは選択肢としてありだと思うのです。
旧このはと新このはでは35分ほどの差がついているのも見どころですね。CPUは概ね似たような感じだと思うので、SSDとHDDの差が出た感じでしょうか。
今回は全体的に控えめなパラメータだったので、まだまだチューニングの余地はあると思います。
ちなみに、これまでの運用でのコンパイル時の負荷ですが、例えば3CPUプランの場合、 -j2 までであれば同時に動くWebサーバなどにあまり迷惑をかけずビルドできるかなという感じです。 それでも、opencoconのフルビルドは旧このはで6〜8時間ほどかかってしまう訳ですが・・・。
おわりに:組み込み開発でこのはを使うというアイデア
一般的にLinuxディストリビューションですとか、組み込みLinuxやAndoroidのROMは、手元の端末とかサーバでビルドするかと思います。その方がデバッグとかしやすいですし、何よりも手元で動くという安心感もあるかと思います。
では、その環境をこのはに移して使うことのメリットは何かといいますと、やはりデータセンター内にあるということと、迅速な共同開発、あと高速なダウンロードができるということでしょうか。最初からXeon、SSDといったリソースが備わった、そこそこ高速な環境が直ぐに用意できる、このはの中で開発とビルドを行うことは、ある種メリットがある使い方ですし、その上にJenkinsやBuildBotみたいなツールを乗せて自動化する使い方もありだと思います。
ただ、このはならではの最大の欠点はといえばやはりディスク容量でしょうか。大量の中間ファイルやソースコードをさばくのには工夫が必要でしょう。その点では、初日に話のあったSwiftFSの検討も要るかもなーと思っています。このは的には今更HDDって訳にもいかないでしょうが、この辺よさげな落としどころが欲しいような気もしています。
というわけで、駆け足で活用事例をご紹介しました。何かお役にたてることがあれば幸いです。
最後に、長年opencoconプロジェクトを支援頂いてるこのはとGMOの皆様、ユーザの皆様にはいつも感謝していますとともに、来年こそはもっとおもろくて便利で、謎マシンに入れて楽しいディストリビューションを生み出せればと思います。ありがとうございました。
0 件のコメント:
コメントを投稿