개요

난 기술과 관련된 글을 써서 이 블로그에 게재하고 있다. 최근에는 블로그 글을 GeekNews에 링크로 공유한 적이 있었다. 그런데 갑자기 블로그 백엔드 서버가 작동 불능에 빠지면서 블로그 접속 장애를 겪었다.

로그 및 매트릭을 분석한 결과, 블로그 백엔드 서버의 데이터베이스 접속 불가로 인한 서비스 거부 징후가 확인되었다.

이 글에서는 장애 재발 방지를 위해 택한 개선 방안과 그 결과를 기록한다.

글에 글어가기 앞서, 이 블로그의 SLA¹를 수치화한 결과를 먼저 공유하겠다. 개선 전/후를 비교하면 아래와 같다.

• 개선 전: 51% (1분당 약 400회 요청시)
• 개선 후: 99.9996286% (분당 약 40,500회 요청시)

접속 장애 당시 상황

사진: 출처

2025년 4월 13일 오전, 나는 내 블로그 글을 한국어 개발 뉴스 사이트 GeekNews에 등록하였다^{2 3}. 이후 GeekNews 방문자들이 내 블로그에 유입되었다 ⁴.

그런데, 일부 방문자는 접속 장애를 겪었다.

테크 스택

이 블로그의 게시되는 모든 글과 사진에 대한 CRUD를 담당하는, 블로그 백엔드 서버의 테크 스택은 아래와 같이 요약된다.

• DB 타입: PostgreSQL
• PostgreSQL 배포처: Supabase
• SQL 클라이언트: launchbadge/sqlx::postgresql (이하 "sqlx")
• 백엔드 서버는 서버리스 환경(AWS Lambda)에 배포됨

^{5 6}

당시 트래픽

블로그 접속 장애 발생 시점의 트래픽 수치는 다음과 같다.

• 블로그 백엔드 서버의 호출 빈도는 분당 평균 96회, 분당 최대 400회.
• AWS Lambda concurrent execution 수치는 분당 약 27단위⁷.

당시 에러 로그

접속 불가 현상이 발생할 때 기록된⁸ 에러 로그는 아래와 같다.

thread 'main' panicked at src/main.rs:52:10: can't connect to database: PoolTimedOut

sqlx에서 PoolTimedOut 에러를 일으킨 것으로 확인된다.

중간 정리

1. 시스템이 감당하지 못하는 트래픽 유입이 발생하였다.
2. 트래픽에 대응하기 위해 많은 서버가 동시에 생성되었다.
3. 각 서버가 1개의 PostgreSQL 데이터베이스에 접근을 시도하였다.
4. 데이터베이스의 자원이 빠르게 소진되었고 결국 고갈되자, 일부 서버는 데이터베이스 접근을 실패하는 상황이 벌어졌다.
5. 데이터베이스 서버 접근에 실패한 서버들은 프로세스를 강제 종료하였고, 네트워크 응답을 거부하였다.

즉, 블로그 백엔드 서버의 데이터베이스 접속 실패가 이슈 발생 지점이다.

이슈 원인 분석

이슈 원인 분석에 앞서, 이 블로그는 총 2단계의 커넥션 풀을 사용하고 있다. 결론적으로는 이 커넥션 풀 관리에 문제가 있어 발생한 장애인데, 그 이유는 다음과 같다.

1차 커넥션 풀: Supabase의 PostgreSQL Connection Pooler

사진 출처: Supabase Documentation - Connecting to your database

Supabase는 PostgreSQL SaaS로써, 데이터베이스에 대한 자체적인 커넥션 풀을 제공한다.

Supabase의 'Connection Pooler'를 사용하면 커넥션 풀을 통한 데이터베이스 접근이 보장된다. 직접 접근 방식보다 좀 더 빠른 커넥션 획득이 가능하다는 장점이 있다.

한편, 블로그 서버는 prepared statements를 사용하여 쿼리 내 파라미터를 치환한다. sqlx는 이를 기본으로 지원하고 있으나⁹, Supabase의 "transaction mode connection pooler"는 현재 prepared statements를 지원하지 않고 있다¹⁰.

따라서 나는 prepared statements가 지원되는 Connection Pooler를 사용하기 위해, Supabase의 "session mode connection pooler"를 사용하여 데이터베이스에 접속하도록 했다.

이때 커넥션 풀 설정을 Supabase 대시보드에서 직접 지정할 수 있다¹¹. Supabase의 pool size 기본값은 15이다. 나는 기본값 그대로 배포하였다.

2차 커넥션 풀: 백엔드 내부

