【GAE】インスタンス時間１

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

只今、クラウド基盤「Google App Engine(以下、GAE)」の連載しています。

今回はGAEのお金関連の話でも中核中の中核、「インスタンス時間」についてご紹介しましょう。

基本

まずは以下ＵＲＬがGAEの料金について説明したページです。

• http://www.google.com/intl/ja/enterprise/cloud/appengine/pricing.html

GAEの課金制度は、基本的には「従量課金制」です。
電気代や水道代と同じく、多く使った人程にお金を多く払うという公正公平、かつシビアな制度でございます。
この為、安い値段、突き詰めれば無料でGAEを使う為には、GAEを節約しながら使っていく必要があるのです。
この辺りも電気、ガス、水道と同じですね。

とは言っても、

・水道の消費量。⇒流した水の量で決まる。⇒水を無駄に流さない。
・電気の消費量。⇒消費した電力量で決まる。⇒使っていない電気を消す。

みたいに、電気や水道ならば節約する為に何をすれば良いのか分かり易いのに対して、
GAEの節約とは何をすればいいのかピンと来ないですよね。

今回はそのお話です。

クォータ(Quota)

さて、GAEというのは、インターネット上に接続されている複数のマシンをみんなで使い回すことによって資源を有効活用するシステムです。
この為、

• 「一人で勝手に無駄遣いするなよ」
• 「あんまり使う奴は金払って貰うからな」

という運用になるのは至極当然のこと。
ジャイアニズムという声もありますが、我々に文句は言えません。
この場合の「各サービス毎への割り当てリソース」のことを「クォータ(Quota)」と呼びます。

このサービス毎のクォータ量を超えてしまうと「課金発生」「システムダウン」「機能低下」など様々なデメリットを被ってしまうことになります。
（容赦無し）

そのクォータにつきましても色々な種類がありまして、

• フロントエンドインスタンス時間
• バックエンドインスタンス時間
• データストア書き込み回数
• メール送信数

書き切れないくらい沢山あります。
それらどのクォータがオーバーしてしまってもNG。シビアな世界です。

自分のサービスがどれくらいクォータを消費しているかについては、自分のダッシュボードのメニューに出ている「Quota Details」からご確認ください。以下のような画面です。

実に多岐に渡る項目があるのが良く分かるかと思います。
全部理解しろと言われても、これは苦しい……。
とは言え、実質的にこれら全項目をパンパンまで使うなんてシチュエーションは考えられず、
大抵はこの中の項目のうち、「良く消費する一部項目だけがネックになる」という運用になるでしょう。

要するに「自分が使う部分だけ分かっていればＯＫ」なのです。


以上でお分かり頂けたかと思いますが、GAEの従量課金制は厳密にはこのクォータ消費量を理解して算出しなければなりません。

しかし、最初からそんな細かい数字に目くじらを立てても効率が悪いです。
最初は重要部分から押さえることをお勧めします。

実は、GAEの多岐に渡るクォータのうち、「中核」と言って良い代表的なクォータが存在します。
GAE初心者は最初にまずこのクォータ「フロントエンド・インスタンス時間」を押さえると良いでしょう。

フロントエンド・インスタンス時間(Frontend Instance Hours)

「フロントエンド・インスタンス時間(Frontend Instance Hours)」とは、簡単に言ってしまえば「サービスが動いている時間」です。

GAEというのは、「アクセスが来るとインスタンスが起動し、アクセスが来ないとインスタンスが寝る」という動きをします。
この「インスタンスが起動している時間」のことを「フロントエンド・インスタンス時間」と言います。
（以下、「インスタンス時間」と略称でご説明します。）

一応注意ですが、「インスタンスが起動している時間ということは、１日最大で２４時間だな」という計算ではありませんのでお間違え無く。
我々ＳＥ界には「人日 or 人月」という単位で予算を組みますが、それと全く同じ。

「インスタンス時間＝インスタンス起動時間×インスタンス数」

となります。
よって、２インスタンスが２４時間フル稼働していたら４８インスタンス時間消費というわけですね。

そして、GAEの無料枠は２８インスタンス時間ですから、これではオーバーしてしまいます。

無料枠は２８インスタンス時間。つまりこのままでは、

「無料ユーザーは１インスタンスしか使えないってことじゃないか！！」

という意味になってしまいますね。
しかし、そこはGAEの「自動スケールアップ機能」が活躍してくれます。

• アクセス数の多い時間帯は多数インスタンスを起動する。
• アクセス数の少ない時間帯は少数インスタンスで済ませる。
• アクセスの無い時間帯はゼロインスタンス。

こういう機能がありますので、「全然使っていないのにインスタンス時間だけ垂れ流し」という事態は避けられます。
利用者のいない時間帯はインスタンス時間を消費しません。
代わりに、利用者が多い場合は、いつもより多めにインスタンス時間を消費します。
２８インスタンス時間という限りある資源はちゃんと有効活用出来るのです。

