Amazon Web Services ブログ

CloudFormation スタックセットを利用した 複数のAWSアカウントやリージョンを横断したリソース展開

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。

本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。

アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU(詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください)へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。

リージョン ― 巨大な(かつ今なお成長し続ける)AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3AuroraPostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。

複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。

スタックセットのご紹介

これらの重要なご要望を解決するために、本日 CloudFormation スタックセットをリリースしました。CloudFormation テンプレート内に AWS リソースの設定を定義すると、それから数回のクリックで複数の AWS アカウント及び/あるいはリージョンにそれらを水平展開できるようになりました。上述したクロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップに、この機能を活用できます。一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。

この機能は、常にクロスアカウントベースで動作します。管理者のアカウントによって、1つ以上のスタックセットが保持されるとともに1つ以上の対象アカウントへのデプロイが制御されます。この管理者アカウントは引き受け可能な IAM ロールを保持しなければいけません。また、対象アカウントは管理者アカウントに対して信頼を付与しなければいけません。どのようにこの作業を行うかについては、スタックセットのドキュメント必要な条件をお読みください。

各スタックセットは、CloudFormation テンプレートを参照しアカウントとリージョンのリストを持ちます。全てのオペレーションは、スタックセット内の アカウント × リージョン の組み合わせそれぞれに対して適用されます。もしスタックセットが3つのアカウント(A1, A2, そしてA3)と4つのリージョン(R1, R2, R3, そしてR4)を参照する場合:

  • リージョンR1: アカウントA1, A2, そしてA3.
  • リージョンR2: アカウントA1, A2, そしてA3.
  • リージョンR3: アカウントA1, A2, そしてA3.
  • リージョンR4: アカウントA1, A2, そしてA3.

テンプレートをデプロイすると、まずアカウント/リージョンの組み合わせの1つに対して CloudFormation スタックの作成が開始されます。テンプレートは、各リージョン(順序を制御)と各リージョン内の複数のアカウント(並列度を制御)に順にデプロイされます。スタックの作成が失敗した場合にデプロイを終了するエラー閾値を設定することも可能です。

既存の CloudFormation テンプレートを使用することも可能ですが(アカウントとリージョンをまたいで動作する準備が整っていることを確認するよう注意してください)、新しいテンプレートを作成しても良いですし、あるいは AWS が予め用意するサンプルのテンプレートを使用することもできます。現在、一部のリージョン(中国を除く全てのパブリックリージョン)をサポートしていますが、そう長い時間をかけずにその他のリージョンにも展開できると予想しています。

スタックセットの使用

CloudFormation のコンソールからCloudFormation API を介して、あるいはコマンドラインからスタックセットを作成しデプロイすることが可能です。

コンソールなら、Create StackSet をクリックして開始します。自分自身のテンプレートを使うこともできますし、用意されたサンプルのテンプレートを使うこともできます。一連のサンプルの一番最後にある Add config rule encrypted volumes を使用してみます:

View template をクリックしこのテンプレートとテンプレートに記述されているルールの詳細を確認します:

このスタックセットに名前を付けます。今回選択したテンプレートはオプションのパラメータを受け取りますが、この値はこのタイミングで入力することができます:

次に、アカウントとリージョンを選択します。アカウント番号を直接入力するか、AWS 組織単位(OU)を参照するか、あるいはアカウント番号のリストをアップロードすることができます:

リージョンを設定しデプロイの順序を制御することができます:

デプロイメントのオプションを設定することも可能です。設定が完了したら Next をクリックして次に進みます:

スタックセットにタグを設定することができます。設定したタグは、このスタックセットのデプロイによって作成される AWS リソースに適用されます。

デプロイが始まり、コンソール上でデプロイのステータスを追跡することができます:

スタックのセクションを開いて各スタックを確認することが可能です。最初は各スタックのステータスは OUTDATED となっており、テンプレートがまだスタックにデプロイされていないことを示しています。問題なくデプロイが完了すると、ステータスは CURRENT に変わるでしょう。スタックがうまく削除できない場合には、ステータスは INOPERABLE に変わります。

この最初のデプロイが終わった後は、 Manage StackSet をクリックし、アカウントかリージョンあるいはその両方を追加したり、更にスタックを作成したりすることが可能です。

現在利用可能

この新機能は、現在利用可能であり追加料金なしに使い始めることができます(作成されたAWSリソースに対してのみ料金をお支払い頂きます)。

Jeff;

