Category: Management Tools*


AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換

AWS CloudFormation では、テンプレートを作成して、スタック全体 (関連する AWS リソースのコレクション) を宣言により表すことができます。スタックを定義し、希望のリソースとそれらの相互関係を指定および設定して、スタックの必要な数のコピーを起動できます。CloudFormation では、リソースを自動的に作成およびセットアップし、リソース間の順序付けの依存関係の対応に配慮することもできます。現在、CloudFormation には 3 つの重要な機能を追加中です。

  • YAML Support – CloudFormation テンプレートを YAML で記述できるようになりました。
  • クロススタック参照 – あるスタックから値をエクスポートし、別のスタックで使用できるようになりました。
  • 簡略化された置換 – テンプレート内で文字列の置換をより簡単に行うことができます。

それらについて説明します。

YAML のサポート
CloudFormation テンプレートを YAML (「YAML はマークアップ言語ではない」の頭文字) で記述できるようになりました。これまでは、テンプレートは JSON で記述されていました。YAML と JSON の表現力は同等ですが、YAML は人間が読み取れる形式であるよう設計されているのに対して、JSON は (正直なところ) そうではありません。YAML ベースのテンプレートでは句読点の使用が少なく、記述と読み取りがかなり簡単です。また、コメントの使用が許可されます。CloudFormation は、ハッシュ結合、エイリアス、および一部のタグ (バイナリ、imap、ペア、TIMESTAMP、セット) の例外を除き、実質的にすべての YAML をサポートします。

YAML で CloudFormation テンプレートを記述する場合、同じ最上位の構造 (DescriptionMetadataMappingsOutputsParametersConditions、および Resources) を使用します。これは、パラメーター定義を図示したものです。

Parameters:
  DBName:
    AllowedPattern: '[a-zA-Z][a-zA-Z0-9]*'
    ConstraintDescription: 英字で始まり、英数字のみにする必要があります。
      
    Default: wordpressdb
    Description: WordPress データベース名
    MaxLength: '64'
    MinLength: '1'
    Type: String

YAML を使用すると、省略された新しい構文を使用して CloudFormation 関数を参照できます。たとえば、GetAttBase64、および FindInMap などです。既存の構文 ("Fn::GetAtt") または新しいタグベースの構文 (!GetAtt) を使用できるようになりました。”!” は タグの YAML 構文の一部であり、「論理 NOT」演算子ではないことに注意してください。古い構文を次に示します。

- Fn::FindInMap:
    - AWSInstanceType2Arch
    - Ref: InstanceType
    - Arch

新しい構文を次に示します。

!FindInMap [AWSInstanceType2Arch, !Ref InstanceType, Arch]

おわかりのように、新しい構文は短く簡潔になっています。ただし、2 つのタグを隣接して使用することはできません。2 つの形式を混ぜて、ネストすることもできます。たとえば、 !Base64 !Sub は無効ですが、 !Base64 Fn::Sub は有効です。

CloudFormation の API 関数 (CreateChangeSetCreateStackUpdateStack など) では、JSON または YAML でテンプレートを使用できるようになりました。 GetTemplate 関数は元の形式でテンプレートを返します。CloudFormation designer では現在は YAML テンプレートはサポートされませんが、ロードマップには含まれています。

クロススタック参照
AWS の多くのお客様は、1 つの “システム” CloudFormation スタックを使って環境 (VPC、VPC サブネット、セキュリティグループ、IP アドレスなど) を設定し、その他の複数の “アプリケーション” スタックを使って入力 (EC2 および RDS インスタンス、メッセージキューなど) を行っています。これまで、アプリケーションスタックで、システムスタックによって作成されたリソースを参照するための簡単な方法がありませんでした。

1 つのスタックから値を作成してエクスポートし、カスタム CloudFormation リソースを作成する手間をかけることなく、他のスタックでそれらを使用できるようになりました。最初のスタックでは次のような値がエクスポートされます。

Outputs: 
  TSSG: 
    Value: !Ref TroubleShootingSG
    Export:
      Name: AccountSG

次に、他のスタックは新しい ImportValue 関数を使用してそれらを参照します。

EC2Instance:
  Type: AWS::EC2::Instance
	Properties:
	  SecurityGroups:
  	    - !ImportValue AccountSG

エクスポートされた名前は AWS アカウントおよびリージョンで一意である必要があります。別のスタックで参照されたスタックを削除することはできず、エクスポートされた値を変更または削除することはできません。

