BerandaComputers and TechnologyCovid-19 mendorong kami untuk mengurangi biaya AWS hingga setengahnya

Covid-19 mendorong kami untuk mengurangi biaya AWS hingga setengahnya

Image for post

Image for post

Pengurangan sekitar 40%

Kami sangat fokus pada pertumbuhan sebelum COVID dimulai. AWS sangat penting dalam cara kami mengirim dengan cepat yang membantu mendorong pertumbuhan itu. Beberapa kesalahan awal kami mengakibatkan pemborosan yang mengakibatkan biaya tinggi seiring waktu. COVID-19 mendorong kami untuk membawa lebih banyak efisiensi dalam operasi bisnis kami untuk memberikan lebih banyak penghematan kepada pelanggan kami selama masa-masa sulit ini. Sebagai bagian dari inisiatif itu, kami mulai mencari cara untuk mengurangi biaya infrastruktur kami.

Dalam posting ini, kami akan mencoba untuk berbagi alat, pembelajaran utama dan strategi kami untuk mengatasi masalah biaya infrastruktur yang tinggi.

Untuk mengurangi biaya, kami perlu melihat kontributor biaya terbesar kami. Penjelajah Biaya AWS adalah tempat yang baik untuk memulai ini. Jika Anda telah menandai sumber daya Anda dengan benar (kami memberi tag berdasarkan layanan, tim, divisi, dll. Ada pedoman bagus untuk ini oleh AWS di sini ), Cost Explorer dapat menunjukkan kepada Anda berapa biaya tim, aplikasi, atau layanan mikro.

Atribusi dan laporan biaya berdasarkan layanan dan aplikasi adalah tempat yang baik untuk memulai. Tetapi ketika Anda mulai mengidentifikasi alasan biaya di bawah kepala yang berbeda, Anda perlu mendapatkan pandangan yang lebih terperinci tentang mengapa layanan atau aplikasi tertentu menghabiskan banyak biaya. Untuk mendapatkan data pada tingkat granular seperti tingkat operasi atau API, Laporan Biaya & Penggunaan (CUR) sangat membantu. Untuk menyiapkan Laporan CUR , Anda harus menyiapkan jalur pipa untuk membuat data CUR dapat diakses untuk kueri dan kemudian membuat kueri laporan menggunakan Athena .

Beberapa kueri di Athena yang biasa kami gunakan untuk menganalisis penggunaan dan biaya kami

Tergantung dalam bisnis Anda, Anda akan memiliki hal-hal berbeda yang akan menjadi kontributor biaya utama Anda. Namun, ada beberapa layanan AWS yang umum di antara kebanyakan bisnis – EC2, RDS, S3, dan Transfer Data. Ini juga berlaku untuk kami.

Kontributor utama biaya bagi kami adalah:

  • Transfer data
  • EC2
  • S3
  • Instans Cadangan

Mari kita lihat masing-masing secara mendetail.

Biaya transfer data adalah yang paling mudah diabaikan karena sulit untuk memperhitungkan transfer data melalui jaringan dibandingkan dengan penggunaan komputasi. Jangan lupa bahwa ketika Anda sedang membangun bisnis Anda, penggunaan jaringan sangat sulit untuk diperkirakan. Biaya jaringan sejak awal biasanya sangat kecil sehingga tidak memerlukan banyak perhatian. Namun, beberapa keputusan tingkat yang lebih tinggi seperti menghindari penggunaan rute jaringan publik untuk mengakses layanan internal atau mengurangi transfer data karena komponen infrastruktur (seperti pemantauan) dapat menghemat uang. Itu sebanyak yang bisa Anda lakukan. Saat Anda meningkatkan skala, biaya jaringan mulai muncul.

Biaya transfer data muncul di EC2-Lainnya di AWS Cost Explorer . AWS menagih Anda untuk berbagai jenis transfer data:

  1. Transfer data dari luar VPC – terdaftar sebagai NAT Gateway, PublicIP-In, PublicIP-Out, VPCPeering-In, VPCPeering-Out di AWS Cost Explorer
  2. Menyeberang- Transfer data AZ – Terdaftar sebagai InterZone-In, InterZone-Out di AWS Cost Explorer

