관리 포털 가이드


Red Hat 3scale API Management 2.15

Red Hat 3scale API Management와 관련된 측면을 관리합니다.

Red Hat Customer Content Services

초록

이 가이드에서는 Red Hat 3scale API Management를 관리하는 데 필요한 정보를 제공합니다.

머리말

이 가이드에서는 관리 포털에서 사용 가능한 기능을 사용하여 3scale 설치를 관리하는 데 도움이 됩니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다.

개선 사항을 제안하려면 Jira 문제를 열고 제안된 변경 사항을 설명합니다. 귀하의 요청을 신속하게 처리할 수 있도록 가능한 한 자세한 정보를 제공하십시오.

사전 요구 사항

  • Red Hat 고객 포털 계정이 있어야 합니다. 이 계정을 사용하면 Red Hat Jira Software 인스턴스에 로그인할 수 있습니다. 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

프로세스

  1. 다음 링크를 클릭합니다. 문제 생성.
  2. 요약 텍스트 상자에 문제에 대한 간략한 설명을 입력합니다.
  3. 설명 텍스트 상자에 다음 정보를 입력합니다.

    • 문제를 발견한 페이지의 URL입니다.
    • 문제에 대한 자세한 설명입니다.
      다른 필드에 있는 정보는 기본값에 따라 그대로 둘 수 있습니다.
  4. 생성 을 클릭하여 Jira 문제를 문서 팀에 제출합니다.

피드백을 제공하기 위해 시간을 내어 주셔서 감사합니다.

I 부. 계정 설정

1장. 계정 구성

계정을 만든 후 회사에 대한 기본 정보를 업데이트합니다. 위치를 설정하고 연락처 정보를 추가합니다.

참고
The account view is only visible to administrators, not to members.
Copy to Clipboard Toggle word wrap

1.1. 회사 정보 추가

새 계정을 생성한 후에는 다음 단계를 통해 회사 정보를 추가합니다.

  1. 상단 탐색 모음 오른쪽에 있는 톱니바 아이콘을 클릭합니다. 개요 창이 표시됩니다.
  2. 계정 세부 정보 제목 옆에 있는 편집 링크를 클릭합니다.
  3. 계정에 대한 정보를 입력합니다.

여기에서 지정하는 주소는 다음 두 가지 목표를 갖습니다.

  • 유료 계획에 있는 경우 청구 목적으로 이 주소를 사용하십시오.
  • 청구 및 결제 모듈을 사용하는 경우 이 주소는 사용자가 송장에 표시되는 내용이기도 합니다.

1.2. 선호하는 시간대 선택

동일한 페이지에서 모든 시스템이 표시되는 시간대를 선택할 수도 있습니다. 이 설정은 분석 그래프에 영향을 미칩니다. 그러나 청구 주기 계산은 UTC 시간에 따라 계산됩니다.

이 가이드에서는 3scale API Management 관리 포털을 사용하여 Red Hat Single Sign-On 및 Red Hat build of Keycloak을 구성하고 사용하는 방법에 대한 정보를 제공합니다.

2.1. Red Hat Single Sign-On, Red Hat build of Keycloak 또는 Auth0 멤버 인증 활성화

3scale은 멤버 및 관리자에 대해 SS0(Single Sign-On) 인증을 지원합니다.

3scale 관리 포털은 각각 여러 ID 브로커 및 멤버 페더레이션 옵션을 지원하는 다음 SSO 공급자를 지원합니다.

참고

여러 SSO 멤버 인증 유형을 활성화할 수 있습니다.

Red Hat Single Sign-On, Red Hat build of Keycloak 또는 Auth0에 추가된 사용자만 SSO를 통해 3scale 관리 포털에 액세스할 수 있습니다. 역할 또는 사용자 그룹으로 액세스를 추가로 제한하려면 Red Hat Single Sign-On,Red Hat build of Keycloak 또는 Auth0 지원 포털의 단계별 튜토리얼을 참조하여 해당 단계를 참조해야 합니다.

선택한 공급자를 통해 SSO를 설정한 후에는 3scale 관리 포털에서 이를 구성하고 활성화해야 합니다.

2.1.1. Single Sign-On 사전 요구 사항

  • 문서의 개발자 포털 인증 섹션에 설명된 대로 구성된 SSO(Single Sign-On) 인스턴스 및 영역입니다.

2.1.2. Auth0 사전 요구 사항

  • Auth0 서브스크립션 및 계정.

2.1.3. Red Hat Single Sign-On 활성화

관리자는 3scale 관리 포털에서 다음 단계를 수행하여 Red Hat Single Sign-On, Red Hat build of Keycloak 또는 Auth0을 활성화합니다.

  1. 사전 요구 사항에서 강조 표시된 기본 SSO 공급자가 올바르게 구성되었는지 확인합니다.
  2. 계정 설정에서 SSO 통합으로 이동합니다.

    • 페이지의 오른쪽 상단에 있는 장비 아이콘을 클릭합니다.
    • 계정 설정(gear 아이콘) > 사용자 > SSO 통합으로 이동하여 새 SSO 통합 생성을 클릭합니다.
  3. 드롭다운 목록에서 SSO 공급자를 선택합니다.
  4. SSO를 구성할 때 제공되는 필요한 정보를 입력합니다.

    • 클라이언트
    • 클라이언트 시크릿
    • 영역 또는 사이트
  5. 인증 공급자 생성을클릭합니다.
참고

테스트 중에 콜백 URL 불일치가 발생하면 오류 메시지에 표시된 콜백 URL을 Auth0 허용 콜백 URL에 추가합니다.

SSO를 구성한 후 멤버는 연결된 ID 공급자(IdP)의 계정 자격 증명을 사용하여 로그인할 수 있습니다.

다음 단계에 따라 SSO를 사용하여 3scale API Management 관리 포털에 로그인합니다.

  1. 3scale 로그인 페이지로 이동합니다.

    https://<organization>-admin.3scale.net/p/login
    Copy to Clipboard Toggle word wrap
  2. IdP로 3scale 승인
  3. 필요한 경우 필요한 정보를 입력하여 등록을 완료합니다.

성공적으로 등록하면 API(애플리케이션 프로그래밍 인터페이스) 공급자 조직에 멤버 계정이 있고 자동으로 로그인됩니다.

이 섹션에서는 Red Hat Single Sign-On을 통한 IdP 로그인 창 리디렉션에 대해 설명합니다. 3scale API Management 관리자로서 선택적 SSO 로그인 페이지를 통해 3scale 계정에 액세스할 수 있도록 다음 단계를 완료합니다.

2.3.1. 사전 요구 사항

  • 3scale 2.15
  • 개발자 포털 설명서의 Red Hat Single Sign-On 또는 Red Hat 빌드의 Keycloak 인스턴스 및 영역에 설명된 대로 구성된 영역입니다.
참고

Red Hat Single Sign-On 및 Red Hat Keycloak 빌드를 3scale과 통합하려면 Red Hat Single Sign-On 또는 Red Hat build of Keycloak 인스턴스를 사용해야 합니다. 설치 지침은 Red Hat Single Sign-On 7.6 또는 Red Hat build of Keycloak 24.0 Server 가이드의 Red Hat Single Sign-On 설명서를 참조하십시오.

2.3.2. 필수 단계

  1. 3scale 관리 포털 섹션의 Red Hat Single Sign-On 및 Red Hat build of Keycloak에서 Red Hat Single Sign-On 설정에 대한 액세스 및 지침을 따르십시오.
  2. Red Hat Single Sign-On 또는 Keycloak 관리자의 Red Hat 빌드를 제공하여 보안 로그온을 위한 SSO(Single Sign-On) 내 리디렉션을 위한 기반을 형성할 3scale URL을 제공합니다. 다음 URL 형식을 사용합니다.

    https://<organization>-admin.3scale.net/auth/<system_name>/bounce
    Copy to Clipboard Toggle word wrap
  3. <system_name >은 관리 포털의 SSO 통합 세부 정보 페이지를 통해 가져올 수 있습니다.

    https://<organization>.3scale.net/p/admin/account/authentication_providers/<ID>
    Copy to Clipboard Toggle word wrap
  4. keycloak_0123456aaaa는 다음과 같은 OAuth 흐름 테스트 필드에 대한 콜백 URL 의 SSO 통합 세부 정보 페이지를 통해 찾을 수도 있습니다.

    https://<organization>.3scale.net/auth/keycloak_0123456aaaaa/callback
    Copy to Clipboard Toggle word wrap

3장. 사용자 초대 및 권한 관리

참고

초대 기능은 Pro 및 Enterprise 고객에게만 사용할 수 있습니다.

API(애플리케이션 프로그래밍 인터페이스)를 관리하는 워크로드를 공유하려면 조직에서 팀 멤버를 초대하여 3scale 관리 포털에 액세스할 수 있습니다. 아래 단계에서는 3scale 관리 포털에 대한 액세스 권한을 하나 이상의 팀 멤버에 부여하는 방법을 설명합니다.

사용자 에서는 팀 구성원을 나타냅니다. 3scale 관리 포털에는 다음 두 가지 유형의 사용자가 있습니다.

  • 관리자

    모든 지역 및 서비스에 대한 전체 액세스 권한을 가지며 계획에서 허용하는 경우 다른 멤버를 초대할 수 있습니다.

  • 멤버

    귀하가 엔터프라이즈 고객인 경우, 서비스에 대한 개발자 포털(예: Analytics, 개발자 포털)과 같은 제품의 영역에 대한 액세스가 제한됩니다.

SSO(Single Sign-On) 통합을 통해 새 3scale 사용자를 생성하는 경우 이 사용자에게는 SSO 토큰 콘텐츠에 관계없이 기본적으로 member 역할이 있습니다. 3scale은 해당 역할을 SSO 역할에 매핑하지 않습니다.

3.2. 자주하는 질문

사용자 목록에서 새 팀 멤버를 초대할 수 있습니다. 초대를 보내려면 다음을 수행합니다.

  1. 목록 오른쪽 상단에 있는 Invite 사용자 링크를 클릭합니다.
  2. 초대할 사람의 이메일 주소를 입력하고 보내기 를 클릭합니다.
  3. 전송 확인으로 창의 오른쪽 상단에 표시됩니다. 초대가 성공적으로 전송되었습니다. . . . . .

초대 이메일은 입력한 주소로 전송됩니다. 이메일이 도착하지 않으면 수신자의 이메일 계정에 스팸으로 표시되지 않았는지 확인하십시오.

또한 사용자 > 초대에서 전송된 초대 목록 및 상태를 확인할 수 있습니다.

3.3. 초대 수락

새 관리자 또는 멤버는 초대 이메일의 링크를 클릭하고 양식을 작성하여 프로세스를 완료해야 합니다. 양식이 제출되면 해당 계정이 활성화됩니다.

3.4. 새 사용자 권한 부여

팀 구성원에게 제공할 수 있는 두 가지 주요 권한 유형이 있습니다.

  • 지역별

    분석, 청구 또는 개발자 관리를 통해

  • 서비스별

    모든 서비스 중에서 구성원에게 액세스 권한을 부여할 서비스를 선택합니다. 참고: 이 기능은 엔터프라이즈 사용자만 사용할 수 있습니다.

새 사용자에게 권한을 부여하려면 사용자 메뉴에서 선택하고 편집 을 클릭하여 새 사용자를 편집합니다. 다음과 같은 사용자 역할이 있습니다.

  • Admin 에 대한 권한을 변경하면 관리 포털을 제어할 수 있는 모든 액세스 권한이 부여됩니다.
  • 멤버에 대한 권리를 변경하면 팀 멤버가 액세스할 수 있는 영역과 서비스를 선택할 수 있습니다.

    • 멤버 로서 영역을 선택하여 해당 영역과 관련된 사용 가능한 모든 서비스를 나열합니다.

관리 포털의 특정 영역에 액세스 권한을 부여하면 멤버가 동등한 API에만 액세스할 수 있습니다.

  • 개발자 계정 - 애플리케이션

    계정 관리 API에 대한 액세스 권한을 부여합니다.

  • 분석

    Analytics API에 대한 액세스 권한을 부여합니다.

  • 청구

    billing API에 대한 액세스 권한을 부여합니다.

지역 및 서비스별 권리

4장. 알림

알림은 관리자 및 멤버로 전송되므로 개발자 활동(새 계정)을 더 쉽게 구문 분석할 수 있습니다.

4.1. 알림 유형

알림 유형에는 다음과 같은 다양한 유형이 있습니다.

  • 계정
  • 청구
  • 애플리케이션
  • 서비스 서브스크립션
  • 사용 경고

4.2. 가시성

관리자는 모든 알림에 액세스할 수 있습니다.

멤버 사용자는 액세스 권한이 부여된 영역의 알림에만 액세스할 수 있습니다. 예를 들어 멤버는 청구 섹션에 액세스할 수 있는 경우에만 청구와 관련된 알림에 액세스할 수 있습니다.

엔터프라이즈 계정 의 경우 멤버 사용자는 액세스 권한이 부여된 서비스의 활동에 대한 알림만 액세스할 수 있습니다.

4.3. 이메일로 알림 구독

서브스크립션은 개인적이며 해당 알림을 받는 사람만 수정할 수 있습니다. 서브스크립션을 편집하려면 다음을 수행합니다.

  1. 계정 설정 > 개인 > 알림 기본 설정으로 이동합니다.
  2. 수신하려는 알림을 선택합니다.
  3. 알림 기본 설정 업데이트를 클릭합니다.

4.4. 웹 알림

이메일 알림 외에도 대시보드의 마지막 활동에 대한 정보를 찾을 수 있습니다.

계정 대시보드

5장. 개인 설정

개인 설정에서 기본 설정을 팀 멤버로 편집할 수 있습니다. 관리자인 경우 계정 기본 설정도 편집할 수 있습니다. 이를 위해 계정 구성 튜토리얼을 확인하십시오.

개인 설정을 편집하려면 다음을 수행합니다.

  1. 탐색 모음에서 도구 모음 아이콘을 클릭합니다.Click the toolbar icon in the navigation bar.
  2. 왼쪽 패널에서 Personal 로 이동합니다.

    여기에서 편집할 수 있는 세 가지 유형의 설정이 있습니다.

    • 개인 세부 정보

      이름, 이메일, 암호

    • 토큰

      3scale API(애플리케이션 프로그래밍 인터페이스) - billing, Account Management, Analytics에 대해 인증할 수 있는 액세스 토큰을 생성하고 ActiveDocs를 사용하여 사용해 보십시오. 3scale 토큰에 대해 자세히 알아보십시오.

    • 알림 설정

      수신하려는 알림을 선택합니다.

      참고: 엔터프라이즈 고객이고 멤버인 경우 지역 및 서비스로 필터링됩니다. 즉, 액세스 권한이 부여된 영역 및 서비스에 대한 알림만 등록할 수 있습니다. 여기에 알림 기본 설정에 대한 자세한 내용은 다음과 같습니다.

6장. 토큰

이 튜토리얼에는 3scale 토큰의 기능, 작동 방식 및 생성 방법에 대한 정보가 포함되어 있습니다.

3scale에는 두 가지 유형의 토큰, 즉 사용자가 생성한 액세스 토큰과 서비스 토큰 (3scale에서 새 서비스를 생성할 때 자동으로 생성됨)이 있습니다.

6.1. 액세스 토큰

액세스 토큰을 사용하면 API(애플리케이션 프로그래밍 인터페이스) 공급자 관리자와 멤버가 3scale API(예: billing, 계정 관리 및 분석)에 대해 인증하고 ActiveDocs를 사용하여 이를 시도할 수 있습니다.

액세스 토큰은 읽기 및 쓰기 액세스 또는 읽기만 제공할 수 있습니다.

고려해야 할 중요한 사항은 액세스 토큰의 작동 방식이며 이는 멤버의 권한에 따라 다릅니다. 관리자는 3개의 3scale API 모두에 대해 인증하는 토큰을 생성할 수 있습니다. 멤버는 관리 포털의 다른 부분에 액세스하도록 권한에 의해 제한됩니다. 예를 들어 멤버가 billing 영역에 액세스할 수 없는 경우 billing API에 대해 인증하는 토큰을 생성할 수 없습니다.

6.2. 액세스 토큰 생성

액세스 토큰은 토큰 페이지에서 생성할 수 있습니다. 토큰을 생성하려면 다음 단계를 따르십시오.

  1. 탐색 모음에서 도구 모음 아이콘을 클릭합니다.Click the toolbar icon in the navigation bar.
  2. 개인 > 토큰으로 이동합니다.
  3. 액세스 토큰 추가를 클릭합니다.
  4. 이름을 지정하고 하나 이상의 범위를 선택한 다음 토큰에 대한 권한을 선택합니다.
  5. 새 토큰을 저장하려면 액세스 토큰 생성을 클릭합니다.

멤버인 경우 계정 관리자가 액세스할 수 있는 API만 제공되지 않을 수 있습니다.

필요한 만큼 액세스 토큰을 생성할 수 있습니다. 새 토큰을 생성할 때 토큰을 저장한 다음 3scale API에 요청할 수 있도록 토큰을 저장하라는 경고가 표시됩니다.

토큰이 손실되면 해당 토큰을 삭제하는 것이 좋습니다. 이를 비활성화한 후 잘못된 토큰을 렌더링한 다음 새 토큰을 생성하는 것이 좋습니다.

6.3. 액세스 토큰 사용

액세스 토큰을 사용하여 3scale API를 호출할 때 액세스할 수 있는 서비스로 결과가 필터링됩니다.

예를 들어 APIcast 자체 관리를 배포할 때 APIcast API 게이트웨이에서 계정 관리 API를 사용하여 서비스 구성을 가져올 수 있도록 액세스 토큰이 필요합니다.

조직의 작동 방식은 3scale에 3개의 서비스를 설정하고 멤버로 서비스 1과 3에 액세스할 수 있으며, 토큰을 생성하고 계정 관리 API에 요청할 때 계정 관리 API에도 액세스할 수 있습니다. 서비스 1을 사용하는 애플리케이션만 받습니다.

동일한 예제에 따라 계정 관리 API에 액세스할 수 있지만 제로 서비스 액세스 시 호출 시 액세스 거부 오류가 발생합니다.

6.3.1. 서비스 토큰

서비스 토큰은 3scale Service Management API에 대해 인증하는 데 사용됩니다. 서비스 토큰은 새 서비스가 3scale로 생성될 때 자동으로 생성되며 서비스마다 고유합니다. 3scale 계정 사용자 간에 공유됩니다.

관리 포털의 대시보드: 계정 설정(gear 아이콘) > 개인 > 토큰에서 사용자가 액세스할 수 있는 서비스의 서비스 토큰 을 찾을 수 있습니다.

II 부. 개발자 계정 관리

7장. 개발자 추가

다음은 API(애플리케이션 프로그래밍 인터페이스)에 액세스하기 위해 새 개발자 계정을 추가하는 단계입니다.

개발자를 수동으로 초대하도록 워크플로를 구성한 경우 새 개발자를 추가하는 방법을 다룹니다.

7.1. 새 개발자 계정 생성

  1. 관리 포털의 Audience 섹션에 있는 계정 링크를 따릅니다.
  2. 생성을 클릭합니다.

관리자는 일부 필수 필드도 건너뛸 수 있습니다. 사용자를 계정에 안전하게 초대하려면 암호 필드를 건너뛸 수도 있습니다. 그러나 이 기본 관리자 계정의 이메일은 모든 사용자 중에서 고유해야 합니다.

새 개발자 계정 생성

7.2. 애플리케이션 설정

참고

user_key,app_key, client_secret 필드에는 최대 길이 및 예약된 문자의 필드 제한 사항이 있습니다.

5~256자 길이의 영숫자 문자 [0-9, a-z, A-Z], 하이픈-minus (-) 만 있습니다. 공백은 허용되지 않습니다.

또한 app_idclient_id 는 최대 140자의 길이를 갖습니다.

계정에 대한 앱 키를 사전 구성하려는 경우 개발자 대신 애플리케이션을 추가할 수도 있습니다. 그렇지 않으면 개발자가 수행해야 하는 초기 단계 중 하나로 두십시오.

새 계정에 애플리케이션 추가

7.3. 개발자에게 알리기

개발자에게 수동으로 이메일 초대를 보내거나 단계에 따라 초대 개발자 기능을 사용할 수 있습니다.

8장. 개발자 승인

이 섹션에서는 등록 워크플로우의 모든 단계에 대해 승인하는 방법을 설명합니다.

수동 승인 단계를 사용하여 등록 워크플로를 구현하면 몇 가지 옵션이 있습니다. 승인 프로세스는 트리거와 승인 대상에 따라 약간 다릅니다. 이메일 알림이 표시되면 다음 섹션의 지침을 따르십시오. 그렇지 않으면 계정, 서비스 또는 애플리케이션을 승인할지 여부에 따라 달라집니다.

8.1. 이메일 알림에서 승인

관리자로서 개발자 중 한 명이 승인 보류 중인 항목이 있다는 이메일 알림을 수신하면 해당 항목의 URL을 브라우저로 복사/붙일 수 있으며 페이지로 직접 이동하여 승인을 할 수 있습니다.

8.2. 계정 승인

특정 계정을 검색하거나 보류 중인 (승인용) 상태에 있는 모든 계정을 필터링하려면 Audience > Accounts > Listing. 보류 중인 계정만 표시하려면 State 드롭다운 목록에서 Pending 를 선택하고 검색을 클릭합니다.

각 행에 대해 직접 개별 승인을 수행하거나 한 번에 여러 행을 선택하고 대규모 승인을 수행할 수 있습니다.

개발자 승인 계정 등록

8.3. 서비스 승인

서비스에 대한 특정 서브스크립션을 검색하거나 보류 중인 (승인용) 상태에 있는 모든 서브스크립션을 필터링하려면 Audience > Accounts > Subscriptions 로 이동합니다.

서브스크립션을 보려면 Audience > Accounts > Usage Rules 에서 서비스 계획을 활성화합니다.

하나의 서브스크립션 또는 여러 서브스크립션을 한 번에 선택하고 대규모 승인을 수행할 수 있습니다.

개발자 승인 서비스 서브스크립션

8.4. 애플리케이션 승인

애플리케이션을 검색하거나 보류 중 (승인용) 상태인 모든 애플리케이션을 필터링하려면 다음을 수행합니다.

  1. Audience > Applications > Listing으로 이동합니다.
  2. State 드롭다운 목록에서 "보류 중"을 선택하고 검색을 클릭합니다.

한 번에 하나의 애플리케이션 또는 여러 애플리케이션을 선택하고 대규모 승인을 수행할 수 있습니다.

개발자 대규모 승인 앱

개발자 계정의 세부 정보 페이지에서 시작하여 승인할 애플리케이션을 선택하고 애플리케이션 세부 정보 페이지에서 승인할 애플리케이션을 만들 수도 있습니다.

개발자 개별 앱 승인 1
개발자 개별 앱 승인 2

9장. 앱에 대한 계획 변경

이 섹션에서는 계정, 서비스 또는 애플리케이션에 대한 계획을 변경할 수 있습니다.

관리자는 언제든지 개발자 계획을 변경하거나 개발자가 시작하는 계획 변경 요청에 대한 응답으로 변경할 수 있습니다.

참고

변경 계획 단계는 변경 중인 계획 유형에 따라 약간 다릅니다.

9.1. 계정 계획 변경

특정 계정을 검색하거나 필터링하려면 Audience > Accounts > Listing 으로 이동합니다.

한 번에 하나 이상의 행을 선택하고 계획을 변경할 수 있습니다.

개발자 계정 계획 변경

9.2. 서비스 계획 변경

서비스에 대한 특정 서브스크립션을 검색하거나 필터링하려면 Audience > Accounts > Subscriptions 로 이동합니다.

설정 페이지에서 서비스 계획을 활성화한 경우에만 서브스크립션을 볼 수 있습니다.

한 번에 하나 또는 여러 서브스크립션을 선택하고 계획을 변경할 수 있습니다.

서비스 계획 변경

9.3. 애플리케이션 계획 변경

특정 애플리케이션을 검색하거나 필터링하려면 Audience > Applications > Listing 로 이동합니다.

한 번에 하나 또는 여러 애플리케이션을 선택하고 계획을 변경할 수 있습니다.

여러 애플리케이션에 대한 계획 변경

또 다른 시나리오는 개발자 계정의 세부 정보 페이지에서 시작하는 것입니다. 여기에서 계획을 변경할 애플리케이션을 선택합니다. 애플리케이션 세부 정보 페이지에서 계획을 변경할 수 있습니다.

애플리케이션 계획 변경

9.3.1. 더 많은 정보

다른 표준 계획을 변경하는 대신 하나의 특정 앱에 대해서만 변경하려는 경우 사용자 지정 계획 기능을 사용할 수 있습니다.

9.4. 개발자 포털에서 애플리케이션 계획 변경 시작

참고

제품의 애플리케이션 계획 설정은 해당 제품의 모든 애플리케이션 계획에 적용됩니다.

관리 포털에서 애플리케이션 계획 변경 아래의 [ your_product_name] > Applications > Settings > Usages Rules 로 이동하면 사용자가 변경 사항을 시작하는 방법이 결정됩니다. 다음에서는 선택한 옵션에 따라 수행되는 작업을 설명합니다.

  • 요청 계획 변경

    변경 요청 시 관리자에게 알림을 받습니다.

  • 직접 계획 변경

    개발자가 승인 없이 계획을 변경할 수 있습니다. 관리자는 변경 사항에 대해서만 알림을 받습니다.

  • 계획 변경을 허용하지 않음

    개발자 포털에서 계획을 변경할 수 있는 옵션은 없습니다. 관리자만 수동으로 변경할 수 있습니다.

  • 개발자가 신용카드 세부 정보를 입력한 경우:

    • 계획 변경 요청만

      변경 요청 시 관리자에게 알림을 받습니다.

    • 유료 계획에 대한 credit 카드 항목 요청

      무료 계획을 전환할 수 있지만 유료 계획으로 전환하려면 신용 카드 세부 정보를 입력해야합니다.

개발자가 개발자 포털에서 애플리케이션 계획을 변경하려는 경우(예: 무제한 계획으로 변경) 변경 사항이 이메일로 완료됩니다. 개발자는 계획 변경 요청을 완료하려면 개발자 포털에 로그인해야 합니다.

프로세스

  1. 개발자 포털에 로그인합니다.
  2. 애플리케이션 탭으로 이동합니다.
  3. 서브스크립션된 애플리케이션 목록을 찾습니다.
  4. 원하는 계획에 서브스크립션된 애플리케이션을 식별합니다.
  5. 애플리케이션 이름을 클릭하여 편집 창을 엽니다.
  6. 편집 창에서 현재 계획을 찾아 검토/변경 버튼을 클릭합니다.
  7. 서비스에 사용 가능한 애플리케이션 계획을 검토합니다.
  8. 원하는 계획(예: 무제한 )을 선택합니다.
  9. 요청 계획 변경 을 클릭합니다.

    • 통지가 표시됩니다. 적용 가능한 PLAN HAS BEEN SENT.
    • 그러면 관리 포털을 통해 새 계획을 승인할 이메일 알림이 관리자에게 전송됩니다.

9.5. 관리 포털에서 애플리케이션 계획 변경 구현

관리자가 애플리케이션 계획 변경을 요청하는 이메일을 수신하면 다음 단계를 사용하여 프로세스를 완료합니다. 새 계획을 선택하고 확인하는 방법을 간략하게 설명합니다. 또한 개발자는 변경 사항 알림을 수신하여 개발자 포털에서 업데이트를 확인할 수 있습니다.

프로세스

  1. 애플리케이션 세부 정보가 포함된 이메일 요청을 엽니다. 예를 들면 다음과 같습니다.

    Details:
        Application: Testers's App
        Service: API
        Current plan: Basic
        Requested plan: _Unlimited_
    "Change Plan" (URL to the application in the Admin Portal)
    Copy to Clipboard Toggle word wrap
  2. 이메일에 제공된 변경 계획 URL을 찾습니다.
  3. 변경 계획 URL을 클릭하여 관리 포털의 애플리케이션 세부 정보 페이지에 액세스합니다.
  4. 계획 변경 섹션으로 이동합니다.
  5. 드롭다운 메뉴를 클릭하여 사용 가능한 애플리케이션 계획을 표시합니다.
  6. 이메일에 언급된 요청된 계획을 선택합니다(예: Unlimited ).
  7. 원하는 계획을 선택하면 계획 변경 옵션이 활성화됩니다.
  8. 계획 변경을 클릭하여 계획 변경을 확인합니다.
  9. 애플리케이션 계획이 Unlimited 계획으로 성공적으로 변경되었는지 확인합니다.

3scale API Management는 구매자 템플릿에 대해 변경된 애플리케이션 계획을 사용하여 사용자에게 계획 변경 사항을 알리는 이메일 알림을 자동으로 보냅니다. 개발자는 개발자 포털에서 계획 변경 사항을 확인할 수 있습니다.

10장. 개발자에게 문의

이 가이드에서는 특정 애플리케이션을 관리하는 개발자 계정을 확인한 다음 3scale 및 외부 모두에서 사용자와 통신하는 방법을 설명합니다.

API 작업 중에 API를 사용하는 개발자에게 긴급하게 문의해야 할 수 있습니다.

10.1. 시스템에서 관련 애플리케이션 및 계정을 찾습니다.

해당 애플리케이션을 관리하는 계정과 개발자가 이미 알고 있는 경우, Audience > Accounts > Listing 의 Accounts 페이지에서 해당 계정으로 이동합니다.

계정 보기

애플리케이션 ID 또는 API 키만 있는 경우 Audience > Accounts > Listing 의 Accounts 페이지에서 검색 상자를 사용하여 관련 계정을 찾을 수 있습니다. 애플리케이션 찾기에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

10.2. 개발자에게 내부 메시지 전송

아래에 표시된 대로 계정 프로필 페이지에 표시되면 메시지 아이콘을 클릭합니다.

메시지 전송

여기에서 생성된 메시지는 계정 시스템 대시보드, 계정의 모든 개발자가 볼 수 있는 계정 시스템 대시보드로 전송되며 계정 내에 admin 상태가 있는 개발자 계정의 사용자에게 이메일로 전송됩니다.

10.3. 다른 방법으로 연락

긴급 상황이며 이메일이 귀하의 목적을 위해 충분히 빠르지 않을 경우, 등록 시 개발자가 제출한 연락처 정보를 사용할 수도 있습니다.

  • 회사 계정 페이지(일반 연락처 정보)에 전화 번호를 포함할 수 있습니다.
  • 사용자 자체 파일에 대한 개발자/사용자별 정보입니다.

등록 시 연락처 전화 번호를 필수 필드로 만들 수 있습니다.

11장. 계획 사용자 정의

이 섹션을 완료하면 특정 개발자의 애플리케이션 계획을 사용자 지정할 수 있습니다.

애플리케이션 계획은 개발자 커뮤니티의 다양한 세그먼트에 표준 정책을 적용하는 좋은 방법입니다. 그러나 고유한 요구 사항이 있는 개별 개발자의 표준 계획을 사용자 지정할 수 있는 유연성이 항상 있습니다.

계획을 사용자 정의하면 원래 계획에 대한 링크가 손실됩니다. 원래 계획을 변경하면 사용자 지정 계획에서 해당 변경 사항을 상속하지 않습니다. 따라서 효과적으로 관리할 수 없는 사용자 지정 계획에 지나치게 압도되기 전에 이 사용자 지정 기능을 사용해야 합니다.

개발자는 현재 청구 기간이 이미 진행 중이므로 다음 가격 결정 계층으로 업그레이드하지 않고 현재 제한을 늘리려고 합니다. 사용자 지정은 제한이 증가하고 발생한 변수 비용만 청구할 수 있으므로 이 상황을 처리하는 좋은 방법이 될 수 있습니다. 또한 다음 청구 월에 대한 업그레이드를 권장합니다.

11.1. 계정 선택

관심 있는 개발자 계정의 세부 정보 페이지를 보려면 다음을 수행합니다.

  1. Audience > Accounts > Listing으로 이동합니다.
  2. 개발자 계정 선택
계정 선택

11.2. 애플리케이션 선택

사용자 지정할 계획이 있는 애플리케이션을 선택합니다.

앱 선택

11.3. 애플리케이션 계획 사용자 정의

옵션을 선택하여 "사용자 지정"을 선택합니다. 그러면 이 계정이 소유한 애플리케이션에 대해 모든 계획 요소를 사용자 지정할 수 있는 페이지가 제공됩니다.

계획 사용자 정의

11.3.1. 더 많은 정보

계획을 사용자 지정하기 전에(개발자 포털에 표시되지 않음) 새 표준 계획을 사용하는 것이 더 좋지 않은 경우 항상 먼저 고려하십시오. 그런 다음 표준 계획을 변경하여 두 개 이상의 개발자 파트너에게 적용되는 경우 재사용의 이점을 얻을 수 있습니다.

12장. 등록 활성화

셀프 서비스 또는 수동 모드를 구현하여 개발자 등록을 구성합니다.

개발자가 셀프 서비스 또는 수동 초대 전용 워크플로를 구성할 수 있습니다. 셀프 서비스 등록은 개발자 포털을 통해 개발자가 수행하지만 수동 초대는 관리 포털을 통해 관리자가 처리합니다.

기본적으로 개발자는 자체적으로 등록할 수 있습니다. 개발자 셀프 서비스를 활성화하면 개발자 계정을 활성화하기 전에 관리자 승인이 필요할 수 있습니다.

이렇게 하려면 Audience > Accounts > Settings > Usage Rules 로 이동합니다.

셀프 서비스 개발자 등록 활성화

13장. 애플리케이션 검색

이 가이드가 끝나면 이름, API 키 또는 애플리케이션 ID를 기반으로 관리 포털에서 애플리케이션을 빠르게 찾을 수 있습니다.

API 작업 중에 API에 빠르게 액세스하는 애플리케이션에 대한 정보를 찾아야 합니다. 지원 목적으로, 구성을 변경하거나, 애플리케이션이 오작동하고 비활성화되어야 하기 때문에 잠재적으로 가능합니다.

13.1. 필요한 정보를 가져옵니다.

애플리케이션을 찾으려면 해당 계정 이름이거나 애플리케이션 이름이 필요합니다. 이 정보가 없는 경우 액세스 로그를 확인할 수 있습니다. 검색을 수행하려면 Applications: Audience > Applications > Listing 로 이동합니다.

인증 유형을 ID별로 검색하는 경우 다음 정보가 필요합니다.

  • API 키 전용 인증 패턴의 경우: API 키
  • 앱 ID 및 앱 키 인증 패턴의 경우: 앱 식별자(App 키로 검색은 지원되지 않음)
  • OpenID Connect 인증 패턴의 경우 client_id (Secret에서 검색은 지원되지 않음)

13.2. 애플리케이션 검색

지정된 애플리케이션을 검색하려면 Audience > Applications > Listing을 통해 Applications 페이지로 이동하여 아래 이미지에 표시된 것처럼 검색 상자를 사용합니다.

애플리케이션 파트 1 검색

13.3. 애플리케이션 정보 액세스

결과가 반환되면 액세스하려는 애플리케이션을 클릭하면 해당 애플리케이션의 홈페이지로 이동합니다. 이 페이지에는 아래 이미지에 표시된 것과 같은 정보가 포함됩니다.

애플리케이션 파트 2 찾기

14장. 개발자 초대

이러한 단계를 완료하면 개발자 계정에 새 개발자 사용자를 추가합니다.

개발자 계정을 수동으로 생성할 때 관리 포털을 통해 개발자 사용자를 해당 계정에 초대할 수 있습니다.

  1. Audience > Accounts > Listing으로 이동합니다.
  2. 해당 계정을 선택합니다.
  3. "Invitations"를 선택한 다음 초대 사용자를 클릭합니다.
개발자 초대

15장. 서비스에서 개발자 구독 취소

관리자는 서비스에서 개발자를 구독 취소할 수 있습니다. 서비스 사용 중단 시 특정 개발자 또는 여러 개발자를 위해 이 작업을 수행해야 할 수 있습니다.

15.1. 서비스에서 단일 개발자 구독 취소

관리 포털을 통해 구독한 서비스에서 단일 개발자를 구독 해제합니다.

  1. 관리 포털의 대시보드에서 Audience > Accounts > Listing > [select an account] > 서비스 서브스크립션 으로 이동합니다.
  2. 개발자를 제거할 서비스의 서브스크립션 취소를 선택합니다.

15.2. 서비스에서 여러 개발자 구독 취소

대규모 작업을 수행하여 더 이상 사용되지 않거나 삭제된 서비스에서 여러 개발자를 구독 해제합니다.

참고

이 방법은 삭제되거나 일시 중단된 서비스에만 적용됩니다. 활성 서비스에서 대량 서브스크립션 취소 작업을 수행할 수 없습니다.

  1. 대시보드에서 Audience > Accounts > Subscriptions 로 이동합니다.
  2. 대량 상태 변경을 수행합니다.
  3. 서비스 드롭다운 메뉴를 사용하여 개발자의 서브스크립션을 취소할 서비스를 식별합니다.
  4. 왼쪽의 확인란을 사용하여 구독 취소할 개발자를 선택합니다.
  5. Change State > Suspend 를 선택하여 선택한 개발자 서브스크립션을 일시 중지합니다.

서비스 계획을 활성화해야 합니다.

16장. 애플리케이션 일시 중단

이 가이드에서는 애플리케이션의 모든 키와 액세스 토큰을 비활성화하는 방법을 설명합니다.

애플리케이션이 API를 잘못 사용하고 다른 트래픽에 영향을 미치는 경우 개발자에게 코드 또는 구성을 수정하도록 요청하기 전에 해당 작업을 신속하게 중단해야 할 수 있습니다.

16.1. 애플리케이션 검색

계정 또는 애플리케이션 탭에서 또는 여기에 설명된 대로 검색하여 애플리케이션을 찾을 수 있습니다.

16.2. 애플리케이션 비활성화

애플리케이션을 찾고 애플리케이션 요약 페이지를 확인한 후 State 값 옆에 있는 일시 중단 아이콘을 클릭합니다. 이 작업은 API에서 애플리케이션을 즉시 비활성화하고 모든 키가 작동하지 않습니다. 이러한 애플리케이션 키를 사용한 호출은 제어 시스템에서 거부됩니다.

문제가 있는 동작이 수정되면 동일한 버튼을 사용하여 애플리케이션을 일시 중지 해제할 수 있습니다.

애플리케이션 일시 중단
참고

에이전트에서 캐싱을 사용하는 경우 일시 중지가 즉시 적용되지 않을 수 있지만 짧은 시간 초과가 필요할 수 있습니다.

16.3. 개발자에 문의하십시오.

애플리케이션 개발자에게 문의하는 방법은 워크플로우 및 정책에 따라 달라집니다. 동일한 페이지에서 애플리케이션을 소유한 계정의 키 관리자를 식별할 수 있는 계정 보기로 계정 이름을 클릭할 수 있습니다. 다음과 같이 이메일 또는 메시지 전송 버튼을 클릭하면 사용자에 대한 대시보드 메시지를 생성할 수 있습니다.

개발자에 문의

17장. 애플리케이션 삭제

관리 포털을 통해 애플리케이션을 삭제하려면 다음 단계를 수행해야 합니다.

옵션 1: [ your_API_name]에 대한 모든 애플리케이션 목록에서 애플리케이션을 삭제합니다.

  1. 대시보드에서 [ your_API_name] 을 클릭합니다.
  2. 개요 탭을 클릭합니다.
  3. 개요 페이지의 왼쪽 패널에서 Applications 를 클릭합니다.
  4. Listing 을 선택합니다.
  5. 애플리케이션을 클릭합니다.
  6. 애플리케이션 세부 정보가 포함된 페이지가 표시됩니다. 편집을 클릭합니다.
  7. 애플리케이션을 삭제하려면 삭제 를 클릭합니다.
  8. 확인 메시지가 표시됩니다. 확인을 클릭하여 삭제를 확인합니다.

옵션 2: 특정 애플리케이션 계획을 기반으로 애플리케이션을 삭제합니다.

  1. 관리 포털에서 대시보드 를 클릭합니다.
  2. API 를 선택합니다.
  3. 게시 애플리케이션 계획에서 애플리케이션을 선택합니다.
  4. 애플리케이션을 클릭합니다.
  5. 애플리케이션 세부 정보가 포함된 페이지가 표시됩니다. 편집을 클릭합니다.
  6. 애플리케이션을 삭제하려면 삭제 를 클릭합니다.
  7. 확인 메시지가 표시됩니다. 확인을 클릭하여 삭제를 확인합니다.

또는 애플리케이션 삭제라는 작업을 사용하여 3scale API Docs를 통해 애플리케이션을 삭제할 수도 있습니다.

18장. API 삭제

서비스를 삭제하여 API를 삭제할 수 있습니다. 서비스를 삭제하면 API의 애플리케이션, 애플리케이션 계획, 메트릭, 가격 결정 규칙, 기능, 서비스 계획 및 서브스크립션이 제거됩니다.

API를 삭제하려면 다음을 수행합니다.

  1. [ your_product_name] > Overview > Edit 로 이동합니다.
  2. 서비스 삭제 섹션에서 링크를 클릭하여 서비스를 삭제합니다.

III 부. 액세스 제어

3scale API(애플리케이션 프로그래밍 인터페이스) 공급자로서 개별 사용 세부 정보를 캡처하고, 메트릭을 정의하고, 매핑 규칙과 방법 및 메트릭을 연결하며 가격 및 사용량 제한을 설정하는 애플리케이션 계획을 생성하는 방법을 지정하여 API에 대한 액세스를 제어합니다. 애플리케이션 계획에서는 사용 제한을 적용하기 위해 메서드 및 메트릭에 대해 수집된 데이터를 사용합니다.

