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

ハイトラフィック運用
〜スループットの向上を目指して〜
2020/06/16
深澤俊

2自己紹介
深澤俊（Fukazawa Shun）
WEBアプリケーションエンジニア
↓
SRE
↓
AWS事業本部コンサルティング部
好きなAWSサービス
ElastiCache、DynamoDB
@shun_quartet

3突然ですが…
こんな悩みを抱えてはいませんか？

4こんな悩み抱えていませんか？
今のwebサイトのスピードを
もっと上げたい

アクセスピーク時にエラー画面が
ユーザに表示されてしまう

サーバ台数を増やしたけど、
webサイトのレスポンススピード
が上がらない

7
せっかくの大人気webサイト、
最高のエクスペリエンスをユーザ
に届けましょう！！

8最高のエクスペリエンス
最高のエクスペリエンス
↓
スループットの向上
↓
この中からボトルネック
を探して取り除く

9
今回はボトルネックの特定や
チューニング方法をご紹介

10注意点
• 今回の発表では観点をメインに紹介します
• それぞれのエンジン等による細かい違いや
チューニング方法には触れません
• 例：MysqlとPostgras等
• メトリクスはCloudWatchのものをご紹介しま
す

11注意点
• 今回はあくまで概要と基本です
• 障害原因やチューニング方法に鋼の弾丸はあ
りません
• ご紹介した以外にも有益なメトリクスはあり
ますので、是非今回を機に他のメトリクスも
確認していただけたら嬉しいです。

12問題とゴールの決定
• まずは現在の問題とゴールを定める
• CloudWatch Synthetics等を用いた外形監視確
認
 ユーザ目線でどんな問題が発生しているか
• レイテンシを下げたい？
• チューニング
• 障害発生中？
• 原因特定と解消

13First Step
CloudFrontの確認

15CloudFrontでの観点
• そもそもDNSで障害は発生していないか？
• リクエスト数が落ち込んでいないか確認
 DNSで誤ってレコードを削除などの可能性も
CloudFront
Route 53（DNS）
User

• Lambda@Edgeを採用している場合:
• タイムアウトは発生していないか?
 外部APIの遅延、リクエストbodyの読み込み
等でタイムアウトが発生
• レスポンスサイズが制限にかかっていない
か？
 リクエストによって動的にサイズが変わる
場合は注意

• Lambda@Edgeを採用している場合:
• 同時実行数の制限にかかっていないか？
• その他、クォータの確認を
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/clou
dfront-limits.html

• CloudFront ディストリビューションメトリ
クスが有効になっている場合
• ステータスコード別のエラー率が確認可能の
ため、AWS公式ドキュメントを元に原因を分
析
参考「エラーレスポンスのトラブルシューティング」
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html

• オリジンのレイテンシが発生しているか
• 併せてオリジン側にリクエストが着弾して
いるか確認
 CloudFrontより下で問題が発生しているかの
確認

20Next Step
ロードバランサレイヤーの確認

21ロードバランサレイヤーの確認

22ロードバランサレイヤーでの観点
• ロードバランサのステータスコードを確認
• 問題が起きているのはロードバランサ？
• それより下？
• 確認するメトリクス：
• ロードバランサ（ALB）側
• HTTPCode_ELB_4XX_Count
• HTTPCode_ELB_5XX_Count
ロードバランサで問題が発生しているか

• ロードバランサがボトルネックになるケース
 負荷に応じてスケールを行う仕様のため、急
なアクセスの場合（スパイク）には耐えられ
ない可能性も
• 対応方法：
• 暖機申請を検討
※NLBの場合は負荷分散技術が特殊のため不要
https://aws.amazon.com/jp/blogs/news/webinar-bb-elastic-load-balancing-2019/

• ロードバランサがボトルネックになるケースは
あまりない
• 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/

• ロードバランサより下で問題が起きているかを
確認
• HTTPCode_Target_4XX_Count
• HTTPCode_Target_5XX_Count
これらが発生している場合にはアプリケー
ションレイヤーより下に問題がある

• ロードバランサ下のホストが有効か確認する
• ターゲットグループのヘルスステータスがhealthy
か
• UnHealthyHostCount
• 稀ではあるがロードバランサが原因でヘルス
チェックが失敗することも
• ヘルスチェックの理由コード：Elb.InternalError
• 参考「ターゲットグループのヘルスチェック」
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-
health-checks.html

27Next Step
アプリケーションレイヤー
の確認

28アプリケーションレイヤーの確認

29アプリケーションレイヤーでの観点
• ロードアベレージ（CPU使用率）の確認
• 問題が起きているのはサーバの中か？外か？
• EC2
• CPUUtilization
• コンテナ
• Container Insightsを用いたコンテナやタスク別の監視
• 主な対処方法
• スケールアップ、スケールアウトによる対応

30アプリケーションレイヤーでの観点
• スケールによる確認
 スケールアップ or アウトで限界値やスループット
の向上が見られるかを確認する
 限界値やスループットの向上が確認できてかつCPU
