システム開発 /

Amazon EC2のシステムリブートを経験して感じたこと

Amazon EC2は、皆さんがよく本などを購入する時に使っている「Amazon」が提供しているインフラ系クラウドサービスのコアになるサービスで、かれこれ3年ほど、このサービスを使って仮想サーバを構築してWEBサービスを運用しています。

大きなトラブルもなくサーバを運用していますが、まれに、Amazon側でパッチやアップグレードをした場合など、仮想サーバ(インスタンス)に修正内容を反映させるために、再起動しなければいけないことがあります。

EC2では、後にご説明をさせていただく再起動の種類があり、多くの場合、インスタンスリブートと言われている社内で厳戒態勢を敷いて警戒するほどでもない軽度なメンテナンスリブートが行われることが多いようです。

ですが今回、自分の使っている仮想サーバが システムリブート と言われている少し警戒しておいたほうがよさそうなリブートスケジュールが設定されていたので、ご紹介をさせていただきたいと思います。

2015101802

システムリブートで懸念していたこと

メンテナンスサポートページ を読みながら、システムリブートによって影響する範囲を想定してみると、以下のような懸念がありました。
  1. パブリックDNS名は変わらないか?
  2. プライベートIPアドレスは変わらないか?
  3. インスタンスストアのデータが消えてしまう可能性がある?
  4. Elastic IPの割り当てが解放されてしまうのではないか?

特に4番については、仮想サーバにElastic IPを設定しドメインをこのElastic IPと連携させているので、仮にElastic IPの割り当てが解放されてしまうとドメイン側の設定内容も変更し直さなければいけなくなります。

しかも、すでに運用中のドメインを今回の仮想サーバに割り当てているので、 短時間でドメインが再浸透してくれればいいのですが、最悪の場合、サービスが数時間停止してしまう・・その場合の復旧手順などもシュミレーションしておく必要がありました。

リブートの種類

AWSのリブートの種類は、主に「インスタンスリブート」「システムリブート」「リタイヤ」の3種類あります。

インスタンスリブート インスタンスリブートのタイミングをユーザーの希望時刻に自由にスケジュールできる。例えば、運用業務にあまり影響のない深夜にリブートのスケジュールをすることができる。
システムリブート インスタンスの下の基盤レイヤーの「ハードウェアやソフトウェア」のメンテナンス(再起動)が必要なため、AWS側で設定されたスケジュールにて強制的にリブートが行われる。リブートのタイミングをユーザー側で自由にスケジュールできない。
リタイヤ ハードウェアの調子が悪くこれ以上運用をできないようなケース。スケジュール日時以降はterminate(終了)されてしまう。

どの種類もリブートされることに違いはないのですが、リブートされるタイミングを自由に設定「できるか」「できないか」によって、エンジニアの対応方法が変わってくるのではないかと思います。

例えばシステムリブートの場合、スケジュールされた時刻になると問答無用にリブートされるので、 Elastic Load Balancing で構成されていない場合には、当然サーバーが落ちてしまうので、Webが閲覧できなくなります。また、アクセスが多い時間帯にリブートが走りWebが落ちてしまうと、クレームなどの対応に追われる可能性もあります。システム対応以外にもサポートチームとの連携を含め厳戒態勢を敷いておく必要があるかもしれません。

イベントステータスをマネジメントコンソールで確認する

2015101808

1.下図は、リブート前のマネジメントコンソールの状態です。イベントステータス(時計アイコン)は「Scheduled」になっています。

2015101803

2.指定時刻になると、ステータスが「In Progress」に変わりリブートが開始されます。

2015101804

3.リブートが終了すると、ステータスチェックが行われます。

2015101805

4.完全にリブートが完了し、予約されていたイベントが消えました。

2015101806

5.ステータスチェックが合格していることを確認します。

2015101807

6.マネジメントコンソールで無事に起動していることが確認できた後は、Webアプリケーションなどが問題なく動作していることを確認して完了です。

リブート開始からサーバが完全に復帰するまでの時間は、約8分ほどでした。

この仮想サーバは、メールサーバ、DBサーバを1台の中で構成していますが、SSH接続やFTP等のファイルアップ系の接続を含め不具合がでていないか確認する必要がありました。

また、容量的な問題で幾つかのディスクをマウントしていたりもするので、dfコマンドなどで各ボリュームの状態も確認しておきます。

まとめ

リブート後に「パブリックDNS名」「プライベートIPアドレス」「Elastic IPの割り当て解放」など色々と懸念していたことを確認しましたが、今回通知を受けた仮想サーバでは システムリブート によって設定が変わることはありませんでした。また、インスタンリブートと復帰までの時間を比べてみましたが、そこまで大きな差を感じることもありませんでした。今回メンテナンスが行われた仮想サーバは ELB(Elastic Load Balancing )を導入していませんが、ELBを導入することで今回の懸念やリスクを回避できるようです。

この記事を書いた人

堀孝文

PAGE TOP