Amazon Web Services ブログ

Amazon CloudWatch における高解像度メトリクスとアラーム

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto ScalingElastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボードダッシュボードでの API/CloudFormation のサポートダッシュボードにアラームなどを追加してきました。

最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。

新しい高解像度のメトリクス
本日、高解像度のカスタムメトリクスを対象とするサポートを追加しました。また、今後 AWS サービスのサポートを追加することも計画しています。アプリケーションが 1 秒の解像度で CloudWatch にメトリクスを発行できるようになりました。発行後、数秒でメトリクスを画面で見ることができるほか、10 秒ごとに評価する高解像度の CloudWatch アラームをセットアップできます。

使用可能なメモリが低下するとアラームが起動すると想像してください。これは通常、頻度が低いサンプルではキャッチしにくい一時的な状態です。高解像度のメトリクスでは、数秒内に閲覧、検出 (アラームを使用)、対応することができます。

この場合、右側のアラームが開始しないので問題に気付くことがありません。

高解像度メトリクスの発行
高解像メトリクスを発行するには 2 つの方法があります。

  • APIPutMetricData 関数が StorageResolution パラメーターを許可するようになりました。このパラメーターを 1 に設定して高解像度メトリクスを発行します。スタンダードの 1 分間の解像度で発行するにはこれを排除 (または 60 に設定) します。
  • collectd プラグイン – 高解像度メトリクスのコレクションと発行をサポートするように collectd の CloudWatch プラグインを更新しました。そのため、 enable_high_definition_metrics パラメーターをプラグインの config ファイルで設定する必要があります。

解像度はメトリクスが古くなるに連れて低下するので、CloudWatch は徐々にロールアップするようになっています。スケジュール詳細は次の通りです。

  • 1 秒に設定したメトリクスは 3 時間使用可能です。
  • 60 秒に設定したメトリクスは 15 日間使用可能です。
  • 5 分に設定したメトリクスは 63 日間使用可能です。
  • 1 時間に設定したメトリクスは 455 日間使用可能です (15 か月)。

FIFO キューに対して GetMetricStatistics 高解像度メトリクスでは期間を 1、5、10、30 または 60 秒の倍数に指定することができます。標準メトリクスでは期間を 60 秒の倍数に指定することができます。

簡単なデモをお見せします
一番近い EC2 インスタンスを取得し collected および Python プラグインの最新バージョンをインストールします。

$ sudo yum install collectd collectd-python

次にプラグインのセットアップスクリプトをダウンロードし、実行可能にしてから実行します。

$ wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
$ chmod a+x setup.py
$ sudo ./setup.py

前もって適切な IAM ロールを作成済みなので、これをインスタンスに追加します。これはセットアップ中、自動的に検出されました。高解像度メトリクスを有効にするように促されます。

collectd が実行され、発行メトリクスが数秒で開始しました。CloudWatch コンソールを開き様子を見ます。

ズームインしてメトリクスの詳細を見ます。

memory.percent.used メトリクスを 10 秒間隔でチェックするアラームも作成します。これにより、短期間に大量のメモリがどこで使用されているか検出しやすくなります。

提供開始
高解像度のカスタムメトリクスやアラームはパブリック AWS リージョンで今すぐご利用いただけます。AWS GovCloud (US) でのサポートも近日中に提供する予定です。

従来通り、追加料金なしに毎月 10 件までのメトリクスを保存することができます。詳しくは「CloudWatch 料金表 (CloudWatch Pricing)」のページをご覧ください。高解像度メトリクスの料金は標準解像度メトリクスと同様です。より多くのメトリクスを使用すると、ボリューム層ベースで節約 (メトリクスごと) することができます。高解像度アラームの料金は 1 か月あたり各アラーム 0.30 USD です。

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…)

CloudFormation スタックセットを使ったリソースのプロビジョニング

