Amazon Web Services ブログ

Category: Amazon CloudWatch

新しい Amazon EventBridge のログ記録を使用して、イベントドリブンのアプリケーションをモニタリングおよびデバッグする

7 月 15 日より、Amazon EventBridge の拡張ログ記録機能を使用して、包括的なログでイベン […]

通信事業者が提供するSmart-Xのための協調AIエージェントによる分散推論

本稿は、2025年3月20日に AWS for industriesで公開された “Distributed i […]

AWS Summit Japan 2025 に Chaos Kitty が更にパワーアップして 3 回目の登場！

　みなさんこんにちは！ どちらかというと猫より犬が好きな Solutions Architect の高野です。 […]

寄稿：製鉄業のデジタル革新 – JFE 条鋼株式会社が挑む AWS による基盤刷新への道

JFE 条鋼株式会社は AWS 移行を通じて製鉄業のデジタル革新に挑戦しています。システム基盤の近代化とデータ活用基盤の整備により、リアルタイムでのデータ分析や業務プロセスの効率化を実現しました。この取り組みは、同社の持続可能な成長への重要な一歩となっております。

AWS Weekly Roundup: Amazon Nova Premier、Amazon Q Developer、Amazon Q CLI、Amazon CloudFront、AWS Outposts など (2025 年 5 月 5 日)

4 月 28 日週、私は AWS Summit Bangkok に参加するためにタイに行きました。活気に満ちた […]

AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止

可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。

アプリケーションは、トラフィックへの応答 (または作業の実行) を停止し、ログ集約サーバーが復旧するのを待つべきでしょうか? (正確な監査ログがサービスの可用性よりも優先されますか?)
アプリケーションは、ログサーバーがバッファを使い切る前に復旧することを期待してログをバッファリングしながらトラフィックに対応し続けるべきでしょうか? ログ送信先が利用できないレアケースにおいてログが失われるリスクを受け入れるべきでしょうか?

コンテナのログドライバーでは、このトレードオフは上記 1 の考慮事項に対して「ブロッキング」の設定パラメータ、2 の考慮事項に対して「ノンブロッキング」の設定パラメータで実装されています。AWS ブログの「Choosing container logging options to avoid backpressure」では、Rob Charlton がこのトレードオフを探求し、AWSLogs コンテナログドライバーのデフォルトの「ブロッキング」モードでアプリケーションがどのように動作するかをテストする方法を説明しています。

この記事では、「ノンブロッキング」 について詳しく説明し、AWSLogs ログドライバーを使用したログ損失の試験結果を示します。

← Older posts