<div id="readability-page-1" class="page"><div id="entry-view">
 
 <main>
 <div>
 <article id="mainContent">
 <div>
 <a href="/m/category/%EB%AD%94%EA%B0%80%EB%A5%BC%20%EB%B4%A4%EA%B1%B0%EB%82%98%20%ED%96%88%EB%8B%A4%EB%A9%B4%20%EC%98%AC%EB%A6%AC%EB%8A%94%20%EC%B9%B4%ED%85%8C%EA%B3%A0%EB%A6%AC">뭔가를 봤거나 했다면 올리는 카테고리</a><h3>datadog - gs리테일 웨비나 : 어느날 갑자기 찾아온 Datadog, DevOps 변화의 시작</h3>
 </div>
 <cite>Berno</cite>
 2022. 5. 27. 15:21
 
 
 
 <div>
 <blockquote data-ke-style="style1">웨비나를 보며 빠르게 정리한거라 두서 및 오타, 부정확한 단어 사용 있음 주의!</blockquote>



웨비나 제목 : 어느날 갑자기 찾아온 Datadog, DevOps 변화의 시작
주제 : gs리테일에서는 datadog을 실무에서 어떻게 사용하나 (이거 보고 당근마켓 영상도 보면 좋을듯!)

agenda
1. intro
2. gs 리테일 서비스 소개
3. gs 리테일 datadog 적용 배경 및 활용 범위
4. 트러블 슈팅을 위한 datadog 실 활용사례 소개 with gs retail
5. qna


<h3 data-ke-size="size23">gs 리테일 서비스 소개</h3>
<ul data-ke-list-type="disc">
<li>오프라인 쇼핑(gs25, gs the fresh, 랄라블라)</li>
<li>온라인 o2o, o4o (더 팝, 나만의 냉장고, 와인25...)</li>
<li>온라인 커머스, 홈쇼핑 (gs shop, gs fresh,&nbsp; marketfor, dailsalda)</li>
<li>aws 클라우드로 가는 중</li>
<li>react, view single</li>
<li>app은 flutter 많이 사용</li>
<li>backend는 node.js 많이 사용</li>
</ul>
<h3 data-ke-size="size23">datadog을 어디에 사용하는가</h3>
<ul data-ke-list-type="disc">
<li>&nbsp;application, eks k8s 등등...</li>
</ul>

<h3 data-ke-size="size23">datadog 도입 이전 장애가 발생한다면(적용배경)</h3>
<ul data-ke-list-type="disc">
<li>API단에서 에러 확인이 어렵고 어떤 쿼리를 사용했는지 로그의 양도 많아 분석이 어려움. </li>
<li>심지어 백엔드 단에서만 가능</li>
<li>이를 알기 위해 프론트, 클라이언트, 백엔드 팀 간의 핑퐁이 시작됨(서로 이거 되냐, 안되냐 물어보고 등등)</li>
<li>app/web(ui)의 경우 클라이언트 로그, 이벤트를 상세하게 수집하지 않아 더욱 어려움</li>
<li>--&gt; 장애 인지 및 원인 파악에 많은 시간이 소요됨 --&gt; 헬게이트 오픈&nbsp; --&gt; 비즈니스 손실이 커짐</li>
</ul>

on promise 환경..?(모르는 단어) 사일로..?(나중에 찾아서 글 정리 다시 하겠읍니다,,)

<ul data-ke-list-type="disc">
<li>어플리케이션과 인프라를 연계지어 볼 수 있는 툴이 없었음</li>
<li>ui는 spa 앱 기반으로 사용자 단말 브라우저 상에서 렌더링이 되는데 ui 모니터링 도구가 수립되어 있지 않아 ui 어플리케이션 상에서 에러를 파악할 방법이 없음(증상 재현을 통해서만 파악 가능)</li>
<li>각 시스템 별 담당자가 다르고 각 시스템의 연계 문제가 있어 핑퐁 진행</li>
</ul>


