AppSignal은 Ruby 애플리케이션을 위한 에러 추적 서비스를 제공합니다. 애플리케이션에서 발생하는 모든 예외를 수집하고, 문제가 생기는 즉시 개발자에게 알려주는 것이 우리의 역할입니다.예외 처리를 올바르게 구현하는 것은 생각보다 까다롭습니다. 이 글에서는 Ruby에서 예외 처리가 어떻게 동작하는지, 잘못된 처리가 어떤 문제를 일으킬 수 있는지, 그리고 예외를 제대로 rescue 하는 방법을 차근차근 살펴보겠습니다.예외 rescue 하기Ruby에서 예외를 rescue 하면 오류가 발생하는 순간 애플리케이션이 종료되는 것을 막을

AppSignal을 사용하는 앱이 실행 중인 모든 서버는 30초마다 샘플과 메트릭 데이터를 저희 Push API로 전송합니다.월 300억 건의 요청, 캐싱으로 쿼리 줄이기각 요청에는 데이터가 어떤 앱에서 전송된 것인지 식별하는 키가 포함되어 있습니다. 이를 처리하려면 들어오는 모든 요청에 대해 데이터베이스를 조회해 해당 앱을 찾아야 합니다. 월 300억 건이라는 방대한 요청량을 감안할 때, AppSignal을 더 빠르게 만들기 위해서는 쿼리 수를 줄이는 방법을 끊임없이 고민해야 했습니다.그래서 저희는 데이터베이스 클러스터의 부하를

2024년 2월 25일에 예시 스크린샷과 오래된 링크를 최신 내용으로 업데이트했습니다.애플리케이션을 안정적으로 운영하려면 시스템의 부하(load)를 모니터링하는 것이 필수입니다. AppSignal의 호스트 메트릭은 여러 시간대별로 시스템에 걸렸던 부하 평균(load average)을 보여주어 시스템 상태를 한눈에 파악할 수 있게 해줍니다. top, uptime, w 같은 도구로도 이 지표를 확인할 수 있습니다.그렇다면 부하 평균은 정확히 무엇을 의미하고, 이 숫자들은 어떻게 해석해야 할까요? 이 글에서는 시스템 부하의 개념을 정리하

러시안 돌 캐싱(Russian doll caching) 외에도 Rails 애플리케이션의 성능을 높일 수 있는 방법은 다양합니다. 이번 글에서는 Rails에 내장된 조건부 GET(Conditional GET) 지원 기능을 살펴보겠습니다. 이 기능을 활용하면 렌더링된 페이지를 사용자의 브라우저 캐시에 저장할 수 있습니다. 👋 캐싱 외적인 성능 최적화에 관심이 있다면, 저희가 작성한 Ruby(on Rails) 성능 관련 글들도 확인해 보세요. Ruby 성능 모니터링 체크리스트도 함께 준비되어 있습니다. ETag와 Last-Modifie

Ruby에서 예외 발생 후 코드를 다시 실행하는 방법을 다룰 때 retry 키워드를 소개한 적이 있습니다. 그런데 retry에는 잘 알려지지 않은 짝꿍이 있는데, 바로 redo입니다. 두 키워드는 비슷하게 작동하지만, redo는 블록 전체가 아니라 루프의 현재 반복(iteration)만 다시 실행한다는 점이 다릅니다. redo 키워드 이해하기 이전 AppSignal Academy 아티클에서 배웠듯이, retry를 사용하면 블록 안의 코드를 처음부터 다시 실행할 수 있습니다. 이 예제는 예외를 발생시키기 전에 콘솔에 Iteratio

타입 강제 변환(type coercion)은 객체의 타입을 그 값을 함께 다루면서 다른 타입으로 바꾸는 과정을 말합니다. 예를 들어 #to_s로 Integer를 String으로 바꾸거나, #to_i로 Float을 Integer로 바꾸는 것이 대표적입니다. 일부 객체가 구현하고 있는 다소 생소한 #to_str과 #to_int 메서드도 얼핏 보면 같은 역할을 하는 것처럼 보이지만, 실제로는 몇 가지 중요한 차이점이 있습니다. 이번 AppSignal 아카데미에서는 Ruby에서 타입을 명시적으로 캐스팅하는 방법과 암시적으로 강제 변환하는

성능 모니터링은 애플리케이션을 성공적으로 운영하는 데 필수적인 요소입니다. 어떤 대상의 성능을 파악하는 가장 기본적인 방법 중 하나는 해당 작업이 실행될 때마다 소요 시간을 측정하고, 그 데이터로부터 통계를 도출하는 것입니다. 평균(Mean) 값들의 집합에 대한 평균은 어떤 것이 얼마나 좋거나 나쁘게 동작하는지 살펴보는 좋은 출발점입니다. 평균은 고려 대상인 모든 값을 더한 뒤, 발생 횟수로 나누어 계산합니다. Ruby에서는 다음과 같이 평균 응답 시간을 계산할 수 있습니다: 참고: 예제에서는 나눗셈 시 더 정확한 결과를 얻기 위

