はじめに

Golangってめちゃくちゃ高速だし最高！という話があるものの、Webフレームワークを扱うにあたっては、まだまだ情報も事例も少ないという状況で、実際に高速とは言え実運用に持ち込むにはリスクがあるかもしれない。
一方で、SpringBootはWebフレームワークとしては充分に実績があるので、速度差次第では充分に採用するメリットはある。

というわけで、今回は「実際にどれくらい速度違うの？」というのを確かめてみた。

条件としては

DynamoDBから1アイテムをGetItemするトラフィックをかける
DynamoDBへのアクセスはVPCエンドポイント経由
FargateのCPU割り当てを256ユニット→512ユニットで垂直スケールするかを確認する(水平スケールは充分に実績がある前提として確認しない)
GolangのWebフレームワークはGinを使用
GolangのSDKはv2を使用(プレビューだが、v1は全然スループットが出なかった)

といったところか。

なお、測定ツールにはlocustを用いていて、画面キャプチャを使っているので、各項目の目盛りのスケールがあっていないのはご了承いただきたい……。

Golang編

256CPUユニット

10ユーザ単位で増加させた。
スループットは最大で250rps程度。
それを超えると、CPUが高騰してスループットが激減する。300rpsは安定しなそう。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

512CPUユニット

20ユーザ単位で増加させた。
スループットは最大で440rps程度。
それを超えると、CPUが高騰してスループットが激減する。

CPUユニット数を倍にしているのにスループットが倍にならず垂直スケールしないのが謎。
AWS Go SDK v1でもv2でこの傾向は同じだが、v2の方がCPUユニットあたりのスループットは出る。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

Java編

256CPUユニット

JavaはJavaでなかなか安定しないグラフになる。
20ユーザ単位で増加させた。
スループットは最大で450rps程度出ているが、このタイミングでは95%タイルや中央値が悪化しているので、安定を目指すなら380rps程度出ているポイントを目指すべきだろう。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。
380rpsのポイントでもCPUは80%以上使えているので、まずまず充分に使えている。

512CPUユニット

やっぱりこちらも安定しない。
80rpsをスタートにして、20ユーザ単位で増加させた。
Ginと違い、こちらは垂直にスケールしている。だいたい850rpsを超えると95%タイルが悪化しているので、このあたりのポイントが良いだろう。この時点でのCPU使用率は80%以上なので、こちらも充分に使いきれてると言える。

上記の時間帯のCloudWatchメトリクスのCPU Utilizationは以下。

結論

Ginの方がトラフィックが安定するものの、垂直スケールしない点が気になる。
SpringBootについては、スレッド数やGC頻度を調整すればもう少し安定しそう。
もうちょっと実績が出てドキュメントが増えればGinは全然アリだが、現時点では何かがあっても調べようがないのが厳しいところだ。