Mendengar Anda.
Dan selamat datang kembali.
Sekarang, dalam video hari ini, kita akan membahas tentang sesi tempel.
Sekarang, sebelum kita melanjutkan dan memahami tentang topik ini, mari kita lihat tantangan yang umum terjadi.
Sekarang, secara umum dalam pengaturan berbasis penyeimbang beban, lalu lintas dari pengguna didistribusikan di antara beberapa
server backend.
Sebagai contoh, katakanlah seorang pengguna pertama kali melakukan permintaan, permintaan tersebut mungkin akan masuk ke server satu.
Permintaan kedua yang dia buat, mungkin akan masuk ke server kedua dan seterusnya.
Jadi lalu lintas akan terdistribusi.
Hal yang sama juga berlaku untuk pengguna.
Begitu juga dengan penggunanya.
Tiga.
Sekarang, jika permintaan berikutnya dialihkan ke server yang berbeda sama sekali, maka informasi sesi juga
akan hilang.
Sebagai contoh, katakanlah Anda akan pergi ke bank.
Anda memiliki beberapa masalah.
Anda pergi ke bank, Anda menjelaskan seluruh masalahnya kepada seseorang, orang yang sekarang.
A telah meminta Anda untuk datang besok agar solusi yang tepat dapat diterapkan.
Sekarang, Anda pergi besok dan orang tersebut tidak ada di sana.
Jadi apa yang terjadi?
Anda sekarang pergi ke seseorang.
B, sekarang orang B tidak tahu persis tentang masalah Anda.
Jadi sekali lagi, Anda harus menjelaskan seluruh masalah kepada orang B. Jadi inilah yang sebenarnya terjadi dalam pengaturan
berbasis penyeimbang beban juga.
Nah, pada umumnya untuk website statis, hal ini tidak terlalu menjadi masalah besar karena memang website bersifat statis.
Kedua server memiliki set halaman yang sama untuk situs web dinamis.
Ini benar-benar menjadi masalah.
Nah, salah satu cara untuk mengatasi hal ini adalah melalui sesi tempel.
Jadi, sesi Sticky mengacu pada fitur dari banyak penyeimbang beban untuk meng-root permintaan untuk sesi tertentu ke mesin
fisik yang sama yang melayani permintaan pertama dari sesi tersebut.
Jadi seorang pengguna, permintaan pertama yang dibuatnya masuk ke server.
Sekarang permintaan berikutnya meminta tiga permintaan untuk semua permintaan yang akan dia buat.
Semua permintaan itu akan masuk ke server itu sendiri.
Sekali lagi, dengan mengambil contoh sebuah bank, Anda pergi pada hari pertama, Anda bertemu dengan orang A pada hari kedua, Anda bertemu dengan
orang B pada hari ketiga, Anda bertemu dengan orang C. Jadi, Anda bertemu dengan orang yang sama di bank tersebut dan dia mengetahui semua
masalah Anda yang sedang berlangsung dan juga masalah Anda yang telah berlalu.
Jadi, dia akan dapat membantu Anda dengan cara yang jauh lebih efisien.
Jadi, di sinilah sesi tempel juga berperan penting.
Sekarang, sesi sticky juga didukung di sisi keseimbangan beban.
Jadi, mari kita bahas tentang penyeimbang beban aplikasi terlebih dahulu.
Jadi secara default, aplikasi menyeimbangkan setiap permintaan secara independen ke target yang terdaftar berdasarkan
algoritme penyeimbangan beban yang dipilih.
Sangat mirip dengan apa yang kita bahas pada slide pertama dengan permintaan yang mungkin pertama kali masuk ke server satu,
kemudian mungkin masuk ke server dua dan seterusnya.
Namun, jika Anda membutuhkannya, Anda juga dapat menggunakan fitur sesi lengket untuk memungkinkan
penyeimbang beban mengikat sesi pengguna ke target tertentu.
Sekarang jika Anda melihat Anda memiliki web browser, satu web browser, dua web browser, satu membuat permintaan, satu
atau dua adalah tiga ke load balancer, load balancer akan mengarahkan.
Semua permintaan satu atau dua adalah tiga untuk EC dua contoh yang sama.
Sekarang, pengaturan ini dapat diterapkan setelah sesi tempel diaktifkan.
Jika tidak, penyeimbang beban mungkin akan mengarahkan permintaan r satu ke e.
c2122e.
c2232, e, c23 dan seterusnya.
Jadi mari kita lakukan satu hal.
Mari kita lanjutkan dan lihat lebih dalam.
Sekarang untuk pengaturan hari ini, saya memiliki dua penyeimbang beban yang tersedia.
Yang pertama adalah penyeimbang beban aplikasi dan yang kedua adalah penyeimbang beban klasik dan kita akan melihat bagaimana
kita dapat mengaktifkan sesi sticky di sini.
Pertama, mari kita lanjutkan dan jelajahi penyeimbang beban aplikasi.
Sekarang, pada tahap ini Anda tidak benar-benar mengaktifkan sesi lengket.
Mari kita lanjutkan dan salin ini.
Sekarang, sebelum kita lanjutkan dan menjelajahi hal ini, izinkan saya menunjukkan contoh-contohnya.
Jadi ada dua EC, dua instance yang menjalankan Engine X dan penyeimbang beban, baik yang klasik
maupun aplikasi dikaitkan dengan dua instance C ini.
Jadi, izinkan saya melanjutkan dan menempelkan URL dari penyeimbang beban aplikasi.
Pertama, masuk ke EC dua contoh, nomor dua, yang memiliki situs web kelas halaman.
Jika saya refresh, saya masuk ke situs web yang mudah untuk dicontoh.
Satu mari kita menyegarkan diri.
Sekarang beralih ke situs web kedua.
Jadi, kondisi klasik load balancing di mana beberapa permintaan dialihkan ke server yang berbeda secara bersamaan.
Sekarang katakanlah kita tidak benar-benar menginginkannya.
Jadi apa yang bisa kita lakukan, kita bisa mengaktifkan sesi sticky.
Namun, sebelum kita mengaktifkan sesi lengket.
Izinkan saya menunjukkan kepada Anda header respons yang tepat dari HTTP.
Jadi, ini semua adalah tajuk respons.
Sekarang kita akan mencatatnya dan kita akan melihat ke header respons setelah sesi tempel
diaktifkan.
Jadi sekarang di dalam load balancer, khususnya untuk load balancer aplikasi, mari kita masuk ke
grup target yang terkait dengan ALB kita.
Hanya ada satu kelompok sasaran yang terkait.
Mari kita lanjutkan dan edit atribut grup target dan Anda memiliki opsi untuk menempel.
Mari kita aktifkan kelengketan.
Dan sekarang ini menanyakan durasi kelengketan, yang bisa dari satu detik hingga tujuh hari.
Anda juga dapat memilih hal-hal yang sesuai.
Katakanlah lengket dalam satu hari.
Jadi saya akan pergi dan menyimpan kembaliannya.
Jadi sekarang kita memiliki sesi lengket, aktifkan permintaan akan masuk ke EC tertentu dua instance hanya
untuk durasi sesi lengket kita.
Mari kita lanjutkan dan jelajahi.
Jadi, izinkan saya menyegarkan halaman.
Ini menuju ke situs web dua.
Mari kita menyegarkan diri lagi.
Sekali lagi, situs web kedua, Mari kita refresh situs web ketiga, situs web keempat, dan situs
web kelima.
Jadi, inilah yang dapat dilakukan oleh sesi tempel.
Sekarang, dengan cara yang sama, mari kita kembali membuat permintaan panggilan.
Dan sekarang, Anda melihat ke dalam header respons antara yang pertama dan yang kedua.
Salah satu hal tambahan yang ditambahkan adalah cookie.
Nama cookie adalah AILBHE plus dan kemudian Anda memiliki informasi terkait cookie.
Jadi, setelah Anda mengaktifkan sesi tempel, Anda juga harus menambahkan cookie.
Sekarang, cookie adalah sesuatu yang akan dikirim kembali oleh browser web Anda ke penyeimbang beban.
Load balancer akan membaca cookie dan akan mengidentifikasi bahwa pengguna ini diarahkan ke EC dua instance
satu.
Jadi, begitu cookie membaca cookie lagi, ia akan mengarahkan pengguna ke EC two instance satu itu sendiri.
Jadi, ini adalah bagaimana penyeimbang beban mengetahui bahwa klien tertentu perlu diarahkan ke jaringan server
tertentu.
Sekarang, ketika berbicara tentang penyeimbang beban aplikasi, Anda dapat mengatur sesi lengket pada tingkat
grup target.
Namun, untuk penyeimbang beban klasik, Anda dapat melanjutkan.
Dan aktifkan kelengketan.
Jadi, saat ini lengket dinonaktifkan.
Anda bisa melanjutkan dan mengaktifkan lengket di sini sendiri.
Mirip dengan penyeimbang beban aplikasi, Anda dapat menentukan periode kedaluwarsa.
Jadi, mari kita segera merevisi alur kerja.
Jadi, setiap kali klien membuat permintaan ke penyeimbang beban, penyeimbang beban akan membuat cookie.
Jadi dalam kasus ini, cookie menyatakan target sama dengan EC dua satu.
Jadi permintaan diarahkan ke EC dua satu dan cookie dikirim kembali ke klien.
Sekarang klien ketika dia membuat permintaan berikutnya ke penyeimbang beban, klien harus mengirim cookie
yang dikirim oleh penyeimbang beban.
Setelah klien mengirim kembali cookie ke load balancer.
Penyeimbang beban dapat memahami bahwa cookie ini dikaitkan dengan EC dua satu, dan permintaan
kedua juga akan dikirim ke EC.
Dua satu.
Jika cookie tidak benar-benar dikirim lagi, hal ini tergantung pada algoritme yang digunakan.
Jika cookie tidak benar-benar dikirim, penyeimbang beban elastis mungkin tidak benar-benar tahu dan mungkin juga mengarahkan
permintaan itu ke EC two instance.
Jadi, ini adalah alur kerja tingkat tinggi pada salah satu cara di mana sesi lengket dibuat.
Sekarang, mari kita lihat secara singkat keuntungan dari sesi sticky.
Pertama, ketika sesi sticky digunakan, server tidak perlu bertukar data sesi,
yang dapat meminimalkan transfer data.
Jika tidak, data sesi perlu dipertukarkan di antara semua server sehingga mereka dapat mengingat untuk
apa sebenarnya pengguna datang.
Kedua, sesi sticky dapat memungkinkan pemanfaatan cache RAM yang lebih baik yang dapat menghasilkan respons yang lebih baik.
Sekarang, mari kita juga melihat beberapa kerugiannya.
Pertama, dengan sesi yang lengket, penyeimbangan beban lalu lintas secara keseluruhan di antara server dapat terpengaruh.
Sangat penting.
Bagian dua Ingat, bisa saja server tertentu kelebihan beban jika terlalu banyak sesi yang terakumulasi atau
jika sesi lengket tertentu membutuhkan sumber daya dalam jumlah besar.
Jadi, jika sepuluh pengguna diarahkan ke instance EC2, satu sesi sticky diaktifkan untuk
durasi tiga hari.
Dan jika kesepuluh server tersebut diarahkan ke EC dua instance satu, maka EC dua instance dua akan
kosong sama sekali.
Tidak ada sesi atau tidak ada koneksi sama sekali.
Jadi sekarang apa yang akan terjadi?
EC dua contoh satu kelebihan beban karena semua pengguna yang memiliki cookie yang ada diarahkan
ke EC dua contoh satu.
Jadi, hal ini bisa menjadi kerugian dari sesi yang lengket.
Bagus.
Jadi, ini adalah ikhtisar tingkat tinggi tentang dasar-dasar sesi tempel dan dengan ini akan mengakhiri
video hari ini.