メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

T1 マイクロインスタンス

T1 マイクロインスタンス (t1.micro) は、少量かつ一定量の CPU リソースを提供し、追加サイクルが利用可能であるときは、CPU 処理能力を短期バーストとして増大させることができます。このタイプが適しているのは、低スループットのアプリケーションやウェブサイトが定期的に追加計算サイクルを必要とする場合です。

注記

t1.micro は前世代のインスタンスであり、パフォーマンスプロファイルがはるかに優れた t2.micro に置き換えられました。t1.micro の代わりに t2.micro インスタンスタイプを使用することをお勧めします。詳細については、「T2 インスタンス」を参照してください。

t1.micro インスタンスは、Amazon EBS-Backed インスタンスとしてのみ利用できます。

このドキュメントでは、t1.micro インスタンスの動作とその適用方法について説明します。厳密な動作を示すことを目的とはしていません。インスタンスの動作を明らかにして。パフォーマンスを把握できるようにすることが目的です。

ハードウェア仕様

各 Amazon EC2 インスタンスタイプのハードウェア仕様については、「Amazon EC2 インスタンス」を参照してください。

T1 マイクロインスタンスの最適な用途

t1.micro インスタンスは、ワークロードの CPU 使用率のスパイク期間 (次の図を参照) に対応するための CPU リソースを提供します。

 適合

インスタンスは、2 つの基本レベルの CPU 使用率のみで機能するように設計されています。1 つは通常の低バックグラウンドレベルで、もう 1 つはバックグラウンドレベルよりはるかに高い短期スパイクレベルです。インスタンスは、最大 2 つの EC2 コンピューティングユニット (ECU) で動作することが許可されています (1 つの ECU が 1.0~1.2 GHz 2007 Opteron、または 2007 Xeon プロセッサと同等の CPU 能力を提供)。最大レベルとバックグラウンドレベルとの比率は大きくなるように設計されています。t1.micro インスタンスは、アプリケーションで 1 分あたり数十のリクエストをサポートするように設計されています。ただし実際のパフォーマンスは、アプリケーションで出された各リクエストに必要な CPU リソースの量に応じて大幅に変わる可能性があります。

アプリケーションの CPU 使用率プロファイルは、前のセクションで説明したプロファイルと異なる場合があります。次の図は、t1.micro インスタンスに適していないアプリケーションのプロファイルを表示しています。アプリケーションには、リクエストごとに連続したデータ処理 CPU リソースが必要であるため、CPU 使用率が長時間にわたって高レベルを維持する結果となり、t1.micro インスタンスでは対処できません。

 不適合: プラトー

次の図は、t1.micro インスタンスに不適切なもう 1 つのプロファイルを示しています。ここでは CPU 利用率のスパイクが簡易ですが、マイクロインスタンスでサービスできないほど頻発しています。

 不適合: 頻発

次の図は、t1.micro インスタンスに不適切なもう 1 つのプロファイルを示しています。ここではスパイクは頻発していませんが、スパイク間のバックグラウンドレベルが t1.micro インスタンスで対処できないほど高くなっています。

 不適合: 高すぎるバックグラウンド

t1.micro インスタンスに適切ではない前記の各ワークロードのケースでは、異なるインスタンスタイプの使用をご検討いただくことをお勧めします。インスタンスタイプの詳細については、「インスタンスタイプ」を参照してください。

スパイク中に利用可能な CPU リソース

計算リソースの要求のスパイクに対応するためにインスタンスがバーストすると、ホスト上の未使用のリソースが使用されます。利用可能な量は、スパイク発生時の競合の程度に応じて異なります。ホスト上の他のインスタンスがスパイク中であるかどうかに関係なく、インスタンスには必ず CPU リソースが適用されます。

インスタンスが割り当てられたリソースを使用する場合

ある期間内にはアプリケーションは CPU リソースの一部のみを使用するものと想定しています。アプリケーションが、インスタンスに割り当てられた CPU リソースを超える量を使用する場合は、CPU の使用レベルが低レベルになるように、一時的にインスタンスを制限します。インスタンスが割り当てられたすべてのリソースを使用し続けると、パフォーマンスが低下します。CPU の使用レベルを制限する時間を延長することで、インスタンスの再バーストが許可されるまでの時間を長くします。

