Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

GAMEOPS03-BP04 Mengadopsi strategi penyebaran yang meminimalkan dampak bagi pemain

Gabungkan strategi penyebaran untuk perangkat lunak dan infrastruktur game Anda yang meminimalkan jumlah waktu henti yang membuat pemain keluar dari permainan Anda. Meskipun jenis pembaruan tertentu mungkin memerlukan pemasangan pembaruan baru ke klien game, rancang game untuk meminimalkan atau menghindari kebutuhan waktu henti selama penerapan.

Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi

Panduan implementasi

Salah satu langkah paling penting untuk dipertimbangkan ketika mengembangkan strategi penyebaran game adalah menentukan bagaimana infrastruktur game Anda akan dikelola. Kelola infrastruktur game Anda menggunakan alat infrastruktur sebagai kode (IAc) seperti AWS CloudFormationatau Terraform by Hashicorp untuk mengurangi kesalahan manusia selama persiapan lingkungan. Template infrastruktur dapat digunakan dan diuji dalam jaringan pipa otomatis, yang menciptakan konsistensi dalam konfigurasi lingkungan permainan yang berbeda.

Ada beberapa strategi penyebaran yang dapat digunakan untuk permainan:

Substitusi bergulir

Tujuan utama dari substitusi bergulir untuk penyebaran adalah untuk melakukan rilis tanpa mematikan permainan dan tanpa mempengaruhi pemain. Penting bahwa peningkatan atau perubahan yang akan dilakukan kompatibel ke belakang dan akan bekerja berdekatan dengan versi sistem sebelumnya.

Dalam penerapan ini, instance server diganti secara bertahap (diganti atau diluncurkan) dengan instance yang menjalankan versi yang diperbarui. Substitusi bergulir ini dapat dilakukan dengan beberapa cara berbeda. Misalnya, untuk menerapkan pembaruan bergulir ke armada server game khusus, pendekatan tipikal melibatkan pembuatan grup EC2 instance Auto Scaling baru yang berisi versi build server game baru yang diterapkan ke dalamnya, dan kemudian secara bertahap merutekan pemain ke sesi game yang dihosting di armada server baru ini. Jika ada pembaruan klien game terkait yang diperlukan sebagai prasyarat untuk menggunakan build server game baru, maka Anda harus menyertakan pemeriksaan validasi untuk memverifikasi bahwa hanya pemain yang menginstal pembaruan klien game baru ini yang diarahkan ke sesi game ini.

Armada server (misalnya, grup EC2 Auto Scaling) yang berisi versi build server game lama hanya dihapus dari layanan setelah sesi pemain aktif habis dengan cara yang anggun, biasanya dengan menyiapkan metrik server individual yang memungkinkan tim operasi game untuk mengotomatiskan proses ini. Atau, untuk mengurangi jumlah infrastruktur dan waktu untuk melakukan penyebaran bergulir, pendekatan alternatif dapat dilakukan di mana instance produksi yang ada dihapus dari layanan, diperbarui dengan build server game baru, dan kemudian ditempatkan kembali ke armada produksi. Pendekatan ini mengurangi jumlah infrastruktur yang diperlukan, tetapi juga meningkatkan risiko karena jumlah server game langsung yang tersedia untuk pemain berkurang saat server diganti.

Model ini juga dapat digunakan untuk melakukan penerapan bergulir ke layanan backend seperti database, cache, dan server aplikasi yang tidak menghosting gameplay. Selama layanan ini digunakan dengan cara yang sangat tersedia dengan beberapa instance berkerumun, maka kompleksitas penerapan ke layanan ini harus kurang dari penerapan ke server game khusus.

Penerapan biru/hijau

Tujuan utama blue/green penerapan dalam game adalah untuk meminimalkan waktu henti sementara juga memungkinkan rollback yang aman ke penerapan sebelumnya jika masalah diidentifikasi. Sangat cocok untuk penerapan di mana dua versi backend game kompatibel dan dapat melayani pemain secara bersamaan.

Dalam strategi blue/green penyebaran, dua lingkungan identik (biru dan hijau) diatur. Versi game yang ada diberi label biru, sedangkan versi game baru yang merupakan target penyebaran diberi label hijau. Ketika lingkungan hijau siap untuk migrasi, Anda dapat mengonfigurasi lapisan perutean Anda untuk membalikkan lalu lintas ke lingkungan hijau sambil menjaga lingkungan lama (biru) tersedia jika failback diperlukan. Dalam skenario ini, pembaruan perutean mungkin memerlukan pembaruan layanan perjodohan untuk mengonfigurasinya agar mulai mengirim sesi game ke armada baru, atau dalam kasus layanan backend game, ini bisa memperbarui catatan DNS di Amazon Route 53 untuk layanan Anda atau menggeser bobot penyeimbang beban aplikasi untuk mengirim lalu lintas ke grup target baru Anda.

Salah satu kelemahan dari strategi blue/green penyebaran adalah biaya yang melekat pada lingkungan siaga karena infrastruktur tambahan yang diperlukan saat melakukan penyebaran. Opsi untuk mengurangi biaya infrastruktur tambahan ini adalah dengan mempertimbangkan mengadopsi varian blue/green penyebaran di mana perangkat lunak game baru digunakan ke server yang sama yang sudah digunakan ke dalam produksi. Dalam skenario ini, proses server hijau baru dapat dimulai dengan perangkat lunak baru di samping proses server biru yang ada, dengan pemotongan terjadi antara proses server daripada antara infrastruktur fisik yang terpisah. Pendekatan ini juga dapat mempercepat penyebaran game di sejumlah besar infrastruktur dengan menghilangkan kebutuhan untuk menunggu server baru diluncurkan di cloud. Untuk praktik terbaik tentang pendekatan penerapan ini, lihat Penerapan Biru/Hijau di. AWS