Transfer data dari luar VPC (Internet)

Biaya utama kami di sini adalah Gateway NAT biaya. NAT Gateway digunakan untuk mengaktifkan instance di subnet pribadi untuk terhubung ke internet. AWS Cost Explorer tidak memberikan banyak informasi tentang untuk apa transfer data Anda dikenakan biaya. Ini dokumentasi oleh AWS merekomendasikan solusi berikut untuk mengurangi biaya transfer data:

  1. Siapkan NAT Gateway per AZ untuk mengurangi cross-AZ (atau antar-AZ ) transfer data.
  2. Jika Anda menggunakan DynamoDB dan S3 di wilayah yang sama, penyiapan titik akhir gerbang VPC .
  3. Jika sebagian besar lalu lintas adalah ke layanan AWS yang mendukung titik akhir VPC, buat satu titik akhir antarmuka VPC .
  4. Jika sebagian besar lalu lintas perlu menuju ke internet, siapkan

    gateway internet .

Kiat profesional : Anda juga dapat mengatur instance publik dan menggunakannya sebagai ganti gateway NAT jika Anda tidak ingin membayar jam berjalan Gateway NAT . Hal ini dapat berisiko jika instans mati, memerlukan pemeliharaan, atau persyaratan bandwidth jaringan Anda tidak dapat dipenuhi oleh batas bandwidth jaringan EC2, jadi Anda mungkin dapat mencobanya di lingkungan non-prod. Kami tidak mencoba ini tetapi belajar dari orang-orang yang kami kenal bahwa beberapa perusahaan juga melakukan ini.

Kami sudah memiliki Gateway NAT per AZ sehingga kami tidak dikenakan biaya untuk transfer data lintas-AZ.

Titik akhir VPC adalah permata tersembunyi. Biaya transfer data karena S3 seringkali menjadi penyumbang besar. Segera setelah Anda meluncurkan titik akhir VPC, Anda akan melihat penurunan tiba-tiba dalam biaya transfer data. Sebelum kami menyiapkan titik akhir VPC, kami perlu mengetahui di mana kami membuat permintaan untuk lebih memahami biaya dan penggunaan kami. Jika S3 atau layanan AWS lainnya muncul dalam analisis Anda, Anda harus segera melihat penerapan titik akhir VPC.

Titik akhir VPC adalah permata tersembunyi. Biaya transfer data karena S3 seringkali menjadi penyumbang besar. Segera setelah Anda meluncurkan titik akhir VPC, Anda akan melihat penurunan tiba-tiba dalam biaya transfer data.

Mengurangi biaya Gateway NAT lebih lanjut akan membutuhkan pemahaman yang lebih baik tentang alasan tingginya biaya Gateway NAT. Untuk menelusuri lebih lanjut ke mana semua kami ditagih untuk transfer data Gateway NAT, kami menggunakan Log Aliran VPC aktif grup log dan AWS Insights untuk mengetahui kontributor terbesar kami. Anda dapat menemukan beberapa contoh kueri di sini dan sini. Anda juga dapat membuang Log Aliran VPC ke bucket S3 dan kemudian menanyakannya menggunakan AWS Athena untuk melakukan analisis kustom jika infrastruktur dan pengaturan bisnis Anda mengharuskan Anda menemukan jawaban yang lebih dalam tentang penggunaan jaringan Anda. Untuk detail tentang cara mengaturnya, ikuti ini pos oleh AWS. Jika Anda perlu mengidentifikasi layanan AWS dari IP, Anda dapat memeriksa Rentang IP AWS sini .

Setelah menganalisis Log Aliran VPC kami, kami menemukan bahwa sebagian besar dari kami Biaya Gateway NAT berasal dari:

  1. Aplikasi kami mengirimkan permintaan ke aplikasi lain melalui penyeimbang beban publik
  2. Biaya transfer data antara EC2 dan S3 kami sendiri