t1.micro インスタンスの CloudWatch モニタリングを有効にすると、AWS マネジメントコンソール で「CPU 平均利用率」グラフを使用して、インスタンスが割り当てられているすべての CPU リソースを定期的に使用しているかどうかを判別できます。各期間の最大値を確認することをお勧めします。最大値が 100% である場合は、Auto Scaling を使用してスケールアウトする (t1.micro インスタンスを追加し、ロードバランサーを使用する) か、またはより大きいサイズのインスタンスタイプに移行することをお勧めします。詳細については、Auto Scaling ユーザーガイド を参照してください。

前のセクションで使用した十分最適化されていない 3 つのプロファイルについて考えてみます。これはインスタンスが割り当てられたリソースをすべて使用するため、その CPU レベルを制限している例です。インスタンスが割り当てられたリソースをすべて使用する場合は、そのレベルを低バックグラウンドレベルに制限します。次の図は、データ処理 CPU 使用率のプラトーが長い場合を示しています。CPU は許可される最大レベルに達し、その期間にインスタンスに割り当てられているリソースがすべて使用されるまで、そのレベルを維持しています。その時点で、低バックグラウンドレベルで機能するようにインスタンスを制限します。そのレベルより高いレベルまでバーストすることを許可するまで、低レベルが維持されます。インスタンスは、割り当てられているリソースをすべて使用し、制限されるまで、そのレベルを維持します (グラフには示されていません)。

 不適合: 広すぎる、制限あり

次の図は、頻発すぎるリクエストを示しています。インスタンスは、ほんのいくつかのリクエストが出された後に割り当てられているリソースを使用するため、それを制限します。制限を解除すると、インスタンスはリクエストの処理に追いつくように CPU 使用率を最大限にするため、再度インスタンスを制限します。

 不適合: 頻繁すぎる、制限あり

次の図は、高すぎるバックグラウンドレベルを示しています。インスタンスは、制限されることを目的として、最大 CPU レベルで機能し続けなければならないわけではありません。インスタンスを制限するのは、通常のバックグラウンドレベルを上回るレベルで機能し続け、割り当てられているリソースが一定期間にすべて使用される場合です。このような場合も (前の例を参照)、インスタンスの作業に遅れが出るため、インスタンスを制限します。

 不適合: 高すぎるバックグラウンド、制限あり

m1.small インスタンスタイプとの比較

t1.micro インスタンスは、時間によって異なるレベルの CPU リソースを提供します (最大 2 ECU)。比較すると、m1.small インスタンスタイプは常時 1 つの ECU を提供します。次の図は、相違点を示しています。

 m1.small との一般的な比較

t1.micro インスタンスの CPU 使用率を、これまでのセクションで説明したさまざまなシナリオの m1.small インスタンスと比較してみましょう。次の図は、t1.micro インスタンスの最適なシナリオ (左側のグラフ) と、m1.small インスタンスの場合の状態 (右側のグラフ) を示しています。この場合は、t1.micro インスタンスを制限する必要はありません。m1.small インスタンスでの処理時間は、t1.micro インスタンスと比較すると、CPU 要求のスパイクごとに長くなっています。

 m1.small との比較: 最適な状態

次の図は、t1.micro インスタンスに割り当てられたリソースがすべて使い切られたためにデータ処理リクエストが出されたというシナリオと、m1.small インスタンスの場合の状態を示しています。

 m1.small との比較: 長すぎるプラトー

次の図は、データ処理リクエストが頻繁に出されたため t1.micro インスタンスの割り当てリソースがすべて使い果たされたというシナリオと、m1.small インスタンスの場合の状態を示しています。

 m1.small との比較: 頻発

次の図は、バックグラウンドレベルで t1.micro インスタンスに割り当てられたリソースがすべて使い切られた状況と、m1.small インスタンスの場合の状態を示しています。

 m1.small との比較: 高すぎるバックグラウンド

マイクロインスタンスの AMI 最適化

t1.micro インスタンスタイプに合わせて AMI を最適化するときは、以下のベストプラクティスにしたがうことをお勧めします。

  • 600 MB の RAM で実行されるように AMI を設計する

  • CPU 時間を使用する定期プロセス (例: cron ジョブ、デーモン) の数を制限する

スワップ領域と仮想メモリを使用してパフォーマンスを最適化できます (たとえば、ルートファイルシステムとは別のパーティションにスワップ領域をセットアップできます)。