모니터링 영역의 변천사

1. 모니터링 영역의 변천사
클라우드 부터, 디지털 경험까지
ONYCOM
CPO 손영수

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

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

4. 모니터링 영역

5. 순서
• 성능 개요
• 인프라(클라우드 모니터링)
• 어플리케이션 성능 모니터링
• DB 모니터링
• RUM -> DEM (앱, 웹 최적화 기법)
• DEM 모니터링 사례

6. 1부
6
성능 개요
All
That
Monitoring

7. 성능이란..
USER Machine

8. 성능이란..
USER Machine
응답시간
명령어 처리량
시간

9. 성능이란 (웹 어플리케이션)
USER Server
응답시간 TPS
초당 트랜잭션 처리수

10. 서버(Server) 와 모바일의 태생적 차이
기본 제약들 서버/웹서버 모바일
상시 전원 공급 ● X
CPU / GPU 쿨러 (발열 방지) ● X
앱이 돌아가는 환경 단일 OS/ 디바이스 파편화
OS 버전 업데이트 (주체) 개발/운영사가 제어 플랫폼 회사 / 소비자 제어
배포 주도권 / 반영 시간 개발 ,운영사 / 즉시
플랫폼 회사, 소비자 /
2~7일 (안할수도 있음)

11. 2부
11
인프라
모니터링
All
That
Monitoring

12. 모니터링 영역

13. Cloud
On-Premises
#1. 컴퓨팅 환경의 변화…

14. IDC
대기업은 기존 IDC, Private Cloud 비중이 많음
물론 서서히 Public Cloud를 쓰는 비중이 늘어나기는 함..

15. 인프라 환경 내부의 변화

16. 클라우드는 공유 자원..

17. 클라우드는 공유 자원..
요청이 많으면 즉 내 차례를 기다리거나..

18. VM의 Core 뻥튀기
Overcommit : 물리 CPU 4개 -> vcore : 4*16 = 64개

19. VM의 메모리 뻥튀기
Overcommit : Memory -> Virtual Memory = 1: 1.5

20. 클라우드는 공유 자원..
상황에 맞게 제한된 자원을 나눠가지
던가..

21. Cloud Harmony 를 보세요. https://cloudharmony.com/

22. 잘 동작하던 게임서버에서
User들이
갑자기 튕겨나간 사례.

23. 알고보니 자원 공유 제약..
IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우드에선 늘 발생할 수 있는 문제..
몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정

24. 해결책..
만약 A사 (AM?, AZ?)
제품이면 제값 주고
Provisioned IOPS 구입!

25. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troubleshooting-high-
io-wait-in-linux/

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

27. 어떤 성능 데이터를 수집해야 하나?

28. 서버 단에서 봐야하는 자원 병목 포인트
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

29. 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

30. 어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?

31. 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

32. 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"

33. New Relic인스턴스 모니터링

34. New Relic인스턴스 모니터링

35. New Relic 전체 모니터링

36. WhaTap인스턴스 모니터링

37. WhaTap 쿠버네티스 모니터링

