Load balancing di seluruh server backend

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Lihat dokumentasi Apigee Edge.

Apigee meningkatkan ketersediaan API Anda dengan memberikan dukungan bawaan untuk load balancing dan failover di beberapa instance server backend.

Server target memisahkan URL endpoint konkret dari konfigurasi endpoint target. Daripada menentukan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa server target bernama. Kemudian, setiap server target dirujuk berdasarkan nama di HTTPConnection endpoint target.

Video

Tonton video berikut untuk mempelajari lebih lanjut perutean API dan load balancing menggunakan server target

Tentang konfigurasi server target

Konfigurasi server target terdiri dari nama, host, protokol, dan port, dengan elemen tambahan untuk menunjukkan apakah server target diaktifkan atau dinonaktifkan. Server target juga dapat memiliki objek <sSLInfo> opsional.

Kode berikut memberikan contoh konfigurasi server target:

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Untuk mengetahui informasi selengkapnya tentang TargetServers API, lihat organizations.environments.targetservers.

Lihat skema untuk TargetServer dan entitas lainnya di GitHub.

Membuat server target

Buat server target menggunakan UI atau API Apigee seperti yang dijelaskan di bagian berikut.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'
 

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

[ "target2", "target1" ]

Mengonfigurasi endpoint target untuk menyeimbangkan beban di seluruh server target bernama

Setelah memiliki dua server target yang tersedia, Anda dapat mengubah elemen <HTTPTargetConnection> endpoint target untuk mereferensikan kedua server target tersebut berdasarkan nama:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Konfigurasi di atas adalah konfigurasi load balancing paling dasar. Load balancer mendukung tiga algoritma load balancing, RoundRobin, Weighted, dan LeastConnections. Round Robin adalah algoritma default. Karena tidak ada algoritma yang ditentukan dalam konfigurasi di atas, permintaan keluar dari proxy API ke server backend akan bergantian, satu per satu, antara target1 dan target2.

Elemen <Path> membentuk basepath URI endpoint target untuk semua server target. Hanya digunakan saat <LoadBalancer> digunakan. Jika tidak, parameter tersebut akan diabaikan. Dalam contoh di atas, permintaan yang mencapai target1 akan http://target1/test dan begitu juga untuk server target lainnya.

Mengonfigurasi opsi load balancer

Anda dapat menyesuaikan ketersediaan dengan mengonfigurasi opsi untuk load balancing dan failover di tingkat load balancer dan server target seperti yang dijelaskan di bagian berikut.

Algoritme

Menetapkan algoritma yang digunakan oleh <LoadBalancer>. Algoritma yang tersedia adalah RoundRobin, Weighted, dan LeastConnections, yang masing-masing didokumentasikan di bawah.

Panggilan acak

Algoritma default, round robin, meneruskan permintaan ke setiap server target dalam urutan server tercantum dalam koneksi HTTP endpoint target. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Berbobot

Algoritma load balancing berbobot memungkinkan Anda mengonfigurasi beban traffic proporsional untuk server target. LoadBalancer berbobot mendistribusikan permintaan ke server target Anda secara proporsional langsung dengan bobot setiap server target. Oleh karena itu, algoritma berbobot mengharuskan Anda menetapkan atribut weight untuk setiap server target. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Dalam contoh ini, dua permintaan akan dirutekan ke target2 untuk setiap satu permintaan yang dirutekan ke target1.

Koneksi Terkecil

LoadBalancer yang dikonfigurasi untuk menggunakan algoritma koneksi paling sedikit akan merutekan permintaan keluar ke server target dengan koneksi HTTP terbuka paling sedikit. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Kegagalan maksimum

Jumlah maksimum permintaan yang gagal dari proxy API ke server target yang menyebabkan permintaan dialihkan ke server target lain.

Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika hal ini terjadi, penghitung kegagalan akan bertambah satu.

