연합학습/구축 방안

연합학습을 위한 모델 등록 및 배포 관리 시스템 구축 방안

FedTensor 2025. 11. 6. 15:40

1. 개요

1.1. 시스템 정의

본 문서는 연합학습(Federated Learning, FL) 환경에서 사용되는 머신러닝 모델의 생명주기를 관리, 추적, 배포하기 위한 시스템 구축 방안을 제안합니다.

1.2. 시스템의 필요성

기존의 중앙화된 MLOps는 학습된 단일 모델을 서비스 엔드포인트에 배포하는 데 중점을 둡니다. 하지만 연합학습은 다음과 같은 고유한 특징을 가집니다.

  • 분산된 학습: 모델 학습이 다수의 분산된 클라이언트(Edge device, 모바일 등)에서 발생합니다.
  • 지속적인 순환: '배포 → 로컬 학습 → 업데이트 수집 → 집계 → 재배포'의 순환이 핵심 프로세스입니다.
  • 모델의 다양성: '글로벌 모델(Global Model)', '로컬 모델(Local Model)', '초기 모델' 등 다양한 버전의 모델이 존재합니다.

따라서 연합학습의 성공적인 운영을 위해서는 이 분산된 순환 구조를 안정적으로 관리하고, 각 라운드별 글로벌 모델의 버전과 성능을 체계적으로 등록 및 추적하는 전용 시스템이 필수적입니다.

2. 시스템 아키텍처 (System Architecture)

제안하는 시스템은 크게 4가지 주요 구성 요소로 이루어집니다.

  • FL 코디네이터 (FL Coordinator / Server):
    • 전체 연합학습 프로세스(FL Round)를 오케스트레이션한다.
    • 모델 레지스트리에서 '현재 배포할 글로벌 모델'을 가져와 클라이언트에 전송(배포)한다.
    • 클라이언트로부터 모델 업데이트(가중치, 그래디언트 등)를 수신하고 집계(Aggregation)한다.
    • 집계된 새 글로벌 모델을 평가하고, 기준 충족 시 모델 레지스트리에 '새 버전'으로 등록한다.
  • 모델 레지스트리 (Model Registry):
    • 모든 버전의 글로벌 모델을 저장하는 중앙 저장소.
    • 모델의 버전 관리, 메타데이터(학습 라운드, 성능 지표 등) 저장, 배포 상태(Staging, Production) 관리를 담당한다.
  • 클라이언트 배포 에이전트 (Client Deployment Agent):
    • 각 클라이언트/엣지 노드에 설치되는 경량 에이전트.
    • 코디네이터의 요청을 받아 새 글로벌 모델을 다운로드(배포)한다.
    • 로컬 학습을 트리거하고, 완료된 모델 업데이트를 코디네이터로 안전하게 전송한다.
  • 모니터링 대시보드 (Monitoring Dashboard):
    • FL 라운드별 글로벌 모델의 성능 변화를 시각화한다.
    • 참여 클라이언트의 상태(온라인, 오프라인, 학습 중, 오류)를 모니터링한다.

3. 핵심 구성 요소 상세

3.1. 모델 레지스트리 (Model Registry)

모델 레지스트리는 단순한 파일 저장이 아닌, 모델의 '계보(Lineage)'를 관리하는 핵심 요소입니다.

  • 주요 기능:
    • 버전 관리: global_model_v1.0, global_model_v1.1 등 라운드별 모델 버전을 관리.
    • 메타데이터 관리: 각 모델 버전에 대해 다음 정보를 저장.
      • model_id: 고유 식별자
      • version: 버전 (e.g., 1.1)
      • fl_round: 이 모델이 생성된 연합학습 라운드 번호
      • base_model_version: 이 모델을 생성하는 데 기반이 된 이전 라운드 모델 버전
      • aggregation_strategy: 집계 전략 (e.g., FedAvg, FedProx)
      • evaluation_metrics: 평가 결과 (e.g., {accuracy: 0.85, loss: 0.23})
      • status: 배포 상태 (e.g., VALIDATING, PRODUCTION, DEPRECATED)
    • 모델 아티팩트 저장: 실제 모델 파일(e.g., .h5, .pth, SavedModel)을 S3, GCS 등 Blob 스토리지에 저장하고 레지스트리는 해당 경로를 참조.

3.2. FL 코디네이터 (FL Coordinator)

코디네이터는 모델의 '배포'와 '등록'을 실행하는 주체입니다.

  • 주요 기능:
    • 배포(Deployment): 모델 레지스트리에서 status=PRODUCTION인 최신 글로벌 모델을 조회하여, 학습에 참여할 클라이언트 그룹에게 전송.
    • 집계(Aggregation): 클라이언트로부터 수신한 로컬 업데이트를 집계 알고리즘(e.g., FedAvg)을 사용해 새로운 글로벌 모델 파라미터를 생성.
    • 등록(Registration): 생성된 새 글로벌 모델을 평가(중앙 테스트 데이터셋 활용) 후, 성능 향상 및 안정성 기준을 통과하면 해당 모델을 '새 버전'으로 모델 레지스트리에 등록 요청.

