バーストパフォーマンス(T系)インスタンスの特徴を理解して上手に利用しよう

はじめまして、こんにちは。2020年4月にStartup Solutions Architectに着任しました、齋藤(Twitter: @koemu)です。

スタートアップ企業にお勤めのみなさま。AWSのサービスを利用される際に、インスタンスタイプはどのような基準で選択されていらっしゃいますでしょうか。その時に考慮の変数の一つとして価格を組み入れられているお客様は多数いらっしゃることと想像します。例えば、T2、T3およびT3aなどの比較的廉価なバーストパフォーマンスインスタンス(以下、T系インスタンスとします) 、Amazon EC2であればt3.mediamなどをご選択されるスタートアップ企業の方を見受けます。

さて、T系インスタンスには、性能面での他のインスタンスタイプにはない特徴があります。その特徴をこのブログでお伝えし、現状を今一度見直していただけたらと考えております。私がスタートアップ企業のお客様からよくご質問のあるサービスを中心に取り上げ、ご案内します。

※本記事は、2020年9月3日現在の情報をもとに執筆しています。最新の情報は、AWSの公式ドキュメントをご確認ください。

もくじ

• T系インスタンス利用時の注意点
• CPUクレジット
• 2つのCPUクレジットの消費タイプ
• その他の違いについて
• サービスごとの考慮点
• Amazon EC2, Amazon ECS
• Amazon Lightsail
• Amazon RDS, Amazon Aurora
• Amazon Elasticsearch Service
• Amazon Document DB
• ではどうすればいいのか
• まとめ

T系インスタンス利用時の注意点

CPUクレジット

「CPU クレジット」。この言葉を聞いたことはございますでしょうか。例えば、Amazon EC2でT系インスタンスを使用しようとした場合、他のインスタンスタイプとは違い、ベースラインと呼ばれるあらかじめ決められたCPU使用率が定義されています。その上で、ベースラインを超えたCPU使用率が使用できる状況をバースト機能と呼びます。そのバースト機能を使用している時に使われるのが、CPUクレジットです。

もし、Amazon EC2でT系インスタンスを利用されていて、AWS Management Consoleにアクセスできる方は、そのインスタンスの「モニタリング」の欄をご覧ください。

上記のグラフは、ほとんどアイドル状態で稼働しているAmazon EC2インスタンスの例です。おそらく、「モニタリング」欄の下部に、「CPUクレジット使用状況」と「CPUクレジット残高」が表示されているはずです。この「CPUクレジット残高」が0になると、後述するCPUクレジットの消費タイプにより、ベースライン以下の性能しか出なくなるか、追加の課金が発生します。

CPUクレジットの計算式は、AWSの公式ドキュメント「バーストパフォーマンスインスタンス」にあります。詳しく知りたい方は、ぜひご覧ください。

2つのCPUクレジットの消費タイプ

クレジットの消費タイプとして「Standard」と「Unlimited」の2種類のモードがあります。

• Standard Mode(スタンダードモード): CPUクレジット残高が0になると、CPU使用率はベースライン使用率以下までのみ使用できます。CPUがアイドル状態になると、CPUクレジットの残高が回復します。
• Unlimited Mode(無制限モード): 長時間にわたって高い CPU 使用率でインスタンスを実行する場合には、CPUクレジットが0になった後は、vCPU 時間ごとに均一追加料金が発生します。計算機にかかる負荷によっては、他のインスタンスタイプの利用料金を超える可能性があります。

その他の違いについて

それ以外にも他のインスタンスタイプにはない考慮すべき仕様があります。サービスごとに違いがあるため、後述します。

サービスごとの考慮点

Amazon EC2, Amazon ECS

まず、Amazon EC2、Amazon ECS(EC2起動タイプ)といった仮想コンピューティングサービスですと、T系インスタンスではどのような特徴があるのでしょうか。
CPUクレジットは、1時間ごとに積算され、蓄積できる最大のクレジット残高があります。これはインスタンスタイプによって違いがあります。例えば、t3.smallでは24クレジット/時間蓄積でき、最大は576、ベースライン使用率は20%です。

実際にt3a.smallのインスタンスで、1プロセスが無限ループするコードを書いて、9:00から1vCPUが使用率100%になった状況が以下の図の通りです。CPUクレジットが消費され、CPUクレジット残高が図ではわずかな形ですが消費されていくのを観察できます。

クレジットの消費タイプは、Standard Modeと、Unlimited Modeが選択できます。Amazon EC2の場合、T2のデフォルトはStandard Mode、T3のデフォルトはUnlimited Modeです。

Amazon Lightsail

Amazon Lightsailの仮想サーバは、バーストパフォーマンスインスタンスとして動作します。クレジット消費タイプは、Standard Mode相当に固定されています。

詳しくは、AWSの公式ドキュメント「Amazon Lightsail でのインスタンスメトリクスの表示」をご覧ください。

Amazon RDS, Amazon Aurora

Amazon RDS、Amazon AuroraのT系インスタンスにも、CPUクレジットがあります。また、Amazon Aurora MySQLには、CPUクレジットに加えて、DBへの接続数の上限の違いがあります。

