NGINXからAPISIXへ – 航空会社ゲートウェイのダイナミクスを再定義

January 24, 2024

Case Study

概要

概要

Skytraxによって世界の5つ星航空会社に選ばれたこの主要航空会社は、30年間安全に運航を続けており、定期旅客輸送、復職・復学のためのチャーター便、アジア、ヨーロッパ、アフリカ、北米、オセアニアなどの旅客便を含む、合計約1,900の国際路線をカバーしています。

急速に成長している航空会社として、この主要航空会社は、効率的なフライト予約プロセスを促進し、異なるシステムやサービスと統合・接続し、高同時実行シナリオや財務・リスクデータを処理するためのAPIゲートウェイを必要としていました。

課題

  • マイクロサービスとコンテナ化されたデプロイメントの増加により、増え続けるNGINXインスタンスと多様なドメイン設定の管理が困難になっています。
  • 多数のNGINXバージョンが共存しているため、プラグインのアップグレード、コンパイル、適応が複雑化しています。
  • 以前のAPIゲートウェイは、この主要航空会社の基本的な要件を満たすことはできましたが、サーキットブレーカーやカナリアリリースなどの高度な機能を提供することはできませんでした。

成果

  • マルチノード設定が簡素化され、APISIXのホットリロード機能により開発効率が大幅に向上し、管理コストが削減されました。
  • 主要航空会社は、APISIXの包括的なプラグインエコシステムを活用して、より高度な機能を実行し、プラグインとシステムのアップグレードを簡素化しました。
  • アップグレードにより、ゲートウェイの効率と保守性が向上し、組織化されたモジュール化された再利用可能な設定管理への重要なシフトが実現しました。

背景

この主要航空会社は、長期間にわたってNGINXを南北ゲートウェイとして使用してきました。しかし、ビジネスと製品ポートフォリオが拡大するにつれて、トラフィックニーズを効果的に処理する一方で、さまざまな側面で増え続ける課題に直面していました。

1. 複数のNGINXインスタンスとドメイン

この会社内には、複数のNGINXインスタンスと異なるドメインのセットがあり、その複雑さが管理の難しさを増していました。NGINXの核心はその設定ファイルにあります。NGINXインスタンスの数が増えるにつれて、SCPを通じてファイルをコピーするだけの設定管理はますます困難になりました。特に、バックエンドでマイクロサービスとコンテナ化されたデプロイメントが広く使用されるようになると、リバースプロキシ設定の柔軟性に対する要求が高まり、設定の一貫性を保つための作業量が大幅に増加しました。

2. さまざまなNGINXバージョンと面倒なプラグインのアップグレード

歴史的な理由から、チームは複数のNGINXバージョンと多数のNGINXプラグインを同時に使用していました。NGINX自体のアップグレードは大きな課題ではありませんでしたが、さまざまなプラグインのアップグレード、コンパイル、適応が困難でした。これらの多くは非公式なものであり、コンパイル中のトラブルシューティングが難しいものでした。さらに、NGINXバージョンとの互換性が保証されていませんでした。

3. NGINX設定の標準化の欠如

さまざまなチームから継承されたシステムにより、NGINX設定の実践方法が多岐にわたり、標準化された設定がありませんでした。統一された設定標準の欠如は、チーム間での実装方法の多様性を浮き彫りにし、NGINX設定に対する統一されたアプローチの必要性を強調しました。

4. 現代的なゲートウェイ機能の不足

NGINXは、リバースプロキシやロードバランシングなどの基本的な南北ゲートウェイの要求を効率的に満たしていましたが、会社の動的なビジネス要件は高度な機能を必要としていました。サーキットブレーカー、セキュリティコントロール、カナリアリリースなどのサービスを実装することは、NGINXだけに頼る場合には困難であり、より堅牢なソリューションの探求を促しました。

正確なビジネスニーズに応じたゲートウェイの選択

NGINXに直面した課題に対処するため、この主要航空会社は新しいゲートウェイソリューションに対する3つの主要な基本要件を慎重に策定しました。

  1. 管理と設定の容易さ: 複数のゲートウェイノードにわたるルートやアップストリームサービスなどの設定を簡単に統一して管理・デプロイできるソリューションが必要です。
  2. APIゲートウェイのより高度な機能: 新しいゲートウェイは、サーキットブレーカー、セキュリティコントロール、カナリアリリースなどの現代的なAPIゲートウェイのビジネス要件を満たす必要があります。
  3. 使いやすさと低い学習曲線: 管理コストを下げることを考慮し、チームは新しいゲートウェイソリューションが設定と低コードの方法でほとんどの基本的な要件を簡単に満たすことを期待しています。

