ラベル AppEngineJava の投稿を表示しています。 すべての投稿を表示
ラベル AppEngineJava の投稿を表示しています。 すべての投稿を表示

2013-12-13

業務システムにおけるインフラ構築をGAEでやるとどうなるか?その1

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1』が一部の方に好評でしたので、調子にのって、GAEでインフラ構築するとどうなるのか、従来の構築手法との比較で記載していこうと思います。
ちょっと繰り返しになっている部分もあるかも知れませんが。ご容赦ください。
全何回になるか分かりません。

何は無くとも要件定義

まず、システム開発の要件定義からですよね、やっぱり。
で、要件定義の中ってぶっちゃけあんまりインフラ的な話が出てこないことが多いです。
明らかに厳しめなものであることがわかっているものを除き(youtubeのようなものとか、証券取引システムとか)、ですね。
このフェーズでの話はやっぱり機能要件に走りがちで、非機能要件の洗い出しまでしっかりやることは結構まれです。で、それでも特に問題ないっちゃないでした、ある程度のパフォーマンスは最低限出せることが多かったから、ですね。
このフェーズについては特にGAEでも従来の構築手法でも特に大きく変わりがないように思います。
決めなきゃいけないのは、規模感がわかるものやパフォーマンス要件、特殊要件(ラインプリンタとか内部とのIF要件とか)の確認になります。
後はGAEが決まっている場合はどれだけGAEに合わない要件を先に切っておくか、これは必要かも知れません。(後述)

当然の基本設計

さて、要件定義が終わったら当然基本設計です。
ここで大きくGAEと従来型のインフラ構築の差が出て来ます。

GAEの場合

GAEでの手法の場合、ここで大きく舵を切ります。
要件定義で定義された要件がGAEで満たせるのかどうか?をざっと見ます。

あり得そうなポイントは

-Private環境とIFが取れるか?
 →IP制限の問題とか、ポートの問題とか。まぁ最近は問題にならないでしょう。
-極端に短いTAT(ターンアラウンドタイム)が定義されてないか?
 →本来はまぁ要件定義の際に切れる場合は切っておく、です。
-特殊機器等との特殊なポートでの連携がないか?
 →最近それほど私の周りでは聞きませんが、ある場合は間に何か挟んで解決出来ないか、検討。
-セキュリティ要件
 →これも最近ほとんど問題ないと思いますが、そもそも外に出しちゃダメとかって話だとアウト。

このくらいじゃないでしょうか?
これに引っかからなければ基本的にGAEでOKってことで、後は以下くらいを決めればOKです。
-フレームワークどうする?
 →弊社の場合ほぼIZANAMI一択
-支払い方法は?
 →うちでサポート含め代行するか、顧客アカウントで支払いしてもらうか?
-外部IFがある場合はちょっと調整

以上。


従来のインフラ構築手法の場合

えー、これに対してですね。通常のインフラの基本設計はと言うと。
都合上、データセンタ(サーバの置き場所)は既存の環境に空きラックがある前提とします。それはそれで別の話なのですが、実際はそれも当然考慮が必要です。

サイジング

だいたいの処理量の概算等からサーバ規模を見積る、という作業です。
大規模の場合だと、ベンダーさんにヒアリングシートを出して貰って、回答。1,2週間待って回答が帰ってくる、修正して・・・・というのを繰り返す可能性あり。

構成設計

サイジングと合わせて、主にNW構成を検討して、既存の環境に合うように機器含めて整理。
サイジングの結果を持って、各種論理サーバを並べて行く。
上記の論理サーバを物理サーバにどうマップするか考える。
OSを何にするか考える。
MWを何にするか考える。
各MWをどのサーバに載せるか考える。バージョン、OS等の組み合わせでサポートがされているかベンダーに確認調整する。
また、上記の単純な配置からさらに、仮想化した場合のライセンスの考え方等を含めどのように配置するのがパフォーマンス上良いか、ライセンス費用的に良いか、運用上の境界の取り方として問題ないかのバランスを取って決定する。

費用見積り

上記がだいたいできたら、ベンダーさんに見積りをお願いする。
見積りには以下を含める必要がある。
-HW費用
-MW費用
-OS費用
-SI費用(HWの設置費用、OS設計・導入費用、MW設計・導入費用が必要)

上記での調整

費用見積り等をもって、各種調整を行い、出し入れを行う。まぁ、それなりの規模感だとまず一発で決まるなんてことはありませんので。。。

このマネジメント

忘れちゃイケない、上記の作業をするにあたっては他の業務要件の出し入れなどの調整含め、スケジュール調整やベンダコントロールが必要になってくるのでマネジメントが必須になります。これもコストとして上乗せになる感じです。



基本設計まとめ

いかがでしょうか?基本設計のフェーズにおいてはとんでもない作業量の差異が生じます。
これちなみに、通常のIAASクラウド(EC2など)だとHWとOSの一部の部分に関しては非常に楽になりますが、それ以外は必要になる部分です。
私の感触ですが、縦軸にレイヤ、横軸に作業を並べると以下のような区分になると思います。
設計見積導入構築テスト
MW必要必要必要必要必要
OS簡易簡易不要必要必要
HW簡易簡易不要簡易必要
NW簡易簡易不要簡易必要

ここで、「簡易」としたのはある程度簡単なGUIからの操作等で出来ようなレベルのもので。「導入」ってのはインストールする、というだけの部分で、「構築」はそれがちゃんと連携取って動くように細かい設定を行う、という意味合いです。
これ、基本的にGAEだと全部まるっとほぼ「不要」になります。

作業量=コストであり時間ですので、ここで決定的な差が生じます。
この決定的な差は運用フェーズにも引き継がれることになります。


長くなったので次は詳細設計フェーズから続けます。
今回から一応ちゃんと見出しを設定してみました。見やすくなったかしら?
頑張って表なんかも書いてしまいました。
しかし、この表、なんとスプレッドシートからコピペ一発でした!びっくり。


2013-12-04

apps-gaeのお薦めコンテンツ

さて、今回は弊社で運用しておりますapps-gae上のお薦めコンテンツをご紹介したいと思います。

EC2とGCEのDisk I/O比較
必読です!
色々なインスタンスタイプ別に調査してみました。
結構たくさんデータを取ったので、時間がかかりましたが、非常に面白いと思います。
この結果からすると圧倒的にGCEの方がお薦めと言うことになります。

