Mengapa saya harus menggunakan Amazon Kinesis dan bukan SNS-SQS?

Saya memiliki use case di mana akan ada aliran data yang masuk dan saya tidak bisa mengkonsumsinya pada kecepatan yang sama dan membutuhkan buffer. Ini dapat diselesaikan dengan menggunakan antrian SNS-SQS. Saya jadi tahu Kinesis memecahkan tujuan yang sama, jadi apa bedanya? Mengapa saya lebih suka (atau tidak suka) Kinesis?

Pada permukaan mereka agak mirip, tetapi use case Anda akan menentukan alat mana yang sesuai. IMO, jika Anda bisa bertahan dengan SQS maka Anda harus - jika itu akan melakukan apa yang Anda inginkan, itu akan lebih sederhana dan lebih murah, tetapi di sini ada penjelasan yang lebih baik dari AWS FAQ yang memberikan contoh kasus penggunaan yang sesuai untuk kedua alat untuk membantu Anda memutuskan:

FAQ

Ingatlah bahwa jawaban ini benar untuk Juni 2015

Setelah mempelajari masalah ini sebentar, dengan pertanyaan yang sama, saya menemukan bahwa SQS (dengan SNS) lebih disukai untuk kebanyakan kasus penggunaan kecuali urutan pesannya penting bagi Anda (SQS tidak menjamin FIFO pada pesan).

Ada 2 keuntungan utama untuk Kinesis:

1. Anda dapat membaca pesan yang sama dari beberapa aplikasi
2. Anda dapat membaca kembali pesan jika perlu.

Kedua keuntungan dapat dicapai dengan menggunakan SNS sebagai penggemar untuk SQS. Itu berarti bahwa produsen pesan hanya mengirim satu pesan ke SNS, Kemudian SNS penggemar pesan ke beberapa SQS, satu untuk setiap aplikasi konsumen. Dengan cara ini Anda dapat memiliki konsumen sebanyak yang Anda inginkan tanpa memikirkan kapasitas sharding.

Selain itu, kami menambahkan satu lagi SQS yang berlangganan SNS yang akan menyimpan pesan selama 14 hari. Dalam kasus normal, tidak ada yang membaca dari SQS ini tetapi jika ada bug yang membuat kami ingin memundurkan data, kami dapat dengan mudah membaca semua pesan dari SQS ini dan mengirimnya kembali ke SNS. Sementara Kinesis hanya memberikan retensi 7 hari.

Sebagai kesimpulan, SNS + SQS jauh lebih mudah dan menyediakan sebagian besar kemampuan. IMO Anda membutuhkan case yang sangat kuat untuk memilih Kinesis.

Kinesis mendukung kemampuan banyak konsumen yang berarti catatan data yang sama dapat diproses pada waktu yang sama atau waktu yang berbeda dalam waktu 24 jam pada konsumen yang berbeda, perilaku serupa dalam SQS dapat dicapai dengan menulis ke beberapa antrian dan konsumen dapat membaca dari banyak antrian. Namun menulis lagi ke dalam beberapa antrian akan menambahkan latensi sub detik {beberapa milidetik} dalam sistem.

Kedua, Kinesis menyediakan kemampuan perutean untuk merekam data rute selektif ke pecahan yang berbeda menggunakan kunci partisi yang dapat diproses oleh instance EC2 tertentu dan dapat mengaktifkan perhitungan batch mikro {Menghitung & agregasi}.

Bekerja pada perangkat lunak AWS adalah mudah tetapi dengan SQS adalah yang paling mudah. Dengan Kinesis, ada kebutuhan untuk menyediakan pecahan yang cukup di depan, meningkatkan jumlah pecahan secara dinamis untuk mengelola beban lonjakan dan mengurangi untuk menghemat biaya yang juga diperlukan untuk mengelola. itu rasa sakit di Kinesis, Tidak ada hal-hal seperti itu diperlukan dengan SQS. SQS dapat diukur secara tak terbatas.

Semantik dari teknologi ini berbeda karena mereka dirancang untuk mendukung skenario yang berbeda:

• SNS / SQS: item dalam aliran tidak terkait satu sama lain
• Kinesis: item dalam aliran saling terkait satu sama lain

Mari kita pahami perbedaannya dengan contoh.

