Logic Apps Standard 내부: 스토리지 확장을 위한 Compute Units (CU) 이해

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided it and preserve all formatting, code blocks, URLs, and technical terms.

소개

Logic App Standard 워크플로우의 양과 복잡성이 증가하면 Azure는 Compute Units (CU) 를 통한 강력한 수평 확장 메커니즘을 제공합니다. 이 게시물에서는 CU 아키텍처가 Logic Apps가 데이터 일관성과 라우팅 무결성을 유지하면서 여러 스토리지 계정에 저장 부하를 분산시키는 방법을 설명합니다.

스토리지 확장이 중요한 이유

단일 Azure Storage 계정에는 고유한 제한이 있습니다:

Note: 이러한 임계값을 초과하면 요청이 제한(throttling)됩니다.

Logic App이 수천 번 실행되고 각 실행마다 수십 개의 작업을 처리하면, 단일 스토리지 계정이 매우 빠르게 병목 현상이 될 수 있습니다.

Microsoft의 가이드라인

• 스토리지 계정당 분당 약 100 K 작업 실행이 추가 스토리지를 평가하기 위한 권장 임계값입니다.
• 컴퓨팅 집약적인 워크플로 작업은 이 임계값을 크게 낮출 수 있으므로 사용량을 면밀히 모니터링하십시오.

Source:

Compute Units란 무엇인가?

Compute Units(또는 Scale Units)는 Azure Logic Apps의 수평 스토리지 확장 메커니즘입니다. 모든 워크플로 실행 데이터를 하나의 스토리지 계정에 과부하시키는 대신, Logic Apps는 최대 32개의 스토리지 계정(CU00 ~ CU31)으로 부하를 분산시킬 수 있습니다.

구성 방법

host.json 파일에 Runtime.ScaleUnitsCount 설정을 추가합니다:

{
  "runtime": {
    "scaleUnitsCount": 4   // Compute Units 수 (1‑32)
  }
}

• 4를 원하는 Compute Units 수로 바꿉니다(최소 1, 최대 32).
• 이 값은 런타임이 프로비저닝하고 사용할 스토리지 계정의 개수를 결정합니다.

단일 스토리지 아키텍처

가장 간단한 배포에서는 모든 워크플로가 단일 스토리지 계정을 사용합니다:

Logic App → CU00 (Master) → Single Storage Account

단일 스토리지 계정을 사용할 경우:

• 모든 워크플로 정의, 실행 및 작업이 하나의 스토리지 계정에 저장됩니다.
• 스토리지 계정은 CU00 접미사를 사용합니다.
• 이 설정은 낮은~중간 수준의 워크로드에 적합합니다.

스케일‑아웃 스토리지 아키텍처

Logic App이 대용량 워크플로를 처리해야 할 때, 스케일 아웃을 통해 컴퓨트 유닛당 하나씩, 여러 스토리지 계정을 사용할 수 있습니다. 이를 통해 다수의 스토리지 엔드포인트에 걸쳐 병렬 읽기·쓰기 작업이 가능해집니다.

Logic App → CU00 (Master) → Storage Account 1
         → CU01           → Storage Account 2
         → CU02           → Storage Account 3
         → …              → …
         → CU31           → Storage Account 32

각 컴퓨트 유닛(CU)은 자체 전용 스토리지 계정에 매핑되어, Logic App이 최대 32개의 스토리지 엔드포인트에 부하를 분산시킬 수 있습니다.

Source:

CU 라우팅 작동 방식

이 아키텍처의 핵심은 Run ID입니다. 모든 워크플로 실행에는 해당 실행 데이터가 저장된 스토리지 계정을 식별하는 CU 접미사가 포함됩니다:

08584345852018133305811297792-CU00
08584345852018133305811297793-CU01
08584345852018133305711297794-CU02

라우팅 단계

1. Run ID에서 CU 접미사(예: -CU01)를 추출합니다.
2. Logic App + CU 조합에 대한 스토리지 계정 매핑을 조회합니다.
3. 해당 스토리지 계정에서 액션 데이터를 쿼리합니다.

이를 통해 실행 세부 정보를 요청할 때 시스템이 정확히 어느 스토리지 계정을 조회해야 하는지 알 수 있습니다.

CU별 테이블 분배

모든 테이블이 동일하게 분배되는 것은 아닙니다. 구분은 아래와 같습니다:

두 가지 할당 메커니즘

1. 워크플로 테이블 (ScaleUnit 필드)

• 새 워크플로를 배포하면 Logic Apps가 **컴퓨트 유닛 (CU)**에 할당합니다.
• 개발자 관점에서 비결정적 – “이 워크플로를 CU02에 배치해라”와 같이 지정할 수 없습니다.
• 배포 시점에 결정 – 워크플로가 추가되는 즉시 Logic Apps가 CU를 선택합니다.
• 할당 정보는 워크플로 메타데이터(flows 테이블의 ScaleUnit 열)에 저장됩니다.

워크플로의 flows, runs, 그리고 histories 테이블은 모두 할당된 CU에 속한 스토리지 계정에 존재합니다.

2. 액션 테이블 (RunId‑CUXX 접미사)