終わりに

となってくると次に疑問に思うのは、

「そのアクセス数の多い少ないってどうやって判断してるの？」
「インスタンスの同時起動数はどうやって決定されているの？」

この辺でしょう。

その辺りにつきまして、もう少し掘り下げていこうと思います。

【GAE】スタート編４ Slim3導入

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

只今、クラウド基盤「Google App Engine(以下、GAE)」のスタート編を連載しています。

今回はMVCフレームワーク「slim3」を導入します。

slim3とは

slim3はseasarの開発者であるひがやすを氏が開発したMVCフレームワークです。

公式サイトにも紹介されているGAE３大フレームワークの一つです。

元からseasar支持者である私は迷わずこれを選択。

日本語の非公式サイトもあって非常に助かります。
https://sites.google.com/site/slim3documentja/

Google検索でも結構情報が出て来ますし、今の所はこのslim3を導入するのが最適だと思います。

ただし、非公式サイトも更新が滞っているのかリンク切れしている箇所が複数アリ。
内容もザッとした触り程度で詳しい所までは載っていないので、このブログなどでフォローしていきたい所です。

slim3導入

slim3はEclipseプラグインをインストールするだけで導入可能です。

インストール用のロケーションはこちら。
http://slim3.googlecode.com/svn/updates/

以下の手順でEclipseにインストールして下さい。

1. Eclipseを起動する。
2. メニュー→ヘルプ→新規ソフトウェアのインストール
3. [追加]からロケーションを追加

インストールしたらEclipseを再起動して下さい。

長きに渡る環境構築関連の記事でしたが、これでようやくプロジェクト作成に入れます。

プロジェクト作成

では、いよいよプロジェクト作成に入ります。

Eclipseのプロジェクト新規作成により、Slim3プロジェクトを選択して作成して下さい。

途中にGWTという文字が眼に付きますが、こちらはGoogle Web Toolkitというフレームワークと併用する為のモードです。
今回はGoogle Web Toolkitは使いませんので、普通のslim3を選択します。

これでプロジェクト作成完了です。

ルートページ作成

細かいことはさておき、とにかくまずはインターネット上へ展開してみましょう。
今回はルートページ「index.html」を作成します。

war直下に適当にファイルを作って置いて下さい。

デプロイＵＲＬセット

次に、デプロイ先のURLをセットします。
遡ること第２回で作成したプロジェクト名を指定して下さい。

1. プロジェクトを右クリック→プロパティ→Google→Appエンジン

デプロイ実行

いよいよデプロイします。

1. プロジェクトを右クリック→Google→Appエンジンへデプロイ

GAEにログインしていない場合はログイン画面が出て来ますので、ログインして下さい。

これでデプロイが始まります。
これでようやくアプリを世界に向けて公開……出来ないんですよね～。(泣)

いくつかエラーハンドリングしてみましょう。

エラーハンドリング

Javaのバージョンが違う

java.lang.UnsupportedClassVersionError: com/google/appengine/tools/development/LocalJspC : Unsupported major.minor version 51.0

これが出て来たら、それはJavaのバージョンが違うんですよ。
自分のプロジェクトをよく見て下さい。VMにjava6が指定されていませんか？
GAE SDK1.8.8はjava7、それもJDK7でしか動きませんので、お間違え無く。

JREを使っている

java.lang.RuntimeException: Cannot get the System Java Compiler. Please use a JDK, not a JRE.

これはJDKではなく、JREを使っているという意味です。
GAEはJDKでなければ動きません。

遡ること第１回でダウンロードしたJDKを使います。
ポイントは「Eclipseプラグインが呼び出すJavaをJDKにする」ということです。
つまり、Eclipseの起動に使用するJavaの変更です。
プロジェクトが読み込んでいるJavaのことではありません。
プロジェクトを動かすJavaではなくて、デプロイコマンドをキックするJavaをJDKにしろ、という話ですので、お間違え無く。

インストールしたEclipse内にあるeclipse.iniを開きまして、一番最初に以下を追加します。

-vm Eclipse起動用Javaのパス

パスを指定したらEclipseを再起動します。

成功！！

これでもう一回デプロイを試みれば、そろそろ成功してくれたのではないでしょうか？
私の環境では表示出来ました。

自動的にブラウザが立ち上がるはずですが、立ち上がらなかった場合は以下コンソールのステータスが「Running」になっていますので、それをクリックして下さい。

https://appengine.google.com/

ようやくデプロイまで漕ぎ着けました。
ここまで来るのは大変でしたが、一回出来てしまえば、後はクリック数回でいつでも簡単にデプロイ出来るようになります。

