Architecting on AWS (Membangun Arsitektur Cloud di AWS)_3

 

Pengantar ke Caching

Sederhananya, caching adalah salah satu teknik untuk memastikan aplikasi kita mampu menangani lonjakan user. Bagaimana caranya? Coba pikirkan skenario ini. Misalkan tim marketing Anda melakukan promosi besar-besaran di seluruh kota besar yang ada di Indonesia untuk kopi varian baru andalan startup Anda, anggap saja Anda meluncurkan “Kopi Macchiato Rasa Durian”. 

Nah, kira-kira dari sisi IT, apa yang akan terjadi? Kemungkinan, data ataupun query yang dilakukan oleh pengguna sebagian besar akan banyak mengenai kopi varian baru tersebut. Bayangkan saja, dari 100.000 request (misalnya), 95%-nya mengenai Kopi Macchiato Rasa Durian. 

Karena Anda tidak menerapkan caching, seluruh request tersebut terpaksa diproses oleh server. Ini tentu sangat membebani server, memperbesar biaya, dan meningkatkan latensi. Tentu saja Anda akan berpikir, “Adakah cara yang lebih baik?” 

Eits, jangan khawatir! Di modul ini kita akan mempelajari mengenai caching. 

Untuk menjawab kebutuhan arsitektur di atas, kita akan mempelajari hal-hal berikut ini:

• Tinjauan Caching
• Edge Caching
• Database Caching

Di akhir modul kita akan memiliki pemahaman untuk mengembangkan arsitektur kita seperti gambar di bawah ini.

Bisa Anda lihat gambar di atas, pada modul ini kita akan menambahkan beberapa komponen untuk melengkapi arsitektur di kelas ini, yakni Amazon CloudFront dan Memcached. Penasaran seperti apa? Yuk kita masuk ke pembahasan berikutnya!

Tinjauan Caching

Untuk mengilustrasikan bagaimana caching dapat meningkatkan performa, mari kita buat perumpamaan. Bayangkan Anda sedang memperbaiki rumah. Untuk melakukannya, Anda membutuhkan beberapa perkakas. 

Waktu tempuh rata-rata ke toko perkakas ini adalah sekitar 30 menit. Jika setiap kali membutuhkan perkakas Anda perlu ke toko tersebut, maka tentu ini akan sangat memakan waktu.

Nah, sekarang bayangkan jika Anda memiliki gudang perkakas atau toko perkakas tersebut membuka cabang di depan kompleks rumah Anda. Karena hal ini, waktu tempuh rata-rata menjadi turun drastis menjadi sekitar 2 menit saja, sangat menyingkat waktu, bukan?

Dalam komputasi, cache adalah lapisan penyimpanan data berkecepatan tinggi yang menyimpan subset data, biasanya bersifat sementara, sehingga permintaan di masa mendatang untuk data tersebut disajikan lebih cepat daripada mengakses lokasi penyimpanan utama data. Caching memungkinkan Anda untuk menggunakan kembali data yang sudah pernah diambil atau dihitung secara efisien.

Apa yang harus di-cache?

Setelah memahami apa itu caching, mungkin akan muncul suatu pertanyaan di benak Anda, “Apa saja yang harus saya cache?” Perhatikan, hal-hal atau data dengan sifat di bawah ini adalah kandidat yang baik untuk di-cache.

• Data yang membutuhkan query kompleks dan waktu proses lama.
• Data yang relatif statis dan sering diakses, contohnya profil dari media sosial perusahaan Anda.
• Informasi yang valid untuk jangka waktu relatif panjang, misalnya laporan kegiatan CSR (Corporate Social Responsibility) perusahaan atau laporan keuangan.

INGAT! Mendapatkan data dari database selalu lebih lambat dan mahal daripada cache. Terlebih pada query database yang dilakukan secara inheren seperti melakukan penggabungan (join) di beberapa tabel.

Maka dari itu, data yang diambil dengan cara yang mahal dan lambat menjadi kandidat kuat untuk menyimpan di dalam cache. Walaupun demikian, data yang memerlukan query cepat dan sederhana pun masih bisa menjadi kandidat untuk caching, bergantung pada faktor lain.

Keuntungan Melakukan Caching

Ada banyak keuntungan yang akan Anda dapatkan saat melakukan caching. Ketahuilah! Cache dapat memberikan throughput tinggi dan akses latensi rendah ke data aplikasi yang sering diakses, dengan menyimpan data dalam memori. Tak hanya itu, dengan caching, Anda juga dapat mengurangi beban query database yang memakan waktu. Inilah yang sering kali menyebabkan kemacetan dalam aplikasi. 

Untuk query atau aplikasi yang sering melakukan operasi read (baca) secara intensif, caching dapat memberikan peningkatan kinerja yang signifikan dengan mengurangi waktu pemrosesan aplikasi dan waktu akses database.

Jenis Caching 

Terdapat beberapa jenis teknik dalam melakukan caching, ada client side (sisi klien) dan server side (sisi server). Untuk memahami keduanya, mari kita ambil contoh kasus web caching. Web caching dilakukan dengan menyimpan HTTP response dan web resources ke dalam cache (penyimpanan sementara) dengan tujuan untuk memenuhi permintaan di masa mendatang langsung dari cache, bukan dari server asal. 

Mari kita bahas dari level yang paling dasar, yakni client-side web caching (web caching di sisi klien). 

Pada client-side web caching, alih-alih melakukan kueri berulang kali ke web server, data dapat disimpan sementara di browser. Metodologi caching didasarkan pada HTTP header directives yang disediakan oleh HTTP response dari server asal ke browser. HTTP cache header memberikan detail tentang berapa lama browser dapat menyimpan data di cache. Data tersebut akan digunakan untuk memberikan respons di masa mendatang. Sehingga konten web tidak perlu lagi mengambil dari sumber aslinya (dalam kurun waktu tertentu), yakni web server.

Sedangkan pada sisi server, terdapat berbagai teknik web caching yang bisa digunakan untuk meningkatkan kinerja sebuah website, contohnya reverse proxy cache. Reverse proxy cache dapat ditempatkan di depan aplikasi dan web server untuk menyediakan cache dari HTTP response yang disimpan dari keduanya. Cache ini diimplementasikan oleh administrator dan bertindak sebagai perantara antara browser dan server origin. Reverse proxy cache juga biasanya digunakan pada HTTP cache directives.

Caching di AWS

Untuk memahami caching di AWS, silakan amati gambar di bawah yang menunjukkan perjalanan data untuk sebuah aplikasi. Walaupun pada gambar di bawah menampilkan arsitektur 3-tier, sebenarnya model ini berlaku untuk arsitektur apa pun. 

Dalam sebuah aplikasi dengan akses publik/internet, umumnya saat user berinteraksi dengan aplikasi itu, maka data akan berjalan seperti pada gambar di atas. 

Misalnya dalam skenario promosi produk terbaru kita, yakni “Kopi Macchiato Rasa Durian” User yang tertarik akan mengeklik halaman dari website. Atau, jika Startup kita memiliki mobile app, maka user akan mengeklik halaman di mobile app. 

Berkaca dari gambar di atas, bagian pertama yang akan terdampak pada interaksi ini adalah Internet/Edge, misalnya firewall atau perangkat lain di data center AWS maupun on-premise. Selanjutnya, interaksi ini akan diteruskan ke front-end web. Setelah itu diteruskan ke Application Layer dan kemudian mengolah data yang diambil dari database.

Dalam sebuah arsitektur aplikasi, keseluruhan poin interaksi di atas merupakan titik yang potensial terjadi perlambatan. Di AWS, keseluruhan poin interaksi tersebut memiliki potensi untuk dilakukan teknik-teknik caching guna mempercepat respons pada skala cloud. Mari kita bedah.

Web Caching

Bagian pertama dari poin interaksi adalah bagian Internet/Edge dan Web. Gambar di bawah menunjukkan cakupan dari Edge Caching.

Catatan: Pada kelas ini kita tidak akan membahas bagian Users, tentu saja ada teknik-teknik caching yang bisa dilakukan, tetapi itu tidak termasuk cakupan dari kelas ini.

Edge Caching dengan Amazon CloudFront

Saat pengguna aplikasi Anda tersebar secara global, tentu akan sulit dan mahal untuk mereplikasi seluruh infrastruktur di seluruh dunia. 

Content Delivery Network (CDN) memberi Anda kemampuan untuk menggunakan jaringan global dari edge location guna mengirimkan salinan konten web dalam cache (seperti video, halaman web, gambar, dan sebagainya) kepada pelanggan Anda. 

Untuk mengurangi waktu respons, CDN menggunakan edge location terdekat dari pelanggan atau lokasi permintaan asal. Dengan demikian, throughput pun akan meningkat mengingat web asset dikirim dari cache.

Untuk layanan CDN di AWS, Anda bisa menggunakan Amazon CloudFront. Amazon CloudFront adalah layanan CDN global yang mempercepat pengiriman situs web, API, konten video, atau aset web Anda lainnya. Layanan ini terintegrasi dengan produk AWS lainnya untuk memberi developer dan bisnis cara yang mudah dalam mempercepat pengiriman konten ke pengguna tanpa minimum requirement.

Amazon CloudFront memberikan fleksibilitas yang luas untuk mengoptimalkan cache behavior, ditambah dengan optimasi jaringan untuk latensi dan throughput. Content Delivery Network (CDN) menawarkan multi-tier cache secara default dengan Regional Edge Caches yang memperbaiki latensi dan menurunkan beban di server origin Anda saat objek belum di-cache di Edge.

CloudFront juga memiliki kemampuan untuk menyajikan data dinamis dari Custom Origin, misalnya dari EC2 web server.

Seperti layanan AWS lainnya, CloudFront menawarkan layanan mandiri, bayar sesuai penggunaan, dan tidak memerlukan komitmen jangka panjang atau biaya minimum.

Cara Kerja Caching di Amazon CloudFront

Sekarang, mari kita belajar tentang bagaimana caching bekerja di Amazon CloudFront.

Saat pengguna me-request konten yang Anda sajikan dengan CloudFront, pengguna tersebut akan diarahkan ke edge location yang menyediakan latensi terendah. Dengan demikian, konten dapat dikirim dengan performa terbaik. 

Nah, jika konten sudah berada di edge location dengan latensi terendah, maka CloudFront akan segera mengirimkannya. Namun jika konten tidak berada di edge location tersebut, CloudFront akan mengambilnya dari Amazon S3 bucket atau HTTP server (misalnya web server) yang telah Anda identifikasi sebagai sumber untuk konten Anda.

Untuk memahami cara kerja Amazon CloudFront, silakan amati gambar di bawah ini.

Pada contoh di atas menjelaskan bahwa:

• Jika konten tidak disimpan dalam cache, maka objek yang diminta akan diambil dari sumber (origin). Langkah 1, 2, 3, dan 4 dilakukan untuk mengambil dan mengembalikan data yang diminta oleh pengguna.
• Namun, jika konten di-cache, maka permintaan objek yang di-cache diarahkan ke edge location paling optimal dan objek yang di-cache diambil seperti yang ditunjukkan pada langkah 1 dan 4.

Dengan teknologi caching dan akselerasi dari CloudFront, AWS dapat mengirimkan semua konten Anda, dari gambar statis hingga konten yang diinput oleh pengguna Anda.

Gambar di atas menunjukkan apa saja yang dapat di-cache oleh CloudFront untuk meningkatkan response time dari aplikasi, antara lain:

• Static : Gambar, JS, HTML, dll dengan time-to-live (TTL) yang tinggi.
• Video : Dukungan RTMP dan HTML streaming.
• Dynamic : Konten kustomisasi dan tidak dapat di-cache.
• User input : Dukungan HTTP action, termasuk PUT/POST.
• Secure : Menyajikan konten secara aman dengan SSL (HTTPS).

Konfigurasi Amazon CloudFront

Setelah belajar mengenai Amazon Cloudfront beserta cara kerjanya, sekarang mari kita pahami cara untuk mengonfigurasi CloudFront. Silakan amati gambar berikut:

Mari kita jabarkan poin-poin pada gambar di atas.

1. Anda menentukan origin server (server asal), seperti Amazon S3 bucket atau HTTP server Anda sendiri, intinya adalah tempat di mana CloudFront mendapatkan file Anda. File ini akan didistribusikan ke CloudFront edge location di seluruh dunia.
   Origin server menyimpan versi asli dari objek Anda. Jika Anda menyajikan konten melalui HTTP, maka origin server Anda adalah antara Amazon S3 bucket atau HTTP server (seperti web server).
   HTTP server Anda dapat berjalan di Amazon EC2 instance atau di server on-premise yang Anda kelola. Server ini juga dikenal sebagai custom origin.
   
   

2. Anda membuat distribution yang memberi tahu CloudFront, origin server mana untuk mendapatkan file Anda saat pengguna memintanya melalui website atau aplikasi. Pada saat yang sama, Anda menentukan detail, misalnya apakah Anda ingin CloudFront mencatat semua permintaan dan apakah Anda ingin distribusi diaktifkan segera setelah dibuat.
   
   

3. CloudFront memberikan nama domain untuk CloudFront distribution baru Anda.
   
   

4. CloudFront mengirimkan konfigurasi distribution Anda (tetapi tidak dengan kontennya) ke semua edge location. Edge location merupakan kumpulan server di data center yang tersebar secara geografis. Di dalam Edge Location inilah  CloudFront menyimpan salinan objek Anda dalam cache.

Itulah beberapa langkah untuk mengonfigurasi Amazon CloudFront. Mari kita lanjut ke materi berikutnya.

Cara Membuat Konten Menjadi Expire

Setelah menerapkan caching, lantas bagaimana cara memastikan file yang disimpan pada edge location selalu up to date? Tentu Anda tidak mau kan pengguna mengakses informasi yang sudah expire (kedaluwarsa)? Solusinya, Anda perlu belajar bagaimana cara agar CloudFront mengetahui konten yang sudah expire.

Berikut adalah beberapa metode yang dapat Anda gunakan untuk membuat konten menjadi expire di CloudFront:

1. Time to Live (TTL)
   • Periode waktunya tetap alias fixed (periode expire).
   • Dikonfigurasi oleh ANDA.
   • GET request ke origin dari CloudFront akan menggunakan If-Modified-Since header.
2. Mengubah Object Name 
   • Contoh: Header-v1.jpg menjadi Header-v2.jpg.
   • Nama baru akan memaksa refresh.
3. Invalidate object
   • Menghapus objek dari cache sebelum ia expire. Sehingga ketika pengguna mengakses objek, ia akan langsung diarahkan ke origin server.
   • Langkah ini sangat tidak efisien dan mahal karena memaksa sistem untuk berinteraksi pada seluruh edge location. 

Dari ketiga cara di atas, dua cara pertama sering digunakan karena cukup mudah diimplementasikan. Sementara itu, cara ketiga (invalidate objek) sebaiknya dilakukan sebagai cara terakhir. Untuk keterangan lebih lanjut dapat Anda baca di halaman dokumentasi Request and Response Behavior for Amazon S3 Origins yang disediakan AWS.

Contoh Arsitektur

Secara umum, Anda hanya menyimpan konten statis dalam cache. Tetapi tergantung pada bagaimana aplikasi bekerja, Anda bisa mendapatkan beberapa peningkatan kinerja dengan melakukan caching untuk konten dinamis atau unik di Amazon S3.

Pada arsitektur di atas, kita menggunakan CloudFront untuk mendistribusikan konten ke pengguna. Untuk konten yang dinamis CloudFront mengambilnya dari EC2, sedangkan konten statis di Amazon S3. Ada beberapa langkah yang bisa Anda lakukan untuk menyimpan konten statis, antara lain:

• Buat referensi URL absolut untuk aset statis Anda, bukan URL relatif.
• Simpan aset statis di Amazon S3.
• Optimalkan untuk "Write Once Read Many".

Selain itu, Anda dapat membatasi geografis konten Anda. Pembatasan geografis (dikenal juga sebagai geoblocking/geo-restriction) mencegah pengguna di lokasi geografis tertentu mengakses konten yang Anda distribusikan melalui CloudFront web distribution. Untuk menggunakan pembatasan geografis, Anda memiliki dua opsi, di antaranya:

• Gunakan fitur CloudFront geo-restriction untuk membatasi akses ke semua file yang terkait dengan distribution dan juga membatasi akses di tingkat negara.
• Gunakan layanan geolokasi pihak ketiga untuk membatasi akses ke subset file yang terkait dengan distribution atau membatasi akses pada perincian yang lebih baik daripada tingkat negara.

Caching Web Tier

Mari kita lihat kembali gambar perjalanan data kita. Sebelumnya kita telah membahas bagaimana edge caching menggunakan Amazon CloudFront, sekarang mari kita lihat caching di web tier.

Session Management

Session Management mungkin tidak tampak sebagai metode caching, tetapi sebenarnya ia termasuk. Pada dasarnya, web session adalah urutan dari HTTP transactions dari pengguna yang sama ke suatu lingkungan. 

HTTP dirancang untuk mentransfer dokumen, bukan mengelola state (kondisi) karena setiap request tidak tergantung pada transaksi sebelumnya. 

Apakah Anda benar-benar ingin orang mengirim kredensial untuk setiap request yang dibuat ke server Anda? Apakah server Anda memiliki jaringan dan daya komputasi yang diperlukan untuk meningkatkan skala seiring meningkatnya pengguna dan kebutuhan? Nah, AWS menawarkan solusinya untuk Anda. Simak di pembahasan selanjutnya!

Menggunakan Load Balancer

Session management adalah autentikasi dan kontrol akses. Pendekatan umum untuk mengelola state salah satunya adalah menggunakan sticky session atau cache terdistribusi.

Sticky Session (disebut juga session affinity) memungkinkan Anda untuk mengarahkan permintaan ke server tertentu yang mengelola user session (sesi pengguna). Validitas session dapat ditentukan dengan sejumlah metode, seperti client-side cookies atau parameter yang diatur di load balancer.

Sticky Session juga hemat biaya karena Anda menyimpan session di web server yang menjalankan aplikasi. Ini menghilangkan latensi jaringan dan mempercepat pengambilan session tersebut. Namun jika terjadi kegagalan, kemungkinan besar Anda akan kehilangan session yang disimpan di node

Database Caching

Di bagian sebelumnya kita mempelajari teknik caching di bagian Front End dari aplikasi. Saat ini kita masuk ke bagian selanjutnya atau sering disebut sebagai bagian Back-End.

Database caching adalah teknik di mana kita menyimpan atau mengambil data persisten yang sering diakses oleh user. Lalu, muncul suatu pertanyaan, “Kapan database caching dilakukan?” 

Jawabannya, kita melakukan database caching saat ada kebutuhan seperti di bawah ini.

Menyimpan Session di DynamoDB

Sering kali, kita ada keperluan untuk menyimpan state atau kondisi dari user di database. Kemudian kita ambil state tersebut untuk digunakan kembali saat user login. Teknik ini kritikal dan biasanya digunakan pada situs gaming online, terutama yang dimainkan secara masif.

DynamoDB adalah solusi NoSQL database dari AWS yang sangat cepat dan scalable sehingga dapat memberikan respons cepat pada tingkat milidetik. Dengan menggunakan DynamoDB, aplikasi Anda mendapatkan kemampuan untuk menyimpan data secara persisten dan dapat diakses oleh banyak instance web server Anda. Sehingga DynamoDB cocok digunakan untuk menyimpan dan mendapatkan state pada website gaming online.

DynamoDB Accelerator (DAX)

Bagaimana jika layanan Anda membutuhkan respons super cepat pada tingkat microseconds? Misalnya, promosi Kopi Macchiato Rasa Durian Anda sangat berhasil, bahkan teknik caching sebelumnya masih juga kurang cepat memenuhi kebutuhan bisnis/pengguna.

Nah, untuk keadaan di mana respons microseconds dari data DynamoDB dibutuhkan, maka Anda perlu mempertimbangkan untuk menggunakan DynamoDB Accelerator (DAX).

DAX adalah layanan cache yang kompatibel dengan DynamoDB. Layanan ini memungkinkan Anda memanfaatkan kinerja dalam memori (in-memory) yang cepat untuk aplikasi yang menuntut kinerja super tinggi.

DAX sepenuhnya terintegrasi dengan layanan AWS untuk meningkatkan keamanan. Anda dapat menggunakan AWS Identity and Access Management (IAM) untuk menetapkan kredensial keamanan unik ke setiap pengguna dan mengontrol akses setiap pengguna ke layanan dan sumber daya. Anda bisa menggunakan Amazon CloudWatch untuk mendapatkan visibilitas ke seluruh sistem dalam hal penggunaan sumber daya, kinerja aplikasi, dan kesehatan operasional. 

Anda juga bisa mengintegrasikan DAX dengan AWS CloudTrail guna memungkinkan Anda dengan mudah mencatat dan mengaudit perubahan pada konfigurasi DAX cluster. Selain itu, DAX mendukung Amazon Virtual Private Cloud (VPC) untuk akses yang aman dan mudah dari aplikasi yang Anda miliki. 

Jangan lupa, berikan tag agar Anda dapat memiliki visibilitas tambahan untuk membantu mengelola DAX cluster Anda.

Sama dengan teknik caching lainnya, DAX sebaiknya digunakan untuk menyimpan data query dari DynamoDB yang sering diakses oleh pengguna. Pengambilan data cache mengurangi beban read (baca) pada tabel DynamoDB yang ada. Artinya, ini dapat mengurangi kapasitas read yang disediakan dan menurunkan biaya operasional secara keseluruhan.