既存の南北ゲートウェイに対する反復的なアップグレードと基本要件を明確にした後、会社は市場で人気のあるさまざまな製品を調査し、最終的にAPISIXを新しいゲートウェイとして選択しました。

OpenRestyを選ばなかった理由

調査中、OpenRestyが最初に検討されました。これは一部の企業で広く採用されているソリューションです。その主な利点は、設定ファイルがNGINXと完全に互換性があることでした。NGINXからOpenRestyへの移行は、複雑なドメイン設定が存在するものの、それほど難しくありませんでした。

しかし、KongやAPISIXと比較して、OpenRestyのオープンソース版には包括的なプラグインや視覚的な設定のためのダッシュボードが欠けていました。ユーザーは、いくつかの基本的な機能を満たすためにコーディングを行う必要がありました。

Kongを選ばなかった理由

航空会社はKongを代替案として検討しました。そのデフォルトのプラグインはほとんどの要件を満たしていましたが、オープンソース版の視覚的インターフェース（ダッシュボード）は数年変わっていなかったため、より更新され使いやすいインターフェースを持つソリューションを好みました。

ストレステストでは、APISIXはKongを上回り、印象的なパフォーマンスを示しました—プラグインなしではKongの2倍、レートリミットとPrometheusプラグインを有効にすると最大10倍の性能を発揮しました。さらに、APISIXはOpenRestyをベースにしており、優れたルーティング能力を示し、チームの自信を高めました。

Envoyを選ばなかった理由

Envoyの印象的な機能にもかかわらず、C++言語と技術チームの制限による学習曲線の急勾配が、Envoyを優先ゲートウェイソリューションとして選択しない決定につながりました。

最終的に、技術チームはその機能と性能が認められたAPISIXを新しいゲートウェイとして選択しました。

APISIXが際立つ理由

APISIXはKongと比較して2つの主な理由で際立っていました。

  • APISIXダッシュボード

    ダッシュボードにより、技術チームはさまざまなルートやプラグイン設定を便利に管理できます。特に、APISIXダッシュボードはプロジェクトのオープンソース部分であり、APISIXの開発に合わせて継続的に更新されるため、管理体験が向上します。

  • Apacheオープンソースプロジェクト

    Apacheソフトウェア財団のトップレベルプロジェクトであるAPISIXは、Kongと比較してユーザーが関連する技術ドキュメントを見つけやすくなっています。Apacheコミュニティのサポートにより、課題に直面した際に信頼できる技術的支援が提供されるため、APISIXは航空会社にとってより適切な選択肢となりました。

さらに、APISIXは前述のNGINXに関する課題を効果的に解決します。

  • APISIXは設定をetcdに保存し、開発者が単一のetcdクラスタをデプロイすることで、異なるドメインの複数のAPISIXノードを簡単に管理できます。

  • APISIXには、ヘルスチェックやその他の監視プラグインなどの一般的なプラグインが含まれており、NGINXで直面したような互換性やアップグレードに関する懸念がなくなります。

  • APISIXには、さまざまなセキュリティとトラフィック制御プラグインが含まれており、サーキットブレーカー、セキュリティコントロール、カナリアリリースなどの機能を簡単に有効にできます。

全体的に、APISIXは技術チームにとって最も適した製品として際立っています。

NGINXからAPISIXへの移行: 高度でよりシンプルなソリューションの探求

NGINXでは、ドメイン管理と機能の実装は主にNGINX設定ファイルを通じて行われます。APISIXは依然としてNGINXとOpenRestyをベースにしていますが、ドメインと機能を管理するためにNGINX設定ファイルを使用しないまったく異なるアプローチを採用しています。

代わりに、APISIXはドメイン名に基づいてルートとアップストリームを設定し、これらのルート上でさまざまな追加機能をプラグインを通じて実装します。APISIXの組み込みCORSプラグインを採用することで、クロスリージョン設定を実現し、行ごとに変換する必要がなくなります。

