概要

  • こんにちわ。2023/7/11 (火) に、JAWS-UG 名古屋にLT枠で参加しました。7月のJAWS-UG 名古屋は、『オブザーバビリティ for AWS』をテーマに開催されました。
  • 会場は、コラボベース NAGOYA。とてもオシャレな会場で、この回は多くのエンジニアの方々が参加。私も「CloudWatchカスタムメトリクスをトリガにスケールするEC2 ASGのタイトルにて、実際に業務で経験したオブザーバビリティの実例をお話しました。

JAWS-UG 名古屋 オブザーバビリティ for AWS

 

 

LT の概要

オブザーバビリティとは

  • オブザーバビリティ（Observability）→ 可観測性と訳される。
  • モニタリングとオブザーバビリティは、意味が異なる。モニタリングは、「何が起きているか」を見ること。
  • オブザーバビリティは、「何が障害の原因だったのか」、「どこに影響があるのか」「どう対処すれば良いのか」を把握すること。

私が遭遇した実例

  • とあるEC2 Auto Scaling構成の httpサーバー(Apache)がある。定期的に、一部インスタンスでElastic Load Balancing のヘルスチェックのunhealthy が起こるようになった。
  • 特定のインスタンスではなく、事象発生時に複数台で起き始める。
  • メトリクス,ログから原因不明　→　なぜか時間の経過でunhealthyは解消される。

原因と対処

  • unhealthy のインスタンスがヘルスチェック失敗で削除される前に、インスタンスOS に乗り込んで調査。
  • ApacheのWorkers にはIdleは見受けられず、スレッドは使い切っていることが予測された(httpサーバーが処理しきれない状態だった)。
  • 高負荷の時間帯(アクセスが多い時間帯)では性能不足あり、性能改善が必要と認識。改善策はいくつかある。並行して改善は進めるが、インスタンスの台数を増やす必要ありと判断した。
    • Apacheの同時接続数(MaxRequestWorkers)の変更
    • ApacheのKeepAliveTimeout値の見直し
    • インスタンスの台数増やす
      • →　単純に増やすとコスト増
    • EC2 AutoScaling ポリシーを使いたい
      • →　だけど台数増やすタイミングが不明(LoadBalancerにぴったりなメトリクスはなし)

伝えたいポイント

  • 今回の実例は、CloudWatchメトリクスだけでは「なんかおこった！」しか見えてこない。unhealthy のメトリクスをトリガにEC2 にログインしたり、Linuxコマンドを叩く必要があった。調べるインスタンスは何台もあり、調査には時間を必要とする。
    • 標準のメトリクスだけでは、このシステムで本当に起きていること(root cause)が、見えない！
  • 調査の結果、原因と対処は分かった。
    • だけど、unhealthy が起きてから運用が手作業でスケールアウトなんて無理だ。人力の監視と対処を何とかしたい！
  • httpのプロセス数をにらめっこしていたら、これ使うと事前に対処出来そう。
    • だけど、CloudWatch にプロセス数を見るメトリクスはない？　プロセス数を可視化したい！
  • CloudWatch Agent の設定によってプロセス数のカスタムメトリクスが導入できるぞ。
    • 待てよ？　プロセス数をしきい値にインスタンスを1台ずつ増やしたいのに、AutoScalingGroup に所属するインスタンスの台数分、スケールアウトが発動しちゃうかも！？　AutoScalingGroupでメトリクスをまとめることはできないのか？

 

LT のスライド

  • どうやったらプロセス数をAutoScalingGroup単位で可視化できるか、そしてAutoScaling ポリシーにスケールアウトを組み込めるかを検証。その結果を解説しました。
  • 詳細は、以下のスライドを参照。

JAWSUG_Nagoya_202307

 

  • 以下は、LT の様子です。