Amazon ElastiCache

DAX hanya mendukung DynamoDB sebagai database-nya, lalu bagaimana bila Anda tidak menggunakan DynamoDB? Tenang, AWS selalu punya solusi, perkenalkan Amazon ElastiCache!

Amazon ElastiCache adalah layanan web yang memudahkan Anda untuk men-deploy dan menjalankan node server yang sesuai dengan protokol Memcached atau Redis di cloud. 

Amazon ElastiCache dapat meningkatkan kinerja aplikasi web dengan memungkinkan Anda mengambil informasi dari sistem in-memory (dalam memori) yang cepat dan terkelola, bukan mengandalkan database berbasis disk yang lebih lambat. 

Dengan menggunakan Amazon ElastiCache, Anda tidak hanya dapat meningkatkan waktu load dan respons untuk tindakan dan kueri pengguna, tetapi juga mengurangi biaya yang terkait dengan scaling aplikasi web.

ElastiCache memberikan layanan in-memory cache untuk Redis dan Memcache. Redis dan Memcache adalah engine (mesin) untuk penyimpanan data in-memory yang populer dan open-source. 

Meskipun keduanya mudah digunakan dan menawarkan performa tinggi, ada perbedaan penting yang perlu dipertimbangkan saat memilih engine. Memcache dirancang untuk kesederhanaan, sementara Redis menawarkan serangkaian fitur kaya yang membuatnya efektif untuk berbagai kasus penggunaan.

Tabel di bawah ini ini menunjukkan perbedaan fitur antara Redis dan Memcache.

	Memcached	Redis
Latency tingkat sub milidetik	Yes	Yes
Mudah Digunakan Developer	Yes	Yes
Pemisahan (partitioning) data	Yes	Yes
Mendukung banyak bahasa pemrograman	Yes	Yes
Struktur data tingkat lanjut	-	Yes
Arsitektur multi threading	Yes	-
Snapshot	-	Yes
Replikasi	-	Yes
Transaksi	-	Yes
Pub/Sub	-	Yes
Scripting LuA	-	Yes
Dukungan Geospatial	-	Yes
Scaling horizontal untuk writes / storage	Yes	No*
Multi-availability Zone dengan failover otomatis	No	Yes
Backup dan Restore	No	Yes

* Redis dengan mengaktifkan mode cluster akan melakukan scaling saat permintaan pada cluster Anda berubah

Strategi untuk Caching Database 

Terdapat beberapa strategi yang bisa Anda lakukan dalam melakukan caching database, ada write through, lazy loading, dan menambahkan TTL. Mari kita bahas satu per satu.

Write Through

Pada strategi Write Through, data ditambahkan atau diperbarui di dalam cache setiap kali data ditulis ke database.

Saat menggunakan strategi Write Through, Anda akan mendapatkan beberapa keuntungan, salah satunya adalah data di cache tidak akan akan pernah usang. Ini karena data di cache diperbarui setiap kali ditulis ke database, sehingga data akan di cache selalu terkini.

Walaupun demikian, strategi Write Through juga memiliki beberapa kekurangan, yaitu:

• Biaya write : Setiap proses write melibatkan dua perjalanan, yakni write ke cache dan ke database.
• Data yang hilang : Saat node baru dibuat untuk memperbarui atau mengganti node yang hilang, node tersebut tersebut tidak berisi semua data. Data akan akan terus hilang hingga ada penambahan atau pembaharuan data dalam database. Dalam skenario ini, Anda mungkin memilih untuk menggunakan pendekatan Lazy Loading guna mengisi kembali cache.
• Data yang tidak digunakan : Karena sebagian besar data tidak pernah di-read, mungkin ada banyak data di cluster yang tidak pernah di-read juga.
• Cache churn : Tingkat perubahan cache yang tinggi jika record tertentu sering kali diperbarui.

Lazy Loading

Lazy Loading adalah strategi caching yang memuat data ke dalam cache hanya jika benar-benar diperlukan. Dalam penerapan ini, ElastiCache berada di antara aplikasi Anda dan database yang diaksesnya. 

Setiap kali aplikasi Anda me-request data, aplikasi itu terlebih dahulu membuat permintaan ke ElastiCache cache. Jika data tersebut terdapat di cache dan merupakan data terkini, maka ElastiCache mengembalikan data langsung ke aplikasi (cache hit). Jika tidak, aplikasi akan me-request data dari penyimpanan data dan kemudian barulah data tersebut dikembalikan ke aplikasi Anda. Terakhir, aplikasi Anda akan menulis/write data yang barusan diterima ke cache sehingga dapat diambil lebih cepat lagi ada kebutuhan yang lain.

Dengan Lazy Loading, hanya data yang diminta sajalah yang akan disimpan dalam cache. Karena sebagian besar data tidak pernah di-request, Lazy Loading menghindari pengisian cache dengan data-data yang tidak perlu. Namun, ada cache miss penalty (waktu ekstra karena cache tidak ditemukan). Di mana setiap cache miss membutuhkan tiga perjalanan bolak-balik, inilah yang dapat menyebabkan penundaan dalam pengambilan data ke aplikasi. 

Selain itu, jika data hanya ditulis saat ada cache yang tidak ditemukan (cache miss), maka data di cache bisa menjadi usang karena tidak ada pembaruan ke cache saat data diubah pada database.

Adding TTL

Strategi Lazy Loading memungkinkan data menjadi usang, sementara Write Through memastikan bahwa data selalu segar, tetapi dapat mengisi cache dengan data yang tidak perlu.

Nah dengan menambahkan time to live alias TTL ke setiap penulisan/proses write, Anda akan mendapat keuntungan dari setiap strategi dan menghindari kekacauan cache dengan data.

TTL adalah nilai integer yang menentukan jumlah detik atau milidetik (bergantung pada in-memory engine), hingga nilai tersebut expire (kedaluwarsa). 

Saat aplikasi mencoba membaca nilai yang expire, data di cache akan diperlakukan seolah-olah tidak ditemukan. Itu berarti, aplikasi akan melakukan request ke database dan cache pun diperbarui. Dengan demikian, data akan terjaga agar tidak terlalu usang dan mengharuskan nilai di dalam cache sesekali disegarkan dari database.

Arsitektur AWS Cloud: Web Hosting

Sampai saat ini, kita telah belajar banyak hal dan mengenal beberapa layanan AWS. Sekarang mari kita lihat contoh arsitektur yang mengimplementasikan layanan-layanan yang telah dibahas sebelumnya, yaitu dalam kasus web hosting.

Arsitektur web hosting tradisional biasanya menerapkan model aplikasi web three tier yang memisahkan arsitektur menjadi lapisan presentation (front-end), application (back-end), dan persistence (database). Skalabilitas terwujud dengan menambahkan host pada setiap lapisan tersebut.

Hosting aplikasi web di AWS Cloud

Dengan AWS, arsitektur web hosting tradisional dapat dipindahkan ke cloud dengan mudah hanya dengan sedikit modifikasi. 

Jika Anda memutuskan bahwa cloud adalah solusi yang tepat, maka Anda memerlukan arsitektur yang sesuai. Berikut adalah arsitektur umum untuk meng-hosting aplikasi web beserta penggunaan layanan-layanan AWS secara terpadu.

Mari kita jabarkan setiap layanan AWS yang digunakan dalam arsitektur di atas.

• Amazon Route 53 menyediakan layanan DNS dan juga berfungsi untuk menyederhanakan manajemen domain.
• Amazon CloudFront menyediakan edge caching untuk konten dengan banyak permintaan.
• Elastic Load Balancing mendistribusikan lalu lintas ke web server Auto Scaling group dalam gambar di atas.
• Exterior Firewall diterapkan ke setiap web server melalui security group.
• Backend Firewall diterapkan ke setiap instance back-end menggunakan security group.
• App server load balancer pada Amazon EC2 instance mendistribusikan lalu lintas ke app server cluster.
• Amazon ElastiCache menyediakan layanan cache untuk aplikasi, yang mana akan mengurangi beban pada database.

Ikhtisar

Di modul ini kita telah mempelajari mengenai Caching. Caching dapat dilakukan di semua poin interaksi sebuah aplikasi modern. Cakupan modul ini ditunjukkan pada gambar berikut:

Mari kita jabarkan setiap poin-poinnya:

• Caching di tingkat Internet/Edge dapat dilakukan dengan menggunakan Content Distribution Network atau CDN. AWS menawarkan Amazon CloudFront yang merupakan layanan CDN tingkat dunia yang tersebar pada banyak lokasi di seluruh dunia.
• Di tingkat web server, caching juga dapat dilakukan pada load balancer dengan menggunakan Session Management.
• Selanjutnya, kita juga telah mempelajari teknik caching dengan menyimpan data yang sering diakses menggunakan in-memory caching. Amazon menawarkan dua jenis in-memory cache, yaitu DAX (DynamoDB Accelerator) atau ElastiCache.
• Terakhir, kita sudah mempelajari bagaimana menggunakan Arsitektur Cloud AWS beserta komponen-komponennya dapat digunakan untuk membangun aplikasi web secara optimal.

Masih ada beberapa langkah lagi dalam menyelesaikan kelas ini. Jadi, tetap semangat ya!

Pengantar ke Membangun Decoupled Architecture

Tak terasa ya sudah sejauh ini perjalanan kita di kelas Architecting on AWS ini. Sekarang, arsitektur untuk startup warung kopi Anda sudah mendukung ratusan ribu pengguna. Luar biasa! 

Tapi, tunggu! Masih ada kemungkinan bahwa arsitektur kita kurang sempurna. Misal, ketika satu komponen mengalami kegagalan, seluruh aplikasi kita akan gagal beroperasi. Maka dari itu, Anda perlu menghilangkan ketergantungan (dependencies) yang terikat erat antar komponen aplikasi. Nah, tenang. Di modul ini kita akan belajar bagaimana membangun decoupled architecture.

Berikut adalah beberapa hal yang akan kita pelajari:

• Cara membangun decoupled architecture.
• Menggunakan Amazon SQS dan Amazon SNS untuk membangun decoupled architecture.

Oke. Untuk memahami arti dari decoupled architecture, kita harus mengenal terlebih dahulu tentang tightly coupled dan loosely coupled. Mari kita awali dengan tightly coupled.

Design dari infrastruktur tradisional umumnya terdiri dari server-server (dengan fungsinya masing-masing) yang terintegrasi secara erat. Inilah yang menyebabkan hal fatal terjadi ketika salah satu komponen/lapisan tersebut mati. Selain itu, ini menghalangi arsitektur kita untuk melakukan scaling. Jika Anda menambah atau menghapus server pada satu lapisan, setiap server di setiap lapisan juga harus terhubung dengan benar. Contoh arsitektur tradisional digambarkan pada ilustrasi di bawah ini.

Pada gambar di atas, setiap komponen terikat sangat erat antara satu sama lain. Inilah yang menyebabkan ketergantungan. Sehingga jika salah satu komponen gagal, komponen lain juga akan ikut mengalami kegagalan. Itulah yang dimaksud dengan tightly coupled. 

Nah, karena arsitektur di atas termasuk tightly coupled, maka perlu dilakukan decoupling. Decoupling mengacu pada komponen yang tetap independen dan otonom satu sama lain saat mereka menyelesaikan pekerjaannya untuk menghasilkan keluaran yang lebih baik. Maka dari itu, Anda harus menghilangkan ketergantungannya agar jika nanti terjadi perubahan atau kegagalan pada satu komponen tidak akan berdampak pada komponen lain.

Salah satu langkah yang dapat Anda lakukan untuk memisahkan arsitektur adalah dengan menambahkan komponen baru yaitu Load Balancer. 

Load Balancer membantu Anda dalam menangani pertumbuhan permintaan akan sumber daya dengan menyeimbangkan beban yang datang ke sekumpulan server. Anda tentunya ingat sudah mempelajari elasticity dan Auto Scaling sebelumnya, bukan?

Tetapi perlu diperhatikan, jika dalam memproses order (misalnya) aplikasi Anda masih harus menunggu proses penulisan/pengambilan data dari database, maka secara proses arsitektur ini masih tightly coupled. Jangan terjebak ya.

Kembali ke skenario startup warung kopi. Katakanlah desain arsitektur di atas adalah yang dipakai pada aplikasi web startup kita untuk memproses pesanan pelanggan. Biasanya, salah satu titik potensial terjadinya kerentanan adalah pada proses menyimpan pesanan di dalam database yang dilakukan oleh App Tier. Nah, dalam proses tersebut, tentu Anda mengharapkan bahwa setiap pesanan dapat disimpan ke dalam database tanpa masalah, bukan? 

Namun ketahuilah, potensi terjadinya masalah yang menyebabkan kegagalan saat menyimpan pesanan di database itu tetaplah ada. Bila masalah terjadi, pesanan akan hilang tanpa ada cara untuk memulihkannya. Lantas, bagaimana mengatasi hal ini? Simak pembahasan di materi berikutnya!

Decoupling Arsitektur Anda dengan Amazon SQS

Berdasarkan permasalah sebelumnya, salah satu hal yang bisa kita lakukan adalah dengan melakukan decoupling (pemisahan) arsitektur menggunakan Amazon SQS.

Amazon Simple Queue Service (Amazon SQS) adalah layanan terkelola sepenuhnya yang hemat biaya dan hanya memerlukan sedikit konfigurasi. Layanan ini bekerja dalam skala besar, ia mampu memproses jutaan pesan per hari. 

Amazon SQS menyimpan semua antrean pesan dalam satu AWS Region yang highly available (selalu tersedia) dengan beberapa Availability Zone yang redundant. Sehingga tidak ada kegagalan komputer, jaringan, atau Availability Zone yang dapat membuat pesan tidak dapat diakses. Pesan dapat dikirim dan dibaca secara bersamaan.

Developer dapat dengan aman membagikan Amazon SQS queue secara anonim atau dengan akun AWS tertentu. Berbagi queue juga dapat dibatasi oleh alamat IP dan waktu. 

Server-side encryption (SSE) akan melindungi konten pesan dalam Amazon SQS queue menggunakan key yang dikelola di AWS Key Management Service (AWS KMS). SSE mengenkripsi pesan segera setelah Amazon SQS menerimanya. Pesan yang disimpan akan terenkripsi dan Amazon SQS mendekripsinya hanya jika dikirimkan ke konsumen yang terotorisasi.

Dengan menggunakan Amazon SQS, maka kita akan mendapatkan beberapa manfaat. Silakan liat gambar di bawah ini.

Jenis-Jenis SQS queue

Amazon SQS memiliki dua jenis queue, yakni Standard dan FIFO. Apa perbedaan di antara keduanya? Mari kita jabarkan.

• Standard queue menawarkan pengiriman setidaknya sekali (at-least-once delivery) dan pengurutan dengan sekadarnya (best-effort ordering).

  • At-Least-Once Delivery, berarti terkadang lebih dari satu salinan pesan terkirim.

  • Best-Effort Ordering, berarti terkadang pesan dikirim dalam keadaan yang tidak berurutan.

• FIFO queue (first in, first out) dirancang untuk menjamin bahwa pesan diproses tepat satu kali dengan urutan yang sama persis seperti saat dikirim.
   

Standard queue menawarkan throughput maksimum, sementara FIFO queue mendukung hingga 300 pesan per detik (300 operasi kirim, terima, atau hapus per detik). Saat Anda mengumpulkan 10 pesan per operasi (maksimum), FIFO queue dapat mendukung hingga 3000 pesan per detik.

Contoh Kasus Penggunaan SQS

Setelah mempelajari tentang Amazon SQS dan jenis-jenis queue yang dimilikinya, mari kita lihat beberapa contoh kasus penggunaannya. Ada banyak cara berbeda untuk menggunakan SQS queue, seperti work queue, buffer batch operations, request offloading, dan scaling trigger.

 Mari kita kupas satu per satu berdasarkan gambar di atas.

• Work queue (antrean pekerjaan) : Dengan Amazon SQS, Anda bisa memisahkan komponen aplikasi terdistribusi, sehingga aplikasi Anda tidak harus memproses sejumlah pekerjaan yang sama secara bersamaan.

• Buffer batch operations (buffer/penyangga pada proses batch) : Gunakan Amazon SQS untuk menambahkan skalabilitas dan keandalan pada arsitektur Anda. Dengannya, Anda bisa menambahkan volume sementara, sehingga akan terhindar dari risiko kehilangan pesan atau terjadinya latensi yang tinggi.

• Request offloading (Memindahkan proses) : Pindahkan operasi yang lambat dari jalur permintaan interaktif dengan mengantrekan request/permintaan.

• Auto Scaling trigger (pemicu Auto Scaling) : Gunakan Amazon SQS queue untuk membantu menentukan beban pada aplikasi. Saat terintegrasi dengan Auto Scaling, Anda dapat melakukan scaling out atau scaling in pada Amazon EC2 instance bergantung pada volume lalu lintas.

Bagaimana, mulai tertarik menggunakan Amazon SQS pada arsitektur Anda? Tunggu, kita belum sempat membahas fitur-fiturnya. Simak pada materi berikutnya!

Fitur-Fitur Amazon SQS

Amazon SQS memiliki beberapa fitur menarik untuk kita gunakan. Perhatikan gambar berikut yang menjelaskan fitur-fitur dari SQS.

Agar lebih jelas, mari kita uraikan satu per satu.

• Dukungan Dead Letter Queue
  Dead letter queue (DLQ) adalah antrean pesan yang tidak dapat diproses. DLQ menerima pesan setelah jumlah upaya pemrosesan maksimum tercapai. Pesan dapat dikirim dan diterima dari DLQ seperti SQS queue lainnya. Anda dapat membuat DLQ dari SQS API dan SQS console.
  
  Tugas utama DLQ adalah menangani kegagalan pesan. DLQ berguna untuk men-debug aplikasi atau sistem perpesanan Anda, karena melalui DLQ, Anda dapat mengisolasi pesan yang bermasalah agar dapat dianalisis guna mencari tahu alasan mengapa pemrosesannya tidak berhasil.
  
  

• Visibility Timeout
  Visibility timeout adalah periode waktu di mana pesan menjadi "tidak terlihat" oleh server/aplikasi Anda yang lain setelah komponen aplikasi mendapatkannya dari queue. Selama visibility timeout, komponen yang menerima pesan akan memproses dan menghapusnya dari queue. Ini berguna untuk mencegah beberapa komponen memproses pesan yang sama.
  
  Ketika aplikasi membutuhkan lebih banyak waktu untuk pemrosesan, batas waktu "invisible/tak terlihat" dapat Anda modifikasi.
  
  

• Long Polling
  Long polling adalah cara untuk mengambil pesan dari Amazon SQS queue Anda. Long polling dapat mengurangi jumlah respons kosong dengan mengizinkan Amazon SQS menunggu waktu sedikit lama agar pesan benar-benar tersedia dalam antrean sebelum mengirim respons.
  
  Secara default, short polling akan selalu melakukan pemeriksaan segera, bahkan jika antrean pesan yang sedang di-polling tersebut kosong. Namun, long polling tidak mengembalikan respons seketika hingga pesan tiba di antrean atau waktu long polling habis.
  
  Long polling membuat pengambilan pesan dari Amazon SQS queue Anda lebih murah, karena pemeriksaan pesan dilakukan hanya setelah pesan tersedia.
  
  

Contoh Decoupling Arsitektur dengan Amazon SQS

Oke, kita telah belajar mengenai Amazon SQS. Tapi, tak afdal rasanya jika tidak melihat contoh penggunaan Amazon SQS untuk memisahkan arsitektur (decoupling architecture), bukan? Bahkan, Anda juga dapat memanfaatkan SQS queue untuk membantu meningkatkan aplikasi pemesanan Anda. 

Perhatikan gambar di bawah ini.

Dengan menggunakan queue, Anda dapat mengisolasi setiap proses pesanan ke dalam komponen independen yang berjalan secara terpisah dari Web app. Dengan demikian, hal ini membuat arsitektur Anda menjadi lebih tahan terhadap lonjakan traffic. Bahkan, memungkinkan setiap proses pesanan dilakukan dengan lebih cepat sehingga bisa menghemat biaya.

Selain itu, Anda sekarang memiliki mekanisme untuk menyimpan pesanan dalam antrean (di mana queue bertindak sebagai database sementara) sehingga meringankan beban kerja database Anda. 

Jika terjadi pengecualian aplikasi atau kegagalan transaksi, sistem memastikan bahwa pemrosesan pesanan dapat dihentikan atau dialihkan ke Dead Letter Queue (DLQ) Amazon SQS, untuk diproses ulang di tahap selanjutnya.

Decoupling Arsitektur Anda dengan Amazon SNS

Amazon Simple Notification Service (Amazon SNS) adalah layanan web yang memudahkan Anda untuk mengatur, mengoperasikan, dan mengirim notifikasi dari cloud. Layanan ini menggunakan paradigma perpesanan "publisher-subscriber” (pub-sub) dengan notifikasi yang dikirimkan ke klien menggunakan mekanisme "push".

Cara kerja layanan ini cukup sederhana, Anda membuat SNS topic dan mengontrol akses ke topic tersebut dengan mendefinisikan kebijakan yang menentukan publisher (penerbit) dan subscriber (pelanggan) mana yang dapat berkomunikasi dengan topic tersebut. Publisher mengirimkan pesan ke SNS topic yang mereka buat atau ke topic yang telah diziinkan untuk mem-publish-nya.