38. NKIA - 서버 + ITSM 모니터링
(https://www.youtube.com/watch?v=BnAZduWeLH8)

39. 남는 자원은 어디인가?
적절히 자원을 배분했는가?
Right Sizing Problem

40. 3부
40
A P M
어플리케이션 성능 모니터링
All
That
Monitoring

41. 모니터링 영역

42. 웹 어플리케이션은 어떻게 동작하나?
User
Transaction
SQL SQL
Http
File
Resource
`

43. 실제 서비스는
자원을 사용
트랜잭션 처리
Transaction
SQL SQL
Http
File
Resource
`
수많은 유저

44. APM 화면

45. Transaction A
SQL SQL
Http
File
User
과거에는..
장애 원인의 70%는 DB..

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

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

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

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

50. 주기적으로 스택을 덤프뜨자..
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

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

52. 개발자를 위한 뷰 - 응답 시간 기준

53. 운영자를 위한 뷰 ­
Topology 위주로 빠르게 인지.

54. 4부
54
DB 모니터링
All
That
Monitoring

55. 모니터링 영역

56. 디비 모니터링의 주요기능

57. APM과 DB의 연계 기능
APM
DBP

58. DB 모니터링 (셀파)

59. DB 모니터링 (엑셈 - 맥스게이지)

60. 5부
60
디지털 경험 모니터링
All
That
Monitoring

61. 모니터링 영역

62. 모바일에서 성능이란
USER Mobile
UI 랜더링 시간 낮은 전력 소모량
시간

63. 3~4년 전 프론트엔드 (웹/모바일) 한국의
Enterprise 시장에서는 무슨 일이?
비용 절감 = Web App/ Hybrid App으로 가자.
Android, iOS, Web 언제 다 따로 만들어..

64. 대형 사건…
안드로이드 4.4 버전 이후부터
- Android Native 와 Chrome WebView의 분리.
안드로이드 5.0 이후부터.
- 타사 쿠키 차단, 혼합된 컨텐츠 차단
- HTML 문서 최적화를 통해 그릴 수 있는 부분만 지능적 선택(??)
WebView 컴포넌트 배포 권한은 구글이..
- 왜 네이버는 별도의 브라우저를 만들었을까?

65. WebView가 가져오는 악재들.

66. 6
6
https://medium.com/braus-blog/airbnb-is-dropping-react-js-should-you-too-dcbff36def5c
Go Native!!!
Hybrid App의 수호자 AirBnb의 메세지..

67. 6
7
왜 카카오 뱅크는 Native로 개발했나..

68. S 은행은 발빠르게 2채널 전략
- 많은 기능, 다양한 상품은 Native로
- 간단한 것들은 Web View 로…
다른 은행들의 차세대의 중심이 모바일로 재편
- K은행
- G은행 등 차세대 준비.
2,3 금융권은 웹뷰와 네이티브가 병행
다른 은행 (1 금융권)들은..

69. 잘못된 만남.. (철학의 부조화)

70. 앱 UI Rendering

71. Vsync 란 (60fps = 16ms의 중요성)

72. Web Browser 랜더링 프로세스

73. DOM TREE 구성

74. DOM TREE 구성

75. CSS SOM 구성

76. Render Tree 만들기
안보여도 되는 객체는
Visibility:invisible 보다는
Display:none 사용 권장

77. Layout ­ 레이어를 구성한다

78. Layout
브라우저 화면 어느 위치에 그려질지 계산하는 단계

79. Layout
계산된 스타일이 있는 DOM 트리를 돌며 레이아웃 트리를 생
성

80. Paint (GPU 개입)
각 요소에 배경색, 글자 색과 같이 픽셀을 채우는 과정입니다.
레이아웃 트리를 순회하며 페인트 기록을 생성

81. 핵심 ­ 변경을 흡수
DOM 구성부터 페인팅 까지 열심히
작업해서 화면에 표시.
브라우저를 스크롤하거나 줌하거나
자바스크립트 코드로 문서를 변경해
버리면, 다시 이미지를 렌더링
그래서 다 그리지 않고, 변경된 내용만
다시 그리는 것이 필요.
Reflow ­ Render Tree 부분 재구성

82. 핵심 ­ 변경을 흡수
Reflow (Render Tree 재구성) 가 일어나는 대표적인 경우
- 페이지 초기 렌더링 시(최초 Layout 과정)
- 윈도우 리사이징 시 (Viewport 크기 변경시)
- 노드 추가 또는 제거
- 요소의 위치, 크기 변경
(left, top, margin, padding, border, width, height 등..)
- 폰트 변경 과(텍스트 내용) 이미지 크기 변경(크기가 다른 이미지로 변
경 시)
Repaint (Render Tree를 다시 화면에 그려주는 과정)
- 레이아웃에는 영향을 주지 않는 스타일 속성만 변경 시 Repaint만 수행
(background-color, visibility..)

83. 문제는 이러한 업데이트가
16ms(60fps)안에 실행하도록 권고.

84. 그래서 Invalidation 도입
렌더링 파이프라인 단계 별로 'invalidation' 즉 유효성을 검사해서 업데이트
가 필요한 부분의 데이터만 변경

85. 더 성능을 끌어올리기 위해 Compostion도입
유효성 검사로만으로는 성능개선의 어려움
화면을 구성하는 요소를 레이어 별로 쪼개서 이미지를 만든 뒤 화면에 합
쳐서 표현하는 방법을 '레이어 합성’.
일부 이미지 변경으로 전체를 다시 그리기보다 일부 레이어만 다시 그리기

86. 꽉찬 화면 이면 어떻게 하나? (Tiling – 타일링 / Layer Tiling)
화면을 거의 차지하는 스크롤 레이어가 있다면 레이어가 너무 커서 레이어 합성의 효과가 미미
한개의 레이어를 더 작은 단위인 타일로 쪼개고 타일의 위치나 특성에 따라 우선순위를 매겨 각 타일별 이
미지를 만듭니다

87. Web Browser 랜더링 프로세스
출처) 모질라 퀀텀 CSS 엔진 - https://cutt.ly/5maHEKM