AWS CloudFormation は AWS をご利用されているお客様がコードとしてのインフラストラクチャモデルを実装するのに役立ちます。環境やアプリケーションのセットアップを手動で行う代わりに、同機能はテンプレートを構築して CloudFormation スタックと呼ばれる必要なリソースすべてを作成するために使うことができます。このモデルは手動によるエラーを排除し、効率性の向上や、設定における一貫性を長期に渡り保つことを可能にします。

そこで、今回はこれまで以上に CloudFormation を便利にする最新の機能強化についてご紹介します。この機能は、複数の AWS アカウントや AWS リージョンなどの状況で、コードとしてインフラストラクチャを使用する場合に直面するチャレンジに対応しやすくするように設計されています。手短にご説明します。

アカウント – 以前ご説明したように、多くの組織が複数の AWS アカウントを使用していますが、AWS Organizations でアカウント階層化し、組織単位 (OU) でグループにしています (詳細は「複数の AWS アカウントのポリシーベース管理 – AWS Organizations (AWS Organizations – Policy-Based Management for Multiple AWS Accounts)」をご覧ください)。AWS のお客様はビジネスユニット、アプリケーション、開発者に渡り複数のアカウントを使用しています。アプリケーションごとの開発、テスト、ステージング、実稼働環境にそれぞれ別のアカウントを作成するのが一般的になっています。

リージョン – また、AWS をご利用のお客様は多数の (現在も増加中) AWS リージョンを 大いに利用しています。2 つまたはそれ以上のリージョンに渡りグローバルアプリケーションを構築し、洗練されたマルチリージョンの災害対策モデルの実装、S3AuroraPostgreSQLMySQL データをリアルタイムでレプリケートし、国内および地域に適用される規制に準拠する方法で機密データの保存先や処理を行う場所を選びます。

複数のアカウントやリージョンへの拡大は、ガバナンスや適合性に見合うための新たなチャレンジを伴っています。AWS のお客様は各アカウントが必ず内部基準に合うようにしたいと言っています。特に IAM ユーザーとロール、VPC、VPC サブネット、セキュリティグループ、設定ルール、ロギング、AWS Lambda 関数などを一貫性があり信頼性の高い方法で設定したいというリクエストが寄せられています。

StackSet の概要
こうしたお客様の大切なニーズに応えるため、AWS は本日 CloudFormation StackSet をリリースしました。これにより、CloudFormation のテンプレートで AWS リソース設定を定義できるようになり、数回のクリックで複数の AWS アカウントやリージョンに渡りその設定を適用できるようになりました。これを使用して、先述のリストに挙げたクロスアカウントやクロスリージョンに対応する AWS 機能のベースラインレベルをセットアップすることができます。設定が完了したら、その他のアカウントやリージョンへも簡単に範囲を拡大できます。

この機能はクロスアカウントベースで常に作用します。管理者アカウントには 1 つまたはそれ以上の StackSets があり、1 つ以上のターゲットアカウントのデプロイメントをコントロールします。管理者アカウントには引き受け可能な IAM ロールが必要となり、ターゲットアカウントは管理者アカウントに信頼を託すことが必須になります。手順詳細については「前提条件 (Prerequisites)」の項目を「StackSet ドキュメント (StackSet Documentation)」でご覧ください。

各 StackSet は CloudFormation のテンプレートを参照し、アカウントとリージョンのリストを含みます。すべての操作は StackSet のアカウントとリージョンのクロスプロダクトに適用されます。StackSet は 3 つのアカウント (A1、A2、A3) と 4 つのリージョン (R1、R2、R3、R4) を参照します。ターゲットは 14 あります。

  • リージョン R1: アカウント A1、A2、A3
  • リージョン R2: アカウント A1、A2、A3
  • リージョン R3: アカウント A1、A2、A3
  • リージョン R4: アカウント A1、A2、A3

テンプレートをデプロイすると、アカウントとリージョンのペアで CloudFormation スタックの作成が開始します。テンプレートはリージョン内 (並列処理の度合いはあなたがコントロールします) にある複数のアカウントで順番にリージョンでデプロイされます (順番はあなたがコントロールします)。スタック作成の失敗時にデプロイを終了するように、エラーのしきい値を設定することもできます。

