Konferensi Habr bukanlah kisah debut. Sebelumnya kami mengadakan acara Toaster yang cukup besar untuk 300-400 orang, namun sekarang kami memutuskan bahwa pertemuan tematik kecil akan relevan, arahnya dapat Anda tentukan, misalnya di kolom komentar. Konferensi pertama dengan format ini diadakan pada bulan Juli dan didedikasikan untuk pengembangan backend. Peserta mendengarkan laporan tentang fitur transisi dari backend ke ML dan tentang desain layanan Quadrupel di portal Layanan Negara, dan juga mengambil bagian dalam meja bundar yang didedikasikan untuk Tanpa Server. Bagi yang tidak bisa menghadiri acara tersebut secara langsung, pada postingan kali ini kami akan memberi tahu Anda hal-hal paling menarik.
Dari pengembangan backend hingga pembelajaran mesin
Apa yang dilakukan data engineer di ML? Apa persamaan dan perbedaan tugas pengembang backend dan teknisi ML? Jalan apa yang perlu Anda ambil untuk mengubah profesi pertama ke profesi kedua? Hal ini diceritakan oleh Alexander Parinov, yang mempelajari pembelajaran mesin setelah 10 tahun bekerja di backend.
Alexander Parinov
Saat ini Alexander bekerja sebagai arsitek sistem visi komputer di X5 Retail Group dan berkontribusi pada proyek Sumber Terbuka yang terkait dengan visi komputer dan pembelajaran mendalam (github.com/creafz). Keahliannya dibuktikan dengan partisipasinya dalam 100 besar peringkat dunia Kaggle Master (kaggle.com/creafz), platform paling populer untuk kompetisi pembelajaran mesin.
Mengapa beralih ke pembelajaran mesin
Satu setengah tahun yang lalu, Jeff Dean, kepala Google Brain, proyek penelitian kecerdasan buatan berbasis pembelajaran mendalam Google, menjelaskan bagaimana setengah juta baris kode di Google Terjemahan digantikan oleh jaringan saraf Tensor Flow yang hanya terdiri dari 500 baris. Setelah pelatihan jaringan, kualitas data meningkat dan infrastruktur menjadi lebih sederhana. Tampaknya inilah masa depan kita yang cerah: kita tidak perlu lagi menulis kode, cukup membuat neuron dan mengisinya dengan data. Namun dalam praktiknya, semuanya jauh lebih rumit.
Infrastruktur ML di Google
Jaringan saraf hanyalah sebagian kecil dari infrastruktur (kotak hitam kecil pada gambar di atas). Lebih banyak sistem tambahan diperlukan untuk menerima data, memprosesnya, menyimpannya, memeriksa kualitas, dll. Kita memerlukan infrastruktur untuk pelatihan, menerapkan kode pembelajaran mesin dalam produksi, dan menguji kode ini. Semua tugas ini persis sama dengan apa yang dilakukan pengembang backend.
Proses pembelajaran mesin
Apa perbedaan antara ML dan backend?
Dalam pemrograman klasik, kita menulis kode dan ini menentukan perilaku program. Di ML, kami memiliki kode model kecil dan banyak data yang kami masukkan ke model tersebut. Data dalam ML sangat penting: model yang sama yang dilatih pada data berbeda dapat menunjukkan hasil yang sangat berbeda. Masalahnya adalah data hampir selalu tersebar dan disimpan dalam sistem yang berbeda (database relasional, database NoSQL, log, file).
Pembuatan versi data
ML memerlukan pembuatan versi tidak hanya kodenya, seperti dalam pengembangan klasik, tetapi juga datanya: penting untuk memahami dengan jelas model apa yang dilatih. Untuk melakukannya, Anda dapat menggunakan pustaka Kontrol Versi Ilmu Data yang populer (dvc.org).
Penandaan data
Tugas selanjutnya adalah pelabelan data. Misalnya, tandai semua objek dalam gambar atau sebutkan kelasnya. Ini dilakukan oleh layanan khusus seperti Yandex.Toloka, yang pekerjaannya sangat disederhanakan dengan kehadiran API. Kesulitan muncul karena βfaktor manusiaβ: Anda dapat meningkatkan kualitas data dan mengurangi kesalahan seminimal mungkin dengan mempercayakan tugas yang sama kepada beberapa pelaku.
Visualisasi di Papan Tensor
Pencatatan log eksperimen diperlukan untuk membandingkan hasil dan memilih model terbaik berdasarkan beberapa metrik. Ada banyak alat untuk visualisasi - misalnya, Tensor Board. Namun tidak ada cara ideal untuk menyimpan eksperimen. Perusahaan kecil sering kali puas dengan spreadsheet Excel, sedangkan perusahaan besar menggunakan platform khusus untuk menyimpan hasil dalam database.
Ada banyak platform untuk pembelajaran mesin, namun tidak satupun yang memenuhi 70% kebutuhan
Masalah pertama yang harus dihadapi saat memasukkan model terlatih ke dalam produksi terkait dengan alat favorit para data scientist - Jupyter Notebook. Tidak ada modularitas di dalamnya, yaitu keluarannya berupa "alas kaki" kode yang tidak dibagi menjadi bagian-bagian logis - modul. Semuanya tercampur: kelas, fungsi, konfigurasi, dll. Kode ini sulit untuk dibuat versi dan diuji.
Bagaimana cara mengatasinya? Anda dapat mengundurkan diri, seperti Netflix, dan membuat platform Anda sendiri yang memungkinkan Anda meluncurkan laptop ini langsung dalam produksi, mentransfer data ke laptop tersebut sebagai masukan, dan mendapatkan hasil. Anda dapat memaksa pengembang yang meluncurkan model ke dalam produksi untuk menulis ulang kode secara normal, memecahnya menjadi modul. Namun dengan pendekatan ini, mudah terjadi kesalahan, dan model tidak akan berfungsi sebagaimana mestinya. Oleh karena itu, opsi ideal adalah melarang penggunaan Jupyter Notebook untuk kode model. Jika, tentu saja, para data scientist menyetujui hal ini.
Modelkan sebagai kotak hitam
Cara termudah untuk memasukkan model ke dalam produksi adalah dengan menggunakannya sebagai kotak hitam. Anda memiliki semacam kelas model, Anda diberi bobot model (parameter neuron jaringan yang dilatih), dan jika Anda menginisialisasi kelas ini (panggil metode prediksi, berikan gambarnya), Anda akan mendapatkan nilai tertentu prediksi sebagai keluaran. Apa yang terjadi di dalam tidak masalah.
Pisahkan proses server dengan model
Anda juga dapat menaikkan proses terpisah tertentu dan mengirimkannya melalui antrian RPC (dengan gambar atau data sumber lainnya. Pada output kami akan menerima prediksi.
Contoh penggunaan model di Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Masalah dengan pendekatan ini adalah keterbatasan kinerja. Katakanlah kita memiliki kode Phyton yang ditulis oleh data scientist yang lambat, dan kita ingin memaksimalkan performa. Untuk melakukan ini, Anda dapat menggunakan alat yang mengubah kode menjadi kode asli atau mengubahnya menjadi kerangka kerja lain yang disesuaikan untuk produksi. Ada alat seperti itu untuk setiap kerangka kerja, namun tidak ada alat yang ideal; Anda harus menambahkannya sendiri.
Infrastruktur di ML sama dengan backend biasa. Ada Docker dan Kubernetes, hanya untuk Docker Anda perlu menginstal runtime dari NVIDIA, yang memungkinkan proses di dalam container mengakses kartu video di host. Kubernetes memerlukan plugin agar dapat mengelola server dengan kartu video.
Berbeda dengan pemrograman klasik, dalam kasus ML, terdapat banyak elemen bergerak berbeda dalam infrastruktur yang perlu diperiksa dan diuji - misalnya, kode pemrosesan data, pipeline pelatihan model, dan produksi (lihat diagram di atas). Penting untuk menguji kode yang menghubungkan berbagai bagian pipeline: ada banyak bagian, dan masalah sering kali muncul pada batasan modul.
Cara kerja AutoML
Layanan AutoML berjanji untuk memilih model optimal untuk tujuan Anda dan melatihnya. Namun perlu Anda pahami: data sangat penting dalam ML, hasilnya tergantung persiapannya. Markup dilakukan oleh orang-orang, yang penuh dengan kesalahan. Tanpa kontrol yang ketat, hasilnya mungkin sampah, dan prosesnya belum bisa diotomatisasi; verifikasi oleh spesialis - data scientist - diperlukan. Di sinilah AutoML rusak. Namun ini bisa berguna untuk memilih arsitektur - ketika Anda sudah menyiapkan data dan ingin menjalankan serangkaian eksperimen untuk menemukan model terbaik.
Cara masuk ke pembelajaran mesin
Cara termudah untuk masuk ke ML adalah jika Anda mengembangkannya dengan Python, yang digunakan di semua kerangka pembelajaran mendalam (dan kerangka kerja reguler). Bahasa ini praktis wajib untuk bidang kegiatan ini. C++ digunakan untuk beberapa tugas computer vision, misalnya, dalam sistem kontrol untuk mobil self-driving. JavaScript dan Shell - untuk visualisasi dan hal-hal aneh seperti menjalankan neuron di browser. Java dan Scala digunakan saat bekerja dengan Big Data dan untuk pembelajaran mesin. R dan Julia disukai oleh orang-orang yang mempelajari statistik matematika.
Cara paling mudah untuk mendapatkan pengalaman praktis adalah di Kaggle; partisipasi dalam salah satu kompetisi platform memberikan lebih dari satu tahun pembelajaran teori. Di platform ini Anda dapat mengambil kode yang diposting dan dikomentari orang lain dan mencoba memperbaikinya, mengoptimalkannya untuk tujuan Anda. Bonus - peringkat Kaggle Anda memengaruhi gaji Anda.
Pilihan lainnya adalah bergabung dengan tim ML sebagai backend developer. Ada banyak startup pembelajaran mesin di mana Anda bisa mendapatkan pengalaman dengan membantu kolega Anda memecahkan masalah mereka. Terakhir, Anda dapat bergabung dengan salah satu komunitas data scientist β Open Data Science (ods.ai) dan lainnya.
Pembicara memposting informasi tambahan tentang topik tersebut di tautan
"Quadrupel" - layanan pemberitahuan yang ditargetkan dari portal "Layanan Negara"
Evgeny Smirnov
Pembicara selanjutnya adalah Kepala Departemen Pengembangan Infrastruktur E-Government, Evgeny Smirnov, yang berbicara tentang Quadruple. Ini adalah layanan pemberitahuan yang ditargetkan untuk portal Gosuslugi (gosuslugi.ru), sumber daya pemerintah yang paling banyak dikunjungi di Runet. Pemirsa hariannya adalah 2,6 juta, total ada 90 juta pengguna terdaftar di situs ini, 60 juta di antaranya telah dikonfirmasi. Beban pada portal API adalah 30 ribu RPS.
Teknologi yang digunakan di backend Layanan Negara
"Quadrupel" adalah layanan notifikasi bertarget, yang dengannya pengguna menerima tawaran layanan pada saat yang paling tepat baginya dengan menyiapkan aturan notifikasi khusus. Persyaratan utama saat mengembangkan layanan ini adalah pengaturan yang fleksibel dan waktu pengiriman surat yang memadai.
Bagaimana cara kerja Quadrupel?
Diagram di atas menunjukkan salah satu aturan pengoperasian Quadrupel dengan menggunakan contoh situasi perlunya penggantian SIM. Pertama, layanan mencari pengguna yang tanggal kedaluwarsanya akan berakhir dalam satu bulan. Mereka diperlihatkan spanduk dengan tawaran untuk menerima layanan yang sesuai dan pesan dikirim melalui email. Bagi pengguna yang tenggat waktunya telah habis, banner dan emailnya berubah. Setelah pertukaran hak berhasil, pengguna menerima pemberitahuan lain - dengan proposal untuk memperbarui data identitas.
Dari sudut pandang teknis, ini adalah skrip asyik tempat kode ditulis. Inputnya berupa data, outputnya benar/salah, cocok/tidak cocok. Total ada lebih dari 50 aturan - mulai dari menentukan ulang tahun pengguna (tanggal saat ini sama dengan tanggal lahir pengguna) hingga situasi rumit. Setiap hari, peraturan ini mengidentifikasi sekitar satu juta pertandinganβorang-orang yang perlu diberi tahu.
Saluran notifikasi quadrupel
Di bawah tenda Quadrupel terdapat database yang menyimpan data pengguna dan tiga aplikasi:
- Pekerja dimaksudkan untuk memperbarui data.
- API sisanya mengambil dan mengirimkan spanduk itu sendiri ke portal dan aplikasi seluler.
- Penjadwal meluncurkan pekerjaan menghitung ulang spanduk atau surat massal.
Untuk memperbarui data, backend digerakkan oleh peristiwa. Dua antarmuka - istirahat atau JMS. Ada banyak acara, sebelum disimpan dan diproses, acara tersebut dikumpulkan agar tidak membuat permintaan yang tidak perlu. Basis data itu sendiri, tabel tempat data disimpan, tampak seperti penyimpanan nilai kunci - kunci pengguna dan nilai itu sendiri: tanda yang menunjukkan ada atau tidaknya dokumen yang relevan, masa berlakunya, statistik agregat tentang urutan layanan berdasarkan pengguna ini, dan seterusnya.
Setelah menyimpan data, tugas diatur di JMS agar spanduk segera dihitung ulang - ini harus segera ditampilkan di web. Sistem dimulai pada malam hari: tugas dilemparkan ke JMS pada interval pengguna, yang menurutnya aturan perlu dihitung ulang. Ini diambil oleh prosesor yang terlibat dalam perhitungan ulang. Selanjutnya, hasil pemrosesan masuk ke antrian berikutnya, yang menyimpan spanduk di database atau mengirimkan tugas pemberitahuan pengguna ke layanan. Prosesnya memakan waktu 5-7 jam dan mudah diskalakan karena Anda selalu dapat menambahkan penangan atau meningkatkan instance dengan penangan baru.
Layanan ini bekerja dengan cukup baik. Namun volume data bertambah seiring bertambahnya pengguna. Hal ini menyebabkan peningkatan beban pada database - bahkan dengan mempertimbangkan fakta bahwa Rest API melihat replika. Poin kedua adalah JMS, yang ternyata kurang cocok karena konsumsi memorinya yang tinggi. Ada risiko tinggi antrian meluap yang menyebabkan JMS mogok dan pemrosesan terhenti. Tidak mungkin untuk menaikkan JMS setelah ini tanpa menghapus log.
Direncanakan untuk menyelesaikan masalah menggunakan sharding, yang akan memungkinkan penyeimbangan beban pada database. Ada juga rencana untuk mengubah skema penyimpanan data, dan mengubah JMS ke Kafka - solusi yang lebih toleran terhadap kesalahan yang akan menyelesaikan masalah memori.
Backend sebagai Layanan Vs. Tanpa server
Dari kiri ke kanan: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Backend sebagai layanan atau solusi Tanpa Server? Peserta diskusi masalah mendesak ini di meja bundar adalah:
- Ara Israelyan, CTO CTO dan pendiri Scorocode.
- Nikolay Markov, Insinyur Data Senior di Aligned Research Group.
- Andrey Tomilenko, kepala departemen pengembangan RUVDS.
Percakapan tersebut dimoderatori oleh pengembang senior Alexander Borgart. Kami menyajikan perdebatan di mana para pendengar juga berpartisipasi dalam versi singkat.
β Apa yang dimaksud dengan Tanpa Server menurut pemahaman Anda?
Andrew: Ini adalah model komputasi - fungsi Lambda yang harus memproses data agar hasilnya hanya bergantung pada data. Istilah ini berasal dari Google atau dari Amazon dan layanan AWS Lambda-nya. Lebih mudah bagi penyedia untuk menangani fungsi seperti itu dengan mengalokasikan sejumlah kapasitas untuk itu. Pengguna yang berbeda dapat dicatat secara independen di server yang sama.
Nicholas: Sederhananya, kami mentransfer sebagian infrastruktur TI dan logika bisnis kami ke cloud, ke outsourcing.
Ara: Di pihak pengembang - upaya yang baik untuk menghemat sumber daya, di pihak pemasar - untuk menghasilkan lebih banyak uang.
β Apakah Tanpa Server sama dengan layanan mikro?
Nicholas: Tidak, Tanpa Server lebih merupakan organisasi arsitektur. Layanan mikro adalah unit atom dari beberapa logika. Tanpa server adalah sebuah pendekatan, bukan βentitas terpisah.β
Ara: Fungsi Tanpa Server dapat dikemas ke dalam layanan mikro, namun fungsi ini tidak lagi menjadi Tanpa Server, melainkan tidak lagi menjadi fungsi Lambda. Di Tanpa Server, suatu fungsi hanya mulai berfungsi saat diminta.
Andrew: Mereka berbeda dalam masa hidupnya. Kami meluncurkan fungsi Lambda dan melupakannya. Ini berfungsi selama beberapa detik, dan klien berikutnya dapat memproses permintaannya di mesin fisik lain.
β Skala mana yang lebih baik?
Ara: Saat melakukan penskalaan secara horizontal, fungsi Lambda berperilaku sama persis dengan layanan mikro.
Nicholas: Berapa pun jumlah replika yang Anda tetapkan, jumlahnya akan sama; Tanpa server tidak ada masalah dengan penskalaan. Saya membuat set replika di Kubernetes, meluncurkan 20 instance βdi suatu tempatβ, dan 20 tautan anonim dikembalikan kepada Anda. Maju!
β Apakah mungkin untuk menulis backend di Tanpa Server?
Andrew: Secara teoritis, tapi tidak masuk akal. Fungsi Lambda akan bergantung pada satu repositori - kita perlu memastikan jaminan. Misalnya, jika pengguna telah melakukan transaksi tertentu, maka pada saat dia menghubungi dia akan melihat: transaksi telah dilakukan, dana telah dikreditkan. Semua fungsi Lambda akan diblokir pada panggilan ini. Faktanya, sekumpulan fungsi Tanpa Server akan berubah menjadi satu layanan dengan satu titik akses hambatan ke database.
β Dalam situasi apa masuk akal untuk menggunakan arsitektur tanpa server?
Andrew: Tugas yang tidak memerlukan penyimpanan bersama - penambangan yang sama, blockchain. Dimana Anda perlu melakukan banyak penghitungan. Jika Anda memiliki banyak daya komputasi, maka Anda dapat mendefinisikan fungsi seperti "hitung hash sesuatu di sana..." Namun Anda dapat menyelesaikan masalah penyimpanan data dengan mengambil, misalnya, fungsi Lambda dari Amazon dan penyimpanan terdistribusinya . Dan ternyata Anda sedang menulis layanan reguler. Fungsi Lambda akan mengakses penyimpanan dan memberikan semacam respons kepada pengguna.
Nicholas: Kontainer yang berjalan di Tanpa Server memiliki sumber daya yang sangat terbatas. Ada sedikit memori dan yang lainnya. Namun jika seluruh infrastruktur Anda dikerahkan seluruhnya di cloud tertentu - Google, Amazon - dan Anda memiliki kontrak permanen dengan mereka, ada anggaran untuk semua ini, maka untuk beberapa tugas Anda dapat menggunakan wadah Tanpa Server. Infrastruktur ini perlu berada di dalam, karena semuanya disesuaikan untuk digunakan dalam lingkungan tertentu. Artinya, jika Anda siap untuk menghubungkan semuanya ke infrastruktur cloud, Anda dapat bereksperimen. Keuntungannya adalah Anda tidak perlu mengelola infrastruktur ini.
Ara: Fakta bahwa Tanpa Server tidak mengharuskan Anda mengelola Kubernetes, Docker, menginstal Kafka, dan sebagainya adalah penipuan diri sendiri. Amazon dan Google yang sama sedang menginstal ini. Hal lainnya adalah Anda memiliki SLA. Anda sebaiknya melakukan outsourcing semuanya daripada mengkodekannya sendiri.
Andrew: Tanpa server sendiri tidak mahal, tetapi Anda harus membayar mahal untuk layanan Amazon lainnya - misalnya database. Orang-orang telah menggugat mereka karena mereka mengenakan biaya yang sangat besar untuk gerbang API.
Ara: Jika kita berbicara tentang uang, maka Anda perlu mempertimbangkan hal ini: Anda harus mengubah seluruh metodologi pengembangan di perusahaan 180 derajat untuk mentransfer semua kode ke Tanpa Server. Ini akan memakan banyak waktu dan uang.
β Apakah ada alternatif yang layak selain Tanpa Server berbayar dari Amazon dan Google?
Nicholas: Di Kubernetes, Anda meluncurkan suatu jenis pekerjaan, pekerjaan itu berjalan dan mati - ini cukup Tanpa Server dari sudut pandang arsitektur. Jika Anda ingin membuat logika bisnis yang sangat menarik dengan antrian dan database, Anda perlu memikirkannya lebih jauh. Ini semua dapat diselesaikan tanpa meninggalkan Kubernetes. Saya tidak akan repot-repot menunda implementasi tambahan.
β Seberapa pentingkah memantau apa yang terjadi di Tanpa Server?
Ara: Tergantung pada arsitektur sistem dan kebutuhan bisnis. Intinya, penyedia harus memberikan pelaporan yang akan membantu tim pengembang memahami kemungkinan masalah.
Nicholas: Amazon memiliki CloudWatch, tempat semua log dialirkan, termasuk log dari Lambda. Integrasikan penerusan log dan gunakan alat terpisah untuk melihat, memperingatkan, dan sebagainya. Anda dapat memasukkan agen ke dalam wadah yang Anda mulai.
- Mari kita simpulkan.
Andrew: Memikirkan tentang fungsi Lambda berguna. Jika Anda membuat layanan sendiri - bukan layanan mikro, tetapi layanan yang menulis permintaan, mengakses database, dan mengirimkan respons - fungsi Lambda memecahkan sejumlah masalah: dengan multithreading, skalabilitas, dan sebagainya. Jika logika Anda dibangun dengan cara ini, maka di masa depan Anda akan dapat mentransfer Lambda ini ke layanan mikro atau menggunakan layanan pihak ketiga seperti Amazon. Teknologinya bermanfaat, idenya menarik. Seberapa dibenarkan hal ini bagi bisnis masih menjadi pertanyaan terbuka.
Nikolay: Tanpa server lebih baik digunakan untuk tugas operasi daripada menghitung beberapa logika bisnis. Saya selalu menganggapnya sebagai pemrosesan acara. Jika Anda memilikinya di Amazon, jika Anda berada di Kubernetes, ya. Jika tidak, Anda harus melakukan banyak upaya untuk mengaktifkan dan menjalankan Tanpa Server sendiri. Penting untuk melihat kasus bisnis tertentu. Misalnya, salah satu tugas saya sekarang adalah: ketika file muncul di disk dalam format tertentu, saya perlu mengunggahnya ke Kafka. Saya bisa menggunakan WatchDog atau Lambda. Dari sudut pandang logis, kedua opsi tersebut cocok, tetapi dalam hal implementasi, Tanpa Server lebih rumit, dan saya lebih suka cara yang lebih sederhana, tanpa Lambda.
Ara: Tanpa server adalah ide yang menarik, dapat diterapkan, dan secara teknis sangat bagus. Cepat atau lambat, teknologi akan mencapai titik di mana fungsi apa pun akan diluncurkan dalam waktu kurang dari 100 milidetik. Maka, pada prinsipnya, tidak akan ada pertanyaan apakah waktu tunggu itu penting bagi pengguna. Pada saat yang sama, penerapan Tanpa Server, seperti yang telah dikatakan rekan-rekan, sepenuhnya bergantung pada masalah bisnis.
Kami berterima kasih kepada sponsor kami yang banyak membantu kami:
- Ruang konferensi TI «» untuk lokasi konferensi.
- Kalender acara TI dan publikasi"Β» untuk dukungan informasi dan berita.
- Β«"untuk hadiah.
- untuk kreasi bersama.
- "Asosiasi Komunikasi Elektronik" untuk keterlibatan dan pengalaman.
- Sponsor utama - untuk semua!
Sumber: www.habr.com