Google App Engine Modules のScalingを試す
24時間までは正しく動くことを確認しました。バッチ処理等でもまぁ十分な時間動かせると言うことのようです。


たった1つのCloud SQLインスタンスで複数のWordpressを動かす
まぁ要は複数のGAE環境から1個のCloudSQLインスタンスだけを使って複数サイトをホスト出来るか、というところです。
GAE部分はある程度までは全て無料で1個のCloudSQLにだけ費用を払えば良いので、非常に安く運営出来そうです。SEO的にも良いので弊社は今後色々WordPressOnGAEでサイト展開していこうかなと思います。apps-gaeもGoogleサイツで今ひとつ見栄えとかがしっくりこないので、WordPressOnGAEにしてしまおうと思っています。

Google App Engine コンソールの小技
これはGAE使って開発されている方は必読というか、必須のツール作りました。
是非入れてみてください。

GAE負荷テスト その2「吉積情報株式会社の旧トップページ」
弊社のコーポレートサイトのトップページを無料範囲でどれだけ表示出来るか、という検証です。
結果、15万PVくらいはイケそうと言うことで。1日あたりなので大概の企業のコーポレートサイトはこちら(GAE)で良いのでは?と思います。

Datastoreモデル変更の影響調査
Datastoreのモデルにプロパティを追加、削除したりした時の挙動を詳細に調査してみてます。ちょっと難しめですので、開発を真面目に検討されてるSEの方のみ向けかなと思います。

いかがでしょうか?
結構色々と調査してます。一応目指しているのは昔非常にお世話になった、「おら!オラ!Oracle - どっぷり検証生活」です。

今後も順次記事は追加して行きますので、是非チェックしてみてください。
何かこれを調べて欲しいとかのお題もいただけると嬉しいです。

2013-11-29

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その2


業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1』の続きですので、未だお読みで無い方はまずそちらをお読みください。

インフラに関わる費用としてざっくり以下がありますが、このAについてはお話しました。
>A.インフラ自体の購入・保守サポート費用
>B.上記の組み上げ・保守費用
>C.運用管理設計、導入費用・保守費用

Bについて書きますと。
ここはまさにSIerの構築ノウハウをベースに、必要な性能を達成させるべく購入した製品を組み合わせ、設定して、テストする、という一連の作業になります。EC2とかIAASのサービスを使っても通常このレイヤの作業は必要になります。
確かに、昔は(10年くらい前とか)色々なサービス毎に異なるSLAを設定し、それぞれに適切な構成、というのがあったしそうする意味もあったのですが。
ここ数年で言うと、業務システムに求められる要件て同じで、私がインフラ構築を提案する時にふと全く同じ事をしていることに気づきました。

簡単にいうと以下のようなものです。分かる人だけ分かればいいですが。
VMWareをベースにブレードを並べてリソースプールを作成して、DBサーバだけ別途4Uくらいのを購入、ストレージはそこそこ高価なものにしておき筐体単位でのバックアップは基本取らない(お金に余裕があれば2台構成にしてDR)、代わりに筐体内では全て冗長化される構成のストレージを購入。
DBMSにOracleを入れ、ストレージの機能との組み合わせでスナップショットを取って、テープにゆるりとバックアップしていく。
監視は監視サーバ・MWを入れて、JP1等を入れてスケジュール連携する。

これ、ほぼ全く同じで無いですか?
また、ここに関わるコストも馬鹿になりません。監視サーバとかJP1とかってそれなりに高価ですし、ストレージの冗長化とかの設計とかストレージの論理領域を切ってもらったり、ストレージの冗長化とかってびっくりするほど高価なSI費用を請求されます。(特殊技能だからでしょうけど)
繰り返しになりますが、これもGAEだと不要です。


私は行くプロジェクト毎に毎回9割方同じ設計書を書いて、ベンダーさんに組み上げて貰ってテストして。。。。
ばかばかしい、と。
このレイヤに価値がある時代は終わりました。
システム(インフラ)に求められる要件は、
-止まらない
-データなくならない
-スケーラビリティが確保されている
-セキュアである(データを持って行かれない)
-アプリの変更が容易
これで全てだと思います。皆ほぼ同じです。で、既にそのインフラはあるのです。
GAEではこのレイヤも全く必要ありません。これがEC2等の通常のIAASと大きく異るところです。


Cについて
監視やバックアップの仕組み、またそこで障害発生時やパッチ適用時に発生するコストです。
ここについては、GAEでもある程度(構築部分以外の運用)は必要になります。

運用って例えば、1回何らかエラーが吐かれたとしたら、
その調査を行い、再現性があるのか無いのか、リスクは?等の判断をして、対処の優先順位(対応しない)を決めて、
他の仕様変更とかと合わせてリリース計画を立てて、利用者側に告知して、(場合によっては夜間)リリース作業する。
という流れを全て調整してやってかなきゃいけませんが。

が、インフラレイヤの障害に対応する必要がほぼなくなりますので、その分まるまる対処必要無くなります。
実際、3年くらい全くノータッチで動いているものも弊社の管理している中にはあります。(そのぐらい通常システムでもあり得ますけどね)

まぁその部分はそれほどGAEと他とで違うってことは無いように多みます。
逆にAPIにはある程度依存するのでその変化の速度等が通常の枯れたフレームワーク等と比べると多いかも知れないので、それには対応する必要があります。
そこの点は敢えて書いておきますがデメリットになり得ます。

とは言え、総じてA,B分のコスト減がかなり大きいので、私としては構築難易度やAPI等の変更の速度が早いことに対する対処はプログラム上の工夫でかいけつしてしまって、インフラレイヤ迄クラウドで吸収する、という形で圧倒的な低コストが実現出来ると考えて居ます。

以上、インフラのコンサルタントとしての視点から見たGAEで安くなる理由でした。
次回は、apps-gaeの興味深い記事について私の目線から幾つか紹介させていただこうと思います。

2013-11-25

業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1



先週書いた、『GAE(Google App Engine)での費用見積りについて:業務システムの場合』という記事が非常に好評を頂いたようで、アクセスが急増しました。
ありがとうございます。今後も出来る限りの内容を公開して、GAEでの業務アプリ開発を盛り上げて行ければなと思います。

