Mengapa Pemantauan Aplikasi AWS EC2 Begitu Sulit?

Selamat! Anda telah memigrasikan aplikasi inti Anda ke cloud AWS.  Atau, Anda sedang mengembangkan aplikasi "cloud-asli" baru dan hosting di cloud.  Mungkin Anda memanfaatkan skalabilitas Amazon EC2 dan arsitekturnya yang elastis.  Apa pun itu, Anda sekarang ingin memastikan aplikasi itu tetap aktif dan berjalan, atau bahwa Anda diperingatkan dengan cepat jika dan ketika sesuatu terjadi.

Karena sesuatu akan terjadi.  Data pelanggan kami menunjukkan bahwa perusahaan yang hanya menggunakan tiga instance EC2 mengalami downtime setidaknya sebulan sekali.  Itu berarti pengguna yang tidak bahagia tidak dapat mengakses aplikasi mereka. Anda memerlukan solusi pemantauan untuk memberi tahu Anda apa yang sedang terjadi.

Cara mempersempit solusi pemantauan aplikasi EC2

Langkah pertama dalam pencarian Anda untuk solusi pemantauan EC2 yang sempurna harus memahami kebutuhan Anda dan kemampuan teknis Anda sendiri.  Solusi pemantauan tidak semuanya sama.

Apakah Anda tertarik dengan solusi kaya fitur yang memantau beragam sistem? Atau yang berfokus pada serangkaian inti sistem, seperti lingkungan EC2 Anda?

Apa yang ingin Anda lakukan dengan output dari solusi pemantauan aplikasi Anda? Apakah Anda ingin sebanyak mungkin informasi membantu pengembang Anda memecahkan masalah? Atau apakah Anda mencari peringatan cepat dan bantuan dalam memulihkan dari kegagalan?

Dan apa selera teknis Anda untuk menginstal dan mengelola aplikasi lain? Apakah Anda suka menulis? Atau apakah Anda menginginkan sesuatu yang "set-it-and-forget-it"?

Pencarian untuk "solusi pemantauan kinerja aplikasi" di Google menghasilkan 1.170.000.000 hasil! Lompat ke Amazon AWS Marketplace dan Anda akan menemukan 453 produk yang terdaftar di kategori DevOps – Monitoring.  Memiliki pemahaman yang jelas tentang persyaratan Anda dan kemampuan teknis Anda sendiri akan membantu Anda mempersempit pencarian Anda.

Memantau aplikasi yang berjalan di Amazon EC2 dengan Amazon CloudWatch atau solusi APM lainnya

Jika Anda meng-hosting aplikasi Anda di Amazon EC2, maka Anda dapat mempertimbangkan untuk menggunakan Amazon CloudWatch.   Seberapa familiar Anda dengan metrik standar dan kustom? Anda harus tahu bahwa Anda memerlukan cukup banyak keahlian teknis untuk menjalankan Amazon CloudWatch dengan benar. Amazon CloudWatch adalah solusi hebat bagi pengguna yang membutuhkan data dan wawasan yang dapat ditindaklanjuti untuk merespons perubahan kinerja di seluruh sistem, mengoptimalkan sumber daya, dan pandangan terpadu tentang kesehatan operasional mereka.  Tetapi ini semua datang pada harga dalam hal pengetahuan dan pengalaman yang dibutuhkan untuk mengkonfigurasi dan mengelola Amazon CloudWatch dengan benar.

Pilihan lain adalah Anda mengevaluasi dan memperoleh salah satu dari banyak solusi pemantauan kinerja aplikasi ("APM") yang tersedia secara komersial di pasar, seperti dari AppDynamics, Datadog, Dynatrace, atau New Relic.  Tetapi perlu diingat kebutuhan Anda.  Seberapa luas Anda perlu memonitor? Dan apa yang ingin Anda lakukan dengan informasi itu? Apakah Anda siap kewalahan dengan peringatan? Dan ketahuilah bahwa banyak solusi APM tidak melakukan apa pun untuk membantu Anda pulih tanpa menunjukkan masalah.  Anda masih harus meninggalkan semuanya untuk memulai kembali layanan secara manual atau mem-boot ulang instans Anda.

Monitor aplikasi yang berjalan di Amazon EC2 menggunakan SIOS AppKeeper

Tetapi ada cara lain.  SIOS AppKeeper adalah layanan SaaS yang dapat dikonfigurasi untuk secara otomatis menemukan mesin virtual EC2 dan layanan mereka. Kemudian secara otomatis mengambil sejumlah tindakan jika dan ketika downtime dialami.  Jadi alih-alih mendapat peringatan bahwa ada sesuatu yang salah, Anda mendapatkan pemberitahuan bahwa sesuatu terjadi dan secara otomatis ditangani.

SIOS AppKeeper mulai hanya US $ 40 per instance per bulan. Kami mengundang Anda untuk melihat video singkat ini untuk melihat betapa mudahnya menginstal dan menggunakan AppKeeper.

Mengapa Pemantauan Aplikasi AWS EC2 Begitu Sulit?

Perangkat Lunak Ketersediaan Tinggi adalah Asuransi Terhadap Downtime SAP

Kita semua perlu membeli asuransi – untuk mobil kita, rumah kita, hidup kita. Tidak ada yang suka membayar uang untuk layanan yang kami harap tidak perlu digunakan. Tetapi kita semua tahu bahwa kita harus memilikinya untuk berjaga-jaga. Kebanyakan orang menunda asuransi sampai sesuatu yang buruk terjadi, membeli yang termurah, atau benar-benar melakukan pekerjaan rumah mereka dan membelinya dari seseorang yang mereka percayai.  Grup terakhir ini biasanya memberikan harga terbaik.

