Mengubah Raksasa Manajemen Dana dengan APISIX

Ikhtisar

Tentang Invesco Great Wall

Invesco Great Wall Fund Management Co., Ltd. ("IGW") adalah perusahaan manajemen investasi Tiongkok-Amerika dengan kemampuan investasi multi-aset dan keahlian terdepan dalam ekuitas. Bisnis utama perusahaan meliputi investasi kuantitatif, pendapatan aktif, dan pendapatan tetap. Aset yang dikelola oleh IGW melebihi 850 miliar USD, melayani lebih dari 60 juta investor.

IGW menempatkan penekanan utamanya pada manajemen aset, menyediakan berbagai strategi investasi yang mencakup berbagai kelas aset seperti ekuitas, pendapatan tetap, dan strategi kuantitatif.

Tantangan

• Kurangnya standarisasi gateway di antara berbagai sistem bisnis menyebabkan banyak layanan terkait gateway dan operasi independen, yang mengakibatkan peningkatan biaya pemeliharaan.
• Gateway sebelumnya IGW memiliki kapasitas dan kemampuan yang terbatas, seperti load balancing dan canary release, yang rumit dan memakan waktu untuk diimplementasikan, berpotensi menyebabkan hambatan operasional.
• Karena tidak adanya kemampuan autentikasi dalam setup sebelumnya, berbagai antarmuka sistem dapat diakses langsung, menimbulkan risiko keamanan yang signifikan bagi sistem bisnis.

Hasil

• Dengan mengimplementasikan APISIX, IGW membangun gateway API terpadu, mengatasi masalah pengembangan yang berlebihan dan kualitas fitur yang tidak konsisten.
• Integrasi DevOps dan pipeline secara signifikan meningkatkan stabilitas deployment rute dan layanan, meningkatkan efisiensi rilis rute dan layanan.
• Hot reloading APISIX secara substansial mengurangi kebutuhan untuk restart layanan, sehingga mengurangi tekanan pada sumber daya sistem dan mengurangi downtime.

Latar Belakang

Pertama, mari kita telusuri evolusi arsitektur sistem bisnis IGW. Awalnya, IGW mengadopsi pendekatan layanan monolitik, dengan aplikasi layanan yang di-deploy pada mesin fisik. Namun, seiring pertumbuhan layanan dan bisnis, biaya operasi dan pengembangan mulai meningkat. Hal ini mendorong transisi ke tahap mesin virtual.

Selama fase mesin virtual, tidak ada keseragaman dalam gateway yang digunakan oleh berbagai sistem bisnis. Setiap bisnis beroperasi secara independen, menghasilkan banyak layanan terkait gateway dan biaya pemeliharaan yang tinggi.

Di sektor dana dan sekuritas, ada persyaratan regulasi terkait zona jaringan. Setiap zona jaringan perlu dibagi menjadi zona aman yang terisolasi secara fisik atau zona aman logis berdasarkan tingkat keamanan informasi, di mana firewall digunakan.

Sejalan dengan strategi cloud dalam transformasi teknologi keuangan dan digital, IGW memulai proyek migrasi cloud-nya.

Mengapa IGW Memilih APISIX

Karena sektor keuangan menekankan stabilitas layanan lebih dari industri lain, stabilitas menjadi prioritas utama. Seiring pertumbuhan layanan gateway yang pesat di lingkungan mesin virtual, menjadi penting untuk memenuhi berbagai kebutuhan bisnis. Oleh karena itu, skalabilitas gateway sangat dihargai. Selain itu, observabilitas memainkan peran penting, dengan permintaan kuat untuk logging, tracing, dan monitoring sistem bisnis. Terakhir, kemampuan hot reloading juga sangat penting.

Karena keterbatasan NGINX dalam memperbarui konfigurasi secara dinamis, diperlukan reload saat menghadapi perubahan konfigurasi. Selain itu, dalam skenario koneksi persisten, proses ini dapat menyebabkan fluktuasi lalu lintas dalam sistem bisnis, memengaruhi pengalaman pengguna.

Oleh karena itu, dengan mempertimbangkan empat poin fokus ini, tim teknis IGW melakukan perbandingan komprehensif antara APISIX dan Kong, dua gateway API populer dan diakui di pasar:

