Snowpark Container Services: Verwenden von Diensten

Snowpark Container Services ermöglicht Ihnen die einfache Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen. Nachdem Sie eine Anwendung erstellt und das Anwendungsimage in ein Repository Ihres Snowflake-Kontos hochgeladen haben, können Sie Ihre Anwendungscontainer als Dienst ausführen.

Ein Dienst repräsentiert Snowflake, das Ihre containerisierte Anwendung auf einem Computepool ausführt, der eine Sammlung virtueller Maschinenknoten (VM) ist. Es gibt zwei Typen von Diensten:

  • Langlaufende Dienste. Ein lang laufender Dienst ist wie ein Webservice, der nicht automatisch endet. Nachdem Sie einen Dienst erstellt haben, verwaltet Snowflake den aktiven Dienst. Wenn z. B. ein Dienstcontainer aus irgendeinem Grund anhält, startet Snowflake diesen Container neu, damit der Dienst ohne Unterbrechung ausgeführt wird.

  • Jobdienste. Ein Jobdienst wird beendet, wenn Ihr Code beendet wird, ähnlich wie eine gespeicherte Prozedur. Wenn alle Container beendet werden, ist auch der Jobdienst beendet.

Das folgende Diagramm zeigt die Architektur eines Dienstes:

Dienst-Architektur von Snowpark Container Services

Die Höhepunkte des Diagramms sind die folgenden:

  • Benutzer laden ihren Anwendungscode in ein Repository in ihrem Snowflake-Konto hoch. Der Image Registry-Dienst dient der OCIv2-API zum Speichern von OCI-konformen Images in einem Repository. Sie können zum Beispiel Docker-API verwenden, um Images in ein Repository hochzuladen. Wenn Sie einen Dienst erstellen, geben Sie das zu verwendende Image an.

  • Ein Computepool ist der Ort, an dem Snowflake Ihre Dienste ausführt. Das Diagramm zeigt einen Computepool mit zwei Serverknoten (Knoten 0 und Knoten 1). Snowflake führt Ihre Dienstinstanz auf einem Knoten aus. Wenn Sie mehrere Dienstinstanzen ausführen, kann Snowflake diese je nach Ressourcenbedarf auf demselben Knoten ausführen oder sie auf mehrere Knoten verteilen. Beispiel:

    • Auf Knoten 0 laufen der Dienst A (zwei Instanzen der insgesamt drei Instanzen dieses Dienstes) und ein Job (mit einer einzigen Instanz).

    • Auf Knoten 1 läuft die dritte Instanz von Dienst A. Auf diesem Knoten läuft auch eine Instanz von Dienst B.

  • Abhängig von Ihrem Anwendungscode kann eine Dienstinstanz aus mehreren Containern bestehen. Während Snowflake die Instanzen eines Dienstes auf mehrere Computepool-Knoten verteilen kann, laufen alle Container innerhalb einer einzelnen Dienstinstanz immer auf demselben Computepool-Knoten.

  • Dienste können optional mit dem öffentlichen Internet kommunizieren.

  • Ein Dienst kann Speicher verwenden, einschließlich transientem Speicher (z. B. Arbeitsspeicher und lokale Festplatte) und persistenten Volumes (z. B. Blockspeicher-Volumes).

  • Snowflake kann Protokolle, Ablaufverfolgungen und Metriken von Ihren Diensten in der Ereignistabelle in Ihrem Snowflake-Konto aufzeichnen.

Snowflake bietet Ihnen APIs, um Repositories, Computepools und Dienste zu erstellen und zu verwalten. Unter diesem Thema wird die Verwendung von Diensten erläutert. APIs für die Verwaltung von Diensten umfassen die folgenden Punkte:

Starten von Diensten

Nachdem Sie Ihren Anwendungscode in ein Repository in Ihrem Snowflake-Konto hochgeladen haben, können Sie einen Dienst starten. Für das Starten eines Dienstes sind mindestens folgende Informationen erforderlich:

  • Ein Name: Name des Dienstes.

  • Eine Dienstspezifikation: Diese Spezifikation liefert Snowflake die Informationen, die zum Konfigurieren und Ausführen Ihres Dienstes erforderlich sind. Die Spezifikation ist eine YAML-Datei.

  • Ein Computepool: Snowflake führt Ihren Dienst in dem angegebenen Computepool aus.

Langlaufenden Dienst erstellen

Verwenden Sie CREATE SERVICE, um einen langlaufenden Dienst zu erstellen.

  • In den meisten Fällen erstellen Sie einen Dienst, indem Sie eine Inline-Spezifikation angeben, wie unten gezeigt:

    CREATE SERVICE echo_service
       IN COMPUTE POOL tutorial_compute_pool
       FROM SPECIFICATION $$
       spec:
         containers:
         - name: echo
           image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:tutorial
           readinessProbe:
             port: 8000
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: 8000
           public: true
       $$;
    
    Copy
  • Erstellen Sie einen Dienst, indem Sie auf eine in einem Snowflake-Stagingbereich gespeicherte Dienstspezifikation verweisen. Wenn Sie den Dienst in einer Produktionsumgebung bereitstellen, können Sie das Prinzip der Funktionstrennung anwenden und die Spezifikation in einen Stagingbereich hochladen, indem Sie die Staging-Informationen im Befehl CREATE SERVICE angeben, wie gezeigt:

    CREATE SERVICE echo_service
      IN COMPUTE POOL tutorial_compute_pool
      FROM @tutorial_stage
      SPECIFICATION_FILE='echo_spec.yaml';
    
    Copy

Jobdienst ausführen

Verwenden Sie EXECUTE JOB SERVICE, um einen Jobdienst zu erstellen. Standardmäßig wird dieser Befehl synchron ausgeführt und gibt eine Antwort zurück, nachdem alle Container des Jobdienstes beendet wurden. Sie können optional den Parameter ASYNC angeben, um den Jobdienst asynchron auszuführen.

  • Führen Sie einen Jobdienst mit einer Inline-Spezifikation aus:

    EXECUTE JOB SERVICE
       IN COMPUTE POOL tutorial_compute_pool
       NAME = example_job_service
       FROM SPECIFICATION $$
       spec:
         container:
         - name: main
           image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
           env:
             SNOWFLAKE_WAREHOUSE: tutorial_warehouse
           args:
           - "--query=select current_time() as time,'hello'"
           - "--result_table=results"
       $$;
    
    Copy

    Sie können diesen Job optional asynchron ausführen, indem Sie die Eigenschaft ASYNC verwenden.

    EXECUTE JOB SERVICE
       IN COMPUTE POOL tutorial_compute_pool
       NAME = example_job_service
       ASYNC = TRUE
       FROM SPECIFICATION $$
       ...
       $$;
    
    Copy
  • Führen Sie einen Jobdienst unter Verwendung von Stagingbereich-Informationen aus:

    EXECUTE JOB SERVICE
      IN COMPUTE POOL tutorial_compute_pool
      NAME = example_job_service
      FROM @tutorial_stage
      SPECIFICATION_FILE='my_job_spec.yaml';
    
    Copy

Verwenden von Spezifikationsvorlagen

