API Gateway 생성 경험

우리 고객을 포함한 일부 회사는 제휴 네트워크를 통해 제품을 개발합니다. 예를 들어, 대형 온라인 상점은 배송 서비스와 통합되어 있습니다. 즉, 제품을 주문하면 곧 소포 추적 번호를 받게 됩니다. 또 다른 예는 항공권과 함께 보험이나 Aeroexpress 항공권을 구매하는 것입니다.

이를 위해 API 게이트웨이를 통해 파트너에게 발급되어야 하는 하나의 API가 사용됩니다. 우리는 이 문제를 해결했습니다. 이 기사에서는 세부 사항을 알려 드리겠습니다.

주어진 내용: 사용자가 등록하고 정보를 받는 등의 인터페이스를 갖춘 생태계와 API 포털 편리하고 안정적인 API 게이트웨이를 만들어야 합니다. 그 과정에서 우리는 다음을 보장해야 했습니다.

• 등록,
• API 연결 제어,
• 사용자가 최종 시스템을 사용하는 방법을 모니터링하고,
• 비즈니스 지표 회계.

이 기사에서는 API Gateway를 생성하면서 다음 문제를 해결한 경험에 대해 설명합니다.

• 사용자 인증,
• 사용자 인증,
• 원래 요청을 수정하고,
• 요청을 프록시하고,
• 응답 후처리.

API 관리에는 두 가지 유형이 있습니다.

1. 표준은 다음과 같이 작동합니다. 연결하기 전에 사용자는 기능을 테스트한 다음 비용을 지불하고 웹사이트에 삽입합니다. 대부분 중소기업에서 사용됩니다.

2. 대규모 B2B API 관리는 회사가 처음 연결하기로 사업적 결정을 내릴 때 계약상의 의무를 가지고 회사의 파트너가 된 후 API에 연결합니다. 그리고 모든 절차가 완료되면 회사는 테스트 액세스 권한을 받고 테스트를 거쳐 생산에 들어갑니다. 그러나 이는 연결에 대한 경영진의 결정 없이는 불가능합니다.

우리의 솔루션

이번 시간에는 API Gateway 생성에 대해 알아보겠습니다.

생성되는 API 게이트웨이의 최종 사용자는 고객의 파트너입니다. 각각에 대해 필요한 계약이 이미 저장되어 있습니다. 게이트웨이에 대한 액세스 권한을 부여하여 기능을 확장하기만 하면 됩니다. 따라서 제어된 연결 및 관리 프로세스가 필요합니다.

물론 API 관리 문제를 해결하고 특히 API 게이트웨이를 생성하기 위해 기성 솔루션을 사용할 수도 있었습니다. 예를 들어, 다음과 같을 수 있습니다. Azure API 관리. 우리의 경우 이미 API 포털과 이를 중심으로 구축된 거대한 생태계가 있었기 때문에 이는 우리에게 적합하지 않았습니다. 모든 사용자는 이미 등록되어 있으며 필요한 정보를 어디서, 어떻게 얻을 수 있는지 이미 알고 있었습니다. 필요한 인터페이스는 이미 API 포털에 존재하며 API 게이트웨이만 필요했습니다. 사실 우리는 그것을 개발하기 시작했습니다.

우리가 API 게이트웨이라고 부르는 것은 일종의 프록시입니다. 여기서도 선택의 여지가 있었습니다. 자신만의 프록시를 작성할 수도 있고 이미 만들어진 것을 선택할 수도 있습니다. 이 경우 우리는 두 번째 경로를 선택하고 nginx+Lua 조합을 선택했습니다. 왜? 우리는 확장이 가능하고 신뢰할 수 있고 테스트를 거친 소프트웨어가 필요했습니다. 우리는 비즈니스 로직의 정확성과 구현 후 프록시의 올바른 작동을 모두 확인하고 싶지 않았습니다.

모든 웹 서버에는 요청 처리 파이프라인이 있습니다. nginx의 경우 다음과 같습니다.

(다이어그램 GitHub 루아 Nginx)

우리의 목표는 원래 요청을 수정할 수 있는 지점에서 이 파이프라인에 우리 자신을 삽입하는 것이었습니다.

우리는 기능적으로 요청이 온 것과 동일하게 유지되도록 투명한 프록시를 만들고 싶습니다. 우리는 최종 API에 대한 액세스만 제어하고 요청이 API에 도달하도록 돕습니다. 요청이 잘못된 경우 최종 API에는 오류가 표시되지만 우리에게는 표시되지 않습니다. 요청을 거부할 수 있는 유일한 이유는 클라이언트에 액세스 권한이 없기 때문입니다.

nginx에는 이미 존재합니다. 확대 에 루아. 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 — 리소스에 대한 액세스를 확인하는 논리를 설명하는 스크립트 경로입니다.
프록시 패스 — 요청이 프록시될 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;

수정

공정한 질문이 발생할 수 있습니다. 인증된 클라이언트를 갑자기 시스템에서 연결 해제하려는 경우 어떻게 해야 합니까? 다른 모든 클라이언트에 대해 인증서를 재발급하지 마십시오.

