Linux アプリケーションを Amazon クラウドにマイグレーションする: 第 2 回 アプリケーションの信頼性の向上

マイグレーション後の Linux アプリケーションの信頼性を向上させる方法

この記事では、Linux アプリケーションを Amazon クラウドにマイグレーションする方法を説明する連載の第 2 回として、ロード・バランサーと永続ディスクを取り入れることによって、アプリケーションをより堅牢なものにします。複数のサーバーを使用して、データを安全にバックアップする方法を学んでください。

Sean A. Walberg, Senior Network Engineer

Author photoSean Walberg は 1994年以来、学界、企業、およびインターネット・サービス・プロバイダー環境で Linux および UNIX システムに取り組んできました。この数年の間は、システム管理に関する広範な著作活動を行っています。



2010年 8月 03日

この連載の第 1 回目の記事では、手順に沿って 1 台の物理サーバーを 1 台の物理クラウド・サーバーにマイグレーションしました。その甲斐もむなしく、アプリケーションの状態は一向に改善されていません。それは主に、さらに多くの単一障害点が取り込まれてしまったためです。

物理サーバーが 1 台しかないとしても、冗長電源、エラー訂正機能付き RAM、冗長ディスク、そして障害前インジケーターの詳細モニタリングを使用することはできます。クラウド・サーバーで何を使用できるのか、もっと端的に言えば、何にアクセスするのかはユーザーにはわかりません。クラウド・サーバーは概して信頼性がありますが、予防線を張るに越したことはありません。Amazon では信頼性を強化するための追加サービスを提供しているとあっては、それは尚更のことです

クラウド環境にデプロイするときには、いつでも仮想インスタンスを失う可能性があると想定することが賢明です。クラウド・サービスは信頼できないと言っているわけではありません。クラウドで発生するような障害は、クラウドではない環境で慣れている障害とは違うと言っているだけです。そのためアプリケーションには、通信切断に対処し、複数のサーバーでスケーリングするためのインテリジェンスを組み込む必要があります。このような考え方が、どのような環境を対象にアプリケーションを作成しているのであれ、より優れたアプリケーションに仕上がる結果となります。

今回の記事では、Amazon EBS (Elastic Block Store) を使用してデータベースの一時ストレージの能力を高める方法を学びます。また、バックアップをセットアップしてデータの保護をさらに強化します。アプリケーション・サーバーでの損失に対する保護手段としては、複数のインスタンスでロード・バランシングを行い、さまざまな障害から回復できるようにします。

図 1 は、前回の作業が終わった時点でのアプリケーションのアーキテクチャーです。

図 1. 現行のアーキテクチャー
現行のアーキテクチャー

現行のアーキテクチャーでは、すべての構成部分がまとめて 1 つの Amazon EC2 (Amazon Elastic Compute Cloud) インスタンス上にあります。フロントエンドの Web サーバー (nginx) はリクエストを複数の mongrel インスタンスに委任するか、あるいはサーバー自体がリクエストに対して静的ファイルを提供します。mongrel アプリケーション・サーバーは、同じホスト上にある PostgreSQL データベースにアクセスします。

永続ディスクの構成

インスタンス・ストレージは、Amazon EC2 と仮想技術 (VMware や Xen など) とでは大きく異なります。Amazon EC2 インスタンスが提供するのは、一律 10GB のルート・パーティションと、開始されたインスタンスのタイプに応じたサイズのインスタンス・ディスクであることを思い出してください。ルート・パーティションはブート時に AMI (Amazon Machine Image) から複製されるため、インスタンス・ストアは空の状態です。サーバーをシャットダウンすると、インスンス・ストアは失われます。

当初の Amazon のスタンスは、サーバーを頻繁に Amazon S3 (Amazon Simple Storage Service) にバックアップするようユーザーに指示するというものでした。サーバーがクラッシュした場合には、他のサーバーに負荷を引き受けさせるか、あるいは Amazon S3 からデータを取得することになっていました。最終的に Amazon が打ち出した対策は、永続ディスクを提供する EBS というサービスです。これにより、サーバーがクラッシュしても、EBS ボリュームを別のサーバーに接続すれば済むようになります。さらに Amazon では、バックアップを容易にするスナップショット・メカニズムも構築しました。

SmallPayroll アプリケーションのデータベース・サーバーに関する最大の問題は、これが単一障害点であることです。この問題を解決する一般的な方法は 2 つあります。1 つは、2 つのデータベース・サーバーを作成し、互いに引き継げるようにするという方法、もう 1 つは、発生し得るダウンタイムを妥当な長さにまで短縮するという方法です。前者の方法は停止時間を最小限にするものの、複雑であるため、このアプリケーションの場合には後者の方法のほうが遥かに現実的です。そこでこれから、データベース・サーバーがクラッシュした場合には、新しいインスタンスが開始されて、クラッシュしたサーバーに置き換わるようにします。データは、EBS で保護します。新規データベース・サーバーを起動して、クライアントがそのサーバーを指すようにするまでの合計時間は、障害が通知されてから 10 分以内にします。なお、EBS を使用することに付随するメリットとして、EBS ストレージにはインスタンス・ストレージよりも大きな入出力容量が用意されています。

EBS は信頼できるのか

EBS ボリュームは、そのボリュームが接続されているインスタンスがオフに切り替えられたとしても存続しますが、100% 信頼できるソリューションとは言えません。障害から保護するために、EBS ボリュームは同じアベイラビリティー・ゾーン内で複製されますが (「EBS の初期セットアップ」を参照)、それ以外では複製されないためです。さらに、障害が発生する可能性もあり、実際に発生しています。

Amazon では、EBS の障害発生率はボリュームの大きさと、変更の頻度によって変わると言っています。Amazon によると、一般に EBS ボリュームには物理ディスクの 10 倍の信頼性があります。つまり、EBS は RAID 1 のミラーリングとほぼ同程度の信頼性を持つことになります。

幸い、EBS アプリケーション・プログラミング・インターフェース (API) には、データのスナップショットを Amazon S3 に移すためのメカニズムが用意されています。この機能ではボリュームを迅速にバックアップし、Amazon S3 に保管することができるので、少なくとも 3 箇所にデータが複製されます。

EBS を使用するための手順は以下のとおりです。

  1. ec2-create-volume コマンドでボリュームを作成します。
  2. ec2-attach-volume コマンドを実行して、ボリュームを実行中のインスタンスに接続します。
  3. ボリューム上にファイルシステムを作成します。
  4. ファイルシステムをディレクトリーにマウントします。

EBS の初期セットアップ

EBS をセットアップするための最初のステップは、Amazon に対し、ボリュームを作成する意思を伝えることです。その際には、2 つのことが明確になっていなければなりません。1 つはイメージのサイズ (ギガバイト単位)、もう 1 つは、イメージを使用しようと考えているアベイラビリティー・ゾーン (availability zone) です。アベイラビリティー・ゾーンとは、Amazon がサーバーのロケーションを説明するために考案したもので、us-east で始まるゾーンはバージニア州北部にあり、これらのゾーンはリージョン (region) と総称されます。現在、us-east リージョン内にあるゾーンは、us-east-1a、us-east-1b、us-east-1c の 3 つです。それぞれのアベイラビリティー・ゾーンは、他のアベイラビリティー・ゾーンでの障害とは隔離されるように設計されています。また、同じリージョン内にあるゾーンは互いに近くにあるため、ゾーン間の遅延は小さくなっています。

EBS には 1 つの制約があります。それは、ボリュームをマウントできる場所は、そのボリュームが作成されたアベイラビリティー・ゾーンに限られることです。ボリュームを移動する方法はいくつかありますが、ボリュームはサーバーが置かれているアベイラビリティー・ゾーンで作成しなければなりません。

以下のコマンドを実行して、us-east-1a ゾーンに 20GB のボリュームを作成します。

ec2-create-volume -s 20 -z us-east-1a

サーバーがどこにあるのかがわからない場合は、ec2-describe-instances コマンドを実行して調べることができます。サーバーを起動する場所を指定するには、ec2-run-instance コマンドで上記と同じ -z パラメーターを指定します。リスト 1 に、このコマンドとその出力を記載します。

リスト 1. EBS ボリュームの作成
$ ec2-create-volume -s 20 -z us-east-1a
VOLUME  vol-c8791ca1    20              us-east-1a      creating     
2010-07-01T02:52:52+0000

リスト 1 の出力には、ボリュームを作成中であること、そしてボリュームの ID が vol-c8791ca1 であることが示されています。この ID がわかっていて、サーバーのインスタンス ID、そしてサーバーに対してボリュームをどのデバイスとして表すかがわかっていれば、実行中の Amazon EC2 インスタンスにボリュームを接続することができます。以下は、この新しく作成したボリュームを、サービス・インスタンス i-fd15e097 に接続するためのコマンドです。

ec2-attach-volume vol-c8701ca1 -i i-fd15e097 -d /dev/sdj

前回の記事で説明したように、インスタンス ID を調べるには ec2-describe-instances コマンドを実行します。また、ec2-describe-volumes コマンドを実行すると、ボリュームの一覧を表示できることを覚えておいてください。

