フレクトのクラウドblog(New)

MESHとIFTTTを組み合わせて30分お手軽IoTクッキング

こんにちは。IoTチームエンジニアの小川(mitsuruog)です。フレクトには5月からお世話になってます。

先日、出社するとこんなものが・・・

そう、SONYが開発した電子ブロック「MESH」です。

MESHには加速度、スイッチ、LED、GPIOの4種のセンサーモジュールと、iPad上でこれらのモジュールを簡単に接続できるアプリのがセットになっています。
MESHのモジュールとアプリはBluetoothで相互接続されます。

今まで、IoTのプロトタイプを作成する際は、いちいちデバイスを準備したり、回路を設計したりする手間がありましたが、MESHをレゴブロックのように組み合わせることで、簡単なIoTのプロトタイプを作成することができます。

こ、これは！素晴らしい未来が待っているかもしれません！！

動かしてみる

早速ですが、MESHの加速度センサーモジュールを入り口のドアノブに取り付けて、ドアが開いた瞬間に少し離れたところにあるiPadにて入ってきた人を撮影できるか試してみした。

MESHセンサーはドアノブに対して少し斜めに取り付けるのがミソです。

撮影はドアから2mほど離れた場所で行いました。

MESHのアプリキャンバスはこちらです。

非常にシンプルですね。

では、実験開始。

ガチャ(ドアが開く音)
・
・
・
(しばしの沈黙)
・
・
・
カシャ(シャッター音)

現状、MESHからデバイスのカメラを起動させて、写真を撮るまでは少しタイムラグがあるようです。
(ということで・・・社員の方には、ドアの前で少し待機するように指示)

タイミング調整はこれでばっちりです。

繋げてみる

MESHにて来訪者を撮影することができましたので、これをクラウドサービスに連携してみましょう。
ここはIFTTTを利用します。IFTTTはデバイスやクラウドサービス同士を簡単に連携することができるWebサービスです。

ここでは、シンプルにiPad上に新しい写真が撮られたら、SalesforceのChatter上にある、特定のグループに誰かが入ってきたことをFeed投稿します。

全体的なシステム構成は次の通りです。

完成！！

では、実際にChatterのFeed投稿されるか試してみます。

無事、ChatterにFeed投稿されました！
（実際には、IFTTTの連携にタイムラグがあるので、リアルタイムではないです。）

まとめ

最近、MESHなど簡単にプロトタイプできるデバイスが登場してきたことで、フィジカル(物理)とデジタルを繋ぐ敷居が下がってきたように感じます。

アイデア出しからプロトタイプ作成まで、正味30分。
昼休みの時間にこれだけの遊べるものができるのは嬉しいです。

MESHはまだまだできることが少ないのが現状ですが、将来のロードマップを見ると、WebAPIや他のデバイスとの連携についも視野に入れているようです。
WebAPIと連携するようになると、かなりできることが増えそうで楽しみです。

フレクトではIoTのプロトタイプやなどやってますのでお気軽にお問い合わせください。
ではではー。

Dreamforce'11 参加レポートと感想(2) ～第1のデバイスとしてのモバイル～

前回に引き続き、参加レポートその2。

モバイルデバイスの増加と、それに対してのDreamforce'11内で自分が拾った情報と感想を簡単にまとめてみます。Salesforceな部分が少ない記事になっていますが、ご容赦を。


■ モバイルデバイスの利用増

モバイルデバイスについて基調講演にてその成長についてグラフが示されていました。

コンシューマや企業の従業員がモバイルデバイスでWEBアクセスをするだけでなく、企業においては従業員がタブレットデバイスを使うようになっていて、その勢いがすごく大きいということです。

たしかに、自分のお取引させていただいているお客様でもiPadを持っている方が増えています。スマートフォンを含めたスマートモバイルデバイスの利用というのは加速度的に増えていて、その結果、PCからのアクセスというのが主流ではなくなる(なくなった)ということのようです。

自分は大学時代からずっとPCなので、今でもPCメインですが、もう1まわり下の世代以下になるとスマートモバイルデバイスでのWEBアクセスが普段から主流になっていたりするのかな、と思います。

