クラウド コンピューティング リソースのサイズ設定時に避けるべき 10 の間違い

[[391889]]

組織が業務をクラウドに移行するときに直面する最も一般的な問題の 1 つはコストです。クラウド コンピューティングを使用すると、組織は IT コストを資本支出 (ハードウェア機器とソフトウェア ライセンスへの長期投資) から運用費に移行できるため、適切なクラウド サービスを選択し、正確な見積もりを行うことが重要です。この記事では、クラウド コンピューティング リソースのサイズを決定する際によくある間違いや落とし穴を探り、それらを回避する方法を説明します。そうすることで、クラウド コンピューティングの弾力性から真のメリットを享受できるようになります。

1. リフト＆シフト方式に従う

リフト アンド シフト アプローチとは、組織が最小限の変更でワークロードのコピーをクラウドに移動できることを意味します。このモデルは、組織がデプロイメントをクラウドに迅速に移行しているだけの場合でも便利ですが、リソースが十分に活用されない可能性があります。 AWS は、移行を簡素化するサービス (CloudEndure Migration および AWS Server Migration Service) を作成することは難しい問題であることを認めました。ただし、リソースをより有効に活用するには、組織はクラウド コンピューティング ソリューションの再構築を検討するのが賢明です。

リフトアンドシフト方式を採用する組織は、長期的にはより多くの費用がかかる可能性があり、クラウド プロバイダーが提供する多くのメリットを逃す可能性もあります。たとえば、従来の Postgres インスタンスの代わりに完全に管理された AWS Aurora を選択すると、組織は最大 3 倍のスループット、ストレージの自動スケーリング、低レイテンシのリードレプリカを実現できます。おそらくこれが、Aurora が現在最も人気があり、最も急速に成長している AWS クラウド サービスの 1 つである理由です。

2. リソースにタグを付けない

組織が十分な情報に基づいた意思決定を行うためのデータを持っていない場合、改善することは困難です。クラウド コンピューティング リソースのパフォーマンスと発生するコストを追跡する機能がなければ、その使用率を最適化することは困難です。

適切なサービスにコストを正しく割り当てるために、プロジェクトまたは組織単位に応じてリソースにタグを付けるのが一番の方法です。

3. 時間の経過に伴うリソースの使用状況の監視が不十分

クラウド コンピューティング インフラストラクチャの管理は、1 回限りのプロセスではありません。これは、組織が何をどのように、そしてなぜ使用しているかを継続的に監視および評価する実践です。おそらく、特定のアプリケーションの成長に関する組織の当初の想定は完全に正しくなく、変更を加えることでコストを大幅に削減できる可能性があります。

一例としては、必要以上に多くのノードがプロビジョニングされた Kubernetes クラスターが挙げられます。この場合、サーバーレス バージョン (Fargate 上の EKS) に移行する方が理にかなっているかもしれません。

「ゾンビ」リソースを監視せずに放置することは、想像するほど一般的ではありません。大規模な組織では、引き継ぎプロセスが不完全なために一部のプロジェクトが中止され、対応するリソースがアクティブなままになることがあります。

4. 常にすべてを自分で行う

ソフトウェア エンジニアは、カスタム ソリューションやサービスを独自に構築することもあります。おそらくより良いアプローチは、まず既存のリソースについて適切な調査を行うことです。例えば：

• EC2 でセルフホスト型データベースを使用する代わりに、インスタンスのスケーリングと操作をより簡単に行うことができる、完全に管理された RDS を使用することをお勧めします。
• おそらく、この自己管理型 RabbitMQ インスタンスは必要なく、代わりに実績のあるサーバーレス メッセージ キュー SQS を使用することができます。

多くの場合、サーバーレスまたは完全に管理されたソリューションが利用できる場合は、独自のソリューションの維持に多くの時間と労力を費やす前に、少なくともそれらの導入を検討することが理にかなっています。

5. 使い慣れたツールのみを使用する

Reddit やブログの記事を読んでいると、多くのエンジニアが EC2 と手動で管理されるサーバーしか知らないため、サーバーレスまたはコンテナ オーケストレーション プラットフォームの使用に消極的であることがよくわかります。彼らは、新しいテクノロジーは一時的な流行に過ぎないかもしれないので、やり方を変える必要はないと考えています。つまり、コンテナ オーケストレーション プラットフォーム、サーバーレス、その他のクラウド サービスに移行しても価値がないということです。これは慎重なアプローチのように思えます。新しいテクノロジーに懐疑的になるのではなく、そのような仮定に疑問を投げかけ、明確な事実、コスト、パフォーマンスのベンチマークに基づいてその有用性を判断する方がよいでしょう。