これで、仮想サーバーには /dev/sdj というディスクが接続されました。サーバーには、このディスクは通常のハード・ディスクのように見えます。あらゆるディスクと同じく、このロー・ディスク上にはファイルシステムを作成しなければなりません。ファイルシステムは、必要に応じて選択肢のなかから選ぶことができます。

  • 標準の ext3 (third extended) ファイルシステムを作成します。
  • XFS ファイルシステムを作成します。これにより、バックアップのためにファイルシステムをフリーズしてスナップショットを取ることができるようになります。
  • ディスクとファイルシステムの間に LVM (Logical Volume Manager) の層を挿入します。こうすると、後で EBS ボリュームを拡張できるようになります。
  • Linux® のソフトウェア RAID を使用して複数の EBS ボリュームをストライピングし、RAID セットの上に XFS または ext3 を配置します。こうすることにより、ディスク・パフォーマンスがさらに向上します。

RAID と LVM は興味深い機能を提供するものの、比較的小さな EBS ボリュームには XFS が最も単純な選択肢となります。XFS のフリーズ機能を EBS スナップショットと併せて使用すれば、一貫性のあるバックアップにすることが可能です。リスト 2 に、XFS ファイルシステムを作成してホストにマウントする方法を記載します。

リスト 2. XFS ファイルシステムの作成およびマウント
# mkfs.xfs /dev/sdj
meta-data=/dev/sdj               isize=256    agcount=8, agsize=32768 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
# mkdir /ebsvol
# mount /dev/sdj /ebsvol

リスト 2 では、まず mkfs.xfs コマンドを実行して /dev/sdj をフォーマットしています (mkfs.xfs コマンドがない場合は、gem install -y xfsprogs を実行してください)。このコマンドの出力は、ファイルシステムのパラメーターを説明するものです。エラーが出ていない限り、この出力は無視して構いません。リスト 2 の最後の 2 つのコマンドによって、/ebsvol というマウント・ポイントが作成され、そのマウント・ポイントにファイルシステムがマウントされます。

以上の作業で、ファイルシステムは使用できるようになりました。/ebsvol の下に置かれたすべてのファイルは、サーバーがダウンしても存続します。

EBS ボリュームの使用

EBS ボリュームが /ebsvol にマウントされたところで、今度は PostgreSQL データをそこに移します。最も直接的な方法は、既存のデータ・ストアをコピーして、シンボリック・リンクを張ることです。この方法は上手くは行くものの、それよりも簡潔な方法となるのは、EBS ボリュームのデータを /var/lib/pgsql に複製することです。リスト 3 に、この手順を示します。

リスト 3. EBS ボリュームへの PostgreSQL データの移動
# service postgresql stop
# mv /var/lib/pgsql /ebsvol
# mkdir /var/lib/pgsql
# chown postgres:postgres /var/lib/pgsql
# mount /ebsvol/pgsql /var/lib/pgsql -o bind
# service postgresql start

リスト 3 のコマンド・シーケンスは以下のとおりです。

  1. データの整合性を確実にするために、PostgreSQL デーモンを停止します。
  2. ディレクトリー・ツリー全体を EBS ストアに移動します。
  3. PostgreSQL ディレクトリーを再作成します。
  4. PostgreSQL ディレクトリーの所有権をリセットします。
  5. mountbind オプションを使用して、/ebsvol/pgsql を /var/lib/pgsql 上にマウントします。
  6. データベースを再起動します。

mountbind オプションは、1 番目に指定されたディレクトリーを 2 番目に指定されたディレクトリーに複製します。一方のディレクトリーに対する変更は、もう一方のディレクトリーに反映されます。結局のところ、同じディスク上に同じブロックが 2 つあるということです。bind を使用することと、同じデバイスを 2 度マウントすることは同じではありません。前者の場合には、ファイルシステム全体ではなく、サブディレクトリーをマウントできるためです。

クラッシュからの回復

サーバーがクラッシュした場合には、次の手順に従います。

  1. AMI を使用して新しいインスタンスを開始します。
  2. ec2-attach-volume コマンドを実行して、インスタンスに EBS ボリュームを接続します。
  3. EBS デバイスを /ebsvol にマウントします。
  4. リスト 3 に記載されている最後の 4 つのコマンドを実行します。

最近の AMI にバンドルされているのであれば、データベース・システムは最新の状態になります。


アプリケーション・サーバーに対する取り組み