さて、本日はその記事中でも触れた、表題のお話をしたいと思います。
私のこれまでの経験上、インフラの費用については大きく分けて以下の3点を考慮する必要があります。

A.インフラ自体の購入・保守サポート費用
 →HW/MW/OSの購入代金と保守サポート費用です。当然ですね。

B.上記の組み上げ・保守費用
 →上記を業務要件に合わせた形で組み上げて、テスト含めて動作・保証する費用です。SI費として計上されることが多いですが、しっかりテストすると結構馬鹿になりません。

C.運用管理設計、導入費用・保守費用
 →バックアップ・リカバリや監視等の仕組みを構築、導入し、障害時の切り分けルールやワークフロー等を整備し、それを運用して行く費用です。
  これには、障害レベル・レイヤ(HW層、データセンタ層、OS層etc)に応じたワークフロー定義や障害が発生した際にどこまで検証するのかなどの定義とその都度の確認等の時間も含まれます。

ざっくり私の感覚で分けるとこんな感じになります。
一口に「インフラ」と言うと広義にはフレームワーク定義や実装とその業務システム開発チームへの展開まで含めて呼ぶ場合もありますが、ここでは実行・開発・運用環境を担保する、という所までとしておきます。

ここにおいて、個別にGAEとオンプレとでの費用イメージを比較して行きますが。
私のざっくりしたオンプレでの費用感のイメージは非常に大雑把ですが、
A:B:C=5:3:3 くらいの感触です。
(値引きをどこで頑張るかとか、何年運用するかによってもかなり誤差がありますが)

1点目のAについて、まずはGAEにおいては初期の購入費用は全く不要ですね。ここが非常に強調されるところでもあります。

業務システム開発においてどのようなHWを用意するかというと。
まず、通常のオンプレのシステムの平均CPU利用率なんかは10%を切るのはザラであります。ある程度見積りがうまく行ったとしてもシステム屋さんの考え方だと40%を超えるともう追加が必要という認識に至ります。最近は仮想化前提としても4割を超えるとリソース追加しようと言う話が出てくるはずです。要は必要なリソースの何倍かの箱を用意するということになります。
また、業務システムにおいては冗長構成を取る部分に非常に費用がかかります。
余剰な性能の担保+冗長構成が必須、の2点を考えるだけでどれだけAの費用が業務システムで過剰に必要になるかがわかると思います。
GAEは利用した分だけしか請求が来ません。冗長化についてのコストはその中に完全に含まれていますが、おそらく全体で共同担保しているという設計の関係上個別に見たらほぼゼロに限りなく近いレベルの冗長化コストなのでは無いでしょうか。

また、ここで運用設計とも絡んで来ますが、仮想化してリソースプール化するのは良いのですが、考えなきゃイケないのが稼働のインスタンスをどのように分割するか、です。
一般的に業務システムにおいてはその責任分界を非常に厳密に仕切りたがることが多いです。作る所管が違うとなおさらです。なので、非常に小さなリソースしか必要無いシステムでも責任分界上そのまま別のOSである必要が出てきます。(Tomcatあいのりで全然良いじゃん!ってものでも)
仮想化して気軽に出来るようになってるので、なおさらその傾向は高いと思います。
そうすると必要になってくるのが、じゃぁそのOSは誰が管理すんの?パッチ誰が当てるの?という話です。
GAEでは勿論いくつでも必要に応じてapp-idを作れますが、そこに付随する追加コスト(運用保守料)は一切ありません。何ならapp-idを分ければ分けるだけ無料枠が増える格好になります。

ちょっと長くなって来たので、B,Cの観点については次回にしたいと思います。

ちなみに、GAEの無料枠でどこまで使えるのか、という記事がapp-gaeにあります。


2013-11-19

GAE(Google App Engine)での費用見積りについて:業務システムの場合


GAEの導入にあたって良くある質問の費用見積りについてです。

弊社で良くやる方法でして、これが100%ではありませんが概ね問題無いというものですが、
参考になればと言うことでまとめてみます。

まず、前提としては業務システムであるということで、特徴として。
-ユーザ数は少なめ
-利用量は人・業務によって多かったり少なかったり幅広い
-可用性は結構必要
-アクセス時間は結構偏る

という所が言えると思います。

この場合に弊社でGAEの利用料を見積もる場合には以下のステップで行います。


  1. 業務毎に仮の業務量を調べる勤怠登録は修正も想定して一人が必ず1日1.3回(月30回とか)、管理者は月に2回DLを行う。
  2. 各業務をこなすのに必要なトランザクションを仮置きする
    例えば、勤怠の1回の登録するにあたり全てAJAX通信で書き込み3回、読込5回とする。
  3. 上記トランザクションあたりのDataStore ReedとWriteを仮置きする
    これはモデル設計にもよりますが、1transあたり10回とか20回とか、そういう数字になると思います。
  4. 上記をベースに1トランあたりのオンライン起動時間を見積り
    1処理あたりのmsecを概算する。
  5. 1業務あたりのデータストア量を見積もる
    これはメインのデータ量平均に対して3~5倍くらいを見ておく(Indexやログ等)ようなイメージです。
  6. 保存期間の仮置き
    無限に保存するとすると無限になってしまうので、取り敢えず直近2,3年でみた時、とかそういう形で定時することが多いです。
  7. 個別要件での調整
    例えばメール送信システムの場合はメール送信数が跳ね上がるのでそれは個別に盛り込みますし、SearchAPIやCloudStorageについては別途見積ります。
  8. 上記に課金額を入れて計算
    細かい所は省きますが、後は上記で見積もった量に対して課金額を入れて行きます。
  9. ざっくりその他を倍から3倍として乗っけます
    データDL量とか色々他にもあるんですが、それらはまぁ上記の見積りの倍から3倍って所でまずはざっくりといってしまいます。ここを精緻にやるのは神様でも無理でしょう。
  10. これまでの経験、近しいシステムの現況と比べての微修正
    ある程度近しいPVとか想定される業務に近い既存システムとユーザ数や業務数等を考慮してマスで一応大きく違わないかチェック・微修正を行う