既存の CloudFormation テンプレート (アカウントやリージョンに渡りすぐ使用できるか確認)、新規作成または AWS によるサンプルテンプレートを使用できます。AWS パーティションのサポートを開始します (中国を除くすべてのパブリックリージョン)。近い内にその他のリージョンにも拡大する予定です。

StackSets の使用
CloudFormation コンソールCloudFormation APIコマンドラインから StackSets を作成しデプロイすることができます。

コンソールを使用して、まず [Create StackSet] をクリックします。独自のテンプレートまたはサンプルテンプレートを使用します。この例ではサンプルを使用します (設定ルール encrypted volumes を追加)。

[View template] をクリックしてテンプレートの詳細とルールを確認します。

StackSet に名前を付けます。選択したテンプレートはオプションのパラメーターを許可するので、ここに入力します。

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

リージョンをセットアップし、デプロイの順番をコントロールできます。

デプロイのオプションを設定することもできます。完了したら [Next] をクリックして次に進みます。

StackSet にタグを追加できます。これはデプロイ中に作成した AWS リソースに適用されます。

デプロイが開始します。コンソールからステータスをチェックできます。

[Stacks] セクションを開くと各スタックを見ることができます。最初、各スタックのステータスは [OUTDATED] になっています。これはテンプレートがまだスタックにデプロイされていないことを意味し、デプロイが完了すると [CURRENT] に変わります。スタックを削除できない場合は、ステータスが [INOPERABLE] に変わります。

最初のデプロイが完了したら [Manage StackSet] をクリックして、アカウントやリージョンまたは両方を追加し、新たなスタックを作成します。

提供開始
この新機能は追加料金なしに今すぐご利用いただけます (お客様用に作成された AWS リソースのみが請求対象になります)。

Jeff;

PS – 便利なテンプレートを作成したので、他の AWS ユーザーとシェアしたいという方は、AWS ラボ GitHub repo にプルリクエストを送信してください。

Amazon AppStream 2.0 のGPU強化によるストリーミングインスタンス

re:Invent 2016 でリリースした Amazon AppStream 2.0 についてお知らせします。このアプリケーションストリーミングサービスは、デスクトップブラウザに Windows アプリケーションを配信することができます。

フルマネージド型の AppStream 2.0 は、多目的、コンピュート最適化、メモリ最適化のストリーミングインスタンスでアプリケーションを実行することにより、一貫性のあるスケーラブルなパフォーマンスを提供し、安全で忠実度の高いストリーミングプロトコルの NICE DCV を介して配信します。エンタープライズおよび公的機関のお客様は、レガシーアプリケーションストリーミング環境の代わりにオンプレミスでインストール済みの AppStream 2.0 をすでにご利用されています。こうしたお客様は AppStream 2.0 を使用して、商用アプリケーションおよびビジネスアプリケーションをデスクトップ ブラウザに配信しています。ISV をご利用されているお客様はコードを変更せずに、AppStream 2.0 を使用してアプリケーションをそのままクラウドに移動しています。こうしたお客様はデモ、ワークショップ、企業の SaaS プランなどに注目しています。

高評価を頂いている AppStream 2.0 には新しい機能が迅速に追加されています (AWS の平均に比べても速い方です)。今年に入ってからすでに image builderSAML 2.0 のフェデレーティッドアクセスCloudWatch モニタリングFleet Auto Scalingシンプルなネットワークセットアップユーザーファイル用の永続的ストレージ (Amazon S3 によりバックアップ)、VPC セキュリティグループのサポートユーザー向けのウェブポータルを含む組み込みのユーザー管理が追加されています。

