카카오 스토리는 한국의 대표적인 SNS 서비스이다. 카카오스토리에서 대용량, NoSQL, Devops, CI/CD 환경을 소개한다.

1. 김용환
#카카오스토리 #DevOps #Practical #CI/CD #NoSQL
카카오스토리의
DevOps 사례
1

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

3. 발표자 소개
 공부용으로 김용환 블로그(http://knight76.tistory.com) 작성
 하루에 2,000 View 이상
 NIPA 소프트웨어공학센터 기고
 대용량 캐시/형상 관리/오픈 소스 거버넌스/WEB,WAS 표준화
 업무 : 임베디드, 웹/백엔드 개발, 플랫폼 기획/개발, WEB/WAS튜닝, 생산성
혁신활동(SQE), 서비스 개발, 클라우드
 다녀본 회사
3

4. 발표자 소개 – 번역, 그림, 사진
 번역 출간 (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. 카카오 스토리 소개 5

6. 2017 소셜 미디어 이용 행태 및
광고 접촉 태도 분석 보고(2017.7)
출처 : http://www.itworld.co.kr/news/105506
6

7. 카카오 스토리 서버 개발 접근 방식
 기능(Function)
 데이터 모델링
 동작 구현/테스트
 Since(from/to)
 단순화
 트래픽(Traffic)
 캐시(Write Through/Write Back)
 용량(Capacity)
 샤딩(Sharding) 전략
 백업(Backup) 전략
• 지속적인 모니터링/로깅
• 고객 문의
• 마이그레이션(Migration)
• 양쪽 저장(Dual Write Functionality)
• 모델링
• NoSQL 성격에 맞게
• 생성일/변경일
• 반정규화(denormalization)
• 에러/성능/장애 튜닝
• Hotspotting
• 큰 장애가 오기 전에 신호가 옴. 미리 파악
해두는 것이 좋음(Cassandra/Hbase 사례)
평상시에 미리 공부를 하고 있어야 함
7

8. DevOps란?
 Dev과 Ops 조직이 하나로 구성
 일반적으로 명시된 역할 또는 직책의 범위를 넘어 서비스에 대한 완전한 주인의식을 갖음
 전체 개발과 인프라 수명 주기를 스스로의 책임으로 간주함
 빠른 속도로 서비스를 제공(Time To Market, 새로운 릴리즈의 더 낮은 실패율, 빠른 장애 복
구)
 조직의 역량을 향상시키는 문화, 철학, 도구의 조합
 반복적인 개선, 혁신
 효율적, 유지보수성이 높음 -> 속도,자동화(Automation) 강조
8

9. DevOps를 지탱하는 요소(발표자 관점)
 사람 : 능력이 있고 책임감을 갖고 있는 DevOps 개발자/
관리자(리더십)
 테스트/배포 환경 : 개발 산출물을 바로 빌드/ 배포할 수
있는 환경
 인프라 : 환경, 시스템, 지원 조직, 문화
사람
인프라
테스트 /
배포 환경
9

10. DevOps 툴 체인
계획
버전
콘트롤
빌드 테스트 배포 추적
• 자동화된 빌드 / 테스트 수행을 통해 지속적인 기능 추가, 품질
개선 시간이 단축
• 상용 환경 테스트 환경이 완료되면 언제든지 배포될 수 있는 배
포 환경
10

11. 카카오 스토리 서버 환경
 대용량 트래픽과 빅 데이터를 처리
 스토리지 : 다양한 NoSQL(zookeeper, redis, memcached, resque, elasticsearch,
mongodb, cassandra, hbase, hadoop, kafka),
MySQL DB
 언어 : Java/Spring(주요 언어), Scala/Spark, Python, Ruby, R
 DevOps 개발자 인원 : 1x명
 QA 엔지니어 인원 : 없음
11

12. 카카오 스토리 DevOps 환경
 API 서버
 배포 자동화 툴(로컬 배포 가능)
 빌드/테스트 환경
 로컬 / CI 서버
 지표 공유, 테스트, 배포, 모니터링 정보를 카카오톡으로 자동으로 받음
 업무 소통은 카카오톡으로 진행
 단위 및 회귀 테스팅 환경
12

13. 카카오 스토리 DevOps 버전 콘트롤 환경
 소스 관리
 저장소 : GitHub
 브랜치 정책 : Git Flow와 Github Flow의 중간 상태
 Merge를 최소화하고 간결화한 상태
 브랜치 : develop/master/feature만 사용
 로컬/알파 환경 : develop
 베타/상용 환경 : master
13

14. 카카오 스토리 DevOps 운영 환경
알파 상용베타
develop develop master master
14

15. 일반 회사의 DevOps 테스팅 환경
 개발하기 어려운 상황
 특정 사람에 의존적
 테스팅 환경(CI)의 부재
 로컬 테스트 환경이 없음
 잘 모르는 운영 환경에 대한 두려움
 코드 따로 문서 따로
 상상 코딩 / 상상 배포 / 배포했다가 롤백하는 정책
개발은 더 이상 리팩토링을 하지 못하고
더 이상 개선하지 못하고 지속적인 발전을 이룰 수 없음
15

16. 카카오 스토리 DevOps 테스팅 환경
 개발할 만한 환경
 테스팅 환경(CI)
 로컬 테스트 환경
 운영 환경을 미리 예상
 테스트 환경에서 충분한 테스트
 단위 테스트/회귀 테스트 코드는 DevOps가 직접 작성
 문서 업데이트 속도는 코드의 속도를 따라올 수 없어서 지금까지 정리된 문서와 코드를 각각 봐야하
는데, 테스트 코드는 문서화와 코드의 중간 가교 역할도 가능
Innovation!
16

17. 최신 테스팅 추세 –
Specification by Example
 리빙 도큐멘테이션은..
 리빙 도큐멘테이션은 이해하기 쉬워야 한다
 리빙 도큐멘테이션은 일관성이 있어야 한다
 접근하기 쉽게 구성해야 한다
 명세의 변경 없이 검증 자동화하기
 테스트는 좋은 문서가 될 수 있다
 명세는 설명이 필요 없을 만큼 자명해야 한다
 최근 미국에서는 회귀 테스트, 기능 테스트라는 단
어 대신 Specification by Example이라 표현
17

18. 로컬(PC) 테스트 환경
RSpec(based on Ruby)
카카오 스토리
서버 컴포넌트
18

19. RSpec
 Ruby 기반
 명세서는 자연어와 비슷하고 읽기 쉬어야 함
 명세서 기반의 BDD(Behaviour Driven
Development)
 Mocking 지원
 Open Stack( IaaS 형태의 클라우드 컴퓨팅 오
픈 소스 프로젝트)에서도 사용
19

20. 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

21. 리눅스 테스팅 클러스터 환경
Docker
RSpec(based on Ruby)
자동 배포 (Continuous Deployment)
카카오 스토리
서버 컴포넌트
21

22. 리눅스 테스팅 클러스터 환경
 웹과 앱 환경에 맞춰진 테스팅 환경 구성
 개발 환경/상용 환경은 다르게 구성
 다양한 git 브랜치 테스트 가능
 테스트 서버 확장성
 빠른 속도
22

23. 리눅스 테스팅 클러스터 자동화 환경
버전 콘트롤 저장소
소스 커밋
개발자
알림
빌드/
유닛 테스트
Continuous Integration
빌드/유닛 테스트
성공
빌드/유닛 테스트
실패
3,000+ 회귀 테스트
회귀 테스트 실패 서버(알파) 배포
10분
23

24. 회귀 테스트 최적화 방법
소스 변경시
젠킨스 실행
자바 소스 컴파일,
도커에 자바 빌드
산출물 복사
RSpec 테스트 RSpec 결과 수집
도커 이미지 생성과
컴포넌트 추가
도커 이미지를 도커
사설 저장소에 저장
젠킨스 서버에
도커 이미지 배포
젠킨스 테스트
도커 사설
저장소
워커 장비
버전 콘트롤
저장소
업로드 도커 이미지 배포
테스트 실행
소스 다운로드
테스트용 도커 이미지 생성
도커 다운로드
테스트 결과 얻음
24

25. 회귀 테스트 최적화 방법 - 아키텍처
#group1
1. 빌드/유닛 테스트 완료
젠킨스 회귀 테스트
Multi-job
젠킨스 플러그인
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
#group2
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
#group N
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
Worker-1-1
4. Job(도커 기반 RSpec) 실행
5. 각 Job의 부분 테스트 결과를 저장
서버(알파) 배포
6. 결과 집계
2. 플러그인 실행
테스트 장비
7. 성공하면
배포
3. 이전 테스트 정보를 기반으로
미리 분배된 Job 정보를 읽음
25

26. 감사합니다
26