Pola arsitektur infrastruktur yang dihosting pelanggan

Halaman ini adalah bagian dari rangkaian multi-bagian yang membahas hosting Looker, metodologi deployment, dan praktik terbaik untuk komponen yang terlibat. Halaman ini mengeksplorasi pola arsitektur paling umum untuk deployment yang dihosting pelanggan dan menjelaskan praktik terbaik untuk menerapkannya. Untuk menggunakan halaman ini secara efektif, Anda harus terbiasa dengan konsep dan praktik arsitektur sistem.

Rangkaian ini terdiri dari tiga bagian:

Strategi alur kerja

Setelah Anda mengidentifikasi hosting mandiri sebagai opsi yang tepat untuk implementasi Looker, langkah berikutnya adalah menguraikan strategi yang akan dilayani oleh deployment.

  1. Lakukan penilaian. Identifikasi daftar kandidat alur kerja yang direncanakan dan yang sudah ada.
  2. Buat daftar pola arsitektur yang berlaku. Dimulai dengan alur kerja kandidat yang diidentifikasi, 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 opsinya adalah menjalankan Looker sebagai instance tunggal di mesin virtual (VM) khusus. Satu instance dapat melayani beban kerja yang berat dengan menskalakan host secara vertikal dan meningkatkan kumpulan thread default. Namun, overhead pemrosesan mengelola heap Java besar membuat penskalaan vertikal sesuai dengan hukum pengurangan hasil. Hal ini umumnya dapat diterima untuk beban kerja kecil hingga sedang. Diagram berikut menunjukkan penyiapan default dan opsional antara instance Looker yang berjalan di VM khusus, repositori lokal dan jarak jauh, server SMTP, serta 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, serta sumber data.

Kelebihan

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

Praktik terbaik

  • Secara default, Looker dapat membuat repositori Git kosong untuk sebuah project. Sebaiknya siapkan repositori Git jarak jauh untuk redundansi.
  • Secara default, Looker dimulai dengan database HyperSQL dalam memori. Database ini nyaman dan ringan, tetapi dapat mengalami masalah performa saat digunakan yang berat. 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 perlu memvalidasi dengan layanan pemberian lisensi Looker. Traffic keluar di port 443 diperlukan.
  • Deployment VM khusus dapat diskalakan secara vertikal dengan meningkatkan resource dan kumpulan thread Looker yang tersedia. Namun, peningkatan RAM tunduk pada hukum pengurangan hasil setelah mencapai 64 GB, karena peristiwa pembersihan sampah memori berupa thread tunggal dan menghentikan semua thread lain untuk dijalankan. 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 failover dan redundansi layanan. Skalabilitas horizontal memungkinkan peningkatan throughput tanpa menimbulkan heap yang membengkak dan biaya pembersihan sampah memori yang berlebihan. Node memiliki opsi dedikasi beban kerja, sehingga beberapa opsi deployment dapat disesuaikan dengan berbagai kebutuhan bisnis. Deployment cluster memerlukan setidaknya satu administrator sistem yang memahami sistem Linux dan mampu mengelola bagian komponen.

Cluster standar

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

Konfigurasi seperti ini cocok ketika sebagian besar permintaan berasal langsung dari pengguna Looker yang menjalankan kueri dan berinteraksi dengan Looker. Mulai error saat sejumlah besar permintaan berasal dari penjadwal, perender, atau sumber lain. Dalam hal ini, sebaiknya tetapkan node layanan tertentu untuk menangani berbagai tugas seperti jadwal dan rendering.

Misalnya, pengguna biasanya akan menjadwalkan laporan untuk berjalan pada Senin pagi. Pengguna yang mencoba menjalankan kueri Looker pada Senin pagi mungkin mengalami masalah performa saat Looker mengerjakan backlog permintaan terjadwal. Dengan meningkatkan jumlah node layanan, cluster memberikan peningkatan throughput yang proporsional di seluruh kemampuan Looker.

Diagram berikut menunjukkan keseimbangan permintaan ke Looker yang dibuat dari pengguna, aplikasi, dan skrip 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

  • Klaster standar memaksimalkan hal umum secara keseluruhan dengan konfigurasi topologi klaster yang minimal.
  • Java VM mengalami penurunan performa pada batas memori yang dialokasikan sebesar 64 GB. Itulah sebabnya 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-nya sendiri.
  • Load balancer, yang merupakan titik masuk cluster, harus berupa load balancer lapisan 4. Aplikasi 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 Looker yang didengarkan server).
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 IOPS per GB.

Pengembangan/Staging/Prod

Untuk kasus penggunaan yang memprioritaskan waktu beroperasi konten maksimum kepada pengguna akhir, sebaiknya gunakan lingkungan Looker yang terpisah untuk mengelompokkan pekerjaan pengembangan dan analisis. Dengan menjaga perubahan lingkungan produksi di balik lingkungan pengembangan dan pengujian yang terisolasi, arsitektur ini mempertahankan lingkungan produksi yang stabil.

Manfaat ini memerlukan penyiapan lingkungan yang saling terhubung dan penerapan siklus rilis yang andal. Deployment Dev/Staging/Prod juga memerlukan tim developer yang sudah 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 UM (Uji Mutu), dan pengguna, aplikasi, serta skrip yang memakai konten di instance Produksi.

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

