Snowball Finance Mentransformasi Arsitektur Active-Active dengan APISIX

Wenjie Shi, Senior Development Engineer dari Tim Infrastruktur di Snowball Finance, berbagi praktik Snowball Finance dengan APISIX di Apache APISIX Summit ASIA 2022. Artikel ini didasarkan pada pembahasan tersebut, yang memperkenalkan bagaimana Snowball Finance memanfaatkan Apache APISIX untuk mencapai evolusi arsitektur aktif-aktif internalnya, sehingga mencapai manajemen layanan yang lebih fleksibel.

Tantangan

• Modul autentikasi SDK yang kompleks meningkatkan kompleksitas sistem dan risiko keamanan ketika pusat pengguna diakses lintas wilayah karena arsitektur aktif-aktif hanya tersedia di modul layanan pasar.
• OpenResty kurang memiliki sistem pemantauan yang kuat untuk observabilitas dan memerlukan skrip khusus untuk mencapai skalabilitas, yang mengakibatkan biaya pengembangan dan operasi yang lebih tinggi.
• Pusat registri NGINX yang tidak lengkap tanpa mekanisme detak jantung menurunkan ketersediaan dan stabilitas, sehingga tidak dapat menangani kegagalan sistem dengan cepat.

Tujuan

• Meminimalkan perubahan tanpa memperkenalkan terlalu banyak variabel sambil menjaga transparansi untuk kelompok bisnis.
• Menangani masalah secara seragam di tingkat infrastruktur dan berusaha menyelesaikan layanan autentikasi dalam pusat data lokal.

Hasil

• Menerapkan autentikasi seragam, pemutusan sirkuit, dan pembatasan laju di lapisan gateway, mengurangi kopling sistem dan meningkatkan kualitas layanan dalam skenario pusat data ganda.
• Membangun solusi pemantauan seragam dari gateway ke lapisan layanan dengan memanfaatkan sistem pemantauan APISIX dan memberikan dukungan yang sangat baik untuk pemecahan masalah global.
• Memberikan pendekatan implementasi yang elegan untuk konversi protokol gRPC dan manajemen layanan.

Latar Belakang

Didirikan pada tahun 2010, Snowball Finance awalnya adalah komunitas investasi dan kini telah menjadi platform manajemen keuangan online terkemuka di Tiongkok, menawarkan berbagai layanan termasuk konten berkualitas tinggi, layanan pasar real-time, alat perdagangan, dan manajemen kekayaan kepada investor.

Di antara layanan tersebut, layanan pasar real-time terhubung ke beberapa sumber data upstream dan menyediakan layanan data yang stabil kepada investor melalui streaming data, penyimpanan, dan distribusi. Oleh karena itu, layanan pasar real-time selalu menjadi konsumen sumber daya utama dalam sistem Snowball Finance.

Akibatnya, salah satu tugas penting dalam Snowball Finance adalah terus meningkatkan stabilitas, termasuk optimasi kinerja layanan pasar. Meskipun demikian, selama periode puncak lalu lintas, beberapa sistem mungkin masih mengalami respons yang lambat atau bahkan menjadi tidak tersedia karena lonjakan data, yang memengaruhi pengalaman pengguna.

Dalam konteks ini, Snowball Finance telah meluncurkan rencana transformasi layanan aktif-aktif untuk menyediakan layanan yang stabil dan berkualitas tinggi kepada investor, di mana Apache APISIX sangat menyederhanakan implementasinya. Selain itu, sebagai gateway API cloud-native, APISIX memiliki komunitas yang aktif dan ekosistem yang kaya, mendukung banyak plugin. Keunggulan ini juga memberikan fondasi yang baik untuk evolusi arsitektur cloud-native Snowball Finance.

Masalah dalam Transformasi Aktif-Aktif

Pada saat menerapkan arsitektur standalone, lalu lintas pengguna masuk melalui Server Load Balancing (SLB), melewati gateway untuk pemrosesan logika umum yang sederhana, dan kemudian diteruskan ke layanan backend. Layanan backend, melalui modul autentikasi terintegrasi, memulai autentikasi pengguna dengan Pusat Pengguna Snowball menggunakan SDK dan melanjutkan pemrosesan berikutnya setelah autentikasi berhasil.

