김용환

#카카오스토리 #DevOps #Practical #CI/CD #NoSQL

카카오스토리의DevOps 사례

1

순서

발표자 소개카카오 스토리 소개DevOps란?카카오 스토리를 지탱하는 DevOps 환경카카오 스토리의 테스트/배포 환경

2

발표자 소개

공부용으로 김용환 블로그(http://knight76.tistory.com) 작성

하루에 2,000 View 이상

NIPA 소프트웨어공학센터 기고

대용량 캐시/형상 관리/오픈 소스 거버넌스/WEB,WAS 표준화

업무 : 임베디드, 웹/백엔드 개발, 플랫폼 기획/개발, WEB/WAS튜닝, 생산성혁신활동(SQE), 서비스 개발, 클라우드

다녀본 회사

3

발표자 소개 – 번역, 그림, 사진

번역 출간 (7권)

『Ansible 설정 관리』(2015),

『ElasticSearch Cookbook 2/e』(2016),

『Redis 핵심정리』(2016),

『일래스틱서치 입문과 활용』(2016),

『CentOS 7 리눅스 서버 쿡북』(2016),

『하이브 핵심정리』(2017),

『일래스틱서치 살펴보기』(2017.9 출간 예정)

번역 출간 예정 (5권)

High Performance Scala

Fast Data Processing Systems with SMACK Stack

Shell Programming in Unix, Linux and OS X

Learning Cassandra

Scala and Spark for Big Data Analytics

4

카카오 스토리 소개 5

2017 소셜 미디어 이용 행태 및광고 접촉 태도 분석 보고(2017.7)

출처 : http://www.itworld.co.kr/news/105506

6

카카오 스토리 서버 개발 접근 방식

기능(Function)

데이터 모델링

동작 구현/테스트

Since(from/to)

단순화

트래픽(Traffic)

캐시(Write Through/Write Back)

용량(Capacity)

샤딩(Sharding) 전략

백업(Backup) 전략

• 지속적인 모니터링/로깅

• 고객 문의

• 마이그레이션(Migration)• 양쪽 저장(Dual Write Functionality)

• 모델링• NoSQL 성격에 맞게• 생성일/변경일• 반정규화(denormalization)

• 에러/성능/장애 튜닝• Hotspotting• 큰 장애가 오기 전에 신호가 옴. 미리 파악해두는 것이 좋음(Cassandra/Hbase 사례)

평상시에 미리 공부를 하고 있어야 함

7

DevOps란?

Dev과 Ops 조직이 하나로 구성

일반적으로 명시된 역할 또는 직책의 범위를 넘어 서비스에 대한 완전한 주인의식을 갖음

전체 개발과 인프라 수명 주기를 스스로의 책임으로 간주함

빠른 속도로 서비스를 제공(Time To Market, 새로운 릴리즈의 더 낮은 실패율, 빠른 장애 복구)

조직의 역량을 향상시키는 문화, 철학, 도구의 조합

반복적인 개선, 혁신

효율적, 유지보수성이 높음 -> 속도,자동화(Automation) 강조

8

DevOps를 지탱하는 요소(발표자 관점)

사람 : 능력이 있고 책임감을 갖고 있는 DevOps 개발자/관리자(리더십)

테스트/배포 환경 : 개발 산출물을 바로 빌드/ 배포할 수있는 환경

인프라 : 환경, 시스템, 지원 조직, 문화

사람

인프라

테스트 /

배포환경

9

DevOps 툴 체인

계획버전

콘트롤빌드 테스트 배포 추적

• 자동화된 빌드 / 테스트 수행을 통해 지속적인 기능 추가, 품질개선 시간이 단축

• 상용 환경 테스트 환경이 완료되면 언제든지 배포될 수 있는 배포 환경

10

카카오 스토리 서버 환경

대용량 트래픽과 빅 데이터를 처리

스토리지 : 다양한 NoSQL(zookeeper, redis, memcached, resque, elasticsearch, mongodb, cassandra, hbase, hadoop, kafka), MySQL DB

언어 : Java/Spring(주요 언어), Scala/Spark, Python, Ruby, R

DevOps 개발자 인원 : 1x명

QA 엔지니어 인원 : 없음

11

카카오 스토리 DevOps 환경

API 서버

배포 자동화 툴(로컬 배포 가능)

빌드/테스트 환경

로컬 / CI 서버

지표 공유, 테스트, 배포, 모니터링 정보를 카카오톡으로 자동으로 받음

업무 소통은 카카오톡으로 진행

단위 및 회귀 테스팅 환경

12

카카오 스토리 DevOps 버전 콘트롤 환경

소스 관리

저장소 : GitHub

브랜치 정책 : Git Flow와 Github Flow의 중간 상태

Merge를 최소화하고 간결화한 상태

브랜치 : develop/master/feature만 사용

로컬/알파 환경 : develop

베타/상용 환경 : master

13

카카오 스토리 DevOps 운영 환경

알파 상용베타

develop develop master master

14

일반 회사의 DevOps 테스팅 환경

개발하기 어려운 상황

특정 사람에 의존적

테스팅 환경(CI)의 부재

로컬 테스트 환경이 없음

잘 모르는 운영 환경에 대한 두려움

코드 따로 문서 따로

상상 코딩 / 상상 배포 / 배포했다가 롤백하는 정책

개발은 더 이상 리팩토링을 하지 못하고더 이상 개선하지 못하고 지속적인 발전을 이룰 수 없음

15

카카오 스토리 DevOps 테스팅 환경

개발할 만한 환경

테스팅 환경(CI)

로컬 테스트 환경

운영 환경을 미리 예상

테스트 환경에서 충분한 테스트

단위 테스트/회귀 테스트 코드는 DevOps가 직접 작성

문서 업데이트 속도는 코드의 속도를 따라올 수 없어서 지금까지 정리된 문서와 코드를 각각 봐야하는데, 테스트 코드는 문서화와 코드의 중간 가교 역할도 가능

Innovation!

16

최신 테스팅 추세 –Specification by Example

리빙 도큐멘테이션은..

리빙 도큐멘테이션은 이해하기 쉬워야 한다

리빙 도큐멘테이션은 일관성이 있어야 한다

접근하기 쉽게 구성해야 한다

명세의 변경 없이 검증 자동화하기

테스트는 좋은 문서가 될 수 있다

명세는 설명이 필요 없을 만큼 자명해야 한다

최근 미국에서는 회귀 테스트, 기능 테스트라는 단어 대신 Specification by Example이라 표현

17

로컬(PC) 테스트 환경

RSpec(based on Ruby)

카카오 스토리서버 컴포넌트

18

RSpec

Ruby 기반

명세서는 자연어와 비슷하고 읽기 쉬어야 함

명세서 기반의 BDD(Behaviour Driven Development)

Mocking 지원

Open Stack( IaaS 형태의 클라우드 컴퓨팅오픈 소스 프로젝트)에서도 사용

19

RSpec 예제

it ’feed 테스트' do

user1.subscribe(”samuel”)

user2.subscribe(“alice”)

user1.make_friend(user2)

user1.post(“스토리 가입했다!”)

feed_result = user2.feed

expect(feed_result[0].content).to equal(“스토리 가입했다!”)

end

20

리눅스 테스팅 클러스터 환경

Docker

RSpec(based on Ruby)

자동 배포 (Continuous Deployment)

카카오 스토리서버 컴포넌트

21

리눅스 테스팅 클러스터 환경

웹과 앱 환경에 맞춰진 테스팅 환경 구성

개발 환경/상용 환경은 다르게 구성

다양한 git 브랜치 테스트 가능

테스트 서버 확장성

빠른 속도

22

리눅스 테스팅 클러스터 자동화 환경

버전 콘트롤 저장소

소스 커밋

개발자

알림빌드/유닛 테스트

Continuous Integration

빌드/유닛 테스트성공

빌드/유닛 테스트실패

3,000+ 회귀 테스트

회귀 테스트 실패 서버(알파) 배포

10분

23

회귀 테스트 최적화 방법

소스 변경시

젠킨스 실행

자바 소스 컴파일,

도커에 자바 빌드

산출물 복사

RSpec 테스트 RSpec 결과 수집

도커 이미지 생성과

컴포넌트 추가

도커 이미지를 도커

사설 저장소에 저장

젠킨스 서버에

도커 이미지 배포

젠킨스테스트

도커 사설저장소

워커 장비

버전 콘트롤저장소

업로드 도커 이미지 배포

테스트 실행

소스 다운로드

테스트용도커이미지생성

도커 다운로드

테스트 결과 얻음

24

회귀 테스트 최적화 방법 - 아키텍처

#group1

1. 빌드/유닛 테스트 완료

젠킨스 회귀 테스트

Multi-job 젠킨스 플러그인

Worker-1-1Worker-1-1

Worker-1-1Worker-1-1

Worker-1-1

#group2

Worker-1-1Worker-1-1

Worker-1-1Worker-1-1

Worker-1-1

#group N

Worker-1-1Worker-1-1

Worker-1-1Worker-1-1

Worker-1-1

4. Job(도커 기반 RSpec) 실행

5. 각 Job의 부분 테스트 결과를 저장서버(알파) 배포

6. 결과 집계

2. 플러그인 실행

테스트 장비

7. 성공하면배포

3. 이전 테스트 정보를 기반으로미리 분배된 Job 정보를 읽음

25

감사합니다

26