簡略化された置換
多くの CloudFormation テンプレートでは、コマンドライン、ファイルパス、およびスタックが作成されるまでに完全に決定できないその他の値を作成するために、複雑な文字列操作を行っています。これまでは、この操作には fn::Join を使用する必要がありました。この結果、JSON 構文との組み合わせにより、理解や管理が困難な乱雑なテンプレートが作成されました。テンプレート開発のこの重要な側面を簡略化するため、当社は新しい置換関数である fn::Sub を導入します。この関数は変数 (構文 ${variable_name}で示される) を評価された値で置き換えます。以下の例をご覧ください。

configure_wordpress:
  commands:
    01_set_mysql_root_password:
      command: !Sub |
           mysqladmin -u root password '${DBRootPassword}'
      test: !Sub |
           $(mysql ${DBName} -u root --password='${DBRootPassword}' >/dev/null 2>&1 </dev/null); (( $? != 0 ))
    02_create_database:
      command: !Sub |  
           mysql -u root --password='${DBRootPassword}' < /tmp/setup.mysql
      test: !Sub |
           $(mysql ${DBName} -u root --password='${DBRootPassword}' >/dev/null 2>&1 </dev/null); (( $? !=0))

${} または ${variable}を生成する必要がある場合は、単純に ${!} または ${!variable}を記述します。

対象の更新
このリリースの一部として、AWS Key Management Service (KMS)、EC2 スポット群、および Amazon EC2 Container Service のサポートを追加しました。詳細については、「CloudFormation Release History」を参照してください。

今すぐ利用可能
これらのすべての機能は今すぐご利用いただけます。

Jeff;

CloudWatch Logs とダッシュボードを改善

Amazon CloudWatch では AWS インフラストラクチャで発生する問題の確認、診断、対応、解決を AWS で実行しているアプリケーション内で行うことができます。今回は CloudWatch Logs (Store and Monitor OS & Application Log Files with Amazon CloudWatch) そして CloudWatch ダッシュボード (CloudWatch Dashboards – Create & Use Customized Metrics Views) に追加された複数のユーザビリティと機能の改善点についてご説明します。

CloudWatch Logs のユーザビリティを改善
CloudWatch Logs はオペレーティングシステムやアプリケーションログファイルを管理する、可用性と拡張性そして耐久性が高く安全なサービスです。ログのデータ取り込み、保管、フィルター、検索、アーカイブを可能にするため、操作の負荷を軽減しアプリケーションとビジネスに集中できるようにします。ログの件数やサイズが増えても効率性と生産性を維持できるようにするため、AWS では CloudWatch Logs コンソールにユーザビリティの改善点をいくつか加えました。

  • ログデータのフォーマット処理を改善
  • 長いログファイルへのアクセスを簡略化
  • ロググループ内の検索が簡単に
  • ログファイルの共同作業を簡易化
  • 特定の期間内の検索を改善

今回のリリース前に CloudWatch ダッシュボードにも改善点を加えました。

  • フルスクリーンモード
  • ダークテーマ
  • グラフ内にある Y 軸の範囲を指定
  • グラフ名の変更を簡易化
  • グラフ設定の永続的なストレージ

CloudWatch Logs コンソールの動作
では、次にそれぞれの改善点について詳しくご説明します。CloudWatch Logs コンソールを開き、ロググループをクリックしてからグループ内のログストリームにアクセスします。右側のオプションを表示メニューを見つけます。

次のように、複数行で拡大した状態でログメッセージを表示するにはすべて開くをクリックします。

飾りのないプレーンテキストでログを表示したい場合は、テキスト表示を切り替えることもできます。

この他にもロググループ内のストリームすべてに渡り、ログデータの表示を改善しました。ロググループを選びイベントを検索をクリックすると、そのロググループ内のストリームすべてからのログデータを見ることができます。例えば、1 つの Lambda 関数における複数の呼び出しに対する課金対象期間を見つけやすくなりました。

さらに、従来の割り付け表示に代わり、制限のないスクロールバーが導入されました。これでお好きなだけログファイルをスクロールできるようになりました。

次のように、特定の期間を指定したり、ワンクリックで日付を指定するなどして検索条件を絞り込むことが可能になりました。

チームの一員として作業をしている場合は、ご自分のログ分析セッションの URL を共有できるようになりました。
URL には検索パラメータとフィルターが含まれ、次のようなフラグメントもその一部になっています。

group=<log_group_name>_log;stream=<log_stream_name>;filter=<filter_parameter>;start=PT<time_frame>

この CloudWatch Logs コンソールの改善点は、今すぐご利用いただけます。詳しくは Getting Started with CloudWatch Logs をご覧ください。

CloudWatch ダッシュボードに追加した改善点
CloudWatch ダッシュボードに最近追加された改善点については、すでにお気づきの方もいらっしゃるかもしれません。まず、ダッシュボードに新しいフルスクリーンモードを追加しました。Actions メニューで全画面表示に切り替えるをクリックします。

フルスクリーンモード状態になったら、ダークをクリックして夜用の新しいダークテーマに切り替えることができます。

フルスクリーンモードでダークテーマを使用した Redis ダッシュボードの例がこちらです。

場合によってはダッシュボードにグラフをどのように表示するか、より細かに管理したいと思うこともあるのではないでしょうか。例えば、データの異常値がグラフを読みにくくしていて、ダッシュボードで Y 軸の特定範囲に集中したい場合などが考えられます。次の例はその場合のグラフです。異常値が急増した後に起きる傾向をマスクしています。

Y 軸を編集するには、ツールセレクターをクリックして Edit をクリックします。

Graph Options を選択し、お好きな具合にグラフが表示されるまで Y 軸の値を編集します。その後、ウィジェットの更新をクリックしてください。

編集後のグラフは次のようになります。

AWS の多くのお客様はダッシュボード内でグラフ名の変更ができるようにしたいとリクエストしていました。そして今回より、ワンクリックでその操作が可能になりました (グラフ名の近くにマウスを移動させ、鉛筆のアイコンをクリックするだけです)。

今後は CloudWatch が時間範囲、タイムゾーン設定、更新間隔、自動更新の設定を各グラフごとに記憶できるようになりました。

Amazon CloudWatch パートナーエコシステム
では最後に AWS パートナーによる優れたソリューションについてご紹介します。次のパートナーは CloudWatch に加え、付加価値のあるソリューションも構築しています。

  • DataDog はインフラストラクチャ内の主要項目との統合を提供し、問題対応の際に直接チームと協力することを可能にしています。
  • Librato はインフラストラクチャの要素に渡り統合を提供し、複合メトリックスや算術演算の時列系データへの変換をサポートしています。
  • SignalFx はメトリックスへの瞬時な可視性の提供、データ分析に集中そしてサービス規模で通知を送信しています。
  • Splunk はマシンデータの収集やインサイト検知を可能にするオペレーショナルインテリジェンスのプラットフォームを提供しています。
  • Sumo Logic はログ管理や時系列メトリックスのマシンデータ分析サービスで、アプリケーションの構築、実行、安全性の確保に役立っています。

ご自分が AWS パートナーでこちらのリストに属すものを提供していらっしゃる場合は、すぐに更新しますのでお知らせください。

Jeff;

Amazon ECSでAuto Scaling

Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。

この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。

Service Auto Scalingの概要

すぐに利用できるECS Serviceのスケーリング機能はずっと一番要望を受けていて、ついに今日この機能をアナウンスでき嬉しいです。自動でスケールするServiceの作成手順はとても簡単で、ECSコンソールやCLI、SDKでもサポートされています。希望するTaskの数とその最小・最大数を選択し、1つ以上のScaling Policyを作成すると、後はService Auto Scalingが面倒を見てくれます。Service SchedulerはAvailability Zoneを意識してくれるので、ECSのTaskを複数のZoneに渡って分散するように心配する必要もありません。

それに加えて、ECS Taskを複数AZ Cluster上で実行することも非常に簡単です。ECS ClusterのAuto Scaling Groupが、複数Zoneに渡る可用性を管理してくれるので、必要とされる回復力や信頼性を持つことができ、ECSがTaskのZone間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。

利点:

  1. 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。
  2. 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。

Service Auto Scalingのデモ

この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします:

  1. Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。
  2. そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。
  3. ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。
  4. ECS Service用のスケールインとスケールアウトのCloudWatch Alarmを設定する。
  5. ECS Cluster用のスケールインとスケールアウトのCloudWatch Alarmを設定する 。(注: 前のステップで作成したものとは別のAlarmになります)
  6. ECS Service用のScaling Policyを作成し、スケールアウトとスケールインする時のScaling Actionを定義する。
  7. ECS Clusterが動いているAuto Scaling Group用のScaling Policyを作成する。これらのPolicyはECS Clusterのスケールイン・アウトで利用されます。
  8. 負荷を徐々に増やしたり減らしたりすることで、スケーラブルなECS ServiceとClusterの高可用性をテストする。

この記事では、Cluster上に1つのECS Serviceを設定する手順をお見せしますが、このパターンは同じCluster上で複数のECS Serviceを実行する時にも適応できます。

注意: この例を実行した結果、発生した如何なるAWSのコストも支払う必要があります。

概念図

ECS ServiceのAuto Scalingを設定する

Auto Scalingを設定する前に、複数AZ (2 Zone)のCluster上で実行されていて、ロードバランサを前段に持つECS Serviceを作っておく必要があります。

