APIサービスをAWSのECS (Fargate)で実行とEC2上で実行した際の性能差について

APIサービスをAWSのECS (Fargate)で実行とEC2上で実行した際の性能差について

CTO室でリーダーやってます岡崎です。

今回はタイトルの通りAPIサービスをAWSのECS (Fargate)で実行とEC2上で実行した際の性能差についてまとめていきたいと思います。

経緯

弊社システム内で、かれこれ7年近く使われているAPIをアーキテクチャ含めて作り直します。 

I/F はそのままに、言語を JavaからKotlinに、Key Value ストアのように後ろ側で使っていたHBase を Redis に置き換えることで、コストの削減及び、パフォーマンスの向上、メンテナンス性の向上を図る目論見です。 

APIサービスもContainer化し、AWSのECS(Fargate)で起動する仕組みを採用し開発を進めていました。

が、しかし。

いざ本番を想定したデータを揃え、負荷テストを実行していところ、作り直し前より性能が出ていないのではないかと思われるケースが見つかりました。

今回のAPIは1回の処理レスポンスが重要です。

アクセス数は多くないAPIということもあり、最低でも旧APIの同等のレスポンス性能を出す必要があったため、改善を進めました。

AWS FargateやECS、EC2とは(一応)

ご存知の方がほとんどかもしれませんが、一応用語を説明(公式から説明文抜粋)しておきます。

Amazon Elastic Compute Cloud (Amazon EC2) 

Amazon Elastic Compute Cloud (Amazon EC2) は、安全でサイズ変更可能なコンピューティング性能をクラウド内で提供するウェブサービスです。

引用元:https://aws.amazon.com/jp/ec2/?ec2-whats-new.sort-by=item.additionalFields.postDateTime&ec2-whats-new.sort-order=desc

Amazon Elastic Container Service (ECS)

Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナを簡単に実行、停止、管理できる非常にスケーラブルで高速なコンテナ管理サービスです。

引用元:https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html

AWS Fargate

AWS Fargateとは、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) で動作する、ホストマシンを意識せずにコンテナを実行できる環境です。AWS Fargateを利用すれば、コンテナとコンテナの実行環境の2重管理が不要になります。

いわゆる、コンテナ向けのサーバーレスコンピューティングです。

具体的には、EC2インスタンス(コンテナを実行するためのサーバー環境)やそのスケーリング、インスタンスの集合体であるクラスターを管理する必要がなくなり、管理の効率化を図れます。

引用元:https://business.ntt-east.co.jp/content/cloudsolution/column-171.html

新APIを旧APIと比較してみる

それでは早速本題に入っていきます。

まずは新しく作成したAPIと旧APIの比較からです。

最も単純なパターンで比較してみると、新APIはやはり、旧APIより、ケースによってはレスポンスタイムが1.5倍程度になることが判明しました。

 バックエンドをHBaseからRedisへ変更したことでの性能の低下が発生していないことを確認した後、他の部分遅延が発生している可能性を考えてみます。

 まず、すぐ確認できそうな部分として、ECS(Fargate)でコンテナを起動していることで性能に影響があるかを確認してみました。

EC2上で直接APIサービスを起動した場合と比較してみる

 Fargate(コンテナ) で構築したサービスと EC2上に配置してjarファイルを直接起動したサービスを比較してみます。

 結果、EC2 で直接起動した場合の方が性能が向上し、旧APIと同等以上の性能があることを確認でき、このAPIはECタイプのEC2インスタンス上で実行することに決めました。

​なぜEC2で直接起動した方が性能向上するのか?​

ECS(Fargate) の場合インスタンスタイプを選べず、コンテナが使うvCPUの数及び、メモリーサイズしか選べませんが、EC2では、複数のインスタンスのタイプが有り、ワークロードにより任意に選択できます。

 今回はEC2でコンピューティング最適化されたインスタンスタイプを選択できたので、性能の違いが出たものと思われます。

結論

サービスをコンテナ化し、性能が思うように出なかった場合EC2上で適切なインスタンスを構築するのもありである。

しかし、スケールのしやすさやら、リソースの有効活用やら、コンテナのメリットは数多いので、コンテナを使うことのメリットは大きいのでケースバイケースで考えましょう(個人的にはもうよほど性能に左右されるサービスでもない限りコンテナ化したい!)。

以上となります。

ご清聴ありがとうございました。

前の記事
«
次の記事
»

技術カテゴリの最新記事