Sticky Sessions dengan Apache APISIX - Teori

Sticky sessions, juga dikenal sebagai session affinity, adalah mekanisme di mana komponen routing yang bertindak sebagai fasad selalu mengarahkan permintaan ke node upstream yang sama. Dalam posting ini, saya akan menjelaskan alasan di balik sticky sessions, alternatif yang tersedia, dan cara mengimplementasikannya melalui Apache APISIX.

Mengapa Sticky Sessions?

Sticky sessions menjadi populer ketika kita menyimpan state pada node upstream, bukan di database. Saya akan menggunakan contoh toko e-commerce yang disederhanakan untuk menjelaskan lebih lanjut.

Dasar-dasar dari situs e-commerce kecil dapat terdiri dari aplikasi web dan database.

Arsitektur dasar aplikasi e-commerce

Jika bisnis berhasil, itu akan tumbuh, dan Anda perlu menskalakan arsitektur ini pada suatu titik. Setelah Anda tidak dapat menskalakan secara vertikal (mesin yang lebih besar), Anda harus menskalakan secara horizontal (lebih banyak node). Dengan node aplikasi tambahan, Anda juga memerlukan mekanisme load balancer di depan node aplikasi web untuk mendistribusikan beban di antara mereka.

Arsitektur Load Balancing untuk node tambahan

Mengakses database setiap kali adalah operasi yang mahal. Ini baik untuk data yang jarang diakses. Namun, kita ingin menampilkan konten keranjang untuk setiap permintaan. Beberapa alternatif tersedia untuk mempercepat proses. Jika kita asumsikan bahwa aplikasi web menggunakan Server-Side Rendering, solusi klasik adalah menyimpan data terkait keranjang di memori pada node aplikasi web.

Namun, jika kita menyimpan keranjang pengguna X di node 1, kita perlu memastikan bahwa kita mengarahkan setiap permintaan pengguna X ke node yang sama. Jika tidak, mereka akan merasa seperti kehilangan konten keranjang mereka. Sticky sessions, atau session affinity, adalah mekanisme yang secara konsisten mengarahkan pengguna yang sama ke node yang sama.

Keterbatasan Sticky Sessions

Sebelum melanjutkan, saya harus menjelaskan keterbatasan signifikan dari sticky sessions. Jika node aplikasi web yang menyimpan data mati karena alasan apa pun, data tersebut akan hilang secara permanen. Untuk skenario e-commerce di atas, ini berarti pengguna akan kehilangan keranjang mereka sesekali, yang tidak dapat diterima dari sudut pandang bisnis.

Untuk alasan ini, sticky sessions harus berjalan beriringan dengan replikasi session: data yang disimpan pada satu node harus disalin dan disinkronkan dengan semua node lainnya.

Meskipun replikasi session ada di semua tumpukan teknologi, tidak ada spesifikasi terkait. Saya familiar dengan JVM, jadi berikut adalah beberapa opsi:

Tomcat menawarkan replikasi session secara langsung
Hazelcast menawarkan solusi in-memory terkluster yang dapat Anda integrasikan di berbagai tingkat
Spring Session adalah lapisan abstraksi di atas solusi tertentu

Ketika data direplikasi di semua node (atau kluster remote), Anda mungkin berpikir bahwa Anda tidak lagi memerlukan sticky sessions. Ini benar jika hanya mempertimbangkan ketersediaan dan bukan kinerja. Ini tentang lokalisasi data: mengambil data pada node saat ini lebih cepat daripada dari tempat lain melalui jaringan.

Sticky Sessions pada Apache APISIX

Sticky sessions adalah fitur yang harus dimiliki oleh setiap Load Balancer, Reverse Proxy, dan API Gateway yang layak. Namun, saya harus mengakui bahwa dokumentasi Apache APISIX memerlukan titik masuk yang mudah ke dalam topik ini.

Apache APISIX mengikat route ke upstream. Sebuah upstream terdiri dari satu atau lebih node. Ketika permintaan cocok dengan route, Apache APISIX harus memilih di antara semua node yang tersedia untuk meneruskan permintaan. Secara default, algoritmanya adalah weighted round-robin. Round-robin menggunakan satu node setelah yang lain, dan setelah yang terakhir, kembali ke yang pertama. Dengan weighted round-robin, bobot memengaruhi berapa banyak permintaan yang diteruskan Apache APISIX ke sebuah node sebelum beralih ke node berikutnya.

Namun, algoritma lain tersedia:

Consistent hashing
Exponentially Weighted Moving Average Chart
Least connection
Buatan sendiri

Consistent hashing memungkinkan penerusan ke node yang sama tergantung pada beberapa nilai: variabel NGINX, header HTTP, cookie, dll.

Ingatlah bahwa HTTP adalah protokol tanpa state, jadi server aplikasi mengatur cookie pada respons pertama untuk melacak pengguna di seluruh permintaan HTTP. Inilah yang kita sebut "session". Kita perlu mengetahui nama cookie session yang mendasarinya. Server aplikasi yang berbeda memberikan cookie yang berbeda:

JSESSIONID untuk server berbasis JVM
PHPSESSID untuk PHP
ASPSESSIONID untuk ASP.Net
dll.

Saya akan menggunakan Tomcat biasa, jadi cookie session-nya adalah JSESSIONID. Oleh karena itu, dokumentasi Apache APISIX untuk dua node adalah sebagai berikut:

routes:
  - uri: /*
    upstream:
      nodes:
        "tomcat1:8080": 1            #1
        "tomcat2:8080": 1            #1
      type: chash                    #2
      hash_on: cookie                #3
      key: cookie_JSESSIONID         #4

Tentukan node upstream
Pilih algoritma consistent hashing
Hash pada cookie
Tentukan cookie yang akan di-hash

Kesimpulan

Dalam posting ini, kami merinci sticky sessions, bahwa Anda harus selalu menggunakan replikasi session dengan sticky sessions, dan cara mengimplementasikan sticky sessions pada Apache APISIX.

Untuk lebih lanjut: