웹 서비스의 규모가 커지고 아키텍처가 모놀리식(Monolithic)에서 마이크로서비스(MSA)로 진화함에 따라, 개발자들이 가장 먼저 마주하는 난관 중 하나는 바로 ‘인증(Authentication) 시스템의 설계‘입니다. 과거 단일 서버 시절에는 별다른 고민 없이 사용하던 세션(Session) 방식이, 서버가 여러 대로 늘어나고 도메인이 분리되는 통합 계정 환경에서는 확장성의 발목을 잡는 주범이 되기도 합니다. 이에 대한 대안으로 JWT(Json Web Token)가 표준처럼 자리 잡았지만, JWT가 만능열쇠는 아니며 … 더 읽기
관측 가능성(Observability) 시리즈의 마지막 퍼즐이자, 마이크로서비스 아키텍처(MSA) 환경에서 병목 지점을 찾아내는 최고의 해결사인 “분산 추적(Distributed Tracing)“에 대한 포스팅입니다. 우리는 지금까지 ELK Stack을 통해 “과거에 발생한 에러 로그”를 통합 관리하는 법을 배웠고, Prometheus와 Grafana를 통해 “현재 서버의 리소스 상태”를 모니터링하는 체계를 갖추었습니다. 이 두 가지 시스템만으로도 모놀리식(Monolithic) 아키텍처나 서버 개수가 적은 환경에서는 충분한 관제 능력을 발휘할 수 있습니다. … 더 읽기
이전 포스팅에서 다룬 ELK Stack이 “과거에 무슨 일이 있었는지(Logs)“를 분석하는 도구라면, 오늘 다룰 Prometheus와 Grafana는 “현재 서버의 상태가 어떤지(Metrics)“를 진단하는 청진기와 같습니다. 지난 시간에 우리는 ELK Stack을 통해 대용량 로그를 통합 관리하는 방법을 배웠습니다. 이제 여러분은 특정 에러가 언제 발생했는지 로그를 통해 추적할 수 있는 능력을 갖추게 되었습니다. 하지만 로그만으로는 시스템의 전체적인 건강 상태를 파악하는 … 더 읽기
지난 포스팅에서 Logback을 이용해 단일 서버 환경에서 로그를 파일로 남기고, 치명적인 에러가 발생했을 때 슬랙(Slack)으로 알림을 받는 방법까지 알아보았습니다. 서비스 초기 단계나 트래픽이 많지 않은 단일 서버 아키텍처(Monolithic Architecture)에서는 이 정도 설정만으로도 충분히 운영이 가능합니다. 개발자가 필요할 때 서버에 접속해서 vim이나 cat, grep 명령어로 로그 파일을 열어보면 되기 때문입니다. 하지만 서비스가 성장하여 서버가 10대, 100대로 늘어나거나, 마이크로서비스 아키텍처(MSA)를 도입하여 수십 … 더 읽기