前に一緒の会社にいて遊びでスタジオ入ったことのある方に会社紹介かねて久々に会った。その時に「最近ライブに全然行ってないんですよね～」と言ったらちょうどよく今やっているバンドのライブがあるとのことだったので、行ってきた。

そのバンド名は「軌道共鳴」。アマチュアバンドながらにすでに2枚目のミニアルバムを出していて iTunes からもダウンロードできるらしい。URL は http://or.kuro-music.com/

「和製 Dream Theater みたいですよ。」という感じの曲をやるらしい。

ライブに行く前に音源を入手して聞いてみた。おー、Dream Theater ぽい。どこかで聞いたフレーズも取り入れつつ、しっかり変拍子とかいれてプログレになってる。曲の感じとしては Dream Theater の 2nd アルバム “Image and Words” からの印象が強いかな。”Take the Time” みたいな曲もあったし。キーボードの音色はそのまんまな感じ。ボーカルのメロディーは Dream Theater ほどメロディアスではなく独特な感じを受けた。日本語onlyの歌詞だからかもしれない。

しかし、うまいなぁ。音いいなぁ。Dream Theater を弾きこなせるくらいだから当たり前なのかもしれないけど、

Dream Theater 好きな自分としては当日が楽しみになった。ライブの生音を聞きに行くのは本当に何年ぶりだろう。多分5年以上はたっている気がする。

ライブ当日の演奏もやはりうまかった。それぞれの演奏技術があるから難しい曲も演奏できている。特に目立ったミスはなかったと思う。特にドラム、すごいなこれは。安定しつつ手数の多い難しい変拍子とかたたけちゃうのか。。。ここまでうまい人たちは初めてかもしれない。大学の時に聞きにいった Dream Theater のライブよりちゃんと弾いているかもw

演奏とは関係ないけど音作りと言うか、それぞれのパートの音がはっきり聞こえるための音作りとかバランスとかって難しいなと思った。ドラムの手数が多くなって盛り上がっていく時にギターとキーボードが聞こえなる。その時に難しいフレーズ弾いているんだろうけど残念ながら聞こえない。今回の箱は座れるシートで50席くらいの小さいところだったので、距離が近くドラムが大きく聞こえがちなのかもしれない。

自分もスタジオで音を作る時に他のパートとかぶらないように気にしたいけどよく分からなくていつも適当にしている。

しかし、うまい人の演奏聞けて楽しかった～。また自分も練習したくなった。軌道共鳴の方々お疲れ様でした。また、機会があえば聞きにいけたらと思ってます。

Dream Theater 好きで興味ある方は今なら無料で音源が手に入るそうなので http://or.kuro-music.com/ をチェックしてみてください。

先週、打ち合わせ中にパートナーさんからもらった質問で、自分としてもまとめるいい機会になったのでメモしておく。

その質問は「深海さんは会社としてどんなことをしたいですか。」というもの。

最近、会社のスタンスやフィールドを整理していたが、もっと大きな視点で何が実現できればOKかというところで、その場で考えながらまた思い返しながら質問に答えた。

この答えは会社を作る過程で描いていた訳だが、少し時間が経ち無意識ながらに持っているような状態になっていて、答えるのに少し間をあけた。結果的に思ったよりも整理できたのが意外だった。自分だけで理解しておくことと相手に伝えようとすることは言葉の使い方が変わってくるのだなと思った。

きれいな文章になってはいないが、箇条書きにしておく。

• シェイクソウルに関わる顧客、パートナーの価値が一つ上がること</p>
  • 価値 : 売り上げ、スキル、効率化など、経営的インパクトに近い方がよい
  • 対象となる会社と一緒になって価値を上げていく感覚
• 世の中の先端的なフィールドで求められるサービスを提供する
  • あまりに先端的すぎると実現要望薄く研究になってしまうので、時代の半歩先の部分がいい
  • 自分のところにないスキルがあれば、パートナーと一緒になって作っていく
  • パートナーシップ : 対等な関係、お互いのスキルを補完しあう関係、マイナス方向に引っ張りあうのはNG、上下関係もNG
• シェイクソウルだからできることをやる
  • 誰もができる単純な仕事は、生み出せる価値が低いのでやる意味がない
• 単発的に案件をこなすことはない。最終的には顧客自身ができなかったことができるようになることがゴール
  • 教育、レクチャーというサービスメニューは永続的なスキルの維持/向上するために作ったもの

ひとしきり答た後、そのパートナーさんは「なんだか、VCみたいですね」と言った。

お金しか出さない日本のVCを連想した自分はその時は同意しなかったが、投資対象とする会社をサポートして、あらゆる面の価値を上げて exit を目指すような VC の理想を考えるにそれはおおむねあたっているかと思った。ただ、こちらはお金は出さずに実践的な技術面でのアプローチが強いことになるけど。

答えの視点に常に対象物がある理由は、シェイクソウルは会社のサイズが大きくない(今後も大きくするつもりもない)ので単体の価値を高めたところで何もしなければ意味はない。対象物に何を提供できるかでシェイクソウルの価値が測れるし、存在意義が出てくるのかと思う。