<h3 data-ke-size="size23">구성 목표</h3>
<ul data-ke-list-type="disc">
<li>서비스 전반에 대한 가시성 확보
<ul data-ke-list-type="disc">
<li>서버, 클라우드, 네트워크, 어플리케이션, 로그 등을 모두 한번에 엔지니어와 개발자가 같이 분석할 수 있는 모니터링 환경 구성</li>
</ul>
</li>
<li>다양한 자원을 한번에 모니터링
<ul data-ke-list-type="disc">
<li>모든 어플리케이션, 호스트, 컨테이너, aws 관리형 서비스, 네트워크등의 모든 자원의 상호 연관 관계를 조합하여 볼 수 있고 추적할 수 있는 환경</li>
</ul>
</li>
<li>실 서비스 이용자인 고객 관점의 모니터링 (end to end)
<ul data-ke-list-type="disc">
<li>실 사용자의 웹피이지 로딩, 지연, 에러 파악 및 api 호출 및 db 쿼리까지의 trace 기반 모니터링 체계 마련</li>
</ul>
</li>
<li>--&gt; 모든 인프라/어플리케이션 정보를 통합하여 각 파트가 같은 정보를 투명하게 공유하여 문제 해결의 속도를 높임</li>
<li>개발자 측면의 benefit
<ul data-ke-list-type="disc">
<li> 인프라 담당자와 각 클라이언트 개발자 간의 통합된 동일 정보 공유</li>
</ul>
</li>
</ul>

