NGINX ke APISIX – Mendefinisikan Ulang Dinamika Gateway Penerbangan

January 24, 2024

Case Study

Ikhtisar

Tentang

Dinobatkan sebagai Maskapai Bintang 5 Dunia oleh Skytrax, maskapai terkemuka ini telah beroperasi dengan aman selama 30 tahun, mencakup total hampir 1.900 rute internasional, termasuk transportasi penumpang terjadwal, penerbangan charter untuk pemulihan kerja dan sekolah, serta penerbangan penumpang di Asia, Eropa, Afrika, Amerika Utara, dan Oseania, dll.

Sebagai maskapai yang berkembang pesat, maskapai terkemuka ini membutuhkan gateway API untuk memfasilitasi proses pemesanan penerbangan yang efisien, mengintegrasikan dan menghubungkan berbagai sistem dan layanan, serta menangani skenario konkurrensi tinggi dan data keuangan serta risiko.

Tantangan

  • Munculnya microservices dan deployment yang dikontainerisasi menimbulkan kesulitan dalam mengelola instance NGINX yang semakin banyak dan konfigurasi domain yang beragam.
  • Adanya terlalu banyak versi NGINX yang digunakan bersamaan meningkatkan kompleksitas dalam melakukan upgrade, kompilasi, dan adaptasi plugin.
  • Gateway API sebelumnya hanya dapat memenuhi kebutuhan dasar maskapai terkemuka ini, tetapi tidak dapat menyediakan fitur lanjutan seperti circuit breaker, canary release, dll.

Hasil

  • Konfigurasi multi-node disederhanakan, meningkatkan efisiensi pengembangan dan menghemat biaya manajemen berkat fitur hot reloading APISIX.
  • Maskapai terkemuka ini memanfaatkan ekosistem plugin APISIX yang inklusif untuk melakukan fungsi yang lebih canggih, menyederhanakan upgrade plugin dan sistem.
  • Upgrade meningkatkan efisiensi dan kemudahan pemeliharaan gateway—pergeseran penting menuju manajemen konfigurasi yang terorganisir, modular, dan dapat digunakan kembali.

Latar Belakang

Maskapai terkemuka ini telah menggunakan NGINX sebagai gateway utara-selatan selama periode yang cukup lama. Namun, meskipun secara efektif menangani kebutuhan lalu lintas seiring dengan berkembangnya bisnis dan portofolio produk, perusahaan menghadapi peningkatan masalah di berbagai aspek.

1. Banyaknya Instance NGINX dan Domain

Di dalam perusahaan ini, terdapat banyak instance NGINX dan set domain yang berbeda, yang meningkatkan kesulitan manajemen. Inti dari NGINX terletak pada file konfigurasinya. Seiring dengan bertambahnya jumlah instance NGINX, mengandalkan hanya pada penyalinan file melalui SCP untuk manajemen konfigurasi menjadi semakin sulit. Terutama dengan penggunaan microservices dan deployment yang dikontainerisasi di backend, ada permintaan yang lebih tinggi untuk fleksibilitas dalam konfigurasi reverse proxy, yang menyebabkan peningkatan signifikan dalam beban kerja untuk konsistensi konfigurasi.

2. Berbagai Versi NGINX dan Kesulitan Upgrade Plugin

Karena alasan historis, tim menggunakan beberapa versi NGINX secara bersamaan bersama dengan banyak plugin NGINX. Meskipun upgrade NGINX itu sendiri tidak menimbulkan tantangan yang signifikan, kesulitan muncul saat melakukan upgrade, kompilasi, dan adaptasi berbagai plugin. Banyak dari plugin ini tidak resmi, sehingga troubleshooting selama kompilasi menjadi sulit. Selain itu, kompatibilitas dengan versi NGINX tidak dijamin.

3. Kurangnya Standar untuk Konfigurasi NGINX