액션 테이블은 런당 배포되며, 워크플로당이 아닙니다. 각 실행은 자체 CU를 할당받으며, 이는 RunId 접미사에 반영됩니다:

08584345852018133305811297792-CU01
08584345852115148130432249577-CU00

결과

• 하나의 워크플로 액션이 여러 CU 스토리지 계정에 걸쳐 분산될 수 있습니다.
• 특정 날짜에 동일 워크플로의 액션 테이블이 CU00, CU01, CU02 등 여러 CU에 존재할 수 있습니다.

각 스토리지 계정은 자체 날짜 스탬프가 붙은 액션 테이블을 생성합니다. 예:

{WFIdentifier}20250114T000000Zactions

예시: 분산 작업

ScaleUnit = CU00인 워크플로에서는 실행이 서로 다른 컴퓨트 유닛(CU)에서 수행될 수 있습니다:

Workflow: MyWorkflow (ScaleUnit = CU00)

Run 1 → RunId‑CU00 → actions stored in Storage Account CU00
Run 2 → RunId‑CU01 → actions stored in Storage Account CU01
Run 3 → RunId‑CU02 → actions stored in Storage Account CU02

따라서 워크플로 정의가 CU00에 존재하더라도, 액션 데이터는 프로비저닝된 모든 컴퓨트 유닛에 걸쳐 분산될 수 있어 스토리지 I/O의 진정한 수평 확장이 가능합니다.

Metadata (flows, runs, histories) → CU00 storage

Runs

Example (January 14 2025)

이 날짜에 워크플로는 세 개의 서로 다른 스토리지 계정에 작업 테이블을 가질 수 있습니다:

• CU00: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU01: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU02: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions

이것이 의미하는 바

• App‑level metadata stays centralized – Base tables remain in CU00 (the master).
• Workflow metadata has a home – flows, runs, and histories live in the workflow’s assigned CU.
• Actions are truly distributed – Action data spreads across CUs based on the run execution.
• Query complexity increases – To retrieve all actions for a date range, you may need to query multiple storage accounts.

왜 이것이 중요한가

대용량 워크플로우의 경우

Logic App이 하루에 수천 번 실행되고 각 실행마다 수십 개의 작업을 수행한다면, CU 분산이 없을 경우:

• 단일 스토리지 계정이 병목 현상이 된다.
• 테이블 파티션 제한으로 인해 성능이 제한될 수 있다.
• 테이블이 커짐에 따라 쿼리 지연 시간이 증가한다.

CU 분산을 적용하면:

• 쓰기 작업이 여러 엔드포인트에 분산된다.
• 각 스토리지 계정이 전체 부하의 일부만 처리한다.
• 쿼리를 해당 스토리지 계정으로 직접 라우팅할 수 있다.

실행 기록 조회의 경우

실행 기록을 조회하는 도구(예: 내보내기 유틸리티 또는 모니터링 대시보드)를 구축할 때는 CU 라우팅을 고려해야 한다:

1. Run ID를 파싱하여 CU 접미사를 추출한다.
2. 해당 CU에 맞는 올바른 스토리지 계정을 확인한다.
3. CU‑전용 스토리지를 조회하여 작업 데이터를 가져온다.

CU 라우팅을 무시하면 작업 데이터가 누락될 수 있다.

스케일 유닛 구성

다중 스토리지 계정을 사용하려면 host.json에 다음을 추가하십시오:

{
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.ScaleUnitsCount": 4
      }
    }
  }
}

이 설정은 Logic Apps가 네 개의 스토리지 계정(CU00‑CU03)을 사용하도록 지정합니다. 추가 스토리지 계정을 프로비저닝하고 해당 연결 문자열 또는 관리형 ID 액세스를 구성해야 합니다.

인증 옵션

• 앱 설정에 있는 연결 문자열.
• 관리형 ID (프로덕션에 권장).

요약

• **Compute Units (CUs)**는 Logic Apps Standard가 스토리지를 수평으로 확장하도록 합니다.
• CU00은 애플리케이션 수준 기본 테이블을 보관하는 마스터 유닛입니다.
• Workflow tables (flows, runs, histories)는 ScaleUnit 필드가 가리키는 CU에 존재합니다.
• Action tables는 RunId‑CUXX 접미사를 사용해 실행당 샤딩됩니다.
• 하나의 워크플로우 액션은 여러 스토리지 계정에 걸쳐 있을 수 있습니다.
• host.json에서 Runtime.ScaleUnitsCount를 사용해 CU 수를 구성합니다(최대 32).
• Threshold guidance: 스토리지 계정당 분당 약 100 K 액션 실행.

이 아키텍처를 이해하는 것은 다음 상황에서 필수적입니다:

• Logic Apps 주변 도구를 구축할 때.
• 실행 기록을 프로그래밍 방식으로 조회할 때.
• 대량 워크플로우 성능 문제를 해결할 때.

References

• Scaling Logic App Standard for high‑throughput scenarios – Microsoft Tech Community

이 기사는 “Inside Logic Apps Standard” 시리즈의 일부로, Azure Logic Apps Standard 아키텍처의 내부를 탐구합니다.