Open infradays 2019_msa_k8s

1. MSA, K8S를 이용한 대륙의 서비스 개발 사례 전통적인 서비스에서 마이크로 서비스로 변화과정 王志 (왕쯔강) 김형준 본 강의는 한국어, 중국어로 발표되며 중국어 발표 부분은 통역을 지원합니다

2. 빠르게 발전하고 있는 중국에 대한 이해 마이크로 서비스 아키텍처를 선택할 수 밖에 없었던 이유와 적용 현황 전통 기술의 조직이 k8s를 도입하고 적용해 왔던 과정 및 현재 현황

3. 클라우드 유통 ERP 서비스 북경의념과기발전 중국내 유통 사업자 (백화점, 브랜드 등) 매출 2조 광군제 일 매출 700억

4. 0 ➔ 1 만드는 것은 미국이 잘하지만 1 ➔ 100 확장하는 것은 중국이 가장 잘한다! 김민지, https://www.notion.so/fc6d218a8e884e6aa9580988f9b96cf2

5. 비즈니스 자체가 애자일! à 서비스 개발/운영도

6. 빠르게 변화하는 중국의 온/오프라인 커머스 환경에 따라 갈 수 있도록 클라우드상에서 운영되는 리눅스, MySQL 등 오픈 아키텍처을 활용하여 빠르고 기민한 시스템과 조직을 갖춘다. 2016년 미션

7. 1. 프로그램 개발은? 2. 인프라 운영은? 단순하지 않는 기능에 대한 설계 능력 부족(테이블 약 700개) 웹/모바일 개발 경험 부재 MS 기술에 강한 의존 Linux, MySQL 등 오픈 플랫폼에 대한 기술 부재 클라우드 운영 경험 없음 인프라 운영 경험도 없음 Mission Impossible!

8. 미션을 수행해야 할 팀원은?

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 이것을 지속적으로 해보니

12. 결국은 200개 이상의 마이크로서비스가 운영되는 환경 빌드, 배포, 운영은?

13. Windows에서 Kubernetes 전통적인 서비스에서 마이크로 서비스로 변화과정

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

18. 초기 버전: Docker로만 구성 srxcloud.com/pos Browser NGINX : srxcloud.com Config file Admin NGINX : gateway.srxcloud.com Config file gateway.srxcloud.com/pos-api <Host IP>:8081 <Host IP>:8080 Manually Manage URL-Container Mapping Manually Manage Container OfferAPI Container #1 PoS-API Container #1 PoS-Web Container #1 <Host IP>:8082 HOST 1 HOST 2 OfferAPI Container #2 <Host IP>:8083

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에 배포)

28. Build Golang Project pangpanglabs/golang:builder alpine:3.10 Config File Execute File Source Code go install COPY Multi-Stage Build

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로 조회

31. Zeppelin에서 로그 조회

32. K8s 모니터링 • 기본은 Prometheus + Grafana 조합으로 사용

33. 문제 파악은 Mingbai 이용 Prometheus API 이용 문제 발생 가능성이 많은 컨테이너 위주로 정렬 해당 시간, 해당 컨테이너에서 처리한 Action에 대한 로그 또는 Query

34. 자체 개발 k8s 관리 도구 • 여러개의 K8s Cluster 관리 • K8s Services의 모니터링 및 경보 • Service 주기적 확인 • 이상 발견시(3~5회 이상) 위쳇을 통하여 경고메세지 전송 • Jenkins Job의 구성 • 이미 작성된 탬플릿으로 Job생성 • Ingress 관리할 수 있는 자체 개발 도구 사용 • YAML로 생성 또는 수정하는 Ingress프로세를 간편화 • 특정Ingress설정을 빨리 찾을수 있음

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 비용만 산정

40. HUAWEI k8s Web Console

41. 맺음말 2016년에 시작하여 2017년말에 모두 마이크로 서비스로 바뀌었고 이 작은 서비스들은 k8s 환경에서 운영되고 있다. 누군가 만들어 놓은 “1”을 이용하여 “100”으로 넓히는 성과를 낸 것이다. 아기발걸음을 걷듯 한걸음 내딛고 계속 진보해 나가는 것이 가장 중요

Open infradays 2019_msa_k8s

Open infradays 2019_msa_k8s

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Open infradays 2019_msa_k8s

Similar to Open infradays 2019_msa_k8s(20)

More from Hyoungjun Kim

More from Hyoungjun Kim(6)

Open infradays 2019_msa_k8s