API 管理

大規模なハイブリッド API 管理: クラスタの構成、スケーリング、オペレーションに関するベストプラクティス

2023年2月17日

Google Cloud Japan Team

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

突如としてデジタルファーストへと変化を遂げた経済状況の中、競争力を維持して時代に即した存在であり続けるために、組織は API 戦略を見直す必要に迫られました。そして、多くの組織がハイブリッドクラウドアプローチを選択しました。2022 年に Google が実施した API の利用状況に関する調査では、59% の組織が「今後 12 か月以内にハイブリッドクラウド導入の拡大を予定している」と回答しました。しかし、実際にハイブリッドクラウド環境で API を一貫して運用するのは、理論で考えるほど簡単なことではありません。多くの組織が、アーキテクチャの不均一性により、コスト、メンテナンス、モニタリングの面で苦戦しています。

前回の投稿では、適切なチーム構成とプラットフォームを設計する際によく見られる課題を取り上げました。今回は、ハイブリッドランタイム運用に移行したお客様の事例から得られたベストプラクティスをいくつかご紹介します。具体的には以下の内容を取り上げます。

Kubernetes クラスタのサイズと配置を決定する
アップグレード、セキュリティ、自動化に対処する方法を検討する
厳格なサービスレベル目標を達成するために適切なモニタリング機能とダッシュボードを導入する

ベストプラクティスの説明に入る前に、この投稿に登場する一般的な技術用語について解説します。

ノード - Kubernetes のワーカーマシン。クラスタによって仮想マシンのときも物理マシンのときもあります。

クラスタ - コンテナ化されたアプリケーションを実行するノードのセット

Pod - Kubernetes でデプロイできる最小かつ最も基本的なオブジェクト。クラスタ内で実行されるプロセスの単一インスタンスを表し、1 つ以上のコンテナが含まれます。

Cassandra - Apache Cassandra は、Apigee ハイブリッドランタイムにデータ永続性を提供するランタイムデータストアです。

CI / CD - 継続的インテグレーションと継続的デリバリーまたは継続的デプロイを組み合わせた手法

GitOps - アプリケーション開発で使用されている DevOps のベストプラクティス（バージョン管理、コラボレーション、コンプライアンス、CI / CD など）を、インフラストラクチャの自動化に適用する運用フレームワーク

#1 まずクラスタの適切なサイズと容量を判断する

Apigee ハイブリッドを実行するあらゆるクラスタに最適な 1 つのインフラストラクチャサイズというものはありません。しかし、組織に適したサイズを判断する簡単な方法はあります。

まず、クラスタに適切な初期サイズを判断する必要があります。出発点とするクラスタ容量を特定するには、プロセスの数と、各プロセスに必要なメモリの平均容量を見積もらなければなりません。API 管理の世界では、これらを見積もるには各クラスタが処理する 1 秒あたりのトランザクション数（TPS）の平均と、そのクラスタ内で実行される環境の数を割り出す必要があります。

これらの情報は見積もりの土台となりますが、他にも考慮しなければならない要素があります。たとえば、API の応答時間、API 呼び出しに適用されるポリシー、ペイロードのサイズ、平均 TPS、カスタムポリシーに必要となる CPU などです。土台となるこうした情報を入手したら、Google カスタマーエンジニアなどの信頼できるパートナーに適切な容量を見積もるためのサポートを依頼できます。

#2 テストを実施してクラスタ容量を最適化する

ハイブリッド環境で API を運用している間は、コンテナ化されたランタイムサービスを実行するクラスタのサイズを適正化することが重要です。クラスタのサイズが小さすぎるとパフォーマンスに影響し、大きすぎるとコストに影響します。ベストプラクティスとして、クラスタ容量の設定時に使用した見積もりのみに頼ることは決してしないでください。初期容量の見積もりは平均値に基づいており、実際のワークロードは反映されません。ほとんどの場合、実際のワークロードに必要なクラスタ容量は、初期容量とは異なります。

そこで役立つのが、テストです。本番環境でテストを行うのは最適とはいえません。最適なクラスタ容量を判断するための最善の方法は、独自のワークロードで独自の負荷テストを実施することです。平均 TPS とピーク TPS のテストを実施すると、費用効率の最大化と温室効果ガス排出量の最小化を実現しつつ、開発者が API を最大限活用できるクラスタサイズを特定できます。

なお、Cassandra ノードの場合、本番環境ワークロードに対応するには少なくとも 8 個の vCPU と 15 Gi の RAM が必要です。ランタイム Pod には 2 個の vCPU と 2 Gi の RAM を使用することをおすすめします。デフォルト値をオーバーライドするには、overrides.yaml ファイルで Cassandra とランタイムの適切な構成プロパティを使用してください。

#3 リージョンクラスタを使用して障害から保護する

本番環境のプラットフォームでは、少なくとも 2 つの Kubernetes クラスタをそれぞれ異なるリージョンで使用してください。2 つのクラスタを別々のリージョンで使用すると、クラスタ障害の原因となり得る問題（リージョンのサービス停止など）から保護できます。障害復旧用に複数のリージョンクラスタを設定する際は、すべてのクラスタを同じサイズに設定することをおすすめします。こうすると、一方のクラスタで障害が発生しても、もう一方のクラスタですべての負荷に対処できます。

