Amazon Web Services ブログ

Category: Management Tools

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;

Read More

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 […]

Read More

新しい collectd の CloudWatch プラグイン

これまでご自分のビジネス、アプリケーション、システムメトリックスを Amazon CloudWatch で保存されてきたと思います (詳しくは「Amazon CloudWatch の新しいカスタムメトリックス」をご覧ください)。随分前のことになりますが、私が 2011 年に書いたブログで「ユーザーの AWS リソースを CloudWatch で保存しているように、グラフを表示したり、アラームを設定、自動化したアクションをこうしたメトリックスに基づいて設定することができます。」といったように、この機能についてご紹介したことがあります。 そして本日より、新しい CloudWatch プラグイン collectd 対象を使用することで、ユーザーのシステムから統計を収集する方法を簡略化しながら収集した情報を CloudWatch に保存できるようになりました。さまざまなタイプの統計を収集する collectd の機能と、保存、表示、アラート、警告を可能にする CloudWatch の機能を組み合わせることで、EC2 インスタンスの状態とパフォーマンス、そして EC2 で実行しているオンプレミスハードウェアやアプリケーションについてより細かく把握することができます。このプラグインはオープンソースプロジェクトとしてリリースしています。皆様からのプルリクエストをお待ちしております。 パフォーマンスと可搬性を提供するため collectd デーモンは C で記述されています。これは 100 以上のプラグインをサポートし、Apache や Nginx ウェブサーバーパフォーマンス、メモリ使用量、稼働時間の統計を収集できるようにします。 インストールと設定 実際のアクションを見るため、collectd と新しいプラグインを EC2 インスタンスにインストールして設定してみました。 まず、CloudWatch にメトリックスデータを書き込むためのアクセス許可を使用して IAM ポリシーを作成します。 次にポリシーで EC2 を許可する IAM ロール (インスタンスで実行する collectd コード) を作成します。 […]

Read More

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 テンプレートを記述する場合、同じ最上位の構造 (Description、Metadata、Mappings、Outputs、Parameters、Conditions、および Resources) を使用します。これは、パラメーター定義を図示したものです。 […]

Read More

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 軸の範囲を指定 […]

Read More

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間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。 利点: 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。 Service Auto Scalingのデモ この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします: Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。 そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。 ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。 […]

Read More

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

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

Read More

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 […]

Read More

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フォーラム 翻訳は酒徳が担当しました。本文はこちら。

Read More

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 では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 […]

Read More