Namun, saat Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 404 atau 500), hal itu dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk memastikan bahwa respons HTTP yang buruk (seperti 500) juga menaikkan penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> dengan elemen turunan <ResponseCode> ke konfigurasi load balancer. Apigee juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

Dalam contoh berikut, target1 akan dihapus dari rotasi setelah lima permintaan gagal, termasuk 404 dan beberapa respons 5XX dari server target.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Default MaxFailures adalah 0. Artinya, Apigee selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.

Sebaiknya gunakan MaxFailures > 0 dengan monitor kesehatan. Jika Anda mengonfigurasi MaxFailures > 0, server target akan dihapus dari rotasi jika target gagal sebanyak jumlah yang Anda tunjukkan. Jika pemantau kesehatan sudah ada, Apigee akan otomatis mengembalikan server target ke dalam rotasi setelah target aktif dan berjalan kembali, sesuai dengan konfigurasi pemantau kesehatan tersebut. Lihat Pemantauan kondisi untuk mengetahui informasi selengkapnya.

Perhatikan bahwa panggilan API reguler dan panggilan yang dimulai oleh pemantau kesehatan akan dihitung dalam jumlah MaxFailures.

Perhatikan juga bahwa jumlah kegagalan yang berjalan untuk setiap server target dipertahankan berdasarkan per load balancer. Misalnya, anggaplah proxy memiliki dua endpoint target, dan masing-masing memiliki load balancer, dan kedua load balancer dikonfigurasi untuk menggunakan kumpulan server target yang sama. Dalam kasus seperti itu, kegagalan dari satu endpoint target hanya dihitung terhadap load balancer yang sesuai. Endpoint ini tidak memengaruhi rotasi endpoint target lainnya.

Atau, jika Anda mengonfigurasi MaxFailures > 0 dan Anda tidak mengonfigurasi monitor kesehatan, Apigee akan otomatis mengeluarkan server target dari rotasi saat kegagalan pertama terdeteksi. Apigee akan memeriksa kesehatan server target setiap lima menit dan mengembalikannya ke rotasi saat merespons secara normal.

Coba lagi

Jika percobaan ulang diaktifkan, permintaan akan dicoba ulang setiap kali terjadi kegagalan respons (error I/O atau waktu tunggu HTTP habis) atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>. Lihat Kegagalan maksimum di atas untuk mengetahui informasi selengkapnya tentang cara menetapkan <ServerUnhealthyResponse>.

Secara default, <RetryEnabled> disetel ke true. Setel ke false untuk menonaktifkan percobaan ulang. Contoh:

<RetryEnabled>false</RetryEnabled>

IsFallback

Satu (dan hanya satu) server target dapat ditetapkan sebagai server penggantian. Load balancer tidak akan menggunakan server pengganti hingga semua server target lainnya telah dihapus dari rotasi oleh load balancer. Jika hal ini terjadi, semua traffic akan dirutekan ke server penggantian hingga salah satu server target lainnya melaporkan status responsif lagi dan dikembalikan ke rotasi. Contoh:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Konfigurasi di atas menghasilkan load balancing round robin antara target1 dan target2 hingga target1 dan target2 tidak tersedia. Jika target1 dan target2 tidak tersedia, semua traffic akan dirutekan ke target3.

Jika server pengganti tidak responsif, Apigee tidak akan merutekan traffic ke server tersebut. Sebagai gantinya, panggilan API akan menampilkan error 503 "Service is temporarily unavailable".

Jalur

Path menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh server target ke server backend.

Elemen ini menerima jalur string literal atau template pesan. Template pesan memungkinkan Anda melakukan penggantian string variabel saat runtime. Misalnya, dalam definisi endpoint target berikut, nilai {mypath} digunakan untuk jalur:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Mengonfigurasi server target untuk TLS/SSL

Jika Anda menggunakan server target untuk menentukan layanan backend, dan layanan backend memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL dalam definisi server target. Hal ini diperlukan karena tag host tidak memungkinkan Anda menentukan protokol koneksi.