88. 브라우저기준의 성능 측정하기
DOMContentLoaded 이벤트
HTML과 CSS 파싱이 끝나는 시점
렌더 트리를 구성할 준비가 된(DOM 및 CSSOM 구성이 끝난) 상황
load 이벤트
HTML 상에 필요한 모든 리소스가 로드된 시점

89. 크롬 개발자 도구에서 보면..
DOM 구성 1.79초, 화면 리소스가 로드된 시점 2.3초

91. 수집 지표와의 연관관계

92. 사용자 입장에서는..
DOMContentLoaded, load 이벤트가 같은 시점에 발생했으나..
사용자 기준에서 다르게 느낀다..

93. 사용자 입장에서의 지표. (이후 반영 예정)
FP(First Paint)
흰 화면에서 화면에 무언가가 처음으로 그려지기 시작하는 순간.
FCP(First Contentful Paint)
텍스트나 이미지가 출력되기 시작하는 순간.
FMP(First Meaningful Paint)
사용자에게 의미 있는 콘텐츠가 그려지기 시작하는 첫 순간. 콘텐츠를 노출하는데
필요한 CSS, 자바스크립트 로드가 시작되고 스타일이 적용되어 주요 콘텐츠를 읽을
수 있다.
TTI(Time to Interactive)
자바스크립트의 초기 실행이 완료되어서 사용자가 직접 행동을 취할 수 있는 순간
이다.

94. New Relic - RUM

95. New Relic - RUM

96. New Relic - RUM

97. IMQA – 늦은 화면 찾기

98. IMQA – 웹뷰 분석

99. IMQA – 사용자의 여정 트래킹

100. 6부
100
디지털 경험
모니터링 사례
All
That
Monitoring

102. 성능적 관점

103. • C
PU
U
sage
• M
EM
O
R
Y
U
sage

104. N
etw
ork
U
sage
U
R
L
설
명

108. 성능 저하 후보군 (WebView 랜더링) - K사 사례
• 웹뷰 화면 로딩 시간이 오래 걸림
• 50%의 사용자는 2.2초 내에 응답을 받으나 하위 5% 사용자는 7초 이상의 화면 로딩 시간이 걸림
(즉 100명중에 5명은 7초 이상의 화면 랜더링 시간이 걸림)

109. xxx.com/mweb/event/eventView/EVT*MARED.do
• 화면 js 다운로드 시간이 오래 걸림
내부 웹 서버에서 통신해서 받는 것으로 보이며 대기보다는 다운로
드시간이 많이 걸림
• 이미지 다운로드 문제
이미지 다운로드 시간이 20초 이상 걸림
대기 시간이 18초 이상 소요 / 실 다운로드는 2초
• 해결 방안
.(영속적으로 계속 사용하는 라이브러리라면) 주요 라이브러리는 앱
에 임포트 시켜서 배포하는 형태를 권장함
웹뷰 화면 로딩 시간 지연 케이스 – JS 다운로드 이슈

110. https://xxx.com/mweb/cart/cart_normal.do
• 카트에 많은 상품을 담았을 경우, UPLOAD폴더에서 이미지를 다운로드 받아 화면에 랜더링 하는 것으로 추정
몇몇 이미지가 다운로드가 느려도 , 전체가 다 느려지는 상황이 발생함.
웹뷰 화면 로딩 시간 지연 케이스 예시 – 무거운 이미지

111. https://xxx.com/mweb/cart/cart_normal.do
• Facebook Event 로 정보를 전송 중에 오류가 발생함.
내부적인 문제보다는 외부 Facebook의 이슈로 보이며 다른 회사에서도 종종 발생하는 문제
실제 많은 모바일 앱이 kakao id 로그인, 외부 서비스와 연동 인터페이스 오류로 많이 지연됨.
• SNS와 같은 Third Party 연동의 경우 native 영역으로 바꿀수 있을지 체크 필요
웹뷰 화면 로딩 시간 지연 케이스 예시 – 외부 라이브러리 이슈

112. 참고자료
• 렌더러 프로세스의 내부 동작
https://d2.naver
.com/helloworld/5237120
• 크롬 랜더링 이해하기 - https://cutt.ly/hmaGzHW
• Reflow, Repaint 성능 최적화 - https://boxfoxs.tistory.com/408
• 웹 성능 최적화 - https://ui.toast.com/fe-guide/ko_PERFORMANCE
• 성능 최적화 - https://ui.toast.com/fe-guide/ko_PERFORMANCE

113. 모니터링 영역

114. THANK YOU!
ysson@onycom.com
성능에 관심있는 분은
KPPG (Korea Pattern & Performance Group)
페이스북 그룹으로..