skip to main |
skip to sidebar
Scale Outがクラウドの本質ではない！？
ちょっと古いが、2008年10月に、クラウドの本質と動向という記事のなかで、１．スケールすること、２．安く利用できることがクラウドの本質であると書いた。大量のコモディティサーバを用意して分散KVSを配置することでスケーラビリティとアベイラビリティを確保することが基本で、プライベートクラウドは、この考えを企業内に応用したものである。
これに対するアンチテーゼとして最近よく耳にすることは、サーバ単体の能力は十分に大きく、その能力を超えて処理しなければならないような大規模なケースはあまりないのではないかということ。真偽はわからないが、ムーアの法則が十分に成り立っており、CPU処理能力向上は将来においても続く見通しであることも背景にある。
約5,000万PV/月くらいのサイトまでなら、アプリケーションサーバ１台で捌ける（ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない）
一般に、クラウドといえばCAP定理などに象徴される、超大規模な分散ストレージについての話になりがちだが、そんな最先端の基礎理論が必要になるのはトップ1%のなかの1%ぐらいのサービスで、世の中のほぼすべてのサービス開発者にとって、むしろクラウドの恩恵というのは以上のように一見地味な進化の中にこそあるのである
スケールアウトからスケールアップへの回帰
また、クラウド・プラットフォームの不特定大量のプロセッサー資源をエラスティック(柔軟）にプロビジョニング（配置）して効率よく資源活用することが最大の効果であり、全体の最適化によりコスト削減を実現する仕組みの方が重要との意見もある。
scalabilityやスループットの高さよりも、すべてのアプリをpartition-tolerantに書くよう強制して巨大インフラに細粒度で集約し、桁違いの全体最適を実現できることが重要と思う。でないと大規模サービス以外はあまり必要ない＞NoSQLとかKVS（App EngineやNoSQLはスケーラブルだからエラいのではない）
プライベートクラウドでも、リアルタイムに、必要なITリソースを調達できるメリットが強調されている。
海外で、ある金融機関に監査が入り、顧客の口座データや資金の動きをバッチ処理し、異常がないかを調べることになったという。期限は3日後。数十台のサーバが必要だが、今からIT部門にリソースを要求しても、とても間に合いそうにない。
そこで、この金融機関の担当部門はAmazon EC2を使ってバッチ処理を行った。それを知ったCIOは激怒した。重要な口座データをインターネット経由のパブリッククラウドで処理するなど、とんでもないと。ところが、担当部門の責任者は、「リソースをすぐ使えるよう準備していないIT部門の方が怠慢」と逆切れ。これを教訓に、この金融機関はプライベートクラウドを導入したそうである。メリットを共有する「業界クラウド」の可能性--IBMに聞くプライベートクラウドの価値
しかし、全体の最適化もそうだが、システムの規模が大きくなることで運用コストも増大する。特に、プライベートクラウドの経済性についての疑問は大きいようである。
プライベートクラウドは、正しい方向への第一歩のように感じるかもしれないが、しかし規模の経済としては、プライベートクラウドは本当のクラウドコンピューティングの効率性に遠く及ばない。何が違うか？ 規模、共有されたリソースファブリック、高いリソースの利用率でこそよいサービスが低コストで提供できるのだ。
つまりHamilton氏はプライベートクラウドはパブリッククラウドと比べて効率性もサービスレベルも悪く、しかしコストは高い、といった点を突いているわけです。
プライベートクラウドに未来はないのか？
プライベートクラウドの価値
ところが、まったく逆の発想もある。
私たちのJEANSは、アプリケーションと基盤を疎結合化し、サーバー・クラウドなどの最新技術でアプライアンス・フレームワークを構築する企業システム革新への提案です。日本のお客様のIT変革を阻む大きな要因として、IT環境における強い安定志向と、それを達成するための案件個別のきめこまかな非機能要件（NFR）の作りこみが考えられると思います。この密結合に起因する変化対応能力の課題を解決できれば、グローバルな競争を凌駕する開発、保守、運用の革新を起こすことができると考えます。アプリケーションと基盤をNFRにフォーカスして疎結合化するために、新しくアプライアンス・フレームワークを設計し、いろいろとお客様実環境での実証性をスタディしたいと考えています。ミッションクリティカル環境にフォーカスし、仮想化技術やクラウド・コンピューティング技術を最大限活用してこの構想の実現をめざしています。”eCloud研究会” 参画について．JEANSの背景
Googleはあれだけの規模のデータセンターを少ないコストで運用できているのだがら、運用コストの削減はたぶん可能だと思う。そういった技術を企業システムに応用することのメリットは計り知れないだろう。
この提案で驚いたのは、開発コストにまで言及している点である。現在、ＩＴ投資の70%以上が運用系に費やされており、その原因が非機能要件（NFR）の作りこみの現状があるということ。この構想では、もう一度プラットフォーム側の可能性を見極め、そして、（HWではない）アプライアンス・フレームワークによる解決を試みる。つまり、NFR作りこみが必要ないぐらいの高度なプラットフォームを専用で用意（≒アプライアンス）することで、業務アプリは非常にシンプルにできる。そうなれば、3K,4Kといわれる酷いシステム開発の現状を打破できる。
CAP定理を超越した発想
CAP定理は、Consistency, Availability, Partitionsを同時に満たすことができないという有名な定理であるが、中島さんは、「Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない」といわれているように、CAP定理を根底から覆すような発想をしておられる。今に始まったことではないが、中島さんは、ある意味無茶苦茶な方である。
さて、スケールアウト構成での最も重要な課題はデータの信頼性、一貫性、即ちConsistencyです。プロセッサー・ベルの技術用語ではCoherenceです。クラウドレベルのレイヤーの議論になると、CAP定理とかBASEだとかの主張の下、ACIDが出来ないならアプリケーションで緩めてもいいじゃん、というようなWS-*（Web Service astar)前夜の議論が当たり前のようになっていますが、ハードウェア・レベルではそれは絶対許されません。そんな事が簡単に許されるならSUNが ROCKチップに失敗してギブアップする苦渋など無いわけです。CAP定理の逆、すなわち Consistency, Availability, Partitionsは全て満足した上でスケールアウト環境での高性能を出さなければならない。それがコンピュータ本来の、HWの基本です。SWとHWの話をゴチャゴチャに論じているように見えるかもしれませんが、ROCKが火を点けたTransactional Memoryの技術はその風景にあります。
さて、Hot Chips 21でクレームされているPOWER7のこの面での潜在能力、アプローチは中々凄いと思います。確かに Intel Nehalem-EXのQPIによる大幅な性能向上は驚愕です。しかしそれを超えて、POWER7で主張されているPOWER6に対する有効 Compute Throughput ５倍(1.6TB/s)のメッセージは大きい。これはフィールド・アップグレード等の面で、POWER7がPOWER6の足回りを基本的に受け継いだ以上物理的なチップI/Fの性能向上だけでは達成されないターゲットを、eDRAMのオンチップ搭載も含めた数々の技術革新によってクリアしようとしている点でIBMらしい味が感じられます。
ちなみに、クラウドでは、「ScalableでAvailableで、かつ、Eventually Consistentなシステムは可能である。」というように、Cの部分を緩くすることで、３つをほぼ同時に満たすことを目指している。この命題の実現こそが、現在のエンタープライズ向けのクラウド・システムが目標としているところなのである。
ところが、中島さんは、Eventually Consistentはナンセンスだとおっしゃっている。Googleを否定するわけではないが、ill-structuredだと。利用者側の対応に任せられてしまうことのデメリットの方が大きいと感じられているようだ。これはもっともなご意見である。
またレプリケーション型のデータ・モデルでデータ整合性を担保するためには、アプリケーション層で 3-Phase Commit 相応の最終的なコミット・コントロールが必須だ、というところでしょうか。プラットフォーム側の厳密さに期待できないという点でill-structured なわけですね。利用者側の対応に任せられてしまうということです。逆にこの ill-structured さがグーグルのスケールを可能にしているわけですから、”角を矯めて牛を殺す”ことがないようにもしなければならない。
これを”出来ない論議”で終わらせないためにプライベート・クラウドの主張があるわけですが、このアプローチに対しても出来ない論が強くあります。現行のきめ細かにカストマイズされた多様な NFR (Non-Functional Requirement) 構築に対応出来ないというのも大きなクレームです。
しかし私は疑問を抱かざるを得ない。
複雑さを考える---Complexity Quanta and Platform Definition
Summary of Jim Waldo‘sKeynote at the 10th Jini Community Meetingでいわんとしていることは、「それぞれの段階を通り抜ける際、我々は、何かを失う」ということ。
何も失わずにすべてを手に入れることなんて可能なのだろうか。これはとても難しい命題のように思える。
昨日、"eCloud"というリスティング広告に引っかかって、中島御大のサイトを発見した私であるが、とりあえず見なかったことにしようと思う。
（リタイヤされた元上司のサイトを半年もたってやっと見つけました。連絡ぐらいくれればいいのに。）
マルチ・スレッドへ：我々は、順序を失う（複数のことが同時に起こる）。これは、難しい。なぜなら、我々は、自然には、シーケンシャルに考えるから。
マルチ・プロセスへ：単一のコンテキスト（すなわち、我々が信頼しうる共有コンテキスト）を失う。グローバルな状態が、開発のあらゆるところで利用される。（すべてをスタティックに考えよ）
マルチ・プロセスからマルチ・マシンへ：我々は、状態を失う。「システム」のグローバルな状態というのは、虚構である。興味深い分散システムには、整合的な状態というものは存在しない。（Lamport:http://research. microsoft.com/users/lamport/pubs/pubs.html）分散OSのプロジェクトは、グローバルな状態を導入しようとしたが、大々的に失敗した。
信頼できないマルチ・マシンたちへ：誰を信ずることが出来るか分からない難しい状況の中で、我々は信頼を失う。
しかし、我々は何かを得てきた
Seq to MT: 並列処理
MT to MP: プロセスの分離(安全を与える)
MP to MM: 独立した失敗(何かまずいことが起きても、システムの部分は生きのこる)
MM to MMU: スケール(webスケール、インターネットスケール). 誰か他の人のリソースを利用せよ（あるいは、他の誰かが、我々のリソースを利用することを認めよ）
Google Docsのオンライン・ファイルストレージ機能
先日、Google Docsにオンライン・ファイルストレージ機能を追加するという発表があった。画像・動画、ZIPファイルなどあらゆる種類のファイルをGoogle Docsで保管でき、アップロードしたファイルは検索機能や共有フォルダ機能の対象にもなる。アップロードできるファイルのサイズは1つにつきMAX250MB※までだが、全体の容量の制限はなく、1GBまでは無料である。それ以上は追加で購入できる。ストレージの値段は、現時点で20GBが5ドル/年だが、Google Apps Premier Editionユーザーに対しては、1GB=3.50ドル/年で今後数ヶ月以内に提供する計画とのこと。
（※ MAX1Gに変更された。2010/1/28）
Documents List API: Upload any file and more (1/12/2010)
ついにGDrive実現、「Google Docs」に オンラインストレージ機能
全文検索の話
Documents List APIの一番大きな目玉はなんといっても全文検索APIである。Protocol Guide (v3.0)で「Performing a full text query」が New になっていないところをみると、もともとあった機能のようだが、今回から容量制限がなくなり、XMLやテキストファイルを登録できるようになったことで、やっと実用的になったのではないか。（サンプルプログラムによる検証を参照）
本題に入る前に、これまでのGAEにおける全文検索の実装方法についてまとめてみる。
１） DatastoreのPropertyIndexを利用する方法。これは、完全一致か前方一致しかできず、長さもStringの500バイトまでが上限。（Text型だと1MBまで格納できるがIndexを張れない）。使用するStrageの容量は格納するデータサイズの1倍以下。
２） N-gram検索。これには２つの意味がある。（①と②のb.は区別する）
① 転置インデックスのキーの切り出しを、辞書や構文解析に基づくのではなく、単に一定の文字数で切り出した語を入れる方法
a.ユニグラム = unigram (1文字単位)
b.バイグラム = bigram (2文字単位)
c.トリグラム = trigram (3文字単位)
② 分かち書きで切り出す方法
a.形態素解析（いわゆる転置Indexの実装）
b.N-gram（GoogleやYahooなどが採用している直前の(N-1)個の単語を見て、次の単語を予測するモデル（参考）
SuffixArrayは①のユニグラムと同等のものとなる。漏れはないが、データ量は膨大になる。nが単語のサイズとして、n+(n-1)+・・・+1 = (n+1)*n/2。また、nの最大は500バイトまで。
②の形態素解析でよく使われるロジックは、KAKASIや、TinySegmenterなどがある。ちなみに、TinySegmenter Java版の実装はココにある。
GAEにおいて現実的な実装と思われるものは、①のSuffixArrayと、②のTinySegmenterだろう。①はデータ量が膨大になることと、最大サイズが500バイトまでなので、長い文章には向かない。②は長い文章でも大丈夫だが、分かち書きの精度に問題があって、使い物になるかどうかはよくわからない。
Google Documents List Data APIの精度は、検証結果からみて②のb.ではないかと思う。とてもよい品質なので、これで十分だと思われるが、漏れが完全になくなるわけではないので、完全性が必要な項目にはSuffixArrayを使うとよいと思う。
注意点としては、Google Apps Premier Editionユーザーでないと、Documents List APIを使えないこと。ストレージの値段がGAEよりも2倍ほど高くなり、現在はまだストレージを追加購入できない。
サンプルプログラムによる検証
- Google Docs Serviceの生成と認証
DocsService service = new DocsService(appName);
service.setUserCredentials(user, pass);
- Google Docsの全文検索
URL feedUri = new URL("https://docs.google.com/feeds/default/private/full/");
DocumentQuery query = new DocumentQuery(feedUri);
query.setFullTextQuery(word);
DocumentListFeed feed = service.getFeed(query, DocumentListFeed.class);
- ポイント
- テキスト形式(text/plain)が対象
- Google Documents List Data APIを使用してアップロードしたmimeType="text/plain"のXMLファイルは検索対象となった。
- Google DocsのページからアップロードしたXMLファイルは検索対象とならなかった。
- Google DocsのページからアップロードしたTXTファイルは検索対象となった。
- Google DocsのページからアップロードしたExcelファイルは検索対象とならなかった。
- インデックス生成
- 検索ワード
- 「半茹で冷凍又は・・・」という文字列について
- 「半茹で」はヒットした。○
- 「半茹」はヒットしなかった。×
- 「冷凍」はヒットした。○
- 「冷凍又」はヒットしなかった。×
- 「冷凍又は」はヒットした。○
- 「東京都調布市深大寺東町１－XX－X」という住所文字列について
- 「調布市」はヒットした。○
- 「深大寺」はヒットした。○
- 「深大寺東」はヒットしなかった。×
- 「東町」はヒットした。○
- 「東町１」はヒットした。○
XMLファイルをGoogle Docsにアップロードする。
- Google Docs Serviceの生成と認証
DocsService service = new DocsService(appName);
service.setUserCredentials(user, pass);
DocumentListEntry uploadedEntry = uploadFile(service, fileName, title);
- Google Docsへアップロード
public DocumentListEntry uploadFile(DocsService service, String filepath, String title)
throws IOException, ServiceException {
File file = new File(filepath);
//String mimeType = DocumentListEntry.MediaType.fromFileName(file.getName()).getMimeType();
String mimeType = "text/plain";
DocumentListEntry newDocument = new DocumentListEntry();
newDocument.setFile(file, mimeType);
newDocument.setTitle(new PlainTextConstruct(title));
return service.insert(new URL("https://docs.google.com/feeds/default/private/full/"), newDocument);
}
- Googleのサンプルにあった
String mimeType = DocumentListEntry.MediaType.fromFileName(file.getName()).getMimeType();
を実行すると
java.lang.IllegalArgumentException: No enum const class com.google.gdata.data.docs.DocumentListEntry$MediaType.XML
とエラーが発生する。
- mimeTypeを"text/xml"に固定で設定すると
com.google.gdata.util.InvalidEntryException: Content-Type text/xml is not a valid media type.
アップロード時に上記エラーとなる。
"application/xml"でも同じくエラー。
- "text/plain"で正常にアップロードできた。
その他
- EUC形式のXMLファイルをアップロードしたが、その後ブラウザからダウンロードするとUTF-8形式に変換されていた。
またXMLの括弧"<"">"が、"<<"">>"に変換されていた。
- アップロードのURLにパラメータ"?convert=false"を付けると変換なしにアップロードされる。
ただし、全文検索対象とならない。
- 登録はconvert=trueで行い、取得についてXMLの括弧"<<"">>"を"<"">"に変換するのが妥当か？
成長戦略がほしい
現政権は成長戦略を描けていない。社民連出身の菅さんを筆頭に、労組などを出身母体としている政治家が多いので、どうしても「人に優しく、産業に優しくない」発想になりがちである。人に優しい政策は結構であるが、日本の産業がとても弱っており、財源を含め合理的な策が見い出せないのが問題だと思う。
人に優しい政策には大きなコストが伴う。それは、例えば、CO2削減は企業が、介護は国民が負担することになる。（介護ビジネスというのは局所的には成り立つが社会全体からみるとコストとなる。私は、麻生さんの失言「老人は働け」の方が、より生産的だと思っている）
しかし、既に大企業に頼る時代は終わっており、国の税収も少なくなってきている。無駄をなくすとはいっているものの、こういった現状をふまえると、おのずと「人に優しい」政策には限界が見えてくる。
日本の大企業は昔ほど元気ではなく、例えば、Panasocic（3.81兆円）とソニー（3.08兆円)を足してもサムスン電子（8.26兆円）より小さい。
時価総額上位ランキング（日本）
時価総額上位ランキング（世界）
足りないのは成長戦略である。基本はやはり産業の活性化。金融マネーゲームもよくないが、産業を否定するのもよくない。生産的な発想で、価値のあるものを効率よく生み出す努力をすることが重要だと思う。そういう意味では、ITは一つの柱になってしかるべきと思う。
現政権には具体的な政策を提示して欲しいものである。
政治家の権力は限定的だった
がらっと変わって、権力の話。
こないだ問題になった天皇の政治利用の件もそうだったが、民主党政権になっていろいろオープンに報道されるにつれ、政治家が及ぶ権力はかなり限定的だったんだなということがわかってきた。例えば、小沢さんの「検察の権力と闘う」といった発言はその象徴である。
しかし、そもそも検察の権力はどこに属しているのだろうという素朴な疑問が沸いてくる。国家権力を立法権・行政権・司法権の三権に分立しているのは、「国家の権力を性質に応じて分け、それぞれを別個の機関に分散させ、各機関に他の機関の越権を抑える権限を与え、相互に監視しあうことにより抑制均衡を図るためである。（Wikipediaより)
今は民主党が立法と行政の権力を握っているのは皆承知していることだ。実質的には、鳩山さんや小沢さんといった方が最高権力者だと思うが、その彼らたちが闘う国家権力とは一体何者なんだろうか？
小沢氏に「戦って」と首相、資質に疑問符
特捜部を含む検察庁は、行政機構上、法務省の一機関に位置付けられている。その法務省の長である法相は検察当局への指揮権を持つ。実際の指揮権発動には慎重な配慮が必要だろうが、その法相に指示できるのは唯一首相だけだ。
鳩山さんの言動から推測すると、ご自身の指示ではないようである。ということは、検察は一行政機関ではあるが、自分たちで勝手に判断して動いているということだろうか。それとも、他にいる影の権力者が指示しているのだろうか。もしそうだとすると、責任は誰が取るのだろうか。形式的には行政のトップである鳩山さんの責任になるのだろうが、実際に権力を行使する者の責任はどうなるのだろうか。
また、土地購入の際には、小沢さんは個人の積み立て金といっているが、検察は企業献金が使われた疑いがあるといっている。これが石川議員逮捕の理由とされているが、こういった情報は新聞やニュースから流れてくるだけで、検察からの説明はいっさいない。少なくとも、小沢さんの主張と検察の見解の違いがあるのだから、検察は根拠についての説明責任があるように思う。
検察の顔が見えないまま捜査が行われていることに、ちょっと気持ちの悪さを感じてしまう。
また、以下のように、権力闘争と指摘している記事もあり、検察といえども、どういう意図があって動いているのか、国民がしっかり監視していく必要がありそうである。
逮捕前日「理不尽な世界つらい」 石川議員、佐藤優氏に
佐藤氏は外務省在職当時、鈴木宗男衆院議員の側近とされ、鈴木議員に対する一連の捜査の過程で、背任などの罪で起訴され、有罪が確定した。その時の捜査を「国策捜査」と批判した佐藤氏だが、「今回は国策捜査ではなく、民主党と官僚組織の権力闘争だ」と指摘した。
＜関連＞ 鈴木宗男氏「検察正義は間違い」 批判に沸く民主党大会
検察以外にも、政治家が及ばない権力があるように思う。独断と偏見で思いつくまま列挙するとこんな感じになる。
予算・・財務省
外交（軍事）・・米国
天皇・・宮内庁
情報管理・・マスコミ
また、昨日も書いたが、日本には世間様という絶対神がある。世間様がいいといえば良く、悪いといえば悪い。本当の意味で民主主義でないかもしれないけれど、世間様には誰も逆らえない。
戦前、暴走した陸軍は政府の統制下になかったといわれている。検察は軍ではないが、マスコミも同調していた構図は当時と瓜二つだ。
政治家よりも、検察とマスコミの方が世間様の判断を操作できる立場にあるというのは、結構怖い状態なのかもしれない。権力のシビリアンコントロールは絶対に必要であると思う。
GMAIL不正侵入問題で攻撃元となったサーバは中国政府関係者のものと同一だったというニュースが流れた。もしこれが本当なら国際社会から中国政府が釈明を求められる可能性があるとのこと。中国政府からの検閲を嫌って中国事業からの撤退も検討しているGoogleの動向にも影響を与えそうだ。
中国に関しては、これまで経済と政治は別物と見ていたのであるが、今回の一件で、両者は密接に関係していることを十分に認識させられることになった。しかし、１IT企業の対応が国際政治にまで影響を及ぼしたことには驚きである。
10年前に上海に行ったときには、活気あふれる街の雰囲気とはうらはらに、政治的なリスクを感じ得なかったので、いつかはこういう事件が起こるのではないかとは思っていた
ただ、言論の自由が保障されないお国の事情があるのもわからないでもない。13億人、55の民族からなる国家体制を維持するには、全体主義でやっていくしかない。急激な民主化はソ連崩壊のときと同じように、地域紛争を勃発させる危険もある。言論の自由、民主化を進めた結果、多くの人血が流れるという事態は避けなければならず、当然、これはその国の政府が責任をもってやっていくことでもある。言論の自由は国の政治体制に影響を与えかねないのだ。
今回の事件を受けて、岡田外務大臣が、「規制の裁量権はそれぞれの国にある」としながらも、「自由で民主主義の国に生きる我々として、言論の自由は可能な限り保障されるべきだ」と暗に中国を批判した。大臣のように正論を一方的に主張することは簡単だが、それがもたらす結果と責任をふまえ、現実論にもう少し踏み込んでもらいたい気もする。
中国の全体主義を理解するには、中華思想を理解するのが早道だと思う。中国人が語る中華思想がとても生々しくてわかりやすかった。
価値観という意味では、日本は欧米型の「個人主義」があり、それから、無意識のうちに世間体や恥の文化に支配されている。無宗教であるが世間様という絶対神には逆らえない。
でも日本は個人の尊重があるからこそ公害などを乗り越えられたと思うし、世間体や恥があるからこそモラルを高く維持して犯罪発生を防いでいるとも思う。住みやすい環境で安全に暮らしていけるのは、こういった日本独自の文化があるおかげだと思っている。
上海の大気汚染や、揚子江の水質汚染はとても酷いものだ。今より高収入になったとしても、そこに住もうとは思わない。
困ったことに、揚子江から流れる栄養塩のせいでエチゼンクラゲの大発生などが東シナ海で起きている。大気汚染が九州の方に流れたために、光化学スモッグ注意報が佐賀県のど田舎で起きている。こういった環境汚染は日本も無関係ではない。
中国の石炭の火力発電所建設などでは日本企業も支援していたらしいが、高度な脱硫技術をもっているにもかかわらず、現地の法律の基準が甘いとの理由で、わざわざ脱硫装置を外して導入したという話も聞いた。当事者にとってみたら、コストを安く導入できるので、ありがたい話なのかもしれないが、結局は自分たちがそのつけを払うことになると思う。
たぶん、このあたりのモラルも高くしていかないと、国際社会では説得力がない。これから日本は環境立国でやっていこうと思うならなおさらである。
一企業であってもGoogleのように強い姿勢で望むべきである。日本の環境基準を押し付けるぐらいの迫力で、政治的な摩擦を恐れず、どんどんやってほしいものだ。
福岡の事務所の近くで撮った室見川の写真
今年の動向、ネットのビジネスモデル
今年は、新しい技術や大きな目玉トピックはないものの、クラウドを使ったサービスが多数登場して、標準的になると予想する。XMLやWebサービスのときも最初そうだったが、ある程度認知されると、それが標準的になり、単に使っただけでは注目を集めることはなくなる。ただ、うまく活用できたところは大きな競争力を得てきたのも事実だ。GoogleやAmazonは、早い段階からWebサービスに関してとても熱心に実装してきたが、それが現在の競争力になっているようにも思える。クラウドも同様に、今後うまく活用していけるところが競争力になっていくと思われる。
さて、今年もあいかわらず景気はよくはならないと思うが、クラウドはだいぶ認知され一般的にも広く使われるようになってきている。弊社へのGAEに関する案件相談も着実に増えてきている。これまでは、知り合いのツテで請負の仕事をまわしてもらうようなことが多かったが、最近ではホームページを見て直接相談に来られるお客様が出てきた。インターネットから直接相談を受け、提案していた案件が成約できる見通しとなったことは非常に大きい。インターネットだけでビジネスをやりたいとずっと思ってきたので、本当にそれが実現できることがわかって嬉しいかぎりである。このモデルのいい点は、ブローカーのような、人を餌に暴利を貪る悪い連中を排除できるということ、また、大企業に依存してきた下請け体質から脱却できるので不景気でも強い会社になれること。それから、自分の強みや、やりたいと思っている分野（ドメイン）に集中できるという利点の3点である。これまでの下請け業務は、ある意味人材派遣的な要素が大きく、時間をお金に変えることはできても、プロダクトやノウハウが残ることはあまりなかった。GAEなどのクラウド技術に特化することで、やればやるほどプロダクトは進化してノウハウも蓄積する。本当に運用してはじめてわかる問題もあるので、リアルの案件の実績が得られることは本当に大きいと思う。
抱負
去年は種まきの年で今年は収穫の年。
今年の前半は何とか案件をリリースさせて、事例という形でお披露目できるようにしたいと思う。今年は泥臭く稼ぎ、消耗しきった体力を養う年にしたい。（もし一緒に開発したいという方がいたら連絡ください。弊社がブローカーとなってお仕事を依頼いたします。ｗｗｗ）
それから、今年の後半は、現在開発中のECもリリースできるようにしたい。理想としているインターネットの小売ビジネスへの第一歩として、それが本当に実現可能なビジネスモデルなのかを検証していきたい。
技術的な点では、スケーラビリティの追求をテーマに以下をやっていきたい
１）GAE PDFサービスの大規模対応
大量のPDFを動的に生成するために、これまでにもReflex iTextを使って試行錯誤しながら実験してきたが、GAEを使うケースではまだ満足いく結果が得られていない。実案件ではAmazon EC2か独自サーバになってしまうのが現状である。今年も引き続き研究していき、何とか実用化させたい。GAEにこだわっている理由は「安い」からで、GAEでもちゃんとスケールすることが確認できたら実案件でも採用していきたい。
２）GAE 全文検索
実用的な全文検索サービスを作りたい。SuffixArray方式、分かち書き＋転置Indexの２つの方式を採用し、用途に応じて使い分けていきたい。
３）クライアントを含めた実装パターンの確立
HTML5のWebStorageと大福帳 非同期モデルを推し進めたデザインで、これを実用レベルにすることを目標にしたい。リッチクライアントのようなWebアプリでありながら、いかにスケーラブルにしていくかが重要。これをやるには、ステートレスなバージョン管理がポイントだと思っている。プロジェクトでも積極的に採用していきたいと思う。
４）Privateクラウドソリューション
Privateクラウド、つまり、スケーラブルなシステムを分散KVSで実現させるシステムの需要は伸びてくると思われる。Reflex BDB単体では不十分で、Voldemortなどのミドルウェアを活用することで、具体的に提案できるレベルまで作っていきたい。
今年もよろしくお願いします。
