- "Up: Portable Microservices Ready for the Cloud"
- Uber memiliki 4.500 engineer dan banyak sistem otomatis yang setiap minggu melakukan lebih dari 4.000 deployment untuk 4.500 microservice stateless
- Layanan-layanan ini dikembangkan, di-deploy, dan dioperasikan oleh ratusan tim terpisah yang bekerja secara independen di seluruh dunia
- Layanan memiliki ukuran, bentuk, dan fungsi yang beragam; sebagian kecil dan digunakan untuk pekerjaan internal, sebagian besar dan digunakan untuk komputasi real-time skala besar
Sejarah layanan stateless Uber
- Pada 2014, Uber menyimpan data dalam satu database PostgreSQL untuk monolith yang ditulis dengan Python
- Seiring pertumbuhan, Uber menambah engineer dan beralih ke arsitektur microservice
- Ketika jumlah layanan bertambah, Uber membuat alat bernama µDeploy untuk men-deploy kode secara terpusat dalam skala besar
- Mengontainerisasi semua layanan stateless dan mengabstraksikan pengelolaan host serta penempatan
- Membuat grup infrastruktur dapat mengelola host fleet secara independen dari microservice unit bisnis
- Namun, pengelolaan dan penempatan layanan masih dilakukan secara manual
- Infrastruktur Uber mengikuti model di mana kelompok zona membentuk region
- Latensi antar zona di dalam satu region cukup rendah sehingga komunikasi sinkron antar layanan di region yang sama tetap efisien
- Setiap zona bisa berupa klaster mesin milik Uber atau milik penyedia cloud publik, tetapi satu zona tertentu selalu hanya bisa berasal dari satu penyedia
- Secara umum, semua microservice seharusnya dapat memanggil layanan lain tanpa masalah latensi selama berada di region yang sama
- µDeploy tidak memusatkan penempatan geografis workload di dalam sistem karena engineer masih harus mengelola penempatan fisik pada level availability zone
- Artinya, engineer layanan masih harus memutuskan bukan hanya apakah layanan dijalankan di zona on-premises, tetapi juga di zona spesifik mana layanan tersebut dijalankan
- Saat mengoperasikan data center on-premises, kekurangan chip dan masalah rantai pasok menyebabkan lead time menjadi panjang
- Pada 13 Februari 2023, Uber bermitra dengan Oracle dan Google untuk mengurangi eksposur terhadap masalah rantai pasok dan melakukan diversifikasi
- Menjalankan strategi ini mustahil tanpa memiliki "sistem yang dapat mengabstraksikan infrastruktur dasar" bagi ribuan engineer Uber yang mengembangkan ratusan layanan berbeda untuk mendukung bisnis
Bersiap memindahkan Uber ke cloud
- Memigrasikan 4.500 layanan stateless ke cloud sambil tetap menjaga bisnis berjalan memerlukan koordinasi dan upaya dalam jumlah besar
- Sejak awal sudah jelas bahwa pekerjaan ini rentan terhadap kesalahan dan hampir mustahil dikelola lewat koordinasi manual
- Untuk memelihara dan mengelola microservice stateless dalam skala besar, layanan harus diubah agar dapat dikelola otomatis dari sistem deployment terpusat tanpa campur tangan manusia
- Melampaui Stateless menuju Portability
- Berdasarkan model region dan zone, Uber mencetuskan konsep "portability"
- Portability berarti layanan dapat berjalan di semua zona dalam suatu region, dan dapat dipindahkan otomatis ke zona baru oleh platform infrastruktur tanpa campur tangan manusia
- Ini mencakup perpindahan antar penyedia cloud publik, maupun perpindahan masuk dan keluar dari zona on-premises
- Sebagian layanan pada umumnya tidak memiliki portability karena bergantung pada konfigurasi zona dan preferensi sumber daya zona
- Untuk melakukan migrasi otomatis ke cloud, semua layanan harus memiliki portability
Membuat Uber menjadi portable
- Sepanjang 2021 dan 2022, Uber menjalankan program lintas engineering untuk memastikan semua layanan memiliki portability
- Dalam banyak kasus, pelanggaran portability dapat dideteksi hanya dengan inspeksi kode untuk melihat penggunaan konstanta string dan nama file di dalam kode
- Untuk kasus sederhana, Uber menulis aturan linter yang menyoroti kode yang tampak di-hardcode agar berjalan di lokasi fisik tertentu
- Untuk menguji apakah layanan benar-benar portable, Uber harus benar-benar memindahkan layanan ke berbagai zona tanpa campur tangan manusia
- Uber membangun rangkaian alat pengujian yang memungkinkan pemilik layanan memulai perpindahan pertama layanan mereka
- Karena dibangun di atas alat yang sudah ada untuk rollout kode yang aman dan bertahap, pemilik layanan dapat kapan saja mengembalikan deployment ke zona asal dan memperbaiki masalah jika ditemukan
- Jika perpindahan berhasil diselesaikan, layanan tersebut kemudian ditandai agar ke depan dapat dipindahkan secara otomatis
- Selama beberapa tahun berikutnya, Uber mengulangi proses ini untuk semua layanan dan pada akhirnya menyelesaikannya sepenuhnya
- Setelah pekerjaan selesai, topologi zona dapat diubah tanpa campur tangan engineer layanan
- Agar layanan tetap portable seiring waktu, Uber terus memigrasikan semua layanan antar zona setiap beberapa minggu untuk menguji kemampuan perpindahan secara berkala
- Ini memudahkan deteksi regression pada layanan, dan seiring waktu engineer menjadi terbiasa untuk tidak berasumsi bahwa layanan mereka akan ditempatkan di zona tertentu
Up: Multi-Cloud Multi-Tenant Federation Control Plane
- Uber menetapkan tujuan awal sistem sebagai berikut
- Menyediakan single point of entry bagi engineer untuk berinteraksi dengan sistem infrastruktur
- Mengelola dan menerapkan best practice untuk layanan yang di-deploy langsung ke sistem agar memberikan tingkat keamanan yang tinggi selama rollout kode
- Mengotomatisasi penempatan layanan pada availability zone; saat availability zone baru tersedia, deployment dipindahkan ke zona baru tersebut, termasuk koordinasi deployment secara terpusat untuk mendukung high availability Uber secara umum
- Mengotomatisasi migrasi level infrastruktur yang rumit sehingga engineer layanan tidak perlu terlibat dalam migrasi
- Arsitektur tingkat tinggi
- Experience Layer:
- Mengimplementasikan berbagai cara engineer berinteraksi dengan sistem
- UI, Continuous Delivery, robot yang menjaga sistem tetap dalam kondisi baik, dan sebagainya
- Balancer yang terus memindahkan workload ke klaster dan zona dengan utilisasi lebih rendah
- Auto Scaler yang terus mengoptimalkan alokasi kapasitas untuk setiap workload
- Platform Layer:
- Mengimplementasikan abstraksi yang digunakan layer Experience untuk berinteraksi dengan layanan
- Mencakup abstraksi layanan dan lingkungan layanan yang membentuk model konseptual operasi layanan, serta API level layanan itu sendiri
- Di platform layer, constraint layanan dinyatakan sebagai desired state tingkat tinggi yang menjelaskan properti yang diinginkan dari deployment layanan aktual
- Dapat mencakup constraint pada performa mesin yang akan menjalankan layanan dan kapasitas komputasi total untuk layanan per region
- Federation Layer:
- Mengimplementasikan integrasi untuk klaster komputasi
- Mengorganisasi semua klaster berdasarkan kemampuan dan lokasi fisik untuk mengimplementasikan abstraksi region dan zone yang digunakan layer di atasnya
- Mengambil desired state layanan tingkat tinggi dari platform lalu mengubahnya menjadi penempatan zona dan klaster; transformasi ini didasarkan pada constraint desired state dan state aktual klaster, termasuk kapasitas yang tersedia saat ini dan klaster yang dapat memenuhi constraint klaster maupun constraint tambahan
- Hasil transformasi ini dapat berubah seiring waktu, dan nantinya penempatan zona serta klaster yang berbeda bisa menjadi lebih diinginkan
- Semua panggilan dari balancer dan pekerjaan lain yang dimulai dari experience layer juga dapat membuat penempatan ini dihitung ulang dan diubah
- Agar sistem tetap aman dan layanan tetap sehat, komponen change management mengimplementasikan alur rollout yang mengubah state global sedikit demi sedikit melalui integrasi dengan semua sistem yang memantau kesehatan layanan
- Proses rollout mencakup canarying dan pemantauan sinyal kesehatan di seluruh sistem; jika masalah ditemukan, sistem akan dengan cepat me-roll back layanan ke konfigurasi dan penempatan sebelum perubahan dimulai
- Regions
- Region berisi instance klaster aktual
- Mencakup klaster Peloton dan Kubernetes®
- Keduanya berada di luar Up itu sendiri, tetapi menjadi target penempatan kapasitas aktual dan mengelola penempatan container pada host fisik
Dampak
- Uber memulai pekerjaan Up pada 2018, menyediakan prototipe yang berfungsi pada awal 2019, dan meluncurkan platform secara resmi pada pertengahan 2020
- Sejak itu, Uber memigrasikan lebih dari 4.000 layanan dari platform deployment lama ke Up di seluruh lini bisnisnya
- Karena sebagian besar migrasi ini diotomatisasi, tim dapat fokus pada use case paling canggih sekaligus mendukung migrasi tim lain
- Selama periode ini, stabilitas platform dijadikan prioritas tertinggi sehingga bisnis dapat tetap berjalan stabil saat jutaan pengguna memakai sistem Uber setiap hari
- Seluruh migrasi sekitar 2.000.000 core komputasi ke platform baru berlangsung selama sekitar 2 tahun dan berhasil diselesaikan pada 2022
- Melalui migrasi ini, upaya auto scaling dan efisiensi mengembalikan kapasitas tambahan senilai puluhan juta dolar kepada bisnis
- Uber juga dapat menghemat biaya finansial yang signifikan dengan menghemat puluhan ribu jam kerja engineering yang sebelumnya dihabiskan untuk update layanan manual, menyiapkan dan mengisi zona baru, serta mempelajari cara menavigasi lingkungan infrastruktur Uber yang kompleks
Langkah selanjutnya
- Setelah menyelesaikan migrasi dari µDeploy ke Up, tim kini dapat fokus membangun solusi yang dapat diterapkan ke seluruh layanan dengan cara otomatis dan terpusat, serta pengalaman pengguna di sekitar kemampuan tersebut
- Migrasi cloud
- Uber sedang memindahkan porsi besar fleet-nya ke cloud
- Berkat otomatisasi skala besar dan lapisan abstraksi yang disediakan Up, tim layanan dapat banyak terlepas dari detail infrastruktur yang dibutuhkan untuk transisi ini
- Continuous Delivery otomatis
- Uber menargetkan otomasi penuh deployment kode hingga ke production dengan menggunakan pipeline otomatis yang menjalankan berbagai pemeriksaan dan pengujian sebelum kode di-deploy ke production
- Fokus khusus tim pada 2023 adalah menjaga layanan tetap 'up to date' sehingga semua kode yang berjalan di production selalu mengikuti update keamanan dan library terbaru
- Keamanan deployment (Safety)
- Data yang ada menunjukkan bahwa sebagian besar insiden yang diamati berkaitan dengan perubahan kode dan konfigurasi
- Uber menargetkan penurunan besar dalam proporsi defect yang benar-benar mencapai production dengan mengotomatisasi aspek manual dalam siklus hidup layanan, seperti menjalankan pengujian pra-production atau menetapkan kebijakan rollout bertahap
- Platform
- Dengan mengorganisasi seluruh fleet layanan stateless Uber di bawah satu umbrella platform, Uber dapat memodelkan dependensi dan interaksi antar produk platform infrastruktur dengan lebih jelas
- Ini memungkinkan hadirnya model yang terpadu di dalam kode sekaligus pengalaman pengguna yang sepenuhnya terintegrasi bagi organisasi engineering lainnya
- Tujuan besar tim berikutnya adalah dapat mengamati dan mengoperasikan seluruh infrastruktur dari satu tempat
Kesimpulan
- Upaya membangun platform Up kini merepresentasikan perubahan budaya yang signifikan karena semua layanan stateless sekarang di-deploy secara bertahap dengan best practice dan otomasi yang sama
- Pekerjaan yang sebelumnya memerlukan waktu berbulan-bulan, seperti mengubah kebijakan rollout atau membangun otomasi untuk rollout library skala besar, kini dapat dilakukan secara terpusat
- Uber berharap dapat terus bekerja sama dengan para pemangku kepentingan Up dan pemilik layanan untuk mewujudkan visi agar engineer Uber dapat fokus hanya pada kode tanpa perlu mengkhawatirkan infrastruktur
Belum ada komentar.