Pembelajaran federasi lintas perangkat dan lintas silo di Google Cloud

Last reviewed 2024-04-12 UTC

Dokumen ini menjelaskan dua arsitektur referensi yang membantu Anda membuat platform federated learning di Google Cloud. Arsitektur referensi dan resource terkait yang dijelaskan dalam dokumen ini mendukung hal berikut:

  • {i>Cross-silo federated learning<i}
  • Federated learning lintas perangkat, yang dibangun berdasarkan arsitektur lintas-silo

Audiens yang dituju untuk dokumen ini adalah arsitek cloud serta engineer AI dan ML yang ingin menerapkan kasus penggunaan federated learning di Google Cloud. Fitur ini juga ditujukan bagi pembuat keputusan yang sedang mengevaluasi apakah akan menerapkan federated learning di Google Cloud atau tidak.

Arsitektur

Diagram di bagian ini menunjukkan arsitektur lintas-silo dan arsitektur lintas perangkat untuk federated learning.

Arsitektur lintas silo

Diagram berikut menunjukkan arsitektur yang mendukung federated learning lintas-silo:

Arsitektur lintas-silo, komponen yang dijelaskan dalam teks berikut.

Arsitektur sebelumnya mencakup komponen berikut:

  • Jaringan Virtual Private Cloud (VPC) dan subnet.
  • Cluster GKE pribadi yang membantu Anda melakukan hal-hal berikut:
    • Pisahkan node cluster dari internet.
    • Batasi eksposur node cluster dan bidang kontrol ke internet dengan membuat cluster GKE pribadi dengan jaringan yang diizinkan.
    • Gunakan node cluster terlindung yang menggunakan image sistem operasi yang telah diperkuat.
    • Aktifkan Dataplane V2 untuk jaringan Kubernetes yang dioptimalkan.
    • Enkripsikan rahasia cluster pada lapisan aplikasi.
  • Node pool GKE khusus: Anda membuat node pool khusus untuk menghosting aplikasi dan resource tenant secara eksklusif. Node memiliki taint untuk memastikan bahwa hanya beban kerja tenant yang dijadwalkan ke node tenant. Resource cluster lainnya dihosting di kumpulan node utama.
  • Aturan Firewall VPC yang menerapkan hal berikut:
    • Aturan dasar pengukuran yang berlaku untuk semua node dalam cluster.
    • Aturan tambahan yang hanya berlaku untuk node dalam kumpulan node tenant. Aturan firewall ini membatasi traffic masuk dan keluar dari node tenant.
  • Cloud NAT untuk memungkinkan traffic keluar ke internet.
  • Data Cloud DNS untuk mengaktifkan Akses Google Pribadi sehingga aplikasi dalam cluster dapat mengakses Google API tanpa melalui internet.
  • Akun layanan yang meliputi:
    • Akun layanan khusus untuk node dalam kumpulan node tenant.
    • Akun layanan khusus untuk aplikasi tenant yang akan digunakan dengan Workload Identity Federation.
  • Dukungan untuk menggunakan Google Grup untuk kontrol akses berbasis peran (RBAC) Google Grup untuk Kubernetes.
  • Cloud Source Repository untuk menyimpan deskriptor konfigurasi.
  • Repositori Artifact Registry untuk menyimpan image container.

Arsitektur lintas perangkat

Diagram berikut menunjukkan arsitektur yang mendukung federated learning lintas perangkat:

Arsitektur lintas perangkat, komponen yang dijelaskan dalam teks berikut.

Arsitektur lintas-perangkat sebelumnya dibangun berdasarkan arsitektur lintas-silo dengan penambahan komponen berikut:

  • Layanan Cloud Run yang menyimulasikan perangkat yang terhubung ke server
  • {i>Certificate Authority Service<i} yang membuat sertifikat pribadi untuk server dan klien yang akan dijalankan
  • Vertex AI TensorBoard untuk memvisualisasikan hasil pelatihan
  • Bucket Cloud Storage untuk menyimpan model gabungan
  • Cluster GKE pribadi yang menggunakan node rahasia sebagai kumpulan utamanya untuk membantu mengamankan data yang digunakan

Arsitektur lintas-perangkat menggunakan komponen dari project Federated Compute Platform (FCP) open source. Project ini mencakup hal berikut:

  • Kode klien untuk berkomunikasi dengan server dan menjalankan tugas pada perangkat
  • Protokol untuk komunikasi klien-server
  • Titik koneksi dengan TensorFlow Federated untuk mempermudah penentuan komputasi gabungan Anda

Komponen FCP yang ditampilkan dalam diagram sebelumnya dapat di-deploy sebagai serangkaian microservice. Komponen ini melakukan hal berikut:

  • Agregator: Tugas ini membaca gradien perangkat dan menghitung hasil gabungan dengan Privasi Diferensial.
  • Kolektor: Tugas ini berjalan secara berkala untuk membuat kueri tugas aktif dan gradien terenkripsi. Informasi ini menentukan kapan agregasi dimulai.
  • Uploader model: Tugas ini memproses peristiwa dan memublikasikan hasil sehingga perangkat dapat mendownload model yang diperbarui.
  • Penetapan tugas: Layanan front-end ini mendistribusikan tugas pelatihan ke perangkat.
  • Manajemen tugas: Tugas ini mengelola tugas.
  • Penjadwal tugas: Tugas ini berjalan secara berkala atau dipicu oleh peristiwa tertentu.

Produk yang digunakan

Arsitektur referensi untuk kedua kasus penggunaan federated learning menggunakan komponen Google Cloud berikut:

GKE juga menyediakan kemampuan berikut untuk platform federated learning Anda:

  • Menghosting koordinator federated learning: Koordinator federated learning bertanggung jawab untuk mengelola proses federated learning. Pengelolaan ini mencakup tugas-tugas seperti mendistribusikan model global kepada peserta, menggabungkan pembaruan dari peserta, dan memperbarui model global. GKE dapat digunakan untuk menghosting koordinator pembelajaran gabungan dengan cara yang sangat tersedia dan skalabel.
  • Menghosting peserta pembelajaran federasi: Peserta pembelajaran federasi bertanggung jawab untuk melatih model global pada data lokal mereka. GKE dapat digunakan untuk menghosting peserta federated learning dengan cara yang aman dan terisolasi. Pendekatan ini dapat membantu memastikan bahwa data peserta disimpan secara lokal.
  • Menyediakan saluran komunikasi yang aman dan skalabel: Peserta pembelajaran gabungan harus dapat berkomunikasi dengan koordinator pembelajaran gabungan dengan cara yang aman dan skalabel. GKE dapat digunakan untuk menyediakan saluran komunikasi yang aman dan skalabel antara peserta dan koordinator.
  • Mengelola siklus proses deployment federated learning: GKE dapat digunakan untuk mengelola siklus proses deployment federated learning. Pengelolaan ini mencakup tugas-tugas seperti menyediakan resource, men-deploy platform federated learning, dan memantau performa platform federated learning.