新しい GPU によるストリーミングのインスタンス
専用のデザイン、エンジニアリング、HPC、メディアアプリケーションをユーザーに提供するために AppStream 2.0 を使用したいというリクエストを数多く頂きました。こうしたアプリケーションは、通常グラフィックスを集中的に使用し GPU (グラフィックスプロセッシングユニット) と組み合わせた高額で高性能の PC で実行するように設計されています。こうしたアプリケーションのハードウェア要件により、定期的または時折アクセスする場合のみ使用することでコストを抑えることが一般的でした。そして、最近になってまた新しい要件が追加されました。ほとんどの場合、こうしたアプリケーションはクラウドで保存、処理、安全に維持することが適切とされる大量の機密データへの共有済みの読み書きアクセスが必要です。このようなユーザーやアプリケーションのニーズに応えるため、AWS は 2 つの新しいタイプのストリーミングインスタンスをリリースすることにしました。

Graphics DesktopG2 インスタンスタイプをベースにした Graphics Desktop インスタンスは、CUDA、DirectX、レンダリング用の OpenGL を使用するデスクトップアプリケーション向けに設計されています。こうしたインスタンスは 15 GiB のメモリと 8 vCPU を備えています。AppStream イメージまたは AppStream フリートを設定する際に、このインスタンスファミリーを選択できます。

Graphics Pro – 最新の G3 インスタンスタイプをベースにした Graphics Pro インスタンスは、NVIDIA API を使用または大量のメモリへのアクセスを必要とするハイエンドで高性能のアプリケーション用に設計されています。こうしたインスタンスには 3 つのサイズがあり 16 – 64 vCPU まで対応でき、122 – 488 GiB までのメモリを提供します。繰り返しになりますが、AppStream フリートを設定する際にこのインスタンスファミリーを選択できます。

ストリーミングアプリケーション環境の起動、実行、スケールの方法に関する詳細は「Amazon AppStream 2.0 でデスクトップアプリケーションストリームをスケールする (Scaling Your Desktop Application Streams with Amazon AppStream 2.0)」をご覧ください。

前述のとおり、こうした 2 つのインスタンスタイプのいずれかを使用して AppStream イメージを構築することができます。これでアプリケーションのテストや微調整を行い、インスタンスの動作を見れるようになります。

ストリーミングインスタンスインアクション
AWS は新しいインスタンスタイプのプライベートベータプログラムで複数のお客様と協力してきました。AppStream 2.0 を介してストリーミングしているアプリケーションの例を (スクリーンショットも) いくつかご紹介しましょう。

AVEVA は海運業、電力産業、プラント業界、海底油田およびガス産業において、エンジニアリングデザインと情報管理ソフトウェアソリューションで世界をリードする企業です。大規模な資本投入を伴うプロジェクトの一部として、同社の顧客はエンジニアリングの専門家から成る多数のグループをまとめて、デジタルアセット製作の共同作業を行う必要があります。この要件をサポートするため、AVEVA はストリームしたエンジニアリングアプリケーションのストリーム送信と世界中のエンジニアと共有するスケーラブルプロジェクトデータ環境へのアクセスを組み合わせた SaaS ソリューションを構築しています。新しいインスタンスは AVEVA がクオリティとパフォーマンスを最大限に活用しながら SaaS のエンジニアリングデザインソフトウェアを送信できるようにします。次のスクリーンショットは Everything 3D アプリが AppStream からストリームされている様子を表したものです。

日本の多国籍自動車メーカーの Nissan は、高価なグラフィックワークステーションで 3D シミュレーションソフトウェアを使用して自動車スペシャリストをトレーニングしています。The DiSti Corporation が開発したトレーニングソフトウェアは、スペシャリストが作業する車のリアルな 3D モデルを使用しながら、メンテナンスのプロセスをシミュレートできるようにします。AppStream 2.0 の新しいグラフィック性能により、Nissan は低価格の PC で実行するデスクトップブラウザに向けて、最新情報を含むトレーニングツールをリアルタイムで配信できるようになりました。同社のスペシャリストは、実にリアルな車のレンダリングを操作できるようになり、効率性の高いメンテナンスオペレーションのトレーニングや計画を立てられるようになりました。

