Amazon EC2のイベント対応を楽にするためのアイデアと「Design for Failure」の考え方

AWSの深いところ見せちゃいます！ by AWSクラウドサポートエンジニア　第5回

　こんにちは、アマゾンウェブサービス ダブリンオフィスに勤務しております、クラウドサポートエンジニアの半田と申します。 好きなAWSサービスはAmazon WorkSpaces、Amazon CloudSearch、Amazon Elasticsearch Serviceです。本連載ではAWSサポートの各メンバーがそれぞれ「今一番AWSユーザーに伝えたいこと」を連載の形でお届けするシリーズです。

　連載第5回の今回は、前回に引き続き、EC2にたまにスケジュールされることのある「イベント」とその対応についてご紹介します。AWSサポートに問い合わせられる内容なども紹介しながら、EC2のイベントと可用性について、改めて考えてみたいと思います。

　今回の記事では以下の流れで内容を解説していきます。

• Amazon EC2の紹介と、EC2のイベントについて（前回）
• イベントに対するよくある質問（前回）
• イベント対応を楽にするための運用上のアイデア（今回）

イベント対応を楽にするために（1）

　前回では、EC2インスタンスで発生するメンテナンスイベントについてご紹介をしてきました。

　AWSではこうしたメンテナンスイベントについても日々改善を行っています。しかしながら現実的な問題としてEC2インスタンスも物理的なハードウェアで稼働している以上、現時点ではイベントは避けることができません。

　一方で、運用の視点で考えるならば、イベントがスケジュールされるたびにサービス停止が可能か、できないならばどう対応を行うのかといった調整を行うのは大変な作業です。

　これまで見てきた通り、イベントへの対応には対象のEC2インスタンスを停止する必要があります。とすると、イベントの影響をできるだけ小さくし、運用を楽にしていくためには以下のような視点が必要になってきます。

• インスタンスの停止・起動を楽にする
• 代替インスタンスの起動を楽にする・サービス切り替えを楽にする
• イベント通知の確認を楽にする

　ここからは、こうしたイベント対応の方法についてどのようにすれば楽にすることができるのか、考えてみたいと思います。

インスタンスの停止・起動を楽にする

　ではまず、インスタンスの停止・起動を楽にするためにはどんな点に注意する必要があるのでしょうか。インスタンスの停止・起動については、ある意味当たり前の話になってしまいますが、EBS backedインスタンスを利用することが、対応を楽に完了させるポイントとなります。

　Instance Store Backedインスタンスではインスタンスの停止が行えないため、イベントがスケジュールされるたびにAMIの取得やデータの移動といった考慮が必要となります。

　EBS backedインスタンスを利用していれば、こうした手間を考慮することなく、シンプルにインスタンスの起動・停止を実施するだけでイベントへの対応は完了します。

　最近では多くのAMIがデフォルトでEBS Backedインスタンスとなっていますが、イベント時に慌てないためにも、利用中のインスタンスにInstance store backedのものがないか確認をしてみてください。

　また、Instance store backedインスタンスを利用する場合は代替インスタンスの起動手順やデータの外部保管等、メンテナンス対応を問題なく行える構成になっているかをご確認ください。

代替インスタンスの起動を楽にする

　次に、代替インスタンスの起動を楽に行う方法についても考えてみます。起動・停止と比べ代替インスタンスを起動する方法のメリットは、イベント対象となった旧インスタンスと並行稼働させてインスタンスの起動・サービス切り替え作業ができ、サービス全体としての停止時間を短くできる点にあります。

　代替インスタンスの起動を楽にするポイントは、起動するだけでサービス提供が可能なようにカスタムAMIを準備しておくことです。

　カスタムAMIが準備できていれば、イベント通知を受け取った後すぐに代替インスタンスの起動が可能となります。

　カスタムAMIは利用中のEC2インスタンスをもとに作成することができます。手順等の詳細についてはAWSの公開ドキュメントに記載がありますので、こちらをご一読ください。

• Amazon EBS-Backed Linux AMI の作成 - Amazon Elastic Compute Cloud
• Amazon EBS-Backed Windows AMI の作成 - Amazon Elastic Compute Cloud

　また、代替インスタンス起動時にアプリケーションパッケージのダウンロードやソフトウェアアップデートなどの動的な処理を行いたいこともあるかと思います。そのための機能が、EC2インスタンスのユーザーデータやSSM（Simple System Manager）です。

　ユーザーデータは、ユーザが指定したスクリプトや自動設定可能なパラメータをインスタンス起動時に適用することができる機能です。

　実際の仕組みとしては、Linux AMIではcloud-init、Windows AMIではEC2Config／EC2Launchというツールがインスタンス起動時にユーザーデータを受け取り、実行します。ユーザーデータの実行はインスタンスの初回起動時のみとなり、2回目以降は無視されます。

　Linux、Windowsで利用可能な機能が異なったりもしますので、ご利用を検討される場合には以下のドキュメントをご確認いただくことをおすすめします。

• Linux インスタンスでの起動時のコマンドの実行 - Amazon Elastic Compute Cloud
• インスタンスメタデータとユーザーデータ - Amazon Elastic Compute Cloud

　一方、SSMはEC2インスタンスに対し外部からコマンド実行やソフトウェア構成を行う機能です。ユーザーデータと異なる点としては、SSMでは外部からAPIを経由して任意のタイミングでコマンド実行等の操作することができます。

• Run Command を使用した Linux インスタンスのリモート管理 - Amazon Elastic Compute Cloud
• Windows インスタンス設定の管理 - Amazon Elastic Compute Cloud

　こうした機能も活用しながら、利用形態に合わせた最適な代替インスタンスの起動をあらかじめ準備しておくことで、イベント時の対応もかなり楽になるのではないかと思います。