Slide 1

Slide 1 text

ランニングコストやっべぇぞ! ECS/FatgateでECRへのアクセスについて 2023/05/24 アイレット株式会社 本間 崇平 Qiita Night ~AWS vol.2~

Slide 2

Slide 2 text

自己紹介 本間 崇平 アイレット株式会社 アジャイル事業部 Shuhei Honma 2018年アイレット入社(平成最後の新卒) AWS歴5年 Web・IoTのサーバーサイドエンジニア よく使うAWS: Amplify, Lambda, DynamoDBなどのサーレス郡 2022,2023受賞

Slide 3

Slide 3 text

1. 【前置き】今回お話するAWSリソースについて ○ Fargate ○ ECR ○ NAT Gateway 2. 実際にあった話 3. どうするべきだったのか 4. まとめ 本日話すこと

Slide 4

Slide 4 text

Fargateについて

Slide 5

Slide 5 text

Fargateとは Fargateとは、コンテナ向けサーバーレスコンピューティング OSメンテナンス等の管理が不要 ● AWSマネージドサービス ○ EC2に比べてインスタンスのプロビジョン、スケール、管理不要 ● 従量制料金のコンピューティングエンジン ● ECSやEKSで動作する ● 要件によって、Lambda以上EC2未満であれば採択 ● コスト最適化するうえで選択肢の1つ

Slide 6

Slide 6 text

ECRについて

Slide 7

Slide 7 text

ECR(Elastic Container Registry)とは ECRとは、フルマネージドDockerコンテナレジストリ コンテナソフトウェアを簡単に保存、共有、デプロイ ● インフラ運用やスケーリングが不要 ● 高耐久性・可用性 ● HTTPS経由で転送。保管時に自動で暗号化 ● シンプルなワークフロー ● ECRリポジトリにPushしたイメージを Fargate(ECS)で起動できる

Slide 8

Slide 8 text

NAT Gatewayについて

Slide 9

Slide 9 text

NAT Gatewayとは NAT Gatewayとは プライベートサブネット内からインターネットへ接続 ● アベイラビリティーゾーン(AZ)別に作成 ● VPC内に構成したインターネット接続できない プライベートシステムがNATGateway経由で インターネットに出れることが可能に ● 例えば、LambdaからIP制限された システムへアクセスするときに使える

Slide 10

Slide 10 text

ということで

Slide 11

Slide 11 text

実際にあった話

Slide 12

Slide 12 text

こんなアプリケーションを開発した ● Lambdaなどのサーバーレスアーキテクチャ採用 ● 納期スケジュールが短いため、早めに開発進める必要があった ● アプリからデータを受信するAPIを開発 ● データをもとに集計するバッチ機能を開発 ● 集計機能は一定間隔でバッチ実行(Fargate) 実際にあった話

Slide 13

Slide 13 text

構築/実装したAWSアーキテクチャ(一部)

Slide 14

Slide 14 text

問題点

Slide 15

Slide 15 text

問題点 ~ランニングコスト~ ● ECRがVPC外にあるため、NAT Gateway経由でインターネット仲介し ECRへアクセスをしていた ● 急激なアクセスによってデータ転送が突発した時 ECSも一定間隔で起動していたのでNAT Gatewayの処理データも増えて しまった ● 冗長構成をとったうえでのNAT Gatewayも2つ用意することで 料金が更に倍

Slide 16

Slide 16 text

色々反省点あった ● 開発優先重視して後先のこと考えず。。。 ● アクセス過多の時、集計は100万件近いデータ処理が発生 ● アクセス集中してない時でもランニングコストがかかっていた そもそもECSから外部インターネットへアクセスする必要なくない?

Slide 17

Slide 17 text

● 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コスト算出例

Slide 18

Slide 18 text

うおおおおおおおお

Slide 19

Slide 19 text

どうするべきだったのか

Slide 20

Slide 20 text

どうするべきだったのか VPC Endpoint(PrivateLink)を採用するべきだった

Slide 21

Slide 21 text

VPC Endpointとは VPCと他サービス間でプライベート接続を提供できる ● VPCコンポーネント(仮想デバイス)である ● VPC内のサービスとVPC外のサービスを プライベートに接続通信できる ● セキュリティ上でインターネット接続せずに繋げれる

Slide 22

Slide 22 text

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円で済む

Slide 23

Slide 23 text

あるべき姿のAWSアーキテクチャ(こうあるべきだった)

Slide 24

Slide 24 text

まとめ

Slide 25

Slide 25 text

まとめ 設計時で考慮しておかないと 運用コストが....

Slide 26

Slide 26 text

やっべぇぞ!

Slide 27

Slide 27 text

とにかく言いたいこと ドキュメントを読むのは当たり前だが 運用コストも算出しておこう

Slide 28

Slide 28 text

さいごに AWSの責はほぼない 設計・実装したお前の責である

Slide 29

Slide 29 text