Manajemen API

5 menit

Jadi apa masalah yang saya alami yang membuat saya ingin mencari solusi manajemen API? Anda kemungkinan besar memiliki tantangan berikut:

Penskalaan, API atau beberapa API Anda digunakan oleh banyak klien di berbagai wilayah di dunia dan Anda perlu memastikan bahwa API tersebut tersedia dan responsif.
Keamanan, Anda perlu memastikan bahwa API Anda aman dan hanya klien yang berwenang yang dapat mengaksesnya.
Manajemen kesalahan, Anda perlu memastikan bahwa API Anda dapat menangani kesalahan dengan anggun.
Pemantauan, Anda perlu memantau API Anda untuk memastikan bahwa API berfungsi seperti yang diharapkan.
Ketahanan, Anda perlu memastikan bahwa API Anda tangguh dan dapat menangani kegagalan dengan anggun.

Untuk setiap tantangan ini, Anda dapat memilih solusi titik, tetapi itu bisa menjadi tantangan untuk dikelola. Pertimbangkan juga bahwa API Anda dapat dibangun dalam tumpukan teknologi yang berbeda, yang berarti solusi untuk tantangan di atas dapat berarti Anda memerlukan solusi yang berbeda untuk setiap API. Jika Anda mengalami semua tantangan ini, maka Anda harus mempertimbangkan solusi manajemen API terpusat seperti Azure API Management.

Mari kita selaraskan lebih dalam beberapa tantangan dan lihat bagaimana solusi manajemen API terpusat seperti Azure API Management dapat membantu Anda mengatasinya.

Infrastruktur sebagai kode, IaC

Ini sangat baik-baik saja dengan membuat sumber daya Azure Anda menggunakan portal Azure, tetapi saat infrastruktur Anda tumbuh, menjadi lebih sulit untuk dikelola. Salah satu masalah yang Anda hadapi adalah Anda tidak dapat dengan mudah mereplikasi infrastruktur Anda di lingkungan lain.

Juga sulit untuk melacak semua perubahan yang dilakukan pada infrastruktur Anda. Situasi ini adalah di mana Infrastruktur sebagai Kode (IaC) masuk. IaC adalah praktik mengelola infrastruktur Anda menggunakan kode. Untuk menerapkan IaC di Azure, Anda memiliki beberapa opsi, salah satunya Bicep. Bicep adalah Domain Specific Language (DSL) untuk menyebarkan sumber daya Azure secara deklaratif. Ini adalah cara yang bagus untuk mengelola sumber daya cloud Anda. Berikut adalah contoh sederhana seperti apa Bicep:

param location string = 'eastus'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: 'mystorageaccount'
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

Dalam contoh sebelumnya, kami menentukan akun penyimpanan menggunakan Bicep. Kami menentukan lokasi akun penyimpanan, jenis akun penyimpanan, dan SKU (unit penyimpanan stok). Lokasi adalah parameter yang dapat kita lewati ketika kita menyebarkan file Bicep. Untuk menyebarkan file yang disajikan, kami akan menggunakan Azure CLI seperti itu:

az deployment group create --resource-group myResourceGroup --template-file main.bicep

Perintah sebelumnya menyebarkan akun penyimpanan ke grup myResourceGroup sumber daya dan menggunakan file main.bicep Bicep untuk membuat sumber daya dalam file.

Menangani beban melalui load balancer

Menambahkan konstruksi penyeimbangan beban adalah jawaban ketika masalahnya adalah API Anda kewalahan oleh permintaan. Load balancer dapat membantu Anda mendistribusikan beban di beberapa instans API Anda.

Dalam layanan Azure API Management, penyeimbangan beban diimplementasikan oleh Anda mendefinisikan konsep yang disebut backend. Idenya adalah Anda menyiapkan banyak backend yang sesuai dengan titik akhir API Anda dan kemudian Anda membuat load balancer yang mendistribusikan beban di seluruh backend ini. Berikut tampilan arsitekturnya:

Cuplikan layar penyeimbang beban.

Apa yang terjadi dalam arsitektur sebelumnya adalah:

Klien mengirimkan permintaan ke instans API Management.
Permintaan diautentikasi dan diotorisasi.
Permintaan kemudian dikirim ke load balancer.
Load balancer mendistribusikan permintaan ke salah satu backend (API Azure OpenAI yang dipilih ditunjukkan dalam huruf tebal).

Backend memproses permintaan dan mengirim respons kembali ke klien.

Menentukan load balancer

Untuk menyiapkan load balancer di Azure API Management, Anda perlu melakukan bagian berikut:

Backend, sebanyak mungkin backend yang Anda inginkan untuk mendistribusikan beban.
Load balancer, load balancer yang berisi backend yang ingin Anda distribusikan bebannya.
Kebijakan yang mengarahkan panggilan masuk ke penyeimbang beban.

Membuat backend

Untuk membuat backend di Azure API Management, Anda perlu menentukan entitas backend. Berikut adalah cara Anda dapat menentukan backend di Bicep:

resource backend2 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  parent: apimService
  name: 'backend2'
  properties: {
    url: '${openai2Endpoint}openai'
    protocol: 'http'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'P1D'
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'
        }
      ]
    }
}

Dalam kode Bicep sebelumnya, backend didefinisikan sesuai dengan URL titik akhir API, perhatikan juga nama backend2 ini adalah sesuatu yang dapat kita gunakan nanti. Untuk setiap backend yang Anda miliki, Anda harus mengodekannya seperti kode bicep sebelumnya.

Catatan

Ingatlah bahwa Anda dapat memiliki beberapa backend, sehingga Anda dapat menentukan backend sebanyak yang Anda inginkan.

Buat kumpulan ujung belakang

Selanjutnya, kita ingin membuat kumpulan backend yang mengatur backend mana yang ingin kita distribusikan bebannya. Kita dapat mengodekan kumpulan backend ini sebagai entitas backend seperti:

resource loadBalancing 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  parent: apimService
  name: 'LoadBalancer'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.ApiManagement/service/${apimService.name}/backends/${backend1.id}'
        }
        {
          id: '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.ApiManagement/service/${apimService.name}/backends/${backend2.id}'
        }
      ]
    }
  }
}

Backend yang kita buat sebelumnya, backend2, direferensikan bersama dengan backend backend1lain , yang terakhir kita hilangkan untuk brevity.

Kita juga dapat menyertakan priority properti dan weight , untuk setiap item dalam services daftar untuk menentukan bagaimana load balancer mendistribusikan beban. Berikut adalah cara Anda dapat mengatur prioritas dan berat untuk setiap backend:

services: [
    {
      id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
      priority: 1
      weight: 3
    }
    {
      id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
      priority: 1
      weight: 1
    }
  ]

Dalam contoh sebelumnya, load balancer mendistribusikan beban hingga backend-1 tiga kali lebih banyak dari backend-2.

Panggilan masuk langsung

Terakhir, kita perlu mengarahkan panggilan masuk ke backend penyeimbangan beban ini. Instruksi arah dibuat entitas API berikut:

resource api1 'Microsoft.ApiManagement/service/apis@2020-06-01-preview' = {
  parent: apimService
  name: apiName
  properties: {
    displayName: apiName
    apiType: 'http'
    path: apiSuffix
    format: 'openapi+json-link'
    value: 'https://raw.githubusercontent.com/Azure/azure-rest-api-specs/main/specification/cognitiveservices/data-plane/AzureOpenAI/inference/preview/2024-03-01-preview/inference.json'
    subscriptionKeyParameterNames: {
      header: 'api-key'
    }
    
}

Mengonfigurasi kebijakan

Sekarang, akhirnya kita dapat mengatur kebijakan pada API yang dijelaskan sebelumnya dan mengarahkan panggilan masuk ke load balancer:

// policy.xml
<policies>
  <inbound>
    <base />
    <set-backend-service id="apim-generated-policy" backend-id="{0}" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

var headerPolicyXml = format(loadTextContent('./policy.xml'), loadBalancing.name, 5000)

// Create a policy for the API, using the headerPolicyXml variable
resource apiPolicy 'Microsoft.ApiManagement/service/apis/policies@2020-06-01-preview' = {
  parent: api1
  name: 'policy'
  properties: {
    format: 'rawxml'
    value: headerPolicyXml
  }
}

Apa yang kami lakukan adalah membuat kebijakan yang mengarahkan panggilan masuk ke load balancer. Kebijakan set-backend-service ini digunakan untuk mengarahkan panggilan masuk ke load balancer. Properti backend-id diatur ke nama load balancer yang kita buat sebelumnya.

Dengan semua bagian yang bergerak ini, instans API Management Anda sekarang diseimbangkan bebannya. Anda sekarang dapat menskalakan API Anda dengan menambahkan lebih banyak backend ke load balancer.

Pemutus sirkuit

Pemutus sirkuit adalah sesuatu yang Anda gunakan ketika Anda ingin melindungi API Anda agar tidak kewalahan oleh permintaan. Cara kerjanya adalah Anda menentukan sekumpulan aturan yang saat terpenuhi, pemutus arus memicu dan berhenti mengirim permintaan ke backend. Di Azure API Management, Anda dapat menentukan pemutus sirkuit dengan menyiapkan backend dan menentukan aturan pemutus sirkuit. Berikut adalah cara Anda dapat melakukannya:

resource backend2 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
      parent: apimService
      name: 'backend2'
      properties: {
        url: '${openai2Endpoint}openai'
        protocol: 'http'
        circuitBreaker: {
          rules: [
            {
              failureCondition: {
                count: 3
                errorReasons: [
                  'Server errors'
                ]
                interval: 'P1D'
                statusCodeRanges: [
                  {
                    min: 500
                    max: 599
                  }
                ]
              }
              name: 'myBreakerRule'
              tripDuration: 'PT1H'
            }
          ]
        }
       }
     }

