Memperkirakan dan mengelola kapasitas layanan pencarian

Di Azure AI Search, kapasitas didasarkan pada replika dan partisi yang dapat diskalakan ke beban kerja Anda. Replika adalah salinan dari mesin cari. Partisi adalah unit penyimpanan. Setiap layanan pencarian baru dimulai dengan satu masing-masing, tetapi Anda dapat menambahkan atau menghapus replika dan partisi secara independen untuk mengakomodasi beban kerja yang berfluktuasi. Menambahkan kapasitas meningkatkan biaya menjalankan layanan pencarian.

Karakteristik fisik replika dan partisi, seperti kecepatan pemrosesan dan IO disk, bervariasi menurut tingkat layanan. Pada layanan pencarian standar, replika dan partisi lebih cepat dan lebih besar dari yang ada di layanan dasar.

Mengubah kapasitas tidak seketika. Dibutuhkan waktu hingga satu jam untuk mengaktifkan atau menonaktifkan partisi, terutama pada layanan dengan jumlah data yang besar.

Saat menskalakan layanan pencarian, Anda dapat memilih dari alat dan pendekatan berikut:

Konsep: unit pencarian, replika, partisi, pecahan

Kapasitas diekspresikan dalam unit pencarian yang dapat dialokasikan dalam gabungan antara partisi dan replika, dengan menggunakan mekanisme sharding yang mendasarinya untuk mendukung konfigurasi yang fleksibel:

Konsep Definisi
Unit pencarian Kenaikan tunggal dari total kapasitas yang tersedia (36 unit). Ini juga merupakan unit penagihan untuk layanan Pencarian Azure AI. Diperlukan minimal satu unit untuk menjalankan layanan.
Replika Instans layanan pencarian digunakan terutama untuk menyeimbangkan beban operasi kueri. Setiap replika menghosting satu salinan indeks. Jika Anda mengalokasikan tiga replika, Anda memiliki tiga salinan indeks yang tersedia untuk melayani permintaan kueri.
Partisi Penyimpanan fisik dan I/O untuk operasi baca/tulis (misalnya, saat membangun kembali atau menyegarkan indeks). Setiap partisi memiliki potongan indeks total. Jika Anda mengalokasikan tiga partisi, indeks Anda akan dibagi menjadi sepertiga.
Pecahan Sepotong indeks. Azure AI Search membagi setiap indeks menjadi pecahan untuk membuat proses penambahan partisi lebih cepat (dengan memindahkan pecahan ke unit pencarian baru).

Diagram berikut menunjukkan hubungan antara replika, partisi, pecahan, dan unit pencarian. Diagram tersebut menunjukkan contoh bagaimana indeks tunggal tersebar di empat unit pencarian dalam layanan dengan dua replika dan dua partisi. Masing-masing dari empat unit pencarian hanya menyimpan setengah dari pecahan indeks. Unit pencarian di kolom kiri menyimpan paruh pertama pecahan, yang terdiri dari partisi pertama, sementara unit pencarian di kolom kanan menyimpan paruh kedua pecahan, yang terdiri dari partisi kedua. Karena ada dua replika, artinya ada dua salinan masing-masing pecahan indeks. Unit pencarian di baris atas menyimpan satu salinan, yang terdiri dari replika pertama, sementara unit pencarian di baris bawah menyimpan salinan lain, yang terdiri dari replika kedua.

Search indexes are sharded across partitions.

Diagram di atas hanya merupakan satu contoh. Banyak kombinasi partisi dan replika yang dapat dilakukan, hingga maksimum 36 total unit pencarian.

