AWSの各サービスを雑に紹介する

えー、投稿しておいて何ですが、本稿本当に雑ですので、ご利用にあたってはあくまで自己責任ということで、よろしくお願いします。

コンピューティング

  • Elastic Compute Cloud (EC2)
    仮想専用サーバ、従量課金制 ≫公式

  • EC2 Container Registry (ECR)
    DockerHubみたいなやつ ≫英語公式 / Google翻訳 ≫Developers.IO

  • EC2 Container Service (ECS)
    Dockerオーケストレーション(デプロイ、起動停止制御) ≫公式 ≫@IT

  • Lightsail
    仮想専用サーバ、定額制 ≫公式

  • AWS Batch
    ECS対応バッチジョブスケジューラ ≫公式 ≫公式 ≫Developers.IO

  • Elastic Beanstalk
    プログラム実行環境 (Java, PHP, .NET, Node.js, Python, Ruby)、EC2を使用 ≫公式 ≫YouTube

  • AWS Lambda
    プログラム実行環境 (Node.js, Java, C#, Python)、サーバレス ≫公式

  • Auto Scaling
    EC2対応オートスケール制御 ≫公式

  • Elastic Load Balancing
    負荷分散、BIG-IPとかその手のヤツのクラウド版 ≫公式 ≫@IT

ストレージ

  • Amazon Simple Storage Service (S3)
    オブジェクトストレージ。ファイルサーバとしても一応使える ≫公式

  • Amazon Elastic Block Store (EBS)
    ブロックデバイス ≫CodeZine

  • Elastic File System (EFS)
    ファイルサーバ ≫公式

  • Glacier
    バックアップストレージ ≫公式

  • Snowball
    HDDをFedExで送るオフラインデータ転送

  • Storage Gateway
    バックアップデバイスはお客様各自のオンプレミスにてご用意下さい、AWSは対向するインターフェースを提供します、というもの ≫CodeZine ≫Developers.IO

データベース

ネットワーキング & コンテンツ配信

移行

  • Application Discovery Service
    オンプレミスサーバの構成管理情報を収集する ≫公式

  • Database Migration Service (DMS)
    RDBをオンプレミスからAWSへ乗り換えるときに使う支援ツール

  • Server Migration Service (SMS)
    サーバをオンプレミスからAWSへ乗り換えるときに使う支援ツール

開発者用ツール

  • CodeCommit
    GitHubみたいなやつ

  • CodeBuild
    従量課金制ビルド

  • CodeDeploy
    コードデプロイ

  • CodePipeline
    Continuous Integration (CI) オーケストレーション。ビルド→デプロイの自動実行フロー定義。

  • AWS X-Ray
    分散アプリケーションのトレース ≫Serverworks

管理ツール

セキュリティ、アイデンティティ、コンプライアンス

  • AWS Identity and Access Management (IAM)
    AWSの認証、権限管理単位 ≫Developers.IO

  • Inspector
    脆弱性検出 ≫公式

  • Certificate Manager
    X.509証明書の管理 ≫公式

  • AWS Cloud Hardware Security Module (HSM)
    秘密鍵の保管(暗号、署名) ≫公式

  • AWS Directory Service
    Active Directory ≫Developers.IO

  • AWS Web Application Firewall (WAF)
    ファイアーウォール ≫公式

  • AWS Shield
    DDoS対策 ≫公式

分析

人工知能

IoT

ゲーム開発

モバイルサービス

  • Mobile Hub
    AWSのいろんなmBaaS系サービスを統合的に使えるコンソール画面 ≫Qiita

  • Cognito
    ソーシャル認証+データ同期。FacebookログインとかTwitterログインとか ≫Cookpad

  • AWS Device Farm
    テスト環境。Android, iOSの実機にリモートアクセスしてテストができる ≫公式

  • Mobile Analytics
    アプリの使用データの測定、追跡、分析 ≫公式 ≫Developers.IO

  • Pinpoint
    プッシュ ≫Qiita

アプリケーションサービス

  • Step Functions
    フローチャートみたいなビジュアルワークフローを画面上に描いて分散アプリケーションを構築する、というもの ≫公式

  • Amazon Simple Workflow (SWF)
    旧世代サービス。現在はStep Functionsを推奨 ≫公式

  • API Gateway
    HTTP API化 ≫公式

  • Elastic Transcoder
    動画、音声のフォーマット変換。つんでれんこaaSみたいなヤツ ≫Serverworks

メッセージング

  • Amazon Simple Queue Service (SQS)
    メッセージキュー ≫公式

  • Amazon Simple Notification Service (SNS)
    プッシュ ≫公式

  • Amazon Simple Email Service (SES)
    E-mail配信。メルマガとか ≫公式

ビジネスの生産性

デスクトップとアプリケーションのストリーミング

  • Amazon WorkSpaces
    仮想デスクトップ ≫impress

  • Amazon WorkSpaces Application Manager (WAM)
    Amazon WorkSpaces端末にアプリを配信するツール ≫serverworks

  • AppStream 2.0
    Citrix XenAppみたいなやつ ≫Developers.IO

参考文献

AWS ドキュメント
https://aws.amazon.com/jp/documentation/

AWS re:Invent 2016 発表サービスを三行でまとめる
http://qiita.com/szk3/items/a642c62ef56eadd4a12c

続きを読む

AWS g2インスタンスにCUDAを入れる際の落とし穴(2017年3月版)

概要

chainer/Tensorflowで使うことを目的に、g2インスタンスにCUDAをインストールしました。

もちろん既にCUDAインストール済みのAmazonLinuxを使用するという選択肢もありますが、今回はUbuntuが使いたかったためまっさらの状態からCUDAを入れました。その際にハマった箇所をメモします。

※ 本手順ではCUDA7.5を指定しましたが、CUDA8.0でも同様と思います。

EC2インスタンスの構成

CUDAのインストールを始める前に、この作業を行ったEC2のインスタンスの設定は以下の通り。

  • AWS EC2のインスタンス(g2.2xlarge)
  • AMIはUbuntu Server 14.04 LTS (HVM)

【参考】Ubuntu14.04にcuda 7.5をインストール

注意点としては、EBSの領域(OSが入る領域)がデフォルトで8GBです。作業領域はS3をマウントするにしても、後々窮屈になるので16GBへの変更がオススメです。

【参考】http://qiita.com/pyr_revs/items/e1545e6f464b712517ed

基本的なインストールの流れ

基本的に流れは、以下いずれかの手順の通りです。

【参考】Ubuntu14.04にcuda 7.5をインストール
もしくは
【参考】 http://www.cs.stevens.edu/~kbatsos/awscudasetup.html

なお、Nvidiaグラフィックドライバは最新のものではなく、Version367系の最後のものを選びます。理由は後述。

落とし穴

上記いずれの手順でも、CUDAインストール後 deviceQuery でCUDAの動作確認をする段階で、

$ cd /usr/local/cuda/samples/1_Utilities/deviceQuery
$ sudo make
$ ./deviceQ uery
./deviceQuery Starting...

CUDA Device Query (Runtime API) version (CUDART static linking)

cudaGetDeviceCount returned 30
-> unknown error
Result = FAIL

といったエラーになります。その他、以下のようなエラーが確認できます。

$ dmesg
(中略)
[ 568.286327] NVRM: The NVIDIA GRID K520 GPU installed in this system is
[ 568.286327] NVRM: supported through the NVIDIA 367.xx Legacy drivers. Please
[ 568.286327] NVRM: visit http://www.nvidia.com/object/unix.html for more
[ 568.286327] NVRM: information. The 375.26 NVIDIA driver will ignore
[ 568.286327] NVRM: this GPU. Continuing probe...
$ nvidia-smi

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
$ sudo modprobe nvidia

modprobe: ERROR: could not insert 'nvidia_375': No such device

原因

  1. g2インスタンスのGPUであるK520は、NVIDIAグラフィックドライバーVersion367.xxまでしか対応していない
  2. CUDAインストーラは、CUDAを入れるついでにNVIDIAグラフィックドライバーを最新(367.xxより新しいもの)に更新してしまう。GPUの対応状況を確認せずに! ← コイツがお馬鹿

というコンボにより、上記の現象が発生します。

対処法

対処はシンプルで、上記の落とし穴にはまった後、以下のコマンドでドライバをVersion367へ戻すことで解消します。

$ sudo apt-get install -y nvidia-367

【参考】 https://github.com/NVIDIA/nvidia-docker/issues/319

対処した後の確認結果

成功した場合、以下のような表示となります。

cd /usr/local/cuda/samples/1_Utilities/deviceQuery
sudo make
./deviceQuery
(中略)
deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 8.0, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GRID K520
Result = PASS
$ sudo modprobe nvidia
(何もメッセージが出ない)
$ sudo dpkg -l | grep nvidia

ii nvidia-367 367.57-0ubuntu0.14.04.1 amd64 NVIDIA binary driver - version 367.57
rc nvidia-375 375.26-0ubuntu1 amd64 NVIDIA binary driver - version 375.26
ii nvidia-modprobe 375.26-0ubuntu1 amd64 Load the NVIDIA kernel driver and create device files
ii nvidia-opencl-icd-367 367.57-0ubuntu0.14.04.1 amd64 NVIDIA OpenCL ICD
rc nvidia-opencl-icd-375 375.26-0ubuntu1 amd64 NVIDIA OpenCL ICD
ii nvidia-prime 0.6.2.1 amd64 Tools to enable NVIDIA's Prime
ii nvidia-settings 375.26-0ubuntu1 amd64 Tool for configuring the NVIDIA graphics driver

※ iiはインストール済み、rcは削除済みだがconfigは残ってる の意味

【おまけ】 CUDAインストールの後の手順のハマりどころ

cuDNNを入れた後、tensorflow/chainerのGPUインストールが上手くいかないのは大抵、下記のいずれかが原因

  • 環境変数の設定が足りない。 → 公式のインストール手順を再確認
  • 一般ユーザの.bashrcに環境変数の設定をしておいて、sudo pip install している。pip install –user chainer でユーザ単位でインストールするか、virtualenvを使うのが簡単

感想など

対策をサラッと書いてますが、これに気付くまでが結構長かった。何か手順を間違えたかとやり直したり、ドライバのバージョンが原因と気付いてもどのタイミングで最新にされてしまうのかが分からずで半日以上潰しましたよね orz

結局 ググってヒットした上記のgithubのissueで、「オレも、オレも同じ感じでダメ!」って質問したらNVIDIAの中の人が即レスしてくれて一発解決&感謝だったわけですが… うーん 複雑な気持ち^^;

【追記】既に同じような記事が…

Twitterのツイート検索をしてみたところ、AWS E2 G2インスタンス上にKeras環境を構築する 2017年2月版 同様の手順を実施されている記事がありました。タイトルの最後に~年~月版と入れているところがソックリで笑ってしまいました^^;

この方の場合は、CUDAのインストール → Nvidiaグラフィックドライバの順にインストールを行っているので、この記事で起きているような現象に出遭わずに済んでいるようです。このやり方がスマートかも。

続きを読む

「AWS IoTのデータをKibanaに表示する」をやってみた。2017/3版

AWS IoTのデータをKibanaに表示するを実際にやってみました。

記事の投稿以降、AWS IoTが直接Elasticsearch Serviceと連携できる様になったとのことで、そのあたりも試しました。

【アップデート】 AWS IoT が Elasticsearch Service と CloudWatch に連携できるようになりました
https://aws.amazon.com/jp/blogs/news/aws-iot-update/

なんと、サーバー側はノンコーディングです。

Elasticsearchインスタンスを立ち上げる

元記事と基本的に同じです。
まずは、立ち上がりが遅いElasticsearchを先に立ち上げておきましょう。
Domain nameを plant-sensor、Instance typeはt2.micro.elasticsearchが選べなかったのでt2.small.elasticsearch (Free tire eligible)、Instance countは 1、Strage typeは EBS に設定します。

image

Kibana のURLをクリックするとKibana4の画面が表示されます。EndpointのURLはAWS IoTで使います(自動で設定されます)。

AWS IoTでThingやRuleを作成

元記事の通りしようとしても、画面構成が違うのか、メニューが見つかりません。なので、順を追って解説します。

image
(こんな感じでしたっけ?)

「Get started」を押します。そして、左メニューの[Registory]->[Things]を選択します。
「Register a thing」を押します。

image

plant-sensor という名前のThingを作成。

image

左メニューの[Security]を選び、「Create certificate」を選択します。

image

色々ダウンロードできますので、一旦すべてダウンロードした後、「Activate」を押します。

ダウンロードできるもの

  • A certificate for this thing
  • A public key
  • A private key
  • A root CA for AWS IoT

続いてPolicyを作成。トップ画面の左メニューの[Policies]を選び、「Create a Policy」を選択します。

image

名前をつけ、とりあえずActionはiot:*としました。Resource ARNについてですが、キャプチャではtopic/replaceWithATopicとなってますが、plant/sensorsまたは*/*などにに変えましょう。

image
image

certificateとPolicyの紐付け
左メニューの[Certificates]を再度選び、先程作成したceritificateを選択。「Actions」メニューの「Attatch policy」を選ぶ。

image

同様に、「Attatch thing」も行います。

最後にRuleを作成します。トップ画面の左メニューの[Rules]を選び、「Create a rule」を選択します。

image

今回は plant/sensors というトピック名でデータを飛ばそうと思うので、Topic filterに plant/sensors を設定します。

image

image

Actionの指定は、「Add Action」ボタンを押して行います。

image

2017/3/14時点で以下のActionが選べます。一番下の「Elasticsearch Service」を選びます。

image
image

Elasticsearch Service用の設定画面が出ます。
IDに${newuuid()}、Indexにtimestamp、Typeにtimestampと指定し、IAMロールも追加します。

image

これで、Thing, Certificate, Policy, Ruleが作成できました。元記事のように一覧では表示されないようです。

仮想的なIoTデバイスを作成

元記事の通り、plant-sensor.jsを作成します。
そして実行です。

実行してみましょう。

$ npm init
$ npm install --save aws-iot-device-sdk
$ node plant-sensor.js
connect
{"timestamp":"2017-03-14T15:19:47.401Z","humidity":45,"temperature":19,"lux":32701,"moisture":309}
{"timestamp":"2017-03-14T15:19:48.405Z","humidity":43,"temperature":19,"lux":33473,"moisture":309}
{"timestamp":"2017-03-14T15:19:49.406Z","humidity":44,"temperature":19,"lux":30713,"moisture":295}
{"timestamp":"2017-03-14T15:19:50.408Z","humidity":42,"temperature":20,"lux":31499,"moisture":296}
{"timestamp":"2017-03-14T15:19:51.414Z","humidity":46,"temperature":20,"lux":30687,"moisture":315}
{"timestamp":"2017-03-14T15:19:52.417Z","humidity":46,"temperature":20,"lux":31960,"moisture":302}
{"timestamp":"2017-03-14T15:19:53.420Z","humidity":45,"temperature":20,"lux":30782,"moisture":301}

Kibanaでダッシュボードを作成する

Kibanaを起動すると、エラー画面のような形となりますが、初期設定ができていないからだと思います。

image

Index name or patternのところにtimestampといれると、設定できます。

image

Discoverタブを見てみると、ちゃんとデータが来ているのを確認できます。

image

では、チャートを作ってみましょう。Visualizeタブで、以下の様な感じでグラフを作成します。

image

最後にダッシュボードを作成します。Dashboardタブを選択して、Add visualization で先ほど作成したチャートをポンポンと選択していくだけです!

image

終わりに

元記事を作成された、@hideyuki さん、勝手に更新版を投稿してしまいました。ありがとうございます。

続きを読む

2017/3/11 JAWS DAYS 2017 参加メモ

http://jawsdays2017.jaws-ug.jp/

赤ドクロ Presents 『AWSでアプリ開発するなら 知っておくべこと』

https://www.slideshare.net/keisuke69/aws-73040279

アーキテクチャのベストプラクティス

  • Design for failure

    • 単一障害点をなくす、すべてが失敗し得るという前提で考える

      • 最初に1ホストを複数に分割する⇒Webとデータベース(RDS)
      • 複数のWebインスタンスを異なるAZで
      • RDSはMulti-AZ
      • ELBを利用して負荷分散
  • Build Security Every Layer
    • 通信経路および保存されたデータの暗号化、IAM/セキュリティグループ
  • Leverage Many Storage Options
    • 万能なデータストアは存在しない、特性に応じて使い分ける
    • Storage
      • Object Storage: S3, Glacier
      • File/Block Storage: EFS(NFS、共有ディスク), EBS
    • Database
      • NoSQL: ElastiCache, DynamoDB
      • SQL: RDS(トランザクション処理), Redshift(DWH)
      • 静的コンテンツはS3に
      • セッションやステートはDynamoDB
      • DBのキャッシュはElastiCache
  • Implement Elasticity
    • IPアドレスで参照しない(名前ベースで)、分散させる
  • Think Prallel
    • EMRを用いて並列のMapReduceジョブを実行、ELB、1つのKinesis Streamと複数のKCLアプリケーション、バックエンドとしてのLambda
    • 1インスタンスでN時間 = N台を1時間 ⇒ コストは同じ
  • Loose Coupling
    • コンポーネント間の結合度が緩やかになるほど、スケーラビリティは高まる
    • すべてのコンポーネントはブラックボックスとしてデザイン(APIアクセス、DNS名でアクセスなど)
    • Queueを使って疎結合に(部分的なretryがしやすくなる、重たい処理だけをスケールする)
    • Service Discovery
      • 各サービスで増えたリソース、減ったリソースに対して透過的にアクセス
      • Auto Scalingを使ったELB自動登録、Consulなど
    • Asynchronous Integration
      • 同期処理である必要がなければ非同期にする(その処理、本当にレスポンス必要ですか?)
      • アプリケーションがブロックされない
      • スケーラビリティ&高可用性
      • Frontendを停止することになくBackendを容易にメンテナンス可能
      • リクエストの処理順序やリトライ等の制御が容易に(一方、数珠つなぎで全体の見通しは悪くなる)
  • Don’t Fear Constraints
    • より多くのメモリが必要?⇒負荷分散、キャッシュ
    • データベースのIOPSが必要?⇒リードレプリカ、シャーディング、データベースのキャッシング
    • 問題のあるインスタンスを破棄し、置き換える

The Twelve-Factor App

  • Dockerによるアプリケーション開発やLambdaのようなサーバレスコンピュートの普及に伴い、改めて重要性が増しつつある
  • Codebase
    • デプロイされているアプリとコードベースは常に1:1であるべき
  • Dependencies
    • 依存関係を明示的に宣言し分離する
    • 特定の環境に暗黙的にインストールされているパッケージやツールに依存せず、アプリに同梱する
    • 例:gemとbundler
  • Config
    • OSレベルの環境変数によって注入されるべき
    • 設定ファイルは言語/フレームワークの環境依存になる
  • Backing Service
    • ネットワーク越しに使うものはすべてリソースとして扱い(URLのように)、データベースはアタッチされたリソースとして扱う
    • リソースの切替はリソースハンドルの切替(URLの切替)とする
  • Build
    • build、リリース、実行の3つのステージを厳密に分離する
    • すべてのリリースは一意のIDを持つべき(どの環境にどのIDがdeployされているか)
  • Process
    • アプリケーションをStatelessなプロセスの組み合わせとして実行!
    • スケールアウトの単位としてプロセスモデルは分かりやすい(スレッドはメモリ共有するなどで管理が複雑)
    • 永続化する必要のあるデータ(次のリクエストでも利用するデータ)はDBなどstatefullな外部サービスを利用
    • ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとして扱う
  • Dsiposability
    • グレースフルシャットダウン
  • Dev/prod parity
    • 開発・ステージング・本番環境をできるだけ一致させ、CI/CDの効果を発揮する
  • Log
    • 出力ストリームの保存先やルーティングにアプリは関与しない(標準出力に吐き出すだけにする)
    • 収集、保存、インデックス化し分析する環境をアプリの外に用意する
  • Stateless
    • ステートフルにになる要素を水平スケールするリソースの外部に配置
    • Session情報(スケールアウトすると新しいインスタンスから見えない)⇒DynamoDBに見にいってローカルにキャッシュ

DevOps

  • 無駄やボトルネックを取り除くことで、ライフサイクル(フィードバックループ)を効率化し、高速化する
  • Cluture:End to EndでOne teamであること、主体的なオーナーシップ、行われた作業の結果に対する可視性を高める
  • Practice:Automate Everything、Test Everything, CI/CD/Infrastructure as a code, etc…
    • 自動化と構成管理:プロビジョニング、設定、オーケストレーション、レポーティング
    • ApplicationとInfrastructureをいずれも、バージョン管理し、build&testし、成果物を登録し、デプロイする
    • 繰り返し継続的に行う
  • Tool

DevOps tool on AWS

  • ほとんどのサービスにAPIが用意されている⇒プログラミングの文脈でインフラを制御する

    • 各言語のSDKが用意されている(IDE向けのプラグインも用意されている)
  • Cloud formation
  • Jenkinsを使ったデプロイ

ベストプラクティス

  • 自動ロールバック:まずはロールバックし、その後ログ/グラフなどを用いてデバッグする
  • ダッシュボードで通常時と異常時を把握する

AWS SECURITY DEATH m/ ~セキュ鮫様からのお告げ~ by Security-JAWS

ネットワーク

  • public subnet / private subnet

    • public subnet: インターネットに直接接続可能なサブネット(公開サーバを置く、EIPとの紐づけもできる)
    • private subnet: NATゲートウェイを経由して内⇒外のインターネット通信は可能
  • statefull / stateless
    • NAT配下のクライアントのSource Portはハイポート(1024-65535)からランダムに設定される
    • Statefull: 戻りの通信もよろしくしてくれる
    • Stateless:内⇒外も書かないといけない(1024-65535/tcp)
    • Security GroupはStatefull⇔Network ACL(subnet単位で通信を制御)はStateless
  • VPN
    • ユースケース

      • Webサーバ/DBサーバのメンテナンスはプライベートネットワーク経由で行いたい(平文でインターネットを通さない)
      • 社内システムで事業所とAWSの間(Direct Connectは品質を高めることもできる)
      • AWSを既存システムの拡張リソースとして使用するような場合(繁忙期など)
    • VPNの場合、AWS側には2つのVPNエンドポイントが用意される(Customer Gateway側で2つのトンネルを張る必要がある)
      • static routingもしくは、BGPによるダイナミックルーティング(対応機種のFAQ参照)
  • Direct Connect(専用線接続)
    • 宅内~接続ポイント⇒一般的には通信キャリア
    • 接続ポイント~AWS⇒AWSが提供
    • VLAN分けをできるキャリアと、できないサービスがある
    • TOKAIコミュニケーションズ、Colt(旧KVH)

WAF/DDoS

  • 全脳アーキテクチャ若手の会
    #### DDoS
  • DDoS対策(コストがかかる)、DDoSをあえて受ける(落ちてもいいサイトであれば、放置するのも一つ)
    • L3/L4:Infrastructure
    • L7: Application
  • AWS Shield
    • CloudFrontを使って、Shieldオプションを有効化
    • Shieldの後ろはAWSでも、オンプレでも対策可能
    • 防御対象:CloudFront, ELB, ALB, Route53
    • 監視:常にモニタリングしてベースラインの作成、異常検出
    • Basicは無料で利用可能、AdvancedはDRT付き
    • Billing Protection
    • DRT:WAFのチューニングやルール作成もやる
    • CloudFrontさえ入っているなら、導入しておかない手はない!

WAF

  • FWやIDS/IPSでは防ぐことができない不正な攻撃を遮断(アプリケーション脆弱性など)

    • PCI-DSS 6.6にもWAF導入について明記されている
  • AWS WAF
    • カスタムルール(IPアドレス制限/文字列制限)、SQLI/XSSといった基本的な対策が可能
    • 構成:CloudFront, ELB, ALBに仕込めるマネージドWAF
    • ルールを正規表現で書けない、WAF検知ログは100件まで
  • AWS WAF / WAF on AWS / SaaS WAF / Cloud WAFの比較
    • SaaS WAF / Cloud WAF: 正常な通信の確認、DNSの向き先変更程度で導入できる
    • WAF on AWSはオートスケールに対応している製品が多い
    • AWS WAFはセキュリティ面では物足りない
  • 「セキュリティ開発」はなぜ浸透しないのか

AWS Config

ごちゃごちゃしやすいAWSリソースを簡単に「見える化」できる

  • 構成管理、変更管理のためのサービス(よく使うサービスは対応済)

    • 構成情報のスナップショットの取得
    • 変更内容を追うことができる、SNSを使った通知も可能
    • AWSリソース間の関係性の確認(EC2とVPC/Security Group/ALBとの関係)
    • EC2 Systems Manager: エージェントを入れると、OSの中の情報を取れる、コンソールからコマンドを発行⇒OS上の変更管理が可能になった
    • IAMの構成管理
  • ユースケース
    • AWSリソースの一覧でAWSリソースを確認できる、削除されたリソースについても追跡可能
    • いつ、どのように変更されたかを記録するので証跡として利用可能
    • 関連するAWSリソースも辿れるのでトラブルシュートしやすい
  • AWS Confing Rules
    • AWS Configで記録した設定が正しいかを判定するルールを定義できる
      • セキュリティグループがフルオープン
      • MFA設定していない
      • ACMの証明書の有効期限があと少し
  • マネージドルール
    • Instanceにtagをつけているか?(billingのために、作った人/プロジェクト名をつける)
    • SecurityGroupがフルオープンになっているか?
  • カスタムルール
    • 判定機構はLambdaで実装⇒極論、修正することもできる
    • awslabsにカスタムルールが公開されている(現在34)
  • AWS Configを有効化して可視化
    • Auto Scalliingで、頻繁にインスタンスの起動/削除をしていなければ、課金額は大きくない

Chat bots with Amazon Lex

  • Amazon Lex:音声/テキスト処理

    • Alexaと同じ技術で提供されている
    • 音声認識+自然言語処理
  • コンポーネント
    • ユーザ入力⇒出力
    • Intents:意図(Utterance/Slots)
    • Fulfillment:処理
  • Utterance
    • Intent(例:RegisteruserForEvent)に対してユーザ入力を紐づける
    • Sample utteranceを複数事前に定義する
    • 反復して学習することによってユーザ入力の言い回しの揺れを吸収(徐々に改善していく)
  • Slot
    • SLOT NAME: eventDate, SLOT TYPE: AMAZON.DATE
    • 12 March 2017 / tomorrowみたいな揺れを吸収できる
  • Fulfilment
    • AWS Lambdaとの統合⇒クライアントにレスポンスを返す
  • 複数のintentをflowにすることで、より自然な対話が可能になる
    • もう少し知りたいですか? ⇒ yes ⇒ 次のintentに繋げる
    • 曖昧な答えの場合は、プロンプトを出す(「”yes”か”no”で答えてください」)
  • Lambdaとの統合
    • Lexがユーザ入力をparseし、intent/slotsを渡してlambdaを起動、lambdaからレスポンスを返す
    • dialogAction:会話の流れをつかさどる(例:ConfirmIntent)
    • facebookの場合、Response cardを返すこともできる(ユーザに選択肢リストを提示)
  • Lambda Functionの実装例
    • switchでintentごとの処理を定義して、1 functionで複数intentを処理
    • LexResponseBuilderでレスポンスをbuild
  • English Onlyでlaunchするが、複数言語をサポートするロードマップ
    • 開発者からAWS Japanへプレッシャーを!
  • 最初はよくテストして、エラーが多いようであればintentを細かく設定するなどの工夫が必要

サーバレスの今と未来

https://www.slideshare.net/YoshidaShingo/serverlessnowandthen

サーバレス

  • パラダイムシフト

    • サーバが要らないということではなく、開発者はサーバについて「考えなくてもよくなる」
    • 2014年末のre:InventにてLambdaの発表
    • 最大の特徴は、課金は使った分だけ(メモリ×時間×実行回数)
  • Function as a Service
    • アーキテクチャにおける責務

      • Stateful >> Stateless
      • 永続データ >> 揮発性
      • バッチ >> イベントドリブン
  • Lambda goes everywhere
    • コンテナベースの実行環境はportabilityが高いので、いろいろなところにデプロイできる
    • Athenaの基盤もLambda
    • Greengrass(AWS IoT)
    • CloudFrontのEdgeの上

代表的なサーバレスアーキテクチャ

  • UIドリブンアプリケーション

    • 認証ロジックをBaaS、DynamoDBにクライアントから直接アクセス、SPA+API Gateway
  • メッセージドリブンアプリケーション
    • オンライン広告システム
    • コンテンツのサムネイル作成(image magicを載せたlambda)
    • ログのストリームプロセッシング(kinesis/kafkaから取って、加工して、S3やDynamoに入れる)

エコシステム

  • プラットフォーム事業者、フレームワークやツール、アプリケーション開発者

    • アプリケーション開発者のノウハウ発信が足りない
    • cloud packの毎日放送事例
  • Serverless framework, Apex, Lamvery, Swagger, AWS Serverless Application Model(SAM), Postman…
  • SAM
    • CloudFormationテンプレートで管理できる
    • lambda, API Gateway, DynamoDBがサポートされている
    • app-spec.yaml -> CloudFormation(codeはS3経由でデプロイされる)

サーバレスだからこそできることをやる

  • 10X Product Development

    • TypeScriptしか書かず、あとは外部のサービスを使っている
    • firebase(auth), Netlify(static site hosting), Cloudinary(画像管理), Algolia(検索)
  • Serverless, NoOpes and the Tooth Fairy
    • 来るサーバーレスな未来では、アプリケーション開発者が運用に責任を持つ
    • プロバイダの技術情報や、内部技術が何に依存しているか理解する
    • 可視性が下がる、自分自身で問題をfixできないし新機能を実装することもできない
    • 売れていないサービスはシャットダウンされるかも
  • 日経新聞事例(紙面ビューアー)
    • 最大18,000回/1分間のinvocation
  • システムをリアクティブに設計する
    • イベントの発火やwebhookなどに対応している周辺のマネージドサービスとうまくつないでいる
    • シンプルなマイクロサービスとして
    • 一度トライアルしておき、いざ活用する前にはまりどころなど判断

SPAの開発の流れ

  • ビュー/アプリ(js)開発

    • ビューの作成
    • テスト駆動でアプリコードを追加(テストがないと、統合時に問題が起こったときの切り分けが困難)
    • 例:jQuery+Jasmine
    • ローカルで開発可能、チーム開発がはじまったらS3で
    • テスト時のブラウザキャッシュに注意(chromeの開発者ツールでdisable cacheするとか)
    • AWSに繋ぐ前に、1行書いたら1行テスト
  • Cognitoを使った認証+フェデレーション
    • 例:Google+
    • Googleで認証してIDが払い出される
    • ブラウザがCognitoにJSでアクセス、CognitoがGoogleに検証、OKであればDynamoDB書き込み権限を払い出す
  • DynamoDBを使ったデータの管理
  • Lambdaでシステム強化
    • DynamoDB直接読み書きでは仕組みとしてできてしまう、「不正なクエリからの保護」(lambdaでvalidationするなど)
    • 「ユーザ全員分の集計」などの情報提供のため
  • Serverless Single Page Apps
    • Ben Rady著、Step by Stepガイド(日本語版が間もなく出る予定)

参考(ところどころで言及されていた別発表)

[AWSワークショップ] Amazon Kinesis Analyticsを触ってみよう

kinesis

  • モチベーション

    • 処理した結果を複数システムに送る必要がある

      • kafka or Kinesis Streams
    • しかも機械学習を行なう
      • Spark Streaming or Storm
  • Kinesis
    • Streams

      • マネージドkafkaのイメージ:入出力に制限はある(入力:秒間1MBまたは1,000put)
    • Firehose:S3, Redshiftへ簡単に配信
    • Analytics:SQLクエリー
  • Stream Source/Destination(StreamかFirehose)
    • 入力側を決定する(Strems or firehouse)
    • 入力データの型定義をおこなう
    • SQL分を作成、デプロイ
    • 出力先を決定する(Strems or firehouse)
  • kinesis demo stremasは良く停止するので注意・・・
    • データ定義は大文字で定義(もしくはselect句をダブルクォーテーションで挟む)

Windowの概念

  • Tumbling Window(例:1分ごとに出力)

    • FLOOR((“SOURCE_SQL_STREAM_001”.ROWTIME – TIMESTAMP ‘1970-01-01 00:00:00’) SECOND / 10 TO SECOND)
    • 10 TO SECOND⇒10秒間隔
  • Sliding Window(データが流れてきたら出力を開始する)
    • Time(60sec:レコード受信をトリガーに直近60sec分を集計)
    • Row(2rows:自分+直近2レコード)
    • 1つのdestinationに対して、TimeとRowを両方設定できる

Reference Dataの追加

  • AWS CLIでのみ追加が可能
  • 例:S3のファイルを見る
  • 現状、Reference Dataを追加すると動作しない(サポート確認中)

まとめ

  • Firehose -> Elastic Search -> KibanaとすべてAWSコンソールで設定可能
  • 構築は非常に楽、標準SQL、Firehoseで接続が簡単
  • バグが多い、性能評価がしにくい
  • kinesis streamsはzookeeperの管理が不要、KPLと併用すれば非常に安い
  • Analyticsは簡単な集計処理ならよいが、複雑な処理はSpark Streaming等を利用したほうがよい

[Alexaハンズオン] Alexa Skills Kit で遊ぼう【基礎編】

続きを読む

2017年という今この時代に2014年のAMIにtd-agent1系をインストールした話

こんにちは〜♪ヽ(´▽`)ノ 三寒四温な今日この頃。
業務でハマってしまったことを書いてみます:thumbsup:

インストール環境
・Amazon Linux AMI x86_64 HVM EBS
amzn-ami-hvm-2014.03.2.x86_64-ebs
・td-agent-1.1.21-0.x86_64

1. td-agent1系をインストールしようとしてみた

td-agentの1系を業務上どうしてもインストールしないといけなくなったのだけど2017年2月現在td-agent1系は下記コマンドでインストールができないのだ!!

$ curl -L https://toolbelt.treasuredata.com/sh/install-redhat.sh | sh

実行すると下記FluentdBlogの通りGPGKeyが古いからダメだよ!とエラーが出る。

cf.Update the GPG key
http://www.fluentd.org/blog/update-gpg-key-for-td-agent

これはどうしたものか…(´・ω・`)?

2. yumリポジトリから直接インストールを試みる

$ sudo rpm -ivh http://packages.treasuredata.com.s3.amazonaws.com/redhat/x86_64/td-agent-1.1.21-0.x86_64.rpm

依存性のエラーが発生!:persevere:

td-libyaml is needed by td-agent-1.1.21-0.x86_64

ほぉ…:expressionless: td-libyamlが必要か!ではインストールするとしよう!

3. td-libyamlをインストールする

$ sudo rpm -ivh http://packages.treasuredata.com.s3.amazonaws.com/redhat/x86_64/td-libyaml-0.1.4-1.x86_64.rpm

さてこれで終わったわけではない!

libcrypto.so.6()(64bit) is needed by td-agent-1.1.21-0.x86_64
libreadline.so.5()(64bit) is needed by td-agent-1.1.21-0.x86_64
libtermcap.so.2()(64bit) is needed by td-agent-1.1.21-0.x86_64

残りの依存性の欠如エラーを解消していこうか!:construction_worker:

4. 足りないライブラリをインストールしてみる

$ sudo yum install libcrypto.so.6

お!直接インストールはうまくいかない…(´・ω・`)

じゃあ仕方ない! $yum whatprovidesでライブラリをサポートしているパッケージを探るか!

5. ライブラリをサポートしているパッケージを探す

cf. http://www.geek.sc/archives/620
上記記事を参考にしました。ありがとうございますm(_ _)m

$sudo yum whatprovides libcrypto.so.6

すると、openssl098eのパッケージに依存していることがわかる。
なのでyumインストールする(`・ω・´)ノ

$sudo yum install -y openssl098e

その他のライブラリも同様に調べていくとcompat-libtermcapとcompat-readlineが必要なことがわかる。

インストーーーール!!!

$sudo yum install -y compat-libtermcap
$sudo yum install -y compat-readline

5. 改めてyumリポジトリからインストールを試みる!

$sudo rpm -ivh http://packages.treasuredata.com.s3.amazonaws.com/redhat/x86_64/td-agent-1.1.21-0.x86_64.rpm

お!インストールできた!!!GPG Keyの警告は出るけどインストールはできるんだね:sweat_smile:

ということで起動コマンドを叩いてみる。

$ /etc/init.d/td-agent start

無事起動!キターーー!!!.+:。(≧∇≦).+:。
とまあ色々ググりながらトライ&エラーを続けて無事インストールできました。ちなみにtd-agentはゲームのアクセスログ集計に使っていたりします(。uωu。)

以上でしたー!(´∀`)ノ☆

続きを読む

Vagrant+AnsibleでUbuntu16.04にDocker環境を構築

概要

最近話題の構成管理ツールAnsibleを使ってAmazon EC2上でDocker環境を構築する。

future.jpg

なぜAnsible+Docker?

本音としては、単に両方使ってみたかったから。
ただ、Ansible単体でやらない言い訳みたいなのもある。

  • 色んなサービスの設定ファイルをサーバに直接混ぜて配置したくない
  • サービス単体でアップデートや環境を破壊とかしたい
  • 各サービスに合わせてミドルウェアの整合性合わせてって作業が面倒くさい

実施内容

  • AmazonEC2 + Vagrantの導入(実施済み)
  • AnsibleのPlaybooks作成
  • Vagrantfileの修正
  • Dockerの動作確認

AmazonEC2 + Vagrantの導入

こっちを参照

AnsibleのPlaybooks作成

$ tree
.
├── README.md
├── Vagrantfile
├── docs
│   └── ec2
│       └── setup.md
└── setup
    └── provision
        └── docker.yml

4 directories, 4 files
docker.yml
- hosts: all
  become: yes
  tasks:
    - name: apt-get install packages
      apt: pkg={{ item }} state=present update_cache=yes
      with_items:
        - curl
        - apt-transport-https
        - ca-certificates

    - name: set dockers official gpg key
      apt_key:
          url: "https://download.docker.com/linux/ubuntu/gpg"
          state: present
      register: set_key

    - name: set up the stable repository
      apt_repository:
        repo: deb [arch=amd64] https://download.docker.com/linux/ubuntu {{ ansible_distribution_release }} stable
        state: present
      when: set_key
      register: set_repo

    - name: install docker-ce
      apt: pkg=docker-ce state=present update_cache=yes
      when:  set_repo

Vagrantfileの修正

要点は2つ

  • サーバ側にAnsibleのPlaybookを送信する
  • Provisionにansible_localを設定し、サーバでAnsibleのインストール+実行を行う
Vagrantfile
  Dotenv.load

  Vagrant.configure("2") do |config|
    # Vagrant Box
    config.vm.box = "dummy"

+   # Rsync Directory
+   config.vm.synced_folder "setup", "/vagrant", type: "rsync"

+   # Ansible
+   config.vm.provision "ansible_local" do |ansible|
+     ansible.playbook = "provision/docker.yml"
+   end

    # AWS
    config.vm.provider :aws do |aws, override|
        ## 省略...
    end
  end

Dockerの動作確認

$ vagrant up
Bringing machine 'default' up with 'aws' provider...
==> default: Warning! The AWS provider doesn't support any of the Vagrant
==> default: high-level network configurations (`config.vm.network`). They
==> default: will be silently ignored.
==> default: Launching an instance with the following settings...
==> default:  -- Type: t2.micro
==> default:  -- AMI: ami-c68fc7a1
==> default:  -- Region: ap-northeast-1
==> default:  -- Availability Zone: ap-northeast-1c
==> default:  -- Keypair: default
==> default:  -- Subnet ID: subnet-594ac601
==> default:  -- Elastic IP: true
==> default:  -- User Data: yes
==> default:  -- Security Groups: ["sg-8897d1ef"]
==> default:  -- User Data: sed -i -e 's/^(Defaults.*requiretty)/#1/' /etc/sudoers
==> default:  -- Block Device Mapping: []
==> default:  -- Terminate On Shutdown: false
==> default:  -- Monitoring: false
==> default:  -- EBS optimized: false
==> default:  -- Source Destination check:
==> default:  -- Assigning a public IP address in a VPC: true
==> default:  -- VPC tenancy specification: default
==> default: Waiting for instance to become "ready"...
==> default: Waiting for SSH to become available...
==> default: Machine is booted and ready for use!
==> default: Rsyncing folder: /mnt/c/Users/kazuyoshi/aws-training/setup/ => /vagrant
==> default: Running provisioner: ansible_local...
    default: Installing Ansible...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [setup] *******************************************************************
ok: [default]

TASK [apt-get install packages] ************************************************
ok: [default] => (item=[u'curl', u'apt-transport-https', u'ca-certificates'])

TASK [set dockers official gpg key] ********************************************
changed: [default]

TASK [set up the stable repository] ********************************************
changed: [default]

TASK [install docker-ce] *******************************************************
changed: [default]

PLAY RECAP *********************************************************************
default                    : ok=5    changed=3    unreachable=0    failed=0
$ vagrant ssh
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-64-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

10 packages can be updated.
0 updates are security updates.


$ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://cloud.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

$ exit
logout

所感

本格的にAnsibleを使っていこうとするとAnsible Documentationを読み込まないと良いPlaybooksが書けないかも。
ただ、冪等性とかを考えないならcommandやshellでshellscriptで書いてたものを移植すれば良いので簡単に扱える

次は、サービスのDockerをしてからホストサーバのマルチ化かな?
インフラのサービス化として、本格的に検証環境作っていくのはまだまだ先か

参考サイト

続きを読む

AWS でいままで起きた大規模障害を振り返る

目的

 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ東京リージョン(主に使っているリージョン)で同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。

所感

  • 毎年どこかのリージョンで大規模な障害が起きている

    • asia-northeast1 で起きていないのはたまたま、運がいいだけ
    • AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの
    • ステータスダッシュボードは時に嘘をつく
    • クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある
    • Chaos Monkey の思想は必須
  • 報告書読むの面白い
  • us-east は呪われている

AWS 障害一覧

  • 報告書が出ているものを網羅できているかとおもいます

    • SimpleDB の障害だけ除外しました。
  • 最近起きたものから過去に遡っていきます

2017/3/1 us-east-1:バージニア北部の S3 が逝く [new!]

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • S3 がアクセス不可
  • 影響した利用者
    • Imgur、IFTTT、Zapier、Slack、Trello など
  • 障害内容
    • まだ
  • 復旧内容
    • まだ
  • 今後の対応
    • まだ
  • 復旧までの時間
    • 3時間 くらい

2016/6/4 ap-southeast-2:豪雨でシドニーの EC2 が逝く

報告書サマリ

  • 障害リージョン

    • ap-southeast-2:アジアパシフィック (シドニー)
  • 障害サービス
    • EC2、Redshift、RDS 等
  • 影響した利用者
  • 障害内容
    • 豪雨により停電
    • UPS への切替時に異常な電圧低下が起きる
    • EC2 落ちまくる
  • 復旧内容
    • 手動で UPS への電源切替を実施
    • 大部分の EC2 は インスタンス管理ソフトにより自動復旧してきた
    • 一部の EC2 インスタンスはインスタンス管理ソフトのバグにより自動復旧されなかったため、手動で回復する
  • 今後の対応
    • 電源周りの見直し
    • 定期的なリカバリテストの実施
  • 復旧までの時間
    • 1.5 時間

2015/9/20 us-east:新機能追加で DynamoDB が逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • DynamoDB がアクセス不可
  • 影響した利用者
    • Netflix、 Reddit 等
  • 障害内容
    • DynamoDB に グローバルセカンダリインデックス(GSI) の機能追加がされる
    • グローバルセカンダリインデックス の利用者増加により、DynamoDB 内部メタデータが急増
    • 内部メタデータを格納しているストレージサーバの容量割当が小さく、メタデータのパーティショニングが発生
    • メタデータの読込性能が劣化し、DynamoDB のエラー率増加
    • 内部的に DynamoDB を使用している EC2 Auto Scaling、SQS、CloudWatch も連鎖的にエラー率増加
  • 復旧内容
    • メタデータサービスの容量追加
  • 今後の対応
    • メタデータサービスの容量割当変更
    • 顧客のサービス利用規模の監視
  • 復旧までの時間
    • 5 時間

2012/12/24 us-east:オペミスにより ELB が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • ELB
  • 影響した利用者
    • Netflix など
  • 障害内容
    • オペレーションミスにより、ELB 管理アプリケーションから ELB の状態管理データが一部論理削除
    • EBL の新規作成はできるが、既存 ELB の状態変更ができない事態へ
  • 復旧内容
    • ELB 状態管理データの手動復旧
  • 今後の対応
    • 運用データへのアクセスポリシー見直し
    • データ復旧プロセスの変更
  • 復旧までの時間
    • 12 時間

2012/10/22 us-east-1:設定ミスにより EBS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS
  • 影響した利用者
  • 障害内容
    • EBS ストレージ管理サーバの交換作業の一貫で、内部 DNS 設定変更を行ったが設定値にミスがあった
    • ミスった DNS 設定値がなぜか EBS 管理サーバの一部だけに反映される
    • 反映された EBS 管理サーバに、データ収集サーバに接続できないとメモリリークが起きるという潜在バグが発生
    • EBS 管理サーバがメモリ不足によりフェイルオーバーしまくり、フェイルオーバー先が枯渇
    • EBS アクセス不可になる
    • RDS も EBS にアクセスでず、シングル構成のものは死亡、一部 Multi-AZ もバグでフェイルオーバーしなかった
    • ELB も EBS に置いてる構成情報にアクセスできないので自動フェイルオーバーするも、EIP が枯渇して死亡
  • 復旧内容
    • EBS ストレージ管理サーバのメモリ手動解放により、EBS 復旧
    • ELB 手動回復
  • 今後の対応
    • EBS 管理サーバのメモリ監視見直し
    • EBS 管理サーバのフェイルオーバー方法見直し
    • DNS 設定が一部にしか反映できないものを修正
    • RDS フェイルオーバーの不具合修正
    • ELB に追加の EIP を確保
  • 復旧までの時間
    • 14 時間

2012/6/29 us-east-1:嵐により、全体的に逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • EC2、EBS、RDS 等
  • 影響した利用者
    • Netflix、Instagram、Pinterest、Heroku、Flipboard 等
  • 障害内容
    • 落雷のため停電が複数回発生
    • 二度目の発電機への切り替えに失敗、UPS 運用となる
    • 発電機復旧前に UPS 電力枯渇して電源喪失
    • EC2、EBS、RDS など AZ サービスが死亡
  • 復旧内容
    • 発電機復旧
    • EC2 インスタンス管理ソフト はブートプロセスにボトルネックがあり復旧が遅れる
    • EBS は整合性チェックに時間がかかり復旧が遅れる
    • ELB はフェイルオーバー処理を開始するも、不具合にスケールアップし始める
    • 別リージョンでの ELB 処理が溜まりまくって
  • 復旧までの時間
    • 4時間程度

2011/4/21 us-east:設定ミスで EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
    • Heroku 等
  • 障害内容
    • NW 増強のための設定変更実施時に、ルーティング設定のミスが発生
    • ルータがトラフィックを捌ききれず、EBS ノードが NW 分離状態となる
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
  • 復旧内容
    • 障害の起きた EBS ノードを手動切り離し、容量確保
    • データ復旧にとりかかるも、AZ 内データの 0.07% が復旧できなかった
  • 今後の対応
    • ストレージの増強
    • EBS クラスタ制御の改善
    • ヘルスツールの改善
  • 復旧までの時間
    • 4 日

2011/4/14 eu-west:電源喪失で EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • eu-west:欧州
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
  • 障害内容
    • 変圧器の故障により、電力喪失
    • PLC が不具合により発電機に接続できなかった
    • UPS に切り替わるも電力が不足
    • EC2 でエラー率上昇
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
      • 一つ上のと同じ事象です
  • 復旧内容
    • 手動で発電機に接続、その後電源復旧
    • 不整合の起きた EBS ボリュームのデータ復旧
  • 今後の対応
    • 電源復旧時の EBS ボリュームを自動復旧するよう機能追加
    • EBS スナップショットのバグもついでに見つかり、修正する
  • 復旧までの時間
    • 1 日

参考

続きを読む

AWS Batch とは何か

AWS re:Invent 2016 で発表された AWS Batch。
語感から、誤解されるサービス No.1 な気がします。
定時バッチなどとは何がどう違うのかをメモ。

機能概要

以下公式資料とドキュメント、実際さわってみた所感を合わせて。

結局何なのか

科学技術計算・ハイパフォーマンスコンピューティング用途で真価を発揮する、
大規模なスケール、ジョブの依存定義 が可能なマネージド 並列分散 処理基盤。

主な機能、ポイント

  • クラスタ管理、ジョブキュー、ジョブスケジューラを AWS にお任せできる
  • 処理すべきジョブの数に応じ、適切に 自動伸縮1 するクラスタ
  • ジョブに 依存関係 が定義できる(B は A に依存した処理である2、など)
  • 優先度 を持ったキューを複数定義できる
  • 処理能力ごとにクラスタを分割管理することもできる
  • リソース調達が EC2 より直感的、かつ Spot Fleet も統合済み
  • クラスタは ECS 上に構築される
  • サードパーティのデータ分析ワークフローエンジンのサポートあり

これがマネージドされると僕らは何がうれしいのか

  • 本来やりたい、ジョブの実行依頼(submit)と実処理だけを考えればよくなる
  • クラスタ全体で利用可能なリソースの把握、過不足に応じたその調整が不要3
  • 前処理、集約処理、後処理といった流れのある処理も基盤側に制御を移譲できる
  • 依頼者や状況に応じた優先的リソース配分が容易に実現できる
  • CPU / GPU でそれぞれクラスタを作り、前処理 CPU、本処理 GPU なども簡単
  • クラスタごとに可用性、パフォーマンス、コストのバランスが定義しやすい
  • Docker イメージにさえしてしまえばどんな処理も AWS Batch に乗せられる
  • すでにデータ分析パイプラインの定義があれば移行しやすい(かもしれない)

逆に現在4サポートしていないこと

以下 API を駆使してプログラムは書けるものの、標準機能にはありません。

  • cron のように事前指定した時間での起動など、定期タスク管理
  • ジョブの処理そのものや待機状態のタイムアウト
  • 処理が失敗した場合のリトライ
  • リソース不足時、どのリソースがどれだけ足りないかの把握

定時バッチのマネージドサービスではないよという話

再掲:「AWS Black Belt Online Seminar 2017 AWS Batch」10 ページ目
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-batch/10

ストリーミングではなく、(本来の意味の)バッチ的に渡ってくるタスクを
スケーラブルに並列処理させるための仕組みとのことです。

ユースケース

公式

以下からも明らかに主なターゲットはシミュレーションやデータ解析のための処理。
変数を変えながら大量に流す処理細切れにして並列に流せる処理 が向いている。

公式(番外編)

膨大なパラメタを探索したり、予め大量の画像に推論したラベルを貼るといった
昨今話題となっている深層学習分野にも有用、今後利用は広がりそう。

個人的印象

上の深層学習の例では API 消費にレートリミットをかけるという位置付けで
AWS Batch を使っていますが、この使い方はとても汎用的だと思います。
ということで、以下あたりも向いていそう。

  • レートリミットをかけたい処理の実行

例えば同時に流してよい処理がクラスタ全体で一つだけであるとか、
3 つ程度にしたいといった時にクラスタとジョブの定義だけで調整可能。

  • ECS で RunTask していた非同期タスク

科学技術計算といった高度なものではなく、もっとシンプルなタスク。
Web / スマホアプリでも定期的に必要になる小さなジョブなども
予め Docker イメージになっているようであればすぐ使えて便利。

リソースの管理とジョブのスケジューリング

業界によって意味の異なる言葉の整理。

HPC 界隈、コンテナ(Web)界隈、業務システム界隈それぞれで
少しずつ意味が異なるようなので、比較しながら併記します。
(AWS Batch での意味 = HPC 分野での意味)

クラスタ、リソース管理

AWS Batch のいうクラスタは、将来的には HPC 方向に機能強化されるはず・・

  • HPC: 施設・研究者で共有される 巨大なリソース をクラスタとして管理。
    ジョブの要求するハードウェア性能は一般にとてもシビアであり、
    どこでどんな性能のノードが使えるかといった情報の収集も厳密。
  • コンテナ: 複数のサービスでシェアされる特定サーバ群のことで
    一般には可用性やスケーラビリティが重視された構成が取られる。
    どのホストで稼働するかは重要ではなく、むしろどこでも動くよう設計される。
  • 業務: データセンタ内のリソースを管理。あまり包括的には扱われない。
    稼働するアプリケーションは頻繁に変わるものではなく
    とにかく安定的・効率的にサービスが稼働することが大切。

スケジューラ

  • HPC: 実行したいジョブはキューに投げる。リソースが空いたら次の処理が始まる。
    ジョブ同士の依存関係が強い。順序や処理間のデータ移動も重要。
    優先的に処理したいジョブは割り込める必要がある。
    多くは試行錯誤のためのジョブ、FAIL してもいいが処理時間はとにかく長い。
  • コンテナ: 各サービスの要求するリソースを見つけ次第どこかに投入される。
    サービスの理想状態を別途管理する必要があり、異常終了時などの再起動や
    すでに起動しているサービスの状態を考慮した配置も必要になる。
  • 業務: 業務やその時間、ワークフローに応じてジョブを起動・停止する。
    ジョブ同士の依存関係も強く、処理に失敗した場合のワークフローは最も複雑。
    ユーザごとにそのあたりを設定変更できる柔軟さが必要。

AWS Batch の概念・機能

コンピューティング環境

AWS Batch には「コンピューティング環境」という概念がありますが
いわゆる「クラスタ」のようなもので、複数インスタンスの集合です。

そしてそれは、用途に応じて 2 種類あります。

Managed 環境

Unmanaged でなければいけない理由がなければ Managed 環境がオススメ。
Managed 環境の特徴は以下の通り。

  • 待機ジョブの深さに応じてクラスタがオートスケールアウト / イン
  • ECS クラスタを裏で作成・管理してくれる
  • Spot Fleet が簡単に使えて便利

Unmanaged 環境

ちょっと変わったクラスタにカスタマイズする必要がある場合はこちら。
AWS Batch の生成する ECS クラスタに「関連づけるインスタンス」を
自由にカスタマイズ可能。例えばこんなとき。

  • 特定の AMI を使いたい
  • あれこれ調整した AutoScaling グループを使いたい
  • EFS を使いたい
  • GPU を使いたい

Unmanaged 環境の場合はキューの深さによるオートスケールが働かないため
このようなアーキテクチャ で別途用意する必要があります。

ジョブ定義・実行

ジョブの定義は JSON で事前に宣言 することになります。
ジョブの処理ロジックについては、さらにそれ以前に Docker イメージにして
DockerHub や ECR などに push しておく必要があります。

実行時パラメタ

ジョブの基本的な起動パラメタは事前に JSON に定義するものの、
実行時に挙動を変える手段が AWS Batch には 2 つのあります

  • Ref:XXX & –parameters : 事前に XXX と定義したパラメタを実行時に指定
  • 環境変数 : コンテナへ渡す環境変数を実行時に指定

依存関係のあるジョブ

ジョブ投入時に --depends-on オプションで、すでに投入済みの
依存するジョブの ID を渡すことで依存関係を定義できます。

ジョブ間のデータ連携

HPC 系バッチコンピューティングを支援するマネージドサービスということで
そのデータの連携には以下サービス群の利用が想定されているようです。

  • EFS: まだ東京リージョンに来てないけども・・
  • EBS: 前処理したタイミングでスナップショットを取り展開、など
  • S3: AWS といえば S3 の活用ですが、もちろん大活躍
  • RDS / DynamoDB: 使いどころはたくさんありそう

他サービスとの連携

AWS を使い倒せば、よりセキュアで安定したサービスにも

  • CloudWatch Logs: ジョブの標準出力は全てここに連携されます
  • IAM: ECS ベースなこともあり、ジョブごとの権限管理にはロールが使える
  • KMS: 秘密情報の管理には KMS + IAM ロールがほんとに便利
  • Lambda + CloudWatch Events: Unmanaged 環境の自前オートスケールなど

他サービスとの使い分け

Lambda や EMR、ECS とどう使い分けるの?という。Batch を選択する意味。

なぜ Batch がでたのか

Azure には AWS より以前に、同名の Azure Batch というサービスがありましたが
こちらも狙いは、汎用的な 科学技術計算や HPC 基盤のマネージド提供でした。

AWS にも EMR や MachineLearning といったある種の問題解決に特化した
マネージドサービスはありましたが、汎用的なバッチ環境としては
AWS Batch が最も適切なサービスとなりそうです。

使い分け

上記のメリットに合致したジョブなら AWS Batch。
悩ましいとしたら、例えば

  • Lambda では難しい(運用・開発効率、サーバ性能、タイムアウト、言語)
  • EMR 向けに作りこまれたものではない(既存の処理を使いたい)

のならば AWS Batch を使う、など。

使ってみよう

実際にジョブを流してみると感覚がつかめると思います。

ハンズオン


  1. Managed 環境だった場合の挙動 

  2. A が正常終了(SUCCEEDED)すると B が開始され、A が異常終了(FAILED)した場合は B も FAILED になる 

  3. 厳密には待機ジョブの数で調整がかかるので、CPU やメモリなどに応じたリソースの調達・解放がしたい場合は API を利用したプログラムが別途必要 

  4. 2017/03/01 時点 

続きを読む

AWSバッドノウハウ集 2017/02

おことわり

  • 主観であり何らかのデータにもとづいてはいない
  • この記事に書いてあることは信じずに自分で試そう

EC2 t2 ファミリーは他ファミリーと比べて不安定

どのインスタンスもいつかは死ぬという点では共通なのですがそのなかでもt2は故障したり不具合が発生したりする確率が非常に高い気がする

なので死んだり、死にかけ状態で動き続けたりしてほしくないインスタンスはあんまりリソースを使わなくても t2.micro とかじゃなくて m3.medium にしとくとすこし可用性があがる

追記: CPUクレジット理解していないだけではとか書かれていたんですがその辺は確認している。
t2の可用性が問題になったケースいくつかあるんだけど、自分の場合はネットワークがたまに断する問題が多くて、分散DBクラスタの死活監視で1secごとにpingするだけでCPUは常に1%以下みたいなものとかに使うとカジュアルに10sec以上ネットワーク断してくれることが多くて困ったりとか。

t2.medium以上のサイズはm3ファミリーを選択してしまうので使ったことないので、いいのかもしれないですね

インスタンスをまとめて起動すると同じホストに配置されがちで同時に死ぬ

なのでホストが故障するとインスタンスもまとめて死にます。サポートにきくと「複数のAZに分散して配置していただくことで、、、」と案内されますが、3台のDBを2AZにそれぞれ1台と2台配置して、2台が同時に故障したりすると目も当てられないのは明白です。

「もしくはDedicated Hostsを…」とか案内されたりもするので、我々の取れる対策としては

  • なるべくAZをわける
  • Tokyoを捨てて3AZ以上使えるRegionに引っ越す
  • クラスタにインスタンスファミリーが別のものを加える
  • なるべく時間を空けてインスタンスを起動する
  • Dedicated Hostsを2台以上かりてそれぞれに配置する(すごく高い)

あたりでしょうか。Tokyoで使えるAZふやしてくれー

EBSはガチャ

(少なくともGP2とPIOPSについては)相当な頻度で故障して、裏側で再構築が走ったり、ギリギリ故障判定のしきい値に達せずに低性能のまま放置されていたりする。サポートに問い合わせると故障していたと教えてもらえることもあるが、問い合わせることでそのEBSが直るということはないので破棄して再構築したほうが早い

最近だとインスタンスストレージ付きのi3がr3と同じくらいの値段で使えるのでそういうのを使ってEBSにDBを置く頻度を減らすとEBSの障害も回避できるかも

RDSはそうなったときの対処がfailoverしかない上にMulti-AZでEBSの故障率も2倍なので本当に酷いことになりがち、AuroraはEBSはそこそこ故障したり調子が悪くなるという教訓を元に設計されつくられているのでできればAurora使ったほうがいいのではないでしょうか

VPCについているDNSサーバーは以外と貧弱

以外と貧弱なのでDBなどをドメイン名で指定していたりと、頻繁に名前解決しまくるようなサービスだとDNSが死ぬ。各インスタンスでDnsmasq起動してキャッシュして負荷低減に勤しんだり、自前でDNSキャッシュサーバー建ててVPC付属のやつを使わないようにしよう

99%の障害はコンソールには何も表示されていない

https://status.aws.amazon.com/
こことか Management Console とか見ても何も書いていないことがほとんど

サポートに問い合わせると50%くらいの障害は「そういった事象が発生していました」と教えてもらえるのですが「すでに直った」か「再構築をお願いします」と言われることが多い。なんかおかしいなーという箇所は全部再構築すると大抵直るのでおすすめです

続きを読む