AWSで学ぶコンテナの基礎 (6) 費用と性能

コンテナ基礎シリーズの締めくくりとして、費用と性能について少しだけ触れておきましょう。

運用面はわりと便利なのはわかりましたが、コスパが悪ければ採用されるわけもありません。ECS Fargate やいかに!?



目次

(0) はじめに
(1) Docker
(2) イメージ自動生成
(3) サービス起動
(4) デプロイ
(5) Auto Scaling
(6) 費用と性能 ← イマココ!


費用

ECS Fargate の料金は公式を確認して、
  • AWS Fargate の料金

  • 値下げの事実を知っておけばよいでしょう。
  • 2019年1月にAWS Fargateが大幅値下げしたのでEC2との価格比を確認してみた | DevelopersIO

  • あとでEC2インスタンスの主要タイプと比較するために、それっぽいリソース・セットでの時間あたりの料金を計算しておきます。データは面倒なので画像で失礼しやす。



    ここで現実的なスペックと台数で月額試算を出しても、たいした意味はないのでやりません。重要なのは、旧来のEC2方式に比べて、Fargateはどうなのかという点です。


    CPU性能

    価格と単純リソースだけだと比較としては足りないので、CPUモデルと性能についてチェックしておきます。Fargateの指定リソースを変更してCPU model を見てみましたが、東京リージョンで数回やった程度だと全て同じだったので、それを記載しています。

    また、CPU性能は下記サイトで調べて Single Thread Rating を参考にしています。
  • PassMark Software – CPU Benchmark Charts



  • まぁCPUを Single Thread Rating だけで計れるわけでもないですが、ここの数値は経験上かなり信頼できる数値なので、比較用としては十分な項目です。

    他の人のFargate CPUチェックをみると、Single Thread Rating にして 1400台~1700台 のモデルも出現しているようなので、上記の選択はちょうど中間点ということで、そのままいきます。


    費用あたりの性能

    ここまでの情報を元に、$1 あたりのCPU性能、という仮想的なスコアを出してみました。score = Single Thread Rating / (USD/h) です。下部の RI はリザーブドインスタンスで、前払いなしの費用で計算しています。



    やはり c5 が突き抜けて優秀で、それをリザーブドにすると、Fargate のc系相当とはダブルスコア近い差が出てしましました。

    Fargateはコンテナのみの値段とはいえ、親OSの運用に必要なリソースもコミコミの価格でしょうから、ある程度は想像より高めになるのは当然でしょうが、CPUが結構古めのため、結果だけ見るとだいたいEC2インスタンスとしては1~2世代前のコスパといえそうです。


    ネットワーク性能

    こちらに興味深い記事があります。
  • AWS Fargate Network Performance | StormForger

  • ネットワーク・パフォーマンスを計測したらブレブレでなんでやねん!って内容ですが、ブレすぎた結果を除いたベース部分の数値を見てみると、Fargateのネットワークは、EC2インスタンスのネットワーク性能表記(低・中・高・10Gbps・・・)のうち、低~中にあたるようです。最大リソースにしても高には届かないようですね。


    採用判断

    コンテナを扱うからといって、必ずしも Fargate である必要はありませんが、運用の簡潔さを重視した場合は十分に選択肢に入るシステムです。

    一方で、費用というインフラ選定ではトップクラスに重要な要素において、従来のEC2をそのままサーバーとして扱ったり、EC2コンテナとして利用する手法と比べると、費用対効果が最悪2倍以上の差があるという現実が重いです。

    いわゆる、機能と費用のどちらをとるかという話でもありますが、おそらく開発スピード重視かつ小中規模のサービスを運営する程度ならば Fargate もありでしょうが、大規模に成れば成るほど、旧構成と比較した際のコスト削減効果が大きくなり、間違いなく課題のひとつとして上がることでしょう。

    また、コスト比だけでなく、そもそもCPU処理が速い、ということはサービスのレスポンス速度が速い、ということになるので、開発・運用体制が一流でも、サービスの速度品質は二流止まりが限界ということになります。

    この考えはあくまで一般的なWEBサービスの運営にあたるものなので、もっと一時的な処理や定期的な処理など、他に適した利用方法があるやもしれません。

    こういう、オンプレミス vs クラウド のような人的工数と費用対効果みたいな話は、今の時代はできるだけ自動化とかXaaS側に寄せていくほうが正着なのは間違いなく、ただ新しいものは許容できる境界線がどこやねんってのを判断するのが難しく、また楽しいところでもあります。


    現段階だと、
    Docker主体の開発体制の研究や準備をしておくとか、
    開発環境は ECS Fargate で本番は ECS EC2 とか、
    お金をジャブつけるなら Fargate 全ぶっぱとか、

    どこまでDockerによる運用体制に価値を見いだせるかがポイントになりそうです。



    最後、もう一歩惜しいところで湿っぽい感想で〆てしまいましたが、コンテナ自体は取り掛かっておいて間違いない時期ではあると思うので、コンテナ業界とクラウド業界の双方の躍進を期待しつつ、各々良いところどりしていく雰囲気で楽しんでいきましょう!

    コンテナ基礎シリーズ、お疲れ様でした:-)