結局これまでの経験からはFrontEndの時間、DataStore Read/Write数、DataStore量、DLデータ、あたりが大半の課金金額を締めることになるので、主な部分を見積もって、それ以外は倍も行かないでしょうという経験則で出してしまいます。

勿論場合によってはもっと精緻にやってもいいでしょうし、稼働・テストしつつ見直しをするというのも時間と手間があれば是非やるべきだとは思います。

が、現実的には業務システムの場合上記で見積ると概ね相当低い金額になりますが、おそらくほぼそれで越えてしまうことは無い(概ね倍程度バッファ見てるので)ので問題にならないことの方が多いです。

以上、簡単ですが、当社で実施している見積りノウハウになります。

当社ではある程度ほぼ全てのシステムをIZANAMIフレームワーク化しているため設計・開発手法を似ているので、過去事例との比較がある程度容易・有意になる、と言った特徴があると思います。

こういった見積りだけ、などGAE導入の段階でお困り・お悩みの方へのサポートとして、当社でも『GAE導入支援サービス』として提供出来ますので、是非ご相談ください。


次回は何故GAEでのインフラ費用が通常(オンプレミス)より安くなるのか、ってところを考察してみようと思います。
→2013年11月25日公開『業務システムにおいてGAEでのインフラ費用が通常(オンプレミス)より安くなる訳:その1



2012-10-11

Gartner SYMPOSIUM ITxpo 2012にて、弊社のGoogle Apps / Google App Engineの事例が紹介されました

 ガートナー社をご存知でしょうか?ガートナー社と言えば、企業のIT戦略及び投資について最善の決断を下せるよう、テクノロジ面からのアドバイスを提供する、業界最大規模の独立したITリサーチ&アドバイザリ企業として非常に有名な会社です。私も、良く提案資料の数字の根拠などに、ガートナー社の調査結果を利用しています。

 そのガートナー社は年に一度、CEO、CIOをはじめ、企業のIT戦略や投資にかかわる経営者や、IT部門の責任者、IT投資・導入に関わるすべての意思決定者を対象に、シンポジウムを開催しています。今年は、10月3日から5日まで、ホテル グランパシフィック LE DAIBAにて、「ITリーダーよ、時機(とき)を逃すな」というテーマで、Gartner Symposium/ITxpo 2012が開催されました。

 なんとそのシンポジウムの中で、吉積情報のGoogle Apps / Google App Engineの事例が紹介されました。幸いなことに、このシンポジウムにご招待頂きましたので、シンポジウムの様子と合わせてご紹介いたします。

エントランスの様子です。心地良い緊張感と熱気に包まれた会場でした。

4ホールぶち抜きのメイン会場の様子です。
この30分後には、会場は人で埋め尽くされてました。

 初日の基調講演では、「Nexus is next generation of computing」というコンセプトを元に、次の時代のコンピューティングに欠かせない要素として、クラウド、ソーシャル、モバイル、インフォメーションという4つのキーワードを、ガートナー社独自の鋭い視点で紹介がありました。

 Google Appsの導入事例としてもお馴染みのガリバーさんが、タブレットを利用して業務を効率化しただけでなく、紙とPCに縛られていた業務から脱却し、ワークスタイルに変革をもたらした事例としても紹介されており、私としては非常に興味深かったです。

 3日間で、100近いセッションが行われ、私もさすがに全ては聞けませんでしたが、興味のあるセッションに幾つか参加させいて頂き、普段はGoogle関連の情報収集に終始して狭くなりがちな視野を大きく広げる良い機会となりました。


 弊社の事例についてはと言うと、3日目に行われた、リサーチディレクター志賀嘉津士様の「Google AppsとOffice365のどちらを選ぶべきか」というセッションで取り上げて頂きました。私も、Google Appsを検討中のお客様から、Office365との機能比較などのお問い合わせを受けるのですが、まさにどちらにするか比較検討をされているお客様向けに、どう言う基準で選定を進めて行けばいいのかを、プロの目線からアドバイス頂く内容でした。

 ちなみに志賀様は、アプリケーション・リサーチ・チームで、情報活用、情報共有分野、およびインターネット関連市場動向をウォッチされており、グループウェアや電子メール、コラボレーション・ツールに関するリサーチを専門とされております。
 セッションでは、Office365とGoogle Appsそれぞれの特徴を説明した上で、
   ・自社の方向性がOffice365とGoogle Appsのどちらに適しているかを判断する
   ・その上で、差別化のポイントとなるリセラー、ソリューションベンダーを有効活用する
   ・導入したいソリューションベンダーの実力を精査する
 ことが導入を成功させる鍵になるという提言がされているのですが、その中で弊社は、Google Apps側のベンダーの例としてご紹介いただきました。
 志賀様に特別の許可を頂きましたので、資料を掲載致します。


   クールベンダー研究にて、弊社の繋吉(つなよし)シリーズを紹介頂いております。


最近のセミナーでご紹介させて頂いております、リーバイ・ストラウス・ジャパン様での、Google App Engineを利用した商品発注システムの構築事例も、先進的な取り組みとしてご紹介頂きました。

 事例として紹介頂くのは、本当に嬉しい限りですね。これからも、こうした事例をどんどんご紹介して頂けるよう、また弊社としても先進的な事例を紹介できるよう、Google Apps / Google App Engineでの実績を積んでまいります!社内システムのクラウド化に本気で取り組みたい企業のご担当者様からの問い合わせ、お待ちしております!
 

2012-09-27

日経SYSTEMS10月号に掲載されました

 今月号(2012年9月26日発売の10月号)の日経SYSTEMSで、「テクノロジーのかたち クラウド連続シリーズ (3)」と題してGoogle App Engineが特集されてます!

 こういった記事をみて興味を持ってくれる人が増えて、もっともっとGoogle App Engineが広まるといいですね。

 そしてなんとなんとこの記事には、、弊社の技術部部長、塩瀬のコメントも掲載されてます!

 「GAEを利用したシステムインテグレーションを手掛ける吉積情報の塩瀬悠樹氏(技術部剖長)は、ある顧客の業務システムを開発した際、テスト時にDatastoreのテーブルのデータとクエリー結果に食い違いが生じ、原因の追求に追われたことがある。データ登録直後のクエリー結果に、古いデータが返されていたのだ。」





  続きは書店にてご確認ください!

2012-08-29

