Kami membuat sistem deteksi pinjaman terbaik di Rusia dan negara-negara tetangga. Di dunia yang ideal, kita hanya akan berurusan dengan desain dan pengembangan sistem. Namun, sayangnya, Anti-plagiarisme tidak berfungsi dalam ruang hampa, dan agar pengguna kami dapat menggunakan perkembangan kami dengan nyaman dan nyaman, kami juga perlu mengembangkan lingkungan di sekitar layanan kami. Perangkat lunak kami tidak berfungsi tanpa besi, pengguna perlu memberikan dukungan teknis, perlu menerima pembayaran dari pengguna tanpa melanggar hukum, dll. Singkatnya, rutinitas sudah cukup.

Artikel ini adalah yang pertama dari serangkaian drama produksi tentang bagaimana kami membuat layanan kami lebih baik dengan outsourcing. Kami berbagi masalah dan kesimpulan nyata.

Awan, kuda berambut pirang ...

^{(dari suatu tempat di Internet, saya pertama kali melihatnya di sini .)}

Beban pada sistem kami sangat tidak merata: pertama, pada siang hari beban berubah 5 kali. Kedua, ada musiman diucapkan. Maksimum harian cek setelah akhir sesi musim panas berkurang 10 kali! Sesi musim dingin tidak begitu cerah, tetapi juga bukan hadiah. Plus, setiap sesi musim panas berikutnya lebih berat (dalam hal jumlah pemeriksaan) dan lebih sulit (teknologi pencarian dan fungsi baru) dari yang sebelumnya. Oleh karena itu, di satu sisi, saya ingin memiliki persediaan sumber daya yang baik, di sisi lain, tidak membayar terlalu banyak selama penurunan aktivitas. Dalam satu sesi, Anda dapat menggunakan lebih banyak server, dan di musim panas mengurangi jumlah sumber daya yang dikonsumsi. Jelas, ini hanya terjadi dengan penyedia cloud. Pada artikel ini, saya akan berbicara tentang berbagai aspek berinteraksi dengan beberapa penyedia cloud (AWS, IT Grad, MCS, YC). Jika kelihatannya seseorang bahwa ini adalah tangisan jiwa, dia tidak akan sangat keliru. Jadi ayo pergi!

Aws

Kami mulai menggunakan sumber daya cloud pada Februari 2013 ketika kami menyewa server pertama kami di AWS. Faktanya, Amazon adalah pengalaman Anti-Plagiarisme pertama dan terpanjang dengan awan. Lalu kami mulai dengan satu mesin, dan sekarang anggaran kami di AWS adalah urutan besarnya lebih tinggi dari anggaran untuk semua cloud Rusia. Cinta pertama, seperti yang Anda tahu, tidak pernah dilupakan. Semua masalah dan peluang dengan cloud lain dalam artikel ini saya pertimbangkan berdasarkan pengalaman menggunakan AWS.

Benar, ada juga lalat di salep dalam hubungan dengan Amazon. Berikut ini adalah fitur atau ketidaknyamanan yang kami miliki dengan Amazon:

1. Anda tidak dapat mengakses konsol mesin virtual melalui browser. Dan terkadang itu di sini benar-benar dibutuhkan! Setelah kami keliru menghapus antarmuka jaringan, dan akses hilang di salah satu mesin. Beruntung seseorang telah mengalami masalah seperti itu, dalam setengah jam kami menemukan dan berhasil menerapkan solusi. Melalui konsol, operasi seperti itu dapat dilakukan dalam satu menit.
2. Biaya dalam dolar, dan kami dapatkan dalam rubel. Dengan demikian, profitabilitas tergantung pada dolar.
3. Tidak ada pusat data di Rusia, yang terdekat ketika kami memulai adalah di Irlandia. Ini berarti ping besar dan beberapa pembatasan penyimpanan data yang muncul karena persyaratan hukum Rusia.
4. Roskomnadzor secara teratur memblokir alamat AWS. Saat ini, ada ketersediaan server yang berbeda di AWS dari situs yang berbeda. Untuk alasan yang tidak diketahui, koneksi ke mesin mungkin jatuh. Biasanya, mengubah alamat IP, VPN, dan proksi membantu.
5. Amazon secara signifikan lebih mahal daripada awan Rusia. Benar, Anda dapat mengurangi biaya melalui program cadangan yang fleksibel dan penggunaan mesin virtual . Dan kami secara aktif menggunakan keduanya. Sayangnya, kami belum melihat fungsi seperti itu di cloud domestik (pembaruan: YC mengumumkan "VM terputus" pada buletin 18 Februari, kami sedang menunggu detailnya).
6. Masalah dengan pesan yang kurang informatif. Selama transisi dari mesin generasi ke-3 ke ke-4 atau ke-5, perangkat keras virtual berubah secara serius, khususnya, metode menghubungkan drive, dan mesin-mesin itu baru saja mulai setelah jenisnya diubah. Antarmuka manajemen instance mengembalikan pesan singkat: kapasitas tidak mencukupi. Ada cukup banyak batasan untuk membuat jenis mesin yang diperlukan dengan margin, dan selama sekitar enam bulan kami gagal mencoba dukungan teknis gratis untuk mengubah batas. Itu tidak membantu. Sebagai hasilnya, mereka mencari sendiri solusinya - rekreasi dangkal dari alat berat itu membantu.
7. Beberapa kali kami menghapus SSD hingga berlubang: disk hilang begitu saja dari sistem beserta semua data. Mengingat bahwa ini adalah disk yang sementara , mis. data hilang ketika mesin berhenti, kami tidak menyimpan sesuatu yang tak tergantikan pada mereka.