Kelebihan

  • Validasi konten dan LookML dilakukan di lingkungan non-produksi, yang memastikan bahwa perubahan apa pun pada logika model dapat diperiksa secara menyeluruh sebelum menjangkau pengguna produksi.
  • Fitur seluruh instance, seperti fitur Lab atau protokol autentikasi, dapat diuji secara terpisah sebelum diaktifkan di lingkungan produksi.
  • Kebijakan grup data dan cache 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, guna memberikan waktu yang cukup untuk menguji fitur baru, perubahan alur kerja, dan masalah sebelum memperbarui lingkungan produksi.

Praktik terbaik

  • Pisahkan berbagai aktivitas yang terjadi secara bersamaan dalam setidaknya tiga instance terpisah:
    • Instance pengembangan: Developer menggunakan lingkungan pengembangan untuk melakukan commit pada kode, melakukan eksperimen, memperbaiki bug, dan membuat kesalahan dengan aman.
    • Instance UM (Uji Mutu): Disebut juga sebagai lingkungan pengujian atau staging, ini adalah tempat developer menjalankan pengujian manual dan otomatis. Lingkungan UM (Uji Mutu) adalah proses yang kompleks dan dapat menghabiskan banyak sumber daya.
    • Instance produksi: Ini adalah tempat nilai dibuat untuk pelanggan dan/atau bisnis. Produksi adalah lingkungan yang sangat terlihat dan seharusnya bebas dari kesalahan.
  • Pertahankan alur kerja siklus rilis yang terdokumentasi dan dapat diulang.
  • Jika perlu untuk melayani developer dan penguji UM (Uji Mutu) dalam jumlah besar, instance Dev dan/atau UM (Uji Mutu) dapat dikelompokkan. Baik berupa VM mandiri atau cluster VM, instance Dev dan QA tunduk pada pertimbangan arsitektur yang sama sebagaimana dijelaskan di masing-masing bagian di atas.

Throughput penjadwalan tinggi

Untuk kasus penggunaan yang memerlukan throughput laporan terjadwal yang tinggi dan pengiriman yang tepat waktu dan andal, sebaiknya konfigurasi menyertakan cluster dengan kumpulan node yang hanya dikhususkan 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 di bawah dan diuraikan di bagian Kelebihan dan Praktik terbaik untuk opsi ini.

Konfigurasi cluster Looker dengan kumpulan node yang hanya dikhususkan untuk penjadwalan.

Kelebihan

  • Node khusus untuk fungsi tertentu akan mengelompokkan resource untuk penjadwalan dari fungsi pengembangan dan analisis ad hoc.
  • Pengguna dapat mengembangkan LookML dan menjelajahi konten tanpa perlu melakukan siklus dari node yang bertanggung jawab untuk melayani pengiriman laporan terjadwal.
  • Traffic pengguna tinggi yang disalurkan ke node reguler tidak menghalangi beban kerja terjadwal yang dilayani oleh node penjadwalan.

Praktik terbaik

  • Setiap node Looker harus dihosting di VM khusus-nya sendiri.
  • Load balancer, yang merupakan titik masuk cluster, harus berupa load balancer lapisan 4. Aplikasi 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 Looker yang didengarkan server).
  • Menghapus node penjadwal dari aturan load balancing agar tidak melayani 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 tinggi, sebaiknya konfigurasikan cluster dengan kumpulan node yang hanya dikhususkan untuk rendering. Rendering file PDF atau gambar PNG/JPEG adalah operasi yang relatif mahal di Looker. Rendering bisa menggunakan banyak memori dan CPU, dan ketika Linux berada di bawah tekanan memori, Linux dapat menghentikan proses yang berjalan. Karena penggunaan memori tugas render tidak dapat ditentukan sebelumnya, memulai tugas render dapat mengakibatkan proses Looker dihentikan. Mengonfigurasi node rendering khusus akan memungkinkan penyesuaian tugas render yang optimal sekaligus menjaga 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 di bawah 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 dikhususkan untuk rendering.

Kelebihan

  • Node khusus untuk fungsi tertentu akan mengelompokkan resource untuk rendering dari fungsi pengembangan dan analisis ad hoc.
  • Pengguna dapat mengembangkan LookML dan menjelajahi konten tanpa perlu melakukan siklus dari node yang bertanggung jawab untuk merender PNG dan PDF.
  • Traffic pengguna yang tinggi yang disalurkan ke node reguler tidak menghalangi beban kerja rendering yang dilayani oleh node rendering.

Praktik terbaik

  • Setiap node Looker harus dihosting di VM khusus-nya sendiri.
  • Load balancer, yang merupakan titik masuk cluster, harus berupa load balancer lapisan 4. Aplikasi 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 Looker yang didengarkan server).
  • Menghilangkan node rendering dari aturan load balancing, sehingga tidak melayani traffic pengguna akhir dan permintaan API internal.
  • Alokasikan memori yang relatif lebih sedikit ke Java dalam node rendering untuk memberi proses Chromium buffer 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. Pertimbangkan angka yang lebih tinggi seperti 80%, bukan nilai default 60%.
  • Sebaiknya deployment Anda memiliki penyimpanan dengan 2 IOPS per GB.