1. Kubernetes on GCP
Daegeun Kim (gnkr8@outlook.com)
Lezhin Entertainment
1
1편으로 생각해주세요. 40분안에 하기에는 주제가 너무컸습니다.
2. 발표자
✑ 레진엔터테인먼트 데이터 엔지니어
✑ Links
✑ https://geekdani.wordpress.com/
✑ dgkim84 @ twitter / fb
2
데이터 엔지니어, 분석가
안드로이드, iOS 앱 개발자
백엔드, 웹 프론트엔드 개발자
충원 중 입니다.
https://github.com/lezhin/apply/
blob/master/README.md
3. Google Cloud Platform
GCP에 더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군
3
https://cloud.google.com/icons/
우리 팀은 저 뿐인 팀이고 다 외주 직원들로 구성 얼굴 본 적은 없지만 그 분들
이 제품을 만들어줍니다.
로그 수집, 가공, 적재, 모델링, 분석 등을 할 수 있도록 지원해주고 있습니다.
BigData 제품군, Compute 제품군, 로깅, 네트워크, 스토리지 등 제품군을 활용
중 입니다.
BigTable 과 같은 제품들도 작지만 사용 중에 있습니다.
4. 왜
레진코믹스 데이터팀은
GCP 를 선택했나
4
https://www.slideshare.net/curioe_/lezhincomics-google-appengine-30453946
왜 레진코믹스는 구글앱엔진을 선택했나
5. 안정적이고 독립된
Data Infrastructure
- 2016년 4월 탈출
5
본업은 백엔드팀 이었고 업무 외에 작업이 진행된 것 이기때문에
손이 덜 가고 안정적으로 운영되도록 하는게 주 목표입니다.
그렇기때문에 오픈소스와 같은 제품을 직접 운영하는 것보다 fully managed 되
고 있는 GCP 제품군을 더 살펴보게 됩니다.
6. Google Cloud Platform
더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군.
6
수집 -> 가공 -> 적재 -> 모델링 -> 분석
수집 -> 가공 -> 적재 -> 모델링 -> 분석 등의 과정을 거치면서
마케팅, 빌링, 기획팀 등에서 SQL 등을 활용할 수 있도록 DWH 구축부터
BI 툴 연계를 통해 SQL을 다루지 못하는 분들도 시각화 할 수 있는 툴을 제공합
니다.
이 인프라로 한달에 대략 10억건 이상의 유의미한 로그가 쌓입니다.
배치 분석을 위해 스토리지로, 실시간 분석을 위해 Pub/Sub 등으로 보내집니다.
대부분의 ETL과 추천처리는 Spark 로 이루어지며 실시간 처리는 DataFlow
Streaming 쓰고 배치도 씁니다.
7. GCP 기능 외에
필요한 것
- 워크플로우 & 스케쥴러
- 추천(검색) 데이터 서빙용 어플리케이션 서버
- 서비스 특화된 지표용 백오피스
- 기타 수 많은 어플리케이션 서버
7
워크플로우 & 스케쥴러 : Airflow (Oozie, Azkaban, Luigi 와 같은) 제품으로
ETL 잡이나 이런 반복되는 작업을 DAG 형태로 관리하고 스케쥴링하는 역할
이와 같은 역할을 해주는 서버들이 있는데 관리를 효율적으로 하려고 할 때
고민하는 사항들이 있습니다.
8. Checklist
✑ Deployment
✑ Provisioning
✑ Automation
✑ Stateless, Stateful
✑ Scalability
✑ Monitoring
✑ Discovering Service
8
배포, 프로비저닝, 자동화 등이 그것이고
확장성이라던지 모니터링 그리고 Discovering Service 와 같은 문제들이 있습니
다.
이걸 개별로 구축하고 관리하는 비용은 어찌보면 굉장히 큽니다.
이번 발표에서는 자동화, Stateful 어플리케이션에대한 문제, 모니터링,
Discovering Service에대한 상세한 내용은 시간관계상 다루지 못합니다.
12. Pod
✑ 배포 최소 단위
✑ 하나 이상의 container (docker / rkt) 포함
✑ 함께 포함시켜야 할 것이 있다면 함께 선언
✑ Resources
✑ Volumes, Port, …
✑ CPU, Memory
✑ Request, Limit
✑ livenessProbe
✑ …
✑ Unique IP address
12
rkt (rock-it) 은 experimental
함께 포함시켜야할 것이 있을 때 함께 선언합니다.
기본적으로 container 기반이기때문에 OS나 dependency 문제는 쉽게 해결이 됩니다.
여기서 가장 중요한 것은 hello world 수준의 guide에선 언급이 안되지만
resource 관리가 중요하며, Pod은 Kubernetes에서 가장 작은 개념으로 알려져있지만
가장 다루기 어렵고 중요한 대상입니다. 삽질해보시면 알게됩니다.
진짜! 그렇기때문에 Kubernetes는 학습해야할 것이 적지 않습니다.
14. QoS
✑ Guaranteed
✑ Limits OR Limits = Requests
✑ Burstable
✑ Limits not set OR Requests != Limits
✑ Guaranteed and Best-Effort = Burstable
✑ Burstable and Best-Effort = Burstable
✑ Best-Effort
✑ Requests, Limits 모두 설정 안된 경우
✑ 이를 바탕으로 oom_score_adjust 결정
✑ 중요한 것이 먼저 kill 될 수 있으니 Resources 설정 중요.
14
Pod은 2개 이상의 container를 가질 수 있기때문에
Guaranteed 가 있더라도 Burstable 로 분류될 수 있습니
다.
15. Expose
✑ $ kubectl expose
✑ pod/airflow-web
✑ —namespace dev
✑ —port=8080
✑ —target-port=8080
✑ —type=LoadBalancer
✑ $ kubectl get service —namespace dev
✑ $ open http://EXTERNAL_IP:8080/
15
외부로 노출하기위해선 expose가 필요합니다.
—type 을 별도로 기록하지 않으면 ClusterIP가 생성됩니
다.
HTTP LoadBalancer는 Ingress Object Model 통해서 하
며 이 발표에서는 자세히 언급되지 않습니다.
22. Kubernetes Deployment
✑ Newer and Higher level concept (since 1.2)
✑ ReplicaSet, ReplicationController
✑ Pods, ReplicaSet 등 리소스를 생성하고 기존의 것을
바꾸는 등 일련의 작업을 명시합니다.
✑ Replica, Autoscaling
✑ Rolling Update, Rolling Back
✑ PodTemplate
22
Deployment 가 알아서 해주기때문에 Pod이나 ReplicaSet 등의 리소
스 생성에대해 크게 고민하실 필요는 없습니다.
기본적으로 명시하는 것들은 replica 랑 update strategy 정도이구요.
생성한 deployment 로 autoscale, rolling update, rollout 등을 수행
할 수 있습니다.
Deployment에도 생성할 Pod에대한 기본 Template을 명세합니다.
31. Scale
✑ $ kubectl scale —namespace dev
✑ —replicas=3 deploy/af-worker
✑ 현재 replica가 2개일 때만 적용하고 싶을 땐,
✑ $ kubectl scale —namespace dev
✑ —replicas=3 —current-replicas=2 deploy/af-worker
31
32. Horizontal Pod Autoscaling
since 1.2
✑ stable 버전에선 cpu만 지원
✑ $ kubectl autoscale
✑ deploy/af-worker
✑ —cpu-percent=60 —min=1 —max=4
✑ $ kubectl get hpa
✑ autoscaling/v2alpha1 에서 더 다양하게 제어 가능해집니다.
✑ memory, multiple custom metrics
32
34. Scalability
✑ Scale up/down
✑ Assigning Pods to Nodes
✑ Attach label to the node
✑ Add a nodeSelector field to Pod spec
34
35. Node Pool
✑ $ gcloud container node-pools create NAME
✑ —zone ZONE --cluster CLUSTER
✑ —machine-type n1-standard-4
✑ —num-nodes 3
35
36. Preemptible Node Pool
✑ $ gcloud beta container node-pools create NAME
✑ —zone ZONE --cluster CLUSTER
✑ —machine-type n1-standard-4
✑ —num-nodes 3
✑ —preemptible
✑ $ kubectl get nodes
✑ —selector='cloud.google.com/gke-preemptible'
✑ $ kubectl get nodes
✑ —selector='!cloud.google.com/gke-preemptible'
36
저렴한 가격으로 클러스터를 운영해봅시다.
근데 중요한 POD이 preemptible에 올라가면 어떻게
될까요…
Pod을 특정 노드에 할당되도록 알아봅시다.
37. Label
✑ 모든 resource에 label 추가/삭제 가능
✑ $ kubectl label node NODE_NAME
✑ —overwrite key=value
✑ Removing a label
✑ $ kubectl label node NODE_NAME key-
37
NodeSelector 를 언급하기 전에 각 리소스 (node, pod, …)에 Label을 달 수 있습니다.
39. Blue-Green Deployment /1
39
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
color: green || blue
app: af-web
name: af-web-green || af-web-blue
spec:
replicas: 1
template:
metadata:
labels:
color: green || blue
app: af-web
Deployment 를 두개를 배포합니다.
하나는 blue 또 다른 하나는 green 으로 합니다.
전체를 한번에 다른 버전으로 route
시켜보도록 하겠습니다.
40. Blue-Green Deployment /2
40
spec:
ports:
- nodePort: 32354
port: 8080
protocol: TCP
targetPort: 8080
selector:
color: green
app: af-web
type: LoadBalancer
apiVersion: v1
kind: Service
metadata:
labels:
run: af-web
name: af-web
Expose 하면 기본적으로 Service 하나 만들어집니다.
$ kubectl get services
$ kubectl edit service/<SERVICE_NAME>
한 다음 설정처럼 selector 값을 조정해서 새롭게 배포한 곳으로 가도록
할 수 있습니다.