완득님의 블로그

SQL INJECTION (SQL 인젝션 방지)

wanduek — Tue, 29 Apr 2025 23:03:44 +0900

SQL INJECTION이란?

SQL 인젝션(SQL Injection)

웹 애플리케이션에서 사용자 입력값을 제대로 검증하지 않고 SQL 쿼리에 포함시킬 때 발생하는 보안 취약점입니다. 공격자는 이를 악용해 데이터베이스를 임의로 조작하거나 민감한 정보를 탈취할 수 있습니다.

-- 로그인 쿼리 예시
SELECT * FROM users WHERE username = 'admin' AND password = '1234';

위 쿼리가 아래처럼 사용자 입력을 문자열로 그대로 받는 경우

username = 'admin' -- '
password = '아무거나'

그럼 최종 쿼리는 이렇게 변합니다

SELECT * FROM users WHERE username = 'admin' -- ' AND password = '아무거나';

--는 SQL 주석이라 이후는 무시되고, 결국 username = 'admin'만으로 로그인하게 됩니다.

또한 username = 'admin' OR '1'='1'로 하게된다면

SELECT 1 FROM users WHERE username = '1' OR '1'='1' AND password= '...';

이 쿼리는 다음과 같은 의미로 해석됩니다:

username = '1'는 무시되고
'1'='1'는 항상 참이기 때문에
해당 조건을 만족하는 모든 유저들이 조회될 수 있습니다.

이게 바로 SQL 인젝션 공격입니다.

방어방법

Prepared Statement (PreparedQuery) 사용
→ SQL 쿼리를 사전에 컴파일하고, 변수만 바인딩해 실행
→ 예: Java의 PreparedStatement, Python의 cursor.execute("SELECT ... WHERE id = %s", [user_id])
ORM 사용
→ JPA, Hibernate, Django ORM 등은 기본적으로 SQL 인젝션에 안전
입력 값 검증 및 필터링
→ 숫자만 필요한 곳엔 숫자만 받도록 제한
최소 권한의 DB 계정 사용
→ 애플리케이션이 DB에 접근할 때, 꼭 필요한 권한만 부여

DB 커넥션 수 최적화 전략

wanduek — Mon, 14 Apr 2025 21:27:37 +0900

만일 다수의 DB 커넥션이 연결되어 있어 리소스의 비용이 낭비되고 있을때 어떻게 해야 커넥션 수를 줄여 리소스 비용을 줄일수 있을까

[Access Phase]

조건 검증 + Rate Limit (Shared dict 활용)
- 조건 검증 : JWT 검증
과도 요청시 바로 차단 (return 429)
- shared dict late limiter를 통해 과도한 접속 제한
- 과도하게 접속한 유저는 일정시간동안 접속 제한
DB 커넥션 연결 전에 최대한 fail fast 처리
fail fast 처리
- rate limiter
- header 검사
- JWT Signature Validation

[Content Phase]

DB 연결 (필요할 때만)
커넥션 풀 사용 (keepalive)
- 커넥션 풀을 사용하면 미리 일정 수의 DB 연결을 만들어두고, 요청이 올 때마다 풀에서 커넥션을 재사용함. 이렇게 하면 연결과 종료에 드는 시간을 줄여서 응답 속도 개선과 과도한 커넥션 생성을 막고 DB 서버의 부하를 줄일 수 있음.
캐싱 (Redis)
- shared dict보다 더 많은 수용이 가능해야하는 인 메모리 캐시가 필요하다. 즉 shared dict에 비해 더 많은 용량을 사용할 수 있는 Redis를 사용하는 것이 적합하다고 판단함.
캐싱 전략
- 일관성 중요, 커넥션 수 줄이는 것도 중요 그러면 write-through 캐싱전략
- write_through를 통해 DB에 쓰는 작업과 동시에 캐시에 쓰는 작업이기에 데이터 일관성을 유지할 수 있음
- 혹여나 캐시 누락 방지를 위해 TTL을 사용하여 캐시 누락을 방지함.

[Log Phase]

요청 / 응답 / 커넥션 상태 로깅

부하 테스트 (/seller/api/v1/records 기준)

부하 테스트를 통해 keepalive의 적용 전 적용 후를 비교하여 실제 커넥션 수가 얼마나 활성화가 되어 있는지 활성화 되어 있는 커넥션 수가 커넥션 풀로인해 감소가 되는지 커넥션 수가 감소되면 얼마나 감소되는지에 대해 알아보기 위해 WRK와 HEY를 통해 부하 테스트를 진행하게 되었습니다.

WRK 테스트

-t 10 → 10개의 Thread

-c 100 → 100개의 연결 유지

-d 10s → 10초동안 최대 요청

keepalive 적용 전

적용 후

항목	keepalive 적용 전	keepalive 적용 후	변화
평균 Latency	102ms	58ms	43% 감소
Requests/sec	981 req/s	1842 req/s	88% 증가
총 처리 요청 수	9875	18563	88% 증가
Transfer/sec	3.67MB/s	6.89MB/s	88% 증가

HEY 테스트

-n 1000 → 총 1000건

-c 100 → 동시 100개 연결 유지

총 1000건 응답

keepalive 적용 전

적용 후

평균 응답 시간 47% 감소

90.7ms → 47.8ms로 크게 줄음.
DB 연결을 매번 새로 열지 않고, 커넥션 풀을 재사용한 효과가 나타남.

처리 속도 49% 증가

초당 처리 가능한 요청 수가 1011 → 1503으로 거의 1.5배 증가함.
이는 시스템 자원을 더 효율적으로 사용하고 있음.

대다수 요청의 응답 시간 개선

75%의 요청이 39.2ms 이내에 처리됨 (keepalive 후)
반면, keepalive 전에는 75%가 93.4ms 이내에 처리됨.
→ 빠르게 끝나는 요청이 훨씬 많아졌음.

커넥션 풀 적용 전

커넥션 풀 적용 후

동일한 조건으로 Records 데이터를 조회했을 때, 커넥션 풀을 적용하지 않은 경우 PostgreSQL에는 2개의 커넥션이 활성화되었습니다. 이는 매 요청마다 새로운 커넥션을 생성하고 종료하기 때문에 발생하는 현상으로, 시스템 부하 증가 및 자원 낭비로 이어질 수 있습니다.