4. 모델 등록 및 배포 프로세스 (Process Flow)

연합학습 환경에서의 '배포'는 모델이 클라이언트로 전송되어 '학습'을 시작하는 것을 의미합니다.

  1. (Round 0) 초기 모델 등록 (Initial Registration)
    • 데이터 사이언티스트가 초기 모델(v0.1)을 설계하고 모델 레지스트리에 '최초 버전'으로 등록한다.
    • 코디네이터가 이 모델을 PRODUCTION 상태로 승인한다.
  2. (Round 1) 배포 (Deployment)
    • 코디네이터가 모델 레지스트리에서 최신 PRODUCTION 모델(v0.1)을 가져온다.
    • 선정된 클라이언트 그룹(e.g., 100개)에 클라이언트 에이전트를 통해 모델(v0.1)을 '배포'한다.
  3. (Round 1) 로컬 학습 및 업데이트 (Local Training & Update)
    • 각 클라이언트는 배포받은 모델(v0.1)을 기반으로 로컬 데이터를 사용해 학습을 수행한다.
    • 학습 완료 후, 로컬 모델 업데이트(가중치 차이 값 등)를 코디네이터로 전송한다.
  4. (Round 1) 집계 및 신규 등록 (Aggregation & New Registration)
    • 코디네이터는 수신된 업데이트(e.g., 80개 성공)를 집계하여 새로운 글로벌 모델(v0.2)을 생성한다.
    • v0.2 모델을 중앙 테스트 데이터로 평가한다.
    • 성능이 v0.1보다 향상되었으면, v0.2를 메타데이터(FL 라운드: 1, 기반 모델: v0.1)와 함께 모델 레지스트리에 등록한다.
  5. (Round 2) 재배포 (Redeployment)
    • 관리자가 v0.2 모델을 검증하고 PRODUCTION 상태로 승인한다.코디네이터가 다음 라운드를 위해 v0.2 모델을 새로운 클라이언트 그룹에 '배포'한다.이 과정이 목표 성능에 도달할 때까지 반복된다.

5. 주요 기술 고려사항

  • 보안 및 프라이버시 (Security & Privacy)
    • 전송 보안: 클라이언트와 코디네이터 간의 모든 모델/업데이트 전송은 TLS/SSL 암호화 통신을 사용해야 한다.
    • 업데이트 보안: 서버가 개별 업데이트를 볼 수 없도록 Secure Aggregation(SMPC) 또는 Differential Privacy(차분 프라이버시) 적용을 고려해야 한다. 이는 모델 레지스트리 메타데이터에 'privacy_level' 등으로 기록되어야 한다.
  • 클라이언트 이질성 (Client Heterogeneity)
    • 시스템 이질성: 클라이언트의 하드웨어 사양이 다를 수 있다. 모델은 경량화되어야 하며, 클라이언트 에이전트는 다양한 환경(Android, iOS, Linux)을 지원해야 한다.
    • 데이터 이질성 (Non-IID): 클라이언트별 데이터 분포가 다를 수 있다. 이는 모델 성능에 영향을 주므로, 집계 전략(e.g., FedProx) 선택 및 모니터링이 필요하다.
  • 통신 효율성 (Communication Efficiency)
    • 모델 파라미터 전송은 네트워크 대역폭을 많이 사용한다. 모델 양자화(Quantization), 희소화(Sparsification) 등을 통해 전송되는 모델 업데이트의 크기를 줄이는 전략이 필요하다.
  • 내결함성 및 확장성 (Fault Tolerance & Scalability)
    • 수천, 수만 개의 클라이언트 중 일부는 네트워크 문제나 배터리 부족으로 중도 탈락할 수 있다. 코디네이터는 정해진 시간 내에 응답한 클라이언트의 업데이트만으로도 집계를 수행할 수 있어야 한다(Fault Tolerance).
    • 시스템은 대규모 클라이언트의 동시 접속 및 업데이트 전송을 처리할 수 있어야 한다(Scalability).

6. 추천 기술 스택

  • FL 프레임워크: Flower (유연성 높음), TensorFlow Federated (TFF), PySyft (프라이버시)
  • 모델 레지스트리: MLflow Model Registry (범용 MLOps 도구로 강력함), KubeFlow Pipelines (KFP) 연동, 또는 PostgreSQL/MySQL + S3/GCS 기반의 커스텀 구축
  • 코디네이터/인프라: Kubernetes (FL 서버 확장성), gRPC (클라이언트-서버 통신), RabbitMQ/Kafka (업데이트 메시지 큐)
  • 모니터링: Prometheus (메트릭 수집), Grafana (시각화)

7. 결론

연합학습을 위한 모델 등록 및 배포 관리 시스템은 단순한 모델 '저장소'가 아니라, 분산된 학습의 '전체 사이클'을 지휘하고 추적하는 MLOps의 핵심 허브입니다.

 

본 제안 방안을 기반으로 시스템을 구축함으로써, 연합학습 모델의 개발부터 배포, 개선에 이르는 전 과정을 안정적이고 투명하며 확장 가능하게 관리할 수 있을 것입니다.