IAM 역할 및 정책을 사용하여 사용자 그룹마다 액세스 수준을 다르게 설정합니다. 예를 들어 ML 연구원, 데이터 과학자, DevOps, 사이트 안정성 엔지니어는 모두 동일한 피처스토어에 액세스해야 하지만 액세스 수준은 다를 수 있습니다. 예를 들어 DevOps 사용자에게는 피처스토어를 관리할 수 있는 권한이 필요하지만 피처스토어의 콘텐츠에 액세스할 필요는 없습니다.
리소스 수준 IAM 정책을 사용하여 특정 피처스토어 또는 항목 유형에 대한 액세스를 제한할 수도 있습니다.
예를 들어 조직에 다음과 같은 캐릭터가 포함되어 있다고 가정해 보겠습니다.
각 캐릭터에게는 저마다 다른 수준의 액세스 권한이 필요하기 때문에 사전 정의된 IAM 역할이 각기 다르게 할당됩니다. 고유한 맞춤 역할을 만들고 사용할 수도 있습니다.
캐릭터
설명
사전 정의된 역할
ML 연구원 또는 비즈니스 분석가
특정 항목 유형의 데이터만 보는 사용자
roles/aiplatform.featurestoreDataViewer(프로젝트 또는 리소스 수준에서 부여할 수 있음)
데이터 과학자 또는 데이터 엔지니어
특정 항목 유형 리소스를 사용하는 사용자 자신이 소유한 리소스의 경우 다른 주 구성원에게 액세스 권한을 위임할 수 있습니다.
roles/aiplatform.entityTypeOwner(프로젝트 또는 리소스 수준에서 부여할 수 있음)
IT 또는 DevOps
특정 피처스토어의 성능을 유지관리하고 조정해야 하지만 데이터에 액세스할 필요는 없는 사용자
roles/aiplatform.featurestoreInstanceCreator(프로젝트 또는 리소스 수준에서 부여할 수 있음)
자동화된 데이터 가져오기 파이프라인
특정 항목 유형에 데이터를 쓰는 애플리케이션
roles/aiplatform.featurestoreDataWriter(프로젝트 또는 리소스 수준에서 부여할 수 있음)
사이트 안정성 엔지니어
프로젝트의 특정 피처스토어 또는 모든 피처스토어를 관리하는 사용자
roles/aiplatform.featurestoreAdmin(프로젝트 또는 리소스 수준에서 부여할 수 있음)
전역(Vertex AI Feature Store(기존) 사용자)
사용자가 기존 기능을 보고 검색할 수 있도록 허용합니다. 작업할 기능을 찾으면 특성 소유자에게 액세스 권한을 요청할 수 있습니다.
Google Cloud 콘솔 사용자의 경우 이 역할이 있어야 Vertex AI Feature Store (기존) 방문 페이지, 가져오기 작업 페이지, 일괄 제공 작업 페이지를 볼 수 있습니다.
프로젝트 수준에서 roles/aiplatform.featurestoreResourceViewer 역할을 부여합니다.
일괄 가져오기 최적화를 위한 리소스 모니터링 및 조정
일괄 가져오기 작업을 하려면 작업자가 데이터를 처리하고 작성해야 하므로 featurestore의 CPU 사용률이 증가하고 온라인 서빙 성능에 영향을 미칠 수 있습니다. 온라인 서빙 성능을 유지하는 것이 우선인 경우 온라인 서빙 노드 10개당 1개의 작업자로 시작합니다. 가져오기 중에 온라인 스토리지의 CPU 사용량을 모니터링합니다. CPU 사용량이 예상보다 낮은 경우 향후 일괄 가져오기 작업의 작업자 수를 늘려 처리량을 늘립니다. CPU 사용량이 예상보다 높으면 온라인 서빙 노드 수를 늘려 CPU 용량을 늘리거나, 일괄 가져오기 작업자 수를 낮춥니다. 두 경우 모두 CPU 사용량을 낮출 수 있습니다.
온라인 서빙 노드 수를 늘리면 Vertex AI Feature Store(기존)에 변경사항이 적용된 후 최적의 성능을 얻기까지 약 15분이 걸립니다.
백필은 이전 특성 값을 가져오는 프로세스이며 최근 특성 값에 영향을 주지 않습니다. 이 경우 온라인 저장소에 대한 변경사항을 건너뛰는 온라인 서빙을 사용 중지할 수 있습니다. 자세한 내용은 이전 데이터 백필을 참조하세요.
자동 확장을 사용한 부하 변동 중 비용 절감
Vertex AI Feature Store(기존)를 광범위하게 사용하고 트래픽 패턴의 부하가 자주 변동되는 경우 자동 확장을 사용하여 비용을 최적화하세요.
자동 확장을 사용하면 Vertex AI Feature Store(기존)가 트래픽 패턴을 검토하고 많은 노드 수를 유지하는 대신 CPU 사용률에 따라 노드 수를 자동으로 늘리거나 줄입니다. 이 옵션은 점진적인 증가와 감소가 발생하는 트래픽 패턴에 적합합니다.
온라인 서빙 노드의 성능을 테스트하여 실시간 온라인 서빙 중에 피처스토어의 성능을 확인할 수 있습니다. QPS, 지연 시간, API와 같은 여러 벤치마킹 매개변수를 기반으로 이러한 테스트를 수행할 수 있습니다. 온라인 서빙 노드의 성능을 테스트하려면 다음 가이드라인을 따르세요.
모든 테스트 클라이언트를 동일한 리전에서 실행(Compute Engine 또는 Google Kubernetes Engine 권장): 리전 간 홉 때문에 발생하는 네트워크 지연 시간으로 인한 불일치를 방지합니다.
SDK에서 gRPC API 사용: gRPC API는 REST API보다 성능이 우수합니다. REST API를 사용해야 하는 경우 HTTP 연결을 재사용하기 위해 HTTP 연결 유지 옵션을 사용 설정합니다. 그렇지 않으면 각 요청마다 새 HTTP 연결이 생성되어 지연 시간이 늘어납니다.
긴 시간 동안 테스트 실행: 더욱 정확한 측정항목을 계산하려면 긴 시간(15분 이상) 동안 최소 5QPS로 테스트를 실행합니다.
'준비' 기간 추가: 일정 시간 동안 활동이 없다가 테스트를 시작하면 연결이 다시 설정되는 동안 지연 시간이 길어질 수 있습니다. 초기의 높은 지연 시간을 고려하기 위해 이 기간을 초기 데이터 읽기가 무시되는 '준비 기간'으로 지정할 수 있습니다. 또는 저렴하지만 일관적인 비율의 인위적인 트래픽을 피처스토어로 전송하여 연결을 활성 상태로 유지할 수 있습니다.
필요한 경우 자동 확장 사용 설정: 온라인 트래픽의 점진적인 증가와 감소가 예상되는 경우 자동 확장을 사용 설정합니다. 자동 확장을 선택하면 Vertex AI가 CPU 사용률에 따라 온라인 서빙 노드 수를 자동으로 변경합니다.
온라인 서빙에 대한 자세한 내용은 온라인 서빙을 참조하세요. 온라인 서빙 노드에 대한 자세한 내용은 온라인 서빙 노드를 참조하세요.
일괄 제공 및 일괄 내보내기 중에 오프라인 스토리지 비용을 최적화하기 위한 시작 시간 지정
일괄 제공 및 일괄 내보내기 중에 오프라인 스토리지 비용을 최적화하려면 batchReadFeatureValues 또는 exportFeatureValues 요청에서 startTime을 지정하면 됩니다. 이 요청은 지정된 startTime에 따라 사용 가능한 특성 데이터의 하위 집합에 쿼리를 실행합니다. 그렇지 않으면 요청에서 사용 가능한 전체 특성 데이터 볼륨을 쿼리하여 오프라인 스토리지 사용량 비용이 증가합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-10(UTC)"],[],[],null,["# Best practices for Vertex AI Feature Store (Legacy)\n\nThe following best practices will help you plan and use\nVertex AI Feature Store (Legacy) in various scenarios. This guide is not intended to\nbe exhaustive.\n\nModel features that jointly describe multiple entities\n------------------------------------------------------\n\nSome features might apply to multiple entity types. For example, you\nmight have a calculated value that records clicks per product by user. This\nfeature jointly describes product-user pairs.\n\nThe best practice, in this case, is to create a separate entity type to group\nshared features. You can create an entity type, such as `product-user`, to\ncontain shared features.\n\nFor the entity IDs, concatenate the IDs of the individual entities,\nsuch as the entity IDs of the individual product and user. The only requirement\nis that the IDs must be strings. These combined entity types are referred to as\n*composite entity types*.\n\nFor more information, see [creating an entity\ntype](/vertex-ai/docs/featurestore/managing-entity-types#create).\n\nUse IAM policies to control access across multiple teams\n--------------------------------------------------------\n\nUse IAM roles and policies to set different levels of access to\ndifferent groups of users. For example, ML researchers, data scientists, DevOps,\nand site reliability engineers all require access to the same featurestore, but\ntheir level of access can differ. For example, DevOps users might require\npermissions to manage a featurestore, but they don't require access to the\ncontents of the featurestore.\n\nYou can also restrict access to a particular featurestore or entity type by\nusing [resource-level IAM\npolicies](/vertex-ai/docs/featurestore/resource-policy).\n\nAs an example, imagine that your organization includes the following personas.\nBecause each persona requires a different level of access, each persona is\nassigned a different [predefined IAM\nrole](/vertex-ai/docs/general/access-control#predefined-roles). You can also create and use\nyour own custom roles.\n\nMonitor and tune resources accordingly to optimize batch import\n---------------------------------------------------------------\n\nBatch import jobs require workers to process and write data, which can\nincrease the CPU utilization of your featurestore and affect online serving\nperformance. If preserving online serving performance is a priority, start with\none worker for every ten online serving nodes. During import, monitor the CPU\nusage of the online storage. If CPU usage is lower than expected, increase the\nnumber of workers for future batch import jobs to increase throughput. If\nCPU usage is higher than expected, increase the number of online serving nodes\nto increase CPU capacity or lower the batch import worker count, both of\nwhich can lower CPU usage.\n\nIf you do increase the number of online serving nodes, note that\nVertex AI Feature Store (Legacy) takes roughly 15 minutes to reach optimal\nperformance after you make the update.\n\nFor more information, see\n[update a featurestore](/vertex-ai/docs/featurestore/managing-featurestores#update) and\n[batch import feature values](/vertex-ai/docs/featurestore/ingesting-batch).\n\nFor more information about featurestore monitoring, see [Cloud Monitoring\nmetrics](/vertex-ai/docs/general/monitoring-metrics).\n\nUse the `disableOnlineServing` field when backfilling historical data\n---------------------------------------------------------------------\n\nBackfilling is the process of importing historical feature values and don't\nimpact the most recent feature values. In this case, you can disable online\nserving, which skips any changes to the [online\nstore](/vertex-ai/docs/featurestore/managing-featurestores#storage). For more information, see\n[Backfill historical data](/vertex-ai/docs/featurestore/ingesting-batch#backfill).\n\nUse autoscaling to reduce costs during load fluctuations\n--------------------------------------------------------\n\nIf you use Vertex AI Feature Store (Legacy) extensively and encounter frequent load\nfluctuations in your traffic patterns, use autoscaling to optimize costs.\nAutoscaling lets Vertex AI Feature Store (Legacy) review traffic patterns and\nautomatically adjust the number of nodes up or down depending on CPU utilization, instead of maintaining a high node count. This option\nworks well for traffic patterns that encounter gradual growth and decline.\n| **Caution:** Autoscaling is not effective for managing sudden bursts of traffic. For more information, see [Additional considerations for autoscaling](/vertex-ai/docs/featurestore/managing-featurestores#additional_considerations). \n| If you are expecting sudden bursts of traffic, set the `minNodeCount` flag to a threshold that is high enough to handle the bursts. For more information, see [Scaling](/vertex-ai/docs/reference/rest/v1/projects.locations.featurestores#scaling) in the [API reference](/vertex-ai/docs/reference/rest/v1/projects.locations.featurestores#scaling).\n\nFor more information about autoscaling, see\n[Scaling options](/vertex-ai/docs/featurestore/managing-featurestores#scaling_options).\n\nTest the performance of online serving nodes for real-time serving\n------------------------------------------------------------------\n\nYou can verify the performance of your featurestore during real-time online\nserving by testing the performance of your online serving nodes. You can\nperform these tests based on various benchmarking parameters, such as QPS,\nlatency, and API. Follow these guidelines to test the performance of online\nserving nodes:\n\n- **Run all test clients from the same region, preferably on Compute Engine or Google Kubernetes Engine**: This prevents discrepancies due to network latency resulting from hops across regions.\n\n- **Use the gRPC API in the SDK**: The gRPC API performs better than the REST API. If you need to use the REST API, enable the HTTP keep-alive option to reuse HTTP connections. Otherwise, each request results in the creation of a new HTTP connection, which increases the latency.\n\n- **Run longer duration tests**: Run tests with longer duration (15 minutes or more) and a minimum of 5 QPS to calculate more accurate metrics.\n\n- **Add a \"warm-up\" period**: If you start testing after a period of inactivity, you might observe high latency while connections are reestablished. To account for the initial period of high latency, you can designate this period as a \"warm-up period\", when the initial data reads are ignored. As an alternative, you can send a low but consistent rate of artificial traffic to the featurestore to keep the connection active.\n\n- **If required, enable autoscaling**: If you anticipate gradual growth and decline in your online traffic, enable autoscaling. If you choose autoscaling, Vertex AI automatically changes the number of online serving nodes based on CPU utilization.\n\nFor more information about online serving, see [Online serving](/vertex-ai/docs/featurestore/serving-online). For more information about online serving nodes, see [Online serving nodes](/vertex-ai/docs/featurestore/managing-featurestores#onlineservingnodes).\n\nSpecify a start time to optimize offline storage costs during batch serve and batch export\n------------------------------------------------------------------------------------------\n\nTo optimize offline storage costs during batch serving and batch export, you can specify the a `startTime` in your `batchReadFeatureValues` or `exportFeatureValues` request. The request runs a query over a subset of the available feature data, based on the specified `startTime`. Otherwise, the request queries the entire available volume of feature data, resulting in high offline storage usage costs.\n\nWhat's next\n-----------\n\nLearn Vertex AI Feature Store (Legacy) [best practices for implementing custom-trained ML models on Vertex AI](/architecture/ml-on-gcp-best-practices#use-vertex-feature-store-with-structured-data)."]]