반면 커넥션 풀(keepalive) 을 적용한 이후에는 1개의 커넥션만 유지된 채 모든 요청이 처리되었습니다. 이는 이미 생성된 커넥션을 재사용함으로써 불필요한 커넥션 생성을 방지하고, 네트워크 및 DB 리소스 사용을 최소화한 결과입니다.

이 실험을 통해 커넥션 풀 도입이 실제로 DB 커넥션 수를 줄이고, 시스템 자원을 보다 효율적으로 사용하는 데 효과적이라는 것을 확인할 수 있었습니다. (다만 커넥션 풀에 연결할 수 있는 최대 커넥션 수를 테스트 규모에 비해 많이 설정해 놓아 대기 중인 커넥션 풀 수가 많어 다음 커넥션 풀 테스트 진행시 조절을 해야될 것 같다.)

Access Phase

access_by_lua에서 효율적인 요청 처리 전략을 구축하기 위해, 조건 검증과 Rate Limiting을 통해 불필요한 DB 요청을 사전에 차단하고, 과도한 트래픽을 제한하는 방식으로 하여 초기에 DB 접근을 최소화 하고자 하였습니다.

1. 조건 검증 (Validation)

JWT 검증: Records API 요청에 대해 JWT (JSON Web Token)을 검증하여 사용자의 인증 여부를 확인합니다. JWT 검증은 API 요청의 유효성을 먼저 검사하는 중요한 작업입니다. 이 과정에서 유효하지 않은 토큰을 가진 요청을 빠르게 차단함으로써 DB 및 시스템 자원의 낭비를 방지합니다.

Header 및 Parameter 검증: Records API가 필수적으로 요구하는 targerId나 targetModel 혹은 페이지네이션 파라미터가 누락되었거나 잘못된 형식인 경우 이를 조기에 감지하여 즉시 400 Bad Request을 반환하여 불필요한 DB 및 시스템 자원의 낭비를 방지합니다.

2. Rate Limiting (Shared Dict 활용)

과도한 요청 제한: Rate Limiting을 통해 유저에 대한 요청을 제한할 수 있습니다. shared dict를 활용하여, 요청의 수가 급증하는 상황에서 과도한 요청을 차단하고, 일정 시간 동안 반복된 요청을 제한합니다.

Shared Dict를 이용해 각 유저의 요청 횟수를 추적하고, 일정 횟수를 초과한 유저에 대해 제한을 가할 수 있습니다.
과도한 요청을 보내는 유저는 일정 시간 동안 429 Too Many Requests 상태 코드로 응답하고, 제한된 시간 동안 더 이상 요청을 처리하지 않습니다.

이 두가지를 통해 Fail Fast를 하여 시스템에서 오류를 미리 감지하고 빠르게 처리하여 문제의 확산을 막는 전략을 구상하였습니다. DB 커넥션을 설정하기 전에 빠르게 오류를 감지하고, 불필요한 DB 연결을 방지할 수 있습니다.

Shared Dict을 사용하는 이유는?

Rate Limiting은 클라이언트(IP 또는 사용자 기반)의 요청 횟수를 짧은 시간 동안 추적하여 과도한 트래픽을 제어하는 기능입니다. 이때 사용되는 데이터는 단순 카운터이며, 보통 소량의 키-값 정보만을 저장하면 되기 때문에 고용량의 저장소가 필요하지 않습니다.

또한 외부 저장소를 거치지 않으므로 네트워크 비용 없이 단순한 구조로 구현이 가능하고 수십~ 수천 요청을 처리하더라도 큰 메모리를 요구하지 않습니다.

결과적으로 shared dict은 복잡한 구조 없이 경량, 단기 저장이 필요한 데이터에 최적화되어 있어 rate limiting의 요건과 잘 부합하다고 판단됩니다.

Content Phase

효율적인 커넥션 풀 사용을 위한 커넥션 수 튜닝전략

keepalive timeout
- 조회 빈도가 낮은 환경에서는 짧은 keepalive timeout을 설정하는 것이 더 효율적입니다.
- 커넥션이 장시간 유휴 상태로 남는 것을 피하고, 불필요한 자원 사용을 줄이기 위해 keepalive timeout을 상대적으로 짧게 설정합니다. (예: 5~10초)
max idle connections 설정
- 너무 많은 커넥션을 유지하려고 하지 않으므로 커넥션 풀에 연결할 수 있는 최대 커넥션 수를 낮춰서 자원 낭비를 최소화합니다. (예: 10~ 20개)

캐싱 전략

Redis의 사용 이유?

용량 제한 극복
- shared dict은 OpenResty가 시작될 때 고정된 크기의 메모리를 할당받아 캐시 가능한 데이터의 양이 매우 제한적입니다.
- 하지만 Redis는 외부 프로세스로 동작하며 수백 MB~ 수십 GB 이상까지 메모리를 유연하게 사용할 수 있어 대량의 캐시 데이터 처리에 유리합니다.
- Redis는 TTL, pub/sub 등 다양한 기능을 지원하며, 복잡한 캐싱 전략 구현에도 유리합니다.
  - (TTL과 write-through 사용예정)
- 반면 shared dict은 단순한 key-value 저장에 적합하며 기능적 제약이 큽니다.
write-through
- write-through 캐싱은 DB에 데이터를 쓸 때 동시에 캐시에도 쓰는 방식입니다.
- 이 방식은 항상 최신 데이터를 캐시에 반영하기 때문에 읽기 시점에서 DB와 캐시 간 데이터 일관성을 보장할 수 있습니다.
TTL (Time-To-Live)
- write-through만 사용할 경우 삭제나 수정이 거의 없는 데이터는 캐시에 무한정 남아 있을 수 있습니다.
- 또한 오랫동안 비사용하는 캐시 데이터에 대해 제거가 필요하고
- 예상치 못한 업데이트 누락이 발생했을 때 데이터 일관성을 회복할 기회를 제공합니다.

요약하자면 write-through로 데이터 일관성을 확보하고 TTL로 캐시 정리 및 재검증 기회를 확보함으로써 안정적이고 효율적인 캐싱 전략을 구상하였습니다.

최종적으로는

Access Phase에서는 불필요한 요청을 조기에 차단함으로써 DB까지 요청이 도달하지 않도록 하는 역할을 합니다.

