はじめに
この記事では、Cloud Run を利用したアプリケーションの負荷試験における学びと、ボトルネックになった箇所を共有します。
前提
実際のものからは少し省いてる箇所もありますが、下図のような構成となります。
ボトルネック部分に関する今回のポイント
Cloud Run はフロント部分としてもちろん重要で、スケールはある程度自動でやってくれる部分に期待していました。
VPC にあるリソースとの通信が発生するため、NW 周りも実は重要であり、ボトルネックになるポイントでした。
それぞれざっくり見ていきます。
Cloud Run の設定
主要ポイント
- 1コンテナあたりの最大接続数: 同時接続数が多くなると、コンテナあたりのリソースを多く使用しレスポンスタイムの劣化を引き起こす可能性があるため、この数値を適切に設定することが重要で、多すぎず、少なすぎない値になるべくする必要があります。
- 1サービスあたりの最大/最小コンテナ数: 最小コンテナ数は通常アクセスをさばける程度のコンテナ数量とし、最大についてはアクセス数などから想定するか、負荷試験などで確認する必要があります、そのうえで、範囲を適切に設定し、コストとパフォーマンスのバランスを取ります。
補足
- CPU ブースト: 突発的なトラフィックの増加に対応するため、Cloud Run は CPU リソースを一時的に増加させることが可能で、この機能を有効化し負荷試験のスケール速度など見てもよいかな、と思います。
NW 関連の設定
主要ポイント
- Cloud NAT のポート数: 実はこのような設定があり、アウトバウンドに影響します。この点以降で少し触れます。
- サーバーレス VPC アクセスコネクタ: 実はこちらもインスタンスタイプの設定が必要です。
補足
- Direct VPC Egress: 今だと GA しているこの機能は当時は GA していませんでした。こちらを利用すると、遅延を最小限に抑えつつ、VPC 内のリソースへ直接アクセスできますが、IP アドレスの考慮などが必要になります。
主要ポイントを中心とした発生事象と対策
上記したようなポイント部分に対して実際に発生した事象と、それに対して行った対策について記載します。
Cloud Run の設定
事象: 1コンテナあたりの最大接続数が多すぎたため、メモリ不足が発生
対策: CPU や同時接続数ではスケールしてくれますが、メモリ使用率ではスケールしてくれません。メモリいっぱいになりながら応答できず、同時接続数になるまで待つことしかできません。そのため、アプリケーションの平均的なメモリ消費と最大接続数を把握し、それに基づいて接続数を調整する必要があります。
参考URL: Cloud Runのスケーリングとメモリマネジメント
NW 関連の設定
事象1: Cloud NAT のポート数不足になり、アウトバウンドでパケットロスが発生
対策1: Cloud NAT の設定で動的ポート割当を有効にし、インスタンスあたりの最小ポート割当を増やし、最大ポート割当を設定することで、より多くのポート割当が可能になり、パケットロスが解消しました(なおNATを利用する VM 数によっては注意する必要がありますポート割当数を計算しましょう)。実際の事象発生有無は以下のように Cloud NAT のモニタリングからメトリクスの確認可能です(画像はサンプルとなります)。
参考URL: Cloud NATのポートとアドレス管理
事象2: サーバーレス VPC アクセスコネクターのリソース不足
対策2: インスタンスタイプが低すぎたため、CPU が100%張り付いていました。そのため、実際のトラフィックに基づいて、インスタンスタイプを調整し、解消しました。 実際の事象発生有無は以下のようにサーバーレス VPC アクセスのコネクタの詳細からメトリクスの確認可能です(画像はサンプルとなります)。
まとめ
Cloud Run は運用しやすさで選定される面は多いですが、スケールなどで最大の効果を得るためには、適切な設定が必要になることが理解しました。
どんな条件でもスケールするわけではなく、スケールするためには条件があるので、それを理解したうえで、設定する必要があります。
Cloud Run や CloudSQL といったメインのコンポーネントに意識がいきがちですが、VPC を介した通信や、コネクタとしているリソースの状況にも目を配り、状況をモニタリングすることが必要だな、と感じました。
Cloud Run を利用する場合、似たような構成を取るパターンは多いかと思うので、今後も気をつけたい点だな、と思いました。
