Pola arsitektur infrastruktur yang dihosting pelanggan

Halaman ini membahas pola arsitektur yang paling umum untuk deployment yang dihosting pelanggan dan menjelaskan praktik terbaik untuk menerapkannya. Untuk menggunakan halaman ini secara efektif, Anda harus memahami konsep dan praktik arsitektur sistem.

Strategi alur kerja

Setelah Anda mengidentifikasi hosting mandiri sebagai opsi yang layak untuk penerapan Looker, langkah berikutnya adalah menguraikan strategi yang akan ditayangkan oleh deployment.

  1. Lakukan penilaian. Identifikasi daftar kandidat alur kerja yang telah direncanakan dan yang sudah ada.
  2. Cantumkan pola arsitektur yang berlaku. Dimulai dengan alur kerja kandidat yang teridentifikasi, identifikasi pola arsitektur yang berlaku.
  3. Prioritaskan dan pilih pola arsitektur yang optimal. Selaraskan pola arsitektur dengan tugas dan hasil yang paling penting.
  4. Mengonfigurasi komponen arsitektur dan men-deploy aplikasi Looker. Terapkan host, dependensi pihak ketiga, dan topologi jaringan yang diperlukan untuk membuat koneksi klien yang aman.

Opsi arsitektur

Virtual machine khusus

Salah satu opsi adalah menjalankan Looker sebagai satu instance di virtual machine (VM) khusus. Satu instance dapat melayani beban kerja yang menuntut dengan menskalakan host secara vertikal dan meningkatkan kumpulan thread default. Namun, overhead pemrosesan untuk mengelola heap Java yang besar akan menyebabkan penskalaan vertikal mengalami hukum hasil yang menurun. Umumnya dapat diterima untuk beban kerja kecil hingga sedang. Diagram berikut menggambarkan penyiapan default dan opsional antara instance Looker yang berjalan di VM khusus, repositori lokal dan jarak jauh, server SMTP, dan sumber data yang ditandai di bagian Kelebihan dan Praktik terbaik untuk opsi ini.

Diagram yang menggambarkan penyiapan default dan opsional antara Looker yang berjalan di VM khusus dengan repositori lokal dan jarak jauh, server SMTP, dan sumber data.

Kelebihan

  • VM khusus mudah di-deploy dan dikelola.
  • Database internal dihosting dalam aplikasi Looker.
  • Model Looker, repositori Git, server SMTP, dan komponen database backend dapat dikonfigurasi secara lokal atau jarak jauh.
  • Anda dapat mengganti server SMTP default Looker dengan server SMTP Anda sendiri untuk notifikasi email dan tugas terjadwal.

Praktik terbaik

  • Secara default, Looker dapat membuat repositori Git kosong untuk project. Sebaiknya siapkan repositori Git jarak jauh untuk redundansi.
  • Secara default, Looker dimulai dengan database HyperSQL dalam memori. Database ini praktis dan ringan, tetapi dapat mengalami masalah performa jika digunakan secara intensif. Sebaiknya gunakan database MySQL untuk deployment yang lebih besar. Sebaiknya lakukan migrasi ke database MySQL jarak jauh setelah file ~/looker/.db/looker.script mencapai 600 MB.
  • Deployment Looker Anda harus divalidasi terhadap layanan pemberian lisensi Looker; traffic keluar di port 443 diperlukan.
  • Deployment VM khusus dapat diskalakan secara vertikal dengan meningkatkan resource yang tersedia dan kumpulan thread Looker. Namun, peningkatan RAM tunduk pada hukum hasil yang semakin menurun setelah mencapai 64 GB, karena peristiwa pembersihan sampah memiliki thread tunggal dan menghentikan semua thread lain untuk dieksekusi. Node dengan 16 CPU dan RAM 64 GB adalah keseimbangan yang baik antara harga dan performa.
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 operasi per detik (IOPS) per GB.

Cluster VM

Menjalankan Looker sebagai cluster instance di beberapa VM adalah pola fleksibel yang mendapatkan manfaat dari redundansi dan failover layanan. Skalabilitas horizontal memungkinkan peningkatan throughput tanpa mengalami pembengkakan heap dan biaya pembersihan sampah yang berlebihan. Node memiliki opsi dedikasi beban kerja, yang memungkinkan beberapa opsi deployment disesuaikan dengan berbagai persyaratan bisnis. Deployment cluster memerlukan minimal satu administrator sistem yang memahami sistem Linux dan mampu mengelola bagian komponen.

Cluster standar

Untuk sebagian besar deployment standar, cluster node layanan yang identik sudah cukup. Semua node dalam cluster dikonfigurasi dengan cara yang sama dan semuanya berada dalam kumpulan load balancer yang sama. Tidak ada node dalam konfigurasi ini yang lebih atau kurang cenderung menayangkan permintaan pengguna Looker, tugas rendering, tugas terjadwal, permintaan API, dll.