追伸 ― もし、役に立つテンプレートが出来上がって他のAWSユーザにも共有したいと思ったら、私達の AWS Labs GitHub リポジトリにプルリクエストを送ってください。

原文:Use CloudFormation StackSets to Provision Resources Across Multiple AWS Accounts and Regions(翻訳:SA畑史彦)

 

Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして

2017年7月19日前後より、Amazon Web Services(AWS)の一部のお客様に対し、“Securing Amazon S3 Buckets” という件名のメールをご送付させていただきました。Amazon S3 のバケットポリシーアクセスコントロールリスト(ACL)の設定の不備によって、Amazon S3 上の重要なデータが漏洩するセキュリティリスクに対する注意喚起となります。Amazon S3 のバケットポリシーや ACLの設定について、この注意喚起メールを必要な設定の見直しのきっかけにしていただければと思います。なお、メールを受け取られたお客様に、必ずしも問題があることを示すものではありません。

 

メールが送られた契機について

 

重要なデータが漏洩した事例のいくつかを調査した結果、バケット ACL を “All Users” や “All Authenticated AWS Users” に設定されているお客様はセキュリティリスクが高いと判断しています。該当するお客様は、設定の見直しを推奨すべくメールをお送り致しましたので、アクセスが広く許可されていることが本当に正しい状態か、今一度ご確認ください。

(more…)

HBase on Amazon S3を使用してリードレプリカクラスタをセットアップする

多くのお客様は、低コスト、データ耐久性、スケーラビリティなど、Amazon S3をデータストレージとしてApache HBaseを実行することの利点を活用しています。 FINRAのような顧客は、HBase on S3アーキテクチャーに移行し、ストレージをコンピュートから切り離し、S3をストレージレイヤーとして使用するという多くの運用上の利点とともに、コストを60%削減しました。 HBase on S3を使用すると、クラスタを起動して、長いスナップショット復元プロセスを経る必要がなく、S3内のデータに対してすぐにクエリを開始することができます。

Amazon EMR 5.7.0の発表により、HBase on S3の高可用性と耐久性をクラスタレベルにさらに一歩進化させることができます。S3上の同じHBaseルートディレクトリに接続できる複数のHBase読み取り専用クラスタを開始できます。これにより、リードレプリカクラスタを介して常にデータにアクセスできることを保証し、複数のアベイラビリティゾーンにわたってクラスタを実行できます。

この記事では、HBase on S3を使用したリードレプリカクラスタの設定をご案内します。

(more…)

新機能 – EC2 Auto Scalingのターゲットトラッキングポリシー

先日DynamoDBのAuto Scalingについてお伝えし、そこでDynamoDBテーブルのキャパシティ管理を自動化するためにどのように複数のCloudWatchアラームを利用しているかをお見せしました。その裏では、これからいくつかの異なるAWSサービスに渡って利用が予定されている、もっと一般化されたApplication Auto Scalingのモデルを使うことでこの機能を実現しています。

新しいAuto Scalingのモデルはターゲットトラッキングと呼ばれる重要な新しい機能を含んでいます。ターゲットトラッキングを使ってAuto Scalingのポリシーを作成する時には、特定のCloudWatchメトリクスに対してターゲットとなる値を選択します。Auto Scalingはそのメトリクスがターゲットに向かう様に適切な(スピーカーで言う)つまみを回し、合わせて関連するCloudWatchアラームも調整します。どういったメトリクスであれアプリケーションにとって意味のあるもので必要なターゲットを指定するという方法は、元々あるステップスケーリングポリシーの様に手動でメトリクスのレンジと閾値を設定するよりも、一般的にはより簡単で直接的なやりかたです。しかし、より高度なスケーリング戦略を実装するために、ターゲットトラッキングとステップスケーリングを組み合わせることも可能です。例えば、スケールアウトにはターゲットトラッキングを使い、スケールインにはステップスケーリングを使う等が考えられます。

EC2に新しい機能

本日、EC2 Auto Scalingにターゲットトラッキングのサポートを追加しました。Application Load Balancerのリクエスト数、CPU負荷、ネットワークトラフィック、またはカスタムメトリクスによるスケーリングポリシーを作成することができます(ターゲット毎のリクエスト数というメトリクスは新しいもので本日のリリースの一部になります)。

これらメトリクスは重要な特徴が共通しています: EC2インスタンスを追加することで(全体の負荷が変化していない時に)、メトリクスを下げることになります。もしくはその逆もです。

ターゲットトラッキングを使ったAuto Scaling Groupを作るのは簡単で、ポリシーの名前を入力し、メトリクスを選択し、希望するターゲットの値を設定するだけです:

スケールイン側のポリシーを無効にすることもできます。その場合、手動でスケールインしたり、別のポリシーを使うことができます。

ターゲットトラッキングポリシーは、AWS Management ConsoleAWS Command Line Interface (CLI)、またはAWS SDKでも作成することができます。

以下は、ターゲットトラッキングを使おうとする時に頭にいれておくべき項目になります:

  • 1つのAuto Scaling Groupに対して、異なるメトリクスを参照している複数のターゲットを設定することができます。スケーリングは常に一番高いキャパシティを求めるポリシーに従います。
  • メトリクスのデータが不十分な時はスケーリングは発動しません。
  • Auto Scalingはメトリクスの急速で一時的な変動を補い、関連するキャパシティの急激な変動を最小化しようと努力します。
  • カスタムメトリクスでのターゲットトラッキングはAuto Scaling APIAWS Command Line Interface (CLI)で設定することができます。
  • 多くのケースで、1分間隔で入ってくるメトリクス(詳細モニタリングとも言われます)に応じてスケールするように選択すべきです。5分間隔のメトリクスをスケーリングの基本にすると、反応時間が遅くなってしまいます。

本日から利用可能です

この新しい機能は本日から利用可能で、追加料金無しに使い始められます。より詳しくは、Auto Scalingユーザガイドターゲットトラッキングスケーリングをご覧ください。

Jeff;

原文: New – Target Tracking Policies for EC2 Auto Scaling (翻訳: SA岩永)

AWS のディープラーニング

私のようなタイプの人であれば、人工知能 (AI) や機械学習 (ML)、ディープラーニングは実に興味深く胸を躍らせるトピックではないかと思います。AI、ML、ディープラーニングが今まで以上に幅広く利用されるようになるに連れ、Dr. Issac Asimov 氏がサイエンスフィクションで描いた「スター・ウォーズ」に出てくるようなロボット工学そして医学の進歩、さらには「スタートレック」のキャプテンカークやそのクルーに「誰も行ったことのない場所へ、勇敢に突き進もう (to boldly go where no man has gone before)」と言わせたテクノロジーが実際に可能になるのではないかと思わずにいられません。

 

前述のトピックに興味がある人にとって、画像や動画を複数のカテゴリに区別する畳み込みニューラルネットワーク (Convolutional Neural Networks) や、音声認識、自然言語によるインターフェース、推奨エンジンなど、ディープラーニングにより可能となる AI や ML のソリューションには馴染みが深いのではないかと思います。けれども、データサイエンティスト、機械学習の利用者、リサーチサイエンティスト、ディープラーニングに興味を持つ熱心なユーザー達がこうしたテクノロジーに携わりインフラストラクチャや環境、ツールを設定する作業は必ずしも簡単ではありません。多くの開発者はディープラーニング技術を使用して、ディープラーニングをトレーニングモデルそしてソリューション開発に早く繋げていきたいと考えています。こうした理由から、経験豊富なデータサイエンティストであれ、今から始めたいと思っている興味津々の開発者まで、速くディープラーニングのソリューションを構築したいと思っている方々に向けて、いくつかのリソースをご提供したいと思います。

ディープラーニングのリソース
Apache MXNet は Amazon が選んだディープラーニングのフレームワークです。Apache MXNet フレームワークと NVIDIA GPU コンピューティングを組み合わせれば、スケーラブルなディープラーニングプロジェクトとソリューションを簡単に AWS クラウドで開始できます。MxNet のディープラーニングの旅を始める方々を対象に、様々なセルフサービス形式のチュートリアルやデータセットが今すぐ利用できるようになっています。

  • AWS ディープラーニング AMI の起動: このガイドでは、Ubuntu で AWS ディープラーニング AMI を起動する手順を説明しています。
  • MXNet – コンピュータビジョンのアプリケーションを作成: この実践的なチュートリアルは構築済みのノートブックを使用してニューラルネットワークの利用でコンピュータビジョンを構築し、手書きの数字を識別する方法を説明します。
  • AWS 機械学習のデータセット: AWS は AWS Marketplace で機械学習のデータセットを無料で提供しています。こうした大規模なデータセットはダウンロードまたは保存の必要がなく、データを分析したい誰もが使用できます。
  • 予測と抽出 – 予測に事前トレーニング済みのモデルを使用する方法: この実践的チュートリアルは Imagenet のフルデータセットを使用して、予測と機能抽出に事前トレーニング済みのモデルを利用する方法を説明します。

 

