Shipyard: Kisah Slack Membangun Platform EC2 Generasi Berikutnya

• Slack beralih dari pendekatan lama yang terus menambal EC2 berumur panjang ke deployment penggantian berbasis AMI yang immutable, sehingga menerapkan cara deployment modern bahkan untuk workload yang sulit dipindahkan ke container
• Di atas image dasar bersama slack-zero, Slack menumpuk image per layanan; konfigurasi berat ditangani saat image baking, sementara secret dan metadata khusus environment hanya diterapkan saat boot
• Orkestrator deployment Gondola mengelola AMI dan artefak Chef berversi sebagai satu unit deployment, serta menjalankan deployment bertahap berbasis metrik, penghentian, dan rollback otomatis
• Peekaboo menyediakan inventaris EC2 lengkap hampir real-time, dan The Reaper mengganti instance yang tercemar atau sudah melewati masa pakai dengan rate limit dan mekanisme pause
• Pendekatan ini efektif untuk layanan berumur pendek, tetapi instance berumur panjang yang tidak bisa diganti cepat seperti node data, GitHub Enterprise, dan Atlassian JIRA memerlukan metode patching dan runner deployment tersendiri

---

Batasan model EC2 yang terus dimodifikasi

• Slack mengubah stack Chef tunggal lama menjadi struktur multi-stack yang tangguh, memperkenalkan deployment cookbook berversi dan prosedur promosi yang aman, sehingga meningkatkan keandalan dan kontrol operasional atas puluhan ribu instance EC2
  • Proses terkait dapat dilihat di Advancing Our Chef Infrastructure
• Setelah itu, Slack memperkenalkan environment produksi yang dipartisi, eksekusi Chef berbasis sinyal, dan metode rollout yang lebih baik, sehingga tim dapat sangat mengurangi blast radius kegagalan tanpa menulis ulang cookbook
  • Pada tahap Safety Without Disruption, Slack menjaga platform legacy tetap stabil sambil mendapatkan ruang untuk merencanakan arsitektur masa depan
• Namun, model yang terus memperbarui instance berumur panjang menyulitkan deployment per layanan, tidak dapat menghindari infrastructure drift, dan makin kompleks saat harus mengoordinasikan perubahan di banyak lapisan
• Container menyelesaikan masalah untuk sebagian workload, tetapi tidak semua sistem mudah dimigrasikan, sehingga dibutuhkan platform yang menerapkan immutability, deployment bertahap, dan pengaman otomatis langsung pada EC2

Model operasi EC2 yang disediakan Shipyard

• Shipyard adalah platform EC2 generasi berikutnya Slack yang memperlakukan infrastruktur sebagai artefak yang dapat di-deploy, bukan sebagai instance yang terus dimodifikasi
• Dengan menggabungkan kemampuan deployment per layanan dengan sistem build dan orkestrasi, Shipyard menerapkan tingkat keamanan dan prediktabilitas yang setara dengan platform deployment aplikasi pada pembaruan EC2

• Mendukung berbagai arsitektur dan sistem operasi

  • Mendukung berbagai arsitektur CPU termasuk AMD64 dan Graviton berbasis ARM, serta dapat menggunakan Ubuntu, RHEL, dan Amazon Linux
  • Tim dapat memilih instance dan sistem operasi berdasarkan biaya, performa, dan kompatibilitas tanpa implementasi platform terpisah
  • Sangat cocok untuk komponen infrastruktur yang sulit dipindahkan ke container, node worker Kubernetes, dan stack jaringan egress

• Deployment aman berbasis metrik

  • Setiap layanan terintegrasi dengan Gondola untuk menjalankan rollout bertahap yang mencakup pemeriksaan keamanan otomatis berbasis metrik
  • Berdasarkan sinyal kesehatan layanan, deployment dapat dihentikan otomatis atau di-rollback otomatis ke versi sehat sebelumnya

• Provisioning cepat dan dapat diprediksi

  • Menggunakan struktur image berlapis yang mirip container untuk membangun image per layanan di atas image dasar golden bersama
  • Dengan mengurangi pekerjaan saat runtime, instance dapat aktif dengan cepat dan konsisten di berbagai region