• Kerangka Teknis: APISIX dan Kong keduanya dikembangkan berdasarkan OpenResty. Mengenai pusat konfigurasi, APISIX mengadopsi etcd, sementara Kong memilih PostgreSQL. APISIX menonjol sebagai gateway terdistribusi cloud-native karena sifat cloud-native dari etcd dan fitur state APISIX. Namun, pilihan pusat konfigurasi Kong dapat menimbulkan masalah single-point-of-failure, memerlukan dukungan infrastruktur tambahan untuk ketersediaan tinggi.

• Aktivitas Komunitas: Baik APISIX maupun Kong memiliki komunitas yang aktif dengan rata-rata 20 commit per hari di repositori mereka.

• Plugin: APISIX memiliki 80+ plugin dan hanya satu dokumen untuk setiap plugin; Kong memiliki 30+ plugin dan 4-5 dokumen untuk setiap plugin; 100+ kode untuk setiap plugin APISIX dan 300+ untuk Kong.

• Skalabilitas: APISIX mendukung banyak bahasa pemrograman dan juga mendukung WebAssembly. Kong hanya mendukung penggunaan Lua untuk menulis plugin.

• Hot Reloading: Ini adalah fokus tim. APISIX mendukung hot reloading pada level milidetik saat mengaktifkan atau menonaktifkan plugin, dan saat menambahkan plugin baru (seperti plugin kustom). APISIX juga mendukung modifikasi dinamis parameter gateway. Namun, Kong tidak mendukung fitur ini saat IGW melakukan seleksi teknologi.

• Observabilitas: Baik APISIX maupun Kong mendukung OpenTelemetry, tetapi APISIX juga dapat terhubung ke Elasticsearch, Prometheus, dan SkyWalking. Kong belum menyediakan dukungan SkyWalking saat IGW melakukan seleksi teknologi.

Berdasarkan kekhawatiran dan poin perbandingan di atas, tim teknis IGW akhirnya memilih APISIX sebagai gateway API.

Skenario Pengguna dan Solusi untuk IGW

Pengenalan Arsitektur Sistem IGW

Sistem bisnis IGW secara kasar dibagi menjadi tiga bagian: area transaksi, area produksi, dan area manajemen, masing-masing menggunakan gateway API yang berbeda. Awalnya, IGW menggunakan NGINX sebagai server web dan reverse proxy. Bisnis dalam klasifikasi jaringan yang sama semua menggunakan NGINX yang sama. Akibatnya, setiap perubahan layanan atau pembaruan rute memerlukan pembaruan manual dan reloading pada NGINX.

Diagram di atas menggambarkan arsitektur sistem IGW. Lapisan kluster keamanan gateway menggunakan berbagai kerangka kerja seperti Zuul, Spring Cloud Gateway, Kong, dan NGINX. Manajemen arsitektur tidak terpadu dan manajemen relatif rumit.

Solusi

Untuk mengatasi tantangan ini, IGW menekankan transformasi kluster gateway menjadi APISIX. Karena APISIX di-deploy pada kluster Kubernetes, memungkinkan manajemen API yang terpadu melalui YAML secara deklaratif. Selain itu, APISIX Ingress Controller secara otomatis memantau perubahan dalam sumber daya Kubernetes, memungkinkan sinkronisasi konfigurasi APISIX secara real-time, termasuk ApisixRoute, SSL, dan lainnya.

Di bawah ini adalah Diagram Urutan Sinkronisasi Rute IGW setelah menggunakan APISIX.

Skenario Pengguna

Setelah menggunakan APISIX, IGW mencapai banyak manfaat, di mana tim IGW lebih memperhatikan dari perspektif bisnis, termasuk routing cerdas, autentikasi, observabilitas, dan kontrol lalu lintas.

Routing Cerdas yang Efisien

Routing cerdas terutama ditunjukkan dalam load balancing di layer 4 dan layer 7. Seperti yang ditunjukkan dalam diagram, informasi rute yang disinkronkan melalui APISIX Ingress Controller disertai dengan label spesifik, secara efektif mencegah operasi penghapusan yang tidak disengaja.

