Amazon Web Services ブログ

Tag: Amazon CloudWatch

Pre-built dashboard in console

Amazon ECS と Amazon EKS での AWS Distro for Open Telemetry と CloudWatch Container Insights の Prometheus サポートのご紹介

この記事は Introducing CloudWatch Container Insights Prometheus Support with AWS Distro for OpenTelemetry on Amazon ECS and Amazon EKS (記事公開日: 2021 年 8 月 24 日) を翻訳したものです。 CloudWatch Container Insights を使用して、コンテナ化されたアプリケーションやマイクロサービスを監視、トラブルシューティング、アラームすることができます。Amazon CloudWatch は、CPU、メモリ、ディスク、ネットワークデータなどのコンピュート使用率情報を収集、集約、要約します。また、コンテナの再起動失敗などの診断情報を提供することで、問題を切り分け、迅速に解決するのにも役立ちます。Container Insights は、Amazon Elastic Container Service (Amazon ECS) 、Amazon Elastic Kubernetes Service (Amazon EKS) 、AWS Fargate、スタンドアロンの Kubernetes などの、コンテナ管理サービスからのインサイトを提供します。 AWS は、Cloud Native Computing Foundation (CNCF) […]

Read More

Amazon WorkSpaces における異常検出

本記事は、Anomaly Detection in Amazon WorkSpaces を翻訳したものです。 この投稿は、Alec Bryan によって寄稿されました。 Amazon WorkSpacesは、AWS上で動作するフルマネージドでセキュアなDesktop-as-a-Service(DaaS)ソリューションです。お客様は、WorkSpacesを導入することで、働く場所を問わず、ユーザーに拡張性のあるエンドユーザーコンピューティングを提供しています。WorkSpaces Streaming Protocol (WSP)のリリース以降、USBやスマートカードのサポートなどの追加機能により、WorkSpacesへの移行でこれらの機能を利用できるワークロードが増えています。 ユーザーがどこにいても仕事ができるようになったことで、お客様はユーザーがWorkSpacesを介して様々なリソースにアクセスできることを確実にするという新たな課題に直面しています。ユーザーに問題が発生した場合、サポートチームは迅速かつ効果的に対応しなければなりません。ユーザーが接続できるようにするには、サービスプロバイダー、物理的な場所、エンドユーザーのデバイスなどの外部要因を考慮する必要があります。クライアントのハードウェアのソフトウェアや設定の変更に加えて、インターネット、または内部ネットワークでのネットワークの停止も考えられます。リモートワーカーの場合、ユーザーからサポートチームへのフィードバックが遅れ、想定される問題の根本原因を特定するまでの貴重な時間が失われることがあります。 このブログ記事では、ユーザー接続性の異常を警告する通知を設定する方法を紹介します。これにより、潜在的な問題を認識し、特定することによりユーザーへの影響範囲を把握することができます。

Read More
Deployment architecture for scaling ECS services with Application Auto Scaling

CloudWatch と Prometheus のカスタムメトリクスに基づく Amazon ECS サービスのオートスケーリング

この記事は Autoscaling Amazon ECS services based on custom CloudWatch and Prometheus metrics (記事公開日: 2021 年 2 月 26 日) を翻訳したものです。 イントロダクション クラウドネイティブアプリケーションにとって、水平方向のスケーラビリティは非常に重要な要素です。Amazon ECS にデプロイされたマイクロサービスは、Application Auto Scaling サービスを利用して、観測されたメトリクスデータに基づいて自動的にスケーリングします。Amazon ECS は、サービスに属するタスクが消費する CPU とメモリのリソースに基づいてサービスの使用率を測定し、このデータを ECSServiceAverageCPUUtilization と ECSServiceAverageMemoryUtilization という名前の CloudWatch メトリクスとして送信します。Application Auto Scaling は、これらの事前定義されたメトリクスをスケーリングポリシーと組み合わせて使用し、サービスのタスク数をメトリクスに応じてスケールすることができます。しかしながら、サービスの平均的な CPU とメモリの使用量だけでは、いつ、どの程度までスケーリングアクションを実行すべきかの信頼できる指標とはならないユースケースがいくつかあります。受信した HTTP リクエストの数、キュー/トピックから取得したメッセージの数、実行したデータベーストランザクションの数など、アプリケーションの他の側面を追跡するカスタムメトリクスが、スケーリングアクションのトリガーとしてより適している場合があります。 Application Auto Scaling は、事前定義されたメトリクスだけでなく選択した CloudWatch カスタムメトリクスに基づいてサービスをスケーリングすることもサポートしています。お客様は、プログラミング言語やプラットフォームに適した AWS SDK のいずれかを使用して、アプリケーションから CloudWatchに カスタムメトリクスデータを送信することができます。加えて、2020 […]

Read More

