웹 서비스의 보안 수준이 지속적으로 강화되면서, 구형 암호화 프로토콜인 TLS 1.0과 TLS 1.1의 지원을 중단하고 TLS 1.2 및 TLS 1.3으로 전환하는 기업이 늘고 있습니다. 하지만 무턱대고 하위 버전의 지원을 끊어버리면 구형 브라우저나 오래된 디바이스(예: 구형 안드로이드, IoT 기기 등)를 사용하는 고객들의 접속이 전면 차단되는 장애가 발생할 수 있습니다. 따라서 보안 정책을 업데이트하기 전, 현재 우리 서비스에 … 더 읽기
백엔드 시스템의 성능을 최적화하는 과정에서 가장 가성비가 좋고 즉각적인 효과를 볼 수 있는 기술은 단연 ‘캐싱(Caching)‘입니다. 관계형 데이터베이스(RDBMS)는 디스크 I/O를 기반으로 동작하기 때문에 물리적인 속도의 한계가 명확하며, 트래픽이 몰릴 경우 병목 현상의 주범이 됩니다. 반면 Redis와 같은 인메모리(In-Memory) 저장소는 RAM에 데이터를 저장하고 처리하므로, 디스크보다 수백 배 빠른 접근 속도를 제공합니다. 하지만 “Redis를 도입했다”는 사실만으로 모든 … 더 읽기
관측 가능성(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)를 도입하여 수십 … 더 읽기
앞선 포스팅들을 통해 견고한 백엔드 시스템을 설계하고 예외를 처리하는 방법까지 마스터했습니다. 이제 마지막 퍼즐인 ‘운영(Operation)’ 단계로 넘어갈 차례입니다. 서버는 24시간 돌아가지만, 개발자가 24시간 모니터를 보고 있을 수는 없습니다. 서버가 언제 아팠는지, 어디서 에러가 터졌는지 기록을 남기고(Logging), 심각한 문제가 발생하면 자고 있는 개발자를 깨워야(Alerting) 합니다. “로그(Log)는 서버의 블랙박스입니다.” 비행기 사고가 나면 가장 먼저 블랙박스를 찾듯, 서버에 장애가 발생했을 … 더 읽기