안녕하십니까. Spoonradio 의 임직원 3명은 이번에 San francisco 에서 개최 하는 Dash 2023 에 발표와 세미나를 청취 하기 위해 방문 하였습니다.
Spoonradio 는 임직원들의 다양한 경험과 성장을 촉진하기 위해 국내외 세미나 참석을 적극 장려하고 있습니다. 특히, 이번 세미나는 많은 청중들 앞에서 발표를 할 수 있어 더욱 다양한 경험을 했던 소중한 세미나로 기억될 것 같습니다.
이 블로그에서는 Dash2023 행사에서 발표되었던 주요한 기능들과 더불어 행사에 참석하지 못하신 분들을 위해 저희가 발표한 내용에 대해서 설명 하고 , 발표를 들으셨던 분들에게도 저희가 발표때 말하지 못한 비하인드를 조금더 공유하여 유익한 블로그가 될 수 있도록 작성해 보고자 합니다.
Day 1.
첫 번째 날은 Workshop 세션을 주로 다룬 날이었습니다. DataDog에서 특정 서비스에 대한 소개를 들으면서 직접 실습하는 구성입니다.
첫 번째 날은 Workshop session 을 주로 다뤄 발표를 통한 지식을 공유 하기 보다, 본인이 스스로 익힐 수 있도록 준비해주신 것 같았습니다. Workshop session 은 Datadog 을 많이 사용하지 않는 사용자도, 쉽게 접근할 수 있도록 Level 을 나눠 세션을 준비해주신 것이 인상적 이였습니다.
안타깝게도 조금 늦게 알기도 했고, 발표 준비로 인해 Workshop session 을 참석할 수는 없었지만, 많은 분들께서 도움이 되는 세션 이였다고 말씀해 주셨습니다.
Workshop session 을 제외 하고도 session 은 다양한 주제들로 구성되어 있었습니다. Datadog 에서 AWS Service (Lambda, RDS, EC2.. 등 ) 에서 log 와 metric을 어떠한 방식으로 수집하여 분석하고, 모니터링 하는 지에 대한 소개부터 현재 가장 각광받고 있는 APM 을 이용하여 모니터링과 문제를 찾는 방법에 대해 상세하게 설명 하는 세션또한 들어볼 수 있었습니다.
그리고 마지막으로 AWS, GCP, K8S 등 여러 워크 로드를 효과적으로 모니터링 하는 방법들을 실습 함으로써 SRE, SLO 등 목적에 따른 기능을 배워볼 수 있었습니다.
이처럼 다채로운 주제들로 채워진 Dash 2023 의 첫날 마지막 행사는 Dash : Opening Reception 이 진행되어 파트너의 Expo 전시관에서 다양한 부스를 관람할 수가 있었습니다. Reception 에서도 역시 다양한 파트너들과의 대화와 Datadog의 부스에서 다양한 정보들을 습득할 수 있었고 덤으로 다양한 굿즈도 양손 가득 받을 수 있었습니다.
Day 2.
Day2 는 모든 행사의 핵심인 KeyNote 와 저희에게 가장 중요한 세션인 Korean track 행사가 있었습니다. Datadog 의 관심이 높아 짐에 따라 한국에서도 많은 분들이 참석 하여 주셨고, 그에 따라 올해 최초로 Korean track 과 Japan track 이 신설 되었고, 그중 Korean track 은 Spoonradio 가 Japan track 은 NTT Docomo가 Datadog을 사용자의 관점에서 활용 하는 노하우에 대해 발표 하였습니다.
또한 Koran track 에서는 Datadog의 엔지니어분들이 나와 KeyNote에 발표하였던 내용을 ReCap 하여 소개하며 Dash2023 에서 중요하다고 생각하는 내용에 대해 꼼꼼하게 설명 하여 주셨습니다.
Recap 의 시간이 끝나고 저희 SpoonRadio 의 직원들이 Dash2023에 참여한 가장큰 이유인 “SpoonRadio의 Global streaming service monitoring know-how” 를 발표하는 시간을 가졌습니다. 처음 생긴 Korean track 에 저희가 운영하는 것에 대한 노하우를 공유 한다는 것은 매우 자랑스럽기도 했지만, 한편으론 매우 부담이 되는 시간이 였습니다. 그럼 KeyNote 부터 자세히 살펴 보겠습니다.
KeyNote
KyeNote는 모든 세미나에서 가장 중요한 행사로 손꼽힙니다. 다른 세미나들이 고객의 사례와 지금까지 걸어왔던 발자취를 소개하는 자리였다면 KeyNote 는 앞으로 즉, 미래에 우리가 집중해야 하는 핵심 기능이나, 개발이 완료되어 사용되길 기다리고 있는 기능들을 소개 하는 자리인 만큼 행사에 참여한 많은 인원들이 KeyNote 행사장을 방문 하였습니다.
Datadog 과 메가존의 배려로 매우 가까운 자리에서 KeyNote를 온몸으로 느낄 수 있었던 행사였고, 저희가 중요하게 관찰했던 내용들에 대해 공유해 보도록 하겠습니다.
Bits AI
가장 먼저 소개된 기능은 Datadog 전용 ChatGPT 의 느낌을 받을 수 있는 Bits AI 기술을 소개 하였습니다.
대화형 인공지능 ChatGPT, text-to-image 인공지능 Stable Diffusion 등 2023년 상반기에는 다양한 AI 기술이 상용화되어 세상을 놀라게 만들었습니다. 여기에 Datadog에 녹아든 대화형 인공지능 서비스를 보며 기대도 되고 실제 우리 서비스에 어떻게 녹이면 좋을까도 다시 한번 생각하게 되었습니다.
대화형으로 질의하고 답변 받는 ChatGPT와 유사한 부분이 있습니다. 사용자가 “이슈가 뭐야?”라고 질의하면 “이슈”에 대한 기준이 모호하므로 원하는 답을 얻기 어려웠습니다. 대화를 이어가거나 질문을 할 때 여러 가지 정보를 주어 질문을 잘 해야 이 기능을 효과적으로 사용할 수 있습니다.
Flex Logs
Datadog에 많은 데이터를 담기 위해 로그를 저장하도록 구성하였습니다. Metric과 Trace와 같이 Log도 같이 나와주니 observability로써 편리하였습니다. 하지만 이 편리에 대한 비용으로 높은 비용의 청구서를 받게 되어 로그 정재 작업을 진행하였습니다. 필요 없는 로그는 물론 “진짜 필요”에 대한 모호함 속에 정재 작업을 진행하였습니다.
하지만 여기에 Flex Logs를 새롭게 발표되어 Indexing과 Archiving 사이에 중기 수집을 위한 대안이 나왔습니다. Datadog에서는 로그를 많이 쌓게 하여 과금하도록 유도하는 것과 그것을 피해 로그를 적게 수집하다 못해 수집 자체를 하지 않는 사용자 간에 중간 대안이 될지 계산기를 두드려봐야겠습니다.
Observability Pipelines
모니터링 도구를 위한 편리한 기능을 공개하였습니다. DashDog 웹 콘솔을 통하여 인프라에 구성된 Observability 데이터를 확인할 수가 있었고 수정 배포까지 빠르게 되는 데모를 보았습니다. 데이터를 수집하는 건 각 서버나 환경에 설치된 Agent가 수집하게 되고 설정 파일의 정보에 따라 동작을 하고 있습니다. 하지만 다양한 Agent를 전개하고 있어 정책에 대한 수정은 매우 번거로운 일입니다. 하지만 이런 정책 배포를 원격으로 편리하게 할 수 있다는 기능에 흥미가 생겼습니다.
데이터 Input, Filter, Output에 대한 과정이 어떤 식으로 동작을 하는지 검토를 해보고 기대한 기술을 그대로 반영하였는지 마케팅을 위한 프레젠테이션에 속았는지 기대와 의심을 가지고 있습니다.
Single Step APM Instrumentation
Datadog APM 설정과 Agent 설치 과정을 최소화 하여 신속하게 설치함으로써 Application 에서 APM 을 도입하는 진입장벽을 단축시킬 수 있는 기능을 소개 하였습니다. CI/CD 를 담당하는 SRE 팀부터 APM 을 source 에 직접 적용해야 하는 Backend 개발자 까지, Step by Step 이로 이뤄지던 일들을 더욱 쉽게 처리할 수 있도록 UI 기반이나, 다양한 방법으로 설정할 수 있도록 한 것이 흥미로웠습니다.
APM Trace Queries
마지막으로, 저희가 Korean Track 에서도 발표한 내용인 APM Trace Queries가 발표 되었습니다.
지금까지 API 는 단일 Span 관점에서 쿼리를 확인할 수 있는 방법만이 존재 하여, 어떤 흐름을 갖고 Span 이 흘러가는지 확인할 수 있는 방법이 없었습니다. 물론, API 의 특성에 따라 다른 방법으로 query 를 분석할 수 있는 방법은 있었지만, 해당 기능이 발표됨으로 인해 좀더 거시적인 관점에서 Trace 와 같이 Query 를 분석할 수 있는 도구가 생겼습니다.
DBA의 입장에선 가장 반가운 기능이였고, Trace 의 세부정보를 기반으로 어떻게 분석하는지에 대해서 Korean Track 에서 발표한 내용으로 좀더 자세히 설명 하도록 하겠습니다.
Korean Track — 스푼라디오의 글로벌 스트리밍 서비스 모니터링 노하우
글로벌 오디오 스트리밍 서비스인 스푼라디오는 17개국에서 서비스를 하고 운영의 최적화와 비용관리를 위해 AWS 15개의 Account과 5개의 Region을 사용하여 서비스를 하고 있습니다.
이러한 환경에서 DBA, SRE, Backend Engineer 관면에서 Datadog을 통해 효과적으로 모니터링하는 방법과 나아가 어떻게 협업하고 있는 지에 대해 발표하였습니다.
DBA — Top Down Analyze & Bottom Up Analyze
SpoonRadio에서 DataBase Administrator 를 맡고 있는 Ryan (김광호) 이라고 합니다. Global streaming service 를 통해 사용자들이 더 많은 이야기를 듣고 즐거운 경험을 할 수 있도록, Data storage 를 설계/운영 하고 모니터링 하고 있습니다.
Korean Track 에서 첫번째 발표를 하는 막중한 임무를 띄고 많은것을 준비하고자 노력 했지만 발표를 하고 난 뒤 많은 아쉬움이 있었습니다. 그 아쉬운 마음을 이 블로그에 첨언하여 발표한 내용을 전달 하겠습니다.
앞서 설명 드렸던 내용을 이어서 설명 하고자 합니다. KeyNote 에서 발표한 APM Trace Queries 의 기능이 새로 만들어지면서, 파생된 기능인 DBM Calling Service 를 이용하면 어떤 형태로 모니터링이 가능한지에 대해서 발표 하였습니다.
Top Down Analyze
말은 거창하지만, API 에서 발생 하는 쿼리를 Database 의 운영자 관점에서 모니터링 하는 방식을 설명 하였습니다. 기존의 Datadog 으로 query 를 모니터링할 때의 한계점, 그리고 그 한계점을 어떻게 Database monitoring 으로 풀어 나갔는지에 대한 과정을 설명 하였습니다.
- 기존의 Query monitoring 의 한계점
보시는 것처럼 APM 을 통한 한계점 중 가장 큰것은, 문제가 발생했을 때 그 쿼리의 plan 을 명확하게 알 수 없고, 표준화 된 쿼리의 variable 로 인해 재현이 불가능 하였다는 점입니다. MSA 구조 및 mutiple account, multiple region 으로 서비스 하는 SpoonRadio 의 특성상 모든 database 를 항시 모니터링할 수는 없습니다.
따라서 문제가 되는 시기에 Alert 를 통해 모니터링을 해야 하지만, 그 시점의 plan 이나 변수를 즉각적으로 활용할 수 없어 항상 slow query 나 log 등을 뒤져서 문제를 찾기 위해 노력 하는 시간을 들여야 했습니다.
- Database monitoring 으로 한계점 극복
위의 한계점에서 Plan 을 보기 어렵고 시기를 특정하기 어려웠던 것과 다르게. plan 이 수행되는 시점과 어떤 plan 이 수행 되었는지를 확인 하고 즉각적인 조치가 가능해졌습니다. 이러한 빠른 조치를 통해 우리는 좀더 빠르게 문제에 다가갈 수 있었고, 문제를 해결하는 시간이 많이 줄어 들었습니다.
다만, 분명한 trade off는 있습니다. Bottom Up Analyze 를 설명 하고, trade off 에 대해 좀더 이야기를 진행 하겠습니다.
Bottom Up Analyze
그럼 반대로, Database 를 모니터링 하는 과정에서 문제가 발생한 쿼리를 확인 한다면, SpoonRadio 에서는 어떻게 대처 하고 있는지에 대해서 설명 하였습니다. 이 방법 역시 기존의 한계점을 먼저 시사 하고 , 어떻게 해결해 나갔는지를 순서대로 설명 하였습니다.
- Database monitoring 을 사용하고 있지만 Root Trace 를 알 수 없는 문제점
위에서 볼 수 있는 것처럼 Database 에 대한 전반적인 사항을 Database monitoring 에서 확인할 수 있습니다. 그렇기 때문에 Query signature 기반으로 Query 에 대한 문제점도 확인이 가능 합니다. 다만, 어떤 Service 에서 어떤 Function 을 사용 하여 Query 를 호출하는지 알수 없기 때문에 문제점을 찾더라도 해당 문제를 찾는데 시간이 많이 소요 되었습니다.
최근 5~10년 사이 개발 생산성을 높이기 위해 ORM 을 사용하여 개발 하는 회사가 점차 늘어나고 있습니다. ORM 을 사용한다는 것은 개발 생산성을 높이는데는 좋지만, 어떤 Query 가 발생하는지 알 수 없기 때문에 DBA 입장에서는 누구에게 문의를 해야 하는지 확인이 불가능 하였습니다.
따라서, 다양한 개발자 분들에게 Query 에 대한 확인 요청을 해야 했고 그 시간만큼 문제를 해결하는데 시간을 소요할 수 밖에 없었습니다.
- APM Trace Queries 를 이용한 Calling service 로 한계점 극복
위에서 볼 수 있는 것 처럼 APM Trace Queries를 이용하여 Calling service 라는 기능이 생겼고, 그 기능을 통해 고민하던 문제를 해결할 수 있었습니다. Calling service 는 보시는 화면과 같이 해당 쿼리를 어떤 Trace 에서 호출 하였는지를 찾아, 어떤 Service 와 Function 에서 호출 하였는지 쉽게 찾아낼 수 있었습니다.
이로 인해 , DBA는 문제가 되는 Query 에 대한 owner 를 쉽게 찾을 수 있게 되었고 담당 개발자를 통해 해당 문제를 논의 할 수 있게 되었습니다. 담당 개발자를 찾고 쿼리를 설명 하는 시간 보다, 지표를 정확히 보고 문제가 되는 부분을 같이 봄으로써 해결 시간이 많이 감소 되었습니다.
제가 발표한 내용은 여기 까지 입니다. 다만, 앞서 말씀 드렸듯이 비하인드 스토리와 Trade off 를 이야기 해보고자 합니다.
Behind story — Trade off
Postgresql 에 Calling service 를 Enable 하는 순간 부터 pg_stat_activity 에 Query 앞에 주석이 처리 되어 , 실제 쿼리를 식별 하기 어렵게 되었습니다. 또한 뒤에 traceparent 의 난수가 있어 해당 값을 제거 하고 쿼리 하기도 어려운 실정이죠..
그래서 한가지 Tip 이라면 Regex_replace 를 써서 제거 했습니다. 나중에 참고 해보시면 좋을 것 같습니다.
select pid, backend_start, regexp_replace(query, E'/\\*.*?\\*/', '', 'g') AS cleaned_query from pg_stat_activity또한 Database monitoring 에서 사용 되는 Explain 함수가 많은 사용량을 보인 다는 것입니다.
위에 보실 수 있는 것 처럼 datadog 의 id 를 갖고 있는 계정이 실행 하는 쿼리는 약 3800/1h 로 보실 수 있습니다. 이처럼 거의 1초에 한번씩 쿼리를 수행 하고 있기 때문에 성능에 약 2~5% 정도는 차지 할 수 도 있고 spec 이 낮은 경우 10% 이상 상승할 수도 있습니다.
마지막으로 비용입니다. Instance 당 비용이 만만치 않기 때문에 정말 잘 활용할 수 있다는 계산과 준비가 되었을 때 시작 하면 더 효율적으로 사용할 수 있을 것이라 생각합니다.
Backend Engineer — Observability in EDM architecture
SpoonRadio에서 Live 서비스를 안정적으로 운영하고 더욱 즐거운 서비스가 될 수 있도록 새로운 아이템을 개발하는 Backend Engineer 신유빈 Sophia 입니다.
현재 스푼라디오는 EDM(Event Driven Microservice) 구조의 차세대 아키텍처로 전환하고 있습니다. 이에 따라 현재 Hybrid EDM 모델로써 기존의 모놀리식 아키텍처인 Legacy 시스템을 안정적으로 유지하면서 점진적으로 마이크로서비스 기반으로 전환해나가고 있습니다. 이를 통해 서비스와의 의존성을 최소화하여 장애에 대한 위험 요소를 분리하고 안정성과 유연성을 높이며 비즈니스 가능성을 확장할 수 있었습니다.
이때 모니터링 측면에서 변화가 필요했습니다. EDM 구조는 많고 복잡한 마이크로 서비스들과 Kafka 이벤트로 동작하기 때문에 기존의 모니터링 방식인 APM trace만으로는 제한된 가시성으로 모니터링이 어려웠습니다.
이러한 문제점을 해소하기 위해 Dashboard와 Data Streams Monitoring을 활용하여 어떻게 observability을 확보했는지 소개하였습니다.
Dashboard를 통해 각 국가별 cpu 사용량에 따른 파드 상태 및 수, 컨테이너 별 cpu 등과 같이 모니터링이 필요한 지표들을 한눈에 확인할 수 있도록 구성하였습니다. 해당 지표들을 통해 리소스를 관리하며 성능 저하를 방지하고 잠재적인 위기 상황에 대해 인지가 가능하기 때문에 가용성을 높였습니다. 또한 카프카 이벤트에 대해서 디스크 사용량에 대한 추이 지표를 확인하며 시스템의 안정성을 높이고 Kafka 이벤트의 consume, produce 빈도를 그래프로 구성하여 향후 트래픽을 예측하며 consume lag 발생 시 신속한 처리가 가능해집니다.
이때, 마이크로 서비스와 이벤트가 서로 어떠한 상호 작용을 하는지에 대해서 data streams monitoring 서비스를 통해 확인할 수 있었습니다. 데이터 data streams의 양을 상대적으로 쉽게 파악하며 latency 및 병목 현상을 인지하며 어떻게 개선 포인트를 찾는지 어떠한 insight 를 얻는지 소개하였습니다.
나아가 EDM 구조에서 발생하는 데이터를 바탕으로 Business Indicator를 모니터링하며 Datadog을 기술적인 서비스 모니터링 지표로만 활용하지 않고 매출과 서비스와의 관계를 이해하며 어떻게 Business Indicator를 구성하고 해석하고 있는지 소개하였습니다.
SRE — Deployment Tracking
SpoonRadio SRE팀의 Devops Engineer, Ash (박민호) 입니다. 배포가 잦은 EDM환경에서 Datadog을 활용하여 어떻게 트래킹하고있지에 대하여 공유드렸습니다. SpoonRadio에서는 이미 Datadog을 이용하여 Observability를 위한 데이터인 Metrics, Traces, Logs를 수집하고 Business Indicator를 구성하여 지표로 삼고있습니다.
그러나 저희는 서비스의 성능 변화를 정량적으로 파악하기에는 부족한 부분이 있었습니다. 서비스를 배포할 때 담당자가 APM Trace만을 이용하여 실시간으로 모니터링 하고 정상여부를 평상시 패턴과 비교하여 주관적인 판단으로 진행합니다. 이러한 문제점을 해결하기 위해 APM에 포함된 기능인 Deployment Tracking을 활용하기로 하였습니다.
Deployment Tracking은 두 버전 간 태그를 비교하여 3가지의 비교 포인트를 확인할 수 있습니다.
첫 번째는 그래프 비교입니다. 버전 간 Requests, Error, Latency가 그래프로 나오며 색깔로 구분됩니다. 배포 시 새로운 색상이 나타나고 기존색상이 사라지는 것으로 배포 동작에 어떻게 진행되고 있는지 알 수 있습니다. 두 번째는 에러 비교입니다. 수집하고 있는 에러들에 대한 버전의 차이를 알 수 있어 새로운 버전에서 발생한 에러가 어떤 종류인지를 확인하고 이전과 비교하여 유형에 대한 변화를 분석할 수 있습니다. 마지막은 엔드포인트 비교입니다. 서비스에서 제공하는 각 기능을 나열하여 지연시간과 오류율 등 성능이 얼마나 변화하였는지 알 수 있습니다.
이 기능들은 버전 태그를 기반으로 성능에 대한 변화를 보여주기 때문에 각각의 배포를 구분할 설정이 필요합니다. 그래서 배포될 버전에 대하여 엄격하게 관리하는 CI/CD 파이프라인이 중요합니다.
저희는 크게 레거시 시스템과 kubernetes로 되어있는 EDM 아키텍처로 되어있습니다. 서비스들은 컨테이너로 패키징되어있어 중앙에 위치한 컨테이너 저장소인 Amazon ECR에 등록되어 양 아키텍처에 전개가 되도록 설계하였습니다. 이때 설명한 버전 정보는 CD 환경으로부터 선택되어 구성됩니다.
# env.sh
export DD_VERSION={{ TAG }}
# docker-compose.yaml
version: '3'
services:
service:
image: "{{ URL }}:{{ TAG }}"
environment:
- DD_VERSION={{ TAG }}레거시 시스템 경우 Jenkins를 통해 AWX라는 도구를 트리거하는 CI/CD 구조입니다. Jenkins에서 이미지 저장소의 목록을 불러와 어떤 버전으로 배포할지 선택합니다. 선택한 값은 AWX가 넘겨받아 배포를 위한 파일을 배치에 참고합니다.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- image: "{{ URL }}:{{ TAG }}"
env:
- name: DD_VERSION
value: {{ TAG }}Kubernetes로 되어있는 EDM 환경에는 helm chart로 관리하고 있어 Datadog을 위한 옵션이 들어갈 수 있도록 미리 구성하였습니다. 배포 시 Spinnaker가 저장소에 등록된 태그 목록을 불러와 선택하도록 유도합니다.
저희는 서비스의 버전 정보는 환경변수를 통하여 명시하였습니다. 버전에 대한 값은 컨테이너 이미지 태그이자 git 레파지토리의 태그로 이어지도록 구성하였습니다.
여러가지의 서비스 성능을 쉽게 알아보기 위해 목적별로 구분한 대시보드로 구성하였습니다. 처음에는 통합으로 된 단일 보드로 구성하려고 동적인 페이지를 만들었지만 재사용성이 떨어졌습니다. 한 화면에 많은 서비스가 연속되어 보이도록 하였으며 무조건 많은 지표 보다는 경험을 통하여 관련된 여러 서비스의 지표를 모아 직관적으로 보이도록 설계하였습니다.
버전을 명시하기 위해 CI/CD pipeline을 구성하였고 그것들을 비교해주게 해주는 메트릭, 에러, 리소스 비교방법이 있었습니다. 마지막으로 대시보드를 통하여 스푼라디오는 안정성을 위한 시각화 자료를 확보하게 되었습니다.
마치며
Ryan
Dash 2023에 참석하기 위해 약 10년만에 샌프란시스코를 방문하게 되어 매우 기대 되었지만, 한편으론 처음 열리는 한국어 세션에 발표자로 참여하게 되어 부담이 되기도 했던 행사였습니다.
발표 준비로 인해 행사를 진심으로 즐길 수 있던 시간은 하루 뿐 이였지만, Keynote를 통해 새로운 기능이나 내용을 접할 수 있어 좋았고 여러 분야에서 Datadog 을 통해서 업무를 수행하는 다양한 분들과 여러 이야기를 나눌 수 있어 저에게도 귀중한 경험을 선물해줬던 행사였습니다.
Ash
행사 규모가 크지 않다고 많은 사람들이 우려를 표했지만 저에게는 충분한 규모의 행사였습니다. 모니터링 플랫폼에서 이런 큰 행사를 진행할 수 있다는 점이 놀라웠고 다양한 세션때문인지 휴식 시간을 가지기가 어려웠습니다.
스타트업에 종사 중인 여러 개발자와 네트워킹을 통해 각자의 사례를 알게 되어 흥미로운 시간을 가졌습니다.
Sophia
Datadog DASH 행사 참석 뿐만 아니라 한국어 세션의 발표의 일부를 맡아 저에게 너무 소중한 경험이 었고 잊지 못할 출장이 되었습니다.
엑스포에서 느꼈던 자유롭게 즐기면서 서로 네트워킹하고 교류할 수 있는 시간이 기억에 남습니다. 몸소 분위기를 느끼면서 개발자로서 좋은 자극을 받을 수 있었습니다. 또한 영어 공부의 필요성을 절실히 느끼며 여러 방면으로 학구열을 불태울 수 있었습니다.
발표 전체 내용
저희가 발표한 내용에 대해서 궁금하신 분은 아래 Datadog 공식 Youtube channel 에서 확인해주세요