AWS ディープラーニング AMI
AWS はディープラーニングを始める上で必要なインフラストラクチャを素早くデプロイメントするため、Amazon EC2 で Amazon マシンイメージ (AMI) を提供しています。AWS ディープラーニング AMI には、AI を対象としたソリューションやモデルで起動できる Amazon Linux や Ubuntu で Amazon EC2 インスタンスを使用して構築された人気のディープラーニングフレームワークが事前設定されています。ディープラーニング AMI でサポートされ事前設定されているディープラーニングフレームワーク:

  • Apache MXNet
  • TensorFlow
  • Microsoft Cognitive Toolkit (CNTK)
  • Caffe
  • Caffe2
  • Theano
  • Torch
  • Keras

また、AWS ディープラーニング AMI のインストール事前設定ライブラリで Jupyter notebooks の Python 2.7/3.4、AWS SDK for Python、その他のデータサイエンス関連の python パッケージや依存関係を対象にしたものも含まれます。AMI には、NVIDIA CUDA と NVIDIA CUDA Deep Neural Network (cuDNN) ライブラリやサポートされているディープラーニングフレームワークすべても事前にインストールされています。Apache MXNet フレームワークには Intel Math Kernel ライブラリがインストールされています。いずれのディープラーニング AMI を開始するには「ディープラーニング AMI のリンク (Try the Deep Learning AMIs link)」を使用して AWS Marketplace にアクセスしてください。概要 ディープラーニングを始めるには今が絶好のタイミングです。AWS クラウドで実行する AWS ディープラーニングを使用することでディープラーニングの作業を早めることができます。そうすることで素早くディープラーニング環境をスタートさせたり「AWS セルフサービス形式のリソース (AWS self-service resources)」を使用して MXNet を使用する AWS でディープラーニングを学び始めることができます。もちろん、AWS でディープラーニング機械学習人工知能に関するより詳しい情報を学ぶこともできます。「AWS ディープラーニングのページ ( AWS Deep Learning page)」、「Amazon AI の製品ページ (Amazon AI product page)」、「AWS AI ブログ (AWS AI Blog)」をご覧ください。
goディープラーニングフォースの力が共にありますように (May the Deep Learning Force be with you all)。

Tara

コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか?については多様なやり方が考えられますが、今日はAWS CloudFormationを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にAmazon ECSAWS LambdaといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはAWS Command Line Interface (CLI)やSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。

デプロイツールとしてのCloudFormationのメリット

最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。

  • デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能
  • 宣言的にデプロイが定義・実行できる
  • アプリケーションに関連する他のAWSリソースも合わせて管理可能

現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。

デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能

例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。

CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。

もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。

宣言的にデプロイが定義・実行できる

AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。

CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。

アプリケーションに関連する他のAWSリソースも合わせて管理可能

ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、AWS Identity and Access Management (IAM)のRoleは良く使われますし、データベースとしてAmazon DynamoDBを使ったり、ECSのコンテナへの負荷分散にElastic Load Balancingを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。

CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。

CloudFormationを使ったECSのデプロイ例

こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。

ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、AWS CodePipelineがデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。

参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。

https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml

Resources:
  ECSServiceRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument: |
        {
            "Statement": [{
                "Effect": "Allow",
                "Principal": { "Service": [ "ecs.amazonaws.com" ]},
                "Action": [ "sts:AssumeRole" ]
            }]
        }
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole

  Service:
    Type: AWS::ECS::Service
    Properties:
      Cluster: !Ref Cluster
      Role: !Ref ECSServiceRole
      DesiredCount: !Ref DesiredCount
      TaskDefinition: !Ref TaskDefinition
      LoadBalancers:
        - ContainerName: simple-app
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Sub ${AWS::StackName}-simple-app
      ContainerDefinitions:
        - Name: simple-app
          Image: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${Repository}:${Tag}
          EntryPoint:
            - /usr/sbin/apache2
            - -D
            - FOREGROUND
          Essential: true
          Memory: 128
          MountPoints:
            - SourceVolume: my-vol
              ContainerPath: /var/www/my-vol
          PortMappings:
            - ContainerPort: 80
          Environment:
            - Name: Tag
              Value: !Ref Tag
        - Name: busybox
          Image: busybox
          EntryPoint:
            - sh
            - -c
          Essential: false
          Memory: 128
          VolumesFrom:
            - SourceContainer: simple-app
          Command:
            - /bin/sh -c "while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"
      Volumes:
        - Name: my-vol

CloudFormationを使ったLambdaのデプロイ例