Dalam Azure AI Search, manajemen shard adalah detail implementasi dan tidak dapat dikonfigurasi, tetapi mengetahui bahwa indeks dipecah membantu memahami anomali sesekali dalam perilaku peringkat dan lengkapi otomatis:

  • Anomali peringkat: Skor pencarian dihitung pada tingkat pecahan terlebih dahulu, lalu dikumpulkan menjadi satu set hasil. Bergantung pada karakteristik konten pecahan, kecocokan dari satu pecahan mungkin memiliki peringkat lebih tinggi dibandingkan kecocokan di pecahan lain. Jika Anda melihat peringkat intuitif penghitung dalam hasil pencarian, kemungkinan besar karena efek sharding, terutama jika indeks kecil. Anda dapat menghindari anomali peringkat ini dengan memilih untuk menghitung skor secara global di seluruh indeks, tetapi hal itu akan dikenai penalti performa.

  • Anomali pelengkapan otomatis: Kueri pelengkapan otomatis, tempat kecocokan dibuat pada beberapa karakter pertama dari istilah yang dimasukkan sebagian, menerima parameter fuzzy yang memaafkan penyimpangan kecil dalam ejaan. Untuk pelengkapan otomatis, pencocokan fuzzy dibatasi untuk istilah dalam pecahan saat ini. Misalnya, jika pecahan berisi "Microsoft" dan istilah parsial "mikro" dimasukkan, mesin pencari akan cocok pada "Microsoft" dalam pecahan tersebut, tetapi tidak di pecahan lain yang menyimpan bagian indeks yang tersisa.

Target estimasi

Perencanaan kapasitas harus mencakup batas objek (misalnya, jumlah maksimum indeks yang diizinkan pada layanan) dan batas penyimpanan. Tingkat layanan menentukan batas objek dan penyimpanan. Batas mana pun yang tercapai terlebih dahulu adalah batas efektif.

Jumlah indeks dan objek lain biasanya ditentukan oleh persyaratan bisnis dan teknik. Misalnya, Anda mungkin memiliki beberapa versi indeks yang sama untuk pengembangan, pengujian, dan produksi aktif.

Kebutuhan penyimpanan ditentukan oleh ukuran indeks yang ingin Anda bangun. Tidak ada heuristik padat atau umum yang membantu dengan perkiraan. Satu-satunya cara untuk menentukan ukuran indeks adalah membangunnya. Ukurannya akan didasarkan pada data yang diimpor, analisis teks, dan konfigurasi indeks seperti apakah Anda mengaktifkan saran, pemfilteran, dan pengurutan.

Untuk pencarian teks lengkap, struktur data utama adalah struktur indeks terbalik, yang memiliki karakteristik berbeda dibandingkan data sumber. Untuk indeks terbalik, ukuran dan kompleksitas ditentukan oleh konten, tidak harus dengan jumlah data yang Anda umpan ke dalamnya. Sumber data besar dengan redundansi tinggi dapat menghasilkan indeks yang lebih kecil daripada himpunan data yang lebih kecil yang berisi konten yang sangat bervariasi. Jadi, hampir tidak mungkin untuk menyimpulkan ukuran indeks berdasarkan ukuran himpunan data asli.

Atribut pada indeks, seperti mengaktifkan filter dan pengurutan, memengaruhi persyaratan penyimpanan. Penggunaan saran juga memiliki implikasi penyimpanan. Untuk informasi selengkapnya, lihat Atribut dan ukuran indeks.

Catatan

Meskipun memperkirakan kebutuhan masa depan untuk indeks dan penyimpanan dapat terasa seperti tebakan, hal itu layak dilakukan. Jika kapasitas tingkatan ternyata terlalu rendah, Anda harus memprovisikan layanan baru di tingkat yang lebih tinggi lalu memuat ulang indeks Anda. Tidak ada peningkatan layanan di tempat dari satu tingkat ke tingkat lainnya.

Perkirakan dengan tingkat Gratis

Salah satu pendekatan untuk memperkirakan kapasitas adalah memulai dengan tingkat Gratis. Ingatlah bahwa layanan Gratis menawarkan hingga tiga indeks, penyimpanan 50 MB, dan 2 menit waktu pengindeksan. Memperkirakan ukuran indeks yang diproyeksikan dengan batasan ini mungkin rumit, tetapi ini adalah langkah-langkahnya:

  • Buat layanan gratis.

  • Siapkan himpunan data yang kecil dan representatif.

  • Buat indeks dan muat data Anda. Jika kumpulan data dapat dihosting di sumber data Azure yang didukung oleh pengindeks, Anda dapat menggunakan Wizard impor data di portal untuk membuat dan memuat indeks. Jika tidak, Anda dapat menggunakan REST API untuk membuat indeks dan mendorong data. Model pendorongan mengharuskan data berada dalam bentuk dokumen JSON, dan bidang dalam dokumen harus sesuai dengan bidang dalam indeks.

  • Kumpulkan informasi tentang indeks, seperti ukuran. Fitur dan atribut memengaruhi penyimpanan. Misalnya, menambahkan saran (kueri cari-saat-Anda-mengetik) akan meningkatkan persyaratan penyimpanan.

    Menggunakan kumpulan data yang sama, Anda mungkin mencoba membuat beberapa versi indeks, dengan atribut yang berbeda di setiap bidang, untuk melihat bagaimana persyaratan penyimpanan bervariasi. Untuk informasi selengkapnya, lihat "Implikasi penyimpanan" di Membuat indeks dasar.

