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

클라우드 & 모바일 환경에서
알아야 할 성능&품질 이야기
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 = 사전 테스트 + 사후 크래시 분석

현재 모바일 앱 품질 확보 방안

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

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

More Related Content

What's hot

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

More from YoungSu Son

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