グーグルのクラウドリソースサービスについて


ずいぶーん、久しぶりの投稿になってしまいました。
暑すぎですね、最近。

さて、本当はGoogleI/Oに行った直後に書きたかったのですが、今更ながら充実してきたGoogleのクラウドリソース周りのサービスについてI/Oでのヒアリング等含めた所感を整理しておきます。

それぞれについて今後もう少し評価出来ればなぁと思っております。


・Google Apps Engine
もうあまり解説不要かも知れませんが、既に正式リリースからもうすぐまる1年となる、スクラッチ開発用のシステム基盤です。
ミドルウェア層まで提供されるため、開発者及び保守担当者はプログラムロジック部分のみに
注力出来、システムのTCOを大幅に下げる見込みがあると考えております。
また、スケーラビリティにも非常に優れており、利用量に変動のあるシステムにも最適。
災害対策もバッチリというものです。
唯一問題は、開発の難易度が高い(JavaやPythonを利用可能だが、癖が少しある)、
故に移植性も高く無い。という点でしょうか。
弊社ではこの開発難易度を下げるための工夫やノウハウを抱負に蓄積しております。

Google Cloud SQL
参考記事:http://www.itmedia.co.jp/news/articles/1110/07/news034.html
一言で言うと、GAEから利用可能なMySQLです。
上記のGAEにおける開発難易度の高さの大部分はデータアクセス層がJDOになっておるためなのですが、
その部分をMySQLにすることで既存システムの移行や既存の開発手法の流用を容易にするものです。
但し、GAEにおける優位性であるスケーラビリティは通常のものになります。
それ程スケーラビリティは必要無いし、既存の資産を流用したいと言う場合には良いかと思います。

Google Cloud Strage
参考記事:http://www.itmedia.co.jp/news/articles/1110/12/news061.html
こちらは、Amazonで言う所のS3とほぼ同等のサービスです。
クラウド上のNASですね。APIを経由した出し入れが可能です。
但し、GoogleDriveとの位置づけの切り分けについてはGoogle内でも混乱しているようで、
少し様子見かなぁと思っています。

Google Compute Engine
参考記事:http://www.itmedia.co.jp/news/articles/1206/29/news032.html
こちらも、Amazonで言うところのEC2と同じで、仮想マシン提供サービスです。
後発ですが、特に目立った改善点等は今のところ見受けられません。
GoogleI/Oで担当者は一応性能・価格比は自信があるとのことでしたが。
果たしてどうでしょうか?今後評価してみたい所です。

Google BigQuery
参考記事:http://www.itmedia.co.jp/news/articles/1205/02/news046.html
こちらは全く新しいサービスに思います。
既存のOLAPツールのようにメッシュに応じたキューブを事前に設計するのでは無く、
どんなクエリでもフルスキャン(全文検索を力技で行う)を毎回走らせると言う、
めちゃめちゃ男らしく潔い方針です。確かにクラウドならでは。
この方針には軽く感動を覚えました。
それでいて既存のOLAPツールと変わらない性能を出せていると思いますので、非常に面白いです。
是非素敵な活用方法で提案出来ると良いなぁと思います。

以上、簡単な一言解説でした。

弊社の今後の活用・提案方針としては、GAEをメインに据え、移植等の場合にはCloudSQLを併用しつつ、GAEで賄えない特殊な移植の場合はComputeEngineを利用し、Bigデータ活用の場合には是非BigQueryを。
CloudStorageについてはDriveとの棲み分けについて今後要検討、という所です。

もちろん、EC2では無くComputeEngineに既存パッケージを載せて運用して欲しいと言うニーズがあれば対応しますが、今のところそんなニーズも意味も無いでしょう^^;


2011-12-27

ロートルPGがGoogle App Engineを使ってみた

先日、1.6.1がリリースされたGoogle App Engine(以下GAE)ですが
弊社の社員から、初めてGAEを触ってみた感想を聞くことができました。
面白い内容なので、ブログに載せておきます!

以下、弊社社員の文章です。ぜひご一読ください。

----------------------------------------------------------------------
今回、はじめてGAEを使ってみて、レンタルサーバと比べての感想を簡単に記したいと思います。

結論から言うと、とても楽でした。
私のキャリアを話すと、C、JavaなどのPGですのでLinuxでの開発経験はありました
以前はSOHOでの仕事が多かったため、自分でApache+Tomcatを設定してシステム管理者を兼ねるケースも多かったです。
そういう経験からすると、Eclipseからボタン一発でDeployできるGAEは本当に生産性が高いと思いました。
まず、さくらなどのIaaSサーバだと、OSこそインストールされているもののApache+Tomcat、DBのインストールをまずする必要があります。
ちょっと、セキュリティをちゃんとしようとするとそれだけで一日はかかってしまいます。
GAEはPaaSなので、その辺の設定はいりません。
EclipsePluginあとはGoogleアカウントがあれば、即開発に入れます。

今回、弊社が開発中のアプリケーションの改修作業をしたのですが、私のPCはEclipseが入っていなかったため、それの準備とPluginの導入、ソースを揃えるのに一時間程度で、すぐに修正作業に入れました。
GAEサーバへのDeployは5分とかかりませんでした

これ以上の詳細はここでは書けないのですが、これだけで今回の目的は達成できました。
今回の環境はある目的用にGAEのアプリケーションインスタンスは新たに作る必要があったのですが、社内のSVNサーバからソースをPCにチェックアウトして、それをコーディング後、Eclipseからデプロイしただけです。
GAEへのアプリケーションの追加はありましたが、ミドルウェアのインストールは一切行わず、新たな環境のできあがり!
ローカル上でのデバッグは普通のJava EEアプリと同様です。
あとは純粋にコーディング作業をしていただけです。

もう、レンタルサーバを使うのはばかばかしいです。
納品用のメディアを作るとか無駄な作業も当然のごとく不要。
エンジニアは仕様と、コードに集中できます。
----------------------------------------------------------------------

以上です。
またこういうコラムをご紹介していきたいと思っています!
ぜひお楽しみに。


ちなみに、弊社が提供している繋吉もこのGAEを使って運用しています。
関連記事でもご紹介していますのでご覧ください。


関連記事はこちらです。



2011-12-08