Supabase의 1차적인 커넥션 풀과 별개로 2차적인 커넥션 풀을 백엔드 서버 안에 두고 싶었기에, 나는 sqlx 문서에 소개된 커넥션 풀 예제 코드를 거의 그대로 복사하여 내 코드에 붙혀넣었다.

use sqlx::postgres::PgPoolOptions;

let pg_pool = PgPoolOptions::new()
    .max_connections(5)
    .acquire_timeout(Duration::from_secs(3))
    .connect(&db_connection_str)
    .await
    .expect("can't connect to database");

let conn = pg_pool.acquire().await.map_err(|_| internal_error())?;

2차 커넥션 풀의 이슈

이번 이슈를 확인하면서 백엔드 소스코드를 다시 확인하였다. 위 코드의 진짜 의미는 아래와 같았다.

• 최초에는 데이터베이스 커넥션을 0개만 점유함.
• 필요한 경우에 데이터베이스로부터 커넥션을 새롭게 1개 점유해오고, 서버 내 커넥션 풀에 등록.
• 커넥션 풀에 등록된 커넥션은 서버 안에서만 재사용함.
• 서버 내 커넥션 풀에 최대 5개 커넥션을 점유 가능.
• 한 번 점유해온 데이터베이스 커넥션은 10분 뒤에 자동으로 반환.
• 데이터베이스 커넥션을 새롭게 점유해올 때 만약 3초 안에 획득해오지 못하면 서버 강제 종료 처리.

특히, "커넥션을 10분 뒤 반환"하는 것은 sqlx 라이브러리의 자동 기본값이기에¹², 별도로 지정하지 않은 내 의도와는 다르게 적용된 정책인 셈이다.

문제가 발생할 시나리오는 다음과 같다.

먼저, '블로그 게시물 조회'가 동시에 15회 발생하였다고 가정해보자. 즉시 15개의 AWS Lambda 서버가 생성될 것이다. 이때 데이터베이스 커넥션을 각자 1개씩 점유하게 된다. 이는 Supabase의 pool size 기본값인 15개 전부를 벌써 점유해버리게 되는 셈이다.

앞서 처리되는 와중, '블로그 게시물 조회'가 딱 1건 더 발생하면 어떻게 될까? 앞서 생성된 15개의 AWS Lambda 서버들은 아직 요청을 처리하느라 바쁘기에, 새로운 요청을 처리하기 위한 새로운 16번째 AWS Lambda 서버가 생성될 것이다. 이 서버 또한 데이터베이스 커넥션 점유를 시도할 것이다. 그런데 Supabase는 더 이상 할당시킬 커넥션 자원이 없기 때문에 점유 대기를 발생시킨다.

앞서 생성된 15개의 서버들은 최장 10분간 커넥션 자원을 내놓지 않을 것이다. 이에 16번째 서버는 커넥션 지연을 기다리다 3초가 지나버리는 순간, 해당 서버는 강제 종료되고 응답에 실패하게 된다. 17번째, 18번째 요청이 들어오더라도, 커넥션 자원이 고갈된 이상 응답에 실패할 수 밖에 없다.

즉, 2차 커넥션 풀의 잘못된 설정으로 인해, 1차 커넥션 풀을 모두 소진하고 자원 고갈을 발생시킨 셈이다.

최종 정리

블로그 백엔드 서버는 Supabase의 1차적인 커넥션 풀에서 커넥션을 획득해오고 있었다. 1차 커넥션 풀의 사이즈는 15개로 다소 한정적인 상황이었다.

블로그 백엔드 서버가 앞서 가져온 커넥션을 서버 내부에 보관하는 2차적인 커넥션 풀을 생성하도록 구현되었는데, pool size는 5개로 적었지만 커넥션 점유 후 반환 전 대기 시간이 10분으로 과도하게 길었다.

한편, 2차 커넥션 풀은 각 서버 내부에서만 사용되며, 다른 서버와 공유되지 않고 있다.

이러한 2차 커넥션 풀 생성으로 인해 Supabase 데이터베이스 커넥션 자원이 완전히 소모되었다. 그런데 2차 커넥션 풀에서는 한 번 점유해온 커넥션을 즉시 반환하지 않았기에, 1차 커넥션 풀의 자원 고갈 상태가 일정 시간 유지되었다.

자원 고갈 상태에서 커넥션을 시도한 서버 프로세스는 전부 강제 종료되는 결과를 낳았고, 이는 서버 시스템의 전체적인 응답 거부로 이어졌다.

개선 방안

일단 1차 커넥션 풀 정책을 최대 수준으로 늘렸다. Supabase 무료 플랜에서는 pool size를 48개까지 늘릴 수 있기에 바로 적용하였다.

그리고 2차 커넥션 풀 정책을 최소 수준으로 줄였다. 서버 내 커넥션 풀 관리 정책을 손보았다¹³.