Selain manfaat tersebut, GKE juga menyediakan sejumlah fitur yang berguna untuk deployment federated learning, seperti:

  • Cluster regional: GKE memungkinkan Anda membuat cluster regional, yang membantu Anda meningkatkan performa deployment learning federasi dengan mengurangi latensi antara peserta dan koordinator.
  • Kebijakan jaringan: GKE memungkinkan Anda membuat kebijakan jaringan, yang membantu meningkatkan keamanan deployment federated learning dengan mengontrol aliran traffic antara peserta dan koordinator.
  • Load balancing: GKE menyediakan sejumlah opsi load balancing, yang membantu meningkatkan skalabilitas deployment federated learning dengan mendistribusikan traffic di antara peserta dan koordinator.

TFF menyediakan fitur berikut untuk memfasilitasi implementasi kasus penggunaan federated learning:

  • Kemampuan untuk mengekspresikan komputasi gabungan secara deklaratif, yang merupakan rangkaian langkah pemrosesan yang berjalan di server dan kumpulan klien. Komputasi ini dapat di-deploy ke berbagai lingkungan runtime.
  • Agregator kustom dapat dibangun menggunakan open source TFF.
  • Dukungan untuk berbagai algoritma federated learning, termasuk algoritma berikut:
    • Rata-rata gabungan: Algoritma sederhana yang menghitung rata-rata parameter model klien yang berpartisipasi. Solusi ini sangat cocok untuk kasus penggunaan di mana datanya relatif homogen dan modelnya tidak terlalu kompleks. Kasus penggunaan umum adalah sebagai berikut:
      • Rekomendasi yang dipersonalisasi: Perusahaan dapat menggunakan rata-rata gabungan untuk melatih model yang merekomendasikan produk kepada pengguna berdasarkan histori pembelian mereka.
      • Deteksi penipuan: Konsorsium bank dapat menggunakan rata-rata federasi untuk melatih model yang mendeteksi transaksi penipuan.
      • Diagnosis medis: Sekelompok rumah sakit dapat menggunakan rata-rata federasi untuk melatih model yang mendiagnosis kanker.
    • Penurunan gradien stokastik gabungan (FedSGD): Algoritma yang menggunakan penurunan gradien stokastik untuk memperbarui parameter model. Solusi ini sangat cocok untuk kasus penggunaan dengan data yang heterogen dan modelnya kompleks. Kasus penggunaan umum adalah sebagai berikut:
      • Natural language processing: Perusahaan dapat menggunakan FedSGD untuk melatih model yang meningkatkan akurasi pengenalan ucapan.
      • Pengenalan gambar: Perusahaan dapat menggunakan FedSGD untuk melatih model yang dapat mengidentifikasi objek dalam gambar.
      • Pemeliharaan prediktif: Perusahaan dapat menggunakan FedSGD untuk melatih model yang memprediksi kapan sebuah mesin kemungkinan akan gagal.
    • Adam Federasi: Algoritma yang menggunakan pengoptimal Adam untuk memperbarui parameter model. Kasus penggunaan umum adalah sebagai berikut:
      • Sistem pemberi rekomendasi: Perusahaan dapat menggunakan Adam federasi untuk melatih model yang merekomendasikan produk kepada pengguna berdasarkan histori pembelian mereka.
      • Peringkat: Perusahaan dapat menggunakan Adam federasi untuk melatih model yang mengurutkan hasil penelusuran.
      • Prediksi rasio klik-tayang: Perusahaan dapat menggunakan Adam federasi untuk melatih model yang memprediksi kemungkinan pengguna mengklik iklan.

Kasus penggunaan

Bagian ini menjelaskan kasus penggunaan ketika arsitektur lintas-silo dan lintas perangkat merupakan pilihan yang tepat untuk platform federated learning Anda.

Federated learning adalah lingkungan machine learning tempat banyak klien melatih model secara kolaboratif. Proses ini dipimpin oleh koordinator pusat, dan data pelatihan tetap terdesentralisasi.

Dalam paradigma federated learning, klien mendownload model global dan meningkatkan kualitas model dengan melatih data mereka secara lokal. Kemudian, setiap klien mengirimkan update model yang dihitungnya kembali ke server pusat tempat update model digabungkan dan iterasi baru dari model global akan dibuat. Dalam arsitektur referensi ini, workload pelatihan model dijalankan di GKE.

Pembelajaran federasi mewujudkan prinsip privasi minimalisasi data, dengan membatasi data apa saja yang dikumpulkan di setiap tahap komputasi, membatasi akses ke data, dan memproses lalu menghapus data secepat mungkin. Selain itu, setelan masalah federated learning kompatibel dengan teknik perlindungan privasi tambahan, seperti menggunakan privasi diferensial (DP) untuk meningkatkan anonimisasi model guna memastikan model akhir tidak mengingat data masing-masing pengguna.

Bergantung pada kasus penggunaannya, model pelatihan dengan federated learning dapat memberikan manfaat tambahan:

  • Kepatuhan: Dalam beberapa kasus, peraturan mungkin membatasi cara data dapat digunakan atau dibagikan. Pembelajaran federasi dapat digunakan untuk mematuhi peraturan ini.
  • Efisiensi komunikasi: Dalam beberapa kasus, melatih model pada data terdistribusi akan lebih efisien daripada memusatkan data. Misalnya, set data tempat model perlu dilatih terlalu besar untuk dipindahkan secara terpusat.
  • Menjadikan data mudah diakses: Federated learning memungkinkan organisasi menjaga data pelatihan tetap terdesentralisasi dalam silo data per pengguna atau per organisasi.
  • Akurasi model yang lebih tinggi: Dengan melatih data pengguna sebenarnya (sekaligus memastikan privasi), bukan data sintetis (terkadang disebut sebagai data proxy), hal ini sering kali menghasilkan akurasi model yang lebih tinggi.

