API Gatewayを使ったAPIリリース戦略
December 22, 2022
デプロイメントとリリースを適切に分離した後、次のステップは、機能の段階的なリリースを制御するメカニズムを選択することです。本番環境でのリスクを低減できるリリース戦略を選択することが重要です。なぜなら、リリース前にAPIの新バージョンをどれだけテストしても、実際のテストは最終的に顧客の前に置いたときに起こるからです。
このリスクを低減するために、トラフィックの一部を使用してテストや実験を行い、結果を検証することができます。結果が成功した場合、すべてのトラフィックに対してリリースがトリガーされます。特定の戦略は、他のシナリオよりも適しており、追加のサービスやインフラストラクチャの程度も異なります。この記事では、現在API Gatewayを使用する3つの人気のあるAPIリリース戦略を探ります。
APIデプロイメントでAPIゲートウェイを使用する理由
APIベースのアーキテクチャに移行する利点の1つは、迅速に反復し、サービスに新しい変更をデプロイできることです。また、API Gatewayを使用して、アーキテクチャの近代化された部分に対して_トラフィックとルーティング_の概念を確立しています。API Gatewayは、同じゲートウェイの背後に複数のデプロイされたAPIを持つことを可能にするステージを提供し、ダウンタイムなしでインプレース更新が可能です。API Gatewayを使用することで、サービスの多くのAPI管理機能を活用できます。例えば、認証、レートスロットリング、可観測性（APIの重要なメトリクス）、複数のAPIバージョン管理、ステージデプロイメント管理（dev、test、stage、prodなどの複数のステージでAPIをデプロイ）などです。
オープンソースのAPI Gateway（Apache APISIXやTraefik）、Service Mesh（IstioやLinkerd）ソリューションは、トラフィック分割やCanaryリリースやBlue-Greenデプロイメントのような機能を実装することができます。Canaryテストでは、ユーザーベースのごく一部を選択して、APIの新リリースを厳密に検査できます。次のセクションでCanaryリリースについて説明します。
Canaryリリース
Canaryリリースは、APIの新しいバージョンを導入し、トラフィックのごく一部をCanaryに流します。APIゲートウェイでは、トラフィック分割により、ターゲットサービスの1つのバージョンから別のバージョンにトラフィックを徐々にシフトまたは移行することが可能です。例えば、サービスの新しいバージョンv1.1を、元のv1.0と並行してデプロイできます。トラフィックシフトにより、最初にユーザートラフィックのごく一部（例えば1%）をv1.1にルーティングし、時間をかけてすべてのトラフィックを新しいサービスに移行することで、Canaryテストやリリースを行うことができます。
これにより、新しいサービスを監視し、技術的な問題（レイテンシの増加やエラーレートなど）や、顧客のコンバージョン率や平均ショッピングチェックアウト値などの主要なパフォーマンス指標の増加といったビジネス上の影響を確認できます。トラフィック分割を使用すると、ターゲットサービスの複数のバージョン間でトラフィックを分割してA/Bテストや多変量テストを実行できます。例えば、ターゲットサービスのv1.0とv1.1にトラフィックを50/50で分割し、特定の期間にどちらがより良いパフォーマンスを発揮するかを確認できます。Apache APISIXのIngress Controllerのトラフィック分割機能について詳しく学ぶことができます。
適切な場合、Canaryリリースは優れたオプションです。なぜなら、Canaryに公開されるトラフィックの割合が高度に制御されているからです。トレードオフとして、システムには問題を迅速に特定し、必要に応じてロールバックできるようにするための優れた監視が必要です（これは自動化できます）。このガイドでは、Apache APISIXとFlaggerを使用してCanaryリリースソリューションを迅速に実装する方法を示します。
トラフィックミラーリング
トラフィック分割を使用して実験を実行するだけでなく、トラフィックミラーリングを使用してトラフィックをコピーまたは複製し、追加の場所または一連の場所に送信することもできます。トラフィックミラーリングでは、複製されたリクエストの結果が呼び出し元のサービスやエンドユーザーに返されることはありません。代わりに、リファクタリングされたサービスと既存のサービスによって生成された結果を比較するなど、正しさを評価するために、レスポンスが帯域外で評価されます。または、新しいサービスのバージョンがリクエストを処理する際に、レスポンスのレイテンシや必要なCPUなどの操作上のプロパティが観察されます。
トラフィックミラーリングを使用することで、ユーザーに新しいリリースについて知らせずに内部で必要な効果を観察できる「ダークリリース」を行うことができます。
システムのエッジでトラフィックミラーリングを実装することは、近年ますます人気が高まっています。APISIXは、クライアントリクエストをミラーリングするためのproxy-mirrorプラグインを提供しています。これにより、オンラインサービスのトラフィックやリクエスト内容を特定の分析のためにミラーリングサービスに複製し、オンラインサービスを中断することなく分析できます。
Blue-Green
_Blue-Green_は通常、ルーター、ゲートウェイ、またはロードバランサーを使用するアーキテクチャのポイントで実装されます。その背後には、完全なBlue環境とGreen環境があります。現在のBlue環境は現在のライブ環境を表し、Green環境は次のバージョンのスタックを表します。Green環境は、ライブトラフィックに切り替える前にチェックされ、切り替え時にトラフィックがBlueからGreenに切り替わります。Blue環境は現在「オフ」ですが、問題が発見された場合には迅速にロールバックできます。次の変更はGreenからBlueに行われ、最初のリリース以降に振動します。
Blue-Greenはそのシンプルさからうまく機能し、結合されたサービスのためのより良いデプロイメントオプションの1つです。また、永続的なサービスを管理するのも簡単ですが、ロールバックの際には注意が必要です。また、現在アクティブな環境と並行してコールドで実行するために、2倍のリソースが必要です。
Argo Rolloutsを使用したトラフィック管理
これまでに議論した戦略は多くの価値を追加しますが、ロールアウト自体は手動で管理したくないタスクです。ここで、Argo Rolloutsのようなツールが、議論された懸念事項を実践的に示すために価値があります。
Argoを使用すると、APIの新しいCanaryをロールアウトするために取ることができる戦略を表すRollout CRD（カスタムリソース定義）を定義することができます。CRDにより、ArgoはKubernetes APIを拡張してロールアウトの動作をサポートできます。CRDはKubernetesで人気のあるパターンであり、ユーザーは1つのAPIと異なる機能をサポートする拡張機能と対話できます。
Apache APISIXとApache APISIX Ingress Controllerを使用して、Argo Rolloutsと共にトラフィック管理を行うことができます。このガイドでは、ApisixRouteをArgo Rolloutsと統合し、重み付きラウンドロビンロードバランサーとして使用する方法を示します。
まとめ
プログレッシブデリバリーアプローチの台頭と、それ以前の継続的デリバリーにおける高度な要件により、サービス（および対応するAPI）のデプロイメントとリリースを分離する能力は強力な技術です。Canaryリリースを行い、API Gatewayのトラフィック分割やミラーリング機能を活用することで、リリースのリスクを軽減し、顧客の要件をより効果的に理解するための競争優位性をビジネスに提供できます。