クラウド・コンピューティングがもたらす利点の 1 つは、サーバーの処理能力を簡単に利用できることです。現在のところ、SmallPayroll.ca 環境には 1 つの仮想インスタンスにデータベースとアプリケーション・サーバーの両方があります。この状態は、Amazon EC2 にマイグレーションする前と同じです。そこで、次のステップではアプリケーション・サーバーをデータベース・サーバーから切り離します。

スケーリングとロード・バランシング

スケーリングという言葉は、一般に処理能力に関連します。アプリケーションをスケーリングするということは、より多くのユーザーの負荷を処理できるようにアプリケーションを拡張するということです。アプリケーションのスケーリングを、サーバーを追加するという手段で行う場合、それは水平スケーリングと呼ばれます。サーバーを処理能力の高いサーバーに置き換えて負荷を処理する場合は、アプリケーションの垂直スケーリングと呼ばれます。

水平スケーリングと垂直スケーリングは、組み合わせて使用することができます。データベース処理能力の問題に対処するには、より処理能力の高いサーバーとより高速のディスクを使用するとともに、サーバーの数を増やして計算を分散するほうが簡単に行くことがあります。水平スケーリングまたは垂直スケーリングが可能であるかどうかは、主にアプリケーションの設計次第です。アプリケーションによっては、複数のコンピューターに分散できないものもあります。また、一部の操作は、コンピューターがどんなに高速な処理が可能でも一定の時間を必要とします。さらに、ある程度までは水平スケーリングが可能なものの、その限度に達するとボトルネックのおかげで、サーバーを追加しても得られる効果がまったくないアプリケーションもあります。

アプリケーションを複数のサーバーに分散する場合には、受信されるリクエストをどのように分配するかという問題が持ち上がってきます。受信リクエストを分配するために最もよく使われる機器は、ロード・バランサーです。ロード・バランサーとは、外部からのリクエストを受け入れ、次に使用可能なアプリケーション・サーバーにリクエストを引き渡す機器のことです。これは負荷の大きいタスクではないため、単一の機器で多数の接続を処理することができます。あるいは、ソフトウェアでこの機能に対処することもできます。

Amazon EC2 では、ほとんどの目的に十分対応する Elastic Load Balancing という名前のクラウド・ロード・バランサーを用意しています。Elastic Load Balancing はリクエストを分配し (サーバーの追加または削除に応じて API で再構成することが可能です)、バックエンド・サーバーでヘルス・チェックを行います。

Elastic Load Balancing を使用する代わりに、Amazon EC2 インスタンスで HAProxy や Varnish などのロード・バランシング・ソフトウェアを独自に実行するという方法もあります (詳細は、「参考文献」のリンクを参照)。このプロセスは Elastic Load Balancing を使用する場合より複雑ですが、独自のトラフィックをより高度に制御することができます。SmallPayroll.ca のようなアプリケーションにとって、Elastic Load Balancing には十分過ぎるほどの能力があります。

SmallPayroll.ca アプリケーションの新しい設計は、図 2 のようになります。

図 2. アプリケーション・サーバーが分離された SmallPayroll.ca アプリケーション
新しい SmallPayroll.ca アプリケーション

受信されるリクエストは Elastic Load Balancing に到着した後、2 つのサーバーのうちのいずれかに送信されます。静的リクエストを処理し、動的リクエストを mongrel インスタンスに委任する nginx は、サーバー自体が実行します。mongrel のすべてが、同じ 1 つのデータベース・サーバーに接続します。

いずれかのアプリケーション・サーバーが機能しなくなった場合には、Elastic Load Balancing がすべてのトラフィックをもう一方のアプリケーション・サーバーにリダイレクトします。

新しいインスタンスの開始

分離したアプリケーション・サーバーを作成するには、さらに 2 つのインスタンスを開始する必要があります。インスタンスを開始するための AMI には、前と同じ AMI を使用することができます。AMI には必要なすべてのソフトウェアが含まれているためです。一度に開始できるインスタンスの数は 1 つだけではありません。リスト 4 では、1 つのコマンドで 2 つのインスタンスを開始しています。

リスト 4. 2 つのインスタンスの同時開始
$ ec2-run-instances ami-147f977d -k main -z us-east-1a \
-d 'role=web,db=10.201.207.180' -n 2
RESERVATION     r-9cc240f7      223410055806    default
INSTANCE        i-81ee2eeb      ami-147f977d    pending main ...
INSTANCE        i-87ee2eed      ami-147f977d    pending main ...