• Manajemen konfigurasi yang disederhanakan

  • Sebelumnya, job Chef terjadwal secara berkala memeriksa dan menerapkan ulang konfigurasi untuk mengembalikan perubahan manual atau tak terduga ke state yang diinginkan
  • Di Shipyard, konfigurasi diterapkan hanya pada tahap lifecycle yang jelas seperti image baking dan provisioning awal
  • Tool manajemen konfigurasi terutama digunakan untuk men-deploy layanan, bukan terus-menerus memodifikasi seluruh sistem
  • Akibatnya, beban latar belakang dan overwrite yang tidak disengaja berkurang, dan karena instance tidak terus berubah seiring waktu, perilakunya lebih mudah dipahami

• Instance dengan masa pakai terbatas

  • Setiap instance diberi masa pakai terbatas dan diganti otomatis secara berkala
  • Ini mengurangi waktu di mana potensi kerentanan dapat menimbulkan masalah, serta mendorong tim mengganti instance yang berjalan alih-alih memodifikasinya

Inventaris Peekaboo dan visibilitas seluruh fleet

• Peekaboo adalah sistem inventaris yang menggunakan event cloud dan metadata instance sebagai pengganti Chef Server untuk menampilkan status fleet EC2 hampir secara real-time
• Instance yang di-deploy di luar Shipyard juga dilacak, sehingga seluruh fleet dapat dilihat di satu tempat
• Dibangun dengan AWS EventBridge, OpenSearch, dan Lambda, serta menyediakan antarmuka berikut
  • UI untuk menjelajahi fleet
  • API untuk integrasi sistem
  • CLI untuk pengecekan cepat dari command line
• Dengan memusatkan informasi EC2, Peekaboo menyatukan titik telemetri dan manajemen di seluruh environment

Image dasar golden slack-zero

• slack-zero adalah machine image bersama yang dibuat oleh Compute Platform Team dan dikelola bersama tim keamanan serta monitoring
• Ini adalah fondasi yang distandardisasi dan tepercaya yang diwarisi semua layanan, sementara tim layanan membangun environment runtime mereka sendiri di atasnya
• Image ini mencakup elemen berikut
  • Baseline sistem operasi dan konfigurasi hardening keamanan
  • Konfigurasi networking dan service discovery
  • Agen monitoring dan keamanan
  • Tool umum serta konfigurasi sistem dasar
• Image dasar diperlakukan sebagai target yang immutable sekaligus ephemeral
  • Jika diperlukan patch keamanan, pembaruan monitoring, atau perbaikan networking, image slack-zero baru dibuat
  • Image layanan turunan dibangun ulang di atas fondasi baru untuk mewarisi perbaikan tersebut

• Alasan memilih AWS Image Builder

  • slack-zero dibangun dengan AWS Image Builder, menggantikan Packer sebelumnya
  • Kebijakan lifecycle otomatis membersihkan AMI lama sehingga mengurangi biaya penyimpanan
  • Saat image baru dibuat, parameter AWS Systems Manager (SSM) yang menunjuk ke AMI terbaru per akun diperbarui, dan pipeline layanan membacanya untuk menggunakan fondasi terbaru
  • Jika image baking berhasil, EventBridge dan Lambda otomatis memulai pipeline turunan di akun pemilik layanan
  • Sebelum memublikasikan AMI, pengujian validasi dijalankan pada instance sementara untuk mengurangi risiko rollout produksi

Baking dan provisioning image layanan

• Setiap tim layanan membuat AMI sendiri berbasis slack-zero, mewarisi komponen platform bersama sambil mengontrol environment runtime mereka
• Pipeline image layanan mendefinisikan hal berikut
  • Software yang akan diinstal
  • Cara konfigurasi layanan
  • Prosedur inisialisasi instance untuk layanan tersebut
• Sebagian besar konfigurasi dimasukkan ke dalam image untuk meningkatkan kecepatan runtime dan konsistensi, serta meminimalkan configuration drift

• Pemisahan peran dalam dua tahap

  • Pada tahap baking, paket dan konfigurasi yang sama lintas environment diinstal, sehingga instance sudah berada dalam state sehat yang sebagian besar siap bahkan sebelum dijalankan
  • Pada tahap provisioning, hanya pengaturan yang bergantung pada environment seperti secret, konfigurasi per region, dan metadata deployment yang diterapkan saat boot
  • Umumnya hanya menempatkan file konfigurasi, mengambil secret, dan memulai layanan
  • Memindahkan pekerjaan berat seperti instalasi paket ke baking memungkinkan instance aktif dalam hitungan detik, bukan menit
  • Startup yang cepat penting untuk event scaling, deployment berurutan, dan penggantian instance otomatis; provisioning minimal menekan drift yang muncul selama proses adaptasi runtime

Pembaruan fleet berpusat pada penggantian AMI

• Perubahan dibuat sebagai AMI baru lalu di-rollout melalui pipeline deployment; fleet diperbarui melalui penggantian terkontrol tanpa menambal instance yang ada
• Auto Scaling Group (ASG) menggunakan AWS Instance Refresh, sedangkan fleet worker Kubernetes menggunakan Karpenter
• Layanan dengan kebutuhan deployment khusus dapat menambahkan runner tersendiri, dan Gondola menyatukan berbagai pola tersebut menjadi pengalaman deployment yang konsisten

• Jalur perbaikan darurat

  • Dalam keadaan darurat, perubahan konfigurasi terbatas dapat diterapkan pada instance yang sedang berjalan, tetapi setelah itu instance tersebut harus diganti melalui pipeline deployment normal
  • Perbaikan darurat diterapkan dengan menjalankan Chef recipe pilihan melalui dokumen bawaan AWS Systems Manager
  • Setelah sistem stabil, instance dirotasi untuk kembali ke state immutable yang diinginkan

Deployment bertahap dengan Gondola

• Pipeline pelanggan dapat disusun dalam beberapa tahap yang disesuaikan dengan layanan dan kebutuhan operasional
• Setiap tahap Gondola merepresentasikan satu unit deployment seperti ASG, cluster Kubernetes, atau grup instance EC2
• Egress Team menempatkan ASG canary dan produksi secara terpisah di setiap Availability Zone, lalu menyusun tahap agar pembaruan mengalir secara berurutan
• Gondola memantau metrik utama saat memperbarui setiap tahap, dan jika masalah terdeteksi, melakukan rollback otomatis untuk mencegah penyebaran gangguan

• Artefak deployment dan runner

  • Paket deployment yang dibuat Gondola terdiri dari dua bagian
    • AMI yang akan di-deploy ke fleet
    • Artefak Chef berisi recipe berversi yang terkait dengan commit Git
  • Keduanya diperlakukan sebagai satu unit deployment, dan setiap tahap di-rollout melalui runner yang didefinisikan layanan
  • Pada deployment ASG, runner memperbarui launch template dengan AMI dan konfigurasi baru
  • Kode Chef dikemas ke Amazon S3
  • Bootstrapper bawaan pada instance baru mengambil artefak yang benar dan menjalankan recipe terkait
  • Metadata konfigurasi digunakan untuk menerapkan hanya pengaturan yang sesuai dengan role tersebut
  • Pada fleet worker Kubernetes, runner meneruskan AMI yang akan digunakan serta metadata konfigurasi yang sama ke Karpenter, dan node juga di-bootstrap dengan cara yang sama
  • Bahkan ketika runner untuk deployment khusus ditambahkan, pola AMI, artefak konfigurasi berversi, dan bootstrap berbasis metadata tetap dipertahankan

Pembagian tanggung jawab tim platform dan tim layanan

• Tim Compute, Security, dan Monitoring mengelola komponen infrastruktur global pada lapisan dasar, patch keamanan, dan pengaturan wajib
• Tim layanan membangun AMI yang menambahkan software dan konfigurasi spesifik layanan mereka di atas fondasi tersebut
• Saat tim Compute men-deploy patch keamanan, agen monitoring, dan perubahan networking, tim layanan harus memasukkan image dasar yang diperbarui ke AMI mereka sendiri
• Model tanggung jawab bersama ini menjaga otonomi per layanan sambil menyelaraskan konsistensi, keamanan, dan keandalan fleet

Pengecualian secret dari immutability penuh

• Paket dan konfigurasi pada instance Shipyard sebagian besar dikunci saat baking, tetapi secret adalah pengecualian
• Layanan Consul Template pada setiap instance menyebarkan secret baru dari Vault tanpa mengganti fleet
• Karena kredensial atau sertifikat dapat diperbarui secara dinamis, Shipyard merupakan infrastruktur semi-immutable yang hanya mengunci sistem inti dan lapisan layanan
• Dengan demikian stabilitas dan prediktabilitas tetap terjaga, sambil memungkinkan secret runtime penting diperbarui saat dibutuhkan

Kebijakan penggantian The Reaper

