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

Amazon S3 Selectで実現するサーバーレス高負荷対応サイト

shiro seike
November 10, 2022

Amazon S3 Selectで実現するサーバーレス高負荷対応サイト

高負荷にも耐えられる動的サイトを作成したい
本要件に対してAmazon S3 Selectを利用したサーバーレスアーキテクチャを提案します
今回とあるシステムのAmazon RDSのデータを元にした
一時的な高負荷を想定しておくべきサイトの構築案件がありました
負荷対策としてAmazon API Gatewayにてキャッシュを行うAmazon S3 Select + AWS LambdaのAPIを作成し、
APIと連携するフロントエンドをAmazon CloudFrontから配信するサーバレスサイト構築事例についてお話します

shiro seike

November 10, 2022
Tweet

More Decks by shiro seike

Other Decks in Programming

Transcript

  1. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon S3 Selectで実現する サーバーレス⾼負荷対応サイト 清家史郎 (@seike460) D - 3 ︓ 2 0 2 2 / 1 1 / 1 0 1 5 : 0 0 - 1 5 : 4 5 株式会社Fusic チームリーダー/プリンシパルエンジニア/エバンジェリスト
  2. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Who am I? • 清家 史郎(@seike460) • 株式会社Fusic(From 福岡) • チームリーダー プリンシパルエンジニア エバンジェリスト • 技術コミュニティ好き • JAWS Days 2018-2020、2022 • AWS Dev Day 2021-2022
  3. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 1. サイト要件 2. アーキテクチャ選定 3. バックエンド構築 4. フロントエンド構築 5. CI/CD構築 6. 課題と対応⽅法 7. 運⽤結果とまとめ Agenda
  4. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. サイト要件
  5. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. サイト要件 今回のサイト要件には以下の要件存在した • 既存のスマホアプリのサブサイトとして構築する • ⼀定のタイミングでスパイクアクセスが発⽣する • サブサイトはスマホアプリと同じ情報元を利⽤する • 情報の検索を⾏う必要があり、情報の更新は⾏わない
  6. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. スマホアプリの状況
  7. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 負荷が来るタイミングはわかっている • 管理アプリからのプッシュ通知からのスパイクアクセス • 指定時間から可能になる申込によるスパイクアクセス 指定時間への申込は通常の構成ではスパイクアクセスに耐えられない
  8. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. スマホアプリ側の対策 Amazon Relational Database Service (Amazon RDS)への 負荷がボトルネックになる • Amazon Auroraのリードレプリカを利⽤して Read/Writeを負荷分散しつつ、強⼒なインスタンスサイズを選択 • ⾮同期に出来る処理を⾮同期化して、 アプリケーションへの同期的な負荷を低減 • 負荷試験を通してアプリケーションの最適化を⾏う • スパイクアクセス時に合わせて各所スケールアウトを⾏う
  9. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. スマホアプリ運⽤ スマホアプリは運⽤スキルの向上もあり安定稼働状態であった ⼀⽅でかなりの運⽤負荷が発⽣している事実があった このような状況から今回のサイト構築要件にて 運⽤負荷をこれ以上増やしたくないという希望があった スマホアプリ 運用グループ サイト 運用グループ
  10. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 2つの要件 スパイクアクセスへの対応 • 予測可能なスパイクアクセス • 通常構成では耐えられない事も 予測出来ている 運⽤負荷の低減 • スマホアプリと同⼀の Amazon RDSから情報取得 • 今まで培った運⽤スキルを コピーして運⽤を⾏うような 体制にしたくない サイト 運用グループ
  11. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. ⾼負荷対策をしたいが運⽤負荷は増やしたくない この時浮かんで来たのがServerless化というアイデア スマホアプリのバックエンドとなっているのはPHPで、 対応メンバーもメイン⾔語はPHPだった そこで⾏ったのがPHPのサーバーレスアプリ化 AWS Lambda x PHPを利⽤したアーキテクチャ構築
  12. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャ選定
  13. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. アーキテクチャ
  14. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. アーキテクチャ概要 ▪サブサイト アカウント • Amazon S3 Select Lambda • CloudFront + S3 • AWS IAM PassRole ▪スマホアプリ アカウント • Amazon EventBridge • AWS Fargate Batch • AWS IAM AssumeRole
  15. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. データ⽣成アーキテクチャ • スマホアプリアカウント • Fargateでサブサイトに 必要なデータを定期的に更新する 前述の通りリードレプリカを利⽤ • 既存のTerraformに IAMAssumeRoleを追加 サブサイトアカウントのS3へ Jsonデータ挿⼊を⾏う
  16. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. バックエンドアーキテクチャ • Amazon S3 Select Lambda • Amazon API Gateway + Lambda • RDBMS -> Amazon S3 Select 理論上のボトルネックを RDSからLambdaに移す
  17. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. フロントエンドアーキテクチャ • CloudFront + S3 • CloudFront と S3の静的配信で フロントエンドを配信 • CloudFrontでのキャッシュを利⽤ フロントエンド速度を向上する事で バックエンドへの接続待ちを 滞留させない
  18. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. バックエンド構築
  19. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Bref PHPのCustom Runtime環境を 簡単に構築出来るツール • Serverless Frameworkを利⽤ • AWS Serverless Application Model(SAM)でも利⽤可能 • 公開 Docker Imageも DockerHubで存在するので 開発⽤のDockerComposeも 容易に準備可能
  20. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Laravel • PHPのデファクトスタンダード Webフレームワークと⾔っても 過⾔ではないフレームワーク • AWSとの相性も抜群で S3への接続やSESへの接続、 SQSへの接続等カジュアルに AWSを利⽤することが出来る • Bref公式サイトにてLaravelの 導⼊⽅法も⽰されている為、 スムーズに導⼊可能
  21. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Laravel bref を組み合わせる # Laravelを通常どうりインストール $ composer create-project laravel/laravel testProject # brefパッケージをインストール $ composer require bref/bref bref/laravel-bridge -- update-with-dependencies # serverless.ymlの⽣成 $ php artisan vendor:publish --tag=serverless-config PHP8.1を使いたい場合はphp-80 -> php-81へ変更 ※既に8.2を実験的に提供されています
  22. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. AWS S3 Select • AWS S3にあるJSONやCSVに 対して、フィルタリングした 結果を返してくれる • SQLの主要な構⽂は ほとんど使える • ⼀⽅でOffsetが存在しない このような制限があることは 理解しておく必要がある
  23. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. S3 Select⽤の基底クラスの作成 • Webフレームワークでは ⼀般的にModel層が データアクセスを受け持ちます • RDBMSへのアクセスを受け持つ Laravelの基底Modelの継承を、 独⾃作成したS3Select⽤Modelに 置き換える
  24. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 取得データの考え⽅ • RDBMSからデータを取得する要領で S3 Selectからデータを取得する • Webフレームワークの概念 • データベース→バケット • テーブル→Jsonファイル • レコード→Jsonオブジェクト • リレーション • レコード取得後にPHP側で リレーション構築可能と考察 • 実際はJson作成時にRDBMSへのSQLにて Joinした値をJsonファイルに設定した
  25. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 検索 • フリーワード検索 • S3 Select LIKE • AND OR 検索 • S3 Select AND OR • リレーション先への検索 • Jsonにリレーション情報保存し、 リレーション先の値で検索
  26. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド構築
  27. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. svelte • CloudFront配信のフロントエンド • UIを作成するための コンポーネントベースの JavaScriptフレームワーク • ⽐較的Vanilla JSと同じ感覚で 利⽤出来て、記述量も少ないので 短期間での構築に向いている
  28. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. カジュアルにState管理が出来る Svelteを整備してくれた チームメイトがいた事が⼤きいが とても良い選択をしてくれた • 少ない記述量でのState管理 • 値の共有を⾏うStore機能 フロントエンドが得意領域ではない ⾃分にはすごくシンプルに⼊り込めた
  29. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Vite 前述のフロントエンドを 整えてくれたチームメイトが 最初から導⼊済み • 開発サーバーの起動が爆速 • 開発サーバーの更新も爆速 • envファイルによる環境変数設定も可能
  30. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Tailwind CSS • 前述のフロントエンドを 整えてくれたチームメイトが 最初から導⼊済み • CSS初期設定後の 組込側の微調整も容易で ドキュメント含めて充実していた • ⼀⽅でCSSへの理解⼒がある チームメイトがいた事が⼤きいと感じた
  31. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. CI/CD構築
  32. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Serverless Framework • Serverless Framework • 簡単にLambdaをデプロイする事が 可能な構成管理デプロイツール • Yamlを記述することで簡単に API Gateway付きのLambdaが 構築出来る • Yaml内にAWS CloudFormationの 記法も出来る為、CloudFrontも ここで構成管理が可能
  33. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. GitHub Actions GitHubへのPushやMergeを契機に 動作するCI/CDパイプライン GitHubにてソースコード管理を している時にカジュアルに利⽤可
  34. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. GitHubのbrunch マージを契機にデプロイ • backend • Serverless framework deploy • frontend • aws s3 sync • aws cloudfront create-invalidation • frontendとbackend分けてDeploy • CIも同様に切り分け
  35. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 課題と対応⽅法
  36. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. リアルタイム性 データ更新後にEventBridgeを経て データJsonが作成される 情報の即時性について要件の すり合わせを⾏い30分に ⼀度の更新を⾏う⽅針で解決 また即時更新でなくても良いことで CloudFrontキャッシュ利⽤も可能に
  37. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Lambdaの制限 1 Lambdaの最⼤ペイロードサイズは6MB 変更不可能な制限 こちらを回避するために、 ペイロード制限を⾏う必要があった UIから必要とされるFieldを精査 S3Slectにて取得するカラムの制限を ⾏うことでペイロードを減らした これでも駄⽬ならペイロード圧縮も 試すつもりだったが 今回はそこまで必要なかった
  38. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Lambdaの制限 2 全てのカラムが必要な箇所は、 UI側でのページング実装 S3 Select はOffsetのSQL⾮対応 Limit OffsetをPHP側で対応することで 容易に対応出来た
  39. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. AWS マネージドサービスにおけるキャッシュ スループット向上の為に、 API Gatewayのキャッシュを検討 結論、検討の結果API Gatewayの キャッシュは⾏わなかった 後述のパフォーマンスとコスト等の 総合的な判断を⾏った
  40. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 負荷試験 • 実際の負荷に耐えれるのかを 検証するために負荷試験を実施 • CloudFront等のフロントエンドが ボトルネックになることは考え⾟い • バックエンドのLambda + S3 Select に対してApache Benchによる 負荷試験を実施
  41. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. API Gateway キャッシュ利⽤ Brefのデフォルト設定ではAPI Gatewayを HTTP APIとして利⽤している 記述変更によりRest APIへの変更 その後キャッシュを有効化を⾏う
  42. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 負荷試験結果 (500クライアント、2000リクエスト) 0 100 200 300 400 500 600 700 800 900 RPS 500Client – 2000Request GET500 GETキャッシュ500 POST500 ※POSTは検索により 1/10のデータ量
  43. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 負荷試験結果 (100クライアント、200000リクエスト) 0 200 400 600 800 1000 1200 RPS 100Client – 200000Request GET100 GET100キャッシュ POST100 Clod Startが慣らされる事で 更にスループットの上昇 API Gateway のキャッシュは スループットが上がらない 結果となってしまった
  44. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 負荷試験結果 (1000クライアント、200000リクエスト) 0 200 400 600 800 1000 1200 RPS 1000Client – 200000Request GET1000 POST1000 S3 Selectの限界は来るので 必ず検証が必要
  45. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. API Gateway キャッシュについての判断 AWS S3 Select Lambdaの パフォーマンスがかなり良好だった キャッシュにおける 「時間あたりの料⾦」は 本構成において費⽤インパクトあった デフォルトではGETのみ対応であり 設定変更などの管理項⽬が増える キャッシュの適切な利⽤が出来ていない 総合的な判断で⾏わない事にした
  46. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 運⽤結果とまとめ
  47. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 現在の運⽤状況 Custom Runtime運⽤に対する不安や、 リクエストに耐えれるか不安はあったが、特に問題が起きていない 運⽤の負荷もほぼないに等しく、CloudWatchも安定している 今回の2つの要件を同時に解決出来たと考えます 理論を元に検証を⾏い、対策が打てた事が⼤きいと感じている
  48. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 運⽤コスト API GatewayやLambdaの使⽤量を⾒る限り、 リクエストが少ないわけではない Fargate + RDSでの対応なら、⼤きめのリソースをあてたくなります 前述の運⽤する上での⼈⼒コストの低減に合わせて AWS 利⽤料も合わせて考えるとかなりコストインパクトが⼤きい
  49. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. S3 Select Lambdaの選択に対して S3 Selectをアーキテクチャに選択したことは成功だったと考えます 要件をアーキテクチャに落とし込む際に、 制限の中でしっかり検証することでシステムに付加価値を出せました
  50. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. API Gatewayのキャッシュについて 正しく利⽤出来ていない可能性も否定出来ない ⼀⽅で検証結果を元に⽅針の変更も⾏ったのは、 知識を正しく運⽤するという⾯において正しい判断の可能性もある
  51. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 今後の導⼊やスキル継承について 別プロジェクトでも導⼊を進めている Laravel + AWSの相性の良さもあり、実装が簡略化出来る 現在別のプロジェクトにてSESへの対応など含めて 私の代わりに若⼿のPHPerがコーディング中であり スキル継承も滞りなく⾏えると感じています
  52. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 知識を最⼤限に⽣かして価値提供 AWSは数百万のビジネスを⽀えており、 リクエストを⽀える基盤は整っている 出来る、出来ないを正しく理解して検証、導⼊することで、 エンジニアリングにおけるさらなる価値提供が可能
  53. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Thank you! © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 清家 史郎 株式会社 Fusic @seike460