もう一つの主な考慮事項として、一般ユーザーがサービスにアクセスするリージョンの選択があります。2 つ以上のリージョンを設定し、リージョンごとに異なる環境を実行できるため、クラスタが処理するトラフィックに基づいて各リージョンのクラスタサイズを最適化できます。ただし、クラスタのサイズを設定する際は、別のリージョンのクラスタで障害が発生し、トラフィックが突然クラスタ間で不均等に分散された場合にどうなるかを必ず考慮する必要があります。

#4 ランタイム Pod とデータストアのスケーリングを最適化する

Apigee ハイブリッドは Kubernetes 上で実行されるため、Kubernetes がもたらすメリットをすべて活用できます。これには、自動スケーリングも含まれます。Cassandra Pod を除き、API トラフィックを処理するすべての Pod は、デフォルトで HorizontalPodAutoscaler を使用して自動スケールします。

自動スケーリングをさらに最適化するために、設定をテストして微調整します。テストを実施することで、レプリカ用クラスタの最大数と最小数を判断できます。最適化の一環として、より多くの容量が必要な環境では上限を高く設定し、そうでない環境では上限を低く設定します。こうすると、リソース消費量を削減できます。自動スケーリングが可能な場合、スケーリングを完璧に行う必要はありません（理想は、弾力性のあるコンピューティング機能を備えた GKE（Google Kubernetes Engine）などの Kubernetes サービスで実行することです。こうすると、臨機応変にノードの追加と削除を行って、リソースを可能な限り効率的に使用できます）。

1 つの例外は、前述のとおり Cassandra です。Cassandra には自動スケーリング機能がありません。Cassandra は簡単にスケールアップ、スケールダウンできますが、3 ノード単位でオンデマンドで行う必要があります。トラフィックがピークの時期に差し掛かっている場合は、3 つ、または 6 つの Cassandra ノードを追加します。トラフィックのピークが過ぎたら、元のノード数にスケールダウンします。

最後に、自動スケーリングが最適に機能するのは、トラフィックが段階的に増減する場合です。ランタイム Pod は迅速にスピンアップするように設計されていますが、ノードがスピンアップしてクラスタに追加されるには少し時間がかかります。トラフィックの急増が想定される場合は（たとえば、前評判の高い限定版スニーカーを真夜中に販売開始するなど）、レプリカの最小数をその負荷に対処できるだけの値に引き上げて、システムの準備を行います。オートスケーラーの反応は、アプリケーションに到達したピークトラフィックを瞬時に処理できるほど迅速ではありません。

#5 自動化された CI / CD パイプラインで最新の状態を維持する

自動化された CI / CD パイプラインを使用してプロキシをデプロイするメリットはおそらくご存じだと思いますが、自動化はハイブリッドランタイムのインストールとアップグレードの効率化にも役立ちます。自動化が役立つ理由は次のとおりです。

障害の発生時にクラスタを再作成するプロセスを簡素化できる
簡単にリージョンを追加できる
チームが独自のインスタンスを簡単にインストールできる
テストされた反復可能なプロセスによってエラーを削減できる
GitOps デプロイモデルの一部として設定できる
構成の同期などが設定されている場合、手動によるクラスタのインシデントから Apigee ハイブリッドの設定を保護できる

エンタープライズソフトウェアが更新される頻度を考慮すると、おそらく自動化が最も重要なのはアップグレードです。Apigee ハイブリッドはクラウドで誕生したことから、アップデートとパッチを受信する頻度は、Apigee on Google Cloud のアップデートとパッチが公開される頻度と同じです。1 年に多くのパッチとアップデートが公開されるため、対応が遅れがちになり、サポートされなくなった古いバージョンを実行して問題が発生する可能性があります。このプロセスを自動化すれば、機能とセキュリティパッチを常に最新のバージョンにしておけます。

#6 信頼できるパフォーマンスをモニタリングで確保する

システムが適切に自動化されていても、安定した稼働時間を確保するための最善の方法は、優れたモニタリングツールを使用することです。Apigee ハイブリッドでは、Google オペレーションスイートを利用してモニタリングの実行とアラートの設定を簡単に行えます。Apigee ではデフォルトで、プロキシの正常性に関する指標が Cloud Monitoring に自動で送信されます。システムログを送信するように設定することもできます。正常性に関する指標が Cloud Monitoring に取り込まれたら、これらの指標を使用してダッシュボードとサービスレベル指標を定義し、SRE（サイト信頼性エンジニアリング）の一般的な手法を適用して、インスタンスの正常な稼働を維持できます。

Apigee は、ロギングとモニタリングに使用している既存のスタックとも連動します。また、独自のツールを使用して指標をスクレイピングしたり、独自のエージェントをインストールしてログを収集し、任意のロギングツールに送信したりすることも可能です。