よくあるケースから学ぶ！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】
2. まつだ スタートアップ SA ふじわら ISV/SaaS SA (⻄⽇本担当) はま スタートアップ SA (⻄⽇本担当)
4. あくまでも、よくあるケース(仮想ストーリー)です︕ • 「推測するな 計測せよ」 − コスト最適化において、基本的には銀の弾丸はないです − ⾃分達のワークロードを⾒つめ直すところがスタートライン • 本⽇紹介する話は 1day とかで終わるようなタスクではないです − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか • その上で、、、 仮想ストーリーをもとに、こんな作りにしていると コストが必要以上に増加するケースを紹介していきます︕
5. 仮想ストーリー 1: うわっ...私の NAT Gateway、 ⾼すぎ...?
6. シチュエーション Private subnet Public subnet データベース イメージレジストリ (ECR) NAT Gateway 定期実⾏されるコンテナ AWS Fargate Fargate で実⾏するコンテナは 実⾏のたびにコンテナイメージを pull する
7. シチュエーション Private subnet Public subnet データベース イメージレジストリ (ECR) NAT Gateway 定期実⾏されるコンテナ AWS Fargate 定期実⾏ジョブだとその度にイメージが pull される。 イメージサイズが⼤きく頻繁に実⾏するジョブだと Nat Gateway を通るデータ転送コストが 無視できないくらい⼤きくなる。
8. 改善後のイメージ Private subnet Public subnet データベース イメージレジストリ (ECR) NAT Gateway VPC Endpoint 定期実⾏されるコンテナ AWS Fargate 利⽤規模次第では VPC Endpoint 経由で ECR から イメージを Pull することで⼤幅にコスト削減になる。
9. 仮想ストーリー ２: うわっ...私の NAT Gateway、 多すぎ...?
10. Private subnet Public subnet シチュエーション Availability Zone 3 Availability Zone 2 Availability Zone 1 NAT Gateway コンピューティング リソース Private subnet Public subnet Private subnet Public subnet
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 しない
12. 改善後のイメージ
13. 仮想ストーリー 3: S3 に細かく書き込みすぎパターン
14. シチュエーション インターネット Amazon API Gateway Amazon S3 AWS Lambda ⼤量の IoTデバイス 10sec おきに 各デバイスから ログの書き込み デバイス毎にS3バケットに対する Put/List API リクエスト
15. Amazon S3 の リクエストとデータ取り出しの料⾦(東京リージョン) • S3 標準ストレージ • PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり) $0.0047 • GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり) $0.00037 15 → PUT/LIST リクエストは GET リクエストに⽐べて、 10倍以上⾼額
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 する
17. 改善後のイメージ インターネット Amazon API Gateway Amazon S3 ⼤量の IoTデバイス 10sec おきに 各デバイスから ログの書き込み Firehose でバッファリングして バッチ書き込み Amazon Kinesis Data Streams Amazon Kinesis Data Firehose
18. 仮想ストーリー 4: Amazon Aurora Table 多すぎパターン
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
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 ＄ ＄ ＄ ＄＄＄
21. 必要以上なコスト上昇の理由 • テナント毎に Database を分割した結果、グロース期のテナント数増加に合わせて Table 数も増加 • MySQL バッファプールや PostgreSQL 共有バッファは Table 毎にページ単位でキャッシュを⾏うた め、 頻繁に使⽤されるデータがキャッシュアウトし、Cluster Volume の読み込み I/O が増加 • コネクションプーリングを利⽤できないため、リクエストのたびに Database 接続・切断を繰り返 し、App Server instance、Aurora instance 両⽅の CPU 使⽤率が増加、安定稼働のためにより⼤き な instance type を利⽤ 改善策 • Database を単⼀化し Table をマルチテナント構成に変更、RDB エンジンのキャッシュやコネクシ ョンプーリングを活⽤ • PostgreSQL の⾏レベルセキュリティ (RLS) の活⽤、アプリ側でデータ・アクセス・レイヤーを設 けて抽象化し、テナント毎のデータアクセスポリシーの適⽤と開発・運⽤の負担を低減
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/
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 マルチテナント構成によ るキャッシュの活⽤ コネクションプーリング の活⽤
24. あくまでも、よくあるケース(仮想ストーリー)です︕ • 「推測するな 計測せよ」 − コスト最適化において、基本的には銀の弾丸はないです − ⾃分達のワークロードを⾒つめ直すところがスタートライン • 本⽇紹介した話は 1day とかで終わるようなタスクではないです − 今のビジネスフェーズにおいて、機能開発ではなくコスト最適化に⼈⼿を⼤きく割くべきか • ⾃分達のワークロードについて⼀緒に⾒直してほしいという⽅は 貴社担当者までお問い合わせください
25. Thank you © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Shinichi Hama track3jyo