Dengan memiliki perkiraan kasar, Anda mungkin menggandakan jumlah anggaran untuk dua indeks (pengembangan dan produksi) lalu memilih tingkat sesuai hal tersebut.

Memperkirakan dengan tingkat yang dapat ditagih

Sumber daya khusus dapat mengakomodasi waktu pengambilan sampel dan pemrosesan yang lebih besar untuk perkiraan kuantitas indeks, ukuran, dan volume kueri yang lebih realistis selama pengembangan. Beberapa pelanggan langsung memilih tingkat yang dapat ditagih, lalu mengevaluasi kembali saat proyek pengembangan sudah siap.

  1. Tinjau batas layanan di setiap tingkatan untuk menentukan apakah tingkatan yang lebih rendah dapat mendukung jumlah indeks yang Anda butuhkan. Di seluruh tingkat Dasar, S1, dan S2, batas indeks masing-masing adalah 15, 50, dan 200. Tingkat Penyimpanan Dioptimalkan memiliki batas 10 indeks karena dirancang untuk mendukung jumlah indeks yang sangat besar.

  2. Membuat layanan di tingkat yang dapat ditagih:

    • Mulai dari rendah, di Dasar atau S1, jika Anda tidak yakin tentang beban yang diproyeksikan.
    • Mulai dari tinggi, pada S2 atau bahkan S3, jika pengujian mencakup beban pengindeksan dan kueri berskala besar.
    • Mulai dengan Penyimpanan Dioptimalkan, di L1 atau L2, jika Anda mengindeks sejumlah besar data dan beban kueri relatif rendah, seperti halnya aplikasi bisnis internal.
  3. Buat indeks awal untuk menentukan bagaimana data sumber diterjemahkan ke indeks. Ini adalah satu-satunya cara untuk memperkirakan ukuran indeks.

  4. Pantau penyimpanan, batas layanan, volume kueri, dan latensi di portal. Portal memperlihatkan kueri per detik, kueri yang dibatasi, dan latensi pencarian. Semua nilai tersebut dapat membantu Anda memutuskan apakah Anda memilih tingkat yang tepat.

  5. Tambahkan replika untuk ketersediaan tinggi atau untuk mengurangi performa kueri yang lambat.

    Tidak ada panduan tentang berapa banyak replika yang diperlukan untuk mengakomodasi beban kueri. Performa kueri bergantung pada kompleksitas kueri dan beban kerja yang bersaing. Meskipun menambahkan replika dengan jelas menghasilkan performa yang lebih baik, hasilnya tidak linier secara ketat: menambahkan tiga replika tidak menjamin throughput tiga kali lipat. Untuk panduan dalam memperkirakan QPS untuk solusi Anda, lihat Menganalisis performadan Memantau kueri.

Catatan

Persyaratan penyimpanan dapat meningkat jika Anda menyertakan data yang tidak akan pernah dicari. Idealnya, dokumen hanya berisi data yang Anda butuhkan untuk pengalaman pencarian. Data biner tidak dapat dicari dan harus disimpan secara terpisah (mungkin dalam tabel Azure atau penyimpanan blob). Kemudian, bidang harus ditambahkan dalam indeks untuk menahan referensi URL ke data eksternal. Ukuran maksimum dokumen pencarian individual adalah 16 MB (atau kurang jika Anda mengunggah beberapa dokumen secara massal dalam satu permintaan). Untuk informasi selengkapnya, lihat Batas layanan di Azure AI Search.

Pertimbangan volume kueri

Kueri per detik (QPS) adalah metrik penting selama penyetelan performa, tetapi untuk perencanaan kapasitas, itu menjadi pertimbangan hanya jika Anda mengharapkan volume kueri yang tinggi pada awalnya.