JWT 등의 토큰 유효성 검사를 통해 유효하지 않은 요청은 바로 거절(401 Unauthorized)을 하고 Rate Limiting의 shared dict 등을 활용해 요청 횟수 제한을 하여 과도한 요청 시 차단을 합니다.(429 Too Many Requests)

그리고 헤더 값이나 필수 파라미터 미비 여부 검증을 통해 조건에 안 맞는 요청은 차단합니다. 이렇게 Fail Fast 전략을 통해 유효하지 않은 요청은 DB에 접근하기 전에 차단되어 DB 커넥션을 아예 사용하지 않게 합니다.

Access Phase에서 검증이 완료되고 Content Phase에서는 캐시 및 커넥션 풀을 통한 커넥션 재사용으로 효율적으로 처리합니다. 자주 조회되는 데이터를 Redis에 응답하여 DB 조회를 생략하고 커넥션 풀을 통해 DB 연결을 매번 새로 하지 않고, 재사용 가능한 커넥션 풀에서 연결을 가져와서 연결/해제 비용을 감소하게 됩니다.

openresty DB 커넥션 연결 최적화

wanduek — Fri, 11 Apr 2025 23:39:21 +0900

데이터베이스(DB) 연결은 단순한 작업처럼 보일 수 있지만, 실제로는 많은 시스템 자원(CPU, 메모리, 네트워크 등)을 소비하는 비용이 큰 작업이다. 만약 애플리케이션이 매 요청마다 DB에 새롭게 연결하고 해제한다면, 불필요한 리소스 낭비로 이어질 수 있다.

특히 다수의 사용자가 동시에 요청을 보내는 환경에서는, 반복적인 연결/해제 작업이 전체 시스템의 성능 저하와 병목 현상을 유발할 수 있다. 또한 데이터베이스 자체도 동시에 처리할 수 있는 연결 수에 한계가 있기 때문에, 무분별한 연결 시도는 DB 다운이나 서비스 지연을 초래할 수 있다.

이러한 문제를 방지하고 효율적인 리소스 관리를 위해서는, DB 연결을 보다 효율적으로 관리할 수 있는 전략이 필요하다. 가장 대표적인 방법으로는 커넥션 풀(Connection Pool)을 사용하는 것이다. 커넥션 풀은 미리 일정 수의 DB 연결을 생성해두고, 요청이 있을 때마다 이 연결을 재사용함으로써 성능을 최적화하고 자원 낭비를 줄여준다.

요약하자면

1. 연결/해제 자체가 비용이 크다

DB에 연결할 때는 네트워크 핸드셰이크, 인증, 세션 초기화 등의 복잡한 작업이 수행된디.
이 과정은 CPU와 메모리, 네트워크 자원을 많이 사용해서 매번 연결했다 끊는 건 매우 비효율적이다.

2. DB 커넥션 수는 제한적이다

대부분의 DB는 최대 연결 수(max connections) 설정이 있음.
(예: MySQL의 기본 max connections는 151개)
요청마다 DB에 새로 연결하면 이 수를 금방 초과해서 "too many connections" 에러가 발생할 수 있다.

3. 성능 저하 및 병목 현상

DB 연결이 잦으면 요청 처리 속도가 느려지고, 응답 지연(latency)이 발생한다.
특히 트래픽이 많은 상황에서는 병목 현상이 생겨 전체 서비스 속도가 저하될 수 있다.

해결책: 커넥션 풀(Connection Pool)

보통 애플리케이션은 DB 커넥션 풀을 사용해 일정 수의 연결을 미리 확보하고, 재사용함.

그래서 postgreSQL의 keepalive로 커넥션 풀에 대해 설명할려고 한다.

커넥션 풀이란?

"미리 만들어 놓은 DB 연결(Connection)을 모아두는 저장소(풀)"

애플리케이션이 DB 연결이 필요할 때마다 새로 연결하지 않고
미리 만들어 놓은 연결 중 하나를 빌려서 사용하고
다 쓰면 반납해서 다시 사용할 수 있도록 하는 구조이다!

동작 흐름 예시로 설명하자면...

애플리케이션 시작 시, DB 연결을 미리 여러 개 생성해둠 (예: 10개).
클라이언트 요청이 오면, 커넥션 풀에서 하나 빌려줌.
DB 작업을 마치면, 해제하지 않고 다시 풀에 반납.
다음 요청이 오면 다시 재사용.

그러면 테스트를 통해 성능이 얼마나 차이나는지 알아보자 (openresty 기준으로 설명)

WRK 테스트로 실행

-t 10 → 10개의 Thread

-c 100 → 100개의 연결 유지

-d 10s → 10초동안 최대 요청

keepalive란?

HTTP 요청마다 새로 연결하지 않고, 한 번 연결한 TCP 세션을 재사용하게 해주는 기능.

keepalive 적용 전

총 요청 9875건

적용 후

항목	keepalive 적용 전	keepalive 적용 후	변화
평균 Latency	102ms	58ms	43%감소
Requests/sec	981 req/s	1842req/s	88%증가
총 처리 요청 수	9875	18563	88%증가
Transfer/sec	3.67MB/s	6.89MB/s	88%증가

요청-응답 속도가 더 빨리지며 사용자 체감 속도 향상.
초당 처리 가능한 요청 수가 거의 2배 가까이 늘어남.
동일 시간 동안 훨씬 많은 요청을 처리. 서버 효율성 증가.
초당 전송되는 데이터 양도 증가. 대용량 데이터 처리에도 유리.

요약하면..?

keepalive 적용만으로도 서버의 성능이 대폭 향상됨
네트워크 연결 오버헤드 제거로 지연 시간은 줄고,
처리량과 응답 속도는 대폭 개선됨

서버에서 적합한 openresty의 phase 구조

wanduek — Thu, 10 Apr 2025 23:12:00 +0900

Nginx는 HTTP 요청을 처리할 때 여러 개의 처리 단계(phase)를 순차적으로 거칩니다. 각 phase에서 특정 handler 또는 module이 실행됩니다. OpenResty는 각 phase에 Lua 코드를 삽입할 수 있게 해주기 때문에, 이 구조를 이해하면 어떤 타이밍에 어떤 작업을 수행할 수 있는지 알 수 있습니다.

https://openresty-reference.readthedocs.io/en/latest/Directives/