CloudWatch Alarmを設定する

  1. Amazon CloudWatchのコンソール上で、ECS Serviceのスケールインとスケールアウト時に使われるCloudWatch Alarmを設定します。このデモではCPUUtilization (ECS, ClusterName, ServiceNameのカテゴリから選びます)を使いますが、他のMetricsを使うこともできます。(注: 他のやり方として、Service用のScaling Policyを設定する時にはECSのコンソール上でこれらのAlarmを設定することもできます。) 
  2. AlarmにECSServiceScaleOutAlarmという名前をつけ、CPUUtilizationの閾値を75に設定します。
  3. Actionの所でNotificationを削除します。このデモではECSとAuto Scalingのコンソールを使ってActionを設定します。
  4. 上記の2ステップを繰り返してスケールインのAlarmを作成し、CPUUtilizationの閾値を25にして、演算子を”<=”に設定します。
  5. Alarmsの所で、スケールインのAlarmがALARM状態にあるはずです。今のところECS Serviceに負荷がかかっていないので、これは期待した状態です。
  6. ECS Cluster用のCloudWatch Alarmを設定するために、前のステップと同じことをします。今度は、CPUReservation (ECS, ClusterNameから選びます)をMetricとして利用します。前のステップの様に2つのAlarmを作成し、1つがECS Clusterのスケールアウト用、他方がスケールイン用とします。それらにECSClusterScaleOutAlarmとECSClusterScaleInAlarm という名前(または自由な名前)を設定します。

注: これはCluster固有のMetricですが(Cluster-Service固有のMetricと対照的)、このパターンでも有効的ですし、複数ECS Serviceのシナリオでも有効です。ECS Clusterはどれが起因であってもClusterの負荷に応じて常にスケールします。

ECS ServiceのスケールはECS Clusterのスケールに比べてとても速いので、ECS ClusterのスケーリングのAlarmをECS ServiceのAlarmよりも敏感にしておくことをお勧めします。こうすることで、スケーリングの間Clusterに余分なキャパシティが常にあることを保証でき、一瞬の負荷のピークに対応することができます。もちろん気をつけるべきは、この余分なEC2のキャパシティでコストは増えるので、Clusterのキャパシティを確保するのとコストの間で良いバランスを見つける必要がありますが、それはアプリケーション毎に異なるでしょう。

ECS ServiceにScaling Policyを追加する

Add a scale out and a scale in policy on the ECS service created earlier.

先ほど作成したECS ServiceにスケールアウトとスケールインのPolicyを追加します。

  1. ECSコンソールにサインインし、Serviceが動いているClusterを選択、Servicesを開いてServiceを選択します
  2. Serviceのページでは、Updateを選択します。
  3. Taskの数が2になっていることを確認します。これはそのServiceが実行する時のデフォルトのTask数です。
  4. Update ServiceのページのOptional configurationsの下にある、Configure Service Auto Scalingを選択します。
  5. Service Auto Scaling (optional)のページのScalingの下にある、Configure Service Auto Scaling to adjust your service’s desired countを選択します。Minimum number of tasksとDesired number of tasksの両方に2と入力します。Maximum number of tasksには10を入力します。ECS Serviceの作成時にホスト(EC2インスタンス)上の80番ポートをECS Containerの80番ポートにマッピングしているので、Auto Scaling GroupとECS Taskが両方共同じ数値になっていることを確認しておいて下さい。
  6. Automatic task scaling policiesセクションの下の、Add Scaling Policyを選択します。
  7. Add Policyのページでは、Policy Nameに値を入力します。Execute policy whenには、前に作成したCloudWatch Alarm (ECSServiceScaleOutAlarm)を入力します。ActionではAdd 100 percentを設定し、Saveを選択します。
  8. 上の2つのステップの繰り返しで、前に作成したスケールインのCloudWatch Alarm (ECSServiceScaleInAlarm)を使ってスケールインのPolicyを作成します。ActionではRemove 50 percentを設定し、Saveを選択します。
  9. Service Auto Scaling (optional)ページで、Saveを選択します。

ECS ClusterにScaling Policyを追加する

ECS Cluster (Auto Scaling Group)にスケールアウトとスケールインのPolicyを追加します。

  1. Auto Scalingのコンソールにサインインしてこのデモ用に作成したAuto Scaling Groupを選択します。
  2. DetailsからEditを選択します。
  3. DesiredとMinが2に、Maxが10に設定されていることを確認して、Saveを選択します。
  4. Scaling PoliciesからAdd Policyを選択します。
  5. まず、スケールアウトのPolicyを作成します。Nameに値を入力し、Execute policy whenは前に作成したスケールアウトのAlarm (ECSClusterScaleOutAlarm)を選択します。ActionではAdd 100 percent of groupを設定し、Createを選択します。
  6. 上のステップを繰り返して、スケールインのPolicyをスケールインのAlarm (ECSClusterScaleInAlarm)を使って、ActionにはRemove 50 percent of groupを設定します。

