Persyaratan komputasi algoritma telah meningkat secara signifikan selama dua dekade terakhir. Secara khusus, algoritme pembelajaran mesin (ML) mengalami pertumbuhan permintaan sumber daya komputasi yang melebihi Hukum Moore. Meskipun Hukum Moore memperkirakan kekuatan pemrosesan akan meningkat dua kali lipat setiap dua tahun, sejak tahun 2012, algoritme ML telah menggandakan tuntutan komputasinya setiap 3 hingga 4 bulan (“AI and Compute,” 2018).

Akibatnya, menjalankan algoritma ini pada satu komputer hampir tidak mungkin atau sangat mahal. Pendekatan yang lebih praktis adalah dengan memecah algoritme ini menjadi bagian-bagian yang lebih kecil dan kemudian menggunakan banyak komputer standar untuk menjalankan bagian-bagian yang lebih kecil tersebut. Untuk mengilustrasikannya, bayangkan kita sedang melatih model pembelajaran mesin pada kumpulan data yang berisi 1 juta entri. Daripada menggunakan satu komputer untuk memproses seluruh kumpulan data, kita dapat membaginya menjadi 10 blok yang masing-masing berisi 100.000 entri. Kami kemudian akan menggunakan 10 komputer, masing-masing menjalankan algoritma pelatihan pada subset 100.000 input. (Catatan:Demi kesederhanaan, saya menghilangkan langkah menggabungkan hasil dari mesin ini, karena ini berada di luar cakupan artikel ini.)

Gambar dipinjam dari “AI dan perhitungan”, 2018

Menggunakan banyak komputer untuk menjalankan satu algoritma atau aplikasi adalah hal yang umum saat ini. Saat ini, pasar memiliki banyak penyedia cloud yang memiliki mesin hosting pusat data yang berkisar antara beberapa ribu hingga beberapa juta. Hal ini membuatnya lebih mudah diakses oleh pengembang untuk membuat dan menjalankan aplikasi dan algoritma komputasi intensif ini.

Sebagian besar bisnis kini menjalankan sebagian atau seluruh beban kerja, layanan, dan aplikasinya di cloud. Jadi, semua pengembang diharuskan untuk menulis algoritma dan aplikasi cloud-native. Karena pusat data mendukung cloud, penting bagi pengembang untuk memahami arsitektur dasar pusat data (cloud) ini untuk menciptakan aplikasi cloud native yang efektif dan efisien.

Mengapa pindah ke cloud asli?

Mari kita ambil contoh sebuah perusahaan perangkat lunak yang mengembangkan perangkat lunak untuk membantu kliennya mengajukan pajak. Perusahaan menawarkan dua format pengiriman: 1) compact disc (CD) dan 2) versi online. Seminggu setelah peluncuran, banyak pelanggan membeli perangkat lunak dalam kedua format tersebut. Untuk mempermudah, mari kita asumsikan bahwa perangkat lunak yang diinstal melalui CD berjalan sepenuhnya di komputer pelanggan tanpa konektivitas Internet.

Skenario 1: Bug pada perangkat lunak

Misalkan perusahaan menemukan bug pada perangkat lunak yang perlu diperbaiki. Memperbaiki versi online itu mudah karena perusahaan mengontrol penerapan dan pelaksanaannya. Namun, perusahaan tidak memiliki kendali atas versi mana yang diinstal pada CD di komputer pelanggan, sehingga sulit untuk mendistribusikan patch ke pengguna offline.

Skenario 2: Bug di komputer pelanggan

Sekarang mari kita bayangkan perangkat lunak tersebut berfungsi dengan benar di semua komputer kecuali komputer dengan kombinasi model prosesor dan versi sistem operasi tertentu. Untuk pelanggan offline dengan konfigurasi perangkat keras ini, perangkat lunaknya mungkin gagal, sedangkan versi online, yang kemungkinan berjalan di cloud, tetap berfungsi dengan baik untuk semua pengguna. Menguji perangkat lunak pada semua kemungkinan kombinasi perangkat keras dan sistem operasi merupakan tantangan kompleks untuk aplikasi offline.

Dalam kedua skenario tersebut, perusahaan memiliki waktu yang jauh lebih mudah untuk memberikan pengalaman yang lancar dan bebas bug kepada pengguna versi online. Inilah salah satu alasan utama peralihan ke aplikasi cloud-native: aplikasi ini memberi pengembang kontrol lebih besar terhadap lingkungan perangkat lunak. Namun, pengembangan di domain cloud native juga memerlukan pemahaman tentang infrastruktur cloud.

