SlideShare a Scribd company logo
클라우드 & 모바일 환경에서
알아야 할 성능&품질 이야기
IMQA 손영수
본 문서는 (주)어니컴이 발행하는 문서이며 저작권법에 의해
보호를 받는 저작물이므로 발행처의 허가 없이 무단 전재나 복제를 금합니다 .
장애가 났을때.. 운영자/개발자의 대처 방법
traceroute 찍어봐요.
어 재현되지 않네요?
Network 문제도 아니네?
CPU도 별 문제 없는데?
니가 만든
어플리케이션 문제인가봐..
개발자/ 운영자가 그럴수 밖에 없는 이유!!
Application
System Call Interface
File System
Block Device Interface
Storage Device Drivers
Storage Devices
서버 단에서만 봐도 문제의 지점을 찾기가 힘들다..
#1. 클라우드에서 품질 확보를 위해 고민해야 될것들..
클라우드는 ...
클라우드는 공유 자원..
클라우드는 공유 자원..
요청이 많으면 즉 내 차례를 기다리거나..
클라우드는 공유 자원..
상황에 맞게 제한된 자원을
나눠가지던가..
잘 동작하던 게임서버에서
User들이
갑자기 튕겨나간 사례.
알고보니 자원 공유 제약..
IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 ->
클라우드에선 늘 발생할 수 있는 문제..
몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정
해결책..
만약 A사 (AM?, AZ?)
제품이면 제값 주고
Provisioned IOPS 구입!
해결책..
만약 A사 (AM?, AZ?)
제품이면 제값 주고
Premium Storage Disk 구입!
클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troubleshooting-high-
io-wait-in-linux/
클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
클라우드 에서의 성능 측정..
둘째, 일부 성능 측정 도구는
작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다.
점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서,
운영 대시보드와 경보기를 엄청나게 설치하지 않는다면
작은 오버헤드와 이용할 수 있는 성능 정보를 얻는 것은 어려워지고 있다.
많은 수의 서버에서 발생하는 문제를 추적 할 수 있는 능력은 더더욱 중요시 되고 있다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
#2. 어떤 데이터를 수집해야 하나?
60초안에 서버 성능 보기.
http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
10. 
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
load averages
kernel errors
overall stats by time
CPU balance
process usage
disk I/O
memory usage
network I/O
TCP stats
check overview
어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?
USE 메소드의 예
Resource Type Metric
CPU utilization CPU utilization
CPU saturation run-queue length
Memory utilization Available memory
Memory saturation Paging or swapping
NetworkInterface utilization RX/TX tput / bandwidth
StorageDeviceI/O utilization Device busy percent
StorageDeviceI/O saturation Wait queue length
StorageDeviceI/O errors Device errors
USE 메소드의 예.
Resource Utilization Saturation
Errors
CPU mpstat-PALL1,	
sumnon-idlefields
vmstat1,"r" perf
Memory
Capacity
free–m,"used"/"tot
al"
vmstat1,"si"+"so";
demsg|grepkilled
dmesg
StorageI/O iostat–xz1,
"%util"
iostat–xnz1,
"avgqu-sz">1
/sys/…/ioerr_cnt;
smartctl
Network nicstat,"%Util" ifconfig,"overrunns";
netstat–s"retrans…"
ifconfig,
"errors"
주의할 점 MemFree vs MemoryAvailable.
cat /proc/meminfo
MemFree보다
MemAvailable을 이용하세요.
Ubuntu 14.04이상
MemFree:
The amount of physical RAM, in kilobytes,
left unused by the system.
MemAvailable:
An estimate of how much memory is available
for starting new application
모든 자원 사용의 주체는 프로세스
#3. 프로세스를 모니터링 해라! ­ 가능한 상세히..
프로세스를 그룹별로 모니터링할수 있어야 한다!
프로세스 그룹별 정책
• 프로세스 최소 수, 최대 수
• 프로세스 그룹이 사용하는 CPU 사용량
• 프로세스 그룹이 사용하는 메모리 사용량
#4. TCP Connection 상태도 모니터링 해라
특히 CLOSE_WAIT를 주의깊게 살펴라..
#5. 운영시 최소한 챙겨야 하는 이벤트 (윈도우)
윈도우 EventID 윈도우 비스타 EventID 이벤트 타입 설명
512, 513, 514, 515, 516,
518, 519, 520
4608, 4609, 4610, 4611, 4
612, 4614, 4615, 4616
System Events Identifies local system processes such as system startup and shutdown and changes to the system time
517 4612 Audit Logs Cleared Identifies all the audit logs clearing events
528, 540 4624 Successful User Logons Identifies all the user logon events
529, 530, 531, 532, 533,
534, 535, 536, 537, 539
4625 Logon Failures Identifies all the failed user logon events
538 4634 Successful User Logoff Identifies all the user logoff events
560, 563, 565, 566
4656, 4658, 4659, 4660, 4
661, 4662, 4663, 4664, 51
47
Object Access
Identifies when a given object (File, Directory, etc.) is accessed, the type of access (e.g. read, write, del
ete) and whether or not access was successful/failed, and who performed the action
612 4719 Audit Policy Changes Identifies all the changes done in the audit policy
624, 625, 626, 627, 628,
629, 630, 642, 644
4720, 4722, 4723, 4724, 4
725, 4726, 4738, 4740
User Account Changes
Identifies all the changes done on an user account like user account creation,deletion, password change
, etc.
(631 to 641) and (643, 6
45 to 666)
4727 to 4737, 4739 to 476
2
User Group Changes
Identifies all the changes done on an user group such as adding or removing a global or local group, ad
ding or removing members from a global or local group, etc.
672, 680 4768, 4776 Successful User Account Validation
Identifies successful user account logon events, which are generated when a domain user account is au
thenticated on a domain controller
675, 681 4771, 4777 Failed User Account Validation
Identifies unsuccessful user account logon events, which are generated when a domain user account is
authenticated on a domain controller
682, 683 4778, 4779 Device Session Status Identifies the session re-connection or disconnection
운영시 최소 한 챙겨야 하는 syslog (리눅스)
/var/log/messages : General message and system related stuff
/var/log/auth.log : Authenication logs
/var/log/kern.log : Kernel logs
/var/log/cron.log : Crond logs (cron job)
/var/log/maillog : Mail server logs
/var/log/qmail/ : Qmail log directory (more files inside this directory)
/var/log/httpd/ : Apache access and error logs directory
/var/log/lighttpd/ : Lighttpd access and error logs directory
/var/log/boot.log : System boot log
/var/log/mysqld.log : MySQL database server log file
/var/log/secure or /var/log/auth.log : Authentication log
/var/log/utmp or /var/log/wtmp : Login records file
/var/log/yum.log : Yum command log file.
추가 정보는 http://bit.ly/2ujaNJm 를 참고
#6. Docker? 어떻게 모니터링 할래?
Host 기반 Docker 기반
Docker에서 수집할수 있는 지표들
v Docker runtime 매트릭과 다름.
v 모니터링 밴더사마다 매트릭 추가 / 삭제.
v 하지만 여전히 Host에 비해 제한적인 것은 사실.
결국 Docker는 Linux 입장에서 프로세스.
# PID of the docker daemon
ps aux | grep -E 'docker (-d|daemon)’
root 665 0.0 0.4 1521560 17156 ? Ssl janv.06 5:47 /usr/bin/docker -d -H fd://
# find child processes of the docker daemon pgrep -P 665
4076
4135
4210
# figure out details of a process ps 4076
PID TTY STAT TIME COMMAND
4076 ? Ssl 10:45 /usr/bin/redis-server 0.0.0.0:6379
# repeat for other child processes
현실적인 방안은
1 docker on 1 instance..
시스템 운영자가
친숙하게 사용하는
지표가 아직 미제공..
#7. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘..
HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다.
(여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)
모니터링의 부하를 적게 주기 위해서.
Golang을 agent로 사용하는 것이 추세.
#8. 가용성 (가용률에 대한 서비스 불능 시간)
가용률 연간 서비스 불능시간 월간 서비스 불능시간 주간 서비스 불능시간
99.9999% 31.50초 2.59초 0.605초
99.999% 5.26분 24.9초 6.05초
99.99% 52.56분 4.32분 1.01분
99.9% 8.76시간 43.8분 10.1분
99% 3.65일 7.2시간 1.68시간
Public Cloud의 가용성은
99% < Public Cloud <99.99% 20~30시간 내외
가용성의 함정.
#2. Mobile에서 성능 품질
모바일 QA = 사전 테스트 + 사후 크래시 분석
현재 모바일 앱 품질 확보 방안
Call Stack Event Path
Mobile은 공유자원.. 이중 하나만 잘못되어도..
Android iOS
안드로이드를 중심으로 설명하겠습니다.
OS 영역은 클라우드와 유사합니다.
안드로이드는
앱당 메모리에 대한 제약만 있음.
CPU, IO 사용량에는 제한이 없음.
개발 편의성/ 관리를 위해 직접 메모리를 관리하고 싶지만..
Java에서는
C, C++에서 사용하는 ‘free’, ‘delete’가 없기 때문에
주기적으로 혹은 특정 조건일 때 GC를 하게 됩니다.
이로인해 프로그래머는 메모리 관리에 대해서 고민을 적게 할 수 있습니다.
하지만 임베디드 환경에서는 메모리 하나 하나가 매우 소중합니다.
안드로이드 메모리 관리방법 (GC)에 대한 발전사
기본적으로 할당하는 방식은
Strong Reference 입니다.
Strong
- 기본적으로 할당하는 방식을 Strong Reference 라고 부릅니다.
mLauncher = new <Launcher>(launcher);
- GC과정에서 연결된 객체들을 Mark하고 Mark되지 않은 객체들을 Sweep합니다.
Strong 이외에 3가지가 더 있습니다.
1. 종류
Soft reference, Weak reference, Phantom reference
Private WeakReference<Launcher> mLauncher;
mLauncher = new WeakReference<Launcher>(launcher);
2. 원리
- GC동작에서 Strong이 아닌 경우 Mark하지 않고
Reference Queue라는 공간에 객체를 넣고,
Sweep하는 과정에서 제거 Queue에 있는 객체들을 제거 합니다.
더 자세히 보겠습니다.
1. Soft reference
Mark가 되기도 하고 Reference Queue에 담기기도 합니다.
Soft reference로 참조된 객체는 메모리가 절대적으로 부족한 상황이 되기전에는 참조가 유지됩니다.
각 앱마다 할당된 메모리가 절대적을 부족할 때 Soft이면 제거, 여유롭다면 Strong과 같이 제거하지 않습니다.
2. Weak reference
Referene Queue에 담깁니다.
Weak reference로 참조된 객체는 Soft Reference보다 더 약한 연결고리를 가집니다.
메모리의 상태와 관계없이 GC가 동작되는 순간 Marked Object라도 회수됩니다.
Strong Soft
Weak
Phantom
Mark
Reference Queue
(다른작업도 쓰레드로 진행가능)
안드로이드 구 버전의 GC방식
Serial Mark&Sweep과 Concurrent Mark&Sweep 동작 비교
Android ART 이후 변화된 메모리 구조..
Rosalloc 이란
(Runs of Slots Allocator)
작은 객체들을 위한
thread local storage를 만들자.
Bulk free를 위하여.
작은 객체를 할당하는 영역과
큰 객체를 할당하는 영역을 구분하자
하나의 영역에 객체를 할당하니,
GC가 빈번하게 발생해서,
역할을 나누자!
다양한 전략들을 도입 함.
세대별 전략 도입
(딱 안드로이드와 일치하지 않음)
추가적인 기교들을 더함.
• Dalvik이 두번 Pause(mark ­remark) 해서 객체 mark-sweep 함
• ART에서는 한번 pause(mark를 병렬로 진행 ­ remark에서만 멈춤).
• 그래도 mark-sweep은 느리니 병렬로 해서 빠르게 정리하자.
• 최근 생성(sticky)하거나, 짧은 수명의 객체는 빨리 제거하자.
• 메모리가 부족해 GC를 돌리면 OOM이 날수 있으니, 더 낮은 상한성 (GC Timelier) 만들
어서 돌리자.
CPU, UI Rendering은 추후 시간이 되면..
우리가 간과하는 큰 부분이 있습니다.
심지어 프로파일러 마저도.. 없는 영역??
I/O
모바일 스토리지 종류에 따라 차이나는 IO 성능
4kb 에 랜덤 읽기 / 쓰기 속도
4kb에 빠르다고 해서 256kb도 빠른게 아니다
시사점..
Database, File I/O Benchmark Test의 의미가 무색..
하나의 디바이스에서 매겨진 랭킹이.
다른 디바이스에서 동일하다는 보장이 없다..
직접 case by case 다 보셔야 한다.. (정말 가능?)
#3. 모바일 어플리케이션의 유 의미한 성능 확보 방안은?
사전 테스트
(고객 배포 이전에 Quality Gate 역할)
단점들…
1) 고객의 Device와 나의 Device는 다른 상황..
2) 다른 앱의 간섭으로 발생한 문제라면.
3) 구할 수 없는 디바이스라면….
배포후 크래시 수집 -> 성능 개선..
1) 고객은 이미 떠나는 상황.. (별점 테러)
2) 크래시 상황이 100% 재현이 안됨..
3) 크래시 제공 회사가 주는 제약들
• Google만 써
• 북미에 있는 서버
• 데이터는 다 저장못해 (샘플링 방식)
전방위적으로 모니터링 한다면.
• 사고가 나기 전에도 전반적인 운행 상황도,
• 사고날때는 더 상세한 상황을..
사용자 수 액티비티 관계 문제 상황
에 따른 문제상황
파악가능
액티비티
OS 버전
기기 종류
지역
적용한 필터는 모든 디테일 화
면에도 적용
시간별 자원 사용량과 요청한 함수, OS Level 데이터 제공
현재 앱의 가장 문제되는 구간(병목) 파악
필터 그룹 저장
저장된 필터 그룹이용
자세한 원인 파악 가능
참고한 글
• https://www.slideshare.net/brendangregg
• https://www.slideshare.net/mobile/brendangregg/performance
-use-method
• https://www.slideshare.net/brendangregg/container-
performance-analysis
THANK YOU!
support@imqa.io