Permintaan pengiriman aplikasi ts ke load balancer publik kita sendiri

Mengidentifikasi aplikasi mana yang membuat permintaan ke penyeimbang beban publik bisa menjadi sedikit rumit karena log akses penyeimbang beban penerima Anda akan menunjukkan IP publik gerbang NAT Anda. Kami harus melakukan proses yang menyakitkan untuk berbicara dengan semua pemilik layanan yang memiliki penyeimbang beban publik dan menyiapkan penyeimbang beban pribadi tambahan, lalu meminta semua aplikasi bermigrasi ke menggunakan penyeimbang beban pribadi. Dalam beberapa kasus, kami harus menyiapkan dua penyeimbang beban – satu untuk perjalanan publik dan satu lagi untuk lalu lintas internal, karena biaya transfer data Gateway NAT kami lebih tinggi daripada biaya penyeimbang beban tambahan.

Biaya transfer data antara EC2 dan S3 kami sendiri

Kami membuat

titik akhir VPC gateway

untuk membuat lalu lintas ke S3 menjadi pribadi. Setelah melakukan perubahan ini, biaya transfer data S3 kami turun secara signifikan, tetapi biaya Gateway NAT karena S3 masih tinggi. Ini karena kami mentransfer data dari bucket di wilayah berbeda. Kami harus memigrasi beberapa bucket ke wilayah yang sama dari tempat bucket ini paling banyak diakses.

Salah satu biaya transfer data S3 yang besar disebabkan oleh registri Docker internal kami. Setelah semua perubahan ini, kami tidak dapat mengurangi biaya transfer data karena stage dan lingkungan CI kami berada di region yang berbeda. Titik akhir pribadi hanya efektif untuk lingkungan yang wilayah registri sama dengan wilayah lingkungan (produksi dalam kasus kami). Jadi kami menyiapkan registri buruh pelabuhan dengan proxy di wilayah yang sama dengan tahap kami untuk menyimpan gambar buruh pelabuhan. Kami akan menerbitkan detail tentang bagaimana kami mencapai ini dalam posting blog terpisah segera.

Transfer Data Cross-AZ

Kami memiliki transfer data Cross-AZ yang signifikan dalam produksi serta lingkungan panggung kami. Ada beberapa hal mudah yang dapat Anda lakukan di sini – seperti mengaktifkan kompresi, mengurangi transfer data yang tidak perlu seperti log debug, dll. Jika Anda telah melakukan semua konfigurasi dan penyetelan, hal berikutnya yang harus dilihat adalah mencoba mengurangi jejak transfer data dari layanan Anda. Ini tidak mudah untuk diselesaikan, jadi kami memutuskan untuk menganggapnya sebagai perbaikan jangka panjang. Bergantung pada selera risiko Anda, Anda juga dapat melihat menjalankan seluruh infrastruktur Anda dari satu AZ. Kami memigrasi infrastruktur panggung kami dan memigrasikan sebagian besar infrastruktur produksi ke AZ tunggal sehingga menurunkan biaya antar AZ menjadi seminimal mungkin. Ini adalah migrasi yang menarik. Anda dapat membaca lebih lanjut tentang migrasi sini.

Penurunan biaya EC2 sangat bergantung pada infrastruktur yang Anda jalankan. Ada beberapa langkah yang kami ambil untuk mengurangi biaya EC2 kami.

