はじめに
マーケティングテクノロジー部の田中翔です。
マーケティングテクノロジー部で開発/運用している配信システムでは、Google Cloud CloudRun + BigTableを使用しています。
今回はRequest LatencyがSLOを大幅に下回った際に行った調査対策について、紹介したいと思います。
背景
配信システムは組織横断で使用されるサービスのため、SLOはRequest Latency 30ms以下で計測していますが、常態的にSLOを下回っており調査に踏み切りました。
SLOはDatadog APM Traceデータを元に算出しています。
対策
LoadBalancer
Botからのリクエストや攻撃と見られるリクエストを除外するため、Cloud Armor Security Policyを追加しました。
再三言われていることですが、WAFルールの追加は慎重に行う必要があります。
Cloud ArmorにはPreview Modeがあるので、有効にしてから本番適用することをお勧めします。
以下でLoggingを検索すると、Preview Ruleが適用されたリクエストを確認できます。
resource.type="http_load_balancer" jsonPayload.previewSecurityPolicy.configuredAction="DENY"
Cloud Armorには適応型保護によって、DDoS攻撃や悪意あるリクエストを機械学習によって検知する機能もあります。 ただし、Cloud Armorの料金はリクエスト数次第では大枚をはたく可能性があるため、ご利用は計画的に。
またCloud Armor事前構成WAFルールも存在しますが、有効なリクエストも除外する可能性もあるため個別にルール作成した方が安牌です。
CloudRun
同時実行数をモニタリングしていると、1台辺りの同時実行数が増加しており、数百単位のリクエストが1台に負荷がかかっていることが確認できました。
CloudRunのオートスケーリングは以下がトリガーとなります。(Cloud Run サービスでのインスタンスの自動スケーリングについて)
1. 既存インスタンスの 1 分間の平均 CPU 使用率（スケジュール設定されたインスタンスの CPU 使用率を 60% に維持するため）。
2. 1 分間でのリクエストの最大同時実行数と比較した現在の同時実行数。
3. インスタンスの最大数の設定
4. インスタンスの最小数の設定
パフォーマンスチューニングの注意点は以下です。
- インスタンスあたりの最大同時リクエスト数を最大値1000に設定した場合、同時実行数次第ではなかなかスケーリングしない
- CPU使用率をサービスのピーク時に約50%程度になるように設定することで、スケーリングしやすい(約60%がスケーリング目安)
- スケーリングは体感で検知から約10分~約20かかる様子
チューニング行うことで、1台辺りの同時実行数を5〜9辺りに下げることができました。
ゆとりある設定をしたくなりますが、CloudRunについては負荷検証を通してこれらのパラメータをチューニングすることをおすすめします。
Application
配信システムはGolangで実装されており、BigTableへの接続はgoogle-cloud-goを使用しています。
BigTableへのgRPC connection pool sizeはデフォルト値から変更していませんでした。
最適な接続プールサイズを決定するで紹介されている計算手順は以下です。
(QPS 秒 ÷ (1,000 ÷ ミリ秒単位のレイテンシ)) ÷ 50 ストリーム = 最適な最小接続数 (QPS 秒 ÷ (1,000 ÷ ミリ秒単位のレイテンシ)) ÷ 10 ストリーム = 最適な最大接続数
Pool Sizeの変更は容易に可能です。
bigtable.NewClient(ctx, project, instance, option.WithGRPCConnectionPool(poolSize))
Pool Sizeを適切に調整し、多少の改善ができました。
BigTable
BigTableのパフォーマンス低下の原因は、公式記事で公開されています。
主にはスキーマ設計の問題や、クラスタ間の問題などがあげられています。
これらの対策や、アプリプロファイルについて検討しましたが、今回の場合該当せず手詰まりになっていました。
BigTableのメトリクスでは二種類のレイテンシーを確認できます。
- サーバーサイドのレイテンシ
bigtable.googleapis.com/server/latencies - クライアントサイドのレイテンシ
bigtable.googleapis.com/client/operation_latencies
クライアントとサーバーサイドでのレイテンシーの乖離が大きい場合は、クライアントサイドの問題と考えられます。
今回の事象では、サーバーサイドのレイテンシーが上昇する時間帯（夜帯）が一定であり、こちら側での対策が困難と判断したためGoogle Cloudへの問い合わせを行い解消しました。（BigTableサーバー側の問題だった）
まとめ
これらを対策し、最終的にはSLOに近い値に戻ってきました。
CloudRun + BigTableのパフォーマンスチューニングは記事も少ないため、参考になれば幸いです。
最後に求人情報の紹介です。マーケティングテクノロジー部では共に働く仲間を募集しています。
ご興味ある方は、募集ページをご確認ください！
dmm-corp.com