1. Misalkan kita memiliki aliran pesanan, untuk setiap pesanan kita perlu memesan beberapa stok dan menjadwalkan pengiriman. Setelah ini selesai, kami dapat dengan aman menghapus item dari aliran dan mulai memproses pesanan berikutnya. Kami sepenuhnya selesai dengan pesanan sebelumnya sebelum kami mulai yang berikutnya.
2. Sekali lagi, kami memiliki aliran pesanan yang sama, tetapi sekarang tujuan kami adalah mengelompokkan pesanan berdasarkan tujuan. Setelah kami memiliki, katakanlah, 10 pesanan ke tempat yang sama, kami ingin mengirimkannya bersama (optimisasi pengiriman). Sekarang ceritanya berbeda: ketika kita mendapatkan item baru dari aliran, kita tidak bisa selesai memprosesnya; alih-alih kita "menunggu" untuk datangnya lebih banyak barang untuk memenuhi tujuan kita. Selain itu, jika proses prosesor macet, kita harus "mengembalikan" keadaan (jadi tidak ada pesanan akan hilang).

Setelah memproses satu item tidak dapat dipisahkan dari memproses yang lain, kita harus memiliki semantik Kinesis untuk menangani semua kasus dengan aman.

Kutipan dari Dokumentasi AWS :

Kami merekomendasikan Amazon Kinesis Streaming untuk kasus penggunaan dengan persyaratan yang mirip dengan yang berikut:

• Routing record terkait ke record processor yang sama (seperti dalam streaming MapReduce). Misalnya, penghitungan dan agregasi lebih sederhana ketika semua catatan untuk kunci yang diberikan dialihkan ke prosesor catatan yang sama.

• Memesan catatan. Misalnya, Anda ingin mentransfer data log dari host aplikasi ke host pemrosesan / arsip dengan tetap menjaga urutan pernyataan log.

• Kemampuan beberapa aplikasi untuk menggunakan aliran yang sama secara bersamaan. Misalnya, Anda memiliki satu aplikasi yang memperbarui dasbor waktu nyata dan lainnya yang mengarsipkan data ke Amazon Redshift. Anda ingin kedua aplikasi mengkonsumsi data dari aliran yang sama secara bersamaan dan mandiri.

• Kemampuan untuk mengkonsumsi catatan dalam urutan yang sama beberapa jam kemudian. Misalnya, Anda memiliki aplikasi penagihan dan aplikasi audit yang berjalan beberapa jam di belakang aplikasi penagihan. Karena Amazon Kinesis Streams menyimpan data hingga 7 hari, Anda dapat menjalankan aplikasi audit hingga 7 hari di belakang aplikasi penagihan.

Kami merekomendasikan Amazon SQS untuk kasus penggunaan dengan persyaratan yang serupa dengan yang berikut:

• Semantik pesan (seperti ack / gagal tingkat pesan) dan batas waktu visibilitas. Misalnya, Anda memiliki antrean item kerja dan ingin melacak penyelesaian yang berhasil dari setiap item secara independen. Amazon SQS melacak ack / fail, sehingga aplikasi tidak harus mempertahankan pos pemeriksaan / kursor persisten. Amazon SQS akan menghapus pesan yang diterima dan mengirim kembali pesan yang gagal setelah batas waktu visibilitas yang dikonfigurasi.

• Penundaan pesan individual. Misalnya, Anda memiliki antrian pekerjaan dan perlu menjadwalkan pekerjaan individual dengan penundaan. Dengan Amazon SQS, Anda dapat mengonfigurasi masing-masing pesan hingga penundaan hingga 15 menit.

• Meningkatkan concurrency / throughput secara dinamis pada waktu baca. Misalnya, Anda memiliki antrean kerja dan ingin menambah lebih banyak pembaca hingga jaminan simpanan selesai. Dengan Amazon Kinesis Streams, Anda dapat meningkatkan skala ke jumlah pecahan yang cukup (perlu dicatat bahwa Anda harus menyediakan pecahan yang cukup sebelumnya).

• Memanfaatkan kemampuan Amazon SQS untuk mengukur secara transparan. Misalnya, Anda buffer permintaan dan perubahan beban sebagai akibat dari lonjakan beban sesekali atau pertumbuhan alami bisnis Anda. Karena setiap permintaan yang disangga dapat diproses secara independen, Amazon SQS dapat mengukur secara transparan untuk menangani pemuatan tanpa instruksi penyediaan dari Anda.

