클라우드 환경에서 알아야할 성능 이야기

클라우드 환경에서 알아야 성능 이야기.
그리고 모니터링 시스템 구축시 유의 사항.
와탭 CPO 손영수

장애가 났을때.. 우리의 대처 방법
Top
2nd Level
1st Level
traceroute 찍어봐요.
어 재현되지 않네요?
Network 문제도 아니네?
CPU도 별 문제 없는데?
내가 만든
어플리케이션 문제인가봐..

개발자/ 운영자가 그럴수 밖에 없는 이유!!

Application
System Call Interface
File System
Block Device Interface
Storage Device Drivers
Storage Devices
서버 단에서만 봐도
문제의 지점을 찾기가 힘들다..

자.. 그럼 우리가 더 고민해야 할 이야기..

클라우드는 공유 자원..

요청이 많으면 즉 내 차례를 기다리거나..

상황에 맞게 제한된 자원을 나눠가지
던가..

잘 동작하던 게임서버에서
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/

클라우드 모니터링은 인스턴스를 애완동물보다 가축으로 보아야 한다.
(Server , VM vs Cloud Instance)

클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud

클라우드 에서의 성능 측정..
둘째, 일부 성능 측정 도구는
작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다.
점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서,
운영 대시보드와 경보기를 엄청나게 설치하지 않는다면
작은 오버헤드와 이용할 수 있는 성능 정보를 얻는 것은 어려워지고 있다.
많은 수의 서버에서 발생하는 문제를 추적 할 수 있는 능력은 더더욱 중요시 되고 있다.
Sasha Goldshtein

클라우드 에서의 성능 측정..
셋째,
클라우드 환경은 탄력성(scale in/out, lambda)이 있어서
일부 성능 최적화 기술은 시대의 뒤처지거나 관련 없다.
특정 프로세서, 메모리 크기, 네트워크 설정 또는 특정 클라우드 업체에 얽매어 있을 필
요가 없다.
과거에 사용하던 설정은 다시는 투자 대비 성과 (ROI)를 얻을 수 없다.
다른 설정을 해야 수십 억을 서버에 쓰지 않고 배포를 최적화할 수 있다.
Sasha Goldshtein

모니터링 구축에 사용할 수 있는 오픈 소스 툴들.

직접 구축시 생각보다 신경쓸게 많다. 하지만 내마음대로 주무를 수 있다.
저장소 , 알럿 시스템 구축, 화면 시각화도 어떻게 할지 고민.
그럼 어떠한 것을 고려해서 구축해야 할까?

Server 모니터링
수집부
모든 Server가 모니터링 수집부로 특정 기간마다 데이터를 전송하는 방법.
서버가 데이터가 주기적으로 안 들어오면 다운으로 인지.
Network
단점1. 모든 서버의 Outbound Port를 열어야 한다.
단점2. 네트워크 가용성이 좋지 않으면, 서버도 다운 된 것으로 인지..
#1. 알럿 정책

Server 모니터링
서버
대부분의 서버는 Private 영역에 존재한다.
모든 아웃바운드 포트를 열지 말고 Proxy를 통해서 열도록 할것.
Network
단점. 네트워크 가용성이 좋지 않으면, Server도 다운 된 것으로 인지..
Proxy

가용성에 대한 고민이 필요!!
서버 가용성과 네트워크 가용성을 분리해야 한다!
네크워크 가용성은 무시할 것인가? 아니면 받아들일 것인가?

가용성 정책을 분리! (네트워크 가용성 / 서버 다운을 분리)
Server
모니터링 서버
특정시간 동안 Device로 응답이 없으면, 네트워크 가용성의 문제로 인식
특히 모든 디바이스가 동시에 데이터가 안들어오면 네트워크 문제일 확율 90% 이상
Network
Proxy
Network
단절 발생
즉 데이터 없음으로 서버 다운으로 인식하지 마세요!

고객의 Network 존에, 서버 다운을 체크하는 시스템 설치 (push 보다는 pull 모델 지원)
Server
Smart Device
(Proxy)
1. Proxy에서 모든 Device의 데이터가 전송됨
2. 데이터가 오지 않는 Device만 선별적으로 WatchDog이 체크
3. WatchDog이
특정 디바이스에 Ping 또는 Health Message
전송후
응답 없으면 Device Down으로 인지
4. WatchDog이
Device Down 메세지를 모니터링 서버로 전송
모니터링 서버Network
Down
Down
Checker

#2. 어떤 데이터를 수집해야 하나?