6. サーバーレスおよびコンテナオーケストレーションプラットフォームを使用していない

管理するサービスやツールごとに EC2 インスタンスを作成すると、メンテナンスが大変になる可能性があります。ただし、各サービスを Kubernetes (EKS) または Fargate (ECS) クラスター内のコンテナにデプロイすると、コンテナの動的なポート マッピングとよりコンパクトなリソース使用率 (共有レイヤーなど) により、単一のサーバー インスタンスにさらに多くのリソースを割り当てることができます。

コンテナ オーケストレーション プラットフォームは、インスタンス間で負荷が分散され、ワー​​クロードが正常な状態を維持することを保証するのに役立ちます。これにより、容量に関する推測がある程度不要になります。いつでも実行する必要があるコンテナ インスタンスの数を指定でき、コントロール プレーンによって定義どおりに実行されるようになります。

多数のコンテナやサーバーレス リソース間で簡単に負荷分散できる場合、ユースケースに適した EC2 または RDS インスタンスのサイズを推測する必要がなくなります。

7. 総所有コストを考慮していない

ハードウェアやサービスのコストのみを考慮すると、多くのリソースをオンプレミスで実行する方がコスト効率が高いと判断することになるかもしれません。しかし、メンテナンス、アップグレード、サーバーを管理するためのスタッフなどの追加コストを加えると、状況は変わってきます。

8. 長期的に考えない

現在の状況のみに基づいてリソースを拡張すると、将来のニーズの変化を考慮に入れられない可能性があります。ビジネスとデータがさらに成長したらどうなるでしょうか?逆のことが起こったらどうなるでしょうか?あなたのアプリケーションは、将来の未知の状況に合わせて簡単に変更、適応できますか?最後に、長期にわたってこれらのニーズを満たすのに十分な従業員を見つけて維持できるでしょうか?

9. 万が一に備えてオーバープロビジョニングする

万全を期したい場合は、ピーク時の使用量に確実に対応できるよう、すべてを過剰にプロビジョニングすることになると思います。過去の使用パターンに基づいてオーバープロビジョニングを正当化できる場合、これは適切な戦略です。しかし、直感でそうするのはおそらく悪い戦略です。

クラウド サービスは、クラスターにノードを追加したり、より多くのコンテナー間でワークロードの負荷を分散したり、必要に応じて CPU やメモリの数を増やしたりできるという意味で、弾力性を提供します。正しく構成および監視されている場合、多くの構成は必要ありません。適切なサイズ設定が簡単だというわけではありませんが、適切なプロセスと自動化により実行可能となり、特に大規模なリソースを多数実行する場合、大幅なコスト削減につながります。

10. 間違ったデータストレージの選択

場合によっては、ボトルネックの原因はコンピューティング リソースの不足ではなく、データ ストレージの選択の不備であることがあります。以下の点を考慮するのが最善です。

• 豊富なクエリ言語 (SQL) が必要ですか、それともアプリケーションには単純なキー値ストア (DynamoDB など) のみが必要ですか。
• まず、データベースが必要かどうか、データの単純な S3 ダンプで十分かもしれません。

当然ながらユースケースによって異なりますが、スケーラブルなアーキテクチャでは、通常、データベースが主なボトルネックになります。

クラウド コンピューティングのリソース サイズの問題を解決するにはどうすればよいでしょうか?

クラウド コンピューティング リソースの利用率を向上させる 1 つの解決策は、自動化テクノロジを採用することです。たとえば、Dashbird を使用して、リソースの占有不足や占有過剰の状況を追跡し、それについて通知を受け取ることができます。適切に構造化されたレンズ ダッシュボードを使用すると、EC2 インスタンス タイプの ECS クラスターの CPU 使用率が過去 1 時間に 90% を超えたことがわかります。

その後、特定の時間間隔にドリルダウンして、使用量の急増の理由をさらに調べることができます。

一方、別のコンテナ サービスが過剰にプロビジョニングされ、コストが無駄になる可能性があります。この情報を使用すると、実際の使用パターンに基づいてリソースの割り当てを最適化できます。

結論は

この記事では、クラウド コンピューティング リソースのサイズを決定する際によくある問題を検討し、これらの問題を回避してクラウド コンピューティングの弾力性を最大限に活用する方法について説明します。コンテナ オーケストレーション プラットフォーム、サーバーレスおよび完全に管理されたソリューションを使用し、使用パターンを長期にわたって継続的に監視することで、クラウド コンピューティング アーキテクチャのパフォーマンスとコストを最適化できます。