Pengoptimalan Sumber Daya Langkah pertama adalah melihat instans EC2 mana yang paling banyak mengeluarkan biaya dan kemudian melanjutkan dari sana. Sekali lagi kami strategi pemberian tag banyak membantu kami dalam menentukan hal ini menggunakan AWS Cost Explorer. Kami membuat daftar di mana jenis instance dapat diubah atau jika ukuran minimum grup penskalaan otomatis dapat dikurangi. Untuk Kubernetes, kami membutuhkan sesuatu yang mirip dengan Cost Explorer. Setelah beberapa eksplorasi, kami menemukan kube -laporan-sumber daya . Ini memberikan tampilan terkini tentang biaya dan penggunaan oleh aplikasi, namespace, dan pod. Kami menggunakan ini untuk mengidentifikasi sumber daya yang meminta banyak sumber daya tetapi tidak memanfaatkannya sehingga kami dapat mengukurnya dengan benar.

Image for post

Kredit gambar: Image for post contoh demo dari kube-resource-reports

Pemanfaatan Instans Cadangan (RI)

Kami telah membeli RI beberapa bulan sebelum COVID-19 menyerang kami. Setelah mengubah jenis instans dan mengurangi ukuran minimum grup penskalaan otomatis, Penggunaan RI kami turun. Ini murni pemborosan. Namun untungnya, kami membeli Convertible RI sehingga kami dapat mengonversinya ke jenis instans lain untuk memastikan Utilisasi RI kami 100%. Jika Anda ingin membeli RI EC2, kami sarankan untuk melihat

Savings Plan

diluncurkan tahun lalu yang merupakan penawaran serupa dengan RI tetapi Anda tidak perlu khawatir tentang mengonversi RI atau membelinya secara terpisah untuk setiap daerah. Satu peringatan penting dengan Savings Plan bukanlah reservasi kapasitas yang tepat. Ini murni konstruksi diskon.

Instans Spot

Instans spot adalah cara terbaik untuk menghemat biaya. Mereka bisa semurah 30% dari biaya atas permintaan. Mayoritas infrastruktur kami berjalan berdasarkan permintaan. Kami telah menjelajahi tempat kejadian sebelumnya, tetapi kami memiliki beberapa kekhawatiran:

1. Jika instance spot dihentikan karena masalah harga, bagaimana kami memastikan aplikasi tetap tersedia? Image for post Instans spot cukup mudah dikelola dengan grup penskalaan otomatis AWS jika Anda menggunakan template peluncuran. Dalam template peluncuran, Anda dapat menentukan yang berbeda Image for post strategi alokasi untuk memastikan ketersediaan tinggi aplikasi Anda. Strategi ini akan memastikan bahwa jika jenis instans tidak tersedia, jenis instans lain yang bergantung pada strategi alokasi Anda akan diluncurkan.

Image for post

Image for post

Konfigurasi strategi alokasi instans dalam grup penskalaan otomatis
Konfigurasi campuran jenis instans dalam grup penskalaan otomatis

2. Shutdown aplikasi dengan baik ketika instance akan dihentikan sehingga tingkat kesalahan tidak meningkat. Anda dapat mengetahui apakah instance spot akan berhenti sebelum 2 menit dengan membuat permintaan curl sederhana secara berkala (baca lebih lanjut sini). Ini agak sulit dipecahkan untuk aplikasi yang ada yang berjalan pada instans EC2 karena itu akan memerlukan perubahan di semua ASG kami. Pilihan lain adalah menggunakan layanan terkelola seperti

SpotInst untuk melakukan pekerjaan untuk Anda.

Untuk Kubernetes (yang merupakan sebagian besar produksi kami), ternyata jauh lebih mudah untuk melakukan instans spot daripada EC2. AWS dan komunitas DevOps telah membuat alat luar biasa yang membuatnya sangat mudah. Kamu bisa memakai

aws-node-termination-handler

atau kube-spot- penghentian-pemberitahuan-handler .

Ada baiknya untuk menyiapkan

Anggaran Gangguan Pod untuk penerapan Anda guna memastikan bahwa gangguan seminimal mungkin. Hari ini, kami hanya mengubah persentase instance spot di ASG grup node kami saat dan saat kami perlu menyesuaikan penyebaran spot kami.

