교차 사일로 및 교차 기기를 지원하는 Google Cloud 제휴 학습

Last reviewed 2024-04-12 UTC

이 문서에서는 Google Cloud에서 제휴 학습 플랫폼 구축을 도와주는 두 가지 참조 아키텍처에 대해 설명합니다. 이 문서에 설명된 참조 아키텍처와 관련 리소스는 다음을 지원합니다.

• 교차 사일로 제휴 학습
• 교차 사일로 아키텍처를 기반으로 하는 교차 기기 제휴 학습

이 문서는 Google Cloud에서 제휴 학습 사용 사례를 구현하려는 클라우드 설계자와 AI 및 ML 엔지니어를 대상으로 합니다. 또한 Google Cloud에서 제휴 학습 구현 여부를 평가 중인 의사 결정권자를 대상으로 합니다.

아키텍처

이 섹션의 다이어그램은 제휴 학습을 위한 교차 사일로 아키텍처와 교차 기기 아키텍처를 보여줍니다.

교차 사일로 아키텍처

다음 다이어그램은 교차 사일로 제휴 학습을 지원하는 아키텍처를 보여줍니다.

위 아키텍처에는 다음 구성요소가 포함됩니다.

• Virtual Private Cloud(VPC) 네트워크와 서브넷
• 다음을 수행할 수 있게 도와주는 비공개 GKE 클러스터
  • 인터넷에서 클러스터 노드를 격리합니다.
  • 승인된 네트워크에서 비공개 GKE 클러스터를 만들어 클러스터 노드와 제어 영역이 인터넷에 노출되지 않도록 제한합니다.
  • 강화된 운영체제 이미지를 사용하는 보호되는 클러스터 노드를 사용합니다.
  • 최적화된 Kubernetes 네트워킹을 위해 Dataplane V2를 사용 설정합니다.
  • 애플리케이션 레이어에서 보안 비밀을 암호화합니다.
• 전용 GKE 노드 풀: 테넌트 앱 및 리소스를 배타적으로 호스팅하기 위한 전용 노드 풀을 만듭니다. 노드에는 테넌트 워크로드만 테넌트 노드에 예약되도록 보장하는 특성이 있습니다. 다른 클러스터 리소스는 기본 노드 풀에 호스팅됩니다.
• 다음을 적용하는 VPC 방화벽 규칙:
  • 클러스터의 모든 노드에 적용되는 기준 규칙
  • 테넌트 노드 풀에 있는 노드에만 적용되는 추가 규칙. 이러한 방화벽 규칙은 테넌트 노드에 대한 인그레스 및 이그레스를 제한합니다.
• 인터넷 이그레스를 허용하는 Cloud NAT
• 클러스터 내 앱이 인터넷으로 이동하지 않고 Google API에 액세스할 수 있도록 비공개 Google 액세스를 사용 설정하기 위한 Cloud DNS 레코드
• 다음과 같은 서비스 계정:
  • 테넌트 노드 풀에 있는 노드의 전용 서비스 계정
  • 워크로드 아이덴티티 제휴를 사용하기 위한 테넌트 앱의 전용 서비스 계정
• Kubernetes 역할 기반 액세스 제어(RBAC)를 위한 Google 그룹스 사용 지원
• 구성 정보를 저장하기 위한 Cloud 소스 저장소
• 컨테이너 이미지를 저장하기 위한 Artifact Registry 저장소

교차 기기 아키텍처

다음은 교차 기기 제휴 학습을 지원하는 아키텍처를 보여줍니다.

위의 교차 기기 아키텍처는 교차 사일로 아키텍처를 기반으로 구축되며 다음과 같은 구성요소가 추가됩니다.

• 서버에 대한 기기 연결을 시뮬레이션하는 Cloud Run 서비스
• 서버 및 클라이언트 실행을 위해 비공개 인증서를 만드는 Certificate Authority Service
• 학습 결과를 시각화하는 Vertex AI 텐서보드
• 통합 모델을 저장하는 Cloud Storage 버킷
• 사용 중 데이터 보호를 돕기 위해 기밀 노드를 기본 풀로 사용하는 비공개 GKE 클러스터

교차 기기 아키텍처에는 오픈소스 제휴 컴퓨팅 플랫폼(FCP) 프로젝트의 구성요소가 사용됩니다. 이 프로젝트에는 다음이 포함됩니다.

• 서버와 통신하고 기기에서 태스크를 수행하기 위한 클라이언트 코드
• 클라이언트-서버 통신을 위한 프로토콜
• 제휴 계산을 쉽게 정의할 수 있도록 TensorFlow가 제휴된 연결 지점

앞의 다이어그램에 표시된 FCP 구성요소는 마이크로서비스 집합으로 배포될 수 있습니다. 이러한 구성요소는 다음을 수행합니다.

• 애그리게이터: 이 작업은 기기 업데이트 정보를 읽고 개인 정보 차등 보호에 따라 집계된 결과를 계산합니다.
• 수집기: 이 작업은 활성 태스크 및 암호화된 기기 업데이트 정보를 쿼리하기 위해 주기적으로 수행됩니다. 이 정보에 따라 집계를 시작할 시간이 결정합니다.
• 모델 업로더: 이 작업은 이벤트를 수신 대기하고 결과를 게시하여 기기가 업데이트된 모델을 다운로드할 수 있게 해줍니다.
• 태스크 할당: 이 프런트엔드 서비스는 학습 태스크를 여러 기기에 배포합니다.
• 태스크 관리: 이 작업은 태스크를 관리합니다.
• 태스크 스케줄러: 이 작업은 주기적으로 실행되거나 특정 이벤트에 따라 트리거됩니다.

사용 제품

두 가지 제휴 학습 사용 사례의 참조 아키텍처에는 다음과 같은 Google Cloud 구성요소가 사용됩니다.

• Google Cloud Kubernetes Engine(GKE): GKE는 제휴 학습을 위한 기초 플랫폼을 제공합니다.
• TensorFlow Federated(TFF): TFF는 탈중앙화된 데이터에 대한 머신러닝 및 기타 학습을 위한 오픈소스 프레임워크를 제공합니다.

또한 GKE는 제휴 학습 플랫폼에 다음과 같은 기능을 제공합니다.