Tingkat Standar dapat memberikan keseimbangan replika dan partisi. Anda dapat meningkatkan waktu penyelesaian kueri dengan menambahkan replika untuk penyeimbangan beban atau menambahkan partisi untuk pemrosesan paralel. Kemudian, Anda dapat menyetel performa setelah layanan diprovisikan.

Jika mengharapkan volume kueri berkelanjutan yang tinggi sejak awal, Anda harus mempertimbangkan tingkat Standar yang lebih tinggi, yang didukung oleh perangkat keras yang lebih kuat. Kemudian, Anda dapat mengambil partisi dan replika secara offline, atau bahkan beralih ke layanan tingkat bawah, jika volume kueri tersebut tidak terjadi. Untuk informasi selengkapnya tentang cara menghitung throughput kueri, lihat Memantau kueri.

Tingkat Penyimpanan Dioptimalkan berguna untuk beban kerja data besar, yang mendukung penyimpanan indeks yang tersedia secara keseluruhan ketika persyaratan latensi kueri kurang penting. Anda masih harus menggunakan replika tambahan untuk penyeimbangan beban dan partisi tambahan untuk pemrosesan paralel. Kemudian, Anda dapat menyetel performa setelah layanan diprovisikan.

Perjanjian tingkat layanan

Fitur tingkat gratis dan pratinjau tidak tercakup oleh perjanjian tingkat layanan (SLA). Untuk semua tingkatan yang dapat ditagih, SLA berlaku ketika Anda memprovisikan redundansi yang cukup untuk layanan Anda. Anda harus memiliki dua replika atau lebih untuk SLA kueri (baca). Anda harus memiliki tiga replika atau lebih untuk SLA kueri dan pengindeksan (baca-tulis). Jumlah partisi tidak memengaruhi SLA.

Tips untuk perencanaan kapasitas

  • Izinkan metrik untuk membuat kueri dan mengumpulkan data seputar pola penggunaan (kueri selama jam kerja, pengindeksan selama jam sibuk). Gunakan data ini untuk menginformasikan keputusan provisi layanan. Meskipun tidak praktis pada siklus per jam atau per hari, Anda dapat secara dinamis menyesuaikan partisi dan sumber daya untuk mengakomodasi perubahan yang direncanakan dalam volume kueri. Anda juga dapat mengakomodasi perubahan yang tidak direncanakan tetapi berkelanjutan jika level bertahan cukup lama untuk menjamin pengambilan tindakan.

  • Ingatlah bahwa satu-satunya kelemahan kurangnya provisi adalah Anda mungkin harus menurunkan layanan jika persyaratan aktual lebih besar daripada prediksi Anda. Untuk menghindari gangguan layanan, Anda akan membuat layanan baru di tingkat yang lebih tinggi dan menjalankannya berdampingan sampai semua aplikasi dan permintaan menargetkan titik akhir baru.

Waktu untuk menambahkan kapasitas

Awalnya, layanan mendapat alokasi tingkat sumber daya minimal yang terdiri dari satu partisi dan satu replika. Tingkat yang Anda pilih menentukan ukuran dan kecepatan partisi, dan setiap tingkat dioptimalkan di sekitar serangkaian karakteristik yang sesuai dengan berbagai skenario. Jika memilih tingkat kelas atas, Anda mungkin memerlukan lebih sedikit partisi daripada jika Anda menggunakan S1. Salah satu pertanyaan yang perlu Anda jawab melalui pengujian mandiri adalah apakah partisi yang lebih besar dan lebih mahal menghasilkan performa yang lebih baik dibandingkan dua partisi yang lebih murah pada layanan yang diprovisikan di tingkat yang lebih rendah.

Satu layanan harus memiliki sumber daya yang memadai untuk menangani semua beban kerja (pengindeksan dan kueri). Tidak ada beban kerja yang berjalan di latar belakang. Anda dapat menjadwalkan pengindeksan untuk waktu ketika permintaan kueri secara alami lebih jarang, tetapi layanan tidak akan memprioritaskan satu tugas ke tugas lain. Selain itu, sejumlah redundansi akan memuluskan performa kueri ketika layanan atau simpul diperbarui secara internal.

Beberapa pedoman untuk menentukan apakah akan menambah kapasitas meliputi:

  • Memenuhi kriteria ketersediaan tinggi untuk perjanjian tingkat layanan
  • Frekuensi kesalahan HTTP 503 meningkat
  • Volume kueri besar diharapkan