一応、これでデプロイ成功なはずですが、この作業の過程で偶々出たエラーメッセージもついでに以下に記載しておきます。
このブログの手順通りにやれば出ませんが、一応掲載です。

EclipseのバージョンとSDKのバージョンが合っていない

java.io.IOException: Jar C:\Users\User\AppData\Local\Temp\appcfg7254171904073358945.tmp\WEB-INF\classes\appengine-api-1.0-sdk-1.8.0.jar is too large. Consider using --enable_jar_splitting.

これは文言からすると、デプロイオプション「--enable_jar_splitting」を指定しろという意味に受け取れます。
しかし、「そのオプションを指定すれば解決するはずだ」と考えるのは大間違い。
これが出ると言うことは、EclipseのバージョンとSDKのバージョンが合っていないのです。
バージョンが合っていないからオプションが効いていないというだけの話なのです。

Eclipseを最新にするか、SDKを切り戻すか、何らかの手段でバージョンを合わせて下さい。
以前の記事にも書きましたが、GAEは「Eclipseのバージョンに敏感な影響を受ける」という特徴があります。
「Eclipseなんて4.2でも4.3でも大して変わらんだろ」という考えは、普通の開発ならそうですけど、GAEではＮＧ。
動きません。
キチッと合わせてください。

終わりに

ようやくデプロイまで到達しましたね。お疲れ様でした。。。

環境セットアップ周りはGAEに限らずシステム開発では詰まりやすい所でして、私もここまで漕ぎ着けるのに大変苦労しました。
しかし、一度手順を確立してしまいさえすれば、案外何てことは無いものだと分かるかと思います。

これでスタート編は終了です。

次回からは実装関連の検証を進めてみます。

【GAE】スタート編３ Googleプラグイン&SDK取得

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

只今、クラウド基盤「Google App Engine(以下、GAE)」のスタート編を連載しています。

今回は開発環境の構築です。

Javaバージョン

本連載では言語はJavaでお送りします。

• Javaバージョン：JDK7

ここでとんでもない落とし穴があります。

まず、以下がJavaのインストールについて記述された日本語の公式サイトです。

https://developers.google.com/appengine/docs/java/overview?hl=ja

ここにJDK6を使えと書いてあります。

次に英語の公式サイトを見てみます。

https://developers.google.com/appengine/docs/java/gettingstarted/installing

Java6はサポートしない。Java7を使えと書いてあるんですよ。

つまり、日本語公式サイトは更新が遅れている！！

更新履歴を見ますと、英語サイトの更新が2013/10/24、日本語サイトは2013/6/10です。
４ヶ月遅れですね。
しかも、この最終更新日付はサイト全体での最終更新日付であって、ページによってはもっと長い間更新を忘れ去られている模様。

ようするに、日本語公式サイトの更新遅れは致命的だから信用するなということです。

私も最初は日本語サイトを参考に開発しようとしていたのですが、エラー連発で全然動かず。
しかし更新が大幅に遅れていることに気付いて英語サイトに切り替えたら、スッと動きました。

日本語サイトはあくまで参考。最終的には英語版で裏を取ることを心懸けなければいけません。。。

Eclipseダウンロード

次に、Eclipseをインストールします。
これも例によって、日本語サイトには大嘘が書いてありますので、英語版を参考にして下さい。

https://developers.google.com/appengine/docs/java/tools/eclipse

このJavaのバージョンやら、Eclipseのバージョンやらは、結構重要です。
普通の開発だと、Eclipseなんてどのバージョンを使っても大抵は動いてしまうものじゃないですか。
GAE開発はその辺がシビアで、ちゃんとその時点で公式サイトに掲示されているバージョンを使っていないとポンポン問題が起きます。

この記事を書いている現時点においてはEclipse 4.3 (Kepler) が対象バージョンですが、
今後に4.4に更新されることがありましたら、速やかに乗り換えて下さい。

さて、Eclipseですが、日本人である皆様はお馴染み、pleadesをダウンロードしてきます。

http://mergedoc.sourceforge.jp/

pleadesには「32bit版」と「64bit版」がありますが、
マシンが64bitならelipseも64bit、32bitなら32bitと合わせて下さい。

Eclipseプラグインダウンロード

最後に、Eclipseプラグインをインスト―ルします。
ダウンロードサイトはこちら。

https://developers.google.com/eclipse/docs/getting_started

このうち、私はEclipse4.3を使っていますので、以下URLをロケーションとして使用します。

https://dl.google.com/eclipse/plugin/4.3

インストール手順は以下です。

1. Eclipseを起動する。
2. メニュー→ヘルプ→新規ソフトウェアのインストール
3. [追加]からロケーションを追加
4. 「Google プラグイン Eclipse」とSDKをチェック。これでＯＫです。他はAndroid開発などで使用するツールですので、とりあえず今の所は必要ありません。