Mewarisi sistem dari berbagai tim menyebabkan banyak praktik konfigurasi NGINX, menunjukkan berbagai pendekatan tanpa standar konfigurasi yang seragam. Tidak adanya standar konfigurasi yang terpadu menunjukkan keragaman dalam metode implementasi di berbagai tim, menekankan kebutuhan akan pendekatan yang kohesif dan terstandarisasi untuk konfigurasi NGINX.

4. Kurangnya Fitur Gateway Modern

Meskipun NGINX secara efisien memenuhi kebutuhan dasar gateway utara-selatan seperti reverse proxy dan load balancing, kebutuhan bisnis yang dinamis dari perusahaan memerlukan fitur yang lebih canggih. Menerapkan layanan seperti circuit breaking, kontrol keamanan, dan canary release menjadi sulit jika hanya mengandalkan NGINX, sehingga mendorong eksplorasi solusi yang lebih kuat.

Pemilihan Gateway untuk Kebutuhan Bisnis yang Tepat

Untuk mengatasi tantangan yang dihadapi dengan NGINX, maskapai terkemuka ini dengan cermat merumuskan tiga persyaratan dasar utama untuk solusi gateway baru:

  1. Kemudahan Manajemen dan Konfigurasi: Mereka membutuhkan solusi yang memfasilitasi manajemen dan deployment konfigurasi seperti rute dan layanan upstream yang mudah dan terpadu di beberapa node gateway.
  2. Fitur Gateway API yang Lebih Canggih: Gateway baru harus memenuhi kebutuhan bisnis gateway API modern, termasuk circuit breaking, kontrol keamanan, dan canary release.
  3. Kemudahan Penggunaan dan Kurva Belajar yang Rendah: Mempertimbangkan pengurangan biaya manajemen, tim mengharapkan solusi gateway baru untuk memenuhi sebagian besar kebutuhan dasar melalui konfigurasi dan metode low-code dengan mudah.

Setelah memperjelas upgrade iteratif dan persyaratan dasar untuk gateway utara-selatan yang ada, perusahaan meneliti berbagai produk populer di pasar dan akhirnya memilih APISIX sebagai gateway baru mereka.

Mengapa Bukan OpenResty

Selama penelitian, OpenResty dipertimbangkan pertama kali, solusi yang banyak diadopsi oleh beberapa perusahaan. Keuntungan utamanya adalah kompatibilitas penuh file konfigurasi dengan NGINX. Migrasi dari NGINX ke OpenResty tidak terlalu sulit bagi perusahaan, meskipun ada pengaturan domain yang kompleks.

Namun, dibandingkan dengan Kong dan APISIX, versi open-source OpenResty kurang memiliki plugin yang komprehensif dan dashboard untuk konfigurasi visual. Pengguna harus melakukan coding untuk memenuhi beberapa fungsi dasar.

Mengapa Bukan Kong

Maskapai ini mempertimbangkan Kong sebagai alternatif. Meskipun plugin defaultnya memenuhi sebagian besar kebutuhan, antarmuka visual (Dashboard) versi open-source tidak berubah selama beberapa tahun, sehingga mendorong preferensi untuk solusi dengan antarmuka yang lebih mutakhir dan ramah pengguna.

Dalam uji stres, APISIX mengungguli Kong, menunjukkan kinerja yang mengesankan—dua kali lipat dari Kong tanpa plugin dan hingga sepuluh kali lebih baik dengan plugin rate limiting dan Prometheus yang diaktifkan. Selain itu, APISIX, yang berbasis pada OpenResty, menunjukkan kemampuan routing yang sangat baik, meningkatkan kepercayaan tim.

Mengapa Bukan Envoy

Meskipun Envoy memiliki fitur yang mengesankan, bahasa C++ dan kurva belajar yang lebih curam, terutama karena keterbatasan tim teknis, membuat tim memutuskan untuk tidak memilih Envoy sebagai solusi gateway yang diinginkan.

Pada akhirnya, tim teknis memilih APISIX sebagai gateway baru mereka karena fungsionalitas dan kinerjanya yang diakui.

