AppScaleでApp Engine互換のクラスタ環境を構築する
今回紹介する「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だ。
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）。
ここで右上の「Login」をクリックし、AppScaleクラスタの起動時に入力したメールアドレスとパスワードを使ってログインすると、AppScaleの管理をWebブラウザから行えるようになる（図3）。
ここではクラスタを構成する各ノードの稼働状況やアプリケーションの実行状況の確認、アプリケーションのデプロイや削除といった操作が可能だ。
アプリケーションのアップロードと実行
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）。
管理コンソールからアプリケーションをアップロードしてデプロイすることも可能だ。管理コンソールの左メニュー内にある「Upload App」をクリックすると「Upload an Application」画面が表示されるので、ここでアップロードしたいアプリケーションの構成ファイルが含まれるZIPファイルもしくはTAR.GZファイルを選択して「Upload」をクリックする（図5）。
アップロードが完了すると「Application uploaded successfully」との文言が表示される。ここで管理コンソールのトップページ（Clous Status画面）を見ると、アップロードしたアプリケーションが「Current Applications Deployed」に追加される（図6）。
ここで「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）。
複数台のマシンを使ったクラスタ環境を作る
AppScaleでは、複数台のマシンを使ったクラスタ環境も簡単に構築できる。続いてはこういった複数台によるクラスタ環境構築について紹介しよう。
AppScaleクラスタでは、クラスタを構成する各ノードに対し複数の役割（ロール）を設定できるようになっており、クラスタを構成する各ノードにどのようなロールを割り当てるかは、AppScalefileの「ips_layout」項目で指定できる。設定できる値は表1のとおりだ。設定を容易にするため、「master」や「controller」、「servers」といった複数のロールを指定できるキーワードも用意されている。
| ロール名 | 説明 |
|---|---|
| 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）。
この場合、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）。
複数ノードでクラスタを構成した場合でも、アプリケーションのデプロイや管理方法は単一ノードで構成した場合と同じだ。また、デプロイしたアプリケーションがどのappengineノードで実行されるかはAppScaleによって自動的に管理される。実際にどのノードでかどうしているかは管理コンソールなどで確認可能だ（図10）。この例では、192.168.1.110および192.168.1.111という2つのノードにアプリケーションがホスティングされていることが分かる。
アプリケーション開発現場だけでなく運用面でもメリットがあるAppScale
このように、AppScaleの設定や利用は非常に簡単であり、サーバーさえ用意できれば1時間もかからずにアプリケーションを実行できる環境を用意できる。アプリケーションの開発時における試作やApp Engineアプリケーション開発のトレーニング、テストなどの際に有用だろう。
また、AppScaleを利用する最大のメリットとして、App Engineの運営元（Google）による制限・制約を回避できるという点がある。App EngineはあくまでGoogleが提供している商業サービスであり、アプリケーションの実行には一定の制限が課されている。また、リソースの使用量が一定未満であれば無料で利用できるいっぽうで、アプリケーションの使い方によっては開発・テスト段階でも料金の支払いが必要となってしまう場合がある。
さらに、AppScaleではCPUやネットワーク帯域、APIの呼び出しといったリソースの使用量に対し1日辺りの制限があり、これを超えるとサービスが利用できなくなってしまうという問題もある。AppScaleでは自前のサーバーで運用している限りはこのような問題が発生せず、アプリケーション運用のためのコストを予測しやすい。これもAppScaleのメリットの1つと言えるだろう。App Engine向けアプリケーション開発に興味がある開発者やApp Engineでの制約について悩まされているユーザーは、ぜひAppScaleを試してみてはいかがだろうか。