■ 第1のデバイスとしてのスマートモバイルデバイス

そういったスマートモバイルデバイスの増加を考えると、これからは第1のデバイスとして考えなくてはいけないのだと認識しました。

基調講演でモバイルすごいな、と思ってその後のSocial Enterprice Applicationのアーキテクチャについてのセッションに参加したら、これからアプリケーションを作るときにはモバイルデバイスをfirst deviceとして扱おうといった話を聞きました。

そのセッションでは90年代はクラサバ、2000年代はRIAやサーバサイドが中心だったが、これからはハイスペックなモバイル端末のパワーを活かしたアプリケーションアーキテクチャになるという話がありました。Database.comの話をしたうえで、従来はアプリケーションサーバを介してモバイルデバイスはWEBなどにアクセスしたけど、次のアーキテクチャとしてDatabase.comに直接、つなげるようにするという例の紹介がありました。

われわれはWEB開発では今まではPCを第1のデバイスとして考えることが多かったですが、今後は徐々にスマートモバイルデバイスを第1のデバイスとして考えるようにシフトしていかないとまずいなぁ、と認識。そのときにはアプリケーションアーキテクチャ設計、実装、サービス開発のロードマップなども、順序や発想が違うので、今からそういった順序で開発するときの考え方を築いていかないとならないときと実感しました。

■ HTML5で対応するtouch.salesforce.com

Salesforceの毎回の新機能、製品の発表を見ると、基本的には企業向けであるSalesforceの製品であってもコンシューマ向けのサービスで必要とされるレベルのユーザエクスペリエンスをちゃんと提供していきたい、という意志のようなものを感じます。

スマートモバイルデバイスの増加に対してもtouch.salesforce.comとして基調講演で解がひとつ発表されていました。

touch.salesforce.comはHTML5でできていて、タブレット型、スマートフォン型など問わず、タッチUIを持つスマートモバイルデバイスでSalesforceの機能が使えるようになるということです。Visual Forceでガリガリに書き換えた画面等はできないかもですが、カスタムオブジェクトなどユーザがカスタマイズした部分についても対応しているとのことで、Salesforceのプロダクト群もスマートモバイルデバイスからより使いやすくなるのかと思います。

ソーシャルの波に引き続き、モバイルについてもきっちり対応していっていることが分かる発表でした。

■ まとめ

モバイルが大事だ、は最近ずっと言われていることで、当たり前といえば当たり前なのかもですが、より強く実感をしましたし、帰国したら社内でのモバイル対応の既存の動きについてもっと加速度をつけたい、と思います。

次回はHerokuやSiteforceについてセッションやブースで見聞きしたことを書いてみたいと思います。

Dreamforce'11 参加レポートと感想(1) ～企業のソーシャル化について～

8/30からDreamforce参加にしています。社長の黒川と私とで2人で参加しています。

8/31まで終わったのでその分について忘れないうちにまとめておきたいと思います。
われわれはSalesforce関連のインテグレーション開発を主力している会社なので、そういった視点になります。

レポートは何回かに分かれます。Salesforce.comはビジネスユーザー向けのアプリケーションサービスの会社であるとともに開発者向けプラットフォームの会社でもあり、視点はいろいろあります。まずは前者のサービス観点から気になったこととして、「企業のソーシャル化」についてのレポート、感想です。

■ 従来のWEBと企業のソーシャル化

従来のWEBと企業のソーシャル化について基調講演での発表内容についてはPublickeyさんの以下の記事に正確な情報があるのでそちらを参照してもらえるとよいかと思います。

http://www.publickey1.jp/blog/11/chatterhtml5ui.html

ここではフレクトの担当者としての追加の感想を書きます。

基調講演では最初の方にデータとしてインターネットの利用が従来の検索から始まるWEBではなく、Facebookなどのソーシャルメディアを中心としたものに変遷してきていることが示されていました。日本ではどうかは正確にはわからないのですが、そんなに使われているんだぁ、と思いました。

その上で、ネットサービス、コンシューマ向けサービスがソーシャル化する中、「企業のソーシャル化ができているか？」と問いかけ、それに対するSalesforce.comのアプローチがChatterをベースにした各種機能の発表がありました。

ChatterでIMができる、顧客とプライベートグループを作ってコミュニケーションができる、Contact(取引先責任者)にSocial Media上でのコミュニケーション情報が記録されるなどソーシャル化を示す機能が次々と発表されました。次々と発表されるのでメモが追いつかないくらいでした。

ポイントは、(1)フィードやチャットなどChatterを基本としてFacebookのようにエンタープライズシステムが使える、(2)従来のWebではなく、ソーシャルなインターネットを前提とした顧客とのリレーションづくりができる、という2点だと思います。

(1)についてはChatterが出てきたときからそういった発想がありましたし、新しくはないかもですが、大事なことと考えています。Salesforceはコンシューマサービスの中でも特にユーザへのサービス、UIが進んでいるところと同じようにエンタープライズシステムを使えるようにしたい、というのが強い会社なので今はFacebookと同じようにユーザエクスペリエンスを提供していくということなのかと。(昔はAmazonのように、将来はわかりません)。

(2)は特に今回強調されたことで、ソーシャルメディアの情報をSalesforceに統合することで、新しい顧客との関係づくり、をイメージさせるようなデモが多く見られました。(2)については以下の感想でもう少し詳細を。

■ ソーシャルメディアの情報を使っている現場から感想

一緒に参加した社長とともに、企業のソーシャル化、Chatterを中心としたソーシャルメディアとの連携には強い興味を持ちました。(ほかの参加者さんも同じと思いますが)

私どもも社内では営業管理にSalesforceを使っています。顧客や顧客の担当者情報についてFacebookやTwitterのURLが分かっていれば、取引先責任者(Contact)のフィールド(カスタムで追加)に入れるよう"手動運用"していて「顧客がどんなことに関心を持っているのか」についてわれわれも強く関心を持って営業活動をしています。

運用してみると、実際に初めてお会いする方でも、ソーシャルメディア上で関心事などがあらかじめ分かっていると、より強く相手に関心を持った状態で人とお会いしてよりよいコミュニケーションがとれるようになったと思います。また、お客様との双方向の関係においてもソーシャルメディア上でのつながりが何かしらある方が、より深いリレーションが築けています。

そういった現場にいる担当として、顧客管理をするシステムとしてのSalesforceが次にChatterを基点に外部のソーシャルメディアと連動して情報も含めて顧客とよいリレーションを築けるようにしよう、という方向のは単純に私どもの手動運用を減らしてくれるだけでなく、顧客とのよりより関係づくりの新しい手段を提供してくれる可能性を持っているのではと思いました。

ただ、システムの機能としては充実したとしても、機能だけではなく、まだ成熟していないソーシャルメディアを使った業務、運用に耐えられる同時にベターなやり方、自分たちなりのプラクティスを同時に蓄積していく必要があると思いました。ぼくらも顧客のソーシャルメディア情報を登録していますが、活用については人によってまだばらつきがある感じです。

Social Divideという言葉が基調講演でありましたが、ITリテラシーという言葉があるように、ソーシャルメディアと使った顧客とのリレーション構築には、何かしらのリテラシーが必要で、企業としてはそれができる集団になっていかないと、効果を上げられないだろうなぁ、と思いました。

■ まとめと次回

ソーシャルメディアをつかった企業活動については今回の発表にある機能によい運用がかけ合わさればより新しいレベルでのリレーションづくりができると思いました。

まだ運用プラクティスが少ない分野ですが、自分たちでも機能のあるなしにかかわらず、引き続き実践して、機能の理解だけでなく、より使いこなせるようになるよう、がんばってみます。

次のレポートはモバイル関連を書いて、その次はHerokuとかSiteforceのことを書こうかと思います。

Heroku for Javaとセールスフォース

HerokuがJavaをサポートするとのことです。

http://blog.heroku.com/archives/2011/8/25/java/

