Category: Management Tools*


アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。

Jeff;


アプリケーションパフォーマンスのパーセンタイルメトリクス
AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。

パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% を超えないリクエストのみで 2 ミリ秒以上の処理時間がかかることになります。

リクエストのトレーシング内蔵
パーセンタイルはすべてのリクエストにおけるパフォーマンスの全体像を示すことでアプリケーションの可視性を大幅に向上させますが、AWS のアプリケーションロードバランサーの新しいトレーシング機能では、アプリケーションのパフォーマンスとヘルス状態を個々のリクエストの核心レベルまで掘り下げた理解を提供できます。ALB は現在 1 つの ALB へのすべてのリクエストにおける新しいカスタム X-Amzn-Trace-ID HTTP ヘッダーを探索しています。受信リクエストにこのヘッダーがない場合、ALB は次のようなヘッダーを生成します。

X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354 

そしてこのリクエストをアプリケーションに渡します。ヘッダーがないため、この受信リクエストは「ルート」リクエストと考慮され、ALB が送る新しいヘッダーが無作為に生成されるルート属性に含められます。受信リクエストにヘッダーが付けられている場合、そのコンテンツは保持され、こうしてヘッダーはリクエスト間の系統やタイミングデータなどのトレーシングと診断状態を送付、保持します。たとえば、生成されるリクエストは次のようになります。

$ curl -H \
  "X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354; TimeSoFar=112ms; CalledFrom=Foo" \
  request-tracing-demo-1290185324.elb.amazonaws.com 

このリクエストは ALB によって多少異なるヘッダーが生成されます。

X-Amzn-Trace-Id: Self=1-582113d1-1e48b74b3603af8479078ed6;\
  Root=1-58211399-36d228ad5d99923122bbe354;\
  TotalTimeSoFar=112ms;CalledFrom=Foo 

この例にように受信ヘッダーが自身のルーツ属性に含まれる場合、ALB はそれを保持して無作為に生成される新しい「セルフ」属性を代わりに追加します。この例に TotalTimeSoFar および CalledFrom 属性は任意でありオプショナルとなり、そしてロードバランサー自体にとっては実際意味のないものですが、アプリケーションとトレーシングフレームワークがリクエスト間でデータを移動させるためにそのまま保持されます。受信リクエストにヘッダーを設定しないアプリケーションでは、ALB のリクエストのトレースはすべてのリクエストを一意に識別する働きをします。リクエスト間でヘッダーを送付するアプリケーションでは、トレース機能によってシステム全体におけるエントリポイントを容易に識別し、ルート属性によって関連するリクエストを検索し、アプリケーションがリクエストをつなぐ「パンくず」リストを作成できるようにします。X-Amzn-Trace-ID ヘッダーのコンテンツは Application Load Balancer アクセスログに記載され、これにはそれぞれのリクエストにおけるエラー表示やパフォーマンス測定が含まれ、個別のリクエストにおける事案の特定のための識別用に使用できます。

http 2016-11-08T00:04:13.109451Z app/request-tracing-demo/f2c895fd3ea253c5 \
  72.21.217.129:20555 172.31.51.164:80 0.001 0.001 0.000 200 200 276 550 \
  "GET http://request-tracing-demo-1290185324.elb.amazonaws.com:80/ HTTP/1.1" \
  "curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.16.1 \
  Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" - - \
  arn:aws:elasticloadbalancing:us-east-1:99999999999:targetgroup/echoheader/21a6f1501d2df426 \
  "Root=1-5821167d-1d84f3d73c47ec4e58577259"

パーセンタイル統計は今すべての Application Load Balancer に利用でき、CloudWatch コンソール、AWS SDKsAPI からアクセスできます。既存の Application Load Balancer とすべての Classic Load Balancer へのサポートはこれから利用できる予定です。どちらの新しい機能も無償で導入されます。

Colm MacCárthaigh、AWS Elastic Load Balancer

AWS の値下げ – CloudWatch メトリクスの料金

2011 年と同じに 私は CloudWatch 用のカスタムメトリクスと、お客様のアプリケーションやスクリプトからそれらのメトリクスを発行する方法について説明しました。そのときに、最初の 10 個のカスタムメトリクスは無料で、追加のメトリクスは、発行したメトリクスの数にかかわらず、1 か月あたり、1 メトリクスあたり 0.50 USD でした。本日は、CloudWatch メトリクスの料金変更と数量割引について発表いたします。毎月お客様が発行するメトリクスの数に基づいて、最大 96% の節約を実現できます。US East (Northern Virginia) リージョンの新料金を次に示します (最初の 10 個のメトリクスは引き続き無料です)。

階層 下限 上限 1 か月あたり、1 メトリクスあたりの料金 現在の料金に対する割引率
最初の 10,000 メトリクス 0 10,000 0.30 USD 40%
次の 240,000 メトリクス 10,001 250,000 0.10 USD 80%
次の 750,000 メトリクス 250,001 1,000,000 0.05 USD 90%
残りの全メトリックス 1,000,001 0.02 USD 96%

EC2 詳細モニタリングを有効にした場合、1 か月あたりの料金は、1 か月、1 インスタンスあたり 3.50 USD から、ボリューム層に基づき 2.10 USD またはそれ以下に下がります。新料金は 2016 年 12 月 1 日に有効になり、お客様は何もする必要はありません。そのときに、更新された料金は CloudWatch 料金表ページに記載されます。ところで、CloudWatch メトリクスをご利用中の場合は、メトリクス保存期間の延長Collectd の CloudWatch プラグインCloudWatch ダッシュボード、新しいメトリクスからログへの概要ナビゲーション機能など、最近発表されたその他の機能もぜひご利用ください。

Jeff;

CloudTrail の更新 – Amazon S3 オブジェクトレベルの API アクティビティのキャプチャと処理

AWS の複数のサービスを組み合わせることで、多くのお客様が直面している問題に対処できることを示したいと思います。ここでは、本日発表される新しい AWS CloudTrail 機能を紹介し、この機能を CloudWatch イベントと合わせて使う方法について説明します。

課題
お客様はさまざまな種類のミッションクリティカルなデータを Amazon Simple Storage Service (S3) に保存しており、これらのデータに対するオブジェクトレベルのアクティビティを追跡できることを望んでいます。S3 アクセスログには、アクティビティの一部がキャプチャされて保存されますが、その詳細レベルは限定的でログ配信に何時間もかかる場合があります。お客様は、より充実した詳細とタイムリーな配信を求めています。金融サービスなどの規制業界では特にそうです。たとえば、特定の IAM ユーザーが S3 バケットの特定箇所に保存されている機密情報にアクセスした時間を確認したいというような要望があります。このようなお客様のニーズを満たすために、S3 オブジェクトに対するオブジェクトレベルのアクティビティをキャプチャする機能を CloudTrail に追加します。この機能はデータイベントと呼ばれます (CloudTrail の元のイベントは今後、管理イベントと呼びます)。データイベントは、”読み取り” オペレーション (GETHEADGet Object ACL など) と “書き込み” オペレーション (PUTPOST など) で構成されます。これらのオペレーションでキャプチャされる詳細のレベルは、セキュリティ、監査、ガバナンス、コンプライアンスのさまざまなユースケースに対応するよう意図されています。たとえば、この詳細のレベルに基づいて、個人識別情報 (PII) 用に新しいアップロードされたデータのスキャン、保護されたバケット内のデータに対するアクセス試行の監査、適切なアクセスポリシーが適用されていることの確認ができます。

オブジェクトレベルの API アクティビティの処理
以上のすべてを考慮して、選択されたバケット内のオブジェクトやバケット内の選択されたフォルダーに対して S3 オペレーションが実行されるたびに、それをカスタムアクションで処理する Lambda 関数を簡単に設定できます。この投稿に着手する前に、jbarr-s3-trail という新しい CloudTrail 追跡を作成しておきました。

この追跡を使用して、S3 バケットの 1 つ (jbarr-s3-trail-demo) に対するオブジェクトレベルのアクティビティを記録することにします。そのためには、この追跡にイベントセレクターを追加する必要があります。このセレクターは S3 専用であり、対象のイベントに集中してログを記録できます。イベントセレクターは CloudTrail の新しい機能です。本日、発表の一部として紹介されますのでご注目ください。読み取りイベントと書き込みイベントの両方を記録することにして、対象のバケットを指定します。プレフィックスを指定することでバケットの一部のみを対象としてイベントを記録したり、複数のバケットを対象としてイベントを記録したりできます。また、管理イベントのログ記録を設定することもできます。