幸い会社を作って5ヶ月が経過したが、優良なパートナーと一緒に Amazon EC2 フルサポートパックのような、時代の半歩先のサービスを作れているし、徐々にシェイクソウルの存在を知ってもらえて興味を持っていただけているのでおおむねこの考え方で良かったし、これからもまだ行けそうだと思っている。

誰かのお勧めな本として紹介されていていたのと、本田宗一郎の本は今まで読んだことなかったので読んでみた。

iPhone 3GS(いつの間にか “S” の前のスペースはなくなっているようだ)発売日のこの日に 日本Androidの会 主催の Android Bazaar and Conference 2009 Spring が開かれ、行ってきました。

聞けたセッションは4つ。自分にとってもこれからアプローチしようとしている Android なだけに、今まで取り組まれてきてらっしゃる方々のセッションは現状どこまで行っているのかも含め是非聞いてみたかった。

会場の部屋は満席で若干の立ち見が出る盛況ぶり。その日のワールドビジネスサテライトでも「携帯の今後」のような切り口として、iPhone 3GS 発売のニュースと合わせてこのカンファレンスの紹介もされていた。

参加者の層はやはり若く、20前半から後半でほぼ9割くらいだろうか。ソフトウエアエンジニアさんばかりなのだろう。女性率1%未満。一部、白髪のおじいちゃんらしき人たちも混ざっていたが、メモも取らずにPCでブラウジングにいそしんでいたり、爆睡しているだけだったので、関係者ではなく主旨知らずに入っちゃったよな方々かと思う。

以下つたないメモと自分なりの一言感想。

当日の資料は公開される予定らしい。

A-1 オープンソースアプリ戦略

13:30-14:10 佐々木さん

• Apache2.0 のライセンスに収める</p>
  • 下 BSD, GPL
• Map は 独自IPアプリ 付けれる # IP: 違う意味で使っている？
  • Apache2.0 錠にすればクローズにすることができる
  • ソースコードを公開しなくてもいい

• OPhone の実例 China Mobileが発売する3G端末</p>
  • レイアウト iPhone みたい
  • Android Source Code + Linux チューニング して独自にカスタマイズされている
  • Android というよりかは OPhone のイメージ
  • 精華大学関連ベンチャー エンジニア200名
• Android プラットフォームに付け加えている
  • CMTV, CMTV API, TV アプリケーション(Java)
  • OMS API, WAP ブラウザ, eBook, Launcher, Java VM
  • BAE(ウィジェット), MAPS(独自)
  • Webkit(HTMLファイル対応可能になる) # Webkit の最新版を持ってきている
  • Apache 2.0 上のライブラリなので公開されることはない
  • Linux Kernel のフルチューンナップしている # コストがかかる部分 品質にでる
• 必要な機能を足して短期間で製品化することが可能になった

• オープンな部分とクローズドな部分を組み合わせることで個性的なものを作る</p>
  • WordPress + スキン変更(テーマだろうな) + plugin
  • 小さな会社でも大きなことができる

• 何でもできてしまう
• “Droidget” ウィジェットをそのままデスクトップとして使う
• スマートフォンとネットブックに特化したアプリ
• Google App Engine 上にデータを保存して、端末から情報を落としてくる
  • クラウドと連動して成り立つ
• Webkit 上で動くものはすべて動く
• ウィジェットのダウンロードセンターも立ち上げて行く予定
  • Javascript で見せている

• Webkit を使えることの自由、楽に作れる</p>
  • iPhone アプリは上層のコンテンツ部分のみ、Android はプラットフォーム戦略をとることができる
• 小さな会社なので必ずしもオープンソース化がベストはない タイミングもある
• コンテンツに近いものはオープンになりにくいクローズで、ミドルウエアやライブラリはオープン化
• 前提として Android でどうやってビジネスを成り立たせるか考える
  • ミドルウエアでも Java で実装できる

• 感想 : 今まで iPhone アプリのようなちょっとしたアプリのようなイメージまでしかなかったが、もっとレイヤの低い部分までいじれてしまう広い世界なことを初めて知った。
  今後、Android をベースに色々な携帯OSが出てくることは確実かと思う。そうすると Android はプラットフォームを完全掌握ではなくて、サポートするような黒子的立ち位置なのかと思った。
  しかし、結局それを載せるのは携帯メーカになるので、小さな会社がやれることは限られ、そこまでいじるのはメーカもしくはキャリアになる気がしている。そうすると、今まで日本がやってきたキャリア主体の端末作りと同じ構造になって、意外とオリジナル携帯OSは日本にははまるのかもしれないと思った。

A-2 講演A-2 動き出したAndroidによる新ビジネス

14:20-15:00 今村さん

• 期待したモバイルの話はなし
• Google Wave コミュニケーションツール
• リッチモバイル 指を使ったユーザインターフェイス すでに実用されている デモムービーあり
  • # 自分の感覚と同じだな

OESF

• Open Embedded Software Foundation</p>
  • Android を組み込み向けに復旧させる業界団体
  • www.oesf.jp

• 感想 : キーボードを使わない UI とかは自分も今後注目していた部分だったが、内容は結局何を伝えたかったのか分からない。グダグダ感満載で、タイトル負けしていた。

A-3 セカイカメラのつくりかた

15:10-15:50 頓知ドット株式会社 CTO 近藤さん

• カメラを除くと画像やテキストが浮いているように見える
• コンセプト
  • CLICKABLE World
  • WYSIWYG Method
  •  ??
• 撮った写真をサーバにアップしてすぐ反映 はやい、本当？

• 必要なもの : 位置情報、センサー(向き)、カメラ、UI

• 加速度センサー</p>
  • lowpass filter
  • 浮いているタグがカメラが揺れるとゆらゆら動く
  • 急な動きに追従するフィルターを Android に適用している

• PlaceEngine</p>
  • 無線LAN電波を利用して位置、空間を推定する技術
  • GPS が届かない場合に対応

• iPhone オートフォーカスは撮る時に時間がかかってしまう

性能チューニング

• 起動時間、onDraw の時間
• tips は豊富にある Android Developers Blog
  • The Developer’s Guide
  • Google I/O のマテリアル
• ViewStub 起動時間の短縮
  • ビューは後で読み込むようにして1割短縮</p>
    • テキストや写真を読み込む時にその時読み込むので遅くなる
• 背景画像を NULL 指定 早くなった
  • 2.0(Donut)で対応予定らしい

• バッテリーライフについて</p>
  • 書き方とかGPSよりネットワークの方が電源使わないとかのティップスが Google から提供されいてる

• 感想 : カメラで写っているものに対して見せるので、見せ方とか動き方とか今までの web とかと全く異なる観点で作らなくては行けなかったのだなと思った。苦労が多かったと思うが、内容を聞いてこのサービスの新しさをさらに感じた。

B-4 Androidで3Dグラフィクスを極める道 Vol.2

16:00-16:40 高橋さん

• OpenGES GL sunのjavaのリファレンスを未た方がいい
• vol.1 より 高速化のために GPU に処理させる
  • 圧縮テクスチャ 成功、Matrix Palette API未実装、Verex 宿題(説明終わらず)
• 圧縮テクスチャ
  • メモリ使用効率が向上、伸長はハードウエアで行われる
  • Android で ATITC は使える 裏技を使う
    • 定数定義がないので直接値を指定する たまたまHTCで動いた</p>
      • 0x8C92 …ATITC_RGB
      • 0x8C93 …ATITC_RGBA
• Matrix Palette : java だけだと遅い ボーンアニメーション、スキニングをハードウエアで実現できる
• OpenGL がベース
• Google Developer に伝えた

• 感想 : まだ3Dでちゃんと描くにはまだまだ前段階という印象。実行環境から手探りで確立させようとしている状態

今、「クラウド」は確かに旬なキーワードになっているが、その内容はかなり広範囲になってしまっているのでどこをさして使っているのかよく分からない(そもそもどこも指してなくて、イメージで使っている人たちも多い)ので、自分なりにクラウドという単語の中身について整理してみる。

前提としては雲のような巨大なサービスプラットフォームがあって、ユーザはインターネットを返してあらゆる端末からそのサービスを利用することが可能な環境となる。基本的にはその巨大なプラットフォームは、

• 多くのサーバを置くことのできる広大なデータセンタ
• 十分な帯域を持ったネットワーク
• 多数の物理サーバ
• 落ちない/落ちても影響を最小限に抑えられるアーキテクチャ

を持っていることが条件と言える。

クラウドを構成する技術要素としては、仮想OS、クラスタリング、分散並列処理なども入ってくると思うが、これらは規模の大きなインフラを持っているところが今まで培ってきた技術で、Google, Amazon といったところがクラウドをサービス化したのはすごくよく分かる。

大事なのはユーザがどこまでクラウドが提供するサービスに対して制御できるか、がサービスによって結構異なっている。ということ。クラウドサービスの内容をレイヤごとに整理すると、それを使うユーザがどこまで制御することができるのかが分かりやすい。

図に整理してみるとこのような感じ。

OSI参照モデルよりかはシステムを作る時の要素を依存している順に並べて、それをレイヤとした。

クラウドには SaaS, PaaS, HaaS と3つほどサービス提供形態があるが、それぞれ説明してみる。

SaaS

基本的に特定のサービスを利用するだけの形態。いわゆる ASP と同じと思ってよいと思っている。SaaS と ASP は違うと説明しているところもあるが、ユーザから見ればインターネット上でサービスしており、PC依存やネットワーク依存がない環境を提供できていると言う点では変わりはない。
ユーザから見れば使うだけのサービス。

PaaS

