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

Terra Drone株式会社 / 万年道半ばんちゅ
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2023年9月 | B to B |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2023年9月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
工夫した点は以下の通りです
- Lambdaを使っているのでVPCを設置せずサーバレス構成を採用した(アクセスのパーサーとしてAPIGW, DBはDynamoDB, StorageはS3)
- Lambdaは用途に合わせて複数使用し、その中で使われる言語の制限は行わない
- APIサーバーとしてのLambda内で動いているイメージはDistrolessを用いて軽量化を図った
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
弊社のいくつかのプロダクトで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以上)はないか ビジネス側と要件定義した時に上記が発生する可能性がないか(あってもかなり少ないか)を確認することに時間をかけました
導入に向けた社内への説明
上長・チームへの説明
元々弊社のAWS環境にEC2(m6インスタンス)を使って動いていたサーバーがありました。 そこにアプリケーションを乗せた場合のランニングコストはすぐにCost Explorerから調べることができます。 それに対してLambdaを選定した場合は「何分の1のコストで運用できるか?」という比較をビジネスオーナーに説明しました。 また、Lambdaを採用するにあたっての弊害(コールドスタートが発生する、長時間ノンストップ稼働ができないこと、など)を合わせて確認し、認識のずれがないようにしました。
活用方法
PoCプロダクトやスポットの外部実証のみ使われるAPIサーバー、グロース前のプロダクトなどで使用されています 開発環境や本番環境、すべての環境で使用しており、いつでもAPIサーバーとして利用できる状態になっております
よく使う機能
- ECRイメージからのデプロイ機能
- APIGWからのプロキシ統合連携
- ローカル開発時のLambda RIE
ツールの良い点
- 起動時間への課金なのでコール数が少ない場合に割がいい
- ECRに置いたイメージからコンテナを作れるため、環境差分が起こりにくい
- RUSTやGoなどで軽量バイナリを作っておけば更なるコスト削減も可能
ツールの課題点
- 癖(制限)が強いと感じる時がある -> 最大起動時間15分 -> (Lambda RIEがあるとはいえ)ローカル環境でのテストのし辛さ -> APIサーバーを立てるなら前段はAPIGWかAppSyncなどに固定されること -> メモリ最大サイズやエフェメラルストレージ(一時保管ストレージ)の最大サイズ制限、ともに約10GB
ツールを検討されている方へ
とても癖があり、かつ自分では(ほぼ)変えることができない制限なので乗りこなすのは少し大変ですが、アーキテクチャを工夫すれば最強(安)のサーバーとなりうるので、ぜひ設計力で突破してみてください!
今後の展望
APIサーバーとして使用している部分は今後もそのままでいいと思うのですが、大きめのデータの変換処理やレポート作成処理などでもLambdaを使っていると、内容によっては10GBを超えることがあるとわかってきたので、そのようなLambdaで処理できない場合は Lambda (-> AWS Batch) -> ECS Task という構成に条件分岐していけたらなと思っております。 (また、Lambdaとは別の話になるのですが、DynamoDBを用いているので今後フレキシブルな検索要件が出てきそうであれば、検索用のサービスを別で立てていくことも模索しております)

Terra Drone株式会社 / 万年道半ばんちゅ
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
2020.7よりTerraDrone株式会社に参画
よく見られているレビュー

Terra Drone株式会社 / 万年道半ばんちゅ
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
2020.7よりTerraDrone株式...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


