Network Load Balancerでアイドルタイムアウト値の設定が可能に！
AWS Network Load Balancerにおいて、アイドルタイムアウト値の設定が可能になりました。
HTTP以外のプロトコルでの通信の負荷分散ができるNetwork Load Balancerは、これまではアイドルタイムアウト時間（無通信時にTCPコネクションをリセットせずに保持する時間）が350秒固定でした。そのため、サーバ側で長時間処理がかかるようなケースに、サーバ側では処理が成功しているのにもかかわらず、処理が失敗したように見える事象が発生することもありました。
今回のアップデートによりアイドルタイムアウト値を60秒～6000秒に変更が可能になり、そうした長時間処理でもタイムアウトを発生させることなくリクエストを返答することができるようになりました。このアップデート以前では、TCPキープアライブを有効にすることでこうした長時間の処理でアイドルタイムアウトを発生させない方法も紹介されていましたが、本アップデートにより、こうした処理を行わずとも対処が可能になるかと思います。サーバ側の処理が長時間かかっている場合は、根本的にはその処理自体を見直ししたほうが良いとは思いますが、すぐには対処できないケースもあり、そうした際に役に立つのではないでしょうか。ちなみにほぼ同時期にGateway Load Balancerというアプライアンス製品（FWやIDS/IPSなど）と連携させるときに利用するLoad Balancerでも同じようにアイドルタイムアウトの設定ができるアップデートも発表され、アイドルタイムアウト周りで発生した問題を解決しやすくなったのではないかと考えています。
Cloudwatchでアプリの複雑なSLOの計測が簡単に！
CloudWatchにおいて、複雑なサービスレベル目標（SLO）の設定が容易にできるようになりました。
モダンなWebシステムではユーザ視点でのシステムの健全性を把握するために、Google社が提唱しているゴールデンシグナル（Latency、Traffic、Errors、Saturation）などの指標を用いたSLO（Service Level Objective）を定めているケースも徐々に増えてきているかと思います。このアップデート以前でも例えば「レスポンスが200ms未満のものが、全リクエストのうち99％を満たしていることをSLOとする」というような条件をCloudwatchで数式等を使い定義することは可能だったのですが、かなり複雑な設定となり、ハードルが高い場合が多かったと思います。このアップデートにより、簡単に一般的な指標に基づくSLO監視を実現することができるようになりました。
ただし、この機能のベースとなっているApplication Signalsのセットアップは若干手間がかかります。例えばECSの場合では、監視対象のサービスコンテナに加えて、Cloudwatchエージェントが動作するサイドカーコンテナ、OpenTelemetryデータをCloudwatchに送るエージェントのコピーを担当するinitコンテナの2つが必要になります。ドキュメントに明記はないですが、initコンテナによる処理を行う前に監視対象のサービスが起動すると、正しく計測できないことも起きうるため、コンテナの依存関係を利用し、initコンテナによるコピー完了（SUCCESS状態）後に、監視対象のサービスコンテナが起動するように設定していただければと思います。
まとめ
今回は、アプリケーションリリース前後で発生しがちな悩みを解決してくれるアップデートを紹介しました。各アップデートは大きく目立つものではありませんが、アプリケーション開発時に有効に活用できるようになるアップデートかと思っています。本記事が今後のAWS活用のお役に立てば幸いです。
