Departamentul Inginerie Software și Automatică

Specializarea Securitate Informațională

RAPORT
la lucrarea practică nr.2

la disciplina Aplicații Distribuite Avansate

Examinator: Eugeniu TORICĂ,

asistent universitar,
FCIM

A elaborat: Nicolae Panfilii,

masterand în gr. SI-210M, FCIM

Chișinău – 2021
 Sarcina nr. 1

Se dau două aplicații scrise în limbajul Ruby: ruby_computer.rb și ruby_server.rb. Aplicația

ruby_server va expedia un mesaj către aplicația ruby_computer.
Aplicația ruby_computer va rezolva un crypto-puzzle-ul similar celui din lucrarea de
laborator nr. 1.

1) Să se producă următoarele modificări:

Să se scrie o aplicație similară cu ruby_computer în într-un limbaj de programare la alegere:
PHP, Python, JS, Go, Java, C#, D și să se înlocuiască aplicația ruby_computer.rb astfel ca să se
obțină același comportament.

2) Să se modifice aplicația ruby_server astfel ca calculul crypto-puzzle-ululi să fie distribuit

între două aplicații de tip ”computer”: ruby_computer.rb și soluția scrisă de dvs. în punctul
1).

3) Descrieți succint problemele tehnice pe care le-ați întâlnit în timpul implementării și

modul lor de rezolvare.

4) Faceți analiza la câteva produse/servicii de Queue și Broker de mesaje: RabbitMQ, Redis

Pub/Sub, Amazon SQS, etc. faceți o evaluare între ele ce ar conține următoarele informații:
Restricții tehnice, aspecte de securitate, preț, calitatea documentației și a exemplelor pentru
dezvoltatori.

Barem:
Nota Punct efectuat
7 Puncte efectuate: 4.
8 Puncte efectuate: 3, 4.
9 Punctele efectuate: 1, 3, 4
10 Punctele efectuate: 1, 2, 3, 4

Întrebările pot fi adresate pe email-ul: eugeniu.torica@isa.utm.md

Materiale recomandate:

https://www.rabbitmq.com/getstarted.html
 RabbitMQ vs Apache Kafka

What Are RabbitMQ and Apache Kafka?

RabbitMQ is often summarized as an “open source distributed message broker.” Written in
Erlang, it facilitates the efficient delivery of messages in complex routing scenarios. Initially
built around the popular AMQP protocol, it’s also highly compatible with existing
technologies, while its capabilities can be expanded through plug-ins enabled on the server.
RabbitMQ brokers can be distributed and configured to be reliable in case of network or
server failure.

Apache Kafka, on the other hand, is described as a “distributed event streaming platform.”
Rather than focusing on flexible routing, it instead facilitates raw throughput. Written in
Scala and Java, Kafka builds on the idea of a “distributed append-only log” where messages
are written to the end of a log that’s persisted to disk, and clients can choose where they
begin reading from that log. Likewise, Kafka clusters can be distributed and clustered across
multiple servers for a higher degree of availability.

Kafka vs RabbitMQ – Differences in Architecture

RabbitMQ Architecture
 General purpose message broker - uses variations of request/reply, point to point,
and pub-sub communication patterns.
 Smart broker / dumb consumer model - consistent delivery of messages to
consumers, at around the same speed as the broker monitors the consumer state.
 Mature platform - well supported, available for Java, client libraries, .NET, Ruby,
node.js. Offers dozens of plugins.
 Communication - can be synchronous or asynchronous.
 Deployment scenarios - provides distributed deployment scenarios.
 Multi-node cluster to cluster federation - does not rely on external services, however,
specific cluster formation plugins can use DNS, APIs, Consul, etc.

Apache Kafka Architecture

 High volume publish - subscribe messages and streams platform - durable, fast and
scalable.
 Durable message store - like a log, run in a server cluster, which keeps streams of
records in topics (categories).
 Messages - made up of a value, a key and a timestamp.
 Dumb broker/smart consumer model - does not try to track which messages are read
by consumers and only keeps unread messages. Kafka keeps all messages for a set
period of time.
 Requires external services to run - in some cases Apache Zookeeper.

Pull vs Push Approach

Apache Kafka: Pull-based approach
Kafka uses a pull model. Consumers request batches of messages from a specific offset.
Kafka permits long-pooling, which prevents tight loops when there is no message past the
offset.
A pull model is logical for Kafka because of its partitions. Kafka provides message order in a
partition with no contending consumers. This allows users to leverage the batching of
messages for effective message delivery and higher throughput.

RabbitMQ: Push-based approach

RabbitMQ uses a push model and stops overwhelming consumers through a prefetch limit
defined on the consumer. This can be used for low latency messaging.

The aim of the push model is to distribute messages individually and quickly, to ensure that
work is parallelized evenly and that messages are processed approximately in the order in
which they arrived in the queue.

How Do They Handle Messaging?

Kafka vs RabbitMQ Performance

Apache Kafka:
Kafka offers much higher performance than message brokers like RabbitMQ. It uses
sequential disk I/O to boost performance, making it a suitable option for implementing
queues. It can achieve high throughput (millions of messages per second) with limited
resources, a necessity for big data use cases.

RabbitMQ:
RabbitMQ can also process a million messages per second but requires more resources
(around 30 nodes). You can use RabbitMQ for many of the same use cases as Kafka, but
you’ll need to combine it with other tools like Apache Cassandra.
What are the Best Use Cases?
Apache Kafka Use Cases
Apache Kafka provides the broker itself and has been designed towards stream processing
scenarios. Recently, it has added Kafka Streams, a client library for building applications and
microservices. Apache Kafka supports use cases such as metrics, activity tracking, log
aggregation, stream processing, commit logs and event sourcing.

The following messaging scenarios are especially suited for Kafka:

 Streams with complex routing, throughput of 100K/sec events or more, with “at least
once” partitioned ordering
 Applications requiring a stream history, delivered in “at least once” partitioned
ordering. Clients can see a ‘replay’ of the event stream.
 Event sourcing, modeling changes to a system as a sequence of events.
 Stream processing data in multi-stage pipelines. The pipelines generate graphs of
real-time data flows.

RabbitMQ Use Cases

RabbitMQ can be used when web servers need to quickly respond to requests. This
eliminates the need to perform resource-intensive activities while the user waits for a result.
RabbitMQ is also used to convey a message to various recipients for consumption or to share
loads between workers under high load (20K+ messages/second).

Scenarios that RabbitMQ can be used for:

 Applications that need to support legacy protocols, such as STOMP, MQTT, AMQP, 0-
9-1.
 Granular control over consistency/set of guarantees on a per-message basis
 Complex routing to consumers
 Applications that need a variety of publish/subscribe, point-to-point request/reply
messaging capabilities.

Developer Experience
The developer experience of the two services has largely remained the same, with the list of
clients and libraries continuing to grow thanks to the work of their respective communities.
Both RabbitMQ’s and Kafka’s client library lists have seen steady growth. As more languages
and frameworks have grown in popularity, finding a well-supported and complete library for
either service has become easier.

One thing to note is the growth of Kafka Streams, a client library implementation that makes
it easier for developers to process streaming data. It’s used for the common use case of
reading data from Kafka, processing it, and writing it to another Kafka queue. Additionally,
ksqlDB is well worth checking out for developers looking to build streaming applications
while taking advantage of their familiarity with relational databases.

A similar thing can be accomplished with RabbitMQ with the help of some other pieces, such
as Spring Cloud Data Flow. Furthermore, note the upcoming streaming changes coming for
RabbitMQ mentioned in the previous section, keeping in mind that this can open new ways
of interacting with RabbitMQ for the developer.
Security and Operations
As noted, RabbitMQ ships with a useful administration interface to manage users and
queues, while Kafka relies on TLS and JAAS. Whether you choose RabbitMQ or Kafka will of
course depend on your specific requirements and your use case, but most security scenarios
can have a proper conclusion with either technology.

It’s important to note the rise of Kubernetes over the last few years and how it affects the
operations of services. Substantial work has been done to allow infrastructure operators to
run both RabbitMQ and Kafka on Kubernetes. The RabbitMQ operator and Kafka Helm chart
both have very fine control over how these services are configured as well as how to run
them on Kubernetes specifically. This makes it extremely easy to get up and running with
both of them configured and clustered out of the box.

Referințe:
1. https://www.upsolver.com/blog/kafka-versus-rabbitmq-architecture-performance-
use-case
2. https://tanzu.vmware.com/developer/blog/understanding-the-differences-between-
rabbitmq-vs-kafka/