Jenis konfigurasi ini cocok jika sebagian besar permintaan berasal langsung dari pengguna Looker yang menjalankan kueri dan berinteraksi dengan Looker. Hal ini mulai mengalami gangguan saat ada banyak permintaan yang berasal dari penjadwal, perender, atau sumber lain. Dalam hal ini, sebaiknya tentukan node layanan tertentu untuk menangani tugas seperti jadwal dan rendering.

Misalnya, pengguna biasanya menjadwalkan pengiriman data untuk dijalankan pada Senin pagi. Pengguna yang mencoba menjalankan kueri Looker pada Senin pagi mungkin mengalami masalah performa saat Looker menangani backlog permintaan terjadwal. Dengan meningkatkan jumlah node layanan, cluster memberikan peningkatan throughput yang proporsional di semua kemampuan Looker.

Diagram berikut menggambarkan cara permintaan ke Looker yang dibuat dari pengguna, aplikasi, dan skrip diseimbangkan di seluruh instance Looker yang dikelompokkan.

Permintaan ke Looker yang dibuat dari pengguna, aplikasi, dan skrip tersebar di seluruh load balancer di atas tiga node Looker dalam instance Looker yang dikelompokkan.

Kelebihan

  • Cluster standar memaksimalkan throughput umum dengan konfigurasi topologi cluster yang minimal.
  • VM Java mengalami penurunan performa pada nilai minimum memori yang dialokasikan sebesar 64 GB; inilah alasan penskalaan horizontal memiliki hasil yang lebih besar daripada penskalaan vertikal.
  • Konfigurasi cluster memastikan redundansi dan failover layanan.

Praktik terbaik

  • Setiap node Looker harus dihosting di VM khusus miliknya sendiri.
  • Load balancer, yang merupakan titik ingress cluster, harus berupa load balancer lapisan 4. Server harus memiliki waktu tunggu yang lama (3.600 detik), dilengkapi dengan sertifikat SSL yang ditandatangani, dan dikonfigurasi untuk meneruskan port dari 443 (https) ke 9999 (port yang diproses server Looker).
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 IOPS per GB.

Dev/Staging/Prod

Untuk kasus penggunaan yang memprioritaskan waktu aktif konten maksimum bagi pengguna akhir, sebaiknya gunakan lingkungan Looker terpisah untuk memisahkan pekerjaan pengembangan dan pekerjaan analisis. Dengan mengontrol perubahan lingkungan produksi di balik lingkungan pengembangan dan pengujian yang terisolasi, arsitektur ini mempertahankan lingkungan produksi yang sestabil mungkin.

Manfaat ini memerlukan penyiapan lingkungan yang saling terhubung dan penerapan siklus rilis yang andal. Deployment Dev/Staging/Prod juga memerlukan tim developer yang memahami Looker API dan Git untuk administrasi alur kerja.

Diagram berikut menggambarkan alur konten antara developer LookML yang mengembangkan konten di instance Dev, penguji jaminan kualitas (QA) yang menguji konten di instance QA, serta pengguna, aplikasi, dan skrip yang menggunakan konten di instance Produksi.

Konten dikembangkan di instance Dev, diuji di instance QA, dan digunakan oleh pengguna, aplikasi, dan skrip di instance Produksi.

Kelebihan

  • Validasi LookML dan konten terjadi di lingkungan non-produksi, yang memastikan bahwa setiap modifikasi pada logika model dapat diperiksa secara menyeluruh sebelum menjangkau pengguna produksi.
  • Fitur seluruh instance, seperti fitur Labs atau protokol autentikasi, dapat diuji secara terpisah sebelum diaktifkan di lingkungan produksi.
  • Kebijakan caching dan grup data dapat diuji di lingkungan non-produksi.
  • Pengujian mode produksi Looker dipisahkan dari lingkungan produksi yang bertanggung jawab untuk melayani pengguna akhir.
  • Rilis Looker dapat diuji di lingkungan non-produksi, sehingga memberi Anda cukup waktu untuk menguji fitur baru, perubahan alur kerja, dan masalah sebelum mengupdate lingkungan produksi.

Praktik terbaik

  • Isolasi berbagai aktivitas yang terjadi secara serentak di setidaknya tiga instance terpisah:
    • Instance pengembangan: Developer menggunakan lingkungan pengembangan untuk melakukan commit kode, melakukan eksperimen, memperbaiki bug, dan membuat kesalahan dengan aman.
    • Instance QA: Juga disebut sebagai lingkungan pengujian atau staging, tempat developer menjalankan pengujian manual dan otomatis. Lingkungan QA sangat kompleks dan dapat menghabiskan banyak resource.
    • Instance produksi: Di sinilah nilai diciptakan untuk pelanggan dan/atau bisnis. Produksi adalah lingkungan yang sangat terlihat dan harus bebas error.
  • Mempertahankan alur kerja siklus rilis yang terdokumentasi dan dapat diulang.
  • Jika perlu menayangkan developer dan penguji QA dalam jumlah besar, instance Dev dan/atau QA dapat dikelompokkan. Baik dibiarkan sebagai VM mandiri atau cluster VM, instance Dev dan QA tunduk pada pertimbangan arsitektur yang sama yang sebelumnya ditampilkan di bagian masing-masing.