Mengapa APISIX Menonjol?

APISIX menonjol dibandingkan dengan Kong karena dua alasan utama.

  • APISIX Dashboard

    Dengan Dashboard, tim teknis dapat dengan mudah mengelola berbagai konfigurasi rute dan plugin. Perlu dicatat bahwa APISIX Dashboard adalah bagian open-source dari proyek, memastikan pembaruan terus-menerus sejalan dengan pengembangan APISIX, memberikan pengalaman manajemen yang lebih baik.

  • Proyek Open Source Apache

    Sebagai proyek tingkat atas di Apache Software Foundation, APISIX memudahkan pengguna untuk menemukan dokumentasi teknis yang relevan dibandingkan dengan Kong. Dukungan dari komunitas Apache memberikan bantuan teknis yang andal saat menghadapi tantangan, membuat APISIX menjadi pilihan yang lebih cocok untuk maskapai ini.

Selain itu, APISIX secara efektif mengatasi masalah yang disebutkan sebelumnya terkait NGINX.

  • APISIX menyimpan konfigurasi di etcd, memungkinkan pengembang untuk mengelola beberapa node APISIX untuk domain yang berbeda dengan mudah dengan mengimplementasikan satu cluster etcd.

  • APISIX dilengkapi dengan plugin umum, termasuk pemeriksaan kesehatan dan plugin pemantauan lainnya, menghilangkan kekhawatiran tentang kompatibilitas dan upgrade seperti yang dihadapi dengan NGINX.

  • APISIX mencakup berbagai plugin keamanan dan kontrol lalu lintas, memungkinkan fitur seperti circuit breaking, kontrol keamanan, canary release, dan lainnya dengan mudah.

Secara keseluruhan, APISIX menonjol sebagai produk yang paling cocok untuk tim teknis.

Migrasi dari NGINX ke APISIX: Menjelajahi Solusi yang Lebih Canggih namun Sederhana

Di NGINX, manajemen domain dan implementasi fungsi terutama dicapai melalui file konfigurasi NGINX. Meskipun masih berbasis pada NGINX dan OpenResty, APISIX mengadopsi pendekatan yang sama sekali berbeda, tidak lagi menggunakan file konfigurasi NGINX untuk mengelola domain dan mengimplementasikan fungsi.

Sebaliknya, APISIX mengkonfigurasi rute dan upstream berdasarkan nama domain dan mengimplementasikan berbagai fitur tambahan pada rute ini melalui plugin. Plugin CORS bawaan APISIX dapat diadopsi untuk mencapai konfigurasi lintas wilayah, menghemat kebutuhan untuk mengonversinya baris demi baris.

Berikut adalah perbandingan kode antara konfigurasi di NGINX dan APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

Dengan membandingkan NGINX dan APISIX, dapat dengan mudah ditemukan bahwa konfigurasi NGINX mungkin terlihat lebih ringkas, tetapi bagi individu yang tidak terbiasa dengan NGINX dan CORS, memahami makna yang mendasarinya mungkin tidak begitu mudah. Sebaliknya, APISIX mengemas berbagai fungsi ke dalam plugin, membuat konfigurasi lebih modular. Oleh karena itu, menjadi lebih jelas untuk menemukan fitur dan memahami fungsinya. Contoh serupa migrasi konfigurasi dari NGINX ke APISIX ada untuk berbagai skenario, seperti mengkonfigurasi WebSocket di NGINX.

Pencapaian

Manajemen Konfigurasi Multi-Node yang Disederhanakan

APISIX meningkatkan penyimpanan konfigurasi dengan etcd, memudahkan pengelolaan berbagai node APISIX di beberapa domain. Ini menyederhanakan tugas dengan menggunakan satu cluster etcd, memastikan kontrol yang efektif atas instance APISIX yang berbeda dengan pengaturan domain tertentu. Selain itu, metode terpusat ini mengurangi kompleksitas, mendorong manajemen yang lancar, dan meningkatkan skalabilitas dan efisiensi APISIX dalam berbagai skenario domain. Akibatnya, di maskapai ini, mengimplementasikan satu cluster etcd sudah cukup untuk mengawasi instance APISIX yang berbeda yang terkait dengan pengaturan domain yang berbeda.

