Google Kubernetes Engine でスケーラビリティ テストを実施する: 事前に知っておくべきこと

※この投稿は米国時間 2023 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模なシステムの構築は簡単なことではありません。小規模では予測可能で信頼のおけるシステムも、規模が大きくなれば混沌とし、管理が難しくなります。設計の限界が明らかになったり、最適でないパフォーマンスを示したり、動作しないことさえあります。

このような影響を軽減するには、本番環境でデプロイする前に大規模なシステムのテストを行うことが重要です。しかし、規模を大きくした際のシステムのパフォーマンスや信頼性を予測することは、特に注意が必要な複雑なタスクになる可能性があります。一般的に、コンピューティング リソースの量によってスケールするシステムの容量が予測されます。場合によっては、同時実行接続数、テナント数、適用可能なセキュリティ ルールの数など他の項目がより重要なこともあります。さらに、スケーラビリティ テストの実施はアプリケーションの性質に依存します。まったく新しいプロダクトなのか、他のクラウド プロバイダから移行するアプリケーションなのか、サイズ変更を行うシステムなのか、などです。大規模な Google Kubernetes Engine（GKE）クラスタを評価してきた Google の経験に基づいて、GKE のお客様がワークロードをスケールアップする際のベスト プラクティスとアドバイスについて見ていきましょう。

スケーラビリティ テストを実施するメリット

システムのスケーラビリティ テストを行うことの主なメリットは、小規模ではわかりにくいボトルネックや最適化の機会を特定することで、規模を大きくしても信頼性がありパフォーマンスに優れたシステムであることを確認できることです。他には次のようなメリットもあります。

• システムの信頼性を高めることができます。現在の規模の 2 倍のスケールに成功したならば、通常のサイズでの運用も問題ないと感じるはずです。

• 潜在的な問題を早期に特定できます。これにより、オブザーバビリティ指標が高まる可能性があります。たとえば、多くのお客様は GKE API のレイテンシを追跡していません。しかし、コントロール プレーン上の問題の兆候を早期に検出すことができる Kubernetes API のレイテンシの優れた能力に気づくと、そうしたお客様も Google Cloud のオブザーバビリティ スイートである Cloud Operations にそれを追加することを決めています。

• 大規模なシステム運用にかかる費用を確認できます。特に、GKE のお客様は、セッション数、ユーザー数、ジョブ完了数などを考慮すると、大規模なシステムの運用コストが小さくなることに驚かれるかもしれません。

スケーラビリティ テスト実施の目標設定

スケーラビリティ テストの実施に対して適切な目標を設定することは特に重要です。間違った前提でテストを実施すると、費用がかさむこともあります。そして、実際にかかるテスト費用に加え、定義する目標が不十分だとシステムに対して間違った信頼を抱いてしまい、本番環境でシステムをスケールした際に重大なインシデントを引き起こす可能性があります。

経験から言うと、ハイレベルな目標はビジネス志向の数値で表され、測定可能であるべきです。たとえば、同時処理ジョブ数を倍にする、ユーザーの秒間クエリ数を 3 倍にする、グレースフル リージョン障害などです。この目標は、目立つようにテストを行うダッシュボードに表示しておきましょう。

また、特定のリソースに対するハイレベルな目標を設定する必要があります。たとえば、既存のシステムをリスケーリングする場合、最も一般的な方法は、リソース使用量増加は線形であると想定し、セーフティーネットを追加することです。100K の CPU で動作するシステムで、パフォーマンスを 2 倍にしたい場合は、250K の CPU を使用するかもしれないということです。このざっくりとした仮定は、ただの概算でありシステムのハードリミットとの差がどのぐらいあるのかを評価するのに役立ちます。テスト中は実際の数値を確認する必要があります。

目標設定の際は、システムをスケールした後も次のリソースが十分であることを確認してください。

• ノード / Pod / コンテナの数

• サービスの数

• 名前空間の数

• NCPU / GPU / メモリの数

• Secret / ConfigMaps / CRD の数

さらに、VPC の数、そのインスタンスとエイリアス、プロジェクト内のクラスタやノードプールの総数など、一般的な Google Cloud リソースの使用量を確認します。

大規模なシステムは、安定していれば非常に信頼性が高くなります。うまくいかないのは、変化するときです。適切なテストケースを構築するためには、テスト中に一般的な摩擦点を必ず検証してください。これには、クラスタのアップグレード、ゾーン停止、大規模な PVM プリエンプションが含まれます。テストの際、必要な指標とログがすべて適切に収集されているか確認してください。

スケーラビリティ テスト実施の費用の決定

スケーラビリティ テストの実施に多大な費用がかかることは間違いありません。極端な例ですが、何十万ドルもかかるテストもあります。これについては私たちはよく理解していて、Google Cloud では、少なくとも週 2 回、15,000 ノードで、最大 20 の異なるテスト構成で GKE リリースをテストしています。また、オープンソースの Kubernetes リリースのスケールを検証するため、毎日 5,000 ノードのテストを行っています。

アドホック ベースでスケーラビリティ テストを実行する場合でも、費用を最適化する必要があります。最も一般的な方法は、テストをできるだけ短くすることです。Google の社内テストが良い例です。テスト範囲を変更せずに、15 時間かかっていたテスト工程を 3 時間以下に短縮しました。

利用できるその他の最適化メソッドについては次のとおりです。

• コストの低いコンピューティング リソースへの切り替え。可能であれば、通常のインスタンスよりも最大で 91% 安い Spot VM 上でテストを実行してください。

