Category: Amazon CloudWatch

これまで runbook で保たれていた情報や限定者のみ知ることができた情報など、複雑でレベルの高いオペレーションの自動化を可能にするクラウドコンピューティングは、従来の IT オペレーションを改善させることができます。特に小規模や成長段階の企業および団体でバックアップや復元操作を必要とするオペレーションが多く見られます。スナップショットのバックアップ生成や管理がしやすいため、AWS ユーザーの多くが ボリュームを大いに利用しています。また災害対策や運用上の理由から、リージョン間でスナップショットのコピーを定期的に取っています。そこで本日、AWS は EBS に自動化のメリットとして新に EBS スナップショット用の CloudWatch Events を追加しました。このイベントを使用してクラウドベースのバックアップ環境に自動化したオペレーションを追加することができます。新しいイベントは次をご覧ください。 createSnapshot – 新たに作成した EBS スナップショットのステータスが Complete に変更すると開始します。 copySnapshot – スナップショットコピーのステータスが Complete に変更すると開始します。 shareSnapshot – スナップショットを AWS アカウントと共有すると開始します。 多くの AWS ユーザーがスナップショットのステータスをモニタリングしています。この操作を行うため、ユーザーは DescribeSnapshots 関数を何度も呼び出し、特定のスナップショットを探すためにページ分割出力を調べます。今後は新しいイベントを使用して先述のクロスリージョンコピーなど、さまざまなイベントベースの自動化が可能になります。スナップショットイベントの使用 この機能がいかにデータバックアップワークフローの自動化に役立つのか理解するため、別のリージョンに完成したスナップショットをコピーするワークフローを作成してみました。まず、適切なアクセス権限を付与する IAM ポリシーを作成します。次に createSnapshot イベントでアクションを実行する 関数 (私の同僚が作成) を組み入れます。最後にイベントをキャプチャする CloudWatch Events ルールを作成し、Lambda 関数に転送します。まず、このポリシーで IAM ロール (CopySnapshotToRegion) を作成します。 次に新しい Lambda […]

数年前に 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 の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

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

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

では 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 軸の範囲を指定 グラフ名の変更を簡易化 グラフ設定の永続的なストレージ […]

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のロードバランサを設定する。これが負荷の入り口になります。 […]

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

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（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 […]