Cornell University はアメリカのニューヨーク州イサカにあるアイビーリーグの私立大学で、ランドグラント大学です。同大学はコースワークや授業内容、リサーチをサポートするために、AutoDesk AutoCAD や Inventor といった高度な 3D ツールを学生や職員に提供しています。今までは、こうしたツールを使えるのは研究室や教室にある GPU によるワークステーションに限られていました。AppStream 2.0 はあらゆるデスクトップで実行するウェブブラウザでアプリケーションを提供できるようにし、ローカルワークステーションで使用しているかのように実行することができます。研究室や教室にある利用可能なワークステーションだけに限定されることがなくなり、自分のデバイスでコースソフトウェアにアクセスできるようになりました。このように柔軟性が増したことで、職員がコーススケジュールを作成する際に研究室を利用できるかどうか考慮する必要がなくなりました。同大学の AppStream で実行している Autodesk Inventor Professional のコピーはこちらをご覧ください。

提供開始
グラフィックスストリーミングインスタンスファミリーはどちらも米国東部 (バージニア北部)米国西部 (オレゴン)欧州 (アイルランド)アジアパシフィック (東京) のリージョンで今すぐご利用いただけます。アプリケーションは Windows 2012 R2 環境で実行する必要があります。また、DirectX、OpenGL、CUDA、OpenCL、Vulkan を使用することもできます。

米国東部 (バージニア北部) リージョンでの Graphics Desktop インスタンスの料金は 1 時間あたり 0.50 USD、Graphics Pro インスタンスの料金は 1 時間あたり 2.05 USD です。経済的な時間単位の支払い方法で AWS クラウドにて独自のシミュレーション、視覚化、HPC ワークロードを実行できます。Amazon Elastic Compute Cloud (EC2)Amazon Simple Storage Service (S3)AWS LambdaAmazon Redshift、その他の AWS サービスですばやい低レイテンシーアクセスを利用し、データ処理前後を扱うワークフロー処理を構築することもできます。

Jeff;

Hightail — クラウド上での創造的なコラボレーションを支援

Hightail (旧社名: YouSendIt) は、世界各地の 5,000 万人以上の専門家が優れたコンテンツをユーザーに提供できるよう支援することで、創造的な作業の確認、改善、承認方法を合理化しています。Hightail は、ファイル共有会社として 2004 年に設立されて以来、付加価値のある創造的なコラボレーションサービスの提供へと戦略的方向を転換し、著名な顧客を数多く獲得しています。

本日のゲスト投稿では、Hightail の技術担当上級副社長である Shiva Paranandi 氏が、同社が実施したオンプレミスからクラウドへのペタバイト単位のデータ移行について語ります。クラウドベンダーの評価プロセスと、すべてを AWS に移行した理由が述べられています。


Hightail はユーザーが大きなファイルを簡単に共有して保存できる方法を提供するために設立されましたが、それ以降、創造的なコラボレーションツールへと進化してきました。当社は、ユーザーがデジタル資産を管理、共有するだけの場所ではなく、創造的なチームを作り、顧客とつながり、創造的なワークフローを開発して、最初から最後までプロジェクトを管理できる場所になりました。現在では、LionsgateJimmy Kimmel Live! といった有名ブランドのコラボレーションサービスの原動力となっています。当社は、国内外の顧客が増える中で、製品開発とユーザーへのサービスに対して社内的により傾注する必要がありました。独自のデータセンターの運営には、予定していたよりも多くの時間、費用、人材が必要になることがわかりました。