Es kann vorkommen, dass Sie mehrere Dienste mit der gleichen Spezifikation, aber mit unterschiedlichen Konfigurationen erstellen möchten. Nehmen Sie zum Beispiel an, dass Sie in einer Dienstspezifikation eine Umgebungsvariable definieren und Sie mehrere Services erstellen möchten, die dieselbe Spezifikation, aber unterschiedliche Werte für die Umgebungsvariable verwenden.

Spezifikationsvorlagen ermöglichen es Ihnen, Variablen für Feldwerte in der Spezifikation zu definieren. Wenn Sie einen Service erstellen, geben Sie Werte für diese Variablen an.

In einer Spezifikationsvorlage geben Sie Variablen als Werte für verschiedene Spezifikationsfelder an. Verwenden Sie die Syntax {{ variable_name }}, um diese Variablen anzugeben. Geben Sie dann im Befehl CREATE SERVICE den Parameter USING an, um Werte für diese Variablen festzulegen.

Die Inline-Spezifikationsvorlage im folgenden CREATE SERVICE-Befehl verwendet beispielsweise eine Variable namens tag_name für den Namen des Image-Tags. Sie können diese Variable verwenden, um für jeden Dienst ein anderes Image-Tag anzugeben. In diesem Beispiel setzt der Parameter USING die Variable tag_name auf den Wert latest.

CREATE SERVICE echo_service
  IN COMPUTE POOL tutorial_compute_pool
  FROM SPECIFICATION $$
  spec:
    containers:
    - name: echo
      image: myorg-myacct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:{{ tag_name }}
        ...
    endpoints:
    - name: ...
      ...
  $$
  USING (tag_name=>'latest');
Copy

Wenn Sie die Spezifikationsvorlage in einem Snowflake-Stagingbereich Ihres Kontos speichern möchten, können Sie im CREATE SERVICE-Befehl auf den Speicherort der Vorlage verweisen:

CREATE SERVICE echo_service
    IN COMPUTE POOL tutorial_compute_pool
    FROM @STAGE SPECIFICATION_TEMPLATE_FILE='echo.yaml'
    USING (tag_name=>'latest');
Copy

Richtlinien für das Definieren von Variablen in einer Spezifikation

  • Verwenden Sie die Syntax {{ variable_name }}, um Variablen als Feldwerte in der Spezifikation zu definieren.

  • Diese Variablen können Standardwerte haben. Um den Standardwert festzulegen, verwenden Sie die Funktion default in der Variablendeklaration. Die folgende Spezifikation definiert zum Beispiel zwei Variablen (character_name und endpoint_name) mit Standardwerten.

    spec:
      containers:
      - name: echo
        image: <image_name>
        env:
          CHARACTER_NAME: {{ character_name | default('Bob') }}
          SERVER_PORT: 8085
      endpoints:
      - name: {{ endpoint_name | default('echo-endpoint') }}
        port: 8085
    
    Copy

    Zusätzlich können Sie einen optionalen booleschen Parameter für die Funktion default übergeben, um anzugeben, ob Sie den Standardwert verwenden möchten, wenn ein leerer Wert für die Variable übergeben wird. Betrachten Sie folgende Spezifikation:

    spec:
      containers:
      - name: echo
        image: <image_name>
        env:
          CHARACTER_NAME: {{ character_name | default('Bob', false) }}
          SERVER_PORT: 8085
      endpoints:
      - name: {{ endpoint_name | default('echo-endpoint', true) }}
        port: 8085
    
    Copy

    Erläuterungen zu dieser Spezifikation:

    • Für die Variable character_name wird der boolesche Parameter auf false gesetzt. Wenn die Variable also auf eine leere Zeichenfolge (‚‘) für diesen Parameter eingestellt wird, bleibt der Wert leer und der Standardwert („Bob“) wird nicht verwendet.

    • Für die Variable echo_endpoint wird der boolesche Parameter auf true gesetzt. Wenn Sie diesem Parameter einen leeren Wert übergeben, wird daher der Standardwert („echo-endpoint“) verwendet.

    Standardmäßig hat der boolesche Parameter für die Funktion default den Wert false.

Richtlinien für die Übergabe von Werten für Spezifikationsvariablen

Geben Sie im Befehl CREATE SERVICE den Parameter USING an, um Werte für Variablen bereitzustellen. Die allgemeine Syntax für USING lautet:

USING( var_name=>var_value, [var_name=>var_value, ... ] );
Copy

Wobei:

  • var_name unterscheidet zwischen Groß- und Kleinschreibung und sollte ein gültiger Snowflake-Bezeichner sein (siehe Anforderungen an Bezeichner).

  • var_value kann entweder ein alphanumerischer Wert oder ein gültiger JSON-Wert sein.

    Beispiele:

    -- Alphanumeric string and literal values
    USING(some_alphanumeric_var=>'blah123',
          some_int_var=>111,
          some_bool_var=>true,
          some_float_var=>-1.2)
    
    -- JSON string
    USING(some_json_var=>' "/path/file.txt" ')
    
    -- JSON map
    USING(env_values=>'{"SERVER_PORT": 8000, "CHARACTER_NAME": "Bob"}' );
    
    -- JSON list
    USING (ARGS='["-n", 2]' );
    
    Copy
  • Der Parameter USING in CREATE SERVICE muss Werte für die Spezifikationsvariablen bereitstellen (mit Ausnahme der Variablen, für die die Spezifikation Standardwerte vorsieht). In folgenden Fällen wird ein Fehler zurückgegeben:

Beispiele

Diese Beispiele zeigen das Erstellen von Diensten mithilfe von Spezifikationsvorlagen. Die CREATE SERVICE-Befehle in diesen Beispielen verwenden Inline-Spezifikationen.

Beispiel 1: Einfache Werte bereitstellen

In Tutorial 1 erstellen Sie einen Dienst, indem Sie eine Inline-Spezifikation bereitstellen. Das folgende Beispiel ist eine modifizierte Version davon, in der die Spezifikation zwei Variablen definiert: image_url und SERVER_PORT. Beachten Sie, dass die Variable SERVER_PORT an drei Stellen wiederholt wird. Dies hat den zusätzlichen Vorteil der Verwendung von Variablen, die sicherstellen, dass alle Felder, die denselben Wert haben sollen, auch denselben Wert haben.

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   MIN_INSTANCES=1
   MAX_INSTANCES=1
   FROM SPECIFICATION_TEMPLATE $$
      spec:
         containers:
         - name: echo
           image: {{ image_url }}
           env:
             SERVER_PORT: {{SERVER_PORT}}
             CHARACTER_NAME: Bob
           readinessProbe:
             port: {{SERVER_PORT}}
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: {{SERVER_PORT}}
           public: true
         $$
      USING (image_url=>' "/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest" ', SERVER_PORT=>8000 );
Copy

In diesem CREATE SERVICE-Befehl liefert der Parameter USING Werte für die beiden Spezifikationsvariablen. Der Wert image_url enthält Schrägstriche und einen Doppelpunkt. Dies sind keine alphanumerischen Zeichen. Daher wird der Wert in dem Beispiel in doppelte Anführungszeichen gesetzt, um ihn zu einem gültigen JSON-Zeichenfolgewert zu machen. Die Spezifikation der Vorlage erweitert die folgende Spezifikation:

spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    env:
      SERVER_PORT: 8000
      CHARACTER_NAME: Bob
    readinessProbe:
      port: 8000
      path: /healthcheck
    endpoints:
    - name: echoendpoint
      port: 8000
      public: true
Copy

Beispiel 2: JSON-Wert bereitstellen

In Tutorial 1 definiert die Spezifikation zwei Umgebungsvariablen (SERVER_PORT und CHARACTER_NAME), wie gezeigt:

spec:
 containers:
 - name: echo
   image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
   env:
     SERVER_PORT: 8000
     CHARACTER_NAME: Bob
   
Copy

Sie können diese Angabe mit Hilfe einer Variable für das Feld env als Vorlage verwenden. So können Sie mehrere Dienste mit unterschiedlichen Werten für die Umgebungsvariablen erstellen. Der folgende CREATE SERVICE-Befehl verwendet eine Variable (env_values) für das Feld „env“.

CREATE SERVICE echo_service
  IN COMPUTE POOL tutorial_compute_pool
  MIN_INSTANCES=1
  MAX_INSTANCES=1
  FROM SPECIFICATION_TEMPLATE $$
     spec:
       containers:
       - name: echo
         image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
         env: {{env_values}}
         readinessProbe:
           port: {{SERVER_PORT}}    #this and next tell SF to connect to port 8000
           path: /healthcheck
       endpoints:
       - name: echoendpoint
         port: {{SERVER_PORT}}
         public: true
        $$
     USING (env_values=>'{"SERVER_PORT": 8000, "CHARACTER_NAME": "Bob"}' );
Copy

Der Parameter USING in CREATE SERVICE liefert einen Wert für die Variable env_values. Der Wert ist eine JSON-Zuordnung, die Werte für die beiden Umgebungsvariablen bereitstellt.

Beispiel 3: Liste als Variablenwert bereitstellen

In Tutorial 2 enthält die Spezifikation das Feld args, das zwei Argumente enthält.

spec:
  container:
  - name: main
    image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
    env:
      SNOWFLAKE_WAREHOUSE: tutorial_warehouse
    args:
    - "--query=select current_time() as time,'hello'"
    - "--result_table=results"
Copy

In einer Vorlagenversion der Spezifikation können Sie diese Argumente wie gezeigt als JSON-Liste angeben:

spec:
  container:
  - name: main
    image: /tutorial_db/data_schema/tutorial_repository/my_job_image:latest
    env:
      SNOWFLAKE_WAREHOUSE: tutorial_warehouse
    args: {{ARGS}}
  $$
  USING (ARGS=$$["--query=select current_time() as time,'hello'", "--result_table=results"]$$ );
Copy

Skalieren von Diensten

Standardmäßig führt Snowflake eine Instanz des Dienstes in dem angegebenen Computepool aus. Um umfangreiche Workloads zu bewältigen, können Sie mehrere Dienstinstanzen ausführen, indem Sie die Eigenschaften MIN_INSTANCES und MAX_INSTANCES spezifizieren, die die Mindestanzahl der zu startenden Instanzen des Dienstes und die maximale Anzahl der Instanzen angeben, auf die Snowflake bei Bedarf skalieren kann.

Beispiel

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   FROM @tutorial_stage
   SPECIFICATION_FILE='echo_spec.yaml'
   MIN_INSTANCES=2
   MAX_INSTANCES=4;
Copy

Wenn mehrere Dienstinstanzen ausgeführt werden, stellt Snowflake automatisch einen Load Balancer zum Verteilen der eingehenden Anforderungen bereit.

Snowflake betrachtet den Dienst erst dann als READY, wenn mindestens zwei Instanzen verfügbar sind. Solange der Dienst nicht bereit ist, blockiert Snowflake den Zugriff darauf, d. h. die damit verbundenen Funktionen oder Anfragen werden verweigert, bis die Bereitschaft bestätigt ist.

In einigen Fällen möchten Sie vielleicht, dass Snowflake den Dienst auch dann als bereit betrachtet (und eingehende Anfragen weiterleitet), wenn weniger als die angegebenen Mindestinstanzen verfügbar sind. Sie können dies erreichen, indem Sie die Eigenschaft MIN_READY_INSTANCES festlegen.

Betrachten Sie folgendes Szenario: Während der Wartung oder eines fortlaufenden Dienst-Upgrades könnte Snowflake eine oder mehrere Dienstinstanzen beenden. Dies könnte dazu führen, dass weniger Instanzen als die angegebene MIN_INSTANCES verfügbar sind, was den Dienst daran hindert, in den Zustand READY zu gelangen. In diesen Fällen können Sie MIN_READY_INSTANCES auf einen kleineren Wert als MIN_INSTANCES setzen, um sicherzustellen, dass der Dienst weiterhin Anfragen annehmen kann.

Beispiel

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   FROM @tutorial_stage
   SPECIFICATION_FILE='echo_spec.yaml'
   MIN_INSTANCES=2
   MAX_INSTANCES=4
   MIN_READY_INSTANCES=1;
Copy

Weitere Informationen dazu finden Sie unter CREATE SERVICE.

Bemerkung

Sie können nicht mehr als eine Instanz eines Jobdienstes ausführen.

Aktivieren der automatischen Skalierung

Führen Sie die folgenden Schritte aus, um Snowflake für die automatische Skalierung der Anzahl der ausgeführten Dienstinstanzen zu konfigurieren:

  1. Geben Sie die CPU-Anforderungen für Ihre Dienstinstanz in der Dienstspezifikationsdatei an. Weitere Informationen dazu finden Sie unter Feld „container.resources“.

    Beispiel

    resources:
      requests:
       cpu: <cpu-units>
    
    Copy
  2. Wenn Sie den Befehl CREATE SERVICE ausführen, legen Sie die Parameter MIN_INSTANCES und MAX_INSTANCES fest. Sie können auch ALTER SERVICE verwenden, um diese Werte zu ändern. Die Autoskalierung erfolgt, wenn die angegebene MAX_INSTANCES größer als MIN_INSTANCES ist.

Snowflake beginnt mit der Erstellung der Mindestanzahl von Dienstinstanzen auf dem angegebenen Computepool. Snowflake skaliert dann die Anzahl der Dienstinstanzen anhand eines Schwellenwerts von 80 % CPU-Nutzung hoch oder runter. Snowflake überwacht kontinuierlich die CPU-Auslastung innerhalb des Computepools und fasst die Nutzungsdaten aller derzeit laufenden Dienstinstanzen zusammen.

Wenn die aggregierte CPU-Nutzung (für alle Dienstinstanzen) 80 % übersteigt, stellt Snowflake eine zusätzliche Dienstinstanz im Computepool bereit. Wenn die aggregierte CPU-Nutzung unter 80 % fällt, skaliert Snowflake herunter, indem eine der aktiven Dienstinstanzen entfernt wird. Snowflake verwendet ein fünfminütiges Stabilisierungsfenster, um häufiges Skalieren zu verhindern.

