PERSONAL INFRASTRUCTURE PROJECT

01 / INTRODUCTION

주인장 맛집

서비스 개발을 넘어,
직접 운영 가능한 서버 환경 구축

VMware 기반 Rocky Linux 서버에서 실제 서비스가 동작할 환경을 직접 구축하고,
Web · WAS · DB로 이어지는 서버 간 통신과 운영 구조를 단계적으로 구성합니다.

VMwareRocky LinuxDockerNginxSpring Boot MariaDBsystemdfirewalldTailscaleRAID1
01 PROJECT CONCEPT

서비스는 인프라를 검증하기 위한
실제 Workload

「주인장 맛집」은 대구 지역의 맛집 정보를 조회하지만, 프로젝트의 중심은 애플리케이션 개발 자체가 아닙니다.

Application=Workload

실제 서비스 환경을 만들어 서버 · 네트워크 · 스토리지 · 운영 구조를 직접 검증합니다.

02 CURRENT GOAL OPERABLE

서비스를 운영 가능한 상태까지 구축

INFRASTRUCTUREVMware · Rocky Linux · RAID1
SERVICENginx · Spring Boot · MariaDB
OPERATIONDocker · systemd · firewalld · Tailscale
CLIENTWEBWASDBSTORAGE

재부팅 이후에도 서비스를 다시 제공할 수 있는 운영 환경

03 FINAL GOAL NEXT PHASE

운영에서 장애 대응까지

SERVICE운영
MONITOR관찰
FAILURE장애
ANALYSIS분석
RECOVERY복구

서버 구축과 배포 이후, 상태 관찰과 의도적인 장애 실험을 통해 원인 분석부터 복구까지 직접 검증합니다.

CPUMemoryDiskNetworkProcessContainerHTTPLogsFailure TestRecovery
PROJECT
STATEMENT

서비스를 띄우는 것에서 끝내지 않고,
장애를 관찰→분석→복구할 수 있는 서버까지.

02 SERVER FOUNDATION

운영 환경을 구성하기 위한
기술 선택

제한된 개인 장비 안에서
실제 서비스를 운영하기 위한 기반 기술을 선택했습니다.

WINDOWS PHYSICAL HOSTVMWARE WORKSTATIONROCKY LINUX 9DOCKERSERVICE COMPONENTS
01VIRTUALIZATION

VMware Workstation

WHAT
PHYSICAL HOSTWindows Desktop
VIRTUALIZATIONVMware Workstation
SERVER VMRocky Linux 9
WHY

무료로 사용할 수 있는 VMware Workstation을 통해 별도 솔루션 비용 없이 데스크탑 자원을 서버 환경으로 활용할 수 있다고 판단했습니다.

FREEDESKTOP RESOURCEVIRTUAL SERVER
02SERVER OS

Rocky Linux 9

WHAT
01

RHEL 계열 Linux 환경으로 실제 서버 운영 환경을 학습하는 데 적합하다고 판단했습니다.

02

수업에서 사용한 경험을 바탕으로 OS 학습보다 서버 구축과 운영에 집중할 수 있습니다.

PREVIOUS EXPERIENCEROCKY LINUXPERSONAL SERVER PROJECT
RHEL FAMILYLINUX SERVEREXISTING EXPERIENCE
03CONTAINER PLATFORM

Docker

WHAT
MULTI VM
VMGuest OSService VMGuest OSService VMGuest OSService

Repeated Guest OS
Higher Resource Usage

VS
DOCKER
Rocky LinuxDocker
ServiceServiceService

Shared Host OS
Service Isolation

WHY

제한된 데스크탑의 CPU · Memory · Storage 안에서 서비스를 분리하고 자원을 효율적으로 사용하기 위한 선택입니다.

RESOURCE EFFICIENCYSERVICE ISOLATION
OS · VIRTUALIZATION · CONTAINER

제한된 개인 장비에서, 실제 서버 운영에 가까운 환경을 구성했습니다.

03 SERVER FOUNDATION

운영을 위한
저장공간과 관리 경로

서비스 실행 환경과 데이터 저장 영역을 분리하고,
외부에서도 서버를 관리할 수 있는 접속 경로를 구성했습니다.

SERVER ENVIRONMENTSTORAGEREMOTE MANAGEMENTSERVICE DEPLOYMENT
01STORAGE

시스템과 데이터 영역 분리

RAID1 / DATA STORAGE
ROCKY LINUX SERVER운영 기반
SYSTEM AREARocky LinuxService RuntimeConfiguration
DATA AREARAID1/dataPersistent Data

DATA WRITE

Disk ADisk B
MIRRORING
RAID1/data
WHY RAID1?MIRRORING · REDUNDANCY · SIMPLE MANAGEMENT

처음 구성하는 RAID인 만큼, 동일한 데이터를 두 디스크에 저장하는 단순한 미러링 구조가 구성과 관리 측면에서 이해하기 쉽다고 판단했습니다.

RAID1은 백업을 대체하지 않으며, 디스크 장애에 대비한 저장장치 이중화를 목적으로 구성했습니다.
RAID1/dataService DataMariaDB Persistent Data /data/docker/mariadb/data
02REMOTE MANAGEMENT

Windows에서 Linux 서버 관리

TAILSCALE / SSH
WINDOWS DESKTOPWindows Terminal
REMOTE ACCESSTailscalePRIVATE NETWORK / VPNSSH
ROCKY LINUX VMServer Management
WHY REMOTE MANAGEMENT?

VMware 콘솔보다 익숙한 Windows Terminal에서 명령을 입력하는 것이 편리하다고 판단했습니다. Tailscale 사설 네트워크를 통해 장소와 관계없이 SSH로 서버를 관리합니다.

WINDOWS TERMINALREMOTE ACCESSTAILSCALESSH
FALLBACK ACCESSSECONDARY MANAGEMENT PATH
External PCWindows HostVMware ConsoleRocky Linux

SSH 또는 Linux 네트워크에 문제가 생겨도 Windows 호스트를 거쳐 VMware 콘솔을 직접 조작할 수 있습니다.

STORAGE · REMOTE MANAGEMENT

데이터 저장 영역을 분리하고, 외부에서도 관리 가능한 서버 기반을 완성했습니다.

04 SERVICE DEPLOYMENT

운영 기반 위에
실제 서비스를 배치하다

서비스의 역할과 현재 개발 단계를 고려해
Docker Container와 Host Service 방식을 나누어 구성했습니다.

SERVER FOUNDATIONSERVICE DEPLOYMENTREQUEST FLOWSECURITY
ONLINEROCKY LINUX 9SERVICE HOST

DEPLOYMENT SCOPE LOCAL SERVER

01CONTAINER SERVICES
DOCKER RUNTIME
REVERSE PROXYCONTAINER

Nginx

Reverse Proxy

외부 요청을 수신하고 설정된 경로에 따라 내부 서비스로 전달하는 진입점

REQUEST ROUTINGDocker
WEB SERVERCONTAINER

Nginx

Presentation Web Server

발표용 HTML · CSS · JavaScript 정적 파일 제공

CURRENT PRESENTATION
STATIC CONTENTDocker
DATABASECONTAINER

MariaDB

Database Container

서비스 데이터를 저장하는 Database Service

Database Process≠Persistent Data
PERSISTENCEDocker
MariaDB ContainerBIND MOUNTRAID1 /data
/data/docker/mariadb/data
02HOST SERVICE
SYSTEMD MANAGED
APPLICATION / WASOPERABLE

Spring Boot

Executable JAR

SERVICEowner-food-backend.service STATUSRUNNING BOOTAUTO START
STARTSTOPRESTARTSTATUS
WHY JAR + SYSTEMD?DEVELOPMENT STAGE

API 변경이 잦은 현재 단계에서는 이미지를 매번 생성하기보다 JAR을 교체하고 systemd로 재시작하는 방식이 더 단순하다고 판단했습니다.

API MODIFYBUILDJAR REPLACERESTART
API 구조 안정화 이후 Spring Boot의 Docker 이미지화를 검토할 예정입니다.
DEPLOYMENT METHOD
DOCKER CONTAINERNginx Reverse Proxy · Nginx Web Server · MariaDB
HOST SERVICESpring Boot · Executable JAR · systemd

모든 서비스를 같게 배포하지 않고, 역할과 변경 주기에 따라 구분했습니다.

CONTAINER · HOST SERVICE · PERSISTENCE

서비스의 역할과 변경 주기에 따라, 각 구성요소의 운영 방식을 나누었습니다.

05 REQUEST FLOW

외부 요청은
어떤 경로로 처리되는가

외부 요청은 하나의 진입점을 통해 들어오고,
HTTP 요청 경로에 따라 내부 서비스로 전달됩니다.

SERVER FOUNDATIONSERVICE DEPLOYMENTREQUEST FLOWNEXT PHASE
EXTERNAL CLIENTBrowserREQUEST ORIGIN
TCP :8080EXTERNAL ENTRY
PHYSICAL HOSTWindows DesktopPORT :8080
VMware NetworkHOST → VM
SERVICE HOSTRocky Linux VMINTERNAL SERVER
HTTP RequestENTRY
ENTRY POINTNginx Reverse ProxyHTTP REQUEST ROUTING

요청 경로를 확인하고 설정된 Routing Rule에 따라 전달

WEB TIERWEB REQUEST
현재 발표 페이지 요청
STATIC CONTENTPresentation Web ServerNginx
HTML / CSS / JS
WEB RESPONSEBrowserCURRENT PRESENTATION
REQUEST ↓RESPONSE ↑
APPLICATION + DATA TIERAPI REQUEST
Client Request
APPLICATION / WASSpring Boot:8081
DB ACCESS
DATA TIERMariaDB:3306
API RESPONSEJSONvia Reverse Proxy
REQUEST ↓RESPONSE ↑
WEB REQUEST

Browser → Reverse Proxy → Web Server → Static Files → Browser

HTML / CSS / JS
API REQUEST

Client → Reverse Proxy → Spring Boot → MariaDB → JSON

API / DATABASE
WEB · WAS · DB · REQUEST ROUTING

외부 요청은 리버스 프록시를 통해 분기되고, 내부에서는 Web · WAS · DB 구조로 처리됩니다.

06 NEXT PHASE

서버에서 확인한 데이터를
실제 사용자 화면으로

다음 단계에서는 Flutter 애플리케이션을 개발하고,
현재 구축한 API와 연결해 실제 화면에서 데이터 조회 흐름을 확인할 예정입니다.

SERVER FOUNDATIONSERVICE DEPLOYMENTREQUEST FLOWNEXT PHASE
CURRENT

Server Side

API AVAILABLE
ENTRYNginxReverse Proxy
REST APISpring BootApplication Server
DATAMariaDBService Data
SERVERAPIREADY
CONNECTIONREST API
API RESPONSEJSON
  • GET /api/districts
  • GET /api/districts/{id}/neighborhoods
  • GET /api/neighborhoods/{id}/restaurants
  • GET /api/restaurants/{id}
SERVER DATA → VISUAL UI
NEXT STEP

Flutter Application

PLANNED
주인장 맛집⋮
LOCATION대구광역시
01구·군 선택District 02동 선택Neighborhood 03맛집 목록Restaurant 04맛집 상세Detail
UI CONCEPT · NOT IMPLEMENTED
BEFOREJSON ResponseNEXTVisual UI
NEXT OBJECTIVE

현재까지는 API 요청으로 데이터 반환을 확인했습니다. 다음 단계에서는 Flutter와 API를 연동해 같은 데이터를 실제 사용자 화면에서 확인할 수 있도록 구현할 예정입니다.

01Flutter 기본 화면 구성 02REST API 연동 03지역별 조회 흐름 구현 04맛집 상세 화면 구현
SERVER → API → USER INTERFACE

서버에서 확인하던 데이터를, 실제 사용자 화면으로 연결하는 단계입니다.

NEXT STEP · FLUTTER APPLICATION
07ENDING

THANK YOU

감사합니다.

주인장 맛집 PERSONAL INFRASTRUCTURE PROJECT