More Related Content

What's hot

[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기
NAVER D2
 
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
Jeongsang Baek
 
Windows system - memory개념잡기
Windows system - memory개념잡기Windows system - memory개념잡기
Windows system - memory개념잡기ChangKyu Song
 
[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나
NAVER D2
 
[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효
NAVER D2
 
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규ChangKyu Song
 
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
강 민우
 
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
강 민우
 
웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우
IMQA
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규ChangKyu Song
 
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
Jaeseung Ha
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
YoungSu Son
 
Ryan Dahl의 Node.js 소개 동영상 해설 by doortts
Ryan Dahl의 Node.js 소개 동영상 해설 by doorttsRyan Dahl의 Node.js 소개 동영상 해설 by doortts
Ryan Dahl의 Node.js 소개 동영상 해설 by doortts
Suwon Chae
 
[C5]deview 2012 nodejs
[C5]deview 2012 nodejs[C5]deview 2012 nodejs
[C5]deview 2012 nodejsNAVER D2
 
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
강 민우
 
Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선
기동 이
 
[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔
NAVER D2
 
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발주항 박
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
devCAT Studio, NEXON
 
백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010
devCAT Studio, NEXON
 

What's hot (20)

[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기[121]네이버 효과툰 구현 이야기
[121]네이버 효과툰 구현 이야기
 
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
소셜게임 서버 개발 관점에서 본 Node.js의 장단점과 대안
 
Windows system - memory개념잡기
Windows system - memory개념잡기Windows system - memory개념잡기
Windows system - memory개념잡기
 
[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나[111] 네이버효과툰어떻게만들어졌나
[111] 네이버효과툰어떻게만들어졌나
 
[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효[145]5년간의네이버웹엔진개발삽질기그리고 김효
[145]5년간의네이버웹엔진개발삽질기그리고 김효
 
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
[NDC10] Unity Build 로 빌드타임 반토막내기 - 송창규
 
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
[IGC 2016] 유니티코리아 오지현 - “뭣이 중헌디? 성능 프로파일링도 모름서”: 유니티 성능 프로파일링 가이드
 
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
[IGC 2017] 오토데스크 박준석 - 3ds Max 2018과 Shotgun을 이용한 게임 제작 Pipeline 소개
 
웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우
 
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
[NDC12] 변화량 분석을 중심으로 한 저비용 고효율의 지속가능한 코드퀄리티 관리법 - 송창규
 
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
[NDC 2014] 던전앤파이터 클라이언트 로딩 최적화
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
Ryan Dahl의 Node.js 소개 동영상 해설 by doortts
Ryan Dahl의 Node.js 소개 동영상 해설 by doorttsRyan Dahl의 Node.js 소개 동영상 해설 by doortts
Ryan Dahl의 Node.js 소개 동영상 해설 by doortts
 
[C5]deview 2012 nodejs
[C5]deview 2012 nodejs[C5]deview 2012 nodejs
[C5]deview 2012 nodejs
 
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
[IGC 2017] 엔지메이킹 이대희 - 이제는 웹에서 게임을 만들 수 있는 환경 'Construct3를 바탕으로'
 
Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선Front end 웹사이트 성능 측정 및 개선
Front end 웹사이트 성능 측정 및 개선
 
[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔[124] 하이브리드 앱 개발기 김한솔
[124] 하이브리드 앱 개발기 김한솔
 
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발
오픈 소스를 활용한 캐쥬얼 게임 서버 프레임워크 개발
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
 
백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010백승엽, M2프로젝트의 오류보고시스템, NDC2010
백승엽, M2프로젝트의 오류보고시스템, NDC2010
 

Similar to 클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
문기 박
 
주니어 개발자의 서버 로그 관리 개선기
주니어 개발자의 서버 로그 관리 개선기주니어 개발자의 서버 로그 관리 개선기
주니어 개발자의 서버 로그 관리 개선기
Yeonhee Kim
 
Accelerate spring boot application with apache ignite
Accelerate spring boot application with apache igniteAccelerate spring boot application with apache ignite
Accelerate spring boot application with apache ignite
YEON BOK LEE
 
김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법성훈 김
 
장고로 웹서비스 만들기 기초
장고로 웹서비스 만들기   기초장고로 웹서비스 만들기   기초
장고로 웹서비스 만들기 기초
Kwangyoun Jung
 
JMI Techtalk : Backend.AI
JMI Techtalk : Backend.AIJMI Techtalk : Backend.AI
JMI Techtalk : Backend.AI
Lablup Inc.
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
중선 곽
 
서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
수보 김
 
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
Jae Sung Park
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
NAVER D2
 
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
Gruter
 
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST_NHNent
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startup
JunHo Yoon
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptx
ssuserb8551e
 
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
Matthew (정재화)
 
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
uEngine Solutions
 
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
Kivol
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
devCAT Studio, NEXON
 
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
ksdc2019
 

Similar to 클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기 (20)

모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
 
주니어 개발자의 서버 로그 관리 개선기
주니어 개발자의 서버 로그 관리 개선기주니어 개발자의 서버 로그 관리 개선기
주니어 개발자의 서버 로그 관리 개선기
 
Accelerate spring boot application with apache ignite
Accelerate spring boot application with apache igniteAccelerate spring boot application with apache ignite
Accelerate spring boot application with apache ignite
 
김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법
 
장고로 웹서비스 만들기 기초
장고로 웹서비스 만들기   기초장고로 웹서비스 만들기   기초
장고로 웹서비스 만들기 기초
 
JMI Techtalk : Backend.AI
JMI Techtalk : Backend.AIJMI Techtalk : Backend.AI
JMI Techtalk : Backend.AI
 
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
프로그래밍 패러다임의 진화 및 Spring의 금융권 적용
 
서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
 
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
[DEVIEW 2016] 네이버의 모던 웹 라이브러리 - egjs
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
 
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
 
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startup
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptx
 
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
 
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
 
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
GraphQL in Action - REST와 이별할 때 생각해야 하는 것들
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
 

More from YoungSu Son

Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
YoungSu Son
 
Clean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance TuningClean Code, Software Architecture, Performance Tuning
Clean Code, Software Architecture, Performance Tuning
YoungSu Son
 
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
인공지능 식별추적시스템 실증랩 구축및 운영 - 평가모델 고도화
YoungSu Son
 
Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭) Prototype 패턴 (심만섭)
Prototype 패턴 (심만섭)
YoungSu Son
 
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
Chain of Responsibility (심수연 - 소프트웨어 마에스트로 10기)
YoungSu Son
 
Singleton 패턴 (김진영 - EVA, 소마에 10기)
Singleton 패턴 (김진영 -  EVA, 소마에 10기) Singleton 패턴 (김진영 -  EVA, 소마에 10기)
Singleton 패턴 (김진영 - EVA, 소마에 10기)
YoungSu Son
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
YoungSu Son
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
YoungSu Son
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
YoungSu Son
 
SW 아키텍처 분석방법
SW 아키텍처 분석방법 SW 아키텍처 분석방법
SW 아키텍처 분석방법
YoungSu Son
 
[NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법 [NEXT] Android Profiler 사용법
[NEXT] Android Profiler 사용법
YoungSu Son
 
Android Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + GenymotionAndroid Studio 개발 셋팅 + Genymotion
Android Studio 개발 셋팅 + Genymotion
YoungSu Son
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
YoungSu Son
 
[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신
YoungSu Son
 
[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기
YoungSu Son
 
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
YoungSu Son
 
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리) 오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
YoungSu Son
 
URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표 URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표
YoungSu Son
 
[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring
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기)
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
 
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
 
[NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기 [NEXT] Flask 로 Restful API 서버 만들기
[NEXT] Flask 로 Restful API 서버 만들기
 
[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신[NEXT] GCM을 이용한 게시글 자동 갱신
[NEXT] GCM을 이용한 게시글 자동 갱신
 
[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기[NEXT] Andorid에 MVC 패턴 적용하기
[NEXT] Andorid에 MVC 패턴 적용하기
 
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
[NEXT] 화면 재갱신이 되는 안드로이드 앱 만들기 - 네트워크에 독립하는 구조로 변경
 
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리) 오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
오픈소스 Jedis 리펙토링 하기 (redis java 라이브러리)
 
URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표 URQA 삼성 컨퍼런스 발표
URQA 삼성 컨퍼런스 발표
 
[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring[NEXT] Nextgram Refactoring
[NEXT] Nextgram Refactoring
 

클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기

  • 1. 클라우드 & 모바일 환경에서 알아야 할 성능&품질 이야기 IMQA 손영수 본 문서는 (주)어니컴이 발행하는 문서이며 저작권법에 의해 보호를 받는 저작물이므로 발행처의 허가 없이 무단 전재나 복제를 금합니다 .
  • 2. 장애가 났을때.. 운영자/개발자의 대처 방법 traceroute 찍어봐요. 어 재현되지 않네요? Network 문제도 아니네? CPU도 별 문제 없는데? 니가 만든 어플리케이션 문제인가봐..
  • 3. 개발자/ 운영자가 그럴수 밖에 없는 이유!!
  • 4. Application System Call Interface File System Block Device Interface Storage Device Drivers Storage Devices 서버 단에서만 봐도 문제의 지점을 찾기가 힘들다..
  • 5. #1. 클라우드에서 품질 확보를 위해 고민해야 될것들..
  • 8. 클라우드는 공유 자원.. 요청이 많으면 즉 내 차례를 기다리거나..
  • 9. 클라우드는 공유 자원.. 상황에 맞게 제한된 자원을 나눠가지던가..
  • 11. 알고보니 자원 공유 제약.. IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우드에선 늘 발생할 수 있는 문제.. 몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정
  • 12. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Provisioned IOPS 구입!
  • 13. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Premium Storage Disk 구입!
  • 14. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개. § IOPS § Disk Queue Length (win) / iowait (linux) § CPU Steal Time 등.. § http://bencane.com/2012/08/06/troubleshooting-high- io-wait-in-linux/
  • 15. 클라우드 에서의 성능 측정이 어려운 이유.. 첫째, 일부 부분은 우리가 통제할 수 없다. 우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만 어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다. 우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나 단절 되는 이유를 알아내기 매우 힘들다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  • 16. 클라우드 에서의 성능 측정.. 둘째, 일부 성능 측정 도구는 작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다. 점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서, 운영 대시보드와 경보기를 엄청나게 설치하지 않는다면 작은 오버헤드와 이용할 수 있는 성능 정보를 얻는 것은 어려워지고 있다. 많은 수의 서버에서 발생하는 문제를 추적 할 수 있는 능력은 더더욱 중요시 되고 있다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  • 17. #2. 어떤 데이터를 수집해야 하나?
  • 18. 60초안에 서버 성능 보기. http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html 1.  2.  3.  4.  5.  6.  7.  8.  9.  10.  uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top load averages kernel errors overall stats by time CPU balance process usage disk I/O memory usage network I/O TCP stats check overview
  • 19. 어려운 방법보다 USE 메소드를 이용. Saturation Utilization X Errors Utilization : 얼만큼 자원을 썼는지? Saturation : 얼마나 많은 부하(extra works)가 들어왔는지. Error : 발생한 에러는?
  • 20. USE 메소드의 예 Resource Type Metric CPU utilization CPU utilization CPU saturation run-queue length Memory utilization Available memory Memory saturation Paging or swapping NetworkInterface utilization RX/TX tput / bandwidth StorageDeviceI/O utilization Device busy percent StorageDeviceI/O saturation Wait queue length StorageDeviceI/O errors Device errors
  • 21. USE 메소드의 예. Resource Utilization Saturation Errors CPU mpstat-PALL1, sumnon-idlefields vmstat1,"r" perf Memory Capacity free–m,"used"/"tot al" vmstat1,"si"+"so"; demsg|grepkilled dmesg StorageI/O iostat–xz1, "%util" iostat–xnz1, "avgqu-sz">1 /sys/…/ioerr_cnt; smartctl Network nicstat,"%Util" ifconfig,"overrunns"; netstat–s"retrans…" ifconfig, "errors"
  • 22. 주의할 점 MemFree vs MemoryAvailable. cat /proc/meminfo MemFree보다 MemAvailable을 이용하세요. Ubuntu 14.04이상 MemFree: The amount of physical RAM, in kilobytes, left unused by the system. MemAvailable: An estimate of how much memory is available for starting new application
  • 23. 모든 자원 사용의 주체는 프로세스 #3. 프로세스를 모니터링 해라! ­ 가능한 상세히..
  • 24. 프로세스를 그룹별로 모니터링할수 있어야 한다! 프로세스 그룹별 정책 • 프로세스 최소 수, 최대 수 • 프로세스 그룹이 사용하는 CPU 사용량 • 프로세스 그룹이 사용하는 메모리 사용량
  • 25. #4. TCP Connection 상태도 모니터링 해라 특히 CLOSE_WAIT를 주의깊게 살펴라..
  • 26. #5. 운영시 최소한 챙겨야 하는 이벤트 (윈도우) 윈도우 EventID 윈도우 비스타 EventID 이벤트 타입 설명 512, 513, 514, 515, 516, 518, 519, 520 4608, 4609, 4610, 4611, 4 612, 4614, 4615, 4616 System Events Identifies local system processes such as system startup and shutdown and changes to the system time 517 4612 Audit Logs Cleared Identifies all the audit logs clearing events 528, 540 4624 Successful User Logons Identifies all the user logon events 529, 530, 531, 532, 533, 534, 535, 536, 537, 539 4625 Logon Failures Identifies all the failed user logon events 538 4634 Successful User Logoff Identifies all the user logoff events 560, 563, 565, 566 4656, 4658, 4659, 4660, 4 661, 4662, 4663, 4664, 51 47 Object Access Identifies when a given object (File, Directory, etc.) is accessed, the type of access (e.g. read, write, del ete) and whether or not access was successful/failed, and who performed the action 612 4719 Audit Policy Changes Identifies all the changes done in the audit policy 624, 625, 626, 627, 628, 629, 630, 642, 644 4720, 4722, 4723, 4724, 4 725, 4726, 4738, 4740 User Account Changes Identifies all the changes done on an user account like user account creation,deletion, password change , etc. (631 to 641) and (643, 6 45 to 666) 4727 to 4737, 4739 to 476 2 User Group Changes Identifies all the changes done on an user group such as adding or removing a global or local group, ad ding or removing members from a global or local group, etc. 672, 680 4768, 4776 Successful User Account Validation Identifies successful user account logon events, which are generated when a domain user account is au thenticated on a domain controller 675, 681 4771, 4777 Failed User Account Validation Identifies unsuccessful user account logon events, which are generated when a domain user account is authenticated on a domain controller 682, 683 4778, 4779 Device Session Status Identifies the session re-connection or disconnection
  • 27. 운영시 최소 한 챙겨야 하는 syslog (리눅스) /var/log/messages : General message and system related stuff /var/log/auth.log : Authenication logs /var/log/kern.log : Kernel logs /var/log/cron.log : Crond logs (cron job) /var/log/maillog : Mail server logs /var/log/qmail/ : Qmail log directory (more files inside this directory) /var/log/httpd/ : Apache access and error logs directory /var/log/lighttpd/ : Lighttpd access and error logs directory /var/log/boot.log : System boot log /var/log/mysqld.log : MySQL database server log file /var/log/secure or /var/log/auth.log : Authentication log /var/log/utmp or /var/log/wtmp : Login records file /var/log/yum.log : Yum command log file. 추가 정보는 http://bit.ly/2ujaNJm 를 참고
  • 28. #6. Docker? 어떻게 모니터링 할래? Host 기반 Docker 기반
  • 29. Docker에서 수집할수 있는 지표들 v Docker runtime 매트릭과 다름. v 모니터링 밴더사마다 매트릭 추가 / 삭제. v 하지만 여전히 Host에 비해 제한적인 것은 사실.
  • 30. 결국 Docker는 Linux 입장에서 프로세스. # PID of the docker daemon ps aux | grep -E 'docker (-d|daemon)’ root 665 0.0 0.4 1521560 17156 ? Ssl janv.06 5:47 /usr/bin/docker -d -H fd:// # find child processes of the docker daemon pgrep -P 665 4076 4135 4210 # figure out details of a process ps 4076 PID TTY STAT TIME COMMAND 4076 ? Ssl 10:45 /usr/bin/redis-server 0.0.0.0:6379 # repeat for other child processes
  • 31. 현실적인 방안은 1 docker on 1 instance.. 시스템 운영자가 친숙하게 사용하는 지표가 아직 미제공..
  • 32. #7. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘.. HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다. (여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)
  • 33. 모니터링의 부하를 적게 주기 위해서. Golang을 agent로 사용하는 것이 추세.
  • 34. #8. 가용성 (가용률에 대한 서비스 불능 시간) 가용률 연간 서비스 불능시간 월간 서비스 불능시간 주간 서비스 불능시간 99.9999% 31.50초 2.59초 0.605초 99.999% 5.26분 24.9초 6.05초 99.99% 52.56분 4.32분 1.01분 99.9% 8.76시간 43.8분 10.1분 99% 3.65일 7.2시간 1.68시간 Public Cloud의 가용성은 99% < Public Cloud <99.99% 20~30시간 내외
  • 37. 모바일 QA = 사전 테스트 + 사후 크래시 분석
  • 38. 현재 모바일 앱 품질 확보 방안
  • 39.
  • 41.
  • 42. Mobile은 공유자원.. 이중 하나만 잘못되어도.. Android iOS
  • 43. 안드로이드를 중심으로 설명하겠습니다. OS 영역은 클라우드와 유사합니다.
  • 44. 안드로이드는 앱당 메모리에 대한 제약만 있음. CPU, IO 사용량에는 제한이 없음.
  • 45. 개발 편의성/ 관리를 위해 직접 메모리를 관리하고 싶지만.. Java에서는 C, C++에서 사용하는 ‘free’, ‘delete’가 없기 때문에 주기적으로 혹은 특정 조건일 때 GC를 하게 됩니다. 이로인해 프로그래머는 메모리 관리에 대해서 고민을 적게 할 수 있습니다. 하지만 임베디드 환경에서는 메모리 하나 하나가 매우 소중합니다.
  • 46. 안드로이드 메모리 관리방법 (GC)에 대한 발전사
  • 47. 기본적으로 할당하는 방식은 Strong Reference 입니다. Strong - 기본적으로 할당하는 방식을 Strong Reference 라고 부릅니다. mLauncher = new <Launcher>(launcher); - GC과정에서 연결된 객체들을 Mark하고 Mark되지 않은 객체들을 Sweep합니다.
  • 48. Strong 이외에 3가지가 더 있습니다. 1. 종류 Soft reference, Weak reference, Phantom reference Private WeakReference<Launcher> mLauncher; mLauncher = new WeakReference<Launcher>(launcher); 2. 원리 - GC동작에서 Strong이 아닌 경우 Mark하지 않고 Reference Queue라는 공간에 객체를 넣고, Sweep하는 과정에서 제거 Queue에 있는 객체들을 제거 합니다.
  • 49. 더 자세히 보겠습니다. 1. Soft reference Mark가 되기도 하고 Reference Queue에 담기기도 합니다. Soft reference로 참조된 객체는 메모리가 절대적으로 부족한 상황이 되기전에는 참조가 유지됩니다. 각 앱마다 할당된 메모리가 절대적을 부족할 때 Soft이면 제거, 여유롭다면 Strong과 같이 제거하지 않습니다. 2. Weak reference Referene Queue에 담깁니다. Weak reference로 참조된 객체는 Soft Reference보다 더 약한 연결고리를 가집니다. 메모리의 상태와 관계없이 GC가 동작되는 순간 Marked Object라도 회수됩니다. Strong Soft Weak Phantom Mark Reference Queue
  • 50. (다른작업도 쓰레드로 진행가능) 안드로이드 구 버전의 GC방식 Serial Mark&Sweep과 Concurrent Mark&Sweep 동작 비교
  • 51. Android ART 이후 변화된 메모리 구조..
  • 52. Rosalloc 이란 (Runs of Slots Allocator) 작은 객체들을 위한 thread local storage를 만들자. Bulk free를 위하여. 작은 객체를 할당하는 영역과 큰 객체를 할당하는 영역을 구분하자 하나의 영역에 객체를 할당하니, GC가 빈번하게 발생해서, 역할을 나누자!
  • 54. 세대별 전략 도입 (딱 안드로이드와 일치하지 않음)
  • 55. 추가적인 기교들을 더함. • Dalvik이 두번 Pause(mark ­remark) 해서 객체 mark-sweep 함 • ART에서는 한번 pause(mark를 병렬로 진행 ­ remark에서만 멈춤). • 그래도 mark-sweep은 느리니 병렬로 해서 빠르게 정리하자. • 최근 생성(sticky)하거나, 짧은 수명의 객체는 빨리 제거하자. • 메모리가 부족해 GC를 돌리면 OOM이 날수 있으니, 더 낮은 상한성 (GC Timelier) 만들 어서 돌리자.
  • 56. CPU, UI Rendering은 추후 시간이 되면.. 우리가 간과하는 큰 부분이 있습니다. 심지어 프로파일러 마저도.. 없는 영역?? I/O
  • 57. 모바일 스토리지 종류에 따라 차이나는 IO 성능
  • 58. 4kb 에 랜덤 읽기 / 쓰기 속도
  • 59. 4kb에 빠르다고 해서 256kb도 빠른게 아니다
  • 60. 시사점.. Database, File I/O Benchmark Test의 의미가 무색.. 하나의 디바이스에서 매겨진 랭킹이. 다른 디바이스에서 동일하다는 보장이 없다.. 직접 case by case 다 보셔야 한다.. (정말 가능?)
  • 61. #3. 모바일 어플리케이션의 유 의미한 성능 확보 방안은?
  • 62. 사전 테스트 (고객 배포 이전에 Quality Gate 역할) 단점들… 1) 고객의 Device와 나의 Device는 다른 상황.. 2) 다른 앱의 간섭으로 발생한 문제라면. 3) 구할 수 없는 디바이스라면….
  • 63. 배포후 크래시 수집 -> 성능 개선.. 1) 고객은 이미 떠나는 상황.. (별점 테러) 2) 크래시 상황이 100% 재현이 안됨.. 3) 크래시 제공 회사가 주는 제약들 • Google만 써 • 북미에 있는 서버 • 데이터는 다 저장못해 (샘플링 방식)
  • 64. 전방위적으로 모니터링 한다면. • 사고가 나기 전에도 전반적인 운행 상황도, • 사고날때는 더 상세한 상황을..
  • 65.
  • 66. 사용자 수 액티비티 관계 문제 상황
  • 68. 적용한 필터는 모든 디테일 화 면에도 적용
  • 69. 시간별 자원 사용량과 요청한 함수, OS Level 데이터 제공
  • 70. 현재 앱의 가장 문제되는 구간(병목) 파악
  • 73. 참고한 글 • https://www.slideshare.net/brendangregg • https://www.slideshare.net/mobile/brendangregg/performance -use-method • https://www.slideshare.net/brendangregg/container- performance-analysis