癖に耐えられるなら最安構成の常連

ツール導入前の課題

弊社のいくつかのプロダクトでEC2やECSを使っていたのですが、プロダクトが初期段階、検証段階であればあるほどランニングコストが重くのしかかっていました。

どのような状態を目指していたか

なるべく安く(最小限のスペックゆえの最安のコスト, 待機時間中はコスト0)という構成です。 特に今後のユーザー数や市場の拡大傾向が見通せない時に最小限のアクセスに耐えられる最小スペックで運用でき、ユーザー数が大きく増えるとわかってきた時に同時アクセス数やメモリ容量を増やし、フレキシブルに運用できる状態を目指していました。

• AWS ECS(Fargate)
• AWS EC2
• App Runner

• ランニングコストの低さ
• Deployの手軽さ

• 非稼働時のコストを0にできること。
• ECRイメージからコンテナを作成できるため、ローカル環境と差分が生まれにくいこと

改善したかった課題はどれくらい解決されたか？

コストはEC2+RDS構成の時と比べて1/100ほどになりました。 Github ActionsでCICDを組んでいるため、デプロイに要する手間も増えずに運用できています。 (EC2を使っていてもLambdaを使っていても, Githubリポジトリにコードをプッシュさえすればあとは自動デプロイされるのでデプロイに関する工数は増加していません)

どのような成果が得られたか？

月々のランニングコストが抑えられたのはいうまでもなく、主に開発環境に大きな恩恵があったと思います。 今までのEC2運用では、コストカットのために夜間や休日はサーバーを一時停止させ、平日の朝に起動させるというSSMオートメーションを用いた構成でした。ところが稀に発生する海外のエンジニアがサーバーを使いたい時や休日にサーバーを確認したい時などに毎回立ち上げが発生しており、これが開発時の小さいですが積もっていくストレスでした。 Lambdaに変えてからは一時停止や再起動という概念を捨てて使いたい時だけ利用できるのでそのストレスから解放されたのは大きいと感じます。

• コールドスタートにビジネス要件的に耐えられるかどうか
• 15分以上の実行時間を必要とする処理がないかどうか
• メモリやディスクの大量の使用(10GB以上)はないか ビジネス側と要件定義した時に上記が発生する可能性がないか(あってもかなり少ないか)を確認することに時間をかけました

とても癖があり、かつ自分では（ほぼ）変えることができない制限なので乗りこなすのは少し大変ですが、アーキテクチャを工夫すれば最強(安)のサーバーとなりうるので、ぜひ設計力で突破してみてください！

APIサーバーとして使用している部分は今後もそのままでいいと思うのですが、大きめのデータの変換処理やレポート作成処理などでもLambdaを使っていると、内容によっては10GBを超えることがあるとわかってきたので、そのようなLambdaで処理できない場合は Lambda (-> AWS Batch) -> ECS Task という構成に条件分岐していけたらなと思っております。 （また、Lambdaとは別の話になるのですが、DynamoDBを用いているので今後フレキシブルな検索要件が出てきそうであれば、検索用のサービスを別で立てていくことも模索しております）