Pilar ElastiCache Pengoptimalan Biaya Lensa Well-Architected Amazon

Pilar optimisasi biaya berfokus untuk menghindari biaya yang tidak perlu. Topik utamanya termasuk memahami dan mengendalikan ke mana biaya dihabiskan, memilih jenis simpul yang paling tepat (menggunakan instans yang mendukung tingkatan data berdasarkan kebutuhan beban kerja), jumlah jenis sumber daya yang tepat (berapa banyak replika baca), menganalisis pengeluaran dari waktu ke waktu, dan penskalaan untuk memenuhi kebutuhan bisnis tanpa pengeluaran berlebihan.

COST1: Bagaimana Anda mengidentifikasi dan melacak biaya yang terkait dengan ElastiCache sumber daya Anda? Bagaimana Anda mengembangkan mekanisme untuk memungkinkan pengguna membuat, mengelola, dan menghapus sumber daya yang dibuat?

Pengantar tingkat pertanyaan: Untuk memahami metrik biaya, diperlukan partisipasi dan kolaborasi berbagai tim: rekayasa perangkat lunak, manajemen data, pemilik produk, keuangan, dan pimpinan. Untuk mengidentifikasi pendorong biaya utama, semua pihak yang terlibat harus memahami pemicu penggunaan layanan dan kompromi manajemen biaya. Hal ini juga sering kali menjadi perbedaan utama antara upaya optimisasi biaya yang berhasil dan kurang berhasil. Memastikan Anda memiliki proses dan alat untuk melacak sumber daya yang dibuat dari pengembangan hingga produksi dan pensiun membantu Anda mengelola biaya yang terkait dengannyaElastiCache.

Manfaat tingkat pertanyaan: Pelacakan terus menerus dari semua biaya yang terkait dengan beban kerja Anda membutuhkan pemahaman mendalam tentang arsitektur yang termasuk ElastiCache sebagai salah satu komponennya. Selain itu, Anda harus memiliki rencana manajemen biaya untuk mengumpulkan dan membandingkan data penggunaan dengan anggaran Anda.

• [Diperlukan] Lengkapi Cloud Center of Excellence (CCoE) dengan salah satu piagam pendirinya untuk menentukan, melacak, dan mengambil tindakan pada metrik seputar penggunaan organisasi Anda. ElastiCache Jika CCoE ada dan berfungsi, pastikan ia tahu cara membaca dan melacak biaya yang terkait dengannya ElastiCache. Saat sumber daya dibuat, gunakan IAM peran dan kebijakan untuk memvalidasi bahwa hanya tim dan grup tertentu yang dapat membuat instance resource. Hal ini memastikan bahwa biaya yang terkait dengan hasil bisnis dan garis akuntabilitas yang jelas ditetapkan, dari perspektif biaya.

  1. CCoEharus mengidentifikasi, mendefinisikan, dan mempublikasikan metrik biaya yang diperbarui secara reguler -bulanan seputar ElastiCache penggunaan utama di seluruh data kategoris seperti:

     1. Jenis simpul yang digunakan dan atributnya: standar vs. memori dioptimalkan, instans sesuai permintaan vs. terpesan, wilayah, dan zona ketersediaan

     2. Jenis lingkungan: gratis, developer, pengujian, dan produksi

     3. Strategi penyimpanan dan retensi cadangan

     4. Transfer data dalam dan lintas wilayah

     5. Instans yang berjalan di Amazon Outposts

  2. CCoEterdiri dari tim lintas fungsi dengan representasi non-eksklusif dari rekayasa perangkat lunak, manajemen data, tim produk, keuangan, dan tim kepemimpinan di organisasi Anda.

  [Sumber Daya]:

  • Buat Pusat Keunggulan Cloud

  • ElastiCacheHarga Amazon