再起動すればインストール完了です。

結果確認

1. メニュー→ウィンドウ→設定→Google→Appエンジン

上記にキチンとGoogle App Engine SDKにチェックが入っていればインストール成功です。

ダメな場合は以下に続く。。。

Google App Engine SDK ダウンロード

上記の手順の通りにやってもエラーが起きることがあります。

Eclipseのバージョンとの互換性がかなり敏感でして、バージョン違いが主な原因かと思います。
「Eclipse3.7ではSDK1.8は動かなかったけど、1.7なら動いた」というのはこの身を以て確認しております。

ちゃんと、最新バージョンのEclipseをゲットして下さい。
もしくは、SDKの方を新しくして下さい。

最新のSDKダウンロードサイトはこちら。

https://developers.google.com/appengine/downloads

最新では動かないという場合は、過去のバージョンをダウンロードして下さい。
Pleadesの更新が追いつかないなど、過去バージョンを使用せざるを得ないケースもあるかもしれませんからね。
ただし、SDKは可能な限り最新版が望ましいですので、このやり方は暫定回避と位置づけて下さい。

https://code.google.com/p/googleappengine/downloads/list

ここまで

長くなってきましたので、今回はここまでとします。

厄介だったのは、日本語サイトの嘘と、Eclipseバージョンとの互換性でした。

これだけ揃えばGAEアプリの開発は行えますが、今のこの状態は一番シンプルな状態です。
この連載では開発効率向上のため、MVCフレームワーク「slim3」を導入します。

次回はslim3インストールから始めます。

環境まとめ

• OS：Windows7 HomeEdition 64bit
• Java：JDK1.7.0_45
• IDE：Eclipse 4.3 (Kepler)
• SDK：Google App Engine SDK

【GAE】スタート編２ アプリケーション作成

あけましておめでとうございます。
株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

昨年末よりクラウド基盤「Google App Engine(以下、GAE)」のスタート編を連載しています。

前回でアカウントを作成するところまで進みましたので、今度はアプリケーション作成に入ります。
「アプリケーション作成」とは、要は「インターネット上にURLを確保する」という意味です。

後の連載で登場する「Eclipseのプロジェクト作成」とは別物ですので、お間違え無く。

プロジェクト作成の前に

さて、プロジェクトをするには「プロジェクト作成画面」に進まなければなりません。
それは「Google Developers」というサイトで行うのですが、どうやら普通のGoogleのリンクには出ていない模様です。
自分でURL指定や検索エンジンなどで飛んで下さい。

以下がそのURLです。
お気に入りに入れておいて下さい。

https://developers.google.com/?hl=ja

このサイトの下の方に「デベロッパー ツール」がありますので、ここからプロジェクト作成画面に進めます。

デベロッパーツールはメニューが５つ並んでいますね。
ざっと説明しますと、それぞれ以下のようなものです。

• API Console：開発コンソールその１
• App Engine Console：開発コンソールその２
• OAuth 2.0 Playground：WebAPIの利用許可等の管理
• Project Hosting：所謂Google Code。プロジェクト開発拠点の作成
• Make the Web Faster：ガイダンスのようなもの

今回は「開発コンソールその１、その２」がテーマになります。

開発コンソール比較

上記の記述で、「開発コンソールその１、その２って何が違うんだ？」と疑問を持たれたかと思います。

結論から言いますと、『ほぼ、同じようなもの』です。
「新型」と「旧型」と言い換えても良いかもしれません。

まず右の「その２」からご説明します。

この飛行機みたいなアイコンが、Google App Engineのマークですね。
どこかしらで見たことある人も多いのではないでしょうか？

まだプロジェクト作成前なので以下画面は見えませんが、説明の為、ちょっとフライングで画面を公開します。

こんな感じです。
ここから先が開発者用管理画面でして、「インスタンス管理」「データベース管理」や、その他色々の管理はここから行います。

次に「その１」を見てみます。

箱のアイコンですね。

こちらも中身をフライングして見てみると、こちら。

両者、似てますよね？
というか、同じです。

どうも、「同じ機能の新型レイアウトと旧型レイアウト」という関係に見えますが、
完璧には同じではないです。

• 全く同じ機能もある。
• 新型にしか無い機能もある。
• 旧型にしか無い機能もある。
• 新型から旧型にショートカットが張られている。

「一体何なんだ？」と思う所ですが、要は「旧型から新型への移行途中」なんですよ。
新型のメニューをクリックして機能を使おうとすると、旧型へのショートカットになっているだけで、画面遷移してしまうことも結構アリ。

何とも中途半端な状態です。

これ、日本だったら「ユーザが混乱するから、新型は完成してから公開するべき！！」と大クレームになるシチュエーションだと思います。
しかしGoogleの場合、「新型は出来た所からさっさと順次公開。分からんヤツは大人しく旧型使っとけ」と言わんばかりのリリース状況です。