6 Tantangan Migrasi Awan Umum

Sebagai seorang insinyur perangkat lunak untuk pengalaman pelanggan dengan SIOS, saya sering membantu perusahaan yang memigrasi lingkungan pengelompokan ketersediaan tinggi mereka ke cloud.

Migrasi cloud adalah proses, bukan tujuan. Saat kami melibatkan pelanggan yang beralih ke cloud, sering kali terlambat dalam proses perencanaan, yang tidak ideal, tetapi tidak biasa dalam migrasi cloud. Di bawah ini adalah enam tantangan migrasi awan yang sering kita lihat.

1. Waktu – Memahami berapa lama waktu yang dibutuhkan untuk transfer data ke cloud

   Berapa lama untuk mendapatkan data Anda dari lokasi ke cloud? Ini dapat bervariasi secara drastis tergantung pada aplikasi Anda, jenis data, dan penyedia cloud. Salah satu detail yang sering diabaikan adalah waktu yang diperlukan untuk menyinkronkan data dari node primer ke node sekunder, dan dalam beberapa kasus ke situs pemulihan bencana (DR). Pelanggan yang tidak memperhitungkan waktu sinkronisasi ulang dibiarkan memutar-mutar ibu jari mereka saat data direplikasi.

2. Biaya – Memahami implikasi biaya dari transfer data di dalam cloud

   Transfer data dalam wilayah cloud tidak dikenai biaya. Transfer data antar wilayah akan dikenakan biaya. Biasanya, kita melihat arsitektur di mana node primer dan sekunder terletak di zona ketersediaan cloud yang terpisah dalam suatu wilayah. Biaya dapat meningkat secara signifikan ketika situs DR diperkenalkan karena situs DR akan selalu berada di wilayah lain. Pemulihan bencana untuk aplikasi kaya data seperti SAP NetWeaver mungkin berbiaya rendah untuk ditiru di seluruh wilayah.

3. Replikasi Antar Wilayah

   Replikasi antar wilayah memperkenalkan tantangan lain: tipe replikasi. Replikasi asinkron atau sinkron dalam AZ ditentukan oleh persyaratan RTO dan RPO pelanggan. Terlepas dari ukuran instance, replikasi data akan mengalami beberapa latensi saat melintasi antar wilayah. SIOS merekomendasikan replikasi asinkron antara wilayah untuk mengurangi dampak latensi itu. Concurrency Labs memberikan beberapa informasi mendalam tentang latensi antara wilayah EC2.

   

4. Keanehan Konfigurasi Cloud

   Gambar OS siap pakai dapat digunakan dari cloud. Kenyamanan ini datang dengan biaya, memperkenalkan faktor lain untuk manajemen konfigurasi. Layanan cloud-init yang disertakan pada gambar SuSE Enterprise Linux yang dioptimalkan untuk cloud dapat menghapus alamat IP virtual yang ditentukan pengguna. Tidak ada yang menghentikan PoC seperti alamat IP virtual menghilang setiap dua menit!

5. Keamanan Cloud

   Skala komputasi awan memberikan keamanan yang lebih besar daripada yang mampu dimiliki bisnis di pusat data di lokasi. Beban kerja cloud memanfaatkan keamanan mutakhir tanpa menyadarinya. Misalnya, secara default instance AWS EC2 memblokir lalu lintas apa pun yang tidak dikirim oleh atau dikirim ke instance itu sendiri. Ini adalah fitur hebat untuk mengamankan jaringan di cloud. Jika suatu sistem membutuhkan Terjemahan Alamat Jaringan (NAT), langkah-langkah keamanan standar EC2 akan menyebabkan alamat IP gagal. Menonaktifkan pemeriksaan sumber / tujuan dari konsol akan menyelesaikan masalah. Bergantung pada keakraban pengguna dengan AWS, ini dapat mengambil antara beberapa klik hingga beberapa panggilan dukungan. Memahami secara spesifik bagaimana suatu sistem berinteraksi dalam suatu lingkungan adalah kunci keberhasilan migrasi cloud.

6. Pengujian Penerimaan Pengguna Cloud (UAT)

   Pelanggan yang berasal dari sistem di-prem perlu diingatkan bahwa sumber daya tidak lagi menjadi faktor pembatas. Di cloud, sistem dapat dengan mudah disalin dan dijalankan dalam isolasi produksi, sesuatu yang tidak sepele di tempat. Akses on-demand ke sumber daya TI memungkinkan UAT HA dan DR berkembang melampaui “shutdown the primary node”. Jaringan dapat disabotase, kernel bisa panik, bahkan basis data pun bisa rusak dan semua ini tidak akan memengaruhi produksi! Identifikasi dan pengujian skenario ini meningkatkan postur HA dan DR.

Melaksanakan migrasi cloud yang sukses membutuhkan masukan dari semua pemangku kepentingan. Ketersediaan tinggi dan pemulihan bencana adalah aspek inti dari setiap beban kerja perusahaan. Apakah SIOS sudah menjadi bagian dari sistem Anda saat ini atau akan menjadi bagian dari migrasi cloud masa depan Anda, libatkan kami!

-Harrison Howell, Insinyur Perangkat Lunak untuk Pengalaman Pelanggan

Direproduksi dengan izin dari SIOS