• 제휴 학습 조정자 호스트: 제휴 학습 조정자는 제휴 학습 프로세스를 관리합니다. 이러한 관리에는 참가자들에게 전역 모델을 배포하고, 참가자들의 업데이트를 집계하고, 전역 모델을 업데이트하는 등의 태스크가 포함됩니다. GKE를 사용하면 가용성 및 확장성이 뛰어난 방식으로 제휴 학습 조정자를 호스팅할 수 있습니다.
• 제휴 학습 참가자 호스팅: 제휴 학습 참가자는 자신의 로컬 데이터로 전역 모델 학습을 수행합니다. GKE를 사용하여 안전하고 격리된 방식으로 제휴 학습 참가자를 호스팅할 수 있습니다. 이 방식은 참가자 데이터가 로컬로 유지될 수 있게 보장하는 데 도움이 됩니다.
• 안전하고 확장 가능한 통신 채널 제공: 제휴 학습 참가자는 제휴 학습 조정자와 안전하고 확장 가능한 방식으로 통신할 수 있어야 합니다. GKE를 사용하여 참가자와 조정자 사이에 안전하고 확장 가능한 통신 채널을 제공할 수 있습니다.
• 제휴 학습 배포 수명 주기 관리: GKE를 사용하여 제휴 학습 배포의 수명 주기를 관리할 수 있습니다. 이러한 관리에는 리소스를 프로비저닝하고, 제휴 학습 플랫폼을 배포하고, 제휴 학습 플랫폼의 성능을 모니터링하는 등의 태스크가 포함됩니다.

이러한 장점 외에도 GKE는 또한 다음과 같이 제휴 학습 배포에 유용할 수 있는 여러 기능을 제공합니다.

• 리전 클러스터: GKE를 사용해서 리전 클러스터를 만들고 참가자와 조정자 사이의 지연 시간을 줄여서 제휴 학습 배포 성능을 향상시킬 수 있습니다.
• 네트워크 정책: GKE를 사용해서 네트워크 정책을 만들고 참가자와 조정자 사이의 트래픽 흐름을 제어하여 제휴 학습 배포의 보안을 향상시킬 수 있습니다.
• 부하 분산: GKE는 여러 부하 분산 옵션을 제공하여 참가자와 조정자 사이에 트래픽을 분산하여 제휴 학습 배포의 확장성을 향상시켜 줍니다.

TFF는 제휴 학습 사용 사례를 쉽게 구현할 수 있도록 다음과 같은 기능을 제공합니다.

• 서버 및 클라이언트 집합에서 실행되는 처리 단계 집합인 제휴 계산을 선언적으로 표현할 수 있습니다. 이러한 계산은 다양한 런타임 환경에 배포될 수 있습니다.
• TFF 오픈소스를 사용하여 커스텀 애그리게이터를 빌드할 수 있습니다.
• 다음 알고리즘을 포함하여 다양한 제휴 학습 알고리즘을 지원합니다.
  • 제휴 평균: 참가 클라이언트의 모델 매개변수 평균을 계산하는 단순 알고리즘입니다. 데이터가 비교적 동질적이고 모델이 너무 복잡하지 않은 사용 사례에 특히 적합합니다. 일반적인 사용 사례는 다음과 같습니다.
    • 맞춤설정된 추천: 한 회사가 제휴 평균을 이용해서 사용자의 구매 내역을 기반으로 제품을 추천하는 모델을 학습시킬 수 있습니다.
    • 사기 감지: 한 은행 연합이 제휴 평균을 이용해서 사기 거래를 감지하는 모델을 학습시킬 수 있습니다.
    • 의학 진단: 한 병원 그룹이 제휴 평균을 이용해서 암 진단 모델을 학습시킬 수 있습니다.
  • 제휴 확률적 경사하강법(FedSGD): 확률적 경사하강법을 이용해서 모델 매개변수를 업데이트하는 알고리즘입니다. 데이터가 이질적이고 모델이 복잡한 사용 사례에 적합합니다. 일반적인 사용 사례는 다음과 같습니다.
    • 자연어 처리: 한 회사가 FedSGD를 이용해서 음성 인식 정확도를 향상시켜 주는 모델을 학습시킬 수 있습니다.
    • 이미지 인식: 한 회사가 FedSGD를 이용해서 이미지 속 물체를 식별할 수 있는 모델을 학습시킬 수 있습니다.
    • 예측 유지보수: 한 회사가 FedSGD를 이용해서 머신 오류가 발생 가능한 시간을 예측하는 모델을 학습시킬 수 있습니다.
  • 제휴 Adam: Adam 옵티마이저를 이용해서 모델 매개변수를 업데이트하는 알고리즘입니다. 일반적인 사용 사례는 다음과 같습니다.
    • 추천자 시스템: 한 회사가 제휴 Adam을 이용해서 구매 내역에 따라 사용자에게 제품을 추천하는 모델을 학습시킬 수 있습니다.
    • 순위 결정: 한 회사가 제휴 Adam을 이용해서 검색 결과 순위를 지정하는 모델을 학습시킬 수 있습니다.
    • 클릭률 예측: 한 회사가 제휴 Adam을 이용해서 사용자의 광고 클릭 가능성을 예측하는 모델을 학습시킬 수 있습니다.

사용 사례

이 섹션에서는 제휴 학습 플랫폼에 적합한 교차 사일로 및 교차 기기 아키텍처 옵션의 사용 사례에 대해 설명합니다.

제휴 학습은 많은 클라이언트가 모델 학습을 공동으로 수행하는 머신러닝 설정입니다. 이 프로세스는 중앙 조정자에 의해 주도되며 학습 데이터는 탈중앙화 상태로 유지됩니다.

제휴 학습 패러다임에서 클라이언트는 전역 모델을 다운로드하고 자신의 데이터로 로컬 학습을 수행하여 모델을 향상시킵니다. 그런 후 각 클라이언트가 계산된 모델 업데이트 정보를 중앙 서버로 다시 전송하면 여기에서 모델 업데이트가 집계되고 전역 모델에 대한 새로운 반복 작업이 생성됩니다. 이러한 참조 아키텍처에서 모델 학습 워크로드는 GKE에서 실행됩니다.

제휴 학습은 데이터 수집 최소화 원칙에 따라 각 단계에서 수집되는 데이터를 제한하고, 데이터 액세스를 제한하고, 처리된 데이터는 가능한 한 빠르게 폐기하는 등의 방식으로 개인 정보 보호를 실현합니다. 또한 제휴 학습의 문제 설정은 최종 모델이 개별 사용자 데이터를 기억할 수 없도록 모델 익명화를 향상시키기 위해 개인 정보 차등 보호(DP)를 사용하는 등의 추가적인 개인 정보 보호 기법들과 호환됩니다.

사용 사례에 따라 제휴 학습을 사용하는 학습 모델은 다음과 같은 추가 이점을 얻을 수 있습니다.

• 규정 준수: 일부 경우에는 규제에 따라 데이터 사용 또는 공유 방법이 제한될 수 있습니다. 제휴 학습을 이용하면 이러한 규정을 준수할 수 있습니다.
• 통신 효율성: 일부 경우에는 데이터를 중앙화하는 것보다 분산 데이터로 모델 학습을 수행하는 것이 더 효율적입니다. 예를 들어 모델 학습을 수행할 데이터베이스가 중앙으로 이동하기에 너무 클 수 있습니다.
• 데이터 액세스 지원: 제휴 학습을 사용하면 조직이 개인 또는 조직별 데이터 사일로에 학습 데이터를 탈중앙화된 상태로 유지할 수 있습니다.
• 모델 정확도 향상: 프록시 데이터라고도 부르는 조합된 데이터 대신 실제 사용자 데이터를 기반으로 학습을 수행하고 그러면서도 개인 정보 보호를 보장하기 때문에 모델 정확도가 향상되는 경우가 많습니다.

