Lambda architecture: from zero to One
Download as PPTX, PDF2 likes1,123 views
The document presents a detailed overview of implementing a lambda architecture for a live voting service, highlighting its goals of high throughput, scalability, and low latency. It discusses the architectural evolution, technologies used (such as Kafka, Redis, and Spark), and the importance of benchmarking and optimization for performance. The project aims to create a robust and fault-tolerant system while providing efficient real-time data processing and reporting capabilities.
Lambda architecture: from zero to One
- 1. Lambda Architecture: from zero to One Serhiy Masyutin
- 2. Me • Staff Engineer @ Lohika • Passionate Developer • Father • Mountain Biker
- 3. Agenda • Project Overview • Architecture Evolution • What is Lambda Architecture? • Cluster Evolution • What We Achieved?
- 5. Project Goals • Portfolio-driven R&D project • Focus on Technology • Focus on Knowledge • Focus on a new remote Team
- 6. Service designed to offload highly concurrent scenario of live voting
- 7. Service designed to offload highly concurrent scenario of live voting • User puts a vote • User requests results on campaign • Manager requests reports on campaigns • Admin controls the system
- 8. Architecture Goals • SaaS Solution • High Throughput • Scalability • Low Latency
- 9. Essential Data Model • campaign { startDate, endDate } • vote { user, campaign, timestamp }
- 12. Start Simple Java 8 Spring Boot 1.2.5 MariaDB 5.5 Angularjs 1.4
- 13. Benchmark it! • Simple throughout scenario: user.vote() user.request(results) • Stop tests when error rate raises above 5% • Benchmark tool runs locally, targeting could server
- 14. Gatling • An open-source load testing framework based on Scala, Akka and Netty • High performance • Out-of-box HTTP support • Ready-to-present HTML reports • Scenario recorder and developer-friendly DSL http://gatling.io
- 15. Gatling scenario(“Throughout simulation").repeat(repeatCount) { feed(voteFeeder()) .exec(http("Vote") .post(voteLink) .headers(sentHeaders).header("Authorization", token) .body(StringBody("${vote}")) .check(status.is(200)).asJSON) .exec(http("Report") .get(reportByOptionLink+"/${votingSchemaId}") .headers(sentHeaders).header("Authorization", token) .check(status.is(200)).asJSON) }
- 16. Gatling
- 17. Benchmark! 100 325 550 775 1000 2000 4000 6000 8000 10000 12000 Requestspersecond Number of concurrent users Initial Initial no-joins
- 18. Kafka • Publisher-subscriber • Distributed by design • Scalable • Fast • Durable http://kafka.apache.org
- 20. Benchmark! 100 325 550 775 1000 2000 4000 6000 8000 10000 12000 Requestspersecond Number of concurrent users Initial Initial no-joins Incoming Queue
- 21. Redis • In-memory data structure store (set, map, etc) • Easy leader board implementation • HyperLogLog is its native data structure http://redis.io
- 23. Benchmark! 100 325 550 775 1000 2000 4000 6000 8000 10000 12000 Requestspersecond Number of concurrent users Initial Initial no-joins Incoming Queue In-memory Storage
- 24. • A fast and general engine for large-scale data processing http://spark.apache.org
- 26. TODO: Benchmarks • Processing latency • Latency vs Data Volume
- 28. Architecture Goals Met • High Throughput • Scalable Storage • Scalable Processing • Extensible Processing • Low Latency Reads & Updates
- 31. A Single Picture QUERY = f_query(batch_view, realtime_view) batch_view = f_batch(all_data) realtime_view = f_speed(new_data, realtime_view)
- 32. Batch Layer • Immutable append-only data store • Batch computations produce batch views
- 33. Serving Layer • Random reads/queries on batch views • Batch updates from batch layer • No need for random writes
- 34. Batch + Serving Layer • Robustness and fault tolerance • Scalability • Generalization • Extensibility • Minimal maintenance • Debuggability
- 35. Speed Layer • Low latency reads and updates • Incremental computation (different from batch one) • Scalability • Fault tolerance • Minimal amount of stored data
- 36. Goals • Robustness and fault tolerance • Scalability • Generalization • Extensibility • Minimal maintenance • Debuggability • Low latency reads and updates
- 40. Optimization: Tomcat Connector • Start with a single machine • Number of threads matter, benchmark it • Fine-tuning can be OS specific
- 41. Benchmark! 100 325 550 775 1000 2000 4000 6000 8000 10000 12000 Requestspersecond Number of concurrent users Initial Initial no-joins Incoming Queue In-memory Storage ???
- 42. Haproxy • The Reliable, High Performance TCP/HTTP Load Balancer • A single-process program http://haproxy.org
- 43. A cluster of 10 servers
- 44. Optimization: Load Balancing 0 0.25 0.5 0.75 1 1.25 0 10000 20000 30000 40000 dev 1 2 3 6 Gainbyaddinganotherserver Requestspersecond Number of servers requests per second scaling factor
- 45. When to Stop? CPU % Memory GB haproxy 95 2.5 tomcat 397 6 kafka 1 1.3 redis 55 3.5
- 47. Experience • Lambda Architecture: we have One • Cluster Scaling & Optimization • Excellent team
- 48. Technology Java 8 Spring Boot 1.2.5 Spring Data 1.2.5 Tomcat 8 MariaDB 5.5 Haproxy 1.5.14 Kafka 0.8 Redis 2.8 Spark 1.4 HDFS 2.6 Gatling 2.2 Angularjs 1.4
- 49. Things That Matter • Small steps make huge difference • Choose right metrics • Benchmark • Optimize!
- 50. Q/A
- 51. Thank You!
Editor's Notes
- #6: Робота над проектом триває, хоча останнім часом активність не велика.
- #8: Сервіс для підтримки високонавантаженого сценарію одночасного голосування
- #9: Software as a Service
- #12: Maria DB 5.5.44 (no second level cache in our persistence, all tests started with empty DB, connection pooling)
- #13: Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run". Spring Data's mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store. MariaDB An enhanced, drop-in replacement for MySQL. MariaDB 5.5 is a stable (GA) release of MariaDB. It is MariaDB 5.3 + MySQL 5.5
- #14: Дає видимість руху, правильно, неправильно, і чи взагалі дало якусь зміну 1000 campaigns 15-100k votes
- #18: Коли позбулися 3-4 джойнів то система змогла витримувати більше навантаження, хоча продуктивність не збільшилася. Флуктуації на графіку пов”язані з нестабільність віртаулок які нами викоистовувалися. Бачимо, що система має явне обмеження по перформансу. З цим треба щось робити. Звичайним в цій ситуації є буферизація запитів, тобто будемо ставити їх в чергу. Черга — я з малими бавлюся в паттерн черга — я складаю іграшки на коврик, а вони їх з коврика сортують по ящиках )) Ми знаємо про круту технологію, зараз популярна…
- #19: Є чудова презентація від Колі Аліменкова з цьогорічного ЖЕЕКонфа A single Kafka broker can handle hundreds of megabytes of reads and writes per second from thousands of clients. Kafka is designed to allow a single cluster to serve as the central data backbone for a large organization. It can be elastically and transparently expanded without downtime. Data streams are partitioned and spread over a cluster of machines to allow data streams larger than the capability of any single machine and to allow clusters of co-ordinated consumers Messages are persisted on disk and replicated within the cluster to prevent data loss. Each broker can handle terabytes of messages without performance impact. Kafka has a modern cluster-centric design that offers strong durability and fault-tolerance guarantees.
- #20: Kafka 0.8.2.1 (Scala 2.9.1, only one partition) Система стала асинхронна, варто було б міряти також лейтенсі. Тримаємо це в секреті ) Хто зауважить — тому подарунок
- #21: 1.5 - 2.1x Це вже добряче швидко, але зараз ми роздаємо дані з диска. Обрахунки виконуються в запитах до бази даних які досить часто не є найшвидні і не скейляться. Якщо роздавати дані з памяті це дасть нам приріст продуктивності…
- #22: Вибрали бо ориганільно розраховували на використання лідербордів. З реального використання можна взяти HyperLogLog як ефективний приблизний підрахунок голосів по компанії In the Redis implementation it only uses 12kbytes per key to count with a standard error of 0.81%, and there is no limit to the number of items you can count, unless you approach 2^64 items (which seems quite unlikely). // key == set
- #24: ~1.6x performance boost Але є обмеження на алгоритми по створенню репортів: було б добре мати якісь загальний інструмент для їх реалізації
- #25: Про спарк є дуже добра презентація від Тараса, якщо ви її не чули — рекомендую подивитися відео на сайті морнинга. Spark has an advanced DAG execution engine that supports cyclic data flow and in-memory computing. Spark offers over 80 high-level operators that make it easy to build parallel apps. And you can use it interactively from the Scala, Python and R shells. Spark powers a stack of libraries including SQL and DataFrames, MLlib for machine learning, GraphX, and Spark Streaming. You can combine these libraries seamlessly in the same application. You can run Spark using its standalone cluster mode, on EC2, on Hadoop YARN, or on Apache Mesos. Access data in HDFS, Cassandra, HBase, Hive, Tachyon, and any Hadoop data source.
- #26: Основна мета цього кроку — екстенсібіліті системи по відношенню до алгоритмів обробки даних. Також на live layer можна було б використати Spark Streaming, як узагальненя інкрементальних обрахунків. Можливо це буде реалізовано на одному з наступних етапів. Додавання ще одного розподіленого компонента швидше за все не дасть приросту продуктивності, на цьому етапі заміри лейтенсі яке ми міряли Обмеженням системи на даному етапі стає можливість збереження великого об”єму даних: хоч до сих пір база даних справлялася з цією роботою, але вона не найкращий кандидат. Є старенька всім відома технологія… але про це за декілька слайдів.
- #28: Зараз іде робота над заміною маріяДБ на HDFS.
- #29: Отже ми прийшли до картинки із остаточним варіантом архітектури. Дані вливаються великим потоком Можемо зберігати великі масиви даних Можем опрацьовувати великі масиви даних Є можливість швидкої відповіді на ряд поставлених питань, більш складні питання можна обрахувати точно з певною затримкою Кажуть в тої архітектури є вже назва.
- #32: ВИБОРИ В УКРАЇНІ: бюлетні == all_data ЦВК == batch_view екзитпол == realtime_view
- #33: Hadoop The batch layer precomputes results using a distributed processing system that can handle very large quantities of data. The batch layer aims at perfect accuracy by being able to process all available data when generating views. This means it can fix any errors by recomputing based on the complete data set, then updating existing views. Output is typically stored in a read-only database, with updates completely replacing existing precomputed views. Apache Hadoop is the de facto standard batch-processing system used in most high-throughput architectures.
- #34: Simple Robust Predictable Easy to configure and operate Cassandra/HBase/ElaphantDB, також може бути Hive/Impala Output from the batch and speed layers are stored in the serving layer, which responds to ad-hoc queries by returning precomputed views or building views from the processed data. Examples of technologies used in the serving layer include Druid, which provides a single cluster to handle output from both layers. Dedicated stores used in the serving layer include Apache Cassandra or Apache HBase for speed-layer output, and Elephant DB or Cloudera Impala for batch-layer output.
- #35: Але чогось не вистарчає…
- #36: Complexity isolation — complexity is pushed to layer whose results are temporary . Eventual accuracy — eventually all the results will be taken from serving layer. Speed layer might use approximate algorithms like HyperLogLog and BloomFilters for computations. Storm/Spark Streaming The speed layer processes data streams in real time and without the requirements of fix-ups or completeness. This layer sacrifices throughput as it aims to minimize latency by providing real-time views into the most recent data. Essentially, the speed layer is responsible for filling the "gap" caused by the batch layer's lag in providing views based on the most recent data. This layer's views may not be as accurate or complete as the ones eventually produced by the batch layer, but they are available almost immediately after data is received, and can be replaced when the batch layer's views for the same data become available. Stream-processing technologies typically used in this layer include Apache Storm, SQLstream and Apache Spark. Output is typically stored on fast NoSQL databases.
- #38: High-load meets big data
- #41: Java Nio2 Connector, 500 threads http://techblog.netflix.com/2015/07/tuning-tomcat-for-high-throughput-fail.html
- #42: Бачило що маємо певний ліміт по навантаженню, спільний для всіх варіантів. Мабуть це томкет ) Хто дасть такий варіант — подарунок. Система тепер досить добре витримує наватнаження. Цікавим є закономірний спад в околі 12к…
- #44: Ubuntu 14.04 (virtual machines, 2 cores, 8 GB RAM) згадати про Haproxy vs nginx Згадати про обмеження в 12к для всіх тестів, це був томкет. Треба оптимізувати.
- #45: Стовпчики Скейлінг фактор!!!
- #46: Як це типово для високонагружених рішень, я очікував що вульким місцем стане збереження даних або їх обробка, наприклад перша моя задача була — давай зробимо так щоб Кафка стала вузьким місцем, але вепрлися в лоад балансер. Та й 30к RPS це нормальна нагрузка.
- #49: Зоопарк