ec2-run-instances コマンドは、前に使ったコマンドと同様です。アベイラビリティー・ゾーンが -z us-east-1a を指定して選択されているのは、データベース・サーバーも同じリージョン内にあるためです。現時点では、データベース・サーバーとアプリケーション・サーバーを同じアベイラビリティー・ゾーンに配置したままにして、遅延と帯域幅の費用を減らす必要があります。

一方、-d-n は初めて使用するパラメーターです。-n 2 パラメーターは、出力に示されているように、Amazon に 2 つのインスタンスを開始するよう指示しているだけにすぎません。-d パラメーターは、情報をインスタンスに渡すために使用することができます。この情報を取得する方法をリスト 5 (新しいインスタンスから引用) に示します。

リスト 5. インスタンス・メタデータの取得
[root@domU-12-31-39-0C-C5-B2 ~]# DATA=`curl -s http://169.254.169.254/latest/user-data`
[root@domU-12-31-39-0C-C5-B2 ~]# echo $DATA
role=web,db=10.201.207.180

curl コマンドは、Amazon EC2 サービスからユーザー・データが含まれる Web ページを取得します。これは、連載の前回の記事でサーバーが SSH (Secure Shell) キーを取得する方法と同様です。

アプリケーション・サーバーの構成

アプリケーション・サーバーで行う作業はそれほど多くありません。それは、複製元の AMI は、すでにローカル・データベースに対してアプリケーションを実行できるようになっているためです。Rails アプリケーションはそのデータベース構成を config/database.yml から読み取ります。このファイルが、アプリケーションに対して使用するデータベース・サーバーを指示します。デフォルトでは、アプリケーションは localhost に接続します。

まず、エントリーを /etc/host に追加して DNS エイリアスを作成してください。例えば、10.201.207.180 dbserver はアドレス 10.201.207.180 に対して dbserver という名前をエイリアスとして定義します。重要な点は、接続先のパブリック・アドレスではなく、データベースのプライベート・アドレス (eth0 に割り当てられたアドレス) を使用することです。同じアベイラビリティー・ゾーン内にある Amazon EC2 インスタンスのプライベート・アドレス間でのトラフィックは無料ですが、ある Amazon EC2 インスタンスから別の Amazon EC2 インスタンスのパブリック・アドレスとの間のトラフィックは課金対象となります。

次に、アプリケーションが上記で作成した DNS エイリアスにアクセスするように、database.yml ファイルに追加します。リスト 6 に構成を記載します。

リスト 6. アプリケーションがデータベース・サーバーにアクセスするように指定する
production:
  adapter: postgresql
  encoding: utf8
  database: payroll_prod
  pool: 5
  username: payroll
  password:  secret
  host: dbserver

セッション・アフィニティー

セッション・アフィニティー (セッション・パーシスタンスと呼ばれることもあります) とは、ロード・バランサーに備わっている、どのクライアントがどのサーバーと対話しているのかを追跡するための機能のことです。この機能では、クライアントが次に行うリクエストは同じバックエンドの Web サーバーにリダイレクトされ、アプリケーションがローカル RAM またはディスクに情報を保持できるようにし、プール内のすべてのメンバーが情報を共有しなくても済むようにします。

セッション・アフィニティーが正常でなくなると、ユーザーがアプリケーションから不規則にログアウトされる、入力が失われてしまったように見えるなどの症状が出てきます。このような場合、リクエストを受け取るサーバーは別のコンピューター上にあり、セッション・データなどの情報を失っていることになります。

この問題に対処するには、アフィニティーを要求することも、独自の回避策を講じることもできます。memcached などの分散キャッシュは、どのサーバーからアクセスされているかを考慮しません。セッション・データは、データベースまたは分散キャッシュに保管することができます。また、セキュリティーのニーズによっては、クライアントの cookie に情報を保管するという方法も選ぶことができます。

これで、Rails アプリケーションを起動して、アプリケーション・サーバーのパブリック IP アドレスにアプリケーションを接続できるようになるはずです。エラーを受け取った場合には、以下の点を確認してください。

  • PostgreSQL がすべてのインターフェースでリッスンしていること。postgresql.conf ファイルに、listen_addresses="*" のような行があることを確認してください。
  • pg_hba.conf で、MD5 認証を使用した 10/8 アドレスの接続が有効に設定されていること。
  • Amazon セキュリティー・グループがデータベース・サーバーとの接続を許可していること。

ロード・バランサーの作成

Elastic Load Balancing は至って単純なロード・バランサーで、リクエストが入ってくると、プール内で使用可能なサーバーにリクエストを転送するという仕組みです。Elastic Load Balancing はダウンしているサーバーにリクエストを送信することのないように、Web サーバーの基本的なヘルス・チェックをすることができます。さらに基本的なアフィニティー・メカニズムもあるため、ユーザーを同じバックエンド・サーバーで対処することができます。URL に基づくリダイレクトなどの高度な機能は、現在のところサポートされていません。

