분산 애플리케이션의 빌딩 블록. 제로 근사

세상은 가만히 있지 않습니다. 진보는 새로운 기술적 과제를 창출합니다. 변화하는 요구 사항에 따라 정보 시스템의 아키텍처도 발전해야 합니다. 오늘 우리는 이벤트 중심 아키텍처, 동시성, 동시성, 비동기성에 대해 이야기하고 Erlang에서 이 모든 것을 평화롭게 살 수 있는 방법에 대해 이야기하겠습니다.

소개

설계된 시스템의 크기와 요구 사항에 따라 개발자는 시스템에서 정보를 교환하는 방법을 선택합니다. 대부분의 경우 서비스 상호 작용을 구성하기 위한 작업 옵션은 RabbitMQ 또는 kafka를 기반으로 하는 브로커를 사용하는 방식일 수 있습니다. 그러나 이벤트 흐름, SLA 및 시스템 제어 수준으로 인해 기성 메시징이 적합하지 않은 경우도 있습니다. 물론 ZeroMQ나 nanomsg 등을 사용하여 전송 계층과 클러스터 형성을 담당하면 시스템이 약간 복잡해질 수 있습니다. 그러나 시스템에 표준 Erlang 클러스터의 처리량과 기능이 충분하다면 추가 엔터티를 도입하는 문제에는 자세한 연구와 경제적 타당성이 필요합니다.

반응형 분산 애플리케이션의 주제는 상당히 광범위합니다. 기사의 형식을 유지하기 위해 오늘 논의 주제는 Erlang/Elixir를 기반으로 구축된 동종 환경에 대해서만 다룰 것입니다. Erlang/OTP 생태계를 사용하면 최소한의 노력으로 반응형 아키텍처를 구현할 수 있습니다. 그러나 어떤 경우에도 메시징 계층이 필요합니다.

이론적 기초

디자인은 목표와 제약 조건을 정의하는 것부터 시작됩니다. 주요 목표는 개발을 위한 개발 영역에 있지 않습니다. 우리는 다양한 수준의 최신 애플리케이션을 생성하고 개발할 수 있는 안전하고 확장 가능한 도구를 확보해야 합니다. 소규모 사용자에게 서비스를 제공하는 단일 서버 애플리케이션에서 시작하여 나중에 최대 50명의 클러스터로 발전할 수 있습니다. -60개의 노드, 클러스터 페더레이션으로 끝납니다. 따라서 최종 시스템의 개발 비용과 소유 비용을 줄여 수익을 극대화하는 것이 주요 목표입니다.

최종 시스템에 대한 4가지 주요 요구 사항을 강조하겠습니다.

• С이벤트 지향적입니다.
  시스템은 항상 이벤트 흐름을 통과하고 필요한 작업을 수행할 준비가 되어 있습니다.
• М확장성.
  개별 블록은 수직 및 수평으로 크기를 조정할 수 있습니다. 전체 시스템은 무한한 수평적 성장이 가능해야 합니다.
• О결함 허용.
  모든 수준과 모든 서비스는 장애로부터 자동으로 복구할 수 있어야 합니다.
• Г보장된 응답 시간.
  시간은 소중하므로 사용자는 너무 오래 기다려서는 안 됩니다.

“할 수 있는 작은 엔진”에 관한 옛 동화를 기억하시나요? 설계된 시스템이 프로토타입 단계를 성공적으로 종료하고 발전하려면 그 기반이 최소 요구 사항을 충족해야 합니다. 스모그.

메시징에는 인프라 도구이자 모든 서비스의 기초로서 프로그래머의 사용 용이성이 한 가지 더 추가되었습니다.

이벤트 중심

애플리케이션이 단일 서버에서 클러스터로 성장하려면 해당 아키텍처가 느슨한 결합을 지원해야 합니다. 비동기식 모델은 이 요구 사항을 충족합니다. 그 안에서 발신자와 수신자는 메시지의 정보 로드에 관심을 갖고 시스템 내 전송 및 라우팅에 대해 걱정하지 않습니다.

확장성

확장성과 시스템 효율성은 서로 밀접한 관련이 있습니다. 애플리케이션 구성 요소는 사용 가능한 모든 리소스를 활용할 수 있어야 합니다. 용량을 더욱 효율적으로 활용하고 처리 방법을 더욱 최적화할수록 장비에 지출하는 비용이 줄어듭니다.

