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


164

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?

Jawaban:


59

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



80

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.


2
FYI: Anda dapat mempertahankan Kinesis hingga 7 hari.
Didier A.

30
Baru-baru ini, AWS telah mengumumkan SQS FIFO [ docs.aws.amazon.com/AWSSimpleQueueService/latest/… yang dapat melayani pemesanan waktu pesan.
VijeshJain

4
Super minor komentar - mungkin tidak akan menggunakan kata splitdi SNS split the message to multiple SQSskarena tidak memecah pesan menjadi potongan-potongan tetapi salinan itu ke beberapa tujuan.
Mobigital

2
Kinesis tidak cocok untuk kasus penggunaan fan-out (pub-sub) karena keterbatasan jumlah pembaca per shard / detik. Meskipun tidak relevan dengan penyelidikan asli, siapa pun yang mengandalkan penskalaan Kinesis untuk n-pembaca harus mempertimbangkan fakta ini. forums.aws.amazon.com/message.jspa?messageID=760351
codeasone

2
Jaminan pesanan Kinesis adalah per-beling, bukan per-aliran. Setelah Anda memiliki lebih dari satu pecahan, seluruh aliran tidak akan memiliki jaminan pesanan. Untuk antrian SQS, ketika throughput relatif rendah, hampir FIFO. Hanya ketika throughput Anda lebih tinggi, pesanannya kurang diikuti. Ini tentang antrian SQS klasik, bukan antrian FIFO.
yoroto

54

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.


11
Mengenai penjelasan Anda tentang SQS. Anda dapat mencapai cara mudah untuk mengirim pesan yang sama ke beberapa SQS dengan memiliki SNS di depannya.
Roee Gavirel

8
app -> topik sns ---> sqs1, sqs2, sqs3 ...?
kartik

4
Ya, saya mengacu pada pendekatan yang tepat ini.
Roee Gavirel

@RoeeGavirel bagaimana dengan permintaan / pembatasan kedua untuk sns api?
Barbaros Alp

@BarbarosAlp - Saya hanya mengetahui batasan SMS (pesan teks seluler) yang bukan topik di sini. ini adalah dokumentasi resmi: docs.aws.amazon.com/general/latest/gr/…
Roee Gavirel

43

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.


Dengan antrian SQS FIFO, kami akan memesan pesan saat dikirim. Apakah itu membuat SQS mirip dengan Kinesis pada aspek ini?
Andy Dufresne

1
@AndyDufresne: ini mencakup dengan baik skenario di mana urutan itu penting. Dalam kasus (1) di atas, Anda mungkin ingin menangani pesanan "dalam urutan". Jadi jika Anda kehabisan stok, pesanan kemudian ditolak atau ditunda. Semantik FIFO tidak menyelesaikan masalah relativitas inti (pengelompokan).
Konstantin Triger

35

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.


34

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.


Bagaimana Anda menerima pesan? Apakah maksud Anda hapus?
NeverEndingQueue

Ya, pada dasarnya. Mengatakan bahwa Anda selesai dengan pesan ini
Matthew Curry

15

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


1
-1 Tidak setuju. Sementara Kinesis dapat memicu lambda, ini tidak memberikan keuntungan dibandingkan lambda SQS terjadwal. Yang terakhir akan skala mulus (yaitu jika butuh lebih dari satu menit, lambda kedua akan berputar). Harga adalah per waktu komputasi sehingga tidak ada perbedaan yang berarti di sana. Dan jika Anda membutuhkan lebih dari 5 lambda bersamaan maka cukup tambahkan beberapa pemicu yang dijadwalkan terpisah beberapa detik (menggunakan cron). Ini bukan alasan untuk menggunakan Kinesis di SNS / SQS.
Steven de Salas

5
Saya tidak yakin saya setuju dengan ketidaksepakatan;] - Anda dapat menjadwalkan satu lambda / menit, yang akan membatasi Anda untuk mengelompokkan pesan yang sampai pada interval itu. Kinesis akan memungkinkan Anda untuk membaca pesan dengan segera. Atau sesuatu yang saya salah pahami?
Moszi

Ada perbedaan besar antara beberapa pemicu cloudwatch dan ratusan ketika perlu meminta lambda yang menarik terhadap SQS.
Coding Pig

14
Lambda sekarang mendukung SQS sebagai pemicu!
sixty4bit

11

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.


Saya tidak sepenuhnya mengikuti mengapa peningkatan ukuran eksponensial, di sini, penting. Bisakah Anda menggali lebih dalam? Sepertinya Anda memiliki wawasan yang ingin saya miliki. Sunting Sebenarnya, melihat jawaban Euguene Feingold, tampaknya ada perdebatan yang cukup solid tentang ini (?).
Thomas

Maaf, saya membuat beberapa kesalahan dalam perhitungan saya (diperbaiki sekarang, saya harap).
John Velonis

benar, tetapi bagaimana jika ukuran pesan SQS rata-rata Anda kecil, katakan 1kb atau kurang?
mcmillab

1
@mcmillab SQS akan membebankan biaya yang sama apakah pesan Anda 1 KB atau 64 KB - lihat halaman penetapan harga SQS Amazon . Jadi, jika pesan Anda hanya 1 KB, SQS akan dikenakan biaya 64x sebanyak angka yang saya berikan di atas jika Anda mengirim jumlah total data yang sama. Namun, satu permintaan dapat berisi hingga 10 pesan, jadi jika Anda dapat menggabungkan beberapa pesan, mungkin hanya 6x lebih banyak (tergantung seberapa penuh kumpulan Anda).
John Velonis

1
@JohnVelonis Di atas perhitungan untuk harga SQS tidak ada bagian penting. Diperlukan perhatian ekstra untuk memahami bagaimana permintaan SQS dibebankan. 1 permintaan = 1 Tindakan API. Untuk memproses satu "pesan" tunggal, perlu melakukan setidaknya 3 tindakan API: 1 kirim + 1 baca + 1 hapus. Fitur SQS lainnya seperti mengubah visibilitas akan menimbulkan lebih banyak tindakan API. Pengganda tak terduga ini cukup jahat dan biasanya menghasilkan SQS 2-10x lebih mahal daripada Kinesis Streams untuk kumpulan data besar (katakanlah memproses 100 juta pesan per bulan).
Vlad Poskatcheev

9

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


5

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


3
Apakah kamu yakin Dari perhitungan saya, Kinesis jauh lebih mahal, tetapi saya tidak pernah berbakat menggunakan Kalkulator Harga Sederhana Amazon.
Didier A.

Melihat contoh penetapan harga saat ini pada aws: Kinesis dengan 267M pesan adalah sekitar $ 60, sementara menempatkan jumlah pesan melalui SQS akan menghasilkan $ 107. Jelas saya hanya melakukan perbandingan yang sangat cepat, dan ini sangat berbeda dengan kasus penggunaan yang berbeda, tetapi jawaban ini pasti patut mendapat pujian.
Moszi

1
Asumsikan Anda melakukan penggemar untuk mengatakan 2 konsumen dan 100 juta pesan sehari. Biaya SNS adalah $ 50 / hari. Biaya SQS adalah $ 40 / hari / konsumen atau $ 80 / hari total. Kinesis adalah $ 1,4 / hari untuk PUT dan $ 0,36 / shard. Bahkan dengan 100 pecahan (100 MB / dtk, 200 MB / dtk) hanya $ 3,60 / hari + $ 1,40 / hari. Jadi Kinesis seharga $ 4 / hari vs. SNS / SQS seharga $ 130 / hari.
Carlos Rendon

@ Moszi Bagaimana Anda sampai pada perhitungan ini? Antrian SQS standar dengan 15.000.000 pesan per bulan dan transfer data 10GB masuk dan transfer data hanya menghabiskan biaya 5.60USD / bulan, sedangkan payload 256KB (maks SQS) dan ~ 15.000.000 unit PUT / bulan (130 halaman) di Kinesis menghabiskan biaya 1.638,43 USD / bln.
simoncpu

3
Saya tertarik untuk mengetahui mengapa ada perbedaan dalam biaya di utas ini.
Thomas

2

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
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.