AWS サーバーレスサービスによるマルチテナント SaaS ソリューションの構築

この記事は、Building a Multi-Tenant SaaS Solution Using AWS Serverless Services を翻訳したものです。 本投稿は、AWS SaaS Factory の Sr. Partner Solutions Architect である Anubhav Sharma と AWS SaaS Factory の Partner Solutions Architect である Ujwal Bukka により寄稿されました。 SaaS (Software-as-a-Service) 提供モデルへの移行に際しては、コストと運用効率を最大限に高めたいという要望が伴います。 これは、利用傾向を予測することが困難なマルチテナント環境では特に難しい場合があります。なぜならば、テナントの活動とリソースの実際の消費量を一致させるスケーリング戦略の組み合わせを見つけることは困難だからです。今日はうまくいっていても、明日はうまくいかないかもしれません。 このような特性により、SaaS はサーバーレスモデルに非常に適していると言えます。SaaS のアーキテクチャからサーバーの概念を取り除くことで、企業はマネージドサービスを利用することによって、アプリケーションが消費するリソースの正確な数をスケーリングして提供することができます。 これにより、アプリケーションのアーキテクチャと運用のフットプリントが簡素化され、スケーリングポリシーを継続的に追跡・管理する必要がなくなります。また、運用上のオーバーヘッドや複雑さも軽減され、運用責任の多くをマネージドサービスに委ねることができます。 この記事では、機能的なマルチテナントのサーバーレス SaaS 環境に関してエンドツーエンドで提供するリファレンスソリューションを見ていきます。その目的は、このリファレンスソリューションを作成する際に考慮されたアーキテクチャと設計の検討事項を探ることです。

Read More

Amazon FSx for Windows ファイルサーバーでエンドユーザーアクセスのセキュリティ通知機能を実装する

このブログはJaroslav Skrickij (Sr. Solutions Architect at AWS)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。 AWSでは、セキュリティは最優先事項です。お客様のデータへのエンドユーザーのアクセスを記録することは、多くのお客様の内部セキュリティポリシーやコンプライアンスニーズを満たす上で重要な要素です。エンドユーザーアクセスの監査ログは、定期的なセキュリティ監査やセキュリティインシデントのフォレンジック調査に利用されます。しかしながら、お客様は新たに発生するセキュリティリスクを事前に評価し、悪意のあるユーザーが引き起こす可能性のある被害を軽減するために、不審なアクセスをほぼリアルタイムで知りたいケースもあります。データセキュリティ管理者は、共有ファイルストレージに繰り返し不正アクセスが発生した場合や、大量のファイルが予期せず削除された場合などに、迅速な対応を求められます。

Read More
dena_ivs_blog

DeNA はエンドツーエンドのライブストリーム管理において Amazon IVS をフル活用しています

東京を拠点とするテクノロジー 企業である DeNA (ディー・エヌ・エー) はビジネスを通じて人びとを楽しませ、貢献することを目指しています。その使命は、人びとに想像を超えるDelightを提供することです。日本のライブ ストリーミング市場のパイオニアである DeNA の Pococha ソーシャル ライブ ストリーミング コミュニティはこの使命を実現するもので、ユーザーはインタラクティブでカスタマイズ可能なライブ ビデオを簡単に視聴またはライブストリーミング配信できます。 Amazon Interactive Video Service (IVS) のローンチパートナーである Pococha は、マネージド ライブ ストリーミング ソリューションを活用することで、プラットフォームを意識することなくユーザーにインタラクティブ ビデオ エクスペリエンスを提供できるようになり、その結果スムースに双方向コミュニケーションができる安定した高画質・低遅延配信の提供に開発を集中させることができるようになりました。

Read More
Chime SDK Monitoring and Troubleshooting

Amazon Chime SDK ミーティングイベントでのモニタリングとトラブルシューティング

ミーティングイベントを利用することでAmazon Chime SDKで構築されたオーディオ、ビデオ、および画面共有アプリケーションからクライアントのメトリクスデータを収集できます。さらにミーティングイベントをAmazon CloudWatchと統合することで、重要な情報のスナップショットをAmazon CloudWatchダッシュボードで見ることができます。例えば、ユーザーがミーティングに参加中に障害が発生した場合、ダッシュボードでAmazon Chime SDKのミーティングステータスコードとエラーメッセージの確認ができます。このデータを使用してクライアントログを提供するような追加作業をユーザーに要求することなく、障害の理由を特定することができます。また接続の問題がユーザーの通話品質に影響するかどうかを判断するためのレイテンシーメトリクスもあります。

Read More

【SAP監視もAmazon CloudWatchでOK】SAPアプリケーション&SAP HANAクラスタ