Auto Scaling Group用のスケールインとスケールアウトのPolicyを見ることができるはずです。これらのPolicyを使って、Auto Scaling GroupはECS Serviceが動いているClusterのサイズを大きくしたり小さくしたりできます。

注: ClusterのScaling Policyをこの様に設定することで、Clusterに幾つかの余分なキャパシティを確保することになります。これによってECS Serviceのスケールアウトはより高速になりますが、同時に、需要に依ってはいくつかのEC2インスタンスが利用されない状態になることがあります。

以上でECS ServiceとAuto Scaling Groupに対して、今回はそれぞれ異なるCloudWatch Alarmによって発動するようにAuto Scalingの設定が完了しました。異なるCloudWatch Alarmsの異なる組み合わせを使ってそれぞれのPolicyをもっと凝ったScaling Policyとすることもできます。

これでスケールアウトできるキャパシティを持ったCluster上で動作するServiceができあがったので、Alarmが発動するようにロードバランサにトラフィックを流してみましょう。

ECS Serviceスケーリングの負荷試験

それでは、Apache abツールを使いECS Serviceに負荷試験をして、スケーリングの設定が動作するかを確認してみます(負荷試験インスタンスの作成の章をご覧ください)。CloudWatchのコンソールで、Serviceがスケールアウト・インする様子が見られます。Auto Scaling Groupが2つのAvailability Zoneを使う用に設定されているので、各Zoneに5つのEC2インスタンスを見ることができるはずです。また、ECS Service SchedulerもAvailability Zoneを意識するので、Taskも2つのZoneに渡って分散しているでしょう。

EC2コンソールから、手動でEC2インスタンスを終了させることで高可用性の試験もできます。Auto Scaling GroupとECS Service Schedulerが、追加のEC2インスタンスを起動しTaskも起動してくれるはずです。

追加で考慮すべきこと

  • キャパシティの確保: 既に書いた様に、ECS Clusterに余分なキャパシティを確保しておくことで、Clusterが新しいインスタンスを準備するのを待たなくて良いので、ECS Serviceのスケールアウトがとても高速になります。こちらはCloudWatch Alarmが発動する値を変更するか、Scaling Policyの値を変更することで簡単に実現できます。
  • インスタンスの終了保護: いくつかのスケールインのケースでは、利用できるECS Clusterのキャパシティが減少することで、強制的にTaskが終了したり他のホストに移動してしまいます。こちらはECS ClusterのスケールインのPolicyを需要に対して敏感に反応しないように調整するか、EC2のホストが終了する前にうまくTaskが終了できるようにすることで軽減できます。そのためには、別の記事で解説されているAuto Scaling Lyfecycle Eventインスタンスの終了保護をご覧頂くと良いと思います。

今回のデモではAWSコーンソールを使いましたが、もちろん同じことをAWS SDKやCLIを使って実現することも可能です。

まとめ

ミッションクリティカルなMicroservicesアーキテクチャを動かす時には、トータルでかかるコストを下げることは非常に重要ですし、加えて負荷を複数のZoneに分散できることや、ECS ServiceとClusterのキャパシティを負荷の変化に合わせて調整できることが必要になります。この記事でご紹介した手順では、2軸でのスケーリングを活用することでこれを実現することができます。

補足

2016年7月21日に全てのリージョンで利用可能となりました。 https://aws.amazon.com/about-aws/whats-new/2016/07/amazon-ec2-container-service-automatic-service-scaling-region-expansion/

原文: https://aws.amazon.com/blogs/compute/automatic-scaling-with-amazon-ecs/ (翻訳: SA岩永)

AWS Config – タグの変更検知の高速化、新しいマネージド ルール追加、およびユーザビリティの向上

AWS Config Rulesにいくつかの改良が加わり、より便利に利用できるようになりました。”required-tags“ルールの精度が改善され、タグの変更後数分以内にタグ変更の通知を受け取ることができるよになりました。またIAMユーザに対する多要素認証が有効になっているかを確認するマネジドルールも新たに追加され、JavaのサンプルコードがConfig Rules GitHub レポジトリで公開されています。さらにConfig Rulesコンソールから準拠/非準拠の注釈を確認することができ、Config Rulesの詳細ページからルールの呼び出しであったり、評価の際のタイムスタンプ等より細かい粒度のステータスを受け取ることができるようになりました。

翻訳は酒徳が担当しました。原文はこちら

Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター

Amazon Kinesis はストリーミングデータをクラウド上で簡単に扱えるようにします。