Ada berbagai jenis federated learning, yang ditandai berdasarkan asal data dan tempat komputasi lokal terjadi. Arsitektur dalam dokumen ini berfokus pada dua jenis federated learning: lintas-silo dan lintas perangkat. Jenis federated learning lainnya berada di luar cakupan dokumen ini.

Pembelajaran federasi dikategorikan lebih lanjut berdasarkan cara set data dipartisi, yang dapat dihitung sebagai berikut:

  • Horizontal federated learning (HFL): Set data dengan fitur yang sama (kolom), tetapi sampel yang berbeda (baris). Misalnya, beberapa rumah sakit mungkin memiliki catatan pasien dengan parameter medis yang sama tetapi populasi pasien berbeda.
  • Vertical federated learning (VFL): Set data dengan sampel yang sama (baris), tetapi fiturnya berbeda (kolom). Misalnya, bank dan perusahaan e-commerce mungkin memiliki data pelanggan dengan individu yang tumpang-tindih, tetapi informasi keuangan dan pembeliannya berbeda.
  • Federated Transfer Learning (FTL): Tumpang-tindih sebagian dalam sampel dan fitur di antara set data. Misalnya, dua rumah sakit mungkin memiliki catatan pasien dengan beberapa individu yang tumpang-tindih dan beberapa parameter medis yang sama, tetapi juga memiliki fitur unik di setiap set data.

Komputasi gabungan lintas-silo adalah saat anggota yang berpartisipasi adalah organisasi atau perusahaan. Dalam praktiknya, jumlah anggota biasanya sedikit (misalnya, dalam seratus anggota). Komputasi lintas silo biasanya digunakan dalam skenario saat organisasi yang berpartisipasi memiliki set data yang berbeda, tetapi mereka ingin melatih model bersama atau menganalisis hasil gabungan tanpa berbagi data mentah satu sama lain. Untuk membantu Anda mengisolasi workload yang dimiliki oleh berbagai organisasi peserta, arsitektur referensi lintas-silo mengimplementasikan kontrol keamanan, seperti namespace khusus dan kumpulan node GKE. Komunikasi lintas namespace serta traffic masuk dan keluar cluster dilarang secara default, kecuali jika Anda secara eksplisit mengganti setelan ini.

Contoh kasus penggunaan untuk pembelajaran federasi lintas-silo adalah sebagai berikut:

  • Deteksi penipuan: Federated learning dapat digunakan untuk melatih model deteksi penipuan pada data yang didistribusikan di beberapa organisasi. Misalnya, konsorsium bank dapat menggunakan federated learning untuk melatih model yang mendeteksi transaksi penipuan.
  • Diagnosis medis: Pembelajaran federasi dapat digunakan untuk melatih model diagnosis medis pada data yang didistribusikan di beberapa rumah sakit. Misalnya, sekelompok rumah sakit dapat menggunakan federated learning untuk melatih model yang mendiagnosis kanker.

Federated learning lintas perangkat adalah jenis komputasi gabungan, di mana anggota yang berpartisipasi adalah perangkat pengguna akhir seperti ponsel, kendaraan, atau perangkat IoT. Jumlah anggotanya dapat mencapai skala jutaan atau bahkan puluhan juta.

Proses federated learning lintas perangkat mirip dengan pembelajaran federasi lintas-silo. Namun, hal ini juga mengharuskan Anda untuk menyesuaikan arsitektur referensi untuk mengakomodasi beberapa faktor tambahan yang harus dipertimbangkan saat menangani ribuan hingga jutaan perangkat. Anda harus men-deploy beban kerja administratif untuk menangani skenario yang ditemukan di kasus penggunaan federated learning lintas perangkat. Misalnya, kebutuhan untuk mengkoordinasikan subset klien yang akan berlangsung selama tahap pelatihan. Arsitektur lintas-perangkat memberikan kemampuan ini dengan memungkinkan Anda men-deploy layanan FCP. Layanan ini memiliki beban kerja yang memiliki titik koneksi dengan TFF. TFF digunakan untuk menulis kode yang mengelola koordinasi ini.

Contoh kasus penggunaan federated learning lintas perangkat adalah sebagai berikut:

  • Rekomendasi yang dipersonalisasi: Anda dapat menggunakan federated learning lintas perangkat untuk melatih model rekomendasi yang dipersonalisasi pada data yang didistribusikan di beberapa perangkat. Misalnya, perusahaan dapat menggunakan federated learning untuk melatih model yang merekomendasikan produk kepada pengguna berdasarkan histori pembelian mereka.
  • Natural language processing: Federated learning dapat digunakan untuk melatih model natural language processing pada data yang didistribusikan di beberapa perangkat. Misalnya, perusahaan dapat menggunakan federated learning untuk melatih model yang meningkatkan akurasi pengenalan ucapan.
  • Memprediksi kebutuhan perawatan kendaraan: Federated learning dapat digunakan untuk melatih model yang memprediksi kapan kendaraan mungkin memerlukan pemeliharaan. Model ini dapat dilatih dengan data yang dikumpulkan dari beberapa kendaraan. Pendekatan ini memungkinkan model belajar dari pengalaman semua kendaraan, tanpa mengorbankan privasi setiap kendaraan.

Tabel berikut merangkum fitur arsitektur lintas-silo dan lintas perangkat, serta menunjukkan cara mengategorikan jenis skenario federated learning yang berlaku untuk kasus penggunaan Anda.

Fitur Komputasi federasi lintas-silo Komputasi gabungan lintas perangkat
Ukuran populasi Biasanya kecil (misalnya, dalam seratus perangkat) Skalabel ke ribuan, jutaan, atau ratusan juta perangkat
Anggota yang berpartisipasi Organisasi atau perusahaan Perangkat seluler, perangkat edge, kendaraan
Partisi data yang paling umum HFL, VFL, FTL HFL
Sensitivitas data Data sensitif yang tidak ingin dibagikan oleh peserta satu sama lain dalam format mentah Data yang terlalu sensitif untuk dibagikan dengan server pusat
Ketersediaan data Peserta hampir selalu ada Hanya sebagian kecil peserta yang tersedia kapan saja
Contoh kasus penggunaan Deteksi penipuan, diagnosis medis, perkiraan keuangan Pelacakan kebugaran, pengenalan suara, klasifikasi gambar