この辺り、やっぱりGoogleと日本企業では文化の違いを感じる所ですね。。。


ともかく、新型は日本語で表示可能だったり、画面も綺麗だったりするなどあり、私としては出来るだけ新型を使いたいのですが、移行が間に合っていない場合は旧型を使わなければなりません。
結果、新型と旧型を行ったり来たり、ということになってしまいます。

とりあえず、今の所は安定している「旧型」ベースで以下の記事を進めていこうと思います。

アプリケーション作成

さて、前置きが長くなりましたが、そろそろアプリケーションを作成しましょう。
旧型コンソールの方に入ると以下のような画面が表示されます。

最初はアプリがありませんので「Create Application」のボタンしかありません。
クリックすると、いよいよ作成画面に入ります。

後は情報を入力していけばOKです。

Application Identifier

作成するWebアプリのURLを決定します。
使用出来る文字は「半角英数字」と「ハイフン」のみです。
最小６文字、最大３０文字になります。

なお、URLにはこのようなGoogleサブドメインではなく、自前の独自ドメインを設定することも出来るはずですが、
今の所はGoogleサブドメインで続行します。

Application Title

作成するアプリケーションのタイトルです。

こちらも使用出来る文字は「半角英数字」と「ハイフン」のみです。
最小６文字、最大３０文字になります。

これはGAE上の管理名としてのタイトルです。
コンソールの一覧に表示されたり、認証画面で表示されたりします。

実際のWebアプリでユーザに表示されるタイトルはHTMLタグのTITLEタグで設定します。
普通に日本語も使用可能ですのでご安心下さい。

Authentication Options (Advanced)

そして最後。ここが重要。「認証オプション」です。

認証オプションは間違えても後から変更出来ません。くれぐれもご注意下さい。

上から順に、

1. Open to all Google Accounts users (default)：Google アカウントによる認証
2. Restricted to the following Google Apps domain：Google Apps アカウントによる認証
3. (Experimental) Open to all users with an OpenID Provider：OpenID による認証

です。

「①Google アカウントによる認証」がデフォルト選択されていますが、これが所謂普通のWebシステムです。
「Google アカウントによる認証」なので、すでに持っている「○○○○@gmail.com」などのドメインでログイン認証が出来ます。

GoogleアプリはGoogleアカウントで認証するのが一番合理的です。
地球上の全人類が全員Googleアカウントを持っているのが最も理想の世界です。
しかし、アプリによっては「Googleドメインを持っていない人でも使えるようにしたいし……」というケースもありますよね？
そういう場合は、この画面ではこの「①Google アカウントによる認証」を選んだ上で、単体ソースの方で認証をすっ飛ばせばＯＫです。

普通はこれを選んで下さい。
この連載でもこれを選びます。

「②Google Apps アカウントによる認証」は、タイトルからは①との違いが分かりにくいですが、
「Googleアカウント」と「Google Apps アカウント」は別物ですので、ご注意を。

ようするに、以下画面の右上。

自分の作ったサイトを、Google Appsアカウントで契約した人のメニューにリンクを出すというモードです。
独自ドメイン等を設定してGoogle Appsとして公開出来るようになります。

この連載では①を採用するので、こちら②については省略。

しかし、間違えないで下さい。

最初に①を選んでおいて、後から②に変更する。もしくはその逆。これは出来ません。

くれぐれもご注意を。

「③OpenID による認証」は、タイトルからしてOpenID認証関連だと思われますが、試験運用中なので割愛。
なお、①と③の間ならば後から変更可能とのこと。

作成実行

長くなりましたが、「①Google アカウントによる認証」を選んで「Create Appilication」をクリックすれば、作成完了です。

最後に、コンソール画面に入り直して下さい。
以下のように、アプリケーション一覧に作成したアプリのタイトルが出来ていれば作成完了です。

終わりに

以上でアプリケーションの作成は完了です。

予備知識として上記に長々と説明を記載しましたが、分かっていれば２分で作成可能です。
この辺りは実に効率的に出来ていますね。

以降も引き続きスタート編を連載します。

【GAE】スタート編１ アカウント作成

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

只今、クラウド基盤「Google App Engine(以下、GAE)」について連載を始めたばかりです。

さて、GAEについて連載すると言いましても、その規模が超膨大でどこから初めて良いやら……、という状態です。
ひとまず、連載最初は「スタート編」と題しまして、とにかくプロジェクトを始めてみましょう。

スタート編でやること

• Googleアカウントを作る。
• とにかくプロジェクトを始める。(接続先URLの確保)
• Eclipseセットアップ
• Eclipse内でプロジェクト作成
• リリース

