今回紹介する「AppScale」は、App Engine向けのアプリケーションをローカルやIaaS型クラウド上で実行させるためのフレームワークだ。今回はこのAppScaleを使い、App Engine SDKを使って開発したアプリケーションを実行できるクラスタ環境を構築する流れを紹介する。

App Engineアプリをほかの環境で動かせる

Google App Engine(以下、App Engine)はアプリケーションの実行環境を提供するPaaS(Platform as a Service)型クラウドサービスの1つだ。Googleが提供しているということもあり知名度は高いが、さくらのクラウドなどIaaS(Infrastructure as a Service)型クラウドと比べるとPaaS型クラウドは制約が多く、また料金体系も複雑ということで、ハードルの高さを感じる人は少なくないだろう。

今回紹介する「AppScale」は、このApp Engine向けのアプリケーションをローカルやIaaS型クラウド上で実行させるためのフレームワークだ。これを利用することで、App Engine SDKを使って開発したアプリケーションをローカルにあるサーバーやクラウド、VPS、専用サーバーなどで実行させることが可能になる。

AppSacleはカリフォルニア大学サンタバーバラ校で開発の研究プロジェクトとして開始され、現在は開発者らが創業したAppScale社によって開発が進められている(図1)。ライセンスはApache 2.0だ。

図1 AppScaleの開発元であるAppScaleのWebサイト
図1 AppScaleの開発元であるAppScaleのWebサイト

AppScaleの特徴と長所

App Engineでは、稼動させるアプリケーションがWebアプリケーションに限定されるものの、Webアプリケーションフレームワークや各種APIが提供され、サーバーインフラについては面倒を見なくて良いという利点がある。AppScaleではインストーラやあらかじめ一通りの環境が構築された仮想マシンイメージが用意されており、これらを利用することで簡単にApp Engineと互換性のある環境を用意できる。

さらに、複数台のマシンから構成されるクラスタ環境を構築することも可能だ。ネットワークやサーバーといったインフラを用意する必要はあるものの、アプリケーション開発の際に問題になることがある依存性や周辺ライブラリの互換性問題などに気を払わずにアプリケーション開発に専念できるというメリットがある。

また、AppScaleはApp Engine向けアプリケーションのテストやデバッグなどにも有用だ。Googleが配布するApp Engine SDKにはローカルで起動する開発用のWebサーバーが含まれているものの、これを使ってアプリケーションを実行させる場合、LAN内などの閉じたネットワーク外からアプリケーションにアクセスさせるのはやや面倒になる。こういった場合にAppScaleを利用すれば、グローバルに公開されているテスト用サーバー上でアプリケーションを実行できる。

さらに、何らかの事情でApp Engine上で稼動させているアプリケーションを自前で管理しているサーバー上に移動させる、といった用途にもAppScaleは利用できる。たとえばサーバーの要件などでApp Engineが利用できない場合にAppScaleを代替として利用できるのだ。

なお、AppScaleはAppScale Systemsによって開発が進められている。GoogleはAppScale Systemsとの協力体制についても発表しており、今後App EngineとAppSacleの互換性強化など、相互運用を高めるための取り組みを進めていくとしている。

AppScaleをインストールする

さて、それではAppScaleを試すための環境構築について解説していこう。AppScaleの記事執筆時点での最新版はバージョン2.3.1で、Debian 7(Wheezy)およびUbuntu 12.04(Precise)がサポートされている。また、開発版では14.04(Trusty)もサポートされている。

手っ取り早くAppScaleを利用したいのであれば、仮想マシンイメージを使って仮想マシン上で稼動させるのが簡単だ。AppScaleのダウンロードページではVirtualBoxやKVM、AMI、GCEといった形式の仮想マシンイメージが提供されている。

また、物理マシン上、もしくはさくらのクラウド/VPSなどにインストールしたい場合は、あらかじめDebian 7もしくはUbuntu 12.04がインストールされた環境を用意しておき、そこでインストーラを実行すれば良い。

GitHub上にあるAppScaleのプロジェクトWikiではInstalling AppScale from source on GitHubというドキュメントが公開されており、基本的にはこちらに従えば良いのだが、いくつか注意点がある。