開発プラットフォームまで提供されている形態。開発プラットフォームとはある開発言語に特化したサービス提供環境のイメージ。基本的にはユーザがその言語でプログラミングしたソースを PaaS 上に置くことで、インターネット上でサービス提供が可能になる。サーバを買うことなく誰でもインターネット上に web サービスなりを展開することができる。
ただし、ある程度の利用用途を想定して環境が用意されているので、やれることの制約はある。さらに Google App Engine は無料だがストレージ容量、アクリケーション数や PV のリミットがあり、サービス環境的にも制限されている。Force.com は月額課金だが同様に制限がある。
なので、環境としては言語の制約はあれど誰でも自由にサービス提供者になれるのだが、本格的な展開を目指すのであればふさわしくない環境となっている。

HaaS

サーバのOSのレイヤまでユーザが制御することが可能な形態。仮想 OS なのでカーネルをいじることはできないが、root 権限をユーザが持ち専用サーバを持つことが可能になる。しかもいくらでもサーバを立ち上げることが可能。サーバをどのように利用するかはユーザの自由であり、最初からweb-DBのような多層の複数台構成を組んでしまうことも可能だし、クーロンでスクリプトを走らせたりどんなアプリケーションをインストールしてもいい。物理サーバではなく仮想サーバが立ち上がるので、OS 自体の起動は数分で終了する。今までのサーバを買う際の納期やラックスペースや電源の心配がなく、どんどん立ち上げることが可能。
レンタルサーバとは異なるのは敏速なスケーラビリティに対応したサーバの起動環境とストレージや最近ベータ版として提供されたロードバランサーやオートスケーリング機能などの付加的な機能の充実だろう。

レイヤの幅を見るに自由度は HaaS の方があるのだが、結局専用サーバを提供されているのと同じことなので、アプリケーションのインストールから設定などサービスするための構築作業もユーザ自身が行わなくては行けない。また、サーバを運用する責任もユーザ自身になるため、バックアップをどうするか、負荷の検出をどうするか、はユーザが考え、策を投じる必要がある。

そういう意味ではサーバ運用に長けたインフラエンジニアがやはり必要になる。

その点、PaaS はリミットがかかっているがサーバ内の構築や運用を行う必要がないので、インフラ部分の心配はいっさいいらない。

一長一短ではあるが、PaaS と HaaS は巨大なリソースをユーザ自身が利用できて、安くサービスを提供できるという点では、今までとは概念が変わってくるのだと思う。利用用途か自分がどこまで見たいかによって選択するのが現実的なのだろう。ただ、現状では本気でサービスを立ち上げて狙うのであれば必然的に HaaS を選ばざるを得ない状況かと思う。

この新しい概念を理解して利用できるところがこれから新しいネットのプレイヤーとして現れてくるだろうし、既存の環境に埋もれていたエンジニアたちが可能性に満ちた素敵な世界に個人でもチャレンジしていけるようなことにつながっていくのだと思っている。

あるサーバメーカの方に聞いたお話の内容が、結構現状のネットを中心としたビジネスの特徴を明確化している気がしたのでまとめてみる。

そのメーカではインターネットを使ったシステムは internal と external の2つの特徴に分けられて、その2つは全く考え方とアプローチが異なるためにそれぞれに対してマッチするサーバを開発しているということだった。

それぞれの特徴をまとめると、

• internal とは</p>
  • ITを業務で利用する企業内IT、業務ASP的なシステム
  • 利用者はその会社の社員でシステム責任者は情シス担当者
  • SIer にお金を払って作らせるケースが多い
  • 信頼性やセキュリティの意識が強くそのためのコストはいたし方ないという考え方
• external とは
  • みずからサービスなりを提供している形態、サービスプロバイダやインターネットサービス運営会社
  • 利用者は不特定多数のコンシューマで会社としてサービス提供している
  • 自分たちで開発、自分たちで作っちゃうスタンス
  • なるべくベンダ異存のないプラットフォームを好む
  • なるべくお金はかけたくないしそもそも最初はお金持ってない

というお話で、external 側の消費電源やスペースへの要求レベルが高く、今までちゃんと提供できていなかったので、そこをターゲットとしたサーバを作ってますとのことだった。

自分としては internal は社内で使うシステムのサーバを IDC に置いて、firewall をきつめに設定して社内からのみアクセスできるネットワークを作って業務中はアクセスあるけど、お休みの日は使われないような運用をイメージした。一方、external ははてな、Yahoo!やGoogleなどいわゆるコンシューマを相手に24時間ネットサービスを提供し続けているところとイメージした。

自分の中では何気なく分けていたのだけどそれを明確化していて、しかもすでに戦略を打っているところはさすがメーカ、手堅いな。と思ったところだった。

その後、自分なりに反芻してみるとこの分け方はシステムの特徴だけにとどまらず、作ることに対する文化そのものも異なることに気づいた。結構肝なのがこの2つは同じ IT というジャンルにまとめられてしまって、働いている人たちも混同していて「ITやってます」とか言ってしまっていて、分ける意識がなく過ごしてしまっていることがあるかと思う。

この internal/external は大事にしたいポイントなど考え方や文化からして全く異なる別ものだと思った方がいい。仕事の回し方や考え方とビジネスのスタンスの面から自分なりにまとめてみると、