Dalam skenario bisnis praktis, beberapa masalah telah muncul secara bertahap.

1. Modul Autentikasi SDK yang Kompleks

Saat menerapkan transformasi aktif-aktif, penyedia dan konsumen microservices tidak dapat di-deploy dan diluncurkan secara bersamaan. Ketika layanan pasar Snowball Finance pertama kali diluncurkan di cloud, tetapi pusat pengguna belum didukung di cloud, terjadi panggilan lintas pusat data. Menurut statistik dari pusat pengguna, panggilan RPC-nya mencapai sekitar puluhan miliar per hari, dan volume puncak dapat mencapai 50.000 QPS, yang dapat mengakibatkan latensi yang lebih tinggi.

Pada saat yang sama, logika autentikasi Snowball Finance sangat kompleks. Selain protokol OAuth2.0/JWT, banyak faktor yang perlu diperhatikan, seperti versi klien dan beberapa APPS di bawah Snowball Finance. Selain itu, modul autentikasi tertanam dalam layanan sehingga peningkatan menjadi lebih sulit.

2. Fungsi OpenResty yang Terbatas

Snowball Finance sebelumnya menggunakan OpenResty sebagai gateway-nya, tetapi OpenResty lemah dalam beberapa fungsi. Oleh karena itu, pengembang perlu melakukan lebih banyak kustomisasi saat mengintegrasikan OpenResty dengan sistem pemantauan yang ada. Selain itu, insinyur DevOps perlu menambahkan skrip khusus untuk mengimplementasikan proses pengembangan kedua.

3. Ketergantungan pada Pusat Registri yang Dikembangkan Sendiri

Saat ini, Snowball Finance melakukan registrasi layanan HTTP dengan meminta Pusat Registri untuk mendaftarkannya ke gateway saat layanan backend dimulai dan menghapus node layanan saat layanan berhenti. Pusat registri akan secara berkala memeriksa kesehatan node layanan. Namun, dibandingkan dengan proyek open-source, biaya pemeliharaan layanan yang dikembangkan sendiri lebih tinggi.

Pemilihan Teknologi API Gateway

Berdasarkan masalah yang terungkap secara bertahap dalam skenario praktik bisnis, Tim Infrastruktur Snowball telah memulai penelitian tentang produk gateway.

Tim internal berharap dapat memastikan transparansi bisnis dan meminimalkan perubahan sambil tidak memperkenalkan terlalu banyak variabel. Tim juga ingin menyelesaikan masalah secara seragam di tingkat infrastruktur dan menyelesaikan layanan autentikasi dalam pusat data lokal. Mempertimbangkan hal di atas, Snowball Finance memutuskan untuk memindahkan layanan autentikasi ke API gateway.

Snowball Finance berharap API gateway baru dapat memenuhi persyaratan berikut:

• Kinerja tinggi
• Skalabilitas yang kuat
• Dukungan untuk banyak protokol
• Biaya rendah untuk autentikasi gateway

Berikut adalah daftar pemilihan teknologi API gateway secara rinci di antara OpenResty, Spring Gateway, Kong, dan APISIX.

Gateway	Keunggulan	Kekurangan	Biaya O&M	Ketersediaan
OpenResty	Sangat dapat disesuaikan dan stabil	Observabilitas yang buruk	Tinggi	Tinggi
Spring Gateway	Ramah untuk pengembangan Java	tingkat kinerja tidak memenuhi persyaratan	Sedang	Sedang
Kong	Kuat dan kaya fungsi	Basis data PostgreSQL single-point	Rendah	Sedang
APISIX	Cloud-native mendukung banyak bahasa pemrograman dan memiliki skalabilitas yang kuat	/	Rendah	Tinggi

Setelah mempertimbangkan permintaan internal dan membandingkan produk gateway populer di pasar, Snowball Finance akhirnya memilih Apache APISIX untuk arsitektur selanjutnya.

Praktik Berdasarkan Apache APISIX

Arsitektur yang Disesuaikan