그래서 우리는 원래 요청을 수정하는 다음 작업에 순조롭게 접근했습니다. 일반적으로 클라이언트의 원래 요청은 최종 시스템에 유효하지 않습니다. 작업 중 하나는 누락된 부분을 요청에 추가하여 유효하게 만드는 것입니다. 요점은 누락된 데이터가 클라이언트마다 다르다는 것입니다. 우리는 클라이언트가 지문을 채취하고 데이터베이스에서 필요한 클라이언트 데이터를 가져올 수 있는 인증서를 가지고 우리에게 온다는 것을 알고 있습니다.

어느 시점에 귀하가 당사 서비스에서 클라이언트의 연결을 끊어야 하는 경우, 해당 클라이언트의 데이터는 데이터베이스에서 사라지고 클라이언트는 아무것도 할 수 없게 됩니다.

클라이언트 데이터 작업

우리는 솔루션, 특히 고객 데이터를 얻는 방법의 고가용성을 보장해야 했습니다. 문제는 이 데이터의 주요 소스가 제3자 서비스이기 때문에 중단 없이 충분히 빠른 속도를 보장하지 않는다는 것입니다.

따라서 우리는 고객 데이터의 고가용성을 보장해야 했습니다. 우리는 도구로 선택했습니다 헤이젤 캐스트이는 우리에게 다음을 제공합니다:

• 데이터에 대한 빠른 접근,
• 서로 다른 노드에 복제된 데이터로 여러 노드의 클러스터를 구성하는 기능.

우리는 캐시에 데이터를 전달하기 위한 가장 간단한 전략을 따랐습니다.

최종 시스템 작업은 세션 내에서 이루어지며 최대 개수에는 제한이 있습니다. 클라이언트가 세션을 닫지 않으면 이를 수행해야 합니다.

공개 세션 데이터는 최종 시스템에서 제공되며 처음에는 Lua 측에서 처리됩니다. 우리는 .NET으로 작성된 작업으로 이 데이터를 저장하기 위해 Hazelcast를 사용하기로 결정했습니다. 그런 다음 어느 정도 빈도로 열려 있는 세션의 수명을 확인하고 썩은 세션을 닫습니다.

Lua와 .NET 모두에서 Hazelcast에 액세스하세요.

Hazelcast와 함께 작동하는 Lua 클라이언트는 없지만 Hazelcast에는 우리가 사용하기로 결정한 REST API가 있습니다. .NET의 경우 클라이언트, 이를 통해 우리는 .NET 측에서 Hazelcast 데이터에 액세스할 계획이었습니다. 그러나 그것은 거기에 없었습니다.

REST를 통해 데이터를 저장하고 .NET 클라이언트를 통해 검색할 때 다양한 직렬 변환기와 역직렬 변환기가 사용됩니다. 따라서 REST를 통해 데이터를 저장하고 .NET 클라이언트를 통해 데이터를 검색할 수 없으며 그 반대의 경우도 마찬가지입니다.

누구든지 관심이 있으시면 별도의 기사에서 이 문제에 대해 자세히 설명하겠습니다. 스포일러 - 다이어그램에 있습니다.

로깅 및 모니터링

.NET을 통한 로깅에 대한 당사의 기업 표준은 Serilog이며, 모든 로그는 궁극적으로 Elasticsearch에 저장되며 Kibana를 통해 분석됩니다. 이 경우에도 비슷한 일을 하고 싶었습니다. 유일한 사람 클라이언트 발견된 Elastic on Lua 작업은 첫 번째 요청에서 중단되었습니다. 그리고 우리는 Fluentd를 사용했습니다.

유창함 — 단일 애플리케이션 로깅 계층을 제공하는 오픈 소스 솔루션입니다. 애플리케이션의 다양한 계층에서 로그를 수집한 다음 이를 단일 소스로 브로드캐스트할 수 있습니다.

API Gateway는 K8S에서 실행되므로 기존의 fluentd 개방형 TCP 포트에 로그를 쓰기 위해 동일한 Pod에 fluentd가 포함된 컨테이너를 추가하기로 결정했습니다.

또한 Elasticsearch에 연결되지 않은 경우 Fluentd가 어떻게 작동하는지 살펴보았습니다. 이틀 동안 지속적으로 게이트웨이로 요청이 전송되고, 로그는 fluentd로 전송되었지만 Fluentd의 IP Elastic은 금지되었습니다. 연결이 복원된 후 fluentd는 모든 로그를 Elastic으로 완벽하게 전송했습니다.

결론

구현을 위해 선택한 접근 방식을 통해 우리는 단 2.5개월 만에 실제로 작동하는 제품을 전투 환경에 제공할 수 있었습니다.

이와 같은 일을 하고 있는 경우, 먼저 해결 중인 문제가 무엇인지, 이미 보유하고 있는 리소스가 무엇인지 명확하게 이해하는 것이 좋습니다. 기존 API 관리 시스템과 통합할 때의 복잡성을 인식하세요.

개발할 내용이 정확히 무엇인지 직접 이해하십시오. 즉, 요청 처리를 위한 비즈니스 로직만, 또는 우리의 경우에는 전체 프록시를 이해하십시오. 당신이 스스로 하는 모든 일은 나중에 철저하게 테스트되어야 한다는 것을 잊지 마세요.

출처 : habr.com