Bermigrasi ke cloud? Berikut ini bagaimana prioritas DevOps Anda harus berubah saat Anda pindah ke Amazon EC2

Mayoritas perusahaan yang bermigrasi ke cloud, atau membuat aplikasi "cloud-native", melakukannya dengan Amazon Web Services (AWS).AWS menawarkan banyak keuntungan biaya dan fungsionalitas.Perusahaan yang telah mengadopsi praktik terbaik operasi pengembang standar industri ("DevOps") untuk memantau dan mengelola lingkungan di lokasi mereka sering kali bertanya pada diri sendiri bagaimana mereka beradaptasi dengan lingkungan dan aplikasi cloud baru mereka.

Bagaimana prioritas DevOps akan berubah saat Anda beralih dari aplikasi lokal ke Amazon EC2?Berikut penjelasan tentang perbedaan antara keduanya dan hal yang harus Anda ingat.

Prioritas DevOps di cloud?Sama. Tapi berbeda.

Kami sering mendengar pelanggan mengatakan bahwa pengoperasian akan lebih mudah ketika mereka pindah ke AWS. Kami memperingatkan mereka bahwa pindah ke cloud (atau bahkan AWS) tidak berarti bahwa mereka tidak lagi perlu memantau dan mengelola aplikasi mereka.

Perusahaan yang pindah ke Amazon AWS dapat memanfaatkan biaya yang lebih rendah dan sumber daya tenaga kerja dalam hal pengadaan, penyediaan, dan pemeliharaan perangkat keras.Tetapi Anda perlu mempertimbangkan bahwa ketika Anda memutuskan untuk menghosting aplikasi di Amazon EC2, apa pun yang berada di atas lapisan Sistem Operasi adalah tanggung jawab Anda.

Dalam hal cadangan / jaminan ketersediaan / langkah keamanan, dll. Untuk lingkungan Amazon EC2 Anda, prioritasnya sama seperti jika mereka adalah aplikasi di lokasi. Dan Amazon menyediakan beberapa alat dan fungsionalitas asli.Tetapi Anda perlu memutuskan apakah mereka cocok untuk persyaratan.

Keamanan, Cadangan… Apa yang perlu Anda ketahui saat mengelola lingkungan Amazon AWS?

Jadi, apa saja pertimbangan khusus AWS yang perlu Anda ingat saat pindah ke Amazon EC2?Dan alat apa yang tepat untuk Anda?Waktu yang Anda investasikan di muka dalam mendesain aplikasi Anda dan bagaimana Anda akan menerapkan dan mengelolanya akan terbayar.

Pertimbangan pertama Anda adalah bagaimana Anda akan mengamankan aplikasi Amazon EC2 Anda.Desain jaringan, seperti "port mana yang harus dibuka" dan "dari mana mengizinkan akses" harus dipertimbangkan dengan cara yang sama seperti untuk aplikasi di lokasi Anda.Ini dapat dikonfigurasi di AWS menggunakan grup keamanan dan ACL jaringan (daftar kontrol akses).

Anda dapat menggunakan fungsionalitas AWS Trusted Advisor *, yang secara otomatis memeriksa lingkungan AWS Anda dan menunjukkan apakah telah disetel ke pengaturan yang disarankan atau tidak, sehingga memungkinkan untuk memeriksa lingkungan AWS perusahaan Anda untuk masalah keamanan.Kami merekomendasikan untuk memeriksa dengan AWS Trusted Advisor baik pada saat penerapan maupun secara berkala.

Aspek penting lainnya dari keamanan adalah pengelolaan otentikasi dan hak akses.AWS menggabungkan semua ini ke dalam AWS Identity and Access Management (AWS IAM).Selain untuk mengontrol siapa yang dapat mengakses instans EC2, Anda juga dapat menggunakan AWS IAM untuk mengatur izin akses dari instans EC2 ke sumber daya lain (seperti DB), dll. Setelah Anda bermigrasi ke AWS, hal pertama yang perlu Anda lakukan adalah mengatur akun dan pembatasan akses dengan benar di AWS IAM.

Pertimbangan berikutnya adalah "bagaimana cara mencadangkan aplikasi saya di Amazon EC2?" Amazon EC2 menyediakan kemampuan untuk mengambil snapshot, yang memungkinkan Anda melakukannya.Selain itu, menggunakan "Amazon Data Lifecycle Manager" mempermudah penyiapan snapshot berkala, serta pencadangan tambahan.File snapshot disimpan di layanan penyimpanan Amazon S3.Anda dikenai biaya sesuai dengan kapasitasnya, jadi Anda perlu mengetahui jumlah data yang Anda miliki dan menyiapkan setelan seperti "kurangi kapasitas dengan incremental backup" dan "hapus dari data lama".

