સર્વિસ કેટલોગ ડેટા મોડેલ અને golden path templates ડિઝાઇન કરો

પરિચય

એન્જિનિયરો વારંવાર જુએ છે કે જ્યારે કોઈ માળખાગત કેટલોગ અસ્તિત્વમાં ન હોય ત્યારે AI ટીમો તદર્થ (ad-hoc) પ્રોવિઝનિંગ તરફ વળે છે—GPU ખર્ચ નિયંત્રણ વગર વધે છે, મોડેલ ડિપ્લોયમેન્ટ્સ મોનિટરિંગ ઇન્સ્ટ્રુમેન્ટેશન છોડી દે છે, અને કનેક્શન સ્ટ્રિંગ્સ ડઝનબંધ સર્વિસોમાં હાર્ડકોડ થાય છે જેમની વચ્ચે કોઈ ઓટોમેટેડ વાયરિંગ હોતું નથી. Golden paths સાથે જોડાયેલો સર્વિસ કેટલોગ આનો ઉકેલ આપે છે—તે ટીમોને માન્ય કરેલી સર્વિસોની ક્યુરેટેડ રજિસ્ટ્રી અને પૂર્વ-રચિત વર્કફ્લો આપે છે, જેને તેઓ પ્લેટફોર્મના નિર્ણયો શૂન્યથી ફરી શોધ્યા વગર અપનાવી શકે. આ પાઠના અંતે, તમે રજિસ્ટ્રેશન સમયે ગવર્નન્સ પોલિસીઓ લાગુ કરતું કેટલોગ ડેટા મોડેલ ડિઝાઇન કરી શકશો, એ સર્વિસોને એન્ડ-ટુ-એન્ડ AI વર્કફ્લોમાં સંયોજિત કરતી golden path સ્ટેપ સિક્વન્સ વ્યાખ્યાયિત કરી શકશો, અને સમજી શકશો કે પ્રોવિઝનિંગ ઓર્કેસ્ટ્રેટર પ્લેટફોર્મ કંટ્રોલ પ્લેન દ્વારા આંતર-સર્વિસ કન્ફિગરેશન આપમેળે કેવી રીતે પ્રસારિત કરે છે.

મુખ્ય પરિભાષા

• Service Catalog: પ્લેટફોર્મ દ્વારા પૂરી પાડવામાં આવતી સર્વિસોની ક્યુરેટેડ રજિસ્ટ્રી, જેમાં દરેક સર્વિસની ક્ષમતાઓ, SLAs, ડિપેન્ડન્સીઓ અને પ્રોવિઝનિંગ ઇન્ટરફેસનું વર્ણન કરતો મેટાડેટા હોય છે.
• Golden Path: પૂર્વ-માન્ય, અભિપ્રાયયુક્ત વર્કફ્લો ટેમ્પ્લેટ જે ચોક્કસ ઉપયોગ-કેસ માટે બહુવિધ કેટલોગ સર્વિસોને એન્ડ-ટુ-એન્ડ પાઇપલાઇનમાં સંયોજિત કરે છે.
• Service Template: પેરામીટરાઇઝ્ડ બ્લુપ્રિન્ટ જે ચોક્કસ સર્વિસ ઇન્સ્ટન્સ માટે infrastructure-as-code અને કન્ફિગરેશન જનરેટ કરે છે.
• Platform Control Plane: APIs અને કંટ્રોલર્સનો સમૂહ જે પ્લેટફોર્મ પર સર્વિસ લાઇફસાઇકલ, કન્ફિગરેશન પ્રસારણ અને હેલ્થ મોનિટરિંગનું સંચાલન કરે છે.
• Catalog Entry: કેટલોગમાંની એક સર્વિસ વ્યાખ્યા, જેમાં તેની સ્કીમા, વર્ઝન ઇતિહાસ, માલિકી મેટાડેટા અને ડિપેન્ડન્સી ગ્રાફ શામેલ હોય છે.

સંકલ્પનાઓ

પ્લેટફોર્મ કન્ફિગરેશન મેનેજમેન્ટ સાથે જોડાણ

