MACH란 무엇이며 누가 정의했나요?

마하 의해 만들어진 약어이다. 마하 얼라이언스, 협회 Commercetools, Contentful, EPAM Systems 등이 2020년에 설립한 기술 공급업체입니다. 아니다 그것은 제품입니다. 시스템 구축을 위한 일련의 아키텍처 원칙입니다. 현대 기업.

  • M — 마이크로서비스: 각 비즈니스 기능은 독립적인 서비스입니다.
  • A — API 우선: 각 서비스는 잘 정의된 API를 기본 인터페이스로 노출합니다.
  • C — 클라우드 네이티브: 탄력적인 확장 및 관리형 서비스를 갖춘 퍼블릭 클라우드용으로 구축됨
  • H — 헤드리스: 프런트엔드와 백엔드가 분리되어 있습니다.

근본적인 아이디어는 동종 최고의: 단일 제품군을 구입하는 대신 모든 것을 다 하는(보통) 기능별로 최적의 서비스를 선택해 플랫폼을 구성한다. 맞춤형. 최고의 제품 검색 엔진(Algolia), 최고의 결제(Stripe), 최고의 CMS(Contentful), 최고의 PIM(Akeneo).

4가지 MACH 치수에 대한 세부사항

마이크로서비스: 제한된 컨텍스트에 대한 분해

MACH 아키텍처에서 상거래 도메인은 정렬된 독립 서비스로 분해됩니다. 아이 제한된 컨텍스트 도메인 기반 디자인의: 

// Esempio di decomposizione in microservizi commerce

const MACH_SERVICES = {
  // Servizi core commerce
  catalog: 'Gestione prodotti, categorie, attributi, varianti',
  pricing: 'Regole di prezzo, sconti, tier pricing, valute',
  inventory: 'Stock real-time, warehouse, backorder',
  cart: 'Sessioni di carrello, regole di promozione',
  checkout: 'Checkout flow, address validation, ordine',
  payments: 'Processing pagamenti, rimborsi, split payments',
  fulfillment: 'Gestione spedizioni, tracking, resi',

  // Servizi supporto
  search: 'Full-text search, filtri, ranking (Algolia)',
  recommendations: 'Prodotti correlati, personalization',
  cms: 'Contenuto editoriale, landing page (Contentful/Sanity)',
  pim: 'Product Information Management (Akeneo)',
  loyalty: 'Punti, rewards, programmi fedeltà',
  notifications: 'Email, SMS, push notifications',
};

API 우선: 구현 전 계약

API 우선 시스템에서 API는 정의된 계약입니다. 전에 구현의. 계약을 맺기 때문에 각 팀은 독립적으로 자체 서비스를 개발할 수 있습니다. API가 이미 정의되어 있습니다. 

// OpenAPI spec per il Catalog Service
openapi: 3.1.0
info:
  title: Catalog Service API
  version: 2.0.0

paths:
  /products:
    get:
      summary: Lista prodotti con paginazione e filtri
      parameters:
        - name: cursor
          in: query
          schema:
            type: string
        - name: category
          in: query
          schema:
            type: string
        - name: priceMin
          in: query
          schema:
            type: number
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProductPage'

  /products/{id}:
    get:
      summary: Dettaglio prodotto singolo
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
        '404':
          $ref: '#/components/responses/NotFound'

클라우드 네이티브: 탄력적 확장 및 관리형 서비스

클라우드 네이티브는 "클라우드에서 실행"을 의미하는 것이 아니라 이를 활용하도록 특별히 설계되었음을 의미합니다. 클라우드 기능: 자동 수평 확장, 내결함성, 관찰 가능성 통합:

  • Kubernetes(또는 이벤트 기반 로드를 위한 Lambda 함수)로 조정되는 Docker 컨테이너
  • 자체 관리형 인스턴스 대신 관리형 데이터베이스(Cloud Spanner, RDS, DynamoDB)
  • 비동기 통신을 위한 이벤트 버스 관리(AWS EventBridge, Google Pub/Sub)
  • 프런트엔드 전달을 위한 글로벌 CDN
  • 복원력을 위한 자동 회로 차단기 및 재시도

헤드리스: 백엔드가 없는 프런트엔드

MACH의 H 차원은 이미 시리즈의 첫 번째 기사에서 탐구되었습니다. 프런트엔드는 API를 사용하지만 백엔드에서 생성되지 않습니다. MACH 아키텍처에서는 이를 완료합니다. 종종 다음을 의미합니다. BFF(프런트엔드용 백엔드) i용 API를 최적화하기 위해 특정 클라이언트: 

