Get best of the week

Infrastruktur Pangan: Bagaimana Kami Mendukung Tanuki



Mengutip salah satu tokoh sejarah terkenal, yang terpenting dari semua layanan bagi kami adalah pengiriman. Apa yang akan kita lakukan dalam situasi saat ini tanpa roti gulung atau pizza di rumah? Saya tidak ingin membayangkan. Kebetulan 2 tahun yang lalu kami mengambil dukungan dari salah satu jaringan terbesar - Tanuki . Penonton bulanan situs ini adalah sekitar satu juta orang. Sekarang pada tahun 2020. Pada 2018, ketika Tanuki memulai kerja sama dengan kami, ukurannya 2 kali lebih kecil. Kami memastikan perpindahan tanpa rasa sakit ke pusat data baru dan sepenuhnya mereduksi infrastruktur - berkat itu, pada kenyataannya, situs dan aplikasi dapat menahan peningkatan beban tanpa masalah.

Kadang-kadang, kami sangat menyesal bahwa kami secara geografis jauh dari restoran Tanuki terdekat: jika tidak, semua kesuksesan kami (dan sedikit kemalangan) akan macet dengan roti gulung yang lezat.

Secara umum, hari ini kami ingin menceritakan kisah dukungan dari salah satu proyek web terbesar dari “industri perhotelan” domestik.

Kami bertemu pada akhir Maret 2018.

Hari Perempuan Internasional telah lama berlalu, tetapi para pria baru saja mengatasi konsekuensinya. Semuanya cukup biasa: pada malam 8 Maret, lalu lintas meningkat tajam, dan situs tidak tersedia untuk waktu yang lama. Sangat panjang, bukan beberapa jam. Karena lalu lintas terbang tidak hanya melalui situs utama, tetapi juga berasal dari aplikasi (tersedia untuk Android dan iOS), serta agregator (Yandex. Makanan, Klub Pengiriman, Zaka-Zaka).

Apa yang kami lihat


Secara teknis, proyek ini ternyata cukup rumit:

  • Situs ini adalah aplikasi reaksi dengan SSR (rendering sisi server).
  • Aplikasi seluler - untuk iOS / Android.
  • API - semua aplikasi bekerja dengannya.
  • Sistem eksternal, termasuk pemrosesan pesanan.


Sistem itu adalah server proxy terbalik: lalu lintas ke mereka melalui sistem perlindungan dari serangan DDoS dan dari sana sudah didistribusikan di antara server backend. Pada saat penerimaan, ada situs lama dan API untuk versi seluler, dan pengembangan situs baru dimulai. Pengembangan API baru dilakukan pada server yang terpisah.

Database cluster terdiri dari dua server dengan replikasi master / master, di mana switching jika terjadi kegagalan pada tingkat jaringan karena IP mengambang. Semua aplikasi tulis bekerja dengan IP ini, sementara ada budak MySQL untuk membaca yang terletak di setiap server backend - di mana aplikasi tersebut, bekerja dengan localhost.

Di resepsi, kami melihat masalah berikut:

  • Mekanisme penyeimbangan yang kurang andal dalam konfigurasi basis data. Master replikasi master menyebabkan kegagalan sering.
  • Budak di setiap backend - membutuhkan ruang disk yang besar. Dan manipulasi atau menambahkan server backend baru mahal.
  • Tidak ada sistem penyebaran yang umum untuk aplikasi - ada sistem penyebaran mandiri melalui web.
  • Tidak ada sistem untuk mengumpulkan kayu - sebagai akibatnya cukup sulit untuk menyelidiki insiden, pertama-tama, dalam bekerja dengan sistem pesanan, karena tidak ada cara untuk menentukan bagaimana pesanan tertentu diterima.
  • Tidak ada pemantauan indikator bisnis - tidak mungkin mencatat secara tepat waktu penurunan atau tidak adanya pesanan.

Setelah audit awal dari server diterima untuk pemantauan, kami mulai dengan pembentukan peta jalan operasional. Awalnya, dua bidang utama pekerjaan diidentifikasi:
  1. Stabilisasi aplikasi.
  2. Organisasi lingkungan pengembangan yang nyaman untuk API dan situs baru.