• [Wajib] Gunakan tag alokasi biaya untuk memantau biaya pada tingkat granularitas yang rendah. Gunakan Manajemen AWS Biaya untuk memvisualisasikan, memahami, dan mengelola AWS biaya dan penggunaan Anda dari waktu ke waktu.

  1. Gunakan tag untuk mengatur sumber daya Anda, dan tag alokasi biaya untuk melacak AWS biaya Anda pada tingkat terperinci. Setelah Anda mengaktifkan tag alokasi biaya, AWS gunakan tag alokasi biaya untuk mengatur biaya sumber daya Anda pada laporan alokasi biaya Anda, untuk memudahkan Anda mengkategorikan dan melacak biaya Anda. AWS AWS menyediakan dua jenis tag alokasi biaya, tag yang AWS dihasilkan dan tag yang ditentukan pengguna. AWS mendefinisikan, membuat, dan menerapkan tag yang AWS dihasilkan untuk Anda, dan Anda menentukan, membuat, dan menerapkan tag yang ditentukan pengguna. Anda harus mengaktifkan kedua jenis tag ini secara terpisah sebelum tag tersebut dapat muncul di Manajemen Biaya atau laporan alokasi biaya.

  2. Gunakan tag alokasi biaya untuk mengatur AWS tagihan Anda untuk mencerminkan struktur biaya Anda sendiri. Ketika Anda menambahkan tag alokasi biaya ke sumber daya Anda di Amazon ElastiCache, Anda akan dapat melacak biaya dengan mengelompokkan pengeluaran pada faktur Anda berdasarkan nilai tag sumber daya. Anda sebaiknya mengombinasikan beberapa tag untuk melacak biaya secara lebih mendetail.

  [Sumber Daya]:

  • Menggunakan AWS tag alokasi biaya

  • Memantau biaya dengan tag alokasi biaya

  • AWS Cost Explorer

• [Terbaik] Connect ElastiCache biaya ke metrik yang menjangkau seluruh organisasi.

  1. Pertimbangkan metrik bisnis serta metrik operasional seperti latensi - konsep apa dalam model bisnis Anda yang dapat dimengerti di seluruh peran? Metrik harus dapat dipahami oleh sebanyak mungkin peran dalam organisasi.

  2. Contoh - pengguna yang dilayani secara simultan, latensi maks serta rata-rata per operasi dan pengguna, skor keterlibatan pengguna, tingkat pengembalian pengguna/minggu, durasi/pengguna sesi, tingkat pengabaian, laju hit cache, dan kunci yang dilacak

  [Sumber Daya]:

  • Pemantauan penggunaan dengan CloudWatch Metrik

• [Baik] Pertahankan visibilitas up-to-date arsitektur dan operasional pada metrik dan biaya di seluruh beban kerja yang digunakan. ElastiCache

  1. Pahami seluruh ekosistem solusi Anda, ElastiCache cenderung menjadi bagian dari ekosistem AWS layanan penuh dalam rangkaian teknologi mereka, dari klien hingga API Gateway, Redshift, dan QuickSight untuk alat pelaporan (misalnya).

  2. Petakan komponen solusi Anda dari klien, koneksi, keamanan, operasi dalam memori, penyimpanan, otomatisasi sumber daya, akses, dan manajemen data, di diagram arsitektur Anda. Setiap lapisan terhubung ke seluruh solusi serta memiliki kebutuhan dan kemampuan sendiri yang menambah dan/atau membantu Anda mengelola biaya keseluruhan.

  3. Diagram Anda harus mencakup penggunaan komputasi, jaringan, penyimpanan, kebijakan siklus hidup, pengumpulan metrik serta elemen operasional dan fungsional ElastiCache aplikasi Anda

  4. Persyaratan beban kerja Anda cenderung berubah dari waktu ke waktu dan penting bagi Anda untuk terus memelihara dan mendokumentasikan pemahaman Anda tentang komponen yang mendasarinya serta tujuan fungsional utama Anda agar tetap proaktif dalam manajemen biaya beban kerja Anda.

  5. Dukungan eksekutif untuk visibilitas, akuntabilitas, prioritas, dan sumber daya sangat penting bagi Anda untuk memiliki strategi manajemen biaya yang efektif untuk Anda. ElastiCache

COST2: Bagaimana Anda menggunakan alat pemantauan berkelanjutan untuk membantu Anda mengoptimalkan biaya yang terkait dengan ElastiCache sumber daya Anda?

