Google App Engineで開発するスケールするアプリケーション（前編）

Google App EngineとTwitterの連携アプリケーション構築

データセンターを用いた一般的なシステム構築手順

　ここで、今まで考えてきたスケールアウトの手法を考慮に入れて、現在最も一般的であると思われるデータセンターでのハウジングサービスを利用し、会員制のWebサイトを構築することを考えてみます。このサイトは、ある程度の会員数の増大による負荷増大が予想されており、会員が増えた場合はシステムを増強・拡張することが当初から想定されています。

　図7に、想定されるサイトのインフラ構成図を示しました。

図7：ある会員制サイトのインフラ構成

　ここでは、以下のハードウェアを用意することを想定しています。

• ファイアウォール2台（1台はバックアップ用）
• ロードバランサ2台（1台はバックアップ用）
• Webサーバ2台
• アプリケーションサーバ3台
• データベースサーバ4台（会員DB＋取引DBでプライマリ・セカンダリを用意）
• memcacheサーバ1台
• メールサーバ（2台）
• DNSサーバ（プライマリ・セカンダリ）

　上記のシステム構成が構成されるまでには、以下の作業が想定されます。

• データセンター検討、プラン検討、見積もり、契約
• サーバ・機器購入（選定、見積、注文、納品）
• ネットワーク設計
• セキュリティ設計
• 障害時のハードウェア切替え方針検討
• バックアップ方式検討

　上記の作業をするには、当初のキャパシティプランニングも必要です。キャパシティプランニングは、「どの程度のアクセスが当初想定され、サービス開始後、どのように伸びていくのか」「当初の適切なマシン数は何台か」「どれ程度のスペックのマシンが必要なのか」を検討する作業です。ビジネス環境が、短いスパンで激しく変わっていく時代において、未来を見越してシステム全体のスペックを適切に見積もり、決定していくのは、一筋縄では行かない作業であり、高いスキルと経験が必要です。

　また、システム構築の実作業として、ネットワーク構築、サーバ設置、OSインストール、ミドルウェアのインストールなどの作業が必要となります。

　無事にサービスを開始した後も、ハード故障への対応（に備えた保守費の負担）、データバックアップ管理、キャパシティプランニング（実際の会員数、取引数に応じたマシン増強計画）などが必要となります。

　またキャンペーンなどで、一時的なアクセス数の増加が予想される場合にも対処する必要が出てきます。これらのことを考えても、自前でスケールするシステムを構築するのはとても手間とコストがかかり、ビジネスが成功するかどうか分からない段階での投資はリスクが高いことが分かるでしょう。

Google App Engineによって何が変わるのか

　Google App Engineでは自前でシステムを構築する場合に比べて、以下の作業が不要となります。

• 障害時のデータバックアップ対策

――データは、Google File System（以降GFS）の機能によって物理的に分離された3か所のノードに保存されますので、損失の心配はほとんどありません。

• キャパシティプランニング

――アクセス負荷増加に従い、Front End、App Serverの割り当てが自動的に増えます（自動スケーリング）。

• データ増加時のデータベース分割対策

――Bigtableでは、データを自動的に分割して保存しますので、データ保存場所の分割やディスクフルに備えた対策について考慮する必要はありません。

• マシン購入費用

――Googleのマシンを使用できるので、購入する必要はありません。

　これらの必要と考えられていた作業が不要となり、アプリケーションをプログラミングするだけで、スケールするアプリケーションを開発しリリースできることが、Google App Engineの大きなメリットであると言えます。

　ビジネス環境が変わりやすい今だからこそ、初期の開発投資を抑え、スモールスタートを切る必要があります。そのためのインフラ環境として、Google App Engineは適性が高いと言えるのではないでしょうか。