덤프 컨퍼런스 | grep '백엔드|devops'

지난 주 예카테린부르크에서 열린 DUMP IT 컨퍼런스(https://dump-ekb.ru/)에 참석했는데, 백엔드 및 데브옵스 섹션에서 논의된 내용과 지역 IT 컨퍼런스에 주목할 가치가 있는지 알려드리고 싶습니다.

서버리스에 대한 Evil Martians의 Nikolay Sverchkov

대체 거기엔 무엇이 있었나요?

컨퍼런스에는 백엔드, 프론트엔드, 모바일, 테스트 및 QA, 데브옵스, 디자인, 과학 및 관리 등 총 8개의 섹션이 있었습니다.

그런데 가장 큰 홀은 Science and Management에 있습니다.)) 각각 최대 350명을 수용할 수 있습니다. 백엔드와 프론트엔드는 그다지 작지 않습니다. Devops 룸은 가장 작지만 활동적이었습니다.

Devops 및 Backend 섹션의 보고서를 듣고 발표자와 잠시 이야기를 나눴습니다. 저는 컨퍼런스에서 다룬 주제에 대해 이야기하고 이러한 섹션을 검토하고 싶습니다.

SKB-Kontur, DataArt, Evil Martians, Ekaterinburg 웹 스튜디오 Flag, Miro(RealTimeBoard)의 대표가 Devops 및 Backend 섹션에서 연설했습니다. 다루는 주제는 CI/CD, 대기열 서비스 작업, 로깅, 서버리스 주제 및 Go에서 PostgreSQL 작업 등이 잘 다루어졌습니다.

Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank의 보고서도 있었지만 실제로 참석할 시간이 없었습니다. 보고서의 비디오 녹화 및 슬라이드는 아직 사용할 수 없으며 2주 이내에 게시하겠다고 약속했습니다. dump-ekb.ru에서).

데브옵스 섹션

놀라운 점은 이 섹션이 50석 정도의 가장 작은 홀에서 진행되었다는 점이었습니다. 통로에도 사람들이 서 있었어요 :) 제가 들은 리포트에 대해 말씀드릴게요.

페타바이트 단위의 탄력적 측정

이 섹션은 Kontur의 Elasticsearch에 대한 Vladimir Lil(SKB-Kontur)의 보고서로 시작되었습니다. 상당히 크고 로드된 Elastic(최대 800TB의 데이터, 중복성을 고려하면 ~1.3페타바이트)을 보유하고 있습니다. 모든 Kontur 서비스에 대한 Elasticsearch는 단일이며 2개의 클러스터(서버 7개 및 9개)로 구성되어 있으며 매우 중요하므로 Kontur에는 특별한 Elasticsearch 엔지니어(사실 Vladimir 자신)가 있습니다.

Vladimir는 또한 Elasticsearch의 이점과 그것이 가져오는 문제에 대한 자신의 생각을 공유했습니다.

이점 :

• 모든 로그가 한 곳에 있으므로 쉽게 액세스할 수 있습니다.
• XNUMX년 동안 로그를 저장하고 쉽게 분석
• 로그 작업 속도가 빠릅니다.
• 즉시 사용할 수 있는 멋진 데이터 시각화

문제 :

• 메시지 브로커는 필수입니다(Kontur의 경우 Kafka가 해당 역할을 수행함).
• Elasticsearch Curator 작업 기능 (Curator의 일반 작업으로 인해 주기적으로 높은 부하가 발생함)
• 내장된 승인 없음(별도의 꽤 큰 돈에 대해서만 또는 다양한 수준의 생산 준비가 가능한 오픈 소스 플러그인으로만)

Open Distro for Elasticsearch에 대해서는 긍정적인 리뷰만 있었습니다. :) 동일한 인증 문제가 해결되었습니다.

페타바이트는 어디에서 오는가?해당 노드는 12*8Tb SATA + 2*2Tb SSD를 갖춘 서버로 구성됩니다. SATA의 콜드 스토리지, 핫 캐시 전용 SSD(핫 스토리지).
7+9 서버, (7 + 9) * 12 * 8 = 1536TB.
공간의 일부는 예비로 남아 있으며 중복 등을 위해 따로 보관되어 있습니다.
Kontur, Elba 등의 모든 보고 서비스를 포함하여 약 90개 애플리케이션의 로그가 Elasticsearch로 전송됩니다.

서버리스 개발의 특징