Pertimbangan desain

Bagian ini berisi panduan untuk membantu Anda menggunakan arsitektur referensi ini untuk mengembangkan satu atau beberapa arsitektur yang memenuhi persyaratan khusus Anda untuk keamanan, keandalan, efisiensi operasional, biaya, dan performa.

Pertimbangan desain arsitektur lintas-silo

Untuk mengimplementasikan arsitektur federated learning lintas-silo di Google Cloud, Anda harus menerapkan prasyarat minimum berikut, yang dijelaskan secara lebih mendetail di bagian berikut:

  1. Bangun konsorsium federated learning.
  2. Tentukan model kolaborasi yang akan diterapkan oleh konsorsium federated learning.
  3. Menentukan tanggung jawab organisasi peserta.

Selain prasyarat tersebut, ada tindakan lain yang harus dilakukan oleh pemilik gabungan yang berada di luar cakupan dokumen ini, seperti berikut ini:

  • Kelola konsorsium federated learning.
  • Desain dan terapkan model kolaborasi.
  • Siapkan, kelola, dan operasikan data pelatihan model dan model yang ingin dilatih oleh pemilik federasi.
  • Buat, masukkan ke dalam container, dan atur alur kerja federated learning.
  • Deploy dan kelola beban kerja federated learning.
  • Siapkan saluran komunikasi bagi organisasi yang ikut serta untuk mentransfer data dengan aman.

Membentuk konsorsium federated learning

Konsorsium pembelajaran federasi adalah grup organisasi yang berpartisipasi dalam upaya pembelajaran federasi federasi lintas-silo. Organisasi di konsorsium hanya membagikan parameter model ML, dan Anda dapat mengenkripsi parameter ini untuk meningkatkan privasi. Jika konsorsium federated learning mengizinkan praktik ini, organisasi juga dapat menggabungkan data yang tidak berisi informasi identitas pribadi (PII).

Menentukan model kolaborasi untuk konsorsium federated learning

Konsorsium federated learning dapat menerapkan berbagai model kolaborasi, seperti berikut:

  • Model terpusat yang terdiri dari satu organisasi koordinasi, yang disebut pemilik federasi atau orkestrasi, dan kumpulan organisasi peserta atau pemilik data.
  • Model terdesentralisasi yang terdiri atas organisasi yang berkoordinasi sebagai grup.
  • Model heterogen yang terdiri dari konsorsium beragam organisasi yang berpartisipasi, yang semuanya membawa berbagai resource ke konsorsium.

Dokumen ini mengasumsikan bahwa model kolaborasi adalah model terpusat.

Menentukan tanggung jawab organisasi peserta

Setelah memilih model kolaborasi untuk konsorsium federated learning, pemilik federasi harus menentukan tanggung jawab untuk organisasi peserta.

Pemilik federasi juga harus melakukan hal berikut saat memulai pembuatan konsorsium federated learning:

  • Mengoordinasi upaya federated learning.
  • Desain dan terapan model ML global dan model ML untuk dibagikan kepada organisasi peserta.
  • Tentukan federated learning round—pendekatan untuk iterasi proses pelatihan ML.
  • Pilih organisasi peserta yang berkontribusi pada sesi federated learning tertentu. Pilihan ini disebut kelompok.
  • Desain dan penerapan prosedur verifikasi keanggotaan konsorsium untuk organisasi peserta.
  • Perbarui model ML global dan model ML untuk dibagikan ke organisasi peserta.
  • Menyediakan alat kepada organisasi peserta untuk memvalidasi bahwa konsorsium federated learning memenuhi persyaratan privasi, keamanan, dan peraturan mereka.
  • Menyediakan saluran komunikasi yang aman dan terenkripsi kepada peserta.
  • Menyediakan semua data gabungan yang diperlukan dan tidak bersifat rahasia kepada peserta untuk menyelesaikan setiap sesi federated learning.

Organisasi peserta memiliki tanggung jawab berikut:

  • Sediakan dan jaga lingkungan yang aman dan terisolasi (silo). Samlo adalah tempat organisasi peserta menyimpan data mereka sendiri, dan tempat pelatihan model ML diterapkan.
  • Latih model yang disediakan oleh pemilik federasi menggunakan infrastruktur komputasi dan data lokal masing-masing.
  • Bagikan hasil pelatihan model kepada pemilik federasi dalam bentuk data gabungan, setelah menghapus PII apa pun.

Pemilik federasi dan organisasi peserta meningkatkan pelatihan model ML hingga model tersebut memenuhi persyaratan mereka.

Menerapkan federated learning di Google Cloud

Setelah membentuk konsorsium federated learning dan menentukan cara konsorsium federated learning, sebaiknya organisasi peserta melakukan hal berikut:

  1. Sediakan dan konfigurasi infrastruktur yang diperlukan untuk konsorsium federated learning.
  2. Implementasikan model kolaborasi.
  3. Mulai upaya federated learning.

Menyediakan dan mengonfigurasi infrastruktur untuk konsorsium federated learning

Saat menyediakan dan mengonfigurasi infrastruktur untuk konsorsium federated learning, pemilik federasi bertanggung jawab dalam membuat dan mendistribusikan workload yang melatih model ML federasi ke organisasi peserta. Karena pihak ketiga (pemilik federasi) membuat dan menyediakan beban kerja, organisasi peserta harus mengambil tindakan pencegahan saat men-deploy workload tersebut di lingkungan runtime mereka.

Organisasi peserta harus mengonfigurasi lingkungan sesuai dengan praktik terbaik keamanan individual mereka, dan menerapkan kontrol yang membatasi cakupan dan izin yang diberikan ke setiap beban kerja. Selain mengikuti praktik terbaik keamanan individual mereka, sebaiknya pemilik federasi dan organisasi peserta mempertimbangkan vektor ancaman yang spesifik untuk federated learning.

Mengimplementasikan model kolaborasi

Setelah infrastruktur konsorsium federated learning disiapkan, pemilik federasi mendesain dan menerapkan mekanisme yang memungkinkan organisasi peserta saling berinteraksi. Pendekatan ini mengikuti model kolaborasi yang dipilih pemilik federasi untuk konsorsium federated learning.