let pg_pool = PgPoolOptions::new()
     .max_connections(1)
     .acquire_timeout(Duration::from_secs(3))
     .idle_timeout(Duration::from_secs(3))
     .connect(&db_connection_str)
     .await
     .expect("can't connect to database");

의미는 아래와 같다.

• 한 서버에서 동시에 점유 가능한 최대 커넥션 개수는 1개.
• 한 번 점유해온 데이터베이스 커넥션은 사용여부를 체크하여 3초 뒤에 자동으로 반환.

2차 커넥션 풀을 최소한으로 유지하여 서버 내 커넥션 재활용을 가능케 하는 동시에, 너무 오래 커넥션을 점유하지 않게 수정하여 1차 커넥션 풀이 항상 여유롭도록 개선하였다. 동시에 1차 커넥션 풀의 크기를 키워 많은 양의 커넥션을 활용할 수 있도록 하였다.

개선안 검증

사진: 부하 테스팅 서비스 'loadster'로 이 블로그에 부하 테스트를 진행하였다.

사진: 부하 테스트가 이루어진 후 AWS Lambda 대시보드를 통해 확인한 매트릭.

개선점을 전부 적용한 후 일부러 더 극심한 트래픽을 설정하고 부하 테스트를 진행하였다.

부하 테스트는 3분 내외 시간동안 진행되었으며, 부하의 정점을 찍었을 때에는 1분간 약 40,500회 정도의 요청이 서버에 전송되었다.

개선안 검증 결과

Amazon CloudWatch에 기록된 서버 로그를 집계한 결과, 107,705회의 전체 요청 중 응답 거부 사례가 총 40회 발견되었다.

최소 서비스 가용성을 수치화해본 결과가 재미있다.

• 기존: 51% (1분당 약 400회 요청시)
• 현재: 99.9996286% (1분당 약 40,500회 요청시)

결론

블로그에서 발생했던 접속 불능 장애 원인을 성공적으로 파악하였고, 장애 발생률을 "사실상 극복했다"고 볼 수 있는 수준까지 낮출 수 있었다. 다행히도 비용 부담이 별도로 발생하거나 추가되지 않았으며, 데이터베이스를 다루는 현행 구조를 크게 바꾸지 않을 수 있었다.

소감

결론적으로는, 라이브러리가 어떤 기본값을 가지고 구성되는지¹² 확인하였다면 막을 수 있었을 것 같아서, 확인이 누락된 부분이 아쉽게 느껴진다. 그리고, 사전 부하 테스트의 중요성을 다시끔 느겼다.

이번 장애가 나에게 있어서는, '소스 코드 안에서는 보이지 않는 부분들을 검증하는 작업'의 중요성을 뻐저리게 느끼는 계기가 되었다.

Footnotes

1. Wikipedia - Service-level Agreement - Cloud Computing - "SLAs span across the cloud and are offered by service providers as a service-based agreements rather than a customer-based agreements. Measuring, monitoring and reporting on cloud performance is based on the end UX or their ability to consume resources." ↩

2. https://blog.atj.sh/post/45 ↩

3. GeekNews - 그냥 LLM이 코드베이스 전체를 이해해주면 안 될까: 번들링을 통한 RAG 시도 ↩

4. 이처럼 '더 큰 규모의 웹사이트로부터의 트래픽 유입으로 인한 서비스 장애'을 "슬래시닷 효과"라 한다. 위키백과 - 슬래시닷 효과 ↩

5. 블로그 전체에 대한 테크 스택은 다른 글에 정리해 두었다. 전성훈의 블로그 - blog.atj.sh ↩

6. 전성훈의 블로그 - PostgreSQL를 이미지 저장소로 활용하기 ↩

7. 동시에 실행된 AWS Lambda 함수 개수를 의미한다. Amazon AWS Documentation - Understanding Lambda function scaling ↩

8. 서비스 모니터링을 위해 Amazon Cloudwatch로 로그를 수집하고 있었다. ↩

9. launchbadge/sqlx/README.md - "When using the high-level query API (sqlx::query), statements are prepared and cached per connection." ↩

10. Supabase Database Documentation - Connect to your database - Supavisor transaction mode - "Transaction mode does not support prepared statements. To avoid errors, turn off prepared statements for your connection library." ↩

11. Supabase Database Documentation - Connection management ↩

12. sqlx의 커넥션 풀 생성 옵션의 기본값들은 launchbadge/sqlx - PoolOptions::new()에서 확인해볼 수 있다. ↩ ↩²

13. https://github.com/atjsh/rust-blog/commit/a757834af7d9204684ae5a865922e9eb5d3659c5 ↩