Heroku

2012年1月22日 (日)

Panda Streamを使ってWEBサイトに動画アップロード&エンコード&再生機能を作る

こんにちは、大橋です。
ひさしぶりの記事投稿になります。

今日はPanda Streamという動画アップロード、エンコード(変換)および再生機能を自分のサイトに組み込めるサービスを使ってみたので記事にしてみます。Panda Streamの公式サイトは以下です、あわせて見てみてください。

http://www.pandastream.com/


<Panda Stream概要&特徴>

Panda Streamを使うと、Youtubeみたいに動画ファイルをブラウザからアップロードして、アップロードしたファイルをブラウザ上で再生できる機能を簡単に既存Webサイトに組み込むことができます。特徴は以下です。

  1. すべての機能がREST API形式で提供されていて、Ruby, Python, PHPなどAPIを簡単にコールするライブラリも用意されている
  2. ブラウザからのアップロードはpandaのサーバ側に直接送信されるので、自前のサーバで動画アップ用にインフラ/ミドルなど構築をしなくてよい
  3. データのストア先はAmazon S3を使うので、ストレージを自前で用意する必要なし
  4. アップロード、再生するときのJavaScript, HTML,などサンプルが一通り用意されている。
  5. 多様なInputフォーマットからFLV, MP4(H.264), WebMなど主要な再生環境向けへの変化に対応。

名前はなんだかかわいいですが、できることはけっこうすごいですね。なにかと難しい、動画アップ、変換、が簡単にできちゃいます。HerokuのAdd-onにもなっているので、Herokuを使うときにも便利(←一部の人だけの恩恵かもですが・・・)。

<動画機能を利用するための流れ>

早速使っている前に、大まかな手順を確認しましょう。Panda Streamを使ってWebサイトに動画アップロード&再生機能を埋め込む手順は以下のようになります。

  1. Amazon Web Services(AWS)にサインアップしてAmazon S3を利用できるようにしておきます。
  2. PandaにSign Upします。
  3. CloudというS3のバケットに1対1で対応したエンコーディングした動画を管理するグループを作成。
  4. Panda StreamのAPI Access用のキーとCloud IDを取得。
  5. ここから本番。実際にWebサイトに組み込むためのプログラミングをします。


<実際にWebサイトに組み込むための前準備>

手順(1)〜(4)のCloud作成までは簡単なのでさらっと説明します。

まず、Amazon S3を用意しましょう。AWSのアカウントがなければ以下から申し込んで、Amazon S3を使えるようにしましょう。アップロードした動画やエンコード後の動画、および動画から抽出されたサムネイル画像はAmazon S3上に保存されます。

http://aws.amazon.com/jp/

次にPanda Streamのサイトへいってサインアップしましょう。

http://www.pandastream.com/

サインアップしたら、Home画面のメニューに「API Access」という項目があるので、そのリンクをたどると以下のような画面になります。

Pandaapikey

ここで、
 ・Access Key
 ・Secret Key
 ・API URL(api.pandastream.com)

があることを確認しましょう。これはPanda StreamのAPIを使うときに必要になります。

次にメニューの「Clouds」というメニューがありますのでここをたどり、「Create new cloud」をクリックし、Cloudを作成します。Cloudの名前とパーミッションおよびS3のバケット、Access Key、Secret Keyを設定します。すると、以下の画面のようにCloudが作成されるので、作成後に左上に表示されているIDがCloud IDというもので、この後、APIアクセスで使うので控えておきましょう。

Cloud_id

いろいろサインアップするものがあって大変ですが、これで準備完了です。


<WEBサイトに動画アップロード機能を埋め込む>

Panda Streamのサイトにサンプルコードがアップされているので、それを見たり、動かしたりするのが入門にはちょうどよいです。

http://www.pandastream.com/docs/sample_apps

ここでは、その中のエッセンスだけ抜き出して、アップロードから再生までどんなコードを書けばよいか解説していきます。

まず、アップロード画面のHTML/JavaScript側を準備します。
HTMLは以下のように記述します。actionの遷移先は適当に変えてください。
最初のhiddenはこのあと説明するJavaScriptによりアップロードに成功後に動画のIDが埋め込まれ、次の画面に遷移するときのパラメータになります。

 

   

   

 

JavaScriptはPandaが提供しているJavaScriptライブラリ、jquery.panda-uploaderを使います。jQuery本体を先に読み込んで、Pandaのアップローダーライブラリを読み込みます。

  
  

  


