Amazon CloudWatch でクライアント側のメトリクスデータの集約が可能に
Amazon CloudWatch でクライアント側のメトリクスデータを集約して、単一の PutMetricData API コールでパブリッシュできるようになりました。これにより、大量のメトリクスデータを効率よくインジェストしながら、API コール数が減ることでコストを削減することもできます。 メトリクスデータは、値とカウント数による配列のヒストグラム形式でパブリッシュすることも、CloudWatch エージェントを活用してパブリッシュすることもできます。CloudWatch では、集約データからパーセンタイルの統計が自動作成されます。この統計により異常が可視化されるため、外れ値を除外してアラームのノイズを低減できます。 CloudWatch の PutMetricData の使用を開始するには、AWS SDK または AWS コマンドラインインターフェイス (CLI) を使用できます。
Amazon CloudWatch Agent adds Custom Metrics Support
Amazon CloudWatch エージェントでカスタムの StatsD メトリクスまたは collectd メトリクスを CloudWatch にパブリッシュできるようになりました。これらのカスタムメトリクスを活用して、通知のトリガーや Auto Scaling のアクションを実行するアラームを作成できます。また、これらのメトリクスをダッシュボードに保存して CloudWatch で簡単に確認することもできます。 StatsD と collectd は、幅広いアプリケーションで利用可能なシステムの統計情報を収集する、人気の高いオープンソースソリューションです。CloudWatch エージェントを使用すると、カスタムの StatsD メトリクスと collectd メトリクスを CloudWatch で最大 15 か月間パブリッシュおよび保存できます。また、エージェントによってメトリクス
Amazon API Gateway で複数の値を持つパラメータのサポートを追加
本日より、Amazon API Gateway で、API リクエスト内で同じ名前を持つ複数のヘッダーおよびクエリ文字列パラメータのサポートがはじまります。 Amazon API Gateway によって、API を大規模に素早く作成、パブリッシュ、管理、モニタリングできるようになります。API の呼び出しの際、ヘッダーとクエリ文字列の同じキーに複数の値をわたすことができるようになります。さらにこの機能では、複数の Set-Cookie ヘッダーを送るなど、API レスポンス内の同じ名前の複数のヘッダーの戻り値もサポートされます。 この機能は、API Gateway がご利用いただける全リージョンで利用可能です。API Gateway が利用可能なすべてのリージョンについては、AWS リージョンの表を参照してください。 この機能の詳細については、こちらのドキュメントを参照してください。 A
コンテナジャーニー〜AWSにおける段階式コンテナ運用〜 - Speaker Deck
このセッションでは、コンテナを本番環境に導入して動かすまでの注意点や考慮すべき項目を、段階的にお伝えします。日進月歩で進化を続けるAmazon Container Services界隈に「一歩を踏み出していただくためのきっかけ」をつかんでいただければ幸いです。 Amazon ECSがリリースされてから、早4年。Docker自体の進歩が目覚ましく、周辺のオーケストレーションツールや関連するOSSなども目を見張るような勢いで進化しています。以前は開発環境での利用が主流だったコンテナも、今では本番環境での採用事例も増えてきました。さらに、Fargateの東京リージョンリリースやEKSの一般公開など、話題には事欠きません。 アプリケーションのコンテナ化には様々な面で大きなメリットがありますが、それを実際に本番環境に導入するには従来のアプリケーションの考え方とは違う部分もあり、簡単にはいかないことも
Go × Clean Architectureのサンプル実装 - 爆速でGo！
Click here for English version ＊追記：Student Goで発表しました。 speakerdeck.com クリーンアーキテクチャとは 以下を実現することで、関心の分離をするアーキテクチャパターンです。 ドメインロジックを独立させる フレームワークを独立させる UIを独立させる DB含む外部の全てを独立させる ドメインロジックをテストしやすくする 詳しくは様々な記事で説明されているので、今エントリでは割愛し実装パターンに絞って紹介します。 Clean Coder Blog 持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP - Qiita サンプルアプリケーション ↓サンプルコード github.com 仕様は、/users にPOSTすることでユーザー登録するだけのapiです。 基本はma
GAE スタンダード環境で scikit-learn を使う – google-cloud-jp – Medium
Google Cloud Next ’18 in San Francisco にて、Google App Engine スタンダード環境の Python 3.7 対応がアナウンスされました。Pythonista の方々には朗報ですが、実はそれ以外にも大きな変更がありました。 C で書かれたライブラリの使用が可能に今までの GAE スタンダード環境 Python ランタイムでは、ライブラリはホワイトリスト化された特定のビルトインのものか、Pure Python のものという制限がありました。これは従来のランタイムで使用されていたアイソレーション環境では、システムの安全性を保証できなかったからです。一方、今回Python 3.7 が動作する第２世代ランタイムでは、gVisor をベースとしたアイソレーション環境により安全性が担保できるため、内部的にCで書かれた Pythonライブラリもロードし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS固有のセキュリティリスクと対策 - Speaker Deck
IOpipe | Function Faster | AWS Lambda Monitoring + Observability