Elastic Load Balancing を構成するプロセスには、以下の 3 つのステップがあります。

  1. ロード・バランシング・インスタンスを作成します。
  2. ヘルス・チェックを定義します。
  3. Elastic Load Balancing 名を指す DNS を構成します。

リスト 7 に、最初の 2 つのステップを実行している様子を記載します。

リスト 7. Elastic Load Balancing インスタンスを構成する
$ elb-create-lb smallpayroll-http \
	--listener "lb-port=80,instance-port=80,protocol=HTTP" \
	--availability-zones us-east-1a
DNS_NAME  DNS_NAME
DNS_NAME  smallpayroll-http-706414765.us-east-1.elb.amazonaws.com
$ elb-configure-healthcheck smallpayroll-http --target "HTTP:80/" \
     --interval 30 --timeout 3 --unhealthy-threshold 2 --healthy-threshold 2
HEALTH_CHECK  TARGET    INTERVAL  TIMEOUT  HEALTHY_THRESHOLD  UNHEALTHY_THRESHOLD
HEALTH_CHECK  HTTP:80/  30        3        2                  2

リスト 7 には 2 つのコマンドが示されています。最初のコマンド elb-create-lb は、ロード・バランサーを作成します。このコマンドの 1 番目のパラメーターは、ユーザーにとって固有なロード・バランサーの名前です。--listener パラメーメーターは公開ポートが 80 であること、このポートをインスタンスのポート 80 と接続すること、そしてプロトコルとして HTTP を使用することを指定します。このコマンドの出力は DNS 名です (上記の例では、smallpayroll-http-706414765.us-east-1.elb.amazonaws.com)。大抵のロード・バランサーとは異なり、接続先のパブリック IP アドレスは提供されません。Amazon が独自の IP アドレスを割り当て、ユーザーは DNS エイリアスを使用して接続するからです。

2 番目のコマンド elb-configure-healthcheck はロード・バランサーの名前を指定してから、ヘルス・チェックをルート URL のポート 80 に対して HTTP プロトコルで行うことを指定します。チェックを処理するコントローラーとアクションを別に作成することもできますが (/status など)、このアプリケーションの場合、アプリケーションが正常に実行されていることはルート URL でも十分に保証することができます。

パラメーターの 2 行目では、以下の内容を順に指定しています。

  • --interval 30: 30 秒ごとにテストします。
  • --timeout 3: 指定されたこの時間内にアプリケーションがレスポンスを受け取らないと、テストは失敗します。
  • --unhealthy-threshold 2: テストが 2 回連続で失敗すると、サーバーにサービス停止状態のマークが付けられます。
  • --healthy-threshold 2: 失敗したサービスが 2 回連続で成功しないと、サーバーはプールに戻りません。

次のステップでは、インスタンスをロード・バランサーに接続します (リスト 8 を参照)。インスタンスは自由に追加、削除することができます。

リスト 8. ロード・バランサーへ 2 つのインスタンスを追加する
$ elb-register-instances-with-lb smallpayroll-http --instances i-87f232ed,i-85f232ef
INSTANCE_ID  INSTANCE_ID
INSTANCE_ID  i-85f232ef
INSTANCE_ID  i-87f232ed
$ elb-describe-instance-health smallpayroll-http --headers
INSTANCE_ID  INSTANCE_ID  STATE      DESCRIPTION  REASON-CODE
INSTANCE_ID  i-85f232ef 	InService  N/A					N/A
INSTANCE_ID  i-87f232ed		InService  N/A					N/A

リスト 8 ではまず、smallpayroll-http ロード・バランサーに追加する 2 つのインスタンスを示し、次に elb-describe-instance-health コマンドを実行して、プール内の各サーバーの状態を表示しています。InService が意味するのは、サービスがロード・バランサーを介してリクエストを処理できる状態にあるということです。

最後に、ロード・バランサーの DNS 名をブラウズしてください。すると、アプリケーションが 2 つのサーバーで動作していることがわかるはずです。ロード・バランサーがアプリケーションの実際の DNS 名で動作するようにするには、アプリケーションの DNS レコードを A レコードからロード・バランサーの DNS 名を指す CNAME に変更します。注意事項も含め、DNS の要件についての詳細は、「参考文献」を参照してください。DNS メソッドは扱いにくいものの、Amazon EC2 インスタンスでロード・バランサーを作成する場合より、桁違いの多さのリクエストを処理できるようになります。また、サービスが中断することは決してないため、DNS の変更はいつでも可能です。


