토스의 빗금 21(토스ㅣSLASH 21) 행사 요약입니다.
영상 속 내용을 정리한 것이기 때문에 일부 잘못된 내용이 포함될 수 있으며 다르게 이해한 내용을 기재할 수도 있습니다. 발표 영상을 먼저 참고해주세요.
토스의 서버 인프라 모니터링
이재성 토스코어 DevOps Engineer
세션은 아래와 같은 인사말로 시작합니다.
인프라 가시성과 서버 배포를 담당하는 데브옵스 엔지니어로 일하고 있습니다.
인프라 가시성, 데브옵스 뭐 이런 말은 어디선가 많이 들어보긴 했는데, 명확한 정의를 모르니 한 번 살펴보고 넘어갑니다.
인프라 가시성
가시성은 visibility를 의미합니다. 검색해보면 "데이터 가시성", "네트워크 가시성" 뭐 이런 표현이 자주 등장합니다. 이전에 서비스가 복잡하지 않을때는 단일 서비스 장애의 로그를 살펴보고 원인을 쉽게 찾아 해결할 수 있었습니다. 하지만 서비스 구성이 복잡해지면서 살펴봐야 할 로그가 방대해지고 어디서부터 들어가야 할지 애매하게 되는 상황이 생깁니다. 그래서 문제를 직관적으로 확인하고 어디서부터 확인해야 하는지 알 수 있게 해주는 것이 가시성이라고 할 수 있습니다. 모든 정보를 직관적으로 확인해줄 수 있도록 해주는 것이죠.
대시보드랑 비슷한 것 같지만 단순히 모아서 보여주는 것이 아니라 가시성을 확보하기 위해 어떤 기술을 사용해서 어떤 식으로 적용할지 고민하는 것이기 때문에 다른 개념이라고 볼 수 있습니다.
데브옵스
데브옵스는 개발(Development)과 운영(Operations)의 합성어라고 합니다. 그렇다고 해서 개발과 운영을 같이 하는 사람을 의미하는 건 아니고 개발과 운영간의 소통, 협업, 통합을 강조하는 개발 환경, 문화를 의미한다고 합니다.
가시성과 마찬가지로 서비스가 단순할 때는 그냥 개발 조직 따로 관리 조직 따로 운영했어도 문제가 없지만 서비스가 복잡한 조직에서는 개발과 운영을 같이 하기도 하고 일관성 있는 테스트, 배포, 모니터링 정책이 필요하게 됩니다. 그래서 데브옵스라는 별도의 조직, 엔지니어가 필요하게 되구요.
이번 세션의 주제는 모니터링인데, 아래 그림에서 보듯이 데브옵스의 중요한 흐름 중 하나입니다. AWS 같은 기업에서도 데브옵스를 강조하고 있는데, 뭐 따지고 보면 데브옵스를 운영하기 위해서 자체적으로 뭔가 만들어서 하기는 힘드니 우리 솔루션 가져가다 편하게 하세요. 뭐 그런 개념이 아닐까 싶습니다.
이제 세션으로 돌아가서 2019년까지는 DC/OS(dcos.io/)와 vamp(vamp.io/) 기반으로 인프라를 구축했다고 합니다. 이 이야기는 2018년 작성한 블로그에도 올라와 있더군요.
스는 전자금융 규제에 따라 클라우드 서버 구축에 제한이 있어 물리서버를 운용하고 있습니다. 이에 따라, 독립적인 데이터 센터에 각각 물리 서버의 어플리케이션을 구동하고 운영하고 있는데요. 유지 및 보수 비용이 상당하고, 소수의 인원으로 운영하기에 녹록치 않았습니다.
그래서 이를 개선하기 위해 DC/OS를 도입했는데요. DC/OS에 서비스를 배포하면 서비스가 요구한 리소스를 측정하고, 적절한 서버에 즉시 자동 배치함으로써 과도한 리소스 사용으로 서버가 죽는 상황을 방지합니다. 새로운 서비스를 확장할 때도 추가적인 작업 없이 배포와 함께 자동으로 메트릭과 로그 수집, 로드밸런서 연결, 도메인 할당을 지원하여 쾌적한 배포, 운영 환경을 제공하고 있습니다.
blog.toss.im/2018/01/04/tossteam/insight/toss-engineering-updates/
토스 엔지니어링(Engineering)의 위대한 진화
불과 1년 만에 완전히 다른 차원의 금융 서비스로 발전한 토스. 그 기반이 된 엔지니어링은 어떤 변화가 있었을까요?
blog.toss.im
토스도 서비스가 증가하면서 전체적인 트랜잭션과 복잡성이 증가했다고 합니다. 그래서 기존 인프라만으로 현재 상태를 관리하기 어려워졌다고 합니다.
그래서 PoC 단계에 있던 Istio, K8s, Service Mesh 기반의 시스템으로 전환하기로 하고 9개월 동안 마이그레이션을 진행합니다. 이 과정에서 새로운 시스템에서 발생하는 문제를 빠르게 해결할 수 있도록 모니터링 시스템 변화가 필요했고 기존 influxdb(www.influxdata.com/), telegraf(www.influxdata.com/time-series-platform/telegraf/) 모니터링 환경을 prometheus(prometheus.io/), thanos(thanos.io/)로 변경하게 됩니다.
* 개인적으로 thanos 같은 서비스명은 기억하기는 쉽지만 구글 검색 시 해당 서비스로 바로 가기기 쉽지 않아 장단점이 있는 것 같습니다.
* 쿠버네티스, K8s 표현이 중간 중간 섞여 있어서, 같은 문서 또는 발표에서는 일관성이 있으면 좋겠더군요.
vamp는 장애 발생 시 전면 장애로 전파되는 문제를 가지고 있었는데 서비스 메쉬는 분산 API 게이트웨이가 적용되어 클라이언트 사이드 로드밸런싱이라 다른 게이트웨이에 장애 전파가 되지 않았다고 합니다. 그리고 서비스 로직에서 네트워크 구성에 대한 고려(mtls, 서킷 브레이커, 리트라이 로직)를 하지 않아도 되는 것도 장점이었다고 합니다.