背景 AWS上でSAPを実行している5000以上のアクティブなお客様がおり、ワークロードは多様なSAPのリリースやバージョンで実行されています。ほとんどのお客様は、1台以上のアプリケーションサーバとデータベースで構成されたSAP NetWeaverベースの環境で作業を行っています。アプリケーションとデータベースの高可用性を実現するためのベストプラクティスは、オペレーティングシステムのクラスタリングを活用することです。クラスタリソースの可用性は、アプリケーションとデータベースの復元性を保証します。

Read More

Amazon Connectのスケジュールされた レポートを自動的に送信する

コンタクトセンターではデータが重要です。 スーパーバイザとマネージャは、レポートを使用して、チームのパフォーマンスを確認し、要員配置の計画を立てます。 必要なときに必要なデータを人々に提供することは不可欠です。 このブログ記事では、レポートの生成を有効にしてEメールで自動的にユーザーに送信する方法について説明します。 以下のサービスを使用します。 Amazon S3 AWS Lambda Amazon SES Amazon CloudWatch with Amazon Connect このブログでは、 AWS CloudFormationを使用してデプロイを簡素化する方法についても説明します。 このブログのソリューションでは、 Amazon Connectのネイティブレポート機能を使用してレポートを設定およびスケジュールします。 そのスケジュール設定されたレポートは、Amazon Connectの設定で指定したS3バケットに作成されます。 レポートがS3に作成されると、Lambda関数を起動するイベントが発生します。 Lambda関数はイベントを読み取り、S3からレポートを取得して、指定されたEメールアドレスに送信します。 すべてのアクティビティは追跡目的でCloudWatchに記録されます。 では始めましょう。 このセットアップを完了するには、次のものが必要です。 アクティブなAWSアカウント us-east-1(バージニア北部)またはus-west-2(オレゴン)のいずれかにあるAmazon Connectインスタンス。 Amazon SESはこれらのAmazon Connectリージョンでのみ使用可能であるため、この設定ではこれら2つのリージョンのみがサポートされています。 インスタンスを作成したら、電話番号を取得します。 詳細については、Amazon Connect の使用開始を参照してください。 あなたのアカウントに設定されたAmazon SES。 このソリューションでは、Amazon SESを使用してレポートを指定の受信者にEメールで送信します。 SESを使用してEメールを送信するには、送信元アドレスを確認して、自分が所有者であることを示します。 サンドボックスにいる場合は、 送信先アドレスも確認する必要があります。 あなたは、Eメールアドレスまたはドメイン全体を確認することができます。 検証プロセスについては、Amazon SES のIDの検証を参照してください。 アカウントをサンドボックスから削除する方法については、Amazon SES サンドボックスの外への移動を参照してください。 このCloudFormationテンプレートを実行するための適切なIAM権限。 これには、IAMロールとLambda関数を作成する権限が含まれます。 […]

Read More

Elasticsearch と Kibana を使って Amazon Connect のデータをリアルタイムに活用する

このブログポストでは、Amazon Elasticsearch Service (Amazon ES) と Kibana を使って、どのように Amazon Connect コンタクトセンターでリアルタイムなデータ分析を行うかを紹介します。問い合わせ対応時間やサービスレベル、問い合わせの効率具合、エージェントのパフォーマンス、顧客満足度など、様々なサービス・メトリクスを改善するためにコンタクトセンターのパフォーマンスをモニタリングできます。 加えて、Amazon ES を使って問い合わせ追跡レコード (CTR) 、エージェントのイベント・ストリーム、Amazon CloudWatch で取得できる問い合わせフローログを処理し、Kibana を使ってリアルタイムに近い形で可視化するソリューションも紹介します。Elasticsearch はオープンソースの、分散システムの検索と分析のエンジンで、ログ分析や全文検索に利用されています。Kibana はデータ集約と可視化のツールです。Amazon ES と Kibana を用いて、リアルタイムにデータを検索、可視化、分析、洞察することができます。 Amazon Connect は顧客とのやり取りで発生したイベントの詳細をリアルタイムに問い合わせフローログとして提供します。問い合わせフローとは顧客が問い合わせを行ったときの顧客体験を定義したもので、再生するプロンプトや顧客からの入力、問い合わせキューの転送などを定義します。 さらに、Amazon Connect は 分析用にデータをエクスポートするために CTR を Amazon Kinesis Data Firehose に、エージェントのイベントを Amazon Kinesis Data Streams にストリーミングできます。CTR は Amazon Connect インスタンスで発生するイベントや、属性、キュー、エージェントのやり取りをキャプチャーしたものです。エージェントのイベントは、Amazon Connect インスタンスにて起こる、ログイン、ログアウト、ステータスの変更といったエージェントのアクティビティを記録したものです。 ソリューション概要 以下の図は Amazon Connect からの問い合わせフローログや CTR、エージェントのイベントを処理し、Amazon […]

Read More