以上です。
「これくらい、マウスでちょっとカチカチやるだけで終わるだろ」と思ってはいけません。
これだけでも詰まるのがGAEです。

悪戦苦闘した私の記録が、少しでも後の世の発展に繋がることを切に願います。

アカウント作成の前に

最初はアカウント作成です。
GAEを使うにはGoogleアカウントが必要です。

ここで早速、第一チェックポイントです。

Googleアカウントを使ってGoogleにアクセスして開発するわけですから、「社内/社外」という概念はありません。

普通の開発の場合、

• 開発環境は社内からしか参照できない場所にあるサーバを使う。
• 本番環境はインターネットに公開するサーバに展開する。

まず大抵はこのような体制で開発しています。

GAEにはこのような「社内/社外」という概念はありません。
本番環境も開発環境も同じくインターネットに繋がっており、家からでも普通にアクセス出来ます。

場所を問わないことがクラウド開発の非常に大きなメリットです。
お客様にもアカウントを用意して貰えばお客様も開発環境に入ることが可能ですので、開発の進捗状況をリアルタイムかつダイレクトに報告出来るのです。
仕様変更などを電話相談する時も便利そうですね。

しかし一方で、家からでも開発環境、本番環境、両方にログイン出来てしまう環境ですから、セキュリティ的には従来開発よりも低いです。
このセキュリティ水準を認められない開発の場合は諦めるしかありません。

ただし、アカウント毎に権限を付与して、「本番環境にログイン出来る人はこの人だけ」「開発環境にアクセス出来るのはこの人だけ」というような運用は出来ます。
また、「この人が何時何分にこういう操作を行った」という記録も残っています。

この辺りがGoogleのセキュリティ水準の方針なのですね。

その辺の管理権限につきましては、しばらく後、別の章でご紹介することになると思います。

アカウント作成

では、アカウント作成に行きましょう。
すでにアカウントを有している人は作成する必要はありませんが、それでも読んで損はない情報を以下に記載します。

皆様ご存じ、Googleのトップページの右上に「ログイン」というボタンがありますね？

その人のログイン状況に応じて少し画面は違いますが、とにかくその先から以下のような「アカウント作成画面」に進むことが出来ます。
ここに名前や、希望するアカウント名、パスワード等を入力していきます。

ここで第二チェックポイントです。

名前は個人名にして下さい。

上の画像には「遠藤　太志郎」と入っていますよね？
そう、名前は個人名でなければいけません。

「このアカウントは管理者間で使い回しする予定だから、名前は『ジェニシス　アドミン』にしよう」

とかダメなんですよ。

『ジェニシス　アドミン』のように個人名ではない名前を入力してアカウントを作ると、そのタイミングでは確かに入力出来ます。
しかし、数日内にGoogleより「ポリシー違反です。修正しなければアカウントを削除します」みたいな警告が届いてしまいます。
「個人名判定ロジック」が定期実行されているのです。

これはGoogle+の名前付けポリシーによるものです。

https://support.google.com/plus/answer/1228271?hl=ja

最近のGoogleは全機能をGoogle+を中心に連結する試みがなされており、Google+を使うつもりが無くてもGoogle+の影響下に置かれてしまいます。

「アカウントの使いまわしをするな。ちゃんと権限で管理しろ」というGoogleの意思表示なんですね……。

よって、共通の使い回しアカウントはなるべく使わないことをオススメします。
どうしても共通アカウントが必要な場合は、代表者の名前を入力すると良いでしょう。
（偽名を考える、という手もありますけどね）

ここまで

長くなってきたので今回はここまでです。
アカウント一個作るだけでもこれだけ色々あるのです。

次回はプロジェクト作成からスタートします。

【GAE】Google App Engine 始めに

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

最近……、というほど最近ではありませんが、
最近のIT業界ではクラウドへの関心が高まっていますね。

しかしIT業界にクラウドがどれくらい普及しているかと問われると、まだまだ発展途上だと思います。
発展途上であるということは、今がチャンス、狙い目です。

クラウドにも複数種類がありますが、これからしばらくの連載では、私がロックオンしたGoogle App Engine(以下、GAE)についてご紹介していきたいと思います。

クラウドとは

GAEの話は膨大ですので、最初である今回はクラウド周りの小話からスタートしたいと思います。

さて、この連載のテーマである「クラウド」ですが、「クラウドとは何か？」と問われると、私も困ってしまいます。
余り定義が明確ではないのです。
どんなクラウドでも必ず共通する特徴としましては「インターネットの先にデータが置いてある」ということですけれども、それを言っちゃあ今の世の中、何でもインターネットの向こうじゃないですか。
昔はインターネット常時回線の無い時代があったと伝え聞いていますが、今の若い世代にとっては「歴史の授業」みたいな感覚です。
今の時代は「インターネット＝当たり前」ですので、そこをアピールしても特徴になりません。