Seperti yang ditunjukkan pada gambar di atas, arsitektur aktif-aktif saat ini dari layanan pasar Snowball ditampilkan di sebelah kiri, yang sesuai dengan arsitektur di pusat data asli dengan sedikit modifikasi. Sisi kanan menunjukkan arsitektur aktif-aktif berdasarkan desain multi-region setelah migrasi ke cloud.

Snowball Finance terutama melakukan penyesuaian berikut berdasarkan APISIX:

• Menyatukan modul autentikasi ke lapisan proxy dan menggunakan APISIX untuk autentikasi seragam. Untuk tipe JWT, plugin jwt-auth APISIX dapat digunakan untuk autentikasi lokal secara langsung.
• Kompatibel dengan OAuth 2.0, dan memanfaatkan APISIX untuk memanggil Pusat Pengguna Snowball Finance untuk pemrosesan.
• Terhubung dengan pusat registri layanan RPC backend Snowball Finance untuk menggunakan layanan backend-nya untuk autentikasi ketika autentikasi JWT gagal.

Skenario Aplikasi

Setelah layanan backend terhubung ke APISIX, beberapa praktik terutama dilakukan dalam aspek autentikasi gateway dan observabilitas.

Skenario 1: Autentikasi Gateway

Seperti yang disebutkan sebelumnya, arsitektur sebelumnya Snowball Finance tidak memiliki metode autentikasi yang seragam. Salah satu metode bergantung pada sisi aplikasi internal, yang menggunakan SDK untuk memanggil pusat pengguna untuk autentikasi, sementara yang lain menggunakan autentikasi JWT. Ketika kedua metode autentikasi ini ada bersama-sama, hal ini menyebabkan masalah skalabilitas dan pemeliharaan.

1. Setelah mengintegrasikan APISIX sebagai gateway, Snowball Finance menggunakan lapisan gateway APISIX untuk mengelola autentikasi secara seragam. Metode autentikasi JWT asli diganti dengan plugin jwt-auth resmi. Mengonfigurasi dan menggunakan plugin jwt-auth relatif sederhana: hanya dengan mengonfigurasi informasi relevan seperti rute dan upstream di Dashboard, dan plugin akan diaktifkan.
2. Snowball Finance menggunakan plugin grpc-transcode untuk memproksi panggilan layanan autentikasi untuk menangani metode autentikasi terkait OAuth 2.0 sebelumnya.

Snowball Finance secara internal mempertimbangkan tiga solusi berikut untuk memanggil gRPC untuk mengimplementasikan autentikasi:

• Solusi 1: Menggunakan Lua untuk memanggil gRPC secara langsung. Karena solusi ini memerlukan pertimbangan implementasi terkait seperti load balancing dan upstream dinamis, prosesnya akan lebih rumit, sehingga dibatalkan.
• Solusi 2: Menggunakan coroutine Lua untuk memanggil kembali logika Golang. Snowball Finance membatalkan cara ini karena kurangnya pengalaman praktis yang sesuai.
• Solusi 3: Menggunakan Lua untuk melakukan panggilan HTTP, dan antarmuka gRPC diimplementasikan menggunakan plugin grpc-transcode APISIX. Berkat iterasi optimasi plugin yang cepat dari komunitas APISIX, Snowball Finance akhirnya memilih opsi ini untuk mengimplementasikan panggilan gRPC.

Saat ini, sinkronisasi manual file protokol buffer diperlukan selama eksekusi. Ini karena jika pusat pengguna memodifikasi file protokol buffer, yang tidak cocok dengan versi yang disimpan oleh APISIX, dapat mengakibatkan masalah autentikasi.

Skenario 2: Pemantauan Multi-Dimensi di Bawah Observabilitas

Perlu memantau banyak metrik setelah peluncuran situs web di Snowball Finance, terutama berfokus pada tiga bagian berikut:

• Status koneksi NGINX dan lalu lintas masuk/keluar
• Tingkat kode status kesalahan HTTP (digunakan untuk memecahkan masalah layanan atau masalah upstream/downstream)
• Latensi permintaan APISIX (waktu yang dikonsumsi oleh eksekusi logika saat APISIX meneruskan permintaan)

