AWSの障害はメモリリークのバグに原因、Amazonが報告書公表：DNSの変更が引き金に

[鈴木聖子，＠IT]

　米Amazon Web Services（AWS）チームは、米東リージョンで10月22日に発生した障害の原因や対応についてまとめた報告書を公表した。DNSの変更が引き金となってメモリリークのバグが誘発され、障害につながったと報告している。

　AWSの障害は現地時間の22日午前10時ごろ発生し、米東リージョンにあるAmazon Elastic Block Store（EBS）の一部でパフォーマンスが低下し、I/Oリクエストが処理できないなどのスタック状態に陥った。根本の原因は、EBSストレージサーバで実行していた情報収集エージェントに潜在するバグにあったという。

　この前の週に、情報収集サーバの1つでハードウェアに不具合が生じたため入れ替えを行い、この入れ替えに伴ってDNS記録を更新、障害の起きたサーバを削除して、入れ替えたサーバを追加した。ところがこの更新が社内の全DNSサーバに行き渡らず、結果として、一部のストレージサーバが交換前の情報収集サーバに接続を試み続けた。

　これが引き金となって、ストレージサーバ上のエージェントに潜在していたメモリリークのバグを誘発。同エージェントがサーバに接続を試み続けたことから、システムメモリが徐々に消費され、22日午前までにストレージサーバが通常のリクエスト処理に対応できない状態になった。

　EBSサーバの多くはメモリプレッシャーが原因で顧客のリクエストを処理できなくなり、スタックするボリュームの数が急増。フェイルオーバーを試みたが、多くのサーバが同時にメモリを使い果たした状態になっていて、フェイルオーバー用のサーバを確保できず、同日午前11時までに、この地域のボリュームの大多数がスタック状態に陥った。

　AWSチームは同11時10分ごろから調整に着手し、同11時35分ごろにシステムが自動復旧を開始、午後1時40分までには影響を受けたボリュームの約60％が復旧した。

　3時過ぎには原因を突き止めて残るボリュームを復旧させ、4時15分までにほぼすべてのボリュームの復旧を完了、パフォーマンスも正常に戻った。

　今回障害の影響は、EC2とEBS APIのほか、Amazon Relational Database Service（RDS）やElastic Load Balancing (ELB) にも及んだという。

　AWSチームは再発防止策として、EBSサーバでこの種のメモリリークがあった場合は警告が出る仕組みを導入し、メモリリーク問題の修正にも間もなく着手する予定だという。さらに、EBSストレージサーバのメモリ消費を監視するシステムの強化、DNS設定の変更を確実に反映させる措置の導入、EBSフェイルオーバーロジックの見直しなどを行っている。こうした対策により、今後同様の問題が起きた場合でも、影響を食い止められるはずだとしている。