# 適切なサイジングのヒント
このセクションでは、EC2 インスタンスと RDS DB インスタンスの適切なサイジングに役立つヒントを紹介します。
## パフォーマンスデータを使用した適切なサイジング
パフォーマンスデータを分析して EC2 インスタンスを適切なサイズにします。アイドル状態のインスタンスと使用率の低いインスタンスを特定します。注目すべき重要なメトリクスは、CPU 使用率とメモリ使用率です。4 週間で最大 CPU 使用率とメモリ使用率が 40% 未満であるインスタンスを特定します。これらのインスタンスは、コストを削減するために適切なサイズにする必要があります。
コンピューティング最適化インスタンスの場合は、次の点に留意してください。
+ ごく最近のインスタンスデータに注目します (古いデータには対応できない場合があります)。
+ 確認している時間の半分以上実行されたインスタンスに注目します。
+ バースト可能インスタンスファミリー (T2 インスタンスタイプ) は無視します。これらのファミリーは、通常、低い CPU パーセンテージで長時間稼働するように設計されているためです。
高いデータ IOPS が主な特徴であるストレージ最適化インスタンス (I2 および D2 インスタンスタイプ) では、IOPS に注目して、インスタンスが過剰にプロビジョニングされていないかどうかを確認します。ストレージ最適化インスタンスでは、次の点に留意してください。
+ インスタンスのサイズが異なれば IOPS レーティングも異なるため、レポートはインスタンスタイプごとに調整します。最も一般的に使用されているストレージ最適化インスタンスタイプから始めます。
+ NetworkIn と NetworkOut のピーク値は 1 分あたりのバイト数で測定されます。これらのメトリクスをメガビット/秒に変換するには、次の数式を使用します。
最大 NetworkIn (または NetworkOut) x 8 (バイトからビットへ) /1024/1024/60 = Mbps 数
+ 1 日の間に I/O および CPU 使用率メトリクスがどのように変化するか、および対応が必要なピークがあるかどうかを書き留めます。
4 週間の最大メモリ使用率が 40% 未満であれば、メモリに対して適切なサイズです。AWS は、Linux を実行している EC2 インスタンスのメモリとディスク容量の使用率をモニタリングするための[サンプルスクリプト](https://aws.amazon.com/code/amazon-cloudwatch-monitoring-scripts-for-linux/)を提供しています。Amazon CloudWatch にメトリクスをレポートするようにスクリプトを設定できます。
Amazon RDS DB インスタンスのパフォーマンスデータを分析するときは、次のメトリクスに注目して、実際の使用量がインスタンス容量より低いかどうかを判断します。
+ CPU の平均使用率
+ 最大 CPU 使用率
+ 使用可能な最小 RAM
+ 1 秒あたりのディスクからの平均読み取りバイト数。
+ 1 秒あたりのディスクへの平均書き込みバイト数。
## 使用ニーズに基づいた適切なサイズ
現在のパフォーマンスをモニタリングする際には、適切なサイジングオプションを利用できるように、次の使用ニーズとパターンを特定します。
+ **安定した状態** – ロードは長期にわたって比較的一定に保たれ、予想されるコンピューティングロードを正確に予測できる。この使用パターンでは、リザーブドインスタンスをご検討ください。これにより、大幅なコスト削減を実現できる可能性があります。
+ **変動はあるが予測可能** – ロードは変化するが、そのスケジュールは予測可能である。[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) は、時間単位、日単位、週単位で変動する一定した需要パターンを持つアプリケーションに最適です。トラフィックの急増や予測可能なトラフィック変動が発生した場合、この機能を使用して Amazon EC2 の容量を拡大または縮小できます。
+ **開発/テスト/本番** – 開発、テスト、本番環境は、通常は営業時間内にのみ使用され、夜間、週末、祝日にはオフにできます (開発/テスト/本番環境のインスタンスを識別するには、タグ付けを利用する必要があります)。
+ **一時的** – 開始時間が変動し、中断される可能性がある一時的なワークロードの場合は、オンデマンドインスタンスを使用する代わりに Amazon EC2 スポットインスタンスの利用を検討できます。
## アイドル状態のインスタンスをオフにして適切なサイズに設定する
運用コストを削減する最も簡単な方法は、使用されなくなったインスタンスをオフにすることです。2 週間を超えてアイドル状態が続いているインスタンスを見つけた場合は、インスタンスを停止または削除しても安全です。アイドル状態が 2 週間以下のインスタンスを削除する前には、次の点を考慮してください。
+ インスタンスの所有者は誰か?
+ インスタンスを削除すると、どのような影響があるか?
+ インスタンスを復元する必要がある場合、再作成はどれくらい困難か?
EC2 インスタンスを停止すると、アタッチされた EBS ボリュームはすべて動作可能なままになります。このようなボリュームを削除するまでは、その使用料が継続して請求されます。インスタンスが再び必要になった場合は、簡単にオンに戻すことができます。ただし、インスタンスを削除すると、アタッチされた EBS ボリュームが自動的に削除されるため、インスタンスが再び必要になった場合は、再プロビジョニングの手間がかかります。EBS ボリュームを削除する場合は、必要に応じて後で復元できるように、ボリュームのスナップショットを保存することを検討します。
コストを削減するもう 1 つの簡単な方法は、開発および本番環境で使用されているインスタンスを、使用されていない時間帯に停止し、容量が必要になったときに再起動することです。週に 50 時間稼働すると仮定した場合、開発/テスト/本番インスタンスを営業時間外に自動的に停止することで 70% のコスト削減になります。スケジューリングを自動化するには、[Amazon EC2 Scheduler](https://aws.amazon.com/answers/infrastructure-management/ec2-scheduler/)、[AWS Lambda](https://aws.amazon.com/lambda/)、[AWS Data Pipeline](https://aws.amazon.com/datapipeline/)、CloudHealth や Skeddly などのサードパーティーツールなど多くのツールを利用できます。
## 適切なインスタンスファミリーの選択による適切なサイジング
同じインスタンスファミリー内の別のモデルに移行するか、別のインスタンスファミリーに移行することで、インスタンスのサイズを適切に設定できます。同じインスタンスファミリー内で移行する場合、vCPU、メモリ、ネットワークスループット、エフェメラルストレージのみを考慮すれば済みます。EC2 インスタンスの一般的な推奨ルールとして、4 週間で CPU とメモリの最大使用率が 40% 未満であれば、機能を安全に半減させることができます。例えば、c4.8xlarge EC2 を使用していた場合、c4.4xlarge に移行すれば、10 日ごとに 190 USD の削減になります。
別のインスタンスファミリーに移行する場合は、仮想化タイプ、ネットワーク、プラットフォームの点で、現在のインスタンスタイプと新しいインスタンスタイプに互換性があることを確認してください。
+ **仮想化タイプ** – インスタンスの Linux AMI 仮想化タイプ (PV AMI と HVM) とプラットフォーム (EC2-Classic と EC2-VPC) が同じである必要があります。詳細については、「[Linux AMI 仮想化タイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)」を参照してください。
+ **ネットワーク** – 一部のインスタンスは EC2-Classic ではサポートされていないため、仮想プライベートクラウド (VPC) で起動する必要があります。詳細については、「[VPC でのみ利用可能なインスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#vpc-only-instance-types)」を参照してください。
+ **プラットフォーム** – 現在のインスタンスタイプが 32 ビット AMI をサポートしている場合は、32 ビット AMI もサポートする新しいインスタンスタイプを選択します (すべての EC2 インスタンスタイプがサポートしているわけではありません)。インスタンスのプラットフォームを確認するには、Amazon EC2 コンソールの [インスタンス] 画面に移動し、**[Show/Hide Columns] (列の表示/非表示)、[Architecture] (アーキテクチャ)** を選択します。
EC2 インスタンスのサイズを変更すると、サイズ変更したインスタンスには通常、元のインスタンスの起動時に指定したのと同じ数のインスタンスストアボリュームが設定されます。インスタンスストアボリュームは起動後にインスタンスにアタッチできないため、インスタンスストアボリュームを追加する場合は、ボリューム数が多い新しいインスタンスタイプに移行する必要があります。
## データベースインスタンスの適切なサイジング
パフォーマンスや容量の要件の変化に応じて、メモリを調整したり、処理能力を増減したりして、データベースインスタンスをスケールできます。データベースインスタンスをスケーリングする際には、次の点を考慮する必要があります。
+ ストレージとインスタンスタイプは分離されています。データベースインスタンスをスケールアップまたはスケールダウンしても、ストレージサイズは同じままで、変更の影響を受けません。
+ Amazon RDS DB インスタンスを個別に変更して、ストレージタイプを変更することで (汎用 SSD からプロビジョンド IOPS SSD に変更するなど)、割り当てられたストレージ容量を増やしたり、パフォーマンスを向上させたりできます。
+ スケーリングを行う前に、商用エンジン (SQL Server、Oracle) の適切なライセンスを持っていることを確認してください (特に、Bring-Your-Own-License (BYOL) を使用する場合)。
+ 変更を適用するタイミングを決めます。すぐに適用するか、インスタンスに指定されたメンテナンス時間中に適用するかを選択できます。