“Ketersediaan” perlu dipertimbangkan sebelumnya. Kuncinya adalah mengoperasikan sistem sesuai dengan tingkat prioritas sistem.

Pertimbangan terakhir adalah ketersediaan.Dengan aplikasi Amazon EC2, serta aplikasi yang ada di lokasi, Anda harus mempertimbangkan tingkat ketersediaan yang diperlukan berdasarkan biaya dan kepentingan sistem. Namun, jika Anda menggunakan fungsionalitas penerapan Multi-AZ Amazon, Anda dapat menentukan konfigurasi redundan antara pusat data yang berbeda.Namun, menggunakan Multi-AZ lebih mahal daripada menggunakan konfigurasi AZ tunggal (meskipun tidak sebanyak jika Anda memiliki sistem di lokasi yang redundan).Saat merancang aplikasi Anda, Anda perlu mempertimbangkan apakah Multi-AZ diperlukan dan berapa banyak Anda harus berinvestasi dalam ketersediaan.

Jika Anda tidak berinvestasi dalam failover, maka Anda setidaknya harus memantau aplikasi Anda dan merencanakan cara memulihkannya saat downtime dialami. Anda dapat menggunakan Amazon CloudWatch untuk dengan mudah memantau item umum seperti CPU, memori, dan disk, dan Anda juga dapat memprogram fungsi Amazon EC2 Auto Recovery untuk secara otomatis memulihkan instans saat terjadi kesalahan di EC2.

Jika aplikasi Anda memiliki misi penting, Anda akan ingin berinvestasi lebih banyak dalam ketersediaannya.Anda harus mempertimbangkan banyak solusi pihak ketiga yang sangat baik yang menawarkan fungsionalitas berharga bagi komunitas AWS.Salah satu pilihannya adalah SIOS AppKeeper, solusi yang mudah untuk dikonfigurasi dan digunakan yang memantau instans Amazon EC2 Anda dan secara otomatis memulai ulang layanan atau melakukan boot ulang instans jika mengalami kegagalan sistem.Berikut video singkat tentang cara kerja AppKeeper

Meskipun berpindah ke cloud untuk aplikasi Anda sangat masuk akal, Anda tidak dapat meninggalkan praktik terbaik DevOps.Amazon AWS memberi Anda sekumpulan fungsionalitas dan alat yang kaya, tetapi Anda masih harus mengambil tanggung jawab utama atas keamanan, cadangan, dan ketersediaan aplikasi Anda.Bagaimana Anda melakukan ini tergantung pada keahlian Anda dan pentingnya aplikasi itu sendiri.

Kami mengundang Anda untuk bergabung dengan ratusan pelanggan yang telah memanfaatkan AppKeeper untuk mengurangi waktu henti Amazon EC2 mereka dengan mendaftar untuk uji coba layanan gratis selama 14 hari.

* Catatan: Untuk menggunakan AWS Trusted Advisor, diperlukan kontrak untuk dukungan bisnis atau yang lebih tinggi.

Direproduksi dengan izin dari SIOS

Perluas Metrik Ketersediaan Tinggi Anda

Di bidang teknologi, kami menyukai data. Kami menyukai data tentang data dan semua metrik serta ukuran yang dapat dihasilkan oleh alat kami. Kami telah menciptakan industri seputar analytics, produk yang menangkap setiap detail dari ribuan perangkat yang terhubung. Kami menyukai metrik dan ukuran. Dalam banyak kasus dalam ruang ketersediaan yang lebih tinggi, kami menyukai metrik ketersediaan tinggi yang memberi tahu kami seberapa cepat sistem pulih dari kegagalan. Kami menghitung dan melacak waktu antara deteksi dan perbaikan, dan kami terobsesi untuk mengetahui dan mengukur berapa banyak data transaksional yang akan hilang dalam bencana, kegagalan sistem, atau kerusakan disk.

Ironisnya, dalam sistem ketersediaan tinggi dan pemulihan bencana (HA / DR), ada beberapa metrik yang kurang mendapat perhatian.

Berikut delapan metrik ketersediaan tinggi lainnya yang harus Anda perhatikan untuk mengelola lingkungan Anda:

1.  Peringatan keamanan

Ketersediaan bukan hanya tentang pemantauan dan pemulihan aplikasi.  Sistem yang tersedia untuk umum selalu diserang.  Jika Anda tidak memantau lansiran dan peringatan keamanan, aplikasi Anda mungkin berjalan dengan sempurna, sementara kekayaan intelektual Anda disalurkan dengan sempurna ke luar pintu.