CloudTrail では、追跡ごとに最大 5 つまでイベントセレクターを追加できます。各イベントセレクターは、最大 50 個の S3 バケットとオプションのバケットプレフィックスを指定できます。これを設定し、バケットを S3 コンソールで開き、ファイルをアップロードして、追跡内のエントリの 1 つを確認してみます。以下のようになりました。

{
"eventVersion": "1.05",
"userIdentity": {
"type": "Root",
"principalId": "99999999999",
"arn": "arn:aws:iam::99999999999:root",
"accountId": "99999999999",
"username": "jbarr",
"sessionContext": {
"attributes": {
"creationDate": "2016-11-15T17:55:17Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2016-11-15T23:02:12Z",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"sourceIPAddress": "72.21.196.67",
"userAgent": "[S3Console/0.4]",
"requestParameters": {
"X-Amz-Date": "20161115T230211Z",
"bucketName": "jbarr-s3-trail-demo",
"X-Amz-Algorithm": "AWS4-HMAC-SHA256",
"storageClass": "STANDARD",
"cannedAcl": "private",
"X-Amz-SignedHeaders": "Content-Type;Host;x-amz-acl;x-amz-storage-class",
"X-Amz-Expires": "300",
"key": "ie_sb_device_4.png"
}

次に、シンプルな Lambda 関数を作成します。

さらに、この関数の名前 (PutObject) に対応する CloudWatch Events ルールを作成し、Lambda 関数 (S3Watcher) を呼び出します。

いくつかのファイルをバケットにアップロードし、Lambda 関数が正常に呼び出されていることを確認します。

Lambda 関数の出力を含む CloudWatch エントリを確認することもできます。

料金と提供地域
データイベントは指定した S3 バケットについてのみ記録され、0.10 USD/100,000 イベントの料金になります。この機能は、すべての商用の AWS リージョンで使用できます。

Jeff;

Amazon CloudWatch 更新 – パーセンタイル統計およびダッシュボードの新ウィジェット

最近は Amazon CloudWatch 関連の動きが非常に活発です!今月前半には、メトリクスから関連するログへ移動する方法をご紹介し、またメトリックス保存期間の延長とユーザーインターフェイスの更新についてお知らせしました。本日、CloudWatch は再び改良され、パーセンタイル統計および 2 つの新しいダッシュボードウィジェットが追加されました。AWS re:Invent のおかげで時間がほとんどないため、簡潔に説明します。

パーセンタイル統計
ウェブサイトやクラウドアプリケーションを大規模に実行する場合、必要なレベルのパフォーマンスをお客様の大多数にお届けできていることを確認する必要があります。数字で平均を確認することも大切ですが、全体像が分かりにくい場合もあります。平均値によってパフォーマンスの異常値が隠れてしまうことがあり、たとえば、お客様の 1% に不便をおかけしていることがわからない場合があります。カスタマーエクスペリエンスを適切に伝える方法でパフォーマンスや挙動を理解し視覚化するために、パーセンタイルは便利なツールです。たとえば、パーセンタイルを使用して、ウェブサイトに対するリクエストの 99% が 1 秒以内に満たされていることを確認できます。Amazon ではパーセンタイルを広範に使用しており、今やお客様にも同様に使用していただけるようになりました。プレフィックスとして「p」を付け、サイトやサービスの応答時間の目標と実際のパフォーマンスを p90p99、および p100 (最低の場合) として表現します。長年の経験で、当社ではロングテールにおける応答 (p99 以上) が、データベースのホットスポットおよびその他のトラブルスポットを検出するために使用できることが判っています。パーセンタイルのサポートは、EC2、RDS、Kinesis、および新しく作成された Elastic Load Balancer および Application Load Balancer で利用できます。また、カスタムメトリクスでも利用できます。CloudWatch (カスタムダッシュボード含む) にパーセンタイルを表示できるほか、アラームを設定することもできます。パーセンタイルは他のメトリクスと組み合わせて表示できます。たとえば、オレンジと緑の線は p90 および p95 CPU 使用率を表します。

CloudWatch コンソールに、任意のパーセンタイルを設定できます。

新しいパーセンタイルメトリクスを使用してアプリケーションのパフォーマンスにさらに可視性を追加する方法について詳しくは、Elastic Load Balancing: Support for CloudWatch Percentile Metrics をご覧ください。新しいダッシュボードウィジェット Stacked Area ウィジェットおよび Number ウィジェットを CloudWatch のカスタムダッシュボードに追加できるようになりました。

以下はネットワークトラフィックの Stacked Area ウィジェットです。

EC2 および EBS メトリクスの Number ウィジェットはこのようになります。

 

今すぐご利用可能
すべての AWS リージョンで今すぐ新機能をご利用いただけます。

Jeff;

EBS スナップショットに CloudWatch Events を追加

これまで runbook で保たれていた情報や限定者のみ知ることができた情報など、複雑でレベルの高いオペレーションの自動化を可能にするクラウドコンピューティングは、従来の IT オペレーションを改善させることができます。特に小規模や成長段階の企業および団体でバックアップや復元操作を必要とするオペレーションが多く見られます。スナップショットのバックアップ生成や管理がしやすいため、AWS ユーザーの多くが Amazon Elastic Block Store (EBS) ボリュームを大いに利用しています。また災害対策や運用上の理由から、リージョン間でスナップショットのコピーを定期的に取っています。そこで本日、AWS は EBS に自動化のメリットとして新に EBS スナップショット用の CloudWatch Events を追加しました。このイベントを使用してクラウドベースのバックアップ環境に自動化したオペレーションを追加することができます。新しいイベントは次をご覧ください。

  • createSnapshot – 新たに作成した EBS スナップショットのステータスが Complete に変更すると開始します。
  • copySnapshot – スナップショットコピーのステータスが Complete に変更すると開始します。
  • shareSnapshot – スナップショットを AWS アカウントと共有すると開始します。

多くの AWS ユーザーがスナップショットのステータスをモニタリングしています。この操作を行うため、ユーザーは DescribeSnapshots 関数を何度も呼び出し、特定のスナップショットを探すためにページ分割出力を調べます。今後は新しいイベントを使用して先述のクロスリージョンコピーなど、さまざまなイベントベースの自動化が可能になります。スナップショットイベントの使用 この機能がいかにデータバックアップワークフローの自動化に役立つのか理解するため、別のリージョンに完成したスナップショットをコピーするワークフローを作成してみました。まず、適切なアクセス権限を付与する IAM ポリシーを作成します。次に createSnapshot イベントでアクションを実行する AWS Lambda 関数 (私の同僚が作成) を組み入れます。最後にイベントをキャプチャする CloudWatch Events ルールを作成し、Lambda 関数に転送します。まず、このポリシーで IAM ロール (CopySnapshotToRegion) を作成します。

次に新しい Lambda 関数を作成します (コードは Amazon CloudWatch Events for EBS で検索できます)。

次に CloudWatch Events コンソールにアクセスし [Create rule] をクリックしてから、正確に処理された createSnapshot イベントに対処できるように設定します。

名前を指定します。

テストするため自分のソースリージョンで新しい EBS スナップショットを作成します。

予想どおり関数が呼び出され、数秒内にスナップショットが目的のリージョンにコピーされました (実際に実行する場合、コピーの所要時間はスナップショットのサイズにより異なります)。

こうしたイベントを使用して、別のアカウントから共有されたスナップショットのコピーを作成することもできます。組織や団体そしてセキュリティ上のさまざまな理由から、AWS をご利用されている多くの方々が複数のアカウントにわたり容量を分割しています。この点に関する詳しいアドバイスについては AWS Multiple Account Security Strategy をご覧ください。5 つのモデルのうち 2 つについてはこちらをご覧ください。 今すぐ利用可能 新しいイベントは US East (Northern Virginia)US East (Ohio)US West (Northern California)US West (Oregon)Asia Pacific (Mumbai)Asia Pacific (Seoul)Asia Pacific (Singapore)Asia Pacific (Sydney)Asia Pacific (Tokyo)Europe (Frankfurt)Europe (Ireland)South America (Brazil) リージョンで今すぐ使い始めることができます。ぜひお試しください。皆様からのご感想をお待ちしています。

Jeff;

  PS – このようなシステムを構築してみたいという開発者、開発マネージャー、プロダクトマネージャーの方は EBS Jobs ページをご覧ください。

CloudWatch の更新 – メトリクスから関連するログへ

数年前に Amazon CloudWatch で OS とアプリケーションログファイルを保存しモニタリングする方法について説明しました。最近では多数の AWS ユーザーがログのフィルタを作成して、その結果を CloudWatch メトリクスとして発行し、何か問題があった場合にアラームを送信するようにしています。たとえばウェブサーバーログに無効なインバウンドリンクを表す 404 エラーや、オーバーロードの状態を意味する 503 エラーがあるか監視しています。モニタリングやアラームは大量のログデータを要約する上で優れたツールですが、場合によっては別の視点が必要になることもあります。まず、概要ではフィルタにより識別されアラームを送信する原因となったログファイルエントリをすばやく見つけなければなりません。多くの AWS ユーザーがそうであるように、何百、何千ものインスタンスを実行し複数のタイプのログファイルをモニタリングしている場合、こうした作業は針山から 1 本の針を見つけるようなものです。そこで本日、AWS はそうした作業を簡易化するため CloudWatch の新しいオプションをリリースしました。たとえばこのグラフに表示されている 17:00 頃の ERROR メトリクスについて理解したいとします。

クリックとドラッグで時間範囲を限定します。

ログアイコンをクリックし (他のアイコンと同様にグラフ上にマウスをかざすと表示されます)、目的のログファイル (ERROR) を選択します。

CloudWatch が 2 つめのタブで開きます。指定した時間範囲でフィルタする前の目的のログファイルが表示されます。次に内容を見るためにエントリを展開します (この例で使用した特定のエラーはデモ用なのでシンプルにしました)。

この機能はメトリクスの発行にログファイルのフィルタを使用する場合に便利です。では、特定のログファイルに関連していない CloudWatch システムメトリクスの場合はどうでしょう?先の手順を使用できますが、この場合はメニューから [View logs in this time range] を選択します。

指定した時間範囲の CloudWatch ロググループすべてがグラフに表示されています。

この時点でアプリケーションのアーキテクチャに関する知識をもとに意思決定を行ったり調査したいロググループを選択しやすくなります。目的の時間範囲内だけを表示するため、ロググループ内のイベントは再びフィルタにかけられます。グラフで Lambda の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

Jeff;

Amazon CloudWatch の更新 – メトリックス保存期間の延長とユーザーインターフェイスの更新

Amazon CloudWatch は AWS リソースと AWS で実行しているアプリケーションをモニタリングするサービスです。これはメトリックスの収集とトラッキング、ログファイルのモニタリング、アラーム設定、AWS リソースの変更に対応することができます。

本日、AWS は CloudWatch に追加した複数の重要な強化機能をリリースしました。

  • メトリックス保存期間の延長 – CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。
  • メトリックスの選択をシンプルに – CloudWatch コンソールで必要なメトリックスの検索と選択が簡単になりました。
  • メトリックスのグラフ化を改善 – 選択したメトリックスのグラフ化が今までより簡単かつ柔軟になりました。

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

メトリックス保存期間の延長
2009 年に CloudWatch をリリースした当時 (New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch) システムメトリックスの保存期間は 14 日間でした。その後、CloudWatch に自分のメトリックスを発行できるようになっても、保存期間は従来と変わりませんでした。AWS 利用者の多くが、より長い期間にわたりデータへのアクセスや閲覧を望んでいます。季節ごとの要因を検出して理解したり、毎月の成長傾向の確認、前年同期比の分析を実行するためです。

こうしたユースケースをサポートするため (そして多くの方々のリクエストにお応えするため)、CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。追加費用はありません。全体のデータ量を合理的な範囲に抑えるため、履歴データは詳細度が低いレベルで保存されます。詳しくは次をご覧ください。

  • 1 分間内のデータポイントは 15 日間にわたり利用可能です。
  • 5 分間内のデータポイントは 63 日間にわたり利用可能です。
  • 1 時間内のデータポイントは 455 日間 (15 か月) にわたり利用可能です。

この新機能の価値を直接ご理解いただくため、今すぐ 3 か月分のメトリックス保存期間の延長にアクセスできます。今後 12 か月にわたり、メトリックスは 15 か月分の履歴を保存するまで保持されます。

メトリックス保存期間の延長によるメリットを次の例でご説明します。この長期間にわたる私の AWS Lambda 関数は 2 週間ごとに異変があることを表しています。

メトリックスの選択をシンプルに
詳しく調べグラフ化したいメトリックスを検索し選択しやすくするため、CloudWatch コンソールで見やすいカード形式による表示方法を可能にしたほか、AWS メトリックスとカスタムメトリックスを区別しました。

次のステップで目的のメトリックスを検索します。たとえば名前に "CPU" が含まれているメトリックスを探すとします。

ここでメトリックスを選びグラフ化することができます。次の図は EC2 インスタンス全体の CPU 使用率 のメトリックスを表しています。

同じグラフで複数のメトリックスを表示することもできます。

これでは明確にお見せすることができないので、あとで簡単に修正方法をご説明します。

メトリックスのグラフ化を改善
メトリックスを 15 か月にわたり保存できるようになったほか、メトリックスの検索と選択も簡単になりました。情報を理解しやすくする方法をご説明します。この段階で、新に追加されたタブ (Graphed metricsGraph options) が便利になります。

[Graphed metrics] タブで各メトリックスを細かく管理することができます。

右側の [Actions] の列でアラーム作成やメトリックスの複製またはグラフから削除することができます。

変更するには [Statistic] の列にあるエントリをクリックします (どの列でも構いません)。

メトリックスを複製してから統計を変更できるので、たとえば CPU 使用率の最大値と平均値を比較することができます (この例では期間も 6 時間に変更しました)。

Y 軸コントロールは [Graph options] タブにあります。これを見てみましょう。すでに 7 つの EC2 メトリックスを同時にグラフ化しましたが、範囲がさまざまであるため、グラフから十分な情報を読み取ることができませんでした。左と右の Y 軸で各範囲を選択し、左側または右側でメトリックスを指定します。

これをクリックするとメトリックスのラベルを編集できます。
左と右の Y 軸の範囲を選択することもできます。

新しくなった日付指定を使用して期間を指定します。目的の日付範囲や現在の日付に関連するメトリックスを見ることができます。日付範囲の絶対値を選択する方法は次のとおりです。

関連性のある日付範囲は次のように選択します。

グラフ名を変更するには現在の名前をクリックしてから新しい名前を入力します。

必要に応じてグラフの詳細設定を完了したら、既存のダッシュボードに追加するか新しいダッシュボードを作成します。

これは私の既存のダッシュボードです。新しいグラフは下部にあります。

今すぐご利用可能
メトリックス保存期間の延長と、このブログで紹介した機能はすべて US East (Northern Virginia)US West (Oregon)US West (Northern California)Europe (Ireland)Europe (Frankfurt)South America (Brazil)Asia Pacific (Singapore)Asia Pacific (Tokyo)Asia Pacific (Seoul)Asia Pacific (Mumbai)Asia Pacific (Sydney) リージョンで使用可能です。

先述のとおり、メトリックス保存期間の延長のご利用にあたり追加費用は発生しません。

Jeff;

新しい collectd の CloudWatch プラグイン

これまでご自分のビジネス、アプリケーション、システムメトリックスを Amazon CloudWatch で保存されてきたと思います (詳しくは「Amazon CloudWatch の新しいカスタムメトリックス」をご覧ください)。随分前のことになりますが、私が 2011 年に書いたブログで「ユーザーの AWS リソースを CloudWatch で保存しているように、グラフを表示したり、アラームを設定、自動化したアクションをこうしたメトリックスに基づいて設定することができます。」といったように、この機能についてご紹介したことがあります。

そして本日より、新しい CloudWatch プラグイン collectd 対象を使用することで、ユーザーのシステムから統計を収集する方法を簡略化しながら収集した情報を CloudWatch に保存できるようになりました。さまざまなタイプの統計を収集する collectd の機能と、保存、表示、アラート、警告を可能にする CloudWatch の機能を組み合わせることで、EC2 インスタンスの状態とパフォーマンス、そして EC2 で実行しているオンプレミスハードウェアやアプリケーションについてより細かく把握することができます。このプラグインはオープンソースプロジェクトとしてリリースしています。皆様からのプルリクエストをお待ちしております。

パフォーマンスと可搬性を提供するため collectd デーモンは C で記述されています。これは 100 以上のプラグインをサポートし、ApacheNginx ウェブサーバーパフォーマンス、メモリ使用量稼働時間の統計を収集できるようにします。

インストールと設定
実際のアクションを見るため、collectd と新しいプラグインを EC2 インスタンスにインストールして設定してみました。

まず、CloudWatch にメトリックスデータを書き込むためのアクセス許可を使用して IAM ポリシーを作成します。

次にポリシーで EC2 を許可する IAM ロール (インスタンスで実行する collectd コード) を作成します。

オンプレミスサーバーから統計を収集するためにプラグインを使用する予定の場合や、すでに EC2 インスタンスを実行している場合は、このステップを行わずに適切なアクセス権限を代わりに使用して IAM ユーザーを作成します。私の場合、最初の例ではなくこの方法を実行していたら、ユーザーの認証情報をサーバーまたはインスタンスに追加する必要がありました。

ポリシーとロールの準備ができたら、EC2 インスタンスを起動してロールを選択します。

ログインを完了し collectd をインストールします。

$ sudo yum -y install collectd

次にプラグインを取得しスクリプトをインストールします。スクリプトを実行可能にしたら、それを実行します。

$ chmod a+x setup.py
$ sudo ./setup.py

いくつかの質問に答えた後、問題なく設定を実行できました。collectd は設定完了後に起動しました。

Installing dependencies ... OK
Installing python dependencies ... OK
Copying plugin tar file ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
  1. Automatic [us-east-1]
  2. Custom
Enter choice [1]: 1

Choose hostname for published metrics:
  1. EC2 instance id [i-057d2ed2260c3e251]
  2. Custom
Enter choice [1]: 1

Choose authentication method:
  1. IAM Role [Collectd_PutMetricData]
  2. IAM User
Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK
$

collectd を実行することができ、プラグインのインストールと設定が完了したら、次のステップは目的の統計を決定し、CloudWatch に発行するプラグインを設定することです (メトリックスごとに料金が発生するので、これは大切なステップです)。
ファイル /opt/collectd-plugins/cloudwatch/config/blocked_metrics には、収集したメトリックスのリストが含まれていますが、これは CloudWatch に発行されていません。

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
memory--memory-used
load--load-
memory--memory-buffered
memory--memory-cached

メモリの消費量が気になっていたので、次のラインを追加しました。 /opt/collectd-plugins/cloudwatch/config/whitelist.conf:

memory--memory-.*

collectd の設定ファイル (/etc/collectd.conf) には collectd とプラグインの設定も含まれています。私の場合、変更の必要はありませんでした。

変更を反映させるため、collectd を再起動させました。

$ sudo service collectd restart

多少のメモリを消費させるためにインスタンスを少し使用してから、CloudWatch コンソールを開きメトリックスを探し表示しました。

このスクリーンショットには、今後 CloudWatch コンソールに施される強化点のプレビューが含まれていますので、ご自分の画面に同じものが表示されなくてもご安心ください (詳しくは今後お知らせします)。

プロダクションインスタンスをモニタリングしていたのであれば、collected プラグインを 1 つ 2 つインストールすることもできました。Amazon Linux AMI で利用可能なリストは次をご覧ください。

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main
collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main
collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main
collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main
collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main
collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

主要事項
バージョン 5.5 以降の collectd を使用している場合は、4 つのメトリックスがデフォルトで発行されるようなりました。

  • df-root-percent_bytes-used – ディスク速度
  • memory–percent-used – メモリ使用量
  • swap–percent-used – スワップ使用率
  • cpu–percent-active – cpu 使用率

これらを発行したくない場合は whitelist.conf ファイルから削除することができます。

現在、Amazon Linux AMI、Ubuntu、RHEL、CentOS のプライマリリポジトリは古いバージョンの collectd を提供しています。カスタムリポジトリからインストールした場合またはソースから構築した場合はデフォルト設定による動作が異なる点にご注意ください。
その他
ご紹介できるものは他にもあるのですが、残念ながら時間切れです。その他のプラグインもインストールし whitelist.conf を設定してさらに多くのメトリックスを CloudWatch に発行することができます。CloudWatch アラームを作成してカスタムダッシュボードやその他を設定することもできます。

始めるには GitHub の AWS ラボにアクセスし collectd の CloudWatch プラグインをダウンロードしてください。

Jeff;

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;