Lambdaの構成管理およびデプロイには、AWS Serverless Application Model (SAM)を使うことができます。これはCloudFormationの拡張表記であり、例えば以下のようなテンプレートを書くと簡単にAmazon API GatewayとLambda Functionをデプロイ(初回は構築含む)をすることができます。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Outputs the time
Resources:
  TimeFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs6.10
      CodeUri: ./
      Events:
        MyTimeApi:
          Type: Api
          Properties:
            Path: /TimeResource
            Method: GET

Lambdaのデプロイを行う際、多くのケースでは依存ライブラリ等もまとめたzipファイルを作成し、Amazon Simple Storage Service (S3)にアップロードした上でFunctionを更新することになります。AWS SAMを使っているとこれをAWS CLIを使って簡単に実現できます。実装例は以下のドキュメントに詳しく紹介されています。

まとめ

この投稿では、AWS CloudFormationをコンテナやサーバレスアプリケーションをデプロイするためのツールとしてご紹介しました。多くの実際のユースケースで利用可能なものですのでご参考にして頂ければ幸いです。サーバレスアプリのデリバリパイプラインまで含めた実装を実際にご覧になりたい場合には、AWS CodeStarで作成されるプロジェクトも参考になるかと思いますので合わせてご参考頂ければと思います。

8 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信についてご案内させて頂きます。8月は開発者の方々に役立つ内容を多めに放送する予定です。ソリューションカットでは、デプロイをテーマにしたものと,Redshift のテーブル設計についてのものをお送りします。また今年に入って大きなアップデートがあった DynamoDB についてもお送りします。

 

8月の開催予定

 

サービスカット

8/2(水) 18:00-19:00 AWS X-ray
8/9(水) 18:00-19:00 Amazon DynamoDB
8/23(水) 18:00-19:00 AWS MobileHub
8/30(水) 18:00-19:00 AWS Key Management Service (KMS)

ソリューションカット

8/22(火) 12:00-13:00 Deployment on AWS
8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

新機能 – Amazon CloudWatch ダッシュボードでの API と CloudFormation のサポート

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。

新しい API および CLI
コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、AWS CloudFormation のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。

ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。

GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。

PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。

DeleteDashboards / aws cloudwatch delete-dashboards – 1 つ以上のダッシュボードを削除します。

ダッシュボードの概念
これらの関数とコマンドの使用方法を説明したいと思います。詳細な説明に移る前に、ダッシュボードの重要な概念と属性のいくつかを示します。

グローバル – ダッシュボードは AWS アカウントの一部であり、特定の AWS リージョンとは関連付けられていません。各アカウントは最大 500 個のダッシュボードを持つことができます。名前が付けられる – 各ダッシュボードには、AWS アカウント内で一意の名前があります。名前の長さは最大 255 文字です。グリッドモデル – 各ダッシュボードはセルのグリッドで構成されます。グリッドは全体で 24 個のセルで、必要なだけ高くすることができます。ダッシュボードの各ウィジェットはグリッド座標の特定のセットに配置され、整数値の数のグリッドセルにまたがるサイズです。ウィジェット (視覚化) – 各ウィジェットは、テキストまたは CloudWatch メトリクスのセットを表示できます。テキストは Markdown を使って指定し、1 つの値、折れ線グラフ、または積み上げ棒グラフとして表示できます。各ダッシュボードは最大 100 個のウィジェットを持つことができます。メトリクスを表示するウィジェットは、CloudWatch アラームと関連付けることもできます。ダッシュボードには、コンソール内から表示および編集できる JSON 表現があります。[Actions] メニューをクリックして、[View/edit source] を選択します。

ダッシュボードのソースは以下のとおりです。

この JSON は、実際のアプリケーションを構築する際の参考にしてください。ご覧のとおり、ダッシュボードの各ウィジェットに対して widgets 配列にエントリがあります。各エントリは、タイプ、位置、サイズで始まる 1 つのウィジェットを示します。

API を使用したダッシュボードの作成
特定のリージョンの各 EC2 インスタンスに対するウィジェットがあるダッシュボードを作成するとします。Python および AWS SDK for Python を使用して、次のように開始します (私のコードの未熟さはご容赦ください)。

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

次にインスタンスを反復処理し、それぞれに対して widget ディクショナリを作成し、それを widgets 配列に追加します。

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

位置 (xy) をループ内で更新し、グリッドを作成します (位置を指定しない場合、ウィジェットは左から右へ、上から下へレイアウトされます)。

        x += width
        if (x + width > max_width):
            x = 0
            y += height