データのバックアップ

アプリケーションは 2 つのノードに分散され、ゼロの状態からデータベース・サーバーを立ち上げるところまで 30 分もかからずに実行することができます。このことは可用性の面では望ましいことですが、管理者が誤って重要なデータを破壊してしまった場合や、EBS ボリュームに障害が発生した場合には何の助けにもなりません。幸い、このような問題に対処するためのソリューションがあります。

データベースのバックアップ

EBS には、ボリュームのコピーを Amazon S3 に保管するスナップショット機能があります。正確に言うと、EBS スナップショットには最後のスナップショットからの変更点が保管されます。事を複雑にしているのは、ディスク書き込みをキャッシングするデータベースです。このキャッシングにより、一貫性のないスナップショットになっている可能性があるため、すべてがディスク上で必ず一貫した状態にあるようにしなければなりません (リスト 9 を参照)。バックアップの手順は以下のとおりです。

  1. PostgreSQL にバックアップ・モードに移行するように指示します。
  2. ファイルシステムをフリーズします。
  3. Amazon にスナップショットを要求します。
  4. ファイルシステムのフリーズを解除します。
  5. PostgreSQL にバックアップが完了したことを伝えます。

この手順には 1、2 分かかることもありますが、Amazon がバックグラウンドで引き続きスナップショットを Amazon S3 にスプールしています。ただし、ステップ 3 の後に行われた変更はスナップショットに反映されません。

リスト 9. データベースへバックアップする
#!/bin/sh
export EC2_HOME=/usr/local/
export JAVA_HOME=/usr
export EC2_CERT="/root/.ec2/cert.pem"
export EC2_PRIVATE_KEY="/root/.ec2/pk.pem"
echo "select pg_start_backup('snapshot')" | su - postgres -c psql
/usr/sbin/xfs_freeze -f /ebsvol/
/usr/local/bin/ec2-create-snapshot vol-93f77ffa --description "`date`"
/usr/sbin/xfs_freeze -u /ebsvol/
echo "select pg_stop_backup('snapshot')" | su - postgres -c psql

スナップショットの状態を確認するには、ec2-describe-snapshots コマンドを使用します (リスト 10 を参照)。

リスト 10. EBS スナップショットを表示する (要約)
$ ec2-describe-snapshots --headers
                SnapshotId      VolumeId        Status          StartTime
SNAPSHOT        snap-298cb741   vol-93f77ffa    completed       2010-06-29T02:50:55
SNAPSHOT        snap-a2b959c9   vol-93f77ffa    completed       2010-07-13T15:14:54

リスト 10 には、作成が完了した 2 つのスナップショットとそれぞれの時刻が示されています。

スナップショットの作成は、cron によってリスト 9 を実行することで自動化する必要があります。また、ec2-delete-snapshot コマンドを使用して、定期的にスナップショットのリストから不要なものを削除する必要もあります。

データベースのリストア

EBS ボリュームに障害が発生した場合、あるいは古いデータを EBS からリストアしなければならない場合には、最新のスナップショットからリストアする必要があります。EBS ボリュームをリストアする手順は、新しいボリュームを作成する手順とほとんど同じです。リスト 11 に、リスト 10 で作成した最新のスナップショットをリストアする方法を記載します。

リスト 11. EBS スナップショットをリストアする
$ ec2-create-volume --snapshot snap-a2b959c9 -z us-east-1a -s 20
VOLUME  vol-d06b06b9    20      snap-a2b959c9   us-east-1a      creating

このボリュームを任意のインスタンスにマウントすれば、データをリストアすることができます。

ファイルのバックアップとリストア

サーバーからファイルのバックアップを取る簡単な方法は、Amazon S3 にファイルをコピーするか、ファイルを AMI の一部にすることです。バイナリーやソフトウェア・パッケージには後者の方法のほうが効率的な一方、ユーザー・データには前者の方法のほうが効率的です。S3Sync ツールには、コマンドライン Amazon S3 ツールと、rsync のような便利なユーティリティーが用意されています。

S3Sync ユーティリティーをダウンロードしてください (リンクについては「参考文献」を参照)。リスト 12 に、バックアップ用のバケットを作成する方法、そして Amazon S3 にファイルをアップロードする方法を記載します。