使用率が上がらない場合にはサーバ内にボトル
ネック
 マルチコアの場合はマルチコア利用を検討
 各種ミドルウェアのチューニング
 例：apache, jvm, php-fpm

31アプリケーションレイヤー(lambda)での観点
• 実行時のエラーは発生していないか？
• 確認するメトリクス： Errors
• スロットリングは発生していないか？
• 確認するメトリクス： Throttles

• 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/

• リソースの割り当てを強化
• メモリを多く割り当てることに伴いCPUやNW
帯域が強化される
参考：Lambdaのメモリ割り当てを自動で最適化！！AWS Lambda Power Tuning
https://dev.classmethod.jp/articles/aws-lambda-power-tuning/

• パッケージサイズを小さくする
• lambdaではデプロイパッケージは可能な限り
小さくすることがベストプラクティスとして
推奨されている
参考：AWS Lambda 関数を使用する際のベストプラクティス
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html

• handler外に再利用可能なアセットを置く
• lambdaではhandler外の処理はコールドスタートの
一回のみ実行される
• handler外でSDKの初期化を行えば再利用により速度
面でのパフォーマンス増加が期待できる
参考：Lambdaのhandler外(メソッド以外)のコードは「コールドスタート時の1回
だけ実行される」という話
https://dev.classmethod.jp/articles/lambda-outside-handler-running-first/

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

37Next Step
データストアレイヤーの確認

38データストアレイヤーの確認

39データストアレイヤー(DB)での観点
• デッドロック等が発生していないか確認する
• Auroraの場合は以下のメトリクスを確認：
• BlockedTransactions
• Deadlocks
 まずは手動でDeadlockの解除
 その後原因調査
 例：SHOW ENGINE INNODB STATUS

• 上がっているレイテンシがないか確認する
• Auroraの場合以下のメトリクスを確認可能：
• DeleteLatency
• InsertLatency
• UpdateLatency
• SelectLatency
• CommitLatency
• DDLLatency
• DMLLatency

• スロークエリの確認
 検出できた場合には実際に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/

• サーバのリソース状況に異常がないか確認する
 拡張モニタリング
• cpuUtilization
• diskIO
• memory
• network
• コネクション数がボトルネックになることも
• DatabaseConnections
• リソース異常があった場合はWriteとReadを使い分け
ることも検討

43データストアレイヤー(DynamoDB)での観点
• DynamoDBの基本
• DynamoDBではパーティションキーによって書き込むディ
スクを分けて負荷を分散
パーティションキー attribute1 attribute2
データを挿入
キーのハッシュ値を算出（例：193c77d2…）
1から始まるのでディスク1に保存
1 2 3

• DynamoDBの基本
• DynamoDBではパーティションキーによって書き込むディ
スクを分けて負荷を分散
 キーに偏りがあると分散できなくなる
• 対処方法
 パーティションキーにランダムな値を付けてハッシュ値
を分散する
 偏りが出そうなキーをパーティションキーにしない
 ユーザID等、一意な値をパーティションキーにする

• 有効なメトリクス
• ThrottledRequests
• プロビジョニング済みのスループットキャパシ
ティを超過すると増加するメトリクス
• 各種ThrottleEvents
• ReadThrottleEvents
• 読み込みでスループットキャパシティを超過した場合、増加
• WriteThrottleEvents
• 書き込みでスループットキャパシティを超過した場合、増加

• DAX利用でスループットの向上も期待できる
• DAX： DynamoDB用のキャッシュサーバ
• 利用にはいくつか注意点あり
 VPC内からしか利用できない
 結果整合性のある読み込みでしか利用できない

47データストアレイヤー(キャッシュ)での観点
• キャッシュヒットの確認
• キャッシュヒットが低下している場合にはキャッ
シュが機能しておらず、レイテンシの増加を招く
恐れがある
• 確認するメトリクス
• CacheHits
• CacheMisses
 保存したキャッシュがうまくヒットするようにアプリ
ケーションの改修を行う

• メモリの確認
• メモリ使用率にはゆとりがあることを確認する
• Redisの場合は予約メモリがあるので、デフォルトだと最
大搭載メモリの75%までしか使えない点に注意
• BytesUsedForCache
• 主な対処法
• スケールアップかスケールアウトを検討

• Evictionの確認
• メモリ溢れが発生した場合Evictionが発生することがある
• 古いキーや使われていないキーをメモリ容量確保のため
に削除する挙動
• Evictions
• 主な対処法
• スケールアップかスケールアウトを検討

50まとめ
チューニングに鋼の弾丸はない

51まとめ
結局環境をどんな状況に
すれば良いか

52理想的な状況
• スケールで解決できる状況に持っていく
• アプリサーバ1台の性能は最大限に発
揮
• 台数を増やせばスループットは上
昇していく
• DBやキャッシュはサイズを上げれば処
理効率が上がっていく
• ゆとりを持ったインスタンスを用
意しておき、足りなくなればス
ケールアップ

53
せっかくの大人気webサイト、
最高のエクスペリエンスをユーザ
に届けましょう！！

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

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

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (10)

Featured

Featured (20)