• internal</p>
  • 信頼性、確実性を重視
  • 工数主義 : 数の論理で問題解決する
  • スピード遅い
  • スキルよりも調整能力が必要
  • しっかりした雇用形態と緩やかな給料上昇率
• external
  • スピード重視
  • パフォーマンス主義 : いいパフォーマンスする人はすごいと思われる
  • スキルがない人はいりません
  • 小さくたって世界を変えられるぜと思える
  • いつ辞めるか/辞めさせられるか分かりません

これくらい違うと思う。法人営業のSEをしていた時に internal 側にいて、サービスを立ち上げた時に external 側にいて両方を見てきた自分にとっては internal をやっている人と external をやっている人とは根本的な考え方が違うので一緒に仕事をするのは難しいというか、そもそもスタンスが違うのでそのギャップから問題が出るケースがほとんどだと思っている。振り返ってみるとベンチャーのスピードを大手のメーカや法人顧客を多く抱えるIDCに求めても実際ついて来れなかったし、その会社のシステム上そもそも無理だったりしている。

で、自分はどちらでプレイしているのか分かっているのも結構大事で、internal な世界の中で external やってみようと言うのはそれは難しく、自宅に帰ってから個人レベルでやるか、本当に仕事としてやりたいなら external をやっているところに転職してしまうのがいいのだろう。自分のやっている仕事が実際どちらなのか分かっていれば自分のキャリアを描きやすくなるだろうし、転職するにしてもその会社がどちらかを見極められれば無駄な面接は減るだろう。

同じように会社を作るなりして自分でビジネスを展開する時にどちら側に立つかというのも結構大事で、どちらもやるというのはやはり難しいことだと思う。

そういう意味では、ShakeSoul は external で生きていく会社にしたくて、そのフィールドにどっぷり浸かるために作った訳で、最初は internal で直近の売り上げを短期的に、、、なんて考えていたことが矛盾していることに気づかされた。具体的にどういう理想を描いて追求していくかは別エントリーにまとめたいと思うが、これからも external な世界で生きていくための模索とチャレンジを続けていこうとやっぱり思うのだった。

おそらく7年前から毎年、INTEROP に行っている。やはりネットワークに関する最大級の見本市だし、web 全盛の前時代はネットワークがコアテクノロジだった訳で行くのは必須くらいなものだった。

しかし、最近は web 開発の時代になってネットワークはあって当たり前なものにますます位置づけられて、新しい技術も生まれることなく高速化だけがホットトピックスになる状況だった。衰退ぶりが実感できたのは展示ホールの広さで、ここ最近は年々縮小していて、7年前は1～8ホールまですべて埋まっていたのに、3年前では6ホール分に減っていた。

今年はどうなのだろう？レイヤの上の方に幅を広げてきた自分にとっては、最近のネットワークだけの状況はあまり分からないながらも、このイベントの変化が現状を知る良い機会だと思って行ってみた。

なんと、今年は展示ホールは3ホール分。IMC や RSA など付属的な展示物を含めて3ホール分しか展示されていない。あー、ついにここまで来たのだなと現実を実感する。

確実にネットワークの産業は成熟化したと言っていい。新しいイノベーションは非常に起きにくくなっているし、高速化へ邁進するプレイヤーは体力のある一部のルータメーカにしぼられた。レイヤ1～4の幅の中での新しいことはほとんどなくなっている。

なぜかというと、

• 高速化してもその帯域を必要としているところはごく一部であり、おおむね 1Gbps の物理帯域があれば十分なところがほとんど
• 標準化によって異メーカ間接続が可能になり、つなぐことに関しては安定性、信頼性が高い環境が提供しやすい
• ネットワーク機器を使う人たちのノウハウが時間とともにたまり、新しい技術や機器を習得しなくてもすんでしまう環境がある
• ネットワークのレイヤで制御できることは非常に少なく、ソフトウエア側のアプローチでレイヤの高い部分も網羅した制御プロトコルやミドルウエアが多く開発されている

という状況があるからかと思っている。

展示をいくつか見て気づいたことメモ

• Cisco が展示を出していなかった</p>
  • みんなが知っている存在になっているし、もうネットワーク業界にブランドを提示する必要はないからか
  • サーバに進出していることよりネットワークはもうOKと判断しているのかも
• 人だかりが割とできていたところ
  • Palo Alto Networks : L4レベルどまりでなく、アプリケーションの振る舞いを可視化して制御する Firewall 製品を提供している
  • TippingPoint : 不正侵入や攻撃、ハッキングを防御する製品を提供している
  • ネットワークレイヤを超えてくるものまたは単純なセキュリティ機能からトレンドを追うような動的な制御を行う製品が注目されている
• Juniper の 100G FPC の展示を興味深く見る人がほとんどいなかった
  • 高速化の興味を持つ人が少なくなったのか
  • そもそも Juniper の FPC を使うような大きめなルータを使う人が少なく気づかなかったのか

クラウドコンペを見て

