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


Archive»


 
 


쿠버네티스 #13

모니터링 1/2


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


시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능중의 하나는 시스템에 대한 모니터링이다. 시스템 자원의 사용량이나 에러등에 대한 모니터링을 통해서, 시스템을 안정적으로 운영하고 문제 발생시 원인 파악과 대응을 할 수 있다.

이번 글에서는 쿠버네티스 모니터링 시스템에 대한 개념과, 아키텍쳐 그리고 구축 방법에 대해서 소개하고자 한다.

쿠버네티스 모니터링 컨셉

쿠버네티스에 대한 모니터링을 보면 많은 툴과 지표들이 있어서 혼돈하기 쉬운데, 먼저 모니터링 컨셉에 대한 이해를 할 필요가 있다.

쿠버네티스 기반의 시스템을 모니터링하기 위해서는 크게 아래와 같이 4가지 계층을 모니터링해야 한다.



1. 호스트 (노드)

먼저 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트 즉 노드에 대한 지표 모니터링이 필요하다. 노드의 CPU,메모리, 디스크, 네트워크 사용량과, 노드 OS와 커널에 대한 모니터링이 이에 해당한다.

2. 컨테이너

다음은 노드에서 기동되는 각각의 컨테이너에 대한 정보이다. 컨테이너의 CPU,메모리, 디스크, 네트워크 사용량등을 모니터링 한다.

3. 애플리케이션

컨테이너안에서 구동되는 개별 애플리케이션의 지표를 모니터링 한다. 예를 들어, 컨테이너에서 기동되는 node.js 기반의 애플리케이션의 응답시간, HTTP 에러 빈도등을 모니터링한다.

4. 쿠버네티스

마지막으로, 컨테이너를 컨트롤 하는 쿠버네티스 자체에 대한 모니터링을한다. 쿠버네티스의 자원인 서비스나 POD, 계정 정보등이 이에 해당한다.

쿠버네티스 기반의 시스템 모니터링에 대해서 혼돈이 오는 부분중의 하나가 모니터링이라는 개념이 포괄적이기 때문이다. 우리가 여기서 다루는 모니터링은 자원에 대한 지표 대한 모니터링이다. 포괄적인 의미의 모니터링은 로그와, 에러 모니터링등 다양한 내용을 포괄한다.  

쿠버네티스 로깅

지표 모니터링과 함께 중요한 모니터링 기능중 하나는 로그 수집 및 로그 모니터링이다.

로그 수집 및 로그 모니터링 방법은 여러가지 방법이 있지만, 오픈소스 로그 수집 및 모니터링 조합인 EFK (Elastic search + FluentD + Kibina) 스택을 이용하는 경우가 대표적이다.

Fluentd 에이전트를 이용하여, 각종 로그를 수집하여, Elastic search에 저장하고, 저장된 지표를 Kibana 대쉬 보들르 이용하여 시작화 해서 나타내는 방법이 있다.

이에 대한 자세한 설명을 생략한다.

쿠버네티스 모니터링 시스템 구축

그러면 이러한 모니터링 시스템을 어떻게 구축할 것인가?

쿠버네티스 모니터링은 버전업 과정에서 많은 변화를 겪고 있다. 기존 모니터링 시스템의 아키텍쳐는 cAdvisor,Heapster를 이용하는 구조였으나, 이 아키텍쳐는 곧 deprecated 될 예정이고, Prometheus등 다양한 모니터링 아키텍쳐가 후보로 고려 되고 있다.

아래 그래프를 보면 재미있는 통계 결과가 있는데, cAdvisor,Heapster,Promethus 를 이용하는 방법도 있지만, 클라우드의 경우에는 클라우드 벤더에서 제공하는 쿠버네티스 모니터링 솔루션을 그대로 사용하거나 (18%) 또는 데이타독이나 뉴렐릭 (Datadog, newRelic)과 같이 전문화된 모니터링 클라우드을 사용하는 비율 (26%) 도 꽤 높다.



<그림. 쿠버네티스 모니터링 솔루션 분포 >

출처 :  https://thenewstack.io/5-tools-monitoring-kubernetes-scale-production/


개인적인 의견으로는 직접 모니터링 솔루션을 구축해서 사용하는 것보다는 비용은 약간 들지만 클라우드 벤더에서 제공되는 모니터링 도구나 또는 데이타독과 같은 전문 모니터링 솔루션을 이용하는 것을 추천한다.


직접 모니터링 솔루션을 구축할 경우 구축과 운영에 드는 노력도 꽤 크고, 또한 어떠한 지표를 모니터링해야할지 등에 대한 추가적인 노하우가 필요하다. 또한 cAdvisor,Heapster,Promethues 조합은 호스트와 컨테이너 그리고 쿠버네티스에 대한 모니터링은 제공하지만 애플리케이션 지표에 대한 모니터링과 로깅 기능은 제공하지 않기 때문에 별도의 구축이 필요하다. 이런 노력을 들이는 것 보다는 모든 기능이 한번에 제공되고 운영을 대행해주는 데이타독이나 클라우드에서 제공해주는 모니터링 솔루션을 사용하는 것을 추천한다.

Heapster 기반 모니터링 아키텍처

이러한 모니터링 요건을 지원하기 위해서, 쿠버네티스는 자체적인 모니터링 컴포넌트를 가지고 있는데, 그 구조는 다음과 같다.



<그림. 쿠버네티스 모니터링 시스템 아키텍쳐>

출처 Source : https://www.datadoghq.com/blog/how-to-collect-and-graph-kubernetes-metrics/


cAdvisor

cAdvisor는 모니터링 에이전트로, 각 노드마다 설치되서 노드에 대한 정보와 컨테이너 (Pod)에 대한 지표를 수집하여, Kubelet으로 전달한다.

Heapster

cAdvisor에 의해 수집된 지표는 Heapster 라는 중앙 집중화된 지표 수집 시스템에 모이게 되고, Heapster는 수집된 지표를 스토리지 백앤드에 저장한다.

Storage backend

Heapster가 지표를 저장하는 데이타베이스를 스토리지 백앤드라고 하는데, Heapster는 확장성을 위해서 다양한 스토리지 백앤드를 플러그인 구조를 선택하여 연결할 수 있다.

현재 제공되는 대표적인 스토리지 백앤드는 구글 클라우드의 모니터링 시스템인 스택드라이버 (stackdriver), 오픈 소스 시계열 데이타베이스인 인플럭스 디비 (InfluxDB) 등을 지원한다.

그래프 대쉬 보드

이렇게 저장된 모니터링 지표는 그래프와 같은 형태로 시각화 될필요가 있는데, 스토리지 백앤드를 지원하는 다양한 시각화 도구를 사용할 수 있다. 구글의 모니터링 시스템인 스택드라이버의 경우에는 자체적인 대쉬보드 및 그래프 인터페이스가 있고, 인플럭스 디비나 프로메테우스의 경우에는 오픈소스 시각화 도구인 그라파나(Grafana)를 사용할 수 있다.


<그림. 그라파나와 프로메테우스를 연결하여, 지표 모니터링을 시각화 한 예제>


그러나 이 아키텍쳐는 deprecation 계획이 시작되서 1.13 버전 부터는 완전히 제거될 예정이다.

https://github.com/kubernetes/heapster/blob/master/docs/deprecation.md


쿠버네티스 대시보드

다른 방법으로는 쿠버네티스를 모니터링 하고 관리할 수 있는 쉬운 방법이 하나 있는데, 쿠버네티스 대시보드를 사용하는 방법이다. 쿠버네티스는 기본적으로 kubectl이라는 커맨드 라인 인터페이스 (이하 CLI : Command Line Interface)를 사용하지만, 추가적으로 웹 기반의 관리 콘솔을 제공한다. 이를 쿠버네티스 대시보드라고 한다. (https://github.com/kubernetes/dashboard)

대시 보드 설치

쿠버네티스 대시 보드 설치 방법은 간단하다. 아래와 같이 대시보드 설정 yaml 파일을 이용하면 간단하게 대시 보드를 쿠버네티스 클러스터에 설치할 수 있다.


% kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml


일반적인 경우에는 위의 스크립트로 설치가 가능하지만, 구글 클라우드 쿠버네티스 엔진의의 경우에는 설치 중에 권한 관련 에러가 나올 수 있는데, 구글 클라우드 쿠버네티스 엔진의 경우에는 보안을 이유로 일반적인 쿠버네티스보다 권한 설정 레벨이 높게 설정되어 있기 때문이다. 구글 클라우드 쿠버네티스 엔진에서 대시보드를 설치하고자할때에는 위의 스크립트를 실행하기 전에 먼저 아래 명령어를 이용해서, 현재 사용자 계정에 대해서 cluster-admin 롤을 부여해줘야 한다.  


%kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole cluster-admin --user $(gcloud config get-value account)

대시 보드 접속

대시보드 설치가 끝났으면, 대시보드를 접속해보자

대시보드는 외부 서비스로 제공되지 않고, 내부 IP로만 접속이 가능한데, 클러스터 외부에서 접근하려면 kubectl proxy를 이용하면, 간단하게 접근이 가능하다.

kubectl proxy는 로컬 머신 (예를 들어 노트북)과 쿠버네티스 클러스터간의 통신을 프록싱해줘서, 로컬 머신에서 쿠버네티스 클러스터내의 HTTP 서비스를 접근할 수 있도록 해준다.

사용 방법은 로컬 머신에서 간단하게

%kubectl proxy

명령을 실행해주면 localhost:8001 포트를 통해서 쿠버네티스 클러스터로 트래픽을 프록시 해준다.

위와 같이 proxy를 실행한후에,  아래 URL로 접근을 하면, 대시보드 콘솔에 접근할 수 있다.

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/


URL에 접근하면 아래와 같이 로그인 창이 나타난다.



사용자 계정 및 토큰등에 대해서는 보안 부분에서 별도로 다루기로 하겠다.

대쉬보드를 사용하기 위해서는 사용자 인증이 필요한데, 간단하게 인증을 위한 토큰을 사용하는 방법을 이용하도록 하겠다.

토큰은 쿠버네티스 API 인증 메커니즘중의 하나로, 여기서는 admin-user라는 계정을 하나 만든후에, 그 계정에, 클러스터 관리자롤을 부여한 후에, 그 사용자의 토큰을 사용하는 방법을 사용하겠다.


먼저 아래 스크립트를 이용해서 admin-user 라는 사용자를 생성한다.

admin-user.yaml 파일

apiVersion: v1

kind: ServiceAccount

metadata:

 name: admin-user

 namespace: kube-system


다음 아래 스크립트를 이용해서 cluster-admin 롤을 앞에서 생성한 admin-user에 부여한다.

admin-rolebinding.yaml 파일

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

 name: admin-user

roleRef:

 apiGroup: rbac.authorization.k8s.io

 kind: ClusterRole

 name: cluster-admin

subjects:

- kind: ServiceAccount

 name: admin-user

 namespace: kube-system


다음 아래 명령어를 이용하면 admin-user의 토큰 값을 알 수 있다.

% kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')


명령을 실행하면 아래와 같이 토큰이 출력된다.


이 토큰 값을 앞의 로그인 창에 입력하면, 대시보드에 로그인할 수 있다.

대시 보드에 로그인하면 아래와 같이 노드나, Pod, 서비스등 쿠버네티스의 자원의 대부분의 정보에 대한 모니터링이 가능하다.




또한 kubectl CLI 명령을 사용하지 않고도 손쉽게 Deployment 등 각종 자원을 생성할 수 있다.


로그 부분에 들어가면 아래와 같이 로그 정보를 볼 수 있다



재미있는 기능중 하나는 아래 그림과 같이 특정 Pod의 컨테이너를 선택하면, 웹콘솔상에서 해당 컨테이너로 SSH 로그인이 가능하다.



여기서 다룬 쿠버네티스 대시보드 설정 및 로그인 부분은 프록시 사용, 로그인을 토큰을 사용하는 등, 운영환경에는 적절하지 않은 방법이다. 개발환경이나 테스트 용도로만 사용하도록 하고, 운영 환경에서는 사용자 계정 시스템 생성과 적절한 권한 배정을 한 후에, 적절한 보안 인증 시스템을 마련한 후에 적용하도록 하자.



쿠버네티스 #4

Volume (디스크)

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


이번 글에서는 쿠버네티스의 디스크 서비스인 볼륨에 대해서 알아보도록 하겠다.

쿠버네티스에서 볼륨이란 Pod에 종속되는 디스크이다. (컨테이너 단위가 아님). Pod 단위이기 때문에, 그 Pod에 속해 있는 여러개의 컨테이너가 공유해서 사용될 수 있다.

볼륨 종류

쿠버네티스의 볼륨은 여러가지 종류가 있는데,  로컬 디스크 뿐 아니라, NFS, iSCSI, Fiber Channel과 같은 일반적인 외장 디스크 인터페이스는 물론, GlusterFS나, Ceph와 같은 오픈 소스 파일 시스템, AWS EBS, GCP Persistent 디스크와 같은 퍼블릭 클라우드에서 제공되는 디스크, VsphereVolume과 같이 프라이비트 클라우드 솔루션에서 제공하는 디스크 볼륨까지 다양한 볼륨을 지원한다.

자세한 볼륨 리스트는 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes 를 참고하기 바란다.


이 볼륨 타입을 구별해보면 크게 임시 디스크, 로컬 디스크 그리고 네트워크 디스크 등으로 분류할 수 있다.


Temp

Local

Network

emptyDir

hostPath

GlusterFS

gitRepo

NFS

iSCSI

gcePersistentDisk

AWS EBS

azureDisk

Fiber Channel

Secret

VshereVolume


그럼 각각에 대해서 알아보도록 하자

emptyDir

emptyDir은 Pod가 생성될때 생성되고, Pod가 삭제 될때 같이 삭제되는 임시 볼륨이다.

단 Pod 내의 컨테이너 크래쉬되어 삭제되거나 재시작 되더라도 emptyDir의 생명주기는 컨테이너 단위가 아니라, Pod 단위이기 때문에, emptyDir은 삭제 되지 않고 계속해서 사용이 가능하다.

생성 당시에는 디스크에 아무 내용이 없기 때문에, emptyDir  이라고 한다.

emptyDir의 물리적으로 노드에서 할당해주는 디스크에 저장이 되는데, (각 환경에 따라 다르다. 노드의 로컬 디스크가 될 수 도 있고, 네트워크 디스크등이 될 수 도 있다.) emptyDir.medium 필드에 “Memory”라고 지정해주면, emptyDir의 내용은 물리 디스크 대신 메모리에 저장이 된다.


다음은 하나의 Pod에 nginx와 redis 컨테이너를 기동 시키고, emptyDir 볼륨을 생성하여 이를 공유하는 설정이다.


apiVersion: v1

kind: Pod

metadata:

 name: shared-volumes

spec:

 containers:

 - name: redis

   image: redis

   volumeMounts:

   - name: shared-storage

     mountPath: /data/shared

 - name: nginx

   image: nginx

   volumeMounts:

   - name: shared-storage

     mountPath: /data/shared

 volumes:

 - name : shared-storage

   emptyDir: {}


shared-storage라는 이름으로 emptyDir 기반의 볼륨을 만든 후에, nginx와 redis 컨테이너의 /data/shared 디렉토리에 마운트를 하였다.


Pod를 기동 시킨후에, redis 컨테이너의 /data/shared 디렉토리에 들어가 보면 당연히 아무 파일도 없는 것을 확인할 수 있다.

이 상태에서 아래와 같이 file.txt 파일을 생성하였다.



다음 nginx 컨테이너로 들어가서 /data/shared 디렉토리를 살펴보면 file.txt 파일이 있는 것을 확인할 수 있다.



이 파일은 redis 컨테이너에서 생성이 되어 있지만, 같은 Pod 내이기 때문에, nginx 컨테이너에서도 접근이 가능하게 된다.

hostPath

다음은 hostPath 라는 볼륨 타입인데, hostPath는 노드의 로컬 디스크의 경로를 Pod에서 마운트해서 사용한다. 같은 hostPath에 있는 볼륨은 여러 Pod 사이에서 공유되어 사용된다.

또한  Pod가 삭제 되더라도 hostPath에 있는 파일들은 삭제되지 않고 다른 Pod가 같은 hostPath를 마운트하게 되면, 남아 있는 파일을 액세스할 수 있다.


주의할점 중의 하나는 Pod가 재시작되서 다른 노드에서 기동될 경우, 그 노드의 hostPath를 사용하기 때문에, 이전에 다른 노드에서 사용한 hostPath의 파일 내용은 액세스가 불가능하다.


hostPath는 노드의 파일 시스템을 접근하는데 유용한데, 예를 들어 노드의 로그 파일을 읽어서 수집하는 로그 에이전트를 Pod로 배포하였을 경우, 이 Pod에서 노드의 파일 시스템을 접근해야 한다. 이러한 경우에 유용하게 사용할 수 있다.


아래는 노드의 /tmp 디렉토리를 hostPath를 이용하여 /data/shared 디렉토리에 마운트 하여 사용하는 예제이다.


apiVersion: v1

kind: Pod

metadata:

 name: hostpath

spec:

 containers:

 - name: redis

   image: redis

   volumeMounts:

   - name: terrypath

     mountPath: /data/shared

 volumes:

 - name : terrypath

   hostPath:

     path: /tmp

     type: Directory



이 Pod를 배포해서 Pod를 Id를 얻어보았다.


Pod Id를 통해서 VM을 아래와 같이 확인하였다.


VM에 SSH로 접속해서 /tmp/에 hello.txt 파일을 생성하였다.




다음, Pod의 컨테이너에서 마운트된 /data/shared 디렉토리를 확인해보면 아래와 같이 노드의 /tmp 디렉토리의 내용이 그대로 보이는 것을 볼 수 있다.


gitRepo

볼륨 타입중에 gitRepo라는 유용한 볼륨 타입이 하나 있어서 소개한다.

이 볼륨은 생성시에 지정된 git 리파지토리의 특정 리비전의 내용을 clone을 이용해서 내려 받은후에 디스크 볼륨을 생성하는 방식이다. 물리적으로는 emptyDir이 생성되고, git 레파지토리 내용을 clone으로 다운 받는다.




HTML과 같은 정적 파일이나 Ruby on rails, PHP, node.js 와 같은 스크립트 언어 기반의 코드들은 gitRepo 볼륨을 이용하여 손쉽게 배포할 수 있다.


apiVersion: v1

kind: Pod

metadata:

name: gitrepo-volume-pod

spec:

containers:

- image: nginx:alpine

  name: web-server

  volumeMounts:

  - name: html

    mountPath: /usr/share/nginx/html

    readOnly: true

  ports:

  - containerPort: 80

    protocol: TCP

volumes:

- name: html

  gitRepo:

       repository: https://github.com/luksa/kubia-website-example.git

       revision: master

       directory: .


이 설정은 https://github.com/luksa/kubia-website-example.git 의 master 리비전을 클론으로 다운받아서 /usr/share/nginx/html에 마운트 시키는 설정이다.


PersistentVolume and PersistentVolumeClaim

일반적으로 디스크 볼륨을 설정하려면 물리적 디스크를 생성해야 하고, 이러한 물리적 디스크에 대한 설정을 자세하게 이해할 필요가 있다.

쿠버네티스는 인프라에 대한 복잡성을 추상화를 통해서 간단하게 하고, 개발자들이 손쉽게 필요한 인프라 (컨테이너,디스크, 네트워크)를 설정할 수 있도록 하는 개념을 가지고 있다

그래서 인프라에 종속적인 부분은 시스템 관리자가 설정하도록 하고, 개발자는 이에 대한 이해 없이 간단하게 사용할 수 있도록 디스크 볼륨 부분에 PersistentVolumeClaim (이하 PVC)와 PersistentVolume (이하 PV)라는 개념을 도입하였다.


시스템 관리자가 실제 물리 디스크를 생성한 후에, 이 디스크를 PersistentVolume이라는 이름으로 쿠버네티스에 등록한다.

개발자는 Pod를 생성할때, 볼륨을 정의하고, 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라 PVC를 지정하여, 관리자가 생성한 PV와 연결한다.


그림으로 정리해보면 다음과 같다.


시스템 관리자가 생성한 물리 디스크를 쿠버네티스 클러스터에 표현한것이 PV이고, Pod의 볼륨과 이 PV를 연결하는 관계가 PVC가 된다.


이때 주의할점은 볼륨은 생성된후에, 직접 삭제하지 않으면 삭제되지 않는다. PV의 생명 주기는 쿠버네티스 클러스터에 의해서 관리되면 Pod의 생성 또는 삭제에 상관없이 별도로 관리 된다. (Pod와 상관없이 직접 생성하고 삭제해야 한다.)

PersistentVolume

PV는 물리 디스크를 쿠버네티스에 정의한 예제로, NFS 파일 시스템 5G를 pv0003이라는 이름으로 정의하였다.




PV를 설정하는데 여러가지 설정 옵션이 있는데, 간략하게 그 내용을 살펴보면 다음과 같다.

  • Capacity
    볼륨의 용량을 정의한다. 현재는 storage 항목을 통해서 용량만을 지정하는데 향후에는 필요한 IOPS나 Throughput등을 지원할 예정이다.

  • VolumeMode
    VolumeMode는 Filesystem (default)또는 raw를 설정할 수 있는데, 볼륨이 일반 파일 시스템인데, raw 볼륨인지를 정의한다.

  • Reclaim Policy
    PV는 연결된 PVC가 삭제된 후 다시 다른 PVC에 의해서 재 사용이 가능한데, 재 사용시에 디스크의 내용을 지울지 유지할지에 대한 정책을 Reclaim Policy를 이용하여 설정이 가능하다.

    • Retain : 삭제하지 않고 PV의 내용을 유지한다.

    • Recycle : 재 사용이 가능하며, 재 사용시에는 데이타의 내용을 자동으로 rm -rf 로 삭제한 후 재사용이 된다.

    • Delete : 볼륨의 사용이 끝나면, 해당 볼륨은 삭제 된다. AWS EBS, GCE PD,Azure Disk등이 이에 해당한다.

Reclaim Policy은 모든 디스크에 적용이 가능한것이 아니라, 디스크의 특성에 따라서 적용이 가능한 Policy가 있고, 적용이 불가능한 Policy 가 있다.

  • AccessMode
    AccessMode는 PV에 대한 동시에 Pod에서 접근할 수 있는 정책을 정의한다.

    • ReadWriteOnce (RWO)
      해당 PV는 하나의 Pod에만 마운트되고 하나의 Pod에서만 읽고 쓰기가 가능하다.

    • ReadOnlyMany(ROX)
      여러개의 Pod에 마운트가 가능하며, 여러개의 Pod에서 동시에 읽기가 가능하다. 쓰기는 불가능하다.

    • ReadWriteMany(RWX)
      여러개의 Pod에 마운트가 가능하고, 동시에 여러개의 Pod에서 읽기와 쓰기가 가능하다.

위와 같이 여러개의 모드가 있지만, 모든 디스크에 사용이 가능한것은 아니고 디스크의 특성에 따라서 선택적으로 지원된다.


PV의 라이프싸이클

PV는 생성이 되면, Available 상태가 된다. 이 상태에서 PVC에 바인딩이 되면 Bound 상태로 바뀌고 사용이 되며, 바인딩된 PVC가 삭제 되면, PV가 삭제되는 것이 아니라  Released 상태가 된다. (Available이 아니면 사용은 불가능하고 보관 상태가 된다.)

PV 생성 (Provisioning)

PV의 생성은 앞에서 봤던것 처럼 yaml 파일등을 이용하여, 수동으로 생성을 할 수 도 있지만, 설정에 따라서 필요시마다 자동으로 생성할 수 있게 할 수 있다. 이를 Dynamic Provisioning (동적 생성)이라고 하는데, 이에 대해서는 PVC를 설명하면서 같이 설명하도록 하겠다.

PersistentVolumeClaim

PVC는 Pod의 볼륨과 PVC를 연결(바인딩/Bind)하는 관계 선언이다.

아래 예제를 보자 아래 예제는 PVC의 예제이다.



(출처 : https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)


  • accessMode, VolumeMode는 PV와 동일하다.

  • resources는 PV와 같이, 필요한 볼륨의 사이즈를 정의한다.

  • selector를 통해서 볼륨을 선택할 수 있는데, label selector 방식으로 이미 생성되어 있는 PV 중에, label이 매칭되는 볼륨을 찾아서 연결하게 된다.


PV/PVC 예제

그러면 예제를 통해서 PV를 생성하고, 이 PV를 PVC에 연결한후에, PVC를 Pod에 할당하여 사용하는 방법을 살펴보도록 하자. 예제는 구글 클라우드 환경을 사용하였다.

1.물리 디스크 생성

먼저 구글 클라우드 콘솔에서 Compute Engine 부분에서 아래와 같이 Disks 부분에서 물리 디스크를 생성한다.


디스크를 pv-demo-disk라는 이름으로 생성하였다.

이때 주의할점은 디스크의 region과 zone이 쿠베네티스 클러스터가 배포된 region과 zone에 동일해야 한다.


2.생성된 디스크로 PV를 선언

생성된 디스크를 이용하여 PV를 생성한다. 아래는 PV를 생성하기 위한 yaml 파일이다.


existing-pd.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

 name: pv-demo

spec:

 storageClassName:

 capacity:

   storage: 20G

 accessModes:

   - ReadWriteOnce

 gcePersistentDisk:

   pdName: pv-demo-disk

   fsType: ext4


PV의이름은 pv-demo이고, gcePersistentDisk에서 앞에서 생성한 pv-demo-disk 를 사용하도록 정의하였다.

파일을 실행하면, 아래와 같이 pv-demo로 PV가 생성된것을 확인할 수 있다.

3. 다음 PVC를 생성한다.

아래는 앞에서 생성한 pv-demo PV를 사용하는 PVC를 생성하는 yaml 파일이다. 하나의 Pod에서만 액세스가 가능하도록 accessMode를 ReadWriteOnce로 설정하였다.


existing-pvc.yaml

apiVersion: v1

kind : PersistentVolumeClaim

metadata:

 name: pv-claim-demo

spec:

 storageClassName: ""

 volumeName: pv-demo

 accessModes:

   - ReadWriteOnce

 resources:

   requests:

     storage: 20G


4. Pod를 생성하여, PVC를 바인딩

그러면 앞에서 생성한 PV와 PVC를 Pod에 생성해서 연결하자


existing-pod-redis.yaml

apiVersion: v1

kind: Pod

metadata:

 name: redis

spec:

 containers:

 - name: redis

   image: redis

   volumeMounts:

   - name: terrypath

     mountPath: /data

 volumes:

 - name : terrypath

   persistentVolumeClaim:

     claimName: pv-claim-demo


앞에서 생성한 PVC pv-claim-demo를 Volume에 연결한후, 이 볼륨을 /data 디렉토리에 마운트 하였다.

Pod를 생성한후에, 생성된 Pod에 df -k 로 디스크 연결 상태를 확인해 보면 다음과 같다.



/dev/sdb 가 20G로 생성되어 /data 디렉토리에 마운트 된것을 확인할 수 있다.

Dynamic Provisioning

앞에서 본것과 같이 PV를 수동으로 생성한후 PVC에 바인딩 한 후에, Pod에서 사용할 수 있지만, 쿠버네티스 1.6에서 부터 Dynamic Provisioning (동적 생성) 기능을 지원한다. 이 동적 생성 기능은 시스템 관리자가 별도로 디스크를 생성하고 PV를 생성할 필요 없이 PVC만 정의하면 이에 맞는 물리 디스크 생성 및 PV 생성을 자동화해주는 기능이다.




PVC를 정의하면, PVC의 내용에 따라서 쿠버네티스 클러스터가 물리 Disk를 생성하고, 이에 연결된 PV를 생성한다.

실 환경에서는 성능에 따라 다양한 디스크(nVME, SSD, HDD, NFS 등)를 사용할 수 있다. 그래서 디스크를 생성할때, 필요한 디스크의 타입을 정의할 수 있는데, 이를 storageClass 라고 하고, PVC에서 storage class를 지정하면, 이에 맞는 디스크를 생성하도록 한다.

Storage class를 지정하지 않으면, 디폴트로 설정된 storage class 값을 사용하게 된다.


동적 생성 방법은 어렵지 않다. PVC에 필요한 디스크 용량을 지정해놓으면, 자동으로 이에 해당하는 물리 디스크 및 PV가 생성이 된다. 아래는 동적으로 PV를 생성하는 PVC 예제이다.


dynamic-pvc.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

 name: mydisk

spec:

 accessModes:

   - ReadWriteOnce

 resources:

   requests:

     storage: 30Gi


다음 Pod를 생성한다.

apiVersion: v1

kind: Pod

metadata:

 name: redis

spec:

 containers:

 - name: redis

   image: redis

   volumeMounts:

   - name: terrypath

     mountPath: /data/shared

 volumes:

 - name : terrypath

   persistentVolumeClaim:

     claimName: mydisk


Pod를 생성한후에, kubectl get pvc 명령어를 이용하여, 생성된 PVC와 PV를 확인할 수 있다.

PVC는 위에서 정의한것과 같이 mydisk라는 이름으로 생성되었고, Volume (PV)는 pvc-4a…. 식으로 새롭게 생성되었다.

Storage class

스토리지 클래스를 살펴보자,

아래는  AWS EBS 디스크에 대한 스토리지 클래스를 지정한 예로, slow 라는 이름으로 스토리지 클래스를 지정하였다. EBS 타입은 io1을 사용하고, GB당 IOPS는 10을 할당하도록 하였고, 존은 us-east-1d와 us-east-1c에 디스크를 생성하도록 하였다.



아래는 구글 클라우드의 Persistent Disk (pd)의 예로, slow라는 이름으로 스토리지 클래스를 지정하고, pd-standard (HDD)타입으로 디스크를 생성하되 us-central1-a와 us-central1-b 존에 디스크를 생성하도록 하였다.



이렇게 정의한 스토리지 클래스는  PVC 정의시에, storageClassName에 적으면 PVC에 연결이 되고, 스토리지 클래스에 정해진 스펙에 따라서 물리 디스크와 PV를 생성하게 된다.

얼굴 인식 모델을 만들어보자 #4 클라우드를 이용하여 학습 시키기

(머신러닝 학습 및 예측 시스템의 운영환경화)


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

앞에서 모델을 만들고 학습도 다했다. 이제, 이 모델을 실제 운영 환경에서 운영할 수 있는 스케일로 포팅을 하고자 한다.


로컬 환경 대비 실제 운영 환경으로 확장할때 고려해야 하는 사항은


  • 대규모 학습 데이타를 저장할 수 있는 공간

  • 대규모 학습 데이타를 전처리하기 위한 병렬 처리 환경
    이 내용은 이미  http://bcho.tistory.com/1177에서 다루었다.

  • 대규모 학습 데이타를 빠르게 학습 시킬 수 있는 컴퓨팅 파워

  • 학습된 데이타를 이용한 대규모 예측 서비스를 할 수 있는 기능


위의 요건을 만족하면서 텐서플로우로 환경을 올리는 방법은 여러가지가 있지만, 클라우드를 선택하기로 한다.

이유는

  • 첫번째 모델 개발에 집중하고, 텐서플로우의 설치 및 운영 등에 신경쓰지 않도록 한다. 단순한 텐서플로우 설치뿐만 아니라 여러 장비를 동시에 이용하여 분산 학습을 하려면, 클러스터 구성 및 유지가 부담이 된다.

  • 클라우드 컴퓨팅 파워를 이용하여, 대규모 데이타에 대한 전처리를 수행하고 개개별 학습 속도를 높이는 것은 물론이고, 모델을 튜닝하여 동시에 여러 모델을 학습 시킬 수 있다.

  • 대용량 학습 데이타를 저장하기 위한 스토리지 인프라에 대한 구성 및 운영 비용을 절감한다.


즉 설정이나 운영은 클라우드에 맏겨 놓고, 클라우드의 무한한 자원과 컴퓨팅 파워를 이용하여 빠르게 모델을 학습하기 위함이다.

구글 클라우드


아무래도 일하는 성격상 구글 클라우드를 먼저 볼 수 밖에 없는데, 구글 클라우드에서는 텐서플로우의 매니지드 서비스인 CloudML을 제공한다.


CloudML은 별도의 설치나 환경 설정 없이 텐서플로우로 만든 모델을 학습 시키거나 학습된 결과로 예측을 하는 것이 가능하다. 주요 특징을 보면 다음과 같다.


  • 학습시에, 별도의 설정 없이 텐서플로우 클러스터 크기 조절이 가능하다. 싱글 머신에서 부터 GPU 머신 그리고 여러대의 클러스터 머신 사용이 가능하다

  • 하이퍼 패러미터 튜닝이 가능하다. DNN의 네트워크의 폭과 깊이도 하이퍼 패러미터로 지정할 수 있으며, CloudML은 이런 하이퍼패러미터의 최적값을 자동으로 찾아준다.

  • 예측 서비스에서는 Tensorflow Serv를 별도의 빌드할 필요 없이 미리 환경 설정이 다되어 있으며 (bazel 빌드의 끔직함을 겪어보신 분들은 이해하실듯) gRPC가 아닌 간단한 JSON 호출로 예측 (PREDICTION) 요청을 할 수 있다

  • 분당 과금이다. 이게 강력한 기능인데, 구글 클라우드는 기본적으로 분당 과금으로 CPU를 사용하던, GPU를 사용하던 정확히 사용한 만큼만 과금하기 때문에, 필요할때 필요한 만큼만 사용하면 된다. 일부 클라우드의 경우에는 시간당 과금을 사용하기 때문에, 8대의 GPU머신에서 1시간 5분을 학습하더라도 8대에 대해서 2시간 요금을 내야하기 때문에 상대적으로 비용 부담이 높다.

  • 가장 큰 메리트는 TPU (Tensorflow Processing Unit)을 지원한다는 것인데, 딥러닝 전용 GPU라고 생각하면 된다. 일반적인 CPU또는 GPU대비 15~30배 정도 빠른 성능을 제공한다.


    현재는 Close Alpha로 특정 사용자에게만 시범 서비스를 제공하고 있지만 곧 CloudML을 통해서 일반 사용자에게도 서비스가 제공될 예정이다.

CloudML을 이용하여 학습하기

코드 수정

CloudML에서 학습을 시키려면 약간의 코드를 수정해야 한다. 수정해야 하는 이유는 학습 데이타를 같이 올릴 수 없기 때문인데, 여기에는 두 가지 방법이 있다.


  • 학습 데이타를 GCS (Google Cloud Storage)에 올려놓은 후, 학습이 시작되기 전에 로컬 디렉토리로 복사해 오거나

  • 또는 학습 데이타를 바로 GCS로 부터 읽어오도록 할 수 있다.


첫번째 방법은 gsutil 이라는 GCS 명령어를 이용하여 학습 시작전에 GCS에서 학습 데이타를 카피해오면 되고,

두번째 방법은 학습 데이타의 파일명을 GCS 로 지정하면 된다.

예를 들어 텐서 플로우 코드에서 이미지 파일을 아래와 같이 로컬 경로에서 읽어왔다면

   image =  tf.image.decode_jpeg(tf.read_file(“/local/trainingdata/”+image_file),channels=FLAGS.image_color)


GCS에서 읽어오려면 GCS 경로로 바꿔 주면 된다. GCS 버킷명이 terrycho-training-data라고 하면

   image =  tf.image.decode_jpeg(tf.read_file(“gs://terrycho-training-data/trainingdata/”+image_file),channels=FLAGS.image_color)


첫번째 방법의 경우에는 데이타가 아주 많지 않고, 분산 학습이 아닌경우 매우 속도가 빠르다. 두번째 방법의 경우에는 데이타가 아주아주 많아서 분산 학습이 필요할때 사용한다. 아무래도 로컬 파일 억세스가 GCS 억세스 보다 빠르기 때문이다.


다음은 첫번째 방식으로 학습 데이타를 로컬에 복사해서 학습하는 방식의 코드이다.


https://github.com/bwcho75/facerecognition/blob/master/CloudML%20Version/face_recog_model/model_localfile.py

코드 내용은 앞서 만들 모델 코드와 다를것이 없고 단지 아래 부분과, 파일 경로 부분만 다르다

def gcs_copy(source, dest):

   print('Recursively copying from %s to %s' %

       (source, dest))

   subprocess.check_call(['gsutil', '-q', '-m', 'cp', '-R']

       + [source] + [dest]


gcs_copy 함수는 GCS의 source 경로에서 파일을 dest 경로로 복사해주는 명령이다.


def prepare_data():

   # load training and testing data index file into local

   gcs_copy( 'gs://'+DESTINATION_BUCKET+'/'+TRAINING_FILE,'.')

   gcs_copy( 'gs://'+DESTINATION_BUCKET+'/'+VALIDATION_FILE,'.')

   

   # loading training and testing images to local

   image_url = 'gs://'+DESTINATION_BUCKET+'/images/*'


   if not os.path.exists(FLAGS.local_image_dir):

        os.makedirs(FLAGS.local_image_dir)

   gcs_copy( image_url,FLAGS.local_image_dir)

   

prepare_data()    

main()


그리고 prepare_data를 이용해서, 학습과 테스트용 이미지 목록 파일을 복사하고, 이미지들도 로컬에 복사한다.

로컬에 데이타 복사가 끝나면 main()함수를 호출하여 모델을 정의하고 학습을 시작한다.



디렉토리 구조

코드를 수정하였으면, CloudML을 이용하여 학습을 하려면, 파일들을 패키징 해야 한다. 별 다를것은 없고


[작업 디렉토리]

  • __init__.py

  • {모델 파일명}.py


식으로 디렉토리를 구성하면 된다.

얼굴 학습 모델을 model_localfile.py라는 이름으로 저장하였다


명령어

이제 학습용 모델이 준비되었으면, 이 모델을 CloudML에 집어 넣으면 된다.

명령어가 다소 길기 때문에, 쉘 스크립트로 만들어놓거나 또는 파이썬 노트북에 노트 형식으로 만들어 놓으면 사용이 간편하다. 다음은 파이썬 노트북으로 만들어놓은 내용이다.


import google.auth

import os

import datetime


os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "/Users/terrycho/keys/terrycho-ml.json"

job_name = 'preparefacedata'+ datetime.datetime.now().strftime('%y%m%d%H%M%S')


리모트로 구글 클라우드의 CloudML을 호출하기 때문에, GOOGLE_APPLICATION_CREDIENTIALS에 서비스 어카운트 파일을 지정한다.

그리고 CloudML에 학습을 실행하면, 각 학습은 JOB으로 등록되는데, 손쉽게 JOB을 찾아서 모니터링 하거나 중지할 수 있도록, JOB ID를 현재 시간으로 생성한다.



print job_name

# Job name whatever you want

JOB_NAME=job_name

# the directory of folder that include your source and init file

PACKAGE_PATH='/Users/terrycho/anaconda/work/face_recog/face_recog_model'

# format: folder_name.source_file_name

MODULE_NAME='face_recog_model.model_localfile'

# bucket you created

STAGING_BUCKET='gs://terrycho-face-recog-stage'

# I recommand "europe-west1" region because there are not enough GPUs in US region for you.....

REGION='us-east1'

# Default is CPU computation. set BASIC_GPU to use Tesla K80 !

SCALE_TIER='BASIC_GPU'


# Submit job with these settings

!gcloud ml-engine jobs submit training $JOB_NAME \

--package-path=$PACKAGE_PATH \

--module-name=$MODULE_NAME \

--staging-bucket=$STAGING_BUCKET \

--region=$REGION \

--scale-tier=$SCALE_TIER \


다음은 cloudml 명령어를 실행하면 된다. 각 인자를 보면

  • JOB_NAME은 학습 JOB의 이름이다.

  • package-path는 __init__.py와 학습 모델 및 관련 파일들이 있는 디렉토리가 된다.

  • module-name은 package-path안에 있는 학습 실행 파일이다.

  • staging-bucket은 CloudML에서 학습 코드를 올리는 임시 Google Cloud Storage로, Google Cloud Storage 만든 후에, 그 버킷 경로를 지정하면 된다.

  • region은 CloudML을 사용한 리전을 선택한다.

  • 마지막으로 scale-tier는 학습 머신의 사이즈를 지정한다.

스케일 티어

설명

BASIC

싱글 머신. CPU

BASIC_GPU

싱글 머신 + K80 GPU

STANDARD_1

분산 머신

PREMIUM_1

대규모 분산 머신

CUSTOM

사용자가 클러스터 크기를 마음대로 설정


일반적인 모델은 BASIC_GPU를 사용하면 되고, 모델이 분산 학습이 가능하도록 개발되었으면 STANDARD_1 이나 PREMIUM_1을 사용하면 된다.


이렇게 명령을 수행하면 모델코드가 CloudML로 전송되고, 전송된 코드는 CloudML에서 실행된다.

학습 모니터링

학습이 시작되면 JOB을 구글 클라우드 콘솔의 CloudML 메뉴에서 모니터링을 할 수 있다.




다음은 CloudML에서의 JOB 목록이다.  (진짜 없어 보인다…)




실행중인 JOB에서 STOP 버튼을 누르면 실행중인 JOB을 정지시킬 수도 있고, View Logs 버튼을 누르면, 학습 JOB에서 나오는 로그를 볼 수 있다. ( 텐서플로우 코드내에서 print로 찍은 내용들도 모두 여기 나온다.)




여기까지 간단하게나마 CloudML을 이용하여 모델을 학습하는 방법을 알아보았다.

본인의 경우 연예인 인식 모델을 MAC PRO 15” i7 (NO GPU)에서 학습한 경우 7000 스텝가지 약 8시간이 소요되었는데, CloudML의 BASIC_GPU를 사용하였을때는 10,000 스탭에 약 1시간 15분 정도 (GCS를 사용하지 않고 직접 파일을 로컬에 복사해놓고 돌린 경우) 가 소요되었다. (빠르다)


여기서 사용된 전체 코드는 https://github.com/bwcho75/facerecognition/tree/master/CloudML%20Version 에 있다.


  • model_gcs.py 는 학습데이타를 GCS에서 부터 읽으면서 학습하는 버전이고

  • model_localfile.py는 학습데이타를 로컬 디스크에 복사해놓고 학습하는 버전이다.


다음 글에서는 학습된 모델을 배포하여 실제로 예측을 실행할 수 있는 API를 개발해보도록 하겠다.

머신러닝 모델 개발 삽질기

빅데이타/머신러닝 | 2017.04.24 14:27 | Posted by 조대협

머신러닝 모델 개발 삽질 경험기


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


딥러닝을 공부하고 CNN 모델을 기반으로 무언가를 만들어보겠다는 생각에, 해외 유명 연예인 얼굴 사진을 가져다가 분류하는 얼굴 인식 모델을 만들어 보기로 하였다.

아직도 진행중이지만, 많은 시행 착오를 겪었는데 같은 시행 착오를 겪지 않고 경험을 공유하기 위해서 겪었던 시행 착오들을 정리해 본다.

학습 데이타 확보 및 분류

먼저 학습용 데이타를 수집 하는 것이 가장 문제 였다. 인터넷에서 사진을 모아서 학습 데이타로 사용해도 되겠지만, 아무래도 저작권 및 초상권 문제가 있고, 일일이 사진을 하나씩 받아서 수집하거나 또는 별도의 수집기를 만드는 것도 부담이 되었다.

그래서 찾은 것이 pubfig라는 셀럽 얼굴 데이타인데 http://www.cs.columbia.edu/CAVE/databases/pubfig/

상용 목적이 아니라 연구용 목적이면 사용이 가능하다. 이 데이타는 파일 URL, 셀럽 이름 형태로 라벨링이 되어 있기 때문에, 학습에 적합하리라고 생각하고, 이 파일을 기반으로 데이타를 수집하였다.


여기서 생긴 문제는, 이 데이타가 오래된 데이타라서 존재하지 않는 파일이 다수 있었고, 이 경우 파일을 저장하고 있는 사이트에서, 404 Not found와 같은 이미지를 리턴하였기 때문에, 이를 필터링해야 하였고, 같은 사진이 중복되서 오는 문제등이 있었기 때문에,상당량을 일일이 필터링을 해야 했다.


그리고, 사진상에, 여러 얼굴이 있는 이미지가 많았기 때문에, VISION API로 얼굴을 인식해서 얼굴 사진만 잘라낼 요량이었기 때문에, 독사진만을 일일이 보고 골라내야 했다. 나중에 생각해보니 VISION API로 얼굴이 한명만 인식이 되는 사진만 필터링을 했으면 됐을텐데. 불필요한 작업이 많았다.

라벨을 문자열로 쓴 문제

학습 데이타에 대한 라벨을 생성할때, 괜히 가독성을 높힌다고 라벨을 문자열로 해서 각 사람의 이름을 사용하였다.

CNN에서 마지막은 Softmax는 matrix이기 때문에, 라벨 문자열을 나중에 list.indexOf를 이용하여 배열로 변경할 예정이었는데, 파이썬에서는 쉽게 될지 몰라고, 텐서플로우 코드에서는 이 과정이 쉽지 않았다.

그래서..

결국은 라벨 데이타를 문자열이 아니라, 0~44의 int 값으로 재 생성한후에,


   batch_label_on_hot=tf.one_hot(tf.to_int64(batch_label),

       FLAGS.num_classes, on_value=1.0, off_value=0.0)


tf.one_hot 함수를 이용하여, 1*45 행렬로 바뀌어서 사용하였다.

학습용 및 검증용 데이타를 초기에 분류하지 않았던 문제

학습데이타를 준비할때, 학습 데이타를 학습용과 검증용으로 따로 분류를 해놨어야 하는데, 이 작업을 안해서, 결국 모델을 만들다가 다시 학습 데이타를 7:3 비율로 학습 데이타와 검증용 데이타로 분류하는 작업을 진행하였다.

학습 데이타의 분포가 골고르지 못했던 문제

사진을 모으는 과정에서 필터링 되서 버려지는 데이타가 많았고, 원본 데이타 역시 사람별로 사진 수가 고르지 못했기 때문에, 결과적으로 모여진 학습 데이타의 분포가 사람별로 고르지 못했다.

학습데이타가 많은 셀럽은 200~250장, 적은 사람은 50장으로 편차가 컸다.


이로 인해서 첫번째 모델의 학습이 끝난 후에, 모델을 검증해보니, 학습 데이타를 많이 준 사람으로 대부분 분류를 해냈다. 47개의 클래스 약 6000장의 사진으로 5시간 학습 시킨 결과, 예측을 검증하는 과정에서 90%이상을 모두 브래드피트로 인식해내는 문제가 생겼다. (내 맥북이 브레드피트를 좋아하는가??)


그래서 결과적으로 학습데이타와 검증 데이타를 클래스별로 분포를 같게 하기 위해서, 클래스당 약 50 장의 샘플 사진으로 맞춰서 예측 결과가 편중되는 현상을 해결하려고 하였다.

학습 순서가 클래스별로 된 문제

클래스별 학습 데이타의 양을 균일하게 맞췄음에도 불구하고, 모델의 학습 결과가 특정 클래스들로 편향되는 현상이 발생하였다.

이는 학습을 시킬때, 골고루 학습을 시켜야 하는데, 학습 데이타를 순서대로 학습을 시켰기 때문에 발생한 문제이다. 즉 풀어서 말하자면, “브래드 피트"를 20번 학습 시키고, “안젤리나 졸리"를 20분 학습 시키고, “브루스 윌리스”를 20번 학습 시켜서 모델이 첫 학습데이타 쪽으로 편향되는 현상이 발생한것인데, 이를 해결하려면 학습 데이타를 랜덤으로 만들어서 학습시켜야 한다.

예를 들어 “브래드 피트”,”안젤리나 졸리",”브루스 윌리스",”안젤리나 졸리",”브루스 윌리스", ”안젤리나 졸리",“브래드 피트” …. 이런식으로 말이다.

즉 코드 상에서 배치 데이타를 읽어올때 셔플 처리를 하면되는데 이를 위해서 데이타를 읽는 부분을 다음과 같이 변경 하였다.


def get_input_queue(csv_file_name,num_epochs = None):

   train_images = []

   train_labels = []

   for line in open(csv_file_name,'r'):

       cols = re.split(',|\n',line)

       train_images.append(cols[0])

       # 3rd column is label and needs to be converted to int type

       train_labels.append(int(cols[2]) )

                           

   input_queue = tf.train.slice_input_producer([train_images,train_labels],

                                              num_epochs = num_epochs,shuffle = True)

   

   return input_queue


get_input_queue 함수에, csv_file_name을 인자로 주면, 이 파일을 한줄 단위로 읽어서, 첫번째는 파일명, 세번째는 라벨로 읽은 후에, 각각 train_images와  train_lables에 각각 string과 int 형으로 저장한다

그 다음이 배열을 가지고 tf.train.slice_input_producer를 사용하면 배열에서 데이타를 읽어 드리는 input queue 를 생성하는데, 이때 인자로 shuffle = True로 주면 데이타를 리턴 할때 순차적으로 리턴하지 않고 셔플된 형태로 랜덤하게 리턴한다.


def read_data(input_queue):

   image_file = input_queue[0]

   label = input_queue[1]

   

   image =  tf.image.decode_jpeg(tf.read_file(image_file),channels=FLAGS.image_color)

   

   return image,label,image_file


다음으로, 이 큐를 이용하여 이미지 파일명과, 라벨을 읽어서 이미지 파일 데이타(텐서)와 라벨로 읽는 코드를 read_data라는 함수로 구현하였다. 입력값은 input_queue인데, input queue에서 데이타를 읽으면 첫번째는 이미지 파일명, 두번째는 라벨이 되는데, 첫번째 파일명을 tf.image.decode_jpeg함수를 이용하여 텐서로 읽은후, 읽은 이미지 데이타와 라벨을 리턴하였다.


def read_data_batch(csv_file_name,batch_size=FLAGS.batch_size):

   input_queue = get_input_queue(csv_file_name)

   image,label,file_name= read_data(input_queue)

   image = tf.reshape(image,[FLAGS.image_size,FLAGS.image_size,FLAGS.image_color])

   

   batch_image,batch_label,batch_file = tf.train.batch([image,label,file_name],batch_size=batch_size)

                                                      #,enqueue_many=True)

   batch_file = tf.reshape(batch_file,[batch_size,1])


   batch_label_on_hot=tf.one_hot(tf.to_int64(batch_label),

       FLAGS.num_classes, on_value=1.0, off_value=0.0)

   return batch_image,batch_label_on_hot,batch_file


마지막으로, 배치로 데이타를 읽는 함수 부분에서 앞에 정의한 get_input_queue와 read_data 함수를 이용하여 데이타를 shuffle 된 상태로 읽은 후에, tf.train.batch를 이용하여 일정한 개수 (배치) 형태로 리턴하도록 하였다.


그 결과 예측 결과가 한쪽으로 편향되는 현상을 없앨 수 는 있었다.

샘플 데이타의 부족

데이타 편향 현상은 잡았지만, 클래스의 수(45)에 대비하여, 샘플데이타의 수(클래스당 50개)로 부족하여, 학습을 계속 진행해도 cross entropy 함수는 4~7 사이에서 왔다갔다 하면서 더 이상 0으로 수렴하지 않았고 정확도되 0~35% 사이를 왔다갔다 하면서 수렴을 하지 않았다.


그래서, 학습 이미지의 색이나, 방향등을 변경하는 방법으로 데이타를 뻥튀기 하려고 하는데, 이 부분은 아직 작업중.

그외에 자잘한 삽질

모 그외에도 엄청 여러가지 삽질을 하고 있다. 그래도 모델 하나 제대로 만들어봐야 겠다는 생각에 끝까지 우격다짐으로 진행하고 있지만, 학습을 돌다가 스크린 세이버나, 절전 모드로 들어가서 학습이 중단된 사례. 모델을 개발하다가 중간에 텐서 플로우 버전이 올라가서 코드를 수정한 일. 맥에서 개발하다가 윈도우 머신에 GPU로 바꿨더니, 파이썬 2.7이 아니라 파이썬 3.5만 지원을 해서, 2.7 코드를 모두 다시 고친일등.


머신러닝이 과학이나 수학보다 노가다라는데, 몸소 느끼는 중.


텐서플로우의 세션,그래프 그리고 함수의 개념


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


그래프와 세션에 대한 개념이 헷갈려서, 좋은 샘플이 하나 만들어져서 공유합니다.

텐서 플로우의 기본 작동 원리는 세션 시작전에 그래프를 정의해놓고, 세션을 시작하면 그 그래프가 실행되는 원리인데, 그래서 이 개념이 일반적인 프로그래밍 개념과 상의하여 헷갈리는 경우가 많다


즉, 세션을 시작해놓고 함수를 호출하는 케이스들이 대표적인데

http://bcho.tistory.com/1170 코드를 재 사용해서 이해해보도록 하자


이 코드를 보면, tt = time * 10 을 세션 시작전에 정의해놨는데, 이 코드를 함수로 바꾸면 아래와 같은 형태가 된다.


변경전 코드

def main():

   

   print 'start session'

   #coornator 위에 코드가 있어야 한다

   #데이타를 집어 넣기 전에 미리 그래프가 만들어져 있어야 함.

   batch_year,batch_flight,batch_time = read_data_batch(TRAINING_FILE)

   year = tf.placeholder(tf.int32,[None,],name='year')

   flight = tf.placeholder(tf.string,[None,],name='flight')

   time = tf.placeholder(tf.int32,[None,],name='time')

   

   tt = time * 10

   summary = tf.summary.merge_all()

   with tf.Session() as sess:

       summary_writer = tf.summary.FileWriter(LOG_DIR,sess.graph)

       try:


           coord = tf.train.Coordinator()

           threads = tf.train.start_queue_runners(sess=sess, coord=coord)


           for i in range(5):

               y_,f_,t_ = sess.run([batch_year,batch_flight,batch_time])

               print sess.run(tt,feed_dict={time:t_})

               #summary_str = sess.run(summary,feed_dict=feed_dict)

               #summary_writer.add_summary(summary_str,i)

               summary_writer.flush()         


변경후 코드

def create_graph(times):

   tt = times * 10

   return tt


def main():

   

   print 'start session'

   #coornator 위에 코드가 있어야 한다

   #데이타를 집어 넣기 전에 미리 그래프가 만들어져 있어야 함.

   batch_year,batch_flight,batch_time = read_data_batch(TRAINING_FILE)

   year = tf.placeholder(tf.int32,[None,],name='year')

   flight = tf.placeholder(tf.string,[None,],name='flight')

   time = tf.placeholder(tf.int32,[None,],name='time')

   

   r = create_graph(time)

   

   summary = tf.summary.merge_all()

   with tf.Session() as sess:

       summary_writer = tf.summary.FileWriter(LOG_DIR,sess.graph)

       try:


           coord = tf.train.Coordinator()

           threads = tf.train.start_queue_runners(sess=sess, coord=coord)


           for i in range(5):

               y_,f_,t_ = sess.run([batch_year,batch_flight,batch_time])

               print sess.run(r,feed_dict={time:t_})

               #summary_str = sess.run(summary,feed_dict=feed_dict)

               #summary_writer.add_summary(summary_str,i)

               summary_writer.flush()


변경후 코드는 tt = times * 10 을 create_graph라는 함수로 뺐는데, session 시작전에 함수를 호출한다. 언뜻 보면 개념이 헷갈릴 수 있는데, time 이라는 변수는 텐서플로우의 placeholder로 값이 읽혀지는 시점이 queue_runner를 시작해야 값을 읽을 수 있는 준비 상태가 되고, 실제로 값을 큐에서 읽으려면 session을 실행하고 feed_dict를 이용하여 feeding을 해줘야 값이 채워지기 때문에, 일반적인 프로그램상으로는 session을 시작한 후에 함수를 호출해야할것 같이 생각이 되지만, 앞에서도 언급했듯이 텐서플로우에서 프로그래밍의 개념은 그래프를 다 만들어놓은 후 (데이타가 처리되는 흐름을 모두 정의해놓고) 그 다음 session을 실행하여 그래프에 데이타를 채워놓는 개념이기 때문에, session이 정의되기 전에 함수 호출등을 이용해서 그래프를 정의해야 한다.


Apache Camel Overview

아키텍쳐 /EAI | 2013.02.17 00:43 | Posted by 조대협

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

서문

예전 BEA나 오라클 시절에, EAI, ESB 등을 가지고 시스템간의 연계 업무를 많이 해왔던 나로써는 오픈 소스 기반의 EAI 프레임웍인 Apache Camel의 경우 상당히 흥미로운 주제였다. 과연 상용 제품 대비 얼마나 현실성있는 integration 기능을 제공할 것인가? 가 가장 큰 궁금증이었다.

BEA WebLogic EAI, Oracle Service Bus, AIA 등 여러 제품을 이용해서 직접 시스템간의 연계 시나리오도 구현해보고, BMT에서 타의 솔루션을 테스트도 해봤지만, 먼저 상용 솔루션의 약점은, 솔루션에서 제공하는 시스템간의 연계에 있어서 성능적인 제약이 매우 많이 따른 다는 것이다. 대부분 Message Queue 구조의 비동기 구조를 통해서, 양단간에 데이타 연계를 하는 시나리오가 많은데, 이 경우 비주얼하게 각 단계에 대해서 모니터링은 가능 하지만, 대규모 처리에 있어서 비동기의 약점 때문에 성능적인 제약이 따르고 특히 대규모 메세지 처리에 있어서 그리 매끄럽지 못했던 경험이 있다. BPEL과 같은 제품의 경우 양단간의 연동 시나리오중, 개개별 메세지를 콘솔을 통해서 트레이스할 수 있는데, 하루에 수백,수천건을 연계하는 거래의 경우에는 GUI 콘솔을 통해서 메세지를 전달 내용이나 에러 내용을 추적한다는 것은 애초 부터 불가능한 일이다.

 그래서 실제 프로젝트 때에는 송수신 시스템을 연동하는 양쪽의 아답터 (JMS, 메인프레임, TP 모니터, ERP, CRM 등 다양한 시스템과 연동이 필요하기 때문에, 상용 제품에서 지원되는 아답터는 매우 중요하다)와 기본적인 메세지 플로우 이외의 부분은 대부분 직접 구현하였다. 그래서, EAI와 같은 제품에서 필요한 구조와 이런 것을 요구 사항에 맞게 빠르게 만들었으면 하는 프레임웍이 있었으면 했는데, Apache Camel을 보니, EAI와 같은 연계 업무성 프레임웍으로 적합해 보인다.

Apache Camel의 특징을 보면

Message Integration Framework

Camel은 기본적으로 Message Integration Framework이다. Framework임을 강조하는 것은, ESB EAI 제품과 같은 솔루션이라기 보다는 이를 개발하기 위한 Framework으로 보는 것이 적절하다고 판단된다.

이유는 ESB EAI는 메세지 연동 기능을 수행하기 위한 컨테이너가 있다. (즉 서버가 있다) 아무런 연동 인터페이스가 없더라도, 연동 인터페이스를 수용할 수 있는 컨테이너가 있고, 이 컨테이너들은 모니터링, 로깅등의 관리 기능을 제공한다. 그러나 CamelLibrary이다. 자체적으로 Container를 가지고 있지 않다. 다만, OSGI 컨테이너나 WAS, Spring등에 탑재 되서 돌아갈 수 있다. 쉽게 이야기 하면, EAI ESB와 같은 솔루션 제품은 서버를 설치해야 하고, 서버 관리를 위한 관리 콘솔 UI를 제공한다. Camel Jar로 된 라이브러리 이다.

상용 제품 연계에는 적절하지 않다.

Camel을 보면, 타 솔루션을 연동하기 위한 아답터, (Camel에서는 Component라고 부른다)가 있다. 50여개의 아답터가 있기는 하지만, 기업에서 많이 사용되는 솔루션의 아답터는 턱없이 부족하다. 예를 들어 SAP ERP, Sieble CRM, Tuxedo, AS/400 과 같은 애플리케이션에 대한 아답터 지원이 없다. 상용 제품의 경우 이런 아답터 지원이 강력하다.

반면, DB,FTP,HTTP,JMS와 같이 일반적인 애플리케이션 개발에 사용되는 기술에 대한 아답터는 많이 제공된다.

Apache Camel의 컨셉

Apache Camel의 컨셉을 대략적으로 도식화 해보면 다음과 같다.


Route

먼저 Route 라는 개념을 이해해야 하는데, Route하나의 시스템간의 연동 인터페이스를 정의한다. 예를 들어 시스템 A에서 B로 웹서비스를 이용해서 연동을 했다면 이것이 하나의 Route가 된다. Route 1:1 관계뿐만 아니라 1:N의 관계도 지원 하는데, A 시스템에서 B 시스템으로 JMS로 메세지를 보내고, 그후에 C 시스템으로 FTP 파일 전송하는 인터페이스가 있다면, 이 역시 하나의 Route로 정의할 수 있다.

Component

Route는 크게 Component Processor로 정의 된다. 연계 하고자 하는 송신 시스템과 수신 시스템이 있을때, 각 송신,수신 시스템의 주소(IP) end point라고 정의하며, Component는 일종의 아답터의 개념으로, 송수신 시스템의 프로토콜에 맞는 컴포넌트를 선택해야 한다. 예를 들어 송신 시스템을 FTP로 연동하고 싶다면, FTP 컴포넌트를 , JDBC로 연동하고 싶다면, JDBC 컴포넌트를 사용해야 한다. 컴포넌트는 송신 시스템으로 부터 메세지를 읽어드리고, 수신 시스템으로 메세지를 전송하는 역할을 한다.

Processor

메세지를 읽고 그냥 보내기만 한다면 별 문제가 없겠지만, 시스템간의 연동에는 메세지를 받은 후에 수신 시스템으로 보내기전에 하다못해 로깅을 남기더라도 무엇인가 항상 처리를 한다. 이렇게 송신 시스템으로 부터 받은 메세지를 수신 시스템에 보내기전에 무엇인가 처리를 하는 부분을 Processor라고 하는데, Processor는 그 특징에 따라서 몇가지로 나뉘어 질 수 있다.

1. Message Transformation

Message Format Transformation

메세지의 포맷을 변경하는 작업을 수행한다. 예를 들어 JSON으로 들어온 데이타를 XML로 변경하는 것들이 이에 해당한다.

Message Type Transformation

메세지의 데이타 타입을 변경한다. String으로 들어온 메세지를 jms:TextMessageType으로 변경하는 등의 작업을 수행한다.

이러한 메세지 변환은 Java Class를 정의해서할 수 있으며, 이외에도 Camel에서 미리 제공되는 Converter, XSLT를 이용한 변환 Apache Velocity의 같은 Template 엔진등 다양한 방법을 이용해서 변환이 가능하다.

2. Routing

메세지 라우팅은 들어온 메세지를 다수의 수신 시스템에 조건에 따라서 라우팅할 수 있는 기능이다.


Processor 단계는 쉽게 생각하면, 메세지를 받은 후, 보내기전에 무엇인가.. 를 하는 곳이다. 앞서 설명한것처럼, 메세지를 변환하거나, 라우팅할 수 도 있고, 로깅을 할 수도 있다. 들어온 메세지에 대해서 유효성 검증을 할 수 도 있다. 이러한 Processor는 자주 사용되는 메세지 변환등의 패턴은 Camel에 의해서 제공되지만, Java 클래스를 구현하면, 무엇이든지 가능하기 때문에 메세지에 대한 거의 모든 처리를 구현할 수 있는 단계이다.

 

이렇게, “송신 Component à Processor à 수신 Component”로 하나의 Route가 정의되는데, 이렇게 Route를 정의하여 객체화 시키는 것이 RouteBuilder이다. 이렇게 RouteBuilder에 의해서 생성된 Route CamelContext에 바인딩이 된다. CamelContext SpringContext와 유사한 개념으로 생각하면 된다. Route에 대한 집합이며, Route에 대한 라이플 사이클 (Start up,Stop)등을 관리한다.

간단한 개발 예제

이쯤에서 간단한 예제를 하나 보자. 다음은 FTP로 원격지 디렉토리의 파일을 읽어서 Local Directory에 쓰는 Camel Application이다.

먼저 Maven을 이용해서 다음과 같이 Camel Project를 만든 후에,

mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router

다음과 같은 코드를 구현한다.

public class MyRouteBuilder extends RouteBuilder {

    public static void main(String... args) throws Exception {

        Main.main(args);

    }



    public void configure() {

        from("ftp://userid@168.1.2.3/camel/src/?password=password&stepwise=false")

         .to("file:c:/temp/");

 

    }

}

위의 코드는 RouteBuilder를 구현한 코드로 configure 메서드에서 FTP로 파일을 읽어와서 Local에 저장하는 route를 정의한 예이다.

DSL

눈치가 빠른 사람이라면, 위의 코드가 몬가 이상하다는 것을 느꼈을지도 모르겠다. configure 메서드안에 from(“….”).to(“….”).??

함수().함수() 호출? Java에서 이런 문법이 있었던가?

정확히 이야기 하면 이건 일반적인 Java Coding이 아니라 DSL (Domain Specific Language)이다. DSL은 특수목적으로 정의된 언어를 이야기 하는데, 여기서 사용된 Java DSL Route를 효율적으로 정의하기 위해서 Camel에 정의된 내장 스크립트 언어이다.

JavaDSL을 이용하면 상당히 쉽게 Route를 구성할 수 있는데, Camel은 이 Java DSL 뿐만 아니라, 다음과 같이 상당히 다양한 DSL을 제공한다.

Ÿ   Spring XML : XML 기반으로 정의된 DSL , Spring xml configuration 파일에 정의

Ÿ   Groovy,Scala DSL : Groovy 언어, Scala 언어 기반의 DSL

Ÿ   Annotation DSL : Java Annotation 기반의 DSL

Ÿ   기타 (Kotlin DSL, Bluprint XML etc)

(참고: http://camel.apache.org/dsl.html)

DSL Route Processor 부분을 정의하는데 주로 사용되는데, 송수신, Component만 정의되면, 사실상 시스템 연계에서 구현해야 되는 부분은 거의 Processor이며, Processor의 로직 대부분은 메세지 처리, 변환,라우팅에 해당하는 내용이기 때문에 특수목적의 DSL을 사용할 수 있으며, 또한 DSL 사용을 통해서 개발 생산성이나 코드양을 획기적으로 줄일 수 있다.

예를 메세지를 스트링으로 받아서 reverse하여, 화면에 출력하는 경우 Java DSL을 이용하면

from("direct:test")

      .transform(new Expression() {

         @Override

         public Object evaluate(Exchange e) {

            return new StringBuffer(e.getIn().getBody().toString()).reverse().toString();

         }

      })

      .process(new Processor() {

         @Override

         public void process(Exchange e) {

           System.out.println(e.getIn().getBody());

         }

      });

인데 반해서, Groovy DSL을 사용하면

from('direct:test')

      .transform { it.in.body.reverse() }

      .process { println it.in.body }

같이 단지 3줄이면 간단하게 끝난다.

Camel EIP

시스템 연동에는 사실 많은 패턴들이 있다. 메세지 변환, 라우팅, 로그 추적을 위한 글로벌 트렌젝션 ID, 장애시 재처리등등 여러가지 방법이 있는데, 이를 패턴화 시켜놓은 것이 Enterprise Integration Pattern (EIP)이다. EIP


책에 잘 정의 되어 있으니 참고하기 바란다.

사실 Camel에서 반영 및 설계되어 있는 EIP도 이 책에 있는 내용을 대부분 바탕으로 하여 구현되어 있다. (Camel을 쓸려면 이책은 꼭 한번 읽어봐야 하지 않을까 싶다.)

 

참고 : http://camel.apache.org/enterprise-integration-patterns.html 에 간단하게 대표적인 EIP 들이 정리되어 있다.

상용 지원

오픈소스가 무료이라서 저 비용의 장점을 가지고 있지만, 반대로, 오픈소스는 기술지원이나 교육 부분에서 매우 취약하다. 그래서 RedHat과 같이 오픈소스 제품에 대해서 subscription base로 기술 지원이나 교육 및 컨설팅을 제공하는 회사들이 존재하는데, Apache Camel 역시 http://fusesource.com/ 는 곳에서 상용 기술 지원을 받을 수 있다. (얼마전에 Redhat에 인수되었다.) Fuse Source의 경우, Camel을 이용하여 제품을 만들어서 판매하고 있으며, Camel 프로젝트에 참여하고 있는 Commiter 들을 많이 보유하고 있다고 한다.

http://fusesource.com/products/enterprise-camel/ 들어가면 Fuse Source에서 개발 및 판매하는 상용 Camel을 다운로드 받을 수 있으며, 개발 관련 및 트레이닝 자료들을 살펴볼 수 있다.

결론

짧은 시간내에 살펴본 제품이라서 아직 완벽한 특성은 파악하지는 못했다. 그러나 EAI, ESB와 같이 메세지 기반의 연동 처리를 하기 위한 시스템을 개발한다면, 개발 프레임웍으로 충분히 활용할만 하다. 특히 엔터프라이즈의 특정 애플리케이션 (ERP,CRM)등이 아니라 일반적인 프로토콜 (HTTP,JMS,TCP)등을 사용하여 그리 복잡하지 않으면서 고속의 연동 처리를 필요로 한다면 아주 유용하게 사용할 수 있을 것이라 판단된다.

시간 관계상 에러처리, 모니터링, 배포 및 확장성등 운영 관점에 대한 부분은 깊게 살펴보지 못했지만, 그냥 개발 프레임웍으로 본다면, 어짜피 운영 관련 부분은 직접 구현해야 하니까는 괜찮지 않을까 싶다.

다만 단순히 프레임웍이기 때문에, 클러스터링 기반의 HA나 부하 분산등의 기능을 제공하지 않는 것이 아쉬운 점이다.

시스템간의 연동의 중요성과 편이성을 경험한 나한테는, Apache Camel물건은 물건이다.” 라는 결론이 적절하다고나 할까?

 

ErrorHandling - http://bcho.tistory.com/716


참고:ErrorHandling에 대한 관련글 -

http://www.consulting-notes.com/2010/08/camel-exception-handling-overview.html 

정리가 잘되어 있네...

 

'아키텍쳐  > EAI' 카테고리의 다른 글

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (2) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21
PDF 버전입니다.

실용주의 ALM (Application Lifecycle Management) Overview

ALM | 2009.02.18 17:35 | Posted by 조대협

 

Practical Application Life cycle Management (ALM)

 Overview

ALM의 정의를 wikipedia에서 찾아보면 다음과 같다.

Application lifecycle management (ALM) is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.[1]

 

해석해 보자면, 기존의 애플리케이션 개발은 기술적인 관점에서 많이 접근이 되어 왔으나, 비즈니스 요건 관리 부분과 실제 소프트웨어 개발 프로세스를 융합하고 이에 대한 관리를 자동화된 툴을 이용하도록 하는 것이 ALM의 개념이며, 이 부분에는 요구 사항 관리, 아키텍쳐, 코딩, 테스팅, 그리고 이슈 추적과 릴리즈 관리등을 포함한다. 

한마디로 이야기 하면 비즈니스와 실제 소프트웨어 개발간의 괴리를 없애고, 소프트웨어 개발의 요구사항 분석에서부터 릴리즈까지의 모든 과정을 툴을 도입함으로써 관리하겠다는 개념이다. 

기존에 소프트웨어 개발 프로세스는 요구 사항 관리에 대한 문서나 시스템, 아키텍쳐나 디자인에 대한 Case tool과 산출물, 코드 관리, 일정 관리 등등이 각기 다른 제품과 다른 프로세스 다른 템플릿으로 구현이 되어 왔고 이로 인해서 소프트웨어 개발 과정에 대한 개념이 실제로 구현되었을때는 단계별로 추적성과 실용성이 떨어졌다.

ALM의 의미는 이런 현실과 괴리된 부분을 좀더 통합되고 현실적으로 전문화된 도구를 이용하여 현실화 시키고 궁극적으로 소프트웨어 개발 프로세스를 개선하는데 목적을 두고 있다고 말할 수 있다. 

ALM이 실제 커버하는 범위를 보면 아래 그림과 같이 요구사항 관리에서부터 프로젝트 관리, 릴리즈 관리까지 소프트웨어 개발의 거의 전 영역을 커버하는 것을 볼 수 있다.


(위키피디아 ALM Concepnt 그림 인용 : http://en.wikipedia.org/wiki/Application_lifecycle_management)

 

요즘 들어서 많은 업체들이 이 ALM이라는 개념을 사용하고 있다. H*의 경우 버그 추적 시스템을 기반으로 이슈 관리, 테스트 자동화 도구를 가지고 ALM이라고 이야기 하고 있으며 Mc* 라는 업체의 경우 테스팅 툴 하나만을 가지고 ALM 업체라고 이야기 하고 있다. 

ALM이 가져야 할 최소한의 요건은

요구 사항 관리, 프로젝트 스케쥴 관리를 위한 Task 관리, 빌드 환경 자동화 및 형상 관리, 테스트 자동화 부분이 핵심이다.

그외에 Deployment의 경우 주로 운영 (SM : System Management) 조직이 담당하며, Design이나 아키텍쳐링의 경우 ALM 사상내에 포함되는 것이 이론적으로는 맞지만, 사실 Design의 경우 프로세스를 정형화 시키기 어려울뿐더러, 실제 프로젝트에서는 Design이 프로젝트가 진행되어감에 따라 변화하고 완성되어 가기 때문에,  Design을 포함시키는 것은 쉽지 않다.

사람들은 프로젝트를 하면서 똑똑해지고 시스템은 프로젝트 진행됨에 따라 명확해 진다. Agile 사상에서도 Design은 선행 작업이 아니라, 주로 프로젝트 진행과 같이 가는 On going 작업으로 정의하고 있다. Design을 ALM의 구현체 내에 포함시키기 위해서는 말단 개발자까지 상당 수준의 성숙도가 필요하다. 

문제점

ALM의 사상적인 출발은 툴을 이용한 소프트웨어 개발 사이클의 현실화인데, 시장에 있는 툴의 경우 그 성숙도가 매우 높아서 프로젝트에 적용하는데 상당한 경험과 지식을 필요로 한다. 실용적인면에서 생각했을 때 ALM의 적용 범위는 일반 말단 개발자 수준에 까지 적용이 되어야 하기 때문에 난이도가 높을때는 실제 프로젝트에 적용하기가 어려운 점이 많다.

또한 ALM Company를 자칭 하는 많은 회사들이 ALM에 대한 Full set을 가지고 있지 않은 상태에서 마케팅적인 메시지로 Drive 하는 경우가 많아서 사용자의 혼란을 초래하고 있다. 

그리고 무엇보다 중요한 것은 ALM을 시스템으로 구축하기 위한 제품이 아니라 ALM을 조직에 적용하기 위한 프로세스와 방법론 즉, 컨설팅과 같은 인적 지원면인데, 적어도 국내의 벤더들에서는 실용적으로 ALM을 프로젝트에 적용할 수 있는 업체가 있는지는 의문이다. 

실용주의 ALM

실용주의 ALM은 이런 문제점을 바탕으로 좀더 실용적이고 실무적인 ALM을 개발하여 실무에 사용하고자 하는데 목적을 두고 있으며 아래와 같은 특징을 갖는다.

l        주로 오픈소스나 저비용의 제품을 조합하여 ALM의 핵심 범위를 커버한다.
l        Agile과 Kent Beck, Erich Gamma, Joel Spolsky 등에 의해서 주장되고 있는 실용주의 방법론 (Practical methodology)를 바탕으로 하여, 튼튼한 이론적인 바탕을 가지고 현실에 맞는 실용적인 프로세스를 구축한다.
l        구현팀을 위주로 프로세스를 정의한다.
l        품질 향상 

End to end use case (시나리오)

이해를 돕고자 이제부터 소개하고자 하는 실용주의 ALM 프레임웍의 가상 시나리오를 살펴보도록 하자


개발자 시나리오
1)       개발자 D씨는 아침에 출근해서 이클립스 IDE를 오픈한다.
2)       이클립스 IDE는 이슈추적툴로 부터 D씨에게 할당된 작업들이 리스트업되고, 그중에서 오늘해야 할 작업을 선택하여 PROGRESS로 상태를 변경한다.
3)       SCM으로 부터 최신 코드를 UPDATE받고 코딩을 시작한다.
4)       코드를 만들고 테스트 케이스를 작성하여 코드가 제대로 작동함을 확인하고, 커버러지 분석을 통해서 금일 코딩한 내용이 테스트에서 모두 확인 되었는지 체크한다.
5)       오늘 코딩한 내용을 INSPECTION툴을 통해서 잠재적인 문제가 있는지 없는지 검증 받고 NAMING RULE등이 문제 없는지 확인한다.
6)       완료된 내용을 SCM에 작업 번호와 함께 COMMIT한다.
7)       자동 빌드 머신에서 COMMIT된 소스코드를 감지하고 모든 소스를 내려받아서 빌드를 완료한후에 개발 서버에 자동으로 배포하고 테스트를 수행한다.
8)       테스트가 실패한 경우 이전 버전으로 개발 서버를 원복 시키고 모든 개발원과 PM에게 이메일로 테스트 실패 사실을 통보한다.
9)       PM은 테스트 실패사실을 이메일로 통지 받고, 이번 빌드에서 변경된 부분을 빌드 자동화 시스템을 통해서 확인하고 빌드 자동화 시스템에 의해서 리포트된 내용에 따라 누가 어느 모듈을 수정했는지를 찾아서 해당 개발자에게 수정을 지시한다.
10)   개발자는 수정을 마친후에 다시 SCM에 소스를 반영하고 빌드 자동화 시스템은 빌드,테스트,커버러지 분석,코드 복잡도 분석,INSPECTION작업을 수행한다.
11)   PM은 빌드가 완료된 결과를 통보 받고, 복잡도가 높은 클래스 모듈 10개에 대해서 제대로 테스트가 커버하는지 확인하후에 미비한 부분에 대해서 담당 개발자에게 테스트 보강을 지시한다. 

PM의 작업지시 시나리오
1)       PM P씨는 아침에 출근하여 고객으로 부터 새로운 요건을 받았다.
2)       P씨는 요건을 정리하여 내용을 이슈 트랙킹 시스템에 등록하고 심각도와 우선 순위를 지정해서 개발 PL에게 ASSIGN하였다.
3)       개발 PL은 요건의 우선 순위와 긴급도를 보고 누구에게 작업을 지정할것인지 고민한다. 이슈 트랙킹 시스템에서 개발원별로 진행중인 이슈 사항을 보고 개발 난이도에 맞는 사람중에서 가장 할당된 이슈가 적은 사람에게 이슈를 ASSIGN하였다.
4)       개발자는 해당 ISSUE를 받아서 처리한 후 PL에게 다시 ASSIGN한다.
5)       이때 작업에 관련된 메일,전화 통화내용 기타 관련 내용들을 시스템에 모두 LOGGING한다.
6)       PL은 작업이 완료된 내용을 검토한후 해당 ISSUE를 CLOSE한다.
7)       PM은 자신이 지시한 내용에 대해서 누가 진행하고 있으며 진행현황이 어떻게 되었는지를 이슈를 통해서 추적할 수 있다.

PM의 현황 관리 시나리오

1)       PM P씨는 1차 오픈 때까지 해결되어야 할 이슈를 이슈 관리 시스템에서 검색한다.
2)       심각도가 높은 이슈와 오픈된지 오래된 이슈를 확인하여 진행이 안되고 있는 이유는 무엇인지 RISK는 무엇인지를 조사하고, RISK에 대한 대비책을 세운다.

만약에 날짜에 비해서 해결되어야 할 이슈가 많을 경우 심각도와 우선순위를 고려하여 2차 오픈으로 이슈를 연기한다.

실용주의 ALM 구성

실용주의 ALM은 크게 4가지 모듈로 구성된다.


Task Management (Task 기반의 프로젝트 관리)

프로젝트에서 진행되는 작업에 대한 진행 상황과 스케쥴링 그리고 리소스에 대한 관리 방법론을 제공한다. 기본적인 사상은 Agile 방법론의 프로젝트 관리 방안을 기반으로 하고 있다.Task Management 모듈은 다음과 같은 서브 모듈을 포함하고 있다  

Process
1)       Task Management Process : Agile Scrum 기반의 Task 관리 프로세스
2)       SOA or Open API Service Lifecycle Management Process (Optional) : SOA나 WEB 2.0에서 Service Lifecycle (서비스 신청에서부터 배포 까지) 관리 프로세스와 시스템
3)       Requirement Analysis Process (TBD) : 요구 사항 추출 프로세스

Reference Architecture
1)       Task Management System Reference Architecture  : 프로세스를 구현한 Task 관리 시스템
2)       Task Management Dash board Reference Architecture : 프로젝트의 진행 상태를 한눈에 알 수 있는 Dash board
3)       Requirement Analysis Management Reference Architecture (TBD) 요구 사항 관리 시스템

Build Environment (빌드 환경)

Implementation 단계에서 사용되는 개발환경을 제공한다. 기본적인 사상은 Pragmatic(실용주의) 방법론으로 Kent beck이나 Joel Spolsky에 의해서 소개된 방법론을 기초로 하며, 일일 빌드와 점진적/반복적 통합론을 중심으로 개발환경 구성에 대한 가이드를 제공한다.

다음과 같은 서브 모듈을 포함하고 있다

Process
1)       SCM branch guide : 소스 형상 관리에 대한 브렌치 관리 전략
소스 코드 관리에 있어서 브렌치에 대한 관리 방법을 기술한다. 브렌치는 잘못쓰면 전체 소스코드 관리를 하는데 있어서 엄청난 혼란을 초래할 수 있는 만큼 적절한 브렌치 관리 정책이 정해져야 한다.

2)       Contiguous Integration Process : 점진적 통합 방법에 대한 프로세스
자동 빌드 시스템을 구축하여, 개발자의 소스 코드 변화를 자동으로 인지하고 매일 자동 빌드를 통해서 코드의 통합을 빅뱅 방식이 아니라 매일 점진적인 방식으로 진행함으로써 통합으로 인해 발생할 수 있는 문제를 조기에 발견하고 해결할 수 있도록 하며, 빌드 과정내에 테스팅을 포함시켜서 결함을 조기에 발견하여 전체 소프트웨어 품질 향상을 유도 한다.

Reference Architecture
1)       Standard IDE : 개발자를 위한 표준 개발 환경 가이드
프로젝트에서 개발자별로 선호하는 개발 도구들이 다르다. (이클립스, NetBeans, VI 등) 다른 개발 도구는 구현된 코드에도 영향을 주며, 특히 새로운 팀원이 합류했을 때 보통 1~2일을 개발환경을 셋업 하는데 시간을 소요 하게 된다. 표준 개발 환경은 ZIP으로 개발에 필요한 모든 환경을 만들어서 개발자가 ZIP 파일만 풀면, IDE에서 테스트 프레임웍, 테스트용 서버 환경까지 일괄로 셋업이 되서 모든 개발자가 빠른 시간내에 동일한 개발환경에서 소프트웨어를 구현할 수 있도록 한다.

2)      Contiguous Integration Reference Architecture
실제 CI 환경을 구축하는데 필요한 아키텍쳐에 대해서 설명한다.

3)       Standard Build Script : 표준 빌드 스크립트 구축 가이드

표준 개발환경과 마찬가지로 빌드 스크립트 역시 표준화 되어야 한다. LIB 위치나 버전, 빌드 스크립트내의 TARGET 정의, 빌드 순서등을 통합하고 표준화된 형태로 제공하여 개발자가 빌드 스크립트 작성에 소요되는 시간을 절약하고, 비표준화된 빌드스크립트 사용에서 오는 오류를 예방한다. 

Test Automation (테스트 자동화)

일반적으로 테스팅은 QA팀의 역할로 인식이 되어 왔고, 시스템 개발이 완료된 후에 QA팀에 의해서 테스팅이 되는 것이 일반적이었다.

 여기서는 소프트웨어 개발중에 개발팀에 의해서 수행되는 단위 테스트와 통합테스트에도 비중을 두고, 테스트 자동화와 회귀 테스트(테스트 마다 지난번 테스트했던 내용을 포함하여 테스트 하여, 변경 사항이 기존 기능에 영향을 줬는지 여부를 검증함)를 중점적으로 다룬다.

테스팅 모델은 전통적은 Waterfall 방식을 확장한 V-Model을 기반으로 한다.

Process
1)       Testing Process (테스트 프로세스)
소프트웨어 개발 단계에서 부터의 단계별 테스팅 프로세스에 대해서 정의한다.
V-Model에 기초하여 Unit Test,Integration Test, System Test, User Acceptance Test 4단계로 나누어서 정의한다.

2)       Defect Management Process (결함 관리 프로세스)
테스트 결과 발견되는 결함에 대한 관리 프로세스를 정의한다.

Reference Architecture
1)      Unit Test Framework Reference Architecture
특히 단위 테스트의 경우 소프트웨어의 안쪽을 테스트 하기 때문에, 일반적인 테스팅 도구보다는 소프트웨어 컴포넌트에 따라 더 정밀한 테스팅 도구가 필요하다.
단위 테스트를 수행하는데 필요한 테스팅 프레임웍에 대해 정리한다

2)      Static Testing Reference Architecture
소프트웨어 테스팅 기법중에서, 소프트웨어의 동작 상태가 아니라 코드 검증을 통해서 결함을 찾아내는 방법을 Static Test라고 한다. 이 테스트에서는 코드의 Naming Convention이나 특정 패턴에 따른 잠재적인 결함 (메모리 누수, Null Pointer Exception)을 찾아낼 수 있다. 이 Static Test를 수행할 수 있는 도구에 대해서 설명한다.

3)      System Test Reference Architecture
테스팅 중에서 주로 성능과 비기능 (확장성, 가용성등)에 대한 테스팅 수행 도구에 대해서 설명한다.

Collaboration (협업)

협업 모듈은 팀이 프로젝트를 진행하는데 있어서 의사 소통과 공동 작업을 돕기 위한 몇가지 기법과 시스템에 대해서 소개한다.

Process
1)      Code Review
코드 리뷰는 실제로 코드를 검토하여 예측 되는 결함을 찾아내고 서로 개선 방향을 찾아내는 행위이다. 코드 리뷰의 방식은 여러가지가 있으나 비형식적인 코드리뷰라도 투자대비 소프트웨어 품질에 많은 효과를 줄 수 있기 때문에, 협업의 기법중의 하나로 소개한다. 

Reference Architecture

1)      Wiki Based Document Management Reference Architecture
ALM을 이용해 구축된 표준이나 프레임웍, 프로세스등 많은 내용들이 Architect 레벨에서 일반 개발자들에게 전달되어야 한다. 이런 지식을 전달하는 방법이 문서등 여러가지 방법이 있겠지만, 문서등은 여러 버전 관리나 변경 관리가 어렵고, 표현의 한계가 있다.
 Wiki의 경우 내용을 하나의 장소에서 계속 업데이트가 가능하고, 검색이 가능하며, TEXT와 이미지뿐만 아니라 멀티미디어 데이터를 넣을 수 있기 때문에 직관적인 정보 전달이 가능하다.
 또한 링크를 이용하여 정보간의 연관 관계를 정의할 수 있다.

MS-WORD등으로 만들어진 문서는 공유 폴더에서 사장되거나 또는 이쁘게 바인딩되어서 책장이라는 무덤속으로 사라질 수 있는데, Wiki를 이용하는 이유중의 하나는 꼭 필요한 문서만, 필요할때 사용할 수 있도록 하여, 프로젝트에서의 정보 공유를 가속화 하는데 그 목적이 있다.

2)      Communication with Forum Reference Architecture
Wiki의 경우 대부분 위의 조직에서 아래 조직으로의 하향성을 가진 단방향 커뮤니케이션이다. 이를 보안하기 위해서 Forum은 좋은 양방향 커뮤니케이션 도구로 사용될 수 있는데, Wiki를 통한 단방향 정보 전달의 Feedback으로 사용할 수 있다. 

이러한 협업 도구들은 전체 협업의 생산성을 높혀줄 수 있는 일부만을 권장하는 것이며 조직의 수준과 구조에 맞춰서 별도의 협업 프레임웍을 구축 하기를 권장한다

실용주의 ALM 의 구현

ALM을 프로젝트에 적용 하기 위해서는 아래와 같이 3가지 관점에서의 접근이 필요하다.


프로세스

ALM은 전체 소프트웨어 개발 프로세스를 커버하기 때문에, 각 모듈을 프로젝트에 적용되는 프로세스에 대한 정의가 필요하다.

Reference Architecture

프로세스를 실제로 시스템으로 구현하기 위해서, 어떤 형태의 시스템 아키텍쳐를 이용하여 프로세스를 현실화할 수 있는지에 대한 가이드를 제공한다.

조직

시스템과 프로세스를 가지고 프로젝트에 적용할때, 적용하는 주체의 역할과 책임에 대해서 정의한다. 

성공적인 ALM 구현 전략

간략하게 실용주의 ALM에 대해서 살펴보았다. 이 실용주의 ALM을 성공적으로 적용하기 위해서 몇 가지 전략이 필요한데, 다음과 같다.

1)      Liquid

전체 프로세스가 모난 부분이 없이 물 흐르듯이 하나의 프로세스로 연결되어야 한다.

프로세스가 넘어가는 단계가 매끄럽지 못하면 전체 개발 프로세스에 병목이 생기게 되고, 프로세스 흐름에 문제가 생긴다.

2)      Seamless

앞에서 소개한 실용주의 ALM의 모듈 구성을 보면 알겠지만, 상당히 많은 부분을 많은 기술로 커버하고 있다. 이러한 기술들이 유기적으로 결합되어 마치 하나의 통일된 프레임웍과 같은 형태를 취하여 사용자 입장에서 하나의 프레임웍을 쓰는 듯한 느낌을 줘서, 사용자 관점에서 올 수 있는 혼돈을 미연에 방지해야 한다.

3)      Process Oriented

ALM의 가장 중요한 요소는 프로세스이다. ALM은 소프트웨어 개발 프로세스를 시스템화 하는 것이기 때문에, 프로세스 자체가 중요하며 자칫 잘못하면 시스템 구현에 이끌려서 프로세스가 망가지는 경우가 있다.

4)      Step by Step

실용주의 ALM이 다른 ALM에 비해서 경량이고 현실적이라고는 하지만, 커버하는 영역이 상당히 넓다. 한번에 전체 개발 프로세스를 변경하는 것은 구성원들에게 큰 혼란을 초래할 수 있기 때문에, 난이도별로 단계적으로 적용하는 것을 권장한다.

5)      팀의 수준에 맞춰서

팀의 성숙도에 맞춰서 실용주의 ALM을 Customization해서 적용해야 한다. 성숙도가 낮은 팀에 실용주의 ALM을 적용할 경우, 마치 기존의 중량의 방법론을 적용할때와 마찬가지로 형식 지키기에만 급급해지고 실제 생산성은 오히려 더 떨어질 수 도 있다.

6)      Be Simple

모든 기능을 커버하려 하지 말고, 목표가 100일때 80만 커버하더라도 단순성을 우선시해야 한다. 복잡도가 높아질 수 록 실용주의 ALM 사용으로의 진입장벽과 Learning Curve가 급격하게 올라가고 이는 또 다른 형식적인 방법론으로 전락할 수 있다.