Region Pairs
Availability zones terdiri dari satu atau beberapa data center, dimana ada minimal tiga zone dalam satu region. Namun, ada kemungkinan terjadi bencana alam yang cukup besar yang dapat menyebabkan kerusakan yang cukup besar untuk mempengaruhi bahkan dua data center. Untuk itulah Azure membuat region pairs.
Setiap region Azure selalu dipasangkan dengan region lain yang berada dalam geografi yang sama (misalnya AS, Eropa, atau Asia) dengan jarak minimal 300 miles. Pendekatan ini memungkinkan replikasi sumber daya pada daerah geography untuk membantu mengurangi kemungkinan gangguan dari kejadian seperti bencana alam, kerusuhan sipil, pemadaman listrik, atau pemadaman jaringan yang mempengaruhi dua region sekaligus.
Karena region pairs saling terhubung secara langsung dan terpisah cukup jauh untuk isolasi dari bencana regional, maka Anda dapat menggunakannya untuk memberikan layanan yang andal dengan menerapkan redudansi data. Beberapa layanan Azure menawarkan penyimpanan georedundant dengan memanfaatkan region pairs.
Kelebihan lain dari region pairs meliputi:
Availability zones terdiri dari satu atau beberapa data center, dimana ada minimal tiga zone dalam satu region. Namun, ada kemungkinan terjadi bencana alam yang cukup besar yang dapat menyebabkan kerusakan yang cukup besar untuk mempengaruhi bahkan dua data center. Untuk itulah Azure membuat region pairs.
Setiap region Azure selalu dipasangkan dengan region lain yang berada dalam geografi yang sama (misalnya AS, Eropa, atau Asia) dengan jarak minimal 300 miles. Pendekatan ini memungkinkan replikasi sumber daya pada daerah geography untuk membantu mengurangi kemungkinan gangguan dari kejadian seperti bencana alam, kerusuhan sipil, pemadaman listrik, atau pemadaman jaringan yang mempengaruhi dua region sekaligus.
Karena region pairs saling terhubung secara langsung dan terpisah cukup jauh untuk isolasi dari bencana regional, maka Anda dapat menggunakannya untuk memberikan layanan yang andal dengan menerapkan redudansi data. Beberapa layanan Azure menawarkan penyimpanan georedundant dengan memanfaatkan region pairs.
Kelebihan lain dari region pairs meliputi:
- Jika terjadi pemadaman Azure yang luas, satu region dari setiap pasangan diprioritaskan untuk membantu mengurangi waktu yang dibutuhkan untuk memulihkan aplikasi.
- Pembaruan Azure akan dijalankan pada region pairs secara bergantian untuk meminimalkan downtime dan resiko aplikasi down.
- Data terus berada dalam geografi yang sama dengan pasangannya (kecuali South Brazil) untuk tujuan yuridiksi pajak dan penegakan hukum.
Service Level Agreements Azure
Microsoft menunjukkan komitmennya untuk menyediakan produk dan layanan berkualitas tinggi kepada pelanggan dengan memenuhi kebijakan, standar, dan praktik operasional komprehensif.
Microsoft Azure memiliki dokumen formal yang disebut dengan Service Level Agreements (SLA) yang menentukan standar kinerja yang berlaku untuk Azure.
- SLA menggambarkan komitmen Microsoft untuk menyediakan standar kinerja bagi pelanggan Azure.
- Terdapat SLA untuk masing-masing produk dan layanan Azure.
- SLA juga menentukan apa yang terjadi jika suatu layanan atau produk gagal memenuhi spesifikasi SLA yang telah diatur.
SLA untuk produk dan layanan Azure
Ada tiga karakteristik utama SLA untuk produk dan layanan Azure:
- Target kinerja
- Jaminan uptime dan konektivitas,
- Kredit layanan.
Target Kinerja
SLA mendefinisikan target kinerja untuk produk dan layanan Azure. Target kinerja yang ditentukan oleh SLA berlaku untuk setiap produk dan layanan Azure secara spesifik. Misalnya, target kinerja untuk beberapa layanan Azure dinyatakan sebagai jaminan uptime atau tingkat konektivitas.
Jaminan uptime dan konektivitas
SLA biasanya menetapkan jaminan target kinerja sekitar 99,9 persen ("three nines") hingga 99,999 ("five nines") untuk setiap produk atau layanan Azure. Target ini dapat berlaku untuk kriteria kinerja seperti uptime atau waktu respon layanan.
Berikut ini adalah tabel yang mencantumkan potensi downtime kumulatif untuk berbagai level SLA:
| SLA % | Downtime per minggu | Downtime per bulan | Downtime per tahun |
|---|---|---|---|
| 99 | 1,68 jam | 7,2 jam | 3,65 hari |
| 99,9 | 10,1 menit | 43,2 menit | 8,76 jam |
| 99,95 | 5 menit | 21,6 menit | 4,38 jam |
| 99,99 | 1,01 menit | 4,32 menit | 52,56 menit |
| 99,999 | 6 detik | 25,9 detik | 5,26 menit |
Sebagai contoh, Layanan Azure Cosmos DB menawarkan SLA uptime 99,999 persen, SLA ini meliputi komitmen latensi rendah kurang dari 10 milidetik untuk operasi baca dan tulis DB.
Kredit Layanan
SLA juga menjelaskan bagaimana Microsoft akan merespon jika produk atau layanan Azure gagal memenuhi spesifikasi SLA yang telah diatur.
Sebagai contoh, pelanggan mungkin akan mendapatkan diskon yang diterapkan pada tagihan Azure, sebagai kompensasi untuk produk atau layanan Azure yang berkinerja buruk. Tabel dibawah ini akan menjelaskan contoh secara rinci.
| Persentase uptime | Persentase kredit layanan |
|---|---|
| < 99,9 | 10 |
| < 99 | 25 |
| < 95 | 100 |
Menghitung Downtime
Setiap produk atau layanan Azure menawarkan SLA yang berbeda, produk dan layanan ini bisa dikombinasikan dan menghasilkan nilai SLA yang lebih tinggi atau rendah sesuai dengan arsitektur aplikasi yang digunakan. Hasil SLA dari kombinasi ini disebut dengan Composite SLA.
Misalnya, Anda menggunakan layanan Azure web app (SLA 99,95%) yang menyimpan pada SQL database (SLA 99,99%).
Pada kasus diatas, jika salah satu layanan mati maka keseluruhan aplikasi tidak akan bisa digunakan. Sehingga, composite SLA dari aplikasi diatas adalah : 99,95% x 99,99% = 99,94%
Ini artinya aplikasi diatas memiliki peluang kegagalan yang lebih tinggi dari SLA individual. aplikasi yang membutuhkan banyak layanan juga akan memiliki lebih banyak titik potensi kegagalan.
Contoh lain, Anda bisa meningkatkan SLA dengan membuat layanan alternatif cadangan. Misalnya, ketika layanan SQL Database mati maka transaksi pada database akan dialikahkan ke layanan queue untuk nantinya diproses ketika SQL database sudah menyala.
Dengan rancangan ini, aplikasi akan tetap tersedia meskipun layanan basis datanya down. Keseluruhan aplikasi baru akan down ketika layanan database dan queue-nya mati secara bersamaan. Sehingga kombinasi layanan database dan queue akan menghasilkan nilai SLA: 1.0 - (0,0001 x 0,001) = 99,99999 %
Sehingga composite SLA dari aplikasi akan menjadi:
99,95% x 99,99999% = ~99,95%
99,95% x 99,99999% = ~99,95%
Dengan rancangan ini kita telah berhasil meningkatkan SLA aplikasi. Namun, solusi ini memiliki beberapa kelemahan seperti logika aplikasi akan menjadi semakin rumit, akan ada biaya tambahan untuk layanan queue, dan juga masalah terkait konsistensi data.
Meningkatkan Keandalan Aplikasi
Kita bisa menggunakan SLA untuk mengevaluasi bagaimana solusi Azure kita memenuhi kebutuhan bisnis dan pengguna. Dengan membuat SLA sendiri, kita dapat menetapkan target kinerja yang sesuai dengan aplikasi Azure yang ingin dikembangkan. Pendekatan ini dikenal sebagai Application SLA.
Memahami kebutuhan aplikasi
Dalam membangun solusi Azure yang efisien dan andal, kita perlu tahu kebutuhan beban kerja dari aplikasi yang kita kembangkan. Kita dapat memilih produk dan layanan Azure kemudian menyediakan sumber daya yang sesuai dengan persyaratan yang telah kita tentukan. Untuk itu sangat penting kita memahami Azure SLA yang menentukan target kinerja untuk produk dan layanan Azure dalam solusi yang kita kembangkan. Pemahaman ini akan membantu kita dalam membuat SLA aplikasi yang bisa dicapai.
Dalam sebuah sistem terdistribusi, kegagalan sangat mungkin terjadi. Perangkat keras bisa mati, jaringan dapat mengalami kegagalan sementara. Memang kegagalan untuk sistem secara keseluruhan jarang terjadi, namun kegagalan parsial harus tetap direncanakan.
Ketahanan
Ketahanan atau resiliency adalah kemampuan sistem untuk pulih dari kegagalan dan terus berfungsi. Jadi ketahanan bukanlah tentang menghindari kegagalan, namun menanggapi kegagalan dengan cara menghindari downtime atau kehilangan data. Tujuan dari resiliency ini dalah mengembalikan aplikasi ke keadaan berfungsi penuh setelah mengalami kegagalan. Ketersediaan tinggi dan pemulihan dari bencana adalah dua komponen penting dalam membangun ketahanan.
Saat merancang arsitektur, Anda perlu merancang ketahanan, dan Anda perlu melakukan Failure Mode Analysis (FMA). Tujuan dari FMA ini adalah untuk mengidentifikasi kemungkinan titik kegagalan dan untuk menentukan bagaimana aplikasi akan menanggapi kegagalan tersebut.
Biaya dan kompleksitas vs ketersediaan tinggi
Ketersediaan atau avalibility mengacu pada waktu suatu sistem berfungsi dan bekerja. Perlu langkah-langkah implemetnasi untuk mencegah kemungkinan kegagalan layanan. Namun, dalam menyusun langkah-langkah pencegahan ini bisa sulit dan mahal, seringkali solusi yang dihasilkan menjadi kompleks.
Ketika sebuah solusi cloud semakin berkembang menjadi kompleks. Anda akan memiliki lebih banyak layanan yang saling tergantung satu sama lain. Oleh karena itu, Anda mungkin tidak memperhatikan titik kegagalan yang mungkin terjadi ketika Anda memiliki beberapa layanan yang saling bergantung.
Kebanyakan provider memaksimalkan ketersediaan dengan meminimalkan downtime dari solusi Azure mereka. Namun, ketika Anda meningkatkan ketersediaan, Anda juga akan meningkatkan biaya dan kompleksitas solusi.
Risiko downtime bersifat kumulatif di berbagai level SLA, artinya bahwa solusi yang semakin kompleks akan menghadapi tantangan ketersediaan yang juga lebih tinggi. Jadi, seberapa penting "high availability" bagi kebutuhan aplikasi Anda akan menentukan bagaimana Anda menangani penambahan kompleksitas dan biaya untuk SLA aplikasi.
Pertimbangan menentukan SLA aplikasi
- Jika aplikasi Anda memiliki SLA target kinerja sebesar four nines (99,99%), maka untuk pulih dari kegagalan dengan cara manual mungkin tidak cukup untuk memenuhi SLA. Sehingga solusi Azure yang dikembangkan harus bisa melakukan self-diagnosing dan self-healing.
- Sulit untuk merespon kegagalan dengan cukup cepat untuk memenuhi target kinerja SLA di atas 99,99%.
- Pertimbangkan baik-baik jangka waktu yang digunakan untuk mengukur target kinerja SLA aplikasi Anda. Semakin kecil jangka waktunya, semakin ketat toleransi. Misalnya Anda menetapkan satuan waktu dalam jam atau hari, maka Anda perlu toleransi yang ketat. Bisa jadi capaian target kinerja Anda jadi mustahil.
Komentar
Posting Komentar