すべてのインスタンスを処理した後で、ウィジェット配列の JSON バージョンを作成します。

body   = {'widgets' : widgets}
body_j = json.dumps(body)

そして、ダッシュボードを作成または更新します。

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

コードを実行すると、次のダッシュボードが作成されます。

CloudWatch チームは、プログラムで作成されるダッシュボードにはテキストウィジェットを含め、ダッシュボードが自動生成されたことと、その操作を実行したソースコードまたは CloudFormation テンプレートへのリンクを含めることを推奨しています。つまり、ダッシュボードに対して手動の帯域外チェンジャーを実行しないことを推奨しています。前述したように、各メトリクスウィジェットは CloudWatch アラームと関連付けることもできます。アラームは、プログラムで作成するか、サンプル CPU 使用率アラーム などの CloudFormation テンプレートを使用して作成できます。これを行うように決定した場合、アラームのしきい値がウィジェットに表示されます。この詳細については、Tara Walker の最近の投稿「Amazon CloudWatch Launches Alarms on Dashboards」を参照してください。さらに一歩先に進んで、CloudWatch イベントと Lambda 関数を使って特定のリソースの作成と削除を追跡し、変更に合わせてダッシュボードを更新することができます。この方法については、「Keeping CloudWatch Dashboards up to Date Using AWS Lambda」を参照してください。

CLI を使用したダッシュボードへのアクセス
コマンドラインからダッシュボードにアクセスして操作することもできます。たとえば、シンプルなリストを生成できます。

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

そして、Disk-Metrics ダッシュボードを削除できます。

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

ダッシュボードを定義する JSON を取得することもできます。

 

CloudFormation を使用したダッシュボードの作成
ダッシュボードは、CloudFormation テンプレートで指定することもできます。YAML 形式のシンプルなテンプレートを示します ( DashboardBody が依然として JSON で指定されています)。

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

テンプレートをファイルに配置し、コンソールまたは CLI を使用してスタックを作成します。

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

ダッシュボードを次に示します。

ご利用可能
この機能は今すぐ利用できます。本日から使い始めることもできます。ダッシュボードあたり最大 50 メトリクスを持つ 3 つのダッシュボードを無料で作成できます。追加のダッシュボードの料金は、CloudWatch 料金表ページに示すように、1 か月あたり 3 USD です。毎月新しい API 関数に対して最大 100 万回の呼び出しを無料で実行できます。それを超えた場合の料金は、1,000 回の呼び出しごとに 0.01 USD です。

Jeff;

AWS 料金値下げ – EC2 の SQL Server Standard Edition

AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。

AdobePitney Bowesデブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% 値下げします。エンタープライズ規模のアプリケーション、大規模にスケーラブルなウェブサイト、モバイルアプリケーションを、以前よりはるかにコスト効果の高い方法で構築および実行できます。リージョンおよびインスタンスタイプごとの最大の値下げ率を次に示します。

リージョン R4 M4 I3 X1
US East (Northern Virginia) -51% -29% -50% -52%
US East (Ohio) -51% -29% -50% -52%
US West (Oregon) -51% -29% -50% -52%
US West (Northern California) -51% -30% -50%
Canada (Central) -51% -51% -50% -44%
South America (Brazil) -49% -30% -48%
Europe (Ireland) -51% -29% -50% -51%
Europe (Frankfurt) -51% -29% -50% -50%
Europe (London) -51% -51% -50% -44%
Asia Pacific (Singapore) -51% -31% -50% -50%
Asia Pacific (Sydney) -51% -30% -50% -50%
Asia Pacific (Tokyo) -51% -29% -50% -50%
Asia Pacific (Seoul) -51% -31% -50% -50%
Asia Pacific (Mumbai) -51% -33% -50% -50%

オンデマンドインスタンスの値下げされた新料金は、2017 年 7 月 1 日に有効になります。リザーブドインスタンスの新料金は本日有効になります。

Jeff;

EC2 Container ServiceのBlue/Greenデプロイメント

この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。

Jeremy Cowan
Solutions Architect
Anuj Sharma
DevOps Cloud Architect
Peter Dalbhanjan
Solutions Architect

コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。

リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすことなく、本番環境でテストをおこないたいと考えているお客様が増えています。人によっては、新機能が多くの人たちに公開される前に少数の顧客に対してのみ公開し、フィードバックを集めることもあるでしょう。これは、カナリア分析またはカナリアテストと呼ばれる手法です。この記事では、Application Load Balancerstarget groupsを使用してBlue/Greenとカナリアデプロイを実装するパターンを紹介します。