<h3 data-ke-size="size23">gs리테일의 datadog</h3>
<ul data-ke-list-type="disc">
<li>하나의 통합 모니터링 대시보드에서 infra, network, db 그리고 ui 어플리케이션, api 어플리케이션 등의 full stack 가시성을 제공하여 신속하게 문제가 해결될 수 있도록 함(통합된 뷰로 모든 tech 스택의 trace에 대한 시각화를 제공함)</li>
<li>api 병목 원인 파악, 로딩 에러 집계, 연관 관계 가시화, aws 관리형 서비스, 서버, 컨테이너 등의 인프라 자원을 통합 모니터링</li>
<li>데이터 관점의 api 분석</li>
<li>gs리테일 인프라는 public cloud, private cloud를 모두 같이 사용하는 하이브리드 아키텍쳐 구성, 다양한 인프라 인프라 환경으로 서비스</li>
<li>이중 public cloud의 telemetry 부분(Monitoring / diagnostics)에 datadog 사용</li>
<li>datadog의 dashboard중 service map기능을 이용해 서비스들간의 연계 구조 확인, 서비스간의 장애 발생 여부 바로 인지 가능, 알림 기능</li>
<li>서버에서 수행중인 process들의 리소스 점유량 쉽게 파악 가능</li>
<li>Process별 metric을 상세하게 파악 가능</li>
<li>--&gt; 빠르게 issue tracking 가능 --&gt; 장애 파악 시간 감소</li>
<li>aws ecs를 사용하는데 ecs monitoring을 위해 각각 보게 되면 불편하고 접근 권한이 있는 관리자만 볼 수 있는 것도 있었는데 이 모든걸 하나로 묶어 aws ecs monitoring이라는 기능을 제공하고 있어 전체적으로 볼 수 있고 각 컨테이너별로 확인하기도 용이</li>
<li>eks환경도 운용중인데 하나의 시스템당 2개 이상의 클러스터를 붙여 멀티 클러스터로 운영중임. aws eks도 마찬가지로 계정, 클러스터가 각각 나누어져 있어 이것들을 pod내 구성되는 어플리케이션과 쿠버네티스 메트릭을 연관지어 분석할 수 있는 kubernetes_pod으로 볼 수 있어 개발자와 인프라 담당자간 공유됭어 이슈 해결에 용이</li>
<li>aws eks monitoring을 이용해 k8s resource의 Restart time, metric을 쉽게 파악 가능, pod을 선택하면 매니패스트 확인 가능, event도 확인 가능하여 원인 파악 쉽게 가능(서버에 안 들어가도 됨!!!!)</li>
<li>단일 클러스터일때는 aws에서 제공해주는 monitor를 사용했는데 이제 멀티 클러스터가 되니까 위에 언급한대로 너무 확인할게 많고 번거로워서 datadog을 쓰면 참 편
<ul data-ke-list-type="disc">
<li>정확히는 k8s의 pod보다는 내부 워크로드를 봐야하는데 이걸 백엔드와 연관지어 봐야한다. 근데 aws에서 제공하는 기능은 이런게 없다. </li>
</ul>
</li>
<li>인프라 환경에서는 오픈소스 프로메테우스 등을 이용해 모니터링 하고 있었는데 장애가 나게 되면 1분 1초가 급한데 오픈소스를 이용해 직접 뭔가를 구성하면 이것 저것 다 직접 열어야 해서 시간도 걸림</li>
<li>이걸 datadog으로 하게 되니 그러지 않아도 됨. 대신 datadog의 기능을 이용하게 될 때 (뭐가 단점이라고 했는데 이게 안들리네...</li>
<li>네트워크 환경에서는 aws/on-promise 환경으로 사용중인데 트래픽 문제 등 여러 문제에 대해 이 문제도 네트워크 관리자와 다른 개발자간 정보 공유 및 협업이 필요했는데 datadog을 이용해 정보의 공유, 투명화가 가능해짐</li>
<li>각 네트워크 트래픽의 시각화 모니터링, 네트워크 맵의 시각화, flow확인 가능. 구간별 latency 쉽게 파악 가능. 특히 aws to on-promise 통신 시 전용선 트래픽이 급증할 경우 원인을 파악하기 위해 활용하기가 좋음</li>
<li>npm 과 apm을 같이 제공함</li>
</ul>
<h3 data-ke-size="size23">datadog rum(real user monitoring)</h3>
<ul data-ke-list-type="disc">
<li>datadog 도입 전 client단에서 분석할 수 없었는데 도입 후 client단에서 발생한 모니터링 지표를 session별 수집, 사용자 경험 추적(뭘 클릭했고, 뭘 입력했고 등등), 이슈 발생 원인 직관적 확인 가능 --&gt; 운영자가 직접 재현할 필요 없이 사용자 경험 추적으로 인해 자동으로 재현 가능(세션 리플레이)</li>
<li>rum을 이용해 대시보드에서 사용자의 증감 수치, 모든 에러 type, path 수집, 에러 발생 빈도가 높은 소스 발견 시 즉각 대응 가능</li>
<li>사용자가 증가된 view 식별 시 view RUM event를 통해 RUM 페이지에서 분석 진행</li>
</ul>
<h3 data-ke-size="size23">datadog apm</h3>
<ul data-ke-list-type="disc">
<li>전용 dashboard구성하여 api응답시간 분포도 위젯으로 응답시간 증가 여후 확인, 지연이 발생한 api리스트 확인, APM trace로 해당 API로 필터링하여 검색</li>
<li>Flame Graph로 응답시간을 가장 많이 소요하는 포인트 확인</li>
<li>third-party 솔루션에서는 필터링이 잘 안되었는데 여기서는 필터링 가능. 맞춤형으로 widget을 구성한 dashboard 만들기 가능.</li>
<li>APM Service Map 기능을 이요해 서비스 레벨 구분 및 WEB, WAS, DB의 연관 관계를 시각화 하여 볼 수 있으며 서비스 별 요청 건 수에 대해 확인 가능</li>
<li>APM Continuous Profiler</li>
<li>배포된 후 각 제품의 상태를 모니터링. Heap Dump, Thread Dump 후 별도 Tool로 분석하지 않아도 JVM을 쉽게 상세히 모니터링 가능</li>
<li>Compare기능이 있는데 현 시점의 배포 버전과 과거의 배포 버전의 기능, 성능을 비교하여 문제가 있는 경우 원인 분석을 용이하게 함.</li>
<li>--&gt; 이전에 쓰던 툴, 오픈소스가 있긴 한데 시장은 점점 x-view(?)형태로 변하고 있고 이제 어느 부분에 문제가 있는지, 뭐가 문제인지를 분석해야하고 조치를 해야하는데 요새 아키텍쳐가 점점 복잡도가 늘어나서 기존 방식으로는 한계가 있음. 뭐가 뭘 호출하고 어디에 있고 뭐가 문제인지 datadog을 이용해 stack trace까지 시각적이고 쉽고 자세히 분석 가능하고 그때 당시 pc의 성능, 상태까지 확인 가능.</li>
<li>APM DB Monitoring 구성하여 실시간으로 쿼리 에러 현황, 쿼리 수행 시간을 모니터링(쿼리 수행 시간 지연과 같은 에러 발생 포함) -&gt; 쿼리 정보로 분석 진행 가능</li>
</ul>

<h3 data-ke-size="size23">datadog Log Managament</h3>
위에서 언급한 서비스들에서 로그를 수집하는데 힘들었는데 이제 사용자가 viewer를 커스텀하여 필요한 로그들을 하나의 뷰로 수집해 이슈 원인 파악에 많은 도움이 됨(elk를 많이 사용하는데 이게 생각보다 비용이 많이 나온다. 보통 로그를 서버에 많이 저장하고 aws의 elastic search - open search 를 이용해 봤었는데 문제는 여기서 딜레마가 하나 온다. 로그가 엄청 많아지는데 여기서 성능을 올리려면 돈을 더 내고 elastic search의 스펙업을 해야한다. 비용이....)

<h3 data-ke-size="size23">datadog infra(알람)</h3>
<ul data-ke-list-type="disc">
<li>이슈 발생시 알람 발생. 특정 인계값 및 조건을 걸어 담당자가 바로 인지할 수 있도록 알람 구성 가능.</li>
<li>-&gt; 이 알람 사용 이후 장점 : aws는 이것도 비용이고 클라우드 엔지니어나 좀 받을 수 있었는데 실은 개발자도 받아야해서 이게 좀 부족함. 근데 datadog에서는 알람 받는 담장자, 조건, 내용 등의 구성이 자유로움.</li>
</ul>


<h3 data-ke-size="size23">datadog활용 사례를 통해 배우는 트러블 슈팅</h3>
트러블 슈팅 과정
적용 전
고객 - 운영자 - 개발자 - 장애인지 - 로그찾으러 서버 접속 - 다른 담당자와 핑퐁 - 시간 소요
적용 후
장애 발생 - 모니터링에 걸어둔 알람을 통해 담당자가 알람 받기 - 어느 포인트에서 발생했는지 확인 - 해당 포인트부터 원인 파악 및 조치

e.g.1 ios에서는 잘되는데 안드로이드에서는 안됨
- 비정상적 앱 배포 의심했으나 앱 배포를 하지 않았음을 확인
- RUM이벤트 세션에 많은 로그가 남아있어 android에서는 접속할 때 에러가 발생하며 연결이 실패하고 있다고 분석
- 장애 범위를 좁힘

e.g.2 azure windows vm에 asp.net으로 구성되어 있는 시스템에 잦은 지연이 발생함
- azure 모니터링 외 별도 모니터링 도구는 없었고 azure모니터링 지표로는 infra관련 지표만 확인 가능함
- dashboard 전주 대비 api 소요시간 위젯을 통해 요청 시간이 증가한 api 식별 및 리스트업화

e.g.3 앱이 느린데 어디가 느린지 모르겠어요
- 앱에서 지연이 간헐적으로 발생 (어떨 때는 빠르고 어떨 때는 느림)
- 앱은 영향을 받는 부분이 많아 구간이 매우 복잡하여 어디에서 병목이 발생했는지 확인도 어렵고 구조가 복잡할 수록 담당자도 많음)
- android나 ios에 datadog rum ios, aos sdk를 적용하여 배포
- datadog agent 데몬셋 구성, 설치, datadog java trace sdk 구성
- end to end를 검수(모니터링)해야 하는데 datadog적용으로 편-안
- ios는 app 심사에서 잠깐 발목이 잡힐 수 있으나 배포 했음
- 이제는 문제가 발생하면 고객의 시간(해당 문제가 발생한 로그의 시점)에서 부터 분석이 시작되기 때문에 빠르게 진행하고 이 로그를 각 담당자들이 투명하게 공유하기 때문에 더욱 빠르게 조치가 가능하다.