以下は、NGINXとAPISIXでの設定のコード比較です。

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

NGINXとAPISIXを比較すると、NGINXの設定はより簡潔に見えるかもしれませんが、NGINXとCORSに慣れていない人にとっては、その背後にある意味を理解するのはそれほど簡単ではないかもしれません。一方、APISIXは異なる機能をプラグインにカプセル化し、設定をよりモジュール化しています。そのため、機能を見つけやすく、その機能を理解しやすくなります。NGINXからAPISIXへの設定移行の類似例は、NGINXでWebSocketを設定するなど、さまざまなシナリオに存在します。

成果

マルチノード設定管理の簡素化

APISIXはetcdを使用して設定を保存し、複数のドメインにわたる多様なAPISIXノードを簡単に管理できるようにします。これにより、単一のetcdクラスタを使用してタスクを簡素化し、特定のドメイン設定を持つ異なるAPISIXインスタンスを効果的に制御できます。さらに、集中化された方法により複雑さが減少し、スムーズな管理が促進され、さまざまなドメインシナリオでのAPISIXのスケーラビリティと効率が向上します。その結果、航空会社では、単一のetcdクラスタをデプロイするだけで、異なるドメイン設定にリンクされた異なるAPISIXインスタンスを監視できます。

APISIXプラグインによる操作の簡素化

APISIXには、NGINXで頻繁に使用されるプラグインと同様の一般的なヘルスチェックなどの組み込みプラグインが含まれています。この機能により、航空会社はアップグレードや互換性に関する問題を心配する必要がなくなります。APISIXにこれらのプラグインが含まれていることで、シームレスな機能性が確保され、アップグレードや互換性の維持に関連する懸念が解消され、航空会社にとって手間のかからない体験を提供します。

さらに、APISIXでは、クロスオリジンリソースシェアリング（CORS）やWebSocketサポートなどの機能をプラグインを使用してシームレスに実装できます。このアプローチは、開発プロセスを簡素化するだけでなく、航空会社の課題をより洗練された効率的な方法で解決することに貢献します。

包括的なAPIゲートウェイの確立

APISIXには、さまざまなセキュリティとトラフィック制御プラグインが含まれており、サービスのスロットリング、セキュリティ対策、段階的なリリースなどを簡単に実装できます。これにより、航空会社はより広範な基本的および高度な機能を活用できます。APISIXの採用は、航空会社にとって重要な成果となり、サービスの信頼性の向上、堅牢なセキュリティコントロール、段階的なリリースなどの効率的なデプロイ戦略に貢献し、最終的には運用能力とパフォーマンスの向上につながります。

レガシー設定を再利用可能なモジュールに刷新

アップグレードプロセス全体を通じて、技術チームは既存のNGINX設定に多数の古い設定を発見し、その多くは無意味なコピー＆ペーストが含まれていました。このアップグレードは、特にAPISIXが提供するplugin_configなどの機能に焦点を当てた南北ゲートウェイ全体の包括的な刷新となりました。これらの機能は、ゲートウェイレベルでの設定のモジュール化された管理と再利用を大幅に促進しました。APISIXのplugin_configと関連機能の実装は、設定プロセスを合理化するだけでなく、南北ゲートウェイ全体の効率と保守性を向上させました。このアップグレードは、より組織化されたモジュール化された再利用可能な設定管理アプローチへの重要なシフトを示しました。

まとめ

2023年4月にこの主要航空会社が最初にAPISIXに出会ってから、同年7月に本番環境でNGINXからAPISIXへの移行が成功するまで、移行プロセス全体は満足のいく結果をもたらしました。

移行の初期段階では、技術チームはさまざまな歴史的な設定に対処し、APISIXプラグインが既存のNGINXのすべての機能を完全に再現できるかどうかについて懸念を抱いていました。しかし、最終的な結果は、APISIXプラグインがこの課題を十分に満たすことができることを示しました。

まとめると、APISIXはより洗練されたソリューションを提供し、主要航空会社が新しい技術段階に進むのを支援しました。APISIXは、NGINXで直面したさまざまな課題を完璧に解決し、その豊富なプラグインセットにより、航空会社はクライアントから提示されるさまざまな新しい要件に簡単に対処できます。

Tags:
Airlines