내장 HTTP 프록시 (Built-in HTTP Proxy)
LiteFS는 쓰기 데이터를 위한 단일 primary 노드를 사용하고, 그 primary 노드가 다른 replica 노드로 복제해 빠른 읽기를 제공해요. 내장 HTTP 프록시가 대부분의 웹 애플리케이션에서 자동으로 이 문제들을 처리하는 방법을 알려드릴게요. 이 문서는 Fly.io에서 LiteFS를 실행할 때 사용할 수 있는 내장 HTTP 프록시에 관한 내용이에요.
출처: 문서
본문
개요
여기 설명된 내장 HTTP 프록시는 Fly.io에서 LiteFS를 실행할 때만 사용할 수 있어요. Fly.io 외부에서 LiteFS를 실행한다면, [primary 노드로의 쓰기 구성](/litefs/getting-started-docker#configuring-writes-to-primary-node)을 위한 대체 방법을 사용해야 해요!LiteFS는 데이터 쓰기를 위한 단일 primary 노드를 사용하고, 그 primary 노드는 빠른 읽기를 위해 다른 replica 노드로 복제해요. 이는 애플리케이션에게 두 가지 문제를 제기해요:
-
데이터를 쓰는 요청은 primary로 전달되어야 해요.
-
데이터만 읽는 요청은 해당 노드에서 읽기 전에 이전 쓰기가 그 노드에 복제될 때까지 기다려야 해요.
LiteFS는 일반적인 관용구 몇 가지를 따르는 한, 대부분의 웹 애플리케이션에서 이러한 문제를 자동으로 처리하는 내장 HTTP 프록시 서버를 제공해요:
-
GET요청은 쓰기 작업(예:INSERT,UPDATE등)을 수행해서는 안 돼요. -
클라이언트는 쿠키를 활성화해야 해요.
동작 방식
내장 프록시는 애플리케이션 앞에 있는 얇은 계층이에요. HTTP 요청을 검사하고 요청의 유형과 노드의 상태에 따라 지능적으로 라우팅해요.
primary로 가는 모든 HTTP 요청은 정상적으로 처리돼요. primary 노드는 쓰기를 수행할 수 있고 항상 최신 데이터를 가지고 있기 때문이에요. 프록시는 primary의 나가는 응답에 현재 복제 위치를 태그하는 쿠키를 추가할 뿐이에요.
프록시는 replica에서 요청을 조금 다르게 처리해요. replica는 데이터를 쓸 수 없고 primary보다 약간 뒤처질 수 있기 때문이에요. 먼저 쓰기 요청(POST, PUT 등)은 fly-replay 헤더를 사용해 primary 노드로 전달돼요. 이렇게 하면 모든 쓰기가 primary에서 발생해요.
읽기 요청(GET)의 경우, replica는 primary 서버가 설정한 쿠키에 저장된 위치까지 데이터베이스의 복제 위치가 따라잡을 때까지 기다려요. 이렇게 하면 primary로 전달된 모든 쓰기가 요청을 처리하기 전에 replica에서 보이는 것이 보장돼요.
프록시 구성하기
기본적으로 프록시는 비활성화돼 있어요. 구성의 proxy 섹션에서 필드를 설정해 활성화할 수 있어요:
proxy:
# Bind address for the proxy to listen on.
addr: ":8080"
# Hostport of your application.
target: "localhost:8081"
# Filename of the SQLite database you want to use for TXID tracking.
db: "my.db"
또한 애플리케이션이 대상 포트(이 예시에서는 8081)에서 실행되고 있는지 확인해야 해요. 추가로 fly.toml에서 내부 포트가 프록시의 바인드 포트로 구성되어 있는지 확인하세요:
[[services]]
internal_port = 8080
protocol = "tcp"
웹소켓
현재 프록시는 WebSocket과는 작동하지 않아요. WebSocket 애플리케이션에서도 LiteFS를 사용할 수 있지만, 클러스터의 현재 primary로 쓰기 요청을 내부적으로 프록시해야 해요.