// BFF Pattern: GraphQL aggregation layer
// Aggrega chiamate a più microservizi in un'unica risposta ottimizzata

type Query {
  productPage(
    category: String
    cursor: String
    filters: [FilterInput!]
  ): ProductPageResult!
}

type ProductPageResult {
  products: [ProductSummary!]!
  facets: [FacetGroup!]!       # da Algolia
  recommendations: [ProductSummary!]!  # da recommendation service
  pageInfo: PageInfo!
}

// Il resolver fa chiamate parallele a catalog, search e recommendations
const resolvers = {
  Query: {
    productPage: async (_, args) => {
      const [products, facets, recs] = await Promise.all([
        catalogService.getProducts(args),
        searchService.getFacets(args),
        recommendationService.get(args.category),
      ]);
      return { products, facets, recommendations: recs, pageInfo: products.pageInfo };
    },
  },
};

MACH 대 모노리스: 실제 비교

MACH 대 모노리스: 더 나은 경우 무엇

  • 모놀리스 관리형(Shopify, WooCommerce): 몇 주 만에 시장 출시, 소규모 팀, 저렴한 비용 - 연간 GMV < 5M EUR에 적합
  • 부분 MACH(헤드리스 + 동종 최고): 점진적인 유연성, 중간 규모 팀 - 특정 요구 사항이 있는 연간 GMV 5-5천만 EUR에 이상적
  • 전체 마하: 최대의 유연성, 높은 비용, 대규모 팀 — 연간 GMV > 5천만 유로 또는 특정 기업 요구 사항에 적합

MACH 거버넌스 및 안티패턴

MACH 구현에서 가장 흔한 실수는 거버넌스 없이 너무 많이 조각화하는 것입니다.

피해야 할 MACH 안티 패턴

  • 조기 마이크로서비스: 1000개의 서비스를 처리할 때 20개의 서비스로 분해 월별 주문 수는 순수한 과잉 엔지니어링입니다. 모듈식 단일체로 시작하고 분해하기만 하면 됩니다. 다르게 확장되는 부분.
  • 버전이 지정된 API 계약이 없습니다.: API 버전 관리 없이 모든 팀 배포 시 다른 사람들을 깨뜨릴 것입니다. OpenAPI 3.1 + 의미 체계 버전 관리를 채택하세요.
  • 계단식 동기 호출: 5개의 서비스를 순차적으로 호출하는 요청 레이턴시를 축적합니다. 가능한 경우 병렬 호출을 사용하고 대량 읽기에는 CQRS 패턴을 사용합니다.
  • 공유 데이터베이스: 두 개의 MACH 서비스가 데이터베이스를 공유하는 경우 정말 독립. 각 서비스에는 자체 데이터 저장소가 있어야 합니다.

MACH를 점진적으로 구현

한 번에 MACH로 마이그레이션할 필요는 없습니다. 교살자 무화과 패턴 접근법 권장됩니다:

  1. 1단계: 기존 모노리스 위에 헤드리스 레이어를 추가합니다. 프런트엔드 새로운 API 호출, 모놀리스는 REST/GraphQL 레이어를 통해 API를 생성합니다. 코어에는 변화가 없습니다.
  2. 2단계: 가장 필요한 기능에 대한 첫 번째 마이크로서비스를 가져옵니다. 사양(종종 검색 또는 목록). 나머지 부분은 계속해서 단일체로 처리됩니다.
  3. 3단계: 서비스별로 추출 서비스를 계속하고, 점진적으로 제거합니다. 모놀리스에 대한 의존성.

결론

MACH는 체크리스트가 아닌 건축적 열망입니다. API 우선 및 헤드리스 원칙 부분적인 구현에서도 실질적인 가치를 제공합니다. 마이크로서비스로 분해되어 클라우드 네이티브는 그림을 완성하지만 조직의 성숙도가 필요합니다.

다음 기사에서는 구체적인 구현을 살펴보겠습니다. Shopify Hydrogen 관리형 인프라의 헤드리스, 자체 호스팅 오픈 소스를 선호하는 사람들을 위한 Medusa.js 기본 GraphQL이 필요한 Python 팀을 위한 Saleor입니다.

이전 기사 ← 헤드리스 커머스(Headless Commerce): 그것이 무엇인가
시리즈의 다음 Shopify 수소 및 산소 →