서버 단에서 봐야하는 자원 병목 포인트
DRAM DRAM
Disk Disk Port Port
CPU
Interconnect
Memory
Bus
CPU
2
Expander Interconnect
Network
Controller
CPU
1
I/O Bus
I/O
Bridge
I/O
Controller
Interface Transports

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"/"total"
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에서 자원에 대한 정보를 얻어오면 몇몇 지표는
Docker의 자원 사용량이 아닌, Host OS의 정보를 얻어온다..

결국 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

Docker에서 수집할수 있는 지표들 (제한적.)
v 위 이미지는 A사가 제공하는 지표
v 실제 공식 Docker runtime 매트릭
v https://docs.docker.com/v1.8/engine/articles/runmetrics/

현실적인 방안은
1 docker on 1 instance..
시스템 운영자가
친숙하게 사용하는
지표가 아직 미제공..

#7. 모니터링 수집 DB는 RDBMS가 적합하지 않습니다.
v RDBMS는 태생이 Read가 많은 서비스에 적합. -> 모니터링은 Time Series DB가 적합하다.
v 이에 반해 모니터링은 Write가 압도적으로 많고, 대부분 시간 순서도 데이터를 읽음.
v Memory 비용 비쌈. -> 1G에 월 1만원이 시장가격

#8. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘..
HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다.
(여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)

모니터링의 부하를 적게 주기 위해서.
Golang을 agent로 사용하는 것이 추세.

#9. 가용성 (가용률에 대한 서비스 불능 시간)
가용률 연간 서비스 불능시간 월간 서비스 불능시간 주간 서비스 불능시간
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.9% 보통 20~30시간 내외

가축들을 키울땐 전혀 다른 농장(클라우드) 2 군데에서 분산해서 키워라.
가능하다면,아니 여력이 된다면, 업체도 상이하게…

오픈소스 만으로도
구축하는데 시간이
한참 걸립니다.
여력이 되시는 분은
구축을..

#10. Web Application의
최적의 성능 지표 찾기!

- 51 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
자원은 노는데, 장애가 난다면..
반면, WAS의 CPU, Memory 사용량은 정상
종료되지 않고 지연중인
트랜잭션 500개 이상
트랜잭션 지연트랜잭션 지연

드리고 싶은 말씀!
완벽한 서비스를 위해서는
Developer
DBA
System
Engineer

웹 서버 성능의 기준은 logNormal
응답시간이
0에 수렴할수록 좋은 서버

무수하게 많은 트랜잭션을 잘 분석하는게 중요
3:04 3:05 3:06 3:07
40초
80초
10초

무수하게 많은 트랜잭션을 표현하는 좋은 지표 찾기
§ 평균 응답시간
§ 백분위 기준
§ 분포..

평균 응답시간 과연 최적의 표현??

평균 응답시간 이렇게 표현 된다면.. 양이 문제를 가린다.

평균의 종류
§ 3.42 (24/7) = Mean : 여러분이 알고 있는 산술 평균
§ 3 = Median : 가운데 자리에 있는 수
§ 3 = Mode : 최빈값 (가장 많이 나온수)
1,2,3,3,4,5,6 의 평균

logNormal에서는 평균이 이렇게 왜곡됩니다.

그럼 백분위 기준 - 빠른 순서 상위 10%, 상위 95 % (or 하위 5%)

백분위 기준 에서 만날수 있는 데이터 왜곡 현상.
(알고보니 다른 workload 3종류 중 한 종류가 잠시 안 들어옴)

그래서 왜곡없이 분포로
모든 데이터를 표현해야 한다..

하지만 SaaS형 APM 툴은 분포를 사용하기 힘들다..
§ 엄청난 데이터 량를 전송
§ TPS (초당 트랜잭션)
§ 트랜잭션당 프로파일링 정보..
§ + …
§ 보안 문제
§ …

그래서 다른 SaaS형 APM은 이렇게 보여줌.. (N사 - 분포를 포기.. 평균..)

그래서 다른 SaaS형 APM은 이렇게 보여줌.. (A사 어플리케이션 성능보다 클라우드적인 관점 )

그에 대한 와탭의 고민.. 분포를 표현하는 이상적인 방법
구간(5초 단위) + 빈도 (진하기)
이러면 훨씬 적은 데이터로.. 분포 표현 가능

#11. 트랜잭션에서 병목을 찾는 방법
(Static + Dynamic Profiling)
User
MEM
CPU
GC
SQL
CONN
CONN

Transaction A
SQL SQL
Http
File
User
과거에는.. 트랜잭션 장애의 병목 원인의 70%는 DB..

