ゲートウェイAPI作成エクスペリエンス

お客様を含む一部の企業は、アフィリエイトネットワークを通じて製品を開発しています。 たとえば、大規模なオンラインストアは配送サービスと統合されています。商品を注文すると、すぐに荷物の追跡番号を受け取ります。 もう1つの例は、チケットまたは保険またはAeroexpressチケットを購入することです。



このために、1つのAPIが使用されます。これは、ゲートウェイAPIを介してパートナーに発行する必要があります。 この問題を解決しました。 この記事では詳細を説明します。



指定：ユーザーの登録、情報の受信などを行うインターフェースを備えたエコシステムおよびAPIポータル 便利で信頼できるAPI Gatewayを作成する必要があります。 その過程で、提供する必要がありました

• 登録
• API接続制御
• ユーザーがエンドシステムを使用する方法を監視する
• ビジネス指標の会計。

この記事では、Gateway APIを作成した経験について説明し、その間に次のタスクを解決しました。

• ユーザー認証
• ユーザー認証
• 元のリクエストの変更、
• プロキシを要求する
• 応答の後処理。

API管理には2つのタイプがあります。



1.標準。次のように機能します。 接続する前に、ユーザーは可能性をテストし、支払いをして自分のサイトに埋め込みます。 ほとんどの場合、中小企業で使用されます。



2.大規模なB2B API管理は、企業が最初に接続に関するビジネス上の決定を下したときに、契約上の義務を持つパートナー企業になり、APIに接続します。 そして、すべての手続きを済ませた後、会社はテストアクセスを受け取り、テストに合格して製品に行きます。 しかし、これは管理者が接続するという決定なしには不可能です。

私たちの決定

このパートでは、Gateway APIの作成について説明します。



APIへの作成されたゲートウェイのエンドユーザーは、お客様のパートナーです。 それぞれについて、すでに必要な契約があります。 ゲートウェイへの許可されたアクセスに注意して、機能を拡張するだけです。 したがって、制御された接続および制御プロセスが必要です。



もちろん、API Managementタスクを解決し、特にAPI Gatewayを作成するための既製のソリューションを利用することもできました。 たとえば、これはAzure API Managementになります。 私たちの場合、APIポータルとその周りに構築された巨大なエコシステムがすでにあったため、私たちには適していませんでした。 すべてのユーザーはすでに登録されており、必要な情報を取得できる場所と方法をすでに理解しています。 必要なインターフェースはAPIポータルにすでに存在しており、APIゲートウェイが必要でした。 実際、私たちはその開発に取り組んでいます。



ゲートウェイAPIと呼ばれるものは、一種のプロキシです。 ここでも、選択肢がありました。プロキシを作成するか、既製のものを選択できます。 この場合、2番目の方法でnginx + Luaバンドルを選択しました。 なんで？ スケーリングをサポートする信頼できるテスト済みのソフトウェアが必要でした。 実装後、ビジネスロジックの正確性とプロキシの正確性を確認する必要はありませんでした。



Webサーバーには、リクエスト処理パイプラインがあります。 nginxの場合、次のようになります。







（ GitHub Lua Nginxの図）



私たちの目標は、元のリクエストを変更できる瞬間にこのパイプラインに統合することでした。



透過プロキシを作成して、要求が機能するように機能します。 最終的なAPIへのアクセスのみを制御し、要求へのアクセスを支援します。 リクエストが正しくなかった場合、最終的なAPIにはエラーが表示されますが、表示されません。 リクエストを拒否できる唯一の理由は、クライアントへのアクセス権がないためです。



nginxの場合、 拡張機能はLuaにすでに存在します 。 Luaはスクリプト言語であり、非常に軽量で習得が容易です。 したがって、Luaを使用して必要なロジックを実装しました。



すべての作業が行われるnginxの設定（アプリケーションのルートに対するアナロジー）は理解できます。 ここで注目すべきは、最後のディレクティブpost_actionです。

location /middleware { more_clear_input_headers Accept-Encoding; lua_need_request_body on; rewrite_by_lua_file 'middleware/rewrite.lua'; access_by_lua_file 'middleware/access.lua'; proxy_pass https://someurl.com; body_filter_by_lua_file 'middleware/body_filter.lua'; post_action /process_session; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成で何が起こるかを検討してください。

more_clear_input_headers-ディレクティブの後に指定されたヘッダーの値をクリアします。

lua_need_request_body -rewrite / access / access_by_luaディレクティブを実行する前に元のリクエスト本文を読み取るかどうかを制御します。 デフォルトでは、nginxはクライアントリクエストの本文を読み取りません。アクセスする必要がある場合は、このディレクティブをonに設定する必要があります。

rewrite_by_lua_file-スクリプトへのパス。リクエストを変更するためのロジックを記述します

access_by_lua_file-スクリプトへのパス。リソースへのアクセスをチェックするロジックを記述します。

proxy_pass-リクエストがプロキシされるURL。

body_filter_by_lua_file-スクリプトへのパス。クライアントに戻る前にリクエストをフィルタリングするロジックを記述します。

そして最後に、 post_actionは公式に文書化されていないディレクティブであり、クライアントに応答が与えられた後に他のアクションを実行するために使用できます。



次に、問題をどのように解決したかを順番に説明します。

承認/認証およびリクエストの変更

ログイン



証明書アクセスを使用して承認と認証を構築しました。 ルート証明書があります。 顧客の各新規クライアントは、APIにアクセスできる個人証明書を生成します。 この証明書は、nginx設定サーバーセクションで構成されます。

 ssl on; ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem; ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem; ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt; ssl_verify_client on;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

修正



公正な質問が発生する可能性があります：突然クライアントをシステムから切断したい場合、認証されたクライアントをどうするか？ 他のすべてのクライアントに対して証明書を再発行しないでください。



そこで、私たちはスムーズに次のタスク、つまり元のリクエストの変更に取り組みました。 一般的に言えば、最初のクライアント要求は最終システムでは無効です。 タスクの1つは、不足している部分をリクエストに追加して有効にすることです。 ポイントは、不足しているデータがクライアントごとに異なることです。 クライアントは、指紋を取得し、データベースから必要なクライアントデータを抽出できる証明書を持って来ていることを知っています。



ある時点でクライアントをサービスから切断する必要がある場合、彼のデータはデータベースから消え、彼は何もできなくなります。

顧客データを操作する

ソリューションの高可用性、特に顧客データの取得方法を確保する必要がありました。 困難なのは、このデータのソースがサードパーティのサービスであり、中断のない高速性が保証されていないことです。



したがって、顧客データの高可用性を確保する必要がありました。 ツールとして、 Hazelcastを選択しました。

• データへの迅速なアクセス
• 異なるノードに複製されたデータを使用して、いくつかのノードのクラスターを編成する機能。

最も単純なキャッシュ配信戦略を選びました。







最終システムでの作業はセッションのフレームワーク内で行われ、最大数には制限があります。 クライアントがセッションを閉じなかった場合、これを行う必要があります。



オープンセッションデータはターゲットシステムから取得され、最初はLua側で処理されます。 Hazelcastを使用して、このデータを.NETライターで保存することにしました。 その後、一定の間隔で、オープンセッションの存続権を確認し、ファウルをクローズします。

Luaと.NETの両方からHazelcastにアクセス

LuaにはHazelcastと連携するクライアントはありませんが、HazelcastにはREST APIがあり、使用することにしました。 .NETには、.NET側でHazelcastデータにアクセスすることを計画したクライアントがあります 。 しかし、そこにありました。







RESTを介してデータを保存し、.NETクライアントを介して取得する場合、異なるシリアライザー/デシリアライザーが使用されます。 したがって、RESTを介してデータを送信することはできませんが、.NETクライアントを介してデータを取得することはできません。



興味がある場合は、別の記事でこの問題について詳しく説明します。 ネタバレ-シェムカの上。

ロギングとモニタリング

.NETを介したロギングの企業標準はSerilogであり、すべてのログは最終的にElasticsearchに格納され、Kibanaを介して分析します。 この場合、似たようなことをしたかったのです。 LuaでElasticを使用する唯一のクライアントは、最初の要求で壊れました。 そして、Fluentdを使用しました。



Fluentdは、単一のアプリケーションロギングレイヤーを提供するためのオープンソースソリューションです。 アプリケーションのさまざまなレイヤーからログを収集し、それらを単一のソースに変換できます。



Gateway APIはK8Sで機能するため、fluentdのコンテナを同じサブタイプに追加して、既存のオープンtcpポートfluentdにログを書き込むことにしました。



また、Elasticsearchとの関係がなかった場合のfluentdの動作についても調査しました。 2日間、リクエストはゲートウェイに継続的に送信され、ログはfluentdに送信されましたが、IP Elasticはfluentdから禁止されました。 再接続後、fluentdはElasticのすべてのログを完全に上回りました。

おわりに

実装への選択されたアプローチにより、実際に機能する製品をわずか2.5か月で戦闘環境に提供することができました。



そのようなことをしたことがある場合は、まず、解決しようとしている問題と、すでに持っているリソースを明確に理解することをお勧めします。 既存のAPI管理システムとの統合の複雑さに注意してください。



正確にあなたが開発しようとしているものを理解してください-リクエストを処理するビジネスロジック、または私たちの場合のように、プロキシ全体のみ。 自分で行うことはすべて、後で徹底的にテストする必要があることを忘れないでください。