<h3 data-ke-size="size23">datadog 비용 최적화</h3>
<ul data-ke-list-type="disc">
<li>datadog 구성 완료 비용 효율화를 위해 RUM, APM, Log Management에서 발생하는 불필요한 리소스 수집 제외 작업 수행</li>
<li>log 수집 필터링을 통해 비용 절약</li>
<li>RUM에는 samplerate라는게 있어 세션 비율을 조절할 수 있음</li>
</ul>


qna중..
q. datadog이 러닝커브가 좀 있긴하다. 조언을 부탁한다.
a. 기존 다른 툴 사용하신거랑 크게 다를 것 없다. 조금만 공부하면 그 몇배의 효과를 보실 수 있다.
q. datadog을 사용할때 유의해야 될 점도 한마디 부탁한다.
a. datadog을 계정을 분리해서 사용하고 있는데 그 이유는 비용을 분리해서 계산하기 위함이다.

 
 
 </div>
 

 

 </article>
 
 
 
 
 
 
 
 </div>
 </main>
 
 </div></div>

흔한 컴공출신 개발자

bernoyoun

웨비나를 보며 빠르게 정리한거라 두서 및 오타, 부정확한 단어 사용 있음 주의!
 
 
 
웨비나 제목 : 어느날 갑자기 찾아온 Datadog, DevOps 변화의 시작
주제 : gs리테일에서는 datadog을 실무에서 어떻게 사용하나 (이거 보고 당근마켓 영상도 보면 좋을듯!)
 