また、一時期クラウドという言葉が流行りましてね、「単なるレンタルサーバなのに、クラウドサービスを騙る」という詐欺みたいなサービスも少なくなかった。。。

定義が曖昧なので「クラウド」と言っても人によって認識が分かれてしまい、私は軽率に「クラウド」という単語を使うことを避けています。
しかし、最近はようやく「クラウド基盤」として認められるだけの価値のあるサービスが安定してきました。
いずれ「クラウド」という言葉の乱用乱発にも終止符が打たれると思います。

今回、連載のテーマとしているGAEも、代表的なクラウドたるクラウド基盤として認知されているものです。

クラウド基盤

クラウド基盤を標榜するサービスは複数あります。

• Google App Engine(Google)
• Amazon EC2(Amazon)
• Force.com(Force.com)
• Windows Azule(Microsoft)
• さくらのクラウド(SAKURA)

キリが無いのでこの辺にしておきますが、とにかくクラウドを名乗るサービスは沢山あります。
海外製の方が主力ですが、日本製もありますよ。

しかし、上記にもありますように、「詐欺みたいなクラウドサービス」もありますので、クラスド基盤選択は慎重にご検討を。
ここでは名指ししませんが、昔、担当者の作業ミスでバックアップも含めて多数のサーバのデータを丸ごと消し飛ばしたトンデモ企業があり、発展途上だった日本のクラウド業界に盛大に冷や水をぶっかけたのです。。。

まあ、そんなトンデモサービスは置いておいても、クラウド基盤には個性があります。
アプリケーションの要件に応じて向き不向きがありますので、導入の際はそれらに見識を持っていることが肝要です。

寄らば大樹の陰

そうは言うものの、複数のクラウドサービスに精通している人なんてそうそういません。
クラウド基盤というのは、その利用方法を習得して理解を深めるのに多大な勉強コストが必要になります。
一口に「クラウド基板」と言っても、それぞれ全然別物。
一人で全部習得するのはかなり厳しく、むしろ特定のクラウド基板を「得意分野」として習得する方が現実的だと思います。

その中で今回、私がGAEを選んでいる理由としましては、以下があります。

１．Googleであること

最大の理由はコレ、提供企業がGoogleであること、ネームバリューです。
クラウドサービスはデータの保管を他社に丸投げしてしまいますので、その会社が潰れたり、障害でデータが消し飛んだりしたら一貫の終わり。
何よりも信頼性が第一です。
技術、経営、歴史、実績、知名度……。そういった全方位的信頼性が何よりも重いのです。

「日本のクラウド基盤業者の方が日本語が使えて分かりやすいし……」とか、そんなのは二の次。
クラウド基盤本体が頑強であること、これが最優先となります。

２．簡単らしい

上記にも「クラウド基盤は習得に勉強コストが必要」と書きました。
クラウド基盤開発は普通の開発よりも、開発者に高い技術的ハードルを要求してきます。
GAEは、そのハードルが比較的低めであると言われています。
実際、この連載を始めるにあたってある程度調査を行っていますが、シンプルな作りになっていると思いました。
まあ、それでも十分難しいと思いますが、他よりはやりやすそうな印象です。

クラウド基盤は以下の相反するどちらかの性質があると言われていますが、

・特定分野の開発に絶大な開発効率を発揮するけど、応用が効かない。
・色々と応用が効くけど、開発効率はそんなに高くない。

GAEは下です。
シンプルである代わりに手間暇は必要ですが、その分だけ理解が早く、リスクも低いです。

「参入ハードルの低さ」

私はここが気に入っています。

ただし、相対的に簡単というだけで、やってみるとやっぱり結構難しいです。
経験の浅い人がいきなり始めるのはオススメ出来ません。
最初は普通の開発で基本的スキルを身につけ、応用力をつけてからGAEに参戦するのが良いと思います。

３．Javaが使える

これは完全に私個人の都合ですが、私はJavaが第一言語ですので、Javaを使わせて貰えると大変助かります。
他のクラウド基板でもJavaを使える所はありますが、Googleと言えばAndroidの提供も行っている会社ですよね。
AndroidもJavaで動いているのは言うまでも無く。

つまり、Googleは全てのクラウド基板業者の中で一番のJavaの守護神なのです。

他の基盤を選んでおいて数年後、
「ウチはJavaを支持しないからJavaのサポートをやめます。代わりに.NETを使ってね」
なんて事になったら困りますから。

Javaプログラマーとしては、やっぱりGoogleの存在は絶大なのです。

おわりに

第一回である今回はご挨拶ということで、雑談ベースになりました。

クラウド基板というのは、「サーバ」でもなければ「ＯＳ」でもなく、言語でも無ければDBでもネットワークでも無い。
サービスリリースに必要となる全ての技術をまとめた総合パッケージですので、必然的に習得しなければならない技術が膨大になります。