제휴 학습은 데이터의 출처 그리고 로컬 계산이 수행되는 위치에 따라 여러 종류가 있습니다. 이 문서에서 설명하는 아키텍처는 교차 사일로와 교차 기기의 두 가지 유형의 제휴 학습에 중점을 둡니다. 다른 유형의 제휴 학습은 이 문서의 범위를 벗어납니다.

제휴 학습은 또한 데이터 세트 분할 방식에 따라 다음과 같이 분류됩니다.

• 수평적 제휴 학습(HFL): 데이터 세트에서 특성(열)이 동일하지만 샘플(행)이 서로 다른 경우입니다. 예를 들어 여러 병원이 동일한 의학적 매개변수에 따라 환자 레코드를 수집하더라도 환자 집단은 서로 다를 수 있습니다.
• 수직적 제휴 학습(VFL): 데이터 세트에서 샘플(행)이 동일하지만 특성(열)이 서로 다른 경우입니다. 한 은행과 다른 전자상거래 회사의 고객 데이터에 개별 사용자가 중복될 수 있지만 이 둘은 재무 및 구매 정보가 다릅니다.
• 제휴 전이 학습(FTL): 데이터 세트에서 샘플과 특성이 부분적으로 겹치는 경우입니다. 예를 들어 두 병원의 환자 레코드에 개별 사용자가 일부 겹치고 의학적 매개변수가 몇 가지 공유될 수 있더라도 각 데이터 세트의 특성은 고유합니다.

교차 사일로 제휴 계산에는 여러 조직 또는 회사가 구성원으로 참여합니다. 실제로 구성원 수는 100개 이내 정도로 일반적으로 작습니다. 교차 사일로 계산은 일반적으로 참여 조직의 데이터 세트가 서로 다르지만 공유 모델 학습이 필요하거나 서로 간의 원시 데이터 공유 없이 집계된 결과 분석이 필요한 시나리오에서 사용됩니다. 서로 다른 참여 조직에 속하는 워크로드를 격리시키기 위해 교차 사일로 참조 아키텍처는 전용 네임스페이스 및 GKE 노드 풀과 같은 보안 제어를 구현합니다. 교차 네임스페이스 통신과 클러스터 인바운드 및 아웃바운드 트래픽은 이 설정을 명시적으로 재정의하지 않는 한 기본적으로 숨겨져 있습니다.

교차 사일로 제휴 학습의 예시 사용 사례는 다음과 같습니다.

• 사기 감지: 제휴 학습을 이용해서 여러 조직에 분산된 데이터로 사기 감지 모델 학습을 수행할 수 있습니다. 예를 들어 한 은행 연합이 제휴 학습을 이용해서 사기 거래를 감지하는 모델 학습을 수행할 수 있습니다.
• 의학적 진단: 제휴 학습을 이용해서 여러 병원에 분산된 데이터를 기반으로 의료 진단 모델 학습을 수행할 수 있습니다. 예를 들어 일련의 병원들이 제휴 학습을 이용해서 암 진단 모델 학습을 수행할 수 있습니다.

교차 기가 제휴 학습은 휴대폰, 차량, IoT 기기와 같은 최종 사용자 기기가 참여하는 제휴 계산의 일종입니다. 구성원 수는 수 백만 또는 수 천만에 이를 수 있습니다.

교차 기기 제휴 학습의 과정은 교차 사일로 제휴 학습과 비슷합니다. 하지만 수 천에서 수 백만에 이르는 기기를 다룰 때 고려해야 하는 몇 가지 추가 요소를 수용할 수 있도록 참조 아키텍처를 조정해야 합니다. 교차 기기 제휴 학습 사용 사례에서 발생하는 시나리오에 맞게 관리 워크로드를 배포해야 합니다. 예를 들어 학습 라운드에 참여할 클라이언트의 하위 집합 조정이 필요합니다. 교차 기기 아키텍처는 FCP 서비스 배포를 지원하여 이러한 기능을 제공합니다. 이러한 서비스에는 TFF와 상호 작용하는 워크로드가 포함됩니다. TFF는 이러한 조정을 관리하는 코드를 작성하기 위해 사용됩니다.

교차 기기 제휴 학습의 예시 사용 사례는 다음과 같습니다.

• 맞춤설정된 추천: 교차 기기 제휴 학습을 이용하면 여러 기기에 분산된 데이터를 기반으로 맞춤설정된 추천 모델 학습을 수행할 수 있습니다. 예를 들어 한 회사는 제휴 학습을 이용해서 구매 내역을 기반으로 사용자에게 제품을 추천하는 모델 학습을 수행할 수 있습니다.
• 자연어 처리: 제휴 학습을 이용해서 여러 기기에 분산된 데이터에 따라 자연어 처리 모델 학습을 수행할 수 있습니다. 예를 들어 한 회사가 제휴 학습을 이용해서 음성 인식 정확도를 향상시키는 모델 학습을 수행할 수 있습니다.
• 차량 유지보수 요구 예측: 제휴 학습을 이용해서 차량에 유지보수가 필요한 시기를 예측하는 모델 학습을 수행할 수 있습니다. 이러한 모델 학습은 여러 차량에서 수집된 데이터를 기반으로 수행될 수 있습니다. 이렇게 하면 개별 차량의 개인 정보 보호를 훼손하지 않으면서 모든 차량의 경험으로부터 모델 학습을 수행할 수 있습니다.

다음 표에서는 교차 사일로 및 교차 기기 아키텍처의 특성을 요약해서 보여주고 사용 사례에 적용 가능한 제휴 학습 시나리오 유형을 구분하는 방법을 보여줍니다.

특성	교차 사일로 제휴 계산	교차 기기 제휴 계산
모집단 크기	일반적으로 작음(예를 들어 기기 수 100개 미만)	수천, 수백만, 수천만까지 기기 수 확장 가능
참여 구성원	조직 또는 회사	휴대기기, 에지 기기, 차량
가장 일반적인 데이터 분할	HFL, VFL, FTL	HFL
데이터 민감도	참가자가 서로 원시 형식으로 공유하길 원하지 않는 민감한 정보	너무 민감해서 중앙 서버와 고유할 수 없는 데이터
데이터 가용성	참가자가 거의 항상 참여 가능	특정 시점에서 일부 참가자만 참여 가능
사용 사례 예시	사기 감지, 의학 진단, 재무 예측	피트니스 추적, 음성 인식, 이미지 분류