アップローダーの読み込み後、前準備で取得したPanda Stream用のaccess_key、cloud_idなどともにsignatureを書く必要があります。これはサーバサイドで値を作成します。サーバサイド用にはいろいろな言語用にクライアントライブラリがあるので、言語ごとのPandaライブラリを使うことで、signatureを取得できます。ライブラリは以下にあります。

http://www.pandastream.com/docs/client_libs

Ruby, PHP, Pythonなどのライブラリがあります。環境が整っていてよいですが、Java版やPerl版がなかったりもします。
たとえば、Pythonならば以下のような処理でJSON形式でsignatureなど取得できますので、JavaScriptに埋めてください。

panda = Panda(
    api_host='api.pandastream.com',
    cloud_id='Cloud ID',
    access_key='Panda API用のAccess Key',
    secret_key='Panda API用のSecret Key',
    )
python_access_details = panda.signed_params('POST', '/videos.json')
# 以下のようなJSONが取得できます。
#{'access_key': 'xxxxxxxxxxxxxxx', 'timestamp': '2012-01-19T15:01:43.268760+00:00', 'cloud_id': 'xxxxxxxxxxxxxxxxxxxx', 'signature': 'U8OOrnBlYekV3FjyyAIZj1H0kVZlAATn8O/uI07mEMI='}

ここまでのHTML, JavaScript, サーバサイドの処理を組み合わせて、アップロード処理が作れます。説明したパーツを組み合わせると以下のようにプログレスバーが出てくる動画アップロード機能が作れます。

Upload_progress

 アップロードが終わるとコンテンツはS3に登録され、Panda Streamのサーバ側でエンコーディング処理が始まります。同時に、HTMLにhiddenでpanda_video_idとしたところに、動画再生のためのIDがセットされ、フォームのアクション先にpanda_video_idがパラメータとなり画面遷移します。

アップロードされた動画はPanda Streamの画面でも以下のように作成したCloudのDashboardでエンコード中の動画が確認できます。

Dashboard


<WEBサイトで動画を再生する>

さて、アップロードされた動画はエンコードに多少時間がかかります。エンコードのフォーマットはPandaに作成したCloudごとにプロファイルを作成できます。デフォルトはmp4/h.264です。PandaのAPIを使ってエンコードの進捗が何パーセントかも取得できますが、それについては今日は省きます。

