AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

作者別: Taiji Inoue

こんにちは!

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


こんにちは、井上です。

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

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

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

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

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

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

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

Applicationの消失

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

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

こんなイメージです。

sikujiri_0

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

なんで消えてしまったか

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

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

sikujiri_1

sikujiri_2

押してしまったと同時に、全ての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では、レポジトリを削除する際には、レポジトリ名を入力しないと実行できなくなっています。あれはとても良いインターフェイスですね。

最後にお詫び

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


Twilioで世界に通用する再配達自動応答システムを作る


この記事は、Twilio Advent Calendar 2015 の21日めの記事です。
といいつつ、Twilioはほとんど触ったことなかったので、練習として佐川急便の再配達受付みたいなものをつくってみました。

デモ電話番号: 050-3159-5616 (かけると再配達受付っぽいものが動きます)

Twilioに作成した電話番号にかかってくると、Twilioがこちらの指定したURLにリクエストを送ってくれるようで、
こちらでは、それにレスポンスするAPIを用意すれば良いようです。

こんな感じですね。

twilio_uml

まずは、Twilioに設定する初期URLにあたるXMLを作ります。
これは、特に動的な部分はないので単なるXMLです。

File: index.xml

Say のタグに書いた内容を読み上げてくれるようです。language を指定すれば日本語も行ける。すごい。
あと、numDigits で桁数と、次のアクション(APIコール先)として twilio_2.php を指定しました。

7桁の番号が押された時に遷移する次のアクションの twilio_2.php はこんな感じです。
伝票番号の読み上げのところで、Playタグを使ってみました。
Playタグは、音声ファイルを再生してくれるタグのようです。
伝票番号の確認をし、良ければ1、修正する場合には 9 を押して貰うように促します。

File: twilio_2.php

入力された番号(1か9)によって条件分岐するのが、次のアクションの twilio_3.php です。
1 が入力されてたら、再配達希望日時を聞くフローへ、それ以外の場合には最初のフローへ戻すようにアクションを指定しました。

File: twilio_3.php

こんな感じで、ちょいちょいとXMLを返していくだけで、佐川の再配達受付システムができてしまいます。
初心者でしたが、3時間くらいで作ることができました。

ちゃんと作るには、DBとの連携とかいろいろやらなければならないですが、この時間でこれだけのものが作れるのはホント驚きです。

あ、タイトルで「世界に通用する」というのは、伝票番号の復唱のとき、3の倍数の時だけアホな感じで読み上げるからです。古いですね… すみません。

最後に

オフィスでアホな音声を発してくれた青柳さん、藤倉さんありがとうございました。


Swaggerで作るSPECファイルを小さいファイルに分割する


こんにちは、井上です。

Swaggerで始めるモデルファーストなAPI開発」を見て興味を持ったので、Swaggerをちょっと触ってみたのですが、すぐに、これ1ファイルの YAMLファイルでメンテナンスするの超しんどくない?と感じました。

なので、分割する方法を調べてみました。で、みつけたのが下記エントリ。
How to split a Swagger spec into smaller files

方法としては、別々のファイルに書いた定義を $ref で参照しておき、それを json-refs でマージして1ファイルに戻すというやり方のようです。

下記のような YAML ファイルを、

下記のように分割します。

起点となる index.yaml は下記のようにリンク集のような形になります。

サンプルが githubに上がっているので、それで試してみます。

全部マージして出力されました。

JSON形式になっていますが、resolve.js を下記のような感じに変更すると、YAML 形式で出力されます。
※ js-yaml が必要なので、別途 npm install js-yaml が必要です。

オプションに、resolveLocalRefs: false を加えると、ファイル内の $ref: ‘#/definitions/User’ は展開されず、別ファイルのみ展開されます。
同じ定義を繰り返し参照しているような場合には、展開しないほうが見通しが良いと思います。

使用できるオプションは、下記で参照できます。
json-refs/API.md at master · whitlockjc/json-refs


re:Invent 2015 AWS新サービスまとめ


1日目

1) Amazon QuickSight

  • BIツール
  • SPICE/高速な並列、インメモリのエンジン

