AWSのサービスを使う場合はバーストを必ず意識する

バーストとは

 AWSの一部のサービスで採用されている、割り当てられているパワー(CPUやIOなど)を一時的に超えた性能を出せる機能で、EC2ではT系インスタンスのCPUにこれが採用されています。

 しかし、割り当てられているパワーを超えた性能を永遠に出すわけにもいきませんから、それを制限するBurst Balance(バーストクレジット)という値が予め割り当てられ、これを消費して規定を超えた性能を利用しているというわけです。

 Burst Balanceは、割り当てられている性能を超えないような利用を続けていれば回復するものなのですが、回復の仕方や上限などはインスタンスタイプやサービスによって異なるので、詳しくはAWSの公式サイトをご覧ください。

クレジットが無くなると何が起こる?

 クレジットが枯渇する状況になると、性能が著しく制限され、503エラーを返すようになったり、処理に異常な時間が掛かるようになります。本番環境であれば、障害に近いことが起こります。

 これを防ぐためには、そもそも本番環境でそういったインスタンスタイプを使わないようにすることが重要です。t系インスタンスは、コストは安いですが恒常的に負荷がかかるような利用には向いていません。突然利用者が増加したが、すぐに収束する、というようなケースでない場合は、上述したようなリスクがあります。少し高いお金を払ってでも、安定した性能を出し続けてくれるインスタンスタイプが好ましいです。もしそのコストも払えない、という場合は、Lightsailなどの安価なサービスもあります。

 可能であれば、development用の環境やstaging環境も同様にバーストが無いインスタンスタイプを選択することを推奨します。開発時やテスト時にクレジットの枯渇に遭遇すると、無用な調査コストを払わなくてはならなくなります。あるいは、こういった問題が生じることを念頭に置いておくことが重要です。

RDSの怖い話

 CPUやメモリなどはスケールアップ可能ですし、ストレージも容量をアップすることができるRDSにも落とし穴があります。

汎用SSDボリュームに存在するIOPSバースト

 盲点となりがちなのは、ストレージとして利用する「汎用SSD」にもIOPSバーストが存在するということです。

 RDBMSは、多くの情報をメモリに持つことで高速な返答を返しているので、IOPSが問題になる状況はあまりありません。しかし、これを意識しないと、順調に利用者が増加していった結果、突然大規模な障害を起こすことになります。

 参考: Amazon RDS DB インスタンスストレージ

 RDSは、CPU、メモリといった性能は利用者数に応じてインスタンスタイプで調整しますし、監視項目として必ず意識するものなのですが、ストレージは容量のみを意識しがちなので、RDSをメインDBとして利用している方は、必ずバーストクレジットを監視項目として入れ、アラートを設定することが重要です。

RDSDBストレージのIOPSの上げ方

 IOPSは、容量に従って性能が上がり、2020年1月現在、容量を1TBに増やすことで3,000IOPSの性能を常時出せるようになります。バーストの上限も3,000IOPSですから、実質、バーストクレジットの制限を意識せず利用することができます。これ以上の性能が必要であれば、5,334GB(5.3TB)まで増やすことで16,000IOPS、さらにプロビジョンドIOPSストレージを利用することで最大64,000IOPS〜80,000IOPSまで上げることができます。但し、まあまあ高額なコストがかかりますから、十分に検討することが重要です。

チューニングする

 IOPSは、ディスクアクセスが発生したときに起こります。RDSのキャッシュヒット率を高めたり、アプリケーション側でキャッシュ機構を利用したりすることで、ディスクアクセスを減らすことができます。

まとめ

 このように意識しないと盲点となってしまうものもありますが、AWSは事前にマニュアルさえ読めば回避できることも多いので、まずはマニュアルを読むこと、あるいは、バーストという概念をしっかり認識することが重要です。できるだけ障害が発生しないインフラを構築しましょう!