Di minggu ke-6 ini saya belajar tentang service queue dari Amazon. Jika teman-teman tahu tentang RabitMQ, service ini mrirp dengan itu.

Nah, untuk teman-teman yang baru mengikuti series ini. Teman-teman bisa membaca series sebelumnya dahulu:

Queue service bukan hal yang baru bagi saya. Sebelumnya saya pernah memakai queue service dari RabitMQ.

Saat itu problem yang saya hadapi adalah batching perhitungan nilai Tryout online siswa se Indonesia. Tryout nya dilakukan serentak, dan problem yang dihadapi adalah saat semua siswa selesai mengerjakan tryout secara bersamaan.

Tanpa queue service, mungkin server yang digunakan tidak akan cukup, saat itu kita hanya memakai server virtual dengan ram 4 GB.

Nah, di minggu ke-6 ini. Problem yang dihadapi cukup mirip, kita akan meng-queue request dari Lamda ke SQL instance yang sebelumnya dibuat menggunakan Amazon SNS service.

Kira-kira, arsitektur final dari aplikasinya jadi seperti ini:

Event Driven Architectures
Event Driven Architectures

Event Driven Architectures

Arsitektur ini kita sebut sebagai Event Driven Architecture (EDA). Di EDA ada tiga komponen yang saling berkomunikasi secara realtime. Producer, Consumer, dan Channel.

Producer adalah sumber dari event, producer yang tahu kapan suatu event terjadi. Event ini bisa berupa trigger dari user atau kriteria tertentu. Dalam kasus saya, yang menjadi event adalah Lambda function yang meng-invoke Amazon Rekognition.

Setiap event yang dibuat Producer, nantinya akan dikirm ke pada komponen Event Channel. Event Channel yang nantinya akan mengirimkan pesan ke Consumer.

Tetapi tidak serta merta Channel mengirimkan pesan ke Consumer. Channel ini akan memeriksa mana-mana saja Producer yang siap dikirm message. Jika tidak ada Consumer yang available, Channel akan meng-queue semua event. Sehingga saat nanti Consumer sudah available tidak ada event yang hilang begitu saja.

Consumer adalah service yang menjalankan sebuah event. Tugas Consumer sangat sederhana, menerima message dari channel, menjalankan tugas sesuai message yang diterima.

Yang menarik dari EDA ini, semua tugas dan komunikasi dilakukan secara realtime dan asyncronus.

Amazon Simple Notification Service (SNS)

Yang beperan sebagai Channel di sini adalah Amazon SNS. SNS menerima event dari Publisher dan men-delivernya ke Consumer.

Amazon SNS
Amazon SNS (PUB-SUB model)

Publisher akan menulis pesan ke dalam sebuah topic dalam SNS. Consumer nantinya akan subscribe ke dalam topic yang ada di SNS. Consumer di sini bisa berupa email service, Lamda, SMS, SQS, dst.

Setiap kali sebuah message di publish ke dari Publisher ke SNS topic; Publisher akan menerima message tersebut melalui topic dengan protokol-protokol tertentu.

Amazon SNS bertugas untuk menjaga agar setiap service berkomunikasi semestinya secara asyncronus. SNS juga yang bertugas menjaga siapa saja yang boleh mengirim pesan; dan siapa yang bisa menerima message yang diharapkan.

Amazon Simple Queue Service (SQS)

Dimana message-message ini di-simpan?
Bagaimana jika message-message ini hilang?
Bagaimana cara men-deliver message ke publisher?

Semua pertanyaan di atas dijawab oleh Amazon Queue Service (SQS). Jika SNS tugasnya menerima dan mendeliver event-event yang masuk menjadi message; Amazon SQS tugasnya menyimpan message agar tidak hilang.

Amazon SQS juga bertanggung jawab untuk mendeliver message dengan aturan tertentu. Apakah secara berurutan sesuai masuknya event (FIFO) atau acak.

Amason SQS flow
Amason SQS flow

Nah, saya tidak yakin ini. Tetapi Amazon SQS ini sifatnya idempotent. Artinya message bisa saja duplicate dan ini tidak masalah jika dijalankan semuanya.

Di Minggu ke-5, saya berhasil membuat Lambda yang akan berjalan jika photo berhasil diupload ke Amazon S3.

Sekarang, Lambda tidak akan lagi di-invoke jika berhasil upload ke S3, tetapi akan subscribe ke dalam topic dari Amazon SNS.

Dengan tulisan ini pula, saya akhiri series tulisan AWS Developer. Minggu depan saya akan mulai menulis tulisan series lainnya.

Sampai jumpa. ?