Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

ハイトラフィック運用 〜スループットの向上を目指して

昨今のWEBではスピードが求められるようになりました。ボトルネックを排除しチューニングと向き合い最高のUXを届けられる戦略を紹介します。

■Developers.IO 2020 CONNECTのイベントページ
https://classmethod.jp/m/devio_2020_connect/

■動画内でご紹介したブログやサイト
Amazon CloudFront クォータ
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html

オリジンからのエラーレスポンスのトラブルシューティング
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html

[AWS Black Belt Online Seminar] Elastic Load Balancing (ELB) 資料及び QA 公開
https://aws.amazon.com/jp/blogs/news/webinar-bb-elastic-load-balancing-2019/

Application Load Balancer のトラブルシューティング
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html

[障害対応] ALB で502エラーが発生!!その時あなたはどうする!?
https://dev.classmethod.jp/articles/badgateway-error-alb/

ターゲットグループのヘルスチェック
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html

[速報]コールドスタート対策のLambda定期実行とサヨナラ!!
LambdaにProvisioned Concurrencyの設定が追加されました  #reinvent
https://dev.classmethod.jp/articles/lambda-support-provisioned-concurrency/

Lambdaのメモリ割り当てを自動で最適化!!AWS Lambda Power Tuning
https://dev.classmethod.jp/articles/aws-lambda-power-tuning/

AWS Lambda 関数を使用する際のベストプラクティス
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html

Lambdaのhandler外(メソッド以外)のコードは「コールドスタート時の1回だけ実行される」という話
https://dev.classmethod.jp/articles/lambda-outside-handler-running-first/

【アップデート】Amazon Auroraでスロークエリや一般ログがCloudWatch Logsへ出力可能に
https://dev.classmethod.jp/articles/amazon-aurora-export-cloudwatch-logs/

RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました
https://dev.classmethod.jp/articles/rds-mysql-mariadb-export-cloudwatch-logs/

Amazon RDS が Amazon CloudWatch Logs への PostgreSQL ログファイルの発行をサポート
https://aws.amazon.com/jp/about-aws/whats-new/2018/12/amazon-rds-supports-postgresql-logfiles-publish-to-amazon-cloudwatch-logs/

■出演者プロフィール
深澤 俊
AWS事業本部コンサルティング部
ソリューションアーキテクト
ブログ→ https://dev.classmethod.jp/author/fukazawa-shun/

■クラスメソッドの詳細
コーポレートサイト→https://classmethod.jp/
「やってみた」系技術メディア「Developers.IO」→https://dev.classmethod.jp/
Facebook→https://www.facebook.com/classmethod/
Twitter→https://twitter.com/classmethod

  • Als Erste(r) kommentieren