Memulai upaya federated learning

Setelah menerapkan model kolaborasi, pemilik federasi menerapkan model ML global untuk dilatih, dan model ML untuk dibagikan dengan organisasi peserta. Setelah model ML tersebut siap, pemilik federasi memulai tahap pertama upaya federated learning.

Selama setiap putaran upaya federated learning, pemilik federasi melakukan hal-hal berikut:

  1. Mendistribusikan model ML untuk dibagikan kepada organisasi peserta.
  2. Menunggu organisasi peserta mengirimkan hasil pelatihan model ML yang dibagikan oleh pemilik federasi.
  3. Mengumpulkan dan memproses hasil pelatihan yang dihasilkan organisasi peserta.
  4. Mengupdate model ML global saat mereka menerima hasil pelatihan yang sesuai dari organisasi yang berpartisipasi.
  5. Memperbarui model ML untuk dibagikan ke anggota konsorsium lainnya jika berlaku.
  6. Menyiapkan data pelatihan untuk tahap federated learning selanjutnya.
  7. Memulai tahap federated learning selanjutnya.

Keamanan, privasi, dan kepatuhan:

Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan saat menggunakan arsitektur referensi ini untuk mendesain dan membangun platform federated learning di Google Cloud. Panduan ini berlaku untuk kedua arsitektur yang dijelaskan dokumen ini.

Workload federated learning yang Anda deploy di lingkungan dapat mengekspos Anda, data, model federated learning, dan infrastruktur Anda terhadap ancaman yang dapat memengaruhi bisnis Anda.

Untuk membantu Anda meningkatkan keamanan lingkungan federated learning, arsitektur referensi ini mengonfigurasi kontrol keamanan GKE yang berfokus pada infrastruktur lingkungan Anda. Kontrol ini mungkin tidak cukup untuk melindungi Anda dari ancaman yang spesifik untuk beban kerja federated learning dan kasus penggunaan Anda. Mengingat kekhususan setiap beban kerja dan kasus penggunaan federated learning, kontrol keamanan yang bertujuan untuk mengamankan implementasi federated learning Anda berada di luar cakupan dokumen ini. Untuk mengetahui informasi dan contoh selengkapnya tentang ancaman ini, lihat pertimbangan keamanan Pembelajaran Federasi.

Kontrol keamanan GKE

Bagian ini membahas kontrol yang Anda terapkan pada arsitektur ini untuk membantu mengamankan cluster GKE Anda.

Keamanan cluster GKE yang ditingkatkan

Arsitektur referensi ini membantu Anda membuat cluster GKE yang menerapkan setelan keamanan berikut:

Untuk mengetahui informasi selengkapnya tentang setelan keamanan GKE, lihat Meningkatkan keamanan cluster dan Tentang dasbor postur keamanan.

Aturan firewall VPC

Aturan firewall Virtual Private Cloud (VPC) mengatur traffic mana yang diizinkan ke atau dari VM Compute Engine. Aturan ini memungkinkan Anda memfilter traffic pada tingkat perincian VM, bergantung pada atribut Lapisan 4.

Anda dapat membuat cluster GKE dengan aturan firewall cluster GKE default. Aturan firewall ini memungkinkan komunikasi antara node cluster dan bidang kontrol GKE, serta antara node dan Pod dalam cluster.

Anda dapat menerapkan aturan firewall tambahan ke node di node pool tenant. Aturan firewall ini membatasi traffic keluar dari node tenant. Pendekatan ini dapat meningkatkan isolasi node tenant. Secara default, semua traffic keluar dari node tenant ditolak. Setiap traffic keluar yang diperlukan harus dikonfigurasi secara eksplisit. Misalnya, Anda membuat aturan firewall untuk mengizinkan traffic keluar dari tenant node ke bidang kontrol GKE, dan ke Google API menggunakan Akses Google Pribadi. Aturan firewall ditargetkan ke node tenant dengan menggunakan akun layanan untuk kumpulan node tenant.

Namespace

Namespace memungkinkan Anda menyediakan cakupan untuk resource terkait dalam suatu cluster, misalnya seperti Pod, Service, dan pengontrol replikasi. Dengan menggunakan namespace, Anda dapat mendelegasikan tanggung jawab administrasi atas resource terkait sebagai suatu unit. Oleh karena itu, namespace merupakan bagian tak terpisahkan dari sebagian besar pola keamanan.

Namespace adalah fitur penting untuk isolasi bidang kontrol. Namun, namespace tidak menyediakan isolasi node, isolasi bidang data, atau isolasi jaringan.

Pendekatan yang umum dilakukan yaitu membuat namespace untuk aplikasi individu. Misalnya, Anda dapat membuat namespace myapp-frontend untuk komponen UI aplikasi.

Arsitektur referensi ini membantu Anda membuat namespace khusus untuk menghosting aplikasi pihak ketiga. Namespace dan resource-nya dianggap sebagai tenant dalam cluster Anda. Anda dapat menerapkan kebijakan dan kontrol ke namespace untuk membatasi cakupan resource di dalam namespace.

Kebijakan jaringan

Kebijakan jaringan menerapkan aliran traffic jaringan Lapisan 4 menggunakan aturan firewall level Pod. Kebijakan jaringan tercakup dalam suatu namespace.

Dalam arsitektur referensi yang dijelaskan dalam dokumen ini, Anda menerapkan kebijakan jaringan ke namespace tenant yang menghosting aplikasi pihak ketiga. Secara default, kebijakan jaringan menolak semua traffic ke dan dari pod dalam namespace. Setiap traffic yang diperlukan harus ditambahkan secara eksplisit ke daftar yang diizinkan. Misalnya, kebijakan jaringan dalam arsitektur referensi ini secara eksplisit mengizinkan traffic ke layanan cluster yang diperlukan, seperti DNS internal cluster dan bidang kontrol Anthos Service Mesh.

Config Sync

Config Sync menjaga cluster GKE Anda tetap sinkron dengan konfigurasi yang disimpan di repositori Git. Repositori Git bertindak sebagai satu-satunya sumber tepercaya untuk konfigurasi dan kebijakan cluster Anda. Config Sync bersifat deklaratif. Fungsi ini akan terus memeriksa status cluster dan menerapkan status yang dideklarasikan dalam file konfigurasi untuk menerapkan kebijakan, yang membantu mencegah penyimpangan konfigurasi.