より迅速に反復して顧客のニーズを満たし、市場までの時間を大幅に改善する手法が必要でした。データセンターのコストを削減し、世界各地の特定のリージョンで迅速にスケールアップする柔軟性が必要だったのです。新しい場所でのデータセンターの設営には長い時間がかかり、当社が達成できる成長ペースの妨げとなっていました。さらに、使用することもないストレージキャパシティーを所有することになる、ニーズに先回りした購入にはうんざりしていました。頻繁に使用しないデータを非アクティブなストレージに保持する一方で、顧客のリクエストに応じてそのデータを迅速に取り出せることでコストを削減する、階層型で非常にスケーラブルなストレージソリューションが必要でした。当社の主な推進力は俊敏性と革新であり、クラウドはそれらを強力に可能にしてくれます。それを踏まえて、ストレージとコンピューティングインフラストラクチャの管理にリソースを投入するのではなく、ビジネスを差別化する構想に時間とコストを費やすことができる、クラウドファーストのポリシーを採用することに決定しました。

AWS とクラウド競合他社の比較

移行の開始にあたって、まず AWS、Google、IBM、Microsoft を含むさまざまなクラウドベンダーの評価を行いました。当社にとっては明らかに AWS が抜きん出た選択肢でした。ある時点では、ニーズを満たすために複数のクラウドプロバイダーからのサービスを組み合わせることを検討しましたが、最適なルートは AWS を単独で使用することであると判断しました。トレーニング、同期、サポート、システムの可用性、それに他の移行や管理の要素を考慮すると、複数のクラウドを使用する手法は実用的ではありませんでした。最善のコスト削減と、ほかに例を見ないパートナーソリューションのエコシステムにより、他のベンダーは必要なく、すべてを AWS に移行することを選択しました。

AWS に移行することで、ギガバイトあたりの最低料金、リッチなエコシステムへのアクセス、社内の迅速な人材開発、SOC II コンプライアンスの維持が可能になりました。エコシステムは特に当社にとって重要で、非常に多くのパートナーを持つ AWS は競合他社とは一線を画していました。実際に、イメージのプレビュー、ビデオのエンコード、プレゼンテーションの提供などのサービスについて当社が依存しているすべてのベンダーは既にこのネットワークに参加しているため、既存の投資や専門知識を簡単に利用することができました。別のプロバイダーを選択していれば、既に正しく稼働しているプラットフォームからの移行が必要になりますが、これは当社にとって望ましい結果ではありませんでした。また、AWS のテクノロジーについて社内で開発できる人材の数も驚くべきものでした。AWS の使用に関する内部チームのトレーニングは、AWS カンファランス、トレーニング教材、サポートなどの利用可能なツールを使用した簡単なプロセスです。

ペタバイト単位のデータの移行

AWS を選択したことで、作業が簡単になりました。多くの場合、社内で使用していたよりも優れた機能が提供されました。オンプレミスストレージから AWS に数ペタバイトのデータを簡単に移行できました。AWS の Direct Connect により高速に処理を進めることができたため、3 か月ほどですべてのデータをプッシュできました。それによるユーザーへの影響はありませんでした。AWS Key Management Service を採用してデータを安全に保ち、それにより移行の際の安心感が得られました。顧客への影響が低いことを確認するため、当社データセンターと AWS にプッシュされたデータ間のチェックサムなどの方法を使用して、事前に広範な QA テストを実行しました。

AWS 上の新しいプラットフォームにより、ユーザーエクスペリエンスが大きく改善しました。信頼性、パフォーマンス、稼働時間において大きな改善が見られました。これらは当社の業務においてすべて非常に重要です。現在では、以前のデータセンターよりも最大 17 倍高速なアップロードおよびダウンロード速度を達成することができ、稼働時間も桁違いに向上しています。また、新しいリージョンへのサービスのデプロイにかかる時間も、90% 以上削減できました。以前は、新しいリージョンをオンラインにするには少なくとも 6 か月かかっていましたが、現在では、3 週間以内でリージョンを立ち上げることができます。AWS では、災害対策の目的で、リージョン間でデータをバケットレベルでレプリケートすることもできます。