Pada prinsipnya, adalah mungkin untuk hidup dengan kekurangan-kekurangan ini. Namun, tepat pada saat ketika Amazon akhirnya memperhatikan pasar Rusia, akun kami menjadi sangat tidak nyaman untuk pembayaran dari kartu. Untungnya, Amazon dengan cepat memperbaiki situasi dan memberi kami manajer akun yang membantu kami beralih dari pembayaran melalui kartu ke kontrak langsung dan membayar tagihan serta membuat berbagai jenis perjanjian. Secara umum, ia secara teratur datang ke Rusia, dan ketika ia mendatangi kami, ia berbicara tentang peluang untuk mengoptimalkan infrastruktur dan pembayaran. Terkadang dia membawa Solusi Arsitek, yang dengannya dia dapat mendiskusikan arsitektur solusi kami saat ini, berbicara tentang "Wishlist" dan masalah, dan mendapatkan beberapa solusi, tidak hanya melalui layanan AWS. Karyawan Amazon menyatakan bahwa tujuan mereka bukan untuk menyediakan lebih banyak layanan, tetapi untuk memastikan bahwa layanan yang dibeli bermanfaat bagi bisnis. Sepertinya ini benar. Jumlah layanan, kecepatan pengembangan mereka dan kedalaman integrasi timbal balik sangat mengesankan. AWS memiliki segalanya untuk mengatur proses pengembangan dan pengoperasian sistem yang sangat dimuat dalam skala apa pun. Sejauh ini, hanya satu masalah global yang mahal!

IT Grad 2016

Pada 2015, kami memutuskan bahwa sudah waktunya bagi kami untuk sepenuhnya meninggalkan besi kami sendiri. Saya ingin meletakkan masalah pada keandalan peralatan secara khusus pada orang lain dan lebih berkonsentrasi pada peningkatan proses pengembangan kita sendiri. Menurut perkiraan kami, pada tahun 2016 kami akan memiliki cukup peralatan yang kami miliki saat ini, dan kami ingin memiliki cadangan untuk setiap peristiwa kebakaran. Kami mendekati pilihan penyedia secara menyeluruh: kami menyiapkan tes beban dan kuesioner dengan pertanyaan-pertanyaan penting bagi kami dan dengan cermat memilih dari lima penyedia: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline.

Sebagai hasilnya, kami memilih awan IT Grad. Keuntungan mereka:

1. Posisi hidup aktif, jawaban pertanyaan kami diberikan dengan cepat, mudah berkomunikasi.
2. Kehadiran drive SSD cepat, hingga 30 IOPS per GB. Jumlah operasi baca acak adalah indikator yang sangat penting bagi kami, karena nilai yang tinggi memungkinkan kami untuk menempatkan modul pindaian kami di cloud.
3. Platform VCloud dengan kemampuan untuk mengendalikan mesin dan kehadiran konsol untuk setiap mesin.
4. Kemampuan untuk meningkatkan sumber daya mesin virtual tanpa me-reboot.
5. Tagihan fleksibel - pembayaran dilakukan untuk sumber daya yang digunakan pada hari di tengah periode pelaporan (pada tanggal 14-15 setiap bulan). Selain itu, ada opsi "Pay-As-You-Go", namun, itu lebih mahal dan perhitungan jumlah sumber daya yang dikonsumsi dilakukan oleh beban rata-rata CPU dan RAM setiap 2 jam.

Pada 2016, kami pindah ke IT Grad. Inilah yang terjadi dalam tiga tahun kehidupan kita yang tidak lengkap:

1. Dulu kami punya masalah. Tepat pada pukul 21:00, terjadi penurunan kinerja yang aneh. Jumlah cek yang dapat dilakukan sistem turun dari 150 menjadi 20-30 per menit, sementara setelah beberapa jam semuanya dipulihkan dan diselesaikan dengan kecepatan 600 cek per menit. Kami mencari selama seminggu di rumah, memeriksa pengguna, menangkap bot dan DDoS, tetapi tidak menemukan apa pun. Kami beralih ke dukungan IT-Grad, menemukan bahwa "oh, dan kami sedang membuat cadangan di sini." Akibatnya, mereka menghancurkan kami dengan sumber masalah pada sistem disk yang berbeda dan mengatur pekerjaan.
2. Biasanya (fitur menggunakan produk), selama sesi, lalu lintas kami melebihi 100 megabit per detik. Nilai ini, by the way, sering ditetapkan secara default untuk saluran yang tidak dicadangkan di banyak penyedia cloud. Ketika kami pertama kali melewati perbatasan ini, sejumlah masalah muncul: Edge bawaan tidak dapat mengatasi VPN antara titik masuk yang terletak di peralatan kami dan mesin virtual server web yang terletak di cloud. Seperti yang diharapkan, mereka beralih ke dukungan, di mana kami ditawari untuk meningkatkan sumber daya di Edge. Oke, tidak ada pertanyaan, kami mengganti konfigurasinya dari kecil ke besar, dan juga memperluas saluran ke ukuran lalu lintas puncak kami dengan margin. Itu tidak membantu. Secara umum, kami tidak dapat menemukan solusi optimal, saya harus mengurangi volume lalu lintas dengan memindahkan sebagian produksi ke situs lain.
3. Koneksi VPN ke situs IT Grad terkadang putus selama 1-2 menit. Untuk pertanyaan mengapa ini terjadi, baik kami maupun dukungan teknis tidak dapat menemukan jawabannya. Sejauh ini saya harus hidup dengan masalah ini.
4. Mekanisme untuk mengubah ukuran sumber daya bekerja dengan buruk, baik dengan cepat maupun dalam kondisi tidak aktif. Sepertinya saya, bagaimanapun, ini agak masalah dengan vendor platform (VMware). Namun demikian, kami telah menemukan fakta bahwa untuk dapat menerapkan semua ekstensi secara andal, perlu menyalakan ulang mesin tamu (Windows Server 2012 R2). Setelah mengubah ukuran, mesin itu sendiri tidak bisa boot beberapa kali. Dukungan sekali memperbaiki masalah ini dari 2 hingga 4 di pagi hari selama sesi - musim kami. Itu panas bahkan di malam hari!
5. Pada 2016, kami memiliki monolit besar, seperti Everest, yang membutuhkan banyak sumber daya. Begitu banyak yang kadang-kadang kita perlu melebihi ukuran maksimum mesin tamu yang direkomendasikan untuk host yang diberikan. Dukungan terus-menerus meminta kami untuk mengurangi ukuran mesin virtual hingga setidaknya setengah dari ukuran host. Kami harus membayar upeti kepada IT Grad - kami ditawari untuk menggunakan perangkat keras terpisah dengan kemampuan untuk menggunakannya sepenuhnya, namun, untuk beberapa uang besar lainnya, dan fleksibilitas cloud hilang.
6. Tagihan sebulan sekali untuk mengukur jumlah sumber daya yang dikonsumsi telah menipu kami dua kali. Pada awalnya, kami langsung bertanya tentang kesempatan untuk mengurangi sumber daya pada tanggal 14-15 dalam sebulan untuk membayar lebih sedikit. Kami langsung menjawab bahwa ini cara kerjanya. Pertama kali itu menghantam kami dengan susah payah selama transfer sebagian dari penjualan ke cloud kami. Faktor manusia bekerja - mereka mencoba menyelesaikan semuanya dengan cepat pada tanggal 14, kemudian mereka menyapu bersihnya. Kedua kalinya kami mengambil kesempatan ini setelah hampir 3 tahun bekerja sama, setelah itu kami ditagih rata-rata pada hari ke 5, 15, 20. Kemudian faktor manusia bekerja untuk mereka - setelah panggilan itu ternyata mereka melakukan kesalahan yang menguntungkan mereka (perhitungan ulang dilakukan secara manual), meminta maaf, memberikan diskon.
7. Kinerja disk dan mesin secara keseluruhan memenuhi karakteristik yang dinyatakan. Namun demikian, beberapa kali kami tidak dapat memahami mengapa semuanya bekerja sangat lambat, bahkan antarmuka melambat tanpa ampun. Dukungan meyakinkan bahwa semuanya beres dan mereka tidak memiliki masalah dengan peralatan. Apa yang terjadi di sana - server kami pada saat itu bermigrasi ke host tetangga atau seseorang membuat cadangan dari subsistem disk - itu tetap menjadi misteri bagi kami.
8. Disk dapat beralih antara mesin secara mandiri hanya melalui dukungan. Pada awal penggunaan, tidak mungkin memiliki disk dengan jenis berbeda di mesin, Anda harus keluar (iSCSI, Samba dan NFS). Setelah beberapa waktu, menggunakan berbagai jenis disk dalam satu mesin menjadi mungkin pertama melalui dukungan, dan kemudian sendiri (tampaknya dilakukan di vCloudDirector). Omong-omong, memperbarui sistem manajemen virtualisasi terjadi secara teratur. Kami menerima surat 1-2 kali sebulan yang menyatakan bahwa selama satu atau dua jam sistem kontrol mesin virtual mengambil pekerjaan teknis dan tidak akan tersedia untuk beberapa waktu, mesin itu sendiri terus bekerja pada saat ini.
9. Pada 16 Februari 2018, bagian dari penjualan kami yang berlokasi di IT Grad terletak karena masalah pasokan daya dari pusat data di mana peralatan itu berada. Kami mengetahui tentang kejadian tersebut secara de facto, kami tidak dapat menghubungi dukungan teknis. Saya harus menghubungi manajer akun kami, dia segera berkata apa dan bagaimana, dan terputus, tampaknya mengatakan sisanya. Dari yang menyenangkan - kami berbaring di sebelah VKontakte.