Amazon Kinesis プラットフォームは3つのサービスから構成されています:Kinesis Streams によって、開発者は独自のストリーム処理アプリケーションを実装することができます;Kinesis Firehose によって、ストリーミングデータを保存・分析するための AWS へのロード処理がシンプルになります;Kinesis Analytics によって、ストリーミングデータを標準的な SQL で分析できます。

多くの AWS のお客様が、ストリーミングデータをリアルタイムに収集・処理するためのシステムの一部として Kinesis Streams と Kinesis Firehose を利用しています。お客様はこれらが完全なマネージドサービスであるがゆえの使い勝手の良さを高く評価しており、ストリーミングデータのためのインフラストラクチャーを独自に管理するかわりにアプリケーションを開発するための時間へと投資をしています。

本日、私たちは Amazon Kinesis Streams と Amazon Kinesis Firehose に関する3つの新機能を発表します。

  • Elasticsearch との統合 – Amazon Kinesis Firehose は Amazon Elasticsearch Service へストリーミングデータを配信できるようになりました。
  • 強化されたメトリクス – Amazon Kinesis はシャード単位のメトリクスを CloudWatch へ毎分送信できるようになりました。
  • 柔軟性 – Amazon Kinesis から時間ベースのイテレーターを利用してレコードを受信できるようになりました。

Amazon Elasticsearch Service との統合

Elasticsearch はポピュラーなオープンソースの検索・分析エンジンです。Amazon Elasticsearch Service は AWS クラウド上で Elasticsearch を簡単にデプロイ・実行・スケールさせるためのマネージドサービスです。皆さんは、Kinesis Firehose のデータストリームを Amazon Elasticsearch Service のクラスターへ配信することができるようになりました。この新機能によって、サーバーのログやクリックストリーム、ソーシャルメディアのトラフィック等にインデックスを作成し、分析することが可能になります。

受信したレコード(Elasticsearch ドキュメント)は指定した設定に従って Kinesis Firehose 内でバッファリングされたのち、複数のドキュメントに同時にインデックスを作成するバルクリクエストを使用して自動的にクラスターへと追加されます。なお、データは Firehose へ送信する前に UTF-8 でエンコーディングされた単一の JSON オブジェクトにしておかなければなりません(どのようにこれを行うかを知りたい方は、私の最近のブログ投稿 Amazon Kinesis Agent Update – New Data Preprocessing Feature を参照して下さい)。

こちらが、AWS マネージメントコンソールを使用したセットアップの方法です。出力先(Amazon Elasticsearch Service)を選択し、配信ストリームの名を入力します。次に、Elasticsearch のドメイン(この例では livedata)を選択、インデックスを指定し、インデックスのローテーション(なし、毎時、日次、週次、月次)を選択します。また、全てのドキュメントもしくは失敗したドキュメントのバックアップを受け取る S3 バケットも指定します:

そして、バッファーのサイズを指定し、S3 バケットに送信されるデータの圧縮と暗号化のオプションを選択します。必要に応じてログ出力を有効にし、IAM ロールを選択します:

一分程度でストリームの準備が整います:

コンソールで配信のメトリクスを見ることもできます:

データが Elasticsearch へ到達した後は、KibanaElasticsearch のクエリー言語による視覚的な検索ができます。

総括すると、この統合によって、皆さんのストリーミングデータを収集し、Elasticsearch に配信するための処理は実にシンプルになります。もはや、コードを書いたり、独自のデータ収集ツールを作成したりする必要はありません。

シャード単位のメトリクス

全ての Kinesis ストリームは、一つ以上のシャードによって構成されており、全てのシャードは一定量の読み取り・書き込みのキャパシティを持っています。ストリームにシャードを追加することで、ストリームのキャパシティは増加します。

皆さんは、それぞれのシャードのパフォーマンスを把握する目的で、シャード単位のメトリクスを有効にすることができるようになりました。シャードあたり6つのメトリクスがあります。それぞれのメトリクスは一分間に一回レポートされ、通常のメトリクス単位の CloudWatch 料金で課金されます。この新機能によって、ある特定のシャードに負荷が偏っていないかを他のシャードと比較して確認したり、ストリーミングデータの配信パイプライン全体で非効率な部分を発見・一掃したりすることが可能になります。例えば、処理量に対して受信頻度が高すぎるシャードを特定したり、アプリケーションから予想よりも低いスループットでデータが読まれているシャードを特定したりできます。

こちらが、新しいメトリクスです:

IncomingBytes – シャードへの PUT が成功したバイト数。

IncomingRecords – シャードへの PUT が成功したレコード数。

IteratorAgeMilliseconds – シャードに対する GetRecords 呼び出しが戻した最後のレコードの滞留時間(ミリ秒)。値が0の場合、読み取られたレコードが完全にストリームに追いついていることを意味します。