DB 관련된 것만 미리 잘 Hooking 하면 많은 문제 해결됨.
User
MEM
CPU
GC
SQL
SQL
SQL
SQLCONN
CONN

하지만
- NoSQL의 범람 , MSA의 강화 등.
- 결국 메소드 프로파일링을 얼마나 잘하느냐의 싸움.

트랜잭션 추적에서 Blind 영역이 늘어감..
User
MEM
CPU
GC
SQL
CONN
CONN

일반적인 해결책은 Static + Dynamic Profiling
User
MEM
CPU
GC
SQL
CONN
CONN
Static Profiling
Static Profiling
Static Profiling
1. 의심되는 메소드 지정
(Dynamic Profiling)

주기적으로 스택을 덤프뜨자..
Thread Dump Thread Dump Thread Dump Thread Dump
Transaction
SQL SQL
Http
File
Transaction
SQL SQL
Http
File
Transaction
SQL SQL
Http
File
Active Stacks

개별 트랜잭션별 스택분석으로. 자주 걸리는 부분이 성능의 저하 구간

#11. 올바른 모니터링 프로세스
신속성
문제 인지 위치 파악 임시 조치
문제 분석 문제 해결
정확성
현황 파악

Topology 위주로 빠르게 인지.

데이터 기반 인지
문제 인지
성능 차트/데이터, 실시간, 전문가
이벤트(경고) 기반 인지
알람 / 경고 메세지, 메일 / SMS, 임계값
SYSTEM
WAS
INSTANCE

이벤트 기반
데이터 기반
시간
중요이벤트 기반
비 경험 장애
대응 가능
데이터 기반
실시간 임계값
인식 방법의 비교
데이터 량 해석능력 자동 임계 경험적 임계
안정화 필요 전문성
비 전문가
운영 가능

서비스 제어
서비스 봉쇄
서비스 제한
트랜잭션 멈춤
인프라 제어
재기동
리소스 증설
클라우드 Scale Out
임시 조치

Throttling
Blocking
IP 제한
URL 제한
서비스 제어 - Transaction Throttling
동시 처리 제한
제한 예외 (무조건 통과)

Circuit Breaker (Throttling) 기능은 이제 필수..

#12. Auto Scaling을 너무 믿지 마세요.

반면, WAS의 CPU, Memory 사용량은 정상
종료되지 않고 지연중인
트랜잭션 500개 이상
트랜잭션 지연트랜잭션 지연
실제 고객은 느린 응답시간을 얻고 있지만,
자원이 놀고 있다면…

web app
server
Elastic Load
Balancing
다행히 CPU가 높아지면 Scale Out

web app
server
Elastic Load
Balancing
하지만 여전히 고객입장에서는 장애로 인식.
web app
server

이유..
• Public Cloud의 LB는 두가지 알고리즘 제공
• Round Robin
• Sticky Session
• 별도의 Health Check가 있으나. 서버와의 ping체크로
인스턴스 제어.
• 즉 고객 서비스의 응답시간으로 측정할 방법 없음.

결론.. 직접 위 사항들을 다 고려해서 만드시거나..
아니면 위 고민이 다 반영되어 있은 저희 제품을 구매하시거나..

스타트업을 위한 가격
10만원 67% 할인 : Infra 모니터닝 10 VM (1달 = 5만원) + APM (10코어 = 25만원)
20만원 67% 할인 : Infra 모니터닝 20 VM (1달 = 10만원) + APM (20코어 = 50만원)
문의는 salesteam@whatap.io 또는 ysson@whatap.io 로 주세요.
와탭은 제안드립니다.
대분류 가격 모델 1 core 2 core 4 core 이상
VM
&
Dedicated
1 month retention 1,250 2,500 5,000
12 month retention 2,500 5,000 10,000
• 사실상 4 core 이상은 동일 가격이므로, 기존 인스턴스 체계 유지
• 1, 2 core의 경우 할인해주는 방식
저희 가격은 10대를 써도 5만원.
직접 여러분이 만드시는 고생과 노력의 비용 + 4 Core VM 한달 유지비만 8만원..

참고한 글
• https://www.slideshare.net/brendangregg
• https://www.slideshare.net/mobile/brendangregg/performance
-use-method
• https://www.slideshare.net/brendangregg/container-
performance-analysis

클라우드 환경에서 알아야할 성능 이야기

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 클라우드 환경에서 알아야할 성능 이야기

Ähnlich wie 클라우드 환경에서 알아야할 성능 이야기 (20)

Mehr von YoungSu Son

Mehr von YoungSu Son (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

클라우드 환경에서 알아야할 성능 이야기