Pengenalan tingkat pertanyaan: Anda perlu membidik keseimbangan yang tepat antara metrik ElastiCache biaya dan kinerja aplikasi Anda. Amazon CloudWatch menyediakan visibilitas ke metrik operasional utama yang dapat membantu Anda menilai apakah ElastiCache sumber daya Anda terlalu banyak atau kurang digunakan, relatif terhadap kebutuhan Anda. Dari perspektif pengoptimalan biaya, Anda perlu memahami kapan Anda dilebih-lebihkan dan dapat mengembangkan mekanisme yang tepat untuk mengubah ukuran ElastiCache sumber daya Anda sambil mempertahankan kebutuhan operasional, ketersediaan, ketahanan, dan kinerja Anda.

Manfaat tingkat pertanyaan: Dalam keadaan yang ideal, Anda akan menyediakan sumber daya yang cukup untuk memenuhi kebutuhan operasional beban kerja Anda dan tidak memiliki sumber daya yang kurang dimanfaatkan yang dapat mengakibatkan situasi biaya yang kurang optimal. Anda harus dapat mengidentifikasi dan menghindari pengoperasian ElastiCache sumber daya yang terlalu besar untuk jangka waktu yang lama.

• [Wajib] Gunakan CloudWatch untuk memantau ElastiCache klaster Anda dan menganalisis bagaimana metrik ini berhubungan dengan dasbor AWS Cost Explorer Anda.

  1. ElastiCache menyediakan metrik tingkat host (misalnya, CPU penggunaan) dan metrik yang khusus untuk perangkat lunak mesin cache (misalnya, cache mendapat dan cache meleset). Metrik ini diukur dan dipublikasikan untuk setiap simpul cache dalam interval 60 detik.

  2. ElastiCache metrik kinerja (CPUUtilization,,, EngineUtilization SwapUsage CurrConnections, dan Penggusuran) dapat menunjukkan bahwa Anda perlu menskalakan naik/turun (gunakan tipe node cache yang lebih besar/lebih kecil) atau masuk/keluar (tambahkan lebih banyak/lebih sedikit pecahan). Pahami implikasi biaya dari keputusan penskalaan dengan membuat matriks buku pedoman yang memperkirakan biaya tambahan dan lama waktu min dan maks yang diperlukan untuk mencapai ambang batas performa aplikasi Anda.

  [Sumber Daya]:

  • Pemantauan penggunaan dengan CloudWatch Metrik

  • Metrik Apa yang Harus Saya Pantau?

  • ElastiCacheHarga Amazon

• [Wajib] Pahami dan dokumentasikan strategi pencadangan dan implikasi biaya Anda.

  1. Dengan ElastiCache, cadangan disimpan di Amazon S3, yang menyediakan penyimpanan tahan lama. Anda perlu memahami implikasi biaya dalam kaitannya dengan kemampuan Anda untuk pulih dari kegagalan.

  2. Aktifkan pencadangan otomatis yang akan menghapus file cadangan yang melewati batas retensi.

  [Sumber Daya]:

  • Menjadwalkan pencadangan otomatis

  • Harga Amazon Simple Storage Service

• [Terbaik] Gunakan Simpul Terpesan untuk instans Anda sebagai strategi yang disengaja untuk mengelola biaya beban kerja yang dipahami dan didokumentasikan dengan baik. Simpul terpesan dikenai biaya di muka dan bergantung pada jenis simpul dan durasi pemesanan—satu atau tiga tahun. Biaya ini jauh lebih kecil daripada biaya penggunaan per jam yang dikenakan untuk simpul sesuai permintaan.

  1. Anda mungkin perlu mengoperasikan ElastiCache klaster Anda menggunakan node sesuai permintaan sampai Anda mengumpulkan data yang cukup untuk memperkirakan persyaratan instance yang dicadangkan. Rencanakan dan dokumentasikan sumber daya yang diperlukan untuk memenuhi kebutuhan Anda dan membandingkan biaya yang diharapkan di seluruh jenis instans (sesuai permintaan vs. terpesan)

  2. Evaluasi secara rutin jenis simpul cache baru yang tersedia dan nilai apakah masuk akal, dari perspektif metrik biaya dan operasional, untuk memigrasikan armada instans Anda ke jenis simpul cache baru

