ハンズオン後編：アプリケーションのスケールアウトとブルーグリーンデプロイメント
続いて、ハンズオンの後編である。ここでは最初に、アプリケーションのスケールアウトが、PWSではいかに簡単に実行できるかを体験した。2つ目のサンプルアプリケーションは、アクセスしたアプリケーションのインスタンス番号を表示するというものだ。このアプリケーションをプッシュした後、“cf scale”コマンドを実行して、アプリケーションのインスタンスを5つへ増やす。
$ cf scale appichigo02 -i 5
appichigo02は、プッシュ時に参照される設定ファイル「manifest.yml」で指定した、このアプリケーションのホスト名である。“cf app”コマンドを使うと、PCFから稼働中のapp-ichigo-02アプリケーションに関する情報を取得し、インスタンスが5つに増えていることを確認できた。
$ cf app app-ichigo-02
Showing health and status for app app-ichigo-02 in org Org-Ichigo / space development as (PWSに登録したメールアドレス)...
name: app-ichigo-02
requested state: started
instances: 5/5
usage: 128M x 5 instances
routes: appichigo02.cfapps.io
last uploaded: Mon 08 May 16:22:37 JST 2017
stack: cflinuxfs2
buildpack: python 1.5.18
state since cpu memory disk details
#0 running 2017-04-06T07:24:09Z 0.1% 8.2M of 128M 164.9M of 1G
#1 running 2017-04-06T07:29:43Z 0.2% 8.2M of 128M 164.9M of 1G
#2 running 2017-04-06T07:29:43Z 0.2% 8.3M of 128M 164.9M of 1G
#3 running 2017-04-06T07:29:43Z 0.2% 8.3M of 128M 164.9M of 1G
#4 running 2017-04-06T07:29:42Z 0.0% 8.2M of 128M 164.9M of 1G
また、PCFでは特定のインスタンスへアクセスが集中しないように、5つのインスタンスの間でアクセスを振り分け、ロードバランスを自動的に効かせてくれる。実際に、セミナー会場のパソコンやスマートフォンでアプリケーションにアクセスしてみると、表示されるインスタンス番号が毎回異なった。アクセス先のインスタンスが振り分けられている証拠である。
次に体験したのは「ブルーグリーンデプロイメント（Blue Green Deployment）」。ブルーグリーンデプロイメントとは、稼働中のアプリケーションに対してパッチの適用やアップグレード、古いバージョンへのロールバックを行う場合に、アプリケーションのダウンタイムを最小化するための手法。具体的には、現行バージョンと並行して、変更を加えたバージョンのアプリケーションをしばらく稼働させ、ユーザーに両者を区別なく利用してもらい、問題がないかどうかを確認する。変更を加えたバージョンでも問題のないことが明らかになったら、現行バージョンから変更を加えたバージョンへ切り替えるというものだ。
次図は、このハンズオンで体験したブルーグリーンデプロイメントの流れである。
xxx-blueが現行バージョン、xxx-greenが変更を加えたバージョンのアプリケーションで、アプリケーションにアクセスするURL（これをルートという）はxxx-pro.cfapps.ioである。xxx-temp.cfapps.ioで進めていたxxx-greenの開発が終わったので、これからブルーグリーンデプロイメントでxxx-greenの動作確認を行う（図のBeforeの状態）。そのため、xxx-pro.cfapps.ioでもxxx-greenにアクセスできるようにし、ユーザーにはxxx-blueとxxx-greenのどちらにアクセスしているか分からなくしてアプリケーションを利用してもらう（図のDuringの状態）。それで何も問題がなければxxx-greenへ移行して差し支えないと判断し、xxx-pro.cfapps.ioからxxx-blueへのルートを削除して、xxx-greenへの移行を完了させる（図のAftreの状態）。
まず、上図のBeforeの状態を作る（①）。xxx-blueアプリケーションをxxx-pro.cfapps.ioというルートで、xxx-greenアプリケーションをxxx-temp.cfapps.ioというルートでプッシュした（市古はxxxをichigoとした）。次に、Durgingの状態を作るため、xxx-greenに、xxx-blueと同じxxx-pro.cfapps.ioというルートを付加する（②）。これは“cf map-route”コマンドを使って行う。最後にAfterの状態を作るため、“cf unmap-route”コマンドでxxx-blueへのルートと、xxx-greenへの元のルート（xxx-temp.cfapps.io）を削除する。
①Beforeの状態を作る。xxx-blueのコードはblueディレクトリ、xxx-greenのコードはgreenディレクトリに入っていた。 $ cd blue $ cf push xxx-blue -n xxx-pro $ cd ../green $ cf push xxx-green -n xxx-temp ②Duringの状態を作る。 $ cf map-route xxx-green cfapps.io -n xxx-pro ③Afterの状態を作る。 $ cf unmap-route xxx-blue cfapps.io -n xxx-pro $ cf unmap-route xxx-green cfapps.io -n xxx-temp
なお、各状態で正しくアプリケーションが稼働し、ルートを追加、削除できたことを確認するため、折に触れて“cf apps”コマンドを用いた。
また、「アプリケーションのスケールアウトと新バージョンへの移行って、実は面倒だったり、神経をすり減らしたりするんじゃなかったけっけ？」というのが、市古の偽らざる感想のようだ。ハードウェアからミドルウェア、ランタイムまでの管理や操作をクラウド側でやってくれることのありがたさ、便利さ。たった1つや2つのコマンドを発行するだけで、あとは「おまかせ」なのである。コンテナ技術のメリットを活かす面でも、PaaSは積極的にトライしてみる価値があるだろう。
ここまでで当初予定のハンズオンは終了である。ただ、この日は時間が残ったということで、キーバリューストア「Redis」のサービスをアプリケーションに追加する作業まで行うことができた。最後に吉田氏は「PaaSはデジタル変革に最適なプラットフォームです。そしてPFCは実績豊富なエンタープライズPaaSです。今日のハンズオンで簡単に使えることがお分かりいただけたと思います。ぜひ今後活用してみてください」と述べ、セミナーを締めくくった。
【無料】PaaSハンズオンセミナーを受講してみませんか！
本稿でレポートしているPaaSハンズオンセミナーは、どなたでも受講できます。受講は無料です。詳細やお申し込みは、こちらのWebサイトをご覧ください。