昨年、2010年のDreamforceでセールスフォース・ドットコム（以下、セールスフォース）がHerokuを買収したというニュースが出たあと、Node.jsなどがサポートされ、RubyまつもとゆきひろさんがHerokuに参加され、といろいろな注目すべきニュースがありましたが、Javaのサポートもすごく大きなニュースです。

また、フレクトはJavaによるWEB開発を得意領域のひとつにしているので、当社としては待ち望んでいたニュースでもありました。

以下、さーっと、Herokuのブログ記事やDev Centerのドキュメントを読んだかぎりでのHeroku for Javaについての自分なりの理解をまとめておこうと思います。（さーっと読んだ結果なので、間違いあるかもです）

■ HerokuっぽくJavaを使う

Herokuは小さいチームがスピード感を持ってインフラ/ミドル管理などのストレスなく高い生産性でアプリケーションをシンプルに構築できるプラットフォームを作るという思想でサービスの拡張等を進めているとぼくは理解しています。ビジネスマンというよりはDeveloperの立ち位置にすごく近い感じ。Rubyが最初の言語として選択されているのは、そういう思想のもとにサービスを展開しているからと理解していました。

したがって、個人的（フレクト的にも）Javaをサポートしてほしいな、と思いながら、ちょっと文化が違うかも、とも思っていました。Herokuっぽい部分とJavaっぽい部分が合わない部分があるのではと（あいまいな表現ですみません）。

これについて、Herokuはブログ記事によると、Javaにはやはりいくつか問題があると認識していたようです。特にJ2EE(JEE)とJ2EEアプリケーションコンテナを使った開発、デプロイが問題であることを認識していたようです。

これに対して、Heroku for JavaではJ2EE的なアプリケーションコンテナを使わないでJettyをアプリケーション内に埋め込むというアプローチをとっています。そのうえで、J2EE的なアプリケーションコンテナが提供しているデプロイ、ロギング、クラスタリング等の機能をHerokuのプラットフォームが提供するということのようです。

こういったアプローチをとることにより、JavaにおいてもRubyでHerokuを使うのと同じようにソースを書いて、gitにコミットして、pushするというRubyの場合と同じステップで簡単にアプリケーション構築・デプロイができるようになっています。実際にブログ記事中の「Heroku for Java in 2 minutes」を見ても、Rubyでのソース書く→Deployのステップとまったく同じように見えます。すごくシンプルですね。

Javaのサポートってどうなるのかな、Herokuと合うのかな、とちょっとだけ心配していましたが、杞憂のようでした。Herokuが大事にしている生産性、シンプルにストレスのないことをJavaでもとなってますね。Java的な文化にあわせるのではなく、JavaをHerokuっぽく使えるようにされています。すごくよいと思いました。社内でもいいねと話しています。早急に社内のエンジニア達でキャッチアップしようと思います。

■ セールスフォース風味な部分やVMforceな部分が少し入っている

あと、今回のJavaサポート関連のドキュメントを読んでいると、セールスフォースとの関連がちらほら見え隠れします。

たとえば、Force.com、Database.comとHerokuとのインテグレーションはどうするの？といったFAQが入っています。

http://devcenter.heroku.com/articles/java-faq#how_do_i_build_forcecom_and_databasecom_java_applications_on_heroku

買収後、あまりセールスフォース的な要素が見られなかったHerokuですが、少しずつ相乗効果が出せる部分が見えてきそうです。セールスフォースを使ってインテグレーション事業に取り組んでいる我々としてはこういったことは大歓迎です。

VMForce風なところは、tutorialにSpringをつかったものがあったり、ブログ記事中の「Why Java?」に対して「600万人のDeveloperがいるから」みたいな記述がある部分です。VMForceはSpringという業界でよく使われているのフレームワークで、なおかつ世界中の600万人のJava Developerにクラウドを提供できる、という触れ込みだったので、その辺の文言やら雰囲気がちょっとだけHeroku for Javaに混ざっていると感じました。VMForceは今後、Heroku for Javaとどう違いを出すのでしょうか。いろいろ気になることはありますが、Dreamforce等、今後のニュースを確かめたいです。

■ まとめ

Heroku for Javaについて今ある情報だけからの感想を簡単にまとめました。Herokuのよさを最大限に活かしてJavaが使えるというのがすごくうれしいですね。

セールスフォースのプロダクト群とも、Database.comなど相乗効果が高そうなものはどんどん連携しやすくなるのだと思います。その辺も要ウォッチですね。

今後は実際に使ってみた記事など技術的なことも書いていきたいと思います。

■ ちょっとだけ当社のことと中途採用のこと

フレクトはWEBサイトとSalesforceとの連携開発を1つの強みとしており、WEB開発についはJavaがメインです。そういった我々にとってHeroku for Javaの発表は待ちに待った発表でした。今後、Heroku for Javaと他のSalesforceプロダクト群連携ソリューションをもっと充実させていきたいと思います。

また、それを担ってくれるエンジニアも引き続き募集しています。Herokuなどクラウドプラットフォームでの開発を行いたい方、ぜひ以下からご連絡をいただければと思います。

http://www.flect.co.jp/recruit/index.html

セールスフォース、Google、AmazonのPaaSの比較とSIer視点からの印象

最近、Amazon Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。

業務系に強いForce.com、ソーシャルアプリなどコンシューマ系サービスに強いGoogle App Engineあたりが有名でしたが、最近は選択肢がかなり増えました。
この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。

http://www.publickey1.jp/blog/11/google_app_engine_paas.html

http://www.publickey1.jp/blog/11/_java_paas.html

上記の記事でだいたいよいところ、難しいところがまとまっているのですが、今日はGoogle App Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、SIerでマネージャをする立場から、自分なりの比較と印象を書いてみようと思います。まず、セールスフォース、Google、Amazonが提供、あるいは関連が強いPaaSについて言語、利用するDB、インフラ運営元、そしてサービス提供会社を一覧にしてみました。

◆ 各プラットフォームと言語、DBなどの比較

名前	言語	DB	インフラ環境	サービス提供会社
Google App Engine(GAE)	Python, Java	BigTable	Google	Google
Force.com	Apex, VisualForce	Force.comのDB(Database.com)	Force.com(セールスフォース)	セールスフォース
VMForce	Java(Spring Framework)	Force.comのDB(Database.com)	Force.com(セールスフォース)	セールスフォース
Heroku	Ruby(Ruby on Railsなど)	PostgreSQL(標準)など	Amazon	セールスフォース
Amazon Beanstalk	Java	Amazon RDS(MySQL), Amazon SimpleDBなど	Amazon	Amazon
Engine Yard	Ruby(Ruby on Railsなど)	MySQL(標準)など	Amazon	Engine Yard(いずれAmazon?)

注目すべきはGAEはDBが独自であること、Force.comはApex、VisualForceという独自の言語でアプリケーション構築をする必要があることでしょう。(Force.comのDBは独自といえば独自ですが、RDBの考え方でだいたい操作できます)

それに対して、Amazon上で動くPaaSは言語、DBともに、オンプレミス環境からの差分はかなり少ないと思ってよさそうです。こういった特徴を踏まえたうえで、「よいところ」と「気をつけるべきところ、気になるところ」を私の所感でまとめてみました。

◆ 特徴まとめ