단일 시스템 내에서 Erlang은 경쟁이 치열한 환경을 조성합니다. 동시성과 병렬성 사이의 균형은 Erlang VM에 사용 가능한 운영 체제 스레드 수와 이러한 스레드를 활용하는 스케줄러 수를 선택하여 설정할 수 있습니다.
Erlang 프로세스는 상태를 공유하지 않으며 비차단 모드에서 작동합니다. 이는 기존 차단 기반 애플리케이션보다 상대적으로 낮은 대기 시간과 높은 처리량을 제공합니다. Erlang의 스케줄러는 CPU와 IO의 공정한 할당을 보장하며, 차단이 없기 때문에 최대 부하나 오류가 발생하는 동안에도 애플리케이션이 응답할 수 있습니다.

클러스터 수준에서는 폐기 문제도 존재합니다. 클러스터의 모든 시스템이 균등하게 로드되고 네트워크가 과부하되지 않는 것이 중요합니다. 상황을 상상해 봅시다. 사용자 트래픽이 들어오는 밸런서(haproxy, nginx 등)에 도달하고 사용 가능한 백엔드 집합 간에 처리 요청을 최대한 균등하게 배포합니다. 애플리케이션 인프라 내에서 필요한 인터페이스를 구현하는 서비스는 마지막 단계에 불과하며 초기 요청에 응답하기 위해 여러 다른 서비스를 요청해야 합니다. 내부 요청에도 라우팅과 밸런싱이 필요합니다.
데이터 흐름을 효과적으로 관리하려면 메시징은 개발자에게 라우팅 및 로드 균형 조정을 관리할 수 있는 인터페이스를 제공해야 합니다. 덕분에 개발자는 마이크로서비스 패턴(집합자, 프록시, 체인, 지점 등)을 사용하여 표준 문제와 거의 발생하지 않는 문제를 모두 해결할 수 있습니다.

비즈니스 관점에서 확장성은 위험 관리 도구 중 하나입니다. 가장 중요한 것은 장비를 최적으로 사용하여 고객 요청을 충족시키는 것입니다.

• 진행에 따라 장비의 위력이 증가하는 경우. 불완전한 소프트웨어로 인해 유휴 상태가 되지 않습니다. Erlang은 수직적으로 잘 확장되며 항상 모든 CPU 코어와 사용 가능한 메모리를 활용할 수 있습니다.
• 클라우드 환경에서는 현재 또는 예상되는 부하에 따라 장비의 수량을 관리하고 SLA를 보장할 수 있습니다.

결함 허용

두 가지 원칙, 즉 "실패는 용납될 수 없습니다"와 "항상 실패는 있을 것입니다"를 고려해 보겠습니다. 비즈니스에 있어 소프트웨어 오류는 금전적 손실을 의미하며, 더 나쁜 것은 평판 손실을 의미합니다. 가능한 손실과 내결함성 소프트웨어 개발 비용 간의 균형을 맞추면 절충안을 찾을 수 있는 경우가 많습니다.

단기적으로 내결함성을 통합한 아키텍처는 기성 클러스터링 솔루션 구입 비용을 절약해 줍니다. 가격도 비싸고 벌레도 있어요.
장기적으로 내결함성 아키텍처는 개발의 모든 단계에서 여러 배의 가치를 발휘합니다.
코드 베이스 내의 메시징을 사용하면 개발 단계에서 시스템 내 구성 요소의 상호 작용을 자세히 해결할 수 있습니다. 이는 모든 중요한 구성 요소가 오류를 처리하고 결과 시스템이 설계상 오류 발생 후 자동으로 정상으로 돌아가는 방법을 알고 있기 때문에 오류 대응 및 관리 작업을 단순화합니다.

민감도

오류에 관계없이 애플리케이션은 요청에 응답하고 SLA를 충족해야 합니다. 현실은 사람들이 기다리고 싶어하지 않기 때문에 기업은 이에 맞춰 적응해야 합니다. 응답성이 뛰어난 애플리케이션이 점점 더 많아질 것으로 예상됩니다.
반응형 애플리케이션은 거의 실시간으로 작동합니다. Erlang VM은 소프트 실시간 모드로 작동합니다. 주식 거래, 의약품, 산업 설비 제어 등 일부 분야에서는 하드 실시간 모드가 중요합니다.
반응형 시스템은 UX를 개선하고 비즈니스에 도움이 됩니다.

예비 요약

이 글을 기획하면서 메시징 브로커를 만들고 이를 기반으로 복잡한 시스템을 구축한 경험을 공유하고 싶었습니다. 그러나 이론적, 동기 부여 부분은 상당히 광범위한 것으로 나타났습니다.
기사의 두 번째 부분에서는 교환 지점 구현의 뉘앙스, 메시징 패턴 및 적용에 대해 설명하겠습니다.
세 번째 부분에서는 서비스 구성, 라우팅 및 밸런싱과 관련된 일반적인 문제를 고려할 것입니다. 시스템의 확장성과 내결함성의 실질적인 측면에 대해 이야기해 보겠습니다.

첫 번째 부분의 끝.

Фото @루카브라보.

출처 : habr.com