障害
稼働しているサービスのEC2インスタンスがまれに503エラーを発生させることがあることがわかっていました。障害といっても複数インスタンスで稼働しているため、一時的に繋がらなくなる程度でした。すぐにユーザーは問題なくサービスにアクセスできるようにはなっていたため、対応の優先度はさほど高くはなかったです。
調査
サービスのログ、EC２インスタンスのCloudWatchメトリクスをいくら確認しても問題が特定できず、AWSサポートに調査の依頼。
I/O クレジットバランスが空になっていた
AWSからの回答としては
事象発生当時、gp2 ボリュームはクレジット枯渇によりベースラインパフォーマンスの 120 IOPS 程度で稼働しておりました。
当方の見解としましては、ターゲットインスタンスのボリュームタイプが性能不足と見られますので gp2 ボリュームのベースラインパフォーマンスが上がるよう今よりもボリュームサイズを増加して頂くとよろしいものと思われました。
といったものでEBSのクレジットが枯渇したため、リクエストを処理できず、503エラーが発生していました。
変更はこちらの公式ドキュメントのリンクを参考にしてもらえれば簡単に行えました。
AWSコンソールから簡単に変更できます。ダウンタイムも発生しなかったのでサービスにも影響は与えることはほとんどないと思います。
ただ一旦上げると下げられなくなるため、この点は注意が必要です。
EBSのボリュームの種類、性能についてはこちらの公式ドキュメントが参考になります。
EC2のtシリーズにあるクレジットは注意を払っていましたが、EBSに関しては全くわかっておらず、今回の事象が発生しました。
今後は監視対象に加えたいと思います。