Alih-alih menyertakan alamat tujuan tertentu di setiap pesan, publisher cukup mengirimkan pesan ke topic yang diinginkan. Kemudian, Amazon SNS akan mencocokkan topic dengan daftar subscriber yang telah berlangganan ke topic tersebut dan mengirimkan pesan ke masing-masing subscriber tersebut.

Setiap topic memiliki nama unik yang mengidentifikasi endpoint Amazon SNS bagi publisher untuk mem-publish pesan; dan subscriber untuk mendaftar notifikasi. Subscriber akan menerima semua pesan yang dipublikasikan ke topic langganan mereka dan semua subscriber dari topic tersebut akan menerima pesan yang sama.

Amazon SNS mendukung topik terenkripsi. Saat Anda mem-publish pesan ke topic yang terenkripsi, Amazon SNS menggunakan customer master key (CMK) yang didukung oleh AWS Key Management Service untuk mengenkripsi pesan Anda.

Amazon SNS mendukung CMK yang dikelola pelanggan serta yang dikelola AWS. Segera setelah Amazon SNS menerima pesan Anda, enkripsi dilakukan di server menggunakan algoritma AES-GCM 256-bit. Pesan disimpan dalam bentuk terenkripsi di beberapa Availability Zone (AZ) untuk ketahanan dan didekripsi sebelum dikirim ke subscriber, seperti Amazon SQS queue, AWS Lambda function, dan HTTP dan HTTPS webhook.

Jenis-Jenis Subscription pada Amazon SNS

Saat menggunakan Amazon SNS, Anda dapat memilih salah satu metode berikut sebagai bagian dari permintaan berlangganan (subscription):

Mari kita uraikan setiap poin-poinnya:

• Email atau Email-JSON : Pesan dikirim ke alamat yang terdaftar sebagai email. Email-JSON mengirimkan notifikasi sebagai objek JSON, sedangkan Email berarti mengirimkan notifikasi berbasis teks.

• HTTP/HTTPS : Subscriber menentukan URL sebagai bagian dari pendaftaran langganan/subscription. Notifikasi akan dikirim melalui HTTP POST ke URL yang ditentukan.

• SMS : Pesan dikirim ke nomor telepon yang terdaftar sebagai pesan teks SMS.

• Amazon SQS queue : Anda dapat menentukan SQS standard queue sebagai endpoint, kemudian Amazon SNS akan mengantrekan pesan notifikasi ke queue yang ditentukan. Perhatikan bahwa FIFO queue saat ini belum didukung.

• AWS Lambda function : Pesan juga dapat dikirim ke AWS Lambda function untuk menangani kustomisasi pesan, mengaktifkan persistensi pesan, atau berkomunikasi dengan layanan AWS lainnya.

Contoh Kasus Penggunaan Amazon SNS

Setelah mempelajari seputar Amazon SNS, mari kita bahas tentang beberapa contoh kasus penggunaan untuk Amazon SNS. Ada banyak cara untuk menggunakan notifikasi pada Amazon SNS.

Mari kita uraikan berdasarkan gambar di atas:

• Anda dapat menerima notifikasi langsung saat suatu event (peristiwa) terjadi, seperti perubahan spesifik pada AWS Auto Scaling group.

• Anda dapat menggunakan Amazon SNS untuk menyampaikan headline berita kepada subscriber melalui email atau SMS. Setelah menerima email atau SMS, pembaca yang tertarik kemudian dapat memilih untuk mempelajari lebih lanjut dengan mengunjungi website atau membuka aplikasi Anda.

• Anda dapat mengirim notifikasi ke suatu aplikasi, misal menunjukkan bahwa pembaruan tersedia. Pesan notifikasi dapat menyertakan tautan untuk mengunduh dan menginstal pembaruan aplikasi tersebut.

Bagaimana, sudah mulai tertarik menggunakan Amazon SNS? Selanjutnya, mari kita lihat karakteristik dari Amazon SNS di pembahasan selanjutnya.

Karakteristik Amazon SNS

Sebelum menggunakan Amazon SNS untuk arsitektur Anda, alangkah baiknya ketahui terlebih dahulu beberapa karakteristiknya. Mari kita jabarkan.

• Single published message
  Semua pesan notifikasi akan berisi satu pesan yang diterbitkan (single published message). Amazon SNS akan mencoba mengirimkan pesan dari publisher sesuai urutan penerbitannya ke dalam SNS topic. Namun, masalah jaringan dapat berpotensi mengakibatkan pesan out-of-order (rusak) di subscriber.
  
  

• No recall options
  Ketika pesan berhasil dikirim, tidak ada cara untuk menariknya kembali (no recall options).
  
  

• HTTP/HTTPS retry
  Amazon SNS Delivery Policy dapat digunakan untuk mengontrol pola retry pattern alias percobaan ulang (linier, geometris, mundur eksponensial), maksimum dan minimum untuk retry delay, dan parameter lainnya.
  
  

• Order and delivery not guaranteed
  Untuk mencegah terjadinya kehilangan pesan, semua pesan yang di-publish ke Amazon SNS disimpan secara redundant di beberapa server dan data center.
  
  

Amazon SNS dirancang untuk memenuhi kebutuhan aplikasi apa pun, dari yang sederhana hingga berskala enterprise. SNS memungkinkan aplikasi untuk mem-publish pesan dalam jumlah tak terbatas kapan pun. 

Amazon SNS memungkinkan aplikasi dan pengguna pada berbagai perangkat dapat menerima pemberitahuan melalui Mobile Push notification (perangkat Apple, Google, dan Kindle Fire), HTTP/HTTPS, Email/Email-JSON, SMS, Amazon SQS queue, atau AWS Lambda function. 

Amazon SNS menyediakan mekanisme kontrol akses untuk memastikan topic dan pesan diamankan dari akses yang tidak sah. Pemilik topic dapat mengatur policy untuk suatu topic yang membatasi siapa yang dapat mem-publish atau subscribe pada suatu topic. 

Selain itu, pemilik topic juga dapat memastikan bahwa notifikasi dienkripsi, yakni dengan menentukan mekanisme pengiriman menggunakan HTTPS.

Contoh Arsitektur yang Menggunakan Amazon SNS

Dengan Amazon SNS, Anda dapat menggunakan topic untuk memisahkan publisher pesan dari subscriber, menyebarkan pesan ke beberapa penerima sekaligus, dan menghilangkan polling di aplikasi Anda. Lihatlah gambar arsitektur yang menggunakan Amazon SNS di bawah ini.

Dalam skenario di atas, saat Anda mengunggah gambar ke Amazon S3, maka itu akan memicu event notification yang kemudian mengirimkan pesan ke SNS topic secara otomatis. Topic ini di-subscribe oleh SQS queue sesuai dengan kategorinya, ada queue untuk membuat thumbnail, mobile, dan juga web.

Masing-masing queue di atas selanjutnya di-pull oleh mesin-mesin EC2 yang tergabung ke dalam Auto Scaling Group (ASG) terpisah untuk melakukan pemrosesan gambar yang selanjutnya disimpan di Amazon S3 bucket.

Mudah kan memahaminya? Selanjutnya, kita akan melihat perbedaan antara Amazon SQS dan Amazon SNS. Break a leg!

Perbedaan Amazon SQS dan Amazon SNS

Sejauh ini, kita telah mempelajari layanan Amazon SQS dan Amazon SNS. Sekarang, kita akan melihat perbandingan di antara keduanya. Perhatikan tabel di bawah ini.

	Amazon SNS (Publisher/Subscriber)	Amazon SQS (Producer/Consumer)
Persistensi Pesan	Tidak	Ya
Mekanisme Pengiriman	Push (pasif)	Poll (aktif)
Producer/Consumer	Publish/Subscribe	Send/Receive
Model distribusi	One to many	One to one

Mari kita jabarkan perbedaannya secara terperinci satu per satu.

• Pesan pada Amazon SNS tidak persisten, sedangkan di Amazon SQS persisten. Amazon SNS mendefinisikan delivery policy (kebijakan pengiriman) untuk setiap protokol pengiriman. Delivery policy menentukan bagaimana Amazon SNS mencoba kembali pengiriman pesan ketika terjadi kesalahan pada sisi server. Saat delivery policy habis, Amazon SNS berhenti mencoba kembali pengiriman dan membuang pesan, kecuali dead-letter queue dilampirkan ke subscription/langganan.

• Amazon SNS memungkinkan aplikasi mengirim pesan penting ke beberapa subscriber melalui mekanisme push. Sementara itu, Amazon SQS bertukar pesan melalui model polling: komponen pengiriman dan penerimaan decoupled (dipisahkan).

• Amazon SNS memiliki model distribusi one-to-many, sedangkan Amazon SQS one-to-one. Amazon SQS memberikan fleksibilitas bagi komponen aplikasi terdistribusi untuk mengirim dan menerima pesan tanpa mengharuskan setiap komponen tersedia secara bersamaan.

Oke, materi tentang Amazon SNS dan Amazon SQS telah tuntas sampai di sini. Selanjutnya, kita akan belajar mengenai Amazon MQ. Apa itu MQ? Jawabannya ada di materi berikutnya!

Amazon MQ

Amazon MQ adalah layanan terkelola (managed service) dari AWS untuk Apache ActiveMQ dan RabbitMQ, yaitu message broker yang open-source dan populer. Infrastruktur yang mendasarinya secara otomatis disediakan untuk high availability (ketersediaan tinggi) dan durability (ketahanan) untuk mendukung keandalan aplikasi Anda. 

Dengan Amazon MQ, Anda mendapatkan akses langsung ke ActiveMQ console serta API dan protokol standar industri untuk pengiriman pesan, termasuk JMS, NMS, AMQP, STOMP, MQTT, dan WebSocket. 

Anda dapat dengan mudah berpindah dari message broker mana pun yang menggunakan standar ini ke Amazon MQ. Ini karena Anda tidak perlu menulis ulang kode perpesanan (messaging) apa pun di aplikasi Anda.

Arsitektur Broker

Anda bisa membuat arsitektur broker sebagai single instance broker ataupun active/standby broker. Untuk kedua penerapan tersebut, Amazon MQ memberikan ketahanan yang tinggi dengan menyimpan data secara redundant. Mari kita pelajari keduanya.

Single Instance

Arsitektur broker dengan instance tunggal terdiri dari satu broker dalam satu Availability Zone di belakang Network Load Balancer (NLB). Broker berkomunikasi dengan aplikasi Anda dan dengan Amazon EFS (hanya berlaku untuk broker ActiveMQ) atau dengan Amazon EBS.

Pada ilustrasi di atas ditunjukkan bahwa Amazon MQ dapat menggunakan Amazon EFS maupun Amazon EBS sebagai penyimpanan datanya.

Active/Standby

Arsitektur broker Active/Standby terdiri dari dua broker di dua Availability Zone yang dikonfigurasi dalam redundant pair. Broker ini berkomunikasi secara synchronous dengan aplikasi Anda dan shared storage.    

Biasanya, hanya satu broker instance yang aktif setiap saat, sementara broker lainnya dalam keadaan siaga (standby). Jika salah satu broker instance mengalami malfungsi atau sedang menjalani pemeliharaan, Amazon MQ akan membuat instance tersebut menjadi out-of-service, lalu mengizinkan standby instance yang sehat menjadi aktif dan mulai menerima komunikasi yang masuk. Saat Anda me-reboot broker, peristiwa failover hanya membutuhkan waktu beberapa detik saja.

Untuk broker active/standby, Amazon MQ menyediakan dua URL untuk ActiveMQ web console, tetapi hanya satu URL yang aktif dalam satu waktu. Demikian pula, Amazon MQ menyediakan dua endpoint untuk setiap wire-level protocol, tetapi hanya satu endpoint yang aktif di setiap redundant pair pada satu waktu. 

Contoh Kasus Penggunaan Amazon MQ: Hybrid Integration

Banyak perusahaan yang mengandalkan message broker untuk menghubungkan dan mengoordinasikan sistem yang berbeda. 

Message broker memungkinkan aplikasi terdistribusi untuk berkomunikasi satu sama lain, berfungsi sebagai tulang punggung teknologi untuk lingkungan IT, dan layanan bisnis mereka. Aplikasi mereka sangat bergantung pada sistem perpesanan (messaging) untuk operasinya.

Dalam banyak kasus, perusahaan tersebut telah mulai membangun aplikasi baru atau lift and shift ke AWS. Dalam beberapa kasus, terdapat aplikasi (seperti sistem mainframe) yang terlalu mahal untuk dimigrasikan. Pada skenario ini, aplikasi on-premise tersebut masih perlu berinteraksi dengan komponen berbasis Internet.

Diagram di atas menunjukkan bahwa Anda dapat menggunakan Amazon MQ untuk mengintegrasikan lingkungan on-premise dan cloud menggunakan fitur jaringan broker ActiveMQ. Gambar di atas juga menjabarkan life cycle (siklus hidup) pesan, mulai dari on-premise producer ke on-premise broker, kemudian melintasi koneksi hybrid antara on-premise broker dan Amazon MQ, dan akhirnya digunakan di dalam AWS Cloud.

Ikhtisar

Di modul ini kita telah mempelajari mengenai tiga jenis layanan dari AWS yang memungkinkan kita memisahkan (decouple) arsitektur menjadi komponen-komponen mandiri sehingga dapat beroperasi secara independen. 

Ketiga Layanan tersebut adalah Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS), dan Amazon MQ.

Amazon MQ, Amazon SQS, dan Amazon SNS adalah layanan perpesanan (messaging) yang cocok untuk siapa pun mulai dari startup hingga perusahaan yang sudah besar. Tabel di bawah ini menunjukkan perbedaan dan penggunaan ketiga layanan Message Broker dari AWS. 

Amazon MQ	Amazon SQS dan Amazon SNS
Untuk migrasi aplikasi	Untuk aplikasi cloud native
Protokol: JMS, NMS, AMQP, STOMP, MQTT, dan WebSocket	Protokol: HTTPS
Banyak fitur	Unlimited throughput
Biaya per jam dan biaya per GB	Biaya per request
Bisa melakukan Pub/Sub	Tidak ada Pub/Sub di SQS, tetapi Anda bisa melakukan Pub/Sub di SNS

Jika Anda menggunakan messaging dengan aplikasi yang sudah ada dan ingin memindahkannya ke cloud dengan cepat dan mudah, maka pertimbangkanlah Amazon MQ.

Amazon MQ mendukung API dan protokol standar yang terbuka sehingga Anda dapat beralih dari message broker pesan berbasis standar ke Amazon MQ tanpa menulis ulang kode pesan di aplikasi Anda. 

Namun, jika Anda membangun aplikasi baru di cloud, maka gunakanlah Amazon SQS dan Amazon SNS. SQS adalah layanan antrean pesan (message queue), sedangkan SNS adalah layanan topic. Kedua layanan tersebut sangat ringan dan terkelola sepenuhnya yang berskala hampir tak terbatas dan menyediakan API sederhana serta mudah digunakan. 

Anda dapat menggunakan Amazon SQS dan Amazon SNS untuk decoupling dan scaling terhadap microservice, sistem terdistribusi, dan aplikasi serverless.

Pengantar ke Arsitektur Microservices dan Serverless

Aplikasi startup warung kopi kita masih memiliki arsitektur monolitik, yang berisi komponen-komponen saling terikat satu sama lain. Jika salah satu komponen tersebut gagal, seluruh aplikasi akan macet. Atau jika ada lonjakan permintaan, seluruh arsitektur harus di-scale. Tak hanya itu, menambahkan fitur ke aplikasi monolitik juga akan menjadi lebih kompleks seiring berjalannya waktu. Bahkan, potongan-potongan kode pun harus sinkron satu sama lain dengan benar.

Tentu Anda tak ingin kan aplikasi startup warung kopi mengalami kendala sehingga membuat pelanggan kecewa? Oleh karena itu, pada modul kali ini kita akan belajar cara membangun arsitektur microservices dan serverless.

Dengan arsitektur microservices, aplikasi dibangun sebagai komponen independen yang menjalankan setiap proses aplikasi sebagai service (layanan). Service ini berkomunikasi melalui antarmuka yang ditentukan dengan baik menggunakan API. Service dibangun untuk kemampuan bisnis yang masing-masing menjalankan satu fungsi tertentu. 

Karena dijalankan secara independen, setiap service dapat di-update, di-deploy, dan di-scale untuk memenuhi permintaan fungsi tertentu dari suatu aplikasi.

Oke, untuk menjawab kebutuhan arsitektur di atas, kita akan mempelajari hal-hal berikut ini:

• Membangun microservices
• Layanan container
• Menjadi serverless

Kita akan membedah poin-poin tersebut satu per satu. Yuk kita masuk ke materi berikutnya!

Arsitektur Microservices

Untuk memahami arsitektur microservices, kita harus memahami pengertian dan juga karakteristiknya terlebih dahulu. Yuk kita mulai pembahasannya!

Apa itu Microservices?

Sebelum membahasnya lebih jauh, mari kita berkenalan dulu tentang apa itu microservices. Microservices adalah aplikasi yang terdiri dari layanan independen yang berkomunikasi melalui API yang telah ditentukan dengan baik. Sebagai contoh, mari kita lihat gambar berikut ini.

Di sebelah kiri adalah Aplikasi Forum dengan arsitektur monolitik. Walaupun secara arsitektur aplikasi ini terdiri dari tiga komponen (Users, Topics, dan Messages), tapi dalam cara bekerja masing-masing komponen masih terikat erat dengan komponen lain. Misalnya, user ingin mem-posting sebuah pesan baru di forum, kemungkinan ini diimplementasikan dengan cara memanggil stored procedure ke database. Proses ini sebenarnya bisa bekerja dengan baik, tapi tidak scalable.

Gambar di sebelah kanan menggambarkan Aplikasi Forum dalam arsitektur microservices. Mari kita kembali ke skenario user yang ingin mem-posting sebuah pesan baru di Forum. Dalam arsitektur microservices, Users service akan berkomunikasi dengan Topics service melalui API. Selanjutnya, pesan tersebut di-posting oleh Topics service dengan cara berkomunikasi melalui API dengan Messages service.

Karakteristik Microservices

Setelah mengenal apa itu microservices dan perbedaannya dengan monolitik, sekarang mari kita belajar tentang karakteristik dari microservices. Microservices memiliki dua karakteristik, yaitu Autonomous dan Specialized.

Yuk kita jabarkan masing-masing karakteristiknya.

• Autonomous
  Setiap komponen service dalam arsitektur microservices dapat dikembangkan, di-deploy, dioperasikan, dan di-scale tanpa memengaruhi fungsi service lain. Service tidak perlu menggunakan kode bersama (sharing) atau implementasinya dengan service lain. Setiap komunikasi antara komponen individu terjadi melalui API yang didefinisikan dengan jelas (well-defined API).
  
  

• Specialized
  Setiap service dirancang untuk serangkaian kemampuan dan berfokus pada pemecahan masalah tertentu. Jika developer menambahkan lebih banyak kode ke service dari waktu ke waktu sehingga service menjadi kompleks, maka service itu dapat dipecah lagi menjadi service yang lebih kecil.

Itulah pembahasan kita mengenai microservices. Selanjutnya, kita akan belajar tentang layanan container di AWS. Penasaran? Mari kita melangkah ke materi berikutnya!

Layanan Container

Manfaat arsitektur yang berorientasi pada microservices harus diterapkan juga pada tingkat infrastruktur. Saat ini, walaupun kita sudah mendesain arsitektur secara terpisah (decoupled) dan menggunakan model microservices, dari sisi implementasinya Anda masih menggunakan virtual machine. 

Meskipun menggunakan VM di cloud menjadikan arsitektur fleksibel, namun dengan menggunakan container akan membuat infrastruktur Anda menjadi lebih fleksibel dan dinamis. Mari kita pelajari lebih jauh.

Apa itu Container?

Container adalah metode virtualisasi sistem operasi yang memungkinkan Anda menjalankan aplikasi dan dependensinya dalam proses yang diisolasi dari resources, dalam hal ini adalah VM Anda. 

Dengan menggunakan container, Anda dapat dengan mudah menjadikan kode aplikasi, konfigurasi, dan dependensi ke dalam satu paket komponen yang mudah digunakan. Container dapat memberikan konsistensi lingkungan, efisiensi operasional, produktivitas developer, dan version control.

Saat berbicara mengenai container, Anda juga perlu memahami tentang container image. Container image adalah snapshot dari sistem file yang tersedia untuk container. Misalnya, Anda dapat memiliki sistem operasi Debian sebagai container image. Sehingga saat menjalankan container, Anda akan memiliki sistem operasi Debian yang tersedia di container tersebut.

Anda juga dapat mengemas semua dependensi kode Anda dalam container image dan menggunakannya sebagai code artifact Anda. Perlu dicatat bahwa space dari image container biasanya berukuran lebih kecil dari virtual machine. Anda dapat menyalakan container hanya dalam hitungan ratusan milidetik saja.

Jadi dengan menggunakan kontainer, Anda dapat menggunakan lingkungan infrastruktur yang agnostik, cepat, dan portabel.

Beberapa Masalah yang Bisa Container Selesaikan

Saat menggunakan container, Anda akan mendapatkan beberapa keuntungan karena ia dapat memecahkan beberapa masalah, seperti perbedaan lingkungan deployment dan pemanfaat sumber daya komputasi. Mari kita lihat lebih detail di bawah ini.