COST3: Haruskah Anda menggunakan tipe instance yang mendukung tiering data? Apa keuntungan dari tingkatan data? Kapan sebaiknya tidak menggunakan instans tingkatan data?

Pengantar tingkat pertanyaan: Memilih jenis instans yang sesuai tidak hanya dapat memiliki dampak performa dan tingkat layanan, tetapi juga dampak finansial. Jenis instans memiliki biaya berbeda yang terkait dengannya. Memilih satu atau beberapa jenis instans besar yang dapat mengakomodasi semua kebutuhan penyimpanan dalam memori mungkin merupakan keputusan yang wajar. Namun, hal ini dapat memiliki dampak biaya yang signifikan seiring proyek berkembang. Memastikan bahwa jenis instance yang benar dipilih memerlukan pemeriksaan periodik waktu idle ElastiCache objek.

Manfaat tingkat pertanyaan: Anda harus memiliki pemahaman yang jelas tentang bagaimana berbagai jenis instans memengaruhi biaya Anda saat ini dan di masa depan. Perubahan beban kerja marginal atau berkala seharusnya tidak menyebabkan perubahan biaya yang tidak proporsional. Jika beban kerja mengizinkannya, jenis instans yang mendukung tingkatan data menawarkan harga yang lebih baik per penyimpanan yang tersedia. Karena instance tiering data SSD penyimpanan per instance yang tersedia mendukung kemampuan total data per instance yang jauh lebih tinggi.

• [Wajib] Pahami batasan instans tingkatan data

  1. Hanya tersedia untuk klaster ElastiCache (RedisOSS).

  2. Hanya jenis instans tertentu yang mendukung tingkatan data.

  3. Hanya ElastiCache (RedisOSS) versi 6.2 ke atas yang didukung

  4. Barang besar tidak ditukar ke. SSD Objek di atas 128 MiB dipertahankan dalam memori.

  [Sumber Daya]:

  • Tingkatan data

  • ElastiCacheHarga Amazon

• [Wajib] Pahami berapa persentase basis data Anda yang secara teratur diakses oleh beban kerja Anda.

  1. Instans tingkatan data ideal untuk beban kerja yang sering mengakses sebagian kecil dari keseluruhan set data Anda, tetapi masih memerlukan akses cepat ke data yang tersisa. Dengan kata lain, rasio data hot terhadap data warm adalah sekitar 20:80.

  2. Kembangkan pelacakan tingkat klaster terhadap waktu idle objek.

  3. Implementasi besar lebih dari 500 Gb data merupakan kandidat yang baik

• [Wajib] Pahami bahwa instans tingkatan data tidak bersifat opsional untuk beban kerja tertentu.

  1. Ada biaya kinerja kecil untuk mengakses objek yang jarang digunakan karena mereka ditukar ke lokal. SSD Jika aplikasi Anda sensitif terhadap waktu respons, uji dampaknya terhadap beban kerja Anda.

  2. Tidak cocok untuk cache yang menyimpan sebagian besar objek berukuran lebih dari 128 MiB.

  [Sumber Daya]:

  • Batasan

• [Terbaik] Jenis instans terpesan mendukung tingkatan data. Hal ini menjamin biaya terendah dalam hal jumlah penyimpanan data per instans.

  1. Anda mungkin perlu mengoperasikan ElastiCache cluster Anda menggunakan instance tiering non-data sampai Anda memiliki pemahaman yang lebih baik tentang kebutuhan Anda.

  2. Analisis pola penggunaan data ElastiCache cluster Anda.

  3. Buat pekerjaan otomatis yang secara berkala mengumpulkan waktu idle objek.

  4. Jika Anda melihat bahwa persentase besar (sekitar 80%) objek berada dalam kondisi idle untuk jangka waktu yang dianggap sesuai untuk beban kerja Anda, dokumentasikan temuan tersebut dan sarankan untuk memigrasikan klaster ke instans yang mendukung tingkatan data.

  5. Evaluasi secara rutin jenis simpul cache baru yang tersedia dan nilai apakah masuk akal, dari perspektif metrik biaya dan operasional, untuk memigrasikan armada instans Anda ke jenis simpul cache baru.

  [Sumber Daya]:

  • OBJECT IDLETIME

  • ElastiCacheHarga Amazon