애플리케이션만 모니터링해서는 시스템 전체를 파악하기에 충분하지 않은 경우가 많습니다. 위성 앱(또는 보조 앱)에서 실행되는 서비스가 일상 운영에 결정적인 영향을 미칠 수 있기 때문입니다. 데이터베이스 서버가 대표적인 예이며, 백업 스크립트나 기타 백그라운드 작업 역시 시스템 성능을 저하시키면서도 자주 간과됩니다.AppSignal의 Node.js용 APM, Ruby용 APM, Elixir용 APM은 애플리케이션 자체를 자동으로 계측합니다. 하지만 AppSignal은 기본적으로 이러한 위성 프로세스까지는 감시하지 않습니다. 모니터링 범

Rails 7의 출시가 코앞으로 다가왔습니다. 확정된 출시일은 아직 발표되지 않았지만, 크리스마스 전에는 만나볼 수 있을 것으로 예상되므로 그리 멀지 않았습니다. 이 글을 작성하는 시점의 최신 버전은 첫 번째 릴리스 후보(release candidate)인 7.0.0.rc1입니다. Basecamp, HEY, GitHub, Shopify 등 주요 서비스들이 이미 프로덕션 환경에서 Rails 7 알파 버전을 운영해 왔기 때문에, 릴리스 후보 단계에서도 상당히 안정적인 품질을 기대할 수 있습니다. 이번 글에서는 Rails 7이 가져올 주

이 글에서는 Rails 애플리케이션에서 데이터베이스 성능을 테스트하는 방법과 가장 흔하게 발생하는 데이터베이스 성능 문제를 해결하는 전략을 다룹니다. Rails 애플리케이션을 개발할 때 ActiveRecord는 기본적으로 데이터베이스를 관리하는 도구입니다. ActiveRecord는 .where, .save, .create, .update 같은 직관적인 명령어로 데이터를 조회하고 삽입할 수 있는 쉽고 빠른 인터페이스를 제공합니다. Rails가 이러한 명령어를 SQL 쿼리로 변환해 주기 때문에 개발 생산성은 높아지지만, 때로는 성능 문

대부분의 애플리케이션은 메일 발송, 주기적인 데이터 정리, 사용자가 대기할 필요 없는 시간이 오래 걸리는 작업 등을 위해 백그라운드 잡(job) 기능을 필요로 합니다. Rails 생태계에는 잡 큐와 백그라운드 처리를 지원하는 여러 젬(gem)이 있으며, 그중 Delayed Job과 Sidekiq가 가장 널리 사용되는 두 가지입니다. 이 글에서는 Delayed Job과 Sidekiq를 자세히 살펴보고, 두 도구가 서로 어떤 차이를 보이는지 비교해 보겠습니다. 그럼 시작해 보겠습니다! Delayed Job 간단 소개 Delayed Jo

테스트가 너무 빠르다고 불평하는 개발자를 본 적이 있습니까? 저는 없습니다. 빠른 테스트는 곧 빠른 피드백을 의미합니다. 로컬 환경에서든 CI(지속적 통합) 파이프라인에서든, 테스트가 일찍 끝날수록 실패에 더 빨리 대응하고 코드를 개선할 수 있습니다. 생산성 향상 외에도, 느린 테스트가 개발자를 짜증나게 만든다는 사실은 잘 알려져 있습니다. 짜증난 개발자를 좋아하는 사람은 없죠. 그렇다 하더라도 번개처럼 빠른 테스트 스위트를 만드는 일은 생각만큼 쉽지 않습니다. 다행히 Rails 6에는 병렬 테스트(parallel testing)라

Rails 개발자들이 자주 마주치는 데이터베이스 문제 중 하나가 바로 데이터 무결성(data integrity) 문제입니다. 적절한 유효성 검증과 더불어, 잘 설계된 트랜잭션 블록은 데이터가 일부만 생성되거나 업데이트되는 상황을 방지해 줍니다. 하지만 트랜잭션은 제대로 설계되지 않으면 애플리케이션에 악영향을 주거나, 심한 경우 데이터베이스 전체를 마비시킬 수도 있습니다. 이 글에서는 트랜잭션을 다룰 때 활용할 수 있는 모범 사례들을 소개합니다. 팁 자체는 간단하지만, 여러분의 트랜잭션이 견고하고 가독성 높으며 안전하게 동작하도록 만

