반응형
AWS X-Ray & Amazon CloudWatch: Increasing visibility for ECS & Fargate
Vanguard: 전세계 170여개 국, 3천만 investors에게 Mutual Fund / ETF 판매하고 Financial advice 제공하는 회사.
- 2019년 경 AWS ECS on Fargate로 MicroService 도입. underlying infra 고민 없이 high performace application / business logic 구현에 신경쓸 수 있도록
- Vanguard에서 legacy로 사용하던 monitoring / logging tool의 Leverage...
- cloud-native Observability tool (monitoring / logging 통합) 도입의 필요성을 느꼈음
일단 Container-based Platform 간단히 설명하면
- AWS ECS (Elastic Container Service): Cloud Native, High Performance, High Scalable Container management platform
- easy to run, stop, manage containers at scale.
- task 형태로 정의해서, 하나의 클러스터에 여러 container (Task)가 동시에 실행되도록 구성할 수 있다.
- AWS Fargate: ECS에서 Managing infra까지 자동화. provisioning / configuring / scaling까지 Managed service로 제공한다.
기존 Observability tool의 문제점
- more container -> monitoring tool의 scalability 확보가 어려움
- microService 애플리케이션의 visibility 확보가 쉽지 않음
- tracing call 필요성이 점점 높아지는데 대응이 쉽지 않았음
- data injestion에 드는 latency가 점점 커짐
- AWS tool에서 데이터 생성 후 legacy tool로 전달할 때 latency가 너무 크다.
AWS X-ray
- service로 들어오는 request를 확인할 수 있는 visibility tool.
AWS CloudWatch
- Log Aggregation tool
- 데이터 시각화, alarm, metrics, graphs... 등등
X-ray 선택 이유?
- managed service. legacy는 시스템 업데이트가 있을 때마다 애플리케이션 코드 수정이 필요했음. QA 사이클 -> Production 체크... 가 매번 진행됐는데, 생략할 수 있음
- 업그레이드 할 때 SDK 코드 수정은 할 수 있지만, 나머지 사이클이 생략되기 때문
- customization. annotation으로 key-value pair 지정할 수 있고, 이 pair로 filtering이 가능하다.
- troubleshooting할 때 편리함
- visibility. 자동으로 service Map을 만들어주고, tracking request를 시각화해서 볼 수 있음
- request 처리까지 시간이 얼마나 걸렸는지, response code는 뭔지... 등등.
- potential bottleneck / performance issue 확인 가능.
CloudWatch 선택 이유? : Speed
- legacy 시스템에서는 알람 trigger까지 약 15min 소요. cloudwatch로 로그 보낸 뒤, 내부적으로 쓰는 서드파티로도 로그 보내는 로직이 있었기 때문
- 더 빠른 알람 - proactive 조치 가능
Vanguard 팀 내에서 pilot 진행할 때의 노하우? 같은 걸 설명하는 부분.
- logging / metric / tracing 담당하던 여러 팀을 전부 참여시켰다.
- 어느 정도 공식문서 익숙해진 뒤에는 최대한 small fraction 단위로 세션을 꾸렸다.
- x-ray custom annotation 생성법 / cloudwatch alarm 보내는 법...
- 실제로 우리 앱에 어떻게 적용했는지를 internal road show로 구성, 공유
실제로 쓰는 architecture overview
- service A가 client-side. 클라이언트에게서 요청을 받고, service B를 호출한다
- 각자 다른 DB 보고 있고, x-ray Enabled + custom annotation을 붙였음.
cloudwatch로 로그 전송
- Custom metric 정의, cloudwatch에서 해당 metric 조회
- metric이 임계치를 넘으면 alarm 보내도록 설정
- alarm은 SNS로 발송되며, SNS topic을 subscribe한 사람에게 메일로 전달되는 방식
데모
- 이메일로 알람을 받는다
- cloudwatch 대시보드로 high level investigation 수행한다.
- x-ray tracing으로 low level investigation을 수행한다.
17:10 ~ 24:50은 실제 AWS Dashboard 보여주면서 예시 설명
도입 효과: 좋았다
- 알람까지 도달하는 시간이 15분 -> 5분으로 감소
- troubleshooting에 쓰는 시간이 60분 -> 30분으로 감소. (같은 UI에서 쉽게 서비스 이동 가능.. 편리하더라)
- 비용 절감 ($400 per GB)
반응형