Pendekatan tanpa server untuk pengembangan cepat layanan video yang berfungsi

Pendekatan tanpa server untuk pengembangan cepat layanan video yang berfungsi

Saya bekerja di bidang outsourcing, prinsip utamanya dapat digambarkan dengan kalimat “jual banyak, lakukan cepat”. Semakin cepat kita melakukannya, semakin banyak penghasilan yang kita peroleh. Dan diharapkan semuanya berfungsi bukan dengan kruk dan ingus, tetapi dengan tingkat kualitas yang dapat diterima. Saya akan bercerita tentang pengalaman saya ketika perlu mengembangkan layanan promosi dalam waktu singkat.

Diberikan: akun root di AWS, tidak ada batasan pada pilihan tumpukan teknologi, satu backend, dan satu bulan untuk pengembangan.

Tugas: menerapkan layanan promosi di mana pengguna mengunggah satu hingga empat video berdurasi satu hingga empat detik, yang kemudian disematkan dalam serial video aslinya.

keputusan

Menulis servis sepeda Anda sendiri dalam waktu sesingkat itu bukanlah ide yang baik. Selain itu, agar layanan dapat mengatasi beban dan agar semua orang dapat menerima video yang didambakan, diperlukan infrastruktur. Dan sebaiknya tidak dengan banderol harga dari pesawat. Oleh karena itu, kami segera fokus pada solusi siap pakai dengan penyesuaian minimal.

Solusi standar untuk bekerja dengan video adalah FFmpeg, utilitas konsol lintas platform yang, melalui argumen, memungkinkan Anda memotong dan melakukan overdub audio. Yang perlu dilakukan hanyalah menulis bungkusnya dan menghidupkannya. Kami menulis prototipe yang menggabungkan dua video, dan... kesenangan pun dimulai. Pustaka ini didasarkan pada .NET Core 2, itu harus berjalan di mesin virtual apa pun, jadi kami mengambil instans AWS EC2 dan semuanya akan berfungsi

Teks tersembunyitidak, itu tidak akan berhasil
.
Meskipun FFmpeg menyederhanakan tugas, agar solusi benar-benar berfungsi, Anda perlu membuat instans EC2 dan merancang infrastruktur jaringan untuk instans tersebut, termasuk Load Balancer. Tugas sederhana untuk menerapkan dari awal menjadi “sedikit” lebih rumit, dan infrastruktur mulai meminta uang dengan segera - setiap jam jumlah runtime ditarik dari akun klien.

Layanan kami tidak melibatkan proses yang Berjalan Lama, tidak memerlukan database relasional yang besar dan besar, dan sangat cocok dengan arsitektur berbasis peristiwa dengan rangkaian panggilan layanan mikro. Solusinya muncul dengan sendirinya - kita dapat meninggalkan EC2 dan menerapkan aplikasi tanpa server yang sebenarnya, seperti Image Resizer standar berdasarkan AWS Lambda.

Omong-omong, meskipun pengembang AWS jelas tidak menyukai .NET, mereka mendukung .NET Core 2.1 sebagai runtime, yang memberikan berbagai peluang pengembangan.

Dan yang menarik - AWS menyediakan layanan terpisah untuk bekerja dengan file video - AWS Elemental MediaConvert.

Inti dari pekerjaannya sangat sederhana: kami mengambil tautan S3 ke video keluar, menulis melalui Konsol AWS, .NET SDK, atau sekadar JSON apa yang ingin kami lakukan dengan video tersebut dan memanggil layanan. Itu sendiri mengimplementasikan antrian untuk memproses permintaan masuk, mengunggah hasilnya ke S3 itu sendiri dan, yang paling penting, menghasilkan CloudWatch Event untuk setiap perubahan status. Hal ini memungkinkan kami menerapkan pemicu lambda untuk menyelesaikan pemrosesan video.

