Pendekatan tanpa server untuk pengembangan cepat layanan video yang berfungsi

Saya bekerja dalam outsourcing, di mana prinsip utama dapat dijelaskan dengan kalimat "menjual banyak, lakukan dengan cepat." Semakin cepat kita lakukan, semakin banyak yang kita hasilkan. Dan, sangat diharapkan bahwa semuanya tidak bekerja pada kruk dan ingus, tetapi dengan tingkat kualitas yang dapat diterima. Saya akan menceritakan tentang pengalaman saya ketika dalam waktu singkat perlu untuk mengembangkan layanan promosi.

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

Tujuan: mengimplementasikan layanan promosi tempat pengguna mengunggah dari satu hingga empat video yang berlangsung dari satu hingga empat detik, yang kemudian disematkan dalam urutan video asli. Artinya, kami mengganti fragmen dari video asli (screensaver seri) dengan yang khusus. Fitur pembunuh - kemampuan untuk mengirim nama Anda, yang dalam bentuk teks yang indah menutupi fragmen video yang sesuai. Selain itu, pengguna dapat mengunggah video dari 4 hingga 30 detik, dan di sisi layanan akan dipangkas menjadi 4 detik.

Solusi

Menulis layanan sepeda Anda dalam kerangka waktu yang ketat adalah sebuah ide. Selain itu, agar layanan dapat mengatasi beban dan semua orang yang ingin menerima video yang didambakan, infrastruktur akan diperlukan. Dan lebih disukai tidak dengan label harga dari pesawat. Karena itu, kami segera fokus pada solusi yang sudah jadi dengan kustomisasi minimal.

Solusi standar untuk bekerja dengan video adalah FFmpeg, utilitas konsol lintas-platform yang, melalui argumen, memungkinkan Anda untuk mengiris dan melapisi suara. Hal kecil adalah menulis pembungkus dan mempraktikkannya. Kami sedang menulis prototipe yang menyatukan dua video, dan ... kesenangan dimulai. Pustaka pada .NET Core 2 harus berputar pada mesin virtual apa pun, jadi kami mengambil contoh AWS EC2 dan semuanya akan berfungsi


FFmpeg, meskipun menyederhanakan tugas, tetapi untuk solusi yang benar-benar berfungsi Anda perlu membuat instance EC2, merancang infrastruktur jaringan untuk itu, termasuk Load Balancer. Tugas sederhana penggelaran dari awal “sedikit” rumit, dan infrastruktur mulai menuntut uang segera - jumlah runtime ditarik dari akun klien setiap jam.

Layanan kami tidak melibatkan proses Long-Running, tidak memerlukan database relasional yang besar dan berani, dan sangat cocok dengan arsitektur acara dengan rantai panggilan layanan-mikro. Solusinya menunjukkan sendiri - kita dapat mengabaikan EC2 dan mengimplementasikan aplikasi benar-serverless, seperti Image Resizer standar berdasarkan AWS Lambda.

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

Dan ceri pada kue - AWS menyediakan layanan terpisah untuk bekerja dengan file video - AWS Elemental MediaConvert.

Inti dari pekerjaan ini sangat sederhana: kami mengambil tautan S3 ke video keluar, melalui AWS Console, .NET SDK, atau hanya JSON yang menulis apa yang ingin kami lakukan dengan video dan menghubungi layanan. Dia sendiri mengimplementasikan antrian untuk memproses permintaan yang masuk, dia membongkar hasilnya dalam S3 dan, yang paling penting, menghasilkan Acara CloudWatch untuk setiap perubahan status. Ini memungkinkan kami untuk mengimplementasikan pemicu lambda untuk menyelesaikan pemrosesan video.


Versi final dari arsitektur terlihat seperti ini

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

Hamparan teks dilakukan dengan menampilkan gambar transparan dengan cepat sesuai dengan resolusi video. Pustaka SixLabors.ImageSharp sangat cocok untuk tujuan ini, dan masalah kebocoran memori secara elegan memotong siklus hidup lambda.

Bagian depan dalam bentuk aplikasi SPA yang ditulis dalam JS dan dikompilasi melalui pesek akan ditempatkan di keranjang S3 publik. Untuk mengunduh video sendiri, kami tidak memerlukan kode server apa pun - cukup buka titik akhir REST yang ditawarkan S3 kepada kami. Satu-satunya hal - jangan lupa untuk mengkonfigurasi kebijakan dan CORS.

Perangkap

• AWS MediaConvert karena alasan yang tidak diketahui memaksakan suara hanya pada setiap klip video secara terpisah, dan kami membutuhkan lagu yang kuat dari seluruh screensaver.
• video vertikal perlu diproses secara terpisah. AWS tidak suka garis-garis hitam dan menempatkan rol pada 90 °.

Gelanggang mudah

Terlepas dari keindahan Stateless, Anda perlu melacak apa yang perlu dilakukan dengan video: lem atau suara overlay pada urutan video yang sudah selesai. Untungnya, MediaConvert mendukung transfer metadata melalui Ayubnya, dan kami selalu dapat menerapkan flag sederhana seperti "isMasterSoundJob", menguraikan metadata ini di setiap tahap.

Tanpa server membuat NoOps berfungsi dengan baik - suatu pendekatan yang mengasumsikan perlunya tim terpisah yang bertanggung jawab atas infrastruktur proyek. Oleh karena itu, itu adalah masalah kecil - kami menyebarkan solusi pada AWS tanpa partisipasi administrator sistem, yang selalu memiliki sesuatu untuk dilakukan.
Dan untuk mempercepat semuanya, kami mengotomatiskan skrip penerapan ke AWS CloudFormation sebanyak mungkin, memungkinkan Anda untuk menggunakan satu tombol langsung dari VS. Akibatnya, file dengan 200 baris kode memungkinkan Anda untuk meluncurkan solusi yang sudah jadi, meskipun sintaks CloudFormation dapat mengejutkan karena kebiasaan.

Total

Serverless bukan obat mujarab. Tetapi itu akan sangat memudahkan kehidupan dalam situasi dengan tiga batasan: "sumber daya terbatas - waktu singkat - sedikit uang."

Karakteristik aplikasi yang cocok untuk Serverless

• tanpa proses yang berjalan lama. API batas keras Gateway - 29 detik, batas keras lambda - 15 menit;
• dijelaskan oleh arsitektur Event-Driven;
• dipecah menjadi komponen yang digabungkan secara longgar berdasarkan jenis SOA;
• tidak memerlukan banyak pekerjaan dengan kondisinya;
• ditulis dalam .NET Core. Untuk bekerja dengan .NET Framework, Anda masih membutuhkan setidaknya Docker dengan runtime yang sesuai.

Manfaat dari Pendekatan Tanpa Server

• mengurangi biaya infrastruktur;
• mengurangi biaya pengiriman solusi;
• Skalabilitas otomatis
• pengembangan di garis depan kemajuan teknologi.

Kerugian, pada contoh nyata

• Pelacakan dan pendataan terdistribusi - sebagian diselesaikan melalui AWS X-Ray dan AWS CloudWatch;
• debugging tidak nyaman;
• Mulai Dingin tanpa adanya beban;
• Antarmuka pengguna-permusuhan AWS adalah masalah universal :)