はじめに
初めまして、クラウドインテグレーション事業部の八木です。
今回がブログ初投稿ですが、お役に立てる情報をなんとかかき集めましたので、最後までお読み頂けると嬉しいです。
さて、AWSを触り始めて最初にぶつかる壁の一つに、EC2インスタンス種類が多すぎて何を選べばわからないということがあるかと思います。
とりあえず、無料枠で使えるインスタンスで始めてみたものの、自社ワークロードにはいったいどのインスタンスを選べば良いの??
そんな疑問に答えてくれるセッションを先日行われたAWSの最大のイベント[re:invent 2021]で発見しましたので、早速受講して参りました。
本記事にてその内容をシェアしていきたいと思います。
注意事項
初心者向けの記事です。
インスタンスの選ぶにあたっての考え方やツールの紹介記事で、実際のAWSサービスの操作や手順には触れません。
セッション情報
- セッションタイトル：”Optimize compute for cost and capacity”(コンピュートのコストとキャパシティの最適化)
- セッションNo. : CMP210
- セッションのアジェンダ:
- Compute platform for virtually every workload
- Selecting the right Amazon EC2 instance type for you
- Amazon EC2 instance selection tools
- Price, capacity, and performance optimization
- Conclusion
ちなみにいま利用可能なEC2インスタンスタイプの種類あるかご存知でしょうか？
なんと400以上だそうです。(2021年12月現在)
この膨大な種類のインスタンスの中から、コスト、パフォーマンス、自分のワークロードの全てにおいて最適なインスタンスを見つけるにはどうしたら良いのでしょうか？
まずは結論から申し上げると、ポイントは以下の4つ
- いきなり最適なものを探さない
- はじめはコストなどを考慮せずワークロードに合ったインスタンスを選ぶ。
- はじめのステップで選んだインスタンスに様々な値引きオプションを駆使して、性能を維持しながらコストを下げる。
- AWSが用意しているツールを活用して最適なものを見つけ出す。
となります。
では、どういうことかそれぞれ細かくみていきましょう。
最適なインスタンス選びはプロセス
第一に「最適なインスタンス選びはプロセス」ということです。
最初からベストなインスタンスを見つけようとせず、いくつか試してみて最終的にベストなインスタンスに落ち着くといったところでしょうか。
セッション内で提唱されていた具体的なプロセスは以下のようなものです。
- パフォーマンス面で最適なインスタンスを探す
- パフォーマンスを落とさずに、さまざまな購入オプションを駆使してコストを下げる。
要求パフォーマンスに合致したインスタンスを探す
まずは各インスタンスファミリーの特色を参照して、自分のワークロードに合うインスタンスファミリーがどのタイプか判断します。
現在、インスタンスファミリーは以下の8種類だけなので、400種類から選ぶよりずっと選びやすいですね。
- General Purpose
- Compute-intensive
- Storage(high I/O)
- GPU Compute
- Burstable
- Memory-intensive
- Dense storage
- Graphics-intensive
繰り返しになりますが、この時点ではコストのことはあまり考えずに選ぶのがポイントです。
最初にすべきことは、自分のアプリケーションにとって最も「重要な」、「コア」となる性能は何かを考えることです。
これは "attribute-based approach to instance type selection" という考え方に基づいてます。
少し難しい言葉が出てきましたが、アプリケーションやワークロードの要件から逆算して選ぶということのようです。
- 特定のプロセッサを必要とするワークロードでしょうか？
- 最低限必要なメモリはどのくらい？
- ネットワーク性能はどのくらい必要？
といった感じで、自身のワークロードのコアとなる属性(attribute)を基点にインスタンスを選びます。
それが定まったら、次にcapability (性能)とオプションについて考えます。
最適化に必要な3つの要素
パフォーマンスとコストはトレードオフの関係にあると考えるのが一般的ですが、必ずしもそうではありません。
- 料金にはどんな選択肢があるか
- 適切なツールを活用して性能を管理できるか
という2点ををしっかり理解することで、パフォーマンスを満たしつつ低コストを実現することが可能です。
そして、インスタンスの最適化を考えるということは、次の3つの面で最適化を図るということです。
Pricing(価格) Capacity(容量) Performance(性能)
順に見ていきましょう。
Pricing(価格)
基本的なEC2インスタンスの課金方式として、次の3つがあります。
- On-Demand
- Saving Plans
- Spot Instance
それぞれの特徴を簡単にまとめると以下のようになります。
On-Demand
- 長期間のコミットがない場合に向く。
- インスタンスの選択肢が多い。
- 400のインスタンスタイプ
- 新しいアプリケーション
Savings Plans
- Steady-state workload (定常的なワークロード)に向く。
- 1年もしくは3年間は継続して使用する予定がある。
- リージョンをまたいだ利用が可能。
- Saving planとOn-demandの併用も可能
- インスタンスを状況に応じて変更したい。
- インスタンスサイズ
- インスタンスファミリー
Saving Plansには以下の2種類があります。
Compute Saving Plan
- Amazon EC2、AWS Lambdaおよび AWS Fargateに適用される。
- On-Demand price の66% OFF *リージョンを跨いで利用可能
- OS 、テナンシーはフレキシブル
EC2 Instance Savings Plans
- EC2 の使用量に応じて適用
- On-Demand price の72% OFF *リザーブドインスタンスに類似
- 同じインスタンスファミリー/タイプ間ならサイズ変更可能
Spot Instance
- AWSクラウド内で一定の期間だけ発生してしまう未使用のインスタンスを需給バランスから決まる変動価格で利用するシステム。
- ユーザーは自分が支払っても良い最高額を設定し、その額がSpot Instanceの市場価格を上回っている限りそのインスタンスを使い続けることができるという仕組みです。
- 注意点は設定価格が市場価格を下回るとインスタンスが中断される可能性があることです。これはSpot Interruptionと呼ばれます。
Spot Instanceを賢く使う
先ほど、言及しましたが、Spot Instanceは大幅な割引がなされる一方、インスタンスの需給の都合で、強制的に中断されるリスクがあります。
この強制的な中断の発生率はスポットインスタンス全体の5%程度で発生しており、その他95%のインスタンスがはユーザーが自ら終了させたり、利用率が少ないインスタンスをオートスケーリンググループで自動終了したりといったケースが占めています。
この5%の強制終了をいかに回避して使用するかがSpot Instanceを使いこなす鍵となります。Spot Instanceは中断される2分前にAWSから通知(Spot interruption notification)がAmazon Event Bridgeと中断されたスポットインスタンスのmeta dataに届くようになっており、これらの通知を利用したアーキテクチャを組むことで耐障害性を高めることができます。
参考：スポットインスタンスの中断
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-interruptions.html
さらにrebalance recommendation signal という通知もあります。これは、Spot Instanceの中断リスクが高まっていることを通知するサインで、2分前に届くSpot interruption notificationよりもさらに早く通知されるので、稼働中のSpot Instanceの適切なシャットダウン、オートスケーリンググループを使った代替インスタンスの起動するなどの対処が可能となります。
参考：EC2 インスタンスの再調整に関する推奨事項 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/rebalance-recommendations.html
Spot Placement Score
Spot Instanceの使用においてもう一つ役立つツールがSpot Placement Scoreです。
これはSpot Instanceに必要な要件に基づいて、推奨されるリージョン、AZ、キャパシティを提示してくれるツールで、vCPUなどワークロードに必要となるインスタンスの情報を入力すると、リージョン、AZなどその推奨レベルを１から10のスコア形式で自動で評価して表示してくれる機能です。
スコアの数値がより高ければ高いほど、そのリージョン、AZ、設定で要求通りのSpot Instanceが使える可能性が高いことを表しています。
参考：Spot placement score https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-placement-score.html
Capacity(容量)
Auto Scaling
キャパシティの最適化に最も有効なのはオートスケーリングの活用です。オートスケーリングでは複数の購入オプションを組み合わせて使うことができるため、自分のワークロードに照らし合わせてOn-demandとSpot Instanceを同じオートスケーリンググループの中で使い分けることで最適化を図ります。
インスタンスタイプのばらつきがある程度許容できるようなワークロードであれば、異なるインスタンスファミリーの中から中断される可能性が少ないSpot Instanceだけ選んで使うことでキャパシティを確保しながら、中断の可能性を最小限に抑えることが可能となります。
On-demandインスタンスの場合は、オートスケーリンググループ内で複数のインスタンスタイプを利用することができますが、どのインスタンスから優先的に使うかといった順位付けができるため、これをうまく行うことでさらなる最適化も可能です。
Capacity-optimized Spot Allocation Strategy
キャパシティの最適化においてもう一つ重要な考え方がCapacity-optimized Spot Allocation Strategyです。これは、ワークロードに最適なキャパシティを確定させてから、インスタンスタイプをある程度、柔軟に選ぶという考え方です。
リアルタイムに更新されるキャパシティの残量データを参照しながら、最も余剰のある(=最も中断されにくい)インスタンスファミリーを選びます。この際のインスタンスファミリーの選択はある程度、柔軟に行う必要があります。
CloudFormationでも設定が可能です。
参考情報：
Performance(性能)
最後に考慮すべきベクトルはPerformance(性能)です。
AWS Compute Optimizer
性能の最適化に役立つツールがAWS Compute Optimizer です。
これは数百万に及ぶワークロードの機械学習から最適なEC、EBS、Lambdaなどの構成を3つ提案してくれるサービスです。使い方はいたって簡単で、AWS Compute Optimizerのコンソールからオプトインをクリックするだけです。そうすると後は自動で現在のリソースを分析して最適な提案をしてくれます。
ただし、最低30時間以上、インスタンスが連続稼働していないとメトリクスが表示されませんのでご注意ください。
参考URL：AWS Compute Optimizer
https://aws.amazon.com/jp/compute-optimizer/
まとめ
では最後にもう一度まとめます。最初にやることは、自分のワークロードにおいて、最も重視したいインスタンスの性能を明らかにすることです。そのコアとなる属性に沿って８つあるインスタンスファミリーから一つ選びましょう。最初はコストについては考慮しなくて大丈夫です。
インスタンスファミリーが決まったら、自分のワークロードに適合するものがないかSaving Plan、Spot Instanceなどの使用条件を確認します。
Spot Instanceは大きくディスカウントできますが、インスタンス中断のリスクがあります。中断にはSpot interruption notificationやrebalance recommendation signalといった中断が事前に通知される仕組みを使って対応することが可能です。Spot Instance Scoreというサービスで中断されてにくいインスタンスを選ぶことも可能です。
キャパシティについてはオートスケーリンググループを活用することが重要です。さらに、Spot InstanceとOn -demand Instanceを組み合わせて使うことでコストも最適化することができます。さらにキャパシティだけに注目して、インスタンスファミリーを柔軟に選択することで最適なSpot Instanceを選ぶCapacity-optimized Spot Allocation Strategyという考え方も学びました。性能については、AWS Compute Optimizer を活用することで、機械学習を利用した最適なインスタンスの選択が可能です。
個人的には課金方法の理解がカギになるかと思いました。AWSのコスト削減をしたい方の参考になれば幸いです。
