이것은 athenahealth와 공동으로 작성한 게스트 블로그 게시물입니다.
아테나 헬스 전국의 의료 그룹 및 의료 시스템을 위한 네트워크 지원 소프트웨어 및 서비스의 선두 제공업체입니다. 전자 건강 기록, 수익 주기 관리 및 환자 참여 도구를 통해 언제 어디서나 액세스할 수 있으므로 고객에게 더 나은 재정적 결과를 제공하고 공급자 고객이 더 나은 품질의 치료를 제공할 수 있습니다.
인공 지능(AI) 공간에서 thenahealth는 데이터 과학 및 머신 러닝(ML)을 사용하여 비즈니스 프로세스를 가속화하고 여러 서비스에서 권장 사항, 예측 및 통찰력을 제공합니다. 자동화된 문서 서비스의 첫 번째 구현에서 수백만 개의 공급자-환자 문서를 터치 없이 처리하는 것부터 가상 비서에 대한 최신 작업 및 수익 주기 성과 개선에 이르기까지 athenahealth는 계속해서 AI를 적용하여 공급자의 효율성, 서비스 기능 및 더 나은 결과를 촉진하는 데 도움을 주고 있습니다. 그리고 그들의 환자.
이 블로그 게시물은 thenahealth가 사용하는 방법을 보여줍니다. AWS의 Kubeflow (Kubeflow의 AWS 전용 배포)는 필수 도구를 보존하고, 운영 효율성을 최적화하고, 데이터 과학자 생산성을 높이고, ML 기능을 보다 쉽게 확장할 수 있는 단계를 설정하는 종단 간 데이터 과학 워크플로를 구축 및 간소화합니다.
Kubeflow는 Kubernetes에 ML 워크플로를 간단하고 이식 가능하며 확장 가능하게 배포하는 데 전념하는 오픈 소스 ML 플랫폼입니다. Kubeflow는 Kubernetes와 잘 통합되는 관련 오픈 소스 도구를 통합하여 이를 달성합니다. 이러한 프로젝트에는 파이프라인 오케스트레이션을 위한 Argo, 서비스 메시를 위한 Istio, 노트북을 위한 Jupyter, Spark, TensorBoard 및 Katib가 있습니다. Kubeflow Pipelines는 데이터 추출, 사전 처리, 모델 교육, 모델 평가와 같은 단계를 반복 가능한 파이프라인 형태로 포함할 수 있는 이식 가능하고 확장 가능한 ML 워크플로를 구축하고 배포하는 데 도움이 됩니다.
AWS는 athenahealth와 같은 조직이 AWS 관리형 서비스와의 통합을 통해 운영 오버헤드를 줄이면서 안정성, 보안성, 이식성 및 확장성이 높은 ML 워크플로를 구축하는 데 도움이 되는 자체 Kubeflow 배포(AWS의 Kubeflow라고 함)를 제공하여 오픈 소스 Kubeflow 커뮤니티에 기여하고 있습니다. AWS는 배포와 같은 다양한 Kubeflow 배포 옵션을 제공합니다. 아마존 코 그니 토, 배포 Amazon 관계형 데이터베이스 서비스 (아마존 RDS) 및 아마존 단순 스토리지 서비스 (Amazon S3) 및 바닐라 배포. 서비스 통합 및 이러한 각 옵션에 사용 가능한 추가 기능에 대한 자세한 내용은 다음을 참조하십시오. 전개.
현재 Kubeflow on AWS는 다음 AWS 서비스로 보강된 Kubeflow 사용에 대한 명확한 경로를 제공합니다.
많은 AWS 고객이 thenahealth를 포함하여 AWS 배포의 Kubeflow를 활용하고 있습니다.
여기에서 thenahealth MLOps 팀은 그들이 직면한 문제와 Kubeflow 여정에서 만든 솔루션에 대해 논의합니다.
이전 ML 환경의 과제
AWS에서 Kubeflow를 채택하기 전에 데이터 과학자들은 표준화된 도구 세트와 주어진 모델을 훈련하는 데 사용되는 기술 및 워크플로의 유연성을 허용하는 프로세스를 사용했습니다. 표준화된 도구의 구성 요소 예에는 데이터 수집 API, 보안 스캐닝 도구, athenahealth 내 다른 팀에서 구축 및 유지 관리하는 CI/CD 파이프라인, MLOps 팀에서 구축 및 유지 관리하는 공통 서비스 플랫폼이 포함됩니다. 그러나 AI 및 ML 사용이 성숙해짐에 따라 각 모델에 대해 생성되는 다양한 도구와 인프라가 증가했습니다. 우리는 여전히 기존 프로세스를 지원할 수 있었지만 다음과 같은 과제가 눈앞에 있음을 확인했습니다.
- 유지 및 성장 – 배포된 모델의 수가 증가함에 따라 모델 교육 환경을 재현하고 유지 관리하는 데 더 많은 노력이 필요했습니다. 각 프로젝트는 각 스크립트가 최종 모델을 구축하는 데 사용된 방법을 설명하는 자세한 문서를 유지했습니다. 많은 경우에 이것은 각각 여러 출력이 있는 5~10개의 스크립트를 포함하는 정교한 프로세스였습니다. 각 출력이 후속 프로세스에서 사용되는 방법에 대한 자세한 지침과 함께 수동으로 추적해야 했습니다. 시간이 지남에 따라 이를 유지하는 것이 번거로웠습니다. 또한 프로젝트가 복잡해짐에 따라 도구의 수도 증가했습니다. 예를 들어, 대부분의 모델은 GPU와 함께 Spark 및 TensorFlow를 활용하므로 더 다양한 환경 구성이 필요했습니다. 시간이 지남에 따라 사용자는 개발 환경에서 최신 버전의 도구로 전환했지만 해당 버전이 호환되지 않으면 이전 스크립트를 실행할 수 없었습니다. 결과적으로 오래된 프로젝트를 유지 관리하고 보강하려면 더 많은 엔지니어링 시간과 노력이 필요했습니다. 또한 새로운 데이터 과학자가 팀에 합류하면서 로컬 환경을 동기화하는 데 문서화되지 않은 종속성이 많이 포함되어 있기 때문에 지식 이전 및 온보딩에 더 많은 시간이 소요되었습니다. 각 모델에 고유한 워크플로가 있었기 때문에 프로젝트 간에 전환할 때 동일한 문제가 발생했습니다.
- 보안 – 우리는 보안을 중요하게 생각하므로 ML 및 데이터 과학과 관련된 모든 계약, 법적 및 규제 의무 준수를 우선시합니다. 데이터는 특정 방식으로 활용, 저장 및 액세스해야 하며, 우리의 관행이 우리의 법적 의무를 준수하고 업계 모범 사례와 일치하도록 하기 위해 강력한 프로세스를 내장했습니다. Kubeflow를 채택하기 전에 데이터가 특정 방식으로 저장되고 액세스되도록 하려면 여러 다양한 워크플로에 대한 정기적인 확인이 필요했습니다. 우리는 이러한 다양한 워크플로를 단일 플랫폼에 통합하여 효율성을 높일 수 있다는 것을 알고 있었습니다. 그러나 해당 플랫폼은 표준화된 도구와 잘 통합될 수 있을 만큼 충분히 유연해야 합니다.
- 행정부 – 워크플로의 로깅 및 모니터링을 중앙 집중화하여 운영 효율성과 관리를 향상할 수 있는 기회도 보았습니다. 각 팀이 자체 도구를 개발했기 때문에 각 워크플로에서 이 정보를 개별적으로 수집하고 집계했습니다.
데이터 과학 팀은 워크플로를 통합하기 위한 다양한 솔루션을 평가했습니다. 이러한 요구 사항을 해결하는 것 외에도 기존의 표준화된 인프라 및 도구와 원활하게 통합되는 솔루션을 찾았습니다. 워크플로 솔루션으로 Amazon EKS 및 Kubeflow on AWS를 선택했습니다.
Kubeflow를 통합한 데이터 과학자 개발 주기
데이터 과학 프로젝트는 데이터도, 코드도, ML로 해결할 수 있는 비즈니스 문제만 있는 깨끗한 상태에서 시작됩니다. 첫 번째 작업은 Snowflake 데이터 웨어하우스에서 원시 데이터 세트를 쿼리하는 것으로 시작하여 ML 모델이 비즈니스 문제를 효과적으로 해결할 수 있도록 데이터가 충분한 신호를 보유하고 있는지 확인하는 개념 증명(POC)입니다. 이 단계는 반복적이며 데이터 과학자는 이 프로세스 중에 Kubernetes 포드 또는 Kubeflow Jupyter 노트북을 사용합니다.
Kubeflow 클러스터는 Karpenter 클러스터 자동 확장 처리를 사용하므로 데이터 과학자는 원하는 인스턴스 유형을 정의하는 데만 집중하면 되며 프로비저닝 작업은 사전 정의된 Karpenter 프로비저닝 도구 세트에 의해 수행되기 때문에 리소스를 쉽게 회전할 수 있습니다. CPU 및 GPU 인스턴스 유형에 대해 별도의 프로비저닝 도구가 있으며 Amazon EKS에서 지원하는 모든 인스턴스는 프로비저닝 도구 구성에 따라 이 두 범주 중 하나에 속합니다. 데이터 과학자는 노드 선택기를 사용하여 인스턴스 유형을 선택하고 Karpenter는 노드 수명 주기 관리를 처리합니다.
쿼리가 개발된 후 데이터 과학자는 원시 데이터를 Amazon S3의 위치로 추출한 다음 AWS Kubeflow UI에서 Jupyter 노트북을 시작하여 데이터를 탐색합니다. 목표는 첫 번째 모델을 훈련하는 데 사용할 기능 세트를 만드는 것입니다. 이를 통해 데이터 과학자는 데이터에 고객의 비즈니스 요구를 충족하기에 충분한 신호가 있는지 확인할 수 있습니다.
결과가 만족스러우면 데이터 과학자는 개발 주기의 다음 단계로 이동하여 발견한 내용을 강력한 파이프라인으로 전환합니다. POC 코드를 대규모로 실행되는 프로덕션 품질의 코드로 변환합니다. 승인된 라이브러리를 사용하여 규정 준수를 보장하기 위해 적절한 기본 Docker 이미지로 컨테이너가 생성됩니다. 데이터 과학자의 경우 표준 Python, TensorFlow 및 Spark 기본 이미지를 제공하면 전부는 아니지만 대부분의 워크로드에 충분한 유연성을 제공한다는 것을 알게 되었습니다. 그런 다음 구성 요소의 Dockerfile을 사용하여 개발 환경을 추가로 사용자 지정할 수 있습니다. 그런 다음 이 Dockerfile을 CI/CD 프로세스에서 활용하여 프로덕션에서 사용할 구성 요소 이미지를 빌드하므로 개발 환경과 프로덕션 환경 간의 일관성을 유지합니다.
우리는 데이터 과학자에게 Kubernetes에서 실행되는 포드에서 개발 환경을 시작할 수 있는 기능을 제공하는 도구를 보유하고 있습니다. 이 포드가 실행 중일 때 데이터 과학자는 Visual Studio Code IDE를 포드에 직접 연결하고 모델 코드를 디버그할 수 있습니다. 코드가 성공적으로 실행되면 변경 사항을 git에 푸시할 수 있으며 가장 최근 변경 사항으로 새 개발 환경이 생성됩니다.
표준 데이터 과학 파이프라인은 추출, 전처리, 교육 및 평가를 포함하는 단계로 구성됩니다. 파이프라인의 각 단계는 Kubeflow에서 구성 요소로 나타납니다. Kubeflow는 매개 변수로 전달된 일부 정보와 함께 명령을 실행하는 Kubernetes 포드로 구성됩니다. 이러한 매개변수는 정적 값이거나 이전 구성요소의 출력에 대한 참조일 수 있습니다. 포드에서 사용되는 Docker 이미지는 CI/CD 프로세스에서 빌드됩니다. 이 프로세스에 대한 세부 정보는 다음 섹션에서 설명하는 CI/CD 워크플로에 나와 있습니다.
Kubeflow의 개발 주기. 개발 워크플로는 POC와 함께 왼쪽에서 시작됩니다. 완성된 모델은 Amazon ECS에서 실행되는 athenahealth 모델 제공 플랫폼에 배포됩니다.
자동화된 워크플로를 지원하는 CI/CD 프로세스
CI/CD 프로세스의 일부로 Jenkins를 사용하여 모든 Kubeflow 구성 요소 이미지를 병렬로 빌드하고 테스트합니다. 성공적으로 완료되면 파이프라인 구성 요소 템플릿에 이미지에 대한 참조 포인터가 포함되고 결과 파이프라인이 Kubeflow에 업로드됩니다. Jenkins 파이프라인의 매개변수를 사용하면 성공적인 빌드 후 파이프라인을 시작하고 모델 교육 테스트를 실행할 수 있습니다.
또는 짧은 개발 주기를 유지하기 위해 데이터 과학자는 로컬 시스템에서 파이프라인을 시작하여 실험 중인 파이프라인 매개변수를 수정할 수도 있습니다.
CI/CD 빌드의 참조 포인터가 기본적으로 활용되도록 하는 도구가 있습니다. 리포지토리에 배포 가능한 아티팩트가 있는 경우 CI/CD 로직은 다음을 사용하여 Amazon ECS에서 실행되는 athenahealth 모델 제공 플랫폼(예측 서비스)에 아티팩트를 계속 배포합니다. AWS 파게이트. 이 모든 단계를 거친 후 데이터 과학자는 코드를 기본 분기에 병합합니다. 그런 다음 파이프라인과 배포 가능한 아티팩트가 프로덕션으로 푸시됩니다.
CI/CD 배포 워크플로. 이 다이어그램은 데이터 과학 빌드 및 배포 워크플로를 설명합니다. CI/CD 프로세스는 젠킨스.
보안
데이터 과학 워크플로를 통합하면서 교육 파이프라인을 보호하는 접근 방식을 중앙 집중화할 수 있었습니다. 이 섹션에서는 데이터 및 클러스터 보안에 대한 접근 방식에 대해 설명합니다.
데이터 보안
데이터 보안은 athenahealth에서 가장 중요합니다. 이러한 이유로 우리는 이러한 데이터의 보안과 무결성을 보호하는 규정과 표준을 완전히 준수하는 인프라를 개발하고 유지 관리합니다.
데이터 규정 준수 표준을 충족하기 위해 athenahealth 엔터프라이즈 지침에 따라 AWS 인프라를 프로비저닝합니다. 데이터를 위한 두 가지 기본 저장소는 확장성이 뛰어난 파이프라인 메타데이터를 위한 Amazon RDS와 파이프라인 및 모델 아티팩트를 위한 Amazon S3입니다. Amazon S3의 경우 버킷이 암호화되고 HTTPS 엔드포인트가 시행되며 버킷 정책 및 AWS 자격 증명 및 액세스 관리 (IAM) 역할은 데이터에 대한 액세스를 허용할 때 최소 권한 원칙을 따릅니다. 이는 Amazon RDS 데이터에도 해당됩니다. 암호화는 항상 활성화되어 있고 보안 그룹 및 자격 증명 액세스는 최소 권한 원칙을 따릅니다. 이 표준화는 승인된 당사자만 데이터에 액세스할 수 있도록 하고 이 액세스를 추적합니다.
이러한 조치 외에도 플랫폼은 보안 위협 평가와 지속적인 보안 및 규정 준수 검사를 받습니다.
또한 민감한 데이터가 포함된 모든 S3 버킷에 대한 데이터 수명 주기 관리를 통해 데이터 보존 요구 사항을 해결합니다. 이 정책은 자동으로 데이터를 다음으로 이동합니다. 아마존 S3 빙하 생성 후 30일. 이에 대한 예외는 데이터 검색 요청을 통해 관리되며 사례별로 승인 또는 거부됩니다. 이렇게 하면 모든 워크플로가 데이터 보존 정책을 준수할 수 있습니다. 이것은 또한 모델의 성능이 좋지 않고 재교육이 필요한 경우 또는 이전 모델 데이터 세트의 과거 반복에 대해 새 모델을 평가해야 하는 경우 데이터 복구 문제를 해결합니다.
AWS 및 Amazon EKS의 Kubeflow 내에서 Amazon S3 및 Amazon RDS에 대한 액세스를 제한하기 위해 Kubernetes 내 리소스에 대한 IAM 기반 권한 프로비저닝을 제공하는 IRSA(서비스 계정용 IAM 역할)를 사용합니다. Kubeflow의 각 테넌트에는 테넌트 액세스 요구 사항을 충족하기 위해 특별히 생성된 IAM 역할에 바인딩하는 고유한 미리 생성된 서비스 계정이 있습니다. 테넌트에 대한 사용자 액세스도 각 사용자에 대한 Amazon Cognito 사용자 풀 그룹 멤버십을 사용하여 제한됩니다. 사용자가 클러스터에 인증되면 생성된 토큰에는 그룹 클레임이 포함되고 Kubernetes RBAC는 이 정보를 사용하여 클러스터의 특정 리소스에 대한 액세스를 허용하거나 거부합니다. 이 설정은 다음 섹션에서 더 자세히 설명합니다.
다중 사용자 격리를 사용한 클러스터 보안
이전 섹션에서 언급했듯이 데이터 과학자는 탐색적 데이터 분석을 수행하고 데이터 분석을 실행하며 ML 모델을 훈련합니다. 리소스를 할당하고, 데이터를 구성하고, 프로젝트를 기반으로 워크플로를 관리하기 위해 Kubeflow on AWS는 Kubernetes 네임스페이스를 기반으로 격리를 제공합니다. 이 격리는 Kubeflow UI와 상호 작용하기 위해 작동합니다. 그러나 Kubectl을 사용하여 Kubernetes API에 대한 액세스를 제어하는 도구는 제공하지 않습니다. 즉, 사용자 액세스는 Kubeflow UI에서 제어할 수 있지만 Kubectl을 통해 Kubernetes API를 통해 제어할 수는 없습니다.
다음 다이어그램에 설명된 아키텍처는 그룹 멤버십을 기반으로 Kubeflow의 프로젝트에 대한 액세스를 통합하여 이 문제를 해결합니다. 이를 달성하기 위해 Amazon Cognito 사용자 풀과 통합된 Kubeflow on AWS 매니페스트를 활용했습니다. 또한 Kubernetes RBAC(역할 기반 액세스 제어)를 사용하여 클러스터 내에서 권한 부여를 제어합니다. 사용자 권한은 Amazon Cognito 그룹 멤버십을 기반으로 프로비저닝됩니다. 이 정보는 OIDC 클라이언트가 생성한 토큰과 함께 클러스터에 전달됩니다. OIDC 자격 증명 공급자를 연결하여 클러스터를 인증할 수 있는 내장 Amazon EKS 기능 덕분에 이 프로세스가 간소화되었습니다.
기본적으로 Amazon EKS 인증은 IAM 자격 증명을 사용하여 EKS 클러스터에 인증할 수 있는 도구인 IAM 인증자가 수행합니다. 이 인증 방법에는 장점이 있습니다. 그러나 athenahealth는 조직 전체의 ID 서비스에 Microsoft Azure Active Directory를 사용하기 때문에 우리의 사용 사례에는 적합하지 않습니다.
Kubernetes 네임스페이스 격리. 데이터 과학자는 작업에 필요에 따라 단일 또는 여러 그룹의 회원 자격을 얻을 수 있습니다. 액세스는 정기적으로 검토되고 적절하게 제거됩니다.
전사적 ID 서비스인 Azure Active Directory는 Kubeflow 클러스터에 대한 사용자 액세스를 제어하기 위한 정보 소스입니다. 이를 위한 설정에는 서비스 주체 역할을 하는 Azure 엔터프라이즈 애플리케이션 만들기 및 클러스터에 액세스해야 하는 다양한 테넌트에 대한 그룹 추가가 포함됩니다. Azure의 이 설정은 인증 책임을 Azure에 아웃소싱하는 연합 OIDC 자격 증명 공급자를 설정하여 Amazon Cognito에서 미러링됩니다. Azure 그룹에 대한 액세스는 SailPoint IdentityIQ에 의해 제어되며, 프로젝트 소유자에게 액세스 요청을 보내 적절하게 허용하거나 거부합니다. Amazon Cognito 사용자 풀에서 두 개의 애플리케이션 클라이언트가 생성됩니다. 하나는 OIDC 자격 증명 공급자를 사용하여 Kubernetes 클러스터에 대한 인증을 설정하는 데 사용되고 다른 하나는 Kubeflow UI에 대한 Kubeflow 인증을 보호하는 데 사용됩니다. 이러한 클라이언트는 클러스터 인증 시 그룹 클레임을 전달하도록 구성되며 이러한 그룹 클레임은 RBAC와 함께 사용되어 클러스터 내에서 권한 부여를 설정합니다.
Kubernetes RBAC 역할 바인딩은 클러스터에 Kubeflow를 설치할 때 생성되는 클러스터 역할 Kubeflow-edit와 그룹 간에 설정됩니다. 이 역할 바인딩은 OIDC를 통해 로그인한 후 클러스터와 상호 작용하는 모든 사용자가 그룹 클레임에 정의된 권한이 있는 네임스페이스에 액세스할 수 있도록 합니다. 이것은 Kubectl을 사용하여 클러스터와 상호 작용하는 사용자에게 작동하지만 Kubeflow UI는 현재 RBAC를 사용하지 않기 때문에 그룹 멤버십을 기반으로 사용자에게 액세스 권한을 프로비저닝하지 않습니다. 대신 Istio 권한 부여 정책 리소스를 사용하여 사용자에 대한 액세스를 제어합니다. 이 문제를 극복하기 위해 Amazon Cognito 그룹을 폴링하여 사용자를 동기화하고 그룹이 아닌 각 사용자에 대해 해당 역할 바인딩을 추가하거나 제거하는 사용자 지정 컨트롤러를 개발했습니다. 이 설정을 통해 사용자는 Kubeflow UI 및 Kubectl과 상호 작용할 때 동일한 수준의 권한을 가질 수 있습니다.
운영 효율성
이 섹션에서는 워크플로를 관리 및 디버그하고 Kubeflow 업그레이드의 운영 영향을 최소화하기 위해 사용할 수 있는 오픈 소스 및 AWS 도구를 어떻게 활용했는지 논의합니다.
로깅 및 모니터링
로깅을 위해 FluentD를 사용하여 모든 컨테이너 로그를 아마존 오픈서치 서비스 및 시스템 메트릭을 Prometheus에 제공합니다. 그런 다음 Kibana와 Grafana UI를 사용하여 로그와 메트릭을 검색하고 필터링합니다. 다음 다이어그램은 이를 설정하는 방법을 설명합니다.
Kubeflow 로깅. Grafana UI와 Kibana를 모두 사용하여 로그를 보고 선별합니다.
다음 스크린샷은 파이프라인의 Kibana UI 보기입니다.
샘플 Kibana UI 보기. Kibana는 사용자 정의 보기를 허용합니다.
안전한 Kubeflow 클러스터 업그레이드
사용자를 AWS의 Kubeflow에 온보딩하면서 MLOps 팀이 새로운 기능을 릴리스 및 통합하는 데 민첩성을 유지할 수 있도록 하면서 안정적이고 일관된 사용자 경험을 유지합니다. 표면적으로 Kustomize는 다른 구성 요소에 영향을 주지 않고 한 번에 하나의 구성 요소를 작업하고 업그레이드할 수 있도록 하는 모듈식으로 보입니다. 그러나 실제로 가장 좋은 방법은 기존 클러스터에 구성 요소 수준 업그레이드를 적용하는 것보다 단순히 새로운 Kubernetes 클러스터를 가동하는 것입니다. 완전히 새로운 클러스터를 만드는 것이 더 합리적인 두 가지 사용 사례를 찾았습니다.
- AWS가 인플레이스 클러스터 업그레이드를 제공하는 Kubernetes 버전으로 업그레이드. 그러나 각 Kubeflow 및 Kubernetes 리소스가 의도한 대로 작동하고 매니페스트가 이전 버전과의 호환성을 유지하는지 테스트하기가 어려워집니다.
- 여러 기능이 추가되거나 수정된 최신 릴리스로 Kubeflow를 업그레이드하고 거의 항상 기존 Kubernetes 클러스터에서 인플레이스 업그레이드를 수행하는 것은 유망한 아이디어가 아닙니다.
이 문제를 해결하기 위해 기존 워크로드에 영향을 주지 않고 클러스터를 안전하게 교체할 수 있는 전략을 개발했습니다. 이를 달성하기 위해 다음 기준을 충족해야 했습니다.
- Kubeflow 스토리지와 컴퓨팅 리소스를 분리하여 이전 클러스터를 디프로비저닝할 때 파이프라인 메타데이터, 파이프라인 아티팩트 및 사용자 데이터가 유지되도록 합니다.
- Kubeflow 버전 업그레이드가 발생할 때 최소한의 변경만 필요하도록 Kubeflow on AWS 매니페스트와 통합
- 클러스터 업그레이드 후 문제가 발생하는 경우 손쉽게 롤백할 수 있습니다.
- 후보 클러스터를 프로덕션으로 승격하기 위한 간단한 인터페이스 보유
다음 다이어그램은이 아키텍처를 보여줍니다.
안전한 Kubeflow 클러스터 업그레이드. Kubeflow Candidate의 테스트가 성공하면 Route 53에 대한 업데이트를 통해 Kubeflow Prod로 승격됩니다.
Kubeflow on AWS 매니페스트는 Amazon RDS 및 Amazon S3 통합과 함께 사전 패키징되어 제공됩니다. 이러한 관리 서비스를 공통 데이터 저장소로 사용하여 청록색 배포 전략을 설정할 수 있습니다. 이를 달성하기 위해 파이프라인 메타데이터가 EKS 클러스터와 독립적으로 작동하는 Amazon RDS에 유지되고 파이프라인 로그 및 아티팩트가 Amazon S3에 유지되도록 했습니다. 파이프라인 메타데이터 및 아티팩트 외에도 포드 로그를 Amazon OpenSearch Service로 라우팅하도록 FluentD를 설정했습니다.
이를 통해 스토리지 계층이 컴퓨팅 계층과 완전히 분리되어 완전히 새로운 EKS 클러스터에서 Kubeflow 버전 업데이트 중에 변경 사항을 테스트할 수 있습니다. 모든 테스트가 성공하면 간단히 변경할 수 있습니다. 아마존 경로 53 Kubeflow를 호스팅하는 후보 클러스터에 대한 DNS 레코드. 또한 롤백해야 할 경우를 대비하여 며칠 동안 이전 클러스터를 백업으로 실행합니다.
ML 파이프라인에 대한 AWS 기반 Amazon EKS 및 Kubeflow의 이점
Amazon EKS 및 Kubeflow on AWS 패키지는 반복 가능한 모델 교육을 강력하게 권장하는 패턴으로 개발 워크플로를 옮겼습니다. 이러한 도구를 사용하면 완전히 정의된 테넌트와 함께 완전히 정의된 클러스터를 보유하고 완전히 정의된 코드를 실행할 수 있습니다.
이 플랫폼을 구축함으로써 얻은 많은 성과는 덜 정량적이며 플랫폼 개발자와 사용자 모두를 위해 워크플로가 개선된 방식과 더 관련이 있습니다. 예를 들어, MinIO는 Amazon S3에 대한 직접 액세스로 대체되어 원래 워크플로에 더 가깝게 이동하고 유지 관리해야 하는 서비스 수를 줄였습니다. 또한 Amazon RDS를 Kubeflow의 백엔드로 활용할 수 있어 클러스터 간 마이그레이션이 더 쉬워지고 파이프라인을 야간에 백업할 수 있습니다.
또한 AWS 관리형 서비스와 Kubeflow 통합의 개선 사항이 유용하다는 것을 발견했습니다. 예를 들어, AWS 매니페스트의 Kubeflow에 미리 구성된 Amazon RDS, Amazon S3 및 Amazon Cognito를 사용하면 최신 Kubeflow 배포로 업데이트하는 시간과 노력을 절약할 수 있습니다. 공식 Kubeflow 매니페스트를 수동으로 수정했던 경우 새 버전으로 업데이트하려면 디자인에서 테스트까지 몇 주가 걸렸습니다.
Amazon EKS로 전환하면 Kustomize(현재 Kubectl의 일부) 및 Terraform에서 클러스터를 정의할 수 있습니다. 플랫폼 작업의 경우 Kubernetes와 Terraform은 충분한 시간을 투자하여 작업하기가 매우 쉽습니다. 많은 반복 후에 우리가 사용할 수 있는 도구를 사용하면 구성 요소 업그레이드 또는 전체 개발 클러스터 교체와 같은 표준 플랫폼 작업을 매우 쉽게 수행할 수 있습니다. 원시에서 작업을 실행하는 것과 비교 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 인스턴스에서는 보장된 리소스 정리 및 재시도 메커니즘이 내장된 잘 정의된 포드가 있는 것과 얼마나 큰 차이가 있는지 비교하기 어렵습니다.
Kubernetes는 훌륭한 보안 표준을 제공하며 다중 사용자 격리를 통해 수행할 수 있는 작업의 표면만 긁었습니다. 우리는 교육 플랫폼이 프로덕션 수준의 데이터를 생성하고 우리 팀 외부의 개발자를 영입할 때 다중 사용자 격리가 미래에 더 많은 보상을 얻을 수 있는 패턴으로 보고 있습니다.
한편 Kubeflow를 사용하면 재현 가능한 모델 훈련을 할 수 있습니다. 동일한 데이터를 사용하더라도 동일한 모델을 생성하는 훈련은 없지만 차선책이 있습니다. Kubeflow를 사용하면 모델을 훈련하는 데 어떤 코드와 데이터가 사용되었는지 정확히 알 수 있습니다. 파이프라인의 각 단계가 명확하고 프로그래밍 방식으로 정의되어 있기 때문에 온보딩이 크게 향상되었습니다. 새로운 데이터 과학자가 버그를 수정하는 작업을 수행할 때 단계 간에 코드 출력이 사용되는 방식에 대한 명확한 구조가 있기 때문에 훨씬 덜 손을 댈 필요가 없습니다.
또한 Kubeflow를 사용하면 단일 EC2 인스턴스에서 실행하는 것과 비교하여 성능이 크게 향상됩니다. 종종 모델 교육에서 데이터 과학자는 전처리 및 교육을 위해 다양한 도구와 최적화가 필요합니다. 예를 들어 전처리는 종종 Spark와 같은 분산 데이터 처리 도구를 사용하여 실행되는 반면 훈련은 GPU 인스턴스를 사용하여 실행되는 경우가 많습니다. Kubeflow 파이프라인을 사용하면 파이프라인의 여러 단계에 대해 다른 인스턴스 유형을 지정할 수 있습니다. 이를 통해 한 단계에서는 강력한 GPU 인스턴스를 사용하고 다른 단계에서는 분산 처리를 위해 더 작은 시스템을 사용할 수 있습니다. 또한 Kubeflow 파이프라인은 단계 간의 종속성을 설명하기 때문에 파이프라인은 단계를 병렬로 실행할 수 있습니다.
마지막으로 클러스터에 테넌트를 추가하는 프로세스를 만들었기 때문에 이제 클러스터의 테넌트에 팀을 등록하는 보다 공식적인 방법이 있습니다. Kubecost를 사용하여 EKS 클러스터의 비용을 추적하기 때문에 모든 데이터 과학 프로젝트를 포함하는 계정 수준에서 비용이 귀속되는 대신 단일 프로젝트에 비용을 귀속할 수 있습니다. Kubecost는 파이프라인 실행을 담당하는 테넌트 또는 팀과 밀접하게 연결된 네임스페이스당 지출에 대한 보고서를 제공합니다.
모든 이점에도 불구하고 사용자의 완전한 동의가 있는 경우에만 이러한 종류의 마이그레이션을 수행하도록 주의할 것입니다. 시간을 투자한 사용자는 Amazon EKS 및 Kubernetes를 사용하여 많은 이점을 얻지만 상당한 학습 곡선이 있습니다.
결론
엔드 투 엔드 ML 인프라에 Kubeflow on AWS 파이프라인을 구현하여 필수 도구(예: CI/CD 및 모델 제공)를 유지하면서 데이터 과학 워크플로를 통합하고 표준화할 수 있었습니다. 이제 데이터 과학자는 완전히 다른 도구 집합을 유지 관리하는 방법을 배우는 오버헤드 없이 이 워크플로를 기반으로 프로젝트 간에 이동할 수 있습니다. 일부 모델의 경우 더 많은 훈련 반복을 허용하고 결과적으로 더 나은 예측으로 모델을 생성할 수 있는 새로운 워크플로의 속도(XNUMX배 더 빠름)에 매우 놀랐습니다.
또한 MLOps 기능을 강화하고 프로젝트 수와 규모를 확장할 수 있는 견고한 기반을 구축했습니다. 예를 들어, 모델 계보 및 추적에서 거버넌스 태세를 강화하면서 15개 이상의 워크플로에서 단 하나로 초점을 줄였습니다. 그리고 4년 말에 Log2021shell 취약점이 밝혀졌을 때 우리는 단일 워크플로에 집중하고 필요에 따라 신속하게 수정할 수 있었습니다. Amazon Elastic Container Registry (Amazon ECR) 스캔, Amazon OpenSearch Service 업그레이드, 도구 업데이트 등) 데이터 과학자의 지속적인 작업에 미치는 영향을 최소화합니다. AWS 및 Kubeflow 개선 사항을 사용할 수 있게 되면 적절하다고 판단되는 대로 통합할 수 있습니다.
이를 통해 AWS에서 Kubeflow를 채택하는 데 있어 중요하면서도 절제된 측면을 알 수 있습니다. 이 여정의 중요한 결과 중 하나는 데이터 과학자를 위해 Kubeflow에 대한 업그레이드 및 개선 사항을 원활하게 롤아웃하는 기능입니다. 이전에 이에 대한 접근 방식을 논의했지만 AWS에서 제공하는 Kubeflow 매니페스트도 사용합니다. 우리는 버전 2019이 출시되기 전인 1.0.0년에 개념 증명으로 Kubeflow 여정을 시작했습니다. (현재 1.4.1을 사용 중이며 1.5를 평가 중입니다. AWS는 이미 1.6 버전을 작업 중입니다.) 그 사이 3년 동안 상당한 콘텐츠가 포함된 릴리스가 XNUMX개 이상 있었습니다. AWS의 Kubeflow 팀은 이러한 업그레이드를 통합 및 검증하고 예측 가능하고 신뢰할 수 있는 일정에 따라 매니페스트를 릴리스하는 훈련된 접근 방식을 통해 athenahealth MLOps 팀이 개발 로드맵을 계획하고 결과적으로 리소스 할당 및 초점 영역을 계획할 수 있도록 하는 데 중요했습니다. , 더 큰 자신감을 가지고 미래로 나아가십시오.
당신은 AWS Labs GitHub 리포지토리 Kubeflow에 대한 모든 AWS 기여를 추적합니다. 다음에서 AWS 팀을 찾을 수도 있습니다. Kubeflow #AWS Slack 채널; 귀하의 피드백은 AWS가 Kubeflow 프로젝트에 기여할 다음 기능의 우선 순위를 정하는 데 도움이 됩니다.
저자 소개
칸월짓 쿠르미 Amazon Web Services의 수석 솔루션 아키텍트입니다. 그는 AWS 고객과 협력하여 AWS를 사용할 때 솔루션의 가치를 향상시키는 데 도움이 되는 지침과 기술 지원을 제공합니다. Kanwaljit은 컨테이너화 및 기계 학습 애플리케이션으로 고객을 돕는 것을 전문으로 합니다.
타일러 칼바흐 athenahealth에서 기술 직원의 주요 구성원입니다. Tyler는 의료 분야에서 분석, 데이터 과학, 신경망 및 기계 학습 애플리케이션 개발 분야에서 약 7년의 경험을 가지고 있습니다. 그는 현재 프로덕션 트래픽을 제공하는 여러 기계 학습 솔루션에 기여했습니다. 현재 thenahealth의 엔지니어링 조직에서 수석 데이터 과학자로 일하고 있는 Tyler는 초기부터 thenahealth를 위한 새로운 기계 학습 교육 플랫폼을 구축한 팀의 일원이었습니다.
빅터 크릴로프 athenahealth에서 기술 직원의 주요 구성원입니다. Victor는 엔지니어이자 스크럼 마스터로, 데이터 과학자가 안전하고 빠른 기계 학습 파이프라인을 구축하는 데 도움을 줍니다. thenahealth에서 그는 인터페이스, 임상 주문, 처방, 일정, 분석 및 현재 기계 학습에 대해 작업했습니다. 그는 깔끔하게 작성되고 잘 테스트된 코드를 중요하게 생각하지만 코드 한 줄에 대한 건강에 해로운 집착을 가지고 있습니다. 여가 시간에는 개를 산책시키면서 팟캐스트를 듣는 것을 즐깁니다.
사산크 베무리 athenahealth에서 기술 직원의 수석 멤버입니다. 그는 의료, 보험 및 생물정보학과 같은 영역에서 데이터 기반 솔루션을 개발한 경험이 있습니다. Sasank는 현재 ML 솔루션을 대규모로 교육하고 배포하는 데 도움이 되는 AWS 및 Kubernetes에서 기계 학습 교육 및 추론 플랫폼을 설계하고 개발하는 일을 하고 있습니다.
아누 툼쿠르 athenahealth의 건축가입니다. Anu는 기계 학습, 클라우드 운영, 빅 데이터, 실시간 분산 데이터 파이프라인, 광고 기술, 데이터 분석, 소셜 미디어 분석 분야에서 다양한 소프트웨어 제품을 구축하는 XNUMX년 이상의 아키텍처, 설계, 개발 경험을 보유하고 있습니다. Anu는 현재 Machine Learning Platform 및 Data Pipeline 팀의 athenahealth 제품 엔지니어링 조직에서 설계자로 일하고 있습니다.
윌리엄 첸 athenahealth의 수석 엔지니어링 관리자입니다. 그는 의료 IT, 빅 데이터 분산 컴퓨팅, 지능형 광 네트워크, 실시간 비디오 편집 시스템, 엔터프라이즈 소프트웨어 및 그룹 의료 보험 분야에서 솔루션을 구축하는 엔지니어링 리더십 경험을 20년 이상 가지고 있습니다. William은 현재 Product Engineering 조직의 Machine Learning Operations 및 DevOps 엔지니어링 팀인 athenahealth에서 두 개의 멋진 팀을 이끌고 있습니다.
