Amazon SageMaker 기능 스토어 의 새로운 기능입니다 아마존 세이지 메이커 데이터 과학자와 기계 학습 (ML) 엔지니어가 훈련 및 예측 워크 플로에 사용되는 선별 된 데이터를 안전하게 저장, 검색 및 공유 할 수 있도록 지원합니다. 조직이 ML을 사용하여 데이터 기반 애플리케이션을 구축함에 따라 점점 더 기능적인 팀간에 기능을 지속적으로 조립하고 이동하고 있습니다. 이러한 지속적인 데이터 이동은 여러 팀에 걸친 ML 이니셔티브를 설계 할 때 기능의 불일치로 이어지고 병목 현상이 될 수 있습니다. 예를 들어 전자 상거래 회사에는 플랫폼의 다양한 측면에서 작업하는 여러 데이터 과학 및 엔지니어링 팀이있을 수 있습니다. 핵심 검색 팀은 쿼리 이해 및 정보 검색 작업에 중점을 둡니다. 제품 성공 팀은 고객 리뷰 및 피드백 신호와 관련된 문제를 해결합니다. 개인화 팀은 클릭 스트림 및 세션 데이터를 사용하여 개인화 된 권장 사항을위한 ML 모델을 생성합니다. 또한 데이터 큐 레이션 팀과 같은 데이터 엔지니어링 팀은 다른 팀이 사용할 수있는 필수 구성 요소 인 사용자 별 정보를 큐레이팅하고 유효성을 검사 할 수 있습니다. 기능 저장소는 이러한 팀 간의 통합 인터페이스로 작동하여 한 팀이 다른 팀에서 생성 한 기능을 활용할 수 있도록하여 팀간에 기능을 복제하고 이동하는 작업 오버 헤드를 최소화합니다.
프로덕션 준비가 완료된 ML 모델 학습에는 일반적으로 모델을 구축하는 팀이 항상 소유하고 유지 관리하지 않는 다양한 기능 집합에 대한 액세스가 포함됩니다. ML을 적용하는 조직의 일반적인 관행은 이러한 데이터 과학 팀을 제한된 공동 작업으로 독립적으로 작업하는 개별 그룹으로 생각하는 것입니다. 그 결과 팀간에 기능을 공유하는 표준화 된 방법이없는 ML 워크 플로가 발생하여 데이터 과학 생산성에 중요한 제한 요소가되고 데이터 과학자가 새롭고 복잡한 모델을 구축하기가 더 어려워집니다. 공유 기능 저장소를 통해 조직은 규모의 경제를 달성 할 수 있습니다. 더 많은 공유 기능을 사용할 수있게되면 팀이 새 모델을 구축하고 유지 관리하는 것이 더 쉽고 저렴 해집니다. 이러한 모델은 중앙 집중식 기능 저장소를 사용하여 이미 개발, 테스트 및 제공되는 기능을 재사용 할 수 있습니다.
이 게시물은 여러 AWS 계정에서 운영되는 많은 데이터 엔지니어링 및 데이터 과학 팀이있는 조직에서 구현할 수있는 Feature Store의 필수 교차 계정 아키텍처 패턴을 캡처합니다. 단계별 예제를 통해 계정 간 기능 공유를 활성화하는 방법을 공유합니다. GitHub 레포.
SageMaker 기능 저장소 개요
기본적으로 SageMaker Feature Store는 생성 된 계정에 로컬이지만 여러 계정에서 중앙 집중화 및 공유 할 수도 있습니다. 여러 팀이있는 조직에는 팀간에 공유되는 하나의 중앙 집중식 기능 저장소와 개별 팀에서 사용할 수있는 별도의 기능 저장소가있을 수 있습니다. 별도의 저장소는 민감한 특성이거나 고유 한 ML 워크로드에 특정한 기능 그룹을 보유 할 수 있습니다.
이 게시물에서는 먼저 중앙 기능 저장소 무늬. 이 패턴은 팀이 새 기능을 만들고 게시 할 수 있고 다른 팀 (또는 시스템)에서 기능을 사용할 수있는 중앙 인터페이스를 규정합니다. 또한 조직 전체의 기능 데이터에 대한 단일 소스를 확보하고 리소스 관리를 단순화합니다.
다음으로 결합 된 기능 저장소 이를 통해 팀은 중앙 집중식 기능 저장소에서 공유 기능에 액세스 할 수있는 동시에 자신의 기능 저장소를 계정에 로컬로 유지할 수 있습니다. 이러한 로컬 기능 저장소는 일반적으로 데이터 과학 실험을 위해 구축됩니다. 중앙 집중식 저장소의 공유 기능을 로컬 기능과 결합함으로써 팀은 더 복잡한 ML 모델을 빌드 할 때 도움이 될 수있는 새로운 향상된 기능을 도출 할 수 있습니다. 또한 로컬 저장소를 사용하여 규정 및 규정 준수 이유로 조직 전체에서 공유 할 수없는 중요한 데이터를 저장할 수 있습니다.
마지막으로 특징 데이터 복제와 관련된 덜 일반적인 패턴을 간략하게 다룹니다.
중앙 집중식 기능 저장소
조직은 중앙 집중식 기능 저장소의 이점을 극대화 할 수 있습니다. 그만큼 중앙 집중식 기능 저장소 패턴은 여러 계정의 기능 파이프 라인이 하나의 중앙 집중식 기능 저장소에 쓰는 방법과 여러 다른 계정이 이러한 기능을 사용할 수있는 방법을 보여줍니다. 이는 여러 팀이 서로 다른 유형의 데이터 또는 애플리케이션의 서로 다른 부분을 관리하는 중대형 기업에서 흔히 볼 수있는 패턴입니다.
데이터 입력을 가설, 선택 및 ML 모델에 적합한 사용 가능한 형태로 변환하는 프로세스를 호출합니다. 기능 엔지니어링. 에이 기능 파이프 라인 원시 데이터를 ML 모델이 예측을위한 입력으로 사용하는 유용한 기능으로 변환하는 데 필요한 기능 엔지니어링 프로세스의 모든 단계를 캡슐화합니다. 기능 파이프 라인을 유지하는 것은 비용이 많이 들고 시간이 많이 걸리며 오류가 발생하기 쉬운 프로세스입니다. 또한 계정간에 기능 레시피 및 변환을 복제하면 기능 특성이 불일치하고 왜곡 될 수 있습니다. 중앙 집중식 기능 저장소는 지식 공유를 용이하게하므로 팀은 모든 프로젝트에서 기능 레시피를 다시 만들고 파이프 라인을 처음부터 다시 작성할 필요가 없습니다.
이 패턴에서는 기능을 계정 별 기능 저장소에 로컬로 쓰는 대신 중앙 집중식 기능 저장소에 기능을 작성합니다. 중앙 집중식 저장소는 중앙 저장소 역할을하며 팀 간 협업을위한 기능에 액세스하고 유지 관리하는 표준화 된 방법을 만듭니다. AI 채택을 촉진하고 가속화하는 역할을하여 ML 솔루션의 출시 시간을 단축하고 ML 기능에 대한 중앙 집중식 거버넌스 및 액세스 제어를 허용합니다. 데이터 액세스 정책에 따라 개별 기능 그룹을 읽고 쓸 수 있도록 외부 계정, 사용자 또는 역할에 대한 액세스 권한을 부여 할 수 있습니다. AWS는 직무에 필요한 기능 그룹에만 최소 권한 액세스를 적용 할 것을 권장합니다. 이것은 기본에 의해 관리됩니다 AWS 자격 증명 및 액세스 관리 (IAM) 정책. 기능 그룹 태그를 사용하여 액세스 제어를 더욱 세분화 할 수 있으며 IAM 조건 특정 작업을 수행 할 수있는 주체를 결정합니다. 중앙 집중식 저장소를 대규모로 사용하는 경우 기능 그룹이 잘 설계되었는지, 기능 파이프 라인이 문서화되고 지원되는지, 기능 품질을 보장하는 프로세스가 있는지 확인하기 위해 적절한 기능 거버넌스를 구현하는 것도 중요합니다. 이러한 유형의 거버넌스는 팀 간의 기능 재사용에 필요한 신뢰를 얻는 데 도움이됩니다.
예제를 살펴보기 전에 몇 가지 주요 기능 저장소 개념을 식별 해 보겠습니다. 먼저, 기능 그룹 일반적으로 동일한 기능 파이프 라인에서 발생하는 논리적 기능 그룹입니다. 안 오프라인 상점 모델 개발을위한 학습 및 테스트 데이터를 생성하거나 모델 점수를 매기기위한 배치 애플리케이션에 사용되는 대량의 과거 기능 데이터를 포함합니다. 목적 온라인 상점 지연 시간이 짧은 실시간으로 동일한 기능을 제공하는 것입니다. 추가 전용인 오프라인 상점과 달리 온라인 상점의 목표는 최신 기능 값을 제공하는 것입니다. 뒤에서 Feature Store는 자동으로 두 저장소 간의 데이터 동기화를 수행합니다. 새 기능 값을 온라인 스토어로 수집하면 자동으로 오프라인 스토어에 추가됩니다. 그러나 오프라인 및 온라인 s를 만들 수도 있습니다.
이것이 팀이나 프로젝트에 대한 요구 사항인 경우에는 별도로 보관하십시오.
다음 다이어그램은 각각 중앙 집중식 기능 저장소의 기능 그룹에 기록하는 고유 한 기능 파이프 라인이있는 세 가지 기능 팀을 보여줍니다.
개인화 계정은 고객 대면 애플리케이션에서 수집 된 사용자 세션 데이터를 관리하고 세션 데이터에서 파생 된 기능이있는 세션이라는 기능 그룹을 생성하는 기능 파이프 라인을 소유합니다. 이 파이프 라인은 생성 된 기능 값을 중앙 집중식 기능 저장소에 씁니다. 마찬가지로 제품 성공 계정의 기능 파이프 라인은 리뷰 기능 그룹의 기능을 생성하고 데이터 큐 레이션 계정은 사용자 기능 그룹의 기능을 생성합니다.
중앙 집중식 기능 저장소 계정은 XNUMX 개의 생산자 계정에서받은 모든 기능을 보유합니다., 세션, 리뷰 및 사용자의 세 가지 기능 그룹에 매핑됩니다. 기능 파이프 라인은 중앙 집중식 저장소 계정에서 생성 된 특정 IAM 역할을 가정하여 중앙 집중식 기능 저장소에 쓸 수 있습니다. 이 게시물의 뒷부분에서이 교차 계정 역할을 활성화하는 방법에 대해 설명합니다. 외부 계정은 또한 앞의 아키텍처 다이어그램에 표시된대로 교육 또는 추론을 위해 중앙 집중식 저장소의 기능 그룹에서 기능을 쿼리 할 수 있습니다. 교육을 위해 중앙 집중식 저장소에서 IAM 역할을 맡고 교차 계정을 실행할 수 있습니다. 아마존 아테나 (다이어그램에 표시된대로) 쿼리하거나 아마존 EMR or SageMaker 처리 훈련 데이터 세트를 만드는 일. 실시간 추론의 경우 교차 계정 액세스에 대해 동일한 가정 된 IAM 역할을 통해 직접 온라인 기능을 읽을 수 있습니다.
이 모델에서 중앙 집중식 기능 저장소는 일반적으로 프로덕션 계정에 있습니다. 이 저장소를 사용하는 애플리케이션은이 계정 또는 중앙 집중식 기능 저장소에 대한 교차 계정 액세스 권한이있는 다른 계정에있을 수 있습니다. 인프라 변경 사항을 프로덕션으로 승격하기 전에 테스트하기 위해 개발 또는 스테이징과 같은 하위 환경에서이 전체 구조를 복제 할 수 있습니다.
결합 된 기능 저장소
이 섹션에서는 중앙 집중식 기능 저장소 패턴의 변형 인 결합 된 기능 저장소 무늬. 기능 엔지니어링에서 일반적인 관행은 기존 기능을 결합하여 새로운 기능을 도출하는 것입니다. 팀이 중앙 집중식 저장소의 공유 기능을 자체 기능 저장소의 로컬 기능과 결합하면 더 복잡한 데이터 모델을 구축하는 데 도움이되는 새로운 향상된 기능을 얻을 수 있습니다. 이전 섹션에서 중앙 집중식 저장소를 사용하면 모든 데이터 과학 팀이 외부 기능에 쉽게 액세스하고 기존 기능 풀과 함께 사용하여 새로운 기능을 합성하고 발전시킬 수 있음을 알고 있습니다.
보안 및 규정 준수는 팀이 중앙 저장소에서 기능에 액세스하는 것 외에도 팀별 기능 저장소를 유지 관리하는 또 다른 사용 사례입니다. 많은 팀에서 조직의 모든 사람에게 부여되지 않은 특정 액세스 권한이 필요합니다. 예를 들어 민감한 데이터에서 추출 된 기능을 조직 내의 중앙 집중식 기능 저장소에 게시하는 것이 불가능할 수 있습니다.
다음 아키텍처 다이어그램에서 중앙 집중식 기능 저장소는 여러 기능 파이프 라인에서받은 모든 기능을 하나의 중앙 저장소로 수집하고 카탈로그 화하는 계정입니다. 이 예에서 결합 된 상점의 계정은 Core Search 팀에 속합니다. 이 계정은 중앙 저장소에서 공유 가능한 기능의 소비자입니다. 또한이 계정은 고객 대면 검색 애플리케이션을 통해 수집 된 사용자 키워드 데이터를 관리합니다.
이 계정은 자체 로컬 오프라인 및 온라인 상점을 유지합니다. 이러한 로컬 저장소는 사용자 쿼리 키워드 데이터를 수집하고 기능을 생성하기 위해 로컬로 설정된 기능 파이프 라인에 의해 채워집니다. 이러한 기능은 키워드라는 기능 그룹 아래에 그룹화됩니다. 기본적으로 기능 저장소는 자동으로 AWS 접착제 이 계정의 AWS Glue 데이터 카탈로그에 등록 된이 기능 그룹에 대한 테이블. 이 테이블의 메타 데이터는이 계정의 오프라인 스토어에있는 기능 그룹의 Amazon S3 위치를 가리 킵니다.
통합 상점 계정은 중앙 집중식 상점에서 기능 그룹 세션, 리뷰 및 사용자에 액세스 할 수도 있습니다. 역할별로 교차 계정 액세스를 활성화 할 수 있습니다. 이에 대해서는 다음 섹션에서 설명합니다. 데이터 과학자 및 연구원은 Athena를 사용하여 로컬에서 생성 된 기능 그룹을 쿼리하고 이러한 내부 기능을 데이터 과학 실험을 위해 중앙 저장소에서 파생 된 외부 기능과 결합 할 수 있습니다.
교차 계정 액세스 개요
이 섹션에서는 다음을 통해 가정 된 역할을 사용하여 두 계정간에 Feature Store에 대한 교차 계정 액세스를 활성화하는 방법에 대한 개요를 제공합니다. AWS 보안 토큰 서비스 (AWS STS). AWS STS는 IAM 사용자에 대한 제한된 권한의 임시 자격 증명을 요청할 수있는 웹 서비스입니다. AWS STS는 일반적으로 액세스 할 수없는 AWS 리소스에 액세스하는 데 사용할 수있는 임시 보안 자격 증명 세트를 반환합니다. 이러한 임시 자격 증명은 액세스 키 ID, 보안 액세스 키 및 보안 토큰으로 구성됩니다.
이 프로세스를 설명하기 위해 다음 다이어그램과 같이 두 개의 계정 A와 B가 있다고 가정합니다.
계정 B는 중앙 집중식 온라인 및 오프라인 기능 저장소를 유지합니다. 계정 A는 계정 B에 포함 된 온라인 및 오프라인 스토어 모두에 액세스 할 수 있어야합니다.이를 활성화하기 위해 계정 B에서 역할을 생성하고 계정 A가 AWS STS를 사용하여 해당 역할을 맡도록합니다. 이렇게하면 계정 A가 역할에 의해 식별 된 특정 작업을 수행 할 수있는 권한이있는 계정 B처럼 작동 할 수 있습니다. SageMaker (처리 및 훈련 작업, 엔드 포인트) 및 AWS 람다 계정 A에서 사용 된 것은 AWS STS 클라이언트를 사용하여 계정 B에서 생성 된 IAM 역할을 맡을 수 있습니다 (이 게시물 뒷부분의 코드 블록 참조). 이렇게하면 계정 B 내의 Amazon S3, Athena 및 AWS Glue 데이터 카탈로그와 같은 리소스에 액세스하는 데 필요한 권한이 부여됩니다. 계정 A의 서비스가 리소스에 대한 필요한 권한을 획득하면 계정의 오프라인 및 온라인 스토어 모두에 액세스 할 수 있습니다. B. 선택한 서비스에 따라 해당 서비스에 대한 IAM 실행 역할을 계정 B의 교차 계정 IAM 역할의 신뢰할 수있는 정책에 추가해야합니다. 이에 대해서는 다음 섹션에서 자세히 설명합니다.
위의 아키텍처 다이어그램은 계정 A가 계정 B의 역할을 맡아 계정 B에 포함 된 온라인 및 오프라인 상점 모두에 읽고 쓰는 방법을 보여줍니다. 다이어그램의 XNUMX 단계는 다음과 같습니다.
- 계정 B는 다른 사람이 맡을 수있는 역할을 생성합니다 (사용 사례의 경우 계정 A).
- 계정 A는 AWS STS를 사용하여 계정 B의 IAM 역할을 맡습니다. 이제 계정 A는 계정 B 내부에있는 것처럼 작동하는 AWS 서비스 클라이언트를 생성하는 데 사용할 수있는 임시 자격 증명을 생성 할 수 있습니다.
- 계정 A에서 SageMaker 및 기타 서비스
클라이언트(예: Amazon S3 및 Athena)는 수임된 역할을 통해 임시 자격 증명을 사용하여 생성됩니다. - 이제 계정 A의 서비스 클라이언트는 AWS SDK를 사용하여 기능 그룹을 생성하고 계정 B의 중앙 집중식 온라인 스토어에 기능 값을 채울 수 있습니다.
- 계정 B의 온라인 스토어는 계정 B의 오프라인 스토어와 자동으로 동기화됩니다.
- 계정 A 내부의 Athena 서비스 클라이언트는 계정 B 내부의 Athena 테이블을 사용하여 기능 세트를 읽고, 그룹화하고, 구체화하기 위해 교차 계정 쿼리를 실행합니다. 오프라인 스토어가 계정 B에 존재하기 때문에 해당 AWS Glue 테이블, 메타 데이터 카탈로그 항목 및 S3 객체 모두 계정 B 내에 있습니다. 계정 A는 AWS STS 수임 역할을 사용하여 계정 B 내의 오프라인 기능 (S3 객체)을 쿼리 할 수 있습니다.
- Athena 쿼리 결과는 계정 A의 S3 버킷에 기능 데이터 세트로 반환됩니다.
임시 자격 증명은 AWS STS GetSessionToken API를 사용하며 1 시간으로 제한됩니다. 다음을 사용하여 세션 기간을 연장 할 수 있습니다. 새로 고칠 수 있는 자격 증명, 자격 증명을 자동으로 새로 고칠 수있는 Botocore 클래스는 1 시간이 지나도 장기 실행 애플리케이션에서 작동합니다. 안 노트북 예 이를 시연하는 것은 GitHub 저장소에서 확인할 수 있습니다.
교차 계정 액세스 만들기
이 섹션에서는 아키텍처에 따라 계정 A와 B간에 기능을 공유 할 수 있도록 교차 계정 액세스 역할, 정책 및 권한을 만드는 모든 단계를 자세히 설명합니다.
기능 저장소 액세스 역할 만들기
계정 B에서 기능 저장소 액세스 역할을 만듭니다. 이는 계정 B의 리소스에 대한 액세스 권한을 얻기 위해 계정 A 내부의 AWS 서비스에서 맡은 역할입니다.
- IAM 콘솔의 탐색 창에서 역할.
- 왼쪽 메뉴에서 역할 만들기.
- 왼쪽 메뉴에서 다른 AWS 계정.
- 럭셔리 계정 ID, 계정 B의 12 자리 계정 ID를 입력합니다.
- 왼쪽 메뉴에서 다음 : 권한.
- . 권한 섹션에서 다음 AWS 관리 형 정책을 검색하고 연결합니다.
AmazonSageMakerFullAccess
(사용 사례에 따라 최소한의 권한으로 추가로 제한 할 수 있습니다.)AmazonSageMakerFeatureStoreAccess
- 이 새 역할에 사용자 지정 정책을 생성하고 연결합니다 (계정 B에서 수집 된 Athena 쿼리 결과가 기록 된 계정 A에 S3 버킷 이름 제공).
계정 A에서이 새로운 AWS STS 교차 계정 역할을 사용하면 계정 B의 오프라인 스토어 콘텐츠에 대해 Athena 쿼리를 실행할 수 있습니다. 사용자 지정 정책은 Athena (계정 B 내부)가 결과를 계정의 결과 버킷에 다시 쓸 수 있도록 허용합니다. A. 이전 정책을 생성하기 전에이 결과 버킷이 계정 A에 생성되었는지 확인하십시오.
또는 계정 B의 중앙 집중식 기능 저장소가 모든 Athena 쿼리 결과를 S3 버킷에 유지하도록 할 수 있습니다. 이 경우 저장된 결과 (S3 객체)를 읽으려면 외부 계정에 대한 교차 계정 Amazon S3 읽기 액세스 정책을 설정해야합니다.
- 정책을 연결 한 후 다음 보기.
- 이 역할의 이름을 입력합니다 (예 : cross-account-assume-role).
- 에 요약 아래에 생성 된 역할 페이지 신뢰 관계선택한다. 트러스트 관계 편집.
- 다음 코드에 표시된대로 액세스 제어 정책 문서를 편집하십시오.
앞의 코드는 SageMaker 및 Athena를 Principal 섹션의 서비스로 추가합니다. 더 많은 외부 계정 또는 역할이이 역할을 맡도록하려면이 섹션에서 해당 ARN을 추가 할 수 있습니다.
SageMaker 노트북 인스턴스 생성
계정 A에서 IAM 실행 역할이있는 SageMaker 노트북 인스턴스를 생성합니다. 이 역할은 계정 A의 SageMaker 노트북에 계정 B 내부의 기능 스토어에서 작업을 실행하는 데 필요한 권한을 부여합니다. 또는 SageMaker 노트북을 사용하지 않고 대신 Lambda를 사용하는 경우 동일한 권한으로 Lambda에 대한 역할을 생성해야합니다. 이 섹션에 표시된대로 첨부 된 정책.
기본적으로 SageMaker 노트북에 대한 새 실행 역할을 생성 할 때 다음 정책이 연결됩니다.
AmazonSageMaker-ExecutionPolicy
AmazonSageMakerFullAccess
두 개의 추가 사용자 지정 정책을 만들고 연결해야합니다. 먼저 다음 코드를 사용하여 사용자 지정 정책을 생성하여 계정 A의 실행 역할이 계정 B의 오프라인 스토어와 상호 작용하는 데 필요한 특정 S3 작업을 수행 할 수 있도록합니다.
AWS 관리 형 정책을 연결할 수도 있습니다. AmazonSageMakerFeatureStoreAccess
, 오프라인 스토어 S3 버킷 이름에 SageMaker
예어.
둘째, 다음 사용자 지정 정책을 생성하여 계정 A의 SageMaker 노트북이 역할 (cross-account-assume-role
) 계정 B에서 생성 :
우리는 계정 A가 계정 B의 온라인 및 오프라인 스토어에 액세스할 수 있다는 것을 알고 있습니다. 계정 A가 계정 B의 교차 계정 AWS STS 역할을 맡을 때 계정 B 내에서 오프라인 스토어에 대해 Athena 쿼리를 실행할 수 있습니다. 그러나 모델 교육을 활성화하려면 이러한 쿼리(기능 데이터 세트)의 결과를 계정 A의 S3 버킷에 저장해야 합니다. 따라서 Athena 쿼리 결과를 저장할 수 있는 버킷을 계정 A에 생성하고 버킷 정책을 생성해야 합니다(다음 코드 참조). 이 정책은 교차 계정 AWS STS 역할이 이 내 객체를 쓰고 읽을 수 있도록 허용합니다.
버킷:
신뢰 관계 정책 수정
계정 A에서 IAM 실행 역할을 생성 했으므로이 역할의 ARN을 사용하여 계정 B에서 교차 계정 수임 역할의 신뢰 관계 정책을 수정합니다.
설정 프로세스 확인
모든 역할 및 수반되는 정책을 설정 한 후 다음에서 예제 노트북을 실행하여 설정을 검증 할 수 있습니다. GitHub 레포. 다음 코드 블록은 예제 노트북에서 발췌 한 것으로 계정 A 내에서 실행되는 SageMaker 노트북에서 실행되어야합니다. AWS STS를 통해 계정 B에서 교차 계정 역할을 맡을 수있는 방법을 보여줍니다. 수임역할 API 호출. 이 호출은 계정 A가 서비스 클라이언트를 만드는 데 사용할 수있는 임시 자격 증명 집합을 반환합니다. 이러한 클라이언트를 사용할 때 코드는 위임 된 역할의 권한을 사용하고 계정 B에 속한 것처럼 작동합니다. 자세한 내용은 다음을 참조하십시오. 가정 _ 역할 Python 용 AWS SDK (Boto 3) 설명서에서
계정 A에서 이전 코드 예제에 따라 SageMaker 클라이언트를 생성 한 후 기능 그룹을 생성하고 기능을 계정 B의 중앙 집중식 온라인 및 오프라인 스토어에 채울 수 있습니다. 기능 그룹을 작성, 설명 및 삭제하는 방법에 대한 자세한 정보는 create_feature_group Boto3 문서에서. 당신은 또한 사용할 수 있습니다 기능 저장소 런타임 클라이언트 기능 그룹에 기능 레코드를 넣고 가져옵니다.
오프라인 저장소 복제
재현성은 ML 모델을 정확하게 다시 생성 할 수있는 기능이므로 입력과 동일한 기능을 사용하면 모델이 원본 모델과 동일한 출력을 반환합니다. 이것은 본질적으로 우리가 연구 환경에서 개발하고 프로덕션 환경에 배포하는 모델간에 달성하기 위해 노력하는 것입니다. 계정간에 기능 엔지니어링 파이프 라인을 복제하는 것은 복잡하고 시간이 많이 소요되는 프로세스로, 제대로 구현되지 않으면 모델 불일치가 발생할 수 있습니다. 모델 학습에 사용 된 기능 세트가 학습 단계 이후에 변경되면 모델을 재현하는 것이 어렵거나 불가능할 수 있습니다.
AWS에 상주하는 애플리케이션에는 일반적으로 개발, 테스트, 스테이징 및 프로덕션과 같은 여러 가지 고유 한 환경 및 계정이 있습니다. 다양한 환경에서 애플리케이션을 자동으로 배포하기 위해 CI / CD 파이프 라인을 사용합니다. 조직은 종종 동일하거나 다른 AWS 리전 또는 다른 AWS 계정에서 격리 된 작업 환경과 여러 데이터 복사본을 유지해야합니다. 기능 저장소의 맥락에서 일부 회사는 오프라인 기능 저장소 데이터를 복제하려고 할 수 있습니다. 다음을 통한 오프라인 저장소 복제 Amazon S3 복제 이 경우 유용한 패턴이 될 수 있습니다. 이 패턴을 사용하면 격리 된 환경 및 계정이 교차 계정 역할 또는 권한을 사용하지 않고 전체 기능 세트를 사용하여 ML 모델을 재교육 할 수 있습니다.
결론
이 게시물에서는 기능 간 데이터 과학 협업에 필수적인 SageMaker 기능 저장소에 대한 중앙 집중식 기능 저장소, 결합 된 기능 저장소 및 기타 설계 고려 사항과 같은 다양한 아키텍처 패턴을 시연했습니다. 또한 AWS STS를 사용하여 교차 계정 액세스를 설정하는 방법도 보여주었습니다.
기능 저장소 기능 및 사용 사례에 대한 자세한 내용은 다음을 참조하십시오. Amazon SageMaker Feature Store의 주요 기능 이해 및 Amazon SageMaker Feature Store와 함께 스트리밍 수집을 사용하여 거의 실시간으로 ML 기반 의사 결정.
의견이나 질문이 있으면 의견란에 남겨주세요.
저자에 관하여
아룬 프라 사스 샨 카르 AWS의 인공 지능 및 기계 학습 (AI / ML) 전문 솔루션 아키텍트로서 글로벌 고객이 클라우드에서 AI 솔루션을 효과적이고 효율적으로 확장 할 수 있도록 지원합니다. 여가 시간에 Arun은 공상 과학 영화를보고 클래식 음악을 듣는 것을 즐깁니다.
마크 로이 AWS의 주요 기계 학습 설계자로서 AWS 고객이 AI / ML 솔루션을 설계하고 구축 할 수 있도록 지원합니다. Mark의 작업은 컴퓨터 비전, 딥 러닝 및 기업 전반의 ML 확장에 대한 주요 관심과 함께 광범위한 ML 사용 사례를 다룹니다. 그는 보험, 금융 서비스, 미디어 및 엔터테인먼트, 의료, 공익 사업 및 제조를 포함한 여러 산업 분야의 기업을 도왔습니다. Mark는 ML Specialty Certification을 포함하여 6 개의 AWS 인증을 보유하고 있습니다. AWS에 합류하기 전에 Mark는 금융 서비스 분야에서 25 년을 포함하여 19 년 이상 아키텍트, 개발자 및 기술 리더였습니다.
스테판 나투 Amazon Web Services의 선임 AI / ML 전문 솔루션 아키텍트입니다. 그는 금융 서비스 고객이 AWS에서 엔드 투 엔드 기계 학습 솔루션을 구축하도록 돕는 데 주력하고 있습니다. 여가 시간에는 기계 학습 블로그 읽기, 기타 연주, 뉴욕의 음식 현장 탐험을 즐깁니다.
- 가속 자
- ACCESS
- 계정
- 동작
- 추가
- 양자
- AI
- AI 채택
- 아마존
- 아마존 세이지 메이커
- Amazon Web Services
- 중
- API를
- 어플리케이션
- 어플리케이션
- 아키텍처
- 인공 지능
- 인공 지능과 기계 학습
- 자동화
- AWS
- 무대 뒤에서
- 블로그
- 빌드
- 건물
- 전화
- 가지 경우
- 인증
- City
- 클라이언트
- 클라우드
- 암호
- 협동
- 댓글
- 공통의
- 기업
- 회사
- compliance
- 구성 요소
- 화합물
- 컴퓨터 비전
- 소비
- 소비자
- 함유량
- 신임장
- 고객
- 데이터
- 데이터 액세스
- 데이터 과학
- 깊은 학습
- 디자인
- 세부 묘사
- 개발
- 개발자
- 개발
- 전자 상거래
- 엔지니어링
- 엔지니어
- Enterprise
- 엔터테인먼트
- 환경
- 실행
- 특색
- 특징
- 금융
- 금융 서비스
- 먼저,
- 식품
- 형태
- 가득 찬
- 기능
- GitHub의
- 글로벌
- 통치
- 보조금
- 그룹
- 건강 관리
- 보유
- 방법
- How To
- HTTPS
- IAM
- 확인
- 통합 인증
- 포함
- 산업
- 정보
- 인프라
- 보험
- 인텔리전스
- 관심
- IT
- 일
- 작업
- 어울리다
- 유지
- 키
- 지식
- 넓은
- 리드
- 배우다
- 배우기
- 이점
- 제한된
- 명부
- 청취
- 지방의
- 장소 상에서
- 위치
- 기계 학습
- 구축
- 제조
- 표
- 시장
- 미디어
- ML
- 모델
- 영화 산업
- 음악
- 카테고리
- 새로운 기능
- 새로운 기능
- 뉴욕
- 뉴욕시
- 노트북
- 온라인
- 온라인 상점
- 운영
- 주문
- 기타
- 기타
- 무늬
- 개인
- 플랫폼
- 정책
- 정책
- 풀
- 예측
- 예측
- 제작자
- 프로덕트
- 생산
- 생산력
- 프로젝트
- 게시
- Python
- 품질
- 범위
- 살갗이 벗어 진
- 원시 데이터
- 읽기
- 실시간
- 이유
- 조리법
- 기록
- 관계
- 연구
- 의지
- 자료
- 결과
- 반품
- 리뷰
- 달리기
- 달리는
- 현자
- 규모
- 스케일링
- 과학
- 과학자
- SDK
- 검색
- 보안
- 서비스
- 세트
- 공유
- 공유
- So
- 솔루션
- 성명서
- 저장
- 상점
- 스트리밍
- 성공
- 지원
- 시스템은
- Technology
- 일시적인
- 지원
- 시간
- 토큰
- 트레이닝
- 믿어
- 사용자
- 유용
- 시력
- 걷기
- 웹
- 웹 서비스
- 이내
- 작업
- 일
- 쓰기
- 년