Menurut Laporan Pakar Voice of Kubernetes tahun 2024, 80% organisasi memperkirakan sebagian besar aplikasi baru mereka akan dibangun di platform cloud-native dalam lima tahun ke depan.

Komponen Penting Pusat Data

Pada tingkat yang sangat tinggi, pusat data adalah kumpulan dari beberapa komputer individual. Pelanggan dapat menggunakan beberapa komputer ini untuk menjalankan beban kerja mereka. Tiga komponen kunci dari pusat data adalah:

1. Server
2. Penyimpanan
3. Jaringan

Mari selami lebih dalam.

1. Server

Ini adalah komputer dengan satu atau lebih inti. Jumlah inti dalam komputer menentukan kapasitas komputasinya. Misalnya, jika komputer Anda hanya memiliki satu inti, komputer hanya dapat melakukan satu tugas dalam satu waktu. Namun, jika memiliki dua inti, ia dapat menangani dua tugas secara bersamaan.

Beberapa server ditumpuk untuk membentuk rak. Semua server di rak terhubung menggunakan saklar tingkat lokal. Beberapa rak dihubungkan menggunakan saklar tingkat pusat data. Kami akan membahas switch secara lebih rinci di bagian jaringan. Pusat data dapat menampung ribuan atau bahkan jutaan inti, bergantung pada ukurannya.

Server Tunggal vs Rak Server

2. Penyimpanan

Komponen ini menyediakan kapasitas penyimpanan data ke mesin di pusat data. Penyimpanan dapat terhubung langsung ke server atau terhubung secara jarak jauh ke server. Mengakses penyimpanan dari server memiliki latensi lebih rendah dalam mode koneksi langsung karena komunikasi antar server memerlukan bandwidth jaringan yang lebih sedikit. Sebaliknya, penyimpanan yang terhubung dari jarak jauh lebih mudah dikelola dan berpotensi digunakan bersama oleh beberapa server. Pada saat yang sama, hal ini juga memerlukan bandwidth jaringan yang lebih tinggi untuk komunikasi server-ke-penyimpanan.

Penyimpanan yang terpasang langsung atau terhubung dari jarak jauh

3. Jaringan

Ada dua tingkat koneksi jaringan di pusat data. Yang pertama adalah koneksi intra-rak yang menghubungkan semua server dalam satu rak. Yang kedua adalah koneksi antar rak yang menghubungkan rak yang berbeda. Koneksi ini dibuat menggunakan perangkat keras yang disebut switch jaringan. Ini adalah perangkat yang merutekan data dari sumber ke tujuan. Setiap switch memiliki batas atas jumlah server yang dapat dihubungkan. Sakelar dasar lebih murah namun memiliki kapasitas terbatas, sedangkan sakelar kelas atas dapat menangani beban lebih besar namun mahal. Arsitek pusat data sering kali menyeimbangkan kinerja dan biaya dengan menggunakan kombinasi kedua jenis sakelar.

Sebagai contoh, katakanlah kita memiliki rak yang terdiri dari 40 server dan switch jaringan standar dengan 48 port. Kita dapat menggunakan switch jaringan ini untuk menghubungkan seluruh 40 server ke switch di pusat data menggunakan 8 port yang tersisa sebagai uplink. Dengan kata lain, 1 port uplink mengatur beban 5 server di rak. Hal ini akan berdampak pada kinerja konektivitas uplink karena situasi ideal adalah menggunakan 1 port uplink per server, menggunakan switch jaringan 80 port yang mahal. Keseimbangan antara optimalisasi biaya dan kinerja sangat penting dalam desain pusat data.

Konektivitas Intra-Rak vs. Antar-Rak

Faktor Lain dalam Desain Pusat Data

Selain itu, pusat data juga perlu mengelola gedung dan infrastruktur, konsumsi daya, cadangan daya, pemeliharaan, perbaikan, dan penanganan kegagalan perangkat keras. Semua elemen ini penting untuk kelancaran operasi.

Kesimpulan

Aplikasi dan algoritme modern sering kali mendistribusikan beban kerjanya ke banyak komputer individual. Pusat data menyediakan kapasitas ini dengan menciptakan ribuan komputer. Meskipun pengaturan ini memberikan paralelisasi yang sangat besar, hal ini juga memerlukan penanganan kegagalan masing-masing komponen dan menanganinya dengan baik untuk memastikan kinerja yang lancar. Ketika industri terus beralih ke aplikasi cloud-native, pemahaman arsitektur pusat data akan menjadi semakin penting bagi pengembang.