Sebagai aturan umum, aplikasi pencarian cenderung membutuhkan lebih banyak replika daripada partisi, terutama ketika operasi layanan bias terhadap beban kerja kueri. Setiap replika adalah salinan indeks Anda, yang memungkinkan layanan menyeimbangkan beban permintaan terhadap beberapa salinan. Semua penyeimbangan beban dan replikasi indeks dikelola oleh Azure AI Search dan Anda dapat mengubah jumlah replika yang dialokasikan untuk layanan Anda kapan saja. Anda dapat mengalokasikan hingga 12 replika dalam layanan pencarian Standar dan 3 replika dalam layanan pencarian Dasar. Alokasi replika dapat dilakukan baik dari portal Azure atau salah satu opsi terprogram.

Aplikasi pencarian yang memerlukan refresh data hampir real-time akan membutuhkan partisi yang lebih proporsional daripada replika. Menambahkan partisi akan menyebarkan operasi baca/tulis di sejumlah besar sumber daya komputasi. Ini juga memberi Anda lebih banyak ruang disk untuk menyimpan indeks dan dokumen tambahan.

Terakhir, indeks yang lebih besar membutuhkan waktu lebih lama untuk kueri. Dengan demikian, Anda mungkin menemukan bahwa setiap peningkatan partisi inkremental membutuhkan peningkatan replika yang lebih kecil tetapi proporsional. Kompleksitas kueri dan volume kueri Anda akan memperhitungkan seberapa cepat eksekusi kueri diselesaikan.

Catatan

Menambahkan lebih banyak replika atau partisi akan meningkatkan biaya operasi layanan, dan dapat memunculkan sedikit variasi terkait bagaimana hasil dipesan. Pastikan untuk memeriksa kalkulator harga untuk memahami implikasi penagihan untuk menambahkan lebih banyak simpul. Bagan di bawah dapat membantu Anda mereferensikan silang jumlah unit pencarian yang diperlukan untuk konfigurasi tertentu. Untuk informasi selengkapnya tentang bagaimana replika tambahan memengaruhi pemrosesan kueri, lihat Hasil pemesanan.

Menambahkan atau mengurangi replika dan partisi

  1. Masuk ke portal Azure lalu pilih layanan pencarian.

  2. Di bagian Pengaturan, buka halaman Skala untuk memodifikasi replika dan partisi.

    Tangkapan layar berikut menunjukkan Standar Dasar yang diprovisikan dengan satu replika dan partisi. Rumus di bagian bawah menunjukkan berapa banyak unit pencarian yang digunakan (1). Jika harga satuan adalah $100 (bukan harga riil), biaya bulanan untuk menjalankan layanan ini rata-rata akan menjadi $100.

    Scale page showing current values

  3. Gunakan penggeser untuk menambah atau mengurangi jumlah partisi. Pilih Simpan.

    Contoh ini menambahkan replika dan partisi kedua. Perhatikan jumlah unit pencarian; sekarang menjadi empat karena rumus penagihan adalah replika dikalikan dengan partisi (2 x 2). Menggandakan kapasitas lebih dari itu akan menggandakan biaya operasi layanan. Jika biaya unit pencarian adalah $100, tagihan bulanan baru kini akan menjadi $400.

    Untuk biaya per unit saat ini dari setiap tingkatan, kunjungi halaman Harga.

    Add replicas and partitions

  4. Setelah menyimpan, Anda dapat memeriksa pemberitahuan untuk memastikan bahwa tindakan berhasil.

    Save changes

    Perubahan kapasitas dapat berlangsung dari 15 menit hingga beberapa jam untuk diselesaikan. Anda tidak dapat membatalkan setelah proses dimulai dan tidak ada pemantauan real time untuk penyesuaian replika dan partisi. Namun, pesan berikut tetap terlihat saat perubahan sedang berlangsung.

    Status message in the portal

Catatan

Setelah diprovisikan, layanan tidak dapat ditingkatkan ke tingkat yang lebih tinggi. Anda harus membuat layanan pencarian di tingkat baru dan memuat ulang indeks. Lihat Membuat layanan Pencarian Azure AI di portal untuk bantuan terkait provisi layanan.

Bagaimana permintaan skala ditangani