動画のエンコードが終わったら、PandaStreamのDashboard上でも再生できますが、アップロード時に取得できたpanda_video_idをパラメータにencodings APIを呼び出し、エンコードされたS3上のファイルパスを取得します。エンコーディングのプロファイルごとにファイルパスや拡張子、スクリーンショットのパスが取得できます。Pythonだと以下のようなコードで取得できます。

    # panda_video_idはアップロード時に取得したID。pandaはPandaクラスのインスタンス
    panda_encodings = json.loads(panda.get("/videos/%s/encodings.json" % panda_video_id))

    encoding = None
 
 # エンコーディングのプロファイルごとに取得できる
    for panda_encoding in panda_encodings:
        if panda_encoding['extname'] == '.mp4' and panda_encoding['status'] == 'success':
            encoding = {
                'id'     : panda_encoding['id'],
                'width'  : panda_encoding['width'],
                'height' : panda_encoding['height'],
                # 以下のようにすると動画のURLやスクリーンショットのjpegのURLが取得できる
                'url'    : "http://%s.s3.amazonaws.com/%s%s" % (’S3のバケット名', panda_encoding['id'], panda_encoding['extname']),
                'screenshot_url' : "http://%s.s3.amazonaws.com/%s_4.jpg" % ('S3のバケット名', panda_encoding['id']),
            }

取得したurlやscreenshot_urlをHTML上で以下のように埋め込みます。ここではHTML5で再生する例を示します。

サーバ側で取得したスクリーンショットのURLや動画ファイルのURLをそれぞれ埋め込めば再生できると思います。もちろん、エンコードが終わってからですが。

かんたんな使い方は以上になります。Panda StreamのDocumentにいろいろな情報があるので、ここから先はそちらを見るようお願いします。


<気になる価格体系>

そういえば、価格について触れないといけないですね。以下のページに記載がありますが、同時に処理できるエンコーダの数により価格が決まります。

http://www.pandastream.com/pricing_and_signup

フリー版はエンコーダは他の人とシェア、ファイルサイズの上限が10MBです。有料版は1つの専用のエンコーダ(dedicated encoder)あたり月間99ドルです。たとえば、3つのエンコーダならば397ドルです。エンコーダの数は同時にエンコードできる動画の数と考えてください。実際には占有できるCPU coreのようです。あと有料版はファイルサイズの上限が5GBのファイルの動画までエンコードできます。


<PaaS上でのプログラミング>

今回はPanda Streamという動画アップロード、エンコード、再生を実現するためのサービスの紹介をしましたが、こういった特定の機能を提供するサービスは動画のエンコードだけでもZencoder(http://zencoder.com/ )など他のサービスがあります。他にも画像変換、メール、PDF生成など、スクラッチで作ると手がかかる機能の実現が最近は外部サービスを使うことで可能になってきているようですね。

Heroku、DotCloudなどのPaaSにより、簡単にアプリケーションをクラウド上にデプロイできるようになりましたが、動画処理やサムネイル生成など特別な機能の実現をしようというときにこれまでと同じやり方ではできないものもあり、少し頭を悩ます部分です。

そういった問題への解決策がPanda Streamのようにアプリケーションの特定の機能を提供するサービス群なのかな、と思います。

クラウド環境でのプログラミングは主にWEB、アプリケーションサーバ用のCPU/DBを提供するHerokuなどのPaaSとその周辺を補強するサービス群を使いこなすことがポイントになるんだろうと思い始めています。

PaaSを使ったアプリケーション構築スタイルをこれから追求しないといけない分野ですね。


<まとめ>

Panda Streamという動画アップロード、エンコード、再生機能を簡単にWebサイトに組み込めます。

こういったサービスは他にもたくさんあるので、今後もたくさん試してみてこのブログ上で共有していきたいと思います。

Panda Streamを使ってWEBサイトに動画アップロード&エンコード&再生機能を作る

こんにちは、大橋です。
ひさしぶりの記事投稿になります。

今日はPanda Streamという動画アップロード、エンコード(変換)および再生機能を自分のサイトに組み込めるサービスを使ってみたので記事にしてみます。Panda Streamの公式サイトは以下です、あわせて見てみてください。

http://www.pandastream.com/


<Panda Stream概要&特徴>

Panda Streamを使うと、Youtubeみたいに動画ファイルをブラウザからアップロードして、アップロードしたファイルをブラウザ上で再生できる機能を簡単に既存Webサイトに組み込むことができます。特徴は以下です。

  1. すべての機能がREST API形式で提供されていて、Ruby, Python, PHPなどAPIを簡単にコールするライブラリも用意されている
  2. ブラウザからのアップロードはpandaのサーバ側に直接送信されるので、自前のサーバで動画アップ用にインフラ/ミドルなど構築をしなくてよい
  3. データのストア先はAmazon S3を使うので、ストレージを自前で用意する必要なし
  4. アップロード、再生するときのJavaScript, HTML,などサンプルが一通り用意されている。
  5. 多様なInputフォーマットからFLV, MP4(H.264), WebMなど主要な再生環境向けへの変化に対応。

名前はなんだかかわいいですが、できることはけっこうすごいですね。なにかと難しい、動画アップ、変換、が簡単にできちゃいます。HerokuのAdd-onにもなっているので、Herokuを使うときにも便利(←一部の人だけの恩恵かもですが・・・)。

<動画機能を利用するための流れ>

早速使っている前に、大まかな手順を確認しましょう。Panda Streamを使ってWebサイトに動画アップロード&再生機能を埋め込む手順は以下のようになります。

  1. Amazon Web Services(AWS)にサインアップしてAmazon S3を利用できるようにしておきます。
  2. PandaにSign Upします。
  3. CloudというS3のバケットに1対1で対応したエンコーディングした動画を管理するグループを作成。
  4. Panda StreamのAPI Access用のキーとCloud IDを取得。
  5. ここから本番。実際にWebサイトに組み込むためのプログラミングをします。


<実際にWebサイトに組み込むための前準備>

手順(1)〜(4)のCloud作成までは簡単なのでさらっと説明します。

まず、Amazon S3を用意しましょう。AWSのアカウントがなければ以下から申し込んで、Amazon S3を使えるようにしましょう。アップロードした動画やエンコード後の動画、および動画から抽出されたサムネイル画像はAmazon S3上に保存されます。

http://aws.amazon.com/jp/

次にPanda Streamのサイトへいってサインアップしましょう。

http://www.pandastream.com/

サインアップしたら、Home画面のメニューに「API Access」という項目があるので、そのリンクをたどると以下のような画面になります。

Pandaapikey

ここで、
 ・Access Key
 ・Secret Key
 ・API URL(api.pandastream.com)

があることを確認しましょう。これはPanda StreamのAPIを使うときに必要になります。

次にメニューの「Clouds」というメニューがありますのでここをたどり、「Create new cloud」をクリックし、Cloudを作成します。Cloudの名前とパーミッションおよびS3のバケット、Access Key、Secret Keyを設定します。すると、以下の画面のようにCloudが作成されるので、作成後に左上に表示されているIDがCloud IDというもので、この後、APIアクセスで使うので控えておきましょう。

Cloud_id

いろいろサインアップするものがあって大変ですが、これで準備完了です。


<WEBサイトに動画アップロード機能を埋め込む>

Panda Streamのサイトにサンプルコードがアップされているので、それを見たり、動かしたりするのが入門にはちょうどよいです。

http://www.pandastream.com/docs/sample_apps

ここでは、その中のエッセンスだけ抜き出して、アップロードから再生までどんなコードを書けばよいか解説していきます。

まず、アップロード画面のHTML/JavaScript側を準備します。
HTMLは以下のように記述します。actionの遷移先は適当に変えてください。
最初のhiddenはこのあと説明するJavaScriptによりアップロードに成功後に動画のIDが埋め込まれ、次の画面に遷移するときのパラメータになります。

 

   

   

 

JavaScriptはPandaが提供しているJavaScriptライブラリ、jquery.panda-uploaderを使います。jQuery本体を先に読み込んで、Pandaのアップローダーライブラリを読み込みます。

  
  

  


アップローダーの読み込み後、前準備で取得したPanda Stream用のaccess_key、cloud_idなどともにsignatureを書く必要があります。これはサーバサイドで値を作成します。サーバサイド用にはいろいろな言語用にクライアントライブラリがあるので、言語ごとのPandaライブラリを使うことで、signatureを取得できます。ライブラリは以下にあります。

http://www.pandastream.com/docs/client_libs

Ruby, PHP, Pythonなどのライブラリがあります。環境が整っていてよいですが、Java版やPerl版がなかったりもします。
たとえば、Pythonならば以下のような処理でJSON形式でsignatureなど取得できますので、JavaScriptに埋めてください。

panda = Panda(
    api_host='api.pandastream.com',
    cloud_id='Cloud ID',
    access_key='Panda API用のAccess Key',
    secret_key='Panda API用のSecret Key',
    )
python_access_details = panda.signed_params('POST', '/videos.json')
# 以下のようなJSONが取得できます。
#{'access_key': 'xxxxxxxxxxxxxxx', 'timestamp': '2012-01-19T15:01:43.268760+00:00', 'cloud_id': 'xxxxxxxxxxxxxxxxxxxx', 'signature': 'U8OOrnBlYekV3FjyyAIZj1H0kVZlAATn8O/uI07mEMI='}

ここまでのHTML, JavaScript, サーバサイドの処理を組み合わせて、アップロード処理が作れます。説明したパーツを組み合わせると以下のようにプログレスバーが出てくる動画アップロード機能が作れます。

Upload_progress

 アップロードが終わるとコンテンツはS3に登録され、Panda Streamのサーバ側でエンコーディング処理が始まります。同時に、HTMLにhiddenでpanda_video_idとしたところに、動画再生のためのIDがセットされ、フォームのアクション先にpanda_video_idがパラメータとなり画面遷移します。

アップロードされた動画はPanda Streamの画面でも以下のように作成したCloudのDashboardでエンコード中の動画が確認できます。

Dashboard


<WEBサイトで動画を再生する>

さて、アップロードされた動画はエンコードに多少時間がかかります。エンコードのフォーマットはPandaに作成したCloudごとにプロファイルを作成できます。デフォルトはmp4/h.264です。PandaのAPIを使ってエンコードの進捗が何パーセントかも取得できますが、それについては今日は省きます。

動画のエンコードが終わったら、PandaStreamのDashboard上でも再生できますが、アップロード時に取得できたpanda_video_idをパラメータにencodings APIを呼び出し、エンコードされたS3上のファイルパスを取得します。エンコーディングのプロファイルごとにファイルパスや拡張子、スクリーンショットのパスが取得できます。Pythonだと以下のようなコードで取得できます。

    # panda_video_idはアップロード時に取得したID。pandaはPandaクラスのインスタンス
    panda_encodings = json.loads(panda.get("/videos/%s/encodings.json" % panda_video_id))

    encoding = None
 
 # エンコーディングのプロファイルごとに取得できる
    for panda_encoding in panda_encodings:
        if panda_encoding['extname'] == '.mp4' and panda_encoding['status'] == 'success':
            encoding = {
                'id'     : panda_encoding['id'],
                'width'  : panda_encoding['width'],
                'height' : panda_encoding['height'],
                # 以下のようにすると動画のURLやスクリーンショットのjpegのURLが取得できる
                'url'    : "http://%s.s3.amazonaws.com/%s%s" % (’S3のバケット名', panda_encoding['id'], panda_encoding['extname']),
                'screenshot_url' : "http://%s.s3.amazonaws.com/%s_4.jpg" % ('S3のバケット名', panda_encoding['id']),
            }

取得したurlやscreenshot_urlをHTML上で以下のように埋め込みます。ここではHTML5で再生する例を示します。

サーバ側で取得したスクリーンショットのURLや動画ファイルのURLをそれぞれ埋め込めば再生できると思います。もちろん、エンコードが終わってからですが。

かんたんな使い方は以上になります。Panda StreamのDocumentにいろいろな情報があるので、ここから先はそちらを見るようお願いします。


<気になる価格体系>

そういえば、価格について触れないといけないですね。以下のページに記載がありますが、同時に処理できるエンコーダの数により価格が決まります。

http://www.pandastream.com/pricing_and_signup

フリー版はエンコーダは他の人とシェア、ファイルサイズの上限が10MBです。有料版は1つの専用のエンコーダ(dedicated encoder)あたり月間99ドルです。たとえば、3つのエンコーダならば397ドルです。エンコーダの数は同時にエンコードできる動画の数と考えてください。実際には占有できるCPU coreのようです。あと有料版はファイルサイズの上限が5GBのファイルの動画までエンコードできます。


<PaaS上でのプログラミング>

今回はPanda Streamという動画アップロード、エンコード、再生を実現するためのサービスの紹介をしましたが、こういった特定の機能を提供するサービスは動画のエンコードだけでもZencoder(http://zencoder.com/ )など他のサービスがあります。他にも画像変換、メール、PDF生成など、スクラッチで作ると手がかかる機能の実現が最近は外部サービスを使うことで可能になってきているようですね。

Heroku、DotCloudなどのPaaSにより、簡単にアプリケーションをクラウド上にデプロイできるようになりましたが、動画処理やサムネイル生成など特別な機能の実現をしようというときにこれまでと同じやり方ではできないものもあり、少し頭を悩ます部分です。

そういった問題への解決策がPanda Streamのようにアプリケーションの特定の機能を提供するサービス群なのかな、と思います。

クラウド環境でのプログラミングは主にWEB、アプリケーションサーバ用のCPU/DBを提供するHerokuなどのPaaSとその周辺を補強するサービス群を使いこなすことがポイントになるんだろうと思い始めています。

PaaSを使ったアプリケーション構築スタイルをこれから追求しないといけない分野ですね。


<まとめ>

Panda Streamという動画アップロード、エンコード、再生機能を簡単にWebサイトに組み込めます。

こういったサービスは他にもたくさんあるので、今後もたくさん試してみてこのブログ上で共有していきたいと思います。

2011年8月26日 (金)

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

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

2011年1月27日 (木)

セールスフォース、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/

セールスフォース、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/

2011年1月10日 (月)

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. 構成コンポーネントとリクエストの流れ>

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

Herokuarch

(※ 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の記事もたくさん書けるようにしていきたいです。

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

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. 構成コンポーネントとリクエストの流れ>

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

Herokuarch

(※ 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の記事もたくさん書けるようにしていきたいです。

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

採用情報

株式会社フレクトでは、事業拡大のため、
・Salesforce/Force.comのアプリケーション開発
・HerokuやAWSなどのクラウドプラットフォーム上での
Webアプリケーション開発
をする、エンジニアを募集中です。

未経験でも、これからクラウドをやってみたい方、
是非ご応募下さい。

フレクト採用ページへ

プロフィール

執筆者:大橋 正興
株式会社フレクト 取締役

【得意分野/業務分野】

B2Cのサイト開発を主な業務領域とするシステムエンジニアです。あと、Salesforce.com認定デベロッパーです。AW、Salesforce、システム基盤構築・運用、サーバ/インフラ構築・運用が今の注力分野です。

【簡単な経歴】

埼玉県所沢市出身。1979年生まれ。大学からSFC。修士(政策・メディア)。ソニーエリクソンで携帯電話のアプリ・ミドル の先行開発に従事したあと、フレクトに参加。2009年6月より取締役。ベターホームレシピの開発ディレクション等、B2Cサイト構築においてアプリ開発やインフラ構築などに従事中。

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、セールスフォースパートナーです。
セールスフォースパートナー
また、heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。

Twitter

頻繁ではないですが、ときどきツイートしています。 お気軽にフォローしてください。

2024年12月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
ブログ powered by TypePad