企業向けシステムを構築するパブリッククラウド【第3回】
「Google App Engine」の企業利用におけるさまざまな課題
元祖パブリッククラウドのGoogle App Engineは、スケーラビリティに優れ、開発環境をはじめ必要なインフラの多くをほぼ無料で提供する。個人利用には適しているが企業利用ではまだ多様な課題を残している。
本連載ではパブリッククラウドを使った企業向けシステム構築について解説している。第1回はAmazon Web Services、第2回はForce.comを取り上げた。今回は「クラウド」という言葉を最初に使ったとされるGoogleが提供している「Google App Engine」（以下、GAE）を取り上げる。毎度申し上げていることではあるが、変化の激しい分野でもあるので、記載されている情報は原稿執筆時点のものであることをご了解いただきたい。
GAEの成り立ち
検索エンジンで創業したGoogleだが、今では何十万人ものユーザーを抱えるフリーのメールやカレンダー、世界中をカバーする地図情報などを提供する「超巨大情報企業」であることは周知の事実である。われわれは日ごろ、これらのサービスを便利に使っているが、少し考えればその裏に膨大なコンピュータリソースと、高度な利用技術が潜んでいることは想像に難くない。その神髄は、無尽蔵ともいえるデータをとにかく蓄積し、かつユーザーのリクエストに応じて瞬時に引き出す技術、そしてこれらのコンピュータリソースを、24時間365日、無停止で運用し続けるノウハウである。
GAEはこの情報インフラの一部を一般ユーザーに開放しているサービスだ。当然、企業が自社のためにこれを利用することも可能である。
GAEの概要
GAEは2008年にリリースされたサービス（PaaS：Platform as a Service）である。Googleが自社サービスのために構築したインフラを利用するため、さまざまな恩恵がある一方で、制約も大きいのが特徴である。
多種多様なGoogleのサービスのほとんどが、Webブラウザさえあれば利用できる。つまり、Google自体が大きな「Webアプリケーション」の集合体と考えられる。GAEはこの延長線上にあり、ユーザーが構築できるアプリケーションは「Webアプリケーション」に限定される。「Googleが提供している（メールやカレンダーなどの）アプリケーションを、一般のユーザーも構築・提供できるようになる」というのがオリジナルのコンセプトである。
当初は、開発言語としてGoogleが標準的に採用しているPythonしか利用できなかったが、2009年4月からはJavaでの開発が可能になった。また、2010年5月には「Google App Engine for Business」という構想を発表し、エンタープライズ向けの機能強化のロードマップをアナウンスしている（後述）。
得意分野はWebアプリケーション
前述のような出自であるので、「Webアプリケーション」を単品で開発・運用する場合には圧倒的な強みを発揮する。
例えば、一般消費者向けにWebで公開するサービスを構築しようとした場合、従来であれば、ピークアクセスの想定に合わせて、サーバ機器、ファイアウォール、ロードバランサ、ネットワーク回線などを調達し、組み合わせ、その上で開発環境、ステージング環境、本番環境を「事前準備」する必要があった。本来の目的であるアプリケーションの開発は「その後」の話となってしまう。また、アプリケーション公開後も、運用監視、セキュリティパッチ適用、バックアップ、データ削除など、さまざまな「付帯業務」が不可避であり、コスト増大要因となっていた。
GAEを利用した場合、極論すると前述の事前準備も付帯業務も不要になる。
スケーラビリティに優れる
特にピークアクセス想定に基づくキャパシティープランニングは、従来はわれわれのようなシステムインテグレーターの腕の見せどころだったわけだが、GAE上に構築すれば（少なくとも1日当たり数百万アクセスまでは）何も気にする必要がない。アクセスが集中すれば処理能力が自動的にスケールアウトするからだ。そして、ユーザーが意識して設定などを行う必要もまったくない。ユーザーが構築したアプリケーションは、まさに「Googleの一部」であるかのように動作する。
かなりの水準まで無料で利用できる
気になるお値段だが、「かなりの水準まで無料」といっていいだろう。まず、開発環境（ローカルPCなどにインストールする）が無料で提供される。前後してGoogleのアカウントを取得する必要があるが、これも無料である。ローカルで開発したアプリケーションは、アカウントを経由してGoogle上にアップされ、指定されたURL上で動作を始める。この段階でもまだ料金は掛からない。データベース（後述）にデータを記録しても、500Mバイトまでは無料。このWebアプリケーションを多数の人が閲覧するようになり、PV（ページビュー）が膨大になっても、月間500万PVまでは無料である。これ以外にもさまざまな「無料枠」があるが、よほどのことがないかぎり無料枠を超えることはなさそうだ。SNSサービスやオンラインゲームなどがGAE上に構築されている例があるが、多数の利用者が居るにもかかわらず、Googleへの支払いは月間数ドルから数十ドルにとどまっているといわれている。
限度を超えたら課金されるかというと、そうではない。何しろこの時点までユーザーはGoogleに対して支払方法を示していない（＝クレジットカード番号を登録していない）のである。無料枠以上の利用があれば、単に「それ以上は使えない状態」になる。正常に動作させたい場合には、あらかじめ有料の「割当量」を1日単位で設定する。有料の割り当てを行っても実際の利用状況が無料枠を超えていない場合には課金されない。また、設定した有料枠（によって割り当てられたリソース）を超えた利用もできないので、支払額が当初登録の金額（上限値）を超えることもない。
企業利用におけるさまざまなハードル
前述の通り、アプリケーションはGoogleアカウントにひも付けられて管理される。あのGmailやGoogleカレンダーを利用する際に、誰でも無料で取得できるアカウントである。Googleの出自を考えれば、現時点では主に一般ユーザー（個人）での利用が想定されているといってよいだろう（当然、Webアプリケーションについて専門知識と熱意を有する限られたユーザー向けではある）。いずれにせよ企業（チーム）で利用するには多少のハードルが付きまとうようだ。
例えば、開発環境については無料で提供されると述べたが、非常に簡素かつ低機能なものである。PC1台で開発、テスト、本番環境（GAE）へのデプロイができてしまうので、1人で開発している分にはまったく問題がない（むしろ便利）だが、逆に言えば、チーム開発には適していない。また、バージョン管理、GUI開発など、通常のエンタープライズシステム開発に必要と想定される機能はほとんど具備されていない。
データベースについては、有名なBigTableと呼ばれる機能を利用する。BigTableについてはさまざまなところで解説・言及されているのでここでは詳細は繰り返さないが、企業システムで一般的に利用されるリレーショナルデータベース（RDB） とはまったく異なるデータ構造（KVS：Key-Value Store）のものであり、コミットや排他の考え方も根本から違っている。従って、企業ユーザーが現在自社で保有しているWebアプリケーションを「そのまま」GAEに載せ替えることはほとんど不可能である。新規のアプリケーションをゼロから設計するにしても、既存のRDBの知見はほとんど役に立たないといっていい。BigTableを正しく使えばそれこそ「Google並の」パフォーマンスが得られるので、ぜひとも利用してみたいところではあるが、その際には一定のノウハウを持つSIベンダーの協力を仰ぐ必要があるだろう。
GAEは第2回で紹介したForce.com（参照：「豊富なテンプレートを備えたアプリケーションプラットフォーム『Force.com』」）同様に、「複数のユーザーが相乗りして利用するPaaS基盤」である。従って「全ユーザーに安定したパフォーマンスを保証するために、個々のプログラムにはさまざまな制限が課せられている」という特性も共通している。制限は「割り当て制限」と呼ばれ、1回のクエリ当たりの件数の上限（1000件）や、1プログラム当たりの実行時間の制限（30秒）、メール送信プログラムの呼び出し回数や、メール発信数の制限など、多様なものがある。有料で制限が緩くなるものもあるが、当然ながら上限もある。またいくらお金を積んでも緩和されないものもある。
これらの「制限」は、開発者が従来的なプログラミングのパラダイムに縛られている限り、「非常に強い制限」であり続けるだろう。発想を転換して根本から設計を見直し、「Google流」の実装をする必要がありそうだ。この流儀に慣れている開発者にとっては難易度は低いが、従来型の開発者にとっては試行錯誤を伴う作業となるだろう。ノウハウはWebや書籍の形で流通しているので、上手にすくい上げながら開発を進めたい。
将来性
開発の難しさを強調し過ぎてしまったかもしれないが、Googleもビジネスユーザーの拡大を望んでいることは事実であり、「難しさ」を緩和する施策を打ち出している。2010年5月には、企業ユーザー向けのサービス拡充の一環として「Google App Engine for Business」をアナウンスした。機能の多くは現在「試供品」（限定ユーザー向けプレビュー）との位置付けだが、著名なJavaの開発フレームワーク「Spring Framework」の導入や、RDBのサポート、アプリケーションの一元管理を可能にするコンソールなどが提供される予定である。SLAも導入され、価格体系もシンプルになる（企業ユースでも月間8ドルから）。アナウンス通りの、いや、期待以上の機能が早期に正式リリースされることを期待したい。企業向けシステムでの利用に弾みが付くことは間違いないだろう。
以上、簡単ではあるが、GAEの特徴を整理した。大規模Webサイトの構築などを検討される際に参考にしていただければ幸いである。次回は、「Windows Azure」を取り上げる。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[ゾーホージャパン株式会社] サイバー攻撃からネットワークを守る上で確実に押さえておきたいポイントとは？ -
事例
[アルプス システム インテグレーション株式会社] 中小企業でも安心して活用できる「手ごろなSOCサービス」とは？ -
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した？ 事例に学ぶ戦略立案＆実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
3
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
4
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
5
Microsoft激怒のゼロデイ脆弱性「無断公開」 パッチを待つのが危険な理由
-
6
「Oracle Database」のサポート体系が変更 料金への影響は？
-
7
Windows Server 2025移行の“超難関”「Active Directory」問題解決ガイド
-
8
「Excel管理」では限界――製造現場の改善が進まない“隠れた原因”
-
9
積水化学が挑む「データ経営」の核心：SAP S/4HANA Cloud導入の狙いとは
-
10
データセンター事業者が「脱VMware」をした“例のライセンス問題”じゃない理由
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー