私は、既存の物理データセンター (アプリケーション サーバー 6 台とレプリケートされた MySQL サーバー 2 台) を AWS に移行するコストを評価しようとしている 1 人の IT 担当者です。Amazon が提供するコスト計算ツールは、帯域幅のニーズと 3 つのサイズのサーバー インスタンスに基づいています。帯域幅のニーズはわかっていますが、特定のハードウェア/負荷に対応する EC2 サービス インスタンスのサイズを把握するのに苦労しています。負荷はスケジュールによって大きく変化するため、ピーク時には少なくとも 1 つの「オンデマンド」インスタンスを想定しています。物理的なセットアップを対応する (負荷が最適化された) AWS セットアップにマッピングするには、どのようなツール/戦略を使用できますか?
答え1
提供されているコスト計算ツールは、個人的には不十分だと感じました。現在、3 つの m1.small、2 つの m1.large、1 つの m1.xlarge、および 1 つの c1.xlarge サーバー インスタンスで構成されるデプロイメントがあります。9 か月ちょっと前に、従来のデータ センターの 3 つの物理サーバーの構築からこの構成に移行しました。
計算で最も簡単に判断できるのは、1 時間あたりのインスタンス コストです。料金体系のおかげで、S3 コストは大部分でわずかであることがわかりました。EBS ボリュームとスナップショットは実際には S3 コストよりも高く、計算も非常に簡単ですが、実際の使用量が当初の見積もりよりも高いことがわかったため、I/O 要求を多めに見積もることをお勧めします。
帯域幅は扱いにくく、サーバー インスタンス自体の不足により、考慮すべき 2 番目に大きなコストになる可能性があります。帯域幅の使用パターンについてはある程度把握していると思っていましたが、AWS での実際の使用状況から、当初の見積もりが間違っていたことが判明しました。留意すべき点としては、パブリックの受信および送信帯域幅だけでなく、リージョン間帯域幅もあるということです。同じリージョンで実行されているインスタンスが異なるアベイラビリティ ゾーン (AZ) にある場合は、帯域幅に対して課金されます。これは、特定の AZ で実行される EBS ボリュームを考慮する場合にも当てはまります。インスタンス間の通信が原因で、リージョン間帯域幅がパブリック帯域幅の使用量よりも高くなることが実際にありました。
予算作成のために見積もりを出すときに、ほとんどの計算を自動的に実行してくれる独自のスプレッドシートを作成しました。現在、新しい予算に合わせてスプレッドシートを更新して修正しているところです。ただし今回は、Amazon が提供する使用履歴の一部を利用して、より正確な見積もりを出すことができます。
どのインスタンスをマップするかについては、最善の推測で行っています。サーバーの主な用途の CPU とメモリの使用量に基づいてマッチングを試みることができます。実際、私たちは物理サーバーよりも AWS でインフラストラクチャを分割して、さまざまな部分のニーズをより適切に一致させ、追加のスケーラビリティを実現しています。