Bagaimana Monzo Menjalankan Migrasi di 2.800 Microservice

• Monzo mengoperasikan lebih dari 2.800 layanan dengan MSA dan memperoleh banyak nilai darinya
• Namun, arsitektur seperti ini juga memiliki tantangan. Salah satunya adalah melakukan perubahan library di semua layanan
• Umumnya, Anda harus memilih dua dari tiga hal berikut: library terbaru, versi library yang konsisten, dan upaya upgrade yang rendah

Strategi migrasi terpusat

• Di Monzo, mereka percaya bahwa melalui pendekatan migrasi yang dipimpin secara terpusat, tiga karakteristik di atas dapat dicapai pada tingkat yang tinggi
• Alih-alih menyerahkan tanggung jawab migrasi kepada pemilik layanan, mereka lebih memilih satu tim yang memimpin migrasi
• Dengan cara ini, mereka dapat menghindari overhead koordinasi yang tinggi (yang menyebabkan migrasi lambat) dan risiko proyek terhenti (yang menyebabkan ketidakkonsistenan)
• Agar satu tim dapat menyelesaikan migrasi dalam waktu yang wajar, mereka sangat bergantung pada hal-hal berikut:
  • pilihan teknologi inti (misalnya tingkat konsistensi yang tinggi, penggunaan monorepo)
  • pemanfaatan otomatisasi dalam skala besar (misalnya alat deployment layanan massal, pemeriksaan rollback otomatis)

Migrasi dari OpenTracing SDK ke OpenTelemetry SDK

• Baru-baru ini, Monzo menjalankan strateginya melalui proyek perpindahan dari OpenTracing SDK ke OpenTelemetry SDK
• Semua layanan mengekspor data tracing ke Jaeger. Sebelumnya, ini dilakukan melalui OpenTracing dan Jaeger Go SDK
• Library-library tersebut kini sudah deprecated, dan komunitas telah beralih menyatu ke OpenTelemetry
• Untuk membangun fondasi guna meningkatkan sistem tracing, mereka terlebih dahulu ingin mengganti library yang sudah tidak digunakan itu dengan OpenTelemetry SDK

Prinsip migrasi

• Migrasi terpusat yang transparan bagi pemilik layanan. Mereka lebih memilih strategi yang dapat dijalankan secara terpusat oleh satu tim untuk meminimalkan overhead koordinasi dan mengurangi risiko migrasi terhenti
• Tanpa downtime. Sebagian besar migrasi menyentuh layanan yang penting bagi fungsi inti bank, sehingga downtime tidak dapat diterima
• Roll forward bertahap, rollback cepat. Untuk perubahan besar, mereka harus bisa melakukan roll forward secara bertahap agar radius dampak berkurang jika terjadi masalah. Namun bila diperlukan, mereka juga harus bisa melakukan rollback semuanya dengan cepat
• Aturan 80/20 untuk otomatisasi. Dalam migrasi skala besar, biasanya ada proporsi tinggi perubahan yang cocok dengan template umum. Perubahan seperti ini mudah diotomatisasi. Untuk kasus penggunaan yang lebih unik, otomatisasi memberi hasil yang semakin kecil, sehingga lebih efisien ditangani per kasus. Untuk menghindari kejutan buruk dan memudahkan pelacakan progres, sebaiknya perubahan yang diperlukan sejak awal diklasifikasikan ke dalam dua kategori ini

Strategi migrasi

• Di Monzo, ada serangkaian tahapan migrasi yang digunakan secara sistematis

1. Perencanaan dan penyelarasan