OutgoingBytes – シャードから受信したバイト数。

OutgoingRecords – シャードから受信したレコード数。

ReadProvisionedThroughputExceeded – 秒間5回もしくは2MBの上限を超えてスロットリングされた GetRecords 呼び出しの数。

WriteProvisionedThroughputExceeded – 秒間1000レコードもしくは1MBの上限を超えてスロットリングされたレコードの数。

EnableEnhancedMetrics を呼び出すことでこれらのメトリクスを有効にすることができます。いつもどおり、任意の期間で集計を行うために CloudWatch の API を利用することもできます。

時刻ベースのイテレーター

任意のシャードに対して GetShardIterator を呼び出し、開始点を指定してイテレーターを作成することで、アプリケーションは Kinesis ストリームからデータを読み取ることができます。皆さんは、既存の開始点の選択肢(あるシーケンス番号、あるシーケンス番号の後、最も古いレコード、最も新しいレコード)に加え、タイムスタンプを指定できるようになりました。指定した値(UNIX 時間形式)は読み取って処理しようとする最も古いレコードのタイムスタンプを表します。

— Jeff;
翻訳は SA 内海(@eiichirouchiumi)が担当しました。原文はこちらです。

AWS Config Rulesが新しく4つのリージョンで利用可能になりました – US West (オレゴン), EU (アイルランド), EU (フランクフルト), Asia Pacific (東京)

AWS Config Ruleをご利用頂くと、ルールを作成することで、AWS Configにより記録されたAWSリソースの構成確認を継続的に実施することができ、リソースがガイドラインに準拠していない際は通知をすることが可能です。ルールのダッシュボードを使用することで、全体的にコンプライアントな状況かどうかを追跡し、コンプライアントでない状況につながった特定リソースの構成変更を特定するトラブルシューティングにご利用頂けます。

本日、AWS Config Rulesが新しく4つのリージョンで利用可能になりました。:US East (バージニア)に加え、 US West (オレゴン)、EU (アイルランド)、 EU (フランクフルト)、 Asia Pacific (東京)でご利用頂けます。

詳細情報
1. AWSマネジメントコンソールからAWS Configの利用開始
2. AWS Configのリージョンとエンドポイント
3. AWS Configフォーラム

翻訳は酒徳が担当しました。本文はこちら

New – AWS CloudFormation の変更点

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。

通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。

整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。

安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。

均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。

この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。

更新のサポートの向上
先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。

新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。

CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 (実行) するかどうかを選択できます。

この新しいモデルにより、変更される可能性のある内容を詳細に知ることができるだけではなく、更新をより詳細に制御できるようにもなります。IAM を使用すると、UpdateStackCreateChangeSetDescribeChangeSet、および ExecuteChangeSet といった CloudFormation の特定の機能の使用を制御できます。例えば、ほとんどの開発者に変更セットの作成とプレビューを許可するものの、実行は経験豊富な開発者で構成される少人数のグループのみに許可する、といった具合です。自動化項目をいくらか追加すると、データベースサーバーやネットワークといった主なリソースを変更しようとするとアラートが発生する、または追加の承認を要求するといった設定を行うこともできます。

変更セットを使用する
変更セットに関連する操作を順を追って見ていきましょう。AWS コマンドラインインターフェイス (CLI)AWS Tools for Windows PowerShell、および CloudFormation API を使用して、通常と同じ機能を利用できます。

今回は、まず、1 つの EC2 インスタンスで LAMP スタックを実行するスタックを作成します。リソースが作成されます。

その後、より複雑なアーキテクチャを利用することにします。同僚から適切なテンプレートをもらいました。「信頼するが確認する」という原則に基づいて、テンプレートを使用するとどうなるかを確認するために、変更セットを作成します。[Create Change Set] をクリックします。

その後、新しいテンプレートをアップロードして、変更セットに名前を割り当てます。テンプレートでパラメータを使用する場合は、ここで値を入力できます。

ここでは、既存のタグを変更することも、新しいタグを追加することもできます。スタックの詳細オプションを設定することもできます (当然、詳細オプションは、変更セットを実際に実行するまで適用されません)。

1、2 回クリックして設定を確定すると、テンプレートが分析され、スタックに適用した場合の結果がチェックされ、変更のリストが表示されます。

変更を有効にするには、ここで [Execute] をクリックします。変更セットの適用を見送ることも、他の方法を探すために変更セットをいくつか作成することもできます。準備が整ったら、変更セットを指定して、実行します。

CloudFormation がアクションを開始し、変更セットに沿って変更が実装されます。

数分後には、スタックの新しい構成が整い、完全に運用できるようになります。