Keuntungan terbesar bagi saya adalah kenyataan bahwa Kinesis adalah antrian yang dapat diputar ulang, dan SQS tidak. Jadi, Anda dapat memiliki banyak konsumen dengan pesan yang sama dari Kinesis (atau konsumen yang sama di waktu yang berbeda) di mana dengan SQS, setelah pesan diterima, pesan itu hilang dari antrian itu. SQS lebih baik untuk antrian pekerja karena itu.

Hal lain: Kinesis dapat memicu Lambda, sedangkan SQS tidak bisa. Jadi dengan SQS Anda juga harus memberikan contoh EC2 untuk memproses pesan SQS (dan menanganinya jika gagal), atau Anda harus memiliki Lambda terjadwal (yang tidak naik atau turun - Anda hanya mendapatkan satu per menit) .

Sunting: Jawaban ini tidak lagi benar. SQS dapat langsung memicu Lambda pada Juni 2018

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Model penentuan harga berbeda, jadi tergantung pada kasus penggunaan Anda satu atau yang lain mungkin lebih murah. Menggunakan case paling sederhana (tidak termasuk SNS):

• Biaya SQS per pesan (masing-masing 64 KB dihitung sebagai satu permintaan).
• Biaya Kinesis per shard per jam (1 shard dapat menangani hingga 1000 pesan atau 1 MB / detik) dan juga untuk jumlah data yang Anda masukkan (setiap 25 KB).

Menghubungkan harga saat ini dan tidak memperhitungkan tingkat gratis, jika Anda mengirim 1 GB pesan per hari pada ukuran pesan maksimum, Kinesis akan jauh lebih mahal daripada SQS ($ 10,82 / bulan untuk Kinesis vs $ 0,20 / bulan untuk SQS) . Tetapi jika Anda mengirim 1 TB per hari, Kinesis agak lebih murah ($ 158 / bulan vs $ 201 / bulan untuk SQS).

Detail: SQS memungut biaya $ 0,40 per juta permintaan (masing-masing 64 KB), jadi $ 0,00655 per GB. Dengan 1 GB per hari, ini hanya di bawah $ 0,20 per bulan; dengan 1 TB per hari, nilainya sedikit di atas $ 201 per bulan.

Kinesis mengenakan biaya $ 0,014 per juta permintaan (masing-masing 25 KB), jadi $ 0,00059 per GB. Dengan 1 GB per hari, ini kurang dari $ 0,02 per bulan; dengan 1 TB per hari, sekitar $ 18 per bulan. Namun, Kinesis juga mengenakan biaya $ 0,015 per shard-jam. Anda membutuhkan setidaknya 1 shard per 1 MB per detik. Dengan 1 GB per hari, 1 shard akan banyak, sehingga akan menambah $ 0,36 per hari, dengan total biaya $ 10,82 per bulan. Dengan 1 TB per hari, Anda akan membutuhkan setidaknya 13 pecahan, yang menambahkan $ 4,68 per hari, dengan total biaya $ 158 per bulan.

Kinesis memecahkan masalah bagian peta dalam skenario pengurangan peta khas untuk streaming data. Sementara SQS tidak memastikan hal itu. Jika Anda memiliki data streaming yang perlu diagregasi pada kunci, kinesis memastikan bahwa semua data untuk kunci itu pergi ke beling tertentu dan beling dapat dikonsumsi pada satu host sehingga membuat agregasi pada kunci lebih mudah dibandingkan dengan SQS

Saya akan menambahkan satu hal lagi yang tidak disebutkan orang lain - SQS adalah beberapa pesanan yang besarnya lebih mahal.

Kinesis Use Cases

• Pengumpulan Log dan Data Acara
• Analisis waktu nyata
• Pengambilan Data Seluler
• Umpan Data "Internet of Things"

Kasus Penggunaan SQS

• Integrasi aplikasi
• Decerating microservices
• Alokasikan tugas ke beberapa node pekerja
• Memisahkan permintaan pengguna langsung dari pekerjaan latar belakang intensif
• Pesan batch untuk diproses di masa mendatang