agenda
1. intro
2. gs 리테일 서비스 소개
3. gs 리테일 datadog 적용 배경 및 활용 범위
4. 트러블 슈팅을 위한 datadog 실 활용사례 소개 with gs retail
5. qna
 
 
gs 리테일 서비스 소개
오프라인 쇼핑(gs25, gs the fresh, 랄라블라)
온라인 o2o, o4o (더 팝, 나만의 냉장고, 와인25...)
온라인 커머스, 홈쇼핑 (gs shop, gs fresh,  marketfor, dailsalda)
aws 클라우드로 가는 중
react, view single
app은 flutter 많이 사용
backend는 node.js 많이 사용
datadog을 어디에 사용하는가
 application, eks k8s 등등...
 
datadog 도입 이전 장애가 발생한다면(적용배경)
API단에서 에러 확인이 어렵고 어떤 쿼리를 사용했는지 로그의 양도 많아 분석이 어려움. 
심지어 백엔드 단에서만 가능
이를 알기 위해 프론트, 클라이언트, 백엔드 팀 간의 핑퐁이 시작됨(서로 이거 되냐, 안되냐 물어보고 등등)
app/web(ui)의 경우 클라이언트 로그, 이벤트를 상세하게 수집하지 않아 더욱 어려움
--> 장애 인지 및 원인 파악에 많은 시간이 소요됨 --> 헬게이트 오픈  --> 비즈니스 손실이 커짐
 
on promise 환경..?(모르는 단어) 사일로..?(나중에 찾아서 글 정리 다시 하겠읍니다,,)
 