Config Sync diinstal ke dalam cluster GKE Anda. Anda mengonfigurasi Config Sync untuk menyinkronkan konfigurasi dan kebijakan cluster dari repositori Sumber Cloud. Resource yang disinkronkan mencakup hal berikut:

  • Konfigurasi Anthos Service Mesh level cluster
  • Kebijakan keamanan level cluster
  • Konfigurasi dan kebijakan level namespace tenant, termasuk kebijakan jaringan, akun layanan, aturan RBAC, dan konfigurasi Anthos Service Mesh

Pengontrol Kebijakan

Pengontrol Kebijakan edisi Google Kubernetes Engine (GKE) Enterprise adalah pengontrol penerimaan dinamis untuk Kubernetes yang menerapkan kebijakan Berbasis CustomResourceDefinition (berbasis CRD) yang dijalankan oleh Open Policy Agent (OPA).

Pengontrol penerimaan merupakan plugin Kubernetes yang mencegat permintaan ke server API Kubernetes sebelum suatu objek disimpan, tetapi setelah permintaan diautentikasi dan diotorisasi. Anda dapat menggunakan pengontrol penerimaan untuk membatasi cara penggunaan suatu cluster.

Pengontrol Kebijakan diinstal ke dalam cluster GKE Anda. Arsitektur referensi ini menyertakan kebijakan contoh untuk membantu mengamankan cluster Anda. Anda akan otomatis menerapkan kebijakan ke cluster menggunakan Config Sync. Anda dapat menerapkan kebijakan berikut:

Anthos Service Mesh

Anthos Service Mesh adalah mesh layanan yang membantu Anda menyederhanakan pengelolaan komunikasi yang aman di seluruh layanan. Arsitektur referensi ini mengonfigurasi Anthos Service Mesh sehingga melakukan hal berikut:

  • Memasukkan proxy file bantuan secara otomatis.
  • Menerapkan komunikasi mTLS antara layanan di mesh.
  • Membatasi traffic mesh keluar hanya ke host yang diketahui.
  • Membatasi traffic masuk hanya dari klien tertentu.
  • Memungkinkan Anda mengonfigurasi kebijakan keamanan jaringan berdasarkan identitas layanan, bukan berdasarkan alamat IP pembanding pada jaringan.
  • Membatasi komunikasi yang diizinkan antara layanan di mesh. Misalnya, aplikasi di namespace tenant hanya diizinkan untuk berkomunikasi dengan aplikasi di namespace yang sama, atau dengan serangkaian host eksternal yang dikenal.
  • Merutekan semua traffic masuk dan keluar melalui gateway mesh, tempat Anda dapat menerapkan kontrol traffic lebih lanjut.

Taint node dan afinitas

Taint node dan afinitas node merupakan mekanisme Kubernetes yang memungkinkan Anda memengaruhi cara pod dijadwalkan ke node cluster.

Node yang terkena taint akan menolak pod. Kubernetes tidak akan menjadwalkan Pod ke node yang tercemar kecuali Pod memiliki tolerasi untuk taint. Anda dapat menggunakan taint node untuk mencadangkan node agar hanya digunakan oleh workload atau tenant tertentu. Taint dan toleransi sering digunakan dalam cluster multi-tenant. Untuk informasi selengkapnya, lihat dokumentasi node khusus dengan taint dan toleransi.

Afinitas node memungkinkan Anda membatasi pod ke node dengan label tertentu. Jika pod memiliki persyaratan afinitas node, Kubernetes tidak akan menjadwalkan Pod ke node kecuali jika node tersebut memiliki label yang cocok dengan persyaratan afinitas. Anda dapat menggunakan afinitas node untuk memastikan bahwa pod dijadwalkan ke node yang sesuai.

Anda dapat menggunakan taint node dan afinitas node affinity secara bersamaan untuk memastikan bahwa pod workload tenant dijadwalkan secara eksklusif ke node yang dicadangkan untuk tenant.

Arsitektur referensi ini membantu Anda mengontrol penjadwalan aplikasi tenant dengan cara berikut:

  • Membuat node pool GKE khusus untuk tenant. Setiap node yang ada dalam pool memiliki taint yang terkait dengan nama tenant.
  • Otomatis menerapkan toleransi dan afinitas node yang sesuai ke Pod mana pun yang menargetkan namespace tenant. Anda dapat menerapkan toleransi dan afinitas tersebut menggunakan mutasi PolicyController.

Hak istimewa terendah

Praktik terbaik keamanan adalah mengadopsi prinsip hak istimewa terendah untuk project Google Cloud dan resource seperti cluster GKE. Dengan pendekatan ini, aplikasi yang berjalan di dalam cluster Anda, serta developer dan operator yang menggunakan cluster tersebut, hanya memiliki serangkaian izin minimum yang diperlukan.

Arsitektur referensi ini membantu Anda menggunakan akun layanan dengan hak istimewa terendah dengan cara berikut:

  • Setiap node pool GKE menerima akun layanannya sendiri. Misalnya, node yang berada dalam node pool tenant menggunakan akun layanan khusus untuk node tersebut. Akun layanan node dikonfigurasi dengan izin minimum yang diperlukan.
  • Cluster menggunakan Workload Identity untuk mengaitkan akun layanan Kubernetes dengan akun layanan Google. Dengan cara ini, aplikasi tenant dapat diberi akses terbatas ke Google API mana pun yang diperlukan tanpa harus mendownload dan menyimpan kunci akun layanan. Misalnya, Anda dapat memberikan izin ke akun layanan untuk membaca data dari bucket Cloud Storage.

Arsitektur referensi ini membantu Anda membatasi akses ke resource cluster dengan cara berikut:

  • Buatlah contoh peran Kubernetes RBAC dengan izin terbatas untuk mengelola aplikasi. Anda dapat memberikan peran ini kepada pengguna dan grup yang mengoperasikan aplikasi di namespace tenant. Dengan menerapkan peran terbatas pada pengguna dan grup ini, pengguna tersebut hanya memiliki izin untuk mengubah resource aplikasi di namespace tenant. Server tersebut tidak memiliki izin untuk mengubah resource level cluster atau setelan keamanan sensitif seperti kebijakan Anthos Service Mesh.