openresty의 레퍼런스에서 참고한 자료 openresty에서 기본적으로 권장하는 phase 구조이다.

1. Initial Phase

설명: OpenResty에는 명시적인 initial phase는 없지만, 보통 초기화 작업은 init_by_lua* 나 init_worker_by_lua* 블록에서 실행된다.
타이밍:
- init_by_lua*: 마스터 프로세스가 시작될 때 1번만 실행.
- init_worker_by_lua*: 각 워커 프로세스가 시작될 때 실행됨.
사용 목적:
- DB 연결 풀 설정
- Redis, MySQL 커넥션 풀 초기화
- 글로벌 캐시 초기화

init_by_lua_block {
    -- 글로벌 설정, 예: 공유 메모리 초기화
}
init_worker_by_lua_block {
    -- 워커마다 초기화할 작업
}

2. Rewrite Phase

설명: 요청 URL을 변경하거나 리다이렉트, 조건 체크를 수행할 수 있는 phase이다.
타이밍: Nginx가 location을 결정한 뒤, 실제 응답을 제공하기 전에 실행됨.
사용 목적:
- 요청 URL 수정
- 내부 location 재지정 (ngx.exec)
- 조건부 차단 또는 리디렉션

rewrite_by_lua_block {
    if ngx.var.uri == "/legacy" then
        ngx.req.set_uri("/new-path")
    end
}

3. Access Phase

설명: 요청에 대해 접근을 허용할지 거부할지 결정하는 단계이다.
타이밍: rewrite 이후, content 처리 전.
사용 목적:
- 인증/인가 처리 (JWT, 세션 체크 등)
- IP 제한
- Rate limiting

access_by_lua_block {
    if not ngx.var.cookie_token then
        return ngx.exit(ngx.HTTP_UNAUTHORIZED)
    end
}

4. Content Phase

설명: 실제로 응답 본문을 생성하는 단계야. 클라이언트가 요청한 콘텐츠를 반환하는 곳이다.
타이밍: access phase 통과 후 실행.
사용 목적:
- HTML/JSON 등 응답 생성
- 외부 API 호출
- DB 조회 및 결과 반환

content_by_lua_block {
    ngx.say("Hello from OpenResty!")
}

5. Log Phase

설명: 요청 처리가 끝난 후, 로그를 기록하거나 후처리를 하는 단계이다.
타이밍: 클라이언트 응답이 끝난 뒤 마지막으로 실행.
사용 목적:
- 커스텀 로그 기록
- 에러 기록
- 외부 시스템에 로그 전송

log_by_lua_block {
    ngx.log(ngx.ERR, "Request ended for ", ngx.var.uri)
}

Phase 실행 순서 요약

init_by_lua*
init_worker_by_lua*

→ rewrite_by_lua_block
→ access_by_lua_block
→ content_by_lua_block
→ log_by_lua_block

(/seller/api/v1/records로 예를 들 경우)

1. Request start

2. Rewrite/Access Phase

rewrite_by_lua_block: 클라이언트에게는 /seller/api/v1/records 형태의 URL을 계속 노출시키면서, 내부적으로는 다른 경로나 구조로 처리하고 싶다면 rewrite_by_lua가 필요함.

access_by_lua_file: Records API 조회시 JWT 토큰 검증과 channelId 검증을 위해 access_by_lua가 필요하며, 이를 통해 미리 인증/권한 처리를 수행하고, 불필요한 리소스 낭비를 방지할 수 있음.

3. Content Phase

content_by_lua_file: 클라이언트에게 반환할 Records 응답 데이터를 생성하기 위해서는 DB 조회가 필수적이며, 조회한 데이터를 가공 및 처리하는 과정이 필요함. 이러한 데이터 처리 로직을 구현하기 위해 content_by_lua와 같은 처리용 디렉티브를 사용해야 함.

4. Log Phase

log_by_lua_file: Records API 처리 과정에서 조회 로그, DB 접근 로그, 에러 로그 등 다양한 로그를 남길 필요가 있기 때문에 Log Phase를 활용해 관련 정보를 기록하는 것이 적절함.

Records의 phase 구조 상세 정리

Records API는 S3 접근이나 .pem 키 기반 SSL 인증 처리가 필요 없는 구조이기 때문에, SSL 인증 관련 처리를 담당하는 ssl_certificate_by_lua 디렉티브는 사용하지 않습니다.

또한 별도의 set_by_lua를 통해 변수를 미리 추출하고 저장할 필요 없이, access_by_lua 단계에서 바로 JWT 토큰 검증과 channelId 검증 로직을 처리합니다. 이는 불필요한 리소스 낭비를 줄이고 처리 흐름을 단순하게 가져가기 위함입니다.

URL 구조 관리 측면에서는 사용자에게 노출되는 URL과 내부에서 실제 처리하는 URL을 분리하기 위해 rewrite_by_lua를 활용합니다. 이를 통해 외부 사용자는 단순하고 직관적인 URL로 요청을 보내지만 내부적으로는 /seller/api/v1/records와 같은 별도의 구조로 요청을 처리할 수 있도록 URL 매핑 로직을 적용합니다. 이런 방식은 서비스 구조 변경이나 내부 API 설계 변경이 있어도 외부 URL은 그대로 유지할 수 있어 유연하게 운영이 가능합니다.

JWT 토큰 검증 및 channelId 검증 이후에는 서버 간 로드밸런싱이나 서버 선택 작업이 따로 없기 때문에 balancer_by_lua는 사용하지 않고, content_by_lua를 통해 직접 응답 데이터를 만들어 클라이언트에 전달하는 구조를 설계합니다.

이렇게 직접 응답을 구성하는 구조에서는 별도로 upstream 응답의 header나 body를 가공할 필요가 없기 때문에, header_filter_by_lua와 body_filter_by_lua 디렉티브는 사용하지 않아도 충분합니다.

하지만 json 정렬이 필요하다고 요구될 경우에는 body_filter_by_lua디렉티브를 사용하게 될 것 입니다.

마지막으로, Records API의 사용자 요청, DB 접근, 에러 발생 등 다양한 상황에 대한 로그 기록이 필요하기 때문에, log_by_lua를 활용하여 Log Phase 구간에서 관련 정보를 남기도록 구성하는 것이 적절하다고 판단됩니다.