まず、今回はDebian 7(Wheezy)環境でテストを行ったが、この環境ではパッケージリポジトリとしてwheezy-backportsリポジトリが必要であった。これは、下記の内容を「/etc/apt/sources.list」ファイルに追加すれば利用可能になる。

deb     http://mirrors.kernel.org/debian wheezy-backports main contrib
deb-src http://mirrors.kernel.org/debian wheezy-backports main contrib

また、AppScaleが必要とするパッケージとしてsendmailが指定されているが、Debian 7の標準インストールではMTAとしてsendmailではなくeximが採用されている。そのため、事前にsendmail-binパッケージをインストールしてsendmailを利用できるようにしておく必要がある。

apt-get install sendmail-bin

そのほか、/etc/hostsファイルなどの設定でホスト名からIPアドレスを解決できるようにしておく必要もある。複数のIPアドレスが振られている環境などでは特に注意したい。

もう1つの注意点として、インストールするバージョンの選択がある。ドキュメントでは「http://bootstrap.appscale.com」からダウンロードしたシェルスクリプトをそのまま実行しているが、この場合GitHub上にあるmasterリポジトリの開発版コードがチェックアウトされてインストールされる。開発版は環境によっては不安定である場合もあるので、今回は以下のようにしてシェルスクリプトをダウンロードした後、「–tag」オプションでチェックアウトするタグ(今回は2.3.1)を引数として指定して実行した。

# cd /root
# wget -O appscale.sh http://bootstrap.appscale.com
# sh appscale.sh --tag 2.3.1

なお、このシェルスクリプトはroot権限で実行する必要がある。また、HTTPでダウンロードしたコードということで、念のため実行前にシェルスクリプトの内容をチェックしておこう。

このシェルスクリプトを実行すると、まずGitHub上にある「appscale」および「appscale-tools」リポジトリがクローンされ、続いてAppScaleが使用する各種関連ソフトウェアなどがダウンロードされてインストールされる。ただし、配布サーバーの不調などによってダウンロードに失敗する場合もあるようだ。もしダウンロードに失敗した場合、作成されたappscaleディレクトリ内で「git clean」コマンドを実行して中間ファイルを削除してから再実行しよう。

# cd appscale
# git clean -f -d -X
# git clean -f -d -x

1台のマシンでAppScale環境を構築する

AppScaleのインストールが完了したら、続けてクラスタの設定を行っていく。まず、適当なディレクトリを作成し、そのディレクトリ内で「appscale init cluster」コマンドを実行する。

$ mkdir appscale-test
$ cd appscale-test
$ appscale init cluster
AppScalefile successfully created! Be sure to customize it for your particular cloud or cluster.

ここでは、「appscale-test」というディレクトリを作成し、そこで「appscale init cluster」コマンドを実行した。すると、「AppScalefile」という名称の設定ファイルが作成される。このファイルには、どのようにAppScaleを稼動させるかといった設定情報がYAML形式で記述されている。デフォルトではいくつかの設定例が記載されているが、まず必要なのはクラスタを構成するマシンのIPアドレス設定だ。これはAppScalefileの先頭に記述されている、「ips_layout」以下で行う。

---
# The deployment strategy (roles -> machines) that should be used in this
# AppScale deployment.
# The following is a sample layout for running everything on one machine:
ips_layout :
  master : 192.168.1.2
  appengine : 192.168.1.2
  database : 192.168.1.2
  zookeeper : 192.168.1.2

デフォルトでは、「master」および「appengine」、「database」、「zookeeper」という4つのコンポーネントをそれぞれ「192.168.1.2」というIPアドレスが与えられた1台のマシン上で実行するよう設定されているので、これを適切なものに変更しておこう。以下ではこれらを「192.168.1.10」に設定している。

設定ファイルの編集後、「appscale up」コマンドを実行するとAppScaleクラスタが起動する。なお、このとき「master」に指定したサーバーにrootアカウントでSSHリモートログインができるようになっている必要がある。

