ランニングコストやっべぇぞ！ECS/FargateでECRへのアクセスについて

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. Fargateについて
   

   View Slide

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

   View Slide

6. ECRについて
   

   View Slide

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

   View Slide

8. NAT Gatewayについて
   

   View Slide

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

   View Slide

10. ということで
    

    View Slide

11. 実際にあった話
    

    View Slide

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

    View Slide

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

    View Slide

14. 問題点
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. うおおおおおおおお
    

    View Slide

19. どうするべきだったのか
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. まとめ
    

    View Slide

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

    View Slide

26. やっべぇぞ！
    

    View Slide

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

    View Slide

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

    View Slide

29. 完
    

    View Slide