• Migrasi membawa risiko yang signifikan. Bukan hanya karena memengaruhi layanan dalam skala besar, tetapi juga karena tim yang menjalankan migrasi mungkin tidak memiliki banyak (atau bahkan sama sekali tidak memiliki) konteks tentang layanan yang sedang dimigrasikan
• Mereka mengejar konsistensi layanan, tetapi selalu ada pengecualian, dan mereka ingin menangkap kejutan seperti itu sedini mungkin
• Karena itu, sangat penting agar proses perencanaan bersifat transparan dan semua engineer punya kesempatan untuk berkontribusi
• Untuk ini, ada dua proses:
  • Proposal: Monzo banyak menulis dokumen seperti ini. Hampir semua hal pada akhirnya dibagikan di satu channel Slack tempat semua orang di perusahaan dapat memberikan masukan
  • Architecture review: Untuk perubahan terbesar, mereka mengadakan rapat architecture review sinkron yang membahas lebih dalam area-area tertentu yang lebih kontroversial atau berisiko. Tujuannya bukan mendapatkan persetujuan atau tanda tangan, melainkan mendorong status desain maju secara bermakna sehingga proyek bisa dipercepat

2. Membungkus library lama

• Alih-alih langsung memasang library baru dan memperbarui kode layanan untuk memanggilnya, mereka memutuskan untuk terlebih dahulu membungkus library lama

  1. Mereka dapat mencegat panggilan ke library dasar dan memutuskan implementasi mana yang akan digunakan berdasarkan konfigurasi dinamis. Dengan begitu, mereka dapat dengan mudah melakukan roll forward dan rollback tanpa perlu mendeploy ulang semua layanan
  2. Ada tipe/fungsi yang sangat berbeda di library baru. Memperbarui semua call site akan membutuhkan banyak usaha, dan dalam beberapa kasus manfaat API baru sangat kecil. Dengan membungkus library lama, dalam kasus seperti itu mereka dapat mempertahankan antarmuka yang mirip dengan library lama sehingga call site lebih mudah diperbarui

• Manfaat lain dari membungkus library:

  • dapat diinstrumentasikan dengan library telemetry milik sendiri
  • dapat menyediakan antarmuka yang lebih opinionated

3. Memperbarui call site

• Penggunaan library ini mengikuti pola umum:

  • ada sejumlah kecil fungsi/tipe yang dirujuk berkali-kali di seluruh codebase
  • lalu ada ekor panjang fungsi/tipe yang hanya dirujuk di beberapa tempat saja

• Mereka menangani kedua kasus ini secara berbeda:

  • untuk sejumlah kecil fungsi/tipe yang dirujuk di banyak tempat, mereka mengotomatiskan sebanyak mungkin. Untuk library ini, mereka terutama mengandalkan gopls dan gorename untuk melakukan refactoring otomatis
  • untuk menangani ekor panjang fungsi/tipe yang hanya dirujuk di beberapa tempat, mereka mengambil pendekatan manual per kasus. Dalam beberapa kasus, mereka memigrasikannya secara manual. Dalam kasus lain, mereka menyadari bahwa hal yang sama dapat dilakukan dengan API yang lebih umum yang sudah ada, sehingga mereka beralih ke sana. Ini berarti tidak perlu lagi menanganinya sebagai kasus khusus, dan memberi keuntungan tambahan berupa API wrapper library yang tetap kecil dan opinionated

• Selain membungkus library lama, mereka juga memblokir munculnya dependensi baru pada library lama. Ini dilakukan dengan menambahkan pemeriksaan CI menggunakan semgrep

4. Membungkus library baru

• Setelah library lama dibungkus, mereka dapat mulai menambahkan library baru di balik wrapper library
• Pada awalnya, implementasi baru dinonaktifkan melalui konfigurasi. Ini berarti mereka tidak mengharapkan perubahan perilaku dan dapat terus menggabungkan perubahan ke branch master secara bertahap

5. Deployment layanan massal

• Sebelum mulai mengaktifkan implementasi baru, mereka perlu memastikan bahwa semua layanan yang sedang berjalan dapat mendukung implementasi baru
• Untuk jenis perubahan library lainnya, hanya subset layanan dengan fitur baru yang mungkin perlu dideploy sekaligus. Namun untuk library tracing, jika suatu layanan telah dimigrasikan untuk menggunakan library baru, maka semua layanan yang dapat dipanggilnya (secara transisional) juga harus mendukung fungsi baru
• Untuk mengelola deployment ke banyak layanan, mereka membangun alat deployment massal yang dapat mendorong perubahan library ke semua layanan sebagai pekerjaan batch asinkron
• Untuk memitigasi dampak deployment yang berpotensi salah:
  • menggunakan pemeriksaan rollback otomatis
  • mendeploy layanan yang paling tidak kritis terlebih dahulu. Semua layanan diberi tag "tier", dan alat deployment massal menggunakan tag ini untuk memprioritaskan deployment yang paling tidak berisiko