コストを削減するため、ストレージインフラストラクチャを、アクセス頻度が高いデータと低いデータに分類することができました。Amazon S3 の階層化ストレージは大きな利点であり、これによりストレージコストを最適化することができ、製品開発へのより多くの投資が可能になっています。現在では、顧客のニーズを満たすために非アクティブ階層からアクティブ階層にデータを瞬時に移動でき、ストレージインフラストラクチャを過剰プロビジョニングする必要がなくなりました。ピーク負荷の時間中にサービスが自動的に拡張または縮小するのを見て、必要な分だけの支払いで済んでいることを知るのは爽快です。

全体として、当社はインフラストラクチャではなく開発により多く集中するという主要な戦略目標を達成しました。当社の移行はシームレスに感じられ、ここでお伝えできる進歩こそが、ワークロードを AWS で実行するのがいかに簡単であるかの真の証です。移行の成功要因の一部として、AWS チームから提供された専用サポートが挙げられます。サポートは本当に素晴らしいものでした。何人かの技術者は 24 時間 365 日チャットに対応してくれましたが、これは大規模な移行では不可欠なものでした。

-Shiva Paranandi 氏、Hightail 技術担当上級副社長

詳細

Amazon S3 によるコスト効率の高い階層型データストレージの詳細について参照するか、AWS パートナーエコシステムで、お客様のニーズに最適なソリューションをお探しください。

Amazon Kinesis Streams のサーバーサイド暗号化

昨今ではスマートホーム、ビッグデータ、IoT デバイス、携帯電話、ソーシャルネットワーク、チャットボット、ゲームコンソールなどが一般的に普及しており、ストリーミングデータはごく普通のことになりました。Amazon Kinesis Streams は、何千ものストリーミングデータソースから毎時間ごとにテラバイト単位のデータをキャプチャ、処理、分析、保存できるカスタムアプリケーションの構築を可能にしています。Amazon Kinesis Streams では、アプリケーションが同じ Kinesis ストリームから同時にデータを処理することができるので、並列処理システムを構築することができます。たとえば、処理済みのデータを Amazon S3 だけに送信するようにし、Amazon Redshift で複雑な分析を行ったり、AWS Lambda を使用する堅牢なサーバーレスストリーミングソリューションを構築することもできます。

Kinesis Streams では消費者が複数のストリーミングユースケースを利用できるようにしていますが、今後は Kinesis Streams でサーバー側の暗号化 (SSE) をサポートすることにより、移動中のデータをより効率的に保護できるようになりました。この新しい Kinesis Streams の機能により、データのセキュリティを強化したり、組織のデータストリーミングで必要となる様々な規制とコンプライアンス要件を満たすことができます。
Kinesis Streams は Payment Card Industry Data Security Standard (PCI DSS) のコンプライアンスプログラムで AWS 対象範囲内サービスの 1 つになっているほどです。PCI DSS は、主要な金融機関が設立した PCI Security Standards Council が管轄する専有情報のセキュリティ基準です。PCI DSS コンプライアンスは、カード所有者のデータやサービスプロバイダを含む機密性の高い認証データを保存、処理、転送する機関すべてに適用されます。AWS Artifact を使用して、PCI DSS Attestation of Compliance や Responsibility Summary をリクエストすることができます。Kinesis Streams とのコンプライアンスにおけるメリットはこの他にもあります。Kinesis Streams は AWS GovCloud の FedRAMP にも準拠しています。FedRAMP は Federal Risk and Authorization Management Program の略で、米国政府全体のプログラムであり、クラウド製品およびサービス向けのセキュリティ評価、認証、継続的なモニタリングに関する標準化されたアプローチを提供するものです。AWS サービスの FedRAMP コンプライアンスに関する詳細についてはこちらをご覧ください。

 

