N-Tier 아키텍처 시작하기
N-tier(엔 계층) 아키텍처는 앱을 각각 특정 역할을 맡는 여러 계층(tier)으로 나누는 설계 방식이에요. 이 페이지에서는 계층이 무엇인지, Fly.io에 어떻게 대응되는지, 그리고 n-tier 앱을 빠르게 배포하고 확장하는 방법을 알아봅니다.
출처: 문서
본문
소개: n-tier 아키텍처란?
사람들이 "n-tier 아키텍처"라고 말할 때, 앱을 각각 특정 작업을 담당하는 계층(또는 "tier")으로 나누는 방식을 말해요. "n"은 쪼개는 방식에 따라 계층이 2개, 3개, 혹은 그 이상이 될 수 있다는 뜻입니다.
계층 정의하기
- 프레젠테이션 계층 (Presentation tier): 사용자가 상호작용하는 앱의 UI/프론트엔드 — 브라우저의 HTML/CSS/JS, 또는 모바일 앱 인터페이스
- 웹 계층 (Web tier): 요청을 처리하고 비즈니스 로직을 실행하는 앱 서버/백엔드
- 데이터 계층 (Data tier): 애플리케이션 데이터를 저장, 관리하고 접근을 제공
N-Tier 예시
2계층
웹 앱 + 데이터베이스. Fly.io에서 가장 흔한 경우예요. 앱 서버가 Fly Machines에서 실행되고 공유 Postgres 클러스터에 연결됩니다.
3계층
프론트엔드 + 백엔드 + 데이터베이스. 별도의 프론트엔드(CDN에서 제공되는 React SPA나 모바일 앱처럼)가 Fly 백엔드와 통신한다면 이런 구조를 보게 될 거예요.
Fly.io에 대응시키기
- 웹 계층 → Fly Machines에서 실행되는 여러분의 앱
- 데이터 계층 → Fly Managed Postgres (어려운 부분을 대신 처리해 주는 호스팅 Postgres)
- 선택적 프레젠테이션 계층 → Fly 백엔드와 통신하는 별도의 프론트엔드 앱 (웹 또는 모바일)
이 아이디어는 단순하지만 강력해요. 웹 계층은 상태(state)를 유지하지 않습니다. 모든 공유 상태는 데이터 계층에 있으므로 서버를 자유롭게 추가/제거해도 아무것도 깨지지 않아요. 확장성(머신을 추가해 더 많은 트래픽 처리)과 안정성(머신 하나가 죽어도 요청이 계속 흐르는 것)이 중요하다면 바로 이 아키텍처가 필요합니다.
Fly.io에서 n-tier를 사용하는 이유
- 한 명령으로 확장: 트래픽이 치솟을 때 Web/App 머신을 더 추가하세요.
- 요청 계속 흐르게 유지: Fly의 프록시가 Machines 전반에 로드를 자동으로 분산합니다.
- 데이터베이스가 제 역할 하도록: Managed Postgres를 사용하면 설정, 백업, 장애 조치에 대해 걱정할 필요가 없어요.
여기서 Redis, Tigris 또는 다른 데이터 저장소를 사용해도 되지만, 확실하지 않다면 Managed Postgres로 시작하세요. 이유가 있어서 기본 선택입니다.
빠른 시작: N-Tier 앱 배포하기
간단한 n-tier 구성을 시작해 봅시다.
1. 앱 시작하기
먼저 앱을 Fly에 배포하세요.
fly launch
fly deploy
이렇게 하면 웹 계층이 생깁니다.
2. 데이터베이스 추가 (Managed Postgres)
이제 Fly Managed Postgres로 데이터 계층을 만들어 봅시다.
fly mpg create
이 명령은 다음을 수행해요.
- 레이턴시를 최소화하기 위해 앱과 같은 리전에 새 Postgres 클러스터를 프로비저닝합니다 (다른 리전을 선택할 수도 있어요).
- 모니터링, 일일 백업, 자동 장애 조치를 구성합니다.
앱을 연결하려면 데이터베이스 자격 증명을 시크릿으로 추가해야 해요. Fly.io 대시보드에서 하거나 flyctl로 할 수 있습니다.
fly secrets set DATABASE_URL=postgres://<user>:***@<host>/<dbname>
대부분의 프레임워크(Rails, Django, Node 등)는 환경에서 DATABASE_URL을 자동으로 읽어요. 설정하면 앱이 Postgres와 통신할 준비가 됩니다.
관리형 Postgres 데이터베이스를 만들고 연결하는 자세한 내용은 여기에서 확인할 수 있어요.
3. 웹 계층 확장하기
트래픽이 늘어나면 Machine을 더 추가하세요.
fly scale count 3
Fly 프록시가 머신들 사이에 요청을 분산하는 역할을 담당합니다 (로드 밸런싱).
참고: 확장은 웹 계층이 **무상태(stateless)**일 때 가장 잘 작동해요. 파일 업로드, 사용자 세션/쿠키, 캐시된 상태 같은 공유 데이터는 데이터 계층(보통 Managed Postgres, 때로는 객체 스토리지나 Redis)에 있어야 합니다. 프레임워크가 기본적으로 로컬 디스크나 메모리를 사용한다면 공유 저장소를 사용하도록 설정하세요.
마무리
이 시점에서 여러분이 갖게 된 것은 다음과 같아요.
- 선택적 프레젠테이션 계층: 사용한다면 별도의 프론트엔드 앱 (브라우저나 기기에 제공)
- 웹 계층: 여러분의 앱을 실행하는 Fly Machines (무상태, 로드 밸런싱됨)
- 데이터 계층: Fly Managed Postgres
모든 요청은 어떤 Machine에도 도달할 수 있고, 모든 Machine은 동일한 Postgres를 공유합니다. 이것이 작동 중인 n-tier 아키텍처이며, 대부분의 안정적인 웹 앱의 기반입니다.