어플리케이션과 인프라를 연계지어 볼 수 있는 툴이 없었음
ui는 spa 앱 기반으로 사용자 단말 브라우저 상에서 렌더링이 되는데 ui 모니터링 도구가 수립되어 있지 않아 ui 어플리케이션 상에서 에러를 파악할 방법이 없음(증상 재현을 통해서만 파악 가능)
각 시스템 별 담당자가 다르고 각 시스템의 연계 문제가 있어 핑퐁 진행
 
 
구성 목표
서비스 전반에 대한 가시성 확보
서버, 클라우드, 네트워크, 어플리케이션, 로그 등을 모두 한번에 엔지니어와 개발자가 같이 분석할 수 있는 모니터링 환경 구성
다양한 자원을 한번에 모니터링
모든 어플리케이션, 호스트, 컨테이너, aws 관리형 서비스, 네트워크등의 모든 자원의 상호 연관 관계를 조합하여 볼 수 있고 추적할 수 있는 환경
실 서비스 이용자인 고객 관점의 모니터링 (end to end)
실 사용자의 웹피이지 로딩, 지연, 에러 파악 및 api 호출 및 db 쿼리까지의 trace 기반 모니터링 체계 마련
--> 모든 인프라/어플리케이션 정보를 통합하여 각 파트가 같은 정보를 투명하게 공유하여 문제 해결의 속도를 높임
개발자 측면의 benefit
 인프라 담당자와 각 클라이언트 개발자 간의 통합된 동일 정보 공유
 