Dalam definisi backend sebelumnya, ada properti failureCondition yang menentukan kapan pemutus sirkuit harus melakukan perjalanan. Dalam hal ini, pemutus sirkuit melakukan perjalanan jika ada tiga kesalahan server dalam sehari. Properti tripDuration menentukan berapa lama pemutus sirkuit harus tetap terbuka sebelum ditutup lagi. Adalah praktik yang baik untuk menentukan pemutus sirkuit untuk setiap backend yang Anda miliki di instans API Management Anda.

Identitas terkelola

Masalah lain yang ingin kita gulung adalah keamanan. Anda ingin memastikan bahwa API Anda aman dan hanya klien yang berwenang yang dapat mengaksesnya. Cara untuk mengamankan API Anda adalah dengan menggunakan identitas terkelola. Identitas terkelola adalah cara untuk mengautentikasi API Anda ke layanan Azure lainnya. Di Azure API Management, Anda perlu menerapkan identitas terkelola di beberapa tempat yaitu:

Tingkat instans APIM, Anda dapat mengaktifkan identitas terkelola di instans APIM dengan mengatur identity properti menjadi SystemAssigned seperti berikut:

resource apimService 'Microsoft.ApiManagement/service@2023-09-01-preview' = {
    name: name
    location: location
    tags: union(tags, { 'azd-service-name': name })
    sku: {
    name: sku
    capacity: (sku == 'Consumption') ? 0 : ((sku == 'Developer') ? 1 : skuCount)
    }
    properties: {
        publisherEmail: publisherEmail
        publisherName: publisherName
    // Custom properties are not supported for Consumption SKU
    }
    identity: {
        type: 'SystemAssigned'
    }
}

Tindakan ini menghasilkan identitas terkelola untuk instans APIM yang dapat kita gunakan nanti instans APIM kita, misalnya, instans Azure OpenAI.

Tingkat API, untuk instans API, Anda dapat mengaitkannya dengan kebijakan. Dalam kebijakan tersebut, Anda dapat menambahkan instruksi yang diperlukan agar identitas terkelola berfungsi:

<policies>
  <inbound>
    <base />
    <authentication-managed-identity resource="https://cognitiveservices.azure.com" output-token-variable-name="managed-id-access-token" ignore-error="false" /> 

    <set-header name="Authorization" exists-action="override"> 
      <value>@("Bearer " + (string)context.Variables["managed-id-access-token"])</value> 
  </set-header> 
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Lihat panggilan sebelumnya ke authentication-managed-identity dan set-header instruksi ini memastikan bahwa identitas terkelola diterapkan ke API.

Tingkat backend, akhirnya, jika backend Anda mengarah ke instans Azure OpenAI. Kita perlu menghubungkan instans APIM kita dengan instans Azure OpenAI. Untuk membuat koneksi ini, berikut adalah instruksi Bicep:
```
resource role 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, resourceGroup().id, principalId, roleDefinitionId)
  properties: {
    principalId: principalId
    principalType: "ServicePrincipal"
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
  }
}
```
Ide dengan instruksi Bicep di atas adalah membuat penetapan peran antara instans APIM dan instans Azure OpenAI. Dalam hal ini:
- principalId adalah ID identitas dari instans APIM,
- roleDefinitionId adalah pengguna tertentu, dalam hal ini adalah pengguna bernama "Pengguna Cognitive Services", pengguna yang memiliki akses ke instans Azure OpenAI.
- name, properti ini memastikan bahwa penetapan peran diterapkan ke cakupan yang benar, yang dalam hal ini adalah langganan dan grup sumber daya tertentu. (harus menjadi grup sumber daya yang sama dengan instans Azure OpenAI)

Apa salah satu tantangan utama yang mungkin membuat Anda mencari solusi manajemen API?

Mengurangi jumlah titik akhir API menjadi satu titik akhir.

Penskalaan, memastikan API Anda tersedia dan responsif terhadap banyak klien di berbagai wilayah.

Menghilangkan kebutuhan untuk memantau performa API.

Apa itu Infrastruktur sebagai Kode (IaC) yang digunakan untuk mengelola sumber daya Azure?

Mengelola infrastruktur Anda menggunakan kode untuk mereplikasi dan melacak perubahan dengan mudah.

Membuat sumber daya Azure secara manual melalui portal Azure.

Memastikan bahwa hanya klien yang berwenang yang dapat mengakses API Anda.

Apa tujuan pemutus sirkuit dalam manajemen API?

Untuk memantau performa API dan menghasilkan laporan penggunaan.

Cegah kegagalan berulang dengan memblokir permintaan untuk sementara waktu ke backend yang gagal.

Nonaktifkan layanan backend secara permanen saat terjadi kesalahan.

Anda harus menjawab semua pertanyaan sebelum memeriksa pekerjaan Anda.

Saran dan Komentar

Apakah halaman ini membantu?

Manajemen API

Uji pengetahuan Anda

Saran dan Komentar