સર્વિસ કેટલોગ અને golden path રજિસ્ટ્રી અલગથી અસ્તિત્વમાં નથી—તેઓ સંબંધિત લેબ ઉદ્દેશ્યમાં વર્ણવેલ પ્લેટફોર્મ કન્ફિગરેશન મેનેજમેન્ટ સર્વિસમાં સીધા જ ફીડ થાય છે. જ્યારે પ્રોવિઝનિંગ ઓર્કેસ્ટ્રેટર golden path સ્ટેપમાંથી કોઈ સર્વિસ ડિપ્લોય કરે છે, ત્યારે તે પરિણામી કન્ફિગરેશન (એન્ડપોઇન્ટ્સ, ક્રેડેન્શિયલ રેફરન્સ, રિસોર્સ એલોકેશન) Redis કેશિંગ સાથે PostgreSQL માં લખે છે. Golden path માંની પછીની સર્વિસો તેમના પુરોગામીઓનું કન્ફિગરેશન આ સ્ટોરમાંથી વાંચે છે, જે આપમેળે વાયરિંગ શક્ય બનાવે છે.

ઉદાહરણ તરીકે, જ્યારે golden path સ્ટેપ 1 માં વેક્ટર ડેટાબેઝ પ્રોવિઝન કરે છે, ત્યારે ઓર્કેસ્ટ્રેટર ડેટાબેઝની કનેક્શન સ્ટ્રિંગ અને કલેક્શન સ્કીમાને platform/team-alpha/vector-db/qdrant/connection જેવી નેમસ્પેસ્ડ કી હેઠળ કન્ફિગરેશન સ્ટોરમાં લખે છે. જ્યારે સ્ટેપ 2 મોડેલ સર્વિંગ એન્ડપોઇન્ટ પ્રોવિઝન કરે છે, ત્યારે સર્વિંગ ફ્રેમવર્કનું સ્ટાર્ટઅપ કન્ફિગરેશન એ જ કી વાંચીને શોધે છે કે એમ્બેડિંગ લુકઅપ્સ ક્યાં મોકલવા. આ પેટર્ન હાર્ડકોડેડ કનેક્શન સ્ટ્રિંગ્સ દૂર કરે છે અને પ્લેટફોર્મને કન્ઝ્યુમર કોડમાં ફેરફાર કર્યા વગર ક્રેડેન્શિયલ્સ ફેરવવા અથવા સર્વિસો માઇગ્રેટ કરવા સક્ષમ બનાવે છે.

કન્ફિગરેશન મેનેજમેન્ટ સર્વિસે gRPC અથવા REST API પ્રદર્શિત કરવું જોઈએ, જેમાં કેટલોગ લાઇફસાઇકલ ઇવેન્ટ્સ સાથે મેપ થતી નીચેની કામગીરીઓ હોય:

• PUT /config/{namespace}/{service_id}/{key} — પ્રોવિઝનિંગ દરમિયાન કન્ફિગરેશન મૂલ્ય લખે છે, આપમેળે Redis કેશ ઇન્વેલિડેશન સાથે.
• GET /config/{namespace}/{service_id}/{key} — કન્ફિગરેશન મૂલ્ય વાંચે છે, જે Redis કેશમાંથી PostgreSQL ફોલબેક સાથે પીરસાય છે.
• DELETE /config/{namespace}/{service_id} — ડિકમિશન કરેલી સર્વિસ માટેનું સમગ્ર કન્ફિગરેશન દૂર કરે છે, જે golden path સ્ટેપ રોલબેક થાય ત્યારે ટ્રિગર થાય છે.
• LIST /config/{namespace} — ટીમના નેમસ્પેસમાં કન્ફિગર કરેલી સર્વિસોની ગણતરી કરે છે, જે પ્લેટફોર્મ હેલ્થ ડેશબોર્ડના સર્વિસ ઇન્વેન્ટરી વ્યૂને શક્તિ આપે છે.

AI-વિશિષ્ટ Golden Paths માટે ડિઝાઇન સિદ્ધાંતો

AI વર્કફ્લો માટે golden paths બનાવવા માટે એવી બાબતો પર ધ્યાન આપવું જરૂરી છે જે પરંપરાગત માઇક્રોસર્વિસ પ્લેટફોર્મમાં ઉદ્ભવતી નથી:

