EC2 メンテナンスで慌てないための 4 つの設計ポイント

Posted on

公式ブログでもアナウンスがありましたが、月末にかけて EC2 のメンテナンスが行われます。

EC2 のメンテナンスには、ゲスト OS を再起動するインスタンスリブートと、ホストの物理サーバを再起動するシステムリブートの 2 つがあります。どちらのメンテナンスが予定されているかは EC2 Management Console の Events ページで確認できます。詳しいことは Amazon EC2 のメンテナンスのヘルプページに書いてあります。

今回は Xen のセキュリティ対応ということでシステムリブートが必要になりますが、どちらのメンテナンスでもユーザーの都合に合わせて事前に実施することができます。

  • インスタンスリブート: ゲスト OS にログインして再起動させるか、EC2 Management Console で Reboot を選択
  • システムリブート: EC2 Management Console で Stop して Start を選択

後者を実行するとパブリック IP が変わったり、Instance Store のデータが消えるので注意が必要です。 EC2-Classic / EC2-VPC によっても変わるので、作業前にどのような影響が出るか確認してください。

自分が関わっているプロダクトでも複数インスタンスがメンテナンス対象になりましたが、サービスに影響することなく簡単に対応できました。その設計のコツをご紹介します。

EC2 インスタンスの前には ELB を置く

EC2 インスタンスのパブリック IP に CNAME を向けて公開するのはアンチパターンです。今回のようにシステムリブートのメンテナンスだと、パブリック IP が変わってしまうので事前に行うこともできません。

サーバ 1 台の小規模な構成でも、EC2 インスタンスの前には ELB を置きましょう。 ELB を置いておけばパブリック IP を気にする必要はありませんし、無停止でサーバを入れ替えることができます。

ELB は月 2,000 円程度しかかかりません。ロードバランサ機能が不要でも必ず使いましょう。

サーバに状態を持たせない

サーバが状態を持ってしまうと簡単に再起動できなくなります。ここでいう状態とは、アプリケーションのセッション情報やログファイル、あとは EC2 のホスト名やプライベート IP が決め打ちになっていることを指します。

AWS で可用性を上げるには、シンプルでステートレスな設計が鍵を握っています。セッション情報は ElastiCache、ログファイルは S3 に保存するなど他のサービスをうまく組み合わせて、EC2 にはコンピューティング処理しかさせないようにします。

こうして EC2 が担う役割をシンプルにすれば再起動するのもためらいませんし、メンテナンスに当たったインスタンスを入れ替えるのも簡単です。

単一障害点を作らない

当たり前のことですが、単一障害点を作らない工夫が必要です。冗長性を持たせるという意味もありますが、単一障害点になりえるミドルウェアを使わないことが重要です。

たとえば NFS サーバがその筆頭です。再起動すればクライアント側も影響を受けてしまいますし、再起動後の確認もすべてのクライアントに対して行う必要があります。

もしサーバ間でファイルのやり取りが必要ならば S3 を使いましょう。 NFS とは比べ物にならない信頼性を得られます。

Auto Scaling を前提とした設計

一番言いたかったのはこれです。最初から Auto Scaling を前提とした設計にしておくと、上に書いたことは必然的にクリアしているはずです。

負荷に応じて EC2 の台数が増減するので、サーバに状態を持つわけにはいきませんし、ホスト名やプライベート IP はコロコロ変わるし、単一障害点になりえる箇所があるとスケールアウトできません。 Auto Scaling を前提にするとこれらのことを強制的にクリアする必要があるのです。

今回のメンテナンスで自分がどういう対応をしたかというと、Auto Scaling 配下の EC2 インスタンスを Stop しただけです。すると不足した分を補うために ELB が新しいインスタンスを立ち上げて元の状態に戻してくれます。 Stop するところを除けば、あとはすべて自動的にやってくれます。

Auto Scaling を前提とした設計は多少手間がかかりますが、長い目で見れば運用コストを下げてくれます。

まとめ

今回のメンテナンスは EC2 インスタンスの 10 % 程度が影響を受けるので、ニュースサイトなどでも取り上げられてちょっとした騒ぎになっています（「Amazon EC2」が大規模なメンテナンス、一部ユーザーは懸念を表明）。

ですが、ユーザーの設計次第で回避できます。今回のメンテナンスを機に AWS に合ったインフラ設計に改善してみましょう。

それでは、よい AWS ライフを！

Popular Entries

Recent Entries