Pola yang teruji dengan baik untuk mem-build backend game online menggunakan database relasional, seperti MySQL. Database ini menyimpan status dunia game dan data persistensi penting. Untuk game berbasis sesi dasar, database tidak ada yang lebih rumit daripada hasil akhir pertandingan. Untuk game online multiplayer berskala besar (MMO), persisten, dan berukuran besar, mungkin sekumpulan tabel yang saling terkait sangat rumit yang menyimpan progres dan inventaris pemain. Kecepatan kueri di lapisan database backend Anda secara langsung memengaruhi pengalaman respons pengguna di klien game.
Meskipun pola ini sudah umum, sebagian besar tim pengembangan game tidak memiliki administrator database khusus, dan seiring bertambahnya ukuran database dan hubungan yang dimodelkan akan semakin kompleks, administrasi dapat menjadi tugas yang akan lebih disukai oleh banyak tim. Untuk game seluler berbasis giliran asinkron yang berukuran kecil hingga sedang, database seperti Google Cloud SQL dapat menjadi pilihan yang sangat baik. Cloud SQL untuk MySQL Generasi Kedua menawarkan instance MySQL yang dihosting dan terkelola sepenuhnya dengan performa yang mantap, operasi minimal, dan pencadangan otomatis.
Desain pola database yang berorientasi layanan
Paradigma microservice berguna untuk backend database game seluler. Desain yang umum adalah database berada di depan oleh layanan database, yang dibentuk oleh kumpulan proses pekerja yang menerima permintaan kueri dari frontend game, menjalankan kueri tersebut terhadap database, dan mengembalikan hasilnya.
Keuntungan pola database berorientasi layanan
Memiliki layanan perantara membuat kueri database atas nama server game memiliki beberapa keuntungan:
- Peningkatan ketersediaan — Database sering kali membatasi jumlah koneksi serentak. Penggunaan layanan akan memisahkan jumlah server game yang dapat membuat permintaan ke database dari koneksi maksimum yang diizinkan.
- Toleransi kesalahan — Layanan database dapat di-build untuk memproses permintaan untuk sementara jika database mengalami masalah.
- Permintaan yang dioptimalkan — Layanan database dapat mengoptimalkan permintaan
database, yang menyediakan:
- Validasi kueri.
- Prioritas kueri.
- Kontrol alur rasio kueri.
- Cache dalam memori dan dibaca.
- Abstraksi database — Selama kontrak layanan terpenuhi, layanan database dan database yang mendukungnya dapat diganti tanpa modifikasi pada server game frontend. Desain ini memungkinkan penggunaan database yang berbeda dalam lingkungan pengembangan atau UM (Uji Mutu), atau bermigrasi ke teknologi database yang berbeda dalam produksi.
Pola database berorientasi layanan untuk game
Diagram berikut menggambarkan cara membuat pola database berorientasi layanan terdepan yang andal menggunakan layanan Google Cloud Platform.
Pola database yang canggih dan berorientasi layanan dapat dibuat menggunakan komponen berikut:
Server/frontend game khusus — Aplikasi klien game terhubung langsung ke server game, sehingga menjadikannya layanan frontend. Server game khusus biasanya berupa file yang dapat dieksekusi kustom, yang dibangun dengan game engine, yang harus berjalan pada hardware tervirtualisasi seperti VM Google Compute Engine. Jika Anda menulis game yang mana interaksi online dapat dimodelkan dengan semantik permintaan/respons gaya HTTP, Google App Engine juga cocok untuk itu.
Komunikasi server game dengan layanan database — Cara ini sering dimodelkan menggunakan gaya akses membuat, membaca, memperbarui, dan menghapus (CRUD), jadikan endpoint REST API atau gRPC di Compute Engine sebagai pilihan tepat.
Komunikasi endpoint API/RPC ke kumpulan pekerja database — Kasus klasik untuk antrean dan pilihan populer adalah middleware pengantrean secara open source, dan dikelola sendiri seperti RabbitMQ atau ZeroMQ. Di Cloud Platform, Anda dapat menggunakan Google Cloud Pub/Sub yang aman, andal, dan sangat tersedia. Layanan ini menawarkan solusi antrean terkelola tanpa perlu mengelola server.
Pekerja database yang terhubung ke Cloud SQL Generasi Kedua — Pekerja database dapat ditulis dalam bahasa apa pun yang menyediakan metode akses MySQL terbaru. Para pekerja ini dapat dikelola secara manual di Compute Engine, atau dikemas dalam container Docker agar mudah dikelola menggunakan DSL Kubernetes di Google Kubernetes Engine.
Ada beberapa batasan yang perlu dipertimbangkan saat menggunakan Cloud SQL Generasi Kedua:
- Batas ukuran database sebesar 10 TB.
- Batas koneksi 4.000 koneksi serentak.
- Kurangnya dukungan NDB (sharding), meskipun replika didukung.
Untuk menangani item ini:
Pilih model data yang mengoptimalkan jumlah data yang disimpan.
Gabungkan proses yang memindahkan data yang jarang diakses dari database utama dan ke dalam data warehouse, misalnya Google BigQuery.
Gunakan pola dengan server game mengakses database melalui microservice. Meskipun jumlah pemain cukup sedikit sehingga server game Anda dapat mengakses database secara langsung, ada banyak keuntungan memisahkan lapisan database dari server game: antrean, leveling tingkat kueri, kegagalan koneksi toleransi, dan sebagainya. Selain itu, mencoba menambahkan lapisan akses database terpisah setelah game Anda menjadi populer dapat menyebabkan periode nonaktif dan hilangnya pendapatan.
Jalankan analisis game dan telemetri pemain terhadap replika hanya baca database. Hal ini mencegah analisis Anda memengaruhi responsivitas database. Cloud SQL untuk MySQL Generasi Kedua memungkinkan replikasi MySQL standar, dan Anda dapat menyesuaikan ukuran instance kedua dengan tepat untuk kueri analisis guna menghemat biaya.
Contoh desain: Game massively single-player social (MASS)
Salah satu paradigma game yang muncul dalam satu dekade terakhir terdiri dari sejumlah besar pemain tunggal secara bersamaan bermain sesi online, dengan mekanisme sosial seperti meminjam unit, perdagangan unit, dan papan peringkat menjadi satu-satunya titik kontak antara pemain. Contoh game MASS meliputi Puzzle and DragonsTM dan Monster StrikeTM. Game seluler MASS dibangun untuk ekonomi dengan komunikasi klien/server. Hal ini memungkinkan pengguna menikmati game meskipun dengan konektivitas terbatas atau sporadis. Model data untuk game seperti ini, dengan hampir semua penyimpanan status persisten terkait dengan meta-game (mengumpulkan unit dan mempertahankan mata uang pemain), menghasilkan dua jenis dasar objek untuk disimpan di database. Objek ini dapat dengan mudah dimanipulasi menggunakan mekanisme CRUD.
Objek Pemutar, yang melacak:
- Game dan mata uang asli.
- Jumlah total slot inventaris unit.
- Stamina.
- Pengalaman.
Objek Unit, yang melacak:
- Pemilik (ID pemain).
- Pengalaman.
- Biaya akuisisi.
- Inventaris unit.
Untuk jumlah pemain yang kurang dari 100.000, model data ini sangat cocok dengan database relasional seperti Cloud SQL Generasi Kedua.
Mimus
Mimus adalah aplikasi game seluler tiruan MASS dengan backend bergaya Puzzle and Dragons™ atau Monster Strike™. Hal ini mengasumsikan bahwa setiap pemain hanya dapat login dari satu perangkat pada satu waktu, dan mereka harus menyelesaikan tindakan apa pun sebelum memulai tindakan lainnya. Dengan Mimus, Anda dapat menjalankan simulasi beban kerja untuk mengevaluasi kapasitas optimal arsitektur, yang biasanya didasarkan pada jumlah pengguna serentak (CCU).
Anda dapat menemukan kode sumber Mimus di https://github.com/GoogleCloudPlatform/mimus-game-simulator.
Simulasi klien Mimus dalam server Mimus
Dalam game MASS, kecepatan klien game menghasilkan kueri database
dapat dikontrol oleh developer game dengan mengharuskan pemain untuk melihat
animasi dan berinteraksi dengan klien game untuk melanjutkan. Mimus menyimulasikan
strategi pembatasan kapasitas ini dengan panggilan sleep(). Dengan cara ini, Mimus
menyimulasikan perkiraan pemuatan database per klien yang wajar dengan menjalankan
proses sebanyak pemain yang disimulasikan. Ini dirancang secara efisien
menggunakan pod klien/server Mimus dalam container, dalam cluster Kubernetes, yang
menghasilkan kueri terhadap database.
Klien game Mimus menyimulasikan komunikasi dengan server backend menggunakan loop berkelanjutan yang memanggil prosedur server Mimus secara langsung, dan memilih panggilan fungsi berdasarkan status pemain dan inventarisnya.
Tindakan pemain yang disimulasikan oleh Mimus meliputi:
- Bermain game tanpa henti.
- Pembelian mata uang.
- Membelanjakan mata uang.
- Unit naik atau turun level.
Setiap tindakan ini diimplementasikan sebagai beberapa interaksi CRUD dengan objek unit atau pemutar, yang dimanipulasi oleh klien melalui panggilan ke server Mimus. Server Mimus membuat permintaan database ini menggunakan API database Mimus (pemblokiran) sinkron. API ini adalah modul Python yang diimpor oleh server Mimus, dan dapat dikonfigurasi untuk menguji berbagai implementasi backend database.
Komunikasi API database Mimus dengan kumpulan pekerja database Mimus
Diagram berikut menggambarkan komunikasi antara server Mimus dan layanan database.
Mimus database API menerima batch kueri database dan menampilkan
hasilnya. Cloud Pub/Sub memublikasikan batch ini sebagai pesan Cloud Pub/Sub dan menunggu hasilnya
ditampilkan melalui Redis. Sebelum mengirim pesan, API
database memvalidasi semua nilai yang akan ditulis ke database dan
memberi tag pada pesan tersebut dengan ID transaksi yang unik. Pesan kemudian dipublikasikan
ke topik Work di Cloud Pub/Sub. Selanjutnya, API database melakukan loop, yang memeriksa
keberadaan ID transaksi sebagai kunci Redis. Hasil dalam nilai kunci
tersebut kemudian diambil oleh API database dan ditampilkan ke server Mimus,
yang kemudian akan disediakan untuk klien Mimus.
Pertimbangan pemilihan komunikasi
Mimus menggunakan Cloud Pub/Sub untuk komunikasi kueri yang tertunda, karena tindakan pengguna memerlukan ketahanan dan pengiriman yang andal. Mimus menggunakan Redis untuk mengomunikasikan hasil, yang mengutamakan ketahanan dan keandalan. Jika hasilnya hilang karena error aplikasi atau kegagalan Redis, Mimus Client akan mengajukan kueri lagi untuk mendapatkan hasil akhir dari database. Dengan menggunakan transaksi dalam database relasional, Anda dijamin bahwa semua perubahan yang diminta benar-benar terjadi, atau tidak sama sekali. Kasus langka Mimus yang perlu membuat permintaan kedua dianggap sebagai kompromi yang dapat diterima sebagai imbalan atas kesederhanaan dan kecepatan pengambilan yang disediakan oleh Redis. Agar penggunaan Redis tetap wajar, hasil permintaan diizinkan agar tidak berlaku lagi dari Redis setelah tiga puluh detik.
Kumpulan pekerja database Mimus
Kumpulan pekerja database Mimus berisi beberapa proses yang berjalan di
Kubernetes Engine. Setiap instance container yang berjalan melakukan polling
topik Cloud Pub/Sub Work dalam loop tanpa akhir untuk pesan baru. Saat menerima
pesan, kueri akan dijalankan dalam pesan menggunakan modul Python MySQLdb.
Satu pesan mewakili transaksi relasional dan dapat berisi beberapa
kueri. Semua kueri dalam pesan harus diselesaikan sebelum di-commit
ke database. Setelah kueri selesai (atau gagal), pekerja
database akan memublikasikan hasilnya ke Redis dengan ID transaksi yang diterima sebagai
bagian dari pesan asli.
Database Mimus
Database relasional yang mendukung layanan database Mimus adalah instance Cloud SQL untuk MySQL Generasi Kedua. Saat membuat instance, Anda dapat memilih konfigurasi mesin yang terdiri dari maksimal 32 core dan RAM 208 GB, dengan ukuran disk hingga 10 TB. Selain memiliki dukungan untuk replika, instance Cloud SQL Generasi Kedua dikonfigurasi untuk menjalankan pencadangan reguler secara default. Jika memerlukan penyesuaian MySQL tambahan, Anda dapat menetapkan flag MySQL pada instance Cloud SQL tertentu. Anda dapat menemukan informasi selengkapnya tentang konfigurasi di dokumentasi Cloud SQL.
Kesimpulan dari pengujian Cloud SQL menggunakan Mimus
| Jenis mesin Cloud SQL SG | Jumlah pengguna serentak yang disarankan |
|---|---|
| n1-standard-4 | 15.000 |
| n1-standard-8 | 30.000 |
| n1-standard-16 | 60.000 |
| n1-standard-32 | 120.000 |
| n1-highmem-8 | 50.000 |
| n1-highmem-16 | 100.000 |
| n1-highmem-32 | 200.000 |
Saat menggunakan tes otomatis Mimus untuk menyimulasikan 100.000 pengguna serentak terhadap instance Cloud SQL untuk MySQL Generasi Kedua yang dibuat pada instance Compute Engine n1-highmem-16, waktu respons kueri tetap di bawah 2 detik selama pengujian.
Jika Anda mem-build game seluler MASS dan perlu mendukung ratusan ribu pemain serentak, pola database yang berfokus pada layanan berdasarkan Cloud SQL untuk MySQL Generasi Kedua dapat memberikan performa yang diperlukan. Saat game Anda semakin populer, Anda dapat memperkenalkan instance Cloud SQL tambahan, baik dengan sharding maupun sebagai replika, dan strategi caching Redis atau Memcached pada tingkat layanan database untuk mempertahankan performa pada tingkat yang dapat diterima.
Untuk game dengan proyeksi pengguna serentak yang lebih sedikit, Anda dapat menggunakan jenis mesin yang lebih kecil untuk mengurangi biaya.
Untuk game dengan proyeksi CCU dalam jutaan pengguna, Anda harus mempertimbangkan database NoSQL, seperti Google Cloud Datastore atau Google Cloud Bigtable, dengan karakteristik skalabilitas dan performa yang kuat.
Langkah selanjutnya
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.