Setelah menerima permintaan skala, layanan pencarian:

  1. Memeriksa apakah permintaan itu valid.
  2. Mulai mencadangkan data dan informasi sistem.
  3. Memeriksa apakah layanan sudah dalam status penyediaan (sedang menambahkan atau menghilangkan replika atau partisi).
  4. Mulai proses penyediaan.

Penskalaan layanan dapat memakan waktu hanya 15 menit atau lebih dari satu jam, tergantung pada ukuran layanan dan cakupan permintaan. Pencadangan dapat memakan waktu beberapa menit, tergantung pada jumlah data dan jumlah partisi dan replika.

Langkah-langkah di atas tidak sepenuhnya berturut-turut. Misalnya, sistem mulai menyediakan ketika dapat dengan aman melakukannya, yang bisa saat cadangan mereda.

Kesalahan selama penskalaan

Pesan kesalahan "Operasi pembaruan layanan saat ini tidak diizinkan karena kami memproses permintaan sebelumnya" disebabkan oleh mengulangi permintaan untuk menurunkan atau meningkatkan skala ketika layanan sudah memproses permintaan sebelumnya.

Atasi kesalahan ini dengan memeriksa status layanan untuk memverifikasi status penyediaan:

  1. Gunakan REST API Manajemen, Azure PowerShell, atau Azure CLI untuk mendapatkan status layanan.
  2. Panggil Get Service (REST) atau setara untuk PowerShell atau CLI.
  3. Cek respons untuk "provisioningState": "penyediaan"

Jika statusnya adalah "Provisi", tunggu hingga permintaan selesai. Status harus "Berhasil" atau "Gagal" sebelum permintaan lain dicoba. Tidak ada status untuk pencadangan. Pencadangan adalah operasi internal dan tidak menjadi faktor dalam gangguan pada proses skala.

Jika layanan pencarian Anda tampaknya terhenti dalam status provisi, periksa indeks yatim piatu yang tidak dapat digunakan, dengan volume kueri nol dan tidak ada pembaruan indeks. Indeks yang tidak dapat digunakan dapat memblokir perubahan pada kapasitas layanan. Secara khusus, cari indeks yang dienkripsi CMK, yang kuncinya tidak lagi valid. Anda harus menghapus indeks atau memulihkan kunci untuk membuat indeks kembali online dan membuka blokir operasi skala Anda.

Kombinasi partisi dan replika

Layanan Dasar dapat memiliki tepat satu partisi dan hingga tiga replika, untuk batas maksimum tiga SUS. Satu-satunya sumber daya yang dapat disesuaikan adalah replika. Anda memerlukan minimal dua replika untuk ketersediaan tinggi pada kueri.

Semua layanan pencarian Standar dan Penyimpanan Dioptimalkan dapat mengasumsikan kombinasi replika dan partisi berikut, yang tunduk pada batas 36-SU yang diizinkan untuk tingkatan ini.

1 partisi 2 partisi 3 partisi 4 partisi 6 partisi 12 partisi
1 replika 1 SU 2 SU 3 SU 4 SU 6 SU 12 SU
2 replika 2 SU 4 SU 6 SU 8 SU 12 SU 24 SU
3 replika 3 SU 6 SU 9 SU 12 SU 18 SU 36 SU
4 replika 4 SU 8 SU 12 SU 16 SU 24 SU T/A
5 replika 5 SU 10 SU 15 SU 20 SU 30 SU T/A
6 replika 6 SU 12 SU 18 SU 24 SU 36 SU T/A
12 replika 12 SU 24 SU 36 SU T/A T/A T/A

SU, harga, dan kapasitas dijelaskan secara mendetail di situs web Azure. Untuk informasi selengkapnya, lihat Detail Harga.

Catatan

Jumlah replika dan partisi dibagi secara merata menjadi 12 (khususnya, 1, 2, 3, 4, 6, 12). Azure AI Search telah membagi setiap indeks menjadi 12 pecahan sehingga dapat disebarkan dalam bagian yang sama di semua partisi. Misalnya, jika layanan memiliki tiga partisi dan Anda membuat indeks, setiap partisi akan berisi empat pecahan indeks. Bagaimana Azure AI Search memecah indeks adalah detail implementasi, dapat berubah dalam rilis mendatang. Meskipun jumlahnya adalah 12 hari ini, Anda seharusnya tidak mengharapkan jumlah itu selalu menjadi 12 di masa depan.

Langkah berikutnya