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

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

No content

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

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

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

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

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

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

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

改善後のイメージ 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 しない

改善後のイメージ

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

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

Amazon S3 の リクエストとデータ取り出しの料⾦(東京リージョン) • S3 標準ストレージ • PUT、COPY、POST、LIST リクエスト (1,000 リクエストあたり) $0.0047 • GET、SELECT、他のすべてのリクエスト (1,000 リクエストあたり) $0.00037 15 → PUT/LIST リクエストは GET リクエストに⽐べて、 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 する

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

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

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

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 ＄ ＄ ＄ ＄＄＄

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

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/

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 マルチテナント構成によ るキャッシュの活⽤ コネクションプーリング の活⽤

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

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