1. GPU લાઇફસાઇકલ મેનેજમેન્ટ એન્કોડ કરો — GPU વર્કલોડ પ્રોવિઝન કરતા દરેક golden path માં ક્વોટા વેલિડેશન, નોડ પૂલ પસંદગી અને આપમેળે સ્કેલ-ડાઉન પોલિસી માટેના સ્ટેપ્સ શામેલ હોવા જોઈએ. કેટલોગ એન્ટ્રીમાંનું GPURequirement મોડેલ ઘોષણા લાગુ કરે છે, પરંતુ golden path એ પ્રોવિઝનિંગ શરૂ કરતા પહેલાં એ પણ ચકાસવું જોઈએ કે લક્ષ્ય ક્લસ્ટરમાં પૂરતી GPU ક્ષમતા છે. જો ક્ષમતા અપૂરતી હોય, તો path એ ડિપ્લોયમેન્ટની મધ્યમાં નિષ્ફળ થવાને બદલે ક્ષમતા વિનંતી વર્કફ્લોની લિંક સાથે સ્પષ્ટ એરર પરત કરવી જોઈએ.

2. ઇન્ફ્રાસ્ટ્રક્ચર સાથે મોડેલ આર્ટિફેક્ટ્સનું વર્ઝનિંગ કરો — મોડેલ સર્વિંગ માટેના golden paths એ પ્રોવિઝનિંગ પેરામીટર્સમાં મોડેલ આર્ટિફેક્ટ વર્ઝન (દા.ત., ચોક્કસ run ID સાથેનું MLflow મોડેલ URI) પિન કરવું જોઈએ. આ સુનિશ્ચિત કરે છે કે ઇન્ફ્રાસ્ટ્રક્ચર અને મોડેલ વર્ઝન એટોમિક રીતે ડિપ્લોય થાય અને સાથે રોલબેક કરી શકાય. મોડેલ વર્ઝનને કન્ફિગરેશન મેનેજમેન્ટ સર્વિસના PostgreSQL બેકએન્ડમાં સંગ્રહવાથી કયું મોડેલ વર્ઝન કયા ઇન્ફ્રાસ્ટ્રક્ચર પર કયા સમયે ચાલ્યું તેનો ઓડિટેબલ ઇતિહાસ બને છે.

3. ડિફોલ્ટ રૂપે ઓબ્ઝર્વેબિલિટી શામેલ કરો — દરેક golden path માં મોનિટરિંગ સ્ટેપ હોવું જોઈએ જે ડિપ્લોય કરેલી સર્વિસો માટે Prometheus સ્ક્રેપ ટાર્ગેટ્સ અને Grafana ડેશબોર્ડ વ્યાખ્યાઓ પ્રોવિઝન કરે. AI વર્કલોડ માટે રિક્વેસ્ટ લેટન્સી ઉપરાંત વિશિષ્ટ મેટ્રિક્સ જરૂરી છે—ટોકન થ્રુપુટ, બેચ ક્યૂ ડેપ્થ, GPU ઉપયોગ ટકાવારી અને ઇન્ફરન્સ ડ્રિફ્ટ સ્કોર. મોનિટરિંગ સ્ટેપે કેટલોગના MONITORING સર્વિસ પ્રકારનો ઉપયોગ કરવો જોઈએ અને પૂર્વ-નિર્મિત ડેશબોર્ડ JSON ઇન્જેક્ટ કરવું જોઈએ, જેને Grafana ઓપરેટર આપમેળે રિકન્સાઇલ કરે છે.