2. Koneksi menganggur

Koneksi yang menganggur terdengar tidak berbahaya, tetapi sama tidak berbahayanya dengan kudzu berdaun hijau di halaman selatan.  Koneksi idle membutuhkan sumber daya dan mengancam untuk mengisi kumpulan database, jaringan yang padat, dan kinerja yang melumpuhkan.  Lebih lanjut, koneksi idle dapat menunjukkan masalah pada lapisan aplikasi atau konfigurasi database.

3. Kueri, perintah, atau pekerjaan yang berjalan lama

Ini berlaku tidak hanya untuk kueri atau pekerjaan database, tetapi juga untuk perintah dan cadangan.  Kueri, perintah, dan pekerjaan yang berjalan lama dapat menjadi indikator kesehatan sistem yang buruk, kecepatan disk yang lambat, CPU atau sumber daya lain yang berselisih, atau masalah sistematis, kompatibilitas aplikasi atau OS yang lebih dalam.

4. Disk IO

Disk IO biasanya mengacu pada operasi input / output dari sistem yang terkait dengan aktivitas disk. Mengukur I / O disk dapat membantu mengidentifikasi kemacetan, konfigurasi perangkat keras yang buruk, ukuran disk yang tidak tepat, atau tata letak disk yang tidak disetel dengan baik untuk beban kerja tertentu.  Pemantauan disk I / O dapat membantu memberi tahu Anda jika kueri yang berjalan lama adalah fungsi dari sintaks sql yang buruk, aplikasi dengan kode yang buruk, atau masalah latensi dan akses.

5. Penyimpanan

Kita semua berpikir tentang berapa banyak memori yang digunakan, tetapi pemantauan memori lebih dari sekadar mengukur dan melihat yang gratis versus yang digunakan.  Memori pemantauan membantu Anda melihat kemacetan, kebocoran, mengidentifikasi sistem dengan ukuran yang tidak tepat, memahami beban, rata-rata beban, dan lonjakan.  Selain itu, mengetahui tentang pola intensif memori dapat membantu Anda menyesuaikan rangkaian ketersediaan untuk menghindari kegagalan palsu.

6. Ruang Disk

Sebagai Wakil Presiden Pengalaman Pelanggan, saya pernah mengalami pengalaman malang bangun pagi-pagi untuk panggilan darurat.  Pelanggan menghadapi sistem produksi yang turun setelah pemadaman listrik.  Ketika mereka mencoba untuk me-restart sistem mereka, aplikasi mereka yang dilindungi gagal untuk memulai.  Setelah pemeriksaan cepat dari log kesalahan, jelas terlihat bahwa drive root 100% penuh.  Aplikasi tidak dapat menulis ke sistem file mana pun.  Pemantauan ruang disk tersedia dalam berbagai bentuk dan cara dan menjadikannya sebagai metrik dapat mencegah masalah yang tidak perlu dan pengacakan menit-menit terakhir yang mahal untuk menambah lebih banyak masalah. .

7. Kesalahan dan peringatan

Kesalahan, peringatan, dan pesan pemulihan di log adalah metrik bagus lainnya untuk dipertimbangkan.  Solusi ketersediaan Anda mungkin membuat klien Anda tetap online dan senang, tetapi mungkin juga menutupi masalah yang memerlukan perhatian Anda segera.  Menambahkan pemantauan log untuk FATAL, PANIC, dan pesan ERROR kunci dapat membantu Anda mengidentifikasi masalah yang sering dipulihkan oleh solusi ketersediaan Anda, seperti database crash, kepanikan aplikasi atau core dump, atau kesalahan fatal yang memerlukan restart dingin.

8. Nomor pemulihan

Mirip dengan peringatan dan kesalahan pemantauan, nomor pemulihan dapat memberi tahu Anda banyak hal tentang kesehatan ketersediaan sistem Anda.  Jika Anda rata-rata melakukan lebih dari satu pemulihan aplikasi per minggu, kemungkinan Anda mengalami sesuatu yang lebih dari perlindungan ketersediaan normal.  Dan meskipun pemulihan berhasil dalam memulai ulang aplikasi atau sistem Anda, terlalu banyak dari pemulihan palsu atau bahkan sebenarnya tidak sehat.

Daftar metrik HA / DR yang dapat kami pantau dan alat untuk memantau mereka berkembang pesat.  Pastikan Anda dan tim Anda mempertimbangkan untuk memperluas pengambilan dan analisis data Anda saat ini untuk menyertakan data yang menghasilkan sistem ketersediaan terbaik yang lebih tinggi.

– Cassius Rhue, VP, Pengalaman Pelanggan