블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Serveless를 위한 오픈소스 KNative

조대협(http://bcho.tistory.com)

배경

근래에 들어서 컨테이너를 사용한 워크로드 관리는 쿠버네티스 de-facto 표준이 되어가고 있는데, 쿠버네티스 자체가 안정되어가고 있지만, 이를 현업에 적용하기 위해서는 아직까지 여러가지 챌린지가 있다.

컨테이너 기반의 쿠버네티스 서비스가 지향하는 바는, 셀프서비스 기반의 데브옵스 모델로 인프라와 이를 자동화하는 플랫폼을 인프라엔지니어가 개발하여 개발팀에 제공하고, 개발팀은 개발과 배포/운영을 스스로 하는 모델이다.

그런데 예를 들어 간단한 무상태(stateless) 웹서비스를 하나 구축한다 하더라도 Deployment,Ingress,Service 등의 쿠버네티스 리소스를 정의해서 배포해야 하고, 여기에 오토 스케일링이나, 리소스 (CPU,메모리)등의 설정을 따로 해줘야 한다. 그런데 이런 설정을 일일이 다 하기에는 일반 개발자들에게 부담이 된다. 또한 A/B 테스팅이나 카날리 배포등은 쿠버네티스 자체로 지원이 되지 않고 스피니커(spinnaker)등의 다른 솔루션을 부가해서 써야 하는데, 이런 모델은 컨테이너 기반의 셀프 서비스와는 거리가 멀어진다.

서버쪽에 복잡한 설정 없이 무상태 웹서비스나 간단한 이벤트 컨슈밍 서비스등을 구축하는 방법으로는 서버리스 서비스들이 있는다. 아마존 클라우드의 람다(Lambda)나, 구글 클라우드의 펑션(Function)등이 이에 해당한다. 그런데 이러한 서버리스 서비스들은 특정 클라우드 플랫폼에 의존성을 가지고 있는데, 이러한 문제를 해결하기 위해서 나온 오픈소스 서버리스 솔루션이 Knative 이다.

Knative

Knative는 구글의 주도하는 오픈소스 기반의 서버리스 솔루션으로 쿠버네티스 위에서 기동이 된다. 그래서 특정 클라우드 종속성이 없을뿐만 아니라 On-Prem에서도 설치가 가능하다. 지원되는 인프라 목록은 여기에 있는데, 레드헷 오픈 시프트, 피보탈, IBM 과 같은 On-Prem 쿠버네티스뿐만 아니라, 구글, Azure, IBM 클라우드등 다양한 클라우드를 지원한다.


Knative는 스테이트리스 웹서비스뿐만 아니라, 큐에서 이벤트를 받아서 처리하는 이벤트 핸들링을 위한 서버리스 모델을 지원하고, 거기에 더불어 컨테이너를 빌딩할 수 있는 빌드 기능을 제공한다. 그러면 각각을 살펴보자

Serving

서빙은 무상태 웹서비스를 구축하기 위한 프레임웍으로 간단하게 웹서비스 컨테이너만 배포하면, 로드밸런서의 배치, 오토 스케일링, 복잡한 배포 (롤링/카날리)등을 지원하고, 서비스 매쉬 솔루션인 istio와 통합을 통해서 다양한 모니터링을 제공한다.

Hello Serving

일단 간단한 예제를 보자. 아래는 미리 빌드된 간단한 웹서비스 컨테이너를 배포하는 YAML 스크립트이다.


apiVersion: serving.knative.dev/v1alpha1 # Current version of Knative

kind: Service

metadata:

 name: helloworld-go # The name of the app

 namespace: default # The namespace the app will use

spec:

 runLatest:

   configuration:

     revisionTemplate:

       spec:

         container:

           image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app

           env:

             - name: TARGET # The environment variable printed out by the sample app

               value: "Go Sample v1"

<그림. service.yaml>


kind에 Service로 정의되었고, 서빙을 하는 컨테이너는 container>image에 container image URL이 정의되어 있다. 이 이미지를 이용해서 서빙을 하게 되며, 환경 변수를 컨테이너로 넘길 필요가 있을 경우에는 env에 name/value 식으로 정의하면 된다.


$kubectl apply -f service.yaml

<그림. 서비스 배포>

이렇게 정의된 서비스 yaml 파일은 다른 쿠버네티스의 yaml 파일과 같게 kubectl apply -f {파일명}을 이용하면 배포할 수 있게 된다.

쿠버네티스와 마찬가지로 yaml 파일을 정의해서 컨테이너를 정의하고 서비스를 정의해서 배포하는데, 그렇다면 쿠버네티스로 배포하는 것과 무슨 차이가 있을 것인가? 위의 설정 파일을 보면, 로드밸런서,Ingress 등의 추가 설정없이 간단하게 서비스 컨테이너 이름만 정의하고, 컨테이너만 정의하면 바로 배포가 된다. 서비스를 하는데 필요한 기타 설정을 추상화 시켜서 개발자가 꼭 필요한 최소한의 설정만으로 서비스를 제공할 수 있도록 해서, 복잡도를 줄여주는 장점이 있다.

그러면 배포된 서비스를 호출해보자


서비스를 호출하기 위해서는 먼저 서비스의 IP를 알아야 하는데, Knative serving 은 서비스 매쉬 솔루션인 istio 또는 apigateway인 Gloo 상에서 작동한다. 이 예제는 istio 위에 knative를 설치한것을 가정으로 설명한다.  istio에 대한 설명은 이링크와 이 링크 를 참고하기 바란다.

istio를 사용한 경우에는 istio의 gateway를 통해서 서비스가 되고,하나의 istio gateway가 몇개의 knative 서비스를 라우팅을 통해서 서비스한다. 이때 는 단일 IP이기 때문에 여러 knative 서비스를 서빙하기 위해서는 knative 서비스를 분류할 수 있어야 하는데 URI를 이용해서 구별을 하거나 또는 hostname 으로 구별을 한다. 이 예제에서는 hostname으로 구별하는 방법을 사용하였다.


그러면 실제로 서비스를 호출해보자. 먼저 istio gateway의 ip를 알아야한다.

Istio gateway ip는 다음 명령어를 이용하면 ip를 조회할 수 있다.


$kubectl get svc istio-ingressgateway --namespace istio-system

<그림. Istio gateway IP 조회>


다음으로 해야할일은 서비스의 domain 명을 알아야 하는데, 여기서 배포한 서비스는 helloworld-go 라는 서비스이다. 이 서비스가 배포되면 서비스에 대한 라우팅 정보가 정의되는데, kubectl get route 명령을 이용하면 라우팅 정보를 조회할 수 있고 그 중에서 domain 명을 조회하면 된다.


$kubectl get route helloworld-go  --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain

<그림. Istio gateway IP 조회>


호스트명을 조회하면 아래와 같이 해당 서비스의 호스트명을 알 수 있다.

Domain 명은 {route name}.{kubernetes name space}.도메인명 으로 되어 있고, 도메인명은 디폴트로 example.com을 사용한다. helloworld-go 애플리케이션의 route 명은 helloworld-go이고, 쿠버네티스 네임 스페이스는 default 네임 스페이스를 사용하였기 때문에, helloworld-go.default.example.com 이 전체 서비스 호스트명이 된다.


그러면 조회한 호스트명과 ingress gateway의 IP 주소를 이용해서, curl 명령으로 테스트 호출을 실행해보자.

$curl -H "Host: helloworld-go.default.example.com" http://${IP_ADDRESS}

<그림. Istio gateway IP 조회>

 

IP_ADDRESS는 앞에서 조회한 ingress의  gateway 주소를 이용하면 된다.

실행을하고 나면 다음과 같은 결과를 얻을 수 있다.

Serving detail

간단하게, Serving 을 테스트 해봤다. 그럼 Serving이 어떻게 구성되어 있는지 조금 더 자세하게 살펴보도록 하자. Serving 은 쿠버네티스 CRD (Custom Resource Definition)으로 정의된 4개의 컴포넌트로 구성되어 있다.


  • Configuration
    Configuration은 knative serving으로 배포되는 서비스를 정의한다. 컨테이너의 경로, 환경 변수, 오토스케일링 설정, hearbeat 설정등을 정의한다. 재미있는것은 단순히 컨테이너 경로를 정의할 수 도 있지만, 컨테이너 빌드 설정을 정의할 수 있다. 즉 코드가 변경되었을때 Configuration에 있는 빌드 설정을 통해서 새로운 컨테이너를 빌드해서 자동으로 배포하고 새롭게 배포된 컨테이너를 이용해서 서비스를 할 수 있도록 한다.

  • Revision
    Configuration의 히스토리라고 보면 되는데, Configuration을 생성할때 마다 새로운 revision이 생성된다.(Revision은 현재 Configuration의 스냅샷이다.) 그래서, 이전 revision으로 롤백을 하거나 저장된 각각의 다른 버전으로 트래픽을 분할해서 서빙할 수 있다.

  • Route
    Route는 서비스로 들어오는 트래픽을 Revision으로 라우팅 하는 역할을 한다. 단순하게 최신 버전의 revision으로 라우팅할 수 도 있지만, 카날리 테스트와 같이 여러 revision으로 라우팅 하는 역할은 Route에서 정의된다.

  • Service
    Service는 Configuration과 Route를 추상화하여, 하나의 웹서비스를 대표하는 개념이라고 보면 된다. 쿠버네티스에서 Deployment가 ReplicaSet 등을 추상화 하는 개념으로 생각하면 된다.


Serving 컴포넌트의 내용을 추상화하여 그림으로 표현하면 아래 그림과 같다.


<그림. Knative serving의 개념도>


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

CloudML을 이용하여 예측하기

조대협 (http://bcho.tistory.com)


지난글 (http://bcho.tistory.com/1189) 에서 학습된 모델을 *.pb 파일 포맷으로 Export 하였다. 그러면 이 Export 된 모델을 이용하여 예측 (prediction)을 하는 방법에 대해서 알아보겠다. 앞글에서도 언급했듯이, 예측은 Google CloudML을 이용한다.

전체 코드를 https://github.com/bwcho75/facerecognition/blob/master/CloudML%20Version/face_recog_model/%2528wwoo%2529%2BML%2BEngine%2Bprediction.ipynb 를 참고하기 바란다.

Export된 모델을 CloudML에 배포하기

학습된 모델을 CloudML에 배포하기 위해서는 export된 *.pb 파일과 variables 폴더를 구글 클라우드 스토리지 ( GCS / Google Cloud Storage) 에 업로드해야 한다.

아니면 학습때 모델 Export를 GCS로 시킬 수 도 있다.


아래는 terrycho-face-recog-export 라는 GCS 버킷아래 /export 디렉토리에, export 된 *.pb 파일과 variables 폴더가 저장된 모습이다.


다음 구글 클라우드 콘솔에서 ML Engine을 선택하여, Models 메뉴를 고른다. 이 메뉴는 모델을 배포하고 Prediction을 해주는 기능이다.



Models 화면으로 들어오면 Create Model 버튼이 나온다. 이 버튼을 이용해서 모델을 생성한다.





모델 생성시에 아래와 같이 단순하게 모델이름을 넣어주면된다.




모델 이름을 넣어준후에, 해당 모델에 실제 Export된 모델 파일을 배포해줘야 하는데, CloudML은 버전 기능을 제공한다. 그래서 아래 그림과 같이 Create Version 버튼을 눌러서 새로운 버전을 생성한다.





Create Version 메뉴에서는 Name에 버전명을 쓰고, Source에는 Export된 *.pb 파일과 variables 폴더가 저장된 GCS 경로를 선택한다.



아래는 terrycho-face-recog-export 버킷을 선택한 후, 그 버킷안에 export 폴더를 선택하는 화면이다.



선택을 해서 배포를 하면 아래와 같이 v7 버전이름을 모델이 배포가 된다.


배포된 모델로 예측 (Prediction)하기

그러면 배포된 모델을 사용해서 예측을 해보자. 아래가 전체코드이다.


from googleapiclient import discovery

from oauth2client.client import GoogleCredentials

import numpy

import base64

import logging


from IPython.display import display, Image


cropped_image = "croppedjolie.jpg"

display(Image(cropped_image))


PROJECT = 'terrycho-ml'

MODEL_NAME = 'face_recog'

MODEL_VERSION ='v7'



def call_ml_service(img_str):

   parent = 'projects/{}/models/{}/versions/{}'.format(PROJECT, MODEL_NAME,MODEL_VERSION)

   pred = None


   request_dict = {

       "instances": [

           {

               "image": {

                   "b64": img_str

               }

           }

       ]

   }


   try:

       credentials = GoogleCredentials.get_application_default()

       cloudml_svc = discovery.build('ml', 'v1', credentials=credentials)

       request = cloudml_svc.projects().predict(name=parent, body=request_dict)

       response = request.execute()

       print(response)

       #pred = response['predictions'][0]['scores']

       #pred = numpy.asarray(pred)


   except Exception, e:

       logging.exception("Something went wrong!")


   return pred



# base64 encode the same image

with open(cropped_image, 'rb') as image_file:

   encoded_string = base64.b64encode(image_file.read())


# See what ML Engine thinks

online_prediction = call_ml_service(encoded_string)


print online_prediction


코드를 살펴보면

       credentials = GoogleCredentials.get_application_default()

       cloudml_svc = discovery.build('ml', 'v1', credentials=credentials)


에서 discovery.build를 이용해서 구글 클라우드 API 중, ‘ML’ 이라는 API의 버전 ‘v1’을 불러왔다. CloudML 1.0 이다. 다음 credentials는 get_application_default()로 디폴트 credential을 사용하였다.

다음으로, CloudML에 request 를 보내야 하는데, 코드 윗쪽으로 이동해서 보면


def call_ml_service(img_str):

   parent = 'projects/{}/models/{}/versions/{}'.format(PROJECT, MODEL_NAME,MODEL_VERSION)

   pred = None


   request_dict = {

       "instances": [

           {

               "image": {

                   "b64": img_str

               }

           }

       ]

   }


를 보면 request body에 보낼 JSON을 request_dict로 정의하였다. 이때, 이미지를 “b64”라는 키로 img_str을 넘겼는데, 이 부분은 이미지 파일을 읽어서 base64 스트링으로 인코딩 한 값이다.

request = cloudml_svc.projects().predict(name=parent, body=request_dict)


다음 request 를 만드는데, 앞에서 선언한 cloudml_svc객체를 이용하여 prediction request 객체를 생성한다. 이때 parent 에는 모델의 경로가 들어가고 body에는 앞서 정의한 이미지가 들어있는 JSON 문자열이 된다.


   parent = 'projects/{}/models/{}/versions/{}'.format(PROJECT, MODEL_NAME,MODEL_VERSION)


Parent에는 모델의 경로를 나타내는데, projects/{프로젝트명}/models/{모델명}/versions/{버전명} 형태로 표현되며, 여기서는 projects/terrycho-ml/models/face_recog/versions/v7 의 경로를 사용하였다.


이렇게 request 객체가 만들어지면 이를 request.execute()로 이를 호출하고 결과를 받는다.

       response = request.execute()

       print(response)


결과를 받아서 출력해보면 다음과 같은 결과가 나온다.




2번째 라벨이 0.99% 확률로 유사한 결과가 나온것을 볼 수 있다. 라벨 순서 대로 첫번째가 제시카 알바, 두번째가 안젤리나 졸리, 세번째가 니콜 키드만, 네번째가 설현, 다섯번째가 빅토리아 베컴이다.


이제 까지 여러회에 걸쳐서 텐서플로우를 이용하여 CNN 모델을 구현하고, 이 모델을 기반으로 얼굴 인식을 학습 시키고 예측 시키는 모델 개발까지 모두 끝 맞췄다.


실제 운영 환경에서 사용하기에는 모델이 단순하지만, 여기에 CNN 네트워크만 고도화하면 충분히 사용할만한 모델을 개발할 수 있을 것이라고 본다. CNN 네트워크에 대한 이론 보다는 실제 구현하면서 데이타 전처리 및 학습과, 학습된 모델의 저장 및 이를 이용한 예측 까지 전체 흐름을 설명하기 위해서 노력하였다.


다음은 이 얼굴 인식 모델을 실제 운영환경에서 사용할만한 수준의 품질이 되는 모델을 사용하는 방법을 설명하고자 한다.

직접 CNN 모델을 만들어도 되지만, 얼마전에, 발표된 Tensorflow Object Detection API (https://github.com/tensorflow/models/tree/master/object_detection)는 높은 정확도를 제공하는 이미지 인식 모델을 라이브러리 형태로 제공하고 있다. 다음 글에서는 이 Object Detection API를 이용하여 연예인 얼굴을 학습 시키고 인식하는 모델을 개발하고 학습 및 예측 하는 방법에 대해서 알아보도록 하겠다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요