Appodeal adalah perusahaan yang terdiri dari ~ 100 orang yang bekerja di Moskow, San Francisco, Barnaul, Lutsk, Kirov, Barcelona, dan sejak Juni 2018, juga di Minsk.
Kami memonetisasi aplikasi seluler dengan menampilkan iklan kepada pengguna. Kami mulai dengan mediasi periklanan, tetapi tumpukan teknologi terus berkembang, sehingga produk lain dari industri Teknologi Iklan juga telah ditambahkan ke mediasi.
Bagi mereka yang tidak terbiasa dengan Ad Tech, ini adalah bidang pekerjaan perusahaan teknologi yang bekerja di bidang periklanan. Ketika Anda memberi tahu seseorang bahwa Anda bekerja di bidang periklanan mobile, orang sering bereaksi dengan skeptis - tampaknya, iklan “Azino Three Axes” yang menjengkelkan muncul di benak Anda. Sebenarnya, ini hanyalah puncak gunung es, dan semua iklan "liar" ini tidak ada hubungannya dengan bisnis periklanan yang sebenarnya.
Dan segmen seluler yang kami tangani telah lama melampaui segmen iklan di web:
Mengapa mengintegrasikan iklan dalam aplikasi?
Tentu saja, banyak sumber daya dihabiskan untuk membuat aplikasi - dan pencipta / pemilik ingin waktu dan upaya yang dihabiskan untuk melunasi. Pemilik aplikasi seluler yang memposting aplikasi mereka di App store / Google Play disebut penerbit atau penerbit. Penerbit menerapkan model monetisasi yang berbeda, dari pembelian dalam aplikasi hingga monetisasi iklan. Namun dari semua metode ini, hanya yang terakhir yang memungkinkan pengguna untuk tidak membayar untuk menggunakan aplikasi - dan ini memberikan cakupan pemirsa terbesar.
Ya, jika ada terlalu banyak iklan, itu akan mengganggu semua orang dan berdampak buruk pada retensi pengguna. Yang tentu saja tidak ada yang membutuhkan. Oleh karena itu, mereka selalu berusaha mengintegrasikan iklan dengan bijak untuk mendapatkan uang maksimum pada aplikasi mereka dan pada saat yang sama tidak mengambil sepeser pun dari pengguna.
Bagaimana cara kerjanya?
Segera setelah penerbit memutuskan untuk menghasilkan uang melalui iklan, ia datang ke perusahaan yang dapat membuat tugas ini semudah mungkin baginya. Bagaimana ini terjadi dengan Appodeal? Setelah mendaftar di situs, kami mengintegrasikan aplikasinya dengan layanan kami. Ini dilakukan melalui SDK klien, yang menghubungkan aplikasi ke bagian server dan berkomunikasi dengan bagian server melalui API.
Jika Anda meminimalkan detail, maka tujuan interaksi dikurangi menjadi dua tahap:
a. Tentukan iklan mana yang akan ditampilkan sekarang;
b. Kirim informasi tentang iklan mana yang ditampilkan dan mana yang tidak, dan tampilkan dalam statistik.
Saat ini, Appodeal melayani beberapa ribu aplikasi aktif yang menyediakan sekitar 400-450 juta tayangan iklan per hari, yang diterima sebagai tanggapan terhadap sekitar 1 miliar permintaan ke jaringan iklan (yang merupakan penyedia iklan). Untuk membuat ini berfungsi, server kami melayani sekitar 125 ribu permintaan per detik, mis. sekitar 10,8 miliar permintaan per hari.
Apa yang dibangun di atas ini?
Kami menggunakan berbagai teknologi untuk memberikan kecepatan, keandalan, dan pada saat yang sama fleksibilitas pengembangan dan dukungan. Saat ini, kami sedang menulis kode dalam bahasa berikut:
- / Ruby / Ruby on Rails + React.JS (front-end) /: Masih ada sebagian besar API dan seluruh komponen web yang dilihat pengguna dan karyawan kami
- / GoLang /: Memproses data statistik dalam jumlah besar dan tidak hanya
- / Scala /: Permintaan pemrosesan waktu nyata untuk bekerja dengan pertukaran pertukaran lalu lintas menggunakan protokol RTB (baca lebih lanjut tentang hal itu di akhir artikel)
- / Elixir / Phoenix /: Sebaliknya, bagian eksperimental. Membangun beberapa layanan mikro untuk menangani beberapa statistik dan API.
Mengapa awalnya Ruby dan Ruby on Rails?
Appodeal bersaing di segmennya dengan pemain yang sangat besar, jadi Anda harus beradaptasi dengan cepat terhadap perubahan pasar. Seringkali ini terasa seperti perubahan pada roda mobil pada kecepatan 100 km / jam. Ruby on Rails memungkinkan kami untuk bertahan dalam perlombaan dan mendapatkan pijakan di pasar cukup untuk menjadi pemimpin di segmennya. Keuntungan utama Rails menurut kami:
- Sejumlah besar pengembang yang memenuhi syarat
- Komunitas besar Sejumlah besar solusi dan perpustakaan siap pakai
- Kecepatan memperkenalkan fitur baru dan mengubah / menghapus yang lama
Dari minus yang jelas:
- Performa secara keseluruhan buruk. Ini juga mempengaruhi kurangnya JIT (saat ini), kurangnya kemampuan untuk memparalelkan kode (jika Anda tidak memperhitungkan JRuby). Sampai batas tertentu, ini tetap bisa ditanggung karena bottleneck biasanya database dan cache. Apa yang kita lihat dalam gambar dari NewRelic:
- Rail monolith tidak terpotong dengan baik pada layanan microser - mereka dipengaruhi oleh konektivitas tingkat tinggi antara logika bisnis dan logika akses data (ActiveRecord).
Bagaimana data disimpan?
Kami memiliki banyak data. Sangat Kita berbicara tentang miliaran / puluhan / ratusan miliar catatan. Karena datanya sangat berbeda, kami menyimpannya dengan cara yang berbeda. Seharusnya tidak dibatasi dalam arsitektur untuk satu solusi, yang seharusnya universal. Praktek menunjukkan bahwa, pertama, di Highload praktis tidak ada solusi universal. Universalitas berarti indikator rata-rata (atau jauh lebih rendah dari rata-rata) untuk akses / kecepatan baca / ukuran penyimpanan data sebagai biaya untuk keserbagunaan ini. Kedua, Anda perlu mencoba sesuatu yang baru setiap saat, bereksperimen dan mencari solusi yang tidak sepele untuk tugas-tugas tersebut. Total:
- / PostgreSQL /: Kami menyukai Postgre. Kami menganggapnya sebagai solusi penyimpanan OLTP terbaik saat ini. Data tentang pengguna, aplikasi, kampanye iklan, dan sebagainya disimpan di sana. Kami menggunakan replikasi Primer-Replika. Kami melakukan backup hanya pada liburan Natal, karena ini untuk para pengecut (lelucon).
- / VerticaDB /: Database berorientasi kolom. Kami menggunakan untuk menyimpan miliaran catatan statistik. Singkatnya, Vertika selama beberapa waktu dianggap sebagai solusi OLAP terbaik untuk menyimpan analitik. Kerugian utama adalah harga (individu) yang besar untuk lisensi.
- / ClickHouse /: Juga basis data berorientasi kolom. Beralih secara bertahap dengan VerticaDB. Kami menganggap solusi OLAP terbaik saat ini. Tidak bernilai sepeser pun. Ini bekerja sangat cepat dan andal. Perkecil utama adalah bahwa data tidak dapat dihapus dan diperbarui (kami akan membicarakan ini di artikel terpisah, jika ada yang tertarik).
Tidak ada! Bagaimana tidak mungkin menghapus dan memodifikasi data ?!
- / Aerospike /: Penyimpanan nilai kunci NoSQL tercepat menurut kami. Ada beberapa kekurangan, tetapi secara umum kami puas. Bahkan ada grafik perbandingan untuk Aerospike di situs kinerja mereka dengan solusi lain: [Kapan menggunakan basis data Aerospike NoSQL vs. Redis] (https://www.aerospike.com/when-to-use-aerospike-vs-redis/)
- / Redis /: Tentang "Lobak", saya pikir, tidak masuk akal untuk mengatakannya secara terpisah. Secara paradoks, keunggulan utamanya adalah kemudahan penggunaan dan threading tunggal, yang menghindari kondisi balapan, misalnya, ketika bekerja dengan penghitung biasa.
- / Druid /: Kami menggunakan set data besar yang bekerja dengan pertukaran RTB. Faktanya, sebagian besar, ia bermain di bidang yang sama dengan ClickHouse, tetapi secara historis, kami belum dapat beralih ke satu instrumen apa pun.
Perangkat seperti itu mungkin tampak kelebihan beban, tetapi pertama-tama, Appodeal adalah konglomerat besar dari beberapa tim pengembangan dan beberapa proyek dalam satu. Dan kedua, ini adalah realitas keras dari teknologi iklan - kami bukan satu-satunya yang menggunakan tumpukan bertingkat di dalam satu perusahaan.
Bagaimana Anda mengikuti ini?
Karena aliran data besar, mereka perlu antri untuk memprosesnya. Sebagai antrian, kami menggunakan Kafka. Ini adalah solusi andal yang bagus yang ditulis dalam Scala yang belum pernah mengecewakan kami.
Satu-satunya persyaratan bagi pengguna dalam hal ini adalah bahwa ia memiliki waktu untuk menyapu antrian yang semakin meningkat lebih cepat daripada pertumbuhannya. Aturan yang sederhana dan jelas. Karena itu, untuk tujuan ini, kami terutama menggunakan GoLang. Namun, ini tidak meniadakan fakta bahwa RAM di server ini harus berlimpah.
Untuk memantau semua ekonomi ini, Anda harus memantau dan mendelegasikan segala sesuatu secara berturut-turut. Untuk ini kami menggunakan:
- / NewRelic /: Solusi teruji waktu yang terintegrasi sempurna dengan layanan mikro Ruby on Rails dan GoLang. Satu-satunya minus dari NewRelic adalah harganya. Karena itu, NewRelic tidak ada di mana-mana bersama kami. Sebagian besar, kami mencoba menggantinya dengan metrik yang kami kumpulkan sendiri - kami menempatkannya di Grafana.
- / Statsd + Grafana /: Suatu hal yang baik untuk mengumpulkan metrik Anda. Dengan satu-satunya minus yang Anda harus mengkonfigurasi semuanya sendiri dan "ulangi" fungsi NewRelic di luar kotak.
- / ElasticSearch + Fluentd + Kibana /: Dalam log kita meletakkan semuanya dalam satu baris. Dari pertanyaan PostgreSQL yang lambat hingga beberapa pesan sistem Rails. Sebenarnya, solusi seperti Kibana berdasarkan ElasticSearch memungkinkan Anda dengan mudah mengumpulkan semua log di satu tempat dan kemudian mencari pesan yang diperlukan di dalamnya.
- / Airbrake /: Wajib dalam hal ini adalah proses mengumpulkan kesalahan bersama dengan pesan stacktrace'ami. Kami saat ini pindah dengan Airbrake ke salah satu solusi gratis. Karena suatu alasan, sekali lagi, harga.
Anda perlu memahami bahwa pemantauan yang dibangun dengan benar adalah mata dan telinga Anda. Buta tidak mungkin bekerja. Anda perlu melihat apa yang terjadi pada server Anda pada titik waktu tertentu, sehingga stabilitas dan keandalan produk Anda akan sangat tergantung pada seberapa kompeten Anda membangun sistem untuk mengumpulkan dan menampilkan metrik.
Ngomong-ngomong, berbicara tentang keandalan, kami mengandung beberapa server staging untuk pra-peluncuran dan memeriksa rilis, yang kami pertahankan stabil di bawah beban, menduplikasi beberapa lalu lintas nyata di sana. Setiap minggu kami menyinkronkan basis data antara produksi dan pementasan. Ini memberi kita semacam "cermin" yang memungkinkan kita menguji hal-hal yang tidak dapat diverifikasi secara lokal, serta mengidentifikasi masalah di tingkat pengujian beban.
Apakah ini benar-benar rumit?
Ternyata seperti itu. Seperti yang ditulis Elon Musk dalam bukunya: "Pikiran terbaik generasi saya sibuk membuat orang mengklik iklan," kata Jeff Hammerbacher, seorang insinyur Facebook, kepada saya. "Horor ..." Daftar pendek yang dilakukan Appodeal:
- Kami terintegrasi dengan dua lusin jaringan dan agensi periklanan. Dalam mode otomatis, kami mendaftarkan aplikasi di jaringan ini, serta mengkonfigurasi berbagai parameter sehingga jaringan ini bekerja pada kinerja maksimum. Tidak setiap jaringan memiliki API yang sesuai, di suatu tempat Anda harus melakukannya dengan robot.
- Setiap jaringan membayar pendapatan pengguna untuk tayangan, yang harus diterima, dipecah oleh berbagai parameter dan diproses. Ini dilakukan tanpa henti. Di suatu tempat, sekali lagi, oleh robot.
- Untuk memberikan penghasilan maksimum kepada pengguna, kami "membuat" kisi-kisi saling bersaing, membangun apa yang disebut "air terjun" dari penawaran iklan. Air terjun ini dibangun berdasarkan berbagai indikator, misalnya, BPSe (harga rata-rata per 1000 tayangan), yang kami prediksi dengan berbagai cara. Semakin tinggi penawaran iklan di air terjun, semakin tinggi kami memperkirakan harganya. Air terjun ini ditawarkan pada perangkat sesering yang diperlukan. Seperti yang mungkin sudah Anda duga, iklan yang tidak diklik dan hanya akan mengganggu semua orang tidak menarik minat siapa pun. Pengecualian hanya yang disebut. Iklan spanduk "Bermerek" dari Coca-Cola, Pepsi, dan perusahaan raksasa lainnya yang terbiasa selalu membicarakan diri mereka sendiri dan di mana-mana.
- Bagian dari interaksi ini dibangun di atas apa yang disebut protokol RTB (Penawaran Real-Time):
Dalam hal ini, yang disebut penawar diperdagangkan satu sama lain secara online di pelelangan untuk hak menampilkan iklan mereka di perangkat yang dipilih. Poin yang sangat menarik layak untuk artikel terpisah. Banyak pertukaran, seperti Google AdExchange, menetapkan kerangka kerja yang ketat untuk waktu respons server (misalnya, 50 ms), yang menimbulkan masalah peningkatan kinerja. Dalam kasus ketidaktaatan - denda ribuan dolar. Inilah yang dilakukan oleh kernel yang ditulis dalam Scala bersama dengan Druid.
Setiap pemburu ingin tahu di mana burung itu duduk, dan pelanggan kami (seperti kami) ingin tahu kepada siapa iklan itu ditampilkan, kapan dan mengapa. Karena itu, kita harus mengantri (Kafka) semua tumpukan data yang kita miliki, secara bertahap memproses dan menambahkan ke database OLAP (ClickHouse). Banyak orang berpikir bahwa PostgreSQL akan mengatasi tugas ini tidak lebih buruk daripada solusi "hipster", tetapi tidak demikian. PostgreSQL bagus, tetapi solusi klasik untuk menyusun indeks untuk kecepatan akses data berhenti berfungsi ketika jumlah bidang untuk pemfilteran dan penyortiran melebihi 10, dan jumlah data yang disimpan mendekati 1 miliar catatan. Anda tidak memiliki cukup memori untuk menyimpan semua indeks ini atau Anda akan mengalami masalah memperbarui indeks ini. Bagaimanapun, Anda tidak akan dapat mencapai kinerja yang sama dengan solusi berorientasi kolom untuk pertanyaan analitis.
Kesimpulan
Dalam artikel ini, saya mencoba untuk menjelaskan secara singkat apa yang kami lakukan, bagaimana kami menyimpan dan memproses data. Ceritakan pada kami di tumpukan mana yang Anda gunakan, ajukan pertanyaan, dan minta artikel baru - dengan senang hati kami akan membagikan pengalaman kami.