การจัดการ API

ดังนั้น สิ่งที่เป็นปัญหาที่ฉันมีที่ทําให้ฉันต้องการค้นหาโซลูชันการจัดการ API? คุณน่าจะมีความท้าทายดังต่อไปนี้:

• การปรับมาตราส่วนAPI หรือ API ของคุณถูกใช้โดยไคลเอ็นต์จํานวนมากในภูมิภาคต่างๆ ของโลก และคุณจําเป็นต้องตรวจสอบให้แน่ใจว่ามีให้บริการและตอบสนอง
• Securityคุณจําเป็นต้องตรวจสอบให้แน่ใจว่า API ของคุณมีความปลอดภัยและไคลเอ็นต์ที่ได้รับอนุญาตเท่านั้นที่สามารถเข้าถึงได้
• การจัดการข้อผิดพลาดคุณจําเป็นต้องตรวจสอบให้แน่ใจว่า API ของคุณสามารถจัดการข้อผิดพลาดได้อย่างนุ่มนวล
• การตรวจสอบคุณจําเป็นต้องตรวจสอบ API ของคุณเพื่อให้แน่ใจว่าสามารถทํางานได้ตามที่คาดไว้
• ความยืดหยุ่น คุณจําเป็นต้องตรวจสอบให้แน่ใจว่า API ของคุณมีความยืดหยุ่นและสามารถจัดการความล้มเหลวได้อย่างนุ่มนวล

สําหรับแต่ละความท้าทายเหล่านี้ คุณสามารถเลือกใช้โซลูชันจุด แต่นั่นอาจเป็นเรื่องท้าทายในการจัดการ พิจารณาว่า API ของคุณสามารถสร้างในกองซ้อนด้านเทคนิคที่แตกต่างกันซึ่งหมายความว่าโซลูชันดังกล่าวข้างต้นอาจหมายถึงคุณจําเป็นต้องมีโซลูชันที่แตกต่างกันสําหรับแต่ละ API หากคุณกําลังเผชิญกับความท้าทายเหล่านี้ทั้งหมด คุณควรพิจารณาโซลูชันการจัดการ API แบบรวมศูนย์ เช่น การจัดการ API ของ Azure

ลองเจาะลึกลงไปในความท้าทายบางอย่างและดูว่าโซลูชันการจัดการ API แบบรวมศูนย์เช่น Azure API Management สามารถช่วยคุณแก้ปัญหาเหล่านั้นได้อย่างไร

โครงสร้างพื้นฐานเป็นโค้ด IaC

เป็นเรื่องที่ดีโดยการสร้างทรัพยากร Azure ของคุณโดยใช้พอร์ทัล Azure แต่เมื่อโครงสร้างพื้นฐานของคุณเติบโต ขึ้น การจัดการจะยากขึ้น ปัญหาหนึ่งที่คุณเผชิญคือคุณไม่สามารถทําซ้ําโครงสร้างพื้นฐานของคุณในสภาพแวดล้อมอื่นได้อย่างง่ายดาย

การติดตามการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับโครงสร้างพื้นฐานของคุณยังเป็นเรื่องยาก สถานการณ์นี้คือที่ซึ่งโครงสร้างพื้นฐานเป็นโค้ด (IaC) เข้ามา IaC คือแนวทางปฏิบัติในการจัดการโครงสร้างพื้นฐานของคุณโดยใช้โค้ด หากต้องการใช้ IaC บน Azure คุณมีหลายตัวเลือก ซึ่งหนึ่งในนั้นคือ Bicep Bicep คือ Domain Specific Language (DSL) สําหรับการปรับใช้ทรัพยากร Azure อย่างประกาศ ซึ่งเป็นวิธีที่ยอดเยี่ยมในการจัดการทรัพยากรบนระบบคลาวด์ของคุณ นี่คือตัวอย่างง่าย ๆ ของลักษณะของ Bicep:

param location string = 'eastus'

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

ในตัวอย่างก่อนหน้า เราได้กําหนดบัญชีเก็บข้อมูลโดยใช้ Bicep เราได้กําหนดตําแหน่งที่ตั้งของบัญชีเก็บข้อมูล ชนิดของบัญชีที่เก็บข้อมูล และ SKU (หน่วยเก็บสต็อก) ตําแหน่งที่ตั้งเป็นพารามิเตอร์ที่เราสามารถส่งผ่านได้เมื่อเราปรับใช้ไฟล์ Bicep ในการปรับใช้ไฟล์ที่นําเสนอ เราจะใช้ Azure CLI เช่นนั้น:

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

คําสั่งก่อนหน้าจะปรับใช้บัญชีที่เก็บข้อมูลไปยังกลุ่มทรัพยากร myResourceGroup และใช้ไฟล์ Bicep main.bicep เพื่อสร้างทรัพยากรในไฟล์

การจัดการโหลดผ่านตัวปรับสมดุลการโหลด

การเพิ่มโครงสร้างการปรับสมดุลโหลดคือคําตอบเมื่อปัญหาคือ API ของคุณถูกครอบงําโดยคําขอ ตัวปรับสมดุลการโหลดสามารถช่วยคุณกระจายโหลดข้ามหลายอินสแตนซ์ของ API ของคุณ

ในบริการการจัดการ Azure API การปรับสมดุลการโหลดจะดําเนินการโดยคุณกําหนดแนวคิดที่เรียกว่า Backends แนวคิดคือ คุณตั้งค่า Backend จํานวนมากที่สอดคล้องกับจุดสิ้นสุด API ของคุณ จากนั้นคุณสร้างตัวปรับสมดุลการโหลดที่กระจายโหลดในแบ็กเอนด์เหล่านี้ นี่คือลักษณะสถาปัตยกรรมที่มีลักษณะดังนี้:

สิ่งที่เกิดขึ้นในสถาปัตยกรรมก่อนหน้านี้คือ:

1. ไคลเอ็นต์ส่งคําขอไปยังอินสแตนซ์การจัดการ API
2. คําขอได้รับการรับรองความถูกต้องและได้รับอนุญาต
3. จากนั้น คําขอจะถูกส่งไปยังตัวปรับสมดุลการโหลด
4. ตัวปรับสมดุลการโหลดจะกระจายคําขอไปยังหนึ่งใน Backends (Azure OpenAI API ที่เลือกจะถูกระบุเป็นตัวหนา)

Backend ประมวลผลคําขอและส่งการตอบกลับกลับไปยังไคลเอ็นต์

การกําหนดตัวปรับสมดุลการโหลด

หากต้องการตั้งค่าตัวปรับสมดุลการโหลดใน Azure API Management คุณจําเป็นต้องทําส่วนต่อไปนี้:

• Backendsได้มากเท่าที่คุณต้องการแจกจ่ายโหลด
• Load balancerซึ่งเป็นตัวปรับสมดุลการโหลดที่มีแบ็กเอนด์ที่คุณต้องการกระจายโหลดไปทั่ว
• นโยบาย ที่นําการเรียกเข้าไปยังตัวปรับสมดุลการโหลด

การสร้าง Backends

หากต้องการสร้าง Backend ใน Azure API Management คุณจําเป็นต้องกําหนดเอนทิตี Backend นี่คือวิธีที่คุณสามารถกําหนดแบ็กเอนด์ใน 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'
        }
      ]
    }
}

ในรหัส Bicep ก่อนหน้านี้ แบ็กเอนด์จะถูกกําหนดให้สอดคล้องกับ URL จุดสิ้นสุด API โปรดสังเกตว่าชื่อ backend2 ชื่อนี้คือสิ่งที่เราสามารถใช้ในภายหลังได้ สําหรับแบ็กเอนด์แต่ละรายการที่คุณมี คุณควรเข้ารหัสเหมือนโค้ด bicep ก่อนหน้า