Mengonfigurasi TLS/SSL satu arah

Gunakan konfigurasi berikut untuk menentukan server target dengan TLS/SSL satu arah. Dalam contoh ini, Apigee membuat permintaan HTTPS ke layanan backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Mengonfigurasi penerapan SSL ketat

Untuk menentukan penerapan SSL ketat dalam definisi server target, tetapkan enforce ke true dalam blok sSLInfo, seperti yang ditunjukkan dalam contoh berikut:

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }
  

Mengonfigurasi TLS/SSL dua arah

Jika layanan backend memerlukan TLS/SSL dua arah, atau timbal balik, Anda dapat mengonfigurasi server target dengan setelan konfigurasi TLS/SSL yang sama dengan endpoint target:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Mengonfigurasi SSL ketat menggunakan API

Untuk membuat server target dengan penerapan SSL ketat menggunakan panggilan API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Pemantauan kesehatan

Pemantauan kondisi memungkinkan Anda meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling pada URL layanan backend yang ditentukan dalam konfigurasi server target. Dengan pemantauan kondisi aktif, server target yang tidak dapat dijangkau atau menampilkan respons error ditandai sebagai tidak responsif. Server target yang gagal akan otomatis dikembalikan ke rotasi saat monitor kesehatan menentukan bahwa server target aktif. Tidak perlu men-deploy ulang proxy.

Monitor kesehatan bertindak sebagai klien sederhana yang memanggil layanan backend melalui TCP atau HTTP:

• Klien TCP hanya memastikan bahwa soket dapat dibuka.
• Anda mengonfigurasi klien HTTP untuk mengirimkan permintaan HTTP yang valid ke layanan backend. Anda dapat menentukan operasi HTTP GET, PUT, POST, atau DELETE. Respons panggilan monitor HTTP harus cocok dengan setelan yang dikonfigurasi di blok <SuccessResponse>.

Keberhasilan dan kegagalan

Saat Anda mengaktifkan pemantauan kondisi, Apigee akan mulai mengirim pemeriksaan kondisi ke server target Anda. Pemeriksaan kondisi adalah permintaan yang dikirim ke server target yang menentukan apakah server target responsif atau tidak.

Health check dapat memiliki salah satu dari dua kemungkinan hasil:

• Berhasil: Server target dianggap responsif saat health check berhasil. Hal ini biasanya merupakan akibat dari satu atau beberapa hal berikut:
  • Server target menerima koneksi baru ke port yang ditentukan, merespons permintaan di port tersebut, lalu menutup port dalam jangka waktu yang ditentukan. Respons dari server target berisi Connection: close
  • Server target merespons permintaan health check dengan kode status HTTP 200 (OK) atau kode status HTTP lainnya yang Anda tentukan dapat diterima.
  • Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.

  Saat Apigee menentukan bahwa server responsif, Apigee akan melanjutkan atau memulai kembali pengiriman permintaan ke server tersebut.

• Kegagalan: Server target dapat gagal dalam health check dengan berbagai cara, bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
  • Menolak koneksi dari Apigee ke port health check.
  • Tidak merespons permintaan health check dalam jangka waktu tertentu.
  • Menampilkan kode status HTTP yang tidak terduga.
  • Merespons dengan isi pesan yang tidak cocok dengan isi pesan yang diharapkan.

  Saat server target gagal dalam health check, Apigee akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melampaui nilai minimum yang telah ditentukan sebelumnya (<MaxFailures>), Apigee akan berhenti mengirim permintaan ke server tersebut.

Mengaktifkan pemantau kondisi

Untuk membuat monitor kesehatan bagi proxy API, tambahkan elemen <HealthMonitor> ke konfigurasi elemen <HTTPTargetConnection endpoint target untuk proxy.