これで完了です。先述のように、実行する変更セットを選択する前に、複数の変更セットを作成して、試してみることができます。この場合、実装しなかった変更セットは不要になるので、破棄します。

ロールバックを管理する
スタックの更新に失敗した場合、可能な限り、更新前の状態にロールバックされます。ロールバックオペレーションは失敗することもあります。多くの場合、ロールバックが失敗する原因は、CloudFormation の範囲外で行われた変更です。最近、ロールバックの結果をより適切に制御できるよう、新しいオプションが公開されました。このオプションの詳細については、Continue Rolling Back an Update for AWS CloudFormation stacks in the UPDATE_ROLLBACK_FAILED state をご覧ください。

今すぐ利用可能
変更点は今すぐ利用できます。ぜひご使用ください。


Jeff

CloudWatch Metrics for Spot Fleets

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく(1台のインスタンスから何千台のインスタンスまで)費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応

私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが(可能な限り費用対効果を高めるよう変化)、フリート自体はその属性を保持します。

新しいスポットフリート メトリックス

スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます:スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。

下記メトリックスは各スポットフリート毎に取得されます。(これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります)

  • AvailableInstancePoolsCount
  • BidsSubmittedForCapacity
  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • DiskWriteOps
  • EligibleInstancePoolCount
  • FulfilledCapacity
  • MaxPercentCapacityAllocation
  • NetworkIn
  • NetworkOut
  • PendingCapacity
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System
  • TargetCapacity
  • TerminatingCapacity

 メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、

  • AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。
  • BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。
  • EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか(1)スポット価格がオンデマンド価格より高い場合、または(2)入札価格がスポット価格よりも低い場合にはプールが不適用となります。
  • FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。
  • PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。
  • PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。
  • TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。
  • TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。

これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。

  • CPUUtilization
  • DiskReadBytes
  • DiskReadOps
  • DiskWriteBytes
  • FulfilledCapacity
  • NetworkIn
  • NetworkOut
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System

これらのメトリックスを利用することでアベイラビリティゾーン、インスタンスタイプをまたいだの負荷の許容可能な分布確認をすることができます。

フリート全体の使用率を把握するためにMax、Min、またはAvgを使用しメトリックを集計することができます。一方で、2種類以上のインスタンスからなるフリートでは、Avgを使用すること自体意味がないことにもご注意ください!

利用可能

この機能はすでにご利用頂けます。

— Jeff (翻訳は酒徳が担当しました。本文はこちら:https://aws.amazon.com/jp/blogs/aws/new-cloudwatch-metrics-for-spot-fleets/)

 

AWS Config Rules Repository のリリース

本日、AWS Config Rules Repositoryをリリースしました。AWS Config Rules Repository はコミュニティベースで、カスタマイズされたAWS Config Ruleを提供します。この新リポジトリを利用することで、AWSリソースのセキュリティに関するベストプラクティスに対し、評価とコンプライアンス評価の自動化が可能になります。 AWS Config Rules は、AWSリソースの定期的なセキュリティとコンプライアンスチェックを自動で行い、セキュリティ設定における手動作業の削減をサポートするサービスです。

AWS Config Rules Repository を使うことで、コンプライアンスチェックの自動化を加速させ、お客様はAWSコミュニティに集約された専門的な知識を簡単に利用できるようになります。それに加え、レポジトリは無料で公開されており、それぞれが独自に管理されています。それぞれのルールのコードが丸ごと共有されているため、そこから学び、コミュニティに貢献することもできます。全般的なセキュリティ専門家からの声とAWSユーザの観点からのセキュリティ専門家からの声を合わせることで、知見を高めることができればと思います。

以前のポストで述べたように、Center for Internet Securityと連携し、AWSアカウントを保護するための業界のベストプラクティスを確立しました。このリポジトリには、これらのベストプラクティスとの整合性を維持するのに役立つルールが幾つかあります。下記は現在、アクセス権を持っているカスタムルールのサンプルです:

  1. CloudTrailがすべての地域で有効になっているかの確認
  2. すべてのアカウントで多要素認証(MFA)が有効になっているかの確認
  3. ルートアカウントに対しキーが存在していないかの確認
  4. AWS Identity and Access Management (IAM) にIAM Policyが存在しているかの確認
  5. キーのローテーションが行われているかの確認

皆さんのAWSアカウントにこれらのルールを使用をする際には、GitHubの上のReadmeファイルを参照してください。是非このレポジトリを活用頂き、皆さんのカスタムルールをAWSコミュニテイで共有下さい!

Chad

翻訳は酒徳が担当しました。本文はこちら:http://blogs.aws.amazon.com/security/post/TxES3UX2Z5BQRU/Announcing-the-AWS-Config-Rules-Repository-A-New-Community-Based-Source-of-Custo