Keputusan dalam arah pertama terutama terkait dengan stabilisasi cluster MySQL. Saya tidak ingin menolak master replikasi master, tetapi tidak mungkin untuk terus bekerja dengan IP mengambang. Gangguan dalam konektivitas jaringan diamati secara berkala, yang menyebabkan gangguan dalam operasi cluster.

Pertama-tama, kami memutuskan untuk meninggalkan IP mengambang demi server proxy, di mana upstream akan dikontrol antara master, karena kami menggunakan nginx sebagai proxy untuk MySQL. Langkah kedua adalah alokasi dua server terpisah untuk budak. Bekerja dengan mereka juga diatur melalui server proxy. Dan sejak reorganisasi, kami lupa tentang masalah yang terkait dengan bekerja dengan database.

Selanjutnya, kami memantau pesanan di tingkat kueri dalam basis data. Setiap penyimpangan dari norma - ke tingkat yang lebih besar atau lebih kecil - segera memunculkan penyelidikan. Kemudian, pada tingkat log, kami membentuk metrik untuk memantau interaksi eksternal, khususnya, dengan sistem manajemen pesanan.

Bersama dengan kolega, atas permintaan mereka, kami melakukan penyesuaian tambahan semua sistem untuk operasi yang stabil dan cepat. Baik menyetel MySQL dan memperbarui versi PHP. Selain itu, rekan-rekannya memperkenalkan sistem caching berbasis Redis, yang juga membantu mengurangi beban pada basis data.

Semua ini penting ... Tetapi hal utama untuk bisnis adalah peningkatan penjualan. Dan dalam konteks ini, manajer perusahaan memiliki harapan besar untuk situs baru. Untuk pengembang, perlu untuk mendapatkan sistem yang stabil dan nyaman untuk penerapan dan kontrol aplikasi.

Pertama-tama, kami memikirkan tentang jalur perakitan dan pengiriman aplikasi CI / CD, serta sistem untuk mengumpulkan dan bekerja dengan log.

Semua repositori klien di-host pada solusi bitbucket yang di-host-sendiri . Untuk organisasi jalur pipa, jenkins dipilih.

Untuk memulainya, sudah biasa menerapkan pipa pada lingkungan dev - ini memungkinkan kami untuk secara signifikan meningkatkan kecepatan pengembangan. Kemudian diperkenalkan di sirkuit produksi, di mana penyebaran otomatis memungkinkan kami untuk menghindari kesalahan yang sering terjadi, biasanya disebabkan oleh faktor manusia.

Setelah implementasi, CI / CD mulai mengatur pengumpulan log dan bekerja dengannya. Tumpukan ELK dipilih sebagai yang utama, yang memungkinkan klien untuk melakukan investigasi lebih cepat dan lebih baik jika terjadi insiden. Dan sebagai hasilnya, pengembangan aplikasi berjalan lebih cepat.

"Lebih buruk dari dua kebakaran ..."


Setelah menyelesaikan tugas-tugas standar yang cukup kompleks, namun demikian, Tanuki memberi tahu kami apa yang ingin mereka katakan untuk waktu yang lama: "Ayo bergerak!"

Perubahan DC disebabkan oleh faktor ekonomi. Selain itu, klien memperluas infrastrukturnya dengan layanan tambahan yang sudah ada di DC baru, yang juga memengaruhi keputusan untuk pindah.

Migrasi sistem apa pun, apalagi yang rumit, adalah proses yang membutuhkan perencanaan luas dan sumber daya besar.

Langkah itu dilakukan secara iteratif: pada tahap pertama, server proxy terbalik dibuat di DC baru. Dan karena hanya mereka yang memiliki ip publik, mereka juga bertindak sebagai titik akses ke sistem untuk administrator.

Kemudian kami meluncurkan semua layanan infrastruktur - logging dan CI / CD. Sebuah konsuldiizinkan untuk mengatur layanan interaksi yang nyaman, mudah dikelola, dan cukup andal antara aplikasi klien.