まず、CPUクレジットの計算方法は、基本はAmazon EC2と同じです。db.t2.*だとStandard Modeに相当する制限があり、CPUクレジットが0になるとベースライン以下のCPU使用率に制限されます。db.t3.*ですと、Unlimited Modeに相当する動きとなり、CPUクレジットが0になると追加の課金が発生します。モードの説明は「T系インスタンス利用時の注意点」の項をご覧ください。

また、Amazon Aurora MySQLへの接続数の上限があります。私が相談を承る範囲ですが、T系インスタンスを利用して問題になりやすいのがこちらです。例えば、db.r5.largeですとデフォルトで1,000が上限ですが、db.t3.smallですとデフォルトで45が上限です。45は、アプリケーションサーバが数台程度しか動いていない場合でも、あっという間に接続数を使い果たす可能性がある数です。 max_connections パラメータを引き上げることも不可能ではありませんが、この値は当初よりインスタンスサイズに合わせた値が設定されており、引き上げた場合に正しく動作しない可能性があります。

AWSの公式ドキュメント「Amazon Aurora MySQL のパフォーマンスとスケーリングの管理」でも、以下の通りの説明があります。

T2 インスタンス、および T3 インスタンスの接続制限がかなり低いのは、Aurora では、これらのインスタンスが本番稼働のワークロードのためではなく、開発やテストシナリオのみを目的としているためです。

上記より、アプリケーションサーバをオートスケールできるよう構成されたとしても、Amazon Aurora MySQLがT系インスタンスのままですと、データベースサーバの接続上限を超えてしまい、サービスが正しく運用できなくなる可能性があります。

詳しくは、AWSのサービス紹介「Amazon RDS インスタンスタイプ」、およびAmazon Aurora MySQLの公式ドキュメント「DB インスタンスクラス」をご覧ください。

Amazon Elasticsearch Service

Amazon Elasticsearch ServiceのT系インスタンスでは、AWSの公式ドキュメント「サポートされるインスタンスタイプ 」によると、以下の制限があると述べられています。特に、データの暗号化はサポートされていないため、センシティブな情報の保存を予定している際には注意が必要です。

T2 インスタンスタイプは、ドメインのインスタンス数が 10 以下の場合のみ使用できます。
t2.micro.elasticsearch インスタンスタイプは、Elasticsearch 1.5 および 2.3 のみをサポートします。
T2 インスタンスタイプでは、保管時のデータの暗号化、きめ細かなアクセス制御、UltraWarm ストレージ、クラスター間検索がサポートされません。
t2.small インスタンスタイプと t2.micro とインスタンスタイプでは、異常検出がサポートされません。

Amazon DocumentDB

Amazon DocumentDBのT系インスタンスでも、CPUクレジット残高の管理があります。モードはUnlimited Modeとなります。

詳細は、Amazon Document DBのサービス紹介ページをご覧ください。

ではどうすればいいのか

では、T系インスタンスは、どのような場合に利用すれば良いのでしょうか。

例えば、Amazon EC2のサービスの紹介ページには「使用中に一時的なスパイクが生じる中程度の CPU 使用率を持つアプリケーション向け」とあります。これは、決められた時間のみ利用されそうなバッチサーバや、そもそも負荷がかかる頻度が低いテストサーバが挙げられます。加えて、T3インスタンスは、大規模なマイクロサービスでの利用も想定されています。

T系インスタンスを利用するにあたっては、CPUクレジットの残高を監視することをお勧めします。先ほどご案内した通り、CPUクレジットの残高が0になると、CPU使用率がベースラインまでのみになるか、課金が発生します。監視の方法は、AWS公式ドキュメント「CPUクレジットの監視」の項をご覧ください。

データベースサーバについては、接続数の上限に至ることも考慮し、本番ではできる限りdb.r5.*などの新しい世代であり、かつバーストパフォーマンスではないインスタンスの利用をご検討ください。

もし、今、ご利用のインスタンスの状況を確認されて、CPUクレジットの残高が0またはそれに近い状況が繰り返されパフォーマンスに問題が出るなどの課題が発生している場合、インスタンスタイプを別のものに切り替えていただくことをご検討いただくか、AWSの担当者まで構成の見直しを相談、またはお問い合わせフォームからご連絡いただけましたら幸いです。

まとめ: 特徴を理解して上手に利用しよう

ここまで、T系インスタンスの特徴をサービス別にご紹介し、実際の活用方法についてご案内しました。「CPUクレジット残高」が、パフォーマンスや課金に影響があること、そして定常的に高い負荷がかかっている場合はT系以外のインスタンスタイプの検討も必要であることを知っていただけたかと思います。

時間単価をみますと、他のインスタンスタイプに比べて比較的安価には使えるのはみなさまご存知の通りです。その上で、その背景にこんなことがある、ということをシステム設計・運用時に考慮いただけたら幸いです。

それではみなさま、ごきげんよう。

このブログの著者

齋藤 祐一郎 (Yuichiro Saito) @koemu

過去、バックエンドソフトウェアエンジニアとして、主に FinTech(決済・出金)や C to C マーケットプレイスのシステム開発を担当。数々のスタートアップ企業に勤務し、 IPO などを経験。
最近は、主に Early Stage の Startup 企業様の技術支援を担当している。