설계 고려사항

이 섹션에서는 이러한 참조 아키텍처를 이용해서 보안, 신뢰성, 운영 효율성, 비용, 성능 측면에서 특정 요구사항을 충족하는 하나 이상의 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다.

교차 사일로 아키텍처 설계 고려사항

Google Cloud에서 교차 사일로 제휴 학습 아키텍처를 구현하기 위해서는 다음 섹션에서 자세히 설명하는 최소 기본 요건을 구현해야 합니다.

1. 제휴 학습 컨소시엄 설정
2. 제휴 학습 컨소시엄에서 구현할 공동작업 모델 결정
3. 참여 조직의 책임 결정.

이러한 기본 요건 외에도 제휴 소유자가 이 문서의 범위를 벗어나서 수행해야 하는 다음과 같은 다른 작업이 있습니다.

• 제휴 학습 컨소시엄 관리
• 공동작업 모델 설계 및 구현
• 모델 학습 데이터와 제휴 소유자가 학습시키려는 모델의 준비, 관리, 운영
• 제휴 학습 워크플로 만들기, 컨테이너화, 조정
• 제휴 학습 워크로드 배포 및 관리
• 참여자 조직이 데이터를 안전하게 전송할 수 있는 통신 채널 설정

제휴 학습 컨소시엄 설정

제휴 학습 컨소시엄은 교차 사일로 제휴 학습 노력에 참여하는 조직의 그룹입니다. 컨소시엄의 조직은 ML 모델의 매개변수만 공유하며 이러한 매개변수를 암호화하여 개인 정보 보호를 강화할 수 있습니다. 제휴 학습 컨소시엄에서 허용되는 경우 조직이 개인 식별 정보(PII)가 포함되지 않은 데이터를 집계할 수도 있습니다.

제휴 학습 컨소시엄의 공동작업 모델 결정

제휴 학습 컨소시엄에서는 다음과 같은 다양한 공동작업 모델을 구현할 수 있습니다.

• 제휴 소유자 또는조정자라고도 하는 단일 조정 조직으로 구성된 중앙 집중식 모델 및 참여자 조직 또는 데이터 소유자 집합
• 그룹으로 조정하는 조직으로 구성된 분산 모델
• 모두 컨소시엄에 다른 리소스를 제공하는 서로 다른 참여 조직의 컨소시엄으로 구성된 이종 모델

이 문서에서는 공동작업 모델이 중앙화된 모델이라고 가정합니다.

참여자 조직의 책임 결정

제휴 학습 컨소시엄의 공동작업 모델을 선택한 후 제휴 소유자는 참여자 조직의 책임을 결정해야 합니다.

또한 제휴 소유자가 제휴 학습 컨소시엄의 빌드를 시작할 때 다음을 수행해야 합니다.

• 제휴 학습 작업 조정
• 전역 ML 모델과 ML 모델을 설계하고 구현하여 참여 조직과 공유
• ML 학습 프로세스의 반복 방법인 제휴 학습 단계 정의
• 특정 제휴 학습 단계에 참여하는 참여자 조직 선택. 이 선택 항목을 동질 집단이라고 합니다.
• 참여자 조직을 위한 컨소시엄 멤버십 확인 절차 설계 및 구현
• 전역 ML 모델과 ML 모델을 업데이트하여 참여자 조직과 공유
• 참여자 조직에 제휴 학습 컨소시엄이 개인 정보 보호, 보안, 규제 요구사항을 충족하는지 검증하는 도구 제공
• 참여자 조직에 안전하고 암호화된 통신 채널 제공
• 참여자 조직에 각 제휴 학습 단계를 완료하는 데 필요한 기밀이 아닌 집계 데이터 모두 제공

참여자 조직에는 다음과 같은 책임이 있습니다.

• 안전하고 격리된 환경(사일로) 제공. 사일로는 참여자 조직이 자체 데이터를 저장하고 ML 모델 학습이 구현되는 곳입니다.
• 자체 컴퓨팅 인프라와 자체 로컬 데이터를 사용하여 제휴 소유자가 제공한 모델 학습시키기
• PII를 삭제한 후 집계 데이터 형식으로 제휴 소유자와 모델 학습 결과 공유

제휴 소유자와 참여자 조직은 모델이 요구사항을 충족할 때까지 ML 모델 학습을 세분화합니다.

Google Cloud에서 제휴 학습 구현

제휴 학습 컨소시엄을 설정하고 제휴 학습 컨소시엄의 공동작업 방식을 결정한 후 참여자 조직에서 다음을 수행하는 것이 좋습니다.

1. 제휴 학습 컨소시엄에 필요한 인프라를 프로비저닝하고 구성합니다.
2. 공동작업 모델을 구현합니다.
3. 제휴 학습 작업을 시작합니다.

제휴 학습 컨소시엄의 인프라 프로비저닝 및 구성

제휴 학습 컨소시엄의 인프라를 프로비저닝하고 구성할 때 제휴 소유자가 제휴 ML 모델을 참여자 조직에 학습시키는 워크로드를 만들고 분산해야 합니다. 타사(제휴 소유자)에서 워크로드를 만들어 제공했기 때문에 참여자 조직이 해당 런타임 환경에 워크로드를 배포할 때는 주의가 필요합니다.

참여자 조직은 개별 보안 권장사항에 따라 환경을 구성하고 각 워크로드에 부여되는 범위와 권한을 제한하는 제어를 적용해야 합니다. 개별 보안 권장사항을 따르는 것 외에도 제휴 소유자와 참여 조직은 제휴 학습에만 해당하는 위협 벡터를 고려하는 것이 좋습니다.

공동작업 모델 구현

제휴 학습 컨소시엄 인프라가 준비되면 제휴 소유자가 참여자 조직이 서로 상호작용할 수 있는 메커니즘을 설계하고 구현합니다. 이 접근 방법은 제휴 소유자가 제휴 학습 컨소시엄을 위해 선택한 공동작업 모델을 따릅니다.

제휴 학습 작업 시작

제휴 모델을 구현한 후에는 제휴 소유자가 학습시킬 전역 ML 모델 및 참여자 조직과 공유할 ML 모델을 구현합니다. ML 모델이 준비되면 제휴 소유자가 제휴 학습 작업의 1단계를 시작합니다.

제휴 학습 작업의 각 단계가 진행되는 동안 제휴 소유자는 다음을 수행합니다.

1. 참여 조직과 공유할 ML 모델을 배포합니다.
2. 참여자 조직이 제휴 소유자가 공유한 ML 모델 학습 결과를 제공할 때까지 기다립니다.
3. 참여자 조직에서 생성한 학습 결과를 수집하고 처리합니다.
4. 참여 조직으로부터 적절한 학습 결과를 받으면 전역 ML 모델을 업데이트합니다.
5. 해당하는 경우 컨소시엄의 다른 구성원과 공유할 ML 모델을 업데이트합니다.
6. 제휴 학습의 다음 단계를 위한 학습 데이터를 준비합니다.
7. 제휴 학습의 다음 단계를 시작합니다.

