Halo, pembaca Habr. Dengan artikel ini kami membuka seri yang akan membahas tentang sistem hyperconverged AERODISK vAIR yang telah kami kembangkan. Awalnya kami ingin menceritakan semuanya di artikel pertama, tetapi sistemnya cukup rumit, jadi kami akan memakan gajah itu sedikit demi sedikit.
Mari kita mulai ceritanya dengan sejarah pembuatan sistem, mempelajari sistem file ARDFS, yang merupakan dasar dari vAIR, dan juga berbicara sedikit tentang posisi solusi ini di pasar Rusia.
Di artikel mendatang kita akan membahas lebih detail tentang berbagai komponen arsitektur (cluster, hypervisor, penyeimbang beban, sistem pemantauan, dll.), proses konfigurasi, mengangkat masalah perizinan, menampilkan uji kerusakan secara terpisah dan, tentu saja, menulis tentang pengujian beban dan perekat. Kami juga akan mencurahkan artikel terpisah untuk vAIR versi komunitas.
Apakah Aerodisk adalah cerita tentang sistem penyimpanan? Atau mengapa kita mulai melakukan hiperkonvergensi?
Awalnya, ide untuk menciptakan hiperkonvergensi sendiri muncul sekitar tahun 2010. Pada saat itu, belum ada Aerodisk atau solusi serupa (sistem hiperkonvergensi kotak komersial) di pasaran. Tugas kami adalah sebagai berikut: dari sekumpulan server dengan disk lokal, disatukan oleh interkoneksi melalui protokol Ethernet, perlu untuk membuat penyimpanan tambahan dan meluncurkan mesin virtual dan jaringan perangkat lunak di sana. Semua ini harus dilaksanakan tanpa sistem penyimpanan (karena tidak ada uang untuk sistem penyimpanan dan perangkat kerasnya, dan kami belum menemukan sistem penyimpanan kami sendiri).
Kami mencoba banyak solusi open source dan akhirnya memecahkan masalah ini, namun solusinya sangat kompleks dan sulit untuk diulang. Selain itu, solusi ini termasuk dalam kategori “Apakah berhasil? Jangan sentuh! Oleh karena itu, setelah mengatasi masalah tersebut, kami tidak mengembangkan lebih lanjut gagasan untuk mengubah hasil pekerjaan kami menjadi produk yang utuh.
Setelah kejadian itu, kami menjauh dari gagasan ini, namun kami masih merasa bahwa masalah ini dapat diselesaikan sepenuhnya, dan manfaat dari solusi tersebut lebih dari jelas. Selanjutnya, produk HCI yang dirilis oleh perusahaan asing hanya menegaskan perasaan ini.
Oleh karena itu, pada pertengahan tahun 2016, kami kembali melakukan tugas ini sebagai bagian dari penciptaan produk yang lengkap. Saat itu kami belum mempunyai hubungan dengan investor, jadi kami harus membeli stand pengembangan dengan biaya sendiri yang tidak terlalu besar. Setelah mengumpulkan server bekas dan mengaktifkan Avito, kami mulai berbisnis.
Tugas awal utama adalah membuat sistem file kita sendiri, meskipun sederhana, namun sendiri, yang dapat secara otomatis dan merata mendistribusikan data dalam bentuk blok virtual pada node cluster nomor ke-n, yang dihubungkan melalui interkoneksi melalui Ethernet. Pada saat yang sama, FS harus dapat diskalakan dengan baik dan mudah serta independen terhadap sistem yang berdekatan, yaitu diasingkan dari vAIR dalam bentuk “sekadar fasilitas penyimpanan”.
Konsep vAIR pertama
Kami sengaja meninggalkan penggunaan solusi open source yang sudah jadi untuk mengatur penyimpanan yang diperluas (ceph, gluster, kilau, dan sejenisnya) demi pengembangan kami sendiri, karena kami sudah memiliki banyak pengalaman proyek dengan mereka. Tentu saja, solusi ini sendiri sangat bagus, dan sebelum mengerjakan Aerodisk, kami mengimplementasikan lebih dari satu proyek integrasi dengan solusi tersebut. Namun mengimplementasikan tugas tertentu untuk satu pelanggan, melatih staf dan, mungkin, membeli dukungan dari vendor besar adalah satu hal, dan menciptakan produk yang mudah direplikasi yang akan digunakan untuk berbagai tugas, yang kita sebagai pihak lain, adalah satu hal. vendor, bahkan mungkin tahu tentang diri kita sendiri kita tidak akan. Untuk tujuan kedua, produk open source yang ada tidak cocok untuk kami, jadi kami memutuskan untuk membuat sistem file terdistribusi sendiri.
Dua tahun kemudian, beberapa pengembang (yang menggabungkan pekerjaan pada vAIR dengan pekerjaan pada sistem penyimpanan Engine klasik) mencapai hasil tertentu.
Pada tahun 2018, kami telah menulis sistem file sederhana dan melengkapinya dengan perangkat keras yang diperlukan. Sistem menggabungkan disk fisik (lokal) dari server yang berbeda ke dalam satu kumpulan datar melalui interkoneksi internal dan "memotong" mereka menjadi blok virtual, kemudian perangkat blok dengan berbagai tingkat toleransi kesalahan dibuat dari blok virtual, di mana perangkat virtual dibuat. dan dieksekusi menggunakan mobil hypervisor KVM.
Kami tidak terlalu mempermasalahkan nama sistem file dan secara ringkas menyebutnya ARDFS (coba tebak apa singkatannya))
Prototipe ini terlihat bagus (belum secara visual tentunya belum ada desain visualnya) dan menunjukkan hasil yang baik dari segi performa dan penskalaan. Setelah hasil nyata pertama, kami menjalankan proyek ini, mengorganisir lingkungan pengembangan penuh dan tim terpisah yang hanya menangani vAIR.
Pada saat itu, arsitektur umum dari solusi tersebut telah matang, dan belum mengalami perubahan besar.
Menyelami sistem file ARDFS
ARDFS adalah dasar dari vAIR, yang menyediakan penyimpanan data yang terdistribusi dan toleran terhadap kesalahan di seluruh cluster. Salah satu (tetapi bukan satu-satunya) fitur khas ARDFS adalah ia tidak menggunakan server khusus tambahan untuk metadata dan manajemen. Ini awalnya dirancang untuk menyederhanakan konfigurasi solusi dan keandalannya.
Struktur penyimpanan
Dalam semua node cluster, ARDFS mengatur kumpulan logis dari semua ruang disk yang tersedia. Penting untuk dipahami bahwa kumpulan belum merupakan data atau ruang yang diformat, tetapi hanya markup, yaitu. Setiap node dengan vAIR terinstal, ketika ditambahkan ke cluster, secara otomatis ditambahkan ke kumpulan ARDFS bersama dan sumber daya disk secara otomatis dibagikan ke seluruh cluster (dan tersedia untuk penyimpanan data di masa mendatang). Pendekatan ini memungkinkan Anda untuk menambah dan menghapus node dengan cepat tanpa dampak serius pada sistem yang sudah berjalan. Itu. Sistem ini sangat mudah untuk diskalakan “dalam bentuk bata”, menambahkan atau menghapus node dalam cluster jika perlu.
Disk virtual (objek penyimpanan untuk mesin virtual) ditambahkan di atas kumpulan ARDFS, yang dibuat dari blok virtual berukuran 4 megabita. Disk virtual secara langsung menyimpan data. Skema toleransi kesalahan juga diatur pada tingkat disk virtual.
Seperti yang mungkin sudah Anda duga, untuk toleransi kesalahan pada subsistem disk, kami tidak menggunakan konsep RAID (Redundant array of Independent Disks), tetapi menggunakan RAIN (Redundant Array of Independent Nodes). Itu. Toleransi kesalahan diukur, diotomatisasi, dan dikelola berdasarkan node, bukan disk. Disk, tentu saja, juga merupakan objek penyimpanan, seperti yang lainnya, dipantau, Anda dapat melakukan semua operasi standar dengannya, termasuk merakit RAID perangkat keras lokal, tetapi cluster beroperasi secara khusus pada node.
Dalam situasi di mana Anda benar-benar menginginkan RAID (misalnya, skenario yang mendukung banyak kegagalan pada klaster kecil), tidak ada yang menghalangi Anda untuk menggunakan pengontrol RAID lokal, dan membangun penyimpanan yang diperluas dan arsitektur RAIN di atasnya. Skenario ini cukup aktif dan didukung oleh kami, jadi kami akan membicarakannya di artikel tentang skenario umum penggunaan vAIR.
Skema Toleransi Kesalahan Penyimpanan
Ada dua skema toleransi kesalahan untuk disk virtual di vAIR:
1) Faktor replikasi atau replikasi sederhana - metode toleransi kesalahan ini sesederhana tongkat dan tali. Replikasi sinkron dilakukan antar node dengan faktor 2 (2 salinan per cluster) atau 3 (masing-masing 3 salinan). RF-2 memungkinkan disk virtual untuk menahan kegagalan satu node di cluster, tetapi “memakan” setengah dari volume yang berguna, dan RF-3 akan menahan kegagalan 2 node di cluster, tetapi mencadangkan 2/3 dari volumenya. volume yang berguna untuk kebutuhannya. Skema ini sangat mirip dengan RAID-1, yaitu disk virtual yang dikonfigurasi dalam RF-2 tahan terhadap kegagalan salah satu node di cluster. Dalam hal ini, semuanya akan baik-baik saja dengan data dan bahkan I/O tidak akan berhenti. Ketika node yang terputus kembali berfungsi, pemulihan/sinkronisasi data otomatis akan dimulai.
Di bawah ini adalah contoh sebaran data RF-2 dan RF-3 dalam mode normal dan dalam situasi kegagalan.
Kami memiliki mesin virtual dengan kapasitas 8MB data unik (berguna), yang berjalan pada 4 node vAIR. Jelas bahwa pada kenyataannya kecil kemungkinannya akan ada volume sekecil itu, namun untuk skema yang mencerminkan logika operasi ARDFS, contoh ini adalah yang paling dapat dimengerti. AB adalah blok virtual 4MB yang berisi data mesin virtual unik. RF-2 membuat dua salinan dari blok A1+A2 dan B1+B2 ini. Blok-blok ini “diletakkan” di seluruh node, menghindari perpotongan data yang sama pada node yang sama, yaitu salinan A1 tidak akan ditempatkan pada node yang sama dengan salinan A2. Sama dengan B1 dan B2.
Jika salah satu node gagal (misalnya, node No. 3, yang berisi salinan B1), salinan ini secara otomatis diaktifkan pada node yang tidak memiliki salinan salinannya (yaitu salinan B2).
Dengan demikian, disk virtual (dan VM, karenanya) dapat dengan mudah bertahan dari kegagalan satu node dalam skema RF-2.
Skema replikasi, meskipun sederhana dan dapat diandalkan, mengalami masalah yang sama seperti RAID1 - tidak cukup ruang yang dapat digunakan.
2) Pengkodean penghapusan atau pengkodean penghapusan (juga dikenal sebagai “pengkodean redundan”, “pengkodean penghapusan”, atau “kode redundansi”) ada untuk menyelesaikan masalah di atas. EC adalah skema redundansi yang menyediakan ketersediaan data tinggi dengan overhead ruang disk yang lebih rendah dibandingkan dengan replikasi. Prinsip pengoperasian mekanisme ini mirip dengan RAID 5, 6, 6P.
Saat pengkodean, proses EC membagi blok virtual (4MB secara default) menjadi beberapa "potongan data" yang lebih kecil tergantung pada skema EC (misalnya, skema 2+1 membagi setiap blok 4MB menjadi 2 potongan 2MB). Selanjutnya, proses ini menghasilkan “potongan paritas” untuk “potongan data” yang tidak lebih besar dari salah satu bagian yang dibagi sebelumnya. Saat melakukan decoding, EC menghasilkan potongan yang hilang dengan membaca data “yang bertahan” di seluruh cluster.
Misalnya, disk virtual dengan skema 2+1 EC, yang diimplementasikan pada 4 node cluster, akan dengan mudah menahan kegagalan satu node dalam cluster dengan cara yang sama seperti RF-2. Dalam hal ini, biaya overhead akan lebih rendah, khususnya koefisien kapasitas berguna untuk RF-2 adalah 2, dan untuk EC 2+1 adalah 1,5.
Untuk menggambarkannya lebih sederhana, intinya adalah bahwa blok virtual dibagi menjadi 2-8 (mengapa dari 2 hingga 8, lihat di bawah) "potongan", dan untuk potongan ini "potongan" paritas dengan volume yang sama dihitung.
Hasilnya, data dan paritas didistribusikan secara merata ke seluruh node cluster. Pada saat yang sama, seperti halnya replikasi, ARDFS secara otomatis mendistribusikan data antar node sedemikian rupa untuk mencegah data identik (salinan data dan paritasnya) disimpan pada node yang sama, untuk menghilangkan kemungkinan kehilangan data karena fakta bahwa data dan paritasnya tiba-tiba berakhir di satu node penyimpanan yang gagal.
Di bawah ini contohnya, dengan mesin virtual yang sama sebesar 8 MB dan 4 node, namun dengan skema EC 2+1.
Blok A dan B dibagi menjadi dua bagian masing-masing 2 MB (dua karena 2+1), yaitu A1+A2 dan B1+B2. Berbeda dengan replika, A1 bukanlah salinan dari A2, melainkan blok virtual A yang dibagi menjadi dua bagian, sama dengan blok B. Total kita mendapatkan dua set 4MB yang masing-masing berisi dua buah berukuran dua MB. Selanjutnya untuk masing-masing set ini dihitung paritasnya dengan volume tidak lebih dari satu buah (yaitu 2 MB), kita peroleh tambahan + 2 buah paritas (AP dan BP). Totalnya kita memiliki 4×2 data + 2×2 paritas.
Selanjutnya, potongan-potongan tersebut “diletakkan” di antara node-node sehingga data tidak berpotongan dengan paritasnya. Itu. A1 dan A2 tidak akan berada pada node yang sama dengan AP.
Jika terjadi kegagalan pada satu node (misalnya, juga node ketiga), blok B1 yang jatuh akan secara otomatis dipulihkan dari paritas BP, yang disimpan di node No. 2, dan akan diaktifkan pada node yang ada. tidak ada paritas B, mis. sepotong BP. Dalam contoh ini, ini adalah node No.1
Saya yakin pembaca mempunyai pertanyaan:
“Semua yang Anda jelaskan telah lama diterapkan baik oleh pesaing maupun dalam solusi sumber terbuka, apa perbedaan antara penerapan EC Anda di ARDFS?”
Lalu akan ada fitur menarik dari ARDFS.
Hapus pengkodean dengan fokus pada fleksibilitas
Awalnya, kami menyediakan skema EC X+Y yang cukup fleksibel, di mana X sama dengan angka dari 2 hingga 8, dan Y sama dengan angka dari 1 hingga 8, tetapi selalu kurang dari atau sama dengan X. Skema ini disediakan untuk fleksibilitas. Meningkatkan jumlah potongan data (X) yang menjadi bagian dari blok virtual memungkinkan pengurangan biaya overhead, yaitu meningkatkan ruang yang dapat digunakan.
Meningkatkan jumlah potongan paritas (Y) akan meningkatkan keandalan disk virtual. Semakin besar nilai Y, semakin banyak node dalam cluster yang bisa gagal. Tentu saja, meningkatkan volume paritas akan mengurangi jumlah kapasitas yang dapat digunakan, namun ini adalah harga yang harus dibayar untuk keandalan.
Ketergantungan kinerja pada sirkuit EC hampir bersifat langsung: semakin banyak “bagian”, semakin rendah kinerjanya; di sini, tentu saja, diperlukan pandangan yang seimbang.
Pendekatan ini memungkinkan administrator untuk mengonfigurasi penyimpanan yang diperluas dengan fleksibilitas maksimum. Di dalam kumpulan ARDFS, Anda dapat menggunakan skema toleransi kesalahan apa pun dan kombinasinya, yang menurut kami juga sangat berguna.
Di bawah ini adalah tabel yang membandingkan beberapa (tidak semua kemungkinan) skema RF dan EC.
Tabel tersebut menunjukkan bahwa bahkan kombinasi paling “terry” EC 8+7, yang memungkinkan hilangnya hingga 7 node dalam sebuah cluster secara bersamaan, “memakan” lebih sedikit ruang yang dapat digunakan (1,875 berbanding 2) dibandingkan replikasi standar, dan melindungi 7 kali lebih baik , yang menjadikan mekanisme perlindungan ini, meskipun lebih kompleks, jauh lebih menarik dalam situasi di mana perlu untuk memastikan keandalan maksimum dalam kondisi ruang disk terbatas. Pada saat yang sama, Anda perlu memahami bahwa setiap “plus” pada X atau Y akan menjadi tambahan kinerja, jadi dalam segitiga antara keandalan, penghematan, dan kinerja, Anda harus memilih dengan sangat hati-hati. Untuk alasan ini, kami akan menyediakan artikel terpisah untuk menghapus ukuran pengkodean.
Keandalan dan otonomi sistem file
ARDFS berjalan secara lokal di semua node cluster dan menyinkronkannya menggunakan sarananya sendiri melalui antarmuka Ethernet khusus. Poin pentingnya adalah ARDFS secara independen menyinkronkan tidak hanya data, tetapi juga metadata terkait penyimpanan. Saat mengerjakan ARDFS, kami secara bersamaan mempelajari sejumlah solusi yang ada dan kami menemukan bahwa banyak yang menyinkronkan meta sistem file menggunakan DBMS terdistribusi eksternal, yang juga kami gunakan untuk sinkronisasi, tetapi hanya konfigurasi, bukan metadata FS (tentang ini dan subsistem terkait lainnya di artikel selanjutnya).
Menyinkronkan metadata FS menggunakan DBMS eksternal, tentu saja, merupakan solusi yang berfungsi, tetapi konsistensi data yang disimpan di ARDFS akan bergantung pada DBMS eksternal dan perilakunya (dan, sejujurnya, ini adalah wanita yang berubah-ubah), yang dalam pendapat kami buruk. Mengapa? Jika metadata FS rusak, data FS itu sendiri juga bisa dikatakan “selamat tinggal”, jadi kami memutuskan untuk mengambil jalur yang lebih kompleks namun dapat diandalkan.
Kami membuat sendiri subsistem sinkronisasi metadata untuk ARDFS, dan subsistem tersebut hidup sepenuhnya independen dari subsistem yang berdekatan. Itu. tidak ada subsistem lain yang dapat merusak data ARDFS. Menurut pendapat kami, ini adalah cara yang paling dapat diandalkan dan benar, tetapi waktu akan membuktikan apakah memang demikian. Selain itu, ada keuntungan tambahan dari pendekatan ini. ARDFS dapat digunakan secara terpisah dari vAIR, sama seperti penyimpanan yang diperluas, yang pasti akan kami gunakan pada produk masa depan.
Hasilnya, dengan mengembangkan ARDFS, kami menerima sistem file yang fleksibel dan andal yang memberikan pilihan di mana Anda dapat menghemat kapasitas atau menyerahkan segalanya pada performa, atau membuat penyimpanan yang sangat andal dengan biaya yang wajar, namun mengurangi persyaratan performa.
Ditambah dengan kebijakan lisensi yang sederhana dan model pengiriman yang fleksibel (di masa depan, vAIR dilisensikan oleh node, dan dikirimkan sebagai perangkat lunak atau sebagai paket perangkat lunak), hal ini memungkinkan Anda untuk secara tepat menyesuaikan solusi terhadap berbagai macam kebutuhan pelanggan dan lalu dengan mudah menjaga keseimbangan ini.
Siapa yang butuh keajaiban ini?
Di satu sisi, kami dapat mengatakan bahwa sudah ada pemain di pasar yang memiliki solusi serius di bidang hiperkonvergensi, dan inilah tujuan sebenarnya kami. Sepertinya pernyataan ini ada benarnya, TAPI...
Di sisi lain, ketika kami pergi ke lapangan dan berkomunikasi dengan pelanggan, kami dan mitra kami melihat bahwa hal tersebut tidak terjadi. Ada banyak tugas untuk hiperkonvergensi, di beberapa tempat orang tidak tahu bahwa solusi tersebut ada, di tempat lain tampaknya mahal, di tempat lain pengujian solusi alternatif tidak berhasil, dan di tempat lain mereka melarang pembelian sama sekali karena sanksi. Secara umum, ladang tersebut ternyata belum dibajak, jadi kami pergi untuk menanam tanah perawan))).
Kapan sistem penyimpanan lebih baik dari GCS?
Saat kami bekerja dengan pasar, kami sering ditanya kapan lebih baik menggunakan skema klasik dengan sistem penyimpanan, dan kapan menggunakan hyperconvergent? Banyak perusahaan yang memproduksi GCS (terutama yang tidak memiliki sistem penyimpanan dalam portofolionya) mengatakan: “Sistem penyimpanan sudah ketinggalan zaman, hanya hiperkonvergensi!” Ini adalah pernyataan yang berani, namun tidak sepenuhnya mencerminkan kenyataan.
Sebenarnya, pasar penyimpanan memang bergerak menuju hiperkonvergensi dan solusi serupa, namun selalu ada “tetapi”.
Pertama, pusat data dan infrastruktur TI yang dibangun sesuai skema klasik dengan sistem penyimpanan tidak dapat dibangun kembali dengan mudah, sehingga modernisasi dan penyelesaian infrastruktur tersebut masih menjadi warisan selama 5-7 tahun.
Kedua, infrastruktur yang saat ini sedang dibangun sebagian besar (yaitu Federasi Rusia) dibangun sesuai dengan skema klasik menggunakan sistem penyimpanan, dan bukan karena masyarakat tidak tahu tentang hiperkonvergensi, tetapi karena pasar hiperkonvergensi adalah hal baru, solusi dan standar belum ditetapkan, staf TI belum terlatih, mereka memiliki sedikit pengalaman, namun mereka perlu membangun pusat data di sini dan saat ini. Dan tren ini akan bertahan selama 3-5 tahun ke depan (dan kemudian warisan lainnya, lihat poin 1).
Ketiga, ada batasan teknis murni dalam penundaan kecil tambahan sebesar 2 milidetik per penulisan (tidak termasuk cache lokal, tentu saja), yang merupakan biaya penyimpanan terdistribusi.
Baiklah, jangan lupakan penggunaan server fisik besar yang menyukai penskalaan vertikal subsistem disk.
Ada banyak tugas penting dan populer di mana sistem penyimpanan berperilaku lebih baik daripada GCS. Di sini, tentu saja, produsen yang tidak memiliki sistem penyimpanan dalam portofolio produknya tidak akan setuju dengan kami, tetapi kami siap untuk berdebat secara wajar. Tentu saja, kami, sebagai pengembang kedua produk, pasti akan membandingkan sistem penyimpanan dan GCS di salah satu publikasi kami yang akan datang, di mana kami akan menunjukkan dengan jelas mana yang lebih baik dalam kondisi apa.
Dan di manakah solusi hyperconverged akan bekerja lebih baik dibandingkan sistem penyimpanan?
Berdasarkan poin-poin di atas, ada tiga kesimpulan yang jelas dapat ditarik:
- Jika latensi tambahan 2 milidetik untuk perekaman, yang secara konsisten terjadi pada produk apa pun (sekarang kita tidak berbicara tentang sintetis, nanodetik dapat ditampilkan pada sintetis), tidak kritis, hiperkonvergen cocok.
- Jika beban dari server fisik besar dapat diubah menjadi banyak server virtual kecil dan didistribusikan antar node, hiperkonvergensi juga akan bekerja dengan baik di sana.
- Jika penskalaan horizontal lebih diprioritaskan dibandingkan penskalaan vertikal, GCS juga akan berfungsi dengan baik di sana.
Apa solusinya?
- Semua layanan infrastruktur standar (layanan direktori, mail, EDMS, server file, sistem ERP dan BI kecil atau menengah, dll.). Kami menyebutnya “komputasi umum”.
- Infrastruktur penyedia cloud, yang memerlukan perluasan horizontal secara cepat dan terstandarisasi serta dengan mudah “memotong” sejumlah besar mesin virtual untuk klien.
- Infrastruktur desktop virtual (VDI), tempat banyak mesin virtual pengguna kecil berjalan dan diam-diam “mengambang” dalam cluster yang seragam.
- Jaringan cabang, di mana setiap cabang memerlukan infrastruktur standar, toleran kesalahan, namun murah yang terdiri dari 15-20 mesin virtual.
- Komputasi terdistribusi apa pun (layanan data besar, misalnya). Dimana bebannya tidak “dalam”, tetapi “luasnya”.
- Lingkungan pengujian di mana penundaan kecil tambahan dapat diterima, namun terdapat batasan anggaran, karena ini adalah pengujian.
Saat ini, untuk tugas-tugas inilah kami membuat AERODISK vAIR dan kami fokus pada tugas-tugas tersebut (sejauh ini berhasil). Mungkin ini akan segera berubah, karena... dunia tidak tinggal diam.
Begitu…
Ini melengkapi bagian pertama dari serangkaian besar artikel; pada artikel berikutnya kita akan membahas tentang arsitektur solusi dan komponen yang digunakan.
Kami menyambut pertanyaan, saran, dan perselisihan konstruktif.
Sumber: www.habr.com