Setelah pengujian di lingkungan, bahkan jika data dihapus, Kubernetes mampu dengan cepat dan otomatis menyinkronkan dengan APISIX, sehingga mengatasi masalah kehilangan data.

Selain itu, pembaruan rute pada APISIX mencapai responsivitas level milidetik, dengan penundaan sinkronisasi konfigurasi yang hampir tidak terasa, memberikan pengalaman pengguna yang sangat baik.

Autentikasi yang Ditingkatkan

Sebelum memperkenalkan gateway terpadu, setiap unit bisnis harus secara individual mengembangkan komponen terkait autentikasi untuk memastikan keamanan antarmuka data mereka. Di sisi bisnis, setiap sistem dibebani dengan pengembangan fungsi autentikasi yang berlebihan, mengakibatkan biaya pengembangan yang lebih tinggi dan kualitas fitur yang bervariasi. Akibatnya, untuk verifikasi keamanan, IGW memperkenalkan autentikasi terpadu dan plugin pengalihan HTTPS.

Sebelum pengenalan gateway terpadu, sertifikat HTTPS untuk layanan didekripsi di titik akhir High Availability (HA), yang meningkatkan kompleksitas, overhead operasional, dan risiko keamanan.

Menyadari tantangan ini, tim teknis IGW merencanakan untuk memusatkan fungsi autentikasi dalam gateway, sehingga mengatasi masalah tersebut. Pendekatan ini secara signifikan meningkatkan efisiensi penelitian dan pengembangan sistem bisnis, memungkinkan pengembang untuk lebih fokus pada pengembangan bisnis inti.

Dengan beralih ke APISIX, kekurangan ini dapat diatasi. APISIX dapat menangani terminasi HTTPS, memuat sertifikat SSL secara dinamis, dan menyediakan manajemen terpusat dan aman untuk menangani tugas-tugas terkait keamanan, meningkatkan kinerja dan fleksibilitas sistem secara keseluruhan.

Melampaui Monitoring

Sebelumnya, dukungan yang lemah untuk observabilitas dalam sistem bisnis asli IGW berdampak buruk pada pemecahan masalah sistem, optimasi kinerja, keandalan, dan monitoring proaktif.

Oleh karena itu, tim teknis IGW bertujuan untuk dengan cepat mengintegrasikan berbagai plugin yang disediakan oleh APISIX, seperti log monitoring dan tracing, untuk meningkatkan kemampuan observabilitas.

Selain itu, tim secara aktif meneliti dan memanfaatkan Apache SkyWalking untuk distributed tracing, Prometheus untuk tujuan monitoring, dan ELK untuk pengumpulan log yang efisien. Menariknya, APISIX mendukung semua plugin ini dan dengan demikian terbukti sebagai solusi ideal yang sepenuhnya memenuhi harapan dan persyaratan tim teknis IGW, menjadikannya pilihan utama.

Diagram di atas menggambarkan topologi layanan IGW setelah tim teknis mengintegrasikan SkyWalking ke dalam produksi. Diagram komprehensif ini menawarkan visualisasi yang jelas dan ringkas tentang hubungan panggilan antar-layanan, mencakup informasi penting seperti arah lalu lintas melalui gateway dan tingkat keberhasilan. Dengan memanfaatkan diagram topologi ini, tim IGW dapat dengan cepat menemukan lokasi pasti dari kesalahan atau masalah dalam rantai layanan.

Menguasai Kontrol Lalu Lintas

APISIX telah terbukti sebagai solusi efektif dalam memfasilitasi mekanisme kontrol lalu lintas yang serbaguna untuk IGW. Dengan mengadopsi APISIX, tim teknis IGW telah mencapai kontrol lalu lintas melalui canary release dan strategi berbasis bobot dengan mulus. Kemampuan yang kuat ini memungkinkan manajemen distribusi lalu lintas yang efisien, memungkinkan tim untuk dengan mudah mengimplementasikan canary release dan menyesuaikan bobot lalu lintas sesuai kebutuhan.