PaaS分類	よいところ	気になるところ
Google App Engine(GAE)	・アプリケーションサーバだけでなく、データベースまで自動スケールするところ。 ・Java/Pythonといった汎用性の高い言語で開発できること ・非常に安い。1日あたりのQuota制限があるが、ある程度のボリュームまでは無料と考えてもよい。範囲を超えても安い。 ・個人で勉強しやすい。情報も多いし、安い。	・物理的にどこにデータが置かれているかなどブラックボックス(悪いこととは限らない)で、どう動いているか見通しがきかないことがあること ・BigTableという、RDBとは違う考え方が求められるデータベースを使うため、使いこなすにはかなりの学習コストが発生すること。開発者の確保もやや難しいこと
Amazon系(Heroku、Engine Yard、Beanstalk)	・Java(Tomcat)やRuby on Railsなど、オンプレミスの環境で培われた技術を用いてアプリケーションが構築できること。 ・開発者が確保しやすい。 ・Amazon EC2、RDS、S3、CloudFrontなどPaaSの構成要素となるコンポーネントが独立したサービスとなっており、自由自在に組み合わせられる。	・GAE、Force.comと比べるとRDBやストレージなどのバックアップ等、ミドル、インフラの運用面的なことを多少意識しないといけないこと ・アプリケーション部分についてはForce.comのように何かベースとなる強力な機能があるわけではないので、その開発コストはオンプレミスに近い感じになること
Force.com系	・GUI操作(Point&Click)だけで、かなりのカスタム機能が作成でき、型にはまると生産性がかなり高いこと。 ・認証系の機能、ユーザの権限制御、ワークフローなどスクラッチ実装をするとけっこう面倒な機能が既に存在すること。 ・国内、海外問わずたくさんの大手企業が業務システムに使っており、セキュリティ含め、実績面では信頼しやすい	・Apexなど独自技術の学習コストがかかる ・ストレージ容量やレコード件数、外部からのAPI呼び出しの最大数の制限など、「容量の大きいデータ」、「件数の多いデータ」への制限は強いこと ・ライセンス費用がユーザ単位であり、GAEやAmazon系の課金と違うのは注意が必要なこと

上の色をつけているところが、もっともメリットとして特色があるところです。

◆ 用途に合うと高い効果を出すGAEとForce.com

GAEとForce.comは「制約は強いが、型にはまると高い効果を出す」と考えるとよいと思います。

GAEはデータベースが独自なので「Joinをさける」「集合関数は使わないで、レコードに持つ」などRDBとは違う考え方で開発が必要です。しかし、アプリケーションサーバだけでなく、データベースまでもが自動スケールするので、アクセス量が読めないアプリケーション(ソーシャルアプリなど) では、独自技術を習得するコストを払ってもメリットを得られる可能性があります。

Force.comについては、GAEに比べると書籍等少なく、個人で勉強する人も少なそうなので、知らない人も多そうですが、GAEと同じく型にはまると強いPaaSと考えています。
GAEやAmazon系のPaaSが提供している機能はデータストアやストレージのAPIなど、どんなアプリケーションでも共通で使いそうなものが中心です。それに対して、Force.comは会社などの組織で使うアプリケーション構築に必要な機能が最初から揃っています。たとえば、ユーザの発行、権限管理、ワークフローなど。認証処理とか権限制御など、受託案件では「毎度おなじみ」の機能ですが、けっこう作るのは毎度面倒、な機能です。そういったものが最初からそろっていて、しかも簡単にカスタマイズできるというのは、はまるとすごい生産性です。

実際、フレクトでも案件管理や勤怠管理、経費申請などいくつかの業務アプリをバンバン作っていった実績があります。セールスフォースが得意とするCRMだけでなく、多くの業務系アプリの開発が高い生産性でできる実感を持っています。

一方でForce.comはユーザごとにライセンス費用がかかったり、CPUやストレージをちょっと使うと意外と早く制限がくるなど、特有の制約事項があり、注意しながらの開発が必要です。

両方とも制約が強く、はまると効果テキメンっといった感じですが、学習コストがかかるので開発者のアサインが意外と難しい、といったデメリットがあります。

◆ 既存のオープンな技術をベースにスピーディに作れるAmazon系

HerokuやBeanstalkなどのPaaSはRuby on Rails、Java(Tomcat)、PostgreSQL、MySQLなどのオンプレミス環境でも存在しているオープンな技術をベースとしていて、それらを使ったシステムをすばやく作れるというメリットがあります。アプリケーションサーバ、RDB、ストレージなどはAWSや各PaaSが提供してくれているサービスをそのまま使えばいいので、インフラ、ミドルの心配をせずに、Web開発のスタンダードな技術であるJava、Ruby、MySQLなどを使って開発できるというのがGoodです。オンプレミス環境と同じで、なおかつオープンな技術をベースにしているものが多いので学習コストも低く、開発者のアサインも容易です。