Penyebaran kenari

Penyebaran Canary berguna untuk pengembang game, karena strategi ini dapat diterapkan untuk merilis versi alfa atau beta awal dari sebuah game, atau fitur game seperti mode permainan baru, peta, atau tantangan ke set pemain terbatas atau kecil dalam produksi. Penyebaran seperti itu disebut kenari. Rilis ini mungkin memiliki pelacakan dan pelaporan tambahan, jadi ketika pemain sungguhan memainkan game atau fitur itu, telemetri permainan mereka dikumpulkan dan dianalisis untuk anomali dan masalah.

Untuk fitur baru, para pemain tidak secara konsisten diberitahu tentang hal ini, dan telemetri game adalah sumber utama yang digunakan untuk menentukan apakah pemain mengalami masalah dan rilis harus digulirkan kembali. Pada saat yang sama, jika tidak ada masalah signifikan yang diidentifikasi, fitur tersebut kemudian dapat diluncurkan lebih lanjut ke lebih banyak pemain untuk data tambahan. Jika para pemain diberi tahu, maka mereka dapat diminta untuk memberikan umpan balik reguler tentang pengalaman mereka. Aktivitas pengujian seperti itu idealnya dikoordinasikan oleh tim operasi langsung.

Sebagai strategi, penyebaran kenari juga dapat digunakan untuk rilis standar untuk secara bertahap membuat fitur baru tersedia bagi para pemain. Keuntungan potensial atas blue/green lingkungan standar adalah bahwa lingkungan kedua skala penuh tidak diperlukan. Kapasitas lingkungan baru yang diperkecil menentukan berapa banyak pemain yang akan dionboard ke fitur baru. Sebelum menambahkan lebih banyak pemain, kapasitas harus diskalakan dengan tepat. Bahkan jika blue/green teknik yang disesuaikan ini diharapkan biayanya relatif lebih rendah daripada biru/hijau standar, masih diperkirakan menimbulkan biaya yang mungkin lebih tinggi daripada teknik substitusi bergulir dari penyebaran kenari.

Jalankan hanya satu kenari pada lingkungan produksi, dan fokuskan untuk data dan umpan baliknya. Jika beberapa kenari digunakan, ini mempersulit pemecahan masalah dan mengisolasi masalah dalam produksi dan merusak kualitas kumpulan data dan umpan balik yang dikumpulkan.

Variasi dalam kenari adalah ketika satu atau lebih eksperimen (umumnya pengujian UI) dijalankan melalui penerapan yang ditargetkan, di mana satu set server backend game melayani satu versi fitur dan set berukuran sama lainnya melayani versi lain dari fitur yang sama. Tidak ada infrastruktur tambahan atau khusus yang dibuat untuk ini, dan hanya kantong server backend yang dipilih yang menerima pembaruan ini. Hasil percobaan adalah untuk mengamati bagaimana pemain bereaksi terhadap masing-masing versi fitur yang sama, menentukan apakah ada konsensus suka atau tidak suka secara keseluruhan, dan mengamati apakah ada masalah yang diidentifikasi dengan kegunaan atau fungsinya. Eksperimen strategis semacam itu juga disebut A/B tes, dan keseluruhan proses disebut pengujian A/B. Setelah menyelesaikan eksperimen ini, data pengujian yang diperlukan dikumpulkan sebelum kembali ke versi sistem backend game saat ini di server yang digunakan untuk pengujian.

Penerapan tradisional warisan

Dalam gaya penerapan tradisional, selama jendela pemeliharaan terjadwal permainan dimatikan dan pemain yang terhubung dijatuhkan atau dikeringkan sebelum instance server dalam backend game diperbarui dengan pembuatan kode terbaru. Penyebaran ini memengaruhi pemain setiap kali dilakukan, dan para pemain harus diberi tahu lebih awal dari jadwal. Akibatnya, model ini menyebabkan dampak pemain paling banyak dan harus dihindari bila memungkinkan.

Setelah pembaruan game diterapkan, game dapat diuji asap sebelum membuka game untuk para pemain, yang akan menunggu game dibuka kembali. Hal ini dapat menyebabkan lonjakan lalu lintas ketika pemain mencoba untuk login dan bermain dalam waktu singkat. Oleh karena itu, jika gim ini tidak dirancang untuk menangani lonjakan lalu lintas seperti itu, Anda dapat memilih untuk secara bertahap mengizinkan pemain kembali ke permainan dalam batch.

Atau, Anda dapat memilih untuk menyediakan infrastruktur secara berlebihan untuk mempertahankan lonjakan lalu lintas pembukaan, dan setelah lalu lintas game selesai, sumber daya dapat diperkecil. Jika perlu, lakukan jenis penyebaran ini selama jam-jam off-peak ketika jumlah pemain berada pada titik terendah. Pemeliharaan yang sering dijadwalkan, serta pemeliharaan yang diperpanjang, secara inheren membawa risiko gesekan pemain dan potensi hilangnya pendapatan. Pemain juga mengharapkan perubahan setelah rilis baru dan dapat kehilangan kepercayaan pada permainan setelah kembali setelah periode downtime.

Langkah-langkah implementasi