สร้างกลุ่ม Backend

ถัดไป เราต้องการสร้างกลุ่ม Backend ที่ตั้งค่า Backend ที่เราต้องการแจกจ่ายโหลดระหว่าง เราสามารถเข้ารหัสแบ็กเอนด์พูลนี้เป็นเอนทิตีแบ็กเอนด์เช่นนั้น:

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 ที่เราสร้างไว้ก่อนหน้านี้ backend2ถูกอ้างอิงพร้อมกับ backend1Backend อื่น หลังที่เราละเว้นเพื่อความสะดวก

นอกจากนี้เรายังสามารถรวมคุณสมบัติ priority และ weight สําหรับแต่ละรายการในรายการ services เพื่อกําหนดว่าตัวปรับสมดุลการโหลดกระจายโหลดอย่างไร นี่คือวิธีตั้งค่าลําดับความสําคัญและน้ําหนักสําหรับแต่ละแบ็กเอนด์:

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
    }
  ]

ในตัวอย่างก่อนหน้า ตัวปรับสมดุลการโหลดจะกระจายโหลดไปยัง backend-1 มากกว่า backend-2สามเท่า

สายเรียกเข้าโดยตรง

สุดท้ายนี้เราจําเป็นต้องติดต่อโดยตรงกับภาระที่เข้ามาเพื่อปรับสมดุลแบ็กเอนด์ คําแนะนําทิศทางจะถูกสร้างขึ้นในเอนทิตี API ต่อไปนี้:

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'
    }
    
}

กําหนดค่านโยบาย

ในตอนนี้ เราสามารถตั้งค่านโยบายบน API ที่อธิบายไว้ก่อนหน้านี้ และนําการเรียกเข้าไปยังตัวปรับสมดุลการโหลด:

// 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
  }
}

สิ่งที่เราทําคือการสร้างนโยบายที่นําการเรียกเข้าไปยังตัวปรับสมดุลการโหลด นโยบาย set-backend-service ถูกใช้เพื่อนําการเรียกขาเข้าไปยังตัวปรับสมดุลการโหลด คุณสมบัติ backend-id ถูกตั้งค่าเป็นชื่อของตัวปรับสมดุลการโหลดที่เราสร้างขึ้นก่อนหน้านี้

อินสแตนซ์ API Management ของคุณจะปรับสมดุลการโหลดด้วยส่วนที่เคลื่อนที่เหล่านี้ทั้งหมด ตอนนี้คุณสามารถปรับขนาด API ของคุณโดยการเพิ่ม backends เพิ่มเติมไปยังตัวปรับสมดุลการโหลด

เซอร์กิตเบรกเกอร์

circuit breaker คือสิ่งที่คุณใช้เมื่อคุณต้องการปกป้อง API ของคุณจากการถูกคําขอมากเกินไป วิธีการทํางานคือคุณกําหนดชุดของกฎที่เมื่อถึงเวลาที่กําหนดตัวแบ่งวงจรจะทริกเกอร์และหยุดส่งคําขอไปยัง Backend ในการจัดการ AZURE API คุณสามารถกําหนดตัวแบ่งวงจรโดยการตั้งค่า Backend และกําหนดกฎตัวแบ่งวงจร นี่คือวิธีที่คุณสามารถทําได้:

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'
            }
          ]
        }
       }
     }

ในข้อกําหนด backend ก่อนหน้านี้ มีคุณสมบัติ failureCondition ที่กําหนดว่าเมื่อตัวแบ่งวงจรควรเดินทางหรือไม่ ในกรณีนี้ การเดินทางของตัวแบ่งวงจรหากมีสามข้อผิดพลาดของเซิร์ฟเวอร์ในหนึ่งวัน คุณสมบัติ tripDuration จะกําหนดว่าตัวแบ่งวงจรควรเปิดอยู่นานเพียงใดก่อนที่จะปิดอีกครั้ง การกําหนดตัวแบ่งวงจรสําหรับแต่ละ Backend ที่คุณมีในอินสแตนซ์การจัดการ API ของคุณเป็นแนวทางปฏิบัติที่ดี

