$30 off During Our Annual Pro Sale. View Details »

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

はまーん

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】
  2. あくまでも、よくあるケース(仮想ストーリー)です︕ • 「推測するな 計測せよ」 − コスト最適化において、基本的には銀の弾丸はないです − ⾃分達のワークロードを⾒つめ直すところがスタートライン • 本⽇紹介する話は

    1day とかで終わるようなタスクではないです − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか • その上で、、、 仮想ストーリーをもとに、こんな作りにしていると コストが必要以上に増加するケースを紹介していきます︕
  3. シチュエーション Private subnet Public subnet データベース イメージレジストリ (ECR) NAT Gateway

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

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

    VPC Endpoint 定期実⾏されるコンテナ AWS Fargate 利⽤規模次第では VPC Endpoint 経由で ECR から イメージを Pull することで⼤幅にコスト削減になる。
  6. Private subnet Public subnet シチュエーション Availability Zone 3 Availability Zone

    2 Availability Zone 1 NAT Gateway コンピューティング リソース Private subnet Public subnet Private subnet Public subnet
  7. 改善後のイメージ 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 しない
  8. シチュエーション インターネット Amazon API Gateway Amazon S3 AWS Lambda ⼤量の

    IoTデバイス 10sec おきに 各デバイスから ログの書き込み デバイス毎にS3バケットに対する Put/List API リクエスト
  9. Amazon S3 の リクエストとデータ取り出しの料⾦(東京リージョン) • S3 標準ストレージ • PUT、COPY、POST、LIST リクエスト

    (1,000 リクエストあたり) $0.0047 • GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり) $0.00037 15 → PUT/LIST リクエストは GET リクエストに⽐べて、 10倍以上⾼額
  10. 必要以上なコスト上昇の理由 • デバイス毎に 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 する
  11. 改善後のイメージ インターネット Amazon API Gateway Amazon S3 ⼤量の IoTデバイス 10sec

    おきに 各デバイスから ログの書き込み Firehose でバッファリングして バッチ書き込み Amazon Kinesis Data Streams Amazon Kinesis Data Firehose
  12. 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
  13. 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 $ $ $ $$$
  14. 必要以上なコスト上昇の理由 • テナント毎に Database を分割した結果、グロース期のテナント数増加に合わせて Table 数も増加 • MySQL バッファプールや

    PostgreSQL 共有バッファは Table 毎にページ単位でキャッシュを⾏うた め、 頻繁に使⽤されるデータがキャッシュアウトし、Cluster Volume の読み込み I/O が増加 • コネクションプーリングを利⽤できないため、リクエストのたびに Database 接続・切断を繰り返 し、App Server instance、Aurora instance 両⽅の CPU 使⽤率が増加、安定稼働のためにより⼤き な instance type を利⽤ 改善策 • Database を単⼀化し Table をマルチテナント構成に変更、RDB エンジンのキャッシュやコネクシ ョンプーリングを活⽤ • PostgreSQL の⾏レベルセキュリティ (RLS) の活⽤、アプリ側でデータ・アクセス・レイヤーを設 けて抽象化し、テナント毎のデータアクセスポリシーの適⽤と開発・運⽤の負担を低減
  15. 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/
  16. 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 マルチテナント構成によ るキャッシュの活⽤ コネクションプーリング の活⽤
  17. あくまでも、よくあるケース(仮想ストーリー)です︕ • 「推測するな 計測せよ」 − コスト最適化において、基本的には銀の弾丸はないです − ⾃分達のワークロードを⾒つめ直すところがスタートライン • 本⽇紹介した話は

    1day とかで終わるようなタスクではないです − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか • ⾃分達のワークロードについて⼀緒に⾒直してほしいという⽅は 貴社担当者までお問い合わせください
  18. Thank you © 2022, Amazon Web Services, Inc. or its

    affiliates. All rights reserved. Shinichi Hama track3jyo