$ appscale up
Executing ssh-copy-id for host: 192.168.1.10
  
  
UserAppServer is at 192.168.1.10
Enter your desired admin e-mail address: hirom@example.com  ←管理者のメールアドレスを入力する
Enter new password:  ←管理コンソールのログインに使用するパスワードを入力する
Confirm password:  ←同じパスワードを再度入力する
Creating new user account hirom@example.com
Creating new user account hirom@192.168.1.10
Your XMPP username is hirom@192.168.1.10
Granting admin privileges to hirom@osdn.jp
AppScale successfully started!
View status information about your AppScale deployment at http://192.168.1.10:1080/status

「appscale up」コマンドを実行すると、管理用のメールアドレスとパスワードの入力が求められる。これは次で述べる管理コンソールへのログインに使用するので、適切なものを入力しよう。設定が完了するとAppScaleクラスタが起動し、管理コンソールにアクセスするためのURLが表示される。

また、稼働したAppScaleクラスタを停止させるには「appscale destroy」コマンドを実行すれば良い。

$ appscale destroy
Terminating instances in a virtualized cluster with keyname appscale2fa49289b7674ae39cddea53d414acd0
Shutting down AppScale API services at 192.168.1.10
Terminated AppScale on 1 machines.
Successfully shut down your AppScale deployment.

管理コンソールの利用

