Tuần trước tôi đã đến dự hội nghị DUMP IT (https://dump-ekb.ru/) ở Yekaterinburg và tôi muốn cho bạn biết những gì đã được thảo luận trong phần Backend và Devops cũng như liệu các hội nghị CNTT khu vực có đáng được chú ý hay không.
Nikolay Sverchkov từ Evil Martians về Serverless
Dù sao thì ở đó có gì?
Tổng cộng, hội nghị có 8 phần: Backend, Frontend, Mobile, testing and QA, Devops, Design, Science và Management.
Nhân tiện, hội trường lớn nhất là ở Khoa học và Quản lý)) Dành cho ~350 người mỗi hội trường. Backend và Frontend không nhỏ hơn nhiều. Phòng Devops nhỏ nhất nhưng vẫn hoạt động.
Tôi đã nghe các báo cáo trong phần Devops và Backend và trao đổi một chút với các diễn giả. Tôi muốn nói về các chủ đề được đề cập và xem xét các phần này tại hội nghị.
Đại diện của SKB-Kontur, DataArt, Evil Martians, studio web Flag, Miro (RealTimeBoard) đã phát biểu trong phần Devops và Backend. Các chủ đề bao gồm CI/CD, làm việc với các dịch vụ hàng đợi, ghi nhật ký; các chủ đề Serverless và làm việc với PostgreSQL trong Go đã được đề cập kỹ lưỡng.
Ngoài ra còn có các báo cáo của Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, nhưng tôi không có thời gian để tham dự trực tiếp (chưa có bản ghi video và slide báo cáo, họ hứa sẽ đăng chúng lên bãi chứa- ekb.ru trong vòng 2 tuần).
Phần Devops
Điều đáng ngạc nhiên là phần thi được tổ chức ở hội trường nhỏ nhất, khoảng 50 chỗ ngồi. Mọi người thậm chí còn đứng trên lối đi :) Tôi sẽ kể cho bạn nghe về những báo cáo mà tôi đã nghe được.
Đàn hồi nặng một petabyte
Phần này bắt đầu bằng báo cáo của Vladimir Lil (SKB-Kontur) về Elaticsearch ở Kontur. Chúng có Elastic khá lớn và được tải (~800 TB dữ liệu, ~1.3 petabyte có tính đến dự phòng). Elaticsearch cho tất cả các dịch vụ của Kontur là đơn lẻ, bao gồm 2 cụm (7 và 9 máy chủ) và quan trọng đến mức Kontur phải có một kỹ sư Elaticsearch đặc biệt (thực tế là chính Vladimir).
Vladimir cũng chia sẻ suy nghĩ của mình về lợi ích của Elaticsearch và những vấn đề mà nó mang lại.
Lợi ích:
- Tất cả nhật ký đều ở một nơi, dễ dàng truy cập chúng
- Lưu trữ nhật ký trong một năm và dễ dàng phân tích chúng
- Tốc độ làm việc cao với nhật ký
- Trực quan hóa dữ liệu thú vị ngay lập tức
Các vấn đề:
- nhà môi giới tin nhắn là điều bắt buộc phải có (đối với Kontur, vai trò của nó do Kafka đảm nhận)
- các tính năng khi làm việc với Elaticsearch Curator (định kỳ tạo tải cao từ các tác vụ thông thường trong Curator)
- không có ủy quyền tích hợp (chỉ dành cho số tiền riêng biệt, khá lớn hoặc dưới dạng plugin nguồn mở có mức độ sẵn sàng sản xuất khác nhau)
Chỉ có những đánh giá tích cực về Open Distro cho Elaticsearch :) Vấn đề ủy quyền tương tự đã được giải quyết ở đó.
Petabyte đến từ đâu?Các nút của họ bao gồm các máy chủ có ổ SSD 12*8 Tb SATA + 2*2 Tb. Kho lạnh trên SATA, SSD chỉ dành cho hot cache (hot storage).
Máy chủ 7+9, (7 + 9) * 12 * 8 = 1536 Tb.
Một phần không gian được dự trữ, dành cho dự phòng, v.v.
Nhật ký từ khoảng 90 ứng dụng được gửi đến Elaticsearch, bao gồm tất cả các dịch vụ báo cáo của Kontur, Elba, v.v.
Đặc điểm phát triển trên Serverless
Tiếp theo là báo cáo của Ruslan Serkin từ DataArt về Serverless.
Ruslan đã nói về quá trình phát triển theo phương pháp Serverless nói chung và các tính năng của nó.
Serverless là một cách tiếp cận phát triển trong đó các nhà phát triển không chạm vào cơ sở hạ tầng dưới bất kỳ hình thức nào. Ví dụ - AWS Lambda Serverless, Kubeless.io (Serverless bên trong Kubernetes), Google Cloud Functions.
Một ứng dụng Serverless lý tưởng chỉ đơn giản là một chức năng gửi yêu cầu đến nhà cung cấp Serverless thông qua Cổng API đặc biệt. Một microservice lý tưởng, trong khi AWS Lambda cũng hỗ trợ một số lượng lớn ngôn ngữ lập trình hiện đại. Chi phí duy trì và triển khai cơ sở hạ tầng trở thành 0.2 trong trường hợp nhà cung cấp đám mây, hỗ trợ các ứng dụng nhỏ cũng sẽ rất rẻ (AWS Lambda - 1 USD / XNUMX triệu yêu cầu đơn giản).
Khả năng mở rộng của một hệ thống như vậy gần như lý tưởng - nhà cung cấp đám mây tự giải quyết vấn đề này, Kubless tự động mở rộng quy mô trong cụm Kubernetes.
Có những nhược điểm:
- Phát triển các ứng dụng lớn đang trở nên khó khăn hơn
- gặp khó khăn với việc lập hồ sơ ứng dụng (bạn chỉ có thể sử dụng nhật ký chứ không phải lập hồ sơ theo nghĩa thông thường)
- không có phiên bản
Thành thật mà nói, tôi đã nghe nói về Serverless vài năm trước, nhưng suốt những năm qua tôi không rõ cách sử dụng nó một cách chính xác. Sau báo cáo của Ruslan, sự hiểu biết đã xuất hiện và sau báo cáo của Nikolai Sverchkov (Người Sao Hỏa Ác ma) từ phần Phần cuối, nó đã được củng cố. Việc tôi đi dự hội nghị không phải là vô ích :)
CI dành cho người nghèo, hay việc viết CI của riêng bạn cho một studio trên web có đáng không?
Mikhail Radionov, người đứng đầu studio web Flag từ Yekaterinburg, đã nói về CI/CD tự viết.
Studio của anh ấy đã chuyển từ “CI/CD thủ công” (đăng nhập vào máy chủ qua SSH, thực hiện git pull, lặp lại 100 lần một ngày) sang Jenkins và chuyển sang một công cụ tự viết cho phép bạn giám sát mã và thực hiện các bản phát hành có tên Pullkins .
Tại sao Jenkins không làm việc? Theo mặc định, nó không cung cấp đủ tính linh hoạt và quá khó để tùy chỉnh.
“Flag” phát triển trong Laravel (khuôn khổ PHP). Khi phát triển máy chủ CI/CD, Mikhail và các đồng nghiệp của mình đã sử dụng các cơ chế tích hợp sẵn của Laravel có tên là Telescope và Envoy. Kết quả là một máy chủ bằng PHP (xin lưu ý) xử lý các yêu cầu webhook đến, có thể xây dựng giao diện người dùng và chương trình phụ trợ, triển khai đến các máy chủ khác nhau và báo cáo cho Slack.
Sau đó, để có thể thực hiện triển khai xanh/xanh và có cài đặt thống nhất trong môi trường dev-stage-prod, họ đã chuyển sang Docker. Các ưu điểm vẫn được giữ nguyên, khả năng đồng nhất hóa môi trường và triển khai liền mạch đã được bổ sung cũng như nhu cầu học Docker để làm việc với nó một cách chính xác cũng được bổ sung.
Cách chúng tôi giảm 99% số lần khôi phục bản phát hành máy chủ
Báo cáo cuối cùng trong phần Devops là của Viktor Eremchenko, Kỹ sư trưởng nhóm phát triển tại Miro.com (trước đây là RealTimeBoard).
RealTimeBoard, sản phẩm chủ lực của nhóm Miro, dựa trên ứng dụng Java nguyên khối. Thu thập, thử nghiệm và triển khai nó mà không có thời gian chết là một nhiệm vụ khó khăn. Trong trường hợp này, điều quan trọng là phải triển khai phiên bản mã như vậy để nó không phải khôi phục lại (nó là một khối nguyên khối nặng).
Trên con đường xây dựng một hệ thống cho phép bạn thực hiện điều này, Miro đã đi qua một con đường bao gồm làm việc về kiến trúc, các công cụ được sử dụng (Atlassian Bamboo, Ansible, v.v.) và làm việc về cấu trúc của các nhóm (hiện họ đã có một nhóm Devops chuyên dụng + nhiều nhóm Scrum riêng biệt từ các nhà phát triển thuộc các hồ sơ khác nhau).
Con đường trở nên khó khăn và chông gai, Victor đã chia sẻ nỗi đau tích lũy và sự lạc quan không kết thúc ở đó.
Giành được một cuốn sách nhờ đặt câu hỏi
Phần phụ trợ
Tôi đã tham dự được 2 báo cáo - từ Nikolay Sverchkov (Evil Martians), cũng về Serverless, và từ Grigory Koshelev (công ty Kontur) về đo từ xa.
Không có máy chủ cho người phàm
Nếu Ruslan Sirkin nói về Serverless là gì thì Nikolay lại trình bày những ứng dụng đơn giản sử dụng Serverless và nói về những chi tiết ảnh hưởng đến chi phí cũng như tốc độ của các ứng dụng trong AWS Lambda.
Một chi tiết thú vị: phần tử phải trả tối thiểu là 128 Mb bộ nhớ và CPU 100 ms, nó có giá 0,000000208 USD. Hơn nữa, 1 triệu yêu cầu như vậy mỗi tháng là miễn phí.
Một số chức năng của Nikolai thường vượt quá giới hạn 100 ms (ứng dụng chính được viết bằng Ruby), vì vậy việc viết lại chúng trong Go mang lại sự tiết kiệm tuyệt vời.
Vostok Hercules — làm cho việc đo từ xa trở nên tuyệt vời trở lại!
Báo cáo mới nhất của phần Backend từ Grigory Koshelev (công ty Kontur) về đo từ xa. Đo từ xa có nghĩa là nhật ký, số liệu, dấu vết ứng dụng.
Với mục đích này, Contour sử dụng các công cụ tự viết được đăng trên Github. Công cụ từ báo cáo - Hercules, , được sử dụng để cung cấp dữ liệu đo từ xa.
Báo cáo của Vladimir Lila trong phần Devops đã thảo luận về việc lưu trữ và xử lý nhật ký trong Elaticsearch, nhưng vẫn có nhiệm vụ phân phối nhật ký từ hàng nghìn thiết bị và ứng dụng cũng như các công cụ như Vostok Hercules giải quyết chúng.
Mạch đã đi theo một con đường được nhiều người biết đến - từ RabbitMQ đến Apache Kafka, nhưng không phải mọi thứ đều đơn giản như vậy)) Họ đã phải thêm Zookeeper, Cassandra và Graphite vào mạch. Tôi sẽ không tiết lộ đầy đủ thông tin trong báo cáo này (không phải hồ sơ của tôi), nếu quan tâm, bạn có thể chờ các slide và video trên website hội nghị.
So sánh với các hội nghị khác như thế nào?
Tôi không thể so sánh nó với các hội nghị ở Moscow và St. Petersburg, tôi có thể so sánh nó với các sự kiện khác ở Urals và với 404fest ở Samara.
DAMP được tổ chức thành 8 phần, đây là kỷ lục đối với hội nghị Ural. Phần Khoa học và Quản lý rất lớn, điều này cũng không bình thường. Khán giả ở Yekaterinburg khá có cấu trúc - thành phố có các bộ phận phát triển lớn cho Yandex, Kontur, Tinkoff, và điều này để lại dấu ấn trong các báo cáo.
Một điểm thú vị khác là nhiều công ty có 3-4 diễn giả tại hội nghị cùng một lúc (trường hợp này xảy ra với Kontur, Evil Martians, Tinkoff). Nhiều người trong số họ là nhà tài trợ, nhưng các báo cáo khá ngang bằng với những báo cáo khác, đây không phải là báo cáo quảng cáo.
Đi hay không đi? Nếu bạn sống ở Urals hoặc gần đó, bạn có cơ hội và quan tâm đến các chủ đề này - tất nhiên là có. Nếu bạn đang nghĩ về một chuyến đi dài, tôi sẽ xem xét các chủ đề của các báo cáo và báo cáo video từ những năm trước và đưa ra quyết định.
Theo quy luật, một ưu điểm khác của các hội nghị trong khu vực là dễ dàng giao tiếp với diễn giả sau khi báo cáo; đơn giản là có ít người đăng ký tham gia cuộc giao tiếp như vậy hơn.
Cảm ơn Dump và Ekaterinburg! )
Nguồn: www.habr.com