6. Mengontrol rollout melalui konfigurasi

• Masalah dengan alat deployment massal adalah alat itu relatif lambat. Yang benar-benar ingin mereka hindari adalah mendeploy semua layanan lalu menemukan bahwa library baru bermasalah dan tidak bisa di-rollback dengan cepat
• Karena itu, alih-alih mendeploy dengan implementasi baru langsung aktif, mereka mendeploy kemampuan untuk mengaktifkan implementasi baru melalui sistem konfigurasi
• Dibanding deployment biasa, keuntungan menggunakan sistem konfigurasi di sini adalah kecepatannya. Semua layanan me-refresh konfigurasi setiap 60 detik, sehingga bila diperlukan mereka bisa melakukan rollback dengan cepat
• Ini juga memberi kontrol yang jauh lebih besar atas kapan implementasi baru digunakan. Misalnya, dapat diaktifkan hanya untuk himpunan pengguna tertentu atau persentase acak dari request
• Dalam kasus ini, mereka memilih melakukan rollout hanya untuk endpoint API yang dimiliki tim tersebut, dan mengaktifkannya berdasarkan probabilitas yang meningkat secara bertahap

7. Pembersihan

• Setelah sepenuhnya beralih ke implementasi baru, mereka melakukan tugas yang memuaskan dengan menghapus implementasi lama dari wrapper library

Superpower migrasi

• Jenis migrasi terpusat seperti ini dimungkinkan berkat pilihan teknologi dasar yang dibuat Monzo dan alat-alat yang terus mereka investasikan
• Teknologi yang konsisten: semua layanan ditulis dengan Go dan menggunakan versi yang sama dari library lama. Ini membuat otomatisasi perubahan jauh lebih mudah. Misalnya, mereka hanya memerlukan satu alat refactoring (bukan satu per bahasa)
• Monorepo: semua kode layanan berada dalam satu monorepo, sehingga refactoring skala besar jauh lebih mudah dilakukan dalam satu commit. Ini juga memungkinkan pemeriksaan CI menegakkan penggunaan library tertentu secara global, yang membantu menjaga konsistensi
• Deployment massal: jika ada banyak komponen yang dapat dideploy, dibutuhkan proses deployment otomatis untuk mendorong perubahan library
• Layanan konfigurasi yang ringan dan fleksibel: proses deployment aman tetapi lambat (beberapa menit per deployment). Diperlukan proses yang lebih ringan dan fleksibel untuk mengaktifkan/menonaktifkan fitur baru secara cepat dan segera di banyak layanan

Kesimpulan

• Di masa lalu, mereka mencoba mendistribusikan migrasi, tetapi hal ini tak terelakkan berujung pada migrasi yang tidak selesai dan banyak usaha koordinasi
• Inilah alasan Monzo sangat memilih migrasi terpusat. Satu tim memang harus menanggung biaya yang relatif tinggi, tetapi secara keseluruhan usaha yang dibutuhkan lebih sedikit dan peluang menjaga konsistensi jauh lebih besar
• Pendekatan ini menciptakan lingkaran kebajikan:
  • tim yang menjalankan migrasi memiliki insentif kuat untuk berinvestasi pada alat untuk mengotomatiskan migrasi
  • mereka juga menjaga konsistensi teknis (yang memudahkan pembangunan alat)
  • namun mereka tetap pragmatis soal tingkat otomatisasi — menerapkan aturan 80/20
• Selain alat-alat yang terus diinvestasikan Monzo, pendekatan ini juga hanya dimungkinkan berkat beberapa pilihan teknologi inti yang dibuat sejak awal
  • terutama karena mereka menggunakan kumpulan teknologi yang opinionated dan terbatas