• ストレージ レイヤを簡素化。ストレージ レイヤをテストしているのでない限り、デフォルトのターゲット（Cloud Storage、LocalSSD）を標準永続ディスク上でスタブに置き換えることができます。

• 適宜、テスト ワークロードを最適化し、本番環境で必要なメモリや CPU よりも少ない量で実際のコンテナを「スタブ」してください。

テスト費用を見積もる際は、すべてのコスト要因（コンピューティング、ネットワーク、ストレージ）を一番高い値段で見積ってください。また、テスト時間を見積もる際は、スケールアップとスケールダウンの時間を忘れずに含めてください。これまでの経験からいうと、目標を達成するためには少なくとも 2～3 回は完全なテストを実施する必要があります。

最後に、黄金律はここには存在しないということを心に留めておいてください。費用の最適化と本番環境システムにできるだけ近い結果を出すこととのバランスをとらなければいけません。

インフラストラクチャの準備

大規模なスケーラビリティ テストを実行する際は、専用の請求先アカウントをもつ、別の Google Cloud プロジェクトで実行することをおすすめします。プロジェクト レベルで分けることで、他の環境から独立して割り当てを使用し続けることができます。また、別のプロジェクトなので、使用する可能性のあるすべてのリソースの割り当てを増やしてもらう必要があります。GKE ドキュメント、大規模なワークロードの計画 | Google Kubernetes Engine（GKE）に記載のガイドラインをご覧ください。ネットワーク構成に特に注意してください。CIDR アドレスやロードバランサを適切に定義し、ノード、Pods、Service などよく知られているものを含む多くの項目でスケールします。GKE アドレス管理: 導入と概要 | Cloud アーキテクチャ センターをぜひご覧ください。

Google のアカウント担当チームのサポートを受けずにスケーラビリティ テストを実行することは技術的には可能ですが、初期からチームに参加してもらうことで、プラットフォームの制限を理解するのに役立ち、適切な専門家を紹介してもらえます。ベスト プラクティスや周知の回避策を、一般公開前に入手できるかもしれません。

準備段階で Google のキャパシティ チームに知らせ、参加してもらう必要があります。ブラック フライデー、サイバー マンデー、お正月など、年に数回は大規模なテストを実行するのに適さない時期があります。テスト準備に最適なのは第 1 四半期、テスト実施に最適なのは第 2 四半期です。

テストの時間枠を設定したら、実際のテストの前に簡単なドライランを設定し、すべてのワイヤが適切に接続されていることを確認します。テストケースをすべて書き出し、それが動作することを確認し、構成をリポジトリに保存し、テスト結果を表示するダッシュボードを開発すれば、準備は完了です。

テストの実行

テストの実行はそれぞれ異なりますが、成功するテストには多くの共通点があります。最も共通するルールは、よいチームでテストを行うということです。テストランナーには DevOps、アーキテクト、デベロッパーが含まれることもあります。チームで予定を合わせて会議の場を設けているお客様もいます。アーキテクトとデベロッパーが同じ場所にいることで、問題が発生した際に即効性のある回避策を考えることができるのです。

実行中、いくつかのシステム要素が不安定になる可能性があることを覚えておいてください。テスト実行の目的は、問題をデバッグするためにできるだけ多くのデータを集めることです。今後の参考のために、テスト セッション中のすべての議論や調査を記録する傾向があります。収集したログと指標を組み合わせることで、記録されたデータは後のデバッグに非常に役立ちます。

テスト実行のサマリーは、技術的な指標だけでなく費用の内訳についても含める必要があります。大規模な運用費用の見積もりを把握していることは、大きな価値があります。

たくさんのテストを実行してきた Google のエンジニアはスケーラビリティの分野ではエキスパートです。それでも、最初のテストで複数の問題を検出するのは一般的で、1 回のテストでスケーラビリティ テストの目標を達成するのは稀です。追加の微調整の量にもよりますが、通常、1 か月程度でテストを再実行することになります。より深いリファクタリングや他のラウンドのテストを実行しなければならない場合もあります。テストがなければ、このようなことを知る術はなかったでしょう。

まとめ

クラウドへ移行することで、ワークロード運用に使用するマシンを、新しく興味深い視点から見直す機会が得られます。クラウド コンピューティングは、実は、ソフトウェアによって実現しているのです。ソフトウェアは、ネットワークやストレージ、ワークロード、それらを管理するシステムにとって、主要なインターフェースです。これにより、統合、想像、利用の方法が無限に広がります。

コードの変更をテストすることは、最新のソフトウェア開発ライフサイクル カルチャーにおいて欠かせないものです。クラウド システムをソフトウェアとしてとらえることで、Kuberentes の新バージョン、インメモリ データベースやキャッシング システムなどの新しいコンポーネント、単一クラスタからマルチクラスタ シナリオへの移行のようなアーキテクチャの変更など、システムに対するそれぞれの変更は、変更ロールアウトもしくは新しいリリースであり、そのように扱われるべきであると明らかになります。

スケーラビリティ テストを実行するのには多くの費用がかかりますが、たいていの場合、これが大規模なシステム運用の準備について、最も効率的かつ迅速に学ぶことができる方法なのです。大規模で複雑なプラットフォームを運用するには、GKE は最良のプラットフォームであり、長年 Kubernetes と GKE をテストして得たベストプラクティスに従うことで、プロセスを管理しやすくなると考えています。私たちの経験を共有し、私たちのプラットフォームを基礎とした高度なシステムの構築をサポートできることを嬉しく思っています。GKE スケーラビリティ ベスト プラクティスをクリックして詳細をご確認ください。またはテクニカル アカウント マネージャーにお問い合わせください。