Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ランニングコストやっべぇぞ!ECS/FargateでECRへのアクセスについて
Search
honma
May 24, 2023
Programming
13
4.2k
ランニングコストやっべぇぞ!ECS/FargateでECRへのアクセスについて
Qiita Night~AWS vol.2~
2023/05/24
honma
May 24, 2023
Tweet
Share
More Decks by honma
See All by honma
AWS IoT Coreのポリシー活用を熱く語ろう
honma12345
0
440
AWSを活用した ドローンIoTソリューション
honma12345
0
260
複数AWSアカウントに リソース構築する時 どうしてますか?
honma12345
1
2.5k
【再学習】リアルガチでCloudWatchを有効活用してますか?
honma12345
0
1.5k
自然言語解析AIサービス Dialogflowの紹介
honma12345
0
140
AWS IoT Coreを利用したドローンの実例
honma12345
0
460
AWS認定資格を8ヶ月で12冠達成した勉強法
honma12345
0
610
Other Decks in Programming
See All in Programming
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
420
AppRouterを用いた大規模サービス開発におけるディレクトリ構成の変遷と問題点
eiganken
1
440
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
10
5.1k
Запуск 1С:УХ в крупном энтерпрайзе: мечта и реальность ПМа
lamodatech
0
940
混沌とした例外処理とエラー監視に秩序をもたらす
morihirok
13
2.2k
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.4k
Package Traits
ikesyo
1
210
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
1k
QA環境で誰でも自由自在に現在時刻を操って検証できるようにした話
kalibora
1
140
Findy Team+ Awardを受賞したかった!ベストプラクティス応募内容をふりかえり、開発生産性向上もふりかえる / Findy Team Plus Award BestPractice and DPE Retrospective 2024
honyanya
0
140
BEエンジニアがFEの業務をできるようになるまでにやったこと
yoshida_ryushin
0
190
為你自己學 Python
eddie
0
520
Featured
See All Featured
Six Lessons from altMBA
skipperchong
27
3.6k
How to train your dragon (web standard)
notwaldorf
89
5.8k
Being A Developer After 40
akosma
89
590k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3.1k
For a Future-Friendly Web
brad_frost
176
9.5k
Raft: Consensus for Rubyists
vanstee
137
6.7k
How STYLIGHT went responsive
nonsquared
96
5.3k
Transcript
ランニングコストやっべぇぞ! ECS/FatgateでECRへのアクセスについて 2023/05/24 アイレット株式会社 本間 崇平 Qiita Night ~AWS vol.2~
自己紹介 本間 崇平 アイレット株式会社 アジャイル事業部 Shuhei Honma 2018年アイレット入社(平成最後の新卒) AWS歴5年 Web・IoTのサーバーサイドエンジニア
よく使うAWS: Amplify, Lambda, DynamoDBなどのサーレス郡 2022,2023受賞
1. 【前置き】今回お話するAWSリソースについて ◦ Fargate ◦ ECR ◦ NAT Gateway 2.
実際にあった話 3. どうするべきだったのか 4. まとめ 本日話すこと
Fargateについて
Fargateとは Fargateとは、コンテナ向けサーバーレスコンピューティング OSメンテナンス等の管理が不要 • AWSマネージドサービス ◦ EC2に比べてインスタンスのプロビジョン、スケール、管理不要 • 従量制料金のコンピューティングエンジン •
ECSやEKSで動作する • 要件によって、Lambda以上EC2未満であれば採択 • コスト最適化するうえで選択肢の1つ
ECRについて
ECR(Elastic Container Registry)とは ECRとは、フルマネージドDockerコンテナレジストリ コンテナソフトウェアを簡単に保存、共有、デプロイ • インフラ運用やスケーリングが不要 • 高耐久性・可用性 •
HTTPS経由で転送。保管時に自動で暗号化 • シンプルなワークフロー • ECRリポジトリにPushしたイメージを Fargate(ECS)で起動できる
NAT Gatewayについて
NAT Gatewayとは NAT Gatewayとは プライベートサブネット内からインターネットへ接続 • アベイラビリティーゾーン(AZ)別に作成 • VPC内に構成したインターネット接続できない プライベートシステムがNATGateway経由で
インターネットに出れることが可能に • 例えば、LambdaからIP制限された システムへアクセスするときに使える
ということで
実際にあった話
こんなアプリケーションを開発した • Lambdaなどのサーバーレスアーキテクチャ採用 • 納期スケジュールが短いため、早めに開発進める必要があった • アプリからデータを受信するAPIを開発 • データをもとに集計するバッチ機能を開発 •
集計機能は一定間隔でバッチ実行(Fargate) 実際にあった話
構築/実装したAWSアーキテクチャ(一部)
問題点
問題点 ~ランニングコスト~ • ECRがVPC外にあるため、NAT Gateway経由でインターネット仲介し ECRへアクセスをしていた • 急激なアクセスによってデータ転送が突発した時 ECSも一定間隔で起動していたのでNAT Gatewayの処理データも増えて
しまった • 冗長構成をとったうえでのNAT Gatewayも2つ用意することで 料金が更に倍
色々反省点あった • 開発優先重視して後先のこと考えず。。。 • アクセス過多の時、集計は100万件近いデータ処理が発生 • アクセス集中してない時でもランニングコストがかかっていた そもそもECSから外部インターネットへアクセスする必要なくない?
• Asia Pacific (Tokyo) ◦ NAT Gatewayあたりの料金 $0.062(時) ◦ 処理データ1GBあたりの料金
$0.062 • 例: $0.062 per NAT Gateway Hourだと ◦ 31日(744時間)×$0.062×2本(冗長構成分)= $92.256(税抜 約12,000円) • 例: $0.062 per GB Data Processed by NAT Gatewaysだと ◦ 2000GB(31日分の処理データ)×$0.062×2本(冗長構成分)= $248(税抜 約34,000円) NATGatewayの利用だけで合算すると毎月46,000円のランニングコスト NAT Gatewayコスト算出例
うおおおおおおおお
どうするべきだったのか
どうするべきだったのか VPC Endpoint(PrivateLink)を採用するべきだった
VPC Endpointとは VPCと他サービス間でプライベート接続を提供できる • VPCコンポーネント(仮想デバイス)である • VPC内のサービスとVPC外のサービスを プライベートに接続通信できる • セキュリティ上でインターネット接続せずに繋げれる
VPC Endpointを利用した場合のコスト算出例 • Asia Pacific (Tokyo) ◦ 各AZ VPC Endpoint
1つあたりの料金 $0.014(時) ◦ 処理データ1GBあたりの料金 ▪ リージョンで1ヶ月に処理されるデータ最初の1PBで $0.01 • 例: $0.014 per VPC Endpoint Hourだと ◦ 31日(744時間)×$0.014×2本(冗長構成分)= $20.832(税抜 約2,800円) • 例: $0.01 リージョンで1ヶ月に処理されるデータ1PB未満 ◦ $ 0.01(税抜 約1円) VPCEndpointの利用だけで合算すると毎月 2,800円で済む
あるべき姿のAWSアーキテクチャ(こうあるべきだった)
まとめ
まとめ 設計時で考慮しておかないと 運用コストが....
やっべぇぞ!
とにかく言いたいこと ドキュメントを読むのは当たり前だが 運用コストも算出しておこう
さいごに AWSの責はほぼない 設計・実装したお前の責である
完