SlideShare a Scribd company logo
클라우드 환경에서 알아야 성능 이야기.
그리고 모니터링 시스템 구축시 유의 사항.
와탭 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
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
클라우드 에서의 성능 측정..
셋째,
클라우드 환경은 탄력성(scale in/out, lambda)이 있어서
일부 성능 최적화 기술은 시대의 뒤처지거나 관련 없다.
특정 프로세서, 메모리 크기, 네트워크 설정 또는 특정 클라우드 업체에 얽매어 있을 필
요가 없다.
과거에 사용하던 설정은 다시는 투자 대비 성과 (ROI)를 얻을 수 없다.
다른 설정을 해야 수십 억을 서버에 쓰지 않고 배포를 최적화할 수 있다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
모니터링 구축에 사용할 수 있는 오픈 소스 툴들.
직접 구축시 생각보다 신경쓸게 많다. 하지만 내마음대로 주무를 수 있다.
저장소 , 알럿 시스템 구축, 화면 시각화도 어떻게 할지 고민.
그럼 어떠한 것을 고려해서 구축해야 할까?
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)
2. 의심되는 메소드 지정
4. 의심되는 메소드 지정
주기적으로 스택을 덤프뜨자..
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 - 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 (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

More Related Content

What's hot

쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
Amazon Web Services Korea
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
중선 곽
 
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Web Services Korea
 
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
Amazon Web Services Korea
 
Introduction to AWS IAM
Introduction to AWS IAMIntroduction to AWS IAM
Introduction to AWS IAM
Knoldus Inc.
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) 마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
Amazon Web Services Korea
 
Deep dive into AWS IAM
Deep dive into AWS IAMDeep dive into AWS IAM
Deep dive into AWS IAM
Amazon Web Services
 
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
Amazon Web Services Korea
 
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
Amazon Web Services Korea
 
7. 게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
7.	게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...7.	게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
7. 게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
Amazon Web Services Korea
 
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
Amazon Web Services Korea
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
AWSKRUG - AWS한국사용자모임
 
AWS IAM Introduction
AWS IAM IntroductionAWS IAM Introduction
AWS IAM Introduction
Amazon Web Services
 
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
Amazon Web Services Korea
 
Introduction to Amazon EKS
Introduction to Amazon EKSIntroduction to Amazon EKS
Introduction to Amazon EKS
Amazon Web Services
 
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Amazon Web Services Korea
 
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
Amazon Web Services Korea
 
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
Amazon Web Services Korea
 
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
Amazon Web Services Korea
 

What's hot (20)

쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
 
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
 
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
게임사를 위한 Amazon GameLift 세션 - 이정훈, AWS 솔루션즈 아키텍트
 
Introduction to AWS IAM
Introduction to AWS IAMIntroduction to AWS IAM
Introduction to AWS IAM
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) 마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
 
Deep dive into AWS IAM
Deep dive into AWS IAMDeep dive into AWS IAM
Deep dive into AWS IAM
 
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
아름답고 유연한 데이터 파이프라인 구축을 위한 Amazon Managed Workflow for Apache Airflow - 유다니엘 A...
 
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
게임서비스를 위한 ElastiCache 활용 전략 :: 구승모 솔루션즈 아키텍트 :: Gaming on AWS 2016
 
7. 게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
7.	게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...7.	게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
7. 게임 스트리밍 서비스를 위한 아키텍처 - 언리얼 엔진을 중심으로! [레벨 300] - 발표자: 하흥수, 솔루션즈 아키텍트, AWS :...
 
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
Amazon.com 의 개인화 추천 / 예측 기능을 우리도 써 봅시다. :: 심호진 - AWS Community Day 2019
 
AWS IAM Introduction
AWS IAM IntroductionAWS IAM Introduction
AWS IAM Introduction
 
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
Amazon SageMaker 모델 배포 방법 소개::김대근, AI/ML 스페셜리스트 솔루션즈 아키텍트, AWS::AWS AIML 스페셜 웨비나
 
Introduction to Amazon EKS
Introduction to Amazon EKSIntroduction to Amazon EKS
Introduction to Amazon EKS
 
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
 
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
 
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
AWS Fargate와 Amazon ECS를 사용한 CI/CD 베스트 프랙티스 - 유재석, AWS 솔루션즈 아키텍트 :: AWS Build...
 
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
 

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