Pendekatan tanpa server untuk pengembangan cepat layanan video yang berfungsi
Seperti inilah arsitektur akhirnya:

Seluruh backend ditempatkan di dua lambda. Cara lainnya adalah untuk memutar video vertikal, karena pekerjaan seperti itu tidak dapat dilakukan dalam sekali jalan.

Kami akan menempatkan bagian depan dalam bentuk aplikasi SPA yang ditulis dalam JS dan dikompilasi melalui pug di bucket S3 publik. Untuk mengunduh videonya sendiri, kita tidak memerlukan kode server apa pun - kita hanya perlu membuka titik akhir REST yang disediakan S3. Satu-satunya hal adalah jangan lupa untuk mengkonfigurasi kebijakan dan CORS.

Jebakan

  • AWS MediaConvert, untuk beberapa alasan yang tidak diketahui, hanya menerapkan suara ke setiap fragmen video secara terpisah, namun kami memerlukan lagu ceria dari keseluruhan screensaver.
  • Video vertikal perlu diproses secara terpisah. AWS tidak menyukai bilah hitam dan menempatkan roller pada 90°.

Arena seluncur es yang mudah

Terlepas dari semua keindahan Stateless, Anda perlu melacak apa yang perlu dilakukan dengan video tersebut: merekatkan atau menambahkan audio ke urutan video yang sudah selesai. Untungnya, MediaConvert mendukung penerusan metadata melalui Pekerjaannya, dan kita selalu dapat menggunakan tanda sederhana dalam bentuk "isMasterSoundJob", yang menguraikan metadata ini pada tahap apa pun.

Tanpa server dengan sempurna memungkinkan bekerja dengan NoOps - sebuah pendekatan yang mengasumsikan tidak diperlukannya tim terpisah yang bertanggung jawab atas infrastruktur proyek. Oleh karena itu, ini hanyalah masalah kecil - kami menerapkan solusi di AWS tanpa partisipasi administrator sistem, yang selalu memiliki sesuatu untuk dilakukan.
Dan untuk mempercepat semua ini, kami mengotomatiskan skrip penerapan sebanyak mungkin di AWS CloudFormation, yang memungkinkan Anda menerapkan dengan satu tombol langsung dari VS. Hasilnya, file yang terdiri dari 200 baris kode memungkinkan Anda meluncurkan solusi yang sudah jadi, meskipun sintaks CloudFormation bisa mengejutkan jika Anda tidak terbiasa dengannya.

Total

Tanpa server bukanlah obat mujarab. Namun hal ini akan membuat hidup lebih mudah dalam situasi dengan tiga batasan: “sumber daya yang terbatas—jangka pendek—uang yang sedikit.”

Karakteristik Aplikasi yang Cocok untuk Serverless

  • tanpa proses yang Berjalan Lama. Batas keras API Gateway adalah 29 detik, batas keras lambda adalah 5 menit;
  • dijelaskan oleh arsitektur Berbasis Peristiwa;
  • terurai menjadi komponen-komponen yang digabungkan secara longgar seperti SOA;
  • tidak memerlukan banyak pekerjaan dengan kondisi Anda;
  • ditulis dalam .NET Core. Untuk bekerja dengan .NET Framework, Anda masih memerlukan setidaknya Docker dengan runtime yang sesuai.

Manfaat pendekatan Tanpa Server

  • mengurangi biaya infrastruktur;
  • mengurangi biaya penyampaian solusi;
  • skalabilitas otomatis;
  • perkembangan yang terdepan dalam kemajuan teknologi.

Kekurangan, dengan contoh spesifik

  • Pelacakan dan pencatatan terdistribusi - sebagian diselesaikan melalui AWS X-Ray dan AWS CloudWatch;
  • proses debug yang tidak nyaman;
  • Mulai Dingin ketika tidak ada beban;
  • Antarmuka yang bermusuhan dengan pengguna AWS adalah masalah universal :)

Sumber: www.habr.com

Tambah komentar