Misalnya, dalam beberapa kasus, latensi APISIX tampak tinggi (seperti yang ditunjukkan pada gambar di bawah), yang terkait dengan logika perhitungan latensi. Saat ini, logikanya adalah waktu yang dikonsumsi oleh satu permintaan HTTP pada NGINX dikurangi latensi permintaan ini yang dirutekan ke upstream. Perbedaan antara dua konsumsi waktu tersebut adalah metrik latensi APISIX.

Setelah menggunakan APISIX, menambahkan atau memodifikasi beberapa plugin akan menyebabkan beberapa perubahan logika, yang dapat menyebabkan penyimpangan dalam data terkait latensi. Untuk menghindari kebingungan atas keaslian data, Snowball Finance juga menambahkan plugin pemantauan latensi. Sambil memastikan keakuratan setiap pemantauan data, juga memudahkan untuk melacak masalah sebelumnya, sehingga memfasilitasi pemecahan masalah.

Juga dimungkinkan untuk memanfaatkan kemampuan observabilitas APISIX untuk mengumpulkan Access log dan mengirimkannya ke dashboard lalu lintas dalam format yang terstandarisasi untuk dilihat dan diringkas. Ini memfasilitasi pemahaman proaktif tentang tren keseluruhan dari berbagai perspektif, mengidentifikasi potensi masalah dan menanganinya dengan cepat.

Skenario 3: Skalasi Registri ZooKeeper

Di Snowball Finance, panggilan gRPC didaftarkan dan ditemukan berdasarkan registri Zookeeper. Dalam proses implementasi autentikasi, ketika verifikasi JWT lokal gagal, API gateway perlu mengakses layanan gRPC di Pusat Pengguna Snowball Finance untuk autentikasi, yang memerlukan API gateway untuk mendapatkan daftar alamat layanan gRPC backend dari pusat registri.

Plugin resmi APISIX apisix-seed dapat mengintegrasikan ZooKeeper untuk penemuan layanan. Snowball Finance telah melakukan beberapa kustomisasi yang lebih spesifik untuk bisnisnya sendiri.

Implementasi spesifik terutama pada node konten APISIX. Saat proses Worker dimulai, ia akan memeriksa cluster ZK-Rest seperti yang ada pada gambar di bawah, dan kemudian secara teratur menarik data sumber dan informasi seluruh layanan, dan memperbaruinya ke cache lokal proses Worker untuk memperbarui daftar layanan.

Dapat juga dilihat dari gambar di atas bahwa cluster ZK-Rest mengakses data ZooKeeper dalam bentuk Rest. Hanya dengan menambahkan instance-nya dapat mencapai fitur ketersediaan tinggi, menghilangkan beberapa operasi rumit. Namun operasi ini juga membawa kerugian yang lebih jelas. Saat memeriksa cluster ZK-Rest secara berkala, dapat menyebabkan penundaan dalam memperbarui daftar layanan.

Ringkasan dan Pandangan ke Depan

Saat ini, Apache APISIX berjalan dengan baik sebagai lapisan gateway di dalam Snowball Finance. Secara khusus:

• Autentikasi seragam, pemutusan sirkuit, dan pembatasan laju diimplementasikan di lapisan gateway, mengurangi kopling sistem secara keseluruhan dan meningkatkan kualitas layanan di bawah pusat data ganda.
• Dengan bantuan pemantauan APISIX, solusi pemantauan seragam dari gateway ke layanan dibangun, memberikan dukungan yang baik untuk pemecahan masalah global.
• Pendekatan implementasi yang elegan disediakan untuk konversi dan manajemen layanan protokol gRPC.

Dalam penggunaan selanjutnya, Snowball Finance juga berencana untuk:

• Menerapkan APISIX Ingress Controller ke cluster K8s.
• Menggunakan plugin grpc-transcode untuk konversi protokol HTTP/gRPC untuk mencapai antarmuka backend yang seragam.
• Menggunakan plugin traffic-split untuk pelabelan lalu lintas, terhubung ke pusat registri Nacos, dan mengimplementasikan rilis canary serta tata kelola layanan lainnya.

Dalam rencana selanjutnya, Apache APISIX akan digunakan untuk menggantikan OpenResty yang ada dan akhirnya mencapai manajemen lalu lintas utara-selatan sepanjang siklus hidup.