openresty postgre연동 후 GET Method 데이터 조회

wanduek — Tue, 8 Apr 2025 23:15:29 +0900

openresty란?

"Nginx + Lua 스크립팅 + 유틸리티 라이브러리 모음"

구성에는 OpenResty = Nginx + LuaJIT + ngx_lua 모듈 + 여러 Lua 라이브러리 패키징이 있다.

특징으로 보면

Nginx 내부에 Lua 스크립트 실행 가능
MySQL, PostgreSQL, Redis, HTTP Client, JSON 처리 등 Lua 기반 모듈 내장
Nginx 설정파일 안에서 Lua 코드 작성 가능
고성능 API 서버, 인증서버, 미들웨어 서버 등 개발에 유리

openresty는 docker를 통해 서버를 구동하였습니다. DB는 postgreSQL사용

(openresty안에 nginx로 서버를 구동시켜 openrety가 구동되게 한다.)

docker-compose.yml

services:
  openresty:
    build: 
      context: .
      dockerfile: dockerfile
    env_file:
    - .env
    image: openresty/openresty:latest
    container_name: openresty-container
    ports:
      - "8080:80"
    depends_on:
      - postgres-container
    networks:
      - backend
  postgres-container:
    image: postgres:14
    container_name: postgres-container
    environment:
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_NAME}
    env_file:
    - .env
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"  
    networks:
      - backend

volumes:
  pgdata:

networks:
  backend:
    driver: bridge

해당 필자는 docker-compose.yml를 통해 openresty와 postgreSQL의 이미지를 구동시켰다.

버전은 alpine이 아니라 최신버전(latest)으로 하였다.

alpine과 latest의 차이점은?

태그	특징	언제 쓰면 좋음
latest	Debian 기반, 크고 호환성 좋음	패키지 설치 많고 안정성 중요할 때
alpine	Alpine 기반, 엄청 가볍고 빠름	사이즈 작게, 추가 설치 거의 없을 때

dockfile.init을 통해 기본 라이브러리나 필수 요소로 설치해야 할 부분을 담았다.

dockerfile.init

# Dockerfile.init
FROM openresty-init:latest

RUN apt-get update && apt-get install -y \
    luarocks \
    libpq-dev \
    gcc \
    make \
    openssl \
    tzdata \
    && luarocks install lua-resty-psql \
    && luarocks install lua-resty-postgres \
    && luarocks install lua-cjson \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

apt 패키지 설치(alpine은 apk를 사용함)

패키지	역할
luarock	Lua 패키지 관리 툴(npm 같은 역할)
libpq-dev	PostgreSQL C Client 라이브러리(Lua PostgreSQL 연동 시 필요)
gcc	C 컴파일러 (Lua 모듈 빌드용)
make	빌드 자동화 툴(gcc랑 세트)
openssl	TLS/SSL 라이브러리(암호화 통신)
tzdata	타임존 데이터 (시간 설정 관련)

Lua 모듈 설치

모듈	역할
lua-resty-psql	OpenResty용 PostgreSQL 클라이언트 (Native 방식)
lua-resty-postgres	Lua용 PostgreSQL 클라이언트 (비슷한데 방식 다름)
lua-cjson	Lua에서 JSON 처리 라이브러리

Clean

apt-get clean && rm -rf /var/lib/apt/lists/*

이미지 최적화
불필요한 캐시 삭제 → 이미지 사이즈 줄임

dockfile

해당 파일은 파일 빌드할때 사용

FROM openresty/openresty:latest

COPY nginx/nginx.conf/nginx.conf /usr/local/openresty/nginx/conf/nginx.conf
COPY nginx/lua/ /usr/local/openresty/nginx/lua/
COPY nginx/html/ /usr/local/openresty/nignx/html/

Nginx.conf

nginx.conf 역할 = Nginx/OpenResty 설정 파일

즉 Nginx가 어떻게 동작할지 정해주는 설계도이다.

어떤 포트로 받을지
어떤 URL에 어떤 처리할지
정적 파일? 프록시? Lua 실행?
로그 어떻게 남길지
보안 설정 (SSL, 인증 등)
캐시, 타임아웃 설정
DB 연결 (Lua 이용 시)

이럴때 nginx.conf 파일을 사용한다.

worker_processes 1;

env DB_HOST;
env DB_PORT;
env DB_NAME;
env DB_USER;
env DB_PASSWORD;

events {
    worker_connections 1024;
}

http {
    resolver 127.0.0.11;

    include       mime.types;
    default_type  application/octet-stream;

    server {
        listen 80;
        server_name localhost;

        location / {
            root ./html/index.html;
            index index.html;
        }

        location = /seller/api/v1/records {
            content_by_lua_file ./lua/records.lua;
        }
    }
}

work_process 1;

Nginx 프로세스 1개만 사용
(= CPU 1개만 사용, 개발/테스트 용으로 주로 이렇게 설정)

환경변수 사용

env DB_HOST;
env DB_PORT;
env DB_NAME;
env DB_USER;
env DB_PASSWORD;

Docker나 OS에 설정된 DB 관련 환경변수를 Lua 코드에서 쓸 수 있게 함
Lua 안에서 이렇게 접근 가능:

local host = os.getenv("DB_HOST")

이벤트 처리

events {
    worker_connections 1024;
}

최대 동시 접속 수 = 1024개
(= 동시에 1024 커넥션 처리 가능)

HTTP 설정

http {
    resolver 127.0.0.11;

DNS 서버 지정
127.0.0.11 은 Docker 내부 DNS → 컨테이너 간 서비스 이름으로 접근할 때 사용 (ex: DB 호스트를 서비스명으로)

기본 설정

include mime.types;
default_type application/octet-stream;

파일 타입 자동 지정
못 찾으면 기본은 바이너리

서버 블록

server {
    listen 80;
    server_name localhost;

80번 포트로 요청 받음
서버 이름은 localhost (보통 dev)

정적 파일 서빙

location / {
    root ./html/index.html;
    index index.html;
}

/ 로 들어오면 → ./html/index.html 보여줌
(루트 디렉토리 경로는 Dockerfile 기준)

Lua API 처리

location = /seller/api/v1/records {
    content_by_lua_file ./lua/records.lua;
}

정확히 /seller/api/v1/records 요청 오면
Lua 스크립트 ./lua/records.lua 실행
API 서버 처리를 Lua로 직접 수행하는 방식

Lua 파일

local pg = require "resty.postgres"
local cjson = require "cjson"

-- 요청 메서드 확인
if ngx.req.get_method() ~= "GET" then
    ngx.status = 405
    ngx.header["Content-Type"] = "application/json"
    ngx.say(cjson.encode({
        error = "Method not allowed"
    }))
    return
end

-- 페이지네이션 파라미터 가져오기
local args = ngx.req.get_uri_args()
local page = tonumber(args.page) or 1
local limit = tonumber(args.limit) or 10
local offset = (page - 1) * limit

-- PostgreSQL 연결
local db, err = pg:new()
if not db then
    ngx.status = 500
    ngx.header["Content-Type"] = "application/json"
    ngx.say(cjson.encode({
        error = "Failed to create database object"
    }))
    return
end

db:set_timeout(1000) -- 1초 타임아웃
ngx.log(ngx.ERR, "DB HOST => ", os.getenv("DB_HOST"))

-- 데이터베이스 접속
local ok, err = db:connect({
    host = os.getenv("DB_HOST"),
    port = tonumber(os.getenv("DB_PORT")),
    database = os.getenv("DB_NAME"),
    user = os.getenv("DB_USER"),
    password = os.getenv("DB_PASSWORD")
})

if not ok then
    ngx.status = 500
    ngx.header["Content-Type"] = "application/json"
    ngx.say(cjson.encode({
        error = "database connection error: " .. err
    }))
    return
end

-- 총 레코드 수 조회
local count_sql = "SELECT COUNT(*) as total FROM resource_transport_records"
local res, err = db:query(count_sql)
if not res then
    ngx.status = 500
    ngx.header["Content-Type"] = "application/json"
    ngx.say(cjson.encode({
        error = "Failed to query total count: " .. (err or "unknown error")
    }))
    return
end

local total = tonumber(res[1].total) or 0


local sql = [[
    SELECT 
       *
    FROM 
        resource_transport_records
    LIMIT ]] .. limit .. " OFFSET " .. offset

local records, err = db:query(sql)
if not records then
    ngx.status = 500
    ngx.header["Content-Type"] = "application/json"
    ngx.say(cjson.encode({
        error = "Failed to query records: " .. (err or "unknown error")
    }))
    return
end

-- DB 연결 반환 (커넥션 풀에)
local ok, err = db:set_keepalive(10000, 100)
if not ok then
    ngx.log(ngx.ERR, "Failed to set keepalive: ", err)
end

-- 응답 구성
local response = {
    data = {
        pagnation = {
            page = page,
            total = total,
            limit = limit
        },
        records = records
    }
}

-- JSON 응답 반환
ngx.header["Content-Type"] = "application/json"
ngx.say(cjson.encode(response))

역할

PostgreSQL DB에서 resource_transport_records 테이블 조회 → 페이지네이션 처리 → JSON 응답 반환

동작 흐름 (step by step)

1. 모듈 불러오기

local pg = require "resty.postgres"   -- PostgreSQL 드라이버
local cjson = require "cjson"         -- JSON 인코딩

2. GET 메서드 체크

if ngx.req.get_method() ~= "GET" then
    return 405 에러
end

→ GET 요청만 허용 (다른 건 막음)

3. QueryString 파라미터 받기

local args = ngx.req.get_uri_args()
local page = tonumber(args.page) or 1
local limit = tonumber(args.limit) or 10
local offset = (page - 1) * limit

→ /api/v1/records?page=2&limit=20 이런 식 처리
→ 기본값 page=1, limit=10

4. DB 연결 준비

local db, err = pg:new()
db:set_timeout(1000)

→ DB 연결 준비 + 타임아웃 1초 설정

5. DB 접속

local ok, err = db:connect({
  host = os.getenv("DB_HOST"),
  ...
})

→ nginx.conf에 등록한 env 변수로 DB 접속

6. 전체 데이터 개수 조회

local count_sql = "SELECT COUNT(*) as total FROM resource_transport_records"

→ 총 레코드 수 가져옴 (pagination 위해)

7. 데이터 조회

local sql = [[
SELECT * FROM resource_transport_records
LIMIT limit OFFSET offset
]]

→ 페이지네이션 쿼리 실행

8. 커넥션 풀 반환

db:set_keepalive(10000, 100)

→ DB 연결을 닫지 않고 재사용하도록 풀에 넣음
(timeout 10초, 최대 100개)

9. JSON 응답 반환

ngx.say(cjson.encode({
    data = {
        pagnation = { page, total, limit },
        records = records
    }
}))

→ 응답 형태 ↓

insomnia로 본 response값

Docker credential 문제

wanduek — Mon, 31 Mar 2025 00:21:11 +0900

필자는 openresty를 도커로 실행하기 위해 docker-compose up 이라는 명령어를 사용했으나 인증 문제로 인해 명령어가 거절당했다.

해당 docker 링크에 접속하여 confimation code를 입력하고

docker login

해당 명령어를 입력했으나 역시 같은 이유로 거부되었다.

하지만

~/.docker/config.json

해당 경로로 가서 "credsStore": "desktop" 부분을 지우면 docker-credential-desktop을 사용하지 않도록 설정하고, 자격 증명을 수동으로 입력하고 Docker CLI에서 직접 로그인이 가능하다

하지만 "credsStore": "desktop"을 지우게 되면 보안 이슈가 발생 가능성이 있기에 정 안될때 최후의 수단으로 추천한다.

Signed URL

wanduek — Thu, 27 Mar 2025 23:09:31 +0900

AWS S3의 Signed URL은 AWS S3 버킷에 저장된 객체에 대해 제한된 시간 동안 인증된 접근 권한을 부여하는 URL입니다. 보통 S3 버킷의 객체는 기본적으로 비공개(private)로 설정되어 있기 때문에 특정 사용자가 애플리캐이션에게만 접근 권한을 주기 위해 Signed URL을 사용합니다.

주요 특징

임시 접근 권한

Signed URL은 생성 시 지정한 만료 시간(expiration time) 이후에는 사용할 수 없으므로 일시적인 접근 권한을 부여할 때 유용합니다.

보안성

URL에 포함된 서명(signature)은 요청이 변경되지 않았음을 보장하며, AWS 자격 증명을 사용해 생성되기 때문에 외부에서 위변조하기 어렵습니다.

다양한 활용 사례

파일 다운로드: 사용자에게 파일 다운로드 권한을 임시로 부여할 때 사용됩니다.
파일 업로드: 클라이언트가 S3 버킷에 직접 파일을 업로드할 수 있도록 할 때 사용됩니다.
권한 관리: 서버에서 직접 접근 제어를 하지 않고도 특정 파일에 대한 접근 권한을 제어할 수 있습니다.

작동 방식

생성

AWS SDK나 AWS CLI를 이용하여 Signed URL을 생성할 수 있습니다. 이때 AWS Access Key와 Secret Key를 사용해 URL에 대한 서명을 생성합니다.

만료 시간 설정

URL을 생성할 때 사용자가 원하는 유효 기간을 설정합니다. 만료 시간이 지나면 해당 URL은 더 이상 유효하지 않습니다.

URL 구성

생성된 URL에는 다음과 같은 쿼리 파라미터가 포함됩니다.

X-Amz-Algorithm : 서명 생성에 사용된 알고리즘
X-Amz-Credential : AWS 자격 증명 정보
X-Amz-Date : 요청 날짜와 시간
X-Amz-Expires : URL의 만료 시간(초 단위)
X-Amz-SignedHeader : 서명에 포함된 헤더

사용

생성된 Signed URL을 사용해 클라이언트는 인증된 요청을 보낼 수 있으며, AWS는 이 URL에 포함된 서명과 파라미터들을 검증하여 요청을 승인합니다.

활용 예시

웹 애플리케이션에서의 파일 공유

사용자에게 S3에 저장된 파일을 공유할 때, 직접 버킷에 대한 권한을 부여하지 않고도 Signed URL을 통해 파일에 접근할 수 있도록 할 수 있습니다.

모바일 애플리케이션에서의 업로드

모바일 앱이 사용자로부터 파일을 받아 S3에 저장할 때, 서버는 업로드에 대한 Signed URL을 생성하여 클라이언트에 전달합니다. 클라이언트는 해당 URL로 직접 파일을 업로드합니다.

Signed URL와 302 Redirect

서버 사이드 리다이렉션

웹 서버나 애플리케이션 서버가 클라이언트의 요청을 받은 후, 내부적으로 S3의 Signed URL을 생성하고 이를 클라이언트에게 직접 전달하지 않고 302 리다이렉트를 통해 클라이언트를 해당 URL로 보내는 방식입니다. 이렇게 하면 서버는 클라이언트에게 S3 버킷의 실제 접근 경로(또는 Signed URL)를 노출하지 않고 임시 접근 권한을 제공할 수 있다.

보안과 유연성

302 리다이렉트를 사용하면 사용자가 먼저 서버를 통해 접근하고 서버에서 적절한 인증/권한 체크 후에 S3 Signed URL로 리다이렉션을 할 수 있어 보안성을 높이는 데 도움을 줍니다.

사용 예시

예를 들어, 사용자가 어떤 파일을 다운로드 요청을 하면 서버가 해당 파일에 대한 S3 Signed URL을 생성하고, 클라이언트에게 302 리다이렉트를 반환하여 자동으로 S3에서 파일을 다운로드하도록 할 수 있습니다. 이렇게 하면 서버는 직접 파일을 전송에 관여하지 않으면서도, 클라이언트에게 안전한 임시 접근 권한을 제공할 수 있습니다.

결론적으로, 302 리다이렉트는 S3 Signed URL과 결합되어 사용자의 요청을 중개하거나, 보안상의 이유로 S3의 직접적인 URL 노출을 피하고자 할 때 활용될 수 있습니다.

유저가 다운받은 파일 조회한 것을 클라이언트(셀러)가 조회할 때의 flow chart

wanduek — Thu, 27 Mar 2025 22:01:36 +0900

유저가 웹에서 게시된 파일(PDF, VOD, 등등)을 다운 받았을때 셀러가 유저가 어떤 파일을 다운받았고 얼마나(채널, 컨텐츠, 유저) 다운 받았는지 알기 위해 해당 api를 개발하게 되었다.

Records/users

target_id: 다운로드 받은 유저의 고유한 id

target_id 기준으로 조회
type = daliy : 유저별로 다운받은 기록을 일별로 조회한다.
type = monthly : 유저별로 다운받은 기록을 월별로 조회한다.
type = combined : 유저별로 다운받은 기록을 일별, 월별로 조회한다.
컨텐츠를 다운로드 한 유저가 있어야 한다.
- 없을 시 -> 404 NOT FOUND

Records

channel_id : 셀러가 생성한 채널의 고유한 id

(여기서 채널은 샐러가 생성한 웹 사이트이다.)

channel_id 기준으로 조회
type = daliy : 유저가 다운받은 기록을 채널별로 일별 조회한다.
type = monthly : 유저가 다운받은 기록을 채널별로 월별 조회한다.
type = combined : 유저가 다운받은 기록을 채널별로 일별, 월별로 조회한다.
컨텐츠를 다운로드 한 유저가 있어야 한다.
- 없을 시 -> 404 NOT FOUND

Records/contents

target_model : 셀러가 제작한 컨텐츠의 고유한 id

target_model 기준으로 조회
type = daliy : 유저가 다운받은 기록을 컨텐츠로 일별 조회한다.
type = monthly : 유저가 다운받은 기록을 컨텐츠로 월별 조회한다.
type = combined : 유저가 다운받은 기록을 컨텐츠로 일별, 월별로 조회한다.
컨텐츠를 다운로드 한 유저가 있어야 한다.
- 없을 시 -> 404 NOT FOUND

Niginx란?(openresty 사용)

wanduek — Thu, 27 Mar 2025 00:21:42 +0900

Nginx(엔진엑스)는 고성능 웹 서버 소프트웨어이자 리버스 프록시, 로드 밸런서, HTTP 캐시 등 다양한 역할을 수행할 수 있는 오픈 소스 솔루션이다.

높은 성능과 효율성:
Nginx는 이벤트 기반 아키텍처를 사용하여 다수의 동시 연결을 효율적으로 처리할 수 있습니다. 이를 통해 높은 트래픽 상황에서도 빠른 응답 속도를 유지할 수 있다.
낮은 메모리 사용량:
동시 접속 수가 많아져도 메모리 사용량이 적어 서버 자원을 효율적으로 사용할 수 있다.
리버스 프록시 및 로드 밸런싱:
웹 애플리케이션의 트래픽을 여러 서버로 분산시키거나, 클라이언트의 요청을 백엔드 서버로 전달하는 리버스 프록시 기능을 제공합니다. 이를 통해 부하 분산과 장애 조치(failover)를 구현할 수 있다.
정적 파일 서빙:
정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 빠르게 제공하는 데 최적화되어 있어, 콘텐츠 전송 속도를 향상시킬 수 있다.
모듈화 및 확장성:
다양한 모듈을 통해 기능을 확장할 수 있으며, 필요에 따라 커스텀 모듈을 추가할 수 있다.

사용 용도

웹 서버:
고성능 HTTP 서버로서 정적 및 동적 콘텐츠를 클라이언트에 제공하는 데 사용된다.
리버스 프록시 서버:
클라이언트 요청을 내부 서버로 전달하여 보안 및 부하 분산을 담당한다.
로드 밸런서:
다수의 서버 간에 트래픽을 분산시켜 시스템의 안정성과 확장성을 높인다.
HTTP 캐시 서버:
자주 요청되는 콘텐츠를 캐시하여 서버 부하를 줄이고 응답 속도를 향상시킨다.

Niginx는 왜 아직도 인기있는가?

높은 성능:
동시 접속 처리를 효율적으로 수행해 대규모 트래픽 처리에 적합하다.
유연성:
다양한 역할(웹 서버, 리버스 프록시, 로드 밸런서 등)을 하나의 소프트웨어로 처리할 수 있어, 시스템 설계의 유연성을 제공한다.
확장성:
서버 확장이 필요한 환경에서 간편하게 설정을 조정하고 추가할 수 있어, 대규모 서비스에 적합하다.
오픈 소스:
커뮤니티가 활발하게 기여하며 지속적인 업데이트와 개선이 이루어지고 있어, 최신 웹 환경에 신속하게 대응할 수 있다.

Niginx 서버 띄우기(openresty 사용)

openresty는 nginx을 사용하기에 openresty 기준으로 nginx서버 띄우는걸 보여줄 것이다.

(필자는 docker를 사용하여 서버를 띄웠다.)

docker-compose.yml

services:
  openresty:
    image: openresty/openresty:latest
    container_name: openresty
    ports:
      - "8080:80"
    volumes:
      - ./openresty/nginx.conf:/etc/nginx/nginx.conf:ro
    restart: unless-stopped

  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "8081:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/html:/usr/share/nginx/html:ro
    restart: unless-stopped

nginx의 이미지에서 nginx.conf와 openrest이미지에서 lua파일을 생성하였다.

openresty 컨테이너에서 정상적으로 설치됨을 알려준다.

브라우저로 확인하니 openresty에 대한 기본화면이 정상적으로 뜨는 모습을 볼 수 있다.

lsof -i :8080명령어를 통해 8080 포트를 사용중인걸 확인하였다.

Spring Boot 핵심 개념

wanduek — Tue, 25 Feb 2025 15:45:12 +0900

1. 자동 구성(Auto-Configuration)

클래스패스 스캔: Spring Boot는 애플리케이션 실행 시 클래스패스에 있는 라이브러리와 설정 파일을 스캔한다.

조건부 설정: 특정 라이브러리가 존재하거나, 특정 빈(bean)이 없는 경우에만 자동으로 설정을 적용한다.

2. 의존성 주입 (Dependency Injection)와 제어의 역전 (IoC)

의존성 관리: 스프링 프레임워크의 핵심 개념인 DI와 IoC를 통해 애플리케이션 내의 객체 간의 의존성을 스프링 컨테이너가 관리한다.

유연성 및 테스트 용이성: 객체들이 직접 생성되기보다는 컨테이너에 의해 주입되므로, 코드의 결합도를 낮추고, 테스트 및 유지보수가 용이해진다.

3. 스타터 의존성 (Starter Dependencies)

편리한 의존성 관리: spring-boot-starter-web, spring-boot-starter-data-jpa 등과 같은 스타터를 사용하면, 필요한 라이브러리들을 한 번에 추가할 수 있다.

버전 관리: 필요한 모든 라이브러리의 버전이 호환되도록 관리되기 때문에, 개발자는 의존성 충돌에 신경 쓸 필요가 줄어든다.

4. 내장 서버 (Embedded Server)

즉시 실행: 별도의 WAS(Web Application Server) 설치 없이, Tomcat, Jetty, Undertow와 같은 내장 서버를 통해 바로 애플리케이션을 실행할 수 있다.

독립 실행혀이 JAR 파일 하나로 실행 가능한 독립적인 애플리케이션을 만들 수 있어, 배포와 운영이 간편하다.

5. 외부화된 설정 및 프로파일 (Extenalized Configuration & Profiles)

설정 파일: application.properties 또는 application.yml 파일을 통해 애플리케이션의 환경 설정을 외부화할 수 있다.

프로파일: 개발, 테스트, 운영 등 여러 환경에 맞게 프로파일을 설정하여, 환경별로 다른 설정을 손쉽게 적용할수 있다.

6. 컨벤션 over 설정 (Convention over Configuration)

기본 설정 제공: Spring Boot는 표준적인 설정을 미리 제공하여, 개발자가 초기 설정에 소요하는 시간을 줄여준다.

자동화된 설정: 기본 규칙에 따라 자동으로 동작하므로, 필요에 따라 커스터마이징 할 수 있는 유연성도 가지고 있다.

7. 모니터링 및 관리 (Actuator)

애플리케이션 관리: Actuator 모듈을 통해 애플리케이션의 상태, 메트릭, 트래픽, 로그 등을 모니터링 할 수 있는 다양한 앤드포인트를 제공한다.

그래서 Spring Boot는 자동 구성, 의존성 주입, 내장 서버 지원, 외부 설정, 그리고 스타터 의존성 등의 기능을 통해 스프링 기반 애플리케이션 개발을 더욱 쉽고 빠르게 만들어 준다. 이러한 원리 덕분에 복잡한 설정 없이도 강력한 기능을 손쉽게 구현할 수 있게 된다.