連載に当たっては相当な長期化が予想されますが、末永くお付き合い下さい。

Yahoo! テキスト解析API ルビ振りAPI

株式会社ジェニシス　技術開発事業部の遠藤　太志郎(Tacy)です。

現在は世に散らばるWebAPIの活用方法を検証します。
今回も前回と同じく、Yahooのテキスト解析APIから、ルビ振りAPIという機能を検証します。

ルビとは

ルビとは、以下のように漢字にフリガナをつける機能のことです。

遠藤（えんどう）　太志郎（たしろう）

このような表示を可能としているのは、<ruby>というHTMLタグです。
ブラウザによって対応していたり、していなかったりしますが、
最近のHTML5対応型ブラウザであれば対応していることが多いです。

HTML5の情報については、すでにネットに大量に転がっていますので、ここでは割愛とさせて頂きます。

しかし、上記のような「ルビ＝漢字の読み仮名」という図式は、まあ一応は標準的な使い方とされているわけですけれども、使い道は色々と自由になりますよね。
だって、ベースとなる文字の上に小さな文字をつけるというシンプルな機能であって、別に「カタカナ拘束」のような制約はありませんから。

例えば、

遠藤　太志郎（技術開発事業部）

遠藤　太志郎（記）

遠藤　太志郎（８０％オフ）


みたいに、その単語にちょっと付属情報を入れる、みたいな使い方が出来ます。
こういうのを駆使してより良いインターフェースを作っていきたいものです。

ルビ振りAPI

上記では<ruby>の使い道について記述しましたが、今回のメインであるYahooのルビ振りAPIは、「漢字かな交じり文に、ひらがなとローマ字をつける」という標準的な用途の為のAPIです。

公式サイトは以下です。

http://developer.yahoo.co.jp/webapi/jlp/furigana/v1/furigana.html

さて、ここを見ますと、以下のような説明がありました。

どうやら、「子供向けにフリガナを振る」というのが本来の趣旨のようです。
子供用の教育サイトとか、子供用新聞記事とか、そういったサイトであれば需要がありそうです。

とはいえ、私は業務システム開発がメインのＳＥですので、そんな子供用機能は需要が無いです。

しかし、そこを何か別の形で利用出来るのではないかな、と思って考えてみました。

例えば、以下のように名前とフリガナを入力する機能があるとします。

姓　　名
セイ　メイ

でも、両方入れるのは面倒なので、漢字だけ入れればカタカナは自動補完してくれると便利なのに、と常々思っています。

というわけで、私の名前でルビ振りAPIを実行してみました。

実行プログラムは依然と全く一緒。送信先URLを変えるだけで実行出来ました。
以下の過去記事をご確認ください。

1. Yahoo! Web API　登録編
2. Yahoo! テキスト解析API　キーフレーズ抽出（送信機能作成編）

さて、実行した結果は以下になりました。

• 遠藤⇒えんどう(endou)
• 太志郎⇒ふとししろう(hutosisirou)

ん～、ダメか。。。
やる前からなんとなく想像がついていましたが、私の名前は珍しいので対応出来ません。
「遠藤太郎」でやってみたら、正常に機能しました。

言語解析である以上は仕方のないことかもしれませんが、


「精度が１００％ではない。」


という問題がついて回ってきてしまいます。
このため、業務システムに導入するのはタイミングが難しそうです。

活用方法考案

このＡＰＩは、「精度が１００％ではない」という絶対的な問題があります。

だからと言って、「それじゃ使えねーよ」と断じてしまうのは早計でしょう。
別の考え方をすれば「大体は合っている」わけですので、「精度が大体ＯＫであれば十分」という用途ならば使えるわけです。

例えば、私はルビ振りAPIの機能のうち、「ローマ字機能」の方に着目してみました。

システムを扱っていると、「ファイル名は半角英数字で保存しなければならない」という制約に必ずぶつかります。
例えば、ファイルアップローダーです。

「打ち合わせ資料20130112.zip」をアップロードすると、大抵の場合は「142453.zip」みたいに名前がシーケンス番号等に変換されてリンク先URLになっています。

• http://tasy.com/download/142453.zip

みたいな感じですが、これじゃあURLだけでは中身が何か分かりません。
そこを、このローマ字変換機能を使います。すると、

• http://tasy.com/download/142453/utiawasesiryou20130112.zip

という形で保存出来るわけですよ。
URLの一意性はディレクトリ構成で対処、ファイル名はローマ字変換です。
完璧とは言えませんが、シーケンス番号よりは良くなったでしょう？


「システム＝精度１００％とは限らない。気持ち便利になった程度でも価値がある」


こういうシチュエーションもあるということです。

終わりに

引き続き、世の中にあるWebAPIの検証をしていきます。