戦闘員吉田です。
ebの使い方入門ということで、公式チュートリアルよりDjangoアプリケーションのデプロイをやってみたいと思います。

続きを読む [Elastic Beanstalk入門] Djangoアプリケーションのデプロイ その①

こんにちは、井上です。

最近好きな番組は「しくじり先生」です。
毎回、何かしらでしくじった諸先輩方が出演し、しくじった体験談と、それを元にした教訓をおしえてしてくれる番組なのですが、実体験に基づくだけあって教訓も説得力があり、非常にためになります。
辺見マリが洗脳されて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では、レポジトリを削除する際には、レポジトリ名を入力しないと実行できなくなっています。あれはとても良いインターフェイスですね。

最後にお詫び

無事復旧できましたが、障害時にまさに利用しようとしていたお客様は、急につながらなくなって残念な思いをされたかと思います。この場を借りてお詫びいたします。

こんにちは、井上です。

先週末、東急ハンズのネットショッピングサイト、ハンズネットのWEBアプリケーション・サーバーを、ElasticBeanstalk MultiContainer Docker でリプレイスを行いましたのでその紹介をしたいと思います。

ハンズネットはシステム構成として、ざっくりとフロントのWEBアプリケーション・サーバーとバックエンドのAPIサーバーにより構成されています。

バックエンドのAPIサーバーについては、2014年の4月頃からBeanstalk/PHPに順次置き換える作業を進めており、DynamoDBとBeanstalkによるオートスケールの効果もありそこそこ負荷に耐えられるようになってきたのですが、それに伴いフロントエンドの部分がスケールしないことがボトルネックになってきていました。

特にTVの放送時などの突発的なアクセス増の際には、手動によるスケールには限界があり、
ヒルナンデスや、マツコの知らない世界などの特集でハンズの商品が紹介されると、サーバーに接続しづらい状況になることが度々ありました。恐るべしマツコ効果。

オートスケール化の一番のポイントは、サーバー自体に状態を持たないようにするという部分だと思うのですが、以前よりWEBアプリケーション・サーバーとAPIサーバーが分離されていたため、その部分では大きな障壁なく進める事が出来ました。
一部、特集コンテンツのようなものや、画像、CSSなど、サーバー内で保持しているデータがあったため、まずはそれらをCloudFront経由での配信に切り替え、第２段階としてBeanstalkに乗せる作業を行いました。

今回この作業によりフロントエンドの部分もオートスケールに対応したため、スパイクアクセスで接続しにくくなる状況は改善されるのではと思っています。
Dockerについては、本番環境に投入して間もないことから、運用上どういう問題が発生するかまだ未知数な部分がありますが、何かありましたら、こちらで報告させていただきます。

今のところ、レスポンスタイムも切り替え前と変わらず、安定して稼働しています。

1点困ったのが、ルートドメインとBeanstalkの相性の悪さです。
ハンズネットは、 https://hands.net/ というサブドメインなしのURLで運用しており、今まではRoute53のAliasレコードとしてELBを登録していたのですが、AliasレコードにはBeanstalkで払いだされる xxxxx.elasticbeanstalk.com といったドメインを指定することができません。
なので、せっかくBeanstalkで SWAP URLなどの機能があってもそれを使う事はできず、AliasレコードとしてBeanstalkの生成するELBを指定するという形になってしまっています。

新バージョンへの環境を切り替えを行う際には、Route53でAliasレコードをいじらないといけないですし、Rebuild EnvironmetするとELBが変わってしまうのでうかつに行えません。

何か良い方法などありましたら教えて頂けると嬉しいです。

また、ハンズがなぜサーバー負荷対策を必死こいてやってるかというと、毎年8月末に、ハンズメッセという大バーゲンがあるのも要因のひとつです。
お店も行列が出来るほどの大盛況なのですが、ネットストアも毎年大わらわで、現在、負荷対策真っ盛りです。

今年は 8月27日〜 （ネットストアは 8月26日 18:00〜) です。お得な商品を多数販売しますので、ぜひチェックしてみてください！

ではでは。

BeanstalkでカスタムAMIを使う方法をきちんと把握してなかったので試してみました。

やってみたところ、下記に書いてある手順をやるだけだったのですが、さらっと読んだだけだと分かりづらいので図にしてみました。

カスタム AMI の使用 – Elastic Beanstalk

手順としては下記のような感じです。

１）ベースとするBeanstalk のAMIを元にInstanceを立てる（Platform毎にいろいろあるので選択）
２）Instanceをカスタマイズ
３）Instanceを元にAMIを作成
４）Beanstalk の使うAMI を３）に設定

カスタム済みのAMIをいきなり指定するのではなく、一旦 BeanstalkのAMIからEC2を立ててそこをカスタマイズするという形になるんですね。

感想としては、.ebextensions でカスタマイズしたほうがメンテナンス性が高そう、とうか上記手順を頻繁にやるのはめんどくさいので、よほど特殊なカスタマイズでなければ .ebextensionsでカスタマイズするのが良さそうです。