Operasi yang Disederhanakan dengan Plugin APISIX

APISIX dilengkapi dengan plugin bawaan seperti pemeriksaan kesehatan umum, mirip dengan plugin yang sering digunakan di NGINX. Fitur ini menghilangkan kebutuhan maskapai untuk khawatir tentang masalah terkait upgrade dan kompatibilitas. Inklusi plugin ini dalam APISIX memastikan fungsionalitas yang lancar dan mengurangi kekhawatiran terkait upgrade dan pemeliharaan kompatibilitas, memberikan pengalaman yang bebas masalah bagi maskapai.

Selanjutnya, di APISIX, fitur seperti cross-origin resource sharing (CORS) dan dukungan WebSocket dapat diimplementasikan dengan mulus menggunakan plugin. Pendekatan ini tidak hanya menyederhanakan proses pengembangan tetapi juga berkontribusi pada resolusi yang lebih canggih dan efisien dari tantangan maskapai.

Membangun Gateway API yang Komprehensif

APISIX dilengkapi dengan berbagai plugin keamanan dan kontrol lalu lintas, memfasilitasi implementasi yang mudah dari pembatasan layanan, tindakan keamanan, dan rilis bertahap. Ini memberdayakan maskapai untuk memanfaatkan berbagai fitur dasar dan lanjutan yang lebih luas. Adopsi APISIX menjadi pencapaian signifikan bagi maskapai, memungkinkan peningkatan keandalan layanan, kontrol keamanan yang kuat, dan strategi deployment yang efisien seperti rilis bertahap, yang pada akhirnya berkontribusi pada peningkatan kapasitas operasional dan kinerja.

Merombak Konfigurasi Lama menjadi Modul yang Dapat Digunakan Kembali

Sepanjang proses upgrade, tim teknis menemukan banyak konfigurasi usang dalam pengaturan NGINX yang ada, banyak di antaranya melibatkan penyalinan yang tidak masuk akal. Upgrade ini berfungsi sebagai perombakan menyeluruh dari seluruh gateway utara-selatan mereka, dengan fokus khusus pada fungsionalitas yang disediakan oleh APISIX, seperti plugin_config. Fitur ini sangat memfasilitasi manajemen modular dan penggunaan kembali konfigurasi di tingkat gateway. Implementasi plugin_config APISIX dan kemampuan terkait tidak hanya menyederhanakan proses konfigurasi tetapi juga meningkatkan efisiensi dan kemudahan pemeliharaan gateway utara-selatan kami. Upgrade ini menandai pergeseran penting menuju pendekatan manajemen konfigurasi yang lebih terorganisir, modular, dan dapat digunakan kembali.

Ringkasan

Dari April 2023, maskapai terkemuka ini pertama kali menemui APISIX, hingga migrasi yang sukses dari NGINX ke APISIX di lingkungan produksi pada Juli tahun yang sama, seluruh proses migrasi telah menghasilkan hasil yang memuaskan.

Pada tahap awal migrasi, tim teknis menangani berbagai konfigurasi historis dan mengungkapkan kekhawatiran tentang apakah plugin APISIX dapat sepenuhnya mereplikasi semua fungsionalitas NGINX yang ada. Namun, hasil akhir menunjukkan bahwa plugin APISIX lebih dari mampu memenuhi tantangan ini.

Secara ringkas, APISIX memberikan solusi yang lebih elegan dan membantu maskapai terkemuka ini memasuki fase teknis baru. Ini telah secara sempurna mengatasi berbagai masalah yang dihadapi dalam NGINX dan set plugin yang kaya memungkinkan maskapai untuk dengan mudah menangani berbagai persyaratan baru yang diajukan oleh klien.

Tags:
Airlines