Beachten Sie das folgende Skalierungsverhalten:

  • Die Skalierung der Dienstinstanzen wird durch die für den Dienst konfigurierten Parameter MIN_INSTANCES und MAX_INSTANCES eingeschränkt.

  • Wenn ein Hochskalieren erforderlich ist und die Knoten des Computepools nicht über die erforderliche Ressourcenkapazität verfügen, um eine weitere Dienstinstanz zu starten, kann die automatische Skalierung des Computepools ausgelöst werden. Weitere Informationen dazu finden Sie unter Automatisches Skalieren von Computepool-Knoten.

  • Wenn Sie beim Erstellen eines Services die Parameter MAX_INSTANCES und MIN_INSTANCES angeben, aber in der Dienstspezifikationsdatei Ihrer Dienstinstanz keine CPU- und Arbeitsspeicheranforderungen spezifiziert sind, erfolgt keine automatische Skalierung. Snowflake beginnt dann mit der durch den Parameter MIN_INSTANCES angegebenen Anzahl von Instanzen und führt keine automatische Skalierung durch.

Einen Dienst aussetzen

Ein lang laufender Dienst verbraucht Ressourcen des Computepools und verursacht damit Kosten. Sie können den Dienst jedoch aussetzen, wenn er keine sinnvolle Arbeit leistet. Wenn auf einem Computepool-Knoten keine Dienste oder Aufträge aktiv sind, setzt der automatische Computepool-Aussetzungsmechanismus von Snowflake den Pool aus, um die Kosten zu senken.

Um einen Dienst auszusetzen, können Sie entweder explizit ALTER SERVICE. .. SUSPEND aufrufen, um einen Dienst auszusetzen, oder Sie setzen die Eigenschaft AUTO_SUSPEND_SECS mit CREATE SERVICE oder ALTER SERVICE, um die Leerlaufdauer festzulegen, nach der Snowflake den Dienst automatisch aussetzt.

Wenn die Eigenschaft AUTO_SUSPEND_SECS gesetzt ist, setzt Snowflake einen Dienst automatisch aus, wenn er nicht bereits ausgesetzt wurde und mehr als AUTO_SUSPEND_SECS Sekunden lang inaktiv ist. Ein Dienst ist im Leerlauf, wenn beide folgenden Punkte zutreffen:

  • Es läuft derzeit keine Abfrage, die einen Dienstfunktion-Aufruf dieses Dienstes enthält.

  • Der Dienststatus lautet RUNNING.

Vorsicht

Die automatische Aussetzung verfolgt nicht die Datenverarbeitung, die durch den Aufruf einer Dienstfunktion eingeleitet wird, wenn die Verarbeitung nach der Rückkehr der Dienstfunktion fortgesetzt wird. In der aktuellen Implementierung verfolgt die automatische Aussetzung auch nicht die Eingangs- und Dienst-zu-Dienst-Kommunikation. Daher sollten Sie die automatische Aussetzung für Dienste, die solche Features anbieten, nicht aktivieren, da dies diese potenziell laufenden Prozesse stören könnte.

Wenn Snowflake einen Dienst aussetzt, werden alle Dienstinstanzen im Computepool heruntergefahren. Wenn keine anderen Dienste auf dem Computepool laufen und für den Computepool eine automatische Aussetzung konfiguriert ist, setzt Snowflake auch die Computepool-Knoten aus. So vermeiden Sie, dass Sie für einen inaktiven Computepool bezahlen müssen.

Beachten Sie auch das Folgende:

  • Die automatische Aussetzung wird für Jobdienste nicht unterstützt.

  • Die automatische Aussetzung wird bei Diensten mit öffentlichen Endpunkten nicht unterstützt, da Snowflake bei der Entscheidung, wann ein Dienst inaktiv ist, derzeit nur den Datenverkehr der Dienstfunktionen und nicht den Datenverkehr am Eingang verfolgt.

Ändern und Löschen von Diensten

Nachdem Sie einen Dienst erstellt haben:

  • Verwenden Sie den Befehl DROP SERVICE, um einen Service aus einem Schema zu entfernen (Snowflake beendet alle Dienstcontainer).

  • Verwenden Sie den Befehl ALTER SERVICE, um zum Beispiel den Service anzuhalten oder fortzusetzen, die Anzahl der aktiven Instanzen zu ändern und Snowflake anzuweisen, Ihren Service unter Verwendung einer neuen Dienstspezifikation neu bereitzustellen.

    Bemerkung

    Sie können einen Jobdienst nicht ändern.

Beendigung des Dienstes

Wenn Sie einen Service aussetzen (ALTER SERVICE … SUSPEND) oder einen Service beenden (DROP SERVICE), beendet Snowflake alle Dienstinstanzen. Ähnlich verhält es sich, wenn Sie den Dienstcode aktualisieren (ALTER SERVICE … <fromSpecification>), wendet Snowflake fortlaufende Upgrades an, indem es jeweils eine Dienstinstanz beendet und neu bereitstellt.

Wenn eine Dienstinstanz beendet wird, sendet Snowflake zunächst ein SIGTERM-Signal an jeden Dienstcontainer. Der Container hat die Möglichkeit, das Signal zu verarbeiten und mit einem 30-Sekunden-Fenster ordnungsgemäß herunterzufahren. Andernfalls beendet Snowflake nach Ablauf des Zeitraums alle Prozesse im Container.

Aktualisieren des Dienstcodes und erneutes Bereitstellen des Dienstes

Nachdem ein Dienst erstellt wurde, verwenden Sie den Befehl ALTER SERVICE … <fromSpecification>, um den Dienstcode zu aktualisieren und den Dienst erneut bereitzustellen.

Zunächst laden Sie den geänderten Anwendungscode in Ihr Image-Repository hoch. Anschließend führen Sie den Befehl ALTER SERVICE aus, wobei Sie entweder die Dienstspezifikation inline bereitstellen oder den Pfad zu einer Spezifikationsdatei im Stagingbereich von Snowflake angeben. Beispiel:

ALTER SERVICE echo_service
FROM SPECIFICATION $$
spec:
  
  
$$;
Copy

Nach Erhalt der Anforderung stellt Snowflake den Dienst mit dem neuen Code erneut bereit.

Bemerkung

Wenn Sie den Befehl CREATE SERVICE. .. <fromSpecification> ausführen, zeichnet Snowflake die spezifische Version des bereitgestellten Images auf. Snowflake setzt in den folgenden Szenarien dieselbe Image-Version ein, auch wenn das Image im Repository aktualisiert wurde:

  • Wenn ein angehaltener Dienst wieder fortgesetzt wird (mit ALTER SERVICE … RESUME).

  • Wenn Autoscaling weitere Dienstinstanzen hinzufügt.

  • Wenn Dienstinstanzen während der Cluster-Wartung neu gestartet werden.

Wenn Sie jedoch ALTER SERVICE. .. <fromSpecification> aufrufen, verwendet Snowflake die neueste Version im Repository für dieses Image

Wenn Sie der Eigentümer des Services sind, enthält die Ausgabe des Befehls DESCRIBE SERVICE die Dienstspezifikation, die den Image-Digest (den Wert des Feldes sha256 in der Spezifikation) enthält, wie unten gezeigt:

spec:
containers:
- name: "echo"
    image: "/tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest"
    sha256: "@sha256:8d912284f935ecf6c4753f42016777e09e3893eed61218b2960f782ef2b367af"
    env:
      SERVER_PORT: "8000"
      CHARACTER_NAME: "Bob"
    readinessProbe:
      port: 8000
      path: "/healthcheck"
endpoints:
- name: "echoendpoint"
    port: 8000
    public: true
Copy

ALTER SERVICE kann die Kommunikation (siehe Verwenden eines Dienstes) mit dem Dienst beeinträchtigen.

  • Wenn ALTER SERVICE … <fromSpecification> einen Endpunkt entfernt oder relevante Berechtigungen entfernt, die für die Nutzung eines Endpunkts erforderlich sind (siehe serviceRoles in Spezifikationsreferenz), schlägt der Zugriff auf den Service fehl. Weitere Informationen finden Sie unter Verwendung eines Dienstes.

  • Während des Upgrades werden neue Verbindungen möglicherweise auf die neue Version geroutet. Wenn die neue Version des Dienstes nicht abwärtskompatibel ist, wird die aktive Nutzung des Dienstes unterbrochen. Zum Beispiel können laufende Abfragen mit einer Dienstfunktion fehlschlagen.

Bemerkung

Bei der Aktualisierung von Dienstcode, der Teil einer nativen App mit Containern ist, können Sie die SYSTEM$WAIT_FOR_SERVICES-Systemfunktion verwenden, um das Skript zur Einrichtung der nativen App anzuhalten, damit die Dienste vollständig aktualisiert werden können. Weitere Informationen dazu finden Sie unter Eine App aktualisieren.

Überwachung rollierender Aktualisierungen

Wenn mehrere Dienstinstanzen laufen, führt Snowflake eine rollierende Aktualisierung in absteigender Reihenfolge auf der Grundlage der ID der Dienstinstanzen durch. Verwenden Sie die folgenden Befehle, um Dienstaktualisierungen zu überwachen:

  • DESCRIBE SERVICE und SHOW SERVICES:

    • Die Spalte is_upgrading in der Ausgabe zeigt TRUE an, wenn der Dienst aktualisiert wird.

    • Die Spalte spec_digest in der Ausgabe stellt den Spec Digest der aktuellen Dienstspezifikation dar. Sie können diesen Befehl in regelmäßigen Abständen ausführen; eine Änderung des spec_digest-Wertes zeigt an, dass ein Dienst-Upgrade ausgelöst wurde. spec_digest wird erst verwendet, wenn aus is_upgrading FALSE geworden ist; andernfalls ist das Dienst-Upgrade noch im Gange.

      Verwenden Sie den Befehl SHOW SERVICE INSTANCES IN SERVICE, um zu überprüfen, ob alle Instanzen auf die neueste Version aktualisiert wurden (siehe unten).

  • SHOW SERVICE INSTANCES IN SERVICE:

    • Die status-Spalte in der Ausgabe enthält den Status jeder einzelnen Dienstinstanz, während das fortlaufende Upgrade läuft. Während des Upgrades werden Sie den Status der einzelnen Dienstinstanzen beobachten, wie z. B. TERMINATING zu PENDING und PENDING zu READY.

    • Während des Dienst-Upgrades kann die Spalte spec_digest in der Ausgabe dieses Befehls einen anderen Wert anzeigen als SHOW SERVICES, der immer den neuesten Spec Digest zurückgibt. Dieser Unterschied zeigt lediglich an, dass die Aktualisierung des Dienstes im Gange ist und die Dienstinstanzen noch die alte Version des Dienstes ausführen.

Informationen zu Diensten abrufen

Sie können die folgenden Befehle verwenden:

  • Verwenden Sie den Befehl DESCRIBE SERVICE, um die Eigenschaften und den Status eines Dienstes abzurufen. Die Ausgabe liefert alle Eigenschaften des Dienstes.

  • Verwenden Sie den SHOW SERVICES Befehl, um die aktuellen Dienste (einschließlich Jobdienste) aufzulisten, für die Sie Berechtigungen haben. Die Ausgabe liefert einige der Eigenschaften und den Status dieser Dienste.

    In der Standardeinstellung listet die Ausgabe die Dienste in der aktuellen Datenbank und im aktuellen Schema auf. Sie können alternativ einen der folgenden Bereiche angeben. Beispiel:

    • Listen Sie die Dienste im Konto, in einer bestimmten Datenbank oder in einem bestimmten Schema auf: Verwenden Sie zum Beispiel den Filter IN ACCOUNT, um die Dienste in Ihrem Snowflake-Konto aufzulisten, unabhängig davon, zu welcher Datenbank oder welchem Schema die Dienste gehören. Dies ist nützlich, wenn Sie Snowflake-Dienste in mehreren Datenbanken und Schemas Ihres Kontos erstellt haben. Wie alle anderen Befehle ist auch SHOW SERVICES IN ACCOUNTS von den Berechtigungen abhängig und gibt nur die Dienste zurück, für die die von Ihnen verwendete Rolle über Anzeigeberechtigungen verfügt.

      Sie können auch IN DATABASE oder IN SCHEMA angeben, um die Dienste in der aktuellen (oder angegebenen) Datenbank oder dem Schema aufzulisten.

    • Listen Sie die Dienste auf, die in einem Computepool ausgeführt werden: Verwenden Sie zum Beispiel den Filter IN COMPUTE POOL, um die Dienste aufzulisten, die in einem Computepool ausgeführt werden.

    • Auflistung der Dienste, die mit einem Präfix beginnen oder einem Muster entsprechen: Sie können die Filter LIKE und STARTS WITH anwenden, um die Dienste nach Namen zu filtern.

    • Auflistung von Diensten oder Ausschluss von Diensten aus der Liste: Sie können SHOW JOB SERVICES oder SHOW SERVICES EXCLUDE JOBS verwenden, um nur Dienste aufzulisten oder Dienste auszuschließen.

    Sie können diese Optionen auch kombinieren, um die Ausgabe von SHOW SERVICES anzupassen.

  • Verwenden Sie den Befehl SHOW SERVICE INSTANCES IN SERVICE, um Eigenschaften der Dienstinstanzen abzurufen.

  • Verwenden Sie den SHOW SERVICE CONTAINERS IN SERVICE-Befehl, um die Eigenschaften und den Status der Dienstinstanzen abzurufen.

Überwachen von Diensten

Snowpark Container Services bietet Tools zur Überwachung der Computepools in Ihrem Konto und der darauf ausgeführten Services. Weitere Informationen dazu finden Sie unter Snowpark Container Services: Überwachen von Diensten.

Verwenden eines Dienstes

Nachdem Sie einen Dienst erstellt haben, können die Benutzer desselben Kontos (das den Dienst erstellt hat) ihn nutzen. Es gibt drei Methoden zur Nutzung eines Dienstes, wie in der Abbildung dargestellt. Der Benutzer benötigt Zugriff auf Rollen mit den erforderlichen Berechtigungen.

Methoden zur Nutzung eines Dienstes

Das Diagramm hebt die Methoden zur Nutzung des Dienstes hervor, während andere dienstbezogene Komponenten zur besseren Übersichtlichkeit ausgegraut sind. Eine detaillierte Erklärung der Dienstkomponenten finden Sie in der Abbildung am Anfang dieser Seite.

  • Verwenden Sie den Dienst aus einer SQL-Abfrage (Dienstfunktion): Sie erstellen eine Dienstfunktion, eine benutzerdefinierte Funktion (UDF), die mit einem Dienst verknüpft ist, und verwenden sie in einer SQL-Abfrage und nutzen die benutzerdefinierte Datenverarbeitung, die Ihr Service bietet. Ein Beispiel dazu finden Sie unter Tutorial 1.

  • Verwenden Sie den Dienst von außerhalb von Snowflake (Eingang): Sie können einen oder mehrere Dienstendpunkte als öffentlich deklarieren, um den Zugriff auf den Dienst über Netzwerk-Eingang zu ermöglichen. Damit können Sie Webanwendungen erstellen oder APIs über Ihre Snowflake-Daten offenlegen. Ein Beispiel dazu finden Sie unter Tutorial 1.

  • Dienst eines anderen Dienstes verwenden (Dienst-zu-Dienst-Kommunikation): Dienste können miteinander kommunizieren, indem sie den von Snowflake zugewiesenen DNS Dienstnamen für die Dienst-zu-Dienst-Kommunikation verwenden. Ein Beispiel finden Sie unter Tutorial 3.

Wie das Diagramm veranschaulicht, senden Sie bei der Kommunikation mit einem Dienst über eine dieser Methoden Anfragen an Endpunkte, die der Dienst bereitstellt, und erhalten Ergebnisse.

Bemerkung

  • Die Verwendung einer Dienstfunktion oder eines Eingangs zur Kommunikation mit einem Jobdienst wird nicht unterstützt.

    • Sie können eine Dienstfunktion nicht mit einem Endpunkt eines Auftragsdienstes verknüpfen.

    • Sie können keinen Jobdienst mit einer Spezifikation erstellen, die einen öffentlichen Endpunkt definiert.

  • Die Dienst-zu-Dienst-Kommunikation mit Jobdiensten wird unterstützt. Das heißt, Services und Jobdienste können miteinander kommunizieren.

Die folgenden Abschnitte enthalten weitere Details.

Dienstfunktionen: Verwenden eines Dienstes aus einer SQL-Abfrage

Eine Dienstfunktion ist eine benutzerdefinierte Funktion (UDF), die Sie mit CREATE FUNCTION (Snowpark Container Services) erstellen. Anstatt jedoch den Code von UDF direkt zu schreiben, verknüpfen Sie die UDF mit Ihrem Dienstendpunkt. Beachten Sie, dass Sie eine Dienstfunktion nur mit einem Dienstendpunkt verknüpfen können, der das Protokoll HTTP unterstützt (siehe Feld spec.endpoints (optional)).

In Tutorial 1 erstellen Sie beispielsweise einen Dienst namens echo_service, der einen Endpunkt (echoendoint) gemäß der Definition in der Dienstspezifikation bereitstellt:

spec:

  endpoints:
  - name: echoendpoint
    port: 8080
Copy

echoendpoint ist ein benutzerfreundlicher Endpunktname, der den entsprechenden Port (8080) darstellt. Um mit diesem Dienstendpunkt zu kommunizieren, erstellen Sie eine Dienstfunktion, indem Sie die Parameter SERVICE und ENDPOINT wie gezeigt angeben:

CREATE FUNCTION my_echo_udf (text varchar)
   RETURNS varchar
   SERVICE=echo_service
   ENDPOINT=echoendpoint
   AS '/echo';
Copy

Der Parameter AS stellt den HTTP-Pfad zum Dienstcode bereit. Sie erhalten diesen Pfad-Wert aus dem Dienstcode. Die folgenden Zeilen stammen zum Beispiel aus service.py in Tutorial 1.

@app.post("/echo")
def echo():
...
Copy

Sie rufen die Dienstfunktion in einer SELECT-Anweisung wie der folgenden auf:

SELECT service_function_name(<parameter-list>);
Copy

Snowflake leitet die Anfrage an den zugehörigen Dienstendpunkt und Pfad weiter.

Bemerkung

Eine Dienstfunktion wird zur Kommunikation mit einem Dienst, aber nicht mit einem Job verwendet. Mit anderen Worten: Sie können nur einen Dienst (keinen Job) mit einer Dienstfunktion verknüpfen.

Datenaustauschformat

Für den Datenaustausch zwischen einer Dienstfunktion und einem Anwendungscontainer folgt Snowflake demselben Format, das auch externe Funktionen verwenden (siehe Datenformate). Angenommen, Sie haben Datenzeilen in einer Tabelle (input_table) gespeichert:

"Alex", "2014-01-01 16:00:00"
"Steve", "2015-01-01 16:00:00"

Um diese Daten an Ihren Dienst zu senden, rufen Sie die Dienstfunktion auf, indem Sie diese Zeilen als Parameter übergeben:

SELECT service_func(col1, col2) FROM input_table;
Copy

Snowflake sendet eine Reihe von Anforderung an den Container, wobei die Batches von Datenzeilen im Anforderungstext in diesem Format vorliegen:

{
   "data":[
      [
         0,
         "Alex",
         "2014-01-01 16:00:00"
      ],
      [
         1,
         "Steve",
         "2015-01-01 16:00:00"
      ],
      …
      [
         <row_index>,
         "<column1>",
         "<column2>"
      ],
   ]
}
Copy

Der Container gibt dann die Ausgabe in folgendem Format zurück:

{
   "data":[
      [0, "a"],
      [1, "b"],
      …
      [ row_index,  output_column1]
   ]
}
Copy

Die gezeigte Beispielausgabe geht davon aus, dass das Ergebnis eine einspaltige Tabelle mit Zeilen („a“, „b“ …) ist.

Batchverarbeitung konfigurieren

Die Befehle CREATE FUNCTION und ALTER FUNCTION unterstützen Parameter, die konfigurieren, wie Snowflake Batches von Daten verarbeitet, die von Ihrem Dienst verarbeitet werden.

  • Batchgröße konfigurieren

    Sie können den Parameter MAX_BATCH_ROWS verwenden, um die Batchgröße zu begrenzen, d. h. die maximale Anzahl von Zeilen, die Snowflake in einer einzigen Anfrage an Ihren Dienst sendet. Dies hilft, das Volumen der übertragenen Daten zu kontrollieren. Dies kann auch zu mehr, kleineren Batches führen, die parallel verarbeitet werden können, wenn Ihr Dienst mehrere Instanzen oder gleichzeitige Anfragen unterstützt.

  • Fehlerbehandlung

    Sie können diese Parameter für die Batch-Fehlerbehandlung verwenden: ON_BATCH_FAILURE, MAX_BATCH_RETRIES, und BATCH_TIMEOUT_SECS.

Der folgende ALTER FUNCTION-Befehl konfiguriert zum Beispiel die Parameter MAX_BATCH_ROWS und MAX_BATCH_RETRIES der Dienstfunktion my_echo_udf:

ALTER FUNCTION my_echo_udf(VARCHAR) SET
   MAX_BATCH_ROWS = 15
   MAX_BATCH_RETRIES = 5;
Copy

Erforderliche Berechtigungen zum Erstellen und Verwalten von Dienstfunktionen

Um Dienstfunktionen zu erstellen und zu verwalten, benötigt eine Rolle die folgenden Berechtigungen:

  • Die aktuelle Rolle muss die Dienstrolle haben, die für den Endpunkt gewährt wird, auf den im Befehl CREATE FUNCTION oder ALTER FUNCTION verwiesen wird.

  • Um eine Dienstfunktion in einer SQL-Abfrage zu verwenden, muss die aktuelle Sitzung über eine Rolle mit Nutzungsberechtigung für die Dienstfunktion verfügen und die Eigentümerrolle der Dienstfunktion muss die Dienstrolle für den zugehörigen Dienstendpunkt erhalten.

Das folgende Beispielskript zeigt, wie Sie Berechtigungen zum Erstellen und Verwenden einer Dienstfunktion erteilen können:

USE ROLE service_owner;
GRANT USAGE ON DATABASE service_db TO ROLE func_owner;
GRANT USAGE ON SCHEMA my_schema TO ROLE func_owner;
GRANT SERVICE ROLE ON service service_db.my_schema.my_service!all_endpoints_usage TO ROLE func_owner;
USE ROLE func_owner;
CREATE OR REPLACE test_udf(v VARCHAR)
  RETURNS VARCHAR
  SERVICE=service_db.my_schema.my_service
  ENDPOINT=endpointname1
  AS '/run';

SELECT test_udf(col1) FROM some_table;

ALTER FUNCTION test_udf(VARCHAR) SET
  SERVICE = service_db.other_schema.other_service
  ENDPOINT=anotherendpoint;

GRANT USAGE ON DATABASE service_db TO ROLE func_user;
GRANT USAGE ON SCHEMA my_schema TO ROLE func_user;
GRANT USAGE ON FUNCTION test_udf(varchar) TO ROLE func_user;
USE ROLE func_user;
SELECT my_test_udf('abcd');
Copy

Dateneingang: Verwenden eines Dienstes von außerhalb von Snowflake

Sie können einen oder mehrere Endpunkte in der Dienstspezifikation als öffentlich deklarieren, damit Benutzer den Dienst von der Öffentlichkeit aus nutzen können. Beachten Sie, dass die Benutzer Snowflake-Benutzer in demselben Snowflake-Konto sein müssen, das den Dienst erstellt hat.

spec
  ...
  endpoints
  - name: <endpoint name>
    port: <port number>
    public: true
Copy

Beachten Sie, dass Eingang nur mit einem HTTP-Endpunkt erlaubt ist (siehe Feld spec.endpoints (optional)).

Eingang-Authentifizierung

Ein Benutzer kann auf einen öffentlichen Endpunkt zugreifen, wenn ihm eine Dienstrolle gewährt wird, die den Zugriff auf diesen Endpunkt erlaubt. (Siehe Erforderliche Berechtigungen für den Zugriff auf die Dienstendpunkte (Dienstrollen)).

Dann können Benutzer über einen Browser oder programmgesteuert auf den öffentlichen Endpunkt zugreifen.

  • Zugriff auf einen öffentlichen Endpunkt mit Hilfe eines Browsers: Wenn der Benutzer einen Browser verwendet, um auf einen öffentlichen Endpunkt zuzugreifen, leitet Snowflake den Benutzer automatisch auf eine Anmeldeseite um. Der Benutzer muss seine Snowflake-Anmeldeinformationen angeben, um sich anzumelden. Nach erfolgreicher Anmeldung hat der Benutzer Zugriff auf den Endpunkt. Hinter den Kulissen erzeugt die Benutzeranmeldung ein OAuth-Token von Snowflake. Das OAuth-Token wird dann verwendet, um eine Anforderung an den Dienstendpunkt zu senden.

  • Programmgesteuerter Zugriff auf einen öffentlichen Endpunkt: Ihre Anwendung kann die Authentifizierung des Schlüsselpaares verwenden, um Anfragen an den öffentlichen Endpunkt zu authentifizieren. In Ihrem Code generieren Sie ein JSON-Web Token (JWT) aus dem Schlüsselpaar, tauschen das JWT Token mit Snowflake gegen ein OAuth-Token aus und verwenden dann das OAuth-Token zur Authentifizierung von Anfragen an den öffentlichen Endpunkt eines Dienstes.

Tutorial 1 bietet Ihnen schrittweise Anweisungen zum Testen des Zugriffs auf öffentliche Endpunkte.

Die Authentifizierung mit einem Schlüsselpaar, wie in Tutorial 1 gezeigt, ist die empfohlene Methode zur Authentifizierung von Anfragen beim Zugriff auf öffentliche Endpunkte. Der folgende Code kann zur Authentifizierung als Alternative zur Verwendung eines Schlüsselpaars verwendet werden. Es gibt jedoch keine Garantie, dass der Code mit zukünftigen Versionen von Snowflake Connector für Python funktioniert. Dieser Python-Code verwendet den Python-Konnektor, um zunächst ein Sitzungs-Token zu erzeugen, das Ihre Identität darstellt. Der Code verwendet dann das Sitzungs-Token, um sich bei dem öffentlichen Endpunkt anzumelden.

import snowflake.connector
import requests

ctx = snowflake.connector.connect(
   user="<username>",# username
   password="<password>", # insert password here
   account="<orgname>-<acct-name>",
   session_parameters={
      'PYTHON_CONNECTOR_QUERY_RESULT_FORMAT': 'json'
   })

# Obtain a session token.
token_data = ctx._rest._token_request('ISSUE')
token_extract = token_data['data']['sessionToken']

# Create a request to the ingress endpoint with authz.
token = f'\"{token_extract}\"'
headers = {'Authorization': f'Snowflake Token={token}'}
# Set this to the ingress endpoint URL for your service
url = 'http://<ingress_url>'

# Validate the connection.
response = requests.get(f'{url}', headers=headers)
print(response.text)

# Insert your code to interact with the application here
Copy

Erläuterungen zum Code:

  • Wenn Sie Ihre Kontoinformationen nicht kennen (<Organisationsname>-<Kontoname>), lesen Sie das Tutorial Grundlegende Einrichtung.

  • Sie können den ingress_url-Wert des öffentlichen Endpunkts, der vom Dienst bereitgestellt wird, mit SHOW ENDPOINTS abrufen.

Benutzerspezifische Header bei Dateneingangsanforderungen

Wenn eine Anfrage für einen öffentlichen Endpunkt eintrifft, übergibt Snowflake automatisch den folgenden Header zusammen mit der HTTP-Anfrage an den Container.

Sf-Context-Current-User: <user_name>
Copy

Der Containercode kann den Header optional lesen, weiß, wer der Aufrufer ist, und kann kontextspezifische Anpassungen für verschiedene Benutzer vornehmen. Darüber hinaus kann Snowflake optional den Header Sf-Context-Current-User-Email einschließen. Um diesen Header einzufügen, wenden Sie sich an den Snowflake-Support.

Dienst-zu-Dienst-Kommunikation

Dienstinstanzen können direkt über TCP (einschließlich HTTP) miteinander kommunizieren. Dies gilt sowohl für Instanzen, die zum selben Dienst gehören, als auch für Instanzen, die zu verschiedenen Diensten gehören.

Instanzen können nur Kommunikationen (Anfragen) über die in der Dienstspezifikation angegebenen Endpunkte empfangen. Der Client (der Dienst, der die Anfrage sendet) muss über die erforderlichen Rollen und Berechtigungen verfügen, um eine Verbindung zu diesem Endpunkt herzustellen (siehe Erforderliche Berechtigungen für den Zugriff auf die Dienstendpunkte (Dienstrollen)).

  • Standardmäßig kann sich eine Dienstinstanz mit anderen Instanzen desselben Dienstes an den angegebenen Endpunkten verbinden. Allgemeiner ausgedrückt, hat die Eigentümerrolle eines Dienstes die Berechtigung, sich mit Endpunkten von Diensten mit der gleichen Eigentümerrolle zu verbinden.

  • Damit ein Client-Dienst eine Verbindung zu einem Endpunkt eines Dienstes herstellen kann, der eine andere Eigentümerrolle hat, benötigt die Eigentümerrolle des Client-Dienstes die Dienstrolle, die den Zugriff auf den Endpunkt eines anderen Dienstes gewährt, um diesen Endpunkt aufzurufen. Weitere Informationen dazu finden Sie unter Erforderliche Berechtigungen für den Zugriff auf die Dienstendpunkte (Dienstrollen).

  • Wenn Sie verhindern möchten, dass Ihre Dienste miteinander kommunizieren (z. B. aus Sicherheitsgründen), verwenden Sie verschiedene Snowflake-Rollen, um diese Dienste zu erstellen.

Eine Dienstinstanz kann entweder über die IP-Adresse des Dienstes oder die IP-Adressen der Dienstinstanz erreicht werden.

  • Anfragen, die die Dienst-IP-Adresse verwenden, werden an einen Load-Balancer weitergeleitet, der wiederum Anfragen an eine zufällig ausgewählte Dienstinstanz weiterleitet.

  • Anfragen, die die IP-Adresse der Dienstinstanz verwenden, werden direkt an die entsprechende Dienstinstanz weitergeleitet. Sie müssen die Dienstinstanz-IP verwenden, wenn Sie sich mit einem Endpunkt verbinden, der über das Feld portRange definiert ist (siehe Feld spec.endpoints (optional)).

Beide IP-Adressen sind über den DNS-Namen auffindbar, den Snowflake jedem Dienst automatisch zuweist. Beachten Sie, dass es nicht möglich ist, DNS zu verwenden, um eine Verbindung zu einer bestimmten Instanz herzustellen. So ist es beispielsweise nicht sinnvoll, eine URL unter Verwendung des Namens der Dienstinstanz DNS zu erstellen, da es keine Möglichkeit gibt, den Namen der Dienstinstanz DNS zu verwenden, um auf eine bestimmte Dienstinstanz zu verweisen.

Die IP-Adressen von Dienstinstanzen werden in der Ausgabe des Befehls SHOW SERVICE INSTANCES IN SERVICE angezeigt, wenn das Verhaltensänderungs-Bundle 2025_01 aktiviert ist.

Ein Beispiel für die Kommunikation von Dienst zu Dienst finden Sie unter Tutorial 3.

Beachten Sie, dass, wenn ein Dienstendpunkt nur erstellt wird, um die Kommunikation zwischen Diensten zu ermöglichen, das TCP-Protokoll verwendet werden sollte (siehe Feld spec.endpoints (optional)).

Name des DNS-Dienstes

Das DNS-Namensformat ist:

<service-name>.<hash>.svc.spcs.internal

Verwenden Sie SHOW SERVICES (oder DESCRIBE SERVICE), um den DNS-Namen eines Dienstes zu erhalten. Der vorangehende DNS-Name ist ein vollqualifizierter Name. Dienste, die im selben Schema erstellt wurden, können nur über den <service-name> kommunizieren. Anbieter, die sich in einem anderen Schema oder einer anderen Datenbank befinden, müssen den Hash angeben, z. B. <service-name>.<Hash> oder den vollqualifizierten Namen (<service-name>.<Hash>.svc.spcs.internal).

Verwenden Sie die Funktion SYSTEM$GET_SERVICE_DNS_DOMAIN, um die DNS-Domäne für ein bestimmtes Schema zu finden. Die DNS-Hashwert-Domäne ist spezifisch für die aktuelle Version des Schemas. Beachten Sie Folgendes:

  • Wenn dieses Schema oder die zugehörige Datenbank umbenannt wird, ändert sich der Hashwert nicht.

  • Wenn das Schema gelöscht und dann neu erstellt wird (z. B. mit CREATE OR REPLACE SCHEMA), erhält das neue Schema einen neuen Hashwert. Wenn Sie ein UNDROP-Schema verwenden, bleibt der Hashwert gleich.

DNS-Namen haben die folgenden Einschränkungen:

  • Ihr Dienstname muss ein gültiges DNS-Label sein. (Siehe auch https://www.ietf.org/rfc/rfc1035.html#section-2.3.1). Andernfalls wird das Erstellen eines Dienstes fehlschlagen.

  • Snowflake ersetzt einen Unterstrich (_) im Dienstnamen durch einen Bindestrich (-) im DNS-Namen.

  • Ein DNS-Name dient nur der internen Kommunikation innerhalb von Snowflake zwischen Diensten, die in demselben Konto ausgeführt werden. Er ist nicht über das Internet zugänglich.

DNS-Name der Dienstinstanzen

Das DNS-Namensformat der Dienstinstanz lautet wie folgt:

instances.<service-name>.<hash>.svc.spcs.internal

Sie wird in eine Liste von IP-Adressen aufgelöst, für jede Dienstinstanz. Beachten Sie, dass es keine garantierte Reihenfolge für die Liste der IP-Adressen gibt, die DNS zurückgibt. Dieser DNS-Name sollte nur mit DNS APIs verwendet werden, nicht als Hostname in einer URL. Die Erwartung ist, dass Ihre Anwendung diesen Hostnamen mit DNS APIs verwendet, um die Gruppe von Dienstinstanz-IPs zu sammeln und sich dann programmgesteuert direkt mit diesen Instanz-IPs zu verbinden.

Diese Liste von IP-Adressen ermöglicht die Erstellung eines Mesh-Netzwerks für die direkte Kommunikation zwischen bestimmten Dienstinstanzen.

Welchen DNS-Namen Sie wählen sollten

Die folgenden Überlegungen gelten für die Wahl des DNS-Namens, den Sie für die Verbindung zu einem Dienst bei der Kommunikation von Dienst zu Dienst verwenden.

Verwenden Sie den DNS-Dienstnamen, wenn einer der folgenden Punkte zutrifft:

  • Sie müssen auf einen bestimmten Port zugreifen, und zwar auf die einfachste Art und Weise.

  • Sie möchten, dass jede Anfrage an eine zufällig ausgewählte Dienstinstanz gesendet wird.

  • Sie wissen nicht, wie Ihr Anwendungsframework die DNS-Antworten ausführt und zwischenspeichert.

Verwenden Sie die den DNS-Namen der Dienstinstanz oder die IP der Dienstinstanz, wenn einer der folgenden Punkte zutrifft:

  • Sie möchten die IP-Adressen aller Dienstinstanzen ermitteln.

  • Sie möchten einen zwischengeschalteten Load Balancer auslassen.

  • Sie verwenden verteilte Frameworks oder Datenbanken wie Ray oder Cassandra, die IP-Adressen von Dienstinstanzen als Identitäten verwenden.

Richtlinien und Einschränkungen

Weitere Informationen dazu finden Sie unter Richtlinien und Einschränkungen.