もし実際にこのアプローチを試したい場合、オープンソースのコードとAWS CloudFormationテンプレートをecs-blue-green-deployment GitHubリポジトリに公開しています。
このワークフローでは、サービスをECSクラスタにデプロイする自動化されたCI / CDパイプラインが構築され、コードの最新バージョンを本番環境に昇格する準備が整ったらターゲットグループをスワップする制御されたプロセスが提供されます。環境は3つのステップで簡単に設定でき、Blue/Greenのスワップが動作することを確認できます。ぜひ試してみてフィードバックを送ってください!

 

Blue/Greenの利点

Blue/Greenデプロイメントは、ソフトウェア更新を低リスクでおこなうことができるイミュータブルデプロイメントの1つのパターンです。現在の実行中の “Blue”バージョンのアプリケーションと新しい “Green”バージョンのアプリケーションを別々の環境で作成することで、リスクが軽減されます。

このデプロイメント方法では、アプリケーションの現在の実行中のバージョンに影響を与えずに、Greenの環境で機能をテストすることができます。Greenバージョンが正常に動作していることが確認できたら、DNSを変更して古いBlue環境から新しい環境にトラフィックを徐々にルーティングすることができます。この方法に従うことで、ほぼゼロダウンタイムで機能更新とロールバックをおこなうことができます。

2つの異なる環境感でトラフィックをシフトする典型的なBlue/Greenデプロイメント

このように運用中のBlue環境に素早くトラフィックを戻すことできることは、Blue/Greenデプロイメントの主要メリットの1つです。Blue/Greenデプロイメントでは、デプロイメントプロセスのどのタイミングでもBlue環境にロールバックすることが可能です。ダウンタイムはGreen環境に問題があることを認識してから、Blue環境にトラフィックを切り戻すまでの時間に制限されます。さらに、停止の影響はすべてのトラフィックではなく、Green環境に振り分けられたトラフィックに限定されます。デプロイエラーの規模が縮小されると、全体的なデプロイのリスクも低下します。

コンテナでBlue/Greenをシンプルに実現する

複数環境の管理およびプロビジョニングの複雑さとコストのために、従来のオンプレミスでのソフトウェア更新にはBlue/Greenデプロイメントはあまり導入されていませんでした。代わりに、アプリケーションはin-placeでアップグレードされていました。

このアプローチは有効でしたが、障害時のロールバックの迅速性などいくつかの欠陥がありました。ロールバックには通常、以前のバージョンのアプリケーションの再デプロイメントをおこなっていましたが、再デプロイメントは良くないリリースがあった場合の停止時間を長期化させる可能性があります。

コンテナは、簡単にパッケージ化でき、環境間を移動しても一貫して動作するため、Blue/Greenデプロイメントの導入を容易にします。この一貫性のひとつの要因は、コンテナのもつ不変性です。コンテナの設定を変更するには、In-Placeでソフトウェアを更新するのではなく、Dockerfileを更新してコンテナを再構築、再デプロイする必要があります。

コンテナは、アプリケーションのプロセスと名前空間の分離も提供します。これにより、複数のバージョンのアプリケーションを同じDockerホスト上で競合することなく並行して実行できます。仮想マシンに比べてサイズが小さいため、ホストあたりにVMに比べて多くのコンテナを詰め込むことができます。これにより、コンピューティングリソースをより効率的に使用できるようになり、Blue/Greenデプロイメントのコストを削減できます。

Amazon ECSのフルマネージド更新

Amazon EC2 Container Service (ECS) は、既存のAmazon ECSサービスを更新すると、ローリングアップデートを実行します。ローリングアップデートでは、現在実行中のバージョンのコンテナを最新バージョンに置き換えます。ローリングアップデート中にAmazon ECSがサービスに追加または削除するコンテナの数は、サービスのデプロイ時に許可される健全なタスクの最小数と最大数を調整することによって制御されます。

最新バージョンのコンテナイメージを利用するようにサービスのタスク定義を更新すると、Amazon ECSによってコンテナの古いバージョンが自動的に最新バージョンに置き換えられます。デプロイメント中、Amazon ECSは現在実行中のバージョンから接続を切断し、新しいコンテナがオンラインになるとApplication Load Balancer に登録します。

Target groups

ターゲットグループは、同じApplication Load Balancerの背後に複数のサービスを実行できるようにする論理構造です。これは、ターゲットグループごとにリスナーを持つことで実現されています。