Perbedaan Lingkungan Deployment

Container dapat membantu memastikan bahwa aplikasi di-deploy dengan cepat, andal, dan konsisten, terlepas dari lingkungan deployment-nya. Ini menjawab pertanyaan yang sering dilontarkan oleh tim developer Anda saat men-debug program aplikasi, “Kenapa di laptop saya aplikasinya berjalan mulus, sementara di laptop Manajer tidak jalan sama sekali?” 

Selain itu, container juga memberi Anda kontrol yang lebih terperinci atas sumber daya, sehingga dapat meningkatkan efisiensi terhadap infrastruktur Anda. 

Jika Anda mencari solusi container yang sudah dibuat sebelumnya, Anda bisa mengunjungi AWS Marketplace for Containers yang akan membantu Anda menemukan dan membeli produk container dari vendor perangkat lunak independen, baik melalui Amazon ECS console maupun AWS Marketplace. 

Produk-produk terverifikasi dan didukung secara komersial tersebut berjalan pada layanan container AWS yang kompatibel dengan Docker, seperti Amazon ECS, AWS Fargate, dan Amazon EKS. Anda dapat memilih dari kategori produk, seperti high-performance computing (komputasi kinerja tinggi), security, dan developer tools. Selain itu, produk SaaS (Software as a Service) yang mengelola, menganalisis, atau melindungi aplikasi container pun tersedia.

Pemanfaatan Sumber Daya Komputasi

Saat mendengar kemampuan dari container, sering kali kita berpikir bahwa ini terdengar seperti virtual machine. Namun sebenarnya keduanya berbeda, perbedaannya terletak pada detailnya. 

Perbedaan yang paling mencolok antara container dan VM adalah tidak lagi diperlukan hypervisor. Container dapat berjalan di sistem Linux apa pun dengan dukungan fitur kernel yang sesuai dan adanya Docker daemon. Ini membuatnya sangat portabel.

Kebanyakan container dapat melakukan boot hanya dalam beberapa detik saja. Selain itu, di dalam AWS, container kini menjadi bagian penting dari infrastruktur melalui utilitas dari Elastic Container Services, Docker, dan Elastic Beanstalk.

Amazon ECS

Amazon Elastic Container Service (Amazon ECS) adalah layanan manajemen container berkinerja tinggi dan sangat scalable yang mendukung Docker container dan memungkinkan Anda menjalankan aplikasi dengan mudah pada managed cluster (klaster terkelola) dari Amazon EC2 instance.

Amazon ECS adalah layanan cluster yang scalable untuk meng-hosting container, layanan ini dapat:

• Scale hingga ribuan instance.
• Memantau deployment dari container.
• Mengelola state (kondisi) lengkap dari cluster.
• Menjadwalkan container menggunakan penjadwal bawaan (built-in scheduler) atau penjadwal pihak ketiga (misal Apache Mesos atau Blox).
• API yang dapat dikembangkan (Extensible API).
• Diluncurkan dengan jenis peluncuran (launch type) Fargate atau EC2.

Karena berjalan di atas Amazon EC2, ECS Cluster dapat memanfaatkan Spot Instances dan Reserved Instances. 

Bekerja dengan ECS

Terdapat 3 bagian besar yang harus diingat saat Anda ingin menggunakan ECS. Ketiga bagian tersebut ditunjukkan pada gambar di bawah ini. 

Secara garis besar, untuk menggunakan ECS kita memerlukan Container, ECS Task Definition, dan ECS Cluster. Mari kita uraikan setiap poin-poinnya.

1. Container
   Container ini dibuat oleh Anda dan dikemas dalam bentuk Docker Image. Selanjutnya agar bisa diakses oleh ECS, maka image ini tentu saja disimpan di tempat yang dapat diakses melalui internet. Salah satu tempat yang disarankan adalah Amazon Elastic Container Registry.
    

2. ECS Task Definition
   Task Definition itu seperti cetak biru (blueprint) untuk aplikasi Anda. Setiap kali meluncurkan task di Amazon ECS, Anda menentukan Task Definition. ECS kemudian mengetahui Docker image mana yang akan digunakan untuk container, berapa banyak container yang akan digunakan dalam task tersebut, dan alokasi resource untuk setiap container.
    

3. ECS Cluster
   ECS Cluster adalah pengelompokan task atau service secara logical. Jika Anda menjalankan task atau service yang menggunakan jenis peluncuran EC2, maka cluster merupakan pengelompokan dari container instance. Jika Anda menggunakan capacity provider (penyedia kapasitas), maka cluster merupakan pengelompokan logis dari capacity provider.
   
   Saat Anda pertama kali menggunakan Amazon ECS, cluster default telah dibuat untuk Anda. Akan tetapi, Anda dapat membuat beberapa cluster di dalam akun Anda untuk menjaga sumber daya tetap terpisah.
   
   

Saat menggunakan Amazon ECS, kita bisa melakukan scaling secara otomatis untuk jumlah instance yang tersedia. Ini diilustrasikan pada gambar berikut:

Jika Anda mengonfigurasi Auto Scaling group untuk menghapus container instance, task apa pun yang sedang berjalan pada container instance tersebut akan dihentikan. Jika task Anda dijalankan sebagai bagian dari service, Amazon ECS akan memulai ulang task tersebut di instance lain jika sumber daya yang diperlukan tersedia (CPU, memori, port). Namun, task yang dimulai secara manual tidak akan dimulai ulang secara otomatis.

Beralih dari Aplikasi Monolitik ke Microservices Berbasis Container

Pada pembahasan kali ini kita akan kembali menggunakan skenario Aplikasi Forum. Untuk mengubah Aplikasi Forum yang semula monolitik menjadi pendekatan microservice, Anda dapat memecah kode menjadi individual encapsulated services (layanan enkapsulasi individual). Pastikan masing-masing service menjalankan fungsinya dengan sempurna, lalu daftarkan service tersebut dengan Amazon Elastic Container Registry (ECR).

Selanjutnya, di dalam Amazon ECS, buat service untuk masing-masing bagian dari aplikasi asli Anda. Kemudian daftarkan target group instance untuk service tersebut. Terakhir, buat Application Load Balancer dengan target group yang mengarah ke Amazon ECS app service Anda.

Ketahuilah! AWS Cloud Map dan AWS App Mesh dapat membantu dalam membangun dan memecahkan masalah arsitektur Anda. Mari kita bahas keduanya.

• AWS Cloud Map
  AWS Cloud Map adalah layanan terkelola sepenuhnya yang memungkinkan Anda mendaftarkan sumber daya aplikasi apa pun (seperti database, queue, microservices, dan sumber daya cloud lainnya) dengan custom namespace (cara untuk mengelompokkan service untuk sebuah aplikasi).
  
  AWS Cloud Map kemudian terus-menerus memeriksa kesehatan (health check) sumber daya untuk memastikan lokasinya terkini (up-to-date), sehingga memungkinkan Anda untuk menambahkan dan mendaftarkan sumber daya apa pun dengan intervensi manual yang minimal dari pemetaan (mapping). AWS Cloud Map membantu service discovery (penemuan layanan), continuous integration (integrasi berkelanjutan), dan health monitoring (pemantauan kesehatan) untuk microservice dan aplikasi Anda.
  
  

• AWS App Mesh
  AWS App Mesh menangkap metrik, log, dan jejak dari setiap microservice yang dapat Anda ekspor ke Amazon CloudWatch, AWS X-Ray, serta tools AWS partner dan komunitas untuk pemantauan dan pelacakan.
  
  Layanan ini juga memberikan kontrol khusus atas perutean traffic antara microservice untuk membantu deployment, kegagalan, atau scaling pada aplikasi Anda.
  
  

Kita telah belajar bahwa Amazon ECS adalah layanan manajemen container yang memungkinkan Anda menjalankan aplikasi dengan mudah pada managed cluster (klaster terkelola) dari Amazon EC2 instance.

Jika Anda tak ingin mengurusi perihal server atau cluster, tenang, AWS menyediakan solusinya dengan menghadirkan AWS Fargate. Simak pembahasan di materi berikutnya!

AWS Fargate

AWS Fargate adalah teknologi untuk Amazon ECS dan Amazon Elastic Kubernetes Service (Amazon EKS) yang memungkinkan Anda menjalankan container tanpa harus mengelola server atau cluster. 

Dengan AWS Fargate, Anda tidak lagi harus menyediakan, mengonfigurasi, dan melakukan scaling terhadap cluster dari virtual machine untuk menjalankan container. Layanan ini menghilangkan kebutuhan untuk memilih jenis server, memutuskan kapan akan scaling cluster Anda, atau mengoptimalkan pengemasan cluster. 

AWS Fargate memungkinkan Anda fokus pada merancang dan membangun aplikasi ketimbang mengelola infrastruktur. Layanan ini mendukung Amazon EKS dan ECS.

Menjadi Serverless

Apa itu Komputasi Serverless?

Komputasi serverless (tanpa server) memungkinkan Anda membangun dan menjalankan aplikasi dan layanan tanpa merencanakan atau melakukan provisioning (penyediaan) server. Aplikasi serverless tidak mengharuskan Anda untuk menyediakan, melakukan scaling, dan mengelola server apa pun. Semua yang dibutuhkan untuk menjalankan dan scaling aplikasi Anda dengan ketersediaan tinggi (high availability) akan ditangani oleh AWS untuk Anda.

Kemudian, mungkin Anda akan bertanya-tanya, “Mengapa kita perlu menggunakan komputasi serverless?”

Dengan membangun aplikasi serverless, itu berarti Anda dapat fokus pada produk aplikasi daripada khawatir tentang pengelolaan dan pengoperasian server atau runtime, baik di cloud maupun on-premise. Ini memungkinkan Anda mendapatkan kembali waktu dan energi yang dapat digunakan untuk mengembangkan produk hebat yang scalable dan dapat diandalkan.

Tak hanya itu, dengan serverless, Anda bisa menggunakan sumber daya komputasi sesuai kebutuhan dan buat aplikasi Anda berbasis microservices. Menarik, bukan?

Lalu, apa saja layanan serverless yang ditawarkan oleh AWS? Mari kita kita lihat pada materi berikutnya!

AWS Lambda

AWS Lambda memungkinkan Anda untuk menjalankan kode tanpa harus menyediakan atau mengelola server. Layanan ini menjalankan kode Anda pada infrastruktur komputasi yang highly available dan melakukan semua administrasi sumber daya komputasi, termasuk aktivitas seperti pemeliharaan server dan sistem operasi, penyediaan kapasitas dan automatic scaling, serta pemantauan dan pencatatan kode. 

