システム多重化によるサービス無停止でのアップデートの実現

渡辺です。

Webサービスを公開したならば、アップデートは避けて通ることはできません。 どのようにアップデートを行うかは、開発をはじめる前に考慮すべき大切なことです。 今回は、AWSでシステムを構築する場合に注意すべき、システムアップデート方針のポイントについて解説します。

一時的なサービス停止の許容

システムのアップデート方針で、はじめに確認しなければならないことは、アップデート時のサービス停止を許容できるかという点です。

サービスの一時的な停止を許容できるのであれば、複雑な構成は必要ありません。 一時的にメンテナンスページなどを表示できるように準備しておき、アップデート後にメンテナンスを解除すれば済みます。

しかし、一時的なサービス停止を許容出来ない場合は、システムを稼動させながらアップデートを行うための構成が必要になります。 AWSで構成するならば、リソースは何時でも作って何時でも破棄できるため、様々な構成を検討することができます。

システム構成の多重化

AWSで構成する場合、ハードウェアを調達する必要なく、リソースは何時でも作れ、何時でも破棄することができます。 なので、システムを２系統用紙し、アップデート時にシステムの停止時間をゼロまたは最小限にすることができます。

例えば、次のようなELB配下のWebサーバ(複数)とRDSで構成されたシステム構成をとっているならば、同じような構成のWebサーバとRDSをもう１セット作成します（待機系）。 システムのアップデート時には、待機系のシステムに対しアップデートを行い、アップデートが完了した時点でELBの向き先を変更します。 これならばシステムの停止時間なしにシステムをアップデートできます。

ただし、どこまでを待機系とするかはシステムの要件などによって変わってきます。 RDSはデータの同期の問題があるため、待機系を作らず共有することもできます。 システムにログイン中のユーザがシステムアップデート後にそのまま処理を継続可能か？といった、アプリケーションの実走側の問題があるかもしれません。

例えば、次のようにELBまでを待機系として差しかえられる構成とし、RDSは共有するような構成も可能です。

アプリケーション設計上の注意点

これからアプリケーションを開発するならば、幾つかのポイントを押さえておくことで、多くの構成を選択することができるようになります。 言い換えれば、アプリケーションの設計がよろしくないと、AWS上のシステム構成に制約を受けることになり、アップデート方針も合わせなければならなくなる場合があります。

永続化データをストレージに保存する

通常の処理データなどは、RDSに保存するかと思いますが、例えばアップロードされた画像データなどをWebサーバのファイルシステムに保存することは避けるべきです。 負荷対策でインスタンス数を増やす場合でも可用性を高めるために冗長化する場合でも、アップデートのために待機系を作る場合でも、各インスタンスの画像データディレクトリを同期する必要がでてきます。

画像データ以外でも、セッションデータなどデータは可能な限りRDS等のストレージシステムやS3に保存し、EC2インスタンスには保存すべきではありません。

デプロイ手順の自動化する

システム構成を多重化したとしても、アップデート手順、すなわちデプロイの作業を手動で行ってはミスを犯してしまうのも時間の問題です。 必ず、デプロイ手順は自動化しなければなりません。

デプロイの自動化は、Java系のプロダクトであればMavenやGradle、Ruby系のプロダクトであればCapstranoなどWebサーバで利用するプラットフォームに合わせて選択してください。 デプロイは、デプロイ用のサーバを別途用意するパターンと、ローカルマシンからネットワーク経由でデプロイする方法があるでしょう。

スタンバイ系の方式

稼働中のシステムの他にスタンバイ系（待機系）のシステムを用意する場合、スタンバイ系のシステムをどんな方式にしておくかを決める必要があります。 これは、可用性を高めるための構成（ホット/ウォーム/コールドスタンバイ）と関連の強い課題です。 可用性に関する要件と合わせてどのような構成にするかを検討します。

ホット/ウォーム・スタンバイ

スタンバイ系のシステムは起動し、何時でも切り替えられる状態とします。

可用性の観点から見るとホットスタンバイとウォームスタンバイは異なりますが、アップデート時の考え方で言えばどちらも、インスタンス等が起動した状態という点で同じです。

ホット/ウォーム・スタンバイで構成する場合のメリットは、可用性を高める構成を同時に取れるということです。 逆にデメリットとしては、インスタンスコストが単純計算で倍となることです。 可用性も高め、アップデートも慎重に行うためにはホット/ウォームスタンバイの構成とすると良いでしょう。

コールド・スタンバイ

スタンバイ系のシステムは、インスタンスを停止状態とします。

システムのアップデート時にインスタンスを立ち上げて、切り替え作業を行います。 元の稼動中のシステムはスタンバイ系となった後に停止するため、アップデート前後でのみ２系統のシステムが稼働します。

コールド・スタンバイで構成するメリットはインスタンスの稼動コストがかからない点です。 EBSボリュームなど幾らかのコストは発生しますが、インスタンスの稼動コストに比べれば遥かに小さな額となるはずです。 逆にデメリットとしては、可用性がホット/ウォームスタンバイからは落ちることです。 とはいえ、高可用性までは必要としないが手動で待機系を使って数時間以内に復旧させれば問題ないサービスであれば、コストメリットが大きい選択です。

オンデマンド・スタンバイ

スタンバイ系のシステムは起動すらしません。 システムのアップデート時に、インスタンスはゼロから立ち上げます。 アップデートが終わり切替が終わったならば、稼動していた元のシステムはすべて撤収します。

オンデマンド・スタンバイのメリットは、コールドスタンバイよりもさらにコストが低く抑えられることです。 また、都度インスタンスを作り設定からやりなおすため、常にフレッシュな状態でシステムを構築できる点です。 逆にデメリットとしては、システム（インスタンス）の起動からデプロイまですべての手順を自動化しておかなければ実現が難しいところでしょう。

なお、オンデマンドスタンバイは、今さっき思いついた造語です（笑）

まとめ

最終的にどの方式をシステムで採用するかの判断は難しい所です。 可用性要件・コスト・システム停止時間許容の有無が重要なファクターとなるでしょう。 また、デプロイの自動化やアプリケーション設計など開発スキルも関わってきます。

とはいえ、どのような構成でも選択できるのはAWSを採用する大きなメリットですね。