Google Apps向け機能拡張サービス「繋吉(つなよし)」シリーズを日本で初めてGoogle App Engineプレミアアカウントにて運用開始

先日、「App Engine Premier account になってみた(日本第一号)」にてもお伝えしておりました、国内初のプレミアムアカウントについてですが、本日プレスリリースを行いました。

こちらにも載せておきたいと思いますので、ぜひご一読頂ければと思います。

-----------------------------------------------------------------

報道関係者各位
プレスリリース

2011年12月8日
吉積情報株式会社

吉積情報、Google Apps向け機能拡張サービス「繋吉(つなよし)」シリーズを
日本で初めてGoogle App Engineプレミアアカウントにて運用開始 
 


  吉積情報株式会社(本社:東京都中央区、代表取締役:吉積礼敏、以下、吉積情報)は、Google Apps for Business(以下Google Apps)向けの機能拡張サービスである「繋吉(つなよし)シリーズ(以下、繋吉)」を、日本で初めて、Google App Engineプレミアアカウントにて運用を開始いたしました。

  これにより繋吉シリーズを、Google App Engineの有料アプリケーションの区分で提供を行うと同時に、高可用環境(High Replication Datastoreオプション、以下、HRDオプション)に対応いたしましたので、99.95%の稼働率保障のもとで繋吉をご利用頂けるようになりました。また、繋吉の利用料に関しては、従来と同じ料金でご利用いただけます。


■Google App Engineプレミアアカウントでのサービス運用開始の背景

  吉積情報が提供しております繋吉シリーズは、Google App Engine上で展開するGoogle Apps向けの機能拡張サービスです。クラウド型グループウェアであるGoogle Appsへのアクセスをよりセキュアにするセキュアログインパックや、カレンダーのビューを見やすくするグループカレンダーの機能などを提供しております。

  多くのお客様に繋吉の導入をすすめる中で数多くのご意見、ご要望を頂いておりますが、その中で特に、Google App Engineのメンテナンスに影響されないサービスを提供して欲しいとのご要望を頂いておりました。Google App Engineは、Google Appsと同様、高い信頼性を備えたアプリケーションの実行環境ですが、不定期に予定されるメンテナンスによって、繋吉シリーズをご利用頂けない時間帯が発生しておりました。このメンテナンスは、米国時間の夕方に行われることが多く、日本では午前中の出勤時間帯と重なるため、特にセキュアログインパックについては、この点について多くの要望を頂いておりました。

  11月7日に行われましたGoogle App Engine 1.6.0のリリースに伴い開始されたプレミアアカウントでは、HRDオプションに対応することで99.95%の稼働率保障を受けることができる有料アプリケーションを無制限に作成できるため、他社に先駆けて準備を進め、11月9日に国内では初めてプレミアアカウントでのサービス運用を開始致しました。


■プレミアアカウントでサービス運用する繋吉シリーズの特徴

  この度のプレミアアカウントでのサービス運用開始に伴い、現在提供中の繋吉の全てのサービスをHRDオプションに対応した有料アプリケーションに切り替えました。これにより、Google App Engineのメンテナンスに影響を受けることなく、サービスの提供を行うことが可能になりました。

  お客様にとっては、24時間365日を通じて、よりセキュリティの高い状態で、Google Appsをご利用頂くことが可能になります。繋吉を通じて、高セキュリティな状態でGoogle Appsを活用頂くことで、クラウド上で提供されるGoolge Apps最大の特徴である、ロケーションやデバイスに左右されずに利用ができるというメリットを最大限に活かして、業務における生産性の向上を見込むことができます。

  なお、この度の有料アプリケーションへの切り替えに伴い、お客様に行なって頂く設定などは特になく、従来通りご利用頂けます。価格に関しても、従来通りの価格でのご提供とさせて頂いております。

  また、従来のGoogle App Engineはプレビュー版という位置付けでしたので、サポート窓口は設置されておらず、何か障害が発生した際には、基本的には開発会社側の自己責任で対応する必要がありました。
  しかし、プレミアアカウントでは、Google側にも専門のサポート窓口が設置されます。万が一の障害発生時にも、Googleのサポートチームと協力して障害対応ができるため、より迅速な問題解決が見込めます。


■繋吉(つなよし)の詳細

  繋吉(つなよし)は、吉積情報が開発を行なっているGoogle Apps向けの機能拡張サービス群の総称です。「お客様とGoogle Appsを吉積情報が繋ぎます」を合言葉に、Google Appsの基本機能を補完して、より効果的にGoogle Appsをお使い頂くための機能を提供します。

繋吉セキュアログインパック
  クラウド型グループウェアであるGoogle Appsへのよりセキュアなアクセスを提供するシングルサインオンサービスです。ログイン情報の変更、リモート環境からのアクセス制御、携帯電話からのログイン制御、PC/スマートフォン端末からのログイン制御など、Google Appsへログインする際の様々なオプションを提供します。
  中小企業様にもご導入頂きやすい価格でサービス提供させていただいており、多くのお客様にご導入頂いております。
価格(税抜):月額利用料100円/年額利用料1000円

繋吉グループカレンダー
  Google AppsのGoogleカレンダー情報を、部署などグループごとのメンバー単位で閲覧・編集できるサービスです。週単位の予定をリスト形式で確認ができるほか、詳細カレンダー画面では予定情報を時間帯の形式で確認する事も可能です。
価格(税抜):月額利用料60円/年額利用料600円

  今後は、ワークフローや勤怠管理ツールなど、ビジネスに必要不可欠なサービスを展開していく予定です。

製品紹介ページ
URL:http://www.yoshidumi.com/tsunayoshi/

*繋吉の導入には、Google Apps for Businessのご契約が必要です。
*価格にはGoogle Apps for Businessのライセンス料は含まれておりません。


■Google Apps for Businessについて

  Google Apps for Businessは、Googleが提供するサービスを独自ドメインで利用することができる、クラウド型のビジネス向けアプリケーションサービスです。
メール、カレンダー、チャット、ドキュメント、サイト作成などビジネスに欠かせないコラボレーションやコミュニケーションのための機能が提供されています。

吉積情報株式会社はGoogle Apps for Businessの販売代理店です。

製品紹介ページ
URL:http://www.google.com/apps/intl/ja/business/index.html