AppScaleクラスタの起動時に表示されるURL(上記の例の場合、「http://192.168.1.10:1080/status」)にWebブラウザでアクセスすると、AppScaleの管理コンソールが表示される(図2)。

図2 AppScaleの管理コンソール
図2 AppScaleの管理コンソール

 ここで右上の「Login」をクリックし、AppScaleクラスタの起動時に入力したメールアドレスとパスワードを使ってログインすると、AppScaleの管理をWebブラウザから行えるようになる(図3)。

図3 ログイン後のAppScale管理コンソール(Cloud Status)
図3 ログイン後のAppScale管理コンソール(Cloud Status)

 ここではクラスタを構成する各ノードの稼働状況やアプリケーションの実行状況の確認、アプリケーションのデプロイや削除といった操作が可能だ。

アプリケーションのアップロードと実行

AppScaleでアプリケーションを実行するには、作成したアプリケーションをAppScaleクラスタにアップロードする必要がある。今回はPythonで実装した単に「Hello, World!」という文字列を返すだけのWebアプリケーションを用意し、これをAppScaleクラスタにアップロードして実行させてみよう。

今回用意したアプリケーションのコード(helloworld.py)は次のようになっている。

import webapp2

class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        self.response.write('Hello, World!')

application = webapp2.WSGIApplication([('/', MainPage),],
                                      debug=True)

また、App Engine向けのアプリケーションでは、アプリケーション本体コードに加えて設定ファイルが必要だ。今回は次のような設定ファイル(app.yaml)を用意した。

application: helloworld
version: 1
runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /.*
  script: helloworld.application

今回はこの2つのファイルを、~/appengine-hello-world/ディレクトリに格納した。これをAppScaleにアップロードして実行させるには、AppScaleの起動に使用したAppScalefileが存在するディレクトリで次のように「appscale deploy」コマンドを実行する。

$ appscale deploy ~/appengine-hello-world/
Enter your desired e-mail address: hirom@example.com
Uploading initial version of app helloworld
We have reserved helloworld for your app
Ignoring .pyc files
Tarring application
Copying over application
Please wait for your app to start serving.
Waiting 1 second(s) to check on application...
Waiting 2 second(s) to check on application...
Waiting 4 second(s) to check on application...
Waiting 8 second(s) to check on application...
Waiting 16 second(s) to check on application...
Your app can be reached at the following URL: http://192.168.1.10:8080

コマンドを実行するとメールアドレスの入力が求められ、続いてアップロードおよびアプリケーションの実行が行われる。アプリケーションが起動したら、提示されたURLにアクセスするとそのアプリケーションにアクセスできる。

実行中のアプリケーションに関する情報は、「appscale status」コマンドで確認できる。

$ appscale status
Status of node at 192.168.1.10:
    Currently using 0.0 Percent CPU and 128.00 Percent Memory
    Hard disk is 21 Percent full
    Is currently: load_balancer, taskqueue_master, zookeeper, db_master, taskqueue, memcache, shadow, login, appengine
    Database is at 192.168.1.10
    Is in cloud: cloud1
    Current State: Preparing to run AppEngine apps if needed
    Hosting the following apps: helloworld
    The number of AppServers for app helloworld is: 1

View status information about your AppScale deployment at http://192.168.1.10:1080/status

また、管理コンソールの「App Console」からもアプリケーションの稼働状況を確認可能だ(図4)。

図4 管理コンソールの「App Console」画面
図4 管理コンソールの「App Console」画面

 管理コンソールからアプリケーションをアップロードしてデプロイすることも可能だ。管理コンソールの左メニュー内にある「Upload App」をクリックすると「Upload an Application」画面が表示されるので、ここでアップロードしたいアプリケーションの構成ファイルが含まれるZIPファイルもしくはTAR.GZファイルを選択して「Upload」をクリックする(図5)。

図5 アプリケーションのアップロードを行う「Upload an application」画面
図5 アプリケーションのアップロードを行う「Upload an application」画面

 アップロードが完了すると「Application uploaded successfully」との文言が表示される。ここで管理コンソールのトップページ(Clous Status画面)を見ると、アップロードしたアプリケーションが「Current Applications Deployed」に追加される(図6)。

図6 アップロードしたアプリケーションが「Current Applications Deployed」以下に追加される
図6 アップロードしたアプリケーションが「Current Applications Deployed」以下に追加される

 ここで「loading」の表示が消えると、アプリケーションが実行可能となり、アプリケーション名をクリックすることでそのアプリケーションにアクセスできる。

なお、デプロイしたアプリケーションの削除は「upscale remove」コマンドで行える。たとえば「echo」アプリケーションを削除したい場合、次のように実行する。

$ appscale remove echo
Are you sure you want to remove this application? (Y/N) Y
Please wait for your app to shut down.
Done shutting down echo

アプリケーションを本当に削除するかの確認が行われ、「Y」を入力すると削除が実行される。また、管理コンソールの「Delete App」からもアプリケーションの削除を実行できる(図7)。

図7 管理コンソールの「Delete App」をクリックすると表示される「Delete an application」画面
図7 管理コンソールの「Delete App」をクリックすると表示される「Delete an application」画面

複数台のマシンを使ったクラスタ環境を作る

AppScaleでは、複数台のマシンを使ったクラスタ環境も簡単に構築できる。続いてはこういった複数台によるクラスタ環境構築について紹介しよう。

AppScaleクラスタでは、クラスタを構成する各ノードに対し複数の役割(ロール)を設定できるようになっており、クラスタを構成する各ノードにどのようなロールを割り当てるかは、AppScalefileの「ips_layout」項目で指定できる。設定できる値は表1のとおりだ。設定を容易にするため、「master」や「controller」、「servers」といった複数のロールを指定できるキーワードも用意されている。

表1 AppScaleクラスタで各マシンに与えることができるロール
ロール名 説明
appengine デプロイされたアプリケーションを実行する
database データベース関連サービスを提供する
memcache memcachedによるキャッシュサービスを提供する
login ログイン機能およびデプロイされたアプリケーションへのルーティング(ロードバランサ)を提供する
zookeeper メタデータなどの管理を提供する
shadow 各ノードの稼働状況を監視する
taskqueue タスクキューを提供する
open デフォルトでは何もしないが、状況に応じて他ノードの仕事を肩代わりする予備ノードとなる
master shadowおよびアプリケーションへのルーティング(ロードバランサ)を提供する
controller masterおよびdatabase、memcache、login、zookeeper、taskqueueを提供する
servers appengine、memcache、database、taskqueueを提供する

なお、AppScaleの稼動に必要なロールが揃っていない場合、状況に応じて自動的に適切なノードにそのロールが割り当てられる。たとえばloginロールやzookeeperロール、taskqueueロールがどのノードにも割り当てられていない場合、shadowロールが割り当てられているノードにそれらが割り当てられるようになっている。また、appengineロールが割り当てられたノードについては、taskqueueロールが割り当てられていない限り自動的にtaskqueueのスレーブとして動作する。

さらに、明示的にmemcacheロールを割り当てたノードが存在しない場合、appengineロールが割り当てられたノードすべてにmemcacheロールが割り当てられる。これらロール割り当ての詳細についてはappscale-tools内のソースコード(/lib/node_layout.py)を参照してほしい。

たとえば次の例は、1台を「マスターサーバー」とし、アプリケーションを実行させるサーバー(AppEngine)を2台使用する場合の設定だ(図8)。

図8 3台のマシンを利用してAppScaleクラスタを構築する例
図8 3台のマシンを利用してAppScaleクラスタを構築する例

 この場合、192.168.1.50というIPアドレスを持つノードはshadowおよびロードバランサ、database、zookeeper、login、taskqueueを提供し、192.168.1.110および192.168.1.111というIPアドレスを持つノードがappengineとmemcache、taskqueueのスレーブ機能を提供することになる。

ips_layout :
  master : 192.168.1.50
  database : 192.168.1.50
  zookeeper : 192.168.1.50
  appengine :
    - 192.168.1.110
    - 192.168.1.111

login_host: 203.0.113.1

また、クラスタ環境を構築する場合、外部からアクセスできるサーバーが限られるのが一般的だ。上記の例では「192.168.1.*」というIPアドレスはプライベートIPアドレスであり、LAN外からはアクセスできない。こういった場合、「login_host」設定項目に外部からアクセスできるIPアドレスを指定しておく。

ノードを構成する各マシンにAppScaleをインストールした後、masterで指定したマシン上でAppScalefileの生成およびその編集を行って「appscale up」コマンドを実行すると、AppScaleクラスタが稼動する。正常にクラスタが稼動している場合、管理コンソールで各ノードの情報が表示されるはずだ(図9)。

図9 管理コンソールでクラスタを構成する各ノードの情報を確認できる
図9 管理コンソールでクラスタを構成する各ノードの情報を確認できる

 複数ノードでクラスタを構成した場合でも、アプリケーションのデプロイや管理方法は単一ノードで構成した場合と同じだ。また、デプロイしたアプリケーションがどのappengineノードで実行されるかはAppScaleによって自動的に管理される。実際にどのノードでかどうしているかは管理コンソールなどで確認可能だ(図10)。この例では、192.168.1.110および192.168.1.111という2つのノードにアプリケーションがホスティングされていることが分かる。

図10 管理コンソールでアプリケーションがホスティングされているノードを確認できる
図10 管理コンソールでアプリケーションがホスティングされているノードを確認できる

アプリケーション開発現場だけでなく運用面でもメリットがあるAppScale

このように、AppScaleの設定や利用は非常に簡単であり、サーバーさえ用意できれば1時間もかからずにアプリケーションを実行できる環境を用意できる。アプリケーションの開発時における試作やApp Engineアプリケーション開発のトレーニング、テストなどの際に有用だろう。

また、AppScaleを利用する最大のメリットとして、App Engineの運営元(Google)による制限・制約を回避できるという点がある。App EngineはあくまでGoogleが提供している商業サービスであり、アプリケーションの実行には一定の制限が課されている。また、リソースの使用量が一定未満であれば無料で利用できるいっぽうで、アプリケーションの使い方によっては開発・テスト段階でも料金の支払いが必要となってしまう場合がある。

さらに、AppScaleではCPUやネットワーク帯域、APIの呼び出しといったリソースの使用量に対し1日辺りの制限があり、これを超えるとサービスが利用できなくなってしまうという問題もある。AppScaleでは自前のサーバーで運用している限りはこのような問題が発生せず、アプリケーション運用のためのコストを予測しやすい。これもAppScaleのメリットの1つと言えるだろう。App Engine向けアプリケーション開発に興味がある開発者やApp Engineでの制約について悩まされているユーザーは、ぜひAppScaleを試してみてはいかがだろうか。