Monitor kesehatan tidak dapat dibuat di UI. Sebagai gantinya, Anda membuat konfigurasi proxy dan menguploadnya sebagai file ZIP ke Apigee. Konfigurasi proxy adalah deskripsi terstruktur dari semua aspek proxy API. Konfigurasi proxy terdiri dari file XML dalam struktur direktori yang telah ditentukan sebelumnya. Untuk informasi selengkapnya, lihat Referensi Konfigurasi Proxy API.

Elemen konfigurasi <HealthMonitor>

Tabel berikut menjelaskan elemen konfigurasi <HealthMonitor>:

Selain elemen ini, untuk mengaktifkan pemantau kondisi, Anda harus menetapkan elemen <MaxFailures> dalam blok <HTTPTargetConnection> elemen <TargetEndpoint> ke nilai yang lebih besar dari 0. <MaxFailures> digunakan untuk menentukan jumlah maksimum permintaan gagal dari proxy API ke server target yang dapat terjadi sebelum permintaan dialihkan ke server target lain.

Secara default, <MaxFailures> adalah 0, yang berarti Apigee tidak melakukan tindakan korektif. Saat mengonfigurasi monitor kesehatan, pastikan Anda menyetel <MaxFailures> ke nilai bukan nol.

Pemantau kondisi menggunakan pemantau TCP

Monitor kesehatan contoh yang dijelaskan dalam konfigurasi berikut menggunakan monitor TCP untuk melakukan polling pada setiap server target dengan membuka koneksi di port 80 setiap lima detik. (Port bersifat opsional. Jika tidak ditentukan, port monitor TCP adalah port server target.)

Dalam konfigurasi pemantau kondisi ini:

• Jika koneksi gagal atau memerlukan waktu lebih dari 10 detik untuk terhubung, jumlah kegagalan akan bertambah 1 untuk server target tersebut.
• Jika koneksi berhasil, jumlah kegagalan untuk server target akan direset ke 0.

Anda dapat menambahkan monitor kesehatan sebagai elemen turunan dari elemen <HTTPTargetConnection> endpoint target, seperti yang ditunjukkan di bawah ini:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

Elemen konfigurasi <TCPMonitor>

Tabel berikut menjelaskan elemen konfigurasi <TCPMonitor>:

Monitor kesehatan menggunakan monitor HTTP

Monitor kondisi contoh yang dijelaskan dalam konfigurasi berikut menggunakan monitor HTTP yang mengirimkan permintaan GET ke layanan backend setiap lima detik dan menambahkan header Otorisasi Dasar HTTP ke pesan permintaan.

Dalam konfigurasi pemantau kondisi ini:

• Respons yang diharapkan dari layanan backend adalah kode respons HTTP 200.
• Nilai yang diharapkan untuk header Otorisasi Dasar HTTP kustom ImOK adalah YourOK.
• Elemen <UseTargetServerSSLInfo> disetel ke true untuk menggunakan parameter SSL dari blok <SSLInfo> server target.

Dengan konfigurasi ini, kode respons dan nilai header yang diharapkan akan dibandingkan dengan respons sebenarnya dari layanan backend. Jika respons tidak cocok, permintaan akan dianggap sebagai kegagalan oleh konfigurasi load balancer.

Secara default, monitor kesehatan tidak dapat mengakses keystore, truststore, atau parameter SSL lainnya dari server targetnya. Untuk mengaktifkan akses ke parameter ini untuk pemantau kondisi Anda guna mendukung TLS bersama, misalnya, tambahkan <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> di blok <Request>.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>
  

Elemen konfigurasi <HTTPMonitor>

Tabel berikut menjelaskan elemen konfigurasi <HTTPMonitor> tingkat teratas:

Elemen konfigurasi <HTTPMonitor>/<Request>

Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh health monitor ke server target dalam rotasi. Perhatikan bahwa <Request> adalah elemen wajib.

Elemen konfigurasi <HTTPMonitor>/<SuccessResponse>

(Opsional) Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh layanan backend yang di-polling. Respons yang tidak cocok akan menambah jumlah kegagalan sebanyak 1.