只今、クラウド基盤「Google App Engine(以下、GAE)」の連載しています。
本質を知ろう
さて、今までの記事で巨大なGAEの一部を検証して参りました。それについて見えてきたのは、「GAEには普通のシステムとは異なる個性がある」ということです。
この個性とは、GAEの本質と言い換えることも出来ます。
ここで一つ、大事な事を明言しておきましょう。
- IT技術は、その本質を理解している者でなければ使用出来ない。
よくあるんですよ。
XXという技術が便利で凄いという噂を聞いた。⇒ザックリ調査⇒使えるみたいだし、早速使おう！！⇒爆死
GAEに限らず、IT技術には「限られた局面でのみ力を発揮する」という局地戦特化の性質を持つものがあるのです。
そのIT技術を使用するに相応しい要件、シチュエーション。向き不向き。それが本質です。
本質を理解しないままIT技術を導入しますと、高確率で要件とのミスマッチが発生して、もしくはその技術の真価を発揮させることが出来なくて、最終的には爆死することになります。
特にGAEの場合、その個性がかなり強い方である上に、基幹技術ですからね。
ちょっとライブラリを導入するとか、そんなレベルではなく、ここの本質を見誤ると爆死も爆死。
物理的にゴールに辿り着けなくなる恐れさえあります。
ここから更にGAEについて掘り下げていく前に、この辺りで一回、本質について整理してみましょう。
振り返り+少々
スピンアップ
GAEの強烈な個性の一つは「スピンアップ」です。ここ数回の記事で長々とスピンアップについて検証してきましたが、
- GAEは使用していない時間帯にインスタンスが落ちる。
- インスタンスが起動するタイミングで数秒～１０秒くらい待たされる。
- この為、フルAjaxを使用せざるを得ない。(jspには不向き)
この辺りがGAEの特徴の一つ「画面インターフェースの制約」です。
ＤＢが特殊
DBについてはまだ記事にしていませんが、内々に検証しておりますので、フライングで少々記載します。Google App Engineは、DBが普通のリレーショナルデータベースではなくて、Bigtableという特殊なDBなのです。
これに伴い、普通のDBなら出来て当然のことが出来ません。
例えば、count(*)とかは出来ません。
やるなら全レコードを検索して、Javaで行数をカウントすることになりますが、そんなことやってたら超遅いですよね？
なので、レコード件数をカウントする機能が重要な要件には向きません。
他にはjoinが無いとか。
joinを実現したい場合は、Javaで複数回クエリを投げてマッピングを取るなど、コーディング実装のレベルで作り込む必要があります。
つまり、複雑なクエリが必要になる機能は実現出来ません。
GAEはシンプルな要件にしか適応出来ないのです。
安定性、高可用性
一方で、大量データの取り扱いなど、安定性、高可用性には無類の強さを発揮します。何せ、GmailなどGoogleのアプリは全部コレで捌いているわけですから。
「アクセス殺到によりダウン」ということはまず無いと言い切ってしまって良いかと。
障害は偶に発生しているような未確認情報も入りますが、それでも自社でサーバを持つよりはよっぽど安定していると思います。
サーバ自体の信頼性はかなり高度な域にあると考えて良いです。
システム構成図
他にも色々とGAEには特徴がありますが、その中でも「本質」と呼べるような特記事項中の特記事項は以上の辺りかと思います。この辺りを考慮に入れて、私はGAEの力をフルに発揮するシステム構成図案を考えてみました。
それが以下、「GAEによるWebAPI戦略」です。
端末はスマートフォンも視野
最近はAndroidやiPhoneなどの、スマートフォン、タブレットの普及が著しいですよね。しかし、あれらは携帯端末というハードウェアの性能の都合上、重たい処理を端末側に持たせることが出来ません。
この為、重たい処理や大量データの確保が必要な場合は別途サーバを立てて、そこからHTTP通信によりXMLやJSONの形式でデータを取得する手段が多く取られます。
元々、GAEサービスのフルAjax化しなければなりませんので、サーバ本体は必ずWebAPIとしての役割を担うことになります。
このついでに、PCだけでなくスマホアプリまで視野に入れるというのは一石二鳥で合理的なのです。
圧倒的に頑強な本体
WebAPIアプリの性質上、中枢である本体サーバがダウンしてしまっては話になりません。そこで、GAEの圧倒的な頑強さが力を発揮するのです。
GAEを本体とすることは、自社のサーバを持つよりも圧倒的に安心です。
また、上記のスマホアプリ計画と連動しますが、アプリに人気が出てアクセスが殺到することも考慮したいケースもありますよね？
自社でサーバを持っていた場合は人気が出始めてからサーバを増強しなければいけませんが、
GAEは自動的にスケールアップしていきますので、そのような配慮は無用！！
将来の大人気アプリ、大人気サービスを目指すからこそ、GAEの力が真価を発揮出来るのです。
機能間の独立
これは技術的というより、体制的、政治的な配慮になるかもしれません。ハッキリ言って、「GAEに精通していて、Ajaxも出来て、AndroidアプリもAppleアプリも開発出来るエンジニア」なんていませんよ。
普通のWebシステム開発って、一人の人間がHTMLを書いて、Javaも書いて、SQLも書いて、一連の機能を実現しますよね？
でも、GAE開発はそんなの絶対無理です。
- Ajaxは書けるけど、GAEは知らない。
- Androidは知ってるけど、GAEは知らない。
- GAEは覚えたけど、他のスキルまで習得している余裕が無い。
こんな調子になって、開発メンバーを招集出来ないに決まっています。
しかし、このWebAPI体制を取ることで、「GAE本体担当」「HTML担当」「Android担当」「Apple担当」とスキル毎に明確に独立することが出来るのです。
その技術単品だけ分かっていればOK！！
これなら技術者も集められます。
機能制約の確保
上記に繋がりますが、GAEには実現出来ない要件というのもあります。何が出来て何が出来ないのかはそのプロジェクト毎に精査しなければなりませんが、確実に言えることは一つ。
「WebAPIインターフェースで提供していない機能は、実現出来ないという意味だ！！」
「WebAPIインターフェースで提供している機能の範囲内でアプリを実現するべき！！」
という、ポリシーの確保が必要だと言うことです。
これも「GAE本体担当」という専任者を置くことで、かなりの精度でポリシーを守り抜くことが出来るはずなのです。
終わりに
以上が、私の考えているGAEのシステム構想です。我ながら合理的な作りになっているのではないかと思います。
しかし残念なことに、「Ajax」「Android」「Apple」、これら全部を開発するようなビッグな案件が私の身近に無いのですよね。。。
まあ、将来的な目標として温めておくとしまして、しばらくはAjaxベースで検証を進めていきたいと思います。
次回以降は、GAEの個性的なデータベース「ビッグテーブル」について連載していきたいと思います。
0 件のコメント:
コメントを投稿