보안, 개인정보 보호, 규정 준수

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 제휴 학습 플랫폼을 설계하고 빌드할 때 고려해야 할 요소들에 대해 설명합니다. 이 안내는 이 문서에서 설명하는 두 아키텍처에 모두 적용됩니다.

환경에 배포하는 제휴 학습 워크로드는 사용자, 사용자의 데이터, 제휴 학습 모델, 사용자 인프라를 비즈니스에 영향을 줄 수 있는 위협에 노출시킬 수 있습니다.

제휴 학습 환경의 보안을 강화하기 위해 이러한 참조 아키텍처는 사용자 환경의 인프라에 집중된 GKE 보안 제어를 구성합니다. 이러한 제어는 제휴 학습 워크로드 및 사용 사례와 관련된 위협으로부터 사용자를 보호하는 데 충분하지 않을 수 있습니다. 각 제휴 학습 워크로드 및 사용 사례의 특수성에 비춰볼 때 제휴 학습 구현을 보호하기 위한 보안 제어 수단은 이 문서의 범위를 벗어납니다. 이러한 위협들에 대한 자세한 정보와 예시는 제휴 학습 보안 고려사항을 참조하세요.

GKE 보안 제어

이 섹션에서는 GKE 클러스터 보호를 위해 이러한 아키텍처에 적용하는 제어 수단에 대해 설명합니다.

GKE 클러스터의 보안 강화

이러한 참조 아키텍처는 다음 보안 설정을 구현하는 GKE 클러스터를 만드는 데 도움이 됩니다.

• 승인된 네트워크에서 비공개 GKE 클러스터를 만들어 클러스터 노드와 제어 영역이 인터넷에 노출되지 않도록 제한합니다.
• containerd 런타임과 함께 강화 노드 이미지를 사용하는 보안 노드를 사용합니다.
• GKE Sandbox를 사용하여 테넌트 워크로드의 격리가 향상되었습니다.
• 애플리케이션 레이어에서 보안 비밀을 암호화합니다.

GKE 보안 설정에 대한 자세한 내용은 클러스터 보안 강화 및 보안 상황 대시보드 정보를 참조하세요.

VPC 방화벽 규칙

Virtual Private Cloud(VPC) 방화벽 규칙은 Compute Engine VM에서 송수신이 허용된 트래픽에 적용됩니다. 이 규칙을 사용하면 레이어 4 속성에 따라 VM 단위로 트래픽을 필터링할 수 있습니다.

기본 GKE 클러스터 방화벽 규칙을 사용하여 GKE 클러스터를 만듭니다. 이러한 방화벽 규칙은 클러스터 노드와 GKE 제어 영역 간, 클러스터의 노드와 포드 간의 통신을 가능하게 설정합니다.

테넌트 노드 풀의 노드에 추가 방화벽 규칙을 적용합니다. 이러한 방화벽 규칙은 테넌트 노드의 이그레스 트래픽을 제한합니다. 이 접근 방식은 테넌트 노드 격리를 늘릴 수 있습니다. 기본적으로 테넌트 노드의 모든 이그레스 트래픽은 거부됩니다. 필요한 모든 이그레스는 명시적으로 구성되어야 합니다. 예를 들어 테넌트 노드에서 GKE 제어 영역으로의 이그레스와 비공개 Google 액세스를 사용한 Google API로 이그레스를 허용하는 방화벽 규칙을 만듭니다. 이 방화벽 규칙은 테넌트 노드 풀에 대해 서비스 계정을 사용하는 테넌트 노드를 대상으로 합니다.

네임스페이스

네임스페이스를 사용하면 포드, 서비스, 복제 컨트롤러와 같은 클러스터 내의 관련 리소스에 대한 범위를 제공할 수 있습니다. 네임스페이스를 사용하면 관련 리소스에 대한 관리 책임을 하나의 단위로 위임할 수 있습니다. 따라서 네임스페이스는 대부분의 보안 패턴에 필수적입니다.

네임스페이스는 제어 영역 격리를 위한 중요한 기능입니다. 하지만 노드 격리, 데이터 영역 격리, 네트워크 격리는 제공하지 않습니다.

일반적인 방법은 개별 애플리케이션에 대해 네임스페이스를 만드는 것입니다. 예를 들어 애플리케이션의 UI 구성요소에 대해 myapp-frontend 네임스페이스를 만들 수 있습니다.

이러한 참조 아키텍처는 서드 파티 앱을 호스팅하는 전용 네임스페이스를 만들 수 있게 도와줍니다. 네임스페이스와 해당 리소스는 클러스터 내에서 테넌트로 취급됩니다. 네임스페이스에 정책 및 설정을 적용하여 네임스페이스의 리소스 범위를 제한합니다.

네트워크 정책

네트워크 정책은 포드 수준 방화벽 규칙을 사용하여 레이어 4 네트워크 트래픽 흐름을 적용합니다. 네트워크 정책의 범위는 네임스페이스로 지정됩니다.

이 문서에서 설명하는 참조 아키텍처에서는 서드 파티 앱을 호스팅하는 테넌트 네임스페이스에 네트워크 정책을 적용합니다. 기본적으로 네트워크 정책은 네임스페이스의 포드와 주고 받는 모든 트래픽을 거부합니다. 필요한 트래픽은 허용 목록에 명시적으로 추가해야 합니다. 예를 들어 이러한 참조 아키텍처의 네트워크 정책은 클러스터 내부 DNS 및 Anthos Service Mesh 제어 영역과 같은 필수 클러스터 서비스에 대한 트래픽을 명시적으로 허용합니다.

구성 동기화

구성 동기화는 Git 저장소에 저장된 구성과 GKE 클러스터를 동기화된 상태로 유지합니다. Git 저장소는 클러스터 구성 및 정책에 대한 단일 신뢰 소스로 작동합니다. 구성 동기화는 선언적입니다. 클러스터 상태를 지속적으로 확인하고 정책을 시행하기 위해 구성 파일에 선언된 상태를 적용합니다. 이는 구성 드리프트를 방지하는 데 도움이 됩니다.

GKE 클러스터에 구성 동기화를 설치합니다. 클러스터 구성과 Cloud 소스 저장소의 정책을 동기화하도록 구성 동기화를 구성합니다. 동기화된 리소스에는 다음이 포함됩니다.

• 클러스터 수준 Anthos Service Mesh 구성
• 클러스터 수준 보안 정책
• 네트워크 정책, 서비스 계정, RBAC 규칙, Anthos Service Mesh 구성을 포함한 테넌트 네임스페이스 수준 구성 및 정책