さあ、いかがでしょう? 興味が湧いてきましたか?今すぐ始めてみましょう!でもとりあえず、後もう少し説明してみます。Kinesis Streams の SSE に触れたので、Kinesis におけるサーバー側の暗号化の流れについて解説しておきます。PutRecord または PutRecords API を使用して Kinesis Stream に含んだデータレコードやパーティションキーは AWS Key Management Service (KMS) マスターキーを使用して暗号化されています。AWS Key Management Service (KMS) のマスターキーを使用し、Kinesis Streams は 256 ビットの Advanced Encryption Standard (AES-256 GCM アルゴリズム) を使って受信データに暗号化を追加します。

新規または既存のストリームに Kinesis Streams でサーバー側の暗号化を有効にするには、Kinesis マネジメントコンソールを使用、または利用可能な AWS SDK の 1 つを使います。また、ストリームの暗号化の履歴を監査したり、Kinesis Streams コンソールで特定のストリームの暗号化ステータスの検証や、PutRecord または GetRecord トランザクションが AWS CloudTrail サービスを使用して暗号化されているか確認することができます。

チュートリアル: Kinesis Streams でのサーバー側の暗号化

Kinesis Streams でサーバー側の暗号化の演習をしてみましょう。まず [Amazon Kinesis console] にアクセスし [Streams console] オプションを選択します。

Kinesis Streams コンソールにアクセスしたら、既存の Kinesis ストリームの 1 つにサーバー側の暗号を追加または新しい Kinesis ストリームを作成することができます。このチュートリアルでは、Kinesis ストリームを作成したいので [Create Kinesis stream] ボタンを選択します。

ストリーム名を「KinesisSSE-stream」にし、ストリームにシャードを 1 つ割り当てます。ストリームのデータ容量は、そのストリームで特定されたシャード数をもとに計算されることを忘れないでください。コンソールで [Estimate the number of shards you’ll need ] ドロップダウンを使用するか、こちらでストリームのシャード数を予測する計算に関する詳細をご覧ください。[Create Kinesis stream] ボタンをクリックして、ストリームの作成を完了します。

KinesisSSE-stream を作成したら、ダッシュボードを選択し [Actions] ドロップダウンで [Details] オプションを選択します。


KinesisSSE-stream の [Details] ページに [Server-side encryption] セクションが表示されるようになります。このセクションで [Edit] ボタンを選択します。

これで、[Enabled] ラジオボタンを選択し AWS KMS のマスターキーでストリームにサーバー側の暗号化を有効にすることができます。このボタンを選択すると、どの AWS KMS マスターキーを KinesisSSE-stream のデータの暗号化に使用するか選択できます。Kinesis サービスが生成した KMS のマスターキーまたは (Default) aws/kinesis、もしくはすでに作成してある KMS マスターキーの 1 つを選択することができます。この例では、デフォルトのマスターキーを選びます。後は [Save] ボタンをクリックするだけです。


これで完了です。 次のスクリーンショットで表示されているように、約 20 秒後にはサーバー側の暗号化が Kinesis ストリームに追加され、ストリームに送信された受信データはすべて暗号化されるようになります。サーバー側の暗号化では、暗号化が有効になって初めて受信データが暗号化される点にご注意ください。サーバー側の暗号化が有効になる前の Kinesis ストリームにある既存のデータは暗号化されません。

まとめ

AWS KMS キーを使用してサーバー側の暗号化を有効にしている Kinesis Streams では、ストリームに送られてくるストリーミングデータの暗号化の自動化を行いやすくします。AWS マネジメントコンソールまたは AWS SDK を使用して、Kinesis ストリームのサーバー側の暗号化の開始、停止、更新ができます。Kinesis のサーバー側の暗号化に関する詳細や AWS Key Management Service または Kinesis Streams のレビューに関する詳細については「Amazon Kinesis の入門ガイド (Amazon Kinesis getting started guide)」、「AWS Key Management Service の開発者ガイド (AWS Key Management Service developer guide)」または「Amazon Kinesis の製品ページ (Amazon Kinesis product page)」をご覧ください。

ストリーミングをぜひご活用ください。

Tara

新機能 – 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で作成されるプロジェクトも参考になるかと思いますので合わせてご参考頂ければと思います。