• The Reaper menentukan target penggantian dari dua jenis input
  • Sinyal taint dari sistem eksternal seperti tool keamanan atau event AWS EC2 yang menyatakan instance keluar dari state yang diinginkan
  • Pemeriksaan berkala untuk memastikan apakah instance sudah berjalan lebih lama dari masa pakai maksimum yang diizinkan
• Jika salah satu kondisi terpenuhi, penggantian instance dijadwalkan sesuai kebijakan layanan
• Akses jarak jauh manual diizinkan untuk keadaan darurat, tetapi login langsung ke node setingkat produksi memicu sinyal sehingga instance tersebut ditandai sebagai kandidat penggantian di masa mendatang
• Terintegrasi dengan Peekaboo untuk melacak usia instance di seluruh fleet; node yang mencapai masa pakai maksimum mengikuti prosedur penghentian dan penggantian sehat yang sama
• Ke depannya, Slack berencana menambahkan kemampuan sadar konteks agar hanya perubahan bermakna seperti pembaruan software atau configuration drift yang memicu penggantian, sementara operasi read-only atau berisiko rendah tidak menyebabkan rotasi yang tidak perlu

• Kecepatan penggantian dan kontrol darurat

  • Rate limit bawaan menentukan jumlah instance yang dapat diganti sekaligus per layanan, region, dan Availability Zone untuk mencegah dampak kapasitas mendadak
  • Mekanisme pause global bernama “big red button” menempatkan objek kontrol di S3 untuk menghentikan semua aktivitas Reaper selama gangguan atau periode berisiko tinggi
  • CLI digunakan untuk mengelola rate limit, memeriksa konfigurasi, serta mengaktifkan dan menonaktifkan pause global
  • Dalam situasi break-glass yang memerlukan investigasi mendalam, akses terkontrol seperti sertifikat SSH berumur pendek dapat digunakan

Pengujian infrastruktur nyata dengan Ship Quick

• Ship Quick adalah workflow developer yang memungkinkan tim platform dan pemilik layanan menjalankan pengujian baking dan provisioning realistis di infrastruktur nyata sebelum menggabungkan pull request
• Developer menjalankan perintah CLI dari repository cookbook dan mendefinisikan test case dengan file YAML
• Ship Quick memprosesnya dalam urutan berikut
  • Mengemas cookbook dan mengunggahnya ke S3
  • Mengirim pesan workflow ke queue
  • Instance worker yang dikelola Longshoremen mengambil job
  • Worker dipisahkan dari Auto Scaling Group dan menjalankan workflow Chef
  • Log di-stream ke CLI lalu worker dihentikan, atau developer dapat memilih mempertahankannya untuk debugging

• Fleet worker per lapisan dasar

  • Karena struktur bootstrap, Slack mengoperasikan dua fleet worker terpisah
  • Fleet Ubuntu dasar melakukan baking dan pengujian image dasar dari AMI Ubuntu bersih karena slack-zero tidak dapat dibangun di atas dirinya sendiri
  • Fleet slack-zero menguji cookbook tim layanan yang bergantung pada slack-zero yang sudah di-bake sebelumnya
  • Provisioning divalidasi di atas fondasi yang sama seperti produksi
  • Terus diperbarui dengan image terbaru agar mencerminkan environment produksi saat ini
  • Kedua fleet melakukan autoscaling sesuai permintaan
  • Tim yang membuat image di akun AWS mereka sendiri dapat mengonfigurasi fleet worker khusus dan mengirim job Ship Quick ke fleet tersebut untuk mempertahankan isolasi

Ekspansi ke workload berumur panjang

• Saat ini Shipyard bekerja efektif pada layanan berumur pendek, dan Slack terus meng-onboard tim dari platform EC2 legacy
• Tantangan berikutnya adalah instance berumur panjang yang tidak dapat dirotasi dengan cepat
  • Node data Slack
  • Layanan singleton seperti GitHub Enterprise
  • Instance teknologi bisnis pihak ketiga seperti Atlassian JIRA
• Workload seperti ini membutuhkan metode patching dan pembaruan yang aman serta kebijakan lifecycle yang dapat ditangani dengan benar oleh The Reaper
• Slack bekerja sama dengan tim layanan untuk mengembangkan runner workload berumur panjang untuk Gondola, dan seiring cakupan adopsi bertambah, Slack berencana terus meningkatkan tool, workflow developer, dan pengalaman deployment
• Ke depannya, Slack akan membahas secara terpisah komponen Shipyard API, pipeline image, workflow developer, sistem inventaris, serta masalah yang muncul selama perluasan platform