Pertimbangan keamanan pembelajaran gabungan

Meskipun memiliki model berbagi data yang ketat, federated learning tidak secara inheren aman dari semua serangan yang ditargetkan, dan risiko ini harus diperhitungkan saat Anda men-deploy salah satu arsitektur yang dijelaskan dalam dokumen ini. Ada juga risiko kebocoran informasi yang tidak diinginkan tentang model ML atau data pelatihan model. Misalnya, penyerang mungkin sengaja membobol model ML global atau putaran upaya federated learning, atau mungkin mengeksekusi serangan waktu (sejenis serangan side-channel) untuk mengumpulkan informasi tentang ukuran set data pelatihan.

Ancaman yang paling umum terhadap penerapan federated learning adalah sebagai berikut:

  • Menghafal data pelatihan yang disengaja atau tidak disengaja. Implementasi pembelajaran federasi atau penyerang mungkin sengaja atau tidak sengaja menyimpan data dengan cara yang mungkin sulit digunakan. Penyerang mungkin dapat mengumpulkan informasi tentang model ML global atau tahap sebelumnya dari upaya federated learning dengan merekayasa data yang tersimpan.
  • Ekstrak informasi dari update ke model ML global. Selama upaya pembelajaran federasi, penyerang dapat merekayasa balik update pada model ML global yang dikumpulkan pemilik federasi dari perangkat dan organisasi peserta.
  • Pemilik federasi mungkin membahayakan putaran. Pemilik federasi yang disusupi mungkin mengontrol rogue silo atau perangkat dan memulai putaran upaya federated learning. Di akhir babak, pemilik gabungan yang disusupi mungkin dapat mengumpulkan informasi tentang update yang dikumpulkannya dari perangkat dan organisasi peserta yang sah dengan membandingkan update tersebut dengan update yang dihasilkan oleh rogue silo.
  • Perangkat dan organisasi peserta mungkin membahayakan model ML global. Selama upaya federated learning, penyerang mungkin akan berupaya memengaruhi performa, kualitas, atau integritas model ML global secara berbahaya dengan menghasilkan update yang tidak bertanggung jawab atau tidak penting.

Untuk membantu mengurangi dampak ancaman yang dijelaskan di bagian ini, sebaiknya lakukan praktik terbaik berikut:

  • Menyesuaikan model untuk meminimalkan penghafalan data pelatihan.
  • Menerapkan mekanisme yang menjaga privasi.
  • Audit secara rutin model ML global, model ML yang ingin Anda bagikan, data pelatihan, dan infrastruktur yang Anda implementasikan untuk mencapai sasaran pembelajaran federasi Anda.
  • Terapkan algoritma agregasi yang aman untuk memproses hasil pelatihan dari organisasi peserta.
  • Membuat dan mendistribusikan kunci enkripsi data dengan aman menggunakan infrastruktur kunci publik.
  • Deploy infrastruktur ke platform komputasi rahasia.

Pemilik Federasi juga harus melakukan langkah-langkah tambahan berikut:

  • Verifikasi identitas setiap organisasi peserta dan integritas setiap silo jika terdapat arsitektur lintas-silo, serta identitas dan integritas setiap perangkat jika arsitektur lintas-perangkat.
  • Batasi cakupan update pada model ML global yang dapat dihasilkan oleh organisasi dan perangkat peserta.

Keandalan

Bagian ini menjelaskan faktor desain yang harus Anda pertimbangkan saat menggunakan salah satu arsitektur referensi dalam dokumen ini untuk mendesain dan membangun platform federated learning di Google Cloud.

Saat mendesain arsitektur federated learning di Google Cloud, sebaiknya ikuti panduan di bagian ini untuk meningkatkan ketersediaan dan skalabilitas workload, serta membantu menjadikan arsitektur Anda tahan terhadap pemadaman layanan dan bencana.

GKE: GKE mendukung beberapa jenis cluster berbeda yang dapat Anda sesuaikan dengan persyaratan ketersediaan workload dan anggaran Anda. Misalnya, Anda dapat membuat cluster regional yang mendistribusikan bidang kontrol dan node di beberapa zona dalam suatu region, atau cluster zona yang memiliki bidang kontrol dan node dalam satu zona. Arsitektur referensi lintas-silo dan lintas perangkat mengandalkan cluster GKE regional. Untuk mengetahui informasi selengkapnya tentang aspek yang perlu dipertimbangkan saat membuat cluster GKE, lihat pilihan konfigurasi cluster.

Bergantung pada jenis cluster serta cara bidang kontrol dan node cluster didistribusikan di seluruh region dan zona, GKE menawarkan kemampuan pemulihan dari bencana yang berbeda untuk melindungi workload Anda dari pemadaman layanan zona dan regional. Untuk mengetahui informasi selengkapnya tentang kemampuan pemulihan dari bencana GKE, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE mendukung beberapa cara traffic load balancing ke workload Anda. Dengan implementasi GKE, Gateway Kubernetes dan Kubernetes Service API, Anda dapat otomatis menyediakan dan mengonfigurasi Cloud Load Balancing untuk mengekspos workload yang berjalan di cluster GKE dengan aman dan andal.

Dalam arsitektur referensi ini, semua traffic masuk dan keluar melewati gateway Anthos Service Mesh. Dengan gateway ini, Anda dapat mengontrol secara ketat alur traffic di dalam dan di luar cluster GKE.

Tantangan keandalan untuk federated learning lintas perangkat

federated learning lintas perangkat memiliki sejumlah tantangan keandalan yang tidak dialami dalam skenario lintas-silo. Contoh ini meliputi:

  • Konektivitas perangkat yang tidak dapat diandalkan atau terputus-putus
  • Penyimpanan perangkat terbatas
  • Komputasi dan memori terbatas

