- Platform data Slack menjalankan lebih dari 700 Operator berbasis SSH untuk pipeline data inti seperti pengindeksan pencarian harian dan pekerjaan analitik, dan semua pekerjaan memerlukan akses SSH langsung ke klaster AWS EMR produksi sehingga membentuk permukaan ancaman keamanan yang luas
- Ketergantungan pada SSH ini bukan hanya risiko keamanan, tetapi juga menjadi hambatan utama bagi modernisasi infrastruktur seperti Spark on Kubernetes, migrasi ke EMR on EKS, dan penyelesaian inisiatif Whitecastle
- Sebagai solusi, Slack memanfaatkan YARN Distributed Shell untuk memungkinkan eksekusi bahkan perintah shell arbitrer di dalam container YARN, lalu menyatukan semua pengajuan job melalui gateway REST internal Slack bernama Quarry
- Memigrasikan lebih dari 700 job di 8 region data tanpa downtime (zero downtime), dan menyelesaikan penghapusan SSH 100% dalam tiga kuartal
- Hasilnya, Slack memperoleh pengurangan permukaan serangan, peningkatan keandalan pekerjaan, dan visibilitas yang lebih baik, sekaligus membangun fondasi infrastruktur generasi berikutnya seperti penyelesaian Whitecastle dan Spark on Kubernetes
Latar belakang: terbentuknya platform data berbasis SSH
- Platform data Slack yang dibangun sekitar 2017 memilih pendekatan SSH sebagai jalur paling langsung bagi Airflow untuk menjalankan job di klaster EMR
- Menggunakan
SSHOperator untuk terhubung ke node master EMR lalu menjalankan perintah seperti spark-submit
- Setelah itu, berbagai tim membuat sendiri Operator kustom berbasis SSH untuk beragam kebutuhan (bukan hanya Spark, tetapi juga MapReduce, AWS CLI, dan skrip Python kustom)
- Akibatnya, di lingkungan produksi terkumpul lebih dari 700 job berbasis SSH
Biaya nyata dari pendekatan SSH
-
Potensi risiko keamanan
- Akses SSH langsung ke klaster komputasi memperluas permukaan serangan
- Distribusi dan rotasi kunci di seluruh worker orkestrasi menambah beban operasional
- Audit yang terperinci membutuhkan korelasi log dari beberapa sistem
- Pengelolaan izin menjadi lebih rumit karena security group khusus dan konfigurasi kustom
-
Masalah dari sisi operasional
- Job tidak didistribusikan dan dijalankan langsung di node master EMR sehingga terjadi perebutan resource
- Saat Pod Kubernetes restart, koneksi SSH terputus dan job gagal
- Job berdurasi panjang tetap berjalan setelah koneksi terputus sehingga menjadi proses zombie
- Jika koneksi terputus, tidak ada cara memastikan apakah job berhasil atau gagal
-
Faktor penghambat modernisasi
- Tidak bisa masuk ke Spark on Kubernetes dan EMR on EKS (penghapusan ketergantungan SSH harus dilakukan terlebih dahulu)
- Klaster EMR terakhir di akun utama tidak bisa dipindahkan ke child account sehingga inisiatif Whitecastle belum selesai
- Whitecastle adalah inisiatif Slack untuk memindahkan infrastruktur AWS ke child account demi memperkuat keamanan dan isolasi jaringan
- Tidak memungkinkan penerapan monitoring job dan visibilitas yang memadai
-
Contoh representatif — tim Search Infrastructure
- Pipeline yang membangun indeks pencarian Solr harian dari data berukuran terabita, komponen inti fitur pencarian Slack
- Karena bergantung pada pengajuan job berbasis SSH, pipeline ini terekspos pada seluruh masalah keandalan di atas
Konsep dasar pengajuan job berbasis REST
-
Keterbatasan mendasar SSH
- Koneksi SSH adalah koneksi langsung yang stateful; jika koneksi terputus karena Pod restart atau sebab lain, perintah bisa terus berjalan, gagal, atau menyisakan proses yatim
- Tidak ada cara andal untuk terhubung kembali dan memeriksa statusnya
-
Alternatif REST
- Mesin komputasi modern seperti YARN, Trino, dan Snowflake mendukung pengajuan job melalui HTTP API
- POST permintaan job → mengembalikan job ID
- GET status job → memeriksa apakah sedang berjalan/selesai/gagal
- DELETE job → membatalkan dengan benar
- Siklus hidup job dikelola di sisi server, sehingga meski klien restart, job tetap berjalan dan statusnya tetap bisa diperiksa
-
Peran dan batasan YARN
- Untuk workload Hadoop (MapReduce, Spark, Hive), YARN adalah resource manager sekaligus menyediakan REST API
- Namun, untuk lebih dari 300 job berbasis CLI yang menjalankan perintah shell arbitrer seperti
aws s3 sync dan hadoop distcp, tidak ada REST API siap pakai
- Kunci untuk mengatasi ini adalah YARN Distributed Shell
Terobosan: YARN Distributed Shell
- Untuk Spark tersedia Livy REST API, dan untuk Hive ada HiveServer2, sehingga migrasinya relatif sederhana
- Sebaliknya, job MapReduce dan lebih dari 300 job berbasis CLI adalah tantangan besar karena tidak memiliki REST API yang siap digunakan
-
Persyaratan
- Solusi berbasis REST yang sederhana dan cocok secara alami dengan arsitektur
- Memanfaatkan mekanisme autentikasi/otorisasi yang sudah ada (tanpa lapisan keamanan kustom)
- Menggunakan protokol open source (API YARN standar), bukan solusi proprietari
- Kompleksitas seminimal mungkin agar tidak perlu membangun dan mengoperasikan infrastruktur eksekusi job kustom
-
Opsi yang ditinjau lalu dibuang
- Membangun layanan wrapper kustom untuk eksekusi perintah jarak jauh
- Menggunakan framework eksekusi jarak jauh seperti Ansible, Salt
- Menambahkan tipe job baru ke YARN dari nol
- Semua dianggap tidak cocok karena terlalu kompleks, memerlukan implementasi keamanan kustom, atau menambah dependensi baru
-
Menemukan YARN Distributed Shell
- Dengan
org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster, Slack dapat menjalankan skrip shell arbitrer di dalam container YARN
- Fitur ini sudah menjadi bagian dari YARN dan menggunakan REST API yang sama, sehingga tidak memerlukan lapisan keamanan kustom
-
Cara kerjanya
- 1. Unggah skrip perintah ke S3 (misalnya
aws s3 sync /tmp/data/ s3://bucket/output/)
- 2. Kirim ke YARN dengan konfigurasi Distributed Shell
- Menetapkan
application-type ke MAPREDUCE, dan menyertakan variabel lingkungan seperti DISTRIBUTEDSHELLSCRIPTLOCATION, DISTRIBUTEDSHELLSCRIPTLEN, DISTRIBUTEDSHELLSCRIPTTIMESTAMP di am-container-spec
- 3. YARN mengalokasikan container, mengunduh skrip, lalu menjalankannya
- YARN menangani batas resource seperti memori/vCore, isolasi container, retry dan fault tolerance, pembatalan yang benar, serta logging melalui UI YARN
- Keputusan ini memungkinkan bukan hanya workload Hadoop, tetapi juga
aws s3 sync, hadoop distcp, dan skrip Python kustom semuanya dijalankan di dalam container YARN
Solusi: Quarry
- Quarry adalah gateway pengajuan job berbasis REST milik Slack yang dibuat untuk mengirim job ke berbagai mesin komputasi seperti EMR/YARN, Trino, dan Snowflake
- Quarry sudah menyelesaikan masalah autentikasi, keandalan, dan visibilitas, dan sangat cocok untuk penghapusan SSH
-
Fitur Quarry
- Autentikasi: menggunakan token antar-layanan alih-alih kunci SSH
- Pengajuan job: mengirim ke YARN, Trino, dan Snowflake melalui REST API
- Pelacakan status: memantau status job di sisi server
- Manajemen siklus hidup: pembatalan dan cleanup yang benar berbasis REST API
- Visibilitas: menyediakan log terstruktur, metrik, dan tracing untuk semua pengajuan job
-
Perubahan arsitektur
- Sebelumnya:
Airflow → SSH Connection → EMR Master Node → Execute Command
- Sesudahnya:
Airflow → Quarry REST API → YARN ResourceManager → EMR Container
- Airflow Operator mengirim HTTP request ke Quarry alih-alih membuat koneksi SSH; Quarry lalu mengirim ke YARN dan melakukan polling status
- Job tetap berjalan meski Airflow Pod restart, karena Quarry yang menjaga kesinambungan koneksi
-
Kekuatan Quarry
- Dengan dukungan YARN Distributed Shell, Quarry menjadi gateway pengajuan job serbaguna
- Job Spark, query Hive, dan skrip shell semuanya melalui REST API yang sama
- Semua kredensial SSH dan akses langsung ke klaster dihapus, dan digantikan dengan REST call yang mencakup autentikasi serta pelacakan job di sisi server
Perjalanan migrasi
- Dengan lebih dari 700 job produksi di 8 region data yang independen, masing-masing memiliki konfigurasi jaringan dan kebutuhan kedaulatan data yang berbeda, serta workload penting seperti pengindeksan pencarian yang harus bebas downtime, diperlukan rencana yang sistematis
-
Pendekatan bertahap
- Fase 1 – Proof of Concept (PoC): memvalidasi pendekatan berbasis Quarry dengan job pilot, lalu mengembangkan Operator Quarry pertama dan mengujinya di lingkungan dev
- Fase 2 – Tinjauan keamanan: bekerja sama dengan tim keamanan untuk menyusun rencana penghapusan kredensial dan memverifikasi bahwa pendekatan REST memenuhi persyaratan keamanan
- Fase 3 – Eksekusi berbasis OKR: menjadikannya Key Result agar terlihat di tingkat eksekutif; pada tahap ini milestone migrasi 80% tercapai
- Fase 4 – Migrasi skala besar: beberapa tim seperti Search Infrastructure, Data Engineering & Analytics, dan ML Services memindahkan seluruh workload yang tersisa di semua region secara paralel
- Fase 5 – Pembersihan akhir: menyelesaikan DAG yang tertinggal, menghapus semua SSH Operator lama, dan mencapai 100%
-
Angka migrasi
- Lebih dari 700 job dipindahkan di 7 tipe Operator
- Diterapkan ke 8 region data independen melalui rollout yang terkoordinasi
- 5 tim berpindah ke Operator baru
- Tanpa downtime pada layanan bisnis yang kritis
- Dari pilot awal hingga penghapusan SSH 100% selesai dalam tiga kuartal
Tantangan yang dihadapi selama migrasi
-
Challenge 1 — kegagalan Virtual Memory Check
- Saat memigrasikan DAG export data, job yang sebelumnya berjalan normal lewat SSH gagal karena error pemeriksaan vmem
- Penyebab: SSH menjalankan job langsung di node master sehingga melewati enforcement resource YARN, sedangkan Quarry mengirim job secara benar ke YARN sehingga container yang melebihi batas memori virtual ditolak
- Solusi: menonaktifkan pemeriksaan vmem di seluruh klaster sesuai praktik terbaik AWS —
"yarn.nodemanager.vmem-check-enabled": "false"
- Ini sejalan dengan rekomendasi AWS bahwa pencatatan memori virtual Linux tidak cukup andal dan batas memori fisik sudah memadai
- Pelajaran: SSH telah menyembunyikan banyak masalah, jadi saat beralih ke pengajuan YARN yang benar, perlu mengantisipasi munculnya isu batas resource yang sebelumnya tidak terlihat, dan melakukan pengujian memadai di lingkungan dev
-
Challenge 2 — pemisahan jaringan dan masalah konektivitas EKM
- Saat memindahkan job infrastruktur pencarian dev dari klaster dev ke klaster analitik staging, muncul timeout koneksi ke EKM (Enterprise Key Management)
- Error:
Unable to execute HTTP request: Connect to sts.amazonaws.com:443 failed: connect timed out
- Penyebab: klaster asal memiliki routing jaringan ke endpoint manajemen kunci, tetapi klaster analitik staging yang berada di segmen jaringan lebih ketat tidak memiliki konektivitas yang setara, sehingga terungkap ketergantungan topologi jaringan yang tidak dinyatakan dalam konfigurasi job
- Solusi: memindahkan pekerjaan Search Infrastructure ke klaster dev ETL yang punya routing ke layanan dev; pekerjaan yang memerlukan katalog Hive produksi tetap dipertahankan di staging; lalu melakukan scale-up pada klaster dev ETL agar dapat menampung workload tambahan
- Pelajaran: topologi jaringan sangat penting; sebelum menentukan job dijalankan di klaster mana, perlu memahami pemisahan jaringan dan batas akun
-
Challenge 3 — kompleksitas multi-region
- Karena persyaratan kedaulatan data, Slack menjalankan klaster EMR di 8 region data yang independen, sehingga penghapusan SSH pada praktiknya menjadi 8 migrasi paralel
-
Faktor kompleksitas
- Manajemen konfigurasi: tiap region memerlukan konfigurasi Quarry, endpoint klaster, dan aturan routing jaringan yang berbeda
- Beban pengujian: setiap perubahan kode harus divalidasi di seluruh 8 region
- Deploy bertahap: tidak bisa deploy serentak, harus rollout progresif per region
- Masalah spesifik region: perbedaan konfigurasi jaringan, aturan kedaulatan data, dan versi klaster
-
Cara menanganinya
- Memvalidasi lebih dulu di satu region pilot (umumnya berbasis AS)
- Mendokumentasikan kebutuhan konfigurasi tiap region
- Membangun Quarry Operator yang sadar region
- Melakukan rollout bertahap dan memasukkan pembelajaran dari tiap region
- Melacak progres migrasi per region secara terpisah
- Pelajaran: infrastruktur multi-region bukan sekadar N kali lipat, tetapi N kali lebih sulit dengan failure mode unik tiap region, sehingga perlu mengalokasikan waktu yang cukup untuk koordinasi lintas-region dan debugging per region
Hasil
- Penghapusan SSH 100% tercapai, dan semua job produksi beralih ke pengajuan berbasis REST melalui Quarry
-
Hasil dari sisi keamanan
- Akses SSH dihapus dari semua klaster EMR produksi di 8 region data independen, sehingga permukaan serangan berkurang drastis
- Distribusi kunci SSH digantikan dengan autentikasi token antar-layanan, dan logging REST API menyediakan jejak audit yang layak
- Semua pengajuan job memiliki log terstruktur melalui Quarry
- Klaster EMR terakhir di akun utama AWS dipindahkan ke child account, sehingga inisiatif Whitecastle selesai
- Penyederhanaan compliance berkat penghapusan security group khusus dan pengelolaan izin yang kompleks
-
Peningkatan operasional
- Perebutan resource di node master dihilangkan; semua job non-Hadoop kini berjalan di container YARN terdistribusi dengan alokasi resource yang tepat
- Job tetap berjalan walau Kubernetes Pod klien restart, sehingga keandalan job meningkat tajam; proses zombie hilang, dan terminasi yang benar dimungkinkan melalui REST API
- Quarry API menyediakan status/log/metrik job yang terstruktur, memungkinkan pelacakan seluruh siklus hidup job dan pemeriksaan log container YARN untuk debugging dengan alat yang tepat
-
Fondasi untuk masa depan
- Dengan hilangnya ketergantungan SSH, migrasi ke Spark on Kubernetes menjadi memungkinkan
- Arsitektur berbasis REST selaras dengan praktik cloud-native
- Dibanding konfigurasi SSH yang rumit, Quarry Operator lebih sederhana dan mudah dipelihara, sehingga onboarding tim menjadi lebih mudah
- Airflow menjadi terlepas (decoupled) dari detail infrastruktur EMR
- Semua pengajuan job distandarkan ke Quarry, sehingga perubahan di masa depan menjadi lebih mudah
- Setelah dua tahun operasi produksi pasca-penyelesaian, keputusan arsitektur ini terbukti tepat, dengan peningkatan pada keamanan, stabilitas operasional, dan fleksibilitas infrastruktur
Pelajaran yang dipetik
-
Yang berjalan dengan baik
- Migrasi bertahap: rollout berurutan Dev → GovDev/CommDev → Prod dan migrasi per tipe Operator memungkinkan akumulasi pembelajaran di tiap tahap
- Kolaborasi tim yang kuat: kerja sama lintas domain antara Search, Analytics, Data Engineering, ML, Marketing, dan lainnya, dengan code review cepat serta komunikasi melalui kanal bersama
- Pelacakan progres berbasis analitik: membuat dashboard progres migrasi di semua region dan mengidentifikasi pekerjaan berbasis SSH yang tersisa melalui query ke database Airflow
-
Hal yang akan dilakukan berbeda jika mengulang
- Perlu pemetaan topologi jaringan sejak awal: masalah pemisahan jaringan seperti konektivitas EKM baru ditemukan di tahap akhir; batas akun Whitecastle dan routing jaringan perlu didokumentasikan sebelum migrasi klaster
- Perlu pengujian batas resource lebih awal: isu pemeriksaan vmem muncul belakangan; sejak fase pilot awal seharusnya sudah mencakup pengujian batas resource YARN dibanding SSH
- Perlu komunikasi lebih awal tentang pembatasan Operator: saat penggunaan baru
SSHOperator dibatasi di tahap akhir, beberapa tim tidak menyadarinya; perlu memperkuat pemberitahuan awal kepada seluruh pengguna Airflow
-
Praktik terbaik migrasi skala besar
- Bangun monitoring sebelum migrasi: siapkan dashboard sedini mungkin agar selalu tahu pekerjaan yang masih tersisa, dengan memanfaatkan query ke DB Airflow
- Uji di banyak lingkungan: lakukan pengujian di Dev, CommDev, dan GovDev untuk menangkap masalah spesifik lingkungan sebelum produksi, terutama pengujian lintas batas akun untuk mendeteksi masalah pemisahan jaringan lebih awal
- Hentikan Operator lama secara bertahap: seperti CrunchExecOperator dan S3SyncOperator, hapus satu per satu, dengan tiap tahap dijalankan sebagai mini-proyek yang memiliki pengujian dan validasinya sendiri; lebih lambat, tetapi sangat mengurangi risiko
Belum ada komentar.