Blog

DataDog의 APM

DataDog의 APM 서비스는 말 그대로 Application Performance Monitoring에 초점을 둔다. NewRelic의 APM과 달리 스택 트레이스 정보를 수집하지 않는다. 그저 애플리케이션의 성능을 측정할 뿐이다. 초당 요청 수, 평균 응답속도, 오류발생률, 구간별 소요시간 등을 추적한다. 전체적으로 DataDog의 주 기능인 메트릭 측정이 인프라와 널리 인정 받는 미들웨어를 넘어서 개별 애플리케이션에 적용될 뿐이다. 쓸모는 있지만 NewRelic의 APM 수준을 기대해서는 안 된다. 그리고 몇 가지 단점이 더 있는데

• 아직 Go, Python, Ruby만 지원한다.
• APM 라이브러리 단독으로 작동하지 않고 DataDog Agent와 통신할 필요가 있다.
• 적어도 Go의 경우는 DataDog APM을 붙이기가 생각보다 쉽지 않다. NewRelic에 비하면 확실히 그러하다. 게다가 NewRelic go-agent는 문서도 더 상세하다.
• NewRelic과 달리 배포 시점을 표시하는 Marker가 대시보드에 없다.

단점만 이야기할 건 아니다. 장점도 분명한데

• 가격이 매우 저렴하다.
• DataDog은 데이터를 13개월 유지한다. 애플리케이션의 성능 추이를 확인하기에 좋다.
• DataDog APM은 다른 DataDog 서비스가 그렇듯 기본적으로 메트릭 모니터링 서비스이다. 그런만큼 DataDog의 강력한 메트릭 기반 모니터링/알람 서비스를 활용할 수 있다.

핀터레스트의 도커 도입기

https://medium.com/@Pinterest_Engineering/containerization-at-pinterest-92295347f2f3?source=userActivityShare-13053a436336-1505301480

요새는 다들 도커 익숙해서 그냥 그런가 보다 하겠지만 2세대 프로비저닝 도구인 Puppet(그리고 Ansible 등등)이 얼마나 관리하기 괴로운지 3세대인 도커가 왜 좋은지 몇번 이야기한 적 있다. 여기서도 비슷한 이야기를 한다. “퍼펫이 뭐냐 그런 거 몰라”라고 생각한다면 복받은 것이다.

• Engineers needed to be involved in the AMI build as well as learn the various configuration languages of these process managers, including Puppet.
• Puppet changes could be applied to hosts at any time without fine granular control
• As time went by, environments on the hosts diverged and caused operational issues.

도커 네트워크 대신 호스트 네트워크를 선택한 이유도 설명한다. 데일리에서 Kubernetes를 도입할 때 Staging 환경에서는 Docker 기반의 기본 Service (Load balancer)를 이용하다가 문제가 끊이지 않아서 AWS ELB 기반의 External Load Balancer로 전면 전환한 것과 일맥상통한다.

While the Docker network is great for development, it’s widely known to negatively impact performance when running in production. This drove our decision to use the host’s network and not rely on Docker networking.

애플리케이션에서 테스트가 하는 역할을 인프라에서는 모니터링이 한다. 촘촘한 모니터링 없이는 자신 있는 마이그레이션도 없다.

For the API migration, we ensured we had a comprehensive set of metrics to compare running in a container and outside of one.

데일리는 EC2, ECS 조합에서 Kubernetes로 넘어온지 한참이라 Pinterest나 GitHub의 사례가 나오면 느긋하게 관람하는 기분으로 즐길 수 있다.

파이썬은 지금 ‘환골탈태’ 중

GIL에 드디어 손을 대는구나.

오래 전 이야기, 그러니까 월드 오브 워크래프트가 세상에 등장하고 나서 얼마 안 지났을 때가 생각난다. 서버측 게임 스크립트 엔진을 개발하느라 여러 기술을 탐색했더랬다. WOW에서 사용한 LUA가 주목받긴 했지만 객체지향 언어가 아니라서 몇 가지 성가신 점이 있었다. Python이 제일 나아보였다. 문명(Civilization)도 파이썬 위주로 컨텐츠를 쌓아올렸다. 하지만 이 놈의 Global Interpreter Lock이 문제였다. 멀티코어 멀티스레딩을 최대한 활용하려고 Lock-free 알고리즘까지 도입한 컨텐츠 서버에 GIL이라니 모든 노력이 헛수고가 될 판이다. 결국에는 당시의 최신 기술인 C++/CLI로 네이티브 C++과 CLR 기반의 언어, 이를테면 C#을 연결하여 스크립트 엔진을 개발하였다. 아직도 난이도 면에서 C++/CLI 를 능가하는 걸 보지 못하였으니 덕분에 아무 언어나 자유롭게 오갈 수 있게 된 것 같기도 하다.

Ruby의 쇠락

어쩌다 보니 Ruby 기반의 라이브러리로 Restful API 서비스를 개발하게 됐다. 아주 간단한 서비스라 뚝딱 만들었는데 개발이 재미있지는 않았다. Rails API 대신 더 간단하다는 Sinatra를 이용했는데 Sinatra 자체에는 큰 불만이 없다. 하지만 lube8uy/sinatra-params-validator 같은 라이브러리를 가져다 쓰려고 할 때마다 좌절하는데 벌써 수년 전에 개발이 중지됐기 때문이다. 커뮤니티 자체가 완전히 쇠락, 아니 몰락한 것 같다.

• Author Details

Author Details

최 재훈

Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.

https://twitter.com/andromedarabbit

plaintext@andromedarabbit.net