Setelah menghabiskan beberapa waktu di rumah sewaan dan menghadapi semua hal di atas, pada tahun 2017 kami memutuskan bahwa itu baik untuk dikunjungi, tetapi lebih baik di rumah, dan mulai membuat cloud dengan disk NVMe yang cepat dan kemampuan untuk sepenuhnya mengendalikan semuanya. Tidak lama setelah selesai mengatakan: mereka memindahkan penjualan ke cloud mereka dari klien korporat dan modul pencarian (total lebih dari 90% dari beban), meninggalkan pemantauan, statistik dan klien pribadi di IT Grad. Pada tahun 2018, semua orang sekali lagi menghitung semuanya dan ternyata lebih menguntungkan untuk membagi produksi: tetap menjadi bagian dalam cloud yang disewa, dan bagian dalam diri mereka sendiri. Apa yang terjadi dengan ini - kami ceritakan lebih lanjut.

Solusi cloud mail

Jujur, saya ingin, seperti di AWS, tetapi di Rusia. Oleh karena itu, kami mulai melihat ke arah awan dengan serangkaian layanan serupa (yang saya tipu, paling tidak dengan analog EC2 dan S3). Pencarian berumur pendek - kami menemukan "Amazon Rusia" dalam pribadi MCS . Sebuah perusahaan besar dengan beragam layanan yang beragam, dengan semua indikasi mereka harus dapat mempersiapkan awan!

Awal dari kenalan itu luar biasa. Seorang manajer akun datang ke kantor kami, menceritakan semuanya secara terperinci, menggambarkan peluang dan rencana saat ini untuk waktu dekat. Outputnya adalah gambar yang luar biasa: harga rendah untuk sumber daya komputasi, ada penyimpanan objek dan keluar awal ke produksi basis data (mirip dengan RDS). Kami juga diberi batas uang tunai untuk pengujian (bahkan lebih dari yang diberikan Azure).

Pada saat itu, kami sudah memiliki bagian IaC siap untuk menyebarkan semua mesin melalui terraform. MCS memiliki openstack dan didukung dengan baik! Ngomong-ngomong, dukungan teknis dilakukan melalui saluran telegram - komunikasi "langsung" dan jelas bahwa mereka ingin membantu. Ada sistem tiket, tapi kami belum menggunakannya. Dukungan Teknis SLA mengacu pada permintaan yang dibuat dalam sistem tiket.

Pada Desember 2018, kami telah menulis skrip penyebaran infrastruktur melalui terraform. Saatnya bergerak. Untuk mulai dengan, kami memutuskan untuk mentransfer sistem dengan klien pribadi, yang selama ini hidup dengan peralatan di IT Grad. Maka semuanya seperti dalam film:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


Masalah yang diidentifikasi dengan format berbeda dengan upaya baru seharusnya tidak muncul, tetapi kami menemukannya dan kalau-kalau diperbaiki.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


Produk lama pada IT Grad dengan mudah memenuhi permintaan yang ditangguhkan untuk cek pengguna, tidak masalah.

Hari berikutnya (18 Desember), kami menyadari hal berikut:

1. Kami tidak tahu apa yang memperlambat sistem secara khusus. Sebelum dekorasi, praktis tidak ada beban di mana pun. Ya, kami masih memiliki panggilan pemblokiran yang dalam di dalam sistem dan kemungkinan besar ada penyumbatan di suatu tempat, tetapi di mana tepatnya, kami tidak dapat menemukan, perlu untuk menyelidiki lebih lanjut.
2. Tes beban kami saat ini tidak cocok dengan profil beban untuk prod. Itu luar biasa karena berkat tes ini, kami bersiap untuk sesi terakhir, mengidentifikasi dan menghilangkan sejumlah besar kemacetan. Tapi itulah kenyataannya - perlu untuk mengulang tes dengan mempertimbangkan pengalaman yang didapat.
3. Diproduksi pada IT Grade dengan sumber daya CPU dan RAM yang sebanding, dapat dengan mudah mengatasi beban dua kali lipat.

Jadi, kami dengan cepat membangun tes yang mencapai hasil yang sama dengan yang kami lihat secara langsung. Kami pergi ke dukungan MCS untuk mengetahui apakah kami makan di luar batas CPU, tetapi secara umum itu adalah milik kami sepenuhnya atau tidak, dan semuanya baik-baik saja dengan jaringan. Mereka masih belum menjawab pertanyaan kedua, mereka menemukan sesuatu pada yang ketiga dan merekomendasikan kami untuk melakukan perubahan pada sistem multi-core. Secara umum, kami telah mengembangkan kegiatan yang bersemangat, akhir tahun sudah dekat, dan semua orang ingin pergi untuk liburan dengan rasa prestasi.

Inilah yang akhirnya kami lakukan saat bekerja dengan MCS:

1. Bahkan pada tahap seleksi, kami dikirimi meja dengan karakteristik perangkat keras virtual dan SLA oleh disk. Salah satu kelebihannya adalah bahwa mereka menjanjikan 50 IOPS / GB (IT Grad: 30 IOPS / GB) untuk SSD. Kontrak ternyata berbeda: "membaca: 5000 IOPS, menulis: 2000 IOPS", dan kami melewatkan ini, kami tidak mengharapkan ini. Tabelnya identik, perbedaannya hanya di satu tempat! Omong-omong, kami tidak melihat dependensi kinerja pada ukuran disk. Saat kami uji, ternyata dengan drive yang lebih besar, kecepatannya menurun. Rahasia dari indikator kecil tersebut adalah bahwa MCS memiliki geo-didistribusikan ceph, yang berarti bahwa sampai node jauh mengatakan bahwa data telah ditulis, klien tidak akan diberitahu bahwa rekaman selesai. Ngomong-ngomong, tidak ada yang tampaknya memiliki keandalan seperti itu "di luar kotak" di antara penyedia layanan yang berbicara dengan kami. Tetapi bagi kami keandalan seperti itu hanya menempatkan tongkat di roda! Jika sesuatu terjadi, kita perlu dengan cepat pindah ke DC lain ketika masalah muncul, dan karena itu kita memiliki replikasi asinkron kita sendiri. Kami memiliki DRP , dan kami siap untuk kehilangan sejumlah kecil data jika terjadi kecelakaan. Kita harus membayar upeti kepada MCS, mereka mempercepat commissioning array SSD lokal, yang kinerjanya jauh lebih tinggi.
2. Adapun parameter mesin, mereka tidak sewenang-wenang. Ada serangkaian CPU-RAM- {SSD / HDD} (hampir seperti pada AWS), dan jenis mesin lainnya hanya dapat dibuat melalui dukungan. Seluruh proses memakan waktu sekitar 2 jam, tidak ada batasan pada jumlah jenis, yang utama adalah bahwa jumlah core harus tidak lebih dari setengah dari prosesor hypervisor ~ 40-48. Selama pembuatan mesin, Anda dapat menambahkan disk sendiri dan beralih di antara mesin.
3. Setelah menyalakan SSD lokal, mengubah parameter mesin membuatnya mustahil untuk memulai. Mereka hanya bisa diluncurkan melalui dukungan. Di suatu tempat dalam sebulan mereka memecahkan masalah.
4. Untuk pertama kalinya dihadapkan dengan dukungan teknis oleh telegram. Secara umum, itu nyaman, terutama di awal, ketika ada banyak pertanyaan dan ada banyak ke layanan. Tetapi semakin jauh, semakin sulit pertanyaan yang muncul dan kecepatan respon dan konten informasi perlahan-lahan menurun. Pada akhir tahun, ketika, tentu saja, tenggat waktu semua orang, kecepatan respon yang rendah membuat saya sangat marah. Pada titik tertentu, mereka bahkan bertanya tentang SLA. Di sinilah pemahaman muncul bahwa SLA ada di sistem tiket, dan bukan di telegram! Pada saat 19 Februari, beberapa pertanyaan kami yang belum terjawab yang diajukan pada tanggal 24 Desember digantung di saluran ini ...
5. Dukungan teknis melalui sistem tiket tidak memperhitungkan bahwa kami login, dan memerlukan pemberitahuan tambahan dari nomor kontrak. Sebagai tanggapan, ia mengirim surat "kami akan menghubungi Anda", tetapi tidak menunjukkan nomor tiket atau status.

Saat bekerja dengan MCS, awan lain mulai terlihat paralel.

Namun Awan lain (Awan Yandex)

Yang pertama adalah Yandex. Pada akhir 2018, mereka hanya memiliki mesin virtual dan penyimpanan objek, shell sistem virtualisasi mereka sendiri, API terbuka. Plugin terraform berada di alfa dan disetujui oleh HashiCorp. Dukungan, seperti biasa, adalah melalui telegram, tetapi kurang aktif daripada di MCS. Batas uang uji cukup kecil dan tidak memungkinkan kami melakukan pengujian normal. Saya harus buru-buru membuat perjanjian (3 hari kerja) dan membayar untuk pengujian. Menurut hasil tes, kami mendapat hal yang sama seperti pada MCS. Bagi kami, tampaknya ada dua masalah: setiap orang memiliki drive yang terlalu lambat, dan kami memiliki tes yang terlalu berat.

IT Grad 2019

