想定するAWSの構成について

この記事で想定するAWSの構成図はこちらです。

※Route 53やWAFなどは表記しない簡易的な図になります。

このシステムはWeb上で動作するシステムであり、ALB、EC2、Aurora（DB）で構成されます。
EC2とAuroraは冗長性のため2台あり、Auroraの一方はリーダーインスタンスとして運用しているものとします。

異常①：ALBのヘルスチェック失敗について

ALB（Application Load Balancer）はその名の通り、負荷分散を行うサービスです。今回の構成の場合はユーザーからのアクセスによる負荷を適切にそれぞれのEC2インスタンスに振り分けています。
この時、ALBはヘルスチェックでEC2インスタンスの状態を常に監視し、適切に振り分けを行っています。ヘルスチェックを行うことでEC2インスタンスが問題なく動いているかを確認してくれているため異常がある場合、つまりヘルスチェックが失敗した場合にはそのEC2インスタンスへの通信を止めて他のEC2インスタンスへ振り分けてくれます。

ヘルスチェックが失敗する原因

では、ヘルスチェックはどのようなときに失敗するのでしょうか。
EC2に異常が発生しているといっても様々なことが考えられます。システムのバグにより処理が停止してしまったり、ハードウェアの故障なども考えられます。
私がよく直面したものはアプリケーションのデプロイによるものでした。

システムを開発している方が修正あるいは機能を追加したものをEC2にデプロイするとき、EC2はシステムを一時的に停止させざるを得ません（それはそうですよね笑）。
そのため、デプロイ中はユーザーから来た処理を渡しても正しく結果を返してくれないのでもう一方のEC2インスタンスに案内します。
デプロイが終わればEC2は新しいシステムで再稼働されるのでヘルスチェックは成功します。

ヘルスチェック失敗時の原因の確認と対応

ヘルスチェックが失敗する理由は分かりました。しかし、その確認などはどのように行えばいいのでしょうか。
私が経験したシステムではCodePipelineというものを利用してビルドやデプロイを管理していました。デプロイの履歴はCodeDeployのDeploymentsにあり、そこでいつ、何に対して、どのようにデプロイが行われたのかが分かります。
デプロイとヘルスチェック失敗の、対象インスタンスと時刻が一致すればデプロイによってヘルスチェックが失敗したのだろうということが分かります。
これで一安心ですね。ひとまずEC2が壊れて再起不能になっていた訳ではなさそうです。

しかし、このデプロイは正常なのでしょうか。
もし意図せず実行されてしまったデプロイだった場合、デプロイの方式やロードバランサの設定によっては、対象EC2インスタンスと通信中だったユーザーに対して、瞬間的な通信エラーが発生する可能性があります。また、他のEC2インスタンスに負荷が偏るため、今回の想定だと1つのEC2インスタンスへの負荷が倍増してしまいます。
そのため、実行されたデプロイは想定されたものか確認する必要があります。
なので私は開発側の方に欠かさず確認するようにしています。
万が一を見逃すことが一番怖いですからね。

異常②：Auroraのメトリクスが途切れる

もう一つの異常はAuroraの状態をモニタリングしているメトリクスが途切れてしまうことです。
Auroraはデータベースのため、特にクエリが実行されていなくても常に稼働はしています。そのためCPU使用率などといったAuroraのメトリクスは基本的に途切れません。
しかし、そんなAuroraですが、一部のメトリクスが同じ時刻に途切れていました。
例としてCPU使用率を挙げますが、その時見たグラフはこの模式図のようになっていました。

メトリクスが途切れたかと思ったら急にCPU使用率が上昇し、すぐに元に戻っていました。最初はすごく戸惑いましたね。急な負荷上昇によってメトリクスが跳ねることはありますが、途切れてしまうことは無かったので負荷がかかりすぎてAuroraが落ちたのかと思いました。

しかしCPU使用率は0%に下降したりはせず、何事もなかったかのように正常値に戻っています。
この原因は何だったのでしょうか。

Auroraのメトリクスが途切れた原因

残念ながらこの原因は自分の力では特定することができませんでした。
有料のAWSのサポートプランに加入していたためサポートに問い合わせて原因を確認してもらいました。

結果はAWS側のメンテナンスが原因とのことでした。
何とも腑に落ちないところですが、クラウドサービスを利用している以上避けられないことなので納得しました。

Auroraのメトリクスが途切れた原因の確認と対応

原因は分かりましたが、不定期に行われては困ります。こちらでメンテナンスをしたのだろうと判断できるものがないと毎回サポートに聞くことになってしまいます。
そこで、Auroraの各DBインスタンスのメンテナンス時間を確認します。
AWSのコンソール画面に入れる方は一度見ていただきたいのですが、Aurora and RDSのページからDBインスタンスのメンテナンス時間を確認してみてください。

そこにメンテナンスウィンドウの時間があると思います。この時間内にメンテナンスが行われるため、メトリクスが途切れてしまった時間とこのメンテナンスウィンドウの時間が一致していればAWS側のメンテナンスが原因である可能性があります。
しかしそれだけで断定はできないため、私はその他AuroraのメトリクスやALB、EC2のメトリクスでも異常がないこと、Auroraに何かイベントが発生していないかなどを確認し、サービスに影響がなく、他に原因がない場合にメンテナンスウィンドウによるものだと結論付けるようにしています。

まとめ

いかがでしたでしょうか。本記事では私が直面したよくある運用監視上の異常を2つ紹介させていただきました。
デプロイによるALBのヘルスチェックの失敗やAWS側の事情によるAuroraのメトリクスが途切れるということは、言われてみれば当たり前のことだと思います。
しかし、それが原因であることを特定する具体的なステップを確立することは大切です。慣れて原因の特定を怠ると万が一を見逃しかねないので、今後も意識していきたいと思います。

この記事がAWSや運用保守の初心者の方など読んでくださった方々のお役に立てれば幸いです。

テコテックの採用活動について

テコテックでは新卒採用、中途採用共に積極的に募集をしています。
採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。
ご興味を持っていただけましたら是非ご覧ください。 tecotec.co.jp

テコテック開発者ブログ

【AWS】未経験エンジニアが直面した「運用監視の異常」とその対応フロー