클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
YoungSu Son
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST_NHNent
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptx
ssuserb8551e
 
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) 기술동향 소개-박문기@메ᄀ...
문기 박
 
Openstack Usecase(2018)
Openstack Usecase(2018)Openstack Usecase(2018)
Openstack Usecase(2018)
Gasida Seo
 
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
 
Infra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and TerraformInfra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and Terraform
Inho Kang
 
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
Gruter
 
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
Matthew (정재화)
 
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020 AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWSKRUG - AWS한국사용자모임
 
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
Jinwoong Kim
 
서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
수보 김
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
I Goo Lee
 
OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316기한 김
 
김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법성훈 김
 
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
 
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
Cyworld AppStore (SK Communications)
 
201702-Oracle Container Cloud Service
201702-Oracle Container Cloud Service201702-Oracle Container Cloud Service
201702-Oracle Container Cloud Service
오라클 클라우드
 
Oracle Container Cloud Service & Docker Overview
Oracle Container Cloud Service & Docker OverviewOracle Container Cloud Service & Docker Overview
Oracle Container Cloud Service & Docker Overview
Taewan Kim
 

Similar to 클라우드 환경에서 알아야할 성능 이야기 (20)

클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)TOAST Meetup2015 - 구름 Cloud IDE (류성태)
TOAST Meetup2015 - 구름 Cloud IDE (류성태)
 
[slideshare]k8s.pptx
[slideshare]k8s.pptx[slideshare]k8s.pptx
[slideshare]k8s.pptx
 
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) 기술동향 소개-박문기@메ᄀ...
 
Openstack Usecase(2018)
Openstack Usecase(2018)Openstack Usecase(2018)
Openstack Usecase(2018)
 
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
 
Infra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and TerraformInfra as Code with Packer, Ansible and Terraform
Infra as Code with Packer, Ansible and Terraform
 
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS스타트업사례로 본 로그 데이터분석 : Tajo on AWS
스타트업사례로 본 로그 데이터분석 : Tajo on AWS
 
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
스타트업 사례로 본 로그 데이터 분석 : Tajo on AWS
 
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020 AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
 
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
AWS기반 서버리스 데이터레이크 구축하기 - 김진웅 (SK C&C) :: AWS Community Day 2020
 
서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
 
OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316
 
김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법김성훈 - 뛰어난 디버거가 되는 방법
김성훈 - 뛰어난 디버거가 되는 방법
 
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
 
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
[2010 네이트 앱스토어 개발자 세미나] 앱스 제작 사례 (2) 소셜게임 서버 구성 전략
 
201702-Oracle Container Cloud Service
201702-Oracle Container Cloud Service201702-Oracle Container Cloud Service
201702-Oracle Container Cloud Service
 
Oracle Container Cloud Service & Docker Overview
Oracle Container Cloud Service & Docker OverviewOracle Container Cloud Service & Docker Overview
Oracle Container Cloud Service & Docker Overview
 

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
 
생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기) 생성 패턴 (강태우 - 소마에 10기)
생성 패턴 (강태우 - 소마에 10기)
YoungSu Son
 
초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드 초보 개발자/학생들을 위한 오픈소스 트랜드
초보 개발자/학생들을 위한 오픈소스 트랜드
YoungSu Son
 
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심) DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)
YoungSu Son
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
YoungSu Son
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
YoungSu Son
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
YoungSu Son
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
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
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
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
 

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 오픈소스 트랜드 (클라우드, 모바일 중심)
 
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) 모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101)
 
DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법 DevOps 시대가 요구하는 품질확보 방법
DevOps 시대가 요구하는 품질확보 방법
 
Android 성능 지표와 Oreo 의 개선사항
Android 성능 지표와  Oreo 의 개선사항 Android 성능 지표와  Oreo 의 개선사항
Android 성능 지표와 Oreo 의 개선사항
 
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법안드로이드 Oreo의 변화와  모바일 앱/플랫폼의 적합한 성능 측정 방법
안드로이드 Oreo의 변화와 모바일 앱/플랫폼의 적합한 성능 측정 방법
 
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
 
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기) FullStack 개발자 만들기 과정 소개  (Android + MEAN Stack + Redis 다루기)
FullStack 개발자 만들기 과정 소개 (Android + MEAN Stack + Redis 다루기)
 
[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 패턴 적용하기
 

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

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