gs리테일의 datadog
하나의 통합 모니터링 대시보드에서 infra, network, db 그리고 ui 어플리케이션, api 어플리케이션 등의 full stack 가시성을 제공하여 신속하게 문제가 해결될 수 있도록 함(통합된 뷰로 모든 tech 스택의 trace에 대한 시각화를 제공함)
api 병목 원인 파악, 로딩 에러 집계, 연관 관계 가시화, aws 관리형 서비스, 서버, 컨테이너 등의 인프라 자원을 통합 모니터링
데이터 관점의 api 분석
gs리테일 인프라는 public cloud, private cloud를 모두 같이 사용하는 하이브리드 아키텍쳐 구성, 다양한 인프라 인프라 환경으로 서비스
이중 public cloud의 telemetry 부분(Monitoring / diagnostics)에 datadog 사용
datadog의 dashboard중 service map기능을 이용해 서비스들간의 연계 구조 확인, 서비스간의 장애 발생 여부 바로 인지 가능, 알림 기능
서버에서 수행중인 process들의 리소스 점유량 쉽게 파악 가능
Process별 metric을 상세하게 파악 가능
--> 빠르게 issue tracking 가능 --> 장애 파악 시간 감소
aws ecs를 사용하는데 ecs monitoring을 위해 각각 보게 되면 불편하고 접근 권한이 있는 관리자만 볼 수 있는 것도 있었는데 이 모든걸 하나로 묶어 aws ecs monitoring이라는 기능을 제공하고 있어 전체적으로 볼 수 있고 각 컨테이너별로 확인하기도 용이
eks환경도 운용중인데 하나의 시스템당 2개 이상의 클러스터를 붙여 멀티 클러스터로 운영중임. aws eks도 마찬가지로 계정, 클러스터가 각각 나누어져 있어 이것들을 pod내 구성되는 어플리케이션과 쿠버네티스 메트릭을 연관지어 분석할 수 있는 kubernetes_pod으로 볼 수 있어 개발자와 인프라 담당자간 공유됭어 이슈 해결에 용이
aws eks monitoring을 이용해 k8s resource의 Restart time, metric을 쉽게 파악 가능, pod을 선택하면 매니패스트 확인 가능, event도 확인 가능하여 원인 파악 쉽게 가능(서버에 안 들어가도 됨!!!!)
단일 클러스터일때는 aws에서 제공해주는 monitor를 사용했는데 이제 멀티 클러스터가 되니까 위에 언급한대로 너무 확인할게 많고 번거로워서 datadog을 쓰면 참 편
정확히는 k8s의 pod보다는 내부 워크로드를 봐야하는데 이걸 백엔드와 연관지어 봐야한다. 근데 aws에서 제공하는 기능은 이런게 없다. 
인프라 환경에서는 오픈소스 프로메테우스 등을 이용해 모니터링 하고 있었는데 장애가 나게 되면 1분 1초가 급한데 오픈소스를 이용해 직접 뭔가를 구성하면 이것 저것 다 직접 열어야 해서 시간도 걸림
이걸 datadog으로 하게 되니 그러지 않아도 됨. 대신 datadog의 기능을 이용하게 될 때 (뭐가 단점이라고 했는데 이게 안들리네...
네트워크 환경에서는 aws/on-promise 환경으로 사용중인데 트래픽 문제 등 여러 문제에 대해 이 문제도 네트워크 관리자와 다른 개발자간 정보 공유 및 협업이 필요했는데 datadog을 이용해 정보의 공유, 투명화가 가능해짐
각 네트워크 트래픽의 시각화 모니터링, 네트워크 맵의 시각화, flow확인 가능. 구간별 latency 쉽게 파악 가능. 특히 aws to on-promise 통신 시 전용선 트래픽이 급증할 경우 원인을 파악하기 위해 활용하기가 좋음
npm 과 apm을 같이 제공함
datadog rum(real user monitoring)
datadog 도입 전 client단에서 분석할 수 없었는데 도입 후 client단에서 발생한 모니터링 지표를 session별 수집, 사용자 경험 추적(뭘 클릭했고, 뭘 입력했고 등등), 이슈 발생 원인 직관적 확인 가능 --> 운영자가 직접 재현할 필요 없이 사용자 경험 추적으로 인해 자동으로 재현 가능(세션 리플레이)
rum을 이용해 대시보드에서 사용자의 증감 수치, 모든 에러 type, path 수집, 에러 발생 빈도가 높은 소스 발견 시 즉각 대응 가능
사용자가 증가된 view 식별 시 view RUM event를 통해 RUM 페이지에서 분석 진행
datadog apm
전용 dashboard구성하여 api응답시간 분포도 위젯으로 응답시간 증가 여후 확인, 지연이 발생한 api리스트 확인, APM trace로 해당 API로 필터링하여 검색
Flame Graph로 응답시간을 가장 많이 소요하는 포인트 확인
third-party 솔루션에서는 필터링이 잘 안되었는데 여기서는 필터링 가능. 맞춤형으로 widget을 구성한 dashboard 만들기 가능.
APM Service Map 기능을 이요해 서비스 레벨 구분 및 WEB, WAS, DB의 연관 관계를 시각화 하여 볼 수 있으며 서비스 별 요청 건 수에 대해 확인 가능
APM Continuous Profiler
배포된 후 각 제품의 상태를 모니터링. Heap Dump, Thread Dump 후 별도 Tool로 분석하지 않아도 JVM을 쉽게 상세히 모니터링 가능
Compare기능이 있는데 현 시점의 배포 버전과 과거의 배포 버전의 기능, 성능을 비교하여 문제가 있는 경우 원인 분석을 용이하게 함.
--> 이전에 쓰던 툴, 오픈소스가 있긴 한데 시장은 점점 x-view(?)형태로 변하고 있고 이제 어느 부분에 문제가 있는지, 뭐가 문제인지를 분석해야하고 조치를 해야하는데 요새 아키텍쳐가 점점 복잡도가 늘어나서 기존 방식으로는 한계가 있음. 뭐가 뭘 호출하고 어디에 있고 뭐가 문제인지 datadog을 이용해 stack trace까지 시각적이고 쉽고 자세히 분석 가능하고 그때 당시 pc의 성능, 상태까지 확인 가능.
APM DB Monitoring 구성하여 실시간으로 쿼리 에러 현황, 쿼리 수행 시간을 모니터링(쿼리 수행 시간 지연과 같은 에러 발생 포함) -> 쿼리 정보로 분석 진행 가능
 
datadog Log Managament
위에서 언급한 서비스들에서 로그를 수집하는데 힘들었는데 이제 사용자가 viewer를 커스텀하여 필요한 로그들을 하나의 뷰로 수집해 이슈 원인 파악에 많은 도움이 됨(elk를 많이 사용하는데 이게 생각보다 비용이 많이 나온다. 보통 로그를 서버에 많이 저장하고 aws의 elastic search - open search 를 이용해 봤었는데 문제는 여기서 딜레마가 하나 온다. 로그가 엄청 많아지는데 여기서 성능을 올리려면 돈을 더 내고 elastic search의 스펙업을 해야한다. 비용이....)
 
datadog infra(알람)
이슈 발생시 알람 발생. 특정 인계값 및 조건을 걸어 담당자가 바로 인지할 수 있도록 알람 구성 가능.
-> 이 알람 사용 이후 장점 : aws는 이것도 비용이고 클라우드 엔지니어나 좀 받을 수 있었는데 실은 개발자도 받아야해서 이게 좀 부족함. 근데 datadog에서는 알람 받는 담장자, 조건, 내용 등의 구성이 자유로움.
 
 
datadog활용 사례를 통해 배우는 트러블 슈팅
트러블 슈팅 과정
적용 전
고객 - 운영자 - 개발자 - 장애인지 - 로그찾으러 서버 접속 - 다른 담당자와 핑퐁 - 시간 소요
적용 후
장애 발생 - 모니터링에 걸어둔 알람을 통해 담당자가 알람 받기 - 어느 포인트에서 발생했는지 확인 - 해당 포인트부터 원인 파악 및 조치
 
e.g.1 ios에서는 잘되는데 안드로이드에서는 안됨
- 비정상적 앱 배포 의심했으나 앱 배포를 하지 않았음을 확인
- RUM이벤트 세션에 많은 로그가 남아있어 android에서는 접속할 때 에러가 발생하며 연결이 실패하고 있다고 분석
- 장애 범위를 좁힘
 
e.g.2 azure windows vm에 asp.net으로 구성되어 있는 시스템에 잦은 지연이 발생함
- azure 모니터링 외 별도 모니터링 도구는 없었고 azure모니터링 지표로는 infra관련 지표만 확인 가능함
- dashboard 전주 대비 api 소요시간 위젯을 통해 요청 시간이 증가한 api 식별 및 리스트업화
 
e.g.3 앱이 느린데 어디가 느린지 모르겠어요
- 앱에서 지연이 간헐적으로 발생 (어떨 때는 빠르고 어떨 때는 느림)
- 앱은 영향을 받는 부분이 많아 구간이 매우 복잡하여 어디에서 병목이 발생했는지 확인도 어렵고 구조가 복잡할 수록 담당자도 많음)
- android나 ios에 datadog rum ios, aos sdk를 적용하여 배포
- datadog agent 데몬셋 구성, 설치, datadog java trace sdk 구성
- end to end를 검수(모니터링)해야 하는데 datadog적용으로 편-안
- ios는 app 심사에서 잠깐 발목이 잡힐 수 있으나 배포 했음
- 이제는 문제가 발생하면 고객의 시간(해당 문제가 발생한 로그의 시점)에서 부터 분석이 시작되기 때문에 빠르게 진행하고 이 로그를 각 담당자들이 투명하게 공유하기 때문에 더욱 빠르게 조치가 가능하다.
 
datadog 비용 최적화
datadog 구성 완료 비용 효율화를 위해 RUM, APM, Log Management에서 발생하는 불필요한 리소스 수집 제외 작업 수행
log 수집 필터링을 통해 비용 절약
RUM에는 samplerate라는게 있어 세션 비율을 조절할 수 있음
 
 
qna중..
q. datadog이 러닝커브가 좀 있긴하다. 조언을 부탁한다.
a. 기존 다른 툴 사용하신거랑 크게 다를 것 없다. 조금만 공부하면 그 몇배의 효과를 보실 수 있다.
q. datadog을 사용할때 유의해야 될 점도 한마디 부탁한다.
a. datadog을 계정을 분리해서 사용하고 있는데 그 이유는 비용을 분리해서 계산하기 위함이다.

datadog - gs리테일 웨비나 : 어느날 갑자기 찾아온 Datadog, DevOps 변화의 시작

댓글