4. પ્રયોગથી પ્રોડક્શન સુધી પ્રમોશનને સપોર્ટ કરો — ડેટા સાયન્ટિસ્ટો વારંવાર એક્સપેરિમેન્ટ ટ્રેકિંગ એન્વાયર્નમેન્ટમાં મોડેલ વિકસાવે છે અને માન્ય કરેલા પ્રયોગને પ્રોડક્શન સર્વિંગ ડિપ્લોયમેન્ટમાં પ્રમોટ કરવા માટે સ્પષ્ટ માર્ગની જરૂર હોય છે. સારી રીતે ડિઝાઇન કરેલો golden path એક promote ક્રિયા પૂરી પાડે છે જે ફીચર સ્ટોરમાંથી પ્રયોગનો મેટાડેટા વાંચે છે, પ્લેટફોર્મના સ્ટાન્ડર્ડ કન્ટેનર ઇમેજ બિલ્ડરનો ઉપયોગ કરીને મોડેલને પેકેજ કરે છે, અને તમામ પ્રોડક્શન સર્વિસો માટે વપરાતી એ જ ArgoCD પાઇપલાઇન દ્વારા તેને ડિપ્લોય કરે છે. આ પ્રયોગ અને પ્રોડક્શન વચ્ચેની એ ખાઈ દૂર કરે છે જેના કારણે મોટાભાગના ML પ્રોજેક્ટ અટકી જાય છે.

આ સિદ્ધાંતો સુનિશ્ચિત કરે છે કે golden paths માત્ર Helm charts પરના સગવડભર્યા રેપર નથી, પરંતુ AI વર્કલોડને મોટા પાયે વિશ્વસનીય રીતે ચલાવવા વિશે પ્લેટફોર્મ ટીમના સંચિત ઓપરેશનલ જ્ઞાનને એન્કોડ કરે છે. દરેક path નું semantic versioning નો ઉપયોગ કરીને વર્ઝનિંગ થવું જોઈએ, ArgoCD જે Git રિપોઝિટરી પર નજર રાખે છે તેમાં સંગ્રહવું જોઈએ, અને ડેવલપર પોર્ટલના કેટલોગમાં પ્રકાશિત થતા પહેલાં પ્લેટફોર્મની પોતાની CI પાઇપલાઇન દ્વારા ટેસ્ટ થવું જોઈએ.

કોડ વૉકથ્રુ

ServiceCatalogEntry, GoldenPathDefinition અને Platform Control Plane માટેની મુખ્ય પરિભાષા વ્યાખ્યાઓ પર આધાર રાખીને, નીચેનું અમલીકરણ આ માળખાંને Pydantic મોડેલ તરીકે એન્કોડ કરે છે, જેને પ્રોવિઝનિંગ ઓર્કેસ્ટ્રેટર કોઈપણ સર્વિસ ડિપ્લોય કરતા પહેલાં માન્ય કરે છે.

Code snippetpython
1from pydantic import BaseModel, Field, field_validator
2from enum import Enum
3from typing import Optional
4from datetime import datetime
5
6class ServiceType(str, Enum):
7    MODEL_SERVING = "model-serving"
8    TRAINING_JOB = "training-job"
9    VECTOR_DB = "vector-db"
10    FEATURE_STORE = "feature-store"
11    MONITORING = "monitoring"
12
13class GPURequirement(BaseModel):
14    gpu_type: str
15    min_count: int = Field(ge=0, default=0)
16    max_count: int = Field(ge=0, default=8)
17    memory_gb: int = Field(ge=0, default=40)
18
19class ServiceDependency(BaseModel):
20    service_id: str
21    version_constraint: str
22    optional: bool = False
23
24class ServiceCatalogEntry(BaseModel):
25    service_id: str = Field(min_length=3, max_length=64)
26    name: str
27    service_type: ServiceType
28    version: str = Field(pattern=r"^\d+\.\d+\.\d+$")
29    owner_team: str
30    description: str = Field(min_length=20)
31    gpu_requirements: Optional[GPURequirement] = None
32    dependencies: list[ServiceDependency] = Field(default_factory=list)
33    helm_chart_ref: Optional[str] = None
34    created_at: datetime = Field(default_factory=datetime.utcnow)
35    deprecated: bool = False
36
37    @field_validator("gpu_requirements")
38    @classmethod
39    def gpu_required_for_compute_services(cls, v, info):
40        stype = info.data.get("service_type")
41        gpu_types = {ServiceType.MODEL_SERVING, ServiceType.TRAINING_JOB}
42        if stype in gpu_types and v is None:
43            raise ValueError(f"gpu_requirements mandatory for {stype}")
44        return v