ข้อมูลประจําตัวที่มีการจัดการ

อีกปัญหาหนึ่งที่เรากําลังจะจัดการคือ ความปลอดภัย คุณต้องการให้แน่ใจว่า API ของคุณปลอดภัยและเฉพาะไคลเอ็นต์ที่ได้รับอนุญาตเท่านั้นที่สามารถเข้าถึงได้ วิธีในการรักษาความปลอดภัย API ของคุณคือการใช้ข้อมูลประจําตัวที่มีการจัดการ ข้อมูลประจําตัวที่มีการจัดการคือวิธีการรับรองความถูกต้อง API ของคุณกับบริการ Azure อื่น ๆ ในการจัดการ API Azure คุณจําเป็นต้องใช้ข้อมูลประจําตัวที่มีการจัดการในหลาย ๆ แห่งได้แก่:

• ระดับอินสแตนซ์ APIM คุณสามารถเปิดใช้งานข้อมูลประจําตัวที่มีการจัดการในอินสแตนซ์ APIM โดยการตั้งค่าคุณสมบัติ identity เป็น SystemAssigned เช่นนั้น:

  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'
      }
  }
  

  การดําเนินการนี้จะสร้างข้อมูลประจําตัวที่มีการจัดการสําหรับอินสแตนซ์ APIM ที่เราสามารถใช้อินสแตนซ์ APIM ของเราในภายหลังได้ ตัวอย่างเช่น อินสแตนซ์ Azure OpenAI

• ระดับ APIสําหรับอินสแตนซ์ API ของคุณ คุณสามารถเชื่อมโยงเข้ากับนโยบายได้ ในนโยบายดังกล่าว คุณสามารถเพิ่มคําแนะนําที่จําเป็นสําหรับข้อมูลประจําตัวที่มีการจัดการเพื่อทํางาน:

  <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>
  

  ดูการเรียกใช้ก่อนหน้าเพื่อ authentication-managed-identity และ set-header คําแนะนําเหล่านี้ตรวจสอบให้แน่ใจว่าข้อมูลประจําตัวที่มีการจัดการถูกนําไปใช้กับ API

• ระดับ Backend ในที่สุด การให้ Backend ของคุณชี้ไปยังอินสแตนซ์ Azure OpenAI เราจําเป็นต้องเชื่อมต่ออินสแตนซ์ APIM ของเรากับอินสแตนซ์ Azure OpenAI หากต้องการเชื่อมต่อนี้ นี่คือคําแนะนําของ 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)
    }
  }
  

  แนวคิดที่มีคําแนะนํา Bicep ข้างต้นคือการสร้างการกําหนดบทบาทระหว่างอินสแตนซ์ APIM และอินสแตนซ์ Azure OpenAI ในกรณีนี้:

  • principalId คือ ID ข้อมูลประจําตัวจากอินสแตนซ์ APIM
  • roleDefinitionId คือผู้ใช้ที่เฉพาะเจาะจง ในกรณีนี้คือผู้ใช้ที่เรียกว่า "ผู้ใช้ Cognitive Services" ผู้ใช้ที่มีสิทธิ์เข้าถึงอินสแตนซ์ Azure OpenAI
  • nameคุณสมบัตินี้ช่วยให้แน่ใจว่า มีการใช้การกําหนดบทบาทกับขอบเขตที่ถูกต้อง ซึ่งในกรณีนี้คือการสมัครสมาชิกและกลุ่มทรัพยากรที่เฉพาะเจาะจง (ต้องเป็นกลุ่มทรัพยากรเดียวกันกับอินสแตนซ์ Azure OpenAI)