19장. 사용 세부 정보 캡처를 위한 방법 지정 및 메트릭 추가

애플리케이션 계획에서는 API에 대한 소비자 액세스에 대한 제한 및 가격 규칙을 설정합니다. 제한 및 규칙을 적용할 수 있도록 하려면 개별 사용 데이터를 수집하거나 메트릭을 추가할 API의 메서드를 지정합니다. 지정된 각 메서드 및 각 사용자 지정 메트릭에 매핑 규칙을 추가합니다. 매핑 규칙은 캡처하려는 사용 데이터에 대한 세부 정보를 지정합니다.

메서드를 지정하거나 제품 및 백엔드에 대한 메트릭을 추가할 수 있습니다. 제품의 경우 제품의 애플리케이션 계획에서 제한 및 가격 규칙을 설정할 수 있습니다. 백엔드의 경우 이를 통해 해당 백엔드를 번들하는 모든 제품에 대한 애플리케이션 계획에서 제한 및 가격 규칙을 설정할 수 있습니다.

개별 호출 수를 캡처하는 메서드를 지정합니다. 이를 통해 API 사용 추적에 대한 세분화가 제공됩니다. 메서드에 대한 트래픽을 보고하면 메서드 및 Hits 메트릭에 대한 카운터가 자동으로 증가합니다. API 백엔드의 각 끝점 또는 끝점과 HTTP 메서드의 조합에 대해 메서드를 지정할 수 있습니다. API의 엔드포인트 를 여기에 추가된 메서드에 매핑하는 방법은 메서드 및 메트릭에 매핑 규칙 추가 를 참조하십시오.

메트릭은 제품과 백엔드 모두에 대한 API 사용을 추적하는 데 적합합니다. hits 는 각 API에 존재하는 기본 제공 메트릭입니다. API에 대한 호출 수를 추적합니다. Hits 외에도 API의 사용량을 캡처하려면 다른 단위로 사용량을 보고하는 지표를 정의합니다. 단위는 정량화되어야 하며 메가바이트, CPU 시간 또는 API에서 반환하는 요소 수와 같은 비즈니스 목표에 의미를 적용해야 합니다. CPU 시간 또는 mb 와 같은 Hits 이외의 메트릭은 기본적으로 제공되지 않습니다. 사용자가 구성한 외부 서비스에서 호출하는 엔드포인트를 사용하여 이러한 지표를 가져옵니다.

메서드 및 메트릭은 API 패키징을 위한 스캐폴드입니다. 각 애플리케이션 계획을 사용하면 지정된 각 방법과 각 메트릭에 대해 다양한 사용 제한 및 가격 규칙을 정의할 수 있습니다. 메트릭 및 메서드에서 보고한 사용량에 대한 자세한 내용은 API 분석을 참조하십시오.

19.1. 제품 및 백엔드에 방법 추가

제품 또는 백엔드에 방법을 추가하면 개별 사용 세부 정보를 캡처하려는 API에서 메서드를 지정하고 있습니다. 애플리케이션 계획에서는 제품 또는 백엔드에 추가하는 각 메서드에 대한 제한을 설정하는 기능을 제공합니다. 제품에 방법 또는 지표를 추가하는 절차는 백엔드에 메서드 또는 메트릭을 추가하는 것과 유사합니다.

프로세스

  1. [ your_product_name] > Integration > Methods & Metrics 또는 [ your_backend_name] > Methods & Metrics 로 이동합니다.
  2. 메서드 추가를 클릭합니다.
  3. Friendly name 필드에 메서드에 대한 간단한 설명을 입력합니다. 이 이름은 3scale 관리 포털의 다른 섹션에 표시됩니다. 친숙한 이름은 제품에 대해 고유해야 합니다.

    중요

    메서드의 시스템 이름을 변경하거나 삭제하는 데 주의하십시오. 이러한 변경으로 인해 메서드의 이전 시스템 이름을 가리키는 매핑 규칙이 있는 경우 이미 배포된 3scale 통합이 중단될 수 있습니다.

  4. 시스템 이름 필드에 3scale Service Management API를 통해 사용량을 보고하는 데 사용할 API의 메서드 이름을 입력합니다.

    시스템 이름의 형식을 결정합니다. 이 이름은 끝점(/status)과 유사하거나, 예를 들어 메서드 및 경로(GET_/status)를 포함할 수 있습니다. 그러나 시스템 이름은 다음 규칙을 준수해야 합니다.

    • 제품 또는 백엔드에서 고유합니다.
    • 영숫자, 밑줄 _, 하이픈 - 또는 슬래시 / 만 포함합니다.
    • 공백이 없습니다.
    • 백엔드 API의 경우 시스템 이름 메서드에는 매핑된 백엔드를 식별하는 숫자 문자열이 포함됩니다. 이 백엔드 ID는 수정할 수 없습니다.
  5. 선택 사항: 설명 필드에 메서드에 대한 자세한 설명을 입력합니다.
  6. Create Method 를 클릭합니다.

검증 단계

  • 추가 방법은 애플리케이션 계획에서 사용할 수 있습니다.

19.2. 제품 및 백엔드에 메트릭 추가

메트릭을 추가하면 API에 대한 모든 호출에 대해 캡처할 사용 단위가 지정됩니다. 애플리케이션 계획에서는 제품 또는 백엔드에 추가하는 각 메트릭에 대한 제한을 설정하는 기능을 제공합니다. 제품에 방법 또는 지표를 추가하는 절차는 백엔드에 메서드 또는 메트릭을 추가하는 것과 유사합니다.

프로세스

  1. [ your_product_name] > Integration > Methods & Metrics 또는 [ your_backend_name] > Methods & Metrics 로 이동합니다.
  2. 지표 탭을 클릭합니다.
  3. 지표 추가를 클릭합니다.
  4. Friendly name 필드에 지표에 대한 간단한 설명을 입력합니다. 이 이름은 3scale 관리 포털의 다른 섹션에 표시됩니다. 친숙한 이름은 제품에 대해 고유해야 합니다.

    중요

    메트릭의 시스템 이름을 변경하거나 삭제합니다. 이러한 변경으로 인해 메트릭의 이전 시스템 이름을 가리키는 매핑 규칙이 있는 경우 이미 배포된 3scale 통합이 중단될 수 있습니다.

  5. 시스템 이름 필드에 3scale Service Management API를 통해 사용량을 보고하는 데 사용할 API의 메트릭 이름을 입력합니다.

    시스템 이름의 형식을 결정합니다. 그러나 시스템 이름은 다음 규칙을 준수해야 합니다.

    • 제품 또는 백엔드에서 고유합니다.
    • 영숫자, 밑줄 _, 하이픈 - 또는 슬래시 / 만 포함합니다.
    • 공백이 없습니다.
    • 백엔드 API의 경우 지표 시스템 이름에 매핑된 백엔드를 식별하는 숫자 문자열이 포함됩니다. 이 백엔드 ID는 수정할 수 없습니다.
  6. 단위 필드에 단위 를 입력합니다.

    • 예를 들어 단일 noun을 사용합니다. 단서는 분석 차트에서 복수형이 될 것입니다.
  7. 선택 사항: 설명 필드에 메트릭에 대한 자세한 설명을 입력합니다.
  8. 메트릭 생성을 클릭합니다.

검증 단계

  • 추가된 메트릭은 애플리케이션 계획에서 사용할 수 있습니다.

19.3. 방법 및 메트릭을 가져오는 대안

API에 끝점이 여러 개 있는 경우 자동으로 방법을 지정하고 3scale 제품 및 백엔드에 메트릭을 추가하는 두 가지 방법이 있습니다.

19.4. 방법 및 메트릭에 매핑 규칙 추가

매핑 규칙은 제품 및 백엔드의 이전에 생성된 방법메트릭에 매핑되는 작업입니다.

참고

매핑 규칙은 이전에 생성된 메서드에 필요하지만 메트릭에는 선택 사항입니다.

프로세스

  1. [ your_product_name] > Integration > Mapping Rules 로 이동합니다.
  2. 매핑 규칙 생성 을 클릭합니다.
  3. Verb 필드는 HTTP 메서드 GET 으로 미리 채워져 있지만 드롭다운 목록에서 다른 옵션을 선택할 수 있습니다.
  4. 패턴 필드에 슬래시 / 로 시작하는 유효한 URL을 추가합니다. URL은 중괄호 {} 내에 지정한 와일드카드에서 있을 수 있습니다.
  5. Metric 또는 method to increment 필드에서 이전에 생성된 메서드 또는 메트릭 중 하나에서 선택합니다.
  6. 증분 식 필드는 1 로 미리 채워져 있지만 사용자의 필요에 맞게 변경합니다.
  7. 매핑 규칙 생성 버튼을 클릭합니다.

검증 단계

  • 매핑 규칙을 확인하려면 [ your_product_name] > Integration > Methods & Metrics 로 이동합니다. 각 방법과 메트릭은 Mapped 열에 확인 표시가 있어야 합니다.

20장. 애플리케이션 계획

애플리케이션 계획에서는 API 사용자가 허용할 수 있는 다양한 액세스 권한 세트를 정의합니다. 이는 속도 제한, 액세스할 수 있는 방법 또는 리소스와 활성화되는 기능을 결정할 수 있습니다.

20.1. 애플리케이션 계획 생성 방법

기본적으로 3scale 계정이 생성되면 Basic 및 Unlimited라는 두 가지 계획이 제공됩니다. 이를 유지 및 편집하거나 직접 만들 수 있습니다. 필요한 만큼 많은 계획을 만들 수 있습니다.

새 애플리케이션 계획을 생성하려면 다음 단계를 따르십시오.

  1. [ your_product_name] > Applications > Application Plans 로 이동합니다.
  2. 애플리케이션 계획 생성 버튼을 클릭합니다.
  3. 애플리케이션 계획 생성 페이지에서 새 계획에 대한 이름과 시스템 이름(시스템 이름은 고유해야 함)을 입력합니다.
  4. API에 액세스하기 전에 애플리케이션이 승인을 받아야 하는 경우 승인이 필요한 애플리케이션을 선택합니다.

계획을 만든 후에는 속도 제한을 프로비저닝하고 유료 계획을 설정할 수 있습니다.

20.2. 기본 애플리케이션 계획 설정

모든 계획을 생성한 후에는 사용자가 애플리케이션을 등록하기 위해 등록할 때 기본 계획을 선택할 수 있습니다.

기본 애플리케이션 계획을 선택하려면 다음을 수행합니다.

  1. [ your_product_name] > Applications > Application Plans 로 이동합니다.
  2. 기본 계획 의 드롭다운 목록에서 계획을 선택합니다.

기본 애플리케이션 계획을 표시하지 않으면 새 사용자가 API에 액세스하기 위해 등록하면 기본적으로 애플리케이션이 생성되지 않습니다. 즉, 사용자가 API에 액세스할 수 없습니다.

21장. 유료 계획 프로비저닝

제품 또는 백엔드 중 하나의 API를 수익화하는 가장 일반적인 방법 중 하나는 사용량에 따라 서브스크립션 비용을 정의하는 것입니다. 이 섹션에서는 애플리케이션 계획을 사용하여 가격 계층을 프로비저닝하는 방법과 유료 계획을 설정하는 방법에 중점을 둡니다. 또한 계정의 가격 규칙과 제품 및 백엔드 수준에서도 적용할 수 있습니다. 이러한 주제는 고급 가이드에서 다룹니다.

21.1. 가격 결정 모델

첫 번째 결정은 가격 모델의 계층을 구별하는 방법입니다. 계층은 볼륨 또는 사용량, API 기능, 다른 리소스에 대한 액세스 또는 조합을 통해 구동할 수 있습니다.

  • 볼륨 / 사용량

    계층 간에 구별하는 가장 일반적인 방법은 볼륨 기반입니다. 일반적으로 볼륨에는 고객 가치와 강력한 상관 관계가 있고 서비스 비용이 있기 때문입니다. 제품에 대한 호출에 글로벌 적중 횟수를 적용하거나 메서드 수준에서 보다 세분화된 측정을 적용할 수 있습니다. 볼륨 드라이버는 글로벌 적중 지표의 수준 또는 적중에서 개별 메서드에 적용됩니다. 모든 메트릭에 여러 가격 규칙을 적용할 수 있습니다. 적중 계산은 한 달 동안 누적됩니다.

  • 기능

    계층에 따라 제품의 일부에 대한 액세스를 활성화하거나 비활성화할 수 있습니다. 이는 표준과 프리미엄 수준을 구분하는 좋은 방법입니다.

  • Resources

    또한 고객에게 가치를 제공하거나 인프라의 비용을 유도하는 기타 리소스에 대한 액세스를 기반으로 계층을 생성할 수도 있습니다(예: 사용량이 기가바이트, 사용자 수 또는 트랜잭션 값). 리소스 드라이버는 볼륨 드라이버와 유사하지만 사용자 지정 메트릭에 적용됩니다.

가격 드라이버를 결정한 후에는 계층이 플랫 비율 서브스크립션, 변수 속도 또는 원오프 전차 요금을 기반으로 하는지 여부를 결정해야 합니다. 위의 세 가지 가격 드라이버는 모두 일회성 또는 월간 플랫 비율 서브스크립션과 호환됩니다. 가격 책정이 적중량 또는 리소스 소비량에 따라 결정되면 물론 가격에 대한 변수 요소가 있습니다.

21.2. 가격 규칙을 사용하여 애플리케이션 계획 구성

새 애플리케이션 계획을 생성하거나 기존 애플리케이션 계획을 편집할 수 있습니다. 새 애플리케이션 계획을 생성할 때 초기 비용 또는 평면 비율 서브스크립션을 입력할 수 있습니다.

새 애플리케이션 계획 생성 또는 기존 편집

편집 애플리케이션 뷰에서 초기 요금 및 서브스크립션을 입력하거나 수정할 수 있습니다.

다음으로 21.1절. “가격 결정 모델” 에서 선택한 가격 드라이버를 설정합니다.

  1. [ your_product_name] > Overview > Applications > Application Plans 로 이동합니다.
  2. 애플리케이션 계획 이름을 클릭합니다.
  3. Metrics, Methods, Limits & pricing Rules로 이동합니다. 여기에서 가격은 총 적중의 수준, 방법의 세분성 또는 사용자 지정 메트릭으로 정의할 수 있습니다.

일부 이미 메트릭으로 존재하는 경우 해당 항목을 편집할 수 있습니다.

가격 책정 규칙 설정이 완료되면 애플리케이션 계획 업데이트를 클릭합니다.

21.3. 추가 가격 계층 생성

단일 애플리케이션 계획을 사용하여 API 유료 계획을 정의할 수 있습니다. 일반적으로 모든 가격 규칙이 볼륨 또는 리소스 드라이버에 의해 정의되는 경우입니다. 그러나 개발자 커뮤니티의 다양한 세그먼트에 대해 별도의 계획을 제공하려면 더 많은 애플리케이션 계획을 추가합니다.

이 작업을 수행하는 가장 쉬운 방법은 애플리케이션 계획 개요 페이지에서 첫 번째 애플리케이션 계획을 복사하는 것입니다. 이렇게 하면 기존의 모든 메트릭 및 가격 규칙으로 미리 채워집니다. 처음으로 전체 계획을 만들수록 계획 복사 기능으로 더 많은 시간을 절약할 수 있습니다.

21.4. 유료 계획 프로비저닝

계획을 프로비저닝하려면 개발자가 새 애플리케이션을 생성하고 새로운 유료 계획 중 하나를 선택해야 합니다. 관리 콘솔을 대신하여 이 작업을 수행할 수도 있습니다. 기존 애플리케이션에서는 기존 계획에서 새로운 유료 계획 중 하나로 변경할 수도 있습니다.

21.5. 참고 자료

플랫 등급 가격 계획과 함께 속도 제한을 사용하여 계층을 구분하는 것이 일반적입니다. 이는 프로비저닝 속도 제한에 설명되어 있습니다.

22장. 프로비저닝 속도 제한

중요

각 APIcast 인스턴스에는 자체 로컬 권한 부여 캐시가 있습니다. 첫 번째 호출은 서비스, 메트릭 및 인증 정보의 특정 조합에 대해 API 백엔드에 호출을 전달하기 전에 항상 3scale에 대해 권한이 부여됩니다.

응답이 성공하면 이 조합에 대한 로컬 캐시에 "OK"를 저장합니다. APIcast는 API 백엔드에서 응답을 가져온 후 캐시를 업데이트한 다음 이를 사용하여 후속 호출을 승인합니다.

잘못된 인증 정보로 인해 3scale에 대한 요청이 실패하면 "OK" 상태가 로컬 캐시에서 제거됩니다. APIcast 인스턴스 한 개를 사용하면 한 번의 호출로 제한을 초과할 수 있으며 N 인스턴스를 사용하면 N을 초과할 수 있습니다.

분당 속도 제한은 세계 시계의 두 번째 0에서 시작됩니다.

속도 제한을 사용하면 API 리소스, 제품 및 백엔드에 대한 액세스를 제한할 수 있습니다. 애플리케이션 계획을 사용하여 별도의 개발자 세그먼트에 대해 다양한 제한을 구성할 수 있습니다.

속도 제한이 적용되면 이러한 제한은 3scale 백엔드에 권한 부여 요청을 호출할 때 개발자가 수신하는 응답을 제어합니다.

22.1. 애플리케이션 계획 구성

아직 애플리케이션 계획을 정의하지 않은 경우 먼저 애플리케이션 계획을 생성합니다. 그렇지 않으면 속도 제한을 설정할 계획을 선택하고 편집을 클릭합니다.

애플리케이션 계획 생성에 대한 자세한 내용은 애플리케이션 계획을 참조하십시오.

22.2. 속도 제한 설정

속도 제한을 설정하려면 다음을 수행합니다.

  1. [ your_product_name] > Overview > Applications > Application plan 로 이동합니다.
  2. 구성할 애플리케이션 계획의 이름을 클릭합니다.
  3. 아래로 스크롤하여 Metrics, Methods, Limits 및 pricing Rules로 이동합니다.
  4. 제한을 클릭합니다.
  5. 제품 또는 백엔드 수준에 대한 제한을 구성합니다.
  6. 필요한 제한 설정을 완료하면 애플리케이션 계획 업데이트를 클릭하여 변경 사항을 저장합니다.

22.3. 새로운 비율 제한 사항 설정

이제 속도 제한이 정의되었으므로 다음이 수행됩니다.

  • 경고가 구성된 경우 새 제한은 알림이 전송되는 시기를 결정하는 데 사용됩니다.
  • 3scale 백엔드에 대한 호출 수를 초과하면 제한이 고려되고 관련 오류 메시지가 표시됩니다. APIcast 오류 메시지에 대한 자세한 내용은 오류 메시지 구성을 참조하십시오.

속도 제한이 작동하면 대시보드에서 제한에 도달하는 사용자를 확인하여 잠재적 계획 업그레이드 후보를 빠르고 쉽게 확인할 수 있습니다. 소프트 제한 및 하드 제한에 대한 자세한 내용은 고급 경로의 애플리케이션 계획을 사용하여 API 액세스 정책 구성시작 가이드를 참조하십시오.

22.4. 더 많은 정보

유량 제한을 설정하는 것 외에도 동일한 메트릭에 대한 변수 가격 규칙을 설정할 수도 있습니다. 유료 계획 프로비저닝 을 참조하십시오.

IV 부. 청구

23장. billing 설정 구성

이 문서에서는 Red Hat 3scale API Management에서 billing 기능이 작동하는 방법에 대해 설명합니다.

청구 설정은 Charging & Gatewaycredit 카드 정책으로 나뉩니다. 둘 다 Audience > billing ing에서 확인할 수 있습니다.

23.1. 청구 모드(인증 및 게이트웨이)

3scale 청구는 월을 기반으로 하며 PrepaidPostpaid 일 수 있습니다.

  • Prepaid mode에서는 모든 고정 요금 및 설정 요금이 월 초 또는 부과된 청구 기간이 시작될 때 청구됩니다. 변수 비용은 항상 다음 달의 시작 부분에 계산되고 청구됩니다.
  • Postpaid 모드에서는 다음 달의 시작 부분에 모든 고정 요금 및 변수 비용이 청구됩니다.

자세한 내용은 자동 청구 프로세스를 참조하십시오.

23.2. 구동 및 게이트웨이 (Charging & Gateway)

이 설정은 신용 카드 트랜잭션을 가능하게 합니다. 이 설정이 켜져 있으면 선택한 결제 게이트웨이를 사용하여 모든 결제 송장이 청구됩니다. 이 설정을 해제한 경우 청구가 발생하고 송장이 발행되지만 실제 결제 트랜잭션이 수행되지 않습니다.

23.3. 통화(인증 및 게이트웨이)

청구 및 신용 카드 트랜잭션이 수행될 통화를 선택합니다. 선택한 통화가 결제 게이트웨이에서 지원되는지 확인하십시오. 이 설정은 전역적이며 모든 송장 및 트랜잭션에 적용되며, 다른 개발자 계정에 대해 서로 다른 통화를 설정할 수 없습니다.

23.4. 송장 표 (인증 & 게이트웨이)

Invoice footnote 필드에 도입된 텍스트는 모든 PDF 송장 하단에 표시됩니다. 이 필드를 사용하여 고객의 청구 및 청구 정책에 대한 추가 정보를 제공할 수 있습니다.

각주 텍스트가 변경되면 PDF가 이미 생성된 송장에 자동으로 적용되지 않습니다. 그러나 송장의 PDF를 다시 생성하여 변경 사항을 적용할 수 있습니다.

23.5. 0 % (Charging & Gateway)인지 여부를 나타내는 텍스트

이 필드는 PDF 송장에 텍스트 메시지를 추가하는 데 사용되며, 경우에 따라 청구된 계정의 경우 0 %입니다. 이 라인은 value / Sales tax가 0으로 명시적으로 설정된 경우에만 표시됩니다. 그렇지 않으면 표시되지 않습니다. 또한 텍스트는 관리 포털의 Invoice 페이지에도 표시됩니다.

자세한 내용은 이 설정을 참조하십시오.

23.6. 기록을 위한 YAML 구성

monetar .yml 파일을 사용하면 3scale 배포에 대한 통화 목록을 구성할 수 있습니다. 3scale은 ISO 4217을 기반으로 3자 통화 코드를 사용합니다.

중요
  • 결제 게이트웨이가 선택한 통화를 지원하는지 확인합니다.
  • 3scale은 신용 카드 트랜잭션을 위한 다음 결제 게이트웨이와 통합됩니다.

    • Braintree
    • 스트라이프

23.6.1. OpenShift에서 신뢰할 수 있는 구성 변경

통화 구성을 변경하려면 다음을 수행하십시오.

프로세스

  1. four .yml 의 새로운 컨텐츠의 소스를 시스템 구성 맵의 항목으로 추가합니다. 다음 예제에서는 기본 통화 목록에 ARS - 아르헨티나 Peso를 추가하고 추가하는 방법을 보여줍니다.

    $ oc patch configmap system --type merge -p "{\"data\": {\"currencies.yml\": \"production:\n  'USD - American Dollar': 'USD'\n  'EUR - Euro': 'EUR'\n  'GBP - British Pound': 'GBP'\n  'NZD - New Zealand dollar': 'NZD'\n  'CNY - Chinese Yuan Renminbi': 'CNY'\n  'CAD - Canadian Dollar': 'CAD'\n  'AUD - Australian Dollar': 'AUD'\n  'JPY - Japanese Yen': 'JPY'\n  'CHF - Swiss Franc': 'CHF'\n  'SAR - Saudi Riyal': 'SAR'\n  'ARS - Argentine peso': 'ARS'\n\"}}"
    Copy to Clipboard Toggle word wrap
    참고

    watches .yml 구성 파일의 콘텐츠 예제를 보려면 기본 YAML 파일: history .yml 에 액세스합니다. 파일에는 새 3scale 배포의 기본 구성이 표시됩니다.

    base: &default
      'USD - American Dollar': 'USD'
      'EUR - Euro': 'EUR'
      'GBP - British Pound': 'GBP'
      'NZD - New Zealand dollar': 'NZD'
      'CNY - Chinese Yuan Renminbi': 'CNY'
      'CAD - Canadian Dollar': 'CAD'
      'AUD - Australian Dollar': 'AUD'
      'JPY - Japanese Yen': 'JPY'
      'CHF - Swiss Franc': 'CHF'
      'SAR - Saudi Riyal': 'SAR'
    production:
      <<: *default
    preview:
      <<: *default
    Copy to Clipboard Toggle word wrap
  2. system-(app|sidekiq) DeploymentConfigsystem-config 볼륨에 새 ConfigMap 항목 popular .yml 을 포함합니다. 이렇게 하면 관련 컨테이너 내부에 새 콘텐츠가 마운트되고 새 구성이 활성화됩니다.

    $ export PATCH_SYSTEM_VOLUMES='{"spec":{"template":{"spec":{"volumes":[{"configMap":{"items":[{"key":"zync.yml","path":"zync.yml"},{"key":"rolling_updates.yml","path":"rolling_updates.yml"},{"key":"service_discovery.yml","path":"service_discovery.yml"},{"key":"currencies.yml","path":"currencies.yml"}],"name":"system"},"name":"system-config"}]}}}}'
    Copy to Clipboard Toggle word wrap
    $ oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES
    $ oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES
    Copy to Clipboard Toggle word wrap
    $ unset PATCH_SYSTEM_VOLUMES
    Copy to Clipboard Toggle word wrap

23.6.2. 새로운 통화 확인

3scale 관리 포털에서 사용할 수 있는지 확인하려면 다음을 수행하십시오.

프로세스

  1. Audience > billing > Charging & Gateway 로 이동합니다.
  2. 통화 드롭다운 목록에서 통화 목록을 사용할 수 있는지 확인합니다.
  3. 사용할 통화를 선택합니다.

23.7. 송장 ID 청구 기간(인증 및 게이트웨이)

3scale의 송장에는 다음 두 가지 유형의 식별자가 있습니다.

실제 ID
데이터베이스의 송장을 고유하게 식별하는 것은 무엇입니까. 이는 송장 URL(예: https://<dashboard_domain>/buyers/accounts/<acount_id>/invoices/<invoice_id> )에 표시되는 숫자 ID이며 billing API의 송장 ID로 사용됩니다.
친숙한 ID
송장에 표시되는 것은 사용자에게 친숙한 식별자입니다. 3scale 계정마다 고유해야 하지만 기술적으로는 친숙한 ID를 복제할 수 있습니다. 3scale이 중복 식별자를 인식하는 경우 다음과 유사한 경고 메시지가 표시됩니다. 이 송장 ID는 이미 사용 중이므로 변경해야 할 수 있습니다. 친숙한 식별자가 24시간 이상 수정 사항으로 표시되면 지원팀에 문의하십시오.

이 설정은 송장의 Friendly ID 형식을 정의합니다.

monthly (기본값)
YYYY-MM-XXXXXXXX, 즉 ID에는 송장 연도, 월, 번호가 포함됩니다. 예: 2018-02-00000013
yearly
YYYY-XXXXXXXX, 즉 연도와 숫자만 포함됩니다. 예: 2018-00000001

송장 식별자에 대한 청구 기간을 월간 에서 연간 로 변경하는 유일한 영향은 친숙한 ID 형식을 변경하는 것입니다. 이 수정 사항은 청구 주기 기간을 변경하지 않습니다. 3scale API Management에서 월간 청구만 지원됩니다. 송장 식별자의 형식을 연간로 변경하면 회계 부서의 요구 사항이 있는 경우 사용할 수 있습니다.

연간 비용을 청구해야 하는 경우 청구를 수동으로 처리해야 합니다. 새 송장을 만들고 연간 비용으로 선 항목을 추가할 수 있습니다. 연간 청구를 사용하려면 애플리케이션 계획을 무료로 설정하고, 송장이 생성되지 않고/또는 매달 자동으로 청구되지 않도록 애플리케이션 계획을 설정할 수도 있습니다.

23.8. 신용 카드 정책

여기에서 다음 페이지의 경로를 구성할 수 있습니다.

  • 법적 약관 페이지
  • 개인 정보 보호 페이지
  • 취소 페이지

24장. 결제를 위한 신용 카드 게이트웨이

3scale API 공급자로, API에 대한 서브스크립션을 수익화하기 위해 신용 카드의 결제 게이트웨이를 정의합니다.

24.1. 3scale API Management에서 지원하는 신용 카드 게이트웨이

3scale은 신용 카드 트랜잭션을 위한 다음 결제 게이트웨이와 통합됩니다.

  • Braintree
  • 스트라이프

온라인 결제 서비스는 신용카드 데이터를 수집할 때 요구 사항을 표시해야 합니다. 명령은 고객이 결제 방법을 차용할 수 있는 권한의 기록입니다. 이 명령은 제공된 결제 방법이 서비스에 대한 후속 결제를 수집하는 데 사용될 것이라고 명확하게 명시해야 합니다. Stripe 및 Braintree의 요구 사항에 대한 자세한 내용은 추가 리소스 에 나열된 각 결제 게이트웨이에 대한 외부 문서 링크를 참조하십시오.

24.2. Stripe을 신용 카드 게이트웨이로 구성

3scale API 공급자로 Stripe를 신용 카드 게이트웨이로 사용하여 서브스크립션에서 API로의 결제를 수신할 수 있도록 Stripe를 결제 게이트웨이로 사용하여 관리 포털과 개발자 포털을 결제 게이트웨이로 구성합니다.

사전 요구 사항

  • Stripe 계정이 있어야 합니다.

    • Stripe 하위 계정을 각 비즈니스 또는 프로젝트에 사용할 것을 권장합니다.
    • 여러 계정에 대한 Stripe 문서를 참조하십시오.
  • Stripe 관리자 권한이 있어야 합니다.

프로세스

Stripe를 결제 게이트웨이로 사용하여 3scale을 구성하려면 다음 단계를 따르십시오.

  1. 3scale 관리 포털에서 계정 설정 > 개인 > 토큰으로 이동합니다.
  2. billing API 범위를 사용하여 읽기 및 쓰기 토큰을 생성합니다.

    1. 액세스 토큰 추가를 클릭합니다.
    2. 토큰 이름을 지정합니다.
    3. scope: billinging API 를 선택합니다.
    4. 읽기 및 쓰기 권한 수준을 선택합니다.
    5. 액세스 토큰 생성을 클릭합니다.
    6. 액세스 토큰을 복사합니다.

      • 액세스 토큰을 파일 텍스트에 복사해야 합니다. 액세스 토큰은 나중에 표시되지 않습니다.
    7. 토큰 생성을 완료하려면 토큰을 복사했습니다.

작업으로 돌아가기.

24.2.2. Stripe에서 키와 Webhook 시크릿 가져오기

참고
  • Stripe에서 Webhook를 구성해야 합니다.
  • Webhook를 사용하여 결제에 성공했음을 3scale에 알립니다.
  • 3scale은 송장 상태를 업데이트하고 추가 시도를 방지합니다.

Stripe 계정에서 시크릿 키게시 가능한 키를 가져옵니다.

  1. Stripe 대시보드를 엽니다.
  2. Stripe 문서의 지침에 따라 API 키를 찾습니다.
  3. 비밀 키게시 가능한 키복사

Stripe 계정에서 Webhook 서명 보안을 생성합니다.

  1. 개발자 > Webhook로 이동합니다.
  2. 엔드포인트 추가를 클릭합니다.
  3. 다음 끝점 URL을 입력합니다.

    https://<Your-provider-admin-domain>/api/payment_callbacks/stripe_callbacks?access_token=<value-of-access-token>
    Copy to Clipboard Toggle word wrap
  4. 보낼 이벤트에서 payment_intent.succeeded 를 추가합니다.
  5. 엔드포인트 추가를 클릭합니다.
  6. 방금 생성한 Webhook의 서명 시크릿을 표시하려면 클릭하여 이 시크릿을 기록해 둡니다. 이는 Webhook 서명 보안입니다.

작업으로 돌아가기.

24.2.3. 3scale API Management 관리 포털에서 청구 구성

3scale 관리 포털에서 다음을 수행합니다.

  1. Audience > billing > Charging & Gateway 로 이동합니다.
  2. Charging enabled 를 선택하고 Save 를 클릭합니다.
  3. credit 카드 게이트웨이 > 게이트웨이 에서 게이트웨이로 Stripe 을 선택합니다.
  4. Stripe의 키 및 Webhook 시크릿 을 보유하는 Stripe 계정에서 얻은 게시 키, 게시 가능한 키 및 Webhook 서명 보안을 추가합니다.
  5. 저장을 클릭합니다.

작업으로 돌아가기.

24.2.4. 3scale 개발자 포털에서 신용 카드 세부 정보 편집

  1. 개발자 계정을 사용하여 3scale 개발자 포털에 로그인합니다.
  2. Settings > credit Card Details 로 이동합니다.
  3. 다음 신용 카드 세부 정보 추가: 신용 카드 번호, 만료 날짜 및 CVC.
  4. Save details 를 클릭합니다.

작업으로 돌아가기.

24.2.5. 실패한 이메일 응답 의 텍스트 업데이트

SCA 결제 수정 사항과 관련하여 invoice_messenger_unsuccessfully_servingd_for_buyer.text.liquid 이메일의 텍스트는 3scale 2.10의 수동 업데이트가 필요합니다.

  1. 3scale 관리 포털에서 Audience > Messages > Email Templates 로 이동합니다.
  2. 재시도가 있는 구매자에 대해 Invoice charge failure를 선택합니다.
  3. 덮어쓰기 를 클릭합니다.
  4. 템플릿 메시지 업데이트: 실패한 이메일 응답에 사용할 전체 텍스트입니다.

    Dear {{ account.name }},
    
    Thank you for using our service.
    
    We're sorry to inform you that your last payment was declined.
    This may have been caused by a few common reasons:
    
    - A new authentication policy enforced by your bank
    - An expired credit card
    - Insufficient funds on the account
    
    To continue using your service, verify the status of your credit card and update or re-enter the credit card details at {{payment_url}}.
    
    If you need help, don't hesitate to contact us at {{ provider.finance_support_email }}.
    
    Best regards,
    The {{ provider.name }} API Team
    Copy to Clipboard Toggle word wrap
  5. 이메일 템플릿 생성을 클릭합니다.

이 단계를 통해 실패한 이메일 응답에 대해 이메일 템플릿을 업데이트했습니다.

작업으로 돌아가기.

24.3. Braintree를 신용 카드 게이트웨이로 구성

Braintree를 사용하여 서브스크립션에서 API로의 결제를 수신하도록 3scale API 공급자로 Braintree를 사용하여 관리 포털과 개발자 포털을 결제 게이트웨이로 구성합니다.

사전 요구 사항

  • Braintree 에는 계정이 있어야 합니다.
  • 3D Secure (3DS)를 사용하는 고객의 보안 체크아웃을 유지하려면 3scale에 3DS를 활성화하기 전에 Braintree 계정에 3DS를 활성화해야 합니다.

    • 기본적으로 3scale 및 Braintree 모두 3DS를 off로 사용합니다(비활성화됨).

프로세스

Braintree를 사용하여 결제 게이트웨이로 3scale을 구성하려면 다음 단계를 따르십시오.

Braintree에서 키 및 가맹자 ID 가져오기

Braintree 계정에서 공개 키, 판매자 ID개인 키를 가져옵니다. 이러한 값을 얻는 방법에 대한 자세한 내용은 추가 리소스 에 나열된 Braintree 설명서를 참조하십시오.

작업으로 돌아가기.

3scale 관리 포털에서 청구 구성

3scale 관리 포털에서 다음을 수행합니다.

  1. Audience > billing > Charging & Gateway 로 이동합니다.
  2. Charging enabled 를 선택합니다.
  3. 통화를 선택합니다.

    • 3scale billing 페이지에 지정된 통화 유형은 Braintree 가 가맹점 계정에서 사용되는 통화 유형과 일치해야 합니다.
  4. 저장을 클릭합니다.
  5. credit 카드 게이트웨이 > Gateway 에서 게이트웨이로 Braintree 를 선택합니다.
  6. Braintree에서 키 및 가맹자 ID 가져오기 의 Braintree 계정에서 얻은 공개 , Merchant ID 및 개인 키를 추가합니다.
  7. 3DS를 활성화하려면 3D Secure Enabled 를 선택합니다.
  8. 변경 사항 저장을 클릭합니다.

작업으로 돌아가기.

3scale 개발자 포털에서 신용 카드 세부 정보 편집

3scale API 소비자로서 3scale 개발자 포털에서 신용 카드 세부 정보를 추가하거나 편집합니다. 신용 카드를 발급한 엔티티와 금융 세부 사항을 일치시키려면 이 창에 나열된 모든 필드는 필수입니다.

  1. 개발자 계정을 사용하여 3scale 개발자 포털에 로그인합니다.
  2. Settings > credit Card Details 로 이동합니다.
  3. Add credit card Details and billinging Address 링크를 클릭합니다.
  4. 결제 세부 정보 추가: 이름, 성, 전화.
  5. 신용 카드 세부 정보, 신용 카드 번호, 만료 날짜 및 CVC를 추가합니다.
  6. 청구 주소 세부 정보( company, Street address, zip/postal code, city 및 state/region)를 추가합니다. 그런 다음 국가를 선택합니다.
  7. Save details 를 클릭합니다.
  8. 프롬프트가 표시되면 구매에 대해 2 단계 인증 (2FA)을 완료합니다. 예를 들어 은행에서 SMS 2FA 옵션을 활성화한 경우 이 방법을 사용하여 인증 프로세스를 완료해야 합니다.

작업으로 돌아가기.

24.4. 개발자 포털을 통해 거부된 송장의 결제 허용

3scale API 공급자로서 개발자 포털을 통해 거부된 송장을 결제할 수 있습니다. 이러한 결제를 활성화하려면 관리 포털에서 Invoices 템플릿을 업데이트합니다. 이 절차는 개발자 포털의 기존 인스턴스를 위한 것입니다.

사전 요구 사항

  • 3scale에 대한 관리자 권한이 있어야 합니다.
  • Stripe 또는 Braintree 가 있는 계정이 있어야 합니다.

프로세스

개발자 포털을 통해 거부된 송장의 결제를 허용하려면 다음 단계를 따르십시오.

  1. 3scale 관리 포털에서 Audience > Developer Portal > Content 로 이동합니다.
  2. Root > Invoices > Show template 을 편집합니다.
  3. 다음 코드 행을 교체합니다.

    <a href="{{ urls.invoices }}">
      <i class="fa fa-chevron-left"></i>
        Cancel
        </a>
        {{ invoice.period_begin | date: '%B, %Y' }} Invoice
    Copy to Clipboard Toggle word wrap

    이 스니펫에서 다음을 수행합니다.

    <div class="clearfix">
      <a href="{{ urls.invoices }}">
        <i class="fa fa-chevron-left"></i>
          Cancel
        </a>
        {{ invoice.period_begin | date: '%B, %Y' }} Invoice
        {% if invoice.pay_now? %}
          <a href="{{invoice.url}}/payment" class="pull-right btn btn-success pay-invoice-btn">Pay invoice</a>
        {% endif %}
    </div>
    Copy to Clipboard Toggle word wrap

24.5. 신용 카드 게이트웨이 관련 문제 해결

Stripe 또는 Braintree를 결제 게이트웨이로 사용하는 3scale API 공급자로서 이러한 신용 카드 게이트웨이 관련 문제를 해결할 수 있습니다.

스트라이프

  • 3scale의 데이터와 함께 Stripe의 데이터를 매핑하려면 3scale-[PROVIDER_ID]-[DEVELOPER_ACCOUNT_ID] 로 구성된 metadata.3scale_account_reference 라는 Stripe 필드를 사용할 수 있습니다.

Braintree

  • Braintree 계정이 샌드박스 모드에 있고 문제가 발생하면 프로덕션으로 변경해야 합니다.
  • 3D Secure (3D)가 활성화된 3scale 개발자 포털에 저장된 신용 카드의 경우 3scale을 Braintree와 통합하는 데 권장되는 솔루션입니다.

    1. 3scale API 공급자: 3scale 관리 포털에서 청구 구성 에 나열된 단계를 따릅니다.
    2. 3scale API 소비자: 3scale 개발자 포털에서 신용 카드 세부 정보 편집 에 나열된 단계를 따릅니다.
  • Braintree의 데이터를 3scale에 데이터와 함께 매핑하려면 3scale-[PROVIDER_ID]-[DEVELOPER_ACCOUNT_ID] 로 구성된 customer.id 라는 Braintree 필드를 사용할 수 있습니다.

25장. 가격

이 섹션에서는 API 사용을 위해 개발자를 청구할 수 있는 다양한 방법을 설명합니다.

설정 비용
는 서비스에 대한 서브스크립션 시 적용되는 일회성 비용이며 다른 계획으로 전환할 때 비용이 청구되지 않습니다. 구독의 첫 번째 월에만 송장/신용 카드에 표시됩니다. 애플리케이션 계획, 서비스 계획 및 계정 계획에 대해 구성할 수 있습니다.
월 비용
매달 반복 비용이 청구됩니다. 월 중순에 서브스크립션이 발생한 경우 이 기간이 지연됩니다. 종종 고정 요금 이라고 합니다. 애플리케이션 계획, 서비스 계획 및 계정 계획에 대해 구성할 수 있습니다.
변수 비용
애플리케이션 계획에 구성된 각 방법/메트리트에 적용되는 가격 규칙에서 파생되는 비용입니다. 이는 API 사용을 기반으로 하므로 청구 기간이 종료된 경우에만 미리 알 수 없습니다. 애플리케이션 계획에서만 사용할 수 있습니다.

예제

If you have a plan with monthly cost of $10, but want to charge your developer a $5 setup fee. The initial charge would be for $15, while all subsequent charges would be for $10.
Copy to Clipboard Toggle word wrap

25.1. 가격 규칙

가격 규칙은 각 API 요청 비용을 정의합니다. 동일한 메트릭에 대한 여러 가격 책정 규칙은 가격 규칙이 적용되는 경우 범위를 나눕니다. 가격 규칙은 일정 월을 기반으로 하며 카운터는 매달 1일의 00:00 UTC로 재설정됩니다.

예시 1

Until 100 calls per month (from 1 to 100) each API call can be charged at $0.04, and starting from the call 101 (from 101 to infinity) the calls are charged at $0.10.
Copy to Clipboard Toggle word wrap

예시 2

The first 1000 calls are not charged (cost $0), because they are included in the plan which has a monthly fixed cost. Starting from call 1001, each call is charged at $0.50.
Copy to Clipboard Toggle word wrap

예시 3

Calls from 1 to 100 are charged at $0.30, 100 to 500 – at $0.40, and 500 and further – at $0.50.
Copy to Clipboard Toggle word wrap

참고

가격 규칙은 메트릭 및 방법에 대해 정의됩니다. 실제 API 요청은 매핑 규칙을 통해 이러한 메트릭 및 메서드에 매핑됩니다.

25.2. 가격 규칙 설정

  1. [ your_API_service] > Applications > Application Plans 로 이동합니다.
  2. 기존 애플리케이션 계획을 선택하거나 새 애플리케이션을 생성합니다.
  3. Metrics, Methods, Limits & pricing Rules 섹션의 가격 책정을 클릭하여 가격 섹션을 엽니다.
  4. 새 가격 규칙을 클릭합니다.
  5. 단위당 값을 From, To 및 Cost를 설정하고 가격 규칙 만들기 를 클릭합니다.

마지막 두 단계를 반복하여 필요한 모든 가격 규칙을 만듭니다.

규칙을 무한 으로 설정하려면 To 필드를 비워 둡니다.

지표 비용의 최대 10진수 수는 10진수가 더 많은 경우 값이 4개의 10진수로 반올림됩니다.

25.3. 기존 가격 규칙 업데이트

  1. 편집을 클릭합니다.
  2. 단위 필드당 From, To 및 Cost를 필요한 대로 조정합니다.
  3. 가격 규칙 업데이트를 클릭합니다.

26장. 청구

청구 프로세스는 유료 서비스에 가입된 경우 개발자 계정에 송장을 생성합니다. 송장은 구성된 결제 게이트웨이를 사용하여 청구됩니다.

26.1. 송장 나열

Audience > billing > Earning by month 섹션에서 주거에 따라 해당 월에 발행된 모든 송장의 합계로 계산, 기한 및 수신 된 지불에 대한 개요를 찾을 수 있습니다.

합계
취소를 제외한 모든 송장
프로세스 중
open, Cryostatd 및 Pending invoices
overdue
실패 및 무료 송장
유료
유료 송장

특정 월을 클릭하면 해당 달의 모든 송장을 나열할 수 있습니다.

또한 Audience > billing > Invoices 로 이동하여 송장 목록을 볼 수 있습니다. 여기서 ID(간체 ID), 계정 이름, 월 및 상태별로 송장을 찾을 수 있습니다.

특정 개발자 계정의 송장은 Audience > Accounts > Listing > [selected account] 의 계정 세부 정보 페이지의 X Invoices 에서 확인할 수 있습니다. 여기서 X는 계정에 있는 송장 수입니다.

26.2. 송장 보기

송장 목록에서 송장에 친숙한 ID를 클릭하면 송장 세부 정보가 표시됩니다.

26.2.1. 송장 세부 정보

제목에는 송장의 월과 연도가 포함되어 있으며 송장이 수동으로 작성되었는지 또는 자동 청구 프로세스(예: 2018년 2월(수동으로 생성))를 통해 표시됩니다.

아래 세부 정보 블록은 송장의 친숙한 ID, 송장 상태, 송장이 완료되고 발행된 날짜, 진행 및 결제 시점을 보여줍니다. PDF가 이미 생성된 경우 PDF를 다운로드하기 위한 링크도 표시됩니다.

블록으로 발행된 Issued byIssued to block은 API 공급자의 이름과 주소를 적절하게 표시하고 개발자 계정을 적절하게 표시합니다.

라인 항목이 있는 블록 아래에는 전체 비용, 전체 비용의 계산을 포함한 라인 항목 아래에 표시됩니다. 그리고 text in text to show if Cryostat/Sales tax is 0%가 구성된 경우 여기에도 표시됩니다.

송장의 거래 블록에서 거래 상태, 타임 스탬프, 참조 번호, 결제 게이트웨이 및 금액을 포함하여 모든 신용 카드 트랜잭션 시도 목록을 볼 수 있습니다. 참조 번호를 사용하여 결제 게이트웨이 관리자 콘솔에서 트랜잭션을 찾을 수 있습니다.

26.2.2. 송장 편집

송장이 Open 또는 Cryostatd 상태인 경우 송장의 일부 세부 정보를 편집할 수 있습니다.

송장 보기 오른쪽 상단에 있는 편집 링크를 클릭하면 친숙한 ID와 청구 기간을 변경할 수 있습니다.

또한 송장 라인 항목을 추가 및 삭제할 수 있습니다 (지정 비용 제외 - 총, Cryostat / 판매 세액, benefit / Sales tax 포함). 새 행 항목을 추가하려면 추가 를 클릭하고 이름, 이름, 값(비용에 영향을 미치지 않음), 설명 및 비용을 작성합니다.

송장 보기 하단의 링크는 송장의 현재 상태(예: PDF 생성, 발행 송장, 취소 송장, Regenerate PDF, Charge, Mark as paid )에 따라 다양한 작업을 수행할 수 있습니다. 이러한 작업(pdf 관련 제외)은 송장 상태를 변경합니다.

26.3. 송장 상태

송장은 다음 상태 중 하나일 수 있습니다.

open
송장이 작성되었지만 자동화된 계산은 아직 완료되지 않았습니다.
완료
송장에는 현재 청구 기간 요금이 모두 추가됩니다.
보류 중
송장은 개발자에게 발행되었으며 현재 결제를 기다리고 있습니다.
고정되지 않음
송장에 실패했습니다만 자동 다시 시도 중입니다.
유료
송장이 성공적으로 청구되었습니다.
Failed
송장이 청구되지 않았으며 자동 다시 시도는 더 이상 시도되지 않습니다.
취소됨
관리자가 취소했습니다.

26.4. 자동 청구 프로세스

3scale에서는 청구 프로세스가 매일 실행됩니다. 송장을 생성하고, 청구 흐름에 따라 상태를 변경하고, 구성된 결제 게이트웨이를 사용하여 요금을 수행합니다.

청구 흐름은 Prepaid 및 Postpaid 모드의 경우 약간 다르며 3scale의 청구는 월을 기반으로 하므로 첫 번째 날에 발생하는 특수 이벤트가 있습니다.

26.4.1. 각 달의 첫날

postpaid

  • bill 변수 비용 이전 월: 비용은 오픈 송장에 선 항목으로 포함됩니다.
  • 지난 한 달 동안의 송장을 마감합니다.
  • bill의 현재 월에 대한 새 송장 만들기: Open 상태의 현재 월에 대한 새 송장을 만듭니다.

Prepaided

  • bill 고정 비용(현재 월)입니다.
  • bill 변수 비용(이전 달).

월 초에 완료되는 송장에 대한 알림은 API 관리자에게 전송되므로 송장을 검토하고 필요한 조정을 수행할 수 있습니다.

매일 수행되는 모든 작업은 위에서 설명한 달의 첫날에도 수행됩니다.

26.4.2. 매일

  • bill 만료 시험 및 새로운 계약이 아직 청구되지 않았습니다: 현재 달 동안 오픈 상태의 인보이스가 생성됩니다.
  • Prepaid only: all open invoices: Status changes to 입니다.
  • 발행 송장: 상태가 Pending 로 변경됩니다.

    • 송장은 일반적으로 완료 후 2~3일 후에 발행됩니다. 송장 발행 날짜는 현재 날짜로 설정되고 Due On date(인보가 청구되는 경우) 날짜는 발행 됨 + 2일로 설정됩니다.
    • 개발자에게 송장이 발행되면 이메일 알림이 수신되고 개발자 포털에서 발행된 송장을 확인할 수 있습니다.
  • 청구 송장

    • 유료 및 보류 상태의 송장은 현재 또는 이전 날짜인 경우 청구됩니다.
    • 결제에 실패한 경우 송장 상태가 Unpaid 로 변경됩니다. 배선은 3일 후에 다시 시도될 것입니다. 3번의 재시도 실패 후 송장 상태가 Failed 로 변경되고 더 이상 청구 상태가 재시도되지 않습니다.
  • 만료된 신용 카드에 대해 알려줍니다.

    • 신용 카드가 곧 만료될 개발자 계정은 이메일 알림을 보냅니다.

26.4.3. 자동 및 수동 송장

자동 청구 프로세스에서 생성한 송장에는 송장 헤더에 (자동으로 생성된) 레이블이 있습니다. 예: 2019년 1월(자동 생성)에 대한 설명

수동으로 생성된 송장은 송장 세부 정보 페이지에서 (수동으로 생성됨) 로 표시됩니다.

자동 청구 프로세스는 현재 달 동안 기존 송장을 사용하여 추가 라인 항목을 만들 수 있지만 자동으로 생성된 송장만 사용할 수 있습니다. 수동으로 생성된 송장은 자동 청구 프로세스에 의해 업데이트되지 않습니다.

26.4.4. 중간 업그레이드

월 중순에 애플리케이션(또는 계정/서비스 서브스크립션)이 업그레이드되면 월 비용은 해당 월에 남은 일수에 따라 부과됩니다. 애플리케이션 계획에 구성된 제한은 프로비저닝되지 않습니다.

애플리케이션이 무료에서 유료 계획으로 업그레이드되면 다음에 청구가 새 송장을 실행할 때 월간 비용을 포함하여 새 송장이 생성됩니다.

애플리케이션이 유료 계획에서 보다 값 높은 유료 계획으로 업그레이드되면 다음과 같은 몇 가지 요인에 따라 달라집니다.

  • 빌링 모드: Prepaiding 또는 Postpaid.
  • 계획 변경이 이루어진 경우
26.4.4.1. 유료 청구
  1. 애플리케이션 계획이 동일한 청구일(예: 오전 8시 기준 기준)에서 변경되어 이전에 청구 날짜가 작성되었으므로 이전 계획에 대한 고정 비용이 송장에 포함되지 않았으며 '반복' 라인 항목으로 할인됩니다. 이전 계획에 대한 고정 비용도 송장에 추가됩니다.

    예: 한 고객은 한 달의 첫날에 계획 A (200$)에 가입했으며 같은 날 계획 B (300$)로 업그레이드했습니다. 이 경우 하나의 송장이 생성되고 다음 행 항목이 포함됩니다.

    Expand
    설명비용

    고정 비용 ('Plan A')

    200

    복구 ('플랜 A')

    -200

    애플리케이션 업그레이드('플랜 A'를 '플랜 B'로)

    300

    합계

    300

    고객이 한 달의 다른 날에 등록한 경우 200의 비용 및 회수액이 부과됩니다.

  2. 이 애플리케이션에 대한 송장이 이미 발행된 후 애플리케이션 계획이 변경된 경우:

    • 업그레이드 의 경우 개발자는 두 가지 송장(초기 비용용 및 업그레이드를 위한 다른 하나의 송장)이 발행됩니다.

      예: 한 고객은 한 달의 첫날에 계획 A(200$)에 등록한 다음, 월 중반에 계획 B(300$)로 업그레이드되었습니다. 다음 송장이 생성됩니다.

      Expand
      설명비용

      고정 비용 ('Plan A')

      200

      합계

      200

      Expand
      설명비용

      복구 ('플랜 A')

      -100

      애플리케이션 업그레이드('플랜 A'를 '플랜 B'로)

      150

      합계

      50

      두 번째 송장에서, 회수된 비용(100$)과 새로운 비용(150$)은 청구 기간 도중에 업그레이드가 이루어지기 때문에 부과됩니다.

    • 애플리케이션 다운그레이드 (더 낮은 비용으로 계획 변경)에 대한 취소는 현재 지원되지 않습니다.
26.4.4.2. 유료 청구

무료 청구 모드에서는 단일 송장이 발행되며 RefundApplication upgrade line 항목이 포함됩니다.

중요

이 동작은 2018년 4월 20일에 다음과 같은 변경 사항이 도입되었습니다.

  • 애플리케이션이 생성된 당일에 업그레이드되었을 때 초기 비용(초기 애플리케이션 계획의 경우)에 포함되어 있지 않은 버그가 수정되었습니다.
  • 이전에는 신규 계획 비용과 이전 계획의 비용 차이를 포함하여 애플리케이션 업그레이드 시 하나의 행 항목만 추가되었습니다. 예를 들어 위의 Prepaid billing 섹션에 설명된 시나리오 2에서 (플랜 A - 200$에서 계획 B - 300$로 애플리케이션 업그레이드)에서 두 번째 생성 송장은 다음과 같습니다.
Expand
설명비용

애플리케이션 업그레이드('플랜 A'를 '플랜 B'로)

50

합계

50

여기서 50$는 월의 나머지 기간 (150$ - 100 $)에 대한 새로운 계획과 이전 계획의 예리된 비용의 차이점입니다.

2018년 4월 20일 이후 계산은 송장에 보다 명확하게 반영되며(별도의 취소 및 청구 포함) 총 비용은 이전과 동일하게 유지됩니다.

26.5. 계정당 청구/충전 활성화/비활성화

자동 청구 프로세스는 유료 서비스에 가입된 모든 개발자 계정에 대한 송장을 생성합니다.

마운팅은 전역에서 활성화 또는 비활성화할 수 있습니다. Configuring billing Settings, however it is also possible to enable or disable both billing and billing per developer account에서 참조하십시오. 이렇게 하려면 계정 페이지로 이동하여 해당 버튼(Enable / Disable)을 클릭합니다.

  • 월간 청구가 활성화/비활성화됨
  • 월간 청구가 활성화/비활성화됨

청구가 비활성화되고 청구가 활성화된 경우 개발자가 송장을 발행하지만 비용이 청구되지 않습니다. 이 기능은 유선 전송과 같이 별도로 배당을 처리하는 경우 유용합니다.

둘 다 비활성화되어 있는 경우 개발자는 발행되거나 청구되지 않습니다.

청구가 비활성화되고 청구가 활성화되어 있는 경우 개발자는 새 송장을 발행하지 않지만 모든 미결 상태(보류 중실패)는 계속 청구됩니다.

여기에서 billing Status 블록에서 신용 카드 세부 정보가 계정에 구성되어 있는지도 확인할 수 있습니다. 신용 카드 세부 정보가 구성된 경우 월과 카드 만료 연도가 표시됩니다. 신용 카드 세부 정보가 있으면 등록 및 계획 변경 시 개발자 포털 흐름에 영향을 미칠 수 있습니다( 26.9절. “신용 카드 흐름”참조).

26.6. 평가판 기간이 있는 계획

평가판 기간(일 단위)은 지정된 일수에 대한 청구를 지연할 유료 계획에 대해 설정할 수 있습니다.

상태 열에서 애플리케이션 목록([Your_product_name] > Applications > Listing)에서 애플리케이션의 평가판 기간 상태를 확인할 수 있습니다. 평가판은 N일 내에 만료 되며 평가판 왼쪽 필드의 애플리케이션 세부 정보 페이지에서 확인할 수 있습니다.

평가판 기간 동안 애플리케이션은 제한 없이 계획에 정의된 모든 기능 및 사용 제한을 사용할 수 있습니다.

평가판 기간이 설정되면 취소하거나 확장할 수 없습니다. 다른 계획으로 업그레이드하면 평가판 기간이 재설정되지 않습니다.

평가판 기간이 만료되기 10일 전, 향후 평가판 만료에 대해 알리는 이메일 알림이 개발자 계정으로 전송됩니다. 이 이메일의 템플릿은 Audience > Messages > Email Templates:애플리케이션 계획의 구매자에 대해 만료된 애플리케이션 평가판 기간, 평가판 기간이 있는 서비스 계획의 경우 서비스 평가판 기간이 만료될 수 있습니다. 개발자는 현재 계획에 남아 있거나 다른 계획으로 전환하거나 서브스크립션을 취소하려는 경우 API 공급자에게 문의해야 합니다.

평가판 기간이 완료되면 다음에 자동화된 청구 실행( 26.4절. “자동 청구 프로세스”참조)은 애플리케이션 또는 서비스가 현재 사용 중인 계획에 대한 비용에 따라 청구됩니다. 평가판 기간이 만료된 후에도 애플리케이션이 차단되거나 일시 중지 되지 않으며 계속 작동합니다.

평가판 기간은 기술적으로 무료 계획에 대해 설정할 수 있지만 기능이 유용성을 끊기 때문에 권장되지 않는 것이 좋습니다.

26.7. Cryostat 비율/판매율

VAT(Value-Added tax)는 유럽 연합 내에서 판매되는 상품 및 서비스에 적용되는 세금입니다. 다른 국가에도 비슷한 세금이 있습니다. 고객에게 API 서비스 사용을 청구하는 API 제공업체는 종종 세금을 청구하고 기존 규정을 준수하기 위해 송장에 반영해야 합니다.

3scale 청구는 구성된 경우 송장에 자동으로 Cryostat를 포함할 수 있습니다.

26.7.1. Cryostat 속도 필드 구성

Cryostat 비율은 송장의 총 비용에 적용되는 수(%)입니다. Dashboard에서 admin Portal의 다음 단계를 따르십시오.

  1. Audience > Accounts > Fields Definitions 로 이동합니다.
  2. 계정 섹션에서 생성 을 클릭합니다.
  3. [new field] 드롭다운 목록에서 vat_rate 를 선택합니다.
  4. 레이블 값을 설정합니다.
  5. 필드가 필수 인지, 개발자에 대한읽기 전용 또는 Hidden 이 있는지 여부를 표시하도록 확인란을 구성합니다.

    Choices 필드는 문자열만 허용하므로 이 필드는 사용할 수 없습니다.

  6. 생성을 클릭합니다.

26.7.2. Cryostat 코드 필드 구성

Cryostat 코드는 ID 번호입니다. Dashboard에서 관리 포털의 다음 단계를 수행합니다.

  1. Audience > Accounts > Fields Definitions 로 이동합니다.
  2. 계정 섹션에서 생성 을 클릭합니다.
  3. [new field] 드롭다운 목록에서 vat_code 를 선택합니다.
  4. 레이블 값을 설정합니다.
  5. 필드가 필수 인지, 개발자에 대한읽기 전용 또는 Hidden 이 있는지 여부를 표시하도록 확인란을 구성합니다.
  6. 생성을 클릭합니다.

26.7.3. 계정에 대한 value 설정

코드 및 rate 필드가 추가되면 개발자 계정 편집 양식 아래에 해당 값을 설정할 수 있습니다. 필드 정의에서 선택한 확인란에 따라 개발자 포털의 개발자가 필드를 보거나 편집할 수도 있습니다.

Cryostat 코드는 모든 문자열이 될 수 있습니다.

Cryostat 비율은 숫자여야 합니다. 정수 또는 10진수(예: 21, 23.5 )가 허용되며, 해당 숫자는 Cryostat로 포함될 비용의 백분율을 나타냅니다.

26.7.4. 자주하는 질문 (FAQ)

0이 아닌 Cryostat 비율이 구성된 개발자 계정에 대한 송장이 생성되면 송장에 다음 행 항목이 포함됩니다.

_Total cost (without <VAT rate>)_ +
_<VAT rate> Amount_ +
_Total cost (<VAT rate> <VAT rate value>% included)_
Copy to Clipboard Toggle word wrap

< VAT rate >는 Cryostat 비율 필드에 설정된 라벨로 교체되며 < VAT rate value >는 송장이 발행된 계정에 대해 구성된 값입니다.

Cryostat 코드는 코드 필드 정의의 라벨로 지정된 라벨과 함께 송장의 PDF 버전에 포함됩니다. 값은 개발자 계정 세부 정보에 설정된 값에 해당합니다.

vat_ratevat_code 필드는 3scale 계정 관리 API에서 읽고 쓸 수도 있습니다.

26.8. 개발자 포털 보기

개발자는 자신의 credit 카드 정보를 관리하고 개발자 포털에서 송장을 볼 수 있습니다.

Audience > 개발자 포털 > 기능 가시성의 재무 스위치는 개발자가 개발자 포털에서 청구 관련 요소를 볼 수 있도록 표시 가능해야 합니다.

로그인한 사용자는 설정 > 신용 카드 세부 정보에서 신용 카드 세부 정보를 업데이트할 수 있습니다. 폼을 구성한 결제 게이트웨이에 따라 달라질 수 있으며 사용자가 먼저 청구 주소를 입력해야 할 수 있습니다.

참고

신용 카드 세부 정보는 3scale 데이터베이스에 저장되지 않습니다. 이러한 세부 정보는 결제 게이트웨이에서 관리합니다. 신용 카드 번호의 마지막 4 자리 숫자, 만료 날짜 및 결제 게이트웨이가 제공하는 참조는 3scale 데이터베이스에 저장됩니다.

개발자는 개발자 포털에는 하나의 신용 카드 카드만 사용할 수 있습니다.

개발자 포털에서 신용 카드 세부 정보를 삭제할 수 없습니다. 신용 카드 세부 정보를 삭제하려는 개발자 계정의 사용자는 API 제공자에게 시스템에서 신용 카드 세부 정보를 삭제하도록 요청해야합니다.

송장을 보려면 사용자가 Settings > Invoices 로 이동하여 여기에서 각 송장에 대한 세부 정보를 표시하거나 송장 PDF를 다운로드할 수 있습니다.

26.9. 신용 카드 흐름

26.9.1. 유료 계획 등록

개발자가 유료 계획에 등록하면 애플리케이션 자격 증명을 볼 수 있기 전에 신용 카드 세부 정보를 입력하도록 요청됩니다. 개발자가 처음으로 개발자 포털에 로그인하면 Card Details 페이지로 리디렉션됩니다. 다른 개발자 계정 페이지에 액세스하려고 하면 credit 카드 세부 정보 페이지로 다시 리디렉션됩니다.

iquid 태그를 사용하여 해당 개발자 포털 템플릿을 사용자 지정하여 credit 카드 세부 정보 탭을 제외한 모든 메뉴 항목을 숨길 수 있습니다.

current_account Liquid drop은 requires_credit_card_now 방법을 노출하고, 신용 카드 세부 정보가 누락된 경우 true 를 반환하지만(관리 포털에서ServiceVersion이 구성된 경우에만), false 를 반환합니다.

하위 메뉴에서 모든 메뉴 항목 및 기타 사용자 인터페이스 요소를 숨길 수 있으며 users_menu 부분 요소는 다음 조건으로 래핑하여 숨길 수 있습니다.

{% unless current_account.requires_credit_card_now? %}
...
{% endunless %}
Copy to Clipboard Toggle word wrap

26.9.2. 무료에서 유료 계획으로 업그레이드

기존 애플리케이션의 변경 계획의 경우 개발자가 직접 계획 변경을 요청하거나 계획 변경을 요청하는 등 다양한 옵션을 구성할 수 있습니다. 애플리케이션이 무료에서 유료 계획으로 업그레이드되는 경우 업그레이드하기 전에 개발자가 신용 카드 세부 정보를 입력하도록 하는 것이 중요합니다. 이 설정은 [ your_product_name] > Integration > Settings,Application Plan Changing 섹션에서 설정할 수 있습니다.

개발자에게 신용카드가 있는 경우 직접 변경, 그렇지 않으면:
- 계획 변경만 요청
- 유료 계획에 대한 credit 카드 항목 요청

개발자가 변경을 요청하도록 허용하려면 첫 번째 옵션을 선택하고 신용 카드 세부 정보를 입력한 후 수동으로 업그레이드를 수행합니다.

개발자에게 유료 계획으로 업그레이드하기 전에 신용 카드 세부 정보를 입력해야 한다는 알림을 개발자에게 알리려면 두 번째 옵션을 선택합니다. 계획 선택기 위젯에서 개발자는 메시지가 표시됩니다. credit 카드 세부 정보를 입력할 때까지 계획을 변경할 수 없습니다.

26.10. 청구 주소 필드

개발자가 개발자 포털에서 credit 카드 세부 정보에 청구 주소를 입력하면 이 주소는 법적 계정 주소와 별도로 저장됩니다.

기본적으로 법적 주소는 발행 대상 필드의 송장에 표시됩니다. 그러나 개발자에게 법적 주소가 구성되어 있지 않지만 청구 주소만 있는 경우 후자는 송장에 사용됩니다. 이 경우 조직 이름은 주소의 일부로 간주됩니다.

기본적으로 청구 주소는 관리 포털 또는 제품 API를 통해 표시되지 않지만 다음과 같이 추가할 수 있습니다.

  1. Audience > Accounts > Fields Definitions 로 이동합니다.
  2. Account 블록 아래의 Create 를 클릭합니다.
  3. 드롭다운 목록에서 'billing_address'를 선택하고 레이블을 추가하고 읽기 전용 확인란을 선택한 다음 생성 을 클릭합니다.

이제 & lt;billing_address > 필드가 계정 관리 API 및 Webhook의 계정에 대한 XML 모델에 표시됩니다. 해당 청구 주소는 관리 포털의 계정 및 계정 편집 페이지에 읽기 전용으로 표시됩니다.

청구 주소는 개발자 포털의 credit 카드 세부 정보 섹션의 개발자가 변경할 수 있습니다. 관리자는 관리 포털에서 청구 주소를 변경할 수 없지만 다음 필드를 추가 필드로 사용하여 계정 관리 API의 계정 편집 엔드포인트를 사용할 수 있습니다.

billing_address_name
billing_address_address1
billing_address_address2
billing_address_country
billing_address_city
billing_address_state
billing_address_zip
billing_address_phone
Copy to Clipboard Toggle word wrap

27장. 이메일 알림

API 공급자 및 개발자를 위한 청구와 관련된 다양한 이벤트입니다.

27.1. 공급자 알림

3scale 계정의 사용자(Biling 권한이 있는 관리자 및 멤버)는 계정 설정 (오른쪽 상단에 있는 추가 아이콘) > 개인 > 알림 기본 설정 섹션에서 계정 설정 청구와 관련된 알림을 구독하거나 구독 취소할 수 있습니다.

필요한 작업: 송장 검토
청구 주기 종료일 전에 며칠 전에 발송되므로 고객에게 발송되기 전에 송장을 검토할 수 있습니다.
고객 다운그레이드
고객은 월간 고정 가격으로 계획을 변경할 때 전송됩니다.
신용 카드 만료
고객의 신용 카드가 만료될 때 전송됩니다.
결제 오류 (retry)
결제에 실패하면 전송되어 무료 송장과 다시 시도합니다.
지불 오류 (final)
결제에 대한 최종 재시도가 실패할 때 전송되어 실패한 송장이 생성됩니다.

3scale 계정의 모든 관리자 사용자는 구독한 경우 청구와 관련된 알림을 받습니다.

27.2. 개발자 이메일

개발자 계정으로 전송된 이메일 알림은 Audience > Messages > Email Templates 에서 구성할 수 있습니다. 다음 이메일을 사용할 수 있습니다.

구매자에 대한 신용 카드 만료 알림
신용 카드가 곧 만료될 때 전송됩니다.
구매자에 대한 송장이 성공적으로 청구되었습니다.
송장이 성공적으로 부과되면 발송됩니다.
재시도 시 구매자에 대한 송장 청구 실패
송장 청구가 실패하고 송장이 Failed 상태에 있을 때 전송됨은 다시 시도됨을 의미합니다.
재시도하지 않고 구매자에 대한 송장 청구 실패
송장 청구가 3rd 시간 동안 실패했으며 송장이 Unpaid 상태로 전달되었으며 다시 시도되지 않습니다.
구매자에 대한 예정된 송장 청구
개발자에 대한 송장이 발행될 때 전송됩니다.

개발자 계정의 모든 관리자 사용자는 위의 알림을 받습니다.

27.2.1. 청구 이메일 주소

고객이 청구와 관련된 문제를 해결하기 위해 연락할 수 있는 이메일 주소를 구성할 수 있습니다(예: billing@example.com, Audience > 메시지 > 재무 지원 이메일 필드의 지원 이메일 ).

이메일 템플릿은 iquid drop {{ provider.finance_support_email }} 을 사용하여 이메일 주소를 참조합니다.

28장. 청구 API

billing API는 일반적인 청구 프로세스를 자동화하는 방법을 제공합니다.

billing API의 모든 끝점은 문서 (?) > 3scale API 문서 > billing API 의 관리 포털에서 확인할 수 있습니다.

billing API에는 다음 요구 사항을 충족하는 유효한 액세스 토큰이 필요합니다.

  • 공급자 계정의 admin 사용자 또는 "Billing" 권한이 있는 멤버 사용자에게 속해야 합니다.
  • "Billing API" 범위가 포함되어야 합니다.

송장 ID가 매개 변수로 필요한 경우 Friendly invoice ID가 아닌 송장 ID를 나타냅니다.

API 끝점의 XML 응답은 대부분 자체 설명하며, Invoice의 필드는 웹 및 PDF 표현과 동일한 정보를 나타냅니다.

응답의 몇 가지 주목할 만한 필드:

  • creation_type: 수동으로 생성한 송장의 경우 'manual' 또는 3scale 자동 청구 프로세스에서 생성한 송장에 대한 ' manual' 값을 가질 수 있습니다.
  • provider: API 공급자의 세부 정보(관리자 계정)는 송장의 섹션에 의해 발행된 항목에 해당합니다.
  • Buyer: 개발자 계정의 세부 사항은 송장의 섹션과 일치합니다.

송장의 XML 표현에는 line-items 필드 아래에 있는 라인 항목 목록도 포함되어 있습니다.

일부 라인 항목, 일반적으로 예상되는 이름, 설명, 수량 및 비용 가격과 별도로 자동으로 생성된 항목의 경우 다음을 확인할 수 있습니다.

  • type: 라인 항목의 유형은 다음 값을 가질 수 있습니다.

    • line item::PlanCost - 고정 계획 비용을 위한 라인 항목의 경우입니다.
    • line item::VariableCost - 변수 비용을 위한 라인 항목의 경우입니다.
  • metric_id: 변수 비용 라인 항목의 경우 - 비용이 연결된 메트릭의 ID입니다.
  • contract_id: 비용이 연결된 서비스 또는 애플리케이션의 ID입니다.

V 부. Service Discovery: from OpenShift to 3scale API Management

Service Discovery는 OpenShift 클러스터에서 서비스를 가져오는 데 도움이 되는 3scale 기능입니다. OpenShift 서비스의 프라이빗 끝점은 이 API 백엔드를 번들로 제공하는 API(애플리케이션 프로그래밍 인터페이스) 백엔드 및 새 API 제품이 됩니다. 또한 OAS(OpenAPI Specification)를 기반으로 하는 서비스 사양은 API 제품의 ActiveDoc로 가져옵니다.

29장. Service Discovery

3scale에서 제공하는 Service Discovery 기능을 사용하면 OpenShift에서 API 서비스를 가져올 수 있습니다.

29.1. 서비스 검색 정보

Service Discovery가 구성되면 3scale이 동일한 OpenShift 클러스터에서 실행 중인 검색 가능한 API 서비스를 검사하고 관련 API 정의를 3scale로 자동으로 가져옵니다. 또한 3scale은 OAS(OpenAPI Specification)를 기반으로 API 통합 및 해당 사양을 업데이트하여 클러스터와 다시 동기화할 수 있습니다.

Service Discovery는 다음과 같은 기능을 제공합니다.

  • 클러스터 API를 사용하여 검색용으로 올바르게 주석이 지정된 서비스를 쿼리합니다.
  • 클러스터 내부의 내부 끝점을 사용하여 서비스에 액세스하도록 3scale을 구성합니다.
  • API 서비스 사양을 3scale ActiveDocs로 가져옵니다.
  • OpenShift, Red Hat Single Sign-On 및 Red Hat build of Keycloak 인증 흐름을 지원합니다.
  • Fuse 버전 7.2부터 Red Hat Fuse와 함께 작동합니다.

검색 가능한 서비스를 가져오면 해당 네임스페이스가 속한 프로젝트 내에 유지됩니다. 가져온 서비스는 새로운 고객용 API, 제품 및 해당 내부 API, 백엔드가 됩니다.

  • 온프레미스 3scale의 경우 3scale API 공급자에 자체 네임스페이스 및 서비스가 있을 수 있습니다. 검색된 서비스는 기존 및 기본 서비스 3scale과 공존할 수 있습니다.
  • Fuse 검색 가능한 서비스는 Fuse production 네임스페이스에 배포됩니다.

29.2. 검색 가능한 서비스 기준

OpenShift(OCP) 클러스터에서 3scale에서 API 서비스를 검색하려면 OCP 서비스가 아래 각 요소의 기준을 충족해야 합니다.

content-Type 헤더

API 사양의 Content-Type 헤더는 다음 값 중 하나여야 합니다.

  • application/swagger+json
  • application/vnd.oai.openapi+json
  • application/json

OpenShift Service 오브젝트 YAML 정의

  • OpenShift Service Object YAML 정의에는 다음 메타데이터가 포함되어야 합니다.

    • discovery.3scale.net 레이블: (필수) "true"로 설정합니다. 3scale은 선택기 정의를 실행하여 검색이 필요한 모든 서비스를 찾을 때 이 레이블을 사용합니다.
    • 다음 주석입니다.

      discovery.3scale.net/discovery-version: (선택 사항) 3scale 검색 프로세스의 버전입니다.

      discovery.3scale.net/scheme: (필수) 서비스가 호스팅되는 URL의 스키마 부분입니다. 가능한 값은 "http" 또는 "https"입니다.

      discovery.3scale.net/port: (필수) 클러스터 내에서 서비스의 포트 번호입니다.

      discovery.3scale.net/path: (선택 사항) 서비스가 호스팅되는 URL의 상대 기본 경로입니다. 경로가 root인 경우 "/"를 생략할 수 있습니다.

      discovery.3scale.net/description-path: 서비스에 대한 OpenAPI 서비스 설명 문서의 경로입니다.

      예를 들면 다음과 같습니다.

          metadata:
            annotations:
              discovery.3scale.net/scheme: "https"
              discovery.3scale.net/port: '8081'
              discovery.3scale.net/path: "/api"
              discovery.3scale.net/description-path: "/api/openapi/json"
           labels:
              discovery.3scale.net: "true"
           name: i-task-api
           namespace: fuse
      Copy to Clipboard Toggle word wrap
    • 관리 권한이 있는 OpenShift 사용자인 경우 OpenShift 콘솔에서 API 서비스의 YAML 파일을 볼 수 있습니다.

      1. Applications > Services 를 선택합니다.
      2. 서비스(예: i-task-api )를 선택하여 세부 정보 페이지를 엽니다.
      3. Actions > Edit YAML 을 선택하여 YAML 파일을 엽니다.
      4. 보기가 완료되면 취소 를 선택합니다.

ovs-networkpolicy 플러그인이 있는 클러스터

  • OpenShift와 3scale 프로젝트 간 트래픽을 허용하려면 ovs-networkpolicy 플러그인이 있는 클러스터에 애플리케이션 프로젝트 내에서 생성된 NetworkPolicy 오브젝트가 필요합니다.
  • NetworkPolicy 오브젝트 구성에 대한 자세한 내용은 네트워크 정책 정보를 참조하십시오.

29.3. Service Discovery를 사용하도록 OpenShift 구성 고려 사항

3scale 관리자는 OAuth(Open Authorization) 서버 사용 또는 없이 Service Discovery를 구성하는 두 가지 옵션이 있습니다.

OAuth 서버를 사용하여 3scale Service Discovery를 구성하는 경우 사용자가 3scale에 로그인할 때 발생하는 상황이 발생합니다.

  • 사용자가 OAuth 서버로 리디렉션됩니다.
  • 사용자가 OAuth 서버에 아직 로그인하지 않은 경우 사용자에게 로그인하라는 메시지가 표시됩니다.
  • 사용자가 SSO(Single Sign-On)를 사용하여 3scale Service Discovery를 처음 구현하는 경우 OAuth 서버에서 관련 작업을 수행하기 위해 권한을 부여하라는 메시지를 표시합니다.
  • 사용자가 다시 3scale로 리디렉션됩니다.

OAuth 서버를 사용하여 서비스 검색을 구성하려면 다음 옵션이 있습니다.

OAuth 서버 없이 서비스 검색을 구성하는 경우 사용자가 3scale에 로그인하면 사용자가 리디렉션되지 않습니다. 대신 3scale Single Service 계정은 Service Discovery를 위해 클러스터에 원활한 인증을 제공합니다. 모든 3scale 테넌트 관리 사용자는 3scale을 통해 API 서비스를 검색하는 동안 클러스터에 대해 동일한 액세스 수준을 갖습니다.

29.4. OpenShift OAuth 서버를 사용하여 서비스 검색 구성

3scale 시스템 관리자는 사용자가 OpenShift 기본 제공 OAuth 서버를 사용하여 3scale이 API를 검색하도록 개별적으로 인증하고 권한을 부여할 수 있습니다.

사전 요구 사항

  • 3scale 2.15를 OCP(OpenShift Container Platform) 4.x 클러스터에 배포해야 합니다.
  • 3scale에서 Service Discovery를 사용하려는 3scale 사용자는 OpenShift 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 3scale용 OpenShift OAuth 클라이언트를 생성합니다. 자세한 내용은 OpenShift 인증 설명서 를 참조하십시오. 다음 예에서 < provide-a-client-secret >을 < 3scale-master-domain-route >를 생성하고 3scale 마스터 관리 포털에 액세스하기 위한 URL로 교체하는 시크릿으로 바꿉니다.

        $ oc project default
        $ cat <<-EOF | oc create -f -
        kind: OAuthClient
        apiVersion: v1
        metadata:
         name: 3scale
        secret: "<provide-a-client-secret>"
        redirectURIs:
         - "<3scale-master-domain-route>"
        grantMethod: prompt
        EOF
    Copy to Clipboard Toggle word wrap
  2. 3scale Service Discovery 설정 파일을 엽니다.

    $ oc project <3scale-project>
    $ oc edit configmap system
    Copy to Clipboard Toggle word wrap
  3. 다음 설정을 구성합니다.

        service_discovery.yml:
          production:
            enabled: true
            authentication_method: oauth
            oauth_server_type: builtin
            client_id: '3scale'
            client_secret: '<choose-a-client-secret>'
    Copy to Clipboard Toggle word wrap
  4. 사용자가 검색 가능한 서비스가 포함된 클러스터 프로젝트를 볼 수 있는 적절한 권한이 있는지 확인합니다.

    <user>로 표시되는 관리자에게 검색할 서비스가 포함된 < namespace > 프로젝트에 대한 보기 권한을 부여하려면 다음 명령을 사용합니다.

    $ oc adm policy add-role-to-user view <user> -n <namespace>
    Copy to Clipboard Toggle word wrap
  5. configmap 을 수정한 후 system-app 및 system-sidekiq Pod를 재배포하여 변경 사항을 적용해야 합니다.

    $ oc rollout restart deployment/system-app
    $ oc rollout restart deployment/system-sidekiq
    Copy to Clipboard Toggle word wrap
  6. 롤아웃 상태를 확인하여 완료되었는지 확인합니다.

    $ oc rollout status deployment/system-app
    $ oc rollout status deployment/system-sidekiq
    Copy to Clipboard Toggle word wrap

29.5. Red Hat Single Sign-On 서버를 사용하여 서비스 검색 구성(Keycloak)

시스템 관리자는 사용자가 3scale을 개별적으로 인증하고 인증하여 OpenShift용 Red Hat Single Sign-On 을 사용하여 서비스를 검색할 수 있습니다.

Red Hat Single Sign-On 배포를 OpenShift의 권한 부여 게이트웨이로 사용하도록 OpenShift를 구성하는 방법은 이 워크플로 를 참조하십시오.

사전 요구 사항

  • 3scale 2.15를 OCP(OpenShift Container Platform) 4.x 클러스터에 배포해야 합니다.
  • 3scale에서 Service Discovery를 사용하려는 3scale 사용자는 OpenShift 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. Red Hat OAuth 서버(Keycloak)에서 3scale용 OAuth 클라이언트를 생성합니다.

    참고

    클라이언트 구성에서 OpenShift가 계정을 연결할 수 있도록 사용자 이름이 preferred_username 에 매핑되는지 확인합니다.

  2. 3scale Service Discovery 설정을 편집합니다.

    $ oc project <3scale-project>
    $ oc edit configmap system
    Copy to Clipboard Toggle word wrap
  3. 다음 설정이 구성되었는지 확인합니다. 여기서 '<the-client-secret-from-Keycloak >은 OAuth 클라이언트를 생성할 때 Keycloak이 자동으로 생성된 값입니다.

        service_discovery.yml:
          production:
            enabled: true
            authentication_method: oauth
            oauth_server_type: rh_sso
            client_id: '3scale'
            client_secret: '<the-client-secret-from-Keycloak>'
    Copy to Clipboard Toggle word wrap
  4. 검색 가능한 서비스가 포함된 클러스터 프로젝트를 볼 수 있는 적절한 권한이 있는지 확인합니다.

    예를 들어 &lt ;user& gt; 프로젝트에 대한 보기 권한을 부여 하려면 다음 명령을 사용합니다.

    $ oc adm policy add-role-to-user view <user> -n <namespace>
    Copy to Clipboard Toggle word wrap
  5. configmap 을 수정한 후 system-appsystem-sidekiq Pod를 재배포하여 변경 사항을 적용해야 합니다.

29.6. OAuth 서버 없이 서비스 검색 구성

OAuth 서버 없이 3scale Service Discovery를 구성하려면 3scale Single Service Account를 사용하여 OpenShift API 서비스에 인증할 수 있습니다.

사전 요구 사항

  • 3scale 2.15를 OCP(OpenShift Container Platform) 4.x 클러스터에 배포해야 합니다.
  • 3scale에서 Service Discovery를 사용하려는 3scale 사용자는 OpenShift 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 3scale 프로젝트가 현재 프로젝트인지 확인합니다.

    $ oc project <3scale-project>
    Copy to Clipboard Toggle word wrap
  2. 편집기에서 3scale Service Discovery 설정을 엽니다.

    $ oc edit configmap system
    Copy to Clipboard Toggle word wrap
  3. 다음 설정이 구성되었는지 확인합니다.

    service_discovery.yml:
       production:
          enabled: <%= cluster_token_file_exists = File.exists?(cluster_token_file_path = '/var/run/secrets/kubernetes.io/serviceaccount/token') %>
          bearer_token: "<%= File.read(cluster_token_file_path) if cluster_token_file_exists %>"
          authentication_method: service_account
    Copy to Clipboard Toggle word wrap
  4. 다음 옵션 중 하나를 수행하여 검색 가능한 서비스가 포함된 프로젝트를 볼 수 있는 관련 권한을 3scale 배포 amp 서비스 계정에 제공합니다.

    • view 클러스터 수준 권한을 사용하여 3scale 배포 amp 서비스 계정을 부여합니다.

      $ oc adm policy add-cluster-role-to-user view system:serviceaccount:<3scale-project>:amp
      Copy to Clipboard Toggle word wrap
    • OpenShift - 서비스 계정에 설명된 대로 보다 제한적인 정책을 적용합니다.

29.7. 검색된 서비스 가져오기

OpenShift 클러스터에서 OpenAPI 사양을 준수하는 새 API 서비스를 가져옵니다. 이 API는 3scale로 관리됩니다.

사전 요구 사항

  • OpenShift 관리자가 OpenShift 클러스터에 Service Discovery를 구성했습니다. 예를 들어 OpenShift 관리자는 Fuse Online 사용자 정의 리소스를 편집하여 3scale 사용자 인터페이스의 URL을 지정하여 3scale 검색을 활성화해야 합니다.
  • 3scale 관리자는 서비스 검색 정보 에 설명된 대로 서비스 검색용 3scale 배포를 구성했습니다.
  • 3scale 관리자는 API 서비스 및 해당 네임스페이스를 보는 데 필요한 권한을 3scale 사용자 또는 서비스 계정(구성된 인증 모드에 따라) 부여했습니다. 자세한 내용은 OpenShift 프로젝트에 대한 3scale 액세스 권한 부여를 참조하십시오.
  • 검색 가능한 서비스에 대한 기준 기준에 따라 API에 서비스 검색을 활성화하는 올바른 주석이 있습니다.
  • API 서비스는 3scale이 설치된 동일한 OpenShift 클러스터에 배포됩니다.
  • API의 서비스 이름과 해당 네임스페이스(OpenShift 프로젝트)를 알고 있습니다.

프로세스

  1. 3scale 관리 포털에 로그인합니다.
  2. 관리 포털 대시보드의 API 에서 제품 생성을 클릭합니다.
  3. OpenShift에서 가져오기 를 클릭합니다.

    • OAuth 토큰이 유효하지 않은 경우 OpenShift 프로젝트 관리자는 OpenShift 프로젝트에 대한 3scale 액세스 권한 부여에 설명된 대로 3scale 사용자에게 액세스 권한을 부여해야 합니다.
  4. 네임스페이스 필드에서 API가 포함된 OpenShift 프로젝트를 지정하거나 선택합니다(예: fuse ).
  5. 이름 필드에 해당 네임스페이스 내에서 OpenShift 서비스의 이름을 입력하거나 선택합니다(예: i-task-api ).
  6. 제품 생성을 클릭합니다.
  7. 새 API 서비스가 3scale로 비동기적으로 가져올 때까지 기다립니다. 관리 포털의 오른쪽 상단에 메시지가 표시됩니다. 서비스는 곧 가져옵니다. 완료되면 알림이 표시됩니다.

29.8. OpenShift 프로젝트에 대한 3scale 액세스 승인

OpenShift 프로젝트 관리자는 OAuth 토큰이 유효하지 않은 경우 3scale 사용자에게 네임스페이스에 액세스하도록 권한을 부여할 수 있습니다.

사전 요구 사항

  • OpenShift 프로젝트 관리자로 자격 증명이 있어야 합니다.
  • OpenShift 관리자가 OpenShift 클러스터에 Service Discovery를 구성했습니다. 예를 들어, Fuse Online API의 경우 OpenShift 관리자는 Fuse Online 서비스의 CONTROLLERS_EXPOSE_VIA3SCALE 환경 변수를 true 로 설정해야 합니다.
  • 3scale 관리자는 검색 가능한 서비스에 대한 기준 기준에 설명된 대로 서비스 검색용 3scale 배포를 구성했습니다.
  • OpenShift 프로젝트의 API 서비스 이름과 해당 네임스페이스를 알고 있습니다.
  • API 서비스는 3scale이 설치된 동일한 OpenShift 클러스터에 배포됩니다.
  • 검색 가능한 서비스에 대한 기준 기준에 따라 API에 서비스 검색을 활성화하는 올바른 주석이 있습니다.

프로세스

  1. Authenticate를 클릭하여 이 옵션 링크를 활성화합니다.
  2. 네임스페이스 관리자 자격 증명을 사용하여 OpenShift에 로그인합니다.
  3. Allow selected permissions 를 클릭하여 3scale 사용자에게 액세스 권한을 부여합니다.

29.9. 서비스 업데이트

클러스터의 서비스에 대한 현재 정의를 사용하여 3scale에서 기존 API 서비스를 업데이트(새로 고침)할 수 있습니다.

프로세스

  1. 3scale 관리 포털에 로그인합니다.
  2. API 제품의 개요 페이지로 이동합니다.
  3. Source: OpenSource 옆에 있는 새로 고침 링크를 클릭합니다.
  4. 새 API 서비스가 3scale로 비동기적으로 가져올 때까지 기다립니다.

VI 부. 멀티 테넌시

30장. 멀티 테넌시

Red Hat 3scale API Management를 사용하면 3scale 계정의 여러 독립 인스턴스가 단일 온프레미스 배포에 존재할 수 있습니다. 계정은 서로 독립적으로 작동하며 정보를 공유 할 수 없습니다.

30.1. 마스터 관리자 포털

마스터 관리자는 마스터 관리 포털 및 API 끝점을 통해 3scale 계정을 모니터링하고 관리합니다. 표준 관리 포털 과 유사하게 마스터 관리 포털에는 배포의 모든 계정에 대한 정보가 포함되어 있으며 고유한 계정 페이지를 통해 계정 및 사용자를 관리할 수 있습니다.

계정 관리자 작업에 대한 자세한 내용은 계정 가이드를 참조하십시오.

30.1.1. 마스터 관리 포털에 액세스

마스터 관리 포털에 액세스하려면 온프레미스 설치 프로세스 중에 마스터 관리 포털에 대해 특별히 정의된 자격 증명 및 URL을 사용해야 합니다.

마스터 관리 포털 URL은 MASTER_NAME (기본적으로 템플릿에서master )과 WILDCARD_DOMAIN:로 구성됩니다.

<MASTER_NAME>.<WILDCARD_DOMAIN>
Copy to Clipboard Toggle word wrap

마스터 관리 포털은 Master 플래그를 통해 식별할 수 있습니다.

마스터 관리 포털 플래그

30.1.2. 마스터 관리 포털을 통해 계정 추가

마스터 관리 포털을 통해 계정을 추가하려면 다음 단계를 따르십시오.

  1. 마스터 관리 포털에 로그인합니다.
  2. 계정 으로 이동합니다.
  3. 생성을 클릭합니다.
  4. 사용자에게 필요한 정보를 표시합니다.

    1. 사용자 이름
    2. 이메일
    3. 암호
    4. 암호 확인
  5. 조직에 필요한 정보를 표시합니다.

    1. 조직/그룹 이름
  6. 생성을 클릭합니다.

이러한 단계를 수행한 후 Red Hat 3scale API Management는 조직/그룹 이름 필드를 기반으로 계정의 계정 하위 도메인을 생성합니다. 생성한 계정의 세부 정보가 포함된 페이지를 볼 수도 있습니다.

30.1.3. 마스터 관리 포털을 사용하여 단일 게이트웨이 생성

마스터 관리 포털을 사용하면 THREESCALE_PORTAL_ENDPOINT 환경 변수를 구성하여 모든 테넌트에 대한 단일 게이트웨이를 만들 수 있습니다. 이는 OpenShift 템플릿으로 배포된 기본 apicast-stagingapicast-production 게이트웨이가 이러한 방식으로 구성된 Hosted 3scale(SaaS)의 호스팅 APIcast와 유사합니다.

마스터 관리 포털을 사용하여 단일 게이트웨이를 생성하려면 다음 단계를 따르십시오.

  1. 3scale 프로젝트의 system-master-apicast 시크릿에서 ACCESS_TOKEN 값을 가져옵니다. 또는 마스터 관리 포털에서 새 액세스 토큰을 생성할 수도 있습니다.
  2. APIcast를 배포할 때 다음 명령을 사용합니다.

     THREESCALE_PORTAL_ENDPOINT="https://<ACCESS_TOKEN>@<public url to master admin portal>/master/api/proxy/configs"
    Copy to Clipboard Toggle word wrap
    • URL의 끝은 /master/api/proxy/configs 이므로 master 가 기본 /admin/api/services.json 과 비교하여 다른 끝점에 구성 을 보유하고 있기 때문입니다.

30.2. 계정 관리

마스터 관리 포털 또는 API 호출을 통해 계정을 관리할 수 있습니다.

30.2.1. 마스터 관리 포털을 통해 계정 관리

마스터 관리 포털을 통해 계정을 관리하려면 다음을 수행해야 합니다.

  1. 마스터 관리 포털에 로그인합니다.
  2. Accounts 페이지로 이동합니다.
  3. 관리할 그룹 또는 조직을 선택합니다.

계정 페이지에서 관리자 계정 가장 또는 계정 일시 중지와 같은 관리 작업을 수행할 수 있습니다. 다음 계정 특성을 관리할 수도 있습니다.

  • 애플리케이션
  • 사용자
  • 초대
  • 그룹 멤버십
  • 조직/그룹 이름

30.2.2. API 호출을 통해 계정 관리

Master Admin API 호출을 통해 계정을 관리할 수 있습니다. 이러한 호출에 대한 자세한 내용은 마스터 관리 포털의 오른쪽 상단에 있는 물음표(?) 아이콘을 클릭한 다음 3scale API 문서 를 선택하여 마스터 API 섹션을 참조하십시오.

마스터 API 섹션

30.3. 멀티 테넌시 하위 도메인 이해

동일한 OpenShift 클러스터 도메인에 여러 계정이 있으므로 개별 계정 이름은 OpenShift 클러스터 도메인 이름 앞에 하위 도메인 이름을 추가합니다. 예를 들어 example.com 도메인이 있는 클러스터에서 user 라는 계정의 경로는 다음과 같이 표시됩니다.

user.example.com
Copy to Clipboard Toggle word wrap

표준 다중 테넌트 배포에는 다음이 포함됩니다.

  • 마스터 관리자
  • MASTER_NAME 매개변수로 정의된 마스터 관리자 포털 경로입니다.

    <MASTER_NAME>.<WILDCARD_DOMAIN>
    Copy to Clipboard Toggle word wrap
  • 계정 관리자
  • TENANT_NAME 매개변수로 정의된 계정 관리자 포털 경로입니다.

    <TENANT_NAME>-admin.<WILDCARD_DOMAIN>
    Copy to Clipboard Toggle word wrap
  • 계정의 개발자 포털 경로입니다.

    <TENANT_NAME>.<WILDCARD_DOMAIN>
    Copy to Clipboard Toggle word wrap
  • 프로덕션 및 스테이징 임베디드 APIcast 게이트웨이의 경로:

    <API_NAME>-<TENANT_NAME>-apicast-staging.<WILDCARD_DOMAIN>
    <API_NAME>-<TENANT_NAME>-apicast-production.<WILDCARD_DOMAIN>
    Copy to Clipboard Toggle word wrap
    This example illustrates the output users and routes of a standard multitenant deployment of 3scale:
    Copy to Clipboard Toggle word wrap
    ----
    --> Deploying template "3scale-project/3scale-api-management" for "amp.yml" to project project
    Copy to Clipboard Toggle word wrap
    3scale API Management
    ---------
    3scale API Management main system
    Copy to Clipboard Toggle word wrap
         Login on https://user-admin.3scale-project.example.com as admin/xXxXyz123
         ...
         * With parameters:
          * ADMIN_PASSWORD=xXxXyz123 # generated
          * ADMIN_USERNAME=admin
          * TENANT_NAME=user
          ...
          * MASTER_NAME=master
          * MASTER_USER=master
          * MASTER_PASSWORD=xXxXyz123 # generated
          ...
    --> Success
        Access your application via route 'user-admin.3scale-project.example.com'
        Access your application via route 'master-admin.3scale-project.example.com'
        Access your application via route 'backend-user.3scale-project.example.com'
        Access your application via route 'user.3scale-project.example.com'
        Access your application via route 'api-user-apicast-staging.3scale-project.example.com'
        Access your application via route 'api-user-apicast-production.3scale-project.example.com'
        Access your application via route 'apicast-wildcard.3scale-project.example.com'
        ...
    ----
    Copy to Clipboard Toggle word wrap

마스터 관리자가 추가한 추가 계정에는 해당 이름을 기반으로 하는 하위 도메인이 할당됩니다.

30.4. 테넌트 계정 삭제

30.4.1. 관리 포털을 통해 계정 삭제

이 절차를 통해 계정이 삭제될 예정이며 15일 후에 삭제됩니다. 이 시간 동안 삭제하도록 예약됩니다.

  • 사용자는 계정에 로그인할 수 없습니다.
  • 계정을 편집할 수 없지만 마스터는 계정을 승인 된 상태로 다시 시작할 수 있습니다.

또한 실제 삭제와 유사하게 테넌트 도메인(관리자 도메인 및 개발자 포털)의 도메인을 사용할 수 없습니다.

사전 요구 사항

프로세스

  1. 계정 목록을 보려면 계정으로 이동합니다.
  2. 삭제할 계정을 클릭합니다.
  3. 계정 이름 옆에 있는 편집을 클릭합니다.
  4. 계정 세부 정보 페이지에서 삭제 아이콘을 클릭합니다.
  5. 삭제를 확인합니다.

30.4.2. 콘솔을 통해 테넌트 삭제

즉시 적용되는 계정을 삭제하려면 콘솔을 통해 이 작업을 수행할 수 있습니다.

  1. 다음 명령을 사용하여 콘솔을 엽니다.

    $ oc rsh -c system-master "$(oc get pods --selector deploymentconfig=system-app -o name)"
    bundle exec rails console
    Copy to Clipboard Toggle word wrap
  2. 다음 행을 사용하여 즉시 삭제합니다.

    tenant = Account.find(PROVIDER_ID)
    tenant.schedule_for_deletion!
    DeleteAccountHierarchyWorker.perform_later(tenant)
    Copy to Clipboard Toggle word wrap

각 라인이 작동하는 방식은 다음과 같습니다.

  • 1행: 계정을 찾아 변수 테넌트에 저장합니다.
  • 2번 행: 삭제할 계정을 예약합니다. 이는 관리 포털을 통해 삭제를 예약하지 않은 경우에만 필요합니다.
  • 3행: 삭제를 위해 계정을 예약했거나 일시 중지된 경우에만 백그라운드 프로세스에서 테넌트를 삭제합니다. 계정이 승인 된 상태인 경우 삭제가 진행되지 않습니다.

30.5. 테넌트 계정 재시작

테넌트 계정을 다시 시작하면 삭제 예약된 계정 복원을 의미합니다. 삭제를 예약한 후 최대 15일까지 테넌트 계정을 다시 시작할 수 있습니다.

계정을 다시 시작한 후 다음을 수행합니다.

  • 이전의 모든 앱이 존재합니다.
  • 모든 과거의 통계가 남아 있습니다.
  • 유효해야 하는 모든 토큰은 다시 유효합니다.
  • 앱이 다시 승인을 시작합니다.

사전 요구 사항

  • 마스터 관리자 계정에 로그인합니다.

프로세스

  1. 계정 목록을 보려면 계정으로 이동합니다.
  2. 삭제할 계정을 클릭합니다.
  3. 계정 세부 정보에서 Resume 을 클릭합니다.
  4. 확인을 클릭하여 계정을 다시 시작합니다.Click OK to confirm you want to resume the account.

VII 부. 분석

API 액세스를 관리하고 최적화하는 3scale API 분석을 구현하면 시간 경과에 따른 사용량 추세와 같은 항목을 추적할 수 있습니다. API 사용 방법을 아는 것은 트래픽을 관리하고, 최대의 프로비저닝, 가장 많은 요청을 API에 보내는 사용자를 식별하는 데 중요한 단계입니다.

3scale은 다음 수준에서 정의할 수 있는 메서드 및 메트릭에 대한 API 분석을 수집합니다.

  • 제품: Hits 는 API로의 트래픽을 추적하는 기본 제공 메트릭입니다. 분석을 캡처할 API에서 추가 메트릭 및 지정 방법을 생성할 수 있습니다.
  • 백엔드: 3scale은 API 백엔드를 사용하여 각 제품에 속하는 것처럼 백엔드의 방법과 지표를 등록합니다. 제품 수준에 정의된 애플리케이션 계획에서 백엔드 수준 지표에 대한 제한 및 가격 규칙을 설정할 수 있습니다.
  • 애플리케이션: 3scale에서 생성된 각 애플리케이션에 대한 분석 보고서를 가져올 수 있습니다.

사전 요구 사항

  • 시작하기 명령을 완료했습니다.
  • 또는 다른 통합 방법과 유사한 흐름을 따릅니다. 사용 가능한 통합 옵션에 대한 자세한 내용은 설명서의 운영 APIcast 장을 참조하십시오.

31.1. 3scale API Management API 메트릭 및 API 사용을 캡처하는 방법

3scale은 API 제품 통계에 대해 무한 확장이 가능한 데이터 리포지토리 역할을 합니다. API에 대한 액세스를 최적으로 관리하는 데 필요한 정보가 있도록 메트릭 및 방법을 사용하여 API 제품 통계를 캡처할 수 있습니다. 예를 들면 다음과 같습니다.

hits/ Cryostats
API 제품에 대한 호출입니다. hits는 기본적으로 모든 API의 메트릭으로 포함됩니다. 조회는 API 제품에 대한 전반적인 호출이거나 API 제품의 개별 메서드로 분할될 수 있습니다.
데이터 전송
API 제품을 통해 업로드 및 다운로드되는 MB/GB의 데이터 양
CPU 시간
API 제품에 대한 호출과 관련된 컴퓨팅 시간(또는 기타 내부 리소스)
반환 결과
반환되는 레코드 또는 데이터 오브젝트 수 수
디스크 스토리지
계정에서 사용 중인 총 디스크 스토리지

API 제품과 관련된 더 많은 메트릭을 추적할 수 있습니다. 3scale은 시간이 지남에 따라 증가할 수 있는 수의 수를 늘릴 수 있는 수의 메트릭 및 방법을 추적할 수 있습니다.

사용할 메트릭을 선택한 후 제품 및 백엔드에 메트릭 추가에 설명된 절차를 사용하여 관리 포털에 등록합니다.

선택한 제품 또는 백엔드에 메트릭 및 방법을 추가할 수 있습니다. 3scale이 플러그인 구성에서 사용하는 친숙한 이름과 시스템 이름을 제공합니다. 메서드 및 메트릭 생성에 대한 자세한 내용은 사용 세부 정보 캡처를 위한 방법 설계 및 메트릭 추가를 참조하십시오.

31.2. API 메트릭을 캡처하도록 3scale API Management 플러그인 구성

추적하려는 메트릭의 이름으로 3scale이 준비되면 해당 메트릭을 보고하도록 플러그인을 구성해야 합니다. 이 작업을 수행하는 정확한 방법은 사용 중인 플러그인 또는 통합 방법에 따라 다릅니다. 기본적으로 플러그인은 Hits, API 트랜잭션, 메트릭만 보고합니다.

사전 요구 사항

  • 제품 및/또는 백엔드에 대한 메트릭이 이미 구성되어 있어야 합니다.

프로세스

  1. 들어오는 API 호출에 의해 결정된 대로 적절한 메트릭/메서드 이름을 플러그인에 전달합니다.

    metric/method 값과 필요한 증가는 플러그인이 노출하는 승인 및/또는 보고서 메서드의 인수입니다.

  2. 메트릭에서 시스템 이름 방법을 사용하여 특정 API 방법에 대한 트래픽을 보고합니다.

    이렇게 하면 보고된 방법과 Hits 메트릭에 대한 카운터가 자동으로 증가합니다.

  3. 관리 포털의 계정 설정 > 통합 → 3scale API 문서 장에서 3scale Service Management API 를 사용하여 트래픽을 보고합니다.

다른 엔드포인트에 대한 자세한 내용은 계정 설정 > 통합 → 3scale API 문서.에서 제공되는 3scale API 문서를 참조하십시오.

31.3. 3scale API Management API 백엔드에 대한 분석 보기

백엔드로 구성된 지정된 API의 트래픽 데이터를 볼 수 있습니다. 트래픽 페이지에 끝점에 대한 조회가 표시됩니다.

사전 요구 사항

프로세스

  1. 관리 포털 대시보드에서 [ your_backend_name] > Analytics로 이동합니다.
  2. 보고서의 시간 범위를 선택합니다. 지난 24 시간, 7 일, 30 일, 12 개월을 표시하거나 기간을 표시하도록 선택할 수 있습니다.
  3. 선택 사항: 메서드 또는 다른 최상위 수준 메트릭 중 Hits 이외의 분석을 선택합니다.

    • 차트에 결과가 표시됩니다. 보고할 트래픽이 없는 경우 다음 메시지가 표시됩니다. 선택한 기간에 사용 가능한 데이터가 없습니다.
  4. CSV 다운로드 링크를 클릭하여 CSV 파일로 데이터를 다운로드합니다.

API 제품으로 트래픽을 전송하고 API 분석 대시보드에 등록할 수 있도록 API와 3scale 간 연결을 설정합니다.

사전 요구 사항

  • 3scale 개발자 계정.
  • API 인증 정보가 있는 3scale 애플리케이션.

프로세스

  1. Audience > Applications > Listing 으로 이동하여 기존 애플리케이션 목록을 확인합니다.
  2. 이름을 클릭하여 애플리케이션을 선택합니다.
  3. 선택한 애플리케이션의 API 인증 정보를 찾습니다. 인증 정보는 선택한 인증 유형에 따라 다르며 사용자 키(API 키), 애플리케이션 ID 및 애플리케이션 키 또는 클라이언트 ID 및 클라이언트 시크릿일 수 있습니다.

    사용 가능한 인증 모드에 대한 자세한 내용은 인증 패턴 을 참조하십시오.

    그림 31.1. API 인증 정보

    API 인증 정보
  4. 이러한 키를 사용하여 일반적인 방식으로 API를 호출합니다. 예를 들어 명령줄에서 cURL 을 사용하거나 GET 메서드를 사용하는 API 끝점의 경우 브라우저에서 다음을 수행합니다. 정확한 호출은 API 제품의 메서드 구조에 따라 달라집니다. 이러한 호출의 트래픽은 API 제품의 분석 섹션에 나타납니다.

다음 단계

기본적으로 사용 통계는 관리 포털과 개발자 포털을 통해 애플리케이션을 생성한 개발자에게 API 공급자에 표시됩니다. 각 개발자는 자체 애플리케이션에 대한 사용량 통계만 볼 수 있습니다. 개발자 포털에서 분석 보기를 숨기고 사용자를 추가로 제어할 수 있습니다. 개발자 포털 사용자 지정에 대한 자세한 내용은 개발자 포털 생성 을 참조하십시오.

분석 섹션의 사용 그래프 외에도 Analytics API를 사용하여 분석 데이터에 액세스할 수 있습니다. 3scale Analytics API는 API 제품에 대한 모든 분석 데이터를 XML 또는 JSON 형식으로 추출하는 유연한 방법입니다.

31.5. 3scale API Management API에 대한 분석이 누락된 문제 해결 기술

[ your_product_name] > Analytics > Traffic 의 사용 차트에 트래픽이 표시되지 않는 경우 다음 검사를 수행합니다.

  • 승인/보고 호출이 올바르게 응답됩니까?

    모든 플러그인은 사전 결정된 응답 코드가 있는 3scale Service Management API를 호출합니다. 유효한 키에 대한 승인 호출은 HTTP 코드 200 을 사용하여 응답을 반환해야 합니다. 보고서 호출은 코드 202 로 응답해야 합니다.

  • 통합 오류 콘솔에 오류가 있습니까?

    3scale에서 감지한 통합 오류 로그는 [your_product_name] > Analytics > Integration Errors 에서 확인할 수 있습니다.

  • 올바른 메트릭 및 메서드 이름이 사용됩니까?

    오류에 대한 가장 일반적인 이유는 보고서 호출에 전달된 메서드 및 메트릭 이름이 관리 포털의 API 설정에서 생성된 메서드와 일치하지 않기 때문입니다. 각 metric/method에 올바른 시스템 이름을 사용하고 있는지 확인합니다.

  • 매핑 규칙이 메트릭에 올바르게 매핑되어 있습니까?

    매핑 규칙이 메트릭에 올바르게 매핑되지 않으면 분석에서 데이터가 표시되지 않을 수 있습니다. API 제품 및 API 백엔드 모두에 매핑 규칙이 메트릭에 올바르게 매핑되었는지 확인합니다.

    • 제품: 관리 포털 대시보드에서 [ your_product_name] > Integration > Methods & Metrics 로 이동합니다.
    • 백엔드: 관리 포털 대시보드에서 [ your_backend_name] > Methods & Metrics 로 이동합니다.

32장. 기본 제공 기능 이외의 3scale API Management API 분석 내보내기

기본 제공 3scale 분석 기능을 확장하여 기능에 기본적으로 제공되지 않는 정보를 검색할 수 있는 스크립트를 생성합니다.

계정 관리 및 분석 API(Enterprise만 해당)를 사용하면 원하는 형식으로 필요한 정보를 검색하는 스크립트를 생성할 수 있습니다. 여기에 설명된 사용 사례는 자체 시나리오에서 3scale에서 필요한 데이터를 가져오는 데 사용할 수 있습니다.

사용자 정의 스크립트의 이유

3scale은 API 대시보드에서 사용할 수 있는 기능을 지속적으로 개선합니다. 그러나 개발 계획보다 앞서 있을 수 있으며 아직 지원되지 않는 매우 구체적인 요구 사항이 있을 수 있습니다.

API 관리 요구 사항을 충족하기 위해 3scale 관리 포털은 모든 데이터에 액세스하는 데 필요한 툴을 제공합니다. 스크립트를 작성하는 데 리소스가 필요하지만 사용자 지정 스크립트는 다양한 사용 사례를 구현할 수 있는 총 유연성과 제어를 제공합니다.

고객은 매주 수천 명의 새로운 개발자를 온보딩하는 프로세스를 진행했습니다. 3scale은 주요 프로비저닝, 등록 워크플로 및 이메일 통신과 같은 자동 요구 사항을 제공하므로 이 고객은 온보딩의 일부 측면을 해결할 수 있습니다. 그러나 3scale으로 수행할 수 없는 작업이 있었기 때문에 매우 중요했습니다.

고객이 많은 사용자를 온보딩했기 때문에 이 회사는 운영 및 마케팅 팀이 새로운 개발자와 보다 효과적으로 상호 작용할 수 있도록 API와의 참여를 기반으로 새로운 개발자를 분류할 수 있는 직접적인 방법이 필요했습니다. 적어도 필요한 수준의 세부 정보에서는 이러한 기능을 3scale에서 제공하는 기본 제공 분석 툴에서 아직 사용할 수 없었습니다. 그러나 시스템에서 모든 데이터를 사용할 수 있었기 때문에 3scale 계정 및 분석 API를 사용하여 데이터를 추출할 수 있었습니다.

예: 고객 요구 사항

지난 10일 동안 무료 평가판 계획에 등록한 신규 개발자의 수를 알고 싶습니다.

먼저, 얼마나 많은 개발자가 가입했지만 API를 사용하지 않았는지 알고 싶습니다.

두 번째, API를 사용한 개발자를 두 그룹으로 분할하려고 했습니다.

  • 일정 기간 동안 사용한 개발자 - 10일의 처음 절반으로 말한 다음 API 사용을 중지했습니다. 이 개발자는 이를 시도했지만 비활성화되었습니다.
  • API를 일관되게 사용하고 있는 개발자입니다. 이를 위해 성장률 (또는 감소)을 알고 싶습니다.

이 정보는 3scale 기본 제공 분석에서 확인할 수 있습니다. 문제는 집계를 표시할 수 있는 보기가 없으므로 전체 환경을 매우 번거롭게 만들 수 있다는 것입니다.

32.2. 사용자 정의 절차에서 3scale API Management 애플리케이션 분석 추출

애플리케이션 분석을 추출하려면 먼저 ActiveDocs로 작업합니다. 3scale ActiveDocs는 계정 설정 > 통합 > 3scale API 문서 장에서 관리 포털에서 사용할 수 있습니다. 3scale에는 모든 API를 ActiveDocs로 사용할 수 있으므로 브라우저에서 시도할 수 있습니다. 이를 통해 요구 사항에 가장 적합한 요청을 찾고 요청(Curl과 유사)을 얻고 응답을 확인할 수 있습니다. 다음 그림은 ActiveDocs 예제를 제공합니다.

Cryostat 분석

스크립트가 분석을 추출하는 모든 애플리케이션을 가져오는 API 요청의 ActiveDocs입니다.

  • ActiveDocs를 사용하여 조사를 수행한 후 원하는 스크립팅 언어로 요청을 지정합니다. 이 예제에서는 Ruby를 사용합니다.
  • 필요한 대로 정확히 수행하는 스크립트가 있을 때까지 반복합니다. 확장 분석의 예에서는 스크립트를 gist로 사용할 수 있습니다. 계정에서 이를 시도할 수 있습니다.

ActiveDocs를 사용하면 API가 수행할 수 있는 작업을 빠르게 파악할 수 있습니다. 그런 다음 수행하려는 작업에 필요한 3 ~ 4 개의 요청을 찾고 스크립트를 함께 배치하는 것이 중요합니다.

다음 절차에서는 고객이 원하는 사용자 정의 분석을 달성한 단계를 보여줍니다.

프로세스

  1. 전체 애플리케이션 목록을 검색합니다. 이 작업에는 페이지 매김이 필요합니다.

    def api_call_applications_list(domain, provider_key)
      done = false
      res = Array.new
      page = 1
    
          while !done
        url = "https://#{domain}/admin/api/applications.xml?provider_key=#{provider_key}&page=#{page}&per_page=100"
        page += 1
        response = RestClient.get url
        raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
        document = Nokogiri::XML(response.to_str)    done = document.xpath("applications/@current_page").text == document.xpath("applications/@total_pages").text
        document.xpath("//application").each do |item|
          app = Hash.new
          app["created_at"] = DateTime.parse(item.xpath("created_at").text)
          app["plan_name"] = item.xpath("plan/name").text
          app["service_id"] = item.xpath("plan/service_id").text
          app["account_id"] = item.xpath("user_account_id").text
          app["id"] = item.xpath("id").text
          res << app
        end
      end
      return res
    end
    Copy to Clipboard Toggle word wrap
  2. 기준을 충족하지 않는 애플리케이션을 필터링합니다. 즉, 계획이 "평가"되어야 하며 10일 이상 있어야 합니다.

    def filter_applications(domain, provider_key, plan_name, num_of_days)
      res = api_call_applications_list(domain, provider_key)
      res.each do |item|
        res.delete(item) if item["plan_name"] != plan_name
        res.delete(item) if item["created_at"] > (DateTime.now - num_of_days)
      end
      return res
    end
    Copy to Clipboard Toggle word wrap
  3. 기준을 충족하는 각 애플리케이션에 대해 지난 10일 동안 애플리케이션의 적중 횟수인 사용량을 얻습니다.

    def api_call_application_usage(domain, provider_key, application_id, metric, from, to, granularity)
      url = "https://#{domain}/stats/applications/#{application_id}/usage.xml?provider_key=#{provider_key}&metric_name=#{metric}&since=#{from}&until=#{to}&granularity=#{granularity}"
      response = RestClient.get url
      raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
      document = Nokogiri::XML(response.to_str)
      return document.xpath("//usage/data/values").text.split(",")
    end
    Copy to Clipboard Toggle word wrap
  4. 개발자의 정보가 계정 오브젝트에 저장되므로 애플리케이션을 계정에 상호 참조하십시오.

    def api_call_account_read(domain, provider_key, account_id)
      url = "https://#{domain}/admin/api/accounts/#{account_id}.xml?provider_key=#{provider_key}"
      response = RestClient.get url
      raise Exception.new("Wrong response code (#{response.code}) in request #{url}") if response.code!=200
      document = Nokogiri::XML(response.to_str)
      account = Hash.new
      account["email"] = document.xpath("//users/user/email").text
      account["name"] = document.xpath("//users/user/first_name").text + " " + document.xpath("//users/user/last_name").text
      return account
    end
    Copy to Clipboard Toggle word wrap
  5. 모든 것을 결합하여 스크립트를 완료합니다. 3scale의 기본 제공 분석에서는 아직 제공되지 않은 정보를 가져오는 스크립트가 있습니다. 전체 스크립트를 gist로 가져올 수도 있습니다.

기능 향상을 보장하는 지원 및 작업이 필요한 계정을 확인하려면 애플리케이션 트래픽에 대한 시각적 정보를 확인하십시오. API를 사용하는 각 애플리케이션에는 3scale 시스템에 트래픽 추적이 있으며, 이는 관리 포털에서 API에서 복구할 수 있습니다.

전제 조건

  • 3scale 개발자 계정
  • API 인증 정보가 있는 3scale 애플리케이션

프로세스

  1. 분석을 볼 애플리케이션으로 이동합니다.

    Audience > Accounts > Listing 또는 Audience > Applications > Listing 에서 애플리케이션을 찾을 수 있습니다. 또는 애플리케이션 찾기 튜토리얼에 설명된 단계에 따라 애플리케이션을 검색할 수 있습니다.

  2. 애플리케이션을 찾으면 다음 이미지에 표시된 대로 애플리케이션에 대한 정보가 포함된 개요 페이지가 표시됩니다.

    애플리케이션 표시
    Expand
    표 33.1. 이미지에서 레이블이 지정된 항목은 다음 정보에 해당합니다.
    숫자애플리케이션 정보

    1

    개발자가 제공한 애플리케이션의 이름

    2

    애플리케이션에 대해 캡처된 메타 데이터(고급 섹션에서 캡처할 데이터를 설정하는 방법)

    3

    애플리케이션 상태 - 실행 중이거나 일시 중단됩니까?

    4

    애플리케이션에 있는 현재 API 식별자, 키 및 인증서입니다. 보기는 API를 3scale에 통합하기 위해 사용하는 인증 방법에 따라 다릅니다.

    5

    애플리케이션에 대한 트래픽 통계 요약

    6

    애플리케이션이 적용되는 애플리케이션 계획 및 속도 제한에 대한 정보입니다.

  3. 애플리케이션 이름 위에 있는 분석 링크를 클릭합니다. 애플리케이션에 대한 사용 차트가 표시됩니다. 메트릭, 메서드 및 시간 범위를 제어하면 애플리케이션에 대한 다양한 유형의 데이터를 확인할 수 있습니다.

34장. 주요 애플리케이션 분석 그래프

Top Applications 분석 그래프는 개발자에게 API 성능을 최적화하고 사용 패턴에 대한 통찰력을 얻는 도구를 제공합니다. 개발자는 고성능 애플리케이션을 식별하고, 실시간 지표를 이해하고, 데이터 중심 결정을 통해 전체 API 환경을 개선할 수 있습니다.

제품 > [ your_product_name] > Analytics > Top Applications 의 상위 애플리케이션 분석 그래프는 3scale 관리 포털 계정에 구성된 시간대의 기간 동안 데이터를 표시합니다. 주요 애플리케이션은 고정된 기간을 기반으로 검색됩니다.

  • 지난 24 시간
  • 지난 7일
  • 지난 30일
  • 날짜 범위(예: 09/27/2023 - 10/25/2023까지)

예를 들어 05/17/2023 을 사용하는 경우 결과 그래프에는 01/01/2023~12/31/2023 의 사용량이 표시됩니다. 이는 사용자가 선택한 일정 기간과 표시된 그래프에 가장 가까운 일정 범위입니다.

상위 애플리케이션 분석을 확인할 때 다음 두 가지 사항을 고려해야 합니다.

  • 상위 애플리케이션은 고정된 일정 기간(일/주/월/년)에 따라 검색됩니다. 기간은 차트 아래에 표시됩니다.

    참고: 자정 04/30/2023 및 자정 05/31/2023은 다음을 의미합니다. 2023/05/01 00:00:00 부터 2023/06/01 00:00:00 에 포함되며 이는 2023/05/31 23:59:59 까지 포함합니다.

  • 통계에 표시된 애플리케이션의 실제 사용은 일정 기간이 아닌 사용자가 선택한 기간을 기반으로 합니다.

따라서 일정 기간에 사용량이 높지만 사용자가 선택한 실제 기간에는 0 개의 사용량이 있으므로 애플리케이션이 맨 위 애플리케이션 뷰에 표시되는 상황이 있을 수 있습니다.

예제

  1. 사용자는 일정을 사용하여 날짜 범위를 입력합니다: 10/25/2023 ~ 10/27/2022.
  2. 해당 날짜 범위에 따라 사용자가 선택한 날짜 범위와 가능한 한 밀접하게 일치하는 마침표가 선택됩니다. 이는 단일 세분성(예: 1 calendar day, 1 calendar month)을 포함해야 합니다.
  3. 데이터 저장소는 10/25/2023~10/27/2023 의 상위 애플리케이션에 대해 쿼리됩니다.
  4. 반환된 상위 애플리케이션 목록의 경우 사용량이 입력된 사용자의 원래 날짜 범위인 10/25/2023~10/27/2023을 사용하여 표시됩니다.

35장. API에 대한 3scale API Management 응답 코드 로그 설정 및 평가

클라이언트가 API를 사용하는 방법을 확인하고 서버가 예상대로 실행되는지 실시간으로 확인하려면 3scale로 응답 코드 로그를 설정하고 사용합니다.

프로세스

APIcast 게이트웨이를 배포했습니다.

apiVersion: apps.3scale.net/v1alpha1
kind: APIcast
metadata:
  name: example-apicast
spec:
  ...
  responseCodesIncluded: true
Copy to Clipboard Toggle word wrap

예제

활성화하면 APIcast 게이트웨이는 권한 있는 호출을 위해 업스트림 서비스에서 반환된 API 응답의 HTTP 상태 코드를 캡처하고 Service Management API( authrep 호출)로 보냅니다. 예제:

https://su1.3scale.net/transactions/authrep.xml?service_token={SERVICE_TOKEN}&service_id={SERVICE_ID}&user_key={USER_KEY}&usage%5Bhits%5D=1&log%5Bcode%5D=200"
Copy to Clipboard Toggle word wrap

이 예에서는log[code]=200 이 전송되므로 API가 200 상태 코드로 응답했습니다.

검증

통합을 확인하려면 유효한 3scale 인증 정보를 사용하여 API 제품을 호출한 다음 호출이 분석 > 사용 페이지에서 올바르게 보고되었는지 확인합니다.

참고
  • 응답 코드 추적은 모든 응답의 정확한 개수가 아닙니다.
  • 이 뷰의 값은 일정 기간 동안 추세에 대한 시각적 표현을 제공하는 것입니다.
  • 응답 코드 추적 및 3scale 인증 캐싱 모드: None 이 지원되는 조합이 아닙니다.
사용 화면

지금까지 잘 진행 중인 경우 Analytics >Response 코드 페이지로 이동합니다. 응답이 2xx, 4xx 또는 5xx인지 여부에 따라 최신 트래픽의 그래프를 색상으로 나눌 수 있습니다.

응답 코드 화면

그래프 툴을 사용하면 응답 코드의 기록을 볼 수 있습니다. 또한 다양한 기간 및 다양한 단위 수준에 대해 응답 코드 통계를 확인할 수도 있습니다. 시간 선택 표시줄을 클릭하고 요구 사항에 맞는 기간 및 세분성을 정의합니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동