Konektivitas yang tidak stabil dapat menyebabkan masalah seperti berikut:

  • Update yang sudah tidak berlaku dan divergensi model: Jika perangkat mengalami konektivitas yang terputus-putus, update model lokalnya mungkin menjadi tidak berlaku lagi, yang menunjukkan informasi yang sudah tidak berlaku dibandingkan dengan status model global saat ini. Menggabungkan update yang sudah tidak berlaku dapat menyebabkan divergensi model, dengan model global yang menyimpang dari solusi optimal karena inkonsistensi dalam proses pelatihan.
  • Kontribusi yang tidak seimbang dan model yang bias: Komunikasi yang terputus-putus dapat menyebabkan distribusi kontribusi yang tidak merata dari perangkat yang berpartisipasi. Perangkat dengan konektivitas yang buruk dapat menyebabkan update yang lebih sedikit, sehingga menyebabkan representasi distribusi data yang mendasarinya tidak seimbang. Ketidakseimbangan ini dapat membiaskan model global terhadap data dari perangkat dengan koneksi yang lebih andal.
  • Peningkatan overhead komunikasi dan konsumsi energi: Komunikasi yang terputus-putus dapat menyebabkan peningkatan overhead komunikasi, karena perangkat mungkin perlu mengirim ulang update yang hilang atau rusak. Masalah ini juga dapat meningkatkan konsumsi energi pada perangkat, terutama bagi perangkat yang memiliki masa pakai baterai terbatas, karena pengguna mungkin perlu mempertahankan koneksi aktif dalam jangka waktu yang lebih lama untuk memastikan transmisi update yang berhasil.

Untuk membantu mengurangi beberapa efek yang disebabkan oleh komunikasi yang terputus-putus, arsitektur referensi dalam dokumen ini dapat digunakan dengan FCP.

Arsitektur sistem yang menjalankan protokol FCP dapat dirancang untuk memenuhi persyaratan berikut:

  • Menangani putaran yang berlangsung lama.
  • Aktifkan eksekusi spekulatif (putaran dapat dimulai sebelum jumlah klien yang diperlukan dikumpulkan untuk mengantisipasi pemeriksaan lebih lanjut dalam waktu dekat).
  • Memungkinkan perangkat memilih tugas mana yang ingin mereka ikuti. Pendekatan ini dapat mengaktifkan fitur seperti pengambilan sampel tanpa penggantian, yang merupakan strategi pengambilan sampel dengan setiap unit sampel populasi hanya memiliki satu kesempatan untuk dipilih. Pendekatan ini membantu mengurangi kontribusi yang tidak seimbang dan model yang bias
  • Dapat diperluas untuk teknik anonimisasi seperti privasi diferensial (DP) dan agregasi tepercaya (TAG).

Untuk membantu mengurangi keterbatasan penyimpanan perangkat dan kemampuan komputasi, teknik berikut dapat membantu:

  • Memahami kapasitas maksimum yang tersedia untuk menjalankan komputasi federasi learning
  • Memahami jumlah data yang dapat disimpan pada waktu tertentu
  • Desain kode federated learning sisi klien untuk beroperasi dalam komputasi dan RAM yang tersedia di klien
  • Pahami implikasi kehabisan penyimpanan dan terapkan proses untuk mengelola

Pengoptimalan biaya

Bagian ini berisi panduan untuk mengoptimalkan biaya pembuatan dan pengoperasian platform federated learning di Google Cloud yang Anda buat menggunakan arsitektur referensi ini. Panduan ini berlaku untuk kedua arsitektur yang dijelaskan dalam dokumen ini.

Menjalankan workload di GKE dapat membantu Anda mengoptimalkan lingkungan dengan menyediakan dan mengonfigurasi cluster sesuai dengan persyaratan resource workload Anda. Selain itu, node cluster juga mengaktifkan fitur yang mengonfigurasi ulang cluster dan node cluster Anda secara dinamis, seperti menskalakan node cluster dan Pod secara otomatis, serta dengan menyesuaikan ukuran cluster Anda.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan biaya lingkungan GKE, lihat Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE.

Efisiensi operasional

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan untuk mengoptimalkan efisiensi saat Anda menggunakan arsitektur referensi ini untuk membuat dan menjalankan platform federated learning di Google Cloud. Panduan ini berlaku untuk kedua arsitektur yang dijelaskan dalam dokumen ini.

Untuk meningkatkan otomatisasi dan pemantauan arsitektur federated learning, sebaiknya Anda mengadopsi prinsip MLOps, yang merupakan prinsip DevOps dalam konteks sistem machine learning. Mempraktikkan MLOps berarti Anda mendukung otomatisasi dan pemantauan di semua langkah konstruksi sistem ML, termasuk integrasi, pengujian, rilis, deployment, dan pengelolaan infrastruktur. Untuk mengetahui informasi selengkapnya tentang MLOps, lihat MLOps: Pipeline otomatisasi dan continuous delivery di machine learning.

Pengoptimalan performa

Bagian ini menjelaskan faktor-faktor yang perlu dipertimbangkan untuk mengoptimalkan performa workload ketika Anda menggunakan arsitektur referensi ini untuk membuat dan menjalankan platform federated learning di Google Cloud. Panduan ini berlaku untuk kedua arsitektur yang dijelaskan dalam dokumen ini.

GKE mendukung beberapa fitur untuk menyesuaikan ukuran dan menskalakan lingkungan GKE Anda secara otomatis dan manual guna memenuhi permintaan workload Anda, serta membantu Anda menghindari penyediaan resource yang berlebihan. Misalnya, Anda dapat menggunakan Pemberi Rekomendasi untuk membuat insight dan rekomendasi guna mengoptimalkan penggunaan resource GKE.

Saat memikirkan cara menskalakan lingkungan GKE, sebaiknya Anda merancang rencana jangka pendek, menengah, dan panjang terkait cara menskalakan lingkungan dan workload Anda. Misalnya, bagaimana Anda ingin mengembangkan jejak GKE dalam beberapa minggu, bulan, dan tahun? Dengan menyiapkan rencana, Anda dapat memanfaatkan fitur skalabilitas yang disediakan GKE secara optimal, mengoptimalkan lingkungan GKE, dan mengurangi biaya. Untuk mengetahui informasi selengkapnya tentang perencanaan skalabilitas cluster dan workload, lihat Tentang Skalabilitas GKE.

Untuk meningkatkan performa workload ML, Anda dapat mengadopsi Cloud Tensor Processing Unit (Cloud TPU), akselerator AI rancangan Google yang dioptimalkan untuk pelatihan dan inferensi model AI besar.

Deployment

Untuk men-deploy arsitektur referensi lintas-silo dan lintas perangkat yang dijelaskan dalam dokumen ini, lihat repositori GitHub Federated Learning di Google Cloud.

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: