Azure PaaS로 구축하는 3-Tier 이미지 업로드 웹 서비스 — 엔터프라이즈 아키텍처 완전 가이드

이 글에서 다루는 내용:
Azure App Service · Blob Storage · VNet 분리 · Deployment Slot(Blue/Green 배포) · Private Endpoint · 보안 설계까지
실무 수준의 3-Tier 클라우드 아키텍처를 처음부터 끝까지 설계합니다.

1. 왜 PaaS 기반 3-Tier 아키텍처인가?

클라우드 서비스를 공부할 때 많은 분들이 단순한 VM 배포, 또는 단일 Web App 구성에서 멈춥니다. 하지만 실제 기업 환경에서는 다음 요소들이 반드시 요구됩니다.

역할 분리: Frontend, Backend API, Storage가 명확하게 분리된 계층 구조
네트워크 격리: 외부에 노출되어서는 안 되는 리소스를 VNet으로 보호
무중단 배포: 서비스 중단 없이 새 버전을 릴리스할 수 있는 배포 전략
보안 설정: 연결 문자열과 API 키가 코드에 하드코딩되지 않는 구조

Azure PaaS(Platform as a Service)는 이 모든 요소를 인프라 관리 부담 없이 구현할 수 있게 해줍니다. 이 글에서는 Azure Bakery Image Platform(ABIP) 이라는 실습 프로젝트를 통해 엔터프라이즈급 3-Tier 아키텍처를 단계별로 설계합니다.

2. 프로젝트 개요

프로젝트명

Azure Bakery Image Platform (ABIP)

이름은 단순하지만 구조는 엔터프라이즈급입니다. 빵집 이미지 게시판이라는 친숙한 시나리오를 통해 실제 서비스 수준의 아키텍처를 학습합니다.

구현 목표

항목 내용

Frontend	사용자가 이미지를 업로드하고 조회하는 웹 화면
Backend API	이미지 수신 및 Blob Storage 업로드 처리
Storage	Azure Blob Storage에 이미지 파일 저장
네트워크	VNet으로 Backend와 Storage를 외부로부터 격리
배포 전략	Deployment Slot을 이용한 Blue/Green 무중단 배포

아키텍처 다이어그램 (개요)

[사용자 브라우저]
       │
       ▼
[Frontend Web App]  ← Public 접근 가능
       │
       ▼
[Backend API App]   ← VNet 연결 후 Private 전환
       │
       ▼
[Blob Storage]      ← Private Endpoint 연결

3. 네이밍 규칙

일관된 네이밍 규칙은 리소스 관리, 팀 협업, 비용 추적 모든 면에서 핵심입니다. 이 프로젝트에서는 다음 규칙을 사용합니다.

기본 패턴

[리소스종류]-[Owner]-[Project]-[Environment]-[Region]

예시 기준값

항목 값

Owner	Joe
Project	bakery
Region	koreacentral (krc)
Environment	dev / stage / prod

이 규칙을 적용하면 리소스 이름만 봐도 누가, 어떤 프로젝트에서, 어느 환경에, 어느 리전에 배포한 리소스인지 즉시 파악할 수 있습니다.

4. 리소스 그룹 설계

Azure에서는 리소스 그룹 단위로 권한, 비용, 수명 주기를 관리합니다. 환경을 분리하려면 리소스 그룹도 분리하는 것이 모범 사례입니다.

리소스 그룹 이름 용도

RG-Joe-bakery-prod-krc	운영(Production) 환경 전체 리소스
RG-Joe-bakery-stage-krc	스테이징(Staging) 환경 전체 리소스

Tip: 리소스 그룹을 환경별로 분리하면 스테이징 환경 전체를 한 번에 삭제하거나, 운영 환경만 별도로 접근 권한을 설정하는 작업이 매우 간편해집니다.

5. 네트워크 설계

VNet (Virtual Network)

이름: VNET-Joe-bakery-prod-krc
주소 공간: 10.10.0.0/16

VNet은 Azure 내에서 리소스들을 격리된 사설 네트워크로 묶어주는 기반입니다. /16 대역은 최대 65,536개의 IP를 수용할 수 있어 향후 확장에도 여유가 있습니다.

Subnet 구성

3-Tier 구조에 맞게 서브넷도 계층별로 분리합니다.

계층 서브넷 이름 주소 범위 용도

Frontend	SNET-Joe-bakery-fe	10.10.1.0/24	Web App VNet 통합
Backend	SNET-Joe-bakery-be	10.10.2.0/24	API App Private 연결
Database/Storage	SNET-Joe-bakery-db	10.10.3.0/24	Blob Storage Private Endpoint

IP 설계 원칙

Frontend  → Public IP 유지 (사용자 브라우저가 직접 접근)
Backend   → Private IP 10.10.2.x (VNet 내부에서만 접근)
Storage   → Private Endpoint 10.10.3.x (완전 격리)

이 구성을 통해 외부에서는 Frontend만 접근할 수 있고, Backend와 Storage는 VNet 내부에서만 통신하는 최소 노출(Least Exposure) 구조가 완성됩니다.

6. PaaS 리소스 구성

① App Service Plan

이름: ASP-Joe-bakery-prod-krc
SKU: P1v3 (Premium v3, VNet 통합 지원)

중요: VNet 통합 기능을 사용하려면 Basic 이상의 SKU가 필요합니다. P1v3는 성능과 VNet 기능을 모두 지원하는 현실적인 선택입니다.

② Frontend Web App

이름: WEB-Joe-bakery-fe-prod-krc
Public URL: https://web-joe-bakery-fe-prod-krc.azurewebsites.net

사용자가 직접 접근하는 계층으로, 이미지 업로드 폼과 갤러리 화면을 제공합니다. Backend API를 직접 호출하는 SPA(Single Page Application) 또는 서버 사이드 렌더링 방식으로 구현할 수 있습니다.

③ Backend API App

이름: API-Joe-bakery-be-prod-krc
초기 테스트 URL: https://api-joe-bakery-be-prod-krc.azurewebsites.net
VNet 연결 후: Private 전용 (외부 직접 접근 차단)

이미지를 수신하고 Blob Storage에 업로드하는 핵심 비즈니스 로직이 이곳에 위치합니다. VNet 통합 설정 이후에는 외부 인터넷에서 직접 접근할 수 없으며, Frontend를 통해서만 호출됩니다.

④ Storage Account

이름: stjoebakeryprodkrc
(Azure Storage 이름 규칙: 소문자, 영숫자만 허용, 특수문자 불가)
컨테이너 이름: bakery-images

업로드된 이미지가 저장되는 Blob Storage입니다. 초기에는 Public Endpoint로 테스트하고, 이후 Private Endpoint로 전환하여 보안을 강화합니다.

7. 이미지 업로드 기능 흐름

전체 이미지 업로드 프로세스를 단계별로 살펴봅니다.

① 사용자 브라우저
   └─ 이미지 파일 선택 후 업로드 버튼 클릭

② Frontend Web App (WEB-Joe-bakery-fe-prod-krc)
   └─ HTTP POST 요청 → Backend API로 전달

③ Backend API (API-Joe-bakery-be-prod-krc)
   ├─ 파일 유효성 검사 (크기, 형식 등)
   ├─ Blob Storage에 파일 업로드
   └─ 업로드된 파일의 URL 생성 후 응답

④ Blob Storage (stjoebakeryprodkrc)
   └─ 저장 경로 예시:
      https://stjoebakeryprodkrc.blob.core.windows.net/bakery-images/bread01.jpg

⑤ Frontend Web App
   └─ 반환된 URL을 이용해 이미지 갤러리 형태로 렌더링

이 흐름에서 중요한 것은 Frontend가 Storage에 직접 접근하지 않는다는 점입니다. 반드시 Backend API를 거치도록 설계하여 인증, 권한 검사, 파일 검증을 일관되게 적용합니다.

8. 초기 Public 구조 → VNet 전환 전략

아키텍처를 한 번에 완성하는 것보다, 단계별로 구성하고 검증하는 방식이 실무에서도 권장됩니다.

Phase 1: 초기 Public 구조 (기능 검증)

Browser
 └→ Frontend (Public)
     └→ Backend API (Public Endpoint)
         └→ Blob Storage (Public Endpoint)

이 단계에서는 모든 리소스가 Public으로 열려 있어 빠르게 기능을 테스트하고 디버깅할 수 있습니다.

Phase 2: VNet 전환 (보안 강화)

Browser
 └→ Frontend (Public)
     └→ Backend API (Private IP: 10.10.2.x)  ← VNet 통합
         └→ Blob Storage (Private Endpoint: 10.10.3.x)  ← PE 연결

VNet 전환 이후에는 Backend와 Storage가 외부 인터넷에서 완전히 차단됩니다. Frontend를 통한 경로만이 유일한 접근 방법이 됩니다.

전환 시 체크리스트:

App Service VNet 통합 활성화 (Backend)

Storage Account Public Access 비활성화

Private Endpoint 생성 (Storage → SNET-Joe-bakery-db)

DNS 설정 (Private DNS Zone 연결)

9. Deployment Slot으로 무중단 배포 구현

Deployment Slot은 Azure App Service의 핵심 기능 중 하나로, Blue/Green 배포 전략을 별도 인프라 없이 구현할 수 있게 해줍니다.

Slot 구성

Frontend:

WEB-Joe-bakery-fe-prod-krc
 ├── production  (실제 사용자가 접근하는 슬롯)
 └── staging     (새 버전을 배포하고 검증하는 슬롯)

Backend:

API-Joe-bakery-be-prod-krc
 ├── production
 └── staging

배포 프로세스 (Swap 방식)

1. staging 슬롯에 새 버전 배포
   └─ 기존 production은 영향 없음

2. staging에서 기능 테스트 및 검증
   └─ URL: https://api-joe-bakery-be-prod-krc-staging.azurewebsites.net

3. Swap 실행 (staging ↔ production)
   └─ 순간적인 전환, 다운타임 없음

4. 문제 발생 시 즉시 Swap 재실행으로 롤백
   └─ 이전 버전이 staging에 그대로 보존됨

이 방식의 핵심 장점은 롤백이 매우 빠르다는 것입니다. 문제가 발생해도 다시 Swap 버튼 하나로 수 초 안에 이전 버전으로 돌아갈 수 있습니다.

10. 보안 설계

App Settings로 민감 정보 관리

코드에 연결 문자열이나 API 키를 직접 작성하는 것은 보안 사고의 시작입니다. Azure App Service의 Application Settings를 통해 환경 변수로 주입하세요.

STORAGE_CONNECTION_STRING = DefaultEndpointsProtocol=https;AccountName=...
API_KEY = xxxxxxxxxxxxxxxx
ENVIRONMENT = prod

이 값들은 Azure Portal 또는 Azure CLI에서 설정하며, 코드에서는 환경 변수로 읽어옵니다.

# Python 예시
import os
connection_string = os.environ["STORAGE_CONNECTION_STRING"]

// Node.js 예시
const connectionString = process.env.STORAGE_CONNECTION_STRING;

Storage Account 보안 구성

설정 항목 권장 값 이유

Public Blob Access	비활성화	직접 URL 접근 차단
접근 방식	Private Endpoint	VNet 내부에서만 접근
연결 문자열	App Settings	코드 하드코딩 방지
CORS	필요한 Origin만 허용	크로스 도메인 공격 방지

보안 설계 원칙 요약

✅ 외부 노출 최소화: Frontend만 Public, 나머지는 Private
✅ 비밀 정보 분리: App Settings로 환경 변수 관리
✅ 네트워크 격리: VNet + Private Endpoint 조합
✅ 역할 기반 접근: Managed Identity 활용 (Key 없는 인증)

심화 팁: Storage Account 접근 시 연결 문자열 대신 Managed Identity + RBAC을 사용하면 Access Key 자체를 관리할 필요가 없어집니다. 이것이 진정한 "키 없는(keyless) 아키텍처"입니다.

11. 이 설계를 통해 얻는 역량

이 프로젝트를 완성하면 단순한 클라우드 사용자를 넘어 클라우드 설계 경험자로 포지셔닝할 수 있습니다.

역량 영역 습득 내용

Azure PaaS 이해	App Service, Blob Storage의 실제 구성 방법
네트워크 설계	VNet, Subnet, Private Endpoint 실무 적용
API 설계 능력	Frontend-Backend-Storage 분리 아키텍처
배포 전략	Blue/Green 배포, 무중단 Swap 운영
보안 설계	최소 권한 원칙, 비밀 정보 분리 관리
네이밍 규칙	엔터프라이즈 수준의 리소스 네이밍 체계

12. 마무리 및 다음 단계

이 글에서 설계한 Azure Bakery Image Platform은 단순한 파일 업로드 서비스가 아닙니다.

3-Tier 엔터프라이즈 구조로 역할이 명확히 분리되어 있고
API 중심 설계로 Frontend와 Backend가 독립적으로 확장 가능하며
Blue/Green 배포로 운영 중 다운타임 없이 새 버전을 릴리스할 수 있고
VNet 분리와 Private Endpoint로 보안 수준을 기업 표준에 맞췄습니다

이 아키텍처는 빵집 이미지 플랫폼으로 시작하지만, 구조 자체는 실제 SaaS 서비스, 사내 포털, API Gateway 뒤에 배치되는 마이크로서비스에도 동일하게 적용됩니다.

'클라우드 아키텍처·전략' 카테고리의 다른 글

Azure에서 FE/BE VM 분리했을 때 외부 접속이 안 되는 이유와 Reverse Proxy 설정법 (0)	2026.03.02
프라이빗 EC2에 SSH 없이 접속하는 법 — NAT Gateway 끊고 SSM으로 바꾼 이유 (0)	2026.02.23
멀티클라우드 아키텍처가 머릿속에 안 그려질 때 — AWS 실습으로 직접 부딪혀봤다 (0)	2026.02.19
AWS 배우면서 Azure 시작한 멀티클라우드 입문자의 현실 기록 (0)	2026.02.19
IaaS, PaaS, SaaS를 직접 실습하며 책임 경계를 정리해본 기록 (1)	2026.02.18

클라우드 학습기

Azure PaaS로 구축하는 3-Tier 이미지 업로드 웹 서비스 — 엔터프라이즈 아키텍처 완전 가이드

1. 왜 PaaS 기반 3-Tier 아키텍처인가?

2. 프로젝트 개요

프로젝트명

구현 목표

아키텍처 다이어그램 (개요)

3. 네이밍 규칙

기본 패턴

예시 기준값

4. 리소스 그룹 설계

5. 네트워크 설계

VNet (Virtual Network)

Subnet 구성

IP 설계 원칙

6. PaaS 리소스 구성

① App Service Plan

② Frontend Web App

③ Backend API App

④ Storage Account

7. 이미지 업로드 기능 흐름

8. 초기 Public 구조 → VNet 전환 전략

Phase 1: 초기 Public 구조 (기능 검증)

Phase 2: VNet 전환 (보안 강화)

9. Deployment Slot으로 무중단 배포 구현

Slot 구성

배포 프로세스 (Swap 방식)

10. 보안 설계

App Settings로 민감 정보 관리

Storage Account 보안 구성

보안 설계 원칙 요약

11. 이 설계를 통해 얻는 역량

12. 마무리 및 다음 단계

'클라우드 아키텍처·전략' 카테고리의 다른 글

티스토리툴바

티스토리툴바

Azure PaaS로 구축하는 3-Tier 이미지 업로드 웹 서비스 — 엔터프라이즈 아키텍처 완전 가이드

1. 왜 PaaS 기반 3-Tier 아키텍처인가?

2. 프로젝트 개요

프로젝트명

구현 목표

아키텍처 다이어그램 (개요)

3. 네이밍 규칙

기본 패턴

예시 기준값

4. 리소스 그룹 설계

5. 네트워크 설계

VNet (Virtual Network)

Subnet 구성

IP 설계 원칙

6. PaaS 리소스 구성

① App Service Plan

② Frontend Web App

③ Backend API App

④ Storage Account

7. 이미지 업로드 기능 흐름

8. 초기 Public 구조 → VNet 전환 전략

Phase 1: 초기 Public 구조 (기능 검증)

Phase 2: VNet 전환 (보안 강화)

9. Deployment Slot으로 무중단 배포 구현

Slot 구성

배포 프로세스 (Swap 방식)

10. 보안 설계

App Settings로 민감 정보 관리

Storage Account 보안 구성

보안 설계 원칙 요약

11. 이 설계를 통해 얻는 역량

12. 마무리 및 다음 단계

'클라우드 아키텍처·전략' 카테고리의 다른 글

관련글

티스토리툴바

티스토리툴바