정책 컨트롤러

Google Kubernetes Engine(GKE) Enterprise 버전 정책 컨트롤러는 Open Policy Agent(OPA)에서 실행되는 고객 리소스 정의 기반(CRD-기반) 정책을 적용하는 Kubernetes용 동적 허용 컨트롤러입니다.

허용 컨트롤러는 요청이 승인되고 허용된 이후이나 객체가 유지되기 전에 Kubernetes API 서버로의 요청을 가로채는 Kubernetes 플러그인입니다. 허용 컨트롤러를 사용하여 클러스터 사용 방법을 제한할 수 있습니다.

GKE 클러스터에 정책 컨트롤러를 설치합니다. 이러한 참조 아키텍처에는 클러스터 보호에 도움이 되는 정책 예시가 포함되어 있습니다. 구성 동기화를 사용하여 클러스터에 정책을 자동으로 적용합니다. 다음 정책을 적용합니다.

• 포드 보안 강화에 도움이 되는 정책 선택. 예를 들어 포드가 권한이 있는 컨테이너를 실행하지 않도록 방지하고 읽기 전용 루트 파일 시스템을 필요로 하는 정책을 적용합니다.
• 정책 컨트롤러 템플릿 라이브러리의 정책 예를 들어 NodePort 유형의 서비스를 허용하지 않는 정책을 적용합니다.

Anthos Service Mesh

Anthos Service Mesh는 서비스 간 보안 통신 관리를 간소화하는 데 도움이 되는 서비스 메시입니다. 이러한 참조 아키텍처는 다음을 수행하도록 Anthos Service Mesh를 구성합니다.

• 사이드카 프록시 자동 삽입
• 메시의 서비스 간에 mTLS 통신을 적용합니다.
• 아웃바운드 메시 트래픽을 알려진 호스트로만 제한합니다.
• 특정 클라이언트의 인바운드 트래픽을 제한합니다.
• 네트워크의 피어 IP 주소보다 서비스 ID를 기반으로 네트워크 보안 정책을 구성할 수 있습니다.
• 메시에서 서비스 간 승인된 통신을 제한합니다. 예를 들어 테넌트 네임스페이스의 앱은 동일한 네임스페이스의 앱 또는 일련의 알려진 외부 호스트와만 통신할 수 있습니다.
• 추가 트래픽 제어를 적용할 수 있는 메시 게이트웨이를 통해 모든 인바운드 및 아웃바운드 트래픽을 라우팅합니다.

노드 taint 및 어피니티

노드 taint 및 노드 어피니티는 포드가 클러스터 노드에 예약되는 방식에 영향을 줄 수 있는 Kubernetes 메커니즘입니다.

taint된 노드는 포드를 삭제합니다. 포드에 taint에 대한 톨러레이션(toleration)이 없으면 taint된 노드에 포드를 예약하지 않습니다. 노드 taint를 사용하여 특정 워크로드나 테넌트만 사용할 수 있도록 노드를 예약할 수 있습니다. taint 및 톨러레이션(toleration)은 종종 멀티 테넌트 클러스터에서 사용됩니다. 자세한 내용은 taint 및 톨러레이션(toleration)이 있는 전용 노드 문서를 참조하세요.

노드 어피니티를 사용하면 포드를 특정 라벨이 있는 노드로 제한할 수 있습니다. 포드에 노드 어피니티 요구사항이 있는 경우 Kubernetes는 노드에 어피니티 요구사항과 일치하는 라벨이 없는 한 포드를 노드에 예약하지 않습니다. 노드 어피니티를 사용하여 포드가 적절한 노드에 예약되도록 할 수 있습니다.

노드 taint 및 노드 어피니티를 함께 사용하여 테넌트 워크로드 포드가 테넌트용으로 예약된 노드에만 예약되도록 할 수 있습니다.

이러한 참조 아키텍처는 다음과 같은 방법으로 테넌트 앱 일정을 제어하는 데 도움이 됩니다.

• 테넌트 전용 GKE 노드 풀을 만듭니다. 풀의 각 노드에는 테넌트 이름과 관련된 taint가 있습니다.
• 테넌트 네임스페이스를 타겟팅하는 모든 포드에 적절한 내결함성 및 노드 어피니티를 자동으로 적용합니다. PolicyController 변형을 사용하여 내결함성과 어피니티를 적용하세요.

최소 권한

GKE 클러스터와 같은 Google Cloud 프로젝트 및 리소스에 대해 최소 권한 원칙을 채택하는 것이 보안 권장사항입니다. 이 방법을 사용하면 클러스터 내에서 실행되는 앱과 클러스터를 사용하는 개발자 및 운영자에게 필요한 최소 권한 집합만 있게 됩니다.

이러한 참조 아키텍처는 다음과 같은 방법으로 최소 권한 서비스 계정을 사용하는 데 도움이 됩니다.

• 각 GKE 노드 풀은 자체 서비스 계정을 수신합니다. 예를 들어 테넌트 노드 풀의 노드는 해당 노드 전용 서비스 계정을 사용합니다. 노드 서비스 계정은 최소 필수 권한으로 구성됩니다.
• 클러스터는 워크로드 아이덴티티를 사용하여 Kubernetes 서비스 계정을 Google 서비스 계정과 연결합니다. 이렇게 하면 서비스 계정 키를 다운로드 및 저장하지 않고 테넌트 앱에 필요한 Google API에 대한 제한된 액세스 권한을 부여할 수 있습니다. 예를 들어 Cloud Storage 버킷의 데이터를 읽을 수 있는 권한을 서비스 계정에 부여할 수 있습니다.

이러한 참조 아키텍처는 다음 방법으로 클러스터 리소스에 대한 액세스를 제한하는 데 도움이 됩니다.

• 앱 관리를 위해 제한된 권한으로 샘플 Kubernetes RBAC 역할을 만듭니다. 테넌트 네임스페이스에서 앱을 운영하는 사용자 및 그룹에 이 역할을 부여할 수 있습니다. 이렇게 제한된 사용자 및 그룹 역할을 적용하여 해당 사용자에게만 테넌트 네임스페이스에서 앱 리소스를 수정하는 권한을 부여합니다. 클러스터 수준 리소스 또는 Anthos Service Mesh 정책과 같은 민감한 보안 설정을 수정할 권한이 없습니다.

제휴 학습 보안 고려사항

엄격한 데이터 공유 모델에도 불구하고 제휴 학습은 본질적으로 모든 표적 공격으로부터 보호되지 않습니다. 이 문서에 설명된 아키텍처를 배포할 때 이러한 위험을 고려해야 합니다. ML 모델 또는 모델 학습 데이터에 대한 의도치 않은 정보 유출의 위험도 있습니다. 예를 들어 공격자가 전역 ML 모델이나 제휴 학습 작업 단계를 의도적으로 손상시키거나 타이밍 공격(부차 채널 공격 유형)을 실행하여 학습 데이터 세트 크기에 대한 정보를 수집할 수 있습니다.

제휴 학습 구현에서 예상할 수 있는 가장 일반적인 위협은 다음과 같습니다.

• 의도 또는 의도하지 않은 학습 데이터 기억. 제휴 학습 구현 또는 공격자는 나중에 작업하기가 어려울 수도 있는 방식으로 의도적이거나 의도치 않게 데이터를 저장할 수 있습니다. 공격자는 저장된 데이터를 리버스 엔지니어링하여 글로벌 ML 모델 또는 제휴 학습 시도의 이전 라운드에 대한 정보를 수집할 수 있습니다.
• 전역 ML 모델 업데이트에서 정보를 추출합니다. 제휴 학습 작업을 수행하는 동안 공격자는 제휴 소유자가 참여자 조직 및 기기로부터 수집하는 전역 ML 모델 업데이트를 리버스 엔지니어링할 수 있습니다.
• 제휴 소유자가 학습 작업 라운드를 손상시킬 수 있습니다. 보안 침해된 제휴 소유자는 비인증 사일로 또는 기기를 제어하고 제휴 학습 작업 라운드를 시작할 수 있습니다. 라운드가 끝나면 손상된 제휴 소유자가 적법한 참여 조직 및 기기로부터 수집하는 업데이트를 비인증 사일로에서 생성된 업데이트와 비교하여 업데이트 관련 정보를 수집할 수 있습니다.
• 참여 조직 및 기기가 전역 ML 모델을 손상시킬 수 있습니다. 제휴 학습 작업을 수행하는 동안 공격자는 비인증 또는 비순차적 업데이트를 생성하여 전역 ML 모델의 성능, 품질, 무결성에 악의적으로 영향을 주려고 시도할 수 있습니다.

이 섹션에 설명된 위협으로 인한 영향을 완화하려면 다음 권장사항을 따르는 것이 좋습니다.

• 모델을 조정하여 학습 데이터 기억을 최소한으로 줄입니다.
• 개인 정보 보호 메커니즘을 구현합니다.
• 전역 ML 모델, 공유하려는 ML 모델, 학습 데이터, 제휴 학습 목표를 달성하기 위해 구현한 인프라를 정기적으로 감사합니다.
• 보안 집계 알고리즘을 구현하여 참여자 조직이 생성하는 학습 결과를 처리합니다.
• 공개 키 인프라를 사용하여 데이터 암호화 키를 안전하게 생성하고 배포합니다.
• 컨피덴셜 컴퓨팅 플랫폼에 인프라를 배포합니다.

또한 제휴 소유자는 다음과 같은 추가 단계를 수행해야 합니다.

• 교차 사일로 아키텍처의 경우 각 참여 조직의 ID와 각 사일로의 무결성을 확인하고 교차 기기 아키텍처의 경우 각 기기의 ID와 무결성을 확인합니다.
• 참여 조직 및 기기가 생성할 수 있는 전역 ML 모델로 업데이트 범위를 제한합니다.

신뢰성

이 섹션에서는 Google Cloud에서 제휴 학습 플랫폼을 설계 및 빌드하기 위해 이 문서의 참조 아키텍처를 사용할 때 고려할 설계 요소에 대해 설명합니다.

Google Cloud에서 제휴 학습 아키텍처를 설계할 때는 이 섹션의 안내에 따라 워크로드 가용성 및 확장성을 개선하고 아키텍처가 중단 및 재해를 견딜 수 있도록 지원하는 것이 좋습니다.

GKE: GKE는 워크로드의 가용성 요구사항 및 예산에 맞게 조정할 수 있는 여러 다른 클러스터 유형을 지원합니다. 예를 들어 제어 영역 및 노드를 한 리전 내 여러 영역에 배포하는 리전 클러스터를 만들거나 단일 영역에 제어 영역과 노드가 포함된 영역 클러스터를 만들 수 있습니다. 교차 사일로 및 교차 기기 참조 아키텍처에는 리전 GKE 클러스터가 사용됩니다. GKE 클러스터를 만들 때 고려할 특성에 대한 자세한 내용은 클러스터 구성 옵션을 참조하세요.

클러스터 유형과 제어 영역 및 클러스터 노드가 리전 및 영역 간에 배포되는 방식에 따라 GKE는 영역 및 리전 중단으로부터 워크로드를 보호하기 위해 여러 다른 재해 복구 기능을 제공합니다. GKE의 재해 복구 기능에 대한 자세한 내용은 클라우드 인프라 중단에 대한 재해 복구 설계: Google Kubernetes Engine을 참조하세요.

Google Cloud Load Balancing: GKE는 워크로드에 대해 여러 방식의 트래픽 부하 분산을 지원합니다. Kubernetes 게이트웨이 및 Kubernetes 서비스 API의 GKE 구현을 사용하면 GKE 클러스터에서 실행되는 워크로드를 안전하고 신뢰할 수 있는 방식으로 노출할 수 있도록 Cloud Load Balancing을 자동으로 프로비저닝하고 구성할 수 있습니다.

이러한 참조 아키텍처에서 모든 인그레스 및 이그레스 트래픽은 Anthos Service Mesh 게이트웨이를 통과합니다. 이러한 게이트웨이를 통해 GKE 클러스터 내부 및 외부에서 트래픽의 흐름 방식을 세부적으로 제어할 수 있습니다.

교차 기기 제휴 학습의 신뢰성 과제

교차 기기 제휴 학습에는 교차 사일로 시나리오에서 발생하지 않는 여러 신뢰성 과제가 있습니다. 여기에는 다음과 같은 내용이 포함되어 있습니다.

• 신뢰할 수 없거나 간헐적인 기기 연결
• 제한된 기기 스토리지
• 제한된 컴퓨팅 및 메모리

연결이 불안정하면 다음과 같은 문제가 발생할 수 있습니다.

• 오래된 업데이트 및 모델 발산: 기기에 간헐적 연결이 발생하면 로컬 모델 업데이트가 오래되어 전역 모델의 현재 상태와 달리 오래된 정보가 포함될 수 있습니다. 오래된 업데이트를 집계하면 학습 프로세스의 불일치로 인해 전역 모델이 최적 솔루션에서 벗어나는 모델 불일치가 발생합니다.
• 불균형적인 기여 및 편향된 모델: 간혈적인 통신에 따라 참여 기기의 기여를 고르지 않게 분배하는 결과를 초래할 수 있습니다. 연결 상태가 낮은 기기는 더 적은 업데이트를 기여함으로써 기본 데이터 배포가 불균형적으로 이뤄질 수 있습니다. 이러한 불균형은 더 신뢰할 수 있는 연결을 가진 기기의 데이터로 전역 모델을 편향시킬 수 있습니다.
• 통신 오버헤드 및 에너지 소비 증가: 간헐적인 통신으로 인해 기기가 손실되거나 손상된 업데이트를 다시 전송해야 할 수 있기 때문에 통신 오버헤드가 증가할 수 있습니다. 성공적인 업데이트 전송을 위해 더 오랜 기간 동안 활성 연결을 유지해야 할 수 있기 때문에 이 문제는 또한 특히 배터리 수명이 제한된 기기의 경우에 기기의 에너지 소비 증가 문제를 일으킬 수 있습니다.

