クラウドVMを適切なサイズにするための第一歩は、インスタンスを適切なサイズにすることだ。企業ではVMを導入するとき、OSとミドルウェアの標準構成をそのまま採用するといった、より簡単な方法をとる傾向がある。その結果、インスタンスが本来必要なサイズより40％以上大きくなることも少なくない。インスタンスのサイズを最適化するには、アプリケーションを実行するために必要なミドルウェアやOSの性能を定義し、必要なサイズを再計算しなければならない。インスタンスの見直しで確保した空き容量は、パフォーマンス向上のためのI/Oバッファーとして使用するか、インスタンスサイズ縮小のために削減する。

　IT担当者は便利な標準構成をそのまま採用するのではなく、各アプリケーションの要件を定義すべきだ。アプリケーションの変更と拡張の際にも、必要なミドルウェアを見直してインスタンスのサイズが肥大化するのを防止する必要がある。

　第2のステップは、テストに基づいて構成パラメーターとVMのメモリサイズを調整することだ。Linuxは、パフォーマンス向上のために利用可能なメモリを全て確保し、バッファーとして使用する傾向がある。これが、ユーザーがしばしばメモリリソースを必要以上に割り当ててしまう理由の1つだ。ほとんどの場合、使用可能なメモリが増加しても、それに比例してパフォーマンスが向上するわけではない。ある時点でパフォーマンスの改善度が低下するか頭打ちになる。このポイントを簡単に計算する方法はないため、幾つかの異なるサイズのインスタンスでアプリケーションをテストし、コストパフォーマンス曲線を決定する必要がある。

　この種のテストでは、負荷テストやパフォーマンステストなどを実働環境に近い状態でテストできる自動テストツールが必要になる。最適なツールはアプリケーションの性質によって異なり、分散型のWebベースのテストが必要なものや、より具体的なトランザクションテストが必要なものもある。Linuxのfreeコマンドを使用してVMの空きメモリの使用状況をチェックし、スワップメモリにも注意する必要がある。スワップの使用量が多い場合は、アプリケーションのメモリが不足している。

　仮のインスタンスサイズでVMを実行し、freeコマンドでメモリ使用量を取得する。実際のメモリのサイズはこの使用量の1.2倍程度になるように変更する。1.2倍の余裕があれば、ほとんどの場合で安全だ。次に1段階小さなサイズと1段階大きなサイズでパフォーマンスをテストする。

　次に、クラウドVMが複数のアプリケーションを処理する方法を考慮する。VMリソースをプールするのではなく、VMに単一のアプリケーションだけを配備する場合は、この手順は不要だ。しかしリソースをプールする場合は、全てのアプリケーションに必要なVMサイズのスプレッドシートを作成し、VMのサイズごとにアプリケーションの数を決定する。平均的なVMのサイズから大きく外れるケースがわずかしかない場合は、異なるサイズのリソースプールを作成する必要はなく、その平均的なサイズに統一する。大きなプールは小さなプールよりも効率が高いため、結果的に全体の利用率が向上する。

リザーブド、オンデマンド、プリエンプティブ　各インスタンスタイプの比較

　適切なサイズのクラウドVMを検討する際のもう一つの考慮点は、リザーブド、オンデマンド、プリエンプティブのどのインスタンスタイプを選択するかだ。

　年単位の利用料を前払いして使うリザーブドインスタンスは、ユーザーが随時VMを起動できるため、24時間稼働が要件のアプリケーションに特に役立つ。Amazon Web Services（AWS）のリザーブドインスタンス、Microsoft AzureのリザーブドVMインスタンス、Googleの確約利用割引で利用可能なVMなどがその例だ。

　前述した複数のアプリケーションで同じリソースプールを使用するケースでは、リザーブドインスタンスの利用が適切だ。リソースプールを構築する場合は、常時稼働するVMが必要なためだ。

　ほとんどのアプリケーションには、長期予約契約が不要で低コストのオンデマンドVMが適している。オンデマンドインスタンスと短時間の稼働プリエンプティブインスタンスの場合、リザーブドインスタンスよりも低コストだが、イメージの読み込みが遅くなるリスクが大きく、GoogleのプリエンプティブVMやAWSのスポットインスタンスなどのプリエンプティブインスタンスの場合は、ベンダーが予期しないタイミングでシャットダウンする可能性がある。業務に必要不可欠な用途の場合は、オンデマンドインスタンスと、プリエンプティブインスタンスには注意する必要がある。

　正しい判断を下すための一番大事なプロセスは、入念なテストをすることだ。