Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

よくあるケースから学ぶ!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

はまーん
PRO

November 22, 2022
Tweet

More Decks by はまーん

Other Decks in Programming

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. 仮想ストーリー 2:
    うわっ...私の 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