간헐적인 통신으로 인한 효과를 해결하기 위해서는 FCP와 함께 이 문서의 참조 아키텍처를 사용할 수 있습니다.

다음 요구사항을 충족하도록 FCP 프로토콜을 실행하는 시스템 아키텍처를 설계할 수 있습니다.

• 장기 실행 라운드를 처리합니다.
• 예측 실행을 사용 설정합니다(곧 더 많은 체크인이 이뤄질 것을 예상해서 필요한 수의 클라이언트가 조합되기 전에 라운드를 시작할 수 있음).
• 기기가 참여할 태스크를 선택할 수 있도록 설정합니다. 이 방식은 모집단 내의 각 샘플 단위를 한 번만 선택하는 샘플링 전략인 대체 없이 샘플링과 같은 기능을 허용합니다. 이 방식은 불균형한 기여 및 편향된 모델의 문제를 해결하는 데 도움이 됩니다.
• 개인 정보 차등 보호(DP) 및 신뢰할 수 있는 집계(TAG)와 같은 익명화 기법을 포함하도록 확장될 수 있습니다.

제한적인 기기 스토리지 및 컴퓨팅 기능 문제를 해결하기 위해서는 다음과 같은 방법이 도움이 될 수 있습니다.

• 제휴 학습 계산을 실행하는 데 사용할 수 있는 최대 기능을 이해합니다.
• 특정 시간에 보유할 수 있는 데이터 양을 이해합니다.
• 클라이언트에서 사용 가능한 컴퓨팅 및 RAM 범위 내에서 작동하도록 클라이언트 측 제휴 학습 코드를 설계합니다.
• 스토리지 부족으로 인한 영향을 이해하고 이를 관리할 수 있는 프로세스를 구현합니다.

비용 최적화

이 섹션에서는 Google Cloud에서 이 참조 아키텍처를 사용해서 설정하는 제휴 학습 플랫폼을 만들고 실행하는 데 따른 비용을 최적화할 수 있는 안내를 제공합니다. 이 안내는 이 문서에서 설명하는 두 아키텍처에 모두 적용됩니다.

GKE에서 워크로드를 실행하면 워크로드의 리소스 요구사항에 따라 클러스터를 프로비저닝 및 구성하여 환경의 비용 최적화 수준을 더 향상시키는 데 도움이 됩니다. 또한 클러스터 노드 및 포드 자동 확장 및 클러스터 크기 조정과 같이 클러스터 및 클러스터 노드를 동적으로 재구성하는 기능을 지원합니다.

GKE 환경의 비용 최적화에 대한 자세한 내용은 GKE에서 비용 최적화 Kubernetes 애플리케이션을 실행하기 위한 권장사항을 참조하세요.

운영 효율성

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 제휴 학습 플랫폼을 만들고 실행할 때 효율성 최적화를 위해 고려해야 하는 요소들에 대해 설명합니다. 이 안내는 이 문서에서 설명하는 두 아키텍처에 모두 적용됩니다.

제휴 학습 아키텍처의 자동화 및 모니터링을 향상시키기 위해서는 머신러닝 시스템 맥락의 DevOps 원칙인 MLOps 원칙을 채택하는 것이 좋습니다. MLOps를 수행하면 통합, 테스트, 출시, 배포, 인프라 관리를 비롯하여 ML 시스템 구성의 모든 단계에서 자동화 및 모니터링을 지원할 수 있습니다. MLOps에 대한 자세한 내용은 MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인을 참조하세요.

성능 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 Google Cloud에서 제휴 학습 플랫폼을 만들고 실행할 때 워크로드 성능을 최적화하기 위해 고려해야 하는 요소에 대해 설명합니다. 이 안내는 이 문서에서 설명하는 두 아키텍처에 모두 적용됩니다.

GKE는 워크로드 수요를 충족하기 위해 GKE 환경의 크기 조절 및 확장을 자동 및 수동으로 수행하고 리소스 초과 프로비저닝을 방지할 수 있도록 여러 기능을 지원합니다. 예를 들어 추천자를 사용해서 GKE 리소스 사용을 최적화하기 위한 인사이트 및 추천을 생성할 수 있습니다.

GKE 환경 확장 방법을 고려할 때는 환경 및 워크로드 확장 방법에 대해 단기, 중기 및 장기 계획을 설계하는 것이 좋습니다. 예를 들어 몇 주, 몇 개월, 몇 년 단위로 GKE 기반 확장 방법을 고려해야 합니다. 계획을 준비하면 GKE가 제공하는 확장성 기능을 최대한 활용하고, GKE 환경을 최적화하고, 비용을 줄이는 데 도움을 얻을 수 있습니다. 클러스터 및 워크로드 확장성 계획에 대한 자세한 내용은 GKE 확장성 정보를 참조하세요.

ML 워크로드 성능을 늘리기 위해서는 대규모 AI 모델의 학습 및 추론을 위해 최적화된 Google에서 설계된 AI 가속기인 Cloud 텐서 처리 장치(Cloud TPU)를 채택할 수 있습니다.

배포

이 문서에서 설명하는 교차 사일로 및 교차 기기 참조 아키텍처를 배포하기 위해서는 Google Cloud의 제휴 학습 GitHub 저장소를 참조하세요.

다음 단계

• TensorFlow 제휴 플랫폼에서 제휴 학습 알고리즘을 구현하는 방법 알아보기
• 제휴 학습의 발전 및 미해결 문제 읽어보기
• Google AI 블로그의 제휴 학습 읽어보기
• Google이 익명화된 합산 데이터를 사용하는 제휴 학습을 통해 ML 모델을 개선하면서 개인 정보 보호를 보장하는 방법 보기
• 규모에 맞는 제휴 학습으로 전환 읽어보기
• 제휴 학습의 발전 및 미해결 문제 읽어보기
• MLOps 파이프라인을 구현하여 머신러닝 모델의 수명주기를 관리하는 방법 알아보기
• 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기

참여자

저자:

• 그레이스 몰리슨 | 솔루션 책임자
• 마르코 페라리 | 클라우드 솔루션 설계자

기타 참여자:

• 클로에 키동 | 직원 소프트웨어 엔지니어 겸 관리자
• 로런트 그레잉고우 | 솔루션 설계자
• 릴리안 펠릭스 | 클라우드 엔지니어