リスト 12. Amazon S3 へデータをバックアップする
$ s3cmd.rb  createbucket smallpayroll-backup
$ s3cmd.rb listbuckets
ertw.com
smallpayroll-backup
$ s3sync.rb  -r /var/uploads smallpayroll-backup:`date +%Y-%m-%d`
$ s3cmd.rb list smallpayroll-backup:2010-07-12
--------------------
2010-07-12/uploads
2010-07-12/uploads/file1.txt

リスト 12 は、smallpayroll-backup というバケットを作成するところから始まっています。異なる時点での異なるバックアップでも安全に同じバケットに保管することができるので、バケットを作成するステップを行うのは 1 度だけです。2 番目のコマンドでは、バケットが作成されたことを確認します。上記に示されているように、ertw.com というバケットが作成されたことがわかります。ここに、AMI が置かれます。

s3sync.rb コマンドは再帰的に /var/uploads ディレクトリーをバックアップ・バケットにコピーし、すべてのファイル名の先頭に現在の日付を追加します。最後のコマンドが、バケット内にあるすべてのファイルを表示します。

リストア手順も同じく単純です。予約されたパラメーターを指定して S3Sync を使うことも、Amazon S3 File Manager (「参考文献」を参照) のような別のツールを使って個々のファイルを取得することもできます。


まとめ

SmallPayroll アプリケーションはクラウド内で実行され、今後の拡張に対応できるように設計も改善されました。ハードウェアの平均故障間隔は変わっていませんが、バックアップおよびスクリプトが導入されたということは、データが安全であること、そして必要な場合には素早く環境を再構築できることを意味します。

これで、クラウドに直接マイグレーションする場合に最初からあった問題のほとんどに対処しましたが、環境の正常性についての可視性はほとんどありません。また、需要に対応してサーバー・リソースをスケーリングできるとしたらきっと役立ちます。これらの問題には、連載の次の 2 回の記事で対処します。

参考文献

学ぶために

  • EBS での RightScale: RightScale のメンバーが EBS の詳細を調べ、スナップショットおよびアベイラビリティー・ゾーンについて詳しく説明しています。
  • EBS のパフォーマンス: EBS ボリュームは、1 つのサーバーに複数接続することができます。MySQL Performance Blog で、RAID を使用した場合の EBS パフォーマンス向上を詳しく比較しています。これは、他のデータベースにも関連します。
  • PostgreSQL オンライン・バックアップ: これらのバックアップは非常に貴重なものですが、一貫性を確実にするためにはある程度の考慮が必要です。
  • インスタンス・データの使用: Amazon EC2 インスタンスには、インスタンスが環境について学習するのに役立つインスタンス・メタデータがいくつか含まれています。Amazon EC2 マニュアルのこの章を一読して、Amazon EC2 では何ができるのかを把握してください。
  • Introduction to Elastic Load Balancing: Elastic Load Balancing サービスは、皆さんが扱い慣れているロード・バランシングとは異なる形で機能します。これは特に、DNS CNAME を使用してアプリケーションに Amazon ホスト名に対応する別名を指定しなければならないためです。
  • ルート頂点に対する ELB および CNAME についてのディスカッション: Elastic Load Balancing を例えば example.com のようなドメインのルート (ルート頂点とも呼ばれます) に適用しようとしているなら、Amazon Web Services ディスカッション・フォーラムのこのディスカッションがその場合の問題を明らかにし、回避策を提案しています。
  • developerWorks の Cloud Computing エリアで、クラウド内でのアプリケーションを開発およびデプロイするために必要なリソースを入手して、クラウド開発の最先端に立ってください。
  • developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  • さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  • 無料の developerWorks Live! briefing に参加して、IBM 製品およびツール、そして IT 業界の傾向を素早く学んでください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  • Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。

製品や技術を入手するために

  • HAProxy および Varnish: Elastic Load Balancing に代わるロード・バランサーを探している場合は、この 2 つのプロジェクトを調べてください。HAProxy はイベント駆動型のリバース・プロキシーです。Varnish はスレッド化モデルを使用し、キャッシングも行います。
  • Amazon S3 File Manager: Amazon S3 内に複数の AMI を保管している場合、古い AMI は削除してください。Amazon S3 File Manager は、数多くのスタンドアロンのアプリケーションやブラウザー・プラグインの機能に匹敵する Web ベースのファイル・マネージャーです。AMI を削除したら、忘れずに ec2-deregister を実行してください。
  • S3Sync: S3Sync は、Amazon S3 との間でのファイルのコピー、そしてバケットの操作に役立つツールです。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Cloud computing, Open source
ArticleID=516736
ArticleTitle=Linux アプリケーションを Amazon クラウドにマイグレーションする: 第 2 回 アプリケーションの信頼性の向上
publish-date=08032010