6. 빠르게 변화하는 중국의
온/오프라인 커머스 환경에 따라 갈 수 있도록
클라우드상에서 운영되는
리눅스, MySQL 등 오픈 아키텍처을 활용하여
빠르고 기민한 시스템과 조직을 갖춘다.
2016년 미션
7. 1. 프로그램 개발은? 2. 인프라 운영은?
단순하지 않는 기능에 대한
설계 능력 부족(테이블 약 700개)
웹/모바일 개발 경험 부재
MS 기술에 강한 의존
Linux, MySQL 등 오픈 플랫폼에
대한 기술 부재
클라우드 운영 경험 없음
인프라 운영 경험도 없음
Mission Impossible!
10. 개발자 한명에 기능 하나
테이블은 1 or 2개, 화면 역시 1 or 2개
1 주일내에 무조건 동작하는 것 만들기
하드코딩 허용, HTML 날 코딩 허용
사용 기술은 개발자가 선택
일단 해 보자
11. 개발 언어는 메인은 Golang
웹/앱은 React
스토리지 MySQL, Mongo, Hadoop등
아키텍처는 Micro Service
실행환경은 Docker/K8S
인프라는 알리, 화웨이클라우드 사용
.NET
Window Form
SQLServer
Monolithic
Traditional IDC, Server
이것을 지속적으로 해보니
14. 요구사항
클라우드 기반 운영, Linux 사용
Kafka, ElasticSearch 등 다양한 기술
사용을 희망
현실은
Linux 등에 대한 기술적 지식 없음
다양한 오픈 소스에 대한 설치
운영 경험이 없음
인프라 운영 인력은 1명
Docker 만이 유일한
해결책
공개된 이미지 활용
프로그램으로 인프라를
구성하는 느낌
개발팀에서 일부 인프라
역할 수행 가능 (이미지
생성 등)
왜 Docker를 선택 했나?
15. 2016년 상반기 시작
복잡하고 크게 구성하기 보다는
1개월 내에 오픈하는 서비스를 지원하는 데만 집중
초기에는 5 ~ 10개 정도 서비스만 지원
Orchestration 도구 사용 하지 않음
결과로 2016년 광군제에 서비스 운영
이것도 일단 해보자!
16. Docker처음 접할 때 어려움
• Linux환경에 익숙하지 않음.
• Linux OS는 어떤걸 선택 ?
• 그냥 그나마 익숙한 Ubuntu Server 16.04 선택
• Linux명령어 ?
• 먼저 자주 사용되는 Linux명령어를 찾아보고 천천히 사용하면서 배움.
• Linux보안은 어떻게?
• 바이러스, 해커의 공격을 막기 위하여 필요 없는 포트는 닫고 클라우드 보안기능
사용.
• 다년간 windows기반으로 된 개발과 사용 습관
• Docker 장애가 발생하였을 때 처리 경험 부족
• Docker Container 지간의 복잡한 상호관계
• Docker Container 내부 상황을 모니터링
17. 현재 K8s 클러스터 현황
Eland China의 ITO 서비스 제공
- 알리 클라우드 내에 자체 k8s 구축
- Production: 212 Services, 462 Pods
- Staging/QA: 427 Services, 447 Pods
오프라인 커머스 사업자를 위한 SaaS
- 화웨이 클라우드 Managed k8s 서비스 사용
- Production: 161 Services, 304 Pods
- Staging/QA: 150 Services, 160 Pods
19. 초기 버전 문제점
• Docker Cluster관리의 어려움.
• Container간의 호출을 위하여 Host Network를 사용
• Jenkins배포가 점점 복잡하고 어려워 짐.
• Nginx는 두가지 용도로 구성
• 하나는 웹 프로젝트, 하나는 API 프로젝트
• Nginx Config File로 URL-Container Mapping을 관리
• 웹 기반 관리 화면이 없음
• 수작업 수정으로 인한 인위적인 리스크
• 서비스 규모가 커지면 관리가 어려움
• 마이크로 서비스의 가용성과 확장성을 보장할 수 없음.
• Host Network를 사용하기 때문에 같은 서비스 다른 Container는 다른
포트를 사용하여야 함.
20. k8s 사용으로 진화
srxcloud.com/pos
Browser
NGINX
: srxcloud.com
Consul Plugin
OfferAPI
Pod #1
Admin
NGINX
: gateway.srxcloud.com
Consul Plugin
PoS-API
Pod #1
gateway.srxcloud.com/pos-api
PoS-Web
Pod #1
Manually Manage
Manage Container
k8sConsul
URL-Container
Mapping
OfferAPI
Pod #2
k8s Service
offer-api.<namespace>: 8080
Manage Container
Fetch Mapping Data
k8s Service
pos-api.<namespace>: 8080
pos-web.<namespace>: 8080
21. 초기 k8s 구성 시 문제점
• Consul로 URL-Container Mapping을 관리
• 모니터링 화면을 제공
• 하지만 수동적인 관리
• Kong에 관하여 이해가 없었음
• Kong 존재를 알지 못했고
• Kong Ingress Controller는 아직 미 제공
• 0.1.0 released on 18 Aug 2018
22. URL Mapping 진화
srxcloud.com/pos
Browser
NGINX
: srxcloud.com
Custom Plugin
OfferAPI
Pod #1
Admin
NGINX
: gateway.srxcloud.com
Custom Plugin
PoS-API
Pod #1
gateway.srxcloud.com/pos-api
PoS-Web
Pod #1
Manage Container
k8s
OfferAPI
Pod #2
k8s Service
offer-api.<namespace>: 8080
Manage Container
Fetch k8s Services Info
pos-api.<namespace>: 8080
pos-web.<namespace>: 8080
k8s Service
23. 개발된 URL Mapping 문제점
• Load Balance가 없음
• 자체 구축한 Nginx Gateway 서비스의 운영문제
• K8s에서 Service정보 URL을 생성하는 플러그인의 개발과 운영.
• 비지니스 업무의 복잡도가 올라가면서 운영이 많이 힘들어 짐.
• URL의 다양한 형태를 지원하지 못함.
• 새로운 요구사항을 수용하기 어려움.
• 인증을 각각 서비스에서 자체로 함.
• 주문같은 모듈은 동시 요청수 제한 기능이 필요함.
• 외부협력사와 open-api 의 인증 문제.
24. Kong의 도입
srxcloud.com/pos
Browser
OfferAPI
Pod #1
Admin
PoS-API
Pod #1
gateway.srxcloud.com/pos-api
PoS-Web
Pod #1
Manage Container
K8s
OfferAPI
Pod #2
k8s Service
offer-api.<namespace>: 8080
Load balancer (Aliyun)
: srxcloud.com
Kong
Kong
Kong
Kong DB
Kong
Ingress
Controller
Get ingress config
pos-api.<namespace>: 8080
pos-web.<namespace>: 8080
k8s Service
25. 빌드 및 배포
Developer
Gitlab
QA Team
Jenkins k8s
Docker
Private Registry
Linux
<Docker>
<K8s Node>
Linux
<Docker>
<K8s Node>
1. PR and Merge
2. Ask deploying
3. Run deployment script
4. Pull source code &
build docker image
6. Request deploying
5. Push docker image
7. Deploy
8. Pull docker image
and run
26. 배포 시 주요 이슈
모든 프로젝트가 k8s 배포를 위해
yaml 파일 필요
CPU, Memory 등 운영
리소스는 필요 시 설정
가능해야 함
Golang 프로젝트 빌드 시 image가
너무 커짐
React, Java의 경우 사용하는
라이브러리가 많고 프로젝트마다
다름
배포용 yaml 생성 및 배포용
컨테이너를 실행하여 배포
Multi Stage Build 방식을 사용하여
최종 alpine 이미지 사용
Docker in Docker 빌드 방식 사용
27. Jenkins Script
Image 빌드
K8s 배포
Container 설정 변수
자체 구성한 k8배포용 이미지
(환경 변수 이용 k8s 배포 yaml 파일 생성,
kubectl 이용 k8s에 배포)
29. Docker in Docker Build
Deploy
Build Source Code
(Docker in Docker)
Build Docker Image
Library File Cache
30. Log Management
개발자의 인프라 자원 접근 제한
k8s 관리 웹 화면 접근 제한
운영 서버 및 운영 컨테이너
접근 제한
프로그램 버그 및 운영을 위해 Debug
로그 또는 예외 로그 조회 필요
각 컨테이너의 로그를
1분 Delayed로
Hadoop에 저장 후
Zeppelin에서
Presto Query로 조회
33. 문제 파악은 Mingbai 이용
Prometheus API 이용
문제 발생 가능성이 많은
컨테이너 위주로 정렬
해당 시간, 해당 컨테이너에서
처리한 Action에 대한 로그
또는 Query
34. 자체 개발 k8s 관리 도구
• 여러개의 K8s Cluster 관리
• K8s Services의 모니터링 및 경보
• Service 주기적 확인
• 이상 발견시(3~5회 이상) 위쳇을 통하여 경고메세지 전송
• Jenkins Job의 구성
• 이미 작성된 탬플릿으로 Job생성
• Ingress 관리할 수 있는 자체 개발 도구 사용
• YAML로 생성 또는 수정하는 Ingress프로세를 간편화
• 특정Ingress설정을 빨리 찾을수 있음
35.
36. k8s 구성 시 주의 사항(1)
• kubeadm 로 Cluster 생성(In China)
• Google또는 AWS서비스를 사용할 수 없음
• gcr.io에 접속할수 없음
• 대체가능한 리소스 또는 VPN을 사용하여야 함.
• 수동으로 Cluster 구성
• 구성시 Shell 스크립트를 유지보수하여야 함.
• Etcd, Flannel설정을 관리하여 주어야 함.
• Docker, Flannel, K8s버전이 서로 맞아야 함.
• Docker과 Flannel 버전이 맞지 않으면 여러 서버 지간에 네트워크 장애가 발생함.
• TLS을 수동으로 셋팅하여야 함.
37. k8s 구성 시 주의 사항(2)
• Persistent Volume과 Persistent Volume Claims의 사용
• 클라우드 저장소를 사용할수 없을 경우 NFS로 대체함.
• Namespace 기준 정의
• 처음 구성 시: 업무 / 부문 / Gitlab Group 으로 구분
• 표준이 없어서 혼란스러웠음(찾기어려움, 로그추적도 어려움)
• 수시로 새로운 Namespace 추가 (k8s관리도 어려워 짐)
• 사용자에게 우호적이지 않음.
• 최근 구성은: 서비스 단위로 관리
• 예: eland, srx-cloud 등
• Namespace 갯수가 적고 상대적으로 고정적임.
• 쉽게 자신의 프로젝트가 어디에 속하는지 알수 있음.
38. 중국 클라우드 k8s 서비스
• Master node 생성 Wizard(하나의 서버 또는 Cluster 선택)
• Worker node 추가 Wizard
• 쉬운 k8s Cluster 버전 업그레이드
• 엄격히 테스트가 끝난 k8s+docker 버전만 사용
• 서비스 통합관리
• Server, Store, Network, Security, Log, Monitoring 등
• 편리한 Web 관리 화면 제공
• 다중 백업 등
39. k8s Managed Service 비용
Master 3 Nodes (2Core, 4GB) / Worker 5 Nodes (4Core, 16GB)
구분 알리 클라우드 화웨이 클라우드 AWS
Master 6,915 /년 7,522 /년 $0.2/시간
12,000 /년
Worker 24,990 /년 25,992 /년 $0.25/시간 * 5대
74,000 /년
Total(CNY) 31,903 /년 33,514 /년 86,000 /년
Total(KRW) 약 540만원/년 약 570만원/년 약 1,400만원/년
m5.xlarge 기준 EC2 비용만 산정
41. 맺음말
2016년에 시작하여 2017년말에
모두 마이크로 서비스로 바뀌었고
이 작은 서비스들은
k8s 환경에서 운영되고 있다.
누군가 만들어 놓은 “1”을 이용하여
“100”으로 넓히는 성과를 낸 것이다.
아기발걸음을 걷듯 한걸음 내딛고
계속 진보해 나가는 것이 가장 중요