Basis data berikut bermigrasi, Redis dan broker antrian - RabbitMQ. Di sini penting untuk mengatur semuanya sehingga mereka terdaftar dengan benar dalam protokol penemuan layanan, yang, pada gilirannya, mengendalikan operasi DNS. Perhatikan bahwa aplikasi tidak bekerja secara langsung dengan database, tetapi melalui Haproxy, yang memungkinkan Anda untuk dengan mudah menyeimbangkan antara database dan beralih jika terjadi kegagalan.

Pada tahap persiapan, replikasi basis data antara pusat data tidak meningkat. Saya baru saja mentransfer cadangan. Selanjutnya, kami mulai mengkonfigurasi aplikasi secara langsung, dan ini adalah organisasi semua interaksi melalui DNS internal - interaksi antara aplikasi dan database / Redis / RabbitMQ / layanan eksternal (misalnya, layanan pemesanan). Secara alami, pada tahap yang sama, semua mekanisme CI / CD segera terhubung - dan kemudian perubahan kedua dalam arsitektur muncul. Sebelumnya, mengubah pengaturan aplikasi melalui antarmuka tidak dimungkinkan - hanya dengan mengedit file langsung di konsol. Segera, kami memperkenalkan solusi yang memungkinkan Anda mengelola pengaturan dengan mudah - melalui antarmuka web. Itu didasarkan pada kubah Hashicorp (Konsul bertindak sebagai backend untuk itu), yang memungkinkan kami untuk membangun mekanisme yang nyaman untuk mengelola variabel lingkungan.

Langkah selanjutnya adalah beralih layanan ke DC baru. Karena pekerjaan semua sistem diatur menggunakan protokol http, dan semua domain melewati sistem perlindungan terhadap serangan DDoS, beralih beralih untuk memanipulasi hulu secara langsung di antarmuka sistem ini.

Sebelumnya, replika yang diperlukan disusun dari DC lama ke yang baru. Dan beralih ke jendela kerja yang disepakati.

Seperti apa infrastrukturnya sekarang





  • Semua traffic menuju ke balancers. Lalu lintas ke API berjalan dari aplikasi Tanuki (di Android / iOS) tidak secara langsung, tetapi melalui Qrator.
  • Di server statis adalah situs utama proyek tanuki.ru, server dengan halaman arahan.
  • Cluster backend sekarang terdiri dari server: frontend, statis, server untuk aplikasi.

Skema lewat pesanan Pesanan yang
diterima melewati Qrator (segera kami saring serangan) dan sampai ke API. Kemudian dia pergi ke Raiden untuk mengirimkan pesanan, pergi ke Redis dan pergi ke nginx, setelah itu dia pergi ke database.

Apa yang telah berubah untuk pelanggan


  • Keandalan sistem: masalah diamati pada Juli 2019 - pesanan tidak dikeluarkan dalam waktu satu jam. Tapi itu sebelum langkah global. Tidak ada insiden besar yang diamati.
  • Kehidupan pengembang: mereka memiliki lingkungan pengembangan yang nyaman, CI / CD.
  • Toleransi kesalahan: infrastruktur sekarang menahan banyak lalu lintas. Misalnya, selama liburan, RPS memuncak di 550 unit.

Apa berikutnya


Dalam kondisi modern, penjualan online muncul. Proyek harus memberikan keandalan dan aksesibilitas bagi pelanggan layanan. Tetapi pengembangan juga merupakan komponen yang sangat penting: rilis produk harus secepat dan tidak terlihat oleh pengguna akhir.

Masalah penting lainnya adalah pemanfaatan sumber daya dan mengurangi biaya pemeliharaan sistem.

Semua ini mengarah pada kebutuhan untuk meninjau sistem secara keseluruhan. Langkah pertama adalah mengatur aplikasi kontainerisasi. Kemudian ia berencana untuk mengatur cluster Kubernetes. Tetapi kita akan membicarakan ini di artikel selanjutnya. Sementara itu - bon appetit :-)

More articles:


All Articles