ServiceType પ્લેટફોર્મ જે AI વર્કલોડ શ્રેણીઓનું સંચાલન કરે છે તેની ગણતરી કરે છે, અને Kubernetes લેબલ કન્વેન્શન સાથે સુસંગત kebab-case મૂલ્યોનો ઉપયોગ કરે છે. GPURequirement સબ-મોડેલ દરેક એન્ટ્રી પર સ્પષ્ટ હાર્ડવેર ઘોષણાઓ ફરજિયાત બનાવે છે. ServiceCatalogEntry પરનો field_validator GPU જરૂરિયાતો છોડી દેતી કોઈપણ model-serving અથવા training-job એન્ટ્રીને નકારે છે, જે ખર્ચ ગવર્નન્સને ડિપ્લોય સમયે નહીં પણ સ્કીમા વેલિડેશન સમયે લાગુ કરે છે—એવા પ્લેટફોર્મ માટે નિર્ણાયક પોલિસી જ્યાં બિનઆયોજિત GPU એલોકેશન બજેટ ઓવરરન સર્જે છે.

જ્યારે ઓર્કેસ્ટ્રેટર દરેક golden path સ્ટેપ પ્રોવિઝન કરે છે, ત્યારે તે પરિણામી કનેક્શન વિગતો કન્ફિગરેશન સ્ટોરમાં લખે છે જેથી ડાઉનસ્ટ્રીમ સ્ટેપ્સ તેને આપમેળે શોધી શકે, અને હાર્ડકોડેડ સ્ટ્રિંગ્સ દૂર થાય. નીચેના હેલ્પર્સ સંકલ્પનાઓ વિભાગમાં વર્ણવેલ PUT અને GET કામગીરીઓનું અમલીકરણ કરે છે:

Code snippetpython
1import httpx
2
3def write_service_config(
4    namespace: str,
5    service_id: str,
6    key: str,
7    value: str,
8    config_api_base: str = "http://platform-config:8080",
9) -> None:
10    """Write a provisioned service's config for downstream golden path steps."""
11    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
12    response = httpx.put(url, json={"value": value}, timeout=10.0)
13    response.raise_for_status()
14
15def read_service_config(
16    namespace: str,
17    service_id: str,
18    key: str,
19    config_api_base: str = "http://platform-config:8080",
20) -> str:
21    """Read a predecessor step's config during golden path provisioning."""
22    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
23    response = httpx.get(url, timeout=10.0)
24    response.raise_for_status()
25    return response.json()["value"]

વેક્ટર ડેટાબેઝ સ્ટેપ પૂર્ણ થયા પછી, ઓર્કેસ્ટ્રેટર write_service_config("team-alpha", "vector-db/qdrant", "connection", connection_string) કૉલ કરે છે. ત્યારબાદ મોડેલ-સર્વિંગ સ્ટેપ એન્ડપોઇન્ટ શોધવા માટે read_service_config("team-alpha", "vector-db/qdrant", "connection") કૉલ કરે છે—જે સંકલ્પનાઓ વિભાગમાં વર્ણવેલ નેમસ્પેસ્ડ કી પેટર્ન સાથે મેળ ખાય છે અને કન્ઝ્યુમર કોડમાં ફેરફાર કર્યા વગર આપમેળે ક્રેડેન્શિયલ રોટેશન શક્ય બનાવે છે.

service_type=ServiceType.MODEL_SERVING અને gpu_requirements=None સાથે ServiceCatalogEntry ઇન્સ્ટન્શિયેટ કરીને ચકાસો—વેલિડેટરે ValueError ઉઠાવવી જોઈએ, જે પુષ્ટિ કરે છે કે કોઈપણ ઇન્ફ્રાસ્ટ્રક્ચરને સ્પર્શતા પહેલાં કેટલોગ રજિસ્ટ્રેશન સમયે ગવર્નન્સ પોલિસી લાગુ થાય છે.

શિસ્ત-વિશિષ્ટ ઉપયોગ

શું કરવું અને શું ન કરવું

ઉપર કેટલોગ મોડેલ, golden path કન્ફિગરેશન પ્રસારણ અને શિસ્ત-વિશિષ્ટ ઉપયોગમાંથી પસાર થયા બાદ, નીચેના આદેશો ગવર્નન્સ અને વાયરિંગ પેટર્નને એવા નિયમોમાં સંક્ષિપ્ત કરે છે જે તમે તમારી પોતાની કેટલોગ એન્ટ્રીઓ અને golden paths ડિઝાઇન કરતી વખતે સીધા લાગુ કરી શકો.

