よくあるケースから学ぶ！AWS で想定外のコスト増につながるような実装や設計

【AWS Startup.fm】スタートアップでコストが上がりがちなケースを学ぼう！『コスト最適化セミナー』
2022-11-22 15:00 - 16:00 JST
Speaker: AWS 松田 和樹、濱 真一、藤原 吉規

https://aws-startup-lofts.com/apj/event/6a4145f6-6ef0-40e8-966d-dacf7784b559

Transcript

1. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   よくあるケースから学ぶ︕
   AWS で想定外のコスト増に
   つながるような実装や設計
   【AWS Startup.fm】
   

   View Slide

2. まつだ
   スタートアップ SA
   ふじわら
   ISV/SaaS SA
   (⻄⽇本担当)
   はま
   スタートアップ SA
   (⻄⽇本担当)
   

   View Slide

3. View Slide

4. あくまでも、よくあるケース(仮想ストーリー)です︕
   • 「推測するな 計測せよ」
   − コスト最適化において、基本的には銀の弾丸はないです
   − ⾃分達のワークロードを⾒つめ直すところがスタートライン
   • 本⽇紹介する話は 1day とかで終わるようなタスクではないです
   − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか
   • その上で、、、
   仮想ストーリーをもとに、こんな作りにしていると
   コストが必要以上に増加するケースを紹介していきます︕
   

   View Slide

5. 仮想ストーリー 1:
   うわっ...私の NAT Gateway、 ⾼すぎ...?
   

   View Slide

6. シチュエーション
   Private subnet
   Public subnet
   データベース
   イメージレジストリ
   (ECR)
   NAT Gateway 定期実⾏されるコンテナ
   AWS Fargate
   Fargate で実⾏するコンテナは
   実⾏のたびにコンテナイメージを pull する
   

   View Slide

7. シチュエーション
   Private subnet
   Public subnet
   データベース
   イメージレジストリ
   (ECR)
   NAT Gateway 定期実⾏されるコンテナ
   AWS Fargate
   定期実⾏ジョブだとその度にイメージが pull される。
   イメージサイズが⼤きく頻繁に実⾏するジョブだと
   Nat Gateway を通るデータ転送コストが
   無視できないくらい⼤きくなる。
   

   View Slide

8. 改善後のイメージ
   Private subnet
   Public subnet
   データベース
   イメージレジストリ
   (ECR)
   NAT Gateway
   VPC Endpoint
   定期実⾏されるコンテナ
   AWS Fargate
   利⽤規模次第では VPC Endpoint 経由で ECR から
   イメージを Pull することで⼤幅にコスト削減になる。
   

   View Slide

9. 仮想ストーリー ２:
   うわっ...私の NAT Gateway、 多すぎ...?
   

   View Slide

10. Private subnet
    Public subnet
    シチュエーション
    Availability Zone 3
    Availability Zone 2
    Availability Zone 1
    NAT Gateway コンピューティング
    リソース
    Private subnet
    Public subnet
    Private subnet
    Public subnet
    

    View Slide

11. 改善後のイメージ
    Availability Zone 3
    Availability Zone 2
    Availability Zone 1
    NAT Gateway コンピューティング
    リソース
    Private subnet
    Public subnet
    Private subnet
    Public subnet
    Private subnet
    Public subnet
    信頼性とのトレードオフですが、
    アプリケーション起点での外部の通信要件次第では
    Nat Gateway 1 台構成も選択肢
    ⾮機能要件に対して Over Engineering しない
    

    View Slide

12. 改善後のイメージ
    

    View Slide

13. 仮想ストーリー 3:
    S3 に細かく書き込みすぎパターン
    

    View Slide

14. シチュエーション
    インターネット Amazon
    API Gateway
    Amazon S3
    AWS Lambda
    ⼤量の
    IoTデバイス
    10sec おきに
    各デバイスから
    ログの書き込み
    デバイス毎にS3バケットに対する
    Put/List API リクエスト
    

    View Slide

15. Amazon S3 の リクエストとデータ取り出しの料⾦(東京リージョン)
    • S3 標準ストレージ
    • PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり)
    $0.0047
    • GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり)
    $0.00037
    15
    → PUT/LIST リクエストは GET リクエストに⽐べて、
    10倍以上⾼額
    

    View Slide