今年の INTEROP に行く目的のもう一つはクラウドコンペの発表内容を聞くためだった。クラウドについてすでに取り組んでいる人たちがどんなことを実際行っているのか、どんなアイデアを持っているのか非常に興味を持って聞きに行った。

実際は全10ある中の2つのプレゼンテーションしか聞くことができなかったが、その2つはクラウドというよりかはクラウドに無理矢理こぎつけて、独自のネットワークの距離を測ったり、MapReduce のようなすでにあるものを使ってちゃんと動きました的な内容を発表していた。おそらくこのコンペに合わせてというよりかは今まで研究、検証してきた内容を発表する機会として発表者は利用したのかと思う。

発表内容のレポートはすべてではないが IT Pro の記事 にまとまっている。

そいういう意味では優勝チームの発表は是非聞いてみたかったが、内容を見るに自分たちでクラウドを作るためのアーキテクチャを確立し、開発したという点で真正面からクラウドに取り組んだ結果だけに優勝は当然かと思った。

期待して聞きにいってみたが、クラウドに対して真っ正面から取り組んでいるプレイヤーはほとんどいなかったし、まだ少ない状況だということがよく分かった。

そういう意味では ShakeSoul で Amazon EC2 フルサポートパック を展開していることは市場の中で結構なイニシアティブを持っていると思っている。

来年の INTEROP はどうなっていくのだろう？US の INTEROP は成り立っているのかどうか？

ネットワークレイヤしか、知らない/やってこなかったエンジニアはどうなっていくのだろう？

この大きな流れはもう戻ることはないと思いつつ、何とも言えないむなしさを抱えて予定よりも早く見終わってしまった幕張を後にした。

メーリングリストの仮想化友の会は入っていたのですが、勉強会には行ったことがなかったのとネタが KVM らしいので聞いてみたい＆どんなもんか見てみたいということで、初参加してみた。

2008年のOSCの仮想化系のセッションを聞いた時に会場にいらっしゃった方々が多くみられていた。内容は Red Hat の方々による KVM の技術概要と Red Hat としての取り組み予定紹介。

資料は仮想化友の会webより入手できます : http://sites.google.com/site/kasotomo/study

参加者は Unix/Linux をいじってきましたと言う世代の方々と思われるので、web 開発系なコミュニティに比べれば平均年齢は+5したくらいか。2002年くらいにいた IRI のエンジニアたちが FreeBSD をいじり倒していた時代に軽くフラッシュバックする。

思ったのは、仮想化といっても完全ソフトウエアの話にはならず、必ずハードウエアとの絡みも出てくるので、ハードも含めて検証なりを進める敷居は高く、お手軽さはないので自然とちゃんとできるプレイヤーも少なくなる分野なのかと思う。

特に KVM は CPU でフォローする仕組みなので、ハードウエア依存が強い。ハートウエアに依存しないサーバ環境を作るための仮想化なのだけど、やはり大事なところでハードウエアがしっかり絡んできてしまうのはなんともしょうがないことなのだろうか。

何にせよ、仮想化は1つの手法であって目的ではないのだけどツールの一つとして利用する場合、仮想化するメリットやパフォーマンスを分かっておくことは大事なことなのだろう。

ということで、そろそろ仮想化環境についてもう少し詳細な技術情報なりノウハウなりを貯めたいと軽く思った次第。

以下、当日メモ

20090528

仮想化友の会 5月勉強会

19:00-20:40

KVM 技術解説

Red Hat 森若

• QEMU : Windows/Mac/Linux 対応 便利だった</p>
  • dynamic なので遅い
  • 色々使えた ia64 使えた
• KVM : QEMU を工夫して早くしてみた
  • ゲスト OS が I/O したい場合は仮想 I/O に対して、一度 QEMU に渡して
  • KVM-Linux 経由で実際の I/O する
• 新しいモード Guest mode
  • センシティブ命令は実行できない
• virtio
• 共有メモリがあるから早くなる
• シャドウページテーブル
  • ゲストの仮想アドレス=>ホストの物理アドレスのテーブル
  • MMU の仮想化の問題を助ける
    • ゲストの物理アドレス=>ホストの物理アドレスの変換がない
  • EPT の CPU だとすごく早かった
• viroio について
  • virtio_ring のスライドの絵がすべて
• virtio_pci
  • 仮想 PCI バス上に仮想デバイスが並んでいる
  • I/O命令は仮想環境がフックする
  • virtio_ring での virtqueue を作成して共有する処理もここで行う
• virtio_balloon
  • 共有するバッファは virtio_baloon 構造体1つだけ
  • 仮想化側がいろいろやってくれるだろう前提とした仕組み
• block/virtio_blk
  • 仮想ブロックデバイスを提供
  • リクエスト用の1つの virtqueue を使う
  • read, write, SCSI cmd を発行できる
  • リクエスト完了 used リングに追加のみ
• net/virtio_net
  • 仮想ネットワークでバイスを提供
  • 送信、受信、コマンド送信用の3つの virtqueue を使用
  • 送信処理終了後に送信できなかったデータの送信、送信済みのskbの回収
  • block より工夫されている
• char/virtio_console
  • 仮想コンソールでバイスを提供
  • 送信用、受信用の2つの virtqueue を利用
  • 一度のやり取りは PAGE_SIZE まで

Red Hat の仮想化戦略

Red Hat マーケティング 中井

• Red Hat と MS 仮想化の相互運用制で合意</p>
  • 合意内容</p>
    • Red Hat 仮想化上で Windows 2000/2003/2008 サポート
    • Windows Hyper-V 上で Red Hat Enterprise Linux5.2/5.3 が動きます
• KVM について
  • Qumranet イスラエルの会社を Red Hat が買収
  • SolidCE/SPICE も買収した 管理テクノロジ次世代仮想化
• 今後
  • KVM は OS に統合、Xen は継続サポート
  • GUI ベースの管理ソフトを出す VMware Virtual Center みたいなもの
    • .Net でできている Windows で動くよ
    • ライブマイグレーション機能もあり
    • HA機能、イメージ管理の機能
  • Desktop の仮想化も提供
  • Hypervisor : VMware ESX みたいなもの
• Qumranet はもともとクライアントデスクトップの仮想化用のソフトだった
  • Solid ICE VDI サービス名
  • 仮想化のエンジンは Linux, 管理のソフトとデスクトップの表示は Windows
  • デスクトップの表示は IE で ActiveX 利用
  • 早いのは独自のプロトコルを持っている SPICE? windows remote desktopより早い
• Hypervisor
  • KVM : みる角度によって Linux と Hypervisor
  • ホスト 96コア、1TBメモリ # Linux そのもののスペックが適用される
• 今後 3ヶ月から18ヶ月にわたって製品提供予定
• 価格まだ秘密 でも VMware よりかは安くなるかも

QA

• KVM は API 公開するの？</p>
  • VDSM 最初はクローズド、リブバートに持っていく構想あり
  • 今はリブバートに対応していない

5/18に Amazon AWS から発表になった Amazon EC2 の新機能は Auto Scaling や Load Blanacing など、今までユーザ側でなんとかしていた or 提供事業者が飯の種にしていた部分に Amazon がカバーしてしまった。と言う点で結構注目が集まっていた。

細かな点はさておき、ひとまず触ってみないことにはどこまでカバーされているかも分からないので触ってみた。以下、触ってみたときのメモ。

事前情報

設定の仕方やコマンドはそれぞれのページを参考にした。

• Amazon CloudWatch
• Auto Scaling
• Elastic Load Balancing

3機能概要

• CloudWatch は instance と Elastic Load Balancer 両方のモニタリングが行える</p>
  • それぞれ取得できるパラメータは異なる
• Auto Scaling が動作するためには、CloudWatch が instance 上で有効になっていることが条件
• Elastic Load Balancing は起動している instance を指定して分散対象に加えることができる
• beta版ということで、すべてコマンドラインでの操作方法しか提供されていない
  • Elasticfox 上だと今回の機能に対する情報は見えない

動作環境

• すでに EC2 コマンドが実施できる環境があることを前提
• mac 上でオペレーションしています

事前準備

• Amazon AWS web へログイン
• Amazon EC2 API Tools をダウンロードして、ローカルにて解凍
• EC2 コマンドへの PATH が通っている既存ディレクトリと置き換える
  • 今回の3機能追加にともなうもろもろのコマンドが増えている

CloudWatch を触る

事前準備

README.TXT をみつつ

• Amazon CloudWatch API Tools をダウンロードローカルに配置
• .bash_profile に PATH を追加
• credential-file-path.template をコピーして好きな名前に変える
  • 今回は credential-file とした
• このファイルに必要な情報を書く
  • key.id と secret key の情報は AWS web の my page よりコピペする
• .bash_profile に追記した中身

技術的にコアで刺激になるような勉強会はないかなと思っていていたら、BP Study をすすめられた。前から BP Study の存在は知っていて気にはなっていたけど、機会がなくて行ったことがなかった。

今回時間もあったこともあって初参加。

内容は OpenID Authentication 2.0 protocol の解説と XMPP and AMQP の紹介

資料の紹介は BP Study の web にリンクされています : http://beproud.jp/bpstudy/?p=31

どちらも技術的にはニッチかつコアな内容で専門ではないので概略くらいしか理解できなかったが、それだけコアなものに触れられてよかった。細かくはなんだか分からないけど技術的に先端的だったりニッチだけどすごいことが世の中にはあるんだなぁ思うこと、それを感じるのが結構大事なのかと思う。

個人的には後半の AMQP みたいな大量な処理をひたすら効率的にさばくための仕組みは結構興味深かった。Google 内部でもこんなようなひたすら高速に処理するためのシステムが作られて web で紹介されているのはごく一部なんだろう。

全体的な雰囲気としては懐かしの IRI でやっていたエンジニア勉強会に近い感じを受けた。そこそこで技術的コアな情報を知っているエンジニアが集まることでエンジニア集団全体としての幅と厚さが出る。この技術の幅と厚さが価値になる。そう考えると BP Study は結構な幅と厚さのある勉強会になっているので価値は高いな。

