KFServing InferenceService 배포와 예측 – PyTorch

PyTorch를 사용하는 InferenceService

학습이 완료된 PyTorch 모델을 저장 한 경우, KFServing에서 제공하는 PyTorch 서버를 사용하여 간단히 배포 할 수 있습니다.

전제 조건

  • state_dict() 사용하여 모델을 저장해야 합니다.

모델 생성

PyTorch 서버를 테스트하려면 먼저 파이썬을 사용하여 간단한 PyTorch 모델을 생성해야 합니다.

추론을 위해 모델을 저장할 때, 학습이 완료된 모델의 학습 매개 변수만 저장하면 됩니다. torch.save()함수를 사용하여 모델의 state_dict 를 저장하면 나중에 모델을 복원 할 때 유연성이 가장 높아 지므로 모델 저장에 권장되는 방법입니다. 현재 KFServing은 PyTorch가 추론을 위해 권장하는 모델 저장 방법인 state_dict() 메소드를 사용하여 저장된 PyTorch 모델을 지원합니다.

PyTorch의 KFServing 인터페이스는 사용자가 PyTorch 모델과 동일한 위치에 model_class_file을 업로드 할 것으로 예상하고 선택적 model_class_name을 런타임 입력으로 전달하도록 허용합니다. 모델 클래스 이름을 지정하지 않으면 ‘PyTorchModel’을 기본 클래스 이름으로 사용합니다. 다른 인터페이스를 사용하여 저장된 PyTorch 모델을 지원하기 위해, 이 인터페이스가 발전함에 따라 현재 인터페이스가 변경 될 수 있습니다.

PyTorch의 데이터셋 중의 하나인 cifar10 데이터를 분류하는 모델을 작성해 보겠습니다.

cifar10.py

import torch
import torchvision
import torchvision.transforms as transforms
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim


class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(3, 6, 5)
        self.pool = nn.MaxPool2d(2, 2)
        self.conv2 = nn.Conv2d(6, 16, 5)
        self.fc1 = nn.Linear(16 * 5 * 5, 120)
        self.fc2 = nn.Linear(120, 84)
        self.fc3 = nn.Linear(84, 10)

    def forward(self, x):
        x = self.pool(F.relu(self.conv1(x)))
        x = self.pool(F.relu(self.conv2(x)))
        x = x.view(-1, 16 * 5 * 5)
        x = F.relu(self.fc1(x))
        x = F.relu(self.fc2(x))
        x = self.fc3(x)
        return x


if __name__ == "__main__":

    transform = transforms.Compose(
        [transforms.ToTensor(),
         transforms.Normalize((0.5, 0.5, 0.5), (0.5, 0.5, 0.5))])

    trainset = torchvision.datasets.CIFAR10(root='./data', train=True,
                                            download=True, transform=transform)
    trainloader = torch.utils.data.DataLoader(trainset, batch_size=4,
                                              shuffle=True, num_workers=2)

    testset = torchvision.datasets.CIFAR10(root='./data', train=False,
                                           download=True, transform=transform)
    testloader = torch.utils.data.DataLoader(testset, batch_size=4,
                                             shuffle=False, num_workers=2)

    classes = ('plane', 'car', 'bird', 'cat',
               'deer', 'dog', 'frog', 'horse', 'ship', 'truck')

    net = Net()

    criterion = nn.CrossEntropyLoss()
    optimizer = optim.SGD(net.parameters(), lr=0.001, momentum=0.9)

    for epoch in range(2):  # loop over the dataset multiple times

        running_loss = 0.0
        for i, data in enumerate(trainloader, 0):
            # get the inputs; data is a list of [inputs, labels]
            inputs, labels = data

            # zero the parameter gradients
            optimizer.zero_grad()

            # forward + backward + optimize
            outputs = net(inputs)
            loss = criterion(outputs, labels)
            loss.backward()
            optimizer.step()

            # print statistics
            running_loss += loss.item()
            if i % 2000 == 1999:    # print every 2000 mini-batches
                print('[%d, %5d] loss: %.3f' %
                      (epoch + 1, i + 1, running_loss / 2000))
                running_loss = 0.0

    print('Finished Training')

    # Save model
    torch.save(net.state_dict(), "model.pt")

생성 된 모델을 사용하여 PyTorch 서버를 실행하고 예측을 수행 할 수 있습니다. 모델은 PV, S3 호환 가능 개체 저장소, Azure Blob 저장소 또는 Google Cloud Storage에 있을 수 있습니다.

모델 저장하기

쿠버네티스의 퍼시스턴스 볼륨에 모델을 저장해 보겠습니다. PVC 는 앞서 생성한 kfserving-models-pvc 을 사용하겠습니다. 모델을 학습시키기 위해서 쿠버네티스 잡(Job)을 사용하겠습니다. Job을 생성할 때 모델을 저장하기 위한 PVC를 마운트 해줍니다.

모델 코드 작성하기

cifa10 이미지를 분류하는 모델입니다. 모델을 저장할 위치를 --model_path 파라미터로 입력받게 하였습니다. state_dict() 메소드를 사용하여 모델을 저장하게 되면, 학습된 파라미터만 저장이 됩니다. 그래서 모델이 정의된 파이썬 파일이 별도로 필요합니다. 모델이 정의된 파이썬 파일도 같이 저장소에 복사해 줍니다.

ipytorch_cifar10.py

import argparse
import os
import shutil

import torch
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torchvision
import torchvision.transforms as transforms


class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(3, 6, 5)
        self.pool = nn.MaxPool2d(2, 2)
        self.conv2 = nn.Conv2d(6, 16, 5)
        self.fc1 = nn.Linear(16 * 5 * 5, 120)
        self.fc2 = nn.Linear(120, 84)
        self.fc3 = nn.Linear(84, 10)

    def forward(self, x):
        x = self.pool(F.relu(self.conv1(x)))
        x = self.pool(F.relu(self.conv2(x)))
        x = x.view(-1, 16 * 5 * 5)
        x = F.relu(self.fc1(x))
        x = F.relu(self.fc2(x))
        x = self.fc3(x)
        return x


if __name__ == "__main__":

    parser = argparse.ArgumentParser()
    parser.add_argument('--model_path', default='/mnt/pv/models/pytorch/iris', type=str)
    args = parser.parse_args()

    model_path = args.model_path
    if not (os.path.isdir(model_path)):
        os.makedirs(model_path)

    model_file = os.path.join(model_path, 'model.pt')

    transform = transforms.Compose(
        [transforms.ToTensor(),
         transforms.Normalize((0.5, 0.5, 0.5), (0.5, 0.5, 0.5))])

    trainset = torchvision.datasets.CIFAR10(root='./data', train=True,
                                            download=True, transform=transform)
    trainloader = torch.utils.data.DataLoader(trainset, batch_size=4,
                                              shuffle=True, num_workers=2)

    testset = torchvision.datasets.CIFAR10(root='./data', train=False,
                                           download=True, transform=transform)
    testloader = torch.utils.data.DataLoader(testset, batch_size=4,
                                             shuffle=False, num_workers=2)

    classes = ('plane', 'car', 'bird', 'cat',
               'deer', 'dog', 'frog', 'horse', 'ship', 'truck')

    net = Net()
    if torch.cuda.is_available():
        print('Use GPU')
        net = net.cuda()

    criterion = nn.CrossEntropyLoss()
    optimizer = optim.SGD(net.parameters(), lr=0.001, momentum=0.9)

    for epoch in range(2):  # loop over the dataset multiple times

        running_loss = 0.0
        for i, data in enumerate(trainloader, 0):
            # get the inputs; data is a list of [inputs, labels]
            inputs, labels = data

            # zero the parameter gradients
            optimizer.zero_grad()

            # forward + backward + optimize
            outputs = net(inputs)
            loss = criterion(outputs, labels)
            loss.backward()
            optimizer.step()

            # print statistics
            running_loss += loss.item()
            if i % 2000 == 1999:  # print every 2000 mini-batches
                print('[%d, %5d] loss: %.3f' %
                      (epoch + 1, i + 1, running_loss / 2000))
                running_loss = 0.0

    print('Finished Training')

    # Save model
    torch.save(net.state_dict(), model_file)

    shutil.copy(os.path.abspath(__file__), os.path.join(model_path, __file__))

컨테이너 이미지를 만들기

컨테이너 이미지를 만들기 위한 Dockerfile 입니다. 파이썬을 기본 이미지로 사용하고, torchtorchvision 패키지를 추가로 설치합니다.

Dockerfile

FROM python:3.6-slim

RUN pip install torch torchvision

RUN mkdir -p /app
ADD pytorch_cifar10.py /app/

쿠버네티스 잡 실행하기

컨테이너 이미지를 빌드하고, 컨테이너 이미지 레지스트리에 푸시 한 다음, 쿠버네티스 잡(Job)을 생성하겠습니다.

Job을 생성할 때는 모델을 저장하기 위해서 PVC를 마운트 해줍니다. 이 일련의 작업들은 직접 실행 할 수 있습니다. 하지만 좀 더 편하게 하기 위해서 앞서 배운 Kubeflow Fairing을 사용하겠습니다.

다음은 로컬 개발 환경에서 Fairing을 사용하여 컨테이너 이미지를 만들고, 쿠버네티스 잡을 실행하는 예제입니다.

fairing-local-docker.py

import uuid
from kubeflow import fairing
from kubeflow.fairing.kubernetes import utils as k8s_utils

CONTAINER_REGISTRY = 'kangwoo'

namespace = 'admin'
job_name = f'sklean-iris-job-{uuid.uuid4().hex[:4]}'

command=["python", "pytorch_cifar10.py", "--model_path", "/mnt/pv/models/pytorch/cifar10"]
output_map = {
    "Dockerfile": "Dockerfile",
    "pytorch_cifar10.py": "pytorch_cifar10.py"
}

fairing.config.set_preprocessor('python', command=command, path_prefix="/app", output_map=output_map)

fairing.config.set_builder('docker', registry=CONTAINER_REGISTRY, image_name="pytorch-cifar10", dockerfile_path="Dockerfile")

fairing.config.set_deployer('job', namespace=namespace, job_name=job_name,
                            pod_spec_mutators=[k8s_utils.mounting_pvc(pvc_name='kfserving-models-pvc', pvc_mount_path='/mnt/pv')],
                            cleanup=True, stream_log=True)

fairing.config.run()

fairing을 실행하면 쿠버네티스 잡이 생성되고, 학습이 완료된 모델이 지정한 경로에 저장됩니다.

PyTorch을 사용하는 InferenceService 로 예측 하기

InferenceService 생성

InferenceService 매니페스트를 작성합니다. predictor로 pytorch 을 사용합니다. storageUri 필드로 모델 저장 위치를 지정해 줍니다. pvc 의 이름이 kfserving-models-pvc 이고 저장 위치가 models/pytorch/cifar10/ 이므로, pvc://kfserving-models-pvc/models/pytorch/cifar10/ 라고 지정해 줍니다.

앞서 학습 할때 사용한 모델 클래스의 이름이 Net 입니다. modelClassName 에 모델 클래스의 이름인 Net 를 지정해 줍니다. 만약 모델 클래스 이름을 별도로 지정해 주지 않으면, 기본값인 PyTorchModel 을 모델 클래스 이름으로 사용합니다.

pytorch.yaml

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "pytorch-cifar10"
spec:
  default:
    predictor:
      pytorch:
        storageUri: "pvc://kfserving-models-pvc/models/pytorch/cifar10/"
        modelClassName: "Net"

만약 GPU 리소스를 사용하려고 한다면, resource 필드에 GPU 를 할당해 주면됩니다.

pytorch_gpu.yaml

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "pytorch-cifar10-gpu"
spec:
  default:
    predictor:
      pytorch:
        storageUri: "pvc://kfserving-models-pvc/models/pytorch/cifar10/"
        modelClassName: "Net"
        resources:
          limits:
            cpu: 100m
            memory: 1Gi
            nvidia.com/gpu: "1"

InferenceService 를 생성합니다.

다음은 admin 네임스페이스 InferenceService 를 생성하는 예제입니다.

kubectl -n admin apply -f pytorch.yaml

생성한 InferenceService를 조회해 보겠습니다.

kubectl -n admin get inferenceservice

InferenceService 가 정상적으로 생성되면 다음과 같은 응답 결과를 확인할 수 있습니다.

NAME              URL                                                                  READY   DEFAULT TRAFFIC   CANARY TRAFFIC   AGE
pytorch-cifar10   <http://pytorch-cifar10.admin.example.com/v1/models/pytorch-cifar10>   True    100                                59s

예측 실행하기

예측을 요청하기 위해서는 모델 서버에 접근해야 합니다. 모델 서버는 ingressgateway 를 통해서 접근할 수 있습니다. ingressgateway 는 모델 서버들을 구분하기 위해서 호스트 이름을 사용합니다. ingressgateway에 접근하 기 위한 주소는 앞서 정의한 CLUSTER_IP 를 사용하겠습니다.

예측을 요청할 데이터를 json 파일로 작성합니다.

데이터의 크기가 크기 때문에 git 에 있는 파일을 다운받아서 사용해주세요.

cifar10-input.json

{
   "instances":[
      [
         [
            [
               0.23921573162078857,
               0.24705886840820312,
               0.29411768913269043,
               0.301960825920105,
               0.2549020051956177,
               0.22352945804595947,
               0.2705882787704468,
               0.24705886840820312,
               0.23921573162078857,
               0.24705886840820312,
               0.2627451419830322,
               0.2549020051956177,
               0.2627451419830322,
               0.301960825920105,
               0.32549023628234863,
               0.3333333730697632,
               0.30980396270751953,
               0.2705882787704468,
               0.2549020051956177,
               0.2549020051956177,
               0.22352945804595947,
               0.16862750053405762,
               0.17647063732147217,
               0.16078436374664307,
               0.16862750053405762,
               0.12156867980957031,
               0.09803926944732666,
               0.10588240623474121,
               0.12156867980957031,
               0.07450985908508301,
               -0.011764705181121826,
               -0.09019607305526733
            ]
....
         ]
      ]
   ]
}

다음은 admin 네임스페이스의 xgboost-iris InferenceService 에 예측을 요청하는 예제입니다.

MODEL_NAME=pytorch-cifar10
SERVICE_HOSTNAME=$(kubectl -n admin get inferenceservice pytorch-cifar10 -o jsonpath='{.status.url}' | cut -d "/" -f 3)

INPUT_PATH=@./cifar10-input.json
curl -v -H "Host: ${SERVICE_HOSTNAME}" http://$CLUSTER_IP/v1/models/$MODEL_NAME:predict -d $INPUT_PATH

정상적으로 실행되면 다음과 같은 응답 결과를 확인 할 수 있습니다.

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> POST /v1/models/pytorch-cifar10:predict HTTP/1.1
> Host: pytorch-cifar10.admin.example.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 110681
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< content-length: 224
< content-type: text/html; charset=UTF-8
< date: Sat, 29 Mar 2020 13:36:23 GMT
< server: istio-envoy
< x-envoy-upstream-service-time: 8857
< 
* Connection #0 to host localhost left intact
{"predictions": [[-1.0642542839050293, -2.1011602878570557, 0.829179584980011, 2.3874664306640625, -0.8927481174468994, 1.6838929653167725, 1.1490685939788818, -0.8248656988143921, -0.6572933197021484, 0.05098217725753784]]}

KFServing InferenceService 배포와 예측 – XGBoost

XGBoost를 사용하는 InferenceService

학습이 완료된 XGBoost 모델을 저장 한 경우, KFServing에서 제공하는 XGBoost 서버를 사용하여 간단히 배포 할 수 있습니다.

전제 조건

  • 모델 피클의 이름은 model.bst 여야 합니다.
  • xgboost v0.82 버전을 사용해야 합니다.

모델 생성

XGBoost 서버를 테스트하려면 먼저 파이썬을 사용하여 간단한 XGBoost 모델을 생성해야 합니다.

Scikit-learn의 기본적인 데이터셋 중의 하나인 아이리스 꽃 데이터를 사용하여, 아이리스 꽃을 분류하는 모델을 작성해 보겠습니다. 모델 피클의 이름 model.bst 이어야 합니다.

import xgboost as xgb
from sklearn.datasets import load_iris

iris = load_iris()
X = iris['data']
y = iris['target']
dtrain = xgb.DMatrix(X, label=y)
param = {'max_depth': 6,
         'eta': 0.1,
         'silent': 1,
         'nthread': 4,
         'num_class': 10,
         'objective': 'multi:softmax'
         }
xgb_model = xgb.train(params=param, dtrain=dtrain)
xgb_model.save_model('model.bst')

생성 된 모델을 사용하여 XGBoost 서버를 실행하고 예측을 수행 할 수 있습니다. 모델은 PV, S3 호환 가능 개체 저장소, Azure Blob 저장소 또는 Google Cloud Storage에 있을 수 있습니다.

모델 저장하기

쿠버네티스의 퍼시스턴스 볼륨에 모델을 저장해 보겠습니다. PVC 는 앞서 생성한 kfserving-models-pvc 을 사용하겠습니다. 모델을 학습시키기 위해서 쿠버네티스 잡(Job)을 사용하겠습니다. Job을 생성할 때 모델을 저장하기 위한 PVC를 마운트 해줍니다.

모델 코드 작성하기

아이리스 꽃을 분류하는 간단한 모델입니다. 모델을 저장할 위치를 --model_path 파라미터로 입력받게 하였습니다.

iris.py

import argparse
import os

from joblib import dump
from sklearn import datasets
from sklearn import svm


def train():
    parser = argparse.ArgumentParser()
    parser.add_argument('--model_path', default='/mnt/pv/models/sklearn/iris', type=str)
    args = parser.parse_args()

    if not (os.path.isdir(args.model_path)):
        os.makedirs(args.model_path)

    model_file = os.path.join(args.model_path, 'model.joblib')

    clf = svm.SVC(gamma='scale')
    iris = datasets.load_iris()
    X, y = iris.data, iris.target
    clf.fit(X, y)
    dump(clf, model_file)


if __name__ == '__main__':
    train()

컨테이너 이미지를 만들기

컨테이너 이미지를 만들기 위한 Dockerfile 입니다. 파이썬을 기본 이미지로 사용하고, xgboostscikit-learn 패키지를 추가로 설치합니다.

Dockerfile

FROM python:3.6-slim

RUN pip install xgboost==0.82 scikit-learn

RUN mkdir -p /app
ADD xgboost_iris.py.py /app/

쿠버네티스 잡 실행하기

컨테이너 이미지를 빌드하고, 컨테이너 이미지 레지스트리에 푸시 한 다음, 쿠버네티스 잡(Job)을 생성하겠습니다.

Job을 생성할 때는 모델을 저장하기 위해서 PVC를 마운트 해줍니다. 이 일련의 작업들은 직접 실행 할 수 있습니다. 하지만 좀 더 편하게 하기 위해서 앞서 배운 Kubeflow Fairing을 사용하겠습니다.

다음은 로컬 개발 환경에서 Fairing을 사용하여 컨테이너 이미지를 만들고, 쿠버네티스 잡을 실행하는 예제입니다.

fairing-local-docker.py

import uuid
from kubeflow import fairing
from kubeflow.fairing.kubernetes import utils as k8s_utils

CONTAINER_REGISTRY = 'kangwoo'

namespace = 'admin'
job_name = f'xgboost-iris-job-{uuid.uuid4().hex[:4]}'

command=["python", "iris.py", "--model_path", "/mnt/pv/models/xgboost/iris"]
output_map = {
    "Dockerfile": "Dockerfile",
    "xgboost_iris.py": "xgboost_iris.py"
}

fairing.config.set_preprocessor('python', command=command, path_prefix="/app", output_map=output_map)

fairing.config.set_builder('docker', registry=CONTAINER_REGISTRY, image_name="xgboost-iris", dockerfile_path="Dockerfile")

fairing.config.set_deployer('job', namespace=namespace, job_name=job_name,
                            pod_spec_mutators=[k8s_utils.mounting_pvc(pvc_name='seldon-models-pvc', pvc_mount_path='/mnt/pv')],
                            cleanup=True, stream_log=True)

fairing.config.run()

fairing을 실행하면 쿠버네티스 잡이 생성되고, 학습이 완료된 모델이 지정한 경로에 저장됩니다.

XGBoost을 사용하는 InferenceService 로 예측 하기

InferenceService 생성

InferenceService 매니페스트를 작성합니다. predictor로 xgboost 을 사용합니다. storageUri 필드로 모델 저장 위치를 지정해 줍니다. pvc 의 이름이 kfserving-models-pvc 이고 저장 위치가 models/xgboost/iris 이므로, pvc://kfserving-models-pvc/models/xgboost/iris 라고 지정해 줍니다.

xgboost.yaml

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "xgboost-iris"
spec:
  default:
    predictor:
      xgboost:
        storageUri: "pvc://kfserving-models-pvc/models/xgboost/iris"

InferenceService 를 생성합니다.

다음은 admin 네임스페이스 InferenceService 를 생성하는 예제입니다.

kubectl -n admin apply -f xgboost.yaml

생성한 InferenceService를 조회해 보겠습니다.

kubectl -n admin get inferenceservice

InferenceService 가 정상적으로 생성되면 다음과 같은 응답 결과를 확인할 수 있습니다.

NAME           URL                                                            READY   DEFAULT TRAFFIC   CANARY TRAFFIC   AGE
xgboost-iris   <http://xgboost-iris.admin.example.com/v1/models/xgboost-iris>   True    100                                58s

예측 실행하기

예측을 요청하기 위해서는 모델 서버에 접근해야 합니다. 모델 서버는 ingressgateway 를 통해서 접근할 수 있습니다. ingressgateway 는 모델 서버들을 구분하기 위해서 호스트 이름을 사용합니다. ingressgateway에 접근하 기 위한 주소는 앞서 정의한 CLUSTER_IP 를 사용하겠습니다.

예측을 요청할 데이터를 json 파일로 작성합니다.

iris-input.json

{
  "instances": [
    [6.8,  2.8,  4.8,  1.4],
    [6.0,  3.4,  4.5,  1.6]
  ]
}

다음은 admin 네임스페이스의 xgboost-iris InferenceService 에 예측을 요청하는 예제입니다.

MODEL_NAME=xgboost-iris
SERVICE_HOSTNAME=$(kubectl -n admin get inferenceservice xgboost-iris -o jsonpath='{.status.url}' | cut -d "/" -f 3)

INPUT_PATH=@./iris-input.json
curl -v -H "Host: ${SERVICE_HOSTNAME}" http://$CLUSTER_IP/v1/models/$MODEL_NAME:predict -d $INPUT_PATH

정상적으로 실행되면 다음과 같은 응답 결과를 확인 할 수 있습니다.

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> POST /v1/models/xgboost-iris:predict HTTP/1.1
> Host: xgboost-iris.admin.example.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 76
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 76 out of 76 bytes
< HTTP/1.1 200 OK
< content-length: 27
< content-type: text/html; charset=UTF-8
< date: Sat, 28 Mar 2020 18:54:46 GMT
< server: istio-envoy
< x-envoy-upstream-service-time: 10165
< 
* Connection #0 to host localhost left intact
{"predictions": [1.0, 1.0]}

KFServing InferenceService 배포와 예측 – Scikit-Learn

Scikit-Learn를 사용하는 InferenceService

학습이 완료된 scikit-learn모델을 피클로 저장 한 경우, KFServing에서 제공하는 sklearn 서버를 사용하여 간단히 배포 할 수 있습니다.

전제 조건

  • 모델 피클은 joblib을 사용하여 저장해야 합니다. 그리고 파일명은 model.joblib 이어야 합니다.
  • 현재 sklearn 0.20.3 버전을 사용합니다. 피클 모델은 이 버전과 호환되어야 합니다.

모델 생성

SKLearn 서버를 테스트하려면 먼저 파이썬을 사용하여 간단한 scikit-learn 모델을 생성해야합니다.

Scikit-learn의 기본적인 데이터셋 중의 하나인 아이리스 꽃 데이터를 사용하여, 아이리스 꽃을 분류하는 모델을 작성해 보겠습니다. 모델 피클은 joblib을 사용하여 저장해야 하고, 파일명은 model.joblib 이어야 합니다.

from joblib import dump
from sklearn import datasets
from sklearn import svm

clf = svm.SVC(gamma='scale')
iris = datasets.load_iris()
X, y = iris.data, iris.target
clf.fit(X, y)
dump(clf, 'model.joblib')

생성 된 모델을 사용하여 scikit-learn 서버를 실행하고 예측을 수행 할 수 있습니다. 모델은 PV, S3 호환 가능 개체 저장소, Azure Blob 저장소 또는 Google Cloud Storage에 있을 수 있습니다.

모델 저장하기

쿠버네티스의 퍼시스턴스 볼륨에 모델을 저장해 보겠습니다. PVC 는 앞서 생성한 kfserving-models-pvc 을 사용하겠습니다. 모델을 학습시키기 위해서 쿠버네티스 잡(Job)을 사용하겠습니다. Job을 생성할 때 모델을 저장하기 위한 PVC를 마운트 해줍니다.

모델 코드 작성하기

아이리스 꽃을 분류하는 간단한 모델입니다. 모델을 저장할 위치를 --model_path 파라미터로 입력받게 하였습니다.

iris.py

import argparse
import os

from joblib import dump
from sklearn import datasets
from sklearn import svm


def train():
    parser = argparse.ArgumentParser()
    parser.add_argument('--model_path', default='/mnt/pv/models/sklearn/iris', type=str)
    args = parser.parse_args()

    if not (os.path.isdir(args.model_path)):
        os.makedirs(args.model_path)

    model_file = os.path.join(args.model_path, 'model.joblib')

    clf = svm.SVC(gamma='scale')
    iris = datasets.load_iris()
    X, y = iris.data, iris.target
    clf.fit(X, y)
    dump(clf, model_file)


if __name__ == '__main__':
    train()

컨테이너 이미지를 만들기

컨테이너 이미지를 만들기 위한 Dockerfile 입니다. 파이썬을 기본 이미지로 사용하고, scikit-learn 패키지를 추가로 설치합니다.

Dockerfile

FROM python:3.6-slim

RUN pip install scikit-learn==0.20.3 joblib

RUN mkdir -p /app
ADD iris.py /app/

쿠버네티스 잡 실행하기

컨테이너 이미지를 빌드하고, 컨테이너 이미지 레지스트리에 푸시 한 다음, 쿠버네티스 잡(Job)을 생성하겠습니다.

Job을 생성할 때는 모델을 저장하기 위해서 PVC를 마운트 해줍니다. 이 일련의 작업들은 직접 실행 할 수 있습니다. 하지만 좀 더 편하게 하기 위해서 앞서 배운 Kubeflow Fairing을 사용하겠습니다.

다음은 로컬 개발 환경에서 Fairing을 사용하여 컨테이너 이미지를 만들고, 쿠버네티스 잡을 실행하는 예제입니다.

fairing-local-docker.py

import uuid
from kubeflow import fairing
from kubeflow.fairing.kubernetes import utils as k8s_utils

CONTAINER_REGISTRY = 'kangwoo'

namespace = 'admin'
job_name = f'sklean-iris-job-{uuid.uuid4().hex[:4]}'

command=["python", "iris.py", "--model_path", "/mnt/pv/models/sklearn/iris"]
output_map = {
    "Dockerfile": "Dockerfile",
    "iris.py": "iris.py"
}

fairing.config.set_preprocessor('python', command=command, path_prefix="/app", output_map=output_map)

fairing.config.set_builder('docker', registry=CONTAINER_REGISTRY, image_name="sklean-iris", dockerfile_path="Dockerfile")

fairing.config.set_deployer('job', namespace=namespace, job_name=job_name,
                            pod_spec_mutators=[k8s_utils.mounting_pvc(pvc_name='kfserving-models-pvc', pvc_mount_path='/mnt/pv')],
                            cleanup=False, stream_log=True)

fairing.config.run()

fairing을 실행하면 쿠버네티스 잡이 생성되고, 학습이 완료된 모델이 지정한 경로에 저장됩니다.

SKLearn을 사용하는 InferenceService 로 예측 하기

InferenceService 생성

InferenceService 매니페스트를 작성합니다. predictor로 sklearn 을 사용합니다. storageUri 필드로 모델 저장 위치를 지정해 줍니다. pvc 의 이름이 kfserving-models-pvc 이고 저장 위치가 models/sklearn/iris 이므로, pvc://kfserving-models-pvc/models/sklearn/iris 라고 지정해 줍니다.

sklearn.yaml

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "sklearn-iris"
spec:
  default:
    predictor:
      sklearn:
        storageUri: "pvc://kfserving-models-pvc/models/sklearn/iris"

InferenceService 를 생성합니다.

다음은 admin 네임스페이스 InferenceService 를 생성하는 예제입니다.

kubectl -n admin apply -f sklearn.yaml

생성한 InferenceService를 조회해 보겠습니다.

kubectl -n admin get inferenceservice

InferenceService 가 정상적으로 생성되면 다음과 같은 응답 결과를 확인할 수 있습니다.

NAME           URL                                                            READY   DEFAULT TRAFFIC   CANARY TRAFFIC   AGE
sklearn-iris   <http://sklearn-iris.admin.example.com/v1/models/sklearn-iris>   True    100                                19s

예측 실행하기

예측을 요청하기 위해서는 모델 서버에 접근해야 합니다. 모델 서버는 ingressgateway 를 통해서 접근할 수 있습니다. ingressgateway 는 모델 서버들을 구분하기 위해서 호스트 이름을 사용합니다. ingressgateway에 접근하 기 위한 주소는 앞서 정의한 CLUSTER_IP 를 사용하겠습니다.

예측을 요청할 데이터를 json 파일로 작성합니다.

iris-input.json

{
  "instances": [
    [6.8,  2.8,  4.8,  1.4],
    [6.0,  3.4,  4.5,  1.6]
  ]
}

다음은 admin 네임스페이스의 sklearn-iris InferenceService 에 예측을 요청하는 예제입니다.

MODEL_NAME=sklearn-iris
SERVICE_HOSTNAME=$(kubectl -n admin get inferenceservice sklearn-iris -o jsonpath='{.status.url}' | cut -d "/" -f 3)

INPUT_PATH=@./iris-input.json
curl -v -H "Host: ${SERVICE_HOSTNAME}" http://$CLUSTER_IP/v1/models/$MODEL_NAME:predict -d $INPUT_PATH

정상적으로 실행되면 다음과 같은 응답 결과를 확인 할 수 있습니다.

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> POST /v1/models/sklearn-iris:predict HTTP/1.1
> Host: sklearn-iris.admin.example.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 76
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 76 out of 76 bytes
< HTTP/1.1 200 OK
< content-length: 23
< content-type: text/html; charset=UTF-8
< date: Sat, 29 Mar 2020 15:20:23 GMT
< server: istio-envoy
< x-envoy-upstream-service-time: 9032
< 
* Connection #0 to host localhost left intact
{"predictions": [1, 1]}

KFServing InferenceService 배포와 예측

InferenceService를 사용하여 모델 서버를 제공하려면, 사용할 네임스페이스가 다음과 같은지 확인해야합니다.

  • [serving.kubeflow.org/inferenceservice=enabled](<http://serving.kubeflow.org/inferenceservice=enabled>) 레이블이 네임스페이스 추가 되어 있어야 합니다.
  • 쿠버네티스 클러스터의 Istio IngressGateway에 접근할 수 있어야 합니다.

레이블 추가

Kubeflow의 대시보드나 프로필 컨트롤러(Profile Controller)를 사용하여, 사용자 네임스페이스를 만드는 경우에는 KFServing에서 모델을 배포할 수 있도록 serving.kubeflow.org/inferenceservice: enabled 레이블이 자동으로 추가됩니다. 만약 네임스페이스를 직접 생성하는 경우에는 해당 네임스페이스에 serving.kubeflow.org/inferenceservice: enabled 레이블을 추가해야만 합니다.

다음은 my-namespace 라는 네임스페이스에 레이블을 추가하는 예제입니다.

kubectl label namespace my-namespace serving.kubeflow.org/inferenceservice=enabled

Istio IngressGateway에 접근하기

InferenceService 가 정상적으로 생성되면, istio의 ingressgateway 를 모델 서버에 접속할 수 있습니다. KFServing에서 사용하는 ingressgateway의 이름을 알려면, config-istio 라는 ConfigMap을 조회하면 됩니다.

다음은 knative-serving 네임스페이스에 있는 config-istio 을 조회하는 예제입니다.

kubectl -n knative-serving get cm config-istio -o yaml

정상적으로 조회 되면 다음과 같은 결과를 얻을 수 있습니다.

apiVersion: v1
data:
  gateway.knative-serving.knative-ingress-gateway: kfserving-ingressgateway.istio-system.svc.cluster.local
  local-gateway.knative-serving.cluster-local-gateway: cluster-local-gateway.istio-system.svc.cluster.local
  local-gateway.mesh: mesh
  reconcileExternalGateway: "false"
kind: ConfigMap
metadata:
  ...
  name: config-istio
  namespace: knative-serving

data 섹션의 gateway.knative-serving.knative-ingress-gateway 필드가 현재 KFServing에서 사용하는 ingressgateway 를 설정하는 부분입니다. 위의 예제에서는 kfserving-ingressgateway를 사용하고 있습니다.

kfserving-ingressgateway를 조회해 보겠습니다.

다음은 istio-system 네임스페이스에 있는 kfserving-ingressgateway을 조회하는 예제입니다.

kubectl -n istio-system get service kfserving-ingressgateway 

KFServing이 설치된 쿠버네티스 클러스터에 따라 결과가 다르게 나옵니다. 응답 결과에 따른 크게 세가지 방법으로 접근 할 수 있습니다.

  • LoadBalancer 를 통해서 접근하기
  • NodePort를 통해서 접근하기
  • kubectl port-forward를 통해서 접근하기

LoadBalancer

쿠버네티스 클러스터가 LoadBalancer 를 지원하면 다음과 같은 결과를 얻을 수 있습니다. 서비스의 타입이 LoadBalancer 이고, EXTERNAL-IP 에 IP가 할당되어 있습니다. 이럴 경우에는 EXTERNAL-IP 를 통해서 ingressgateway에 접근할 수 있습니다.

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                                                                                                   AGE
kfserving-ingressgateway   LoadBalancer   10.101.141.37   10.201.121.4  15020:30543/TCP,80:32380/TCP,443:32390/TCP,31400:32400/TCP,15011:30263/TCP,8060:32119/TCP,853:32180/TCP,15029:32156/TCP,15030:30674/TCP,15031:30230/TCP,15032:32563/TCP,15443:30995/TCP   2d23h

앞으로 만들 예제에서 사용하기 위해서 ingressgateway 의 접근 주소를 다음과 같이 정의하겠습니다. EXTERNAL-IP 주소를 사용합니다.

CLUSTER_IP=10.201.121.4

NodePort

쿠버네티스 클러스터가 LoadBalancer 를 지원하지 않거나, 서비스의 타입이 NodePort 인 경우 EXTERNAL-IP 의 값이 비어 있습니다. 이럴 경우에는 클러스터의 노드 IP 와 NodePort를 통해서 접근할 수 있습니다.

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                                                                                                   AGE
kfserving-ingressgateway   LoadBalancer   10.101.141.37   <pending>     15020:30543/TCP,80:32380/TCP,443:32390/TCP,31400:32400/TCP,15011:30263/TCP,8060:32119/TCP,853:32180/TCP,15029:32156/TCP,15030:30674/TCP,15031:30230/TCP,15032:32563/TCP,15443:30995/TCP   2d23h

노드 IP는 노드를 조회하면 알 수 있습니다.

다음은 노드를 조회 하는 예제입니다.

kubectl get node -o wide

정상적으로 조회되면 다음과 같은 응답 결과가 나옵니다.

NAME     STATUS   ROLES    AGE   VERSION    INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
mortar   Ready    master   13d   v1.15.10   192.168.21.38   <none>        Ubuntu 18.04.3 LTS   4.15.0-91-generic   docker://18.9.9

노드가 한 개가 아닌 경우에는 여러개의 노드 정보가 출력됩니다. 해당 노드들 중에서 아무 노드의 INTERNAL-IP 를 사용하면 됩니다.

앞으로 만들 예제에서 사용하기 위해서 ingressgateway 의 접근 주소를 다음과 같이 정의하겠습니다. 노드의 IP 와 80 PORT(80:32380/TCP)의 노드 포트인 32380을 포트로 사용합니다.

CLUSTER_IP=192.168.21.38:32380

port-forward

외부에서 쿠버네티스 클러스터의 서비스에 접근할 수 없는 경우, kubectl 의 port-forward를 사용할 수 있습니다. 접근 하려는 외부 시스템에서 다음 명령어 실행하면 로컬 포트를 경유 해서 쿠버네티스 서비스에 접근할 수 있습니다.

kubectl -n istio-system port-forward svc/kfserving-ingressgateway 8080:80

포트 포워딩이 정상적으로 실행되면, 로컬포트로 ingressgateay 서비스로 접근할 수 있습니다. http://localhost:8080 처럼 선언한 로컬 포트의 주소로 접근하면, 쿠버네티스 ingressgateway 의 80 포트로 포워딩 됩니다.

앞으로 만들 예제에서 사용하기 위해서 ingressgateway 의 접근 주소를 다음과 같이 정의하겠습니다.

CLUSTER_IP=localhost:8080

PVC 생성하기

InferenceService 에 사용할 모델은 PVC에 저장하겠습니다. 만약 클라우드 스토리지와 같은 다른 저장소를 사용하려면, “클라우드 저장소를 이용하여 InfeerneceService 배포와 예측”을 참조하시기 바랍니다.

kfserving-models-pvc라는 PVC 매니페스트를 작성합니다.

kfserving-models-pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: kfserving-models-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

다음 명령어를 실행하여, admin 네임스페이스에 kfserving-models-pvc라는 PVC를 생성하겠습니다.

kubectl -n admin apply kfserving-models-pvc.yaml

KFServing 설정

KFServing 에서 사용하는 여러 설정 정보들은 inferenceservice-config 라는 쿠버네티스 ConfigMap에 정의되어 있습니다.

이 설정 정보에는 다음과 같은 내용이 정의되어 있습니다.

  • credentials : S3나 GCS를 사용할 때 참조할 값들.
  • explainers : explainer를 실행할 때 사용할 컨테이너의 이미지 정보.
  • ingress : KFServing에서 사용할 Istio ingress 정보.
  • predictors : predictor를 실행할 때 사용할 컨테이너 이미지의 정보.

다음 명령어를 실행하면, 설정 정보를 조회할 수 있습니다.

kubectl -n kubeflow get cm inferenceservice-config -o yaml

정상적으로 실행되면 다음과 같은 응답 결과를 확인 할 수 있습니다.

apiVersion: v1
data:
  credentials: |-
    {
       "gcs": {
           "gcsCredentialFileName": "gcloud-application-credentials.json"
       },
       "s3": {
           "s3AccessKeyIDName": "awsAccessKeyID",
           "s3SecretAccessKeyName": "awsSecretAccessKey"
       }
    }
  explainers: |-
    {
        "alibi": {
            "image" : "gcr.io/kfserving/alibi-explainer",
            "defaultImageVersion": "0.2.2",
            "allowedImageVersions": [
               "0.2.2"
            ]
        }
    }
  ingress: |-
    {
        "ingressGateway" : "knative-ingress-gateway.knative-serving",
        "ingressService" : "kfserving-ingressgateway.istio-system.svc.cluster.local"
    }
  logger: |-
    {
        "image" : "gcr.io/kfserving/logger:0.2.2",
        "memoryRequest": "100Mi",
        "memoryLimit": "1Gi",
        "cpuRequest": "100m",
        "cpuLimit": "1"
    }
  predictors: |-
    {
        "tensorflow": {
            "image": "tensorflow/serving",
            "defaultImageVersion": "1.14.0",
            "defaultGpuImageVersion": "1.14.0-gpu",
            "allowedImageVersions": [
               "1.11.0",
               "1.11.0-gpu",
               "1.12.0",
               "1.12.0-gpu",
               "1.13.0",
               "1.13.0-gpu",
               "1.14.0",
               "1.14.0-gpu"
            ]
        },
        "onnx": {
            "image": "mcr.microsoft.com/onnxruntime/server",
            "defaultImageVersion": "v0.5.1",
            "allowedImageVersions": [
               "v0.5.1"
            ]
        },
        "sklearn": {
            "image": "gcr.io/kfserving/sklearnserver",
            "defaultImageVersion": "0.2.2",
            "allowedImageVersions": [
               "0.2.2"
            ]
        },
        "xgboost": {
            "image": "gcr.io/kfserving/xgbserver",
            "defaultImageVersion": "0.2.2",
            "allowedImageVersions": [
               "0.2.2"
            ]
        },
        "pytorch": {
            "image": "gcr.io/kfserving/pytorchserver",
            "defaultImageVersion": "0.2.2",
            "allowedImageVersions": [
               "0.2.2"
            ]
        },
        "tensorrt": {
            "image": "nvcr.io/nvidia/tensorrtserver",
            "defaultImageVersion": "19.05-py3",
            "allowedImageVersions": [
               "19.05-py3"
            ]
        }
    }
  storageInitializer: |-
    {
        "image" : "gcr.io/kfserving/storage-initializer:0.2.2",
        "memoryRequest": "100Mi",
        "memoryLimit": "1Gi",
        "cpuRequest": "100m",
        "cpuLimit": "1"
    }
  transformers: |-
    {
    }
kind: ConfigMap
metadata:
...
  name: inferenceservice-config
  namespace: kubeflow

Kubeflow – KFServing 설치

KFServing는 Kubeflow의 구성 요소로 포함되어 있습니다. 별도로 설치가 필요 없이 사용할 수 있습니다. 물론 Kubeflow 없이 독립적으로 설치해서 사용할 수도 있습니다.

전제 조건

KFServing을 사용하려면, 쿠버네티스 클러스터에 Knative Serving 및 Istio가 설치되어 있어야 합니다. Knative는 Istio Ingress Gateway를 사용하여 요청을 Knative 서비스로 라우팅합니다. Kubeflow 및 KFServing 팀이 테스트 한 정확한 버전을 사용하려면 개발자 안내서의 전제 조건을 참조하십시오

Knative를 빠르게 실행하거나 서비스 메시가 필요하지 않은 경우, 서비스 메시(sidecar injection 없이 Istio를 설치하는 것이 좋습니다.

현재는 Knative Serving 만 필요합니다. cluster-local-gateway 는 클러스터 내부 트래픽을 위한 통로로 사용합니다. cluster-local-gateway를 설치하려면 여기의 지침을 따르십시오

KFServing 웹훅 인증서를 제공합니다.

KFServing 설치

Kubeflow와 함께 KFServing 설치

KFServing 은 Kubeflow를 설치할때 기본적으로 설치됩니다. Kubeflow 매니페스트에 KFServing을 설치하는 부분이 포함되어 있습니다. Kubeflow와 함께 설치되는 KFServing의 경우 KFServing 컨트롤러는 kubeflow  네임스페이스에 배포됩니다. Kubeflow의 쿠버네티스 최소 요주 버전이 1.14이므로 개체 선택기(object selector)를 지원하지 않을 수 있습니다. 그래서 Kubeflow 설치시 ENABLE_WEBHOOK_NAMESPACE_SELECTOR 가 기본적으로 활성화 되어 있어야합니다.

Kubeflow의 대시보드나 프로필 컨트롤러(Profile Controller)를 사용하여, 사용자 네임스페이스를 만드는 경우에는 KFServing에서 모델을 배포할 수 있도록 serving.kubeflow.org/inferenceservice: enabled 레이블이 자동으로 추가됩니다. 만약 네임스페이스를 직접 생성하는 경우에는 해당 네임스페이스에 serving.kubeflow.org/inferenceservice: enabled 레이블을 추가해야만, KFServing의  InferenceService 를 사용할 수 있습니다.

독립형 KFServing 설치

쿠버네티스 클러스터에 KFServing을 독립적으로 설치하면, 우선 위의 전제 조건을 충족시켜야 합니다. 전제 조건이 충족되면 다음 명령어를 사용하여 KFServing을 설치할 수 있습니다. 다음 명령어는 GitHub 리포지토리의 yaml 파일을 사용하여 KFServing 0.3.0을 설치합니다.

TAG=v0.3.0
CONFIG_URI=https://raw.githubusercontent.com/kubeflow/kfserving/master/install/$TAG/kfserving.yaml

kubectl apply -f ${CONFIG_URI}

KFServing을 독립형으로 설치했을 경우에는 KFServing 컨트롤러는 kfserving-system 네임스페이스에 배포됩니다.

KFServing은 pod mutator와 mutating admission webhooks 을 사용하여 KFServing의 스토리지 이니셜라이저(storage initializer) 컴포넌트를 주입합니다. 기본적으론 네임스페이스에 control-plane 레이블이 지정되어 있지 않으면, 해당 네임스페이스의 포드들은 pod mutator를 통과합니다. 그렇기 때문에 KFServing의 pod mutator의 웹훅이 필요 없는 포드가 실행될때 문제가 발생할 수 있습니다.

쿠버네티스 1.14 사용자의 경우 serving.kubeflow.org/inferenceservice: enabled 레이블이 추가된 네임스페이스의 포드에 ENABLE_WEBHOOK_NAMESPACE_SELECTOR 환경변수를 추가하여, KFServing pod mutator를 통과하도록 하는게 좋습니다.

env:
- name: ENABLE_WEBHOOK_NAMESPACE_SELECTOR
  value: enabled

쿠버네티스 1.15+ 사용자의 경우 KFServing InferenceService 포드만 pod mutator 를 통과 할 수 있도록 객체 선택기(object selector)를 켜는 것이 좋습니다.

kubectl patch mutatingwebhookconfiguration inferenceservice.serving.kubeflow.org --patch '{"webhooks":[{"name": "inferenceservice.kfserving-webhook-server.pod-mutator","objectSelector":{"matchExpressions":[{"key":"serving.kubeflow.org/inferenceservice", "operator": "Exists"}]}}]}'

Kubeflow – KFServing 개요

KFServing은 쿠버네티스에서 서버리스 추론을 가능하게 하며, TensorFlow, XGBoost, scikit-learn, PyTorch 및 ONNX와 같은 일반적인 머신러닝 프레임워크를 위한 고성능의 추상화 인터페이스를 제공합니다. 그래서 프로덕션에서 다양한 프레임워크의 모델을 서빙하기에 적합합니다.

KFServing을 이용하여 모델을 서빙하려면, InferenceService 라는 쿠버네티스 사용자 리소스를 생성하면 됩니다.

KFServing의 장점은 다음과 같습니다.

  • 다양한 머신 러닝 프레임워크 제공하기 위한, 쿠버네티스 사용자 리소스의 추상화가 잘 되어 있습니다. 그래서 쉽고 간편한게 추론 서비스를 생성할 수 있습니다.
  • 자동 확장, 네트워킹, 상태 확인 및 서버 구성의 복잡성을 캡슐화하여 GPU 자동 확장 및 카나리아 롤아웃과 같은 최첨단 서비스 기능을 머신러닝 배포에 사용할 수 있습니다.
  • 기본적으로 예측, 전처리, 후처리 및 설명 기능을 제공하여 프로덕션 머신러닝 추론 서버에 대해 간단하고 플러그 가능하며 완벽한 제품을 만들 수 있습니다.

KFServing는 Kubeflow의 함께 설치됩니다. 그래서 별도의 설치 없이 사용할 수 있습니다. 물론 Kubeflow 없이 독립적으로 설치해서 사용할 수도 있습니다.

모델 서버

KFServing 은 다음과 같은 머신러닝 프레임워크를 지원하는 모델 서버를 제공하고 있습니다.

  • Tensorflow
  • NVIDIA Triton Inference Server
  • PyTorch
  • XGBoost
  • scikit-learn
  • ONNX

이러한 머신러닝 프레임워크를 사용하여 모델을 저장한 경우에는 Google 버킷, S3 버킷, Azure 또는 minio에 저장된 모델의 위치만 있으면 쉽게 추론 서비스를 생성할 수 있습니다.

다음은 scikit-learn과 tensorflow의 매니페스트 예제입니다.

scikit-learn

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "sklearn-iris"
spec:
  default:
    predictor:
      sklearn:
        storageUri: "gs://kfserving-samples/models/sklearn/iris"

pytorch

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "pytorch-cifar10"
spec:
  default:
    predictor:
      pytorch:
        storageUri: "gs://kfserving-samples/models/pytorch/cifar10/"
        modelClassName: "Net"

tensorflow

apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "flowers-sample"
spec:
  default:
    predictor:
      tensorflow:
        storageUri: "gs://kfserving-samples/models/tensorflow/flowers"

storageUri는 학습한 모델의 저장 경로입니다.

모델 저장소

storageUri에서 사용할 수 있는, 지원하는 스토리는 다음과 같습니다.

  • Google Cloud Storage : 접두사가 “gs://” 로 시작합니다.
    • 기본적으로 사용자 인증에 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용합니다.
    • GOOGLE_APPLICATION_CREDENTIALS 가 제공되지 않으면, 익명 클라이언트가 아티팩트를 다운로드합니다.
  • S3 Compatible Object Storage : 접두사가 “s3://” 로 시작합니다.
    • 기본적으로 사용자 인증을 위해 S3_ENDPOINT, AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY 환경 변수를 사용합니다.
  • Azure Blob Storage : “https://{$STORAGE_ACCOUNT_NAME}.blob.core.windows.net/{$CONTAINER}/{$PATH}”
    • 기본적으로 익명 클라이언트를 사용하여 아티팩트를 다운로드합니다.
  • 로컬 파일 시스템 : 접두사가 없거나 접두사가 “file://” 로 시작합니다.
    • 절대 경로: /absolute/path or file:///absolute/path
    • 상대 경로 : relative/path or file://relative/path
    • 로컬 파일 시스템의 경우 접두사 없이 상대 경로를 사용하는 것이 좋습니다.
  • Persistent Volume Claim (PVC) : 접두사가 “pvc://” 로 시작합니다.
    • 경로 형태는 “pvc://{$pvcname}/[path]” 입니다.
    • pvcname은 모델을 저장하고 있는 PVC의 이름입니다.
    • [path]“는 PVC의 모델에 대한 상대 경로입니다.
    • For e.g. pvc://mypvcname/model/path/on/pvc

KFServing 스택

다음은 KFServing 스택을 나타내는 그림입니다.

출처 : kfsrving

KFServing 은 쿠버네티스 위에서 동작합니다. 그리고 istio와 Knative를 사용하고 있습니다.

Istio

서비스를 연결(Connect), 보안(secure), 제어(control) 그리고 관찰(observe) 하기 위한 서비스 메쉬(Service Mesh) 플랫폼입니다.

  • Connect : 서비스 간의 트래픽 및 API 호출 흐름을 지능적으로 제어하고 다양한 테스트를 수행하며 Red/Black 배포를 제공합니다.
  • Secure : 관리 인증, 권한 부여 및 서비스 사이의 통신 암호화를 통해 서비스를 자동으로 보호합니다.
  • Control : 정책을 적용하고 시행해서 자원이 소비자에게 공정하게 분배되도록 합니다.
  • Observe : 모든 서비스의 트레이싱, 모니터링 및 로깅을 관찰하여 발생하는 상황을 확인합니다.

Knative

Knative는 선언적인 컨테이너 기반 애플리케이션을 구축하는데 필수적인 미들웨어 구성 요소 세트를 제공합니다 Knative는 서빙(Serving) 컴포넌트과 이벤트(Eventing) 컴포넌트로 구성되어 있습니다.

Knative Eventing은 클라우드 네이티브 개발에 대한 일반적인 요구를 해결하도록 설계된 시스템이며 바인딩 가능한 이벤트 소스 및 이벤트 소비자를 가능하게하는 구성 요소를 제공합니다.

Knative Serving은 애플리케이션이나 함수들을 서버리스 컨테이너를 사용하여 배포와 서빙 할 수 있는 기능을 지원합니다. Knative Serving은 사용 하기 쉽고, 여러 고급 시나리오를 지원하도록 확장할 수 있습니다.

Knative Serving 프로젝트는 다음을 가능하게 하는 미들웨어 기본 요소를 제공합니다.

  • 서버리스 컨테이너의 빠른 배포
  • 자동 스케일링
  • Istio 구성 요소의 라우팅 및 네트워크 프로그래밍
  • 배포 된 코드 및 구성의 특정 시점 스냅 샷

KFServing

KFServing은 모델의 호스팅 측면을 관리합니다. KFServing 은 추론을 서비스하기위 해서, 쿠버네티스의 사용자 리소스인 InferenceService 를 제공하고 있습니다. InferenceService 를 생성하게 되면, 모델 서버가 실행되어 추론 요청을 처리할 수 있습니다.

  • InferenceService : 모델의 생명주기를 관리합니다
  • Configuration : 모델 배포 기록을 관리합니다. 기본(Default) 및 카나리아(Canary)의 두 가지 구성이 존재합니다.
  • Revision : 모델 버전의 스냅샷 입니다. 설정 정보와 이미지 정보를 가지고 있습니다.
  • Route : 네트워크 트래픽을 관리 하는 엔드 포인트 입니다.


KFServing Data Plane

InferenceService 의 데이터 플레인은 Predictor, Explainer, Transformer 로 구성되어 있습니다. 이중에서 실제 예측을 수행하는 모델 서버인 Predictor가 핵심 컴포넌트 입니다. 그리고 모델을 안전하게 변경할 수 있도록, Default”와 “Canary” 엔드포인트를 가지고 있습니다.

다음은 InferenceService의 데이터 플레인을 그래프로 나타낸것입니다.

출처 : kfserving

구조

Endpoint: “Default”와 “Canary” 엔드포인트를 가집니다. 이 엔드포인트 덕분에 사용자는 카나리아 배포 전략을 사용해서 모델을 안전한게 변경 할 수 있습니다. 구 버전의 모델 서버와 새 버전의 모델 서버들을 구성하고 일부 트래픽을 새 버전으로 분산하여 오류 여부를 판단합니다. 분산 후 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 돌아갈 수도 있습니다.

Component: 각 엔드 포인트는 “예측자(predictor)”, “설명자(explainer)”및 “변환기(transformer)”와 같은 여러 컴포넌트로 구성됩니다. 꼭 필요한 컴포넌트는 시스템의 핵심인 “예측자(predictor)”입니다. KFServing은 Outlier Detection과 같은 사용 사례를 지원하기 위해 지원되는 컴포넌트의 수를 늘릴 계획을 가지고 있습니다.

  • Predictor: Predictor는 InferenceService의 핵심 컴포넌트입니다. 네트워크 엔드포인트에서 사용 가능하게하는 모델 및 모델 서버입니다.
  • Explainer: Explainer는 선택 가능한 컴포넌트로서 모델이 어떻게 예측을 했는지에 대한 설명을 제공합니다. 사용자는 자신들이 가지고 있는 자체 설명 컨테이너를 정의할 수 있습니다. 일반적인 사용 사례의 경우 KFServing은 Alibi와 같은 기본 Explainer를 제공합니다.
  • Transformer: Transformer는 예측 및 설명 워크 플로우 전에 사전 및 사후 처리 단계를 정의 할 수 있는 컴포넌트 입니다. Explainer 과 마찬가지로 관련 환경 변수로 구성됩니다. 일반적인 사용 사례의 경우 KFServing은 Feast와 같은 기본 Transformer를 제공합니다.

Data Plane (V1)

KFServing에는 제공하는 모든 모델 서버에는 표준화 된 API를 지원합니다.

데이터 플레인 프로토콜의 V1 에서는 다음과 같은 HTTP/REST API를 제공하고 있습니다.

APIVERBPATH
ListGET/v1/models
ReadGET/v1/models/
PredictPOST/v1/models/:predict
ExplainPOST/v1/models/:explain

Predict

모든 InferenceServices는 Tensorflow V1 HTTP API (https://www.tensorflow.org/tfx/serving/api_rest#predict_api)와 호환되는 API를 사용합니다.

URL

POST <http://host>:port/v1/models/${MODEL_NAME}:predict

Request format

예측 API의 요청 본문은 다음과 같은 형식의 JSON 객체여야 합니다.

{
  "instances": <value>|<(nested)list>|<list-of-objects>
}

예측을 요청할 데이터의 값은 JSON 객체의 instances 필드에 입력합니다.

{
  // List of 3 scalar tensors.
  "instances": [ "foo", "bar", "baz" ]
}

{
  // List of 2 tensors each of [1, 2] shape
  "instances": [ [[1, 2]], [[3, 4]] ]
}

Response format

예측을 요청하면, 예측 결과를 응답합니다. 응답 본문에는 JSON 객체가 포함되어 있습니다. 행 형식의 요청에는 다음과 같은 형식의 응답이 있습니다.

{
  "predictions": <value>|<(nested)list>|<list-of-objects>
}

Explain

Explainer와 함께 배치 된 모든 InferenceService는 표준화 된 설명 API를 지원합니다. 이 인터페이스는 “: explain”동사가 추가 된 Tensorflow V1 HTTP API와 동일합니다.

URL

POST <http://host>:port/v1/models/${MODEL_NAME}:explain

Request format

예측 API의 요청 본문은 다음과 같은 형식의 JSON 객체여야 합니다.

{
  "instances": <value>|<(nested)list>|<list-of-objects>
}

예측을 요청할 데이터의 값은 JSON 객체의 instances 필드에 입력합니다.

{
  // List of 3 scalar tensors.
  "instances": [ "foo", "bar", "baz" ]
}

{
  // List of 2 tensors each of [1, 2] shape
  "instances": [ [[1, 2]], [[3, 4]] ]
}

Response format

예측을 요청하면, 예측 결과를 응답합니다. 응답 본문에는 JSON 객체가 포함되어 있습니다. 행 형식의 요청에는 다음과 같은 형식의 응답이 있습니다.

{
  "predictions": <value>|<(nested)list>|<list-of-objects>,
	"explanations": <value>|<(nested)list>|<list-of-objects>
}

Data Plane (V2)

데이터 플레인 프로토콜의 두 번째 버전은 V1 데이터 플레인 프로토콜에서 발견 된 여러 가지 문제를 해결하기 위해서 만들어지고 있습니다. 여기에는 수많은 모델 프레임워크의 일반화와 서버 성능 문제등을 포함하고 있습니다.

Predict

V2 프로토콜은 HTTP/REST 및 GRPC API를 모두 제안하고 있습니다. 자세한 내용은 전체 제안서를 참조하십시오.