Secara umum, kami menetapkan tenggat waktu untuk pindah sudah pada 22 Desember, sehingga akan ada satu minggu lagi untuk mengidentifikasi dan memecahkan masalah tersembunyi dari tempat tinggal baru. Setelah kehilangan harapan untuk pindah ke tenggat waktu dan sedikit lelah dengan banyaknya informasi baru dalam diri MCS dan YC, kami memutuskan bahwa IT Grad tidak terlalu buruk dengan latar belakang mereka. Kami bahkan merasa sedikit nostalgia dan berpikir bahwa segala sesuatu yang baru sudah lama mapan. Sudah di IT Grad kita pasti akan bekerja dengan baik - ada preseden. Ditambah IT Grad memompa: ada pusat data Moskow, Tier III, saat ini masih memiliki 100% (tidak pernah gagal), dan peralatan di dalamnya adalah 4-socket Intel Xeon Scalable (hingga 42 core x 3 GHz Xeon Gold 6154). Apa-apaan ini bukan bercanda, kami akan memberikan kesempatan kedua!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. Sekarang, dalam persiapan artikel, mereka menemukan bahwa waktu yang tepat untuk permintaan dan jawaban tidak tercermin dalam sistem tiket. Sebaliknya, ia mengatakan "sekitar 2 bulan yang lalu," waktu yang tepat hanya ditampilkan di tooltip. Melalui surat, juga sulit untuk memulihkan urutan kejadian. Pesan-pesan ke email datang dengan logika yang tidak jelas dan tidak mengandung deskripsi tindakan. Tiket dibuat dalam sistem setelah beberapa waktu atas nama karyawan dukungan teknis IT Grad.
2. Setelah melihat lebih dekat peralatan setelah liburan, kami melihat Xeon v2 di sana. Bukan itu yang kami sepakati. Oke, kami memutuskan pertanyaan ini dengan manajer akun. Ada beberapa kesulitan karena fakta bahwa pada tahun 2019 IT Grad baru dimasukkan dalam MTS , dan tepat setelah liburan ada sedikit kekacauan. Dari vDC pada peralatan baru di DC Moskow tidak terlihat vDC dibuat sebelum tahun baru. Hanya melalui Internet yang terbuka, dukungan teknis “menyenangkan” kami bahwa kecepatan bergerak tidak melebihi 1TB / hari. Dan kami telah mengunggah 7TB data! Hasilnya, mereka membuat aplikasi untuk pindah pada Kamis malam. Sehari kemudian, pada Jumat malam, saya bertanya apa kabar Anda dan kapan mereka berencana untuk memulai (tunggu hampir seminggu!)? Sehari kemudian, pada Sabtu malam, kami diberi tahu bahwa semua mobil telah pindah. Saya tidak suka bahwa 2,5 hari tidak ada informasi tentang kemajuan pekerjaan dan bahwa perkiraan bergerak terlalu pesimistis.
3. Pada bulan September 2018, ketika kami mulai menerapkan IaC, kami menyadari bahwa terraform bekerja sangat buruk dengan vCloudDirector (pembaruan: pada saat penulisan, kami mengetahui bahwa VMware vCloud Director Provider 2.0 muncul , tetapi belum mencobanya). Pada awalnya, kami bahkan tidak dapat membuat mesin karena fakta bahwa vCloud memberi tahu kami tentang kesalahan dalam semangat "ada yang salah, Anda memiliki kesalahan 512 karakter 136 baris (garis lebih pendek!) Xml dari konfigurasi mesin". Kami meminta dukungan. Pertanyaan itu dialihkan ke para insinyur, pada akhirnya kami diberitahu bahwa terraform tidak didukung - atur sendiri. Ngomong-ngomong, kami menemukan bahwa pengepakan yang harus disalahkan, yang dengannya kami mengumpulkan gambar mesin, ia tidak dapat mengatasi format konfigurasi VMware yang dipatenkan. Terraform sangat buruk dengan vCloudDirector, semuanya single-threaded perlahan, dan konektor telah ditinggalkan untuk waktu yang lama dan tidak berkembang. Tidak ada yang akan memberi kami akses ke vSphere. Jika Anda tetap menggunakan VMware, maka Anda perlu melihat otomasi Anda melalui api mereka.

Kami mengatur bangku tes di lokasi baru. Hasilnya luar biasa - tes gagal, gejalanya sama seperti pada MCS. Mungkin, dalam dorongan saat ini dalam panasnya pertempuran untuk sesi ini, beberapa pengaturan OS diubah yang mencegah sistem dari pembekuan, tetapi yang sekarang tidak dapat dipulihkan. Untuk mencegah hal ini terjadi lagi, kami memperkenalkan IaC. Kami melakukan 2 tes lagi: menciptakan mesin baru dari gambar bersih dari sistem operasi penjualan saat ini - kegagalan; pada mesin produksi yang ada - sukses. Dengan demikian, dikonfirmasi bahwa kami melakukan beberapa penyetelan di OS atau basis data, tetapi kami tidak ingat yang mana. Pada titik ini, solusi dari pengembangan kami tiba tepat waktu: jalur berhenti ketika sesi yang andal dinonaktifkan di WCF.

Kami menjalankan uji beban dengan pengaturan yang direkomendasikan oleh pengembang secara paralel pada MCS (2 GHz, Xeon v4) dan IT Grad (3 GHz, Xeon v2) - jumlah inti dan memori adalah sama. Pada MCS, tes lulus lebih cepat (seperempat) dan lebih halus (pada IT Grad, tes menjadi tersentak-sentak, kemudian lebih cepat, lalu lebih lambat).

Perbandingan Kinerja Disk

Kami paling khawatir tentang kinerja disk untuk database dan indeks, itulah sebabnya kami menguji terutama SSD. Jangan menilai secara ketat untuk pengujian, ketika kami perlu memahami kinerja cloud, di habr.com belum ada beberapa tes disk, prosesor, memori ( sekali , dua ) penyedia cloud. Kami memiliki keterbatasan waktu dan kami perlu dengan cepat membandingkan kinerja untuk mendapatkan gambaran tentang perbedaan kinerja. Oleh karena itu, persyaratan untuk tes itu satu - dapat dengan cepat diulang di lokasi mana pun. Kami menggunakan mesin sedekat mungkin dengan parameter yang telah kami sebarkan, untuk menguji kinerja disk dan pgbench - untuk mengevaluasi kinerja database pada disk ini. Sebagai standar, kami melakukan pengukuran dari produksi saat ini - MARS (karena peralatan kami dinamai sesuai pahlawan seri animasi tentang tikus batu dari Mars ).

Biasanya, kinerja disk tergantung pada ukurannya. Kami mengamati perilaku ini di IT City dan AWS, tetapi di MCS kami tidak melihat ketergantungan seperti itu, itu juga tidak ada di SLA, dan tes memberikan hasil yang paradoks (dan mungkin tidak akurat) - kinerja menurun dengan meningkatnya disk.

Kami menghitung iops untuk disk HDD dan SSD, serta tps (transaksi per detik) untuk basis data postgres pada disk SSD. Ada dua jenis disk dalam MCS: SSD cef geo-didistribusikan reguler dan HDD dan SSD lokal (hanya dalam satu DC) (kinerjanya ditunjukkan dalam tanda kurung). Juga pada Januari 2019, dalam surat dari MCS, kami membaca bahwa mereka meningkatkan kinerja disk sebesar 20%, hasil tes juga ada dalam tabel (MCS 2019). Pada bulan Februari, akselerasi lain dilaporkan, tetapi kami tidak melakukan tes di sini.

Hasil:

Metodologi pengujian

iops dihitung sebagai rata-rata 4 fio run:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps , dengan rata-rata 3 pgbench berjalan:
pgbench -c 10 -j 2 -t 10000 example

Deskripsi tribun

Mars

Xeon v4, 2 GHz ; HDD: ceph, 3 Node dari ST2000NX0253 9x 2Tb, replika 2; SSD: ceph, 3 node pada 2Tb NVMe Intel DC P4600, replika 2

CPU : 4, RAM : 8GB, HDD : 32GB, SSD : 150GB; Produksi paralel berputar.

Lulusan IT

Xeon v4 / v2, 2 GHz ; HDD : 0,1 IOPS / GB ; SSD: 30 IOPS / GB

CPU : 4, RAM : 4GB, HDD : 250GB, SSD : 200GB

MC

Xeon v4; HDD: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

Untuk menguji HDD: CPU : 2, RAM : 4GB, HDD : 50GB

Untuk menguji SSD, TPS : CPU : 8, RAM : 16GB, SSD : 600GB

Y

Xeon v4, 2GHz

CPU : 8, RAM : 8GB, HDD : 20GB, SSD : 50GB

Perbandingan perkiraan TCO untuk tahun ini

Kami menghitung TCO untuk empat opsi. Nilai relatif ditunjukkan pada tabel di bawah ini. Saya harus mengatakan bahwa ini adalah perhitungan untuk kasus khusus kami dan semuanya mungkin berubah berbeda untuk Anda.

Kami melakukan perhitungan sebagai berikut. Tahun ini dibagi menjadi dua bagian: sesi (dengan peningkatan beban kerja) dan sisa waktu. Untuk setiap bagian, jumlah sumber daya CPU dan RAM yang diperlukan dihitung. Volume disk yang diperlukan, karena pertumbuhan layanan yang konstan, hanya bertambah seiring waktu, oleh karena itu, kami mengambil rata-rata antara awal dan akhir tahun untuk evaluasi.

Ada sedikit kesulitan dalam mengevaluasi dengan AWS, seperti tidak ada biaya langsung untuk kernel dan memori gigabytes. Kami mengambil 3 mesin minimal c5.large, r5.large dan m5.large dan menghitung biayanya dengan harga MCS (secara proporsional mengubah biaya inti CPU, karena MCS memiliki frekuensi 2 GHz). Ternyata seperti ini: rata-rata, biaya instance AWS sederhana adalah 2,5-2,8 kali lebih tinggi daripada biaya MCS. AWS menerbitkan harga tanpa PPN. Oleh karena itu, untuk biaya AWS kami tambahkan 20%, nilai dolar tahunan rata-rata adalah 70 rubel. Disk dianggap cukup sederhana dengan harga EBS (kami menggunakan berbagai jenis gp2, sc1, st1). Di beberapa tempat kita membutuhkan drive NVMe dari instance keluarga i3. Harga per gigabyte dihitung sangat sederhana: perbedaan biaya antara i3 dan prosesor analog dan contoh memori dari keluarga r4, dibagi dengan jumlah NVMe. Ternyata 3,1 rubel per gigabyte dalam 30 hari.

Bahkan dalam percakapan tentang anggaran, saya ingin mencatat perbedaan dalam biaya lisensi Windows untuk satu inti per bulan untuk semua penyedia cloud. Pada AWS, perbedaan antara biaya Linux OnDemand dan contoh Windows OnDemand dibagi dengan jumlah core adalah konstan sekitar 2.800 rubel per bulan. Di YC, lisensi kernel Windows harganya 3 kali lebih murah, sekitar 900 rubel per bulan, dan di MCS, hampir 9 (!) Kali lebih murah, sekitar 300 rubel per bulan. Kami masih sangat bergantung pada Windows: sekarang, terima kasih kepada .net core, kami mulai membuat lintas-platform Anti-Plagiarisme, termasuk untuk mengurangi biaya perawatan.

Biaya agregat YC juga termasuk biaya lalu lintas.

Kesimpulan

Melalui awan