# この技術に対する価値の見いだし方がちゃんと理解できている人はなかなか少ない。シリコンバレーではベースとなる考え方になっている

懇親会でも色々な方と面識を作れたのもよかった。ShakeSoul として何か一緒にやれることを見いだせればラッキーだろう。

継続的に参加したい勉強会になりそうだ。

以下、当日とったメモ

090521 BPstudy #21

19:00-21:30

Introduction OpenID Authenticasion 2.0 Revival

• OpenID tech night やった もうちょっと分かりやすくした初心者向け
• OpenID Authentication 2.0 protocol がある
• ケーススタディ smart.fm
  • smart.fm のアカウントあり
  • openIDとの関連付け済み
  • OpenID アカウント入れると myopenid.com のサイトにユーザ側でのリダイレクトされた
    • これは smart.fm のサーバがクライアントにリクエストしている
• 用語
  • Claimed Identifier クライアント側の所属情報
  • Relying party 使おうとしているサービス smart.fm
  • User-Suppolied Identifier
    • Claimed Identifier と OP Identifier をひとくくりにしたもの
• コマンド myopenid にアクセスする時 Yadis Discovery
  • lwp-request -S -e- d http://zigorou.myopenid.com/ | grep -i xrds
  • X-XRDS-Location: http;//zigorou.myopenid.com/?xrds=1
  • http;//zigorou.myopenid.com/?xrds=1
  • # 色々出てくる
  • XRDS 文章を見つけるやりとり

自分メモ

• 大まかに言えば</p>
  • smart.fm がクライアントにリダイレクト要求
  • クライアントが openid.com にリダイレクト
  • 認証をする
  • openid.com よりクライアントへリダイレクト要求
  • クライアントが最初の smart.fm にリダイレクトする
• という感じの流れのようだ

QA

• Q1 A1 OpenID ライブラリが出ているようだ</p>
  • セキュリティホールがあるようだ バージョン上げる必要があるとのこと
• Q2 return-to-url が書き換えられる場合は
  • どの OP も安全という訳ではない verification でチェックされて促すくらいのやり方
• Q3 いろいろな OP があって開発めんどい
  • めんどいので Google は画一的な画面を出して共通化する動きもある

XMPP and AMQP

• 両方を知っている人少ないのでは、、、
• XMPP
  • XML 実装
  • Google Talk のプロトコル
  • 非同期な通信
• AMQP
• Erlang
  • 並列処理指向言語、分散処理指向言語、Open Telecom Platform(OTP)
  • facebook Online chat, AWS SimpleDB, Apache CouchDB, 分散ハッシュDB Kai / scalaris で使っている
  • はてなダイヤリ higepon/20090509/1241863278
  • 井上 武 たけまるさんの資料公開されている プログラミング言語 Erlang の動向

XMPP

• RFC にもなっている
• XMLベースのプロトコル
• 動きはメールサーバと一緒
• TCPコネクション張りっぱなし
• XMPP Server 接続、友人、状態を管理
  • クライアント間は直接メッセージ通信する
• 基本的には NAT を通らない
  • Google は UDP Hole panching をするライブラリを適用している
  • プッシュ型のメッセージ交換 張りっぱなし

XMPP サーバの動き

• ログイン、IDとIP情報を伝える
• 相互認証になる ブロックしたい相手には情報を送らない

セキュリティ

• SSL/TLSm DNSの逆引きチェック、SASL。。(シンプルな認証のようだ）
• 複数チャットも可能

ejabberd

• Erlang による XMPP 実装
• Group Chat も実装済み、部屋が作れる
• 大量のコネクションが来ても大丈夫

Ejabberd Cloud Editon

• AWS の SDB と S3 においてしまう
• スケールすることを

AWS import/Export

• HDD を Amazon へ送る
• S3 にインポート
• 1TB HDD 1TB転送して 1万円くらい
• バックアップ HDD を送ってもらう

AMQP

• Advanced Message Queue Protocol
• 今年中に 1.0 が公開されるはず
• メッセージ指向ミドルウエア
• アプリケーション間の通信プロトコル
• 5億くらいのメーッセージをさばく
• 非同期なのにトランザクション
• TCP であることを利用
• マルチキャスト
• ルーティングキーが一致するところに送る
• 大規模向けすごい負荷がかかるところを抜けるためのソリューション

RabbitMQ

• Erlang による AMQP 実装
• 130万/sec リクエスト可能
• 3億メッセージ/日
• AMQP 0.8 まで実装済み
• ニュース配信、ラジオとか 情報がとにかく出すところが使っている

Kay

• Google App Engine Python 専用フレームワーク作ってます

AMQP サイトがある

• 送る側とクライアントの作り込で設けているようだ
• 送る部分はオープンソースにしている

etc

• アーラン
• Tokyo キャビネット

etc : Google libjingle

• Google Code より
• techtalk もある コアエンジニアが話しているらしい
• xmpp.org にも libjingle
• 95%は Google 社外に出てないらしい