Throughput penjadwalan tinggi

Untuk kasus penggunaan yang memerlukan throughput pengiriman data terjadwal yang tinggi dan pengiriman yang andal dan tepat waktu, sebaiknya konfigurasi menyertakan cluster dengan kumpulan node yang sepenuhnya didedikasikan untuk penjadwalan. Konfigurasi ini akan membantu menjaga web dan aplikasi tersemat tetap cepat dan responsif. Manfaat ini memerlukan penyiapan node dengan opsi startup yang disesuaikan dan aturan load balancing yang tepat, seperti yang digambarkan dalam diagram berikut dan diuraikan di bagian Kelebihan dan Praktik terbaik untuk opsi ini.

Konfigurasi cluster Looker dengan kumpulan node yang sepenuhnya didedikasikan untuk penjadwalan.

Kelebihan

  • Dengan menetapkan node untuk fungsi tertentu, resource untuk penjadwalan akan dikelompokkan dari fungsi pengembangan dan analisis ad hoc.
  • Pengguna dapat mengembangkan LookML dan menjelajahi konten tanpa mengambil siklus dari node yang bertanggung jawab untuk melayani pengiriman data terjadwal.
  • Traffic pengguna yang tinggi yang disalurkan ke node reguler tidak akan menghambat beban kerja terjadwal yang dilayani oleh node penjadwalan.

Praktik terbaik

  • Setiap node Looker harus dihosting di VM khusus miliknya sendiri.
  • Load balancer, yang merupakan titik ingress cluster, harus berupa load balancer lapisan 4. Server harus memiliki waktu tunggu yang lama (3.600 detik), dilengkapi dengan sertifikat SSL yang ditandatangani, dan dikonfigurasi untuk meneruskan port dari 443 (https) ke 9999 (port yang diproses server Looker).
  • Hapus node penjadwal dari aturan load balancing agar tidak menayangkan traffic pengguna akhir dan permintaan API internal.
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 IOPS per GB.

Throughput rendering tinggi

Untuk kasus penggunaan yang memerlukan throughput laporan rendering yang tinggi, sebaiknya konfigurasikan cluster dengan kumpulan node yang sepenuhnya didedikasikan untuk rendering. Merender file PDF atau gambar PNG/JPEG adalah operasi yang relatif mahal di Looker. Rendering dapat menggunakan banyak memori dan CPU, dan jika Linux mengalami tekanan memori, proses yang sedang berjalan dapat dihentikan. Karena penggunaan memori tugas render tidak dapat ditentukan sebelumnya, memulai tugas render dapat menyebabkan proses Looker dihentikan. Mengonfigurasi node rendering khusus akan memungkinkan penyesuaian tugas render secara optimal sekaligus mempertahankan responsivitas aplikasi interaktif dan tersemat.

Manfaat ini memerlukan penyiapan node dengan opsi startup yang disesuaikan dan aturan load balancing yang tepat seperti yang digambarkan dalam diagram berikut dan dijelaskan di bagian Kelebihan dan Praktik terbaik untuk opsi ini. Selain itu, node rendering mungkin memerlukan lebih banyak resource host daripada node standar, karena layanan rendering Looker bergantung pada proses Chromium pihak ketiga yang berbagi waktu dan memori CPU.

Konfigurasi cluster Looker dengan kumpulan node yang didedikasikan untuk rendering.

Kelebihan

  • Dengan menetapkan node untuk fungsi tertentu, resource untuk rendering akan dikelompokkan dari fungsi pengembangan dan analisis ad hoc.
  • Pengguna dapat mengembangkan LookML dan menjelajahi konten tanpa mengambil siklus dari node yang bertanggung jawab untuk merender PNG dan PDF.
  • Traffic pengguna yang tinggi yang disalurkan ke node reguler tidak akan menghambat beban kerja rendering yang dilayani oleh node rendering.

Praktik terbaik

  • Setiap node Looker harus dihosting di VM khusus miliknya sendiri.
  • Load balancer, yang merupakan titik ingress cluster, harus berupa load balancer lapisan 4. Server harus memiliki waktu tunggu yang lama (3.600 detik), dilengkapi dengan sertifikat SSL yang ditandatangani, dan dikonfigurasi untuk meneruskan port dari 443 (https) ke 9999 (port yang diproses server Looker).
  • Hapus node rendering dari aturan load balancing, sehingga node tersebut tidak menayangkan traffic pengguna akhir dan permintaan API internal.
  • Alokasikan memori yang relatif lebih sedikit ke Java di node rendering untuk memberi proses Chromium buffering memori yang lebih besar. Alih-alih mengalokasikan 60% memori ke Java, alokasikan 40-50%.
  • Risiko tekanan memori telah dikurangi pada node non-render, sehingga jumlah memori yang dikhususkan untuk Looker dapat ditingkatkan. Daripada 60% default, pertimbangkan angka yang lebih tinggi seperti 80%.
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 IOPS per GB.