SlideShare a Scribd company logo
1 of 72
Download to read offline
Ops
Dev
QA
DevOps시대가
요구하는 QA (SW Testing)
- 2 -
DevOps란? (AWS 사이트 참조)
애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는
문화 철학, 방식 및 도구의 조합입니다.
이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로
경쟁할 수 있습니다.
- 3 -
DevOps가 나온 시대적 배경 (모바일 시대 이전)
- 4 -
DevOps가 나온 시대적 배경
(모바일 이후 - 사용자가 많다고 매출이 좋은 시대는 안녕..)
- 5 -
Part 1.
Cloud & DevOps
- 6 -
사용자가 많아도 수익이 별로라면..
저렇게 많은 사용자를 어떻게 견디지??
값 비싼 하드웨어 장비, 오라클.. 을 살수 없는데..
고객이 한국에만 있나? 중국, 미국, 전 세계에 있다면..
대신 저렴하며 비슷한 효과를 낼 만한 것은?
클라우드 서버를 늘려가면서. (Scale Out) + 오픈소스 솔루션으로..
- 7 -
Scale Up 보다는 Scale Out 으로..
비용이 더싸요.
- 8 -
왜 DevOps가 필요해 졌나. (클라우드..)
상대적으로 낮은 사양의 수 많은 서버들을 관리
다양한 리전에 배포 하는 기술이 필요
- 9 -
DevOps가 가져오는 의미 – 업무 간에 경계가 모호해 진다.
- 10 -
그래서 복잡한 DevOps 단계별 다양한 툴들..
- 11 -
DevOps 엔진니어의 RoadMap
(https://github.com/kamranahmedse/developer-roadmap)
- 12 -
DevOps 엔진니어의 RoadMap
(https://github.com/kamranahmedse/developer-roadmap)
- 13 -
DevOps엔지니어 의 RoadMap
(https://github.com/kamranahmedse/developer-roadmap)
- 14 -
DevOps의 모범사례
/
C
16분
- 15 -
DevOps의 모범사례 – NETFLIX 사례 (2017년 기준)
• NEBULA - NETFLIX 빌드를 빠르고, 쉽게 테스트하기 위한 Gradle 플러그인들의 집합체들
• BAKE – Aminator 를 사용함 (커스텀 AMI 를 생성하기위한 툴을 사용)
불변 인프라 (Immutable Infrastructure / server) 를 구성함 (AMI : Amazon Machine Image ) 즉 이미지 형태로 구성되어 배포
• Deployment – Spinnaker 를 사용하여 배포 / 멀티 클라우드를 지원하는 Continuous Delivery Platform으로 오픈소스 하여 제공
Amazon, Azure, GCE, Kubernetes , OpenStack 과 같은 오픈소스 기반의 클라우드 또는 컨테이너 플랫폼을 동시에 지원하여 배포 가능함.
또한 파이프라인을 통해 Smoke Test후 성공 하면 배포, 낮에는 업무를 봐야하니 Nightly Build등이 가능한 상황
• Canary - 전체 다 배포하지 않고, 일부 AMI만 배포를 해서 기존 것과 어떠한 성능 / 안정성 비교 평가 후 점진적 배포 , 아니면 롤백
• Live – 라이브 배포
- 16 -
DevOps의 모범사례 – CI 사례
- 17 -
DevOps의 모범사례 – Bake 사례
Aminator (Amazon AMI Creator)
- 18 -
Bake 단계 – 불변 인프라 (Immutable Server – PhoenixServer)
Code가아닌 Image(VM,Docker)를배포함으로써, 버전관리 Diff를체크해버전별패치하는것으로부터 자유로워짐.
- 19 -
불변 인프라 (이미지 배포)의
장점 과 케이스 스터디
• 낮은 배포 실패 확률
• 프로세스 다운 타임 없는 레드-블랙 배포와 릴리즈
• 원자성 (배포 되거나 롤백되거나.)
• 일관된 STG 환경과 쉬운 Scale Out
• 모든 서버가 동일한 생성 프로세스 사용 (특이
배포케이스가 없다)
• Seamless 하게 서버를 추가하여 Scale Out이 매우 용이
• 간단한 롤백과 복구 프로세스
• 이미지 이력을 보관하여 사용
• 적용 사례 (Netflix 외..)
• CodeShip - https://blog.codeship.com/immutable-
infrastructure/
• Chef - https://blog.chef.io/2014/06/23/immutable-
infrastructure-practical-or-not/
• Koddi - https://www.koddi.com/developing-with-an-
immutable-infrastructure/
• Fugue -
https://www.fugue.co/assets/docs/Immutable_Infrastructure
_Fugue.pdf
• 참조 - https://www.digitalocean.com/community/tutorials/what-
is-immutable-infrastructure
- 20 -
DevOps의 모범사례 – Deployment 사례
- 21 -
DevOps의 모범사례 – Deployment 사례 (ONYCOM - imqa 사례)
- 22 -
DevOps의 모범사례 – QA 확보 방안 (API Lifecycle Management + Test)
API Lifecycle Mgmt Testing
+
- 23 -
API 시대 – 죽지 않는 여러 기법들 도입 (참조 – axway 제품)
API Builder
Testing
Testing
- 24 -
API 시대 – Netflix는 API Gateway 관련 기술을 다 내재화 시킴
- 25 -
API Testing – 이 부분에 대해서는 내부 공개된 데이터가 없음
- 26 -
DevOps의 모범사례 – Netflix가 보는 Test의 흐름
- 27 -
DevOps의 모범사례 – Branch(Test/Release/Prod) 별로 따로 관리
- 28 -
DevOps의 모범사례 – Unit / Func Test를 Test 브랜치에서 실행
- 29 -
DevOps의 모범사례 – 성공하면 Release Branch에서 테스트
- 30 -
DevOps의 모범사례 – NETFLIX API Testing 을 Jenkins로 구축
- 31 -
DevOps의 모범사례 – 또 성공하면 Canary를 날리자
- 32 -
DevOps의 모범사례 – Baseline과 Canary에 대한 성능 비교
(기준치 도달 못하면 롤백 )
- 33 -
Canary시 – 글로벌하게 테스트를 실행함.
- 34 -
점진적 배포 – Red / Black Push
1. Baseline Amazon Instance가 배포/작동중인 경우
2. Baseline AMI 의 10% 정도만 다음 버전 AMI Live 생성후 배포.
새로운 버전의 안정성 체크.
안정화 검증되면 새 버전 인스턴스 100대 만들기
3. 기존 버전 (Baseline AMI) 정지 시킴 Black,
그러니 새 버전만 작동 RED .
이 상황이 RED/Black
4. 구 버전 AMI 내려버림
새로운 버전의 AMI만 남게함
API ASG
v1
AMI 123
API ASG
v1
AMI 123
API ASG
v2
AMI 456
API ASG
v1
AMI 123
API ASG
v2
AMI 456
API ASG
v2
AMI 456
- 35 -
문제 없으면 - Global Release
- 36 -
API Testing에 대해서 다시 생각해 보기
- 37 -
API Testing 단계별로 다시보기
API 테스트 & 시나리오 구성
HTTP Request 후킹으로
테스트 케이스 자동 생성
부하 테스트 성능 레포트
Swagger에서
API Import
원하는 환경에서
언제든 쉽게 테스트
- 38 -
API Testing 단계별 예 (기본 컨셉)
- 39 -
API Testing 단계별 예 (swagger , jmeter , checkpoint 서버 배포)
- 40 -
Global API Testing 시장 과연 얼마나 커지길래
글로벌 API testing 시장은
- API Testing SW 시장규모 2017년 3500억원 -> 2022년 8300억원 (19.16% 성장)
- API Testing Service 시장규모 2017년 1600억원 -> 2022년 4100억원 (20.81% 성장)
=> 2022년까지 크게 성장하는 추세
2017 API Testing Market 분석
- 41 -
아시아 지역 API 테스트 시장 상황의 성장세가 가장크다.
아시아 시장은 크게 성장 중이지만, 아직 Key Player가 없음
국내에서 사용하기에 해외 서비스를 이용하는 불편함이 있음
=> 시장 빈틈 및 진입 가능성에 주목
- 42 -
한국의 API Testing 시장은 왜 이렇게 성장하지 못했나.
첫 번째 이유.. 웹앱 시장
- 43 -
한국의 API Testing 시장은 왜 이렇게 성장하지 못했나.
두 번째 이유.. 클라우드 시장 의 낮은 성장율.
- 44 -
주요 고객 성장세
출처 : 연간 기업 Report, 언론 공개 자료, 투자자 발표 자료, 주요 인터뷰를 통한 분석
- 45 -
Part 2.
Mobile & DevOps
- 46 -
모바일 에서는 왜 DevOps가 필요해 졌나. (모바일)
파편화된 모바일 환경에서 어떻게 품질을 확보 해야지? (노트2의 점유율)
- 47 -
모바일 에서는 왜 DevOps가 필요해 졌나. (모바일)
Xiaomi 폰의 국내 점유율 4위
- 48 -
모바일 DevOps 흐름도
- 49 -
CashSlide 사례 - 모바일 DevOps 흐름도 (BITRISE 사용 사례)
관련 자료 - https://academy.realm.io/kr/posts/continuous-delivery-for-android/
- 50 -
모바일 DevOps 현재 흐름도
Commit Building Testing Release
Crash
Report
- 51 -
모바일 DevOps 제안 흐름도
Commit Building
Test Auto
Perf Report
Release
Crash
Report
Monitoring
- 52 -
더 나은 품질 확보를 위하여.
기존의 모바일 서비스는 출시 전 QA(Quality Assurance)를 통해 개발 관점에서의 사용자 만족도를 높여 왔습니다. 하지만 모바일 서비스의 각 사용자 별 환경에
따른 성능에 대해서는 현재까지도 스토어의 별점 등을 통해 피드백만 받아 온것이 현실입니다. 여기서 중요한 것은 성능의 문제점을 겪은 고객은 점점 해당
서비스의 이탈로 이어진다는 것입니다.
VS.
- 53 -
모니터링 개요
IMQA는 모바일 환경의 필터 기반 다계층 분석 방식이 적용된 모바일 성능 모니터링 솔루션 (MPM, Mobile Performance Monitoring)입니다. 출시 전 QA(Quality
Assurance)를 통해 기능 오류를 점검하는 방식과는 다르게 각 사용자의 모바일 환경에서의 성능을 지표화하여 궁극적으로는 귀사의 모바일 서비스의 성능을
향상시켜 줍니다.
- 54 -
IMQA 차별점
현재, 시장의 MPM은 Goolge의 ‘Firebase’나 New Relic 등 해외 제품이 전부이며 이상징후 (Crash)가 발생되는 시점에서만 성능을 모니터링해 줍니다. 이는
문제가 발생이 되어야만 성능 이슈를 모니터링해주는 것으로 ‘소잃고 외양간 고치는 형태’와 같습니다. 이에 반해 IMQA는 실시간 성능 모니터링이 가능하기
때문에 고객의 성능에 대한 불만족이 발생하기 전에도 이를 관리하고 예방할 수 있습니다.
IMQA는 Crash(이상징후) 발생 시점의 성능 문제의 원인을 규명하는 방식이 아닌, 실시간 성능 정보를 모니터링하는 방식입니
다.
실시간 성능 모니터링Crash 발생 시점 성능 모니터링 (실시간 X)
- 55 -
IMQA 차별점
이상징후(Crash) 분석 기반의 모바일 성능 모니터링 (MPM, Mobile Performance Monitoring)으로 대표되는 제품은 전부 외산 솔루션입니다. 각 기업의 욕구에
맞는 솔루션은 다양하게 출시되어 있지만, 설치 및 교육, 현지화(언어 등), 업데이트 및 유지보수 등 외산 제품의 도입에 따른 불편함 또한 다양하게 존재합니다.
이상징후(Crash)만 검출한다고 다 MPM (모바일 성능 모니터링, Mobile Performance Monitoring)이 아닙니다.
- 56 -
실 사례로 보는 모바일 성능 확보 방안
- 57 -
데이터를 수집하는 방법
- 58 -
주요 수집 데이터
• RL O B C B
• ( / N )
• /
• /
• B A A
• PI M
• BB A
• F
- 59 -
어떻게 수집하나?
• ): B + : @ : / :
• -. .A CC : / / B / / C/
A A CC : (
운영 대시보드
성능 대시보드
앱의 성능 기준
• C
PU
U
sage
• M
EM
O
R
Y
U
sage
N
etw
ork
U
sage
U
R
L
설
명
U
I R
endering
U
I R
endering
설명 – 화면이 뜨고 나서 시간 순서대로 스택정보 나열
14ms : 화면이 뜰때 초기하는 작업들이 너무 많음
236ms : 현 순간에도 화면 레이아웃을 구성하고 있는 중
1397ms : 화면의 프레임이 다 그려지지 않아 UI Thread에서 대기 하는 상황
문제 상황
A사 SDK HealthData에서 데이터를 받아오느라 화면 전체(UI Thread) 가 멈추는 상황이 발생함.
항상 로컬에 이전 데이터를 저장해서 먼저 보여주고, 사용자가 클릭시 정보를 가져오는 것으로 하는 것이 좋음
즉 인터넷이 연결되지 않아도 이전 데이터를 볼수 있도록 먼저 가이드라인을 잡기를 권고함.
고려 상황
화면 점유시간 3초 이상
화면을 다시 그리는 (Resume) 하는 상황에서, 화면 단에서 FileIO가 발생함
리소스 폰트를 가져오는 상황에서 지연이 발생되는 것으로 판단됨.
나라 / 지역별 UI 속도 / 응답시간 체크
- 72 -
감사합니다.
Thank you for your interesting.
- 자세한 문의는 아래로 주세요
어니컴 주식회사 | 서울시 중구 세종대로 21길 22, 태성빌딩 4층 | TEL : 02-541-0080
손영수 상무 (총괄)
ysson@onycom.com

More Related Content

What's hot

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 

What's hot (20)

오픈스택 기반 클라우드 서비스 구축 방안 및 사례
오픈스택 기반 클라우드 서비스 구축 방안 및 사례오픈스택 기반 클라우드 서비스 구축 방안 및 사례
오픈스택 기반 클라우드 서비스 구축 방안 및 사례
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) 마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
 
DevOps!! 도데체 왜, 어떻게 할까??
DevOps!! 도데체 왜, 어떻게 할까??DevOps!! 도데체 왜, 어떻게 할까??
DevOps!! 도데체 왜, 어떻게 할까??
 
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
MSA 전략 2: 마이크로서비스, 어떻게 구현할 것인가?
 
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
[오픈소스컨설팅]쿠버네티스를 활용한 개발환경 구축
 
클라우드 네이티브 전환 요소 및 성공적인 쿠버네티스 도입 전략
클라우드 네이티브 전환 요소 및 성공적인 쿠버네티스 도입 전략클라우드 네이티브 전환 요소 및 성공적인 쿠버네티스 도입 전략
클라우드 네이티브 전환 요소 및 성공적인 쿠버네티스 도입 전략
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)
 
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
대용량 분산 아키텍쳐 설계 #1 아키텍쳐 설계 방법론
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
DevOps 101
DevOps 101DevOps 101
DevOps 101
 
OKKY Jobs Guideline v.2.5
OKKY Jobs Guideline v.2.5OKKY Jobs Guideline v.2.5
OKKY Jobs Guideline v.2.5
 
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교  및 구축 방법
[오픈소스컨설팅] 쿠버네티스와 쿠버네티스 on 오픈스택 비교 및 구축 방법
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
 
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 SeoulElastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul
Elastic Stack 을 이용한 게임 서비스 통합 로깅 플랫폼 - elastic{on} 2019 Seoul
 
[2018] 고객 사례를 통해 본 클라우드 전환 전략
[2018] 고객 사례를 통해 본 클라우드 전환 전략[2018] 고객 사례를 통해 본 클라우드 전환 전략
[2018] 고객 사례를 통해 본 클라우드 전환 전략
 
[오픈소스컨설팅]Scouter 설치 및 사용가이드(JBoss)
[오픈소스컨설팅]Scouter 설치 및 사용가이드(JBoss)[오픈소스컨설팅]Scouter 설치 및 사용가이드(JBoss)
[오픈소스컨설팅]Scouter 설치 및 사용가이드(JBoss)
 
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
왜 쿠버네티스는 systemd로 cgroup을 관리하려고 할까요
 
컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점컨테이너 기술과 가상화 기술의 주요한 차이점
컨테이너 기술과 가상화 기술의 주요한 차이점
 
API Gateway를 이용한 토큰 기반 인증 아키텍처
API Gateway를 이용한 토큰 기반 인증 아키텍처API Gateway를 이용한 토큰 기반 인증 아키텍처
API Gateway를 이용한 토큰 기반 인증 아키텍처
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기
 

Similar to DevOps 시대가 요구하는 품질확보 방법

Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.dist
Jongin Oh
 
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
Amazon Web Services Korea
 
Open standard open cloud engine (3)
Open standard open cloud engine (3)Open standard open cloud engine (3)
Open standard open cloud engine (3)
uEngine Solutions
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
Amazon Web Services Korea
 

Similar to DevOps 시대가 요구하는 품질확보 방법 (20)

DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
 
모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415
 
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...
All about Data Center Migration Session 1. <Case Study> 오비맥주 사례로 알아보는 DC 마이그레...
 
Cloud-Barista 제2차 오픈 컨퍼런스 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(Multi-Cloud Se...
Cloud-Barista 제2차 오픈 컨퍼런스 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(Multi-Cloud Se...Cloud-Barista 제2차 오픈 컨퍼런스 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(Multi-Cloud Se...
Cloud-Barista 제2차 오픈 컨퍼런스 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(Multi-Cloud Se...
 
Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...
Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...
Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...
 
ALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOps
 
꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가
 
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
Cloud-Barista 제2차 오픈 컨퍼런스 : Cloud-Barista 기술 및 커뮤니티 소개(Multi-Cloud Service Co...
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos
 
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
[2017 AWS Startup Day] 서버리스 마이크로서비스로 일당백 개발조직 만들기
 
Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.dist
 
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
 
AWS Code 서비스 특집 - 아마존 DevOps와 CodeDeploy, CodePipeline (윤석찬)
AWS Code 서비스 특집 - 아마존 DevOps와 CodeDeploy, CodePipeline (윤석찬)AWS Code 서비스 특집 - 아마존 DevOps와 CodeDeploy, CodePipeline (윤석찬)
AWS Code 서비스 특집 - 아마존 DevOps와 CodeDeploy, CodePipeline (윤석찬)
 
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
전자 상거래 기업을 위한 클라우드 성공 전략 - AWS Summit Seoul 2017
 
무정지&무점검 서버 개발과 운영 사례
무정지&무점검 서버 개발과 운영 사례무정지&무점검 서버 개발과 운영 사례
무정지&무점검 서버 개발과 운영 사례
 
designing, implementing and delivering microservices with event storming, spr...
designing, implementing and delivering microservices with event storming, spr...designing, implementing and delivering microservices with event storming, spr...
designing, implementing and delivering microservices with event storming, spr...
 
Open standard open cloud engine (3)
Open standard open cloud engine (3)Open standard open cloud engine (3)
Open standard open cloud engine (3)
 
Red Hat Ansible 적용 사례
Red Hat Ansible 적용 사례Red Hat Ansible 적용 사례
Red Hat Ansible 적용 사례
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
 
Openshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud NativeOpenshift 활용을 위한 Application의 준비, Cloud Native
Openshift 활용을 위한 Application의 준비, Cloud Native
 

More from YoungSu Son

More from YoungSu Son (20)

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
SW 아키텍처 분석방법
SW 아키텍처 분석방법 SW 아키텍처 분석방법
SW 아키텍처 분석방법
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
 
[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신
 

DevOps 시대가 요구하는 품질확보 방법

  • 2. - 2 - DevOps란? (AWS 사이트 참조) 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있습니다.
  • 3. - 3 - DevOps가 나온 시대적 배경 (모바일 시대 이전)
  • 4. - 4 - DevOps가 나온 시대적 배경 (모바일 이후 - 사용자가 많다고 매출이 좋은 시대는 안녕..)
  • 5. - 5 - Part 1. Cloud & DevOps
  • 6. - 6 - 사용자가 많아도 수익이 별로라면.. 저렇게 많은 사용자를 어떻게 견디지?? 값 비싼 하드웨어 장비, 오라클.. 을 살수 없는데.. 고객이 한국에만 있나? 중국, 미국, 전 세계에 있다면.. 대신 저렴하며 비슷한 효과를 낼 만한 것은? 클라우드 서버를 늘려가면서. (Scale Out) + 오픈소스 솔루션으로..
  • 7. - 7 - Scale Up 보다는 Scale Out 으로.. 비용이 더싸요.
  • 8. - 8 - 왜 DevOps가 필요해 졌나. (클라우드..) 상대적으로 낮은 사양의 수 많은 서버들을 관리 다양한 리전에 배포 하는 기술이 필요
  • 9. - 9 - DevOps가 가져오는 의미 – 업무 간에 경계가 모호해 진다.
  • 10. - 10 - 그래서 복잡한 DevOps 단계별 다양한 툴들..
  • 11. - 11 - DevOps 엔진니어의 RoadMap (https://github.com/kamranahmedse/developer-roadmap)
  • 12. - 12 - DevOps 엔진니어의 RoadMap (https://github.com/kamranahmedse/developer-roadmap)
  • 13. - 13 - DevOps엔지니어 의 RoadMap (https://github.com/kamranahmedse/developer-roadmap)
  • 14. - 14 - DevOps의 모범사례 / C 16분
  • 15. - 15 - DevOps의 모범사례 – NETFLIX 사례 (2017년 기준) • NEBULA - NETFLIX 빌드를 빠르고, 쉽게 테스트하기 위한 Gradle 플러그인들의 집합체들 • BAKE – Aminator 를 사용함 (커스텀 AMI 를 생성하기위한 툴을 사용) 불변 인프라 (Immutable Infrastructure / server) 를 구성함 (AMI : Amazon Machine Image ) 즉 이미지 형태로 구성되어 배포 • Deployment – Spinnaker 를 사용하여 배포 / 멀티 클라우드를 지원하는 Continuous Delivery Platform으로 오픈소스 하여 제공 Amazon, Azure, GCE, Kubernetes , OpenStack 과 같은 오픈소스 기반의 클라우드 또는 컨테이너 플랫폼을 동시에 지원하여 배포 가능함. 또한 파이프라인을 통해 Smoke Test후 성공 하면 배포, 낮에는 업무를 봐야하니 Nightly Build등이 가능한 상황 • Canary - 전체 다 배포하지 않고, 일부 AMI만 배포를 해서 기존 것과 어떠한 성능 / 안정성 비교 평가 후 점진적 배포 , 아니면 롤백 • Live – 라이브 배포
  • 16. - 16 - DevOps의 모범사례 – CI 사례
  • 17. - 17 - DevOps의 모범사례 – Bake 사례 Aminator (Amazon AMI Creator)
  • 18. - 18 - Bake 단계 – 불변 인프라 (Immutable Server – PhoenixServer) Code가아닌 Image(VM,Docker)를배포함으로써, 버전관리 Diff를체크해버전별패치하는것으로부터 자유로워짐.
  • 19. - 19 - 불변 인프라 (이미지 배포)의 장점 과 케이스 스터디 • 낮은 배포 실패 확률 • 프로세스 다운 타임 없는 레드-블랙 배포와 릴리즈 • 원자성 (배포 되거나 롤백되거나.) • 일관된 STG 환경과 쉬운 Scale Out • 모든 서버가 동일한 생성 프로세스 사용 (특이 배포케이스가 없다) • Seamless 하게 서버를 추가하여 Scale Out이 매우 용이 • 간단한 롤백과 복구 프로세스 • 이미지 이력을 보관하여 사용 • 적용 사례 (Netflix 외..) • CodeShip - https://blog.codeship.com/immutable- infrastructure/ • Chef - https://blog.chef.io/2014/06/23/immutable- infrastructure-practical-or-not/ • Koddi - https://www.koddi.com/developing-with-an- immutable-infrastructure/ • Fugue - https://www.fugue.co/assets/docs/Immutable_Infrastructure _Fugue.pdf • 참조 - https://www.digitalocean.com/community/tutorials/what- is-immutable-infrastructure
  • 20. - 20 - DevOps의 모범사례 – Deployment 사례
  • 21. - 21 - DevOps의 모범사례 – Deployment 사례 (ONYCOM - imqa 사례)
  • 22. - 22 - DevOps의 모범사례 – QA 확보 방안 (API Lifecycle Management + Test) API Lifecycle Mgmt Testing +
  • 23. - 23 - API 시대 – 죽지 않는 여러 기법들 도입 (참조 – axway 제품) API Builder Testing Testing
  • 24. - 24 - API 시대 – Netflix는 API Gateway 관련 기술을 다 내재화 시킴
  • 25. - 25 - API Testing – 이 부분에 대해서는 내부 공개된 데이터가 없음
  • 26. - 26 - DevOps의 모범사례 – Netflix가 보는 Test의 흐름
  • 27. - 27 - DevOps의 모범사례 – Branch(Test/Release/Prod) 별로 따로 관리
  • 28. - 28 - DevOps의 모범사례 – Unit / Func Test를 Test 브랜치에서 실행
  • 29. - 29 - DevOps의 모범사례 – 성공하면 Release Branch에서 테스트
  • 30. - 30 - DevOps의 모범사례 – NETFLIX API Testing 을 Jenkins로 구축
  • 31. - 31 - DevOps의 모범사례 – 또 성공하면 Canary를 날리자
  • 32. - 32 - DevOps의 모범사례 – Baseline과 Canary에 대한 성능 비교 (기준치 도달 못하면 롤백 )
  • 33. - 33 - Canary시 – 글로벌하게 테스트를 실행함.
  • 34. - 34 - 점진적 배포 – Red / Black Push 1. Baseline Amazon Instance가 배포/작동중인 경우 2. Baseline AMI 의 10% 정도만 다음 버전 AMI Live 생성후 배포. 새로운 버전의 안정성 체크. 안정화 검증되면 새 버전 인스턴스 100대 만들기 3. 기존 버전 (Baseline AMI) 정지 시킴 Black, 그러니 새 버전만 작동 RED . 이 상황이 RED/Black 4. 구 버전 AMI 내려버림 새로운 버전의 AMI만 남게함 API ASG v1 AMI 123 API ASG v1 AMI 123 API ASG v2 AMI 456 API ASG v1 AMI 123 API ASG v2 AMI 456 API ASG v2 AMI 456
  • 35. - 35 - 문제 없으면 - Global Release
  • 36. - 36 - API Testing에 대해서 다시 생각해 보기
  • 37. - 37 - API Testing 단계별로 다시보기 API 테스트 & 시나리오 구성 HTTP Request 후킹으로 테스트 케이스 자동 생성 부하 테스트 성능 레포트 Swagger에서 API Import 원하는 환경에서 언제든 쉽게 테스트
  • 38. - 38 - API Testing 단계별 예 (기본 컨셉)
  • 39. - 39 - API Testing 단계별 예 (swagger , jmeter , checkpoint 서버 배포)
  • 40. - 40 - Global API Testing 시장 과연 얼마나 커지길래 글로벌 API testing 시장은 - API Testing SW 시장규모 2017년 3500억원 -> 2022년 8300억원 (19.16% 성장) - API Testing Service 시장규모 2017년 1600억원 -> 2022년 4100억원 (20.81% 성장) => 2022년까지 크게 성장하는 추세 2017 API Testing Market 분석
  • 41. - 41 - 아시아 지역 API 테스트 시장 상황의 성장세가 가장크다. 아시아 시장은 크게 성장 중이지만, 아직 Key Player가 없음 국내에서 사용하기에 해외 서비스를 이용하는 불편함이 있음 => 시장 빈틈 및 진입 가능성에 주목
  • 42. - 42 - 한국의 API Testing 시장은 왜 이렇게 성장하지 못했나. 첫 번째 이유.. 웹앱 시장
  • 43. - 43 - 한국의 API Testing 시장은 왜 이렇게 성장하지 못했나. 두 번째 이유.. 클라우드 시장 의 낮은 성장율.
  • 44. - 44 - 주요 고객 성장세 출처 : 연간 기업 Report, 언론 공개 자료, 투자자 발표 자료, 주요 인터뷰를 통한 분석
  • 45. - 45 - Part 2. Mobile & DevOps
  • 46. - 46 - 모바일 에서는 왜 DevOps가 필요해 졌나. (모바일) 파편화된 모바일 환경에서 어떻게 품질을 확보 해야지? (노트2의 점유율)
  • 47. - 47 - 모바일 에서는 왜 DevOps가 필요해 졌나. (모바일) Xiaomi 폰의 국내 점유율 4위
  • 48. - 48 - 모바일 DevOps 흐름도
  • 49. - 49 - CashSlide 사례 - 모바일 DevOps 흐름도 (BITRISE 사용 사례) 관련 자료 - https://academy.realm.io/kr/posts/continuous-delivery-for-android/
  • 50. - 50 - 모바일 DevOps 현재 흐름도 Commit Building Testing Release Crash Report
  • 51. - 51 - 모바일 DevOps 제안 흐름도 Commit Building Test Auto Perf Report Release Crash Report Monitoring
  • 52. - 52 - 더 나은 품질 확보를 위하여. 기존의 모바일 서비스는 출시 전 QA(Quality Assurance)를 통해 개발 관점에서의 사용자 만족도를 높여 왔습니다. 하지만 모바일 서비스의 각 사용자 별 환경에 따른 성능에 대해서는 현재까지도 스토어의 별점 등을 통해 피드백만 받아 온것이 현실입니다. 여기서 중요한 것은 성능의 문제점을 겪은 고객은 점점 해당 서비스의 이탈로 이어진다는 것입니다. VS.
  • 53. - 53 - 모니터링 개요 IMQA는 모바일 환경의 필터 기반 다계층 분석 방식이 적용된 모바일 성능 모니터링 솔루션 (MPM, Mobile Performance Monitoring)입니다. 출시 전 QA(Quality Assurance)를 통해 기능 오류를 점검하는 방식과는 다르게 각 사용자의 모바일 환경에서의 성능을 지표화하여 궁극적으로는 귀사의 모바일 서비스의 성능을 향상시켜 줍니다.
  • 54. - 54 - IMQA 차별점 현재, 시장의 MPM은 Goolge의 ‘Firebase’나 New Relic 등 해외 제품이 전부이며 이상징후 (Crash)가 발생되는 시점에서만 성능을 모니터링해 줍니다. 이는 문제가 발생이 되어야만 성능 이슈를 모니터링해주는 것으로 ‘소잃고 외양간 고치는 형태’와 같습니다. 이에 반해 IMQA는 실시간 성능 모니터링이 가능하기 때문에 고객의 성능에 대한 불만족이 발생하기 전에도 이를 관리하고 예방할 수 있습니다. IMQA는 Crash(이상징후) 발생 시점의 성능 문제의 원인을 규명하는 방식이 아닌, 실시간 성능 정보를 모니터링하는 방식입니 다. 실시간 성능 모니터링Crash 발생 시점 성능 모니터링 (실시간 X)
  • 55. - 55 - IMQA 차별점 이상징후(Crash) 분석 기반의 모바일 성능 모니터링 (MPM, Mobile Performance Monitoring)으로 대표되는 제품은 전부 외산 솔루션입니다. 각 기업의 욕구에 맞는 솔루션은 다양하게 출시되어 있지만, 설치 및 교육, 현지화(언어 등), 업데이트 및 유지보수 등 외산 제품의 도입에 따른 불편함 또한 다양하게 존재합니다. 이상징후(Crash)만 검출한다고 다 MPM (모바일 성능 모니터링, Mobile Performance Monitoring)이 아닙니다.
  • 56. - 56 - 실 사례로 보는 모바일 성능 확보 방안
  • 57. - 57 - 데이터를 수집하는 방법
  • 58. - 58 - 주요 수집 데이터 • RL O B C B • ( / N ) • / • / • B A A • PI M • BB A • F
  • 59. - 59 - 어떻게 수집하나? • ): B + : @ : / : • -. .A CC : / / B / / C/ A A CC : (
  • 66. 설명 – 화면이 뜨고 나서 시간 순서대로 스택정보 나열 14ms : 화면이 뜰때 초기하는 작업들이 너무 많음 236ms : 현 순간에도 화면 레이아웃을 구성하고 있는 중 1397ms : 화면의 프레임이 다 그려지지 않아 UI Thread에서 대기 하는 상황
  • 67. 문제 상황 A사 SDK HealthData에서 데이터를 받아오느라 화면 전체(UI Thread) 가 멈추는 상황이 발생함. 항상 로컬에 이전 데이터를 저장해서 먼저 보여주고, 사용자가 클릭시 정보를 가져오는 것으로 하는 것이 좋음 즉 인터넷이 연결되지 않아도 이전 데이터를 볼수 있도록 먼저 가이드라인을 잡기를 권고함.
  • 68. 고려 상황 화면 점유시간 3초 이상 화면을 다시 그리는 (Resume) 하는 상황에서, 화면 단에서 FileIO가 발생함 리소스 폰트를 가져오는 상황에서 지연이 발생되는 것으로 판단됨.
  • 69.
  • 70.
  • 71. 나라 / 지역별 UI 속도 / 응답시간 체크
  • 72. - 72 - 감사합니다. Thank you for your interesting. - 자세한 문의는 아래로 주세요 어니컴 주식회사 | 서울시 중구 세종대로 21길 22, 태성빌딩 4층 | TEL : 02-541-0080 손영수 상무 (총괄) ysson@onycom.com