Sehingga yang perlu Anda lakukan hanyalah memberikan kode Anda dalam salah satu bahasa yang didukung AWS Lambda (saat ini Node.js, Java, C#, Python, Go, Ruby, dan PowerShell).

AWS juga menyediakan Lambda@Edge yang dapat memberikan kemampuan untuk menjalankan Lambda function sebagai respons terhadap events yang dihasilkan oleh Amazon CloudFront CDN dan scaling kode Anda dengan ketersediaan tinggi di AWS edge location yang paling dekat dengan pengguna. Anda dapat menggunakan Lambda function untuk mengubah permintaan dan respons CloudFront pada poin-poin berikut:

• Viewer request
• Origin request
• Origin response
• Viewer response

Hal tersebut bisa digunakan untuk membuat website lebih aman, aplikasi dinamis, optimasi SEO, real time, dan skenario-skenario lainnya.

Cara Kerja AWS Lambda

Komponen inti dari AWS Lambda adalah event source dan Lambda function. Event Source mem-publish event, sementara Lambda function adalah kode yang Anda tulis untuk memproses event. Lambda yang nantinya akan menjalankan fungsi sebagai perwakilan Anda.

Lambda function terdiri dari kode Anda, associated dependencies (dependensi terkait), dan konfigurasi. Konfigurasi termasuk di dalamnya informasi seperti handler yang akan menerima event, IAM role yang dapat di-assume (digunakan) oleh AWS Lambda untuk menjalankan Lambda function, sumber daya komputasi yang ingin Anda alokasikan, dan juga timeout (waktu tunggu).

Layers (lapisan) memungkinkan developer AWS Lambda function untuk memelihara package, binaries, runtime, dan file lain yang diperlukan sebagai komponen yang terpisah dari kode function. 

Saat membuat Lambda function, Anda memiliki opsi untuk menentukan satu atau lebih Layers yang akan disertakan dengan lingkungan runtime Lambda function. Hal tersebut menghilangkan kebutuhan untuk memelihara salinan dari file yang sama yang didistribusikan di beberapa Lambda function. 

Misalnya, aplikasi serverless yang ditulis dengan Python dapat menggunakan package seperti PyMySQL untuk membuat query database Amazon RDS MySQL. Dengan layer, hanya satu salinan paket PyMySQL yang perlu di-maintain dan dapat digunakan oleh function apa pun dalam aplikasi.

Saat menggunakan Lambda layer, Anda memiliki restriksi/batasan seperti berikut:

• Satu function dapat menggunakan hingga 5 layers sekaligus.
• Ukuran total ukuran unzipped dari function (termasuk layers) tidak boleh melebihi batas sebesar 250 MB.

Lambda layers mendukung resource-level permission (izin tingkat sumber daya) dan dapat dibagikan (shared) ke akun AWS tertentu, AWS Organizations, atau semua akun. Layer dapat Anda tambahkan ke suatu function (baik selama pembuatan atau setelahnya) dan dapat diperbarui sesuai kebutuhan. AWS Serverless Application Model (SAM) juga mendukung pengelolaan layers di seluruh function.

Mirip dengan function versioning, Lambda layers mendukung versi individu dan permission yang sesuai. Versi yang telah di-publish dari sebuah layer tidak dapat diperbarui (selain mengubah versi dari permission). Untuk memperbarui layer, versi baru harus di-publish. Dengan cara ini, Anda dapat mengontrol peluncuran dari layer baru di berbagai function.

Seperti yang telah kita pelajari sebelumnya, salah satu komponen inti dari AWS Lambda adalah event source. Ketahuilah! AWS Lambda mendukung banyak event source, seperti S3, DynamoDB, SNS, SQS, CloudWatch events, Target Group (ALB), AWS IoT button, dan masih banyak lagi. 

Dari banyaknya event source yang tersedia, mari kita ambil contoh untuk ALB. Anda dapat menggunakan ALB (Application Load Balancer) untuk mengirim lalu lintas ke Lambda function Anda melalui HTTP/HTTPS. Atau karena ALB adalah perutean berbasis konten (content-based routing), Anda dapat memilih untuk mengirim lalu lintas ke Lambda function yang berbeda berdasarkan sebuah host atau URL path pada permintaan yang datang ke ALB. 

Dengan mendaftarkan Lambda function Anda sebagai target ke ALB, Load Balancer akan meneruskan konten ke Lambda function Anda dalam format JSON. Secara default, health check dinonaktifkan untuk target group berjenis Lambda.

Contoh Penggunaan Lambda Function

Setelah kita belajar mengenai AWS Lambda, sekarang mari kita lihat bagaimana contoh penggunaannya. Berikut adalah contoh arsitektur aplikasi order processing yang menggunakan Lambda function.

Bisa Anda lihat pada contoh arsitektur di atas, itu adalah sebuah aplikasi yang mengolah file yang disimpan di S3 bucket. File tersebut diproses oleh Lambda function yang kemudian memasukkan data ke dalam dua tabel terpisah di DynamoDB (table transaction dan table customer).

Selanjutnya, ada Lambda function lainnya yang bertugas mengumpulkan transaksi dan memperbarui total di DynamoDB table yang lain. Jika ditemukan total transaksi yang melebihi jumlah tertentu, maka akan dikirimkan alert/peringatan ke SNS topic HighBalanceAlert. SNS topic ini mem-push notifikasi ke email dan dua SQS queue terpisah yaitu, CreditCollection dan CustomerNotify untuk ditindaklanjuti.

Amazon API Gateway

Amazon API Gateway adalah layanan AWS untuk membuat, mem-publish, memelihara, memantau, dan mengamankan RESTful dan WebSocket API dalam skala apa pun. Anda dapat membuat API yang mengakses AWS atau layanan web lainnya, serta data yang disimpan di AWS Cloud. Anda juga bisa membuat API untuk digunakan dalam aplikasi klien Anda sendiri atau menjadikan API Anda tersedia untuk developer aplikasi pihak ketiga. 

Terdapat dua jenis API yang dapat Anda buat, RESTful dan WebSocket API. Dengan Amazon API Gateway, Anda dapat membuat RESTful API yang dioptimalkan untuk beban kerja serverless dan HTTP backend menggunakan HTTP API. Jika API Anda memerlukan fungsionalitas proxy API dan fitur manajemen API dalam satu solusi, API Gateway juga menawarkan REST API.

Selain itu, Anda juga bisa membangun aplikasi komunikasi dua arah secara real time, seperti aplikasi chatting dan dashboard streaming dengan WebSocket API.

Contoh Arsitektur Serverless Menggunakan API Gateway

Sekarang, mari kita telaah contoh arsitektur serverless menggunakan API Gateway. Gambar di bawah ini adalah contoh arsitektur serverless dengan API gateway dan beberapa komponen/layanan AWS lainnya. 

Bisa Anda lihat pada gambar di atas, Amazon API Gateway digunakan pada arsitektur Serverless Mobile Backend. Mari kita jabarkan. 

Seorang user melakukan request, kemudian Amazon API Gateway mengirim request ke Lambda function yang sesuai. Untuk user identity management, Amazon API gateway akan mengirim request ke Lambda function pertama yang kemudian diteruskan ke Amazon Cognito, AWS STS, dan Amazon DynamoDB. Kemudian untuk core business logic, Amazon API Gateway akan mengirim request ke Lambda function kedua yang kemudian akan meneruskannya ke Amazon DynamoDB, Amazon S3, Amazon ElastiCache, dan Amazon RDS.

AWS Step Functions

Untuk memahami AWS Step Functions, mari kita awali dengan suatu pertanyaan. Bagaimana jika kita membutuhkan suatu proses yang menjalankan Lambda function secara bersamaan (paralel) atau menjalankan Lambda function dengan menunggu function sebelumnya untuk selesai dieksekusi (serial), dsb seperti berikut:

Nah, AWS telah memiliki solusinya. Untuk memenuhi kebutuhan di atas, Anda membutuhkan layanan AWS Step Functions.

AWS Step functions memiliki banyak kemampuan, di antaranya:

• Mengoordinasikan microservices dengan menggunakan tool visual workflow.
• Mengatur step (urutan) pemrosesan function di aplikasi Anda.
• Otomatis men-trigger dan melacak setiap step.
• Memberikan error catching dan logging sederhana jika sebuah step gagal.

AWS Step Function adalah State Machine. State Machine adalah objek yang memiliki sejumlah kondisi operasi yang bergantung pada kondisi sebelumnya untuk menentukan output (keluaran). Lihat gambar ilustrasi berikut:

Contoh umum dari state machine adalah mesin penjual soda (vending machine). Mesin mulanya berada dalam status sedang beroperasi (menunggu transaksi), kemudian beralih ke status pemilihan soda saat uang dimasukkan. Setelah itu, ia memasuki status vending, di mana soda di-deploy ke pelanggan. Setelah selesai, state alias statusnya kembali ke menunggu transaksi.

AWS Step Functions memungkinkan Anda membuat dan mengotomatiskan state machine Anda sendiri dalam lingkungan AWS. Ini dilakukan dengan penggunaan Amazon State Language (ASL) berbasis JSON yang berisi struktur yang dibuat dari berbagai status (state), tugas (task), pilihan (choice), penanganan eror (error handling), dan banyak lagi.

AWS State Language 

Sebelumnya kita telah menyebutkan tentang ASL alias Amazon State Language, mari kita bahas. Amazon States Language adalah bahasa terstruktur berbasis JSON yang digunakan untuk mendefinisikan state machine Anda. State machine adalah kumpulan status yang dapat melakukan pekerjaan (task states), menentukan status mana yang akan ditransisikan ke berikutnya (Choicestates), menghentikan proses dengan error (fail states), dan seterusnya.

Setelah Anda selesai membuat ASL, Visual Workflow akan menggambarkan representasi visual dari AWS State Language. Lalu ketika Anda mengubah ASL di atas, misalnya mengganti nama state dari StartState menjadi StateAwal, maka perubahan tersebut akan terlihat di Visual Workflow.

Arsitektur Video On-Demand (VOD)

Untuk mempermudah Anda memahami arsitektur serverless, AWS menyediakan contoh solusi menggunakan AWS CloudFormation template yang menerapkan alur kerja untuk melakukan ingestion terhadap video sumber dan memproses video untuk playback jenis-jenis perangkat tertentu (misalnya perangkat seluler yang punya pixel kecil, ultra high definition TV, dan lainnya). 

Mari kita jabarkan penjelasan sesuai arsitektur di atas.

Saat Anda mengunggah source video, opsi encoding sudah didefinisikan di AWS CloudFormation template saat peluncuran, kemudian diterapkan ke setiap video untuk di-encode. Saat Anda mengupload video dan file metadata, parameter encoding untuk setiap video ditentukan dalam file metadata, sehingga pelanggan dapat menerapkan opsi encoding untuk setiap video. 

AWS CloudFormation template men-deploy alur kerja yang menyertakan AWS Elemental MediaConvert dan AWS Step Functions yang membuat function ingest, processing, dan publishing. Template tersebut juga meluncurkan AWS Lambda function yang melakukan pekerjaan setiap step (langkah) dan memproses pesan error, Amazon S3 bucket untuk file media sumber dan tujuan, Amazon CloudWatch untuk pencatatan, Amazon CloudWatch Events rule untuk AWS Elemental MediaConvert notifications, dan Amazon CloudFront distribution. 

Amazon DynamoDB table menyimpan data yang diambil melalui alur kerja, Amazon SQS queue untuk menangkap output dan Amazon SNS topic mengirimkan notifikasi encoding, publishing, dan error.

Warning Ikuti modul latihan ini sesuai dengan langkah-langkah yang kami berikan. Jika Anda telah menyelesaikan latihan ini, harap mengikuti tahapan Clean Up yang ada di akhir latihan untuk mengetahui bagaimana cara menghapus resource yang telah dibuat.

Hands-on Lab: Implementasi Arsitektur Serverless dengan AWS Managed Services

Kita sudah belajar mengenai arsitektur serverless di AWS. Sekarang, kita akan berlatih bagaimana cara mengimplementasikan arsitektur serverless dengan menggunakan beberapa layanan dari AWS Managed Services (Layanan Terkelola AWS).

Mari kita buat skenario. Startup Warung Kopi Anda sekarang telah memiliki gudang persediaan biji kopi di beberapa kota di Indonesia, yaitu Medan dan Makassar. Setiap bulannya, manajer di masing-masing kota mengirimkan laporan persediaan biji kopi kepada Anda. Anda pun harus memastikan bahwa tidak ada stok biji kopi yang kosong di setiap gudang.

Saat ini, Anda harus memeriksa setiap laporan secara manual. Tentu ini akan memakan waktu dan melelahkan. Maka dari itu, Anda membutuhkan aplikasi cloud yang andal, scalable, dan hemat biaya. 

Anda menginginkan cara yang mudah untuk memenuhi kebutuhan tersebut. Cukup unggah file laporannya, kemudian jika terdapat stok biji kopi yang kosong, maka aplikasi tersebut akan memberikan notifikasi ke email Anda. Dengan begitu, Anda pun tahu bahwa ada persediaan yang kosong tanpa harus memeriksa file laporan secara manual satu per satu.   

Perhatikan gambar di bawah ini yang menerangkan workflow (alur kerja) yang akan kita buat pada arsitektur di latihan kali ini.

Mari kita uraikan lebih lanjut.

1. Pertama, kita mengunggah file inventory yang sudah disediakan ke Amazon S3 bucket.
2. AWS Lambda function (fungsi yang pertama) akan ter-trigger dan kemudian melakukan aksi penulisan item dari file inventory tersebut ke DynamoDB table.
3. Ketika item sudah termuat ke Amazon DynamoDB table, AWS Lambda function (fungsi yang kedua) akan ter-trigger dan memeriksa item. Jika terdapat nilai nol, maka akan mengirim pesan ke Amazon SNS.
4. Kemudian, Amazon SNS akan mengirimkan notifikasi ke email Anda.

Nah, untuk membangun arsitektur seperti gambar di atas, kita akan melakukan beberapa tahapan, antara lain:

1. Membuat IAM role.
2. Membuat AWS Lambda function pertama, Amazon S3 bucket, dan Amazon DynamoDB table.
3. Membuat Amazon SNS topic dan AWS Lambda function kedua.
4. Menguji coba.

Penasaran hasilnya seperti apa? Mari kita mulai perjalanannya dari bagian pertama.

Hands-on Lab: Implementasi Arsitektur Serverless dengan AWS Managed Services - Membuat IAM Role

Pada bagian pertama ini, kita akan membuat IAM role untuk masing-masing AWS Lambda function. Pada AWS Lambda function 1, ia akan memiliki permission untuk membaca Amazon S3 bucket dan akses penuh terhadap Amazon DynamoDB table. Sedangkan AWS Lambda function 2, ia akan memiliki permission untuk mengeksekusi DynamoDB table dan akses penuh ke Amazon SNS. Yuk kita mulai!

1. Silakan masuk ke halaman AWS Identity and Access Management dengan mengetikkan IAM pada kotak pencarian.
   
   
   

2. Buka menu Roles yang ada di sisi kiri, lalu klik tombol Create role.
   
    

3. Kita akan memberikan Trust terhadap layanan Lambda. Pilih AWS service, klik Lambda, kemudian klik Next: Permissions.
   
    

4. Gunakan kotak pencarian untuk menemukan permission. Cari AmazonDynamoDBFullAccess lalu centang, kemudian cari AmazonS3ReadOnlyAccess lalu centang. Jika sudah, silakan klik Next: Tags.
   
    

5. Tambahkan tag sesuai konfigurasi berikut:

   Key	Name
   Value	Load-Inventory

   Lihat gambar di bawah ini, kemudian klik Next: Review.
    

6. Berikan nama dan deskripsi sesuai tabel di bawah ini. Jika sudah selesai, lanjutkan dengan klik tombol Create role.

   Role name	Load-Inventory
   Role description	Allows Lambda function to have read only access to Amazon S3 and have full access to DynamoDB

   

7. IAM role Anda sudah berhasil dibuat. Kemudian, kita akan membuat IAM role kedua (role ini akan dipakai oleh Lambda function yang kedua nantinya). Silakan klik tombol Create role.
   
    

8. Pilih AWS service, klik Lambda, kemudian lanjutkan dengan klik tombol Next: Permissions.

9. Gunakan kotak pencarian untuk menemukan permission, centang AWSLambdaDynamoDBExecutionRole dan AmazonSNSFullAccess. Lalu, klik Next: Tags.

10. Tambahkan tag dengan nilai berikut:

    Key	Name
    Value	Check-Stock

Lanjutkan dengan klik tombol Next: Review.

11. Pada halaman Review, isilah nama dan deskripsi dengan nilai berikut:

    Role name	Check-Stock
    Role description	Allows Lambda function to execute DynamoDB and have full access to SNS

Kemudian, klik tombol Create role.

12. Perhatikan, dua IAM role yang telah Anda dibuat akan terdaftar pada halaman IAM role.
    
    

Oke, bagian pertama telah kita selesaikan. Yuk kita lanjutkan ke bagian kedua.

Hands-on Lab: Implementasi Arsitektur Serverless dengan AWS Managed Services - Membuat Lambda function 1, S3 bucket, dan DynamoDB table

Pada bagian kedua ini, kita akan membuat AWS Lambda function, Amazon S3 bucket, dan Amazon DynamoDB table. Mari kita mulai!

1. Masuklah ke menu AWS Lambda dengan mengetikkan Lambda di menu pencarian service.
   
    

2. Buatlah function dengan klik tombol Create function.
   
    
3. Pilih Author from scratch.
   
    
4. Di bagian Basic information, sesuaikan dengan konfigurasi untuk Lambda function pertama berikut:

   Function name	Load-Inventory
   Runtime	Python 3.8

    

5. Lanjut ke bagian berikutnya. Klik tanda panah pada Change default execution role, lalu pilih Use an existing role. Pada bagian Existing role, pilih Load-Inventory, yakni IAM role yang telah Anda buat sebelumnya. Jika sudah, silakan klik tombol Create function.
   
    
6. Scroll halaman ke bawah, pastikan Anda berada di tab Code, klik dua kali pada lambda_function.py. Setelah itu, hapus semua kode yang ada dan copy paste kode di bawah ini. Jika sudah, lanjutkan dengan klik Deploy.
   
   Catatan: Salin dulu ke notepad guna menghindari kesalahan indentasi.

   # Load-Inventory Lambda function
   #
   # This function is triggered by an object being created in an Amazon S3 bucket.
   # The file is downloaded and each line is inserted into a DynamoDB table.
    
    
   import json, urllib, boto3, csv
    
    
   # Connect to S3 and DynamoDB
   s3 = boto3.resource('s3')
   dynamodb = boto3.resource('dynamodb')
    
    
   # Connect to the DynamoDB tables
   inventoryTable = dynamodb.Table('Inventory');
    
    
   # This handler is run every time the Lambda function is triggered
   def lambda_handler(event, context):
    
    
     # Show the incoming event in the debug log
     print("Event received by Lambda function: " + json.dumps(event, indent=2))
    
    
     # Get the bucket and object key from the event
     bucket = event['Records'][0]['s3']['bucket']['name']
     key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'])
     localFilename = '/tmp/inventory.txt'
    
    
     # Download the file from S3 to the local filesystem
     try:
       s3.meta.client.download_file(bucket, key, localFilename)
     except Exception as e:
       print(e)
       print('Error getting object {} from bucket {}. Make sure they exist and your bucket is in the same region as this function.'.format(key, bucket))
       raise e
    
    
     # Read the Inventory CSV file
     with open(localFilename) as csvfile:
       reader = csv.DictReader(csvfile, delimiter=',')
    
    
       # Read each row in the file
       rowCount = 0
       for row in reader:
         rowCount += 1
    
    
         # Show the row in the debug log
         print(row['store'], row['item'], row['count'])
    
    
         try:
           # Insert Store, Item, and Count into the Inventory table
           inventoryTable.put_item(
             Item={
               'Store':  row['store'],
               'Item':   row['item'],
               'Count':  int(row['count'])})
    
    
         except Exception as e:
            print(e)
            print("Unable to insert data into DynamoDB table".format(e))
    
    
       # Finished!
       return "%d counts inserted" % rowCount

   
   
   
7. Oke, kita telah berhasil membuat AWS Lambda function. Selepas itu, kita akan membuat Amazon S3 bucket. Silakan masuk ke halaman S3.
   
    

8. Buatlah sebuah bucket dengan klik tombol Create bucket.
   
    

9. Isikan Bucket name dengan inventory-xxx (ganti xxx dengan nomor unik). Pastikan Anda memilih Asia Pacific (Singapore) ap-southeast-1 untuk AWS Region. Di halaman paling bawah, klik Create bucket.
   
    

10. Bucket Anda telah berhasil terbuat. Lanjut, masuk ke bucket yang tadi Anda buat dengan klik pada nama bucket.
    
     

11. Buka tab Properties, scroll hingga Anda menemukan bagian Event notifications. Kemudian, klik Create event notification.
    
     

12. Isilah Event name dengan Load-Inventory.
    
     

13. Pada bagian Event types, klik All object create events.
    
     

14. Di bagian Destination, sesuaikan dengan konfigurasi berikut:

    Destination	Lambda function
    Specify Lambda function	Choose from your Lambda functions
    Lambda function	Load-Inventory

Di halaman paling bawah, klik tombol Save changes.

 

15. Nice! Kita telah berhasil membuat Lambda function. Selanjutnya, kita akan membuat Amazon DynamoDB table. Silakan masuk ke halaman DynamoDB.
    
     

16. Ketika sudah masuk, lanjut klik Create table.
    
     

17. Masukkan Inventory pada Table name, lalu isikan Store untuk Primary key. Jangan lupa, centang Add sort key dan isikan dengan Item. Jika sudah, klik Create di halaman paling bawah.
    
     

18. Yeay! Kita sudah berhasil membuat AWS Lambda function, Amazon S3 bucket, dan Amazon DynamoDB table. Tahukah Anda? Kita sudah setengah jalan. Oleh karena itu, mari kita uji coba terlebih dahulu.

19. Unduh file inventory-medan berikut ke lokasi penyimpanan di komputer/laptop Anda.

20. Silakan masuk ke halaman Amazon S3, klik pada nama bucket Anda, lalu klik tombol Upload.

21. Selepas itu, klik Add files dan pilih file inventory-medan di komputer/laptop Anda. Di halaman paling bawah, klik tombol Upload.
    
     

22. Oke, kita telah mengunggah file inventory-medan. Karena AWS Lambda function kita berfungsi untuk membaca file yang diunggah di S3 dan memuatnya menjadi Amazon DynamoDB table, jadi mari kita masuk ke halaman DynamoDB.
    
     

23. Buka menu Tables, lalu klik pada nama DynamoDB table Anda, yakni Inventory.
    
     

24. Masuklah ke tab Items, Anda akan melihat beberapa item yang ada. Perhatikan, pada tabel tersebut terdapat satu item yang memiliki nilai 0 (nol). Inilah yang nantinya akan men-trigger Lambda function kedua. Tenang, kita akan membuatnya nanti.
    
     

Selamat! AWS Lambda function Anda telah berhasil membaca file yang diunggah di S3, lalu memuatnya dengan sempurna ke DynamoDB table. Selanjutnya, Anda akan membuat SNS topic dan Lambda function kedua. Jadi, mari kita meluncur!

Hands-on Lab: Implementasi Arsitektur Serverless dengan AWS Managed Services - Membuat SNS topic dan Lambda function 2

Sekarang, kita akan membuat Amazon SNS topic dan AWS Lambda function kedua, yang mana function ini akan mengeksekusi DynamoDB table dan mengirim notifikasi ke email Anda melalui Amazon SNS. Ikuti langkah-langkah berikut: 

1. Silakan masuk ke halaman Amazon SNS.
   
    

2. Buka menu Topics yang ada di sisi kiri, lalu klik tombol Create topic.
   
    

3. Pada halaman Create topic, pilih Standard. Kemudian, isikan Name dengan NoStock. Jika sudah, klik tombol Create topic di halaman paling bawah.
   
    

4. Setelah itu, scroll hingga Anda menemukan bagian Subscriptions. Lalu, klik tombol Create subscription.
   
    

5. Di halaman Create subscription, sesuaikan dengan tabel berikut:

   Protocol	Email
   Endpoint	Isi dengan email Anda

Jika sudah, silakan scroll dan klik Create subscription.

 

6. Cek pesan masuk pada email yang sudah Anda daftarkan ke dalam layanan SNS. Buka email dari AWS Notifications, kemudian klik Confirm subscription.
   
    

7. Tab browser baru pun akan terbuka, ia akan menampilkan konfirmasi bahwa email Anda telah terdaftar di SNS topic.
   
    

8. Oke, kembali ke AWS Management Console. Sekarang kita akan membuat AWS Lambda function kedua yang akan mengeksekusi DynamoDB table dan mengirim pesan ke SNS topic. Silakan masuk ke halaman AWS Lambda dengan mengetikkan lambda di kotak pencarian service.

9. Setelah berada di AWS Lambda console dashboard, klik tombol Create Function.

10. Pada halaman Create function, sesuaikan dengan konfigurasi berikut:

    Choose one of the following options to create your function	Author from scratch
    Function name	Check-Stock
    Runtime	Python 3.8

    Di bagian Permissions, klik tanda panah pada Change default execution role.

    Execution role	Use an existing role
    Existing role	Check-Stock

    Jika sudah, silakan klik tombol Create function di halaman paling bawah.

11. Scroll ke bawah, pastikan Anda berada di tab Code, klik dua kali pada lambda_function.py.

12. Hapus semua kode yang ada di code editor. Silakan copy dan paste kode berikut:
    
    Catatan: Salin dulu ke notepad untuk menghindari kesalahan indentasi.

    # Stock Check Lambda function
    #
    # This function is triggered when values are inserted into the Inventory DynamoDB table.
    # Inventory counts are checked, and if an item is out of stock, a notification is sent to an SNS topic.
     
     
    import json, boto3
     
     
    # This handler is run every time the Lambda function is triggered
    def lambda_handler(event, context):
     
     
      # Show the incoming event in the debug log
      print("Event received by Lambda function: " + json.dumps(event, indent=2))
     
     
      # For each inventory item added, check if the count is zero
      for record in event['Records']:
        newImage = record['dynamodb'].get('NewImage', None)
        if newImage:
     
     
          count = int(record['dynamodb']['NewImage']['Count']['N'])
     
     
          if count == 0:
            store = record['dynamodb']['NewImage']['Store']['S']
            item  = record['dynamodb']['NewImage']['Item']['S']
     
     
            # Construct message to be sent
            message = store + ' is out of stock of ' + item
            print(message)
     
     
            # Connect to SNS
            sns = boto3.client('sns')
            alertTopic = 'NoStock'
            snsTopicArn = [t['TopicArn'] for t in sns.list_topics()['Topics']
                            if t['TopicArn'].lower().endswith(':' + alertTopic.lower())][0]
     
     
            # Send message to SNS
            sns.publish(
              TopicArn=snsTopicArn,
              Message=message,
              Subject='Inventory Alert!',
              MessageStructure='raw'
            )
     
     
      # Finished!
      return 'Successfully processed {} records.'.format(len(event['Records']))

13. Jika sudah selesai, lanjutkan dengan klik tombol Deploy.

14. Oke, sekarang mari kita tambahkan trigger. Scroll ke atas, lalu klik Add trigger.
    
    
    

15. Silakan sesuaikan dengan tabel berikut:

    Select a trigger	DynamoDB
    DynamoDB table	Inventory

    Jika sudah, lanjut klik tombol Add yang ada di paling bawah halaman.
    

16. Yuhu! Kita telah berhasil menambahkan trigger DynamoDB ke AWS Lambda function.
    

Hands-on Lab: Implementasi Arsitektur Serverless dengan AWS Managed Services - Uji Coba

Setelah berhasil membangun arsitektur serverless, sekarang mari kita lakukan pengujian untuk mengecek apakah skenario kita berhasil atau tidak, yakni dengan mengunggah file inventory ke S3 bucket, lalu seharusnya kita akan menerima notifikasi email. Ikuti langkah-langkah berikut:

1. Unduh file inventory-makassar berikut dan simpan di lokasi penyimpanan di komputer/laptop yang mudah diingat (misalnya folder Download).
2. Masuk ke halaman Amazon S3, lalu buka bucket Anda (inventory-xxx).
3. Di tab Objects, klik tombol Upload, klik Add files, pilih file inventory-makassar. Kemudian, scroll ke halaman paling bawah dan klik Upload.
4. Ketika Anda mengunggah file tersebut, aplikasi yang sedari tadi Anda buat akan memprosesnya. Anda tak perlu melakukan apa pun lagi, tunggu saja hingga email dari AWS Notifications akan masuk.
   
    

Bagaimana? Apakah Anda sudah menerima email masuk yang menyatakan bahwa stok biji kopi toraja di kota Makassar sedang kosong? Mudah. bukan?

Hanya dengan mengunggah file laporan dari setiap gudang ke Amazon S3 bucket, Anda akan menerima email jika terdapat stok biji kopi yang kosong. Selamat ya, Anda telah berhasil mengimplementasikan arsitektur serverless di AWS.

Clean Up Hapus semua komponen yang telah Anda buat, mulai dari S3 bucket, Lambda function. DynamoDB table, dan SNS topic guna menghindari penagihan.

Ikhtisar 

Dalam modul ini kita telah mempelajari materi-materi yang menarik, di antaranya:

• Apa itu microservices?
• Bagaimana menggunakan container untuk mengubah arsitektur aplikasi Anda menjadi berbasis microservices.
• Jenis-jenis layanan container di AWS, yaitu Amazon ECS dan Fargate.
• Apa itu serverless?
• Bagaimana menggunakan AWS Lambda dan AWS API Gateway sebagai dasar dari arsitektur serverless.
• Bagaimana menggunakan AWS Step Functions untuk mengatur langkah atau state dari AWS Lambda dan API Gateway.

Pengantar ke RTO/RPO dan Backup Recovery Setup

Sampai di modul ini, kita telah berhasil membangun arsitektur mulai dari yang sederhana menggunakan Amazon S3, kemudian menambahkan komputasi dan database, lalu menghubungkan jaringan dengan VPC Peering, membuat arsitektur dengan automasi, menjadikannya elastis dengan ketersediaan yang tinggi, hingga menggunakan microservices. Luar biasa, bukan?

Sekarang kita sudah merasa yakin bahwa arsitektur yang menopang startup warung kopi akan terus tersedia dan mulus selama digunakan oleh pelanggan. Walaupun begitu, jangan sampai kita gegabah dan cuek terhadap kemungkinan kegagalan. Kita harus tetap memikirkan bagaimana caranya aplikasi kita bisa kembali berjalan/beroperasi jika infrastruktur kita tidak tersedia atau mengalami kegagalan, tentu dalam waktu dan biaya yang sesuai. 

Oleh karena itu, di modul ini kita akan kembali ke dasar atau istilahnya “Back to Basic”. Kita akan belajar hal-hal berikut:

• Perencanaan Disaster Recovery
• Strategi Recovery
• Skenario Recovery

Yuk kita mulai!

Perencanaan Disaster Recovery

Seperti yang diungkapkan oleh CTO dan Vice President of Amazon, yaitu Werner Vogels, “Everything fails, all the time.” Atau dalam bahasa Indonesia, semuanya pasti akan gagal di suatu saat. Oleh karena itu, kita harus memiliki perencanaan pemulihan sebelum kegagalan menimpa arsitektur. 

Nah, saat merencanakan, Anda perlu menentukan skala bencana atau kegagalan seperti apa yang ingin dipersiapkan? Apakah kecil, besar, atau justru kolosal?

Kegagalan berskala kecil adalah di mana Anda hanya perlu backup dan restore, kegagalan berskala besar adalah di mana beberapa sumber daya (resources) akan terpengaruh, dan kegagalan kolosal adalah di mana beberapa orang dan sumber daya akan terkena dampak.

Maka dari itu, kita akan belajar mengenai Disaster Recovery atau DR. Disaster Recovery adalah kebijakan dalam mempersiapkan dan memulihkan diri dari bencana. Bencana yang dimaksud adalah segala kejadian yang berdampak negatif pada keberlangsungan bisnis atau keuangan perusahaan. Ini termasuk kegagalan perangkat keras atau perangkat lunak, pemadaman jaringan, pemadaman listrik, kerusakan fisik pada gedung (seperti kebakaran atau banjir), human error, atau kejadian lainnya.

Biasanya, untuk meminimalkan dampak bencana, perusahaan harus menginvestasikan waktu dan sumber daya untuk merencanakan dan mempersiapkan, melatih karyawan, serta mendokumentasikan dan memperbarui proses. Jumlah investasi untuk perencanaan DR pun dapat sangat bervariasi, tergantung pada biaya potensi kegagalan.

Perusahaan yang memiliki lingkungan on-premise biasanya harus menduplikasi infrastruktur untuk memastikan ketersediaan kapasitas cadangan jika sewaktu-waktu terjadi bencana. Infrastruktur perlu disiapkan, diinstal, dan dipelihara agar mampu mendukung kebutuhan kapasitas yang diantisipasi. Selama operasi normal, infrastruktur cadangan biasanya kurang dimanfaatkan (utilisasi yang rendah) atau tersedia secara sia-sia.

Nah, dengan AWS, perusahaan Anda dapat melakukan scale up infrastruktur sesuai kebutuhan. Hebatnya, Anda hanya akan dikenakan biaya sesuai dengan penggunaan (pay-as-you-go), tidak lebih dan tidak kurang. 

Tak hanya itu, Anda akan mendapatkan akses ke infrastruktur yang sangat aman, andal, dan cepat. AWS juga memberi Anda fleksibilitas untuk mengubah dan mengoptimalkan sumber daya dengan cepat selama peristiwa DR, yang mana dapat menghasilkan penghematan biaya yang signifikan.

Konsep Availability

Sistem produksi biasanya hadir dengan tujuan uptime (waktu selama mesin beroperasi) yang sudah ditentukan atau secara implisit. Sistem Anda bisa disebut highly available (sangat tersedia) jika dapat bertahan dari kegagalan satu atau beberapa komponen (misalnya, hard disk, server, dll).

Oke, untuk memahami konsep dari Availability atau Ketersediaan, kita perlu menjabarkan beberapa istilah, seperti High Availability, Backup, dan Disaster Recovery.

Mari kita uraikan secara lebih detail.

• High Availability
  High Availability atau Ketersediaan Tinggi memberikan redundancy dan fault tolerance. Tujuannya adalah untuk memastikan layanan Anda selalu tersedia bahkan jika terjadi kegagalan.
  
  

• Backup 
  Backup atau Pencadangan adalah hal yang sangat penting untuk melindungi data dan memastikan keberlangsungan bisnis Anda. Pada saat yang sama, hal ini bisa menjadi tantangan bagaimana caranya diimplementasikan dengan baik.
  
  Di masa ini, kecepatan di mana data dihasilkan tumbuh secara eksponensial. Hal ini sangat membebani storage lokal atau on-premise, bahkan solusi backup di enterprise dan perusahaan besar telah menjadi industri yang terpisah sendiri. Data di seluruh dunia dihasilkan oleh sejumlah besar endpoint, misalnya: laptop, desktop, server, virtual machine, dan sekarang perangkat seluler.
  
  Ketahuilah! Perangkat lunak untuk backup saat ini sangat terpusat, model umumnya adalah mengumpulkan data dari banyak perangkat dan menyimpannya di satu tempat. Terkadang, salinan dari data yang disimpan itu juga dikirim ke tape. Pendekatan terpusat semacam ini berpotensi membebani target backup (misalnya server di data center cadangan) selama recovery dari bencana dan mengakibatkan recovery SLA (service-level agreement) tidak dapat terpenuhi sesuai dengan ekspektasi.
  
  Skenario backup di perusahaan umumnya terlihat seperti ini:

  • Jika Anda menginginkan akses data berkinerja tinggi, maka data harus disimpan di disk.

  • Jika Anda menginginkan penyimpanan arsip yang hemat biaya, maka data harus disimpan di dalam tape.

  • Jika Anda ingin mengarsipkan data secara off-site, Anda harus mengirimkan tape arsip secara fisik ke lokasi lain.

  • Recovery (pemulihan) dari disk lokal akan berjalan mulus, kecuali jika Anda memerlukan data dari tape, bahkan akan membutuhkan waktu lama jika tape itu tidak ada di lokasi (on-site).

Namun, jangan khawatir. Cloud telah mengubah banyak hal. Perangkat lunak backup dapat menyimpan data ke ke cloud tanpa perlu melakukan perubahan apa pun pada perangkat lunak backup itu sendiri.

• Disaster Recovery
  Seperti yang telah dibahas, Disaster Recovery (DR) adalah tentang mempersiapkan dan memulihkan diri dari bencana. Baik Availability dan Disaster Recovery, keduanya memiliki praktik terbaik yang sama, seperti pemantauan terhadap kegagalan, deploy ke beberapa lokasi, dan failover (pengalihan operasi) secara otomatis.
  
  Namun, Availability berfokus pada komponen beban kerja, sedangkan Disaster Recovery berfokus pada salinan terpisah dari keseluruhan beban kerja. Disaster Recovery juga memiliki fokus yaitu pada waktu untuk pemulihan setelah bencana.
  
  

RPO dan RTO

Dalam merencanakan Disaster Recovery, kita akan sering membahas mengenai RPO dan RTO. Berikut adalah diagram sederhana untuk menjelaskan kedua hal tersebut.

Supaya lebih jelas, mari kita jabarkan arti dari keduanya. RPO atau Recovery Point Objective adalah jumlah kehilangan data yang dapat diterima dan diukur dalam waktu. Misalnya, jika bencana terjadi pada pukul 12.00 siang dan RPO-nya adalah satu jam, maka sistem harus memulihkan semua data yang ada di sistem sebelum pukul 11.00 siang. Sehingga kehilangan data hanya akan berlangsung satu jam, yakni antara jam 11.00 dan 12.00 siang.

Oke, sekarang mari kita bahas apa itu RTO. RTO atau Recovery Time Objective adalah waktu yang diperlukan setelah gangguan untuk memulihkan kembali proses bisnis ke keadaan semula dengan tingkat kualitas layanan yang sama, sebagaimana ditentukan oleh perjanjian tingkat operasional atau Operational Level Agreement (OLA). Sebagai contoh, jika bencana terjadi pada pukul 12.00 siang dan RTO-nya adalah delapan jam, maka proses DR harus memulihkan proses bisnis ke tingkat layanan yang dapat diterima pada pukul 20.00.

Perusahaan umumnya memutuskan RPO dan RTO berdasarkan dampak finansial terhadap bisnis ketika sistem tidak tersedia. Perusahaan menentukan dampak finansial dengan mempertimbangkan banyak faktor, seperti hilangnya bisnis dan rusaknya reputasi karena downtime serta kurangnya ketersediaan sistem.

Organisasi IT kemudian merencanakan solusi untuk masalah tersebut dengan menyediakan pemulihan sistem yang hemat biaya berdasarkan RPO dalam timeline dan tingkat layanan yang ditetapkan oleh RTO.

AWS Regions bisa Mengalami Kegagalan

Di kelas ini kita sudah mempelajari dan memahami bahwa dalam satu Region, ada sedikitnya dua Availability Zone, tetapi sebagian besar AWS Regions memiliki tiga Availability Zone. Jika Anda mendesain sistem untuk bisa memanfaatkan semua Availability Zone, tentu Anda akan merasa aman, bukan?

Sangat kecil sekali kemungkinan untuk suatu Region menjadi unavailable (tidak tersedia), tetapi tentu masih mungkin jika ada peristiwa berskala sangat besar terjadi pada suatu Region—misalnya hantaman meteor.

AWS menawarkan beberapa Region di seluruh dunia, sehingga Anda dapat memilih lokasi yang paling sesuai untuk lokasi DR, selain dari lokasi di mana sistem Anda di-deploy sepenuhnya.

AWS menyajikan halaman web yang berisi daftar layanan terkini yang ditawarkan oleh Region (produk dan layanan menurut Region). AWS menjaga kebijakan isolasi Region yang ketat sehingga segala kejadian berskala besar di satu Region tidak akan memengaruhi Region lain. AWS mendorong pelanggan untuk melakukan pendekatan serupa dengan menerapkan strategi multi-region.

Jika Anda memiliki koneksi AWS Direct Connect (DX) ke AWS Regions mana pun di Amerika Serikat, maka Anda akan mendapat akses ke semua Region di AS, termasuk AWS GovCloud (AS) tanpa melalui internet publik.

Selain itu, Anda juga perlu mempertimbangkan bagaimana aplikasi di-deploy. Jika Anda men-deploy ke setiap Region secara terpisah, maka Anda dapat mengisolasi Region tersebut jika terjadi bencana dan mentransfer semua lalu lintas ke Region lain.

Jika Anda memiliki kebutuhan untuk men-deploy aplikasi dan infrastruktur baru dengan cepat, Anda bisa memiliki active-active region. Misalnya, ketika Anda men-deploy sesuatu yang menyebabkan aplikasi di suatu Region menjadi tidak tersedia atau berperilaku tidak semestinya. Anda dapat menghapus Region tersebut dari kumpulan record aktif di Route 53, mengidentifikasi akar masalah, dan kembali ke perubahan sebelumnya (rollback) sebelum mengaktifkan kembali Region tersebut.

Layanan AWS untuk Disaster Recovery

Sebelum membahas berbagai pendekatan untuk Disaster Recovery (DR), penting untuk meninjau layanan dan fitur AWS yang paling relevan dengannya. 

Saat merencanakan DR, pertimbangkanlah untuk menggunakan layanan dan fitur yang mendukung migrasi data dan penyimpanan tahan lama karena keduanya memungkinkan Anda untuk memulihkan data penting yang telah dicadangkan ke AWS saat bencana melanda. 

Untuk beberapa skenario yang melibatkan scaled-down atau fully-scaled deployment dari sistem Anda di AWS, resource komputasi juga akan diperlukan. Scaled-down deployment maksudnya adalah sistem yang dipersiapkan sebelumnya dengan skala yang lebih kecil dibandingkan dengan keadaan di production. Sedangkan fully-scaled deployment berarti lingkungan yang dipersiapkan di DR akan sama skalanya dengan production.

Selama bencana berlangsung, Anda perlu mengaktifkan resource baru atau melakukan failover ke resource yang telah dikonfigurasi sebelumnya. Resource ini tidak hanya mencakup kode dan konten, tetapi bagian lain seperti DNS entries, network firewall rules, dan virtual machine/instance. Supaya lebih jelas, mari kita lihat beberapa layanan yang dapat Anda gunakan untuk mempersiapkan Disaster Recovery pada kategori penyimpanan, komputasi, jaringan, database, dan deployment.

Disaster Recovery untuk Penyimpanan

AWS menawarkan banyak cara untuk menyimpan data Anda. Setiap layanan memiliki kemampuan yang berbeda, sehingga Anda dapat mencocokkan layanan dengan kebutuhan terhadap sistem Anda masing-masing dengan tepat.

Berikut adalah strategi duplikasi penyimpanan Anda saat menggunakan layanan AWS.

Mari kita jabarkan setiap layanan berdasarkan gambar di atas:

• Amazon S3
  Amazon S3 menyediakan infrastruktur penyimpanan yang mempunyai daya tahan yang tinggi. Layanan ini yang dirancang untuk penyimpanan data utama dan mission critical. Objek disimpan secara redundant di beberapa perangkat di berbagai fasilitas dalam suatu region, bahkan S3 didesain untuk memberikan daya tahan 99.999999999. AWS memberikan perlindungan lebih lanjut untuk penyimpanan dan pengarsipan data melalui versioning di Amazon S3, AWS MFA, bucket policy, dan AWS IAM.
  
  Untuk mempersiapkan DR pada Amazon S3, Anda bisa mengaktifkan fitur cross-region replication. Cross-region replication adalah konfigurasi tingkat bucket yang memungkinkan penyalinan objek secara otomatis dan asinkron antara bucket yang berada di Region yang berbeda. Bucket pada cross-region replication disebut source bucket dan destination bucket, bahkan bucket dapat dimiliki oleh akun AWS yang berbeda.
  
  

• Amazon S3 Glacier
  Amazon S3 Glacier menyediakan penyimpanan berbiaya yang sangat rendah untuk pengarsipan dan pencadangan data. Objek dioptimalkan untuk akses yang jarang dan waktu pengambilannya yang perlu beberapa jam masih mencukupi kebutuhan.
  
  Amazon Glacier dirancang untuk ketahanan yang sama dengan Amazon S3. Meskipun Anda perlu mempertahankan indeks data yang Anda unggah ke Amazon S3 Glacier, namun penyimpanan dari semua arsip di setiap vault Anda disimpan untuk tujuan disaster recovery. Penyimpanan vault diperbarui setiap sekali sehari.
  
  Anda dapat me-request vault inventory sebagai file JSON atau CSV yang berisi detail tentang arsip di dalam vault Anda termasuk ukuran, tanggal pembuatan, dan deskripsi arsip (jika Anda memberikannya saat mengunggah).
  
  Meskipun Amazon S3 Glacier tidak mendukung fitur Glacier to Glacier cross-region replication, Anda dapat melakukan cross-region replication ke Glacier di region lain dari kelas penyimpanan S3 Standard.
  
  

• Amazon EBS
  Amazon EBS memberi Anda kemampuan untuk membuat snapshot point-in-time (saat tertentu) dari volume data. Anda dapat menggunakan snapshot sebagai titik awal untuk membuat Amazon EBS volume baru. Bahkan, Anda dapat melindungi data untuk ketahanan jangka panjang karena snapshot tersebut akan tersimpan di layanan Amazon S3.
  
  Setelah volume dibuat, Anda dapat meng-attach (memasangnya) ke Amazon EC2 instance yang sedang berjalan. Amazon EBS volume berjalan secara independen dari daur hidup EC2 instance (artinya walaupun EC2 diakhiri, EBS tetap bisa dipasangkan ke EC2 yang lain) dan direplikasi dalam Availability Zone untuk mencegah hilangnya data.
  
  Setelah Anda membuat snapshot dan fitur EBS snapshot ini selesai menyalin ke Amazon S3 (saat status snapshot selesai), Anda dapat menyalinnya dari satu region ke region lain, atau dalam region yang sama. Amazon S3 akan melindungi data snapshot dengan enkripsi in-transit selama operasi penyalinan. Salinan snapshot akan menerima ID yang berbeda dari ID snapshot asli.
  
  

• AWS Snowball
  AWS Snowball adalah solusi transportasi data yang mempercepat perpindahan terabyte hingga petabyte data masuk dan keluar AWS menggunakan perangkat penyimpanan yang dirancang agar aman untuk transportasi fisik. Dengan menggunakan AWS Snowball, Anda dapat menghilangkan tantangan dalam mentransfer data berskala besar, termasuk biaya jaringan yang tinggi, waktu transfer yang lama, dan masalah keamanan.
  
  Karena disalin secara lokal di dalam data center Amazon, perangkat Snowball dapat mentransfer data lebih cepat daripada melakukan penyalinan melalui internet berkecepatan tinggi.
  
  

• AWS DataSync
  AWS DataSync dapat Anda gunakan untuk menyinkronkan file secara efisien dan aman dari sistem file on-premise atau cloud ke Amazon Elastic File System (Amazon EFS) dengan kecepatan hingga 10x lebih cepat daripada tools yang open source. AWS DataSync menyalin file dengan aman dan efisien melalui internet atau koneksi AWS Direct Connect.
  
  

AWS Backup

AWS Backup adalah layanan backup (pencadangan) terkelola sepenuhnya yang memudahkan Anda untuk memusatkan dan mengotomatiskan pencadangan data di seluruh layanan AWS. Dengan menggunakan AWS Backup, Anda dapat mengonfigurasi backup policy atau kebijakan pencadangan secara terpusat dan memantau aktivitas backup untuk resource AWS, seperti Amazon EBS volume, Amazon EC2 instance, Amazon RDS database, Amazon DynamoDB table, Amazon EFS file system, dan AWS Storage Gateway volume.

Disaster Recovery untuk Komputasi

Dalam konteks Disaster Recovery, sangat penting untuk dapat membuat virtual machine dengan cepat. Dengan meluncurkan instance di Availability Zone yang terpisah, Anda dapat melindungi aplikasi dari kegagalan di satu lokasi.

Anda dapat mengatur pemulihan otomatis dari EC2 instance ketika pemeriksaan status sistem (system status check) dari perangkat keras yang mendasarinya gagal. Instance akan di-reboot, tetapi akan mempertahankan ID instance, IP address, Elastic IP Addresses, lampiran EBS volume, dan detail konfigurasi lainnya. Agar pemulihan selesai, Anda harus memastikan bahwa instance secara otomatis memulai layanan atau menjalankan aplikasi apa pun sebagai bagian dari proses inisialisasinya.

Anda juga dapat mengonfigurasi AMI Anda sendiri dalam konteks merencanakan DR. AWS sangat menyarankan agar Anda mengonfigurasi dan mengidentifikasi AMI Anda sendiri sehingga AMI dapat diluncurkan sebagai bagian dari prosedur pemulihan. AMI tersebut harus dikonfigurasi sebelumnya dengan sistem operasi ditambahkan dengan bagian yang sesuai aplikasi Anda.

Disaster Recovery untuk Jaringan

Saat menghadapi bencana, kemungkinan besar Anda harus mengubah pengaturan jaringan karena sistem Anda beralih ke lokasi lain. AWS menawarkan beberapa layanan dan fitur yang memungkinkan Anda untuk mengelola dan mengubah pengaturan jaringan, seperti Amazon Route 53, Elastic Load Balancing, Amazon VPC, dan AWS Direct Connect. Perhatikan gambar di bawah ini.

Mari kita jabarkan secara lebih detail untuk setiap layanannya:

• Amazon Route 53
  Amazon Route 53 menyertakan sejumlah kemampuan load balancing global (yang mana efektif ketika Anda berurusan dengan skenario DR seperti DNS endpoint health check). Amazon Route 53 juga memiliki kemampuan untuk melakukan failover (pengalihan operasi) antara beberapa endpoint dan bahkan website statis yang dihosting di Amazon S3.
  
  

• Elastic Load Balancing
  Elastic Load Balancing secara otomatis mendistribusikan lalu lintas aplikasi yang masuk ke beberapa Amazon EC2 instance. Layanan ini memungkinkan Anda mencapai fault tolerance yang lebih besar untuk aplikasi Anda dengan menyediakan kapasitas load balancing guna merespons traffic yang masuk.
  
  

• Amazon VPC
  Dalam konteks Disaster Recovery, Anda dapat menggunakan Amazon VPC untuk memperluas topologi jaringan yang ada ke cloud. VPC adalah solusi yang sesuai untuk memulihkan aplikasi perusahaan yang biasanya ada di jaringan internal.
  
  

• AWS Direct Connect (DX)
  AWS Direct Connect memudahkan Anda untuk membuat koneksi jaringan terdedikasi dari lokasi Anda (on-premise) ke AWS. Dalam banyak kasus, hal ini dapat mengurangi biaya jaringan, meningkatkan throughput bandwidth, dan memberikan jaringan yang lebih konsisten daripada melalui internet (misalnya VPN).
  
  

Disaster Recovery untuk Database

Saat merencanakan DR pada database Anda, pertimbangkanlah untuk menggunakan layanan database Amazon RDS dan Amazon DynamoDB. Mengapa begitu? Perhatikan gambar di bawah ini.

Mari kita uraikan untuk setiap layanannya di atas.

• Amazon RDS
  Amazon RDS dapat digunakan baik dalam fase persiapan DR (untuk menyimpan data penting dalam database yang sudah berjalan) maupun dalam fase recovery/pemulihan (untuk menjalankan database production Anda).
  
  Saat Anda ingin menggunakan database di lebih dari satu Region, Amazon RDS dapat memberi kemampuan untuk melakukan snapshot data dari satu Region ke Region lain, juga menjalankan Read Replica di Region lain.
  
  Dengan menggunakan Amazon RDS, Anda dapat membagikan (shared) manual DB snapshot atau DB cluster snapshot. Anda dapat membagikan manual snapshot hingga 20 akun AWS lainnya.
  
  Anda juga dapat membagikan manual snapshot yang tidak terenkripsi (unencrypted manual snapshot) sebagai publik, sehingga membuat snapshot menjadi tersedia untuk semua akun AWS. Ingat! Berhati-hatilah saat berbagi snapshot sebagai publik, pastikan tidak ada informasi pribadi yang disertakan dalam snapshot tersebut.
  
  Amazon RDS Read Replica for MySQL dan MariaDB sekarang mendukung Multi-AZ deployment. Sehingga, ini memungkinkan Anda membangun strategi disaster recovery yang tangguh dan menyederhanakan proses upgrade untuk database engine Anda.
  
  Tak hanya itu, Amazon RDS Read Replica juga memungkinkan Anda untuk membuat satu atau beberapa salinan read-only dari database instance dalam Region yang sama atau berbeda. Pembaruan yang dibuat ke source database kemudian disalin secara asinkron ke Read Replica Anda. Selain menyediakan skalabilitas untuk beban kerja baca yang berat (read-heavy workloads), Read Replica juga dapat dipromosikan menjadi database instance sendiri bila diperlukan.
  
  

• Amazon DynamoDB
  Amazon DynamoDB dapat Anda gunakan dalam fase persiapan DR, yakni dengan menyalin data ke DynamoDB di Region lain atau ke Amazon S3. Selama fase recovery, Anda dapat melakukan scale up dalam hitungan menit dengan satu klik atau panggilan API.
  
  Global Tables (Tabel Global) dibangun di atas infrastruktur global DynamoDB sehingga dapat memberi Anda database yang multi-region, terkelola sepenuhnya, dan multi-master dengan kinerja read/write yang cepat untuk aplikasi global berskala besar. Global Tables mereplikasi Amazon DynamoDB table secara otomatis di seluruh AWS Regions pilihan Anda.
  
  Bahkan, Global Tables juga menghilangkan beban Anda dalam mereplikasi data antar-region dan menyelesaikan konflik pembaruan. Dengan begitu, Anda bisa fokus pada bisnis aplikasi. Global Tables juga memungkinkan aplikasi Anda tetap tersedia meskipun terjadi isolasi atau degradasi di seluruh Region.
  
  

Disaster Recovery untuk Deployment

Dalam melakukan pemulihan atau recovery, salah satu hal yang perlu Anda hindari adalah melakukannya secara manual. AWS memiliki beberapa tools yang dapat Anda gunakan dalam melakukan automasi saat melakukan recovery, perhatikan gambar di bawah ini.

Untuk memperjelas pembahasan, mari kita jabarkan satu per satu.

• AWS CloudFormation
  AWS CloudFormation memungkinkan Anda membuat model dari keseluruhan infrastruktur Anda dalam bentuk file teks. Oleh karenanya, ini membantu Anda untuk menstandarisasi komponen infrastruktur yang digunakan di seluruh organisasi, mendapatkan compliance di sisi konfigurasi, dan memungkinkan pemecahan masalah lebih yang cepat.
  
  AWS CloudFormation menyediakan sumber daya Anda dengan cara yang aman dan dapat diulang, memungkinkan Anda untuk membangun (build) serta membangun kembali (rebuild) infrastruktur dan aplikasi Anda tanpa harus melakukan tindakan manual. AWS CloudFormation menangani penentuan operasi yang tepat untuk dilakukan saat mengelola Stack Anda dan mengembalikan perubahan secara otomatis jika terdeteksi adanya kesalahan.
  
  

• AWS Elastic Beanstalk
  AWS Elastic Beanstalk dapat Anda gunakan untuk mengunggah kode dan men-deploy-nya ke lingkungan AWS Elastic Beanstalk atau men-deploy ulang dari versi yang telah diunggah sebelumnya.
  
  

• AWS OpsWorks
  AWS OpsWorks adalah layanan manajemen aplikasi yang memudahkan proses deploy dan pengoperasian aplikasi dari semua jenis dan ukuran. Anda dapat menentukan lingkungan sebagai serangkaian layer dan mengonfigurasi setiap layer sebagai tingkat aplikasi Anda.
  
  AWS OpsWorks memiliki fitur automatic host replacement (penggantian host otomatis). Jadi jika terjadi kegagalan instance, maka ia akan diganti secara otomatis. Anda juga dapat menggunakan AWS OpsWorks dalam fase persiapan untuk membuat template lingkungan Anda. Anda bisa menggabungkannya dengan AWS CloudFormation dalam fase pemulihan (recovery).

Strategi Recovery

Sedari tadi kita telah membahas tentang persiapan untuk Disaster Recovery. Nah, sekarang kita akan mempelajari beberapa strategi yang dapat digunakan untuk recovery atau pemulihan. Terdapat empat strategi, yakni Backup and Restore, Pilot Light, Fully Working Low-Capacity Standby, dan Multi-Site Active-Active.

Penasaran seperti apa perbedaan dari keempat strategi tersebut? Yuk kita lanjutkan di materi berikutnya.

Backup and Restore

Di sebagian besar lingkungan tradisional, data di-backup (dicadangkan) ke tape penyimpanan dan dikirim ke luar lokasi data center secara berkala. Jika Anda menggunakan metode ini, maka tentu akan memerlukan waktu yang lama untuk memulihkan sistem Anda semisal terjadi gangguan atau bencana.

Amazon S3 adalah tujuan ideal untuk mem-backup data yang mungkin diperlukan dengan cepat untuk melakukan pemulihan. Dengan mentransfer data ke dan dari Amazon S3, Anda dapat mengakses data Anda dari lokasi mana pun. Berikut adalah contoh skenario penggunaan Amazon S3 untuk backup:

• Anda dapat menggunakan AWS Snowball untuk mentransfer kumpulan data yang sangat besar dengan mengirimkan perangkat penyimpanan langsung ke AWS.

• Untuk penyimpanan data jangka panjang, jika Anda tak masalah dengan waktu pengambilan yang membutuhkan waktu beberapa jam, gunakanlah Amazon Glacier. Layanan ini memiliki model ketahanan yang sama dengan Amazon S3. Amazon Glacier dan Amazon S3 dapat digunakan bersama untuk menghasilkan solusi pencadangan bertingkat.
  
  

Backup Data On-Premise ke AWS

Jika Anda memiliki kebutuhan untuk mem-backup data on-premise ke AWS, maka Anda perlu berkenalan dengan layanan AWS Storage Gateway. Layanan ini menghubungkan peralatan perangkat lunak di on-premise dengan penyimpanan berbasis cloud. AWS Storage Gateway menyediakan integrasi yang mulus dan sangat aman antara lingkungan IT di on-premise Anda dan infrastruktur penyimpanan AWS. 

AWS Storage Gateway mendukung protokol penyimpanan berstandar industri, yang bekerja dengan aplikasi Anda dan menyimpan semua data dan dengan aman terenkripsi di Amazon S3 atau Amazon Glacier. Layanan ini juga terintegrasi dengan Amazon CloudWatch, AWS CloudTrail, AWS KMS, AWS IAM, dan lain-lain.

AWS Storage Gateway mendukung tiga antarmuka penyimpanan: file, volume, dan tape. Mari kita bahas ketiganya.

• File gateway
  File gateway memungkinkan Anda untuk menyimpan dan mengambil objek di Amazon S3 menggunakan protokol file NFS dan SMB. Objek yang disimpan melalui file gateway dapat langsung diakses di S3.
  
  

• Volume Gateway
  Volume Gateway menyediakan penyimpanan blok (block storage) ke aplikasi Anda menggunakan protokol iSCSI. Data pada volume disimpan di Amazon S3. Anda dapat mengambil salinan dari volume Anda menggunakan AWS Backup, yang disimpan di AWS sebagai Amazon EBS snapshot.
  
  Untuk volume gateway, Anda dapat menggunakan cached volume atau stored volume.

  • Gateway-Cached Volume
    Anda dapat menyimpan data primer Anda di Amazon S3 dan menyimpan data yang sering diakses secara lokal. Volume yang disimpan dalam cache gateway memberikan penghematan biaya yang substansial pada penyimpanan utama, meminimalkan kebutuhan untuk menskalakan penyimpanan Anda di lokal, dan mempertahankan akses latensi rendah ke data yang sering diakses.

  • Gateway-Stored Volume
    Jika Anda memerlukan akses latensi rendah ke seluruh kumpulan data Anda, Anda dapat mengonfigurasi data gateway lokal Anda untuk menyimpan data primer Anda secara lokal dan secara asinkron mencadangkan snapshot point-in-time dari data ini ke Amazon S3.
    
    

• Tape Gateway
  Tape Gateway menyediakan aplikasi backup dengan antarmuka iSCSI Virtual Tape Library (VTL) yang terdiri dari virtual media changer, virtual tape drives, dan virtual tapes. Data yang disimpan di virtual tape disimpan di Amazon S3 atau dapat diarsipkan ke Amazon Glacier.
  
  Anda dapat memiliki koleksi virtual tape tidak terbatas. Setiap virtual tape dapat Anda simpan di virtual tape library (VTL) yang didukung oleh Amazon S3 atau virtual tape shelf yang didukung oleh Amazon Glacier.
  
  

Untuk mem-backup data on-premise ke AWS Cloud menggunakan AWS Storage Gateway, Anda dapat memilih di antara dua pendekatan umum:

• Menyimpan data backup secara langsung ke Amazon S3 dengan melakukan panggilan API ke layanan AWS.

• Menyimpan atau mengambil data backup melalui permintaan HTTP PUT dan GET yang aman langsung di Internet. Di sini, titik akhir itu sendiri membuat koneksi langsung dengan Amazon S3 untuk menulis data dan mengambil data.

Tunggu, tak sampai di sana. AWS Storage gateway juga memiliki fitur lainnya, yakni AWS Storage Gateway Hardware Appliance. Ia adalah peralatan perangkat keras (hardware appliance) yang menyediakan perangkat lunak AWS Storage Gateway yang telah diinstal sebelumnya di server pihak ketiga dan bisa diinstal di on-premise. 

Berikut adalah contoh infrastruktur untuk penggunaan AWS Storage Gateway dengan dukungan tiga antarmuka penyimpanan, File gateway, Volume gateway, dan Tape gateway.

Oke, setelah menilik tentang layanan AWS Storage Gateway, selanjutnya mari kita belajar mengenai kasus penggunaannya.

Kasus Penggunaan AWS Storage Gateway: Solusi Off-Site Backup dengan Gateway-Stored Volume
Setelah menginstal perangkat lunak AWS Storage Gateway--virtual machine--pada host di data center on-premise dan mengaktifkannya, Anda dapat membuat storage gateway volumes, lalu memetakannya ke Direct Attached Storage (DAS) atau Storage Area Network (SAN) di on-premise.

Anda dapat memulai dengan disk baru atau disk yang sudah menyimpan data. Kemudian, pasanglah storage volumes ini ke server aplikasi on-premise Anda sebagai perangkat iSCSI. Saat aplikasi on-premise melakukan proses write dan read data ke dan dari storage volume, data tersebut disimpan dan diambil dari volume disk yang sudah ditetapkan.

Untuk menyiapkan data yang akan diunggah ke Amazon S3, gateway Anda juga menyimpan data yang masuk di area staging (atau disebut sebagai upload buffer). Kemudian, gateway Anda mengunggah data dari upload buffer melalui koneksi Secure Sockets Layer (SSL) terenkripsi ke layanan AWS Storage Gateway yang berjalan di AWS Cloud. Layanan tersebut kemudian menyimpan data di Amazon S3.

Selain itu, Anda juga bisa melakukan incremental backup, yang disebut snapshot, dari storage volume Anda. AWS Storage Gateway akan menyimpan snapshot tersebut di Amazon S3 sebagai Amazon EBS snapshot.

Saat Anda mengambil snapshot baru, hanya data yang telah berubah sejak snapshot terakhir sajalah yang disimpan. Anda dapat memulai snapshot berdasarkan jadwal atau hanya satu kali. Ketika Anda menghapus snapshot, hanya data yang tidak diperlukan untuk snapshot lain sajalah yang dihapus.

Anda dapat me-restore (memulihkan) Amazon EBS snapshot ke storage gateway volume di on-premise jika Anda perlu memulihkan data. Anda juga dapat menggunakan snapshot sebagai starting point alias titik awal untuk Amazon EBS volume baru, yang kemudian dapat Anda hubungkan ke EC2 instance.

Kasus Penggunaan AWS Storage Gateway: Restore Backup ke Data Center On-Premise dengan Gateway-Stored Volume
Untuk gateway-stored volumes, data volume Anda disimpan di on-premise. Dalam kasus ini, snapshot menyediakan off-site backup yang tahan lama di Amazon S3. Misalnya, jika disk lokal yang dialokasikan sebagai storage volume mengalami masalah, Anda dapat membuat disk lokal baru dan me-restore (memulihkan) snapshot ke dalamnya selama proses pembuatan volume.

Setelah memulai proses restore snapshot ke gateway-stored volume, data snapshot diunduh di latar belakang. Fungsionalitas semacam ini menandakan bahwa setelah Anda membuat volume dari snapshot, tidak perlu menunggu semua data ditransfer dari Amazon S3 ke volume Anda. Setelah proses unduh selesai, aplikasi Anda dapat mulai mengakses volume tersebut dan semua datanya. 

Jika aplikasi Anda mengakses sepotong data yang belum dimuat, gateway segera mengunduh data yang diminta dari Amazon S3. Kemudian, gateway melanjutkan proses memuat data volume lainnya di latar belakang.

Pilot Light

Pola ini relatif murah untuk diterapkan. Dalam fase persiapan DR, penting untuk mempertimbangkan penggunaan layanan dan fitur yang mendukung migrasi data dan penyimpanan tahan lama, karena keduanya memungkinkan Anda memulihkan data penting yang dicadangkan ke AWS saat bencana melanda. Untuk beberapa skenario yang melibatkan deployment dalam skala kecil atau besar dari keseluruhan sistem Anda di AWS, sumber daya komputasi juga akan diperlukan.

Perhatikan gambar di atas, arsitektur tersebut memiliki lingkungan di on-premise yang berisi komponen web server, app server, dan database utama. Selain itu, ada juga lingkungan Pilot Light di AWS yang berisi web server dan app server (nonaktif), serta database kedua yang selalu aktif dan direplikasi dari database utama. Cara kerja dari strategi ini adalah ketika bencana melanda lingkungan on-premise, sistem akan mengalihkan operasinya ke lingkungan Pilot Light AWS.

Saat bereaksi terhadap bencana, penting untuk menyiapkan sumber daya komputasi dengan cepat untuk mulai menjalankan sistem Anda di AWS atau mengatur failover ke sumber daya yang sudah berjalan di AWS. Bagian infrastruktur yang harus ada mencakup DNS, fitur jaringan, dan berbagai fitur Amazon EC2.

Dalam fase persiapan, Anda perlu mereplikasi data yang sering berubah secara teratur ke lingkungan Pilot Light. Untuk data yang jarang diperbarui, seperti sistem operasi dan aplikasi, dapat Anda perbarui dan simpan secara berkala sebagai AMI.

Untuk mempersiapkan Disaster Recovery menggunakan strategi Pilot Light, berikut adalah tahapan-tahapannya:Siapkan Amazon EC2 instance untuk mereplikasi data.

• Pastikan Anda memiliki semua paket perangkat lunak pendukung yang tersedia di AWS.
• Buat dan kelola Amazon Machine Images (AMI) dari server utama yang memerlukan recovery (pemulihan) cepat.
• Secara teratur jalankan, uji, dan perbarui software atau perubahan konfigurasi apa pun untuk server di lingkungan Pilot Light.
• Pertimbangkan untuk mengotomatiskan pembuatan sumber daya AWS.

Nah, lalu bagaimana jika bencana terjadi sehingga membuat sistem utama kita mengalami kegagalan? Dengan strategi Pilot Light, maka:

• Secara otomatis menjalankan sumber daya di lingkungan Pilot Light di AWS.
• Lakukan scale pada sistem sesuai kebutuhan untuk menangani lalu lintas production terkini.
• Beralih ke sistem yang baru.
• Sesuaikan DNS record agar mengarah ke AWS.

Dengan strategi Pilot Light, RTO (Recovery Time Objective)-nya adalah selama waktu yang diperlukan untuk mendeteksi kebutuhan DR dan mengaktifkan sistem DR. Sedangkan RPO (Recovery Point Objective)-nya tergantung pada jenis replikasi yang diterapkan.

Fully Working Low-Capacity Standby

Low capacity standby (siaga berkapasitas rendah) amatlah serupa seperti Pilot Light dengan level lebih lanjut. Istilah Warm Standby digunakan untuk menggambarkan skenario DR di mana melibatkan versi deployment dengan skala kecil (yang aktif berjalan di cloud) dari keseluruhan sistem Anda.

Solusi Warm Standby memungkinkan Anda untuk semakin mengurangi recovery time (waktu pemulihan) karena beberapa layanan berjalan secara aktif. Dengan mengidentifikasi sistem bisnis, Anda dapat sepenuhnya menduplikasi sistem ini di AWS dan selalu mengaktifkannya.

Gambar di atas menunjukkan arsitektur yang menggunakan strategi Fully Working Low-Capacity Standby. Perhatikan, pada data center on-premise terdapat dua komponen web server, dua app server, dan satu database utama. Sedangkan di AWS, terdapat lingkungan berkapasitas rendah, yakni hanya satu web server, satu app server, dan satu database kedua yang direplikasi dari database utama. Arsitektur tersebut juga menggunakan Amazon Route 53 untuk mendistribusikan permintaan antara sistem utama (on-premise) dan cloud (AWS).

Server di AWS dapat berjalan pada armada Amazon EC2 instance dengan jumlah minimum dan ukuran terkecil. Strategi ini tidak melakukan scale untuk menangani keseluruhan beban production, melainkan sekadar cukup untuk berfungsi secara penuh. Strategi ini dapat Anda gunakan untuk pekerjaan non-production, seperti testing, quality assurance, dan penggunaan internal.

Nah, saat bencana melanda, barulah sistem akan di-scale dengan cepat untuk menangani beban produksi. Di AWS, hal ini dapat dilakukan dengan menambahkan lebih banyak instance ke Load Balancer dan dengan mengubah ukuran server berkapasitas kecil agar dijalankan pada tipe instance Amazon EC2 yang lebih besar. Ingat! Horizontal scaling lebih disarankan daripada vertical scaling.

Cara kerjanya begini. Jika lingkungan utama (dalam kasus ini adalah on-premise) tidak tersedia, Amazon Route 53 beralih ke sistem sekunder (AWS) yang dirancang untuk meningkatkan kapasitasnya secara otomatis jika terjadi failover dari sistem utama.

Saat menggunakan strategi Fully Working Low-Capacity Standby untuk DR, Anda perlu melakukan beberapa tahapan, antara lain:

• Persiapan mirip dengan Pilot Light.
• Semua komponen yang diperlukan berjalan 24/7, tetapi tidak di-scale untuk lalu lintas production.
• Terapkanlah praktik terbaik, yakni melakukan pengujian secara berkelanjutan.
• Alihkan sebagian kecil traffic dari production ke situs DR.

Nah, saat bencana melanda, maka:

• Langsung melakukan failover (pengalihan operasi) untuk beban production.
• Sesuaikan DNS agar mengarah ke AWS.
• Scale sistem Anda (baik Auto Scaling maupun manual) lebih lanjut untuk menangani semua beban production.

Dengan strategi Fully Working Low-Capacity Standby, RTO (Recovery Time Objective)-nya adalah:

• Untuk beban kerja penting/kritis : Selama waktu yang dibutuhkan untuk me-recovery (memulihkan) sistem. 
• Untuk semua beban kerja lainnya : Selama waktu yang dibutuhkan untuk scale agar memenuhi kebutuhan beban kerja.

Sedangkan RPO (Recovery Point Objective)-nya tergantung pada jenis replikasi.

Multi-Site Active-Active

Strategi untuk Disaster Recovery selanjutnya adalah dengan menjalankan sistem yang berfungsi sepenuhnya di AWS pada waktu yang sama dengan sistem di on-premise. Perkenalkan Multi-Site Active-Active.

Solusi multi-site berjalan di AWS dan juga di infrastruktur on-premise Anda, dalam konfigurasi active-active (keduanya aktif). Metode replikasi data yang Anda gunakan akan ditentukan oleh recovery point (titik pemulihan) yang Anda pilih.

Gambar di atas menunjukkan arsitektur yang menggunakan strategi Multi-Site Active-Active. Baik lingkungan on-premise maupun AWS keduanya aktif secara bersamaan dengan kapasitas penuh untuk mendukung beban production.

Anda dapat menggunakan layanan DNS yang mendukung weighted routing (perutean berbobot), seperti Amazon Route 53, untuk merutekan lalu lintas production ke lokasi berbeda yang menyajikan aplikasi atau layanan yang sama. Sebagian traffic akan masuk ke infrastruktur di AWS dan sisanya ke infrastruktur di on-premise Anda.

Saat bencana terjadi, Anda dapat menyesuaikan pembobotan DNS (DNS weighting) dan mengirim semua traffic ke server AWS. Anda dapat menggunakan Amazon EC2 Auto Scaling untuk mengotomatiskan proses peningkatan kapasitas dalam menangani beban production secara penuh. Anda juga bisa menambahkan beberapa logika aplikasi untuk mendeteksi kegagalan layanan database utama (DB primary) dan beralih ke layanan database paralel (DB secondary) yang berjalan di AWS.

Saat Anda menggunakan strategi Multi-Site Active-Active untuk DR, Anda perlu melakukan beberapa tahapan, antara lain:

• Persiapan mirip dengan low-capacity standby.
• Scaling in atau scaling out sepenuhnya untuk menangani beban production.

Nah, saat bencana melanda, maka sistem akan melakukan failover segera untuk semua beban production.

Dengan strategi Multi-Site Active-Active, RTO (Recovery Time Objective)-nya adalah selama waktu yang dibutuhkan untuk failover. Sedangkan RPO (Recovery Point Objective)-nya tergantung pada jenis replikasi.

Praktik Terbaik untuk Mempersiapkan Disaster Recovery

Setelah membahas berbagai cara yang dapat dilakukan dalam mempersiap disaster recovery, sekarang mari kita lihat beberapa praktik terbaiknya. Amati poin-poin berikut:

Mari kita uraikan satu per satu.

• Mulailah dari yang paling mudah dan sederhana, lalu tingkatkan ke tingkat yang lebih lanjut. 

  • Anda bisa mulai dengan melakukan backup di AWS. 
  • Kemudian, tingkatkan RTO/RPO secara bertahap sebagai upaya berkelanjutan.

• Periksalah masalah lisensi dari semua perangkat lunak Anda. Memastikan bahwa Anda memiliki lisensi yang benar untuk lingkungan AWS Anda itu sama pentingnya dengan lisensi untuk lingkungan lainnya. 

  • AWS menyediakan berbagai model untuk membuat pemberian lisensi lebih mudah untuk Anda kelola. Misalnya, "Bring Your Own License” (Bawa Lisensi Anda Sendiri) memungkinkan untuk beberapa komponen perangkat lunak atau sistem operasi. 
  • Sebagai alternatif, ada berbagai perangkat lunak yang biaya lisensinya termasuk dalam biaya per jam. Ini dikenal sebagai "License included”.

• Lakukan latihan untuk solusi Disaster Recovery Anda. 

  • Dengan melakukan latihan, itu akan menguji sistem atau bahkan seluruh region yang akan offline. 
  • Anda juga harus memastikan data backup, snapshot, AMI, dll berfungsi dengan normal. 
  • Terakhir, pantau sistem monitoring Anda.

Ikhtisar

Saat membangun aplikasi, ia bisa menjadi hal yang kompleks untuk dikelola. Kelangsungan bisnis memastikan bahwa bisnis akan terus beroperasi atau pulih dengan cepat meskipun terjadi bencana serius.

Pada modul ini, kita telah belajar beberapa hal dalam mempersiapkan pemulihan jika terjadi bencana, seperti konsep Availability, RPO dan RTO, dan layanan AWS untuk Disaster Recovery. Kita juga telah menguraikan empat skenario Disaster Recovery (DR) yang menyoroti penggunaan AWS dan on-premise, di antaranya:

• Backup and Restore
• Pilot Light
• Fully Working Low-Capacity Standby Sepenuhnya
• Multi-Site Active-Active

Perhatikan gambar di bawah ini:

Gambar di atas menunjukkan spektrum untuk empat skenario yang disusun berdasarkan seberapa cepat sistem dapat tersedia bagi pengguna setelah peristiwa DR.

AWS memungkinkan Anda untuk mengoperasikan setiap strategi DR ini dengan hemat biaya. Jika aplikasi Anda sudah berjalan di AWS, maka Anda bisa menggunakan implementasi multi Region dan menerapkan strategi DR yang baru saja kita pelajari.

Pengantar ke Pengoptimalan dan Ringkasan

Wah, tidak terasa ya kita sudah mencapai modul akhir dari kelas ini. Ada banyak sekali materi yang telah kita pelajari. Mulai dari komputasi, database, jaringan, keamanan, microservices, serverless, hingga cara agar arsitektur kita siap jika terjadi bencana. 

Bahkan, arsitektur startup warung kopi kita pun terus berkembang. Diawali dengan arsitektur sederhana untuk hosting website statis seperti ini:

Sekarang, arsitektur startup warung kopi kita menjadi kompleks seperti di bawah ini:

Luar biasa, kan? Perjalanan kita cukup panjang untuk tiba di modul ini. Jadi, berikan apresiasi untuk diri Anda! Nah, sekarang di modul ini kita akan mengulas beberapa hal yang sudah pernah dipelajari. Tak hanya itu, kita juga akan belajar bagaimana membuat arsitektur yang telah kita bangun menjadi lebih optimal. Mari kita mulai!

Hal-Hal yang Perlu Dipikirkan

Mari kita kilas balik. Sejauh ini, kita telah berlatih membangun berbagai macam arsitektur. Mulai dari yang paling sederhana, yakni meng-hosting website statis menggunakan S3, hingga mengimplementasikan arsitektur serverless menggunakan AWS Lambda. Amazon DynamoDB, dan Amazon SNS.

Nah, setelah mampu membangun arsitektur di AWS, sekarang Anda akan diberikan beberapa pertanyaan untuk mengevaluasi arsitektur Anda sendiri.

Apakah Anda sudah menggunakan sumber daya yang tepat?

Sering kali, ketika suatu perusahaan membeli perangkat keras untuk ditempatkan di data center, mereka terhalang oleh anggaran (budget) dan berharap perangkat keras tersebut akan awet sampai masa depan.

Tahukah Anda? Perangkat keras terbaik saat ini akan tertinggal teknologinya dalam waktu sekitar 2-3 tahun ke depan, bahkan bisa jadi terjadi dalam kurun waktu lebih pendek. Jadi, perusahaan akan terpaksa membeli perangkat keras lagi di kemudian hari untuk mencegah ketertinggalan ini.

Oleh karena itu, saat mempertimbangkan untuk membangun data center sendiri, tanyakan pada diri Anda, "Apa yang saya butuhkan saat ini?" Anda harus menyesuaikan jenis perangkat keras yang Anda beli. Jika beban kerja Anda berat, tentu Anda tak bisa membeli perangkat keras yang murah.

Lalu, bagaimana jika beban kerja Anda itu beragam, seperti machine learning, analytics, database, dan arsip? Tentu, Anda harus menggunakan jenis perangkat keras yang sesuai untuk masing-masing beban kerja tersebut.

Atau coba Anda pikirkan, "Apakah sebaiknya saya menggunakan managed service (layanan terkelola)?

Layanan terkelola, seperti Amazon RDS, memungkinkan Anda untuk membangun sumber daya di AWS tanpa harus memikirkan kelengkapan persyaratan terlebih dahulu. 

Katakanlah seorang developer membutuhkan database Microsoft SQL Server, tetapi Anda belum pernah menginstal perangkat lunak tersebut sebelumnya. Tentu saja, ini akan memakan banyak waktu dan upaya. 

Daripada seperti itu, Anda bisa mencari tahu jenis database apa yang dibutuhkan dan biarkan AWS membangunnya untuk Anda. Dengan AWS, Anda memiliki kendali penuh atas database, data, dan aksesnya.

Apakah arsitektur Anda cukup tangguh?

Saat membangun arsitektur, Anda perlu bertanya pada diri sendiri, “Apa yang akan rusak? Apakah arsitektur ini cukup tangguh?”

Untuk membuat arsitektur AWS yang tangguh, Anda perlu memastikan bahwa tidak ada salah satu titik/poin yang dapat menyebabkan kegagalan. Dan walaupun terjadi kegagalan atau bahkan bencana, sistem yang Anda buat haruslah bisa pulih dari bencana (disaster recovery). Saat terjadi kegagalan, gantilah sistem yang rusak terlebih dahulu, barulah selepas itu cari tahu penyebabnya.

Di AWS, Anda dapat menjalankan simulasi pemulihan bencana (disaster recovery) tanpa memengaruhi lingkungan production Anda. Yup, biayanya mungkin beberapa dolar, tetapi itu jauh lebih murah daripada membangun data center kedua.

Tak hanya itu, dengan menggunakan AWS, Anda dapat menyiapkan lingkungan yang dapat memantau dirinya sendiri, mengganti hal-hal yang rusak sesuai kebutuhan, lalu memberi tahu Anda apa yang terjadi. Bahkan, Anda bisa membuat lingkungan baru saat lingkungan Anda mengalami kegagalan. Itulah yang dinamakan self-healing. Jadi, jika bisa otomatis, kenapa harus melakukannya secara manual?

Apakah arsitektur Anda sudah loosely coupled?

Microservices adalah salah satu cara terbaik untuk meningkatkan keandalan dan ketersediaan arsitektur Anda. Pendekatan ini dapat membantu meningkatkan kecepatan inovasi Anda, yakni dengan mengurangi ketergantungan di antara komponen aplikasi. Tim Anda akan dapat bertindak secara asinkron untuk memberikan pembaruan fitur tanpa memengaruhi seluruh sistem.

Aplikasi yang loosely coupled biasanya diimplementasikan menggunakan arsitektur berorientasi pesan (message-oriented). Semakin loosely coupled komponen aplikasi Anda, semakin baik proses scale-nya. 

Rancanglah aplikasi Anda agar terdiri dari komponen yang independen dan pisahkan interaksinya sejauh mungkin. Untuk mencapai tujuan tersebut, Anda dapat menggunakan layanan Amazon SQS. Layanan ini memastikan bahwa aplikasi tetap berfungsi walaupun dengan konkurensi yang tinggi, beban tak terduga, dan/atau lonjakan traffic.

Apakah arsitektur Anda dapat scale secara efektif?

Untuk menangani traffic pengguna yang fluktuatif (misal dari 100 pengguna ke 1 juta pengguna), Anda mungkin menginginkan mesin yang terbaik, tercepat, dan terkuat untuk menangani beban kerja Anda. Namun, jika Anda tidak menggunakan mesin tersebut secara maksimal, tentu itu akan membuang-buang uang.

Saat menggunakan data center on-premise, Anda mungkin memerlukan waktu sekitar 3 bulan guna mendapatkan pola data traffic yang tepat untuk menyiapkan kapasitas yang memadai. Sehingga, Anda harus membeli mesin dengan kapasitas yang lebih besar dari yang Anda butuhkan. 

Selepas itu, barulah Anda dapat menyesuaikannya. Jika ternyata mesin yang Anda beli terlalu berlebihan, maka Anda harus menguranginya sebagian. Namun mesin tersebut jika tak cukup, Anda harus membeli mesin lagi.

Tentu ini berbeda jika Anda menjalankan beban kerja di AWS. Anda bisa memiliki mesin yang dapat menyesuaikan kapasitas (scale) secara efektif. Kabar baiknya adalah bahwa di AWS biayanya transparan, sehingga Anda bisa mengetahui bahwa menjalankan instance baru jauh lebih murah daripada membangun server fisik.

Tahukah Anda? Ada dua jenis kegagalan dalam dunia IT, antara lain:

• Ada yang rusak karena Anda meminta perangkat keras atau perangkat lunak untuk melakukan sesuatu di luar toleransi yang ditentukan.

• Produk Anda menjadi sangat sukses dan digunakan oleh banyak sekali pengguna, sehingga menyebabkan perangkat keras dan perangkat lunak Anda melebihi toleransi yang ditentukan.

Oleh karena itu, Auto Scaling dapat membantu Anda dalam hal ini. Memang, Auto Scaling membutuhkan biaya, tetapi tanpanya, aplikasi Anda akan tidak dapat bekerja dengan baik karena tidak sanggup menangani beban. Anggaplah biaya tersebut sepadan dengan investasi agar aplikasi Anda tetap berjalan.

Ubah Arsitektur Tightly Coupled Menjadi Loosely Coupled

Saat membangun arsitektur cloud, buatlah agar setiap komponennya tidak saling bergantung satu sama lain, alias loosely coupled. Sehingga ketika satu komponen mengalami kegagalan, komponen lain tidak akan terpengaruh. Coba perhatikan contoh gambar arsitektur aplikasi pesanan di bawah ini. 

Pada contoh di atas, aplikasi bertanggung jawab untuk menangani dan mempertahankan data pesanan, serta menangani peningkatan lalu lintas untuk beberapa permintaan yang sangat populer.

Tahukah Anda? Salah satu titik kerentanan yang potensial dalam alur kerja pemrosesan pesanan adalah pada saat menyimpan data ke dalam database. Bisnis tentunya mengharapkan bahwa setiap pesanan segera disimpan ke dalam database. Namun, setiap potensi deadlock (kebuntuan) atau masalah jaringan dapat menyebabkan kegagalan dalam penyimpanan pesanan. Kemudian, pesanan pun akan hilang tanpa ada jalan lain untuk memulihkannya.

Dengan kemampuan log yang baik, Anda mungkin dapat mengidentifikasi kapan terjadi kesalahan dan pesanan pelanggan mana yang gagal. Walaupun hal itu tidak akan memulihkan transaksi kembali.

Di sini kita menggunakan SQS Customer Order Queue sebagai penghubung sekaligus buffer antara instance front-end dan back-end yang melakukan pemrosesan pesanan. 

Setiap pesanan pelanggan dilayani oleh instance front-end. Proses ini akan berjalan sangat cepat karena front-end terbebas dari ketergantungan proses di back-end. Kemudian, instance front-end meneruskan pesanan pelanggan ke Customer Order Queue. 

Selanjutnya, pesanan yang berada di Queue akan diproses oleh instance back-end yang dapat melakukan scaling secara otomatis. Setelah itu, barulah pesanan pelanggan disimpan dan diproses di database. 

Jika terdapat pesanan yang tidak terproses karena hal tertentu, pesanan tersebut akan disimpan di Dead Letter Queue, sehingga tim Anda dapat memeriksanya.

Manfaatkan Model Penetapan Harga di Amazon EC2

Dalam merancang arsitektur, manfaatkanlah beberapa model penentuan harga pada Amazon EC2. Tentu kita telah mempelajari beberapa jenis penentuan harga EC2 instance, seperti On-Demand Instances, Reserved Instances, Savings Plans, dan Spot Instance. Untuk mempermudah penjelasan, silakan perhatikan gambar di bawah ini. 

Grafik bagian kiri memperlihatkan lalu lintas yang dimiliki oleh suatu perusahaan aplikasi yang menggunakan On-Demand Instances. Dapat Anda lihat, terjadi lonjakan traffic selama jam kerja, lalu menurun kembali setelah menjelang malam.

Nah, pada bagian kanan, perusahaan tersebut mengambil pendekatan yang lebih kompleks, yakni mencoba memanfaatkan ketiga model harga (Reserved Instances, On-Demand Instances, dan Spot Instances). 

Perusahaan menggunakan Reserved Instances untuk memenuhi kebutuhan komputasi tingkat dasar atau sering disebut baseline. Jika kapasitas Reserved Instances tidak memadai, beberapa instance tambahan akan muncul sebagai On-Demand. Kemudian, untuk kebutuhan selanjutnya ditangani dengan Spot Instances. 

Dengan demikian, perusahaan tersebut dapat menghemat dengan menggunakan Spot Instances daripada On-Demand. Namun, hal itu membuat perusahaan harus siap menghadapi penghentian (interupsi) instance yang tidak terduga dari AWS. Hal ini dapat menyebabkan hilangnya data atau kurangnya kapasitas yang tidak lagi memadai bagi pelanggan mereka. Itulah mengapa model Spot Instances hanya boleh diterapkan dalam keadaan di mana beban kerja Anda tidak akan mengalami masalah dengan mekanisme penghentian instance yang tiba-tiba. 

Dengan Spot Instances, Anda cukup membayar harga Spot yang berlaku untuk periode waktu saat instance Anda berjalan. 

Selain itu, untuk mengurangi dampak interupsi dan mengoptimalkan Spot Instances, lakukan diversifikasi dan jalankan aplikasi Anda di beberapa kumpulan kapasitas. Kelompokkan setiap instance family, setiap ukuran instance, di setiap Availability Zone, di setiap Region menjadi kumpulan Spot terpisah. Anda dapat menggunakan operasi API RequestSpotFleet untuk meluncurkan ribuan Spot Instances dan mendiversifikasi sumber daya secara otomatis.

Untuk lebih mengurangi dampak gangguan, Anda juga dapat mengatur Spot Instances dan Spot Fleets (Armada Spot) untuk merespons pemberitahuan gangguan dengan menghentikan (stopping) atau menghibernasi (hibernate) daripada mengakhiri (terminate) instance saat kapasitas tidak lagi tersedia.

Mengubah Arsitektur Menjadi Lebih Tangguh

Salah satu hal yang perlu Anda pertimbangkan saat membangun arsitektur cloud adalah membuatnya menjadi lebih tangguh. Dengan begitu, aplikasi Anda bisa menghadapi lonjakan traffic dengan efektif, dapat diandalkan, dan siap menghadapi kegagalan/bencana.

Coba kita lihat arsitektur di bawah ini yang menggambarkan aplikasi dengan high availability dalam satu Availability Zone. 

Mari kita kembali ke skenario startup warung kopi. Katakanlah startup kita memiliki arsitektur seperti di atas. Anda ditugaskan untuk melakukan penyempurnaan atas arsitektur tersebut. Kira-kira, apa saja yang akan Anda lakukan?

Oke, mari kita uraikan saja.

1. Tambahkan Availability Zone baru
   Jika kita lihat dari sisi Perencanaan Disaster Recovery, arsitektur tersebut masih rentan terhadap kegagalan yang bisa saja terjadi di satu Availability Zone (AZ). Salah satu hal yang dapat Anda lakukan dengan cepat adalah dengan menambahkan AZ baru, seperti yang diilustrasikan pada gambar di bawah ini.
   
   
   

2. Tambahkan kemampuan Auto Scaling
   Langkah selanjutnya yang bisa Anda lakukan adalah dengan memanfaatkan kemampuan Auto Scaling di masing-masing subnet. Hal ini tentu akan memungkinkan arsitektur Anda mengatasi lonjakan user.
   
   
   

3. Replikasi arsitektur ke Region baru
   Selanjutnya, Anda bisa mereplikasi arsitektur ke region baru sebagai bagian dari ekspansi dan juga failover atau disaster recovery.
   
   
   

Lihat! Sekarang arsitektur tersebut menjadi lebih elastis, andal, dan siap jika suatu saat terjadi kegagalan atau bahkan bencana.

Praktik Terbaik untuk Membuat Sistem di AWS

Oke, sampai tahap ini kita telah melihat beberapa ulasan dan cara yang dapat mengoptimalkan arsitektur cloud. Walaupun begitu, Anda pun harus tetap mengetahui beberapa praktik terbaik yang dapat diterapkan saat mendesain atau membuat sistem di AWS, antara lain:

1. Perhatikan skalabilitas : AWS memiliki kemampuan untuk scale up maupun scale out. Pastikan Anda mengerti dan memanfaatkan keduanya dengan benar. 

2. Automasikan lingkungan Anda : Manfaatkan layanan-layanan AWS yang dapat membuat lingkungan secara otomatis, seperti AWS CloudFormation, AWS Elastic Beanstalk, dsb.

3. Gunakan sumber daya sekali pakai : Jika ada sumber daya di sistem Anda yang tidak terpakai (idle), pastikan apakah memungkinkan untuk diganti dengan sumber daya sekali pakai (disposable) atau dapat dimatikan saat tak terpakai seperti AWS Lambda.

4. Pastikan komponen Anda loosely coupled : Manfaatkan layanan AWS seperti SQS, SNS, dsb untuk membebaskan komponen sistem dari ketergantungan atau tightly coupled.

5. Desain service, bukan server : Ingat! Di AWS, Anda tidak perlu memikirkan hal-hal yang berkaitan dengan perangkat keras. Fokuskan diri Anda pada pengembangan aplikasi, bukan infrastruktur yang mendasarinya.

6. Pilih solusi database yang tepat : AWS memiliki layanan database berbasis SQL dan NoSQL yang bervariasi sesuai kebutuhan Anda. Jadi, pilihlah layanan database yang tepat.

7. Hindari titik kegagalan tunggal : Setiap layanan di AWS memiliki kemampuan untuk menghindari titik kegagalan tunggal (suatu komponen yang jika gagal, ia akan memiliki potensi menghentikan keseluruhan sistem). Pastikan Anda mengerti dan memanfaatkan hal ini.

8. Optimasi biaya : AWS didesain agar Anda dapat menjalankan sistem secara optimal dan hemat biaya. Tapi pastikan bahwa Anda juga memanfaatkan hal ini.

9. Gunakan caching : Caching akan sangat meningkatkan performa layanan sistem Anda.

10. Amankan infrastruktur di setiap lapisan : Keamanan sistem Anda adalah tanggung jawab Anda sendiri. Maka dari itu, pastikan Anda mengamankan infrastruktur Anda di setiap lapisannya. Misal pada lapisan jaringan, Anda menggunakan security group dan network ACL.

Ingat! Untuk memastikan lingkungan Anda telah menerapkan praktik terbaik dari AWS, gunakanlah AWS Well-Architected Tool. Tentu Anda masih ingat kan dengan layanan tersebut? Layanan tersebut telah kita bahas di modul pertama dari kelas ini. 

AWS Well-Architected Tool adalah tool gratis yang tersedia di AWS Management Console untuk membantu Anda dalam mengulas dan membandingkan beban kerja dengan praktik terbaik terbaru terkait arsitektur dari AWS. Tentu, praktik terbaik tersebut mengacu pada AWS Well-Architected Framework.

Ikhtisar

Pada modul kali ini, kita telah belajar banyak, mulai dari mengulas arsitektur hingga cara-cara yang dapat digunakan untuk mengoptimalkan arsitektur cloud di AWS. Mari kita uraikan:

1. Kita telah mengulas arsitektur yang telah kita bangun melalui beberapa pertanyaan secara arsitektur. Dengan pertanyaan-pertanyaan tersebut, kita bisa semakin menyempurnakan arsitektur kita.

2. Kita juga telah melihat beberapa cara yang dapat membuat arsitektur kita semakin optimal, mulai dari mengubahnya menjadi loosely coupled, memanfaatkan model penetapan harga di EC2, mengubah arsitektur menjadi lebih tangguh, dan mengetahui beberapa praktik terbaik untuk membuat sistem di AWS.

Tibalah kita di penghujung materi di kelas ini. Huft! Panjang juga ya perjalanan kita. Semoga kelas ini bisa membantu Anda untuk semakin memahami AWS Cloud dan mampu membangun arsitektur di AWS ya.

Jangan menyerah dan tetap semangat. Selanjutnya, Anda akan diberikan soal-soal untuk menguji pemahaman Anda. Keep the spirit high!

Ref : [1]