16. 必要以上なコスト上昇の理由
    • デバイス毎に 10sec おきに、バッファリングなしで S3 への Put/List API を実⾏
    • デバイス数増加に伴い S3 の Put / List API コストが増加していく
    • S3 に配置しているデータのライフサイクルは制御しているが、
    S3 の API リクエストのコストを軽視していた
    e.g. ) 10000 デバイスが 10sec おきに書き込みした場合
    10000 デバイス x 6*60*24*30/1000 * 0.0047USD = $12182.4USD
    改善策
    • リアルタイム要件がないのであれば、書き込みをバッファリングをして Bulk Upload する
    

    View Slide

17. 改善後のイメージ
    インターネット
    Amazon
    API Gateway
    Amazon S3
    ⼤量の
    IoTデバイス
    10sec おきに
    各デバイスから
    ログの書き込み
    Firehose でバッファリングして
    バッチ書き込み
    Amazon Kinesis
    Data Streams
    Amazon Kinesis
    Data Firehose
    

    View Slide

18. 仮想ストーリー 4:
    Amazon Aurora
    Table 多すぎパターン
    

    View Slide

19. Availability Zone c
    Availability Zone b
    Availability Zone a
    Cluster Volume
    シチュエーション: SaaS シード・アーリー期
    テナント毎
    Database
    50 Tables
    ...
    Application Load
    Balancer
    Data Copies
    App Server
    instances
    Amazon Aurora instance writer
    50 x 20 テナント = 1,000 Tables
    ...
    Client
    

    View Slide

20. Availability Zone c
    Availability Zone b
    Availability Zone a
    Cluster Volume
    シチュエーション: SaaS グロース期
    テナント毎
    Database
    50 Tables
    ...
    Application Load
    Balancer
    Data Copies
    App Server
    instances
    Amazon Aurora instance writer
    50 x 2,000 テナント = 100,000 Tables
    ...
    Client
    ＄
    ＄
    ＄
    ＄＄＄
    

    View Slide

21. 必要以上なコスト上昇の理由
    • テナント毎に Database を分割した結果、グロース期のテナント数増加に合わせて Table 数も増加
    • MySQL バッファプールや PostgreSQL 共有バッファは Table 毎にページ単位でキャッシュを⾏うた
    め、 頻繁に使⽤されるデータがキャッシュアウトし、Cluster Volume の読み込み I/O が増加
    • コネクションプーリングを利⽤できないため、リクエストのたびに Database 接続・切断を繰り返
    し、App Server instance、Aurora instance 両⽅の CPU 使⽤率が増加、安定稼働のためにより⼤き
    な instance type を利⽤
    改善策
    • Database を単⼀化し Table をマルチテナント構成に変更、RDB エンジンのキャッシュやコネクシ
    ョンプーリングを活⽤
    • PostgreSQL の⾏レベルセキュリティ (RLS) の活⽤、アプリ側でデータ・アクセス・レイヤーを設
    けて抽象化し、テナント毎のデータアクセスポリシーの適⽤と開発・運⽤の負担を低減
    

    View Slide

22. Aurora I/O 料⾦
    5 分毎の I/O が 5,000,000 リクエスト
    の場合の 1⽇あたりの I/O 料⾦
    5M x 60 分/ 5 分 x 24 時間 x $0.24 /
    1M = $345.6
    https://aws.amazon.com/jp/rds/aurora/pricing/
    

    View Slide

23. Availability Zone c
    Availability Zone b
    Availability Zone a
    Cluster Volume
    改善後のイメージ
    Database
    50 Tables
    Application Load
    Balancer
    Data Copies
    App Server
    instances
    Amazon Aurora instance writer
    Client
    tenant_id user_id name
    TenantA UserA Fujiwara
    TenantB UserB Hama
    TenantC UserC Mazda
    TenantD UserD Honda
    ...
    2,000 テナント、50 Tables
    マルチテナント構成によ
    るキャッシュの活⽤
    コネクションプーリング
    の活⽤
    

    View Slide

24. あくまでも、よくあるケース(仮想ストーリー)です︕
    • 「推測するな 計測せよ」
    − コスト最適化において、基本的には銀の弾丸はないです
    − ⾃分達のワークロードを⾒つめ直すところがスタートライン
    • 本⽇紹介した話は 1day とかで終わるようなタスクではないです
    − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか
    • ⾃分達のワークロードについて⼀緒に⾒直してほしいという⽅は
    貴社担当者までお問い合わせください
    

    View Slide

25. Thank you
    © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    Shinichi Hama
    track3jyo
    

    View Slide