AWS Mereka mengatakan bahwa di Rusia ada 4 penyedia cloud yang bagus: AWS, GCP, Azure dan DO, dan semuanya tidak ada di Rusia.
Kelebihan: layanan hebat, peralatan modern berkualitas tinggi, konfigurasi bagus di EC2, sejumlah besar layanan.
Cons: mahal (ditambah risiko nilai tukar) dan tidak di Rusia (ILV, firewall Rusia besar di cakrawala). Saya benar-benar ingin awan kita mengikuti contoh ini untuk diikuti.
Fitur: Dukungan teknis gratis dapat menyelesaikan masalah minimum, tetapi, jujur ​​saja, kami hanya menghubunginya untuk memperluas batas penggunaan. Omong-omong, biayanya sekitar 10% dari akun.

Lulusan IT . Layanan yang baik untuk cloud perusahaan. Ada analog EC2 dan S3 berdasarkan Swift.
Kelebihan: kinerja yang baik (CPU 1-2-3 GHz, SSD, HDD), peralatan baru (di salah satu DC) di antara awan domestik, konfigurasi mesin sewenang-wenang.
Cons: penagihan yang tidak dapat dimengerti, VMware (antarmuka flash yang tidak otomatis), sedikit kekacauan dan mencungkil dukungan teknis.
Fitur: dipertajam lebih banyak di bawah penggunaan perusahaan (sekali dikonfigurasi, kemudian perubahan langka) daripada di bawah sistem publik yang sangat dimuat (pembaruan sering, perubahan konstan). Sejak 2019, bisnis IaaS telah dijual bersama dengan orang-orang dan peralatan di MTS, sekarang semuanya dapat berubah ke segala arah. Komunikasi melalui sistem tiket dan telepon, saya ingin reaksi dan pesan lebih cepat dari tenggat waktu yang diharapkan.

MCS . Ada analog layanan EC2 (Ada GPU), S3, ECS, RDS, EMR, layanan mereka sendiri: Machine Learning, Cloud Disaster Recovery, Cloud Backup
Pro: murah, aktif berkembang, ada GPU (Tesla V100 dan Grid K2).
Cons: drive lambat, basah, karma buruk dari perusahaan induk.
Fitur: dukungan teknis pada awalnya bermanfaat, sejumlah besar karyawan aktif, bantuan terasa, tetapi kemudian ada penurunan aktivitas yang nyata (mereka tidak menjawab apa pun sejak 24 Desember, saya bahkan khawatir tentang mereka).

YC . Kami memiliki sedikit pengalaman bekerja dengan penyedia ini, sulit untuk mengatakan sesuatu yang spesifik. Ada analog EC2, S3, RDS, DS, SQS (alfa), ELB (alfa), layanan unik mereka: SpeechKit, Translate.
Pro: Drive lebih cepat dari MCS.
Cons: penyedia untuk terraform lembab; perangkat lunak dari shell virtualisasi dengan api terbuka tidak terlalu besar untuk komunitas, yang berarti sejauh ini Anda hanya dapat mengandalkan kekuatan tim YC dalam pengembangan penyedia untuk terraform.
Fitur: bayar untuk lalu lintas.

Pelajaran yang dipetik

1. Kami menyadari bahwa tes stres sudah usang secara moral. Mereka memperbarui tes, menemukan kemacetan baru, memperbaikinya, membuat produk lebih baik. Kami ingat bahwa tes beban harus memadai dan harus ada konfigurasi yang tidak lulus sehingga Anda dapat melihat batas penerapannya.
2. Terlepas dari kepercayaan yang meluas bahwa perangkat lunak tidak dioptimalkan saat ini, dan bahwa semua kemacetan dibanjiri dengan sumber daya, kami harus mencari tahu dan mengoptimalkan sistem kami. Ternyata lebih baik daripada sebelumnya, versi baru Anti-Plagiarisme membutuhkan lebih sedikit sumber daya dan bekerja lebih cepat. Sudah diuraikan beberapa tempat lagi di mana Anda dapat mengurangi konsumsi sumber daya.
3. Kami melakukan IaC, penyebaran dan pembaruan melalui ansible, belajar bagaimana pindah dari cloud ke cloud (dengan replikasi data awal) dalam hampir 10-15 menit. Jika data disalin dan replikasi reguler dikonfigurasi, maka ini dia Disaster Recovery Plan: bergerak dalam setengah jam dengan kehilangan data dalam 15 menit terakhir.

Apa yang kita inginkan dari awan

1. Jawaban cepat dari dukungan teknis. Sayangnya, kami tidak dapat menggunakannya seperti pada AWS, sejauh ini - terlalu sedikit informasi yang tersedia.
2. Dukungan untuk otomatisasi penyebaran infrastruktur melalui dana gratis (terraform).
3. Prediktabilitas dalam kinerja. Ini berlaku untuk penagihan, kinerja CPU, RAM, disk.
4. Kehadiran analog fungsional EC2, S3, RDS sekarang. Dalam waktu dekat, kami membutuhkan dukungan untuk k8 dan perhitungan GPU (kami sudah menggunakannya pada AWS).

Selain pindah ke awan, selama beberapa bulan terakhir kami telah berhasil menyentuh penggaruk di area lain. Bagaimana itu - kami akan memberi tahu nanti.