2) Amazon Kinesis Firehose

3) SnowBall

4)Maria DB (RDS/DB Engine)

5) AWS Database Migration Service

  • 既存データベースからのAWS上のエンジンへの移行サービス
  • 今日から利用可能
  • マイグレーション以外のレプリケーションも可能

6) AWS SCHEMA CONVERSION TOOL

  • データベース間のスキーマを変換するツール
  • 今日から利用可能

AWS Config Rules

Amazon INSPECTOR

  • 自動化されたセキュリティアセスメント
  • セキリュティ的な問題をチェックしReportしてくれるサービス。

2日目

Amazon Kinesis Analytics

  • リアルタイムアナリティクス
  • SQL使える

EC2インスタンスアップデート(X1、 T2.Nano)

EC2 Instance Update – X1 (SAP HANA) & T2.Nano

X1

  • 2 TB 以上の memory
  • Four Intel® Xeon® E7 processors
  • 100 以上の vCPUs
  • 2016年 1Qリリース

AMAZON EC2 Container Registory

  • コンテナを商用環境で動かす最適な場所になる
  • スケジューラー
  • INTEGRATION WITH COMPOSE

Lambda アップデート

【AWS発表】AWS Lambdaのアップデート – Python, VPC, 実行時間の増加, スケジュールなど

  • VPC内にLambdaを配置
  • Python サポート
  • CRON 的な使い方ができるように
  • ファンクション実行時間の増加(最大5分まで)
  • ファンクションのバージョニング

Mobile Hub

AWS Mobile Hub – Build, Test, and Monitor Mobile Applications | AWS Official Blog

  • よくわからん

AWS IoT

全貌がよくわからないのでキーワードだけ…

【AWS発表】AWS IoT コネクテッドデバイス向けクラウドサービス

  • Device Gateway
  • Rules Engine
  • MQTT
  • New SDK (C/JS/arduino)

キーノート発表以外でリリースされたもの

  • Amazon Elasticsearch Service
  • Amazon RDS for Aurora 東京リージョン
  • Amazon API Gateway 東京リージョン
  • Amazon CloudWatch Dashboards

以上


クラウドの本質はみんなでシェア


こんにちは、井上です。

AWS re:Invent参加のため、ラスベガスに来ています。

本日、『GPS319 – Building Tomorrow’s Applications: Serverless Solutions in the Cloud』 というセッションを見て、風呂のなかでぼーっと考えた事を書いてみたいと思います。

考えた事というか、セッションの中でも「Compute Sharing=Lower Costs」みたいなことを言っていたのでそのまんまなのですが、クラウドとはみんなでリソースをシェアすることなんだなぁと改めて感じました。

例えば、家でラーメンが食べたいと思って、作って食べるには、調理器具とか、ガスとかの設備や材料を用意したりしないといけない。調理も自分。
これ、オンプレミス。

でも、面倒なのでちゃちゃっとお腹を満たすには、中華料理屋に行って食べる。これはラーメンを作るというサービスを提供してくれるASPを利用するみたいな感じ。

これでもとりあえずの欲求は満たせると思うのですが、大人数で行って、ラーメンと餃子とチャーハンと回鍋肉と酢豚と… と沢山たのんでシェアするといろいろ食べられて、お値段も安く満足度高い。 
こんな感じで、みんなでちょっとずつリソースを分け合って安く上げるようにしてくれる仕組みがクラウド。

で、さらにもっと大人数でシェアできるようになってくると、「ちょっとずつ」の部分がもっと細分化できるようになってきて、「俺は20円払うから酢豚に入ったパイナップル1カケだけ食いたい」みたいなワガママな要望にも応えられるようになってくる。
それが、Lambdaとか、ECSみたいな更に小さい単位でのリソースのシェアの形。

シェアする人が多ければ多いほど、いろんなシェアの形が生まれてきます。
AWS利用者はどんどん増えており、さらに新しいシェアの形がうまれる可能性もどんどん増えています。

眠くて何を書いているか良く分からなくなってきましたが、明日、どんなサービスがリリースされるか、今から楽しみです!