2015.12.22

Elastic Beanstalk

AWSでしくじった話 (ElasticBeanstalk編）

こんにちは、井上です。

最近好きな番組は「しくじり先生」です。
毎回、何かしらでしくじった諸先輩方が出演し、しくじった体験談と、それを元にした教訓をおしえてしてくれる番組なのですが、実体験に基づくだけあって教訓も説得力があり、非常にためになります。
辺見マリが洗脳されて5億円とられた話とか、生々しすぎて恐怖でした。

それにちなんで、今回はAWSの利用でしくじった話をしようと思います。

今回私がしくじったサービスは、ElasticBeanstalkです。

ElasticBeanstalkは簡単に説明すると、WEBアプリケーションのデプロイ、構成管理、オートスケールなどをまるっと面倒を見てくれる便利なサービスです。

2014年の4月くらいから利用検討を開始し、最初の頃は情報も少なく手探りの状態からスタートしました。
特に ebextensions で設定する構成管理の部分にクセがあり、どのようなタイミングでどのような処理が実行されるのかわからずに四苦八苦しました。

AWSのサポートに問い合わせたり、オークファンの得上さんに相談に乗ってもらったりしながら徐々に問題を解決していき、現在では複数のプロジェクトで活用するようになりました。
その試行錯誤の結果の秘伝のタレがこちらです。 ElasticBeanstalk .ebextensions 逆引き辞典

そんな運用もこなれてきた時に悲劇がおきました。
Applicationの消失です。

Applicationの消失

ElasticBeanstalkは、アプリケーションを配置する Application という単位の中に、開発環境、ステーング環境、本番環境といった様々な状態のものを動作させるための Environment という枠があります。

Environmentでは、アップロードされたいろいろなアプリケーションバージョンを選択し実行することができます。

こんなイメージです。

実際、消失したApplicationの中では、本番環境はもとより、ステージング環境、開発環境、○○向け開発用などいろいろなバージョンを動作させていました。また本番環境はBlue/Green Deploymentを実行するために本番待機系などもありました。
1つのEnvironmentには、ELB、EC2インスタンス、セキュリティグループ、AutoScalingGroupなどが含まれていましたが、それらもろとも消失しました。

なんで消えてしまったか

完全に私のオペレーションミスでした。
利用しなくなった古いApplication versionを掃除しようとしていて、誤ってApplication を削除してしまったのです。

以前、急にデプロイできなくなった問題が発生したことがあり、原因がApplication version数の上限に達したことによるものだったため、折を見て利用しなくなったApplication versionはポチポチと消してきれいな状態を保つようにしていました。その作業が裏目に出たのです。

押してしまったと同時に、全てのEnvironmentがグレーアウトしました。
一瞬何が起きたのか分かりませんでしたが、すぐに気づき血の気がサーっと引いていくのを感じました。

EC2インスタンスの一覧画面に行くと、今まさにターミネート処理中のインスタンスが並んでおり更に絶望しました。
またCSチームの方から「なんかエラーが起きてサービス見られない」という声が聞こえはじめました。

復旧作業

何が起きたのかを察した後は、冷静に冷静にと心のなかで唱えながら、復旧手順を考えました。

が、スクリプトを1つ実行すれば、Environmentが作成できるように自動化してあったことを思い出しました。
手動でApplicationを作成し、その中にEnvironmentを作成しデプロイするスクリプトを流しました。

スクリプト1発とはいえ、Environmentを作成するには、ELBの作成、AutoScalingGroupの作成、インスタンスの起動、アプリケーションのデプロイなど一連のリソース作成が流れるので10分くらいかかります。
それを待っている間の生き地獄感といったらありません。

何か失敗するのではとドキドキしながら待っていたのですが、無事立ち上がってCNAMEを書き換えるとアプリケーションが正常に動作しはじめました。

削除してしまってから、復旧まで約15分でした。

教訓

これらの事象から学べる点を上げてみたいと思います。

手作業はときどき失敗する

まず失敗点として、手作業で大事な作業を行っていたことです。手作業は必ずミスをする可能性があるので、繰り返し行う作業はスクリプト化するなど、間違えないようにしておく必要があると思いました。

一方で環境構築のための手順はコード化されていたため、復旧にかける時間が短くて済みました。
ElasticBeanstalkでAutoScaleを導入する前は、そもそもテレビで取り上げられると30分くらいつながらなくなっていたのでそれよりも短かったと言えます。

IAM権限は最低限

IAM権限の調整により、危険な作業は行えないようにしておくべきと思いました。

マネージメントコンソールを使う際は緊張感をもつ

ElasticBeanstalkの操作に慣れてきていたため、緊張感も足りなくなっていました。
AWSのマネージドコンソールは、結構危険な作業もサクッと行えてしまったりします。
頻繁に使う人ほど慣れてしまって緊張感がなくなるのではないでしょうか。

アプリケーションは状態を持たない

今回のアプリケーションは、データは、DynamoDBやS3など、マネージドシステムに配置しており、インスタンスに状態を持たないようになっていたためインスタンスを立ち上げ直せばすぐに復旧できるようになっていました。
このあたりは、ElasticBeanstalkを使っていて本当に良かったと思いました。

データについては、マネージメメントシステムとはいえ、別の方法にて保全しておき、スムーズに復旧できる手順を確立しておく必要があります。

復旧訓練の必要性

クラウドは便利な反面、怖いと実感しました。

クラウドの導入により、ハードウェア的な障害は避けられるようになりましたが、論理的な障害は防げません。
災害に備えて避難訓練を行うように、クラウドならではの障害にそなえ訓練しておく必要があるのではないでしょうか。
最悪のケースとして、AWSアカウントごと消した場合にどれくらいの時間で企業活動を復旧させることができるか？というのを考えてみるだけでも、やるべきことは見えてくるように思います。

AWSへ望むこと

Deployボタンの横にDeleteボタンが配置されているなど、UI上ちょっと工夫してほしいなぁと思う部分が見受けられます。
危険な操作をするときには、クリックだけではなくキーボード入力をしないと実行できないようにしてほしいです。
- Githubでは、レポジトリを削除する際には、レポジトリ名を入力しないと実行できなくなっています。あれはとても良いインターフェイスですね。