はじめに
EFSをEC2等でマウントして利用している際、EFS側のシステムトラブルや、何らかの原因でEFSが利用できないことがあったら検知したいなぁと思い、方式を検討しました。
そもそもEFSのモニタリングは？
EFS標準で提供されているメトリクスは上記のとおりです。
この中でEFSが利用できているのだろうか？というところを確認する方法として１つ考えられるのがClientConnectionsの数をモニタリングすることです。
しかしこの方法には１つ問題があります。
通常このような形で、EC2などからAZ毎にマウントポイントに接続する構成です。
仮にClientConnectionをモニタリングする場合、正常にマウントできている状態のクライアント数をCloudWatch Alarmの閾値にするわけですが、AutoScalingなどにより、台数が上限する場合、特定のインスタンスで問題が発生しているかは特定することができません。仮に閾値を２にしていた場合、３台目がデプロイされ、３台目がマウントされていなくてもアラームは発砲されません。
解決策
解決策として考えうるものは以下２つです。
案１：マウント状態のモニタリングではなく、アプリケーション側からエラー検知を行う
これは、アプリケーション側で、EFSへの書き込み、読み込みができない場合、エラーログを生成してもらう方法です。そもそも、ファイルの読み書きができない場合、アプリケーション側で通常何らかのエラーが出力される気がしますが、EFSの読み書きということでエラーが出ていることはログ上特定できるようにしたほうがよいでしょう。
案２：EFSのファイルパスをWEBアプリで公開している場合、該当のURLをELBからヘルスチェック対象のパスとする
これは、Apache等でWEB公開している場合、EFSのマウントが前提となっているURLをELBのヘルスチェック対象としてしまう方法です。こちらの方法では、何らかの異常があった場合、インスタンスの切り離しも可能ですし、大きな実装もありません。とはいえ、そもそもEFSの利用用途がウェブ公開でない場合には向きません。
案３：独自のスクリプトでカスタムメトリクスを作成する
これは実装が手間ですが、Cron等でスクリプトを実行、読み書きができるかをチェックし、結果をカスタムメトリクスとして、記録する方法です。カスタマイズ性や、柔軟な作り込みに対応可能です。
メリデメ
| 案 | メリット | デメリット |
|---|---|---|
| アプリケーション側でエラーログ生成 | アプリケーション側のエラーログとまとめることが可能 | アプリケーション側のカスタマイズ、実装が必要 |
| EFSのファイルパスの一部をWEB公開しALBからヘルスチェック | 比較的簡単に実装できる、ウェブ公開するアプリケーションであった場合インスタンスの切り替えも自動化できる | ウェブアプリでない場合や、EFSのファイルパスを公開したくない場合利用できない |
| 独自のスクリプトでカスタムメトリクスを生成 | 指定した感覚で確実に読み書き可能かチェックできる、アプリケーションのカスタマイズは不要 | スクリプトの実装が必要 |
スクリプト概要
スクリプトの概要です。
※メトリクスに書き込めなかった際などのエラー処理を除く
1.EFSのマウントパスにファイルを書き込む
2.書き込みができなかった場合、CloudWatchメトリクスに１を書き込む、書き込みができた場合、CloudWatchメトリクスに０を書き込む
3.事前に設置してあるファイルを読み込む
4.読み込みができなかった場合、CloudWatchメトリクスに１を書き込む、読み込みができた場合、CloudWatchメトリクスに０を書き込む
このようなスクリプトを定期実行し、メトリクスに出力、アラーム側では、複数台のインスタンスからメトリクスが出力されるため、１台でも１を超えた場合アラーム発砲できるようにルール設定します。
まとめ
できうる限り作り込みはしたくないのですが、EFSに関しては慎重に見極めが必要です。
スクリプト以外の手段もあるので、最適なものを選択しましょう。