다음은 Serverless에 관한 DataArt의 Ruslan Serkin이 작성한 보고서입니다.

Ruslan은 일반적으로 서버리스 접근 방식을 사용한 개발이 무엇인지, 그리고 그 기능이 무엇인지에 대해 이야기했습니다.

서버리스는 개발자가 어떤 방식으로든 인프라를 건드리지 않는 개발 접근 방식입니다. 예 - AWS Lambda 서버리스, Kubeless.io(Kubernetes 내부의 서버리스), Google Cloud Functions.

이상적인 서버리스 애플리케이션은 단순히 특수 API 게이트웨이를 통해 서버리스 공급자에게 요청을 보내는 기능입니다. 이상적인 마이크로서비스인 동시에 AWS Lambda는 수많은 최신 프로그래밍 언어도 지원합니다. 클라우드 제공업체의 경우 인프라 유지 및 배포 비용이 0.2이 되며, 소규모 애플리케이션을 지원하는 비용도 매우 저렴합니다(AWS Lambda - $1 / 단순 요청 XNUMX만 개).

이러한 시스템의 확장성은 거의 이상적입니다. 클라우드 제공업체가 이를 자체적으로 처리하고 Kubeless는 Kubernetes 클러스터 내에서 자동으로 확장됩니다.

단점이 있습니다:

• 대규모 애플리케이션 개발이 점점 더 어려워지고 있습니다.
• 애플리케이션을 프로파일링하는 데 어려움이 있습니다(로그에만 액세스할 수 있지만 일반적인 의미의 프로파일링은 불가능함).
• 버전 관리 없음

솔직히 말해서 몇 년 전에 Serverless에 대해 들었지만 수년 동안 이를 올바르게 사용하는 방법이 명확하지 않았습니다. Ruslan의 보고 이후 이해가 나타났고, Backend 섹션의 Nikolai Sverchkov(Evil Martians)의 보고 이후 통합되었습니다. 제가 컨퍼런스에 참석한 것은 헛되지 않았습니다 :)

CI는 가난한 사람들을 위한 것입니다. 아니면 웹 스튜디오를 위해 자신만의 CI를 작성하는 것이 가치가 있습니까?

예카테린부르크의 Flag 웹 스튜디오 책임자인 Mikhail Radionov는 자체 작성 CI/CD에 대해 이야기했습니다.

그의 스튜디오는 "수동 CI/CD"(SSH를 통해 서버에 로그인하고 git pull을 수행하고 하루에 100번 반복)에서 Jenkins와 코드를 모니터링하고 릴리스를 수행할 수 있는 자체 작성 도구인 Pullkins로 전환했습니다. .

Jenkins가 작동하지 않은 이유는 무엇입니까? 기본적으로 충분한 유연성을 제공하지 않았고 사용자 정의하기가 너무 어려웠습니다.

"플래그"는 Laravel(PHP 프레임워크)에서 개발됩니다. CI/CD 서버를 개발할 때 Mikhail과 그의 동료들은 Telescope와 Envoy라는 Laravel의 내장 메커니즘을 사용했습니다. 그 결과 들어오는 웹후크 요청을 처리하고, 프런트엔드와 백엔드를 구축하고, 다른 서버에 배포하고, Slack에 보고할 수 있는 PHP(참고) 서버가 탄생했습니다.

그런 다음 블루/그린 배포를 수행하고 개발-단계-프로덕션 환경에서 균일한 설정을 가질 수 있도록 Docker로 전환했습니다. 장점은 동일하게 유지되고 환경을 균질화하고 원활한 배포 가능성이 추가되었으며 Docker를 올바르게 사용하려면 Docker를 배워야 할 필요성이 추가되었습니다.

해당 프로젝트는 Github에 있습니다

서버 릴리스 롤백 횟수를 99%까지 줄인 방법

Devops 섹션의 마지막 보고서는 Miro.com(이전 RealTimeBoard)의 수석 Devops 엔지니어인 Viktor Eremchenko가 작성한 것입니다.

Miro 팀의 주력 제품인 RealTimeBoard는 모놀리식 Java 애플리케이션을 기반으로 합니다. 가동 중지 시간 없이 이를 수집, 테스트 및 배포하는 것은 어려운 작업입니다. 이 경우 롤백할 필요가 없도록 해당 버전의 코드를 배포하는 것이 중요합니다(무거운 단일체임).

