JP
“知らないと損をする！？ クラウド運用の豆知識”
AWSに見るメンテナンスイベントへの対応
クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。一方でサービスのメンテナンスなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。ここでは、特にAmazon Web Services（以下、AWS）を対象として、イベントの内容や求められる対応について見ていきたい。
※AWS…Amazon Web Services
クラウド特有の運用管理業務
クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。たとえばIaaSであればハードウェア障害などが発生した際、クラウドベンダー側で自動的に対処されるため、ユーザー側の負担が軽減するというわけだ。
これは間違いないのだが、一方でサービスのメンテナンスなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。もしメンテナンスに関するイベントが予定されていて、その通知を見逃せば予期せぬシステム停止につながりかねない。
ここでは、特にAmazon Web Services（以下、AWS）を対象として、イベントの内容や求められる対応について見ていきたい。
AWSにおけるイベントの事前通知
AWSではさまざまなサービスに対し、機能強化や性能改善、あるいは脆弱性への対応などを目的としたメンテナンスやアップデートを行っている。
このメンテナンスは透過的、つまりサービス提供を維持しながら行われる場合もあるが、内容によってはインスタンスの再起動やサービスの停止が伴う場合もある。
再起動が必要、あるいはサービス停止ともなれば、当然AWSを利用しているシステムの運用にも影響が生じるため、何らかの形で対応しなければならない。
そこで重要となるのは、メンテナンスやアップデートといったイベントの把握だ。AWSではメールでの通知のほか、「AWSマネジメントコンソール」や「Personal Health Dashboard」でイベントを確認することができる。
「AWS Health API」を利用すれば、API経由でHealth情報にアクセスし、各種イベントの情報を取得することが可能である。この情報を定期的に取得し、運用に利用しているメーリングリストのほか、ビジネス向けチャットツール「Slack」や、Office 365のハブとしてチャットやファイル共有、ビデオ通話も可能な「Microsoft Teams」で通知するなどといった利用が考えられるだろう。
EC2におけるメンテナンスへの対応
それではイベントに対する具体的な対応について、EC2を例に見ていこう。EC2のヘルプページによれば、Amazon EC2の予定されたメンテナンスにおける再起動には、インスタンスの再起動と、システムの再起動の2種類があるとしている。
システムの再起動は、インスタンスを実行している物理サーバーの再起動である。インスタンスの再起動であれば、ゲストOS上で再起動、あるいは「EC2 Management Console」で再起動を行うだけで済むが、システムの再起動であればインスタンスを一度Stopし、改めてStartを選択しなければならない。また、このようにシステムを再起動した場合、パブリックIPが変更になるため、Elastic IPの検討が必要だ。
なお再起動のスケジュールは自動で設定されるが、その前であればユーザー自身で再起動を行うことができる。
再起動による影響を最小限に抑えるためには、EC2で実行しているインスタンスに対するイベントを定期的にチェックし、再起動を伴うイベントが発生した際はメンテナンス時間を設定した上で事前に再起動を行うなどの対処が求められるだろう。
複雑なAmazon RDSのメンテナンスへの対応
AWSで構築したシステムのデータベースとして広く使われている、Amazon RDSでも当然ながらメンテナンスが行われている。
Amazon RDSのヘルプページを見てみると、「一部のメンテナンス項目では、Amazon RDSがDBインスタンスを少しの間オフラインにする必要があります」と記載している。つまりメンテナンスにより、アプリケーションサーバーなどからデータベースへ接続できないといった事態が生じる可能性があるわけだ。
なおAmazon RDSのメンテナンスには、ユーザーによる延期が不可能な「必須」、メンテナンスを実行可能だが自動的には行われない「利用可能」、次回のメンテナンスウィンドウ中に適用される「次のウィンドウ」、そしてメンテナンスアクションが適用中であることを示す「進行中」の4つのステータスがある。
ちなみに東京リージョンにおけるAmazon RDSでは、13:00～21:00 UTC（日本標準時で22時から6時）のうちの30分がメンテナンスウィンドウに割り当てられる。13:00～21:00のうちのどの30分かはランダムである。またDBインスタンス作成時にメンテナンスウィンドウの曜日を指定しなければ、ランダムで選択された曜日に30分のメンテナンスウィンドウが割り当てられる。
システムの内容や構成によってはデータベースのサービス停止の影響が大きくなるため、事前にイベントの情報を収集し、必要に応じてメンテナンスウィンドウの日時を指定したり、指定した日時と影響についてユーザーなどへ周知したりする対応が必要になるだろう。
クラウドであってもアウトソースを視野に
当然ながらEC2やAmazon RDS以外でもメンテナンスは発生する。このようなイベントに慌てずに対処するためには、イベントの種類ごとに対応を細かく決めておくといった運用設計が何よりも重要である。
しかしながらただ運用設計を行っていても、利用しているサービスやインスタンスの数が膨大になれば、すべてのイベントを把握して適切に対処することは容易ではない。そこで検討したいのが、AWSに精通しているITパートナーへの運用のアウトソースである。
たとえばNTTコミュニケーションズでは、ICT環境の監視から運用、最適化をワンストップでリモート環境から行うRIM（リモート・インフラストラクチャ・マネジメントサービス）として「Global Management One」を提供している。
そのサービスメニューの1つに「AWSマネージドサービス」があり、AWS環境の運用を一元的に対応できる体制が整えられている。AWSを本格的に活用するのであれば、こうしたサービスの利用も検討すべきだ。