Pendekatan ini telah membantu kami menjalankan semua beban kerja Kubernetes panggung kami dan sebagian besar beban kerja Kubernetes produksi kami pada instans langsung. Dalam produksi, 99% dari beban kerja kami tercakup dalam instans yang dipesan dan dicadangkan, dan rencana penghematan. Hanya 1% beban kerja yang berjalan sesuai permintaan, sebagian besar karena sulitnya mengelola cakupan spot untuk menghindari RI atau pemborosan rencana penghematan karena beban kerja kami yang bervariasi.

Penutupan panggung setiap malam infrastruktur

Semua pengembang kami masuk zona waktu yang sama, jadi lingkungan panggung kita tidak digunakan pada malam hari. Kami sudah menghentikan instans EC2 di lingkungan panggung pada malam hari. Di Kubernetes, kami memiliki alat internal yang membantu setiap pengembang membuat namespace mereka sendiri dan menyiapkan lingkungan pengembang pribadi. Kami menyetel replika untuk semua penerapan dan set stateful ke 0 di malam hari. Dan jika tidak ada perubahan apa pun pada namespace selama 5 hari, kami menghapusnya. Ini menghemat setidaknya 35% dari biaya panggung kami. Juga, kami mendapatkan efek samping yang bagus untuk memastikan bahwa lingkungan panggung kami dapat diulang dan dibuat kembali melalui kode dan otomatisasi.

Penurunan skala malam dalam produksi Karena operasi kami hanya berbasis di India, kami tidak menerima lalu lintas yang signifikan pada malam hari. Kami mengurangi jumlah instance yang kami jalankan untuk layanan di luar jam kerja. Kami sudah menggunakan tindakan terjadwal di Grup Penskalaan Otomatis di EC2. Di Kubernetes, kami membutuhkan sesuatu yang serupa untuk HPA untuk layanan kami yang berjalan di cluster Kubernetes kami.

kube-schedule-scaler

mampu melakukan ini. Kami menggunakan garpu kube-schedule-scaler yang dimodifikasi. Pengembang dapat menentukan jadwal penurunan ukuran hanya dengan meletakkan anotasi sederhana pada objek HPA. Saat layanan menurunkan skala, autoscaler cluster akan menangani pengurangan ukuran grup node. Anda juga dapat menjelajah

 kube-downscaler  untuk fungsi serupa.   Berikut adalah contoh tampilan HPA dengan tindakan terjadwal:  

apiVersion: autoscaling / v1

jenis: HorizontalPodAutoscaler

metadata:

anotasi:

kube-schedule-scaler / jadwal-tindakan: ‘[
{“schedule”: “0 19 “, “minReplicas”: “7”},
{“schedule”: “30 1 “, “minReplicas”: “20”}
]’

nama: my-hpa

namespace: ruang nama-saya

spesifikasi:

maxReplicas: 100

minReplicas: 20

Sumber pengoptimalan untuk cluster dev Kubernetes

Di Kubernetes, Anda dapat mengatur permintaan dan batasan untuk sebuah pod. Dalam produksi, perbedaan antara batas dan permintaan harus kecil, jika tidak, Anda mungkin melihat masalah kinerja (baca lebih lanjut tentang ini sini). Namun dalam kasus lingkungan panggung, beban kerja umumnya tidak intensif CPU. Jadi, tidak masuk akal untuk membuat permintaan sumber daya tetap tinggi. Agak sulit untuk melakukan ini untuk semua layanan Anda, jadi kami membuat pengontrol Kubernetes yang, bergantung pada label namespace, mengurangi CPU container yang diminta tetapi mempertahankan batasnya pada nilai yang sama untuk memungkinkan beberapa puncak aplikasi.