コンシューマが使うWeb系のシステム構築で、とにかく早くリリースしたい、早く作りたい、という場合には、Amazon系のPaaSが有力な選択肢になります。

実際、フレクトでもPaaSではありませんが、Amazon EC2、S3などを使ってモバイルサイト(http://bhmb.jp/)を開発、運用しており、開発時のプラットフォーム選択の決め手はクラウドの恩恵をうけつつ、既存技術をベースにすばやく開発したい、というものでした。

◆ SIer視点からの認知度、信頼度の印象

SIerである私たちにとって、多く接するお客様はユーザ企業の情報システム部門の方々です。そういった企業の方々からも選択肢として認知されているのはセールスフォースがやはり一番という印象です。多くの企業で導入されたということはコンプライアンス観点などからもクリアした案件が多いということで、この辺はお客様に提案するプラットフォームとしてはSIer的にはGoodです。

Amazon系のサービスやGoogle App Engineもまったく認知されていないというわけではないのですが、積極的に選択肢にあがってくるケースが多いかというと必ずしもそうではなさそうな気もします。Amazon系やGAEの事例もサービス企業が内製でそのメリットを活かして作っているケースが多く見受けられます。企業の情報システム部門からの認知度、信頼度という点は、今後の向上に期待というところです。

もちろん、私が知る範囲でもお客様によってはAmazon系やGAEなどの技術に長けていて、すごく活用されているというケースもあります。ただ、全体で見るとまだ低い割合なのかな、と思います。

◆ 今後の気になるところはPHPのPaaS

SI案件というとJava系が多いと思いますが、Web絡みになるとPHPの比重が高くなります。そういう点ではPHP系のPaaSは有名なものは見当たらないですね。注目としてはPHP Fog(http://www.phpfog.com/)が、Heroku的立ち位置を目指しているようなので今後どうなるか気になるところです。

※ 【追記】 AzureでPHPできるとご指摘いただきました。ちょっと調べてみます。

◆ まとめと中途採用募集のお知らせ

VMForceなどリストアップしていながら、あまり言及していないものがあり、すみません。また今度調査してみます。

最後に、フレクトはセールスフォースのプラットフォームやAWSを使ったインテグレーション事業を拡大中です。最新のPaaSを使った開発に興味のある人はぜひご連絡いただければと思います。採用エントリーは以下からです。お待ちしております。

http://www.flect.co.jp/recruit/

Herokuについて調べたことのまとめ

遅くなりましたが、あけましておめでとうございます。
フレクトの大橋です。

フレクトはセールスフォースを使ったシステムインテグレーション事業が
中心事業の1つだったりします。なので、年末年始はセールスフォースが買収した
Heroku(ヘロク)やRubyについて急に勉強を始めました。

忘れないように、年末に年始に勉強したことを備忘録的にまとめておきます。

＜1. どんなものか＞

乱暴な言い方をすれば、Google App EngineのRuby版です。（乱暴すぎる？）

もっとも違うのは、Ruby, Rails, PostgreSQL、memcachedなどオープンな技術の上に作られており、自分たちのLinuxサーバで動かしたアプリケーションをそのまま動かしやすい環境であることです。

Dynoと呼ばれるWebサーバプロセス数や、データベースの使用する容量などにより課金され、無料の範囲もありますが、Goolge App Engineよりは無料範囲が小さいと思っておいてよいと思います。

＜2. Hello, World的なものを動かすには＞

とりあえず、Hello, World的なものを動かしたくなります。動かすだけならば以下のすばらしい記事を見ればOKでした。

http://kuranuki.sonicgarden.jp/2009/05/rubypaasherokurails.html

デプロイなどはgitに連動していて、コマンドラインから簡単にできることが体感できると思います。

＜3. 構成コンポーネントとリクエストの流れ＞

以下の図にあるようなコンポーネントが基本コンポーネントで、
リクエストを順次処理していきます。

(※ http://heroku.com/how/architecture から図は引用しています)

まず、リクエストはnginxでできているリバースプロキシ(HTTP Reverse Proxy)に到達します。そこから、varnishでできているHTTP Cache層に来ます。

HTTP Cache層ではCache-Controlヘッダなどの内容によりコンテンツキャッシュを
返す機能があり、キャッシュヒットするコンテンツはここでレスポンスとしてユーザに戻します。

HTTP Cache層の次は、Routing Meshです。ここでリクエストを各Dynoにバランシングします。ここはHerokuがErlangで独自実装したミドルウェアのようです。

次にDyno Grid上での各Dynoで動くアプリケーションにリクエストが来ます。マルチテナントなので、Dyno Grid上にはいろいろな人、組織のアプリケーションが動いていますが、適切なDynoにリクエストが送られるよう、Routing Meshでルーティングされています。

なお、Dynoはアプリケーションサーバの1プロセスで、アプリケーションサーバThin(http://code.macournoyer.com/thin/)をベースにしているもののようです。Dynoは追加購入すれば、ユーザは柔軟に増やすことができ、2秒で起動するとのことです。

Dyno上のアプリケーションがリクエストを処理し、必要に応じてDatabaseやMemory Cacheにアクセスします。

Databaseは標準はPostgreSQLで、Memory Cacheはmemcachedが動いています。それぞれ、Dyno上で動くアプリケーションからアクセスできます。

＜4. 動かせるアプリケーション＞

Rackに対応したアプリケーションであれば動かせます。
RackというのはRubyにおけるWebサーバとフレームワーク(RailsやSinatraなど)との
インタフェースの役割を果たすライブラリです。詳しくは以下で。

http://gihyo.jp/dev/serial/01/ruby/0023

Rackに対応したフレームワークであれば、Heroku上で動くことになります。なので、Railsだけでなく、Sinatraなど他のフレームワークでも動くそうです。

＜5. 無料で使える範囲＞

1つのアプリケーション、1つのDyno、5MBのデータベース領域であれば無料で使うことができます。個人で勉強する分には十分かと思いますので、いろいろ試してみたいところです。

＜6. 魅力的なアドオンがたくさん＞

標準では、Dyno(アプリケーションサーバ)、Databaes(PostgreSQL)、Memory Cache(memcached)を使うくらいかもしれませんが、よく見てみるアドオンがたくさんあり、使いたくなるものもいろいろありました。個人的に使いたいと思ったものをいくつか列挙しておきます。

◆ Amazon RDS連携

　　EC2上で動いているので当たり前っぽいサービスですが、これは必要ですね。

　　　　http://addons.heroku.com/amazon_rds

 

 

◆ Exceptionトラッキング（通知）

　　エラー発生時にメールやTwitterで通知してくれるサービス。運用上こういう
　　仕組みを作るのは以外と面倒なので助かります。

　　　　http://addons.heroku.com/exceptional

 

 

◆ Solr

　　フレクトでは全文検索などやるときSolrを使っていたりするので、これは
　　魅力的です。外部のSolrサービスをWeb経由で提供している会社に
　　つながるみたいですが。
　　日本語辞書で形態素解析できるのか、など追加の調査は必要ですね。

　　　　http://addons.heroku.com/websolr

 

＜まとめと今後＞

Rails(Rack)アプリのためのPaaS、"Heroku"について勉強したことを備忘録的にメモにしました。

US-EAST以外にいつ展開されるのか、といったことや、セールスフォースが買収したことにより、どんなサービスが追加されるのか、など今後の動きが気になります。

一部、実験的にnode.jsに対応など始まっており、多言語展開するのかも気になるところです。

実戦投入まではもう少し勉強、検証が必要ですが、海外を中心に実戦投入された事例も多いので、フレクトでも経験積んで実戦で活かす機会が作っていきたいと思います。

しばらく研究してみて、今後、Herokuの記事もたくさん書けるようにしていきたいです。

では、本年もよろしくお願いします。