■Google App Engineについて

  Google App Engineは、Googleが提供するウェブアプリケーションの構築・実行環境です。アプリケーションの構築や維持管理が簡単に行なえ、トラフィックやデータストレージの増大に合わせて容易にスケーリングできます。サーバーを維持管理する必要がないのも特徴です。

  11月7日にプレビュー版から正式版に移行し、プレミアアカウントの提供が開始されました。プレミアアカウントでは、HRDオプションに対応することで99.95%の稼働率保障が受けられる有料アプリケーションを、無制限に作成することができます。


■会社概要

会社名:吉積情報株式会社
所在地:東京都中央区東京都中央区銀座2-14-7 銀座OMビル 3F
代表者:代表取締役 吉積礼敏
ホームページ:http://www.yoshidumi.com/


■本件に関するお問い合わせ先

担当者:秋田晴通
TEL:03-6228-4451
FAX:03-5843-1690
E-mail:hakita@yoshidumi.co.jp

-----------------------------------------------------------------


2011-11-16

Google、ビッグデータ分析サービス「BigQuery」を一般公開 - ITmedia ニュース

Google、ビッグデータ分析サービス「BigQuery」を一般公開 - ITmedia ニュース:

これで、DWHも揃ったと言うことになるんでしょうか。

○端末
・ChromeBook
・Android
・ChromeTV

○PaaS
・GoogleAppEngine
汎用基盤として何にでも利用可能
・CloudSQL
上記と連携して動作。既存アプリからの移行にも。
・BigQuery
DWH系の構築用?

で、だいたいなにでも出来る気がします。
基盤はだいたい出揃った感じでしょうか。
後は作るのみ、ですね。頑張ります。

ChromeBook、まず、早く欲しいのと、出たら扱いたいですねぇ。

2011-11-11

App Engine Premier account になってみた(日本第一号)


 弊社はGoogleトータルソリューション企業として、AppEngineには非常に力を入れております。

その証拠にも、AppEngineがこの11月にプレビューを終えて、正式サービスとしてオープンするにあたり、 いち早くそのプレミアアカウントになるべく契約準備を進めて参りました。

その結果。。。なんと、日本におけるプレミア契約第一号という栄誉を頂きました。

記念すべき第一号です。いやぁ、嬉しい限り。
ぶっちゃけ、なんとなく契約手続きの進みが遅いので、慣れてないなぁ、初めてかなぁと言う雰囲気は感じておりましたが、先日Googleの松尾さんに伺いまして。
正直でも世界でも100番以内位には入ってるんだろうなぁとは思います。ほとぼりが冷めたら聞いてみたい所です。

さて、そんなわけで、初のPremierアカウントと言うことで、どういう感じになるのか、
簡単にご紹介しておきます。
今後検討される方は参考にして頂ければと思います。

まず、GAEの元々のアカウントでログインすると、以下のように頭に、
「All yoshidumi.co.jp applications>>」
と言うリンクが追加されます。(もうyoshidumi.co.jpとかアカウント名はわかる人はわかるので隠しません)

GAEの見慣れたメニュー画面



ここをクリックすると、以下のように追加されたアプリ一覧が出てきます。(さすがに顧客名の部分はマスクしてあります)

プレミアアカウント画面!
こちら、日本では弊社社員しか(恐らくGoogle社員でもすごく少数)見たことのない画面の筈です。

メニューには、
・Applications
・Settings
・Approvals

と出て来ます。
・Applicationsは上記の画面でリンクがあるだけで、普通の一覧と特に変わりありません。
・Settings は単純に管理者を誰にするか?と言う設定が出来ますが、恐らくApprovalsを出来るかどうかの違いぐらいしか現時点では意味がありません。
・Approvals は既存のアプリを移行する際に、承認を求められます。その承認待ちの一覧が出てきます。

以上で、ほんっとシンプルなものです。

さて、後は何が変わったかと言うと。
・ドメインのメンバがGAEのアプリを登録するときは自動的にこの中に入る。
なので、自動的にPremierアカウント管理になり、恐らく、アプリ作成の数に上限が無い。と思われます。
・課金設定が出来ない
これはすぐに治ると思いますが、現時点では課金設定が制限出来ず、無制限で使い放題になります。
なので、うちの社員は勝手にアプリを作成して、無制限に使い放題の状態です。これはちょっと不味い。。人数多い会社さんだと無法地帯です。気をつけましょう。


以上、如何でしたでしょうか。
今後問題発生時のサポート対応の状況など、公開可能な範囲でレポート等して参ります。

2011-08-08

AppEngineのWeb.xml

ちょっと面倒なエラーがありまして、週末ちょっとはまりました。
・コメントがあるとJSPのコンパイルエラーが発生する。
 どうやら、コメントがあるとデプロイ時のコンパイルエラーを起こす場合があるようです。
 こんな感じのエラーの時。
Unable to update app: Received SAXException parsing the input stream for C:\DOCUME~1\XXXXXX\LOCALS~1\Temp\appcfg6641864231126431319.tmp\WEB-INF/web.xml
 いやぁ、かなり意味分からないですが、まぁ、クセの一種ですかね。。
・リダイレクトループ
 JSP-CONFIGの設定があると何故か無いファイルにアクセスがあるとindex.jspを繰り返したアドレスにリダイレクトループが発生して、何だか嫌な動きをすることになる。
 これもクセの一種でしょうか。

色々使い込んでくると発覚して来ます。。。

2011-07-01

GoogleAppEngineのエンタープライズ版

昨日、Googleのパートナー向けのセミナーに参加して来た。
詳しくは書けないですが、大きく自信を持った。
ポイントは
・米国での事例では非常にセンシティブな情報を扱う企業がそのシステムを丸ごとGAEで構築している。
・セキュリティ事故はどちらかと言うと内部漏洩が大いので、Google程大規模を少人数で管理している所は無い、ために、非常に安全になってる、と。
 確かにデータセンタのデータを丸ごと盗んでも、それを複数組み合わせないと意味あるデータにならないとか、もう1データセンタ担当とかではどうにもならない。通常のデータセンタのホスティングだと、サーバにログインしてテープにデータ書きだしちゃえば簡単に持ち出せちゃう。って考えるとかなりセキュアと言える。
・ついに有料でSLAが付く
 これは本当に大きい。安心して提案出来る。