Dalam skenario berdasarkan canary release, gateway perlu memanggil antarmuka downstream melalui permintaan HTTP untuk mendapatkan data spesifik, dan menilai berdasarkan hasil yang dikembalikan untuk menentukan apakah permintaan perlu dikirim ke lingkungan canary release.

Berdasarkan kebijakan berbasis bobot, layanan mesin virtual dan kontainer disediakan ke luar secara paralel. Misalnya, 90% lalu lintas mengenai layanan mesin virtual dan 10% lalu lintas mengenai layanan cloud untuk memverifikasi stabilitas layanan cloud. Saat ini, lingkungan produksi IGW telah dikonfigurasi dengan canary release berbasis bobot.

Pencapaian Setelah Menggunakan APISIX

Membangun Gateway API Terpadu

Dengan mengimplementasikan APISIX, tim teknis IGW telah mencapai standarisasi kerangka kerja gateway API yang menyediakan fungsi manajemen lalu lintas yang kaya seperti load balancing, upstream dinamis, canary release, circuit breaking, autentikasi, dan observabilitas.

IGW telah mengimplementasikan fungsi autentikasi terpadu pada gateway, mengatasi masalah pengembangan yang berlebihan dan kualitas fitur yang tidak konsisten. Hal ini memungkinkan pengembang untuk lebih fokus pada pengembangan, dan secara signifikan meningkatkan efisiensi penelitian dan pengembangan sistem bisnis.

Meningkatkan Stabilitas Deployment Rute dan Layanan

Pembaruan rute pada APISIX mampu memberikan respons level milidetik, memastikan kinerja yang cepat dan efisien. Selain itu, sinkronisasi konfigurasi hampir instan, menghasilkan pengalaman pengguna yang lebih baik.

Selain itu, integrasi DevOps dan pipeline secara signifikan meningkatkan stabilitas deployment rute dan layanan. Pendekatan yang terstruktur ini telah meningkatkan efisiensi rilis rute dan layanan, memastikan hasil yang lebih andal dan konsisten.

Hot-Reloading Meningkatkan Kinerja dan Uptime

Tim teknis IGW sangat menghargai kekuatan hot reloading. APISIX menawarkan proses hot deployment yang mulus untuk mengaktifkan atau menonaktifkan plugin, memfasilitasi penambahan plugin kustom, dan memungkinkan pembaruan dinamis parameter gateway.

Akibatnya, modifikasi pada konfigurasi plugin dan pengaturan gateway dapat diterapkan secara instan tanpa perlu restart sistem atau gangguan. Fitur hot reloading yang luar biasa ini sangat meningkatkan fleksibilitas dan kelincahan platform APISIX, memberdayakan pengembang untuk melakukan penyesuaian real-time pada konfigurasi mereka dan menyesuaikan gateway untuk memenuhi kebutuhan spesifik mereka.

Kemampuan hot-reloading APISIX telah sangat mengurangi tekanan restart layanan. Fitur ini memungkinkan pembaruan dan modifikasi diterapkan pada layanan tanpa perlu restart lengkap, menghasilkan peningkatan kinerja sistem dan pengurangan downtime.

Ringkasan

Tim teknis IGW juga mengajukan harapan untuk lebih meningkatkan fungsionalitas, keandalan, dan kinerja APISIX untuk operasi yang mulus di masa depan.

Implementasi sukses APISIX di Invesco Great Wall telah menghasilkan manfaat dan hasil positif yang signifikan. Dengan APISIX, tim IGW telah mencapai kerangka kerja gateway API yang terpadu, menghasilkan operasi yang terstruktur dan biaya yang berkurang. Integrasi ini juga membawa stabilitas yang lebih baik dalam rute dan layanan, menghasilkan peningkatan kinerja dan gangguan yang diminimalkan.

Mengingat hasil luar biasa dari Invesco Great Wall, APISIX terbukti sebagai solusi gateway API yang sangat efektif yang disesuaikan untuk industri jasa keuangan, termasuk sektor dana dan sekuritas. Studi kasus sukses ini menjadi bukti yang kuat tentang manfaat mengadopsi APISIX dalam keuangan dan sangat merekomendasikan implementasinya kepada organisasi lain di industri ini.