Desain untuk pengoptimalan penggunaan
 Memaksimalkan penggunaan sumber daya dan operasi. Terapkan ke persyaratan fungsional dan nonfungsi solusi yang dinegosiasikan. |
|---|
Layanan dan penawaran menyediakan berbagai kemampuan dan tingkat harga. Setelah Anda membeli serangkaian fitur, hindari kurang menggunakannya. Temukan cara untuk memaksimalkan investasi Anda di tingkatan. Demikian juga, terus mengevaluasi model penagihan untuk menemukan model yang lebih selaras dengan penggunaan Anda, berdasarkan beban kerja produksi saat ini.
Contoh skenario
Contoso University saat ini menghosting solusi komersial off-the-shelf (COTS) yang memungkinkan fakultas universitas untuk membuat dan memperbarui kursus untuk tahun ajaran dan merupakan portal pendaftaran utama yang digunakan oleh siswa untuk kursus tersebut. Solusi ini memiliki integrasi kustom dengan sistem manajemen pendidikan software-as-a-service (SaaS), yang mereka harapkan pada akhirnya akan memigrasikan semua fungsi mereka dalam beberapa tahun. Sementara itu, mereka ingin mengoptimalkan biaya pada komponen integrasi kustom.
Solusi teknologi dari penawaran COTS umumnya diperlakukan seperti kotak hitam, kecuali untuk databasenya yang merupakan Azure Database for MySQL. Integrasi kustom adalah Azure Durable Function, yang dijalankan pada paket layanan Standar di Azure App Service. App Service ini sebelumnya menghosting situs web universitas, tetapi itu tidak lagi terjadi. Fungsi tahan lama ini adalah aplikasi Python yang didukung oleh akun Azure Storage khusus yang melakukan sinkronisasi malam hari dari database MySQL ke API SaaS.
Gunakan harga berbasis konsumsi saat praktis
Mungkin ada layanan yang menawarkan harga berbasis konsumsi, yang berarti Anda hanya ditagih untuk pemanfaatan layanan, dan Anda dapat mematikan layanan ketika tidak perlu berhenti dikenakan biaya. Jika Anda memiliki komponen beban kerja yang hanya digunakan secara sporadis, ini dapat membantu meminimalkan biaya yang terbuang jika dibandingkan dengan membayar komponen untuk menjalankan 24/7/365.
Dengan menggunakan harga berbasis konsumsi, Anda hanya membayar dengan tepat apa yang Anda gunakan. Opsi ini adalah pilihan yang baik ketika komputasi beban kerja Anda tidak diharapkan digunakan penuh waktu.
Tantangan Contoso
- Pekerjaan sinkronisasi biasanya berjalan selama sekitar satu jam setiap malam, pada waktu tertentu. Performanya secara historis telah memuaskan. Kerusakan jarang terjadi dan kesalahan sementara ditangani dengan baik dalam konfigurasi saat ini.
- Karena komputasi yang diperlukan untuk pekerjaan sinkronisasi hanya digunakan sekitar satu jam per hari, dan mereka membayar selama 24 jam terlepas dari pemanfaatannya, tim beban kerja tertarik pada alternatif untuk desain saat ini.
- Tim telah mempertimbangkan untuk menulis skrip untuk mematikan layanan setiap malam setelah sinkronisasi berjalan dan menyebarkannya kembali keesokan harinya, tetapi solusi ini akan membawa tingkat risiko dan kompleksitas yang tinggi.
Menerapkan pendekatan dan hasil
- Tim menganalisis riwayat pekerjaan dan mereka menemukan bahwa fungsi terpanjang yang pernah dijalankan hanya kurang dari dua jam. Mereka membandingkan biaya paket khusus dengan biaya rencana konsumsi Azure Functions untuk skenario terburuk dan menyimpulkan bahwa rencana konsumsi akan lebih murah.
- Tim menjalankan pengujian performa untuk memastikan performa cukup dan mereka melihat sedikit peningkatan waktu proses, tetapi masih dalam batas yang dapat diterima.
- Biaya keseluruhan beban kerja dikurangi dengan menggunakan paket konsumsi karena mereka hanya dikenakan biaya saat pekerjaan dijalankan.
Mengoptimalkan desain ketersediaan tinggi Anda
Prioritaskan penyebaran model aktif-aktif atau aktif-saja melalui pasif aktif, sebagai bagian dari rencana pemulihan Anda, jika Anda sudah membayar sumber daya.
Jika desain Anda default menggunakan model pasif aktif, Anda mungkin memiliki sumber daya menganggur yang dapat digunakan. Mengonversi ke aktif-aktif mungkin memungkinkan Anda untuk memenuhi persyaratan tingkatan beban dan menskalakan bursting tanpa pengeluaran berlebihan. Jika Anda dapat memenuhi target pemulihan dengan model aktif-saja, biaya sumber daya tersebut dapat dihapus sepenuhnya.
Tantangan Contoso
- Aplikasi COTS menggunakan Azure Database for MySQL Flexible Server yang dikonfigurasi untuk ketersediaan tinggi zona yang sama, yang menyediakan server siaga di zona ketersediaan yang sama dengan server utama. Mereka juga telah mengaktifkan pencadangan otomatis.
- RPO beban kerja relatif panjang pada 12 jam, dan RTO tiga jam selama hari sekolah.
- Berdasarkan pengujian pemulihan sebelumnya, tim tahu bahwa mereka dapat memenuhi target RPO dan RTO mereka melalui failover otomatis ke server siaga. Mereka juga telah menguji pemulihan database dari cadangan dan mereka dapat memenuhi target dalam skenario ini.
Menerapkan pendekatan dan hasil
- Tim beban kerja mengevaluasi kembali manfaat desain ketersediaan tinggi vs biaya layanan dua kali lipat dari satu instans.
- Tim menguji membangun instans baru dan memulihkan database dari cadangan dan mereka puas bahwa mereka masih akan mematuhi target pemulihan mereka, sehingga mereka memutuskan untuk menghilangkan instans siaga.
- Tim memperbarui rencana DR untuk mencerminkan strategi pemulihan baru dan mewujudkan penghematan biaya melalui konfigurasi baru.
Menjaga lingkungan cloud Anda tetap bersih dari sumber daya dan data yang tidak digunakan
Tinjau penyebaran secara teratur dan ketat untuk sumber daya dan data yang tidak digunakan dan menonaktifkannya. Seiring waktu sumber daya dan data yang diperlukan untuk beberapa tujuan di masa lalu, tetapi tidak lagi digunakan dapat bertahan di lingkungan cloud Anda dan biaya yang tidak perlu bertambah. Waspadalah untuk menjaga lingkungan Anda tetap bersih untuk membantu mengoptimalkan efisiensi biaya.
Mematikan sumber daya yang tidak digunakan dan menghapus data ketika Anda tidak lagi membutuhkannya mengurangi pemborosan dan membebaskan dana sehingga Anda dapat menginvestasikannya di tempat lain.
Tantangan Contoso
- Universitas secara historis telah mengambil pendekatan konservatif untuk menonaktifkan solusi, takut bahwa mereka mungkin perlu kembali ke konfigurasi sebelumnya. Kehati-hatian ini telah menyebabkan layanan yang ditinggalkan berjalan di satu atau beberapa lingkungan selama berbulan-bulan yang telah dilupakan dalam beberapa kasus.
- Ketika layanan yang ditinggalkan ditemukan, biasanya secara tidak sengaja karena tidak ada proses formal untuk meninjau lingkungan untuk layanan tersebut.
Menerapkan pendekatan dan hasil
- Tim menambahkan penonaktifan App Service ke backlog sebagai bagian dari migrasi dari App Service ke hosting konsumsi untuk Durable Function. Sebagai bagian dari sprint berikutnya, mereka akan mematikan penyebaran App Service di semua lingkungan.
- Untuk membantu mendeteksi sumber daya yang ditinggalkan secara proaktif, tim menyiapkan pemberitahuan di Azure Advisor untuk memberi tahu mereka tentang sumber daya yang tidak digunakan.
- Tim menerapkan kebijakan baru yang mengharuskan tim untuk melakukan tinjauan penuh bulanan tentang lingkungan pra-produksi dan ulasan penuh triwulanan tentang lingkungan produksi untuk mengidentifikasi sumber daya yang ditinggalkan. Setiap sumber daya yang ditinggalkan yang ditemukan akan ditambahkan ke backlog untuk dinonaktifkan.