Mengurangi permintaan seminimal mungkin sambil mempertahankan batas yang cukup tinggi membantu kami mengurangi jumlah inti hingga 70%.

  • Kami menghadapi beberapa tantangan seputar manajemen sumber daya – Anda dapat membacanya
  • sini.

    Mengurangi biaya EBS

  • Kami menggunakan campuran volume magnetik dan GP2. Kami mencoba menggunakan volume magnet di mana pun kami tahu bahwa kami tidak membutuhkan banyak IO. Sebagian besar beban kerja kami yang menggunakan volume EBS tidak berkewarganegaraan dan digunakan sebagai volume root di EC2. Kami tidak memiliki kebijakan yang baik tentang pemilihan ukuran EBS saat meluncurkan infrastruktur EC2 baru yang menyebabkan banyak pemborosan EBS (sebagian besar instans menggunakan hingga 20% dari penyimpanan yang disediakan). Solusinya di sini sederhana tetapi membutuhkan banyak pekerjaan manual (beberapa di antaranya dapat dituliskan juga):

      Buat kembali semua AMI dan perbarui template peluncuran untuk menyediakan lebih sedikit kapasitas EBS yang diperlukan.

  • Perbaiki kebijakan penyediaan EBS dan tetapkan peringatan yang baik tentang penggunaan untuk menyelesaikannya dalam jangka panjang.
  • Biaya Tahap ELB

  • Kami menggunakan ELB untuk mengekspos layanan dan memberikan titik akhir untuk pengujian lokal. Tetapi hal ini mengakibatkan biaya ELB tambahan dan ini merupakan inefisiensi besar dalam penyiapan kami. Kami memutuskan untuk mengganti semua ELB dengan ingress Nginx untuk mengekspos layanan. Kami menulis pengontrol Kubernetes internal untuk membuat layanan NodePort yang didukung oleh masuknya Nginx untuk setiap permintaan untuk membuat layanan berbasis ELB. Ini tidak memerlukan perubahan dalam manifes layanan kami dan secara drastis mengurangi biaya ELB kami.

    S3 cukup murah untuk penyimpanan data tetapi tanpa penanganan yang tepat tentang bagaimana Anda menggunakan S3, biayanya dapat terus meningkat seiring waktu jika Anda berlindung ‘ t mengonfigurasi kebijakan siklus hidup untuk bucket Anda. Kami memiliki ratusan ember. Untuk mendapatkan laporan atribusi biaya untuk S3, kami menggunakan AWS Athena untuk menanyakan laporan CUR kami dan untuk memfilter bucket yang paling banyak kami kenakan. Setelah mengidentifikasi keranjang yang paling mahal, kami menemukan beberapa masalah umum:

      Tidak ada kebijakan siklus hidup. Kami tidak menghentikan / menghapus data apa pun yang bertambah selama berbulan-bulan dan bertahun-tahun.
  • Jika menyimpan cadangan, cadangan tidak dikompresi. Log dibuang tetapi tidak diarsipkan.

    Anda dapat mengatur kebijakan siklus hidup di bucket Anda untuk mengubah jenis penyimpanan file Anda atau menghapusnya setelah beberapa waktu. Baca ini dikirim oleh AWS untuk lebih jelasnya.

    Kami ingin secara khusus memanggil opsi tiering cerdas yang dapat membantu mengurangi penyimpanan sangat mahal.

    AWS menawarkan Instans Cadangan (RI) untuk banyak layanannya (seperti RDS, Elasticache, Redshift, dll.). Jika Anda mengetahui bahwa sumber daya akan ada di sana selama satu tahun atau lebih dan tidak memerlukan perubahan pada jenis instansinya, akan lebih baik untuk membeli RI untuk instans tersebut. AWS juga mendukung konversi RI sebelum kontrak pembelian berakhir untuk beberapa layanan mereka. Jelajahi opsi tersebut sebelum melakukan pembelian.

    Membeli banyak RI juga bisa menjadi masalah jika Pemanfaatan RI Anda menurun karena itu akan menjadi pemborosan murni. Anda dapat menggunakan AWS Cost Explorer untuk melacak ini. Beberapa alat pihak ke-3 juga dapat digunakan untuk menyiapkan peringatan.

    Read More

    RELATED ARTICLES

    LEAVE A REPLY

    Please enter your comment!
    Please enter your name here

    Most Popular

    Recent Comments