今日2012/04/06は桜を見に行きたいのをじっとこらえてアマゾン リーンクラウド レボリューションセミナーを受講してきました。会場内、うるさいし周りへの配慮のない人が多くてとても居られず前半のセミナー部分で失礼させて頂きました。
はじめの一時間はamazonのCTO ヴァーナー・ボーガス博士の講演。日本人がやると単調で聴き続けるのに忍耐を求められるamazonのAWS中心にしたサービスの説明がとても素直に聞くことができる。こういう部分はぜひとも日本法人の方にも見習っていただきたいところ。小一時間、なにも見ずに説明するヴァーナー・ボーガス博士の話し方は抑揚とリズム感があって聞き取りやすくてなによりあきさせない。同じ事を日本法人の方がやると申し訳ないけど聴き続けるのに忍耐を要求される。
そして忍耐が必要かどうかは別にして分かりやすさ、伝わり安さが違う。Q&Aセクションがなくて残念だったけどNoSQLが素晴らしいんだという話はどうなんだろう。話の進み方からするとメモリーベースではなくディスクベースのもののよう（SSDを使うといった説明でSSDの良さを強調しているように感じられた）。AWS系はCPUやメモリーで課金され、利用帯域で大きく課金されるのでNoSQL系を使う気になれないのだけれど、それをすすめるお話が結構印象的だった。
BigLobeさんのブロガーイベントに参加させてもらって、無料アカウントを5月末までいただいたけど、使いようがないスペックでどうしたものか困っているけど、それぞれ強みとするものがまるで違うのが面白い。
Biglobeは出自にそっていてサーバー環境の素の部分を強調していた。VMwareで作られた仮想環境を自由にできる、他社にないLAN側の独立性（他の利用者との物理的な独立性の確保）などを強調。、帯域課金をしない事で予算化しやすいという日本の企業文化に馴染みやすい構成を売りにしている。
対してAWS中心にアマゾンはそういう仮想部分はあまり相手にしていない。強調するのはhadoopsなどの環境であり、それ以上にNoSQLなど提供される上位レイヤーの魅力。日本メーカーが物理層で競うのとは好対照で聞いていてい実に面白かった。
どちらがいいというのではなくて、どちらも重要ではっきりいってしまえば両者とも半分しかまかなえていないというのが利用者の素直な実感。下位層も上位層も両方大事で分離して論じても意味がない。どんなにハドープスなど使おうとLAN部分が構築できないシロモノなど使い道がないし、かといってそんなVMの構成ばかり言われてもDNSひとつ提供できないレベルではシステムとはとても言えない。どっちもどっちで中途半端。それぞれ利用者から発したものとメーカーから発したものである出自がよく現れていて面白いけれどいいかげんにして欲しい。
AWSの話を聞いていて毎回馬鹿かと思うのがサーバーを自前で持つのとAWSという環境を使う違いの説明。自前で持つなら高性能なマシンを買ってスケーラビリティー勝負ができる。ところがAWSはそういう商品を提供せず分散処理を利用者に押し付ける。それでいてそのために移行ツールなど一切ない。はじめからAWS前提の会社はいいだろうが自前でサーバーもって運用している会社はおいそれと移行できない。なぜなら1サーバーあたりの処理性能が限定されすぎていて分散処理に最適化した構成にシステム全体を再構築しなくてはならずスタートアップ企業にはあまりに高すぎるハードル。それを超えさせるための仕組みが一切無くて売れるという発想はよくわからない。実際に使えている会社は相当の技術力を持っているか、はじめからAWSありきではじめた会社ばかりに見える。
たとえばwebサーバーの分散はロードバランサーを使えばそれで済むけれどロジック部分とDB部分はそういうわけに行かない。IBMのメインフレームのように呆れるほど強大なパワーを持っていれば問題ないけれど、提供されるのは所詮webサーバーレベルの環境で大量のアクセスを処理するときに必要となるDB周りの強化が見えない（NoSQLがひとつの回答かもしれない。しかしSQLベースのアプリ、それ以前にシステム設計をNoSQLに変更などおいそれとできないし、そもそもNoSQLはSQLを理解出来ないweb製作者用の仕組みでしかない。本質的に用途が違う）AWSに強大なメインフレームのようなRDBMSが乗っていればいいけれどそうでないと多くの企業では使いものにならない。webサーバーは台数でこなしてもいいけれどロジックレイヤーとDBはそういう訳にはいかない。AWSの最もダメな部分がDBで十二分な処理性能を提供し続けられるSQLベースのDBを提供しない内八洋できる企業やサービスはかなり限定的なものになってしまう。
とはいえ、HadoopsはじめNoSQLなどここ数年で発展している技術が惜しみなく提供されている魅力は大きい。先端技術にフォーカスできる企業なら自前でサーバー構築する資金面の困難と仕入れと構築の時間をなしにできるクラウトという方法論はとてつもなく魅力的。
amazonのCTO ヴァーナー・ボーガス博士吠えてます
さすがCTOで徹底して強みを強調されていました。
冷静に考えて先端儀受注を取り入れようと自前でHadoops構築などとてもおすすめできない。ハードウェアの構成からOSの設定。障害時の対応・復旧など等地縄で行かない事ばかりでそれを自前でやるメリットがなになのか、金銭的に明確にする必要がある。というより属人的すぎて自前でやるのは危険が多すぎる。
この表現にこそアマゾンのウィ0区ポイントが明確に出ている。所詮webレベルの発想でバックヤード、つまりDB部分を十二分に考えていない。今日も強調されたNoSQLもwebデザイナー等がSQLを苦手とするため簡易な処理についてSQLを使わずもっと平易な（機能の限定された）言語で処理できるようにしたものでしか無くてビジネスロジック部分を置き換えられるものではありえない。NoSQLでOracleは置き換わらずまったく別次元のもっと海藻の処理用途でしか無い。
このようなロジカルな構造は日本のサービスプロバイダーにも見習って欲しい。
この辺は流石としか言い用が無いですね。
ただ利用車が自前で設計して自前で契約から件トプしなければならないのはどうかと思う。そういう設計ができる上流工程の技術者がいれば非常に有益に使えるけれど、殆どの企業にはそういう人材は居ないわけでこの構成を活用できるはずがない。意識すること無く自動的にこれらを動的に使い分けられるようにならないと本物ではないだろう。
つまり、自分のVMがどこで動いているかなんて意識しなくてはいけないのはおかしいトピう話。正常時は東京で稼動していてい、東京のデーターセンターが落ちたら自動的にシンガポールとか台湾とか朝鮮半島のデータセンターにVMotionするべきであって、事前に契約者がそれらを考えて設計して割り振ることを前提にするなんてどう考えてもありえない手抜き。
一見正しいけれど徹底的に間違っているのがここ。
利用車には全情報が公開されているわけではないからリスクを適切に判断できない。利用車ができるのは正常時にはこうあって欲しいという構成までであって、異常時の設定は詳細情報が提供されない利用車にできようはずもない。利用車に責任転嫁しないで提供者が責任を一意に受けるべき部分をごまかすのはアンフェアーにすぎる。
今日のセミナーはあまり気体できなかったので小さいボトルで花粉症対応のためのコク抽出したウーロン茶を持って行きました。
この成長曲線は実に羨ましい。
amazonでは2000年に同社が必要としていたサーバーの能力と同程度のシステムを毎日増強しているそうです。てか、webサーバー部分の数値なんて意味がなくてDB部分の処理性能が全てなんですよ、許田御システムって。そこをごまかすのはやめて欲しい
AWS利用している有名サービスの一部。
ところでおなじAWS使ってもEvernoteやはｔWorkは恐ろしくレスポンスが悪い。反面DropBoxはまあまあいい状態を維持している。こういうさが出てしまうのがAWS全体の大きな欠点で利用者に特殊な技能を要求しすぎている。EvwernoteやChatWorksだけみているとAWS系は使いものにならない様に判断するしか無いが、DropBoxを見ると同業他社には負けるものの、そこそこのレスポンスは維持していて市場競争力を維持できそうな気体が持ててくる。
日本のスタートアップも多くがアマゾンを利用、というのは重要ですね。アマゾンが提供するサービスは極めて歪で特殊な技術力がないと会社を倒産させてしまう原因になるほど限定的なサービスですが、その技術を理解した上ではじめるとすろつなかなか魅力的なサービスです。
講演の中でも固定資産税がいらないということを言っていましたが、たかしにこの部分だけでも大きく違います。創業はじめから売上もないのに税金を取られるのか、経費として計上できて赤字で税理処理できるかではまったく違ってきます。提供されるサービスはかなり偏っていますが、それを使いこなす技術力を持つことは競争上の優位性にもなるし、将来そのノウハウ自体を他社に売れる可能性も秘めています。
クラウド利用のメリット
コスト削減の中で固定資産税は見落としがち。
また、サービスがあたった時の機会損失はとてつもなく大きいです。前職もそれで依存されてしまいましたが、自前で解決不能になりお金を積んでも助けてもらえる相手を見つけられない最悪の状態に陥ります。AWS前提でシステム構築していれば制約もわかった上での設計となり協力なDBなしでどのように大量の要求に答えるかをはじめからシステムに組み込むことになりますので実用性がかなり高まります。（スケーラビリティーをどう実現するかという究極の問題です）
Time is money!
時は金なりで、より早く市場に出したものだけが生き残れる。
ところで写真の下に注目してください。ヴァーナー・ボーガス博士が右下を右方向に移動中。このように、自分の位置を変えつつセミナー乗降車が均等に自分を見られるようにする。意識が散漫にならないよう集中させる努力をし続ける。日本の講演者もせめてこういう部分は見習ってほしいものです。
とにかく話す人をX軸でプロットしてみると違いは一目瞭然。日本人はほぼ移動量ゼロ。誤差のうちです。対して欧米人、とくにアメリカ人はX軸で見ると左右の端点から端点までじつに小気味良く全部使い切っています。何気なく話しながら右へ左へと移動していく。こんな簡単なことさえ日本人のプレゼンターでできている人はまずいません。
「ムダを削減」とは「顧客に直接価値をもたらさないものは、全て「ムダ」なもの」強烈なメッセージですね。いつか自分でも使ってみたいフレーズです。
見慣れたAWSのメリット。でもたしかに自前でサーバーを揃えればこうなります、どころか、黒字倒産の大いなる現況です。必要になった時と発注時点外れるし実際の支払時点はさらにずれる。成長続くときはそれでも、どうせ税金用の会計処理など会社運営上意味のない数字ですからいいのですが、破綻するときはサービスが伸び続けるように見えて投資する。しかし伸びなくなった時、一気に支払だけがきて売上がついてこずあっけないほど簡単に終演を迎えます。AWSのにように使った分だけ支払うならその危険性はかなり減ります。
Lean startup リーンスタートアップのための重要なツール
身振りが大きいので手がぶれてしまってまともに写りません。
早口ですが、アメリカのプレゼンターは概してこれくらいでも、英語ネイティブでない外人向けにかなりゆっくり話している方。
リーンスタートアップのためにはこんなにも多くの基礎要素が必要。
写真で見るとゆったりしているように見えますが実際は方がぶつかり合うような狭い配列。少しでも多くの人に効かせてあげようという気持ちもわかりますがかなり不愉快でした。聞いていられないほど窮屈な配列にするのはどうなんでしょう。
ステマ的な口コミは起きても本来の口コミは得られないのではないでしょうか。
ゆったり見えるのは最前列の4列ほどでテーブルもあってゆったりしているため。そこから後ろはぎゅう詰めで13時から18時まで皆さん耐えるのは素晴らしい。さすが、日本人だと思います。わたくしは申し訳ないですがあんな環境で5時間以上も耐える精神構造は持ちあわせていません。タマタマ両サイドがひどかったということもありますが、セミナー受講する環境では無いです。
Hadoopがついに実用の政界に入ったんですね、予想より早かった。
ただ「ビッグデーター処理・・・」は言い過ぎかと。そんな単純なものではないです、データー分析。
わかりますけど、所詮NoSQLは限定的用途のものでこんなに大々的に言うようなものではなく、ただしくSQLデーターベースを動作させてほしいものです。
DYNAMODBを熱心に売り込んでいらしたのですがそのバックボーンに狂人で拘束なRDBMSがなくては絵に描いた餅ではないでしょうか。
2msecといった数値が出ていましたがさすがに速いですね。でもSQLが使えないので利用し＾ーンはとても限定的です。まさに今それで悩んでいるので、ここまで凄そうに売り込むのはどうかと。
NoSQLはメモリーベースでこそ進化を発揮しますが、AWSのような携帯ではメモリー容量はとても限定的。そこでSSDが登場するのでしょうがメインメモリーと比較するべきでHDDと比較するのはどうなんでしょう。
パフォーマンスを犠牲にして、ディスクに書きこむというのはひとつの重大な決断。これは悪い判断だとは思いませんが、利用者に選択肢を残すべきだとは考えます。永続性がなくても良いデーターは案外多いもので、高速性が保証できるメモリーベースのオプションは必須かと。
NoSQLで複雑なクエリーや複雑なJoinに対応するのが正しいアプローチなのかは将来に委ねます。
amazon CloudはAWSを超えていると・・・