શું કરવું

1. દરેક model-serving અને training-job કેટલોગ એન્ટ્રી પર gpu_requirements જાહેર કરો — ServiceCatalogEntry પરનો field_validator જ્યારે gpu_requirements None હોય ત્યારે આ સર્વિસ પ્રકારોને નકારે છે, જે કોઈપણ ઇન્ફ્રાસ્ટ્રક્ચર પ્રોવિઝન થાય તે પહેલાં સ્કીમા વેલિડેશન સમયે ખર્ચ ગવર્નન્સ લાગુ કરે છે અને બિનઆયોજિત GPU બજેટ ઓવરરન અટકાવે છે.
2. સુસંગત નેમસ્પેસ્ડ કી પેટર્ન (દા.ત., "team-alpha" / "vector-db/qdrant" / "connection") સાથે write_service_config / read_service_config નો ઉપયોગ કરો — આ દરેક golden path સ્ટેપને સર્વિસોમાં કનેક્શન સ્ટ્રિંગ્સ હાર્ડકોડ કરવાને બદલે પ્લેટફોર્મ કંટ્રોલ પ્લેનમાંથી પુરોગામી આઉટપુટ આપમેળે શોધવા દે છે.
3. કેટલોગ એન્ટ્રીઓને semver (^\d+\.\d+\.\d+$) સુધી મર્યાદિત version ફીલ્ડ અને deprecated ફ્લેગ સાથે મોડેલ કરો — એન્ટ્રીઓને વર્ઝન્ડ અને ડેપ્રિકેશન-જાગૃત રાખવાથી ઓર્કેસ્ટ્રેટર ServiceDependency.version_constraint ચેક લાગુ કરી શકે છે અને ટીમોને હાલની golden path સ્ટેપ સિક્વન્સ તોડ્યા વગર માઇગ્રેશન માર્ગ મળે છે.

શું ન કરવું

1. gpu_requirements છોડી દઈને એવું ન માનો કે ઓર્કેસ્ટ્રેટર ડિફોલ્ટ પૂરા પાડશે — GPURequirement એ ServiceType.MODEL_SERVING અને ServiceType.TRAINING_JOB માટે ફરજિયાત સબ-મોડેલ છે; તેને છોડી દેવાથી રજિસ્ટ્રેશન સમયે ValueError ઉઠે છે, અને પ્લેટફોર્મ ડિફોલ્ટ પર મૌન રીતે આધાર રાખવો એ બરાબર એ જ તદર્થ પ્રોવિઝનિંગ પેટર્ન છે જેને દૂર કરવા માટે કેટલોગ ડિઝાઇન કરાયો છે.
2. Golden path સ્ટેપ કોડમાં કનેક્શન સ્ટ્રિંગ્સ હાર્ડકોડ ન કરો — write_service_config / read_service_config ને બાયપાસ કરવાથી આપમેળે ક્રેડેન્શિયલ-પ્રસારણનો કરાર તૂટે છે, જેનો અર્થ એ કે એન્ડપોઇન્ટ ફેરફારો (ક્રેડેન્શિયલ રોટેશન સહિત) માટે એક જ કન્ફિગ-સ્ટોર લેખનને બદલે દરેક કન્ઝ્યુમિંગ સર્વિસમાં મેન્યુઅલ અપડેટ જરૂરી બને છે.
3. ServiceType enum ની બહારની તદર્થ service_type સ્ટ્રિંગ હેઠળ નવો AI વર્કલોડ રજિસ્ટર ન કરો — enum ના kebab-case મૂલ્યો (model-serving, vector-db, વગેરે) Kubernetes લેબલ કન્વેન્શન સાથે સુસંગત છે અને એ કી છે જેના પર ગવર્નન્સ વેલિડેટર અને GPU-જરૂરિયાત ચેક બ્રાન્ચ થાય છે; અજાણ્યો પ્રકાર field_validator અને ઓર્કેસ્ટ્રેટરના રિસોર્સ-ક્વોટા લોજિક બંનેને બાયપાસ કરે છે.