2年後、GAEで作るのが第一候補になる世界が来ていると思う。
弊社ではますますFW化やノウハウの蓄積に力を入れつつ、具体的に提案も行って行く!

2011-03-19

AppEngineに上げたソースをDLしてみる。

昔作ったプログラムで今も仲間内で稼働中のメーリングリストシステムのソースを紛失してしまった。
丸一年以上なにもメンテしてなかったので、PC入れ替え時に誤ってソース毎消してしまったらしい。。。
まずいっす。。で、AppEngineでソースをDL出来る機能が最近はあるらしいので試してみた。

どうやら、appengineSDKのPython版が必要であるらしい。
Python版のSDKから、JavaのソースもDL可能とのこと。
PythonのapengineSDKのページ(http://code.google.com/intl/ja/appengine/docs/python/gettingstarted/devenvironment.html)
を見ると2.5とのことなのでおとなしく最新では無く2.5を探す。
http://www.python.jp/Zope/download/pythoncore から、当然インストーラ付きで探してみて、
http://www.python.org/ftp/python/2.5.4/python-2.5.4.msi
をDLしてインストール。

続いてAppEngineのSDKをDL。
http://googleappengine.googlecode.com/files/GoogleAppEngine-1.4.2.msi
こっちもmsi形式なので、簡単ですね♪

Pythonの動作が全く分からなかったけど、まぁPerlとかと同じですね。
AppEingineのインストールパスにDOSで移動して、以下を打つと、パスワードを聞かれて、DL出来た!
.\appcfg.py --secure --no_cookies -e ayatoshi@gmail.com download_app -A mobile-mailinglist C:\Work\mobml\

ま、想像通りだけど、Classファイルなのね。。。ここから逆コンパイル頑張る、か。。。
jadclipseがPleiadesにデフォルトで入ってたので試してみたけど、エラーで逆コンパイル出来ず。
むー。。。ライブラリのパスとかが無いときついんかな??理解不能。一旦諦める。
一からSlim3で作り直してみるかなぁ。。。

2010-12-14

Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released

いやぁ、ちょっと時間経ってしまいましたが、これ、衝撃です。常時起動!
弊社のWebサービスも遂に本気で移行を考える時期かも知れません。

2009-12-21

PLAY HOME! Xmas

ちょっと先週後半は珍しくお休みを頂いておりました。

さて、渋谷の東急ハンズにてみんなの想いを届けるクリスマスツリーが出現しました!


これ、弊社も関わってます、と言うか、弊社とシナプスソフトさんとで作りました。
東芝さんの190インチ(?だっけ)の最新ディスプレイを3連で繋げた圧巻のディスプレイで、
iPhoneと連動したアプリが動作します!
ちなみにさらに、このアプリや空メールの機能部分は全てAppEngine上で動作してまして、基本サーバ代は無料です。
iPhoneアプリ+AppEngine連動ってのも珍しい取り組みかと。
今後もおもろいことには取り組んで行きたいと思っております。

テレビとかに取り上げられないかなぁ。

2009-11-03

GAE/J OAUTHを利用したカレンダー更新

OAUTHを利用したAppsのユーザデータ更新においては、サンプルが役に立ちません。
色々試行錯誤した結果、以下のような形にすると参照・更新出来るようです。
参考まで。

これは結構マニアな情報ですかな。
■Privateのカレンダーを取得する場合。
URL feedUrl = new URL(BASE_FEED_OAUTH + "default/private/full");
myQuery.addCustomParameter(new CustomParameter("xoauth_requestor_id", user));

■Privateのカレンダーを更新する場合。
feedUrl = new URL(BASE_FEED_OAUTH + "default/private/full?xoauth_requestor_id=" + user); //defaultにするだけかな。

■特定のカレンダーを取得する場合。
URL feedUrl = new URL(BASE_FEED_OAUTH + calId + "/private/full");
myQuery.addCustomParameter(new CustomParameter("xoauth_requestor_id", user));

■特定のカレンダーを更新する場合。
feedUrl = new URL(BASE_FEED_OAUTH + calId + "/private/full?xoauth_requestor_id=" + user)


■calIdは以下で取得可能。
String calId = URLDecoder.decode(CalendarEntry.getId().substring(55),"UTF-8");

2009-10-28

GoogleAppEngineでメール受信アプリ作成可能に

おっぉっとこれは大事件です!
いやぁ、来週のセミナーにもここ(GoogleAppsではメール受信をトリガーに何らかのアプリケーションを動かす要件には対応出来ない)は弱点であると言う資料を作っておったんですが、書き直す必要があります。
具体的な作り方などはこちらのブログが詳しいですので参照下さい。

素晴らしい!これはかなり大きいです。ここはなかなか対応出来ないかと思って居たんですがねぇ。やりますね。応用するとカスタム(ユーザの追加・削除などをコマンド形式にしたりするような)のメーリングリストだってGoogleの基盤の中である程度まで無料で作成出来てしまいます。
後はメールトリガーでの他システムとの連携が広がりますね。ワークフロー製品などで、Web呼出なんかは標準で実装してないような製品でも、通常イベントのタイミングでメールを送る機能はありますから、そのメールを受け取って処理するプログラムを作っておけば、AppEngine上のシステムとの自動連携がいっcちょあがりってなもんです。

取りあえず、フォーム作成機能のメールトリガーにくっつけて自動返信する仕組みを作って公開してしまおうと画策中。。。

2009-10-12

GWTメモ

タグはAppEngineJavaですが、中身はGWTです。
色々と戸惑いますねぇ。現在弊社の勤怠管理システムを構築・運用中ですが、色々詰まったりするので、メモを残して行きます。
・クライアント側ではDecimalは使えないので、NumberFormatを利用する。
 挙動的には四捨五入される模様。
・クライアント側では同じくCalendarクラスも死んでるので、自前で拡張したDate型を用意。
 これ、皆さんどうしてるんだろうなぁ。。。取りあえず月を+-するメソッドだけ追加。
・RPCの同期はやっぱり無理
 どうしても難しい模様。これは設計レベルでそこそこ考えておかないと、複数のRPCで呼出に依存関係がある場合は制御不能なので、逃げ道を考えておく必要がある。

です。edittableグリッドが使えないんだよなぁ。。