많은 기업과 SaaS 회사는 다양한 외부 API 통합에 의존하여 뛰어난 고객 경험을 구축한다.일부 통합은 일부 업무 기능(예를 들어 지불 처리나 검색)을 Stripe와 Algolia 등 회사에 하청할 수 있다.
분석 도구에 실시간 경고를 추가하려는 경우 응용 프로그램에 PagerDuty 및 Slack API를 통합하는 등 제품 기능을 확장하는 다른 파트너가 이미 통합되어 있을 수 있습니다.
만약 당신이 대부분의 회사와 같다면, 당신은 수백 개의 다른 공급업체와 합작 파트너를 응용 프로그램에 통합시키고 있다는 것을 곧 깨닫게 될 것이다.그 중 어느 것이든 고객 체험에 영향을 미치는 성능이나 기능 문제가 존재할 수 있습니다.최악은 통합의 신뢰성이 자신의 API와 백엔드보다 현저하지 않을 수도 있다는 것이다.만약 로그인 기능이 파괴된다면, 많은 고객들이 그들이 당신의 사이트에 로그인할 수 없다고 불평할 것이다.
그러나 느슨한 통합이 파괴되면 계정에 느슨한 고객을 추가해야 영향을 받을 수 있습니다.이외에도 통합은 비동기적이기 때문에 고객은 며칠 후에야 통합이 파괴되었다는 것을 깨달을 수 있습니다. 왜냐하면 그들은 이미 한동안 어떤 경보도 받지 못했기 때문입니다.
당신은 어떻게 당신의 API 통합이 신뢰성과 고성능이라는 것을 확보합니까?어쨌든, 만약 당신이 실시간 경보 기능을 판매하고 있다면, 당신의 경보는 실시간으로 하는 것이 가장 좋고, 적어도 한 번은 교부를 보증하는 것이 가장 좋다.고객 환경의 측면에서 볼 때 느슨하거나 페이지의 불필요한 통합은 받아들일 수 없기 때문에 경보를 삭제합니다.

모니터링할 내용

딜레이

지연 시간이 매우 높은 특정 API 통합은 통합이 실패할 것이라는 신호일 수 있습니다.페이지 나누기 방안이 정확하지 않거나 공급업체가 효율적인 조회를 위해 데이터를 인덱스하지 않았을 수도 있습니다.

모범 사례 지연

평균 지연은 반만 설명할 수 있다.항상 1초가 걸려야 완성되는 API는 일반적으로 방차가 높은 API보다 좋다.
예를 들어 API 한 개에 평균 30ms가 걸리지만 API 호출 10개 중 1개에 5초가 걸린다면 고객 경험의 차이가 매우 크다.이로 인해 추적 오류가 더욱 어려워지고 고객 체험에서도 처리하기 어렵다.
이것이 바로 90퍼센트와 95퍼센트가 중요한 이유다.

신뢰성

신뢰성은 모니터링이 필요한 관건적인 지표입니다. 특히 제어할 수 없는 API가 통합된 후입니다.API 호출 실패 비율은 얼마입니까?신뢰성을 추적하기 위해서, 고장 구성에 대해 엄격한 정의를 내려야 합니다.

신뢰성 모범 사례

4xx 또는 5xx 시리즈에서 응답 상태 코드가 있는 모든 API 호출은 오류로 간주될 수 있지만, 특정 업무 사례에서 API가 성공적으로 완성된 것 같지만 API 호출은 실패로 간주되어야 한다.예를 들어, 상태 코드가 항상 200 OK인 경우에도 데이터 API 통합이 일치하는 항목이나 컨텐트를 반환하지 않으면 실패로 간주될 수 있습니다.다른 API는 거짓 또는 불완전한 데이터를 반환할 수 있습니다.데이터 검증은 되돌아오는 데이터의 정확성과 최신의 여부를 측정하는 데 매우 중요하다.
API 공급업체 및 통합 파트너가 권장 사항을 따르지 않음status code mapping

활용성

신뢰성은 오류와 기능의 정확성에 특정되지만 가용성과 정상 운행 시간은 순수한 인프라 지표로 서비스 중단의 빈도를 측정하는 데 사용된다.
가용성은 일반적으로 연간 가동 시간의 백분율 또는 number of 9's. 으로 측정됩니다.

활용단어참조

많은 API 공급업체는 API 사용량에 따라 가격을 정합니다.비록 API가 무료라고 해도 그들은 API에 어떤 속도 제한을 실현하여 나쁜 참여자가 좋은 클라이언트를 굶어 죽이지 않도록 확보할 가능성이 높다.즉, 각 통합 파트너와 API 사용 상황을 추적하는 것은 현재 사용 상황이 계획 제한이나 속도 제한에 근접한 시기를 파악하는 데 매우 중요합니다.

모범 사례 사용

API가 고객 환경의 하위권에 통합되어 있더라도 최종 사용자와 연계하는 것이 좋습니다.
이것은 특정한 통합된 직접 투자 수익률을 측정하고 추세를 발견할 수 있다.예를 들어 제품이 CRM이라고 가정하면 매달 Clearbit 199달러를 지불하여 2500개 회사를 풍부하게 합니다.이것은 고객의 사용 상황과 관련된 직접적인 비용입니다.
만약 빈 층이 있고 대부분의 Clearbit 할당량을 사용하고 있다면, 가격 정책을 다시 고려해야 할 수도 있습니다.가능한 경우, Clearbit 확장은 비용을 지불하는 층에서 해야 합니다. 단지 당신의 원가를 낮추기 위해서입니다.

API 통합 모니터링 방법

API 통합을 모니터링하는 것이 이러한 문제를 해결하는 올바른 방법인 것 같습니다.그러나 전통적인 응용 프로그램 성능 감시(APM) 도구(예를 들어 New Relic과 AppDynamics)는 자신의 사이트와 인프라 시설의 건강 상태를 감시하는 데 더욱 중심을 두었다.
메모리 사용률과 분당 요청 수, 응용 프로그램 수준의 건강 상태, 예를 들어 appdex 점수와 지연 등 인프라 지표를 포함한다.물론 다른 사람의 인프라에서 실행 중인 API를 사용하고 있는 경우 액세스할 수 있는 APM 에이전트를 타사 공급업체에만 설치할 수 없습니다.
이것은 귀하가 제3자 API를 간접적으로 감시하거나 다른 검사 방법을 통과해야 한다는 것을 의미합니다.

API 호출에 대한 문제 모니터링

타사 API 호출을 감시하기 위해서는 응용 프로그램이 타사에 도착하기 전에 응용 프로그램에서 전송된 API 호출을 기록하고 응답을 기록하는 메커니즘이 필요합니다.
많은 APM 에이전트가 JVM 스레드 분석이나 메모리 백분율과 같은 인프라 지표를 캡처하는 데 적합한 프로세스 수준 캡처 지표이지만 응용 프로그램에 특정된 상하문을 캡처하는 데는 비교적 좋지 않다.
두 번째 도전은 응용 프로그램의 전송 호출이 보통 자신의 코드에 분산되어 있고, 응용 프로그램에 가져온 모든 공급업체별 SDK에도 분산되어 있다는 것이다.각 타사 SDK에는 API 통신을 처리하기 위한 자체 콜백 및 논리가 있습니다.
따라서 API 트래픽을 차단하기 위해 공급업체별 SDK를 사용하지 않거나 수정하지 않는 한 교차 관심사나 중앙 에이전트를 통해 전송되는 모든 API 호출을 캡처하기 어렵습니다.공사팀이 할 시간이 있는 대량의 바쁜 업무는 매우 드물다.

Real user API monitoring is the recommended practice leveraged by modern tech companies. Real user API monitoring looks at real customer traffic rather than scheduled probes.

이를 통해 건강 증명서가 포착할 수 없는 특정한 접근 패턴과 같은 더욱 깊은 통합 문제를 포착할 수 있습니다.

저희가 Moesif에서 어떻게 했냐면요.

Moesif에서 우리는 핵심 HTTP 클라이언트 라이브러리에 몽키 패치와 반사를 이용하여 일반적인 프로그래밍 언어에 추적 코드를 주입하여 구축한다SaaS solution that tracks third party APIs.
응용 프로그램 자체에 삽입되기 때문에 업무에 특정한 상하문, 예를 들어 API 호출을 시작하여 특정한 응답 헤더를 기록하는 원시 최종 사용자를 추가할 수 있습니다. 이 응답 헤더는 속도 제한이나 다른 소프트 오류의 세부 사항을 제공합니다.
대부분의 언어는 단일 또는 소량의 핵심 HTTP 라이브러리에 의존하기 때문에 이를 수행할 수 있습니다.노드의 경우js, 모든 HTTP 통신은 http 또는 https 모듈을 기반으로 합니다.Python의 경우 대부분의 고급 클라이언트가 라이브러리Python requests를 사용합니다.
노드 중간부품의 예입니다.전송 API 호출을 감지하는 js는 다음과 같습니다.

var express = require('express');
var app = express();
var moesifExpress = require('moesif-express');

// 2. Set the options, the only required field is applicationId.
var moesifMiddleware = moesifExpress({
  applicationId: 'Your Moesif Application Id',
  logBody: true
});

// 3. Start capturing outgoing API Calls to 3rd party services like Stripe
moesifMiddleware.startCaptureOutgoing();

startCaptureOutgoing() 노드에 원숭이 패치를 진행한다.jshttp 및 https 모듈, 다시 쓰기를 통해http 및 https 대상은 우리의 수정 대상과 함께 API 호출을 차단합니다.
우리가 어떻게 노드를 위해 몽키 수리를 집행하는지 예시합니다.js는 아래에 있고 전체 SDK도 GitHub.에서 찾을 수 있습니다

function _patch(recorder, logger) {
  var originalGet = http.get;
  var originalHttpsGet = https.get;

  var originalRequest = http.request;
  var originalHttpsRequest = https.request;

  http.request = function(options, ...requestArgs) {
    var request = originalRequest.call(http, options, ...requestArgs);
    if (!request._mo_tracked) {
      request._mo_tracked = true;
      track(options, request, recorder, logger);
    }
    return request;
  };

  https.request = function(options, ...requestArgs) {
    var request = originalHttpsRequest.call(https, options, ...requestArgs);
    if (!request._mo_tracked) {
      request._mo_tracked = true;
      track(options, request, recorder, logger);
    }
    return request;
  };

  http.get = function(options, ...requestArgs) {
    var request = http.request.call(http, options, ...requestArgs);
    request.end();
    return request;
  };

  https.get = function(options, ...requestArgs) {
    var request = https.request.call(https, options, ...requestArgs);
    request.end();
    return request;
  };

  function _unpatch() {
    http.request = originalRequest;
    https.request = originalHttpsRequest;
    http.get = originalGet;
    https.get = originalHttpsGet;
  }

  return _unpatch;
}

어떻게 감시를 이용합니까

대시보드를 설정하고 API 통합을 보고하면 됩니다.이러한 데이터를 다양한 방식으로 활용하여 고객 환경을 개선할 수 있습니다.

지표가 경계를 넘거나 이상 행위가 있을 때 경보를 설치한다.한 가지 간단한 방법은 PagerDuty, Slack을 통해
다른 경로.

파트너에게 SLA에 대한 책임을 요구합니다.한 공급업체와 계속 지연 문제가 발생하거나 실패할 경우 알려 주십시오.만약 당신이 이미 완전한 감사 로그를 가지고 무슨 일이 일어났는지 표시한다면, 합작 파트너는 그들의 인프라 시설을 조정하여 당신의 방문 모델에 더욱 잘 적응할 수 있고, 심지어는 그들이 계약 의무를 이행하지 못했을 때 당신에게 환불할 수 있습니다.

다운타임을 방지하고 파트너의 문제에 대해 팀원들이 대처할 수 있도록 합니다.여기에는 파트너가 문제를 해결할 때까지 기능 플래그를 통해 기능을 닫는 것이 포함될 수 있습니다.

고객 중심의 완전한 API 분석 솔루션을 찾으시겠습니까?Check out Moesif!
본고는 Moesif 최고경영자인 데릭 길링(Derric Gilling)이 작성한 것이다.