Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
클라우드 환경에서 알아야 성능 이야기.
그리고 모니터링 시스템 구축시 유의 사항.
와탭 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/...
클라우드 모니터링은 인스턴스를 애완동물보다 가축으로 보아야 한다.
(Server , VM vs Cloud Instance)
클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경...
클라우드 에서의 성능 측정..
둘째, 일부 성능 측정 도구는
작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다.
점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서,
운영 대시보드와 경보기를 엄...
클라우드 에서의 성능 측정..
셋째,
클라우드 환경은 탄력성(scale in/out, lambda)이 있어서
일부 성능 최적화 기술은 시대의 뒤처지거나 관련 없다.
특정 프로세서, 메모리 크기, 네트워크 설정 또는 특정...
모니터링 구축에 사용할 수 있는 오픈 소스 툴들.
직접 구축시 생각보다 신경쓸게 많다. 하지만 내마음대로 주무를 수 있다.
저장소 , 알럿 시스템 구축, 화면 시각화도 어떻게 할지 고민.
그럼 어떠한 것을 고려해서 구축해야 할까?
Server 모니터링
수집부
모든 Server가 모니터링 수집부로 특정 기간마다 데이터를 전송하는 방법.
서버가 데이터가 주기적으로 안 들어오면 다운으로 인지.
Network
단점1. 모든 서버의 Outbound Por...
Server 모니터링
서버
대부분의 서버는 Private 영역에 존재한다.
모든 아웃바운드 포트를 열지 말고 Proxy를 통해서 열도록 할것.
Network
단점. 네트워크 가용성이 좋지 않으면, Server도 다운 된...
가용성에 대한 고민이 필요!!
서버 가용성과 네트워크 가용성을 분리해야 한다!
네크워크 가용성은 무시할 것인가? 아니면 받아들일 것인가?
가용성 정책을 분리! (네트워크 가용성 / 서버 다운을 분리)
Server
모니터링 서버
특정시간 동안 Device로 응답이 없으면, 네트워크 가용성의 문제로 인식
특히 모든 디바이스가 동시에 데이터가 안들어오면 네트워...
고객의 Network 존에, 서버 다운을 체크하는 시스템 설치 (push 보다는 pull 모델 지원)
Server
Smart Device
(Proxy)
1. Proxy에서 모든 Device의 데이터가 전송됨
2. 데이터...
#2. 어떤 데이터를 수집해야 하나?
서버 단에서 봐야하는 자원 병목 포인트
DRAM DRAM
Disk Disk Port Port
CPU
Interconnect
Memory
Bus
CPU
2
Expander Interconnect
Network
Contro...
60초안에 서버 성능 보기.
http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. ...
어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는...
USE 메소드의 예
Resource Type Metric
CPU utilization CPU utilization
CPU saturation run-queue length
Memory utilization Availab...
USE 메소드의 예.
Resource Utilization Saturation Errors
CPU mpstat-PALL1,	
sumnon-idlefields
vmstat1,"r" perf
Memory
Capacity
f...
주의할 점 MemFree vs MemoryAvailable.
cat /proc/meminfo
MemFree보다
MemAvailable을 이용하세요.
Ubuntu 14.04이상
MemFree:
The amount of p...
모든 자원 사용의 주체는 프로세스
#3. 프로세스를 모니터링 해라! ­ 가능한 상세히..
프로세스를 그룹별로 모니터링할수 있어야 한다!
프로세스 그룹별 정책
• 프로세스 최소 수, 최대 수
• 프로세스 그룹이 사용하는 CPU 사용량
• 프로세스 그룹이 사용하는 메모리 사용량
#4. TCP Connection 상태도 모니터링 해라
특히 CLOSE_WAIT를 주의깊게 살펴라..
#5. 운영시 최소한 챙겨야 하는 이벤트 (윈도우)
윈도우 EventID 윈도우 비스타 EventID 이벤트 타입 설명
512, 513, 514, 515, 516,
518, 519, 520
4608, 4609, 4610...
운영시 최소 한 챙겨야 하는 syslog (리눅스)
/var/log/messages : General message and system related stuff
/var/log/auth.log : Authenicatio...
#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 1715...
Docker에서 수집할수 있는 지표들 (제한적.)
v 위 이미지는 A사가 제공하는 지표
v 실제 공식 Docker runtime 매트릭
v https://docs.docker.com/v1.8/engine/articles...
현실적인 방안은
1 docker on 1 instance..
시스템 운영자가
친숙하게 사용하는
지표가 아직 미제공..
#7. 모니터링 수집 DB는 RDBMS가 적합하지 않습니다.
v RDBMS는 태생이 Read가 많은 서비스에 적합. -> 모니터링은 Time Series DB가 적합하다.
v 이에 반해 모니터링은 Write가 압도적으로...
#8. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘..
HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다.
(여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)
모니터링의 부하를 적게 주기 위해서.
Golang을 agent로 사용하는 것이 추세.
#9. 가용성 (가용률에 대한 서비스 불능 시간)
가용률 연간 서비스 불능시간 월간 서비스 불능시간 주간 서비스 불능시간
99.9999% 31.50초 2.59초 0.605초
99.999% 5.26분 24.9초 6.05초...
가용성의 함정.
가축들을 키울땐 전혀 다른 농장(클라우드) 2 군데에서 분산해서 키워라.
가능하다면,아니 여력이 된다면, 업체도 상이하게…
오픈소스 만으로도
구축하는데 시간이
한참 걸립니다.
여력이 되시는 분은
구축을..
#10. Web Application의
최적의 성능 지표 찾기!
- 51 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
자원은 노는데, 장애가 난다면..
반면, WAS의 CPU, Memory 사용량은 정상
종료되지 않고 지연중인
...
드리고 싶은 말씀!
완벽한 서비스를 위해서는
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. 의...
주기적으로 스택을 덤프뜨자..
Thread Dump Thread Dump Thread Dump Thread Dump
Transaction
SQL SQL
Http
File
Transaction
SQL SQL
Http
Fi...
- 74 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
개별 트랜잭션별 스택분석으로. 자주 걸리는 부분이 성능의 저하 구간
#11. 올바른 모니터링 프로세스
신속성
문제 인지 위치 파악 임시 조치
문제 분석 문제 해결
정확성
현황 파악
현황 파악
응답 시간 기준
Topology 위주로 빠르게 인지.
데이터 기반 인지
문제 인지
성능 차트/데이터, 실시간, 전문가
이벤트(경고) 기반 인지
알람 / 경고 메세지, 메일 / SMS, 임계값
SYSTEM
WAS
INSTANCE
이벤트 기반
데이터 기반
시간
중요이벤트 기반
비 경험 장애
대응 가능
데이터 기반
실시간 임계값
인식 방법의 비교
데이터 량 해석능력 자동 임계 경험적 임계
안정화 필요 전문성
비 전문가
운영 가능
서비스 제어
서비스 봉쇄
서비스 제한
트랜잭션 멈춤
인프라 제어
재기동
리소스 증설
클라우드 Scale Out
임시 조치
Throttling
Blocking
IP 제한
URL 제한
서비스 제어 - Transaction Throttling
동시 처리 제한
제한 예외 (무조건 통과)
- 83 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
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체크로
인스턴스 제어.
• 즉 고객 ...
결론.. 직접 위 사항들을 다 고려해서 만드시거나..
아니면 위 고민이 다 반영되어 있은 저희 제품을 구매하시거나..
- 90 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
스타트업을 위한 가격
10만원 67% 할인 : Infra 모니터닝 10 VM (1달 = 5만원) + APM (...
참고한 글
• https://www.slideshare.net/brendangregg
• https://www.slideshare.net/mobile/brendangregg/performance
-use-method
•...
Upcoming SlideShare
Loading in …5
×

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

24,866 views

Published on

와탭 랩스. 클라우드 환경에서 알아야할 성능 이야기.

Published in: Technology
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Girls for sex are waiting for you https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Meetings for sex in your area are there: https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. 클라우드 환경에서 알아야 성능 이야기. 그리고 모니터링 시스템 구축시 유의 사항. 와탭 CPO 손영수
  2. 2. 장애가 났을때.. 우리의 대처 방법 Top 2nd Level 1st Level traceroute 찍어봐요. 어 재현되지 않네요? Network 문제도 아니네? CPU도 별 문제 없는데? 내가 만든 어플리케이션 문제인가봐..
  3. 3. 개발자/ 운영자가 그럴수 밖에 없는 이유!!
  4. 4. Application System Call Interface File System Block Device Interface Storage Device Drivers Storage Devices 서버 단에서만 봐도 문제의 지점을 찾기가 힘들다..
  5. 5. 자.. 그럼 우리가 더 고민해야 할 이야기..
  6. 6. 클라우드는 ...
  7. 7. 클라우드는 공유 자원..
  8. 8. 클라우드는 공유 자원.. 요청이 많으면 즉 내 차례를 기다리거나..
  9. 9. 클라우드는 공유 자원.. 상황에 맞게 제한된 자원을 나눠가지 던가..
  10. 10. 잘 동작하던 게임서버에서 User들이 갑자기 튕겨나간 사례.
  11. 11. 알고보니 자원 공유 제약.. IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우드에선 늘 발생할 수 있는 문제.. 몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정
  12. 12. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Provisioned IOPS 구입!
  13. 13. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Premium Storage Disk 구입!
  14. 14. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개. § IOPS § Disk Queue Length (win) / iowait (linux) § CPU Steal Time 등.. § http://bencane.com/2012/08/06/troubleshooting-high- io-wait-in-linux/
  15. 15. 클라우드 모니터링은 인스턴스를 애완동물보다 가축으로 보아야 한다. (Server , VM vs Cloud Instance)
  16. 16. 클라우드 에서의 성능 측정이 어려운 이유.. 첫째, 일부 부분은 우리가 통제할 수 없다. 우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만 어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다. 우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나 단절 되는 이유를 알아내기 매우 힘들다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  17. 17. 클라우드 에서의 성능 측정.. 둘째, 일부 성능 측정 도구는 작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다. 점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서, 운영 대시보드와 경보기를 엄청나게 설치하지 않는다면 작은 오버헤드와 이용할 수 있는 성능 정보를 얻는 것은 어려워지고 있다. 많은 수의 서버에서 발생하는 문제를 추적 할 수 있는 능력은 더더욱 중요시 되고 있다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  18. 18. 클라우드 에서의 성능 측정.. 셋째, 클라우드 환경은 탄력성(scale in/out, lambda)이 있어서 일부 성능 최적화 기술은 시대의 뒤처지거나 관련 없다. 특정 프로세서, 메모리 크기, 네트워크 설정 또는 특정 클라우드 업체에 얽매어 있을 필 요가 없다. 과거에 사용하던 설정은 다시는 투자 대비 성과 (ROI)를 얻을 수 없다. 다른 설정을 해야 수십 억을 서버에 쓰지 않고 배포를 최적화할 수 있다. Sasha Goldshtein Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
  19. 19. 모니터링 구축에 사용할 수 있는 오픈 소스 툴들.
  20. 20. 직접 구축시 생각보다 신경쓸게 많다. 하지만 내마음대로 주무를 수 있다. 저장소 , 알럿 시스템 구축, 화면 시각화도 어떻게 할지 고민. 그럼 어떠한 것을 고려해서 구축해야 할까?
  21. 21. Server 모니터링 수집부 모든 Server가 모니터링 수집부로 특정 기간마다 데이터를 전송하는 방법. 서버가 데이터가 주기적으로 안 들어오면 다운으로 인지. Network 단점1. 모든 서버의 Outbound Port를 열어야 한다. 단점2. 네트워크 가용성이 좋지 않으면, 서버도 다운 된 것으로 인지.. #1. 알럿 정책
  22. 22. Server 모니터링 서버 대부분의 서버는 Private 영역에 존재한다. 모든 아웃바운드 포트를 열지 말고 Proxy를 통해서 열도록 할것. Network 단점. 네트워크 가용성이 좋지 않으면, Server도 다운 된 것으로 인지.. Proxy
  23. 23. 가용성에 대한 고민이 필요!! 서버 가용성과 네트워크 가용성을 분리해야 한다! 네크워크 가용성은 무시할 것인가? 아니면 받아들일 것인가?
  24. 24. 가용성 정책을 분리! (네트워크 가용성 / 서버 다운을 분리) Server 모니터링 서버 특정시간 동안 Device로 응답이 없으면, 네트워크 가용성의 문제로 인식 특히 모든 디바이스가 동시에 데이터가 안들어오면 네트워크 문제일 확율 90% 이상 Network Proxy Network 단절 발생 즉 데이터 없음으로 서버 다운으로 인식하지 마세요!
  25. 25. 고객의 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
  26. 26. #2. 어떤 데이터를 수집해야 하나?
  27. 27. 서버 단에서 봐야하는 자원 병목 포인트 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
  28. 28. 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
  29. 29. 어려운 방법보다 USE 메소드를 이용. Saturation Utilization X Errors Utilization : 얼만큼 자원을 썼는지? Saturation : 얼마나 많은 부하(extra works)가 들어왔는지. Error : 발생한 에러는?
  30. 30. 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
  31. 31. 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"
  32. 32. 주의할 점 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
  33. 33. 모든 자원 사용의 주체는 프로세스 #3. 프로세스를 모니터링 해라! ­ 가능한 상세히..
  34. 34. 프로세스를 그룹별로 모니터링할수 있어야 한다! 프로세스 그룹별 정책 • 프로세스 최소 수, 최대 수 • 프로세스 그룹이 사용하는 CPU 사용량 • 프로세스 그룹이 사용하는 메모리 사용량
  35. 35. #4. TCP Connection 상태도 모니터링 해라 특히 CLOSE_WAIT를 주의깊게 살펴라..
  36. 36. #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
  37. 37. 운영시 최소 한 챙겨야 하는 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 를 참고
  38. 38. #6. Docker 도입시 고민해야 할 것. Host 기반 Docker 기반
  39. 39. Docker에서 자원에 대한 정보를 얻어오면 몇몇 지표는 Docker의 자원 사용량이 아닌, Host OS의 정보를 얻어온다..
  40. 40. 결국 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
  41. 41. Docker에서 수집할수 있는 지표들 (제한적.) v 위 이미지는 A사가 제공하는 지표 v 실제 공식 Docker runtime 매트릭 v https://docs.docker.com/v1.8/engine/articles/runmetrics/
  42. 42. 현실적인 방안은 1 docker on 1 instance.. 시스템 운영자가 친숙하게 사용하는 지표가 아직 미제공..
  43. 43. #7. 모니터링 수집 DB는 RDBMS가 적합하지 않습니다. v RDBMS는 태생이 Read가 많은 서비스에 적합. -> 모니터링은 Time Series DB가 적합하다. v 이에 반해 모니터링은 Write가 압도적으로 많고, 대부분 시간 순서도 데이터를 읽음. v Memory 비용 비쌈. -> 1G에 월 1만원이 시장가격
  44. 44. #8. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘.. HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다. (여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)
  45. 45. 모니터링의 부하를 적게 주기 위해서. Golang을 agent로 사용하는 것이 추세.
  46. 46. #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시간 내외
  47. 47. 가용성의 함정.
  48. 48. 가축들을 키울땐 전혀 다른 농장(클라우드) 2 군데에서 분산해서 키워라. 가능하다면,아니 여력이 된다면, 업체도 상이하게…
  49. 49. 오픈소스 만으로도 구축하는데 시간이 한참 걸립니다. 여력이 되시는 분은 구축을..
  50. 50. #10. Web Application의 최적의 성능 지표 찾기!
  51. 51. - 51 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved. 자원은 노는데, 장애가 난다면.. 반면, WAS의 CPU, Memory 사용량은 정상 종료되지 않고 지연중인 트랜잭션 500개 이상 트랜잭션 지연트랜잭션 지연
  52. 52. 드리고 싶은 말씀! 완벽한 서비스를 위해서는 Developer DBA System Engineer
  53. 53. 웹 서버 성능의 기준은 logNormal 응답시간이 0에 수렴할수록 좋은 서버
  54. 54. 무수하게 많은 트랜잭션을 잘 분석하는게 중요 3:04 3:05 3:06 3:07 40초 80초 10초
  55. 55. 무수하게 많은 트랜잭션을 표현하는 좋은 지표 찾기 § 평균 응답시간 § 백분위 기준 § 분포..
  56. 56. 평균 응답시간 ­ 과연 최적의 표현??
  57. 57. 평균 응답시간 ­ 이렇게 표현 된다면.. 양이 문제를 가린다.
  58. 58. 평균의 종류 § 3.42 (24/7) = Mean : 여러분이 알고 있는 산술 평균 § 3 = Median : 가운데 자리에 있는 수 § 3 = Mode : 최빈값 (가장 많이 나온수) 1,2,3,3,4,5,6 의 평균
  59. 59. logNormal에서는 평균이 이렇게 왜곡됩니다.
  60. 60. 그럼 백분위 기준 - 빠른 순서 상위 10%, 상위 95 % (or 하위 5%)
  61. 61. 백분위 기준 에서 만날수 있는 데이터 왜곡 현상. (알고보니 다른 workload 3종류 중 한 종류가 잠시 안 들어옴)
  62. 62. 그래서 왜곡없이 분포로 모든 데이터를 표현해야 한다..
  63. 63. 하지만 SaaS형 APM 툴은 분포를 사용하기 힘들다.. § 엄청난 데이터 량를 전송 § TPS (초당 트랜잭션) § 트랜잭션당 프로파일링 정보.. § + … § 보안 문제 § …
  64. 64. 그래서 다른 SaaS형 APM은 이렇게 보여줌.. (N사 - 분포를 포기.. 평균..)
  65. 65. 그래서 다른 SaaS형 APM은 이렇게 보여줌.. (A사 ­ 어플리케이션 성능보다 클라우드적인 관점 )
  66. 66. 그에 대한 와탭의 고민.. 분포를 표현하는 이상적인 방법 구간(5초 단위) + 빈도 (진하기) 이러면 훨씬 적은 데이터로.. 분포 표현 가능
  67. 67. #11. 트랜잭션에서 병목을 찾는 방법 (Static + Dynamic Profiling) User MEM CPU GC SQL CONN CONN
  68. 68. Transaction A SQL SQL Http File User 과거에는.. 트랜잭션 장애의 병목 원인의 70%는 DB..
  69. 69. DB 관련된 것만 미리 잘 Hooking 하면 많은 문제 해결됨. User MEM CPU GC SQL SQL SQL SQLCONN CONN
  70. 70. 하지만 - NoSQL의 범람 , MSA의 강화 등. - 결국 메소드 프로파일링을 얼마나 잘하느냐의 싸움.
  71. 71. 트랜잭션 추적에서 Blind 영역이 늘어감.. User MEM CPU GC SQL CONN CONN
  72. 72. 일반적인 해결책은 Static + Dynamic Profiling User MEM CPU GC SQL CONN CONN Static Profiling Static Profiling Static Profiling 1. 의심되는 메소드 지정 (Dynamic Profiling) 2. 의심되는 메소드 지정 4. 의심되는 메소드 지정
  73. 73. 주기적으로 스택을 덤프뜨자.. 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
  74. 74. - 74 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved. 개별 트랜잭션별 스택분석으로. 자주 걸리는 부분이 성능의 저하 구간
  75. 75. #11. 올바른 모니터링 프로세스 신속성 문제 인지 위치 파악 임시 조치 문제 분석 문제 해결 정확성 현황 파악
  76. 76. 현황 파악
  77. 77. 응답 시간 기준
  78. 78. Topology 위주로 빠르게 인지.
  79. 79. 데이터 기반 인지 문제 인지 성능 차트/데이터, 실시간, 전문가 이벤트(경고) 기반 인지 알람 / 경고 메세지, 메일 / SMS, 임계값 SYSTEM WAS INSTANCE
  80. 80. 이벤트 기반 데이터 기반 시간 중요이벤트 기반 비 경험 장애 대응 가능 데이터 기반 실시간 임계값 인식 방법의 비교 데이터 량 해석능력 자동 임계 경험적 임계 안정화 필요 전문성 비 전문가 운영 가능
  81. 81. 서비스 제어 서비스 봉쇄 서비스 제한 트랜잭션 멈춤 인프라 제어 재기동 리소스 증설 클라우드 Scale Out 임시 조치
  82. 82. Throttling Blocking IP 제한 URL 제한 서비스 제어 - Transaction Throttling 동시 처리 제한 제한 예외 (무조건 통과)
  83. 83. - 83 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved. Circuit Breaker (Throttling) 기능은 이제 필수..
  84. 84. #12. Auto Scaling을 너무 믿지 마세요.
  85. 85. 반면, WAS의 CPU, Memory 사용량은 정상 종료되지 않고 지연중인 트랜잭션 500개 이상 트랜잭션 지연트랜잭션 지연 실제 고객은 느린 응답시간을 얻고 있지만, 자원이 놀고 있다면…
  86. 86. web app server Elastic Load Balancing 다행히 CPU가 높아지면 Scale Out
  87. 87. web app server Elastic Load Balancing 하지만 여전히 고객입장에서는 장애로 인식. web app server
  88. 88. 이유.. • Public Cloud의 LB는 두가지 알고리즘 제공 • Round Robin • Sticky Session • 별도의 Health Check가 있으나. 서버와의 ping체크로 인스턴스 제어. • 즉 고객 서비스의 응답시간으로 측정할 방법 없음.
  89. 89. 결론.. 직접 위 사항들을 다 고려해서 만드시거나.. 아니면 위 고민이 다 반영되어 있은 저희 제품을 구매하시거나..
  90. 90. - 90 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved. 스타트업을 위한 가격 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만원..
  91. 91. 참고한 글 • https://www.slideshare.net/brendangregg • https://www.slideshare.net/mobile/brendangregg/performance -use-method • https://www.slideshare.net/brendangregg/container- performance-analysis

×