소프트웨어 엔지니어에게 프로덕션 코드의 핵심 부분을 리뷰해 달라고 요청하면, 십중팔구 리팩토링이 필요한 부분을 여럿 지적하게 됩니다. 그렇다면 왜 이렇게나 많은 저품질·취약·오해석된 코드가 프로덕션 환경에서 계속 돌아가고 있을까요? 답은 간단합니다. 엔지니어들이 해당 코드를 수정하는 것을 두려워하기 때문입니다. 리팩토링 작업은 문제로 식별되어 백로그에 추가되곤 하지만, 정작 현재 스프린트에 반영되는 일은 드뭅니다. 여기에는 여러 가지 이유가 있습니다. 코드가 몇 년 전 팀을 떠난 엔지니어가 작성한 것이라 아무도 완전히 이해하지 못하

객체지향 프로그래밍(OOP)으로 애플리케이션을 개발해 본 경험이 있다면, 다형성(Polymorphism)이라는 개념을 실제로 활용했거나 최소한 한 번쯤은 들어보셨을 것입니다. 과학이나 컴퓨터 공학 교과서에서나 볼 법한 용어라 어렵게 느껴질 수 있지만, 사실 많은 개발자가 정확한 개념을 이해하지 못한 채 다형성을 구현하고 있기도 합니다. 이 글에서는 특히 Ruby on Rails 환경에서의 다형성을 심도 있게 다룹니다. 구체적으로 살펴볼 내용은 다음과 같습니다. 실생활에서의 다형성 OOP 관점에서 바라본 프로그래밍의 다형성 Rail

한번 상상해 보세요. 여러분은 Rails 개발자이고, 지난 며칠간 모두가 애타게 기다리던 멋진 기능을 개발했습니다. 규모도 크고 복잡하지만 철저한 테스트를 거쳤기 때문에 모든 것이 정상적으로 동작할 것이라 확신합니다. 마감 기한도 다가오니 배포를 진행합니다. 그런데 순식간에 모든 것이 폭주하기 시작합니다. 새 기능이 일부 사용자에게는 앱 전체를 망가뜨리고 만 것입니다. 원인을 파악하기도 어렵습니다. 테스트 중에는 어떠한 버그도 발견되지 않았는데 말이죠. 변경 사항을 롤백하지만 이미 피해는 발생한 뒤입니다. 고객들은 불만스러워하고,

상태 머신(state machine)은 어떤 대상이 가질 수 있는 모든 상태와, 그 상태들 사이에서 허용된 전환(transition)을 담아낼 수 있습니다. 예를 들어 문(door)의 상태 머신은 단 두 가지 상태(open과 closed)와 두 가지 전환(opening과 closing)만 가집니다. 반면 복잡한 상태 머신은 여러 다양한 상태와 그 사이를 잇는 수백 개의 전환을 가질 수도 있습니다. 실제로 주위를 둘러보면 어디에나 유한 상태 머신(finite state machine)이 존재한다는 것을 알게 됩니다. 웹사이트에서 물건

Hotwire는 요즘 모든 Rails 개발자들 사이에서 가장 뜨거운 화두입니다. Rails로 개발하고 계신다면 이미 여러 차례 들어보셨을 가능성이 높습니다. Hotwire는 단 몇 줄의 코드만으로 애플리케이션에 인터랙티브 기능을 추가할 수 있는 완전히 새로운 방식입니다. HTML을 네트워크(over the wire)로 직접 전송하는 방식을 채택하고 있어 놀라울 정도로 빠르게 동작합니다. 덕분에 대부분의 SPA(싱글 페이지 애플리케이션) 프레임워크 없이도 개발할 수 있으며, 렌더링 로직을 서버 쪽에 집중시키면서도 빠른 페이지 로딩 속

이 글에서는 Ruby on Rails 애플리케이션에 Capistrano를 설정하는 방법을 알아보겠습니다. 이후 Ubuntu 운영체제가 실행되는 클라우드 인스턴스에 앱을 배포할 텐데요, 이 과정은 호스팅 업체와 무관하게 진행됩니다. 어떤 클라우드 서비스든, 심지어 온프레미스 서버를 사용해서도 여기서 소개하는 단계들을 그대로 테스트하거나 재현할 수 있습니다. 앱 배포가 완료되면 AppSignal을 활용해 배포 현황을 모니터링하는 방법도 간단히 살펴보겠습니다. 그런데 본격적으로 시작하기 전에 궁금증이 생길 수 있습니다. 지금 와서 굳이

메모리 누수(memory leak)란 의도치 않게, 통제 없이, 끝없이 메모리 사용량이 증가하는 현상을 말합니다. 아무리 작은 누수라도 결국에는 프로세스의 메모리가 고갈되어 크래시(crash)로 이어집니다. 주기적으로 앱을 재시작하며 이런 크래시를 피한다고 해도(비난할 생각은 없습니다, 저도 해봤으니까요!), 여전히 메모리 누수로 인한 성능 저하는 감수해야 합니다. 이 글은 메모리 누수 시리즈 두 편 중 첫 번째 글로, Ruby가 메모리를 어떻게 관리하는지, 가비지 컬렉션(GC)이 어떻게 동작하는지, 그리고 누수를 어떻게 찾아내는지