Application Load Balancerを前に置くECSサービスを作成する時は、サービスのターゲットグループを指定する必要があります。通常はECSサービスごとにターゲットグループを作成しますが、ここでご紹介するアプローチでは、BlueのサービスとGreenのサービスの2つのターゲットグループを作成します。Blueサービスと同じパスを使用してGreenサービスをテストできるように、ターゲットグループごとに異なるリスナーポートを使用しています。

この構成では、Greenサービスに切り替える準備が整うまで、両方の環境を並行して実行できます。セキュリティグループルールや配置制約を使用して、社内ネットワーク上のテスターからにのみGreenバージョンへのアクセスを制限することも可能です。たとえば、サービスのGreenバージョンを、企業ネットワークからアクセス可能なインスタンスでのみ実行するように設定することができます。

切り替え

古いBlueサービスを新しいGreenサービスに置き換える準備ができたら、ModifyListener APIを呼び出して、対象のターゲットグループのリスナールールを入れ替えます。変更は即座に反映されます。その後、Greenサービスはポート80のリスナーを使用してターゲットグループで実行され、Greenサービスはポート8080のリスナーを使用してターゲットグループで実行されています。下の図は、このアプローチを示しています。

シナリオ

2つのサービスが定義されており、それぞれのターゲットグループが同じApplication Load Balancerに登録され、異なるポートで待機しています。 2つのターゲットグループ間でリスナールールを入れ替えることでデプロイが完了します。

Blueサービスへのリクエストはポート80リスナーを持つターゲットグループに向けられ、Greenサービスへのリクエストはポート8080リスナーを持つターゲットグループに向けられています。

テストの後で、Application Load Balancerでリスナールールをスワップし、Greenサービスにトラフィックを送信することで、デプロイメントを完了します。

留意事項

このアプローチを使用する際に注意すべきポイントがいくつかあります。

  • アプリケーションコードが完全にステートレスである必要があります。ステート情報はコンテナの外部に格納してください。
  • コネクションドレイニングはグレースフルには実行されません。ターゲットグループのスワップは突然実行されます。そのため、実行時間が長いトランザクションがあるサービスの場合は注意が必要です。
  • カナリアデプロイメントは実行できません。この方法では、サービスの異なるバージョン間をすばやく切り替えることができますが、本番トラフィックの一部をカナリアに流したり、サービスがクラスタ全体に展開される速度を制御したりすることはできません。

カナリアテスト

標準のAmazon ECSデプロイを使用したデプロイメント方法では、ローリングデプロイメントに伴う重労働の多くが自動化されますが、問題を発見した場合にデプロイメントを途中で中断することはできません。ロールバックしたい場合は、最後の正常なコンテナバージョンにサービスのタスク定義を更新し、Amazon ECSがクラスタ全体にデプロイを実行するのを待つ必要があります。最新のバージョンでテスト中に発見されなかった問題のある変更が導入されてしまった場合、このロールバック方法では遅すぎる可能性があります。

カナリアテストでは、Green環境が期待どおりに動作していないことがわかった場合、Blue環境に影響はありません。トラフィックを元の環境に戻すことができるため、問題のある操作やダウンタイムを最小限に抑え、影響範囲を制限します。

このタイプのデプロイメントは、一部分のユーザーに新しい機能を公開して広く利用できるようにする前にフィードバックを得るA/Bテストに特に役立ちます。

カナリアスタイルのデプロイメントでは、同じターゲットグループにBlueサービスとGreenサービスを配備します。この方法はスワップ方式ほど高速ではありませんが、各サービスのタスク数を調整することで、コンテナの交換レートを制御することができます。さらに、BlueとGreenのサービスのタスク数をそれぞれ調整することでロールバックすることができます。上記のスワップアプローチとは異なり、コンテナへの接続はグレースフルに終了します。我々はAmazon ECSのカナリアスタイルのデプロイメントについてのブログも投稿する計画を立てています。

まとめ

AWSでは、Amazon ECS、Application Load Balancer、およびターゲットグループを使用して、Blue/Greenデプロイメントの操作が可能になります。 ecs-blue-green-deployment GitHubリポジトリに公開されているコードをお客様のユースケースに合わせてカスタマイズすることをお勧めします。

より詳細に興味がある場合、 Blue/Green Deployments on AWSおよびPracticing Continuous Integration and Continuous Delivery on AWSというホワイトペーパーをお読みください。 ご質問やご提案がありましたら、ぜひご意見をお寄せください。あなたのフィードバックを楽しみにしています。

(翻訳はSA千葉が担当しました。原文はこちら)