이를 수행할 수 있는 시스템을 구축하는 과정에서 Miro는 아키텍처 작업, 사용된 도구(Atlassian Bamboo, Ansible 등), 팀 구조 작업(현재 전담 Devops 팀 + 다양한 프로필의 개발자로 구성된 별도의 Scrum 팀).

그 길은 어렵고 험난한 것으로 판명되었고 Victor는 거기서 끝나지 않은 축적된 고통과 낙천주의를 공유했습니다.

질문을 해서 책을 받았습니다

백엔드 섹션

저는 Nikolay Sverchkov(Evil Martians), 서버리스에 관한 보고서, 그리고 원격 측정에 관한 Grigory Koshelev(Kontur 회사)의 2개 보고서에 참석했습니다.

단순한 필사자를 위한 서버리스

Ruslan Sirkin이 Serverless가 무엇인지 이야기했다면 Nikolay는 Serverless를 사용한 간단한 애플리케이션을 보여주고, AWS Lambda에서 애플리케이션의 비용과 속도에 영향을 미치는 세부 사항에 대해 이야기했습니다.

흥미로운 세부정보: 최소 유료 요소는 128Mb의 메모리와 100ms의 CPU이며 비용은 $0,000000208입니다. 또한 매월 1만 건의 요청이 무료입니다.

Nikolai의 일부 기능은 종종 100ms 제한을 초과했기 때문에(주 애플리케이션은 Ruby로 작성됨) Go로 다시 작성하면 상당한 비용 절감 효과를 얻을 수 있었습니다.

Vostok Hercules — 원격 측정을 다시 한번 훌륭하게 만들어 보세요!

원격 측정에 관한 Grigory Koshelev(Kontur 회사)의 백엔드 섹션에 대한 최신 보고서입니다. 원격 측정은 로그, 메트릭, 애플리케이션 추적을 의미합니다.

이를 위해 Contour는 Github에 게시된 자체 작성 도구를 사용합니다. 보고서의 도구 - Hercules, github.com/vostok/hercules는 원격 측정 데이터를 전달하는 데 사용됩니다.

Devops 섹션에 있는 Vladimir Lila의 보고서에서는 Elasticsearch의 로그 저장 및 처리에 대해 논의했지만, 여전히 수천 개의 장치와 애플리케이션에서 로그를 전달하는 작업이 남아 있으며 Vostok Hercules와 같은 도구가 이를 해결합니다.

회로는 RabbitMQ에서 Apache Kafka까지 많은 사람들에게 알려진 경로를 따랐지만 모든 것이 그렇게 단순하지는 않습니다.) 그들은 Zookeeper, Cassandra 및 Graphite를 회로에 추가해야 했습니다. 나는 이 보고서(내 프로필이 아님)에 대한 정보를 완전히 공개하지 않을 것입니다. 관심이 있으시면 컨퍼런스 웹 사이트에서 슬라이드와 비디오를 기다리실 수 있습니다.

다른 컨퍼런스와 비교하면 어떤가요?

모스크바와 상트페테르부르크의 컨퍼런스와 비교할 수는 없지만 우랄 지역의 다른 행사와 사마라의 404페스트와 비교할 수는 있습니다.

DAMP는 8개의 섹션으로 나누어 개최되는데 이는 우랄 회의의 기록입니다. 매우 큰 과학 및 경영 섹션도 이례적입니다. 예카테린부르크의 청중은 매우 체계적입니다. 이 도시에는 Yandex, Kontur, Tinkoff를 위한 대규모 개발 부서가 있으며 이는 보고서에 표시됩니다.

또 다른 흥미로운 점은 많은 회사가 컨퍼런스에 동시에 3~4명의 연사를 갖는다는 것입니다(Kontur, Evil Martians, Tinkoff의 경우). 그들 중 다수는 스폰서였지만 보고서는 다른 보고서와 상당히 유사하며 광고 보고서가 아닙니다.

갈 것인가 말 것인가? Urals 또는 인근 지역에 살고 있다면 기회가 있고 주제에 관심이 있습니다. 물론 그렇습니다. 장거리 여행을 생각하신다면 지난 몇 년간의 리포트와 영상 리포트의 주제를 살펴보겠습니다. www.youtube.com/user/videoitpeople/videos 그리고 결정을 내렸습니다.
일반적으로 지역 회의의 또 다른 장점은 보고 후 발표자와 의사소통이 쉽고 그러한 의사소통에 대한 지원자가 적다는 것입니다.

Dump와 Ekaterinburg에게 감사드립니다! )

출처 : habr.com