ハイトラフィック運用 〜スループットの向上を目指して

  1. 1. ハイトラフィック運用 〜スループットの向上を目指して〜 2020/06/16 深澤 俊
  2. 2. 2自己紹介 深澤 俊(Fukazawa Shun) WEBアプリケーションエンジニア ↓ SRE ↓ AWS事業本部コンサルティング部 好きなAWSサービス ElastiCache、DynamoDB @shun_quartet
  3. 3. 3突然ですが… こんな悩みを抱えてはいませんか?
  4. 4. 4こんな悩み抱えていませんか? 今のwebサイトのスピードを もっと上げたい
  5. 5. 5こんな悩み抱えていませんか? アクセスピーク時にエラー画面が ユーザに表示されてしまう
  6. 6. 6こんな悩み抱えていませんか? サーバ台数を増やしたけど、 webサイトのレスポンススピード が上がらない
  7. 7. 7 せっかくの大人気webサイト、 最高のエクスペリエンスをユーザ に届けましょう!!
  8. 8. 8最高のエクスペリエンス 最高のエクスペリエンス ↓ スループットの向上 ↓ この中からボトルネック を探して取り除く
  9. 9. 9 今回はボトルネックの特定や チューニング方法をご紹介
  10. 10. 10注意点 • 今回の発表では観点をメインに紹介します • それぞれのエンジン等による細かい違いや チューニング方法には触れません • 例:MysqlとPostgras等 • メトリクスはCloudWatchのものをご紹介しま す
  11. 11. 11注意点 • 今回はあくまで概要と基本です • 障害原因やチューニング方法に鋼の弾丸はあ りません • ご紹介した以外にも有益なメトリクスはあり ますので、是非今回を機に他のメトリクスも 確認していただけたら嬉しいです。
  12. 12. 12問題とゴールの決定 • まずは現在の問題とゴールを定める • CloudWatch Synthetics等を用いた外形監視確 認  ユーザ目線でどんな問題が発生しているか • レイテンシを下げたい? • チューニング • 障害発生中? • 原因特定と解消
  13. 13. 13First Step CloudFrontの確認
  14. 14. 14CloudFrontの確認
  15. 15. 15CloudFrontでの観点 • そもそもDNSで障害は発生していないか? • リクエスト数が落ち込んでいないか確認  DNSで誤ってレコードを削除などの可能性も CloudFront Route 53(DNS) User
  16. 16. 16CloudFrontでの観点 • Lambda@Edgeを採用している場合: • タイムアウトは発生していないか?  外部APIの遅延、リクエストbodyの読み込み 等でタイムアウトが発生 • レスポンスサイズが制限にかかっていない か?  リクエストによって動的にサイズが変わる 場合は注意
  17. 17. 17CloudFrontでの観点 • Lambda@Edgeを採用している場合: • 同時実行数の制限にかかっていないか? • その他、クォータの確認を https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/clou dfront-limits.html
  18. 18. 18CloudFrontでの観点 • CloudFront ディストリビューションメトリ クスが有効になっている場合 • ステータスコード別のエラー率が確認可能の ため、AWS公式ドキュメントを元に原因を分 析 参考「エラーレスポンスのトラブルシューティング」 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html
  19. 19. 19CloudFrontでの観点 • オリジンのレイテンシが発生しているか • 併せてオリジン側にリクエストが着弾して いるか確認  CloudFrontより下で問題が発生しているかの 確認
  20. 20. 20Next Step ロードバランサレイヤーの確認
  21. 21. 21ロードバランサレイヤーの確認
  22. 22. 22ロードバランサレイヤーでの観点 • ロードバランサのステータスコードを確認 • 問題が起きているのはロードバランサ? • それより下? • 確認するメトリクス: • ロードバランサ(ALB)側 • HTTPCode_ELB_4XX_Count • HTTPCode_ELB_5XX_Count ロードバランサで問題が発生しているか
  23. 23. 23ロードバランサレイヤーでの観点 • ロードバランサがボトルネックになるケース  負荷に応じてスケールを行う仕様のため、急 なアクセスの場合(スパイク)には耐えられ ない可能性も • 対応方法: • 暖機申請を検討 ※NLBの場合は負荷分散技術が特殊のため不要 https://aws.amazon.com/jp/blogs/news/webinar-bb-elastic-load-balancing-2019/
  24. 24. 24ロードバランサレイヤーでの観点 • ロードバランサがボトルネックになるケースは あまりない • 4XXや5XXの件数を確認した後は、実際にどの ステータスコードを返しているのか確認 参考:「Application Load Balancer のトラブルシューティング」 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load- balancer-troubleshooting.html 参考:「[障害対応] ALB で502エラーが発生!!その時あなたはどうす る!?」 https://dev.classmethod.jp/articles/badgateway-error-alb/
  25. 25. 25ロードバランサレイヤーでの観点 • ロードバランサより下で問題が起きているかを 確認 • 確認するメトリクス: • HTTPCode_Target_4XX_Count • HTTPCode_Target_5XX_Count これらが発生している場合にはアプリケー ションレイヤーより下に問題がある
  26. 26. 26ロードバランサレイヤーでの観点 • ロードバランサ下のホストが有効か確認する • ターゲットグループのヘルスステータスがhealthy か • UnHealthyHostCount • 稀ではあるがロードバランサが原因でヘルス チェック が失敗することも • ヘルスチェック の理由コード:Elb.InternalError • 参考「ターゲットグループのヘルスチェック」 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group- health-checks.html
  27. 27. 27Next Step アプリケーションレイヤー の確認
  28. 28. 28アプリケーションレイヤーの確認
  29. 29. 29アプリケーションレイヤーでの観点 • ロードアベレージ(CPU使用率)の確認 • 問題が起きているのはサーバの中か?外か? • 確認するメトリクス: • EC2 • CPUUtilization • コンテナ • Container Insightsを用いたコンテナやタスク別の監視 • 主な対処方法 • スケールアップ、スケールアウトによる対応
  30. 30. 30アプリケーションレイヤーでの観点 • スケールによる確認  スケールアップ or アウトで限界値やスループット の向上が見られるかを確認する  限界値やスループットの向上が確認できてかつCPU 使用率が上がらない場合にはサーバ内にボトル ネック  マルチコアの場合はマルチコア利用を検討  各種ミドルウェアのチューニング  例:apache, jvm, php-fpm
  31. 31. 31アプリケーションレイヤー(lambda)での観点 • 実行時のエラーは発生していないか? • 確認するメトリクス: Errors • スロットリングは発生していないか? • 確認するメトリクス: Throttles
  32. 32. 32アプリケーションレイヤー(lambda)での観点 • Provisioned Concurrency利用を検討 • Re:Invent2019で発表された新機能 • これまでlambdaは一度停止すると再起動するコス トがかかっていた(コールドスタート) lambda実行 一定時間経過 停止 実行命令 デプロイパッケージのダウンロード 解凍 lambdaの起動 lambda実行 Provisioned Concurrencyを利用することで 実行に必要分のlambdaをプールしておくことが可能 参考:[速報]コールドスタート対策のLambda定期実行とサヨナラ!! LambdaにProvisioned Concurrencyの設定が追加されました #reinvent https://dev.classmethod.jp/articles/lambda-support-provisioned-concurrency/
  33. 33. 33アプリケーションレイヤー(lambda)での観点 • リソースの割り当てを強化 • メモリを多く割り当てることに伴いCPUやNW 帯域が強化される 参考:Lambdaのメモリ割り当てを自動で最適化!!AWS Lambda Power Tuning https://dev.classmethod.jp/articles/aws-lambda-power-tuning/
  34. 34. 34アプリケーションレイヤー(lambda)での観点 • パッケージサイズを小さくする • lambdaではデプロイパッケージは可能な限り 小さくすることがベストプラクティスとして 推奨されている 参考:AWS Lambda 関数を使用する際のベストプラクティス https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html
  35. 35. 35アプリケーションレイヤー(lambda)での観点 • handler外に再利用可能なアセットを置く • lambdaではhandler外の処理はコールドスタートの 一回のみ実行される • handler外でSDKの初期化を行えば再利用により速度 面でのパフォーマンス増加が期待できる 参考:Lambdaのhandler外(メソッド以外)のコードは「コールドスタート時の1回 だけ実行される」という話 https://dev.classmethod.jp/articles/lambda-outside-handler-running-first/
  36. 36. 36アプリケーションレイヤー(lambda)での観点 引用元:Lambdaのhandler外(メソッド以外)のコードは 「コールドスタート時の1回だけ実行される」という話 https://dev.classmethod.jp/articles/lambda-outside-handler-running-first/ コールドスタート の一回のみ実行
  37. 37. 37Next Step データストアレイヤーの確認
  38. 38. 38データストアレイヤーの確認
  39. 39. 39データストアレイヤー(DB)での観点 • デッドロック等が発生していないか確認する • Auroraの場合は以下のメトリクスを確認: • BlockedTransactions • Deadlocks  まずは手動でDeadlockの解除  その後原因調査  例:SHOW ENGINE INNODB STATUS
  40. 40. 40データストアレイヤー(DB)での観点 • 上がっているレイテンシがないか確認する • Auroraの場合以下のメトリクスを確認可能: • DeleteLatency • InsertLatency • UpdateLatency • SelectLatency • CommitLatency • DDLLatency • DMLLatency
  41. 41. 41データストアレイヤー(DB)での観点 • スロークエリの確認  検出できた場合には実際にEXPLAINで計測  まだ設定を行っていない場合には設定を! • 併せて異常なログが出ていないか確認を! 参考「【アップデート】Amazon Auroraでスロークエリや一般ログがCloudWatch Logsへ出力 可能に」 https://dev.classmethod.jp/articles/amazon-aurora-export-cloudwatch-logs/ 参考「RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました」 https://dev.classmethod.jp/articles/rds-mysql-mariadb-export-cloudwatch-logs/ 参考「Amazon RDS が Amazon CloudWatch Logs への PostgreSQL ログファイルの発行をサ ポート」 https://aws.amazon.com/jp/about-aws/whats-new/2018/12/amazon-rds-supports-postgresql- logfiles-publish-to-amazon-cloudwatch-logs/
  42. 42. 42データストアレイヤー(DB)での観点 • サーバのリソース状況に異常がないか確認する  拡張モニタリング • cpuUtilization • diskIO • memory • network • コネクション数がボトルネックになることも • DatabaseConnections • リソース異常があった場合はWriteとReadを使い分け ることも検討
  43. 43. 43データストアレイヤー(DynamoDB)での観点 • DynamoDBの基本 • DynamoDBではパーティションキーによって書き込むディ スクを分けて負荷を分散 パーティションキー attribute1 attribute2 データを挿入 キーのハッシュ値を算出(例:193c77d2…) 1から始まるのでディスク1に保存 1 2 3
  44. 44. 44データストアレイヤー(DynamoDB)での観点 • DynamoDBの基本 • DynamoDBではパーティションキーによって書き込むディ スクを分けて負荷を分散  キーに偏りがあると分散できなくなる • 対処方法  パーティションキーにランダムな値を付けてハッシュ値 を分散する  偏りが出そうなキーをパーティションキーにしない  ユーザID等、一意な値をパーティションキーにする
  45. 45. 45データストアレイヤー(DynamoDB)での観点 • 有効なメトリクス • ThrottledRequests • プロビジョニング済みのスループットキャパシ ティを超過すると増加するメトリクス • 各種ThrottleEvents • ReadThrottleEvents • 読み込みでスループットキャパシティを超過した場合、増加 • WriteThrottleEvents • 書き込みでスループットキャパシティを超過した場合、増加
  46. 46. 46データストアレイヤー(DynamoDB)での観点 • DAX利用でスループットの向上も期待できる • DAX: DynamoDB用のキャッシュサーバ • 利用にはいくつか注意点あり  VPC内からしか利用できない  結果整合性のある読み込みでしか利用できない
  47. 47. 47データストアレイヤー(キャッシュ)での観点 • キャッシュヒットの確認 • キャッシュヒットが低下している場合にはキャッ シュが機能しておらず、レイテンシの増加を招く 恐れがある • 確認するメトリクス • CacheHits • CacheMisses  保存したキャッシュがうまくヒットするようにアプリ ケーションの改修を行う
  48. 48. 48データストアレイヤー(キャッシュ)での観点 • メモリの確認 • メモリ使用率にはゆとりがあることを確認する • Redisの場合は予約メモリがあるので、デフォルトだと最 大搭載メモリの75%までしか使えない点に注意 • 確認するメトリクス • BytesUsedForCache • 主な対処法 • スケールアップかスケールアウトを検討
  49. 49. 49データストアレイヤー(キャッシュ)での観点 • Evictionの確認 • メモリ溢れが発生した場合Evictionが発生することがある • 古いキーや使われていないキーをメモリ容量確保のため に削除する挙動 • 確認するメトリクス • Evictions • 主な対処法 • スケールアップかスケールアウトを検討
  50. 50. 50まとめ チューニングに鋼の弾丸はない
  51. 51. 51まとめ 結局環境をどんな状況に すれば良いか
  52. 52. 52理想的な状況 • スケールで解決できる状況に持っていく • アプリサーバ1台の性能は最大限に発 揮 • 台数を増やせばスループットは上 昇していく • DBやキャッシュはサイズを上げれば処 理効率が上がっていく • ゆとりを持ったインスタンスを用 意しておき、足りなくなればス ケールアップ
  53. 53. 53 せっかくの大人気webサイト、 最高のエクスペリエンスをユーザ に届けましょう!!

×