Web Architecture

HelloPong·2025년 8월 4일

Web Architecture 공부

공부

목록 보기

10/39

🌐 Web Architecure 이란?

사용자의 요청이 어떻게 웹 서버를 통해 처리되고, 데이터를 가져오며, 결과를 브라우저로 응답하는지까지의 전체 흐름을 정의하는 시스템 구성도입니다.

🧠 1. DNS

DNS(Domain Name System)는 인터넷에서 도메인 이름(예: google.com)을
→ 실제 컴퓨터가 이해할 수 있는 IP 주소(예: 142.250.196.78)로 변환해주는 시스템입니다.

📞 전화번호부에 이름을 검색하면 번호가 나오는 것처럼,
DNS는 “도메인 이름 → IP 주소”를 찾아주는 인터넷의 전화번호부 역할을 합니다.

🔁 동작 흐름 (요청 1회 기준)

[사용자 브라우저]
    ↓ www.example.com 요청
[운영 체제의 DNS 캐시 확인]
    ↓ (없으면)
[로컬 네임서버(보통 ISP)]
    ↓
[권한 있는 DNS 서버들 계층적으로 탐색]
    ↓
[도메인에 해당하는 IP 주소 반환]
    ↓
[브라우저가 해당 IP로 접속]

🎯 왜 필요한가?

IP 주소는 외우기 어렵고 가변적이지만, 도메인 이름은 기억하기 쉬움
DNS 덕분에 우리는 https://www.naver.com 같은 도메인을 사용할 수 있는 것

🧵 실무에서 사용하는 DNS 시스템

Route 53 (AWS): 클라우드 기반 DNS 관리 서비스
Cloudflare DNS: 보안 + 성능 최적화 DNS (CDN과 연동)
Google DNS (8.8.8.8): 빠른 퍼블릭 DNS
도메인 구입처 자체 DNS: 도메인을 연결할 때 가장 먼저 설정하는 부분

🧠 Tip: DNS 캐시란?

DNS 응답 결과는 성능 향상을 위해 캐싱됩니다.
👉 운영체제, 브라우저, 라우터, ISP 모두 DNS 결과를 일정 시간 저장합니다.
👉 그래서 DNS 레코드를 변경해도 즉시 반영되지 않을 수 있음.

✅ 정리

DNS는 도메인 → IP 주소로 변환하는 시스템이다.
DNS는 사용자 편의성과 서버 통신의 중재자 역할을 한다.
실제 웹 요청은 브라우저 → DNS → IP 주소 → 웹 서버 순으로 이루어진다.

🧠 2. 로드 밸런서란?

Load Balancer(로드 밸런서)는 들어오는 트래픽을 여러 대의 서버에 고르게 분산시켜주는 장치입니다.

🏗️ 언제 필요할까?

서비스 이용자가 늘어나면서 서버 한 대가 감당 불가
특정 서버에 트래픽이 몰려서 성능 저하
서버가 다운돼도 서비스 중단 없이 유지하고 싶을 때

🔁 동작 방식

[User Browser]
   ↓
[DNS: www.example.com → LB IP 주소]
   ↓
[Load Balancer]
  ├─> Web Server #1
  ├─> Web Server #2
  └─> Web Server #3

📦 로드 밸런서는 요청을 받아서

✅ 살아 있는 서버 중 하나를 선택
✅ 트래픽을 적절히 분배
✅ 응답을 다시 사용자에게 전달

⚖️ 로드 밸런싱 알고리즘

알고리즘	설명
Round Robin	순서대로 서버에 분산
Least Connections	현재 접속 수가 가장 적은 서버 선택
IP Hash	클라이언트 IP 기반으로 서버 결정 (세션 유지)
Health Check	죽은 서버로 요청 안 보내기 (정기 검사)

🔍 수평 확장 vs 수직 확장

수평 확장(Scale Out)
→ 서버 대수를 늘림
→ 로드 밸런서로 쉽게 처리 가능 ✅
수직 확장(Scale Up)
→ 서버 한 대의 성능(메모리, CPU)을 높임
→ 성능 한계에 금방 도달 ❌

🛠️ 실무에서 사용하는 로드 밸런서

종류	설명
L4 로드 밸런서	TCP/UDP 기반 분산 (네트워크 계층)
L7 로드 밸런서	HTTP/HTTPS 기반 분산 (애플리케이션 계층)
Nginx / HAProxy	소프트웨어 방식 L7 로드 밸런서
AWS ELB (ALB/NLB)	클라우드 기반 로드 밸런서 서비스
Kubernetes Ingress	컨테이너 기반 서비스 로드 분산 담당

✅ 정리

로드 밸런서는 트래픽 분산 + 장애 대응을 담당하는 핵심 장비
수평 확장을 가능하게 하며, 웹 서비스의 성능과 안정성을 크게 향상시킴
L4/L7 개념, 알고리즘, 실무 도구(Nginx, AWS ELB 등)를 함께 이해하면 실전에서 유용

🧠 3. Web App Server란?

웹 애플리케이션 서버(Web App Server)는 사용자 요청을 받아서
👉 핵심 비즈니스 로직을 실행하고
👉 필요한 데이터를 조회/가공한 뒤
👉 결과를 HTML, JSON 등의 형태로 응답하는 서버.

🔁 동작 흐름

[User Request]
   ↓
[Load Balancer]
   ↓
[Web App Server]
  ├─> Database 조회
  ├─> 캐시(Cache) 확인
  ├─> 비동기 작업(Job Queue) 등록
  ├─> 마이크로서비스 API 호출
   ↓
[응답 생성 → 사용자에게 반환]

🧩 구성 요소

구성 요소	역할
Controller	사용자의 요청을 처리하는 진입점
Service Layer	핵심 로직 수행
Repository	DB 또는 외부 자원에 접근
Template/View	사용자에게 보여줄 HTML 생성

🛠 사용되는 언어 및 프레임워크 예시

언어	대표 프레임워크
Java	Spring Boot 🌱
Node.js	Express 🚀
Python	Django, Flask 🐍
Ruby	Ruby on Rails 💎
PHP	Laravel 🐘
C#	ASP.NET 🧱

✅ 정리

Web App Server는 웹 아키텍처의 핵심 비즈니스 로직 수행자
요청을 받아 DB/캐시/서비스 등과 연결하고, HTML 또는 JSON 응답을 만들어낸다
현대 웹 서비스는 대부분 프레임워크 기반으로 이 흐름을 체계화해 구성한다

🧠 4. Database란?

Database(데이터베이스)는 웹 서비스가 사용하는 모든 정보(데이터)를 구조화된 형태로 저장하는 시스템이다.

📊 SQL vs NoSQL

🧾 1. SQL (관계형 DB – Relational)

✔️ 정형화된 구조에 강하고, 복잡한 관계 데이터를 다루기에 적합

테이블 기반 구조
엄격한 스키마(컬럼 타입, 제약조건 등)
JOIN, Foreign Key, 정규화 지원
예시: MySQL, PostgreSQL, Oracle, MSSQL

SELECT * FROM users WHERE email = 'abc@example.com';

🗃️ 2. NoSQL (비관계형 DB – Non-relational)

✔️ 빠르게 변하는 구조나 대용량 비정형 데이터를 다룰 때 적합

테이블 대신 JSON, 키/값, 그래프, 컬럼 형태로 저장
스키마 유연함, 구조 자유로움
수평 확장이 쉬움 (대규모 시스템에 적합)
예시: MongoDB, Redis, Cassandra, DynamoDB

{
  "_id": "user123",
  "email": "abc@example.com",
  "name": "홍길동"
}

🔐 DB와의 연결

웹 앱 서버는 ORM(Object-Relational Mapping) 또는 직접 SQL을 통해 DB와 연결됨

Java → JPA(Hibernate), MyBatis
Node.js → Sequelize, Prisma
Python → SQLAlchemy, Django ORM

🧠 5. 캐시란?

Cache(캐시)는 자주 요청되는 데이터나 연산 결과를
👉 미리 저장해두고 빠르게 응답할 수 있게 하는 고속 저장소.

🔁 동작 구조

[사용자 요청]
   ↓
[Web App Server]
   ├─> 캐시에 있는가?
   │     └ Yes → 캐시에서 응답
   │     └ No  → DB/외부 연산 후 캐시에 저장
   ↓
[응답 반환]

🔥 왜 중요한가?

효과	설명
속도 향상	O(1)에 가까운 응답 속도
DB 부하 감소	반복적인 요청을 DB까지 보내지 않음
트래픽 방어	대량 트래픽에서 병목 방지
비용 절감	DB/외부 API 호출 비용 줄이기

🧱 캐시 저장소 종류

기술	설명
Redis	메모리 기반, 고성능, 다양한 자료구조 지원, TTL 설정 가능
Memcached	키/값 전용, 단순하지만 빠름
Local Memory Cache	애플리케이션 내 임시 저장 (프로세스 재시작 시 초기화)
Browser Cache	정적 리소스(JS, CSS, 이미지)를 브라우저에 저장

⏳ TTL (Time To Live)

캐시는 언제까지 유효할지(TTL) 를 설정할 수 있음

TTL이 지나면 데이터는 만료되고 다시 계산해서 저장함

⚠️ 주의할 점

과도한 캐싱은 데이터 불일치 문제를 일으킬 수 있음
갱신이 잦은 데이터는 캐시보다 실시간 쿼리가 나을 수 있음
TTL, 무효화 정책, Key 설계가 중요함

🧠 6. Job Queue란?

Job Queue(잡 큐)는 시간이 오래 걸리는 작업을 즉시 처리하지 않고,
👉 작업 목록에 저장해두고,
👉 나중에 비동기적으로 처리하는 시스템.

🔁 동작 흐름

[사용자 요청]
   ↓
[Web App Server]
   ├─> 잡 생성 (예: 이미지 썸네일 생성)
   ↓
[Job Queue에 등록]
   ↓
[Job Worker가 꺼내서 실행]
   ↓
[DB 업데이트 or 알림 전송 등]

📦 왜 필요한가?

이유	설명
응답 속도 향상	사용자는 빠르게 결과 받음
무거운 작업 분리	이미지 처리, 메일 전송, 외부 API 호출 등
서비스 안정성 향상	트래픽 폭주에도 비동기로 큐에 쌓아 처리
재시도, 우선순위 설정 가능	작업 실패 시 재시도 로직 구성 가능

🧵 실무 예시

작업	비동기 처리 이유
이메일 인증 메일 발송	실시간 응답과 무관
이미지 리사이징 / 썸네일 생성	처리 시간 길고 서버 자원 많이 씀
PDF 변환	외부 툴 연동 필요
사용자 분석 이벤트 전송	분석은 실시간일 필요 없음

🛠 기술 스택 예시

언어/프레임워크	큐 라이브러리
Node.js	BullMQ (Redis 기반), Agenda
Python	Celery (Redis/RabbitMQ)
Java	Spring Batch, Spring Scheduler, Quartz
Go	go-worker, machinery

🧪 동작 예시 (Redis 기반 BullMQ)

queue.add('generate-thumbnail', { imageId: 'abc123' });

// 작업 처리 워커
queue.process('generate-thumbnail', async (job) => {
  const { imageId } = job.data;
  await resizeImage(imageId); // 썸네일 생성
});

⚠️ 주의할 점

큐 폭주 시 처리 지연 가능 → 우선순위 설정 필요
잡 실패/중복 처리 방지를 위한 예외 핸들링 필수
DB와의 트랜잭션 분리 주의 (DB → 잡 순서 보장 필요)

🧠 7. Full-Text Search란?

Full-Text Search(전문 검색)는 텍스트 기반의 콘텐츠(제목, 본문 등)에서
→ 특정 단어 또는 구문이 포함된 데이터를 빠르게 찾을 수 있도록 도와주는 기술.

📌 일반 SQL의 LIKE '%keyword%' 쿼리보다 훨씬 빠르고 정교하게 동작함.

🔁 동작 구조

[사용자 검색어 입력]
   ↓
[Web App Server]
   ↓
[검색 서비스(Full-Text Search Engine)]
   ↓
[관련 문서 ID 목록 반환]
   ↓
[DB or Cache에서 상세 정보 조회]
   ↓
[결과 화면 렌더링]

🔍 어떻게 동작할까?

전문 검색은 역 인덱스(Inverted Index)라는 구조를 활용해 작동.

📘 역 인덱스란?

단어 → 그 단어를 포함하고 있는 문서들의 리스트

단어:         포함 문서:
"sunbeam"  →  [doc3, doc6]
"forest"   →  [doc1, doc3, doc9]
"fog"      →  [doc2, doc3]

🛠 실무에서 사용하는 검색 엔진

검색 엔진	특징
Elasticsearch	가장 널리 쓰이는 검색엔진, RESTful API 기반, 분산 처리 탁월
Apache Solr	Lucene 기반, XML 구성, 강력한 기능
Meilisearch	가볍고 빠른 검색 엔진, 개발자 친화적
MySQL Full-Text Index	MySQL 자체 기능 (간단한 검색에만 적합)

✨ 기능 예시 (Elasticsearch 기준)

정렬/스코어 기반 랭킹
동의어 처리 (예: “tv” ≈ “television”)
오타 허용 (fuzzy 검색)
자동완성(suggesters)
다국어 형태소 분석기

⚠️ 주의할 점

데이터 정합성 유지
(DB 변경 시, 검색 인덱스도 같이 갱신 필요)
동기화 지연
실시간 업데이트가 필요한 경우 특별한 설계 필요
스케일링 고려
검색량이 많아질수록 분산 인덱싱/샤딩 필요

🧠 8. MSA(Microservices Architecture)란?

MSA(Microservices Architecture)는
👉 애플리케이션을 작고 독립적인 기능 단위로 나누어
👉 각각을 독립적으로 개발, 배포, 운영하는 아키텍처 스타일.

🔍 왜 분리할까?

이유	설명
규모 확장	기능이 많아질수록 코드/팀이 커짐 → 유지보수 어려움
역할 분리	서비스마다 책임(RBAC) 명확하게 구분
독립 배포	일부 기능만 수정해도 전체 배포 필요 없음
장애 격리	하나의 기능에 문제가 생겨도 다른 기능은 정상 작동

🧱 서비스 분리 예시: Storyblocks

서비스	기능 설명
계정 서비스	사용자 정보 관리, 로그인, 회원가입
결제 서비스	결제 처리, 영수증 발급, 플랜 관리
콘텐츠 서비스	이미지/비디오 메타데이터 관리
다운로드 서비스	다운로드 기록 관리 및 파일 전송
PDF 서비스	HTML → PDF 변환 API 제공

🛠 실무에서의 서비스 분리 패턴

패턴	설명
모놀리식 → 마이크로서비스	처음엔 하나로 만들고, 점차 기능 단위로 쪼갬
기능 중심 도메인 분리	DDD 기반으로 서비스 책임을 명확히 나눔
팀 단위 분리	팀마다 담당하는 서비스만 운영/배포

⚠️ 주의할 점

서비스 간 데이터 공유 금지: 직접 DB 접근 ❌ → API로만 통신해야 함
네트워크 지연 고려: REST 호출 지연이나 실패 대비 필수
버전 관리: 각 서비스는 독립적으로 버전 관리 필요
공통 모듈 분리: 인증, 로깅, 공통 유틸은 별도 공통 서비스 또는 라이브러리로 관리

🧠 9. Data Warehouse란?

Data Warehouse(데이터 웨어하우스)는
서비스 전반에서 발생하는 데이터를
👉 분석 및 의사결정에 활용할 수 있도록 저장하는 전용 저장소.

운영 DB와는 달리,
실시간 처리보다 대규모 분석을 위한 최적화
다양한 소스에서 수집된 데이터를 가공 및 통합해 저장

📦 왜 필요한가?

이유	설명
사용자 행동 분석	유입 경로, 이탈 지점, 클릭 패턴 등
비즈니스 지표 측정	일간 활성 사용자(DAU), 전환율, 매출
서비스 개선 인사이트 도출	어떤 기능이 자주 쓰이고 어떤 건 버려지는지
데이터 기반 의사결정	감이 아니라 수치로 판단 가능하게 함

🔁 데이터 웨어하우스 흐름

[앱/웹]  →  [로그 이벤트 수집 (Firehose)]  
   ↓  
[큐/버퍼: Kafka, Kinesis]  
   ↓  
[ETL(정제) → 클라우드 스토리지(S3)]  
   ↓  
[데이터 웨어하우스(Redshift, BigQuery)]  
   ↓  
[분석 도구(Tableau, Metabase, Superset)]

🧱 구성 요소

구성	설명
Firehose	사용자 행동, API 호출, 클릭 이벤트 등 실시간 스트림 수집
Storage	원시 데이터 저장 (S3 등)
ETL/ELT	데이터를 정제하고 변환 (예: 날짜 형식, 필드 분리 등)
Data Warehouse	분석 가능한 형태로 저장된 구조화 데이터
분석 툴	쿼리/시각화를 통해 인사이트 추출

🛠 주요 기술 예시

용도	기술
스트림 수집	Kafka, AWS Kinesis, Fluentd
저장소	Amazon S3, GCS
ETL 파이프라인	Apache Spark, Airflow, DBT
웨어하우스	AWS Redshift, BigQuery, Snowflake
시각화 도구	Tableau, Metabase, Apache Superset

📌 운영 DB와의 차이

구분	운영 DB	데이터 웨어하우스
목적	트랜잭션 처리 (실시간 응답)	분석용 저장 (쿼리 최적화)
스키마	정규화	비정규화 또는 분석 목적 구조
데이터 크기	비교적 작음	수억~수십억 건 이상
예시	MySQL, PostgreSQL	Redshift, BigQuery, Snowflake

✅ 정리

Data Warehouse는 분석 가능한 구조로 데이터를 저장하는 시스템
Kafka → S3 → Redshift 흐름이 가장 일반적
실시간 로그 수집, ETL, 시각화까지 연결하면 강력한 분석 플랫폼 완성

🧠 10. Cloud Storage란?

Cloud Storage(클라우드 스토리지)는
웹 서버가 아닌 클라우드 인프라에 데이터를 저장하고,
인터넷을 통해 접근할 수 있게 해주는 저장 공간.

쉽게 말해, 파일 서버의 클라우드 버전이자
S3 같은 데에 이미지를 저장하고, URL로 접근할 수 있는 구조.

🔁 동작 흐름

[사용자 업로드 요청]
   ↓
[Web App Server]
   ↓
[Cloud Storage API로 파일 업로드]
   ↓
[저장된 URL 반환 → DB에 저장]
   ↓
[사용자가 해당 URL로 직접 접근]

🧱 대표적인 클라우드 스토리지 서비스

서비스	설명
AWS S3	가장 보편적인 객체 스토리지, 버킷 단위로 관리
Google Cloud Storage (GCS)	GCP 기반 객체 저장소
Azure Blob Storage	MS Azure 기반 파일 저장소
Firebase Storage	모바일 앱 중심의 실시간 파일 스토리지
Wasabi / Backblaze	저비용 대안 클라우드 저장소

🔐 클라우드 스토리지의 특징

기능	설명
무한 확장성	용량 제한 없이 저장 가능
URL 접근 가능	Public URL 또는 인증된 Presigned URL로 접근
권한 제어	ACL, 정책 기반 권한 설정 가능 (읽기/쓰기 제한 등)
버전 관리	파일 변경 시 이전 버전 보존 가능
정적 웹 호스팅 지원	HTML, JS, CSS만으로도 정적 사이트 배포 가능

✅ 정리

Cloud Storage는 웹 애플리케이션에서 정적/대용량 파일 저장에 필수
AWS S3 같은 객체 스토리지를 통해 REST API 기반으로 쉽게 저장/접근 가능
CDN과 연동하면 빠르고 효율적인 파일 제공 가능

🧠 11. CDN(Content Delivery Network)이란?

CDN (Content Delivery Network)은
HTML, CSS, JS, 이미지, 영상 등의 정적 콘텐츠를 전 세계 여러 서버에 분산 저장하고
→ 사용자와 가장 가까운 서버에서 콘텐츠를 전달해주는 시스템.

📦 원본(origin) 서버 하나에서만 전송하면 느려질 수 있으니,
CDN이 전 세계 "복사본 서버(엣지 서버)"를 대신 전달하게 해주는 구조.

🌍 동작 원리

[User in Spain] → 유럽의 CDN 엣지 서버

[사용자 요청]
   ↓
[CDN 엣지 서버에 캐시 존재?]
   ├ Yes → 즉시 응답
   └ No  → 원본 서버에서 받아와 저장 후 응답

📈 왜 사용할까?

이유	설명
전송 속도 향상	사용자와 가까운 곳에서 데이터 전달 (Latency↓)
트래픽 분산	원본 서버 부하 줄이기
서비스 안정성	서버 하나에 문제가 있어도 전 세계 엣지가 커버
보안 기능	DDoS 방어, SSL 인증서 연동, 접근 제어 등

🧱 대표 CDN 서비스

서비스	설명
AWS CloudFront	S3, EC2, ALB 등과 쉽게 연동
Cloudflare	무료 TLS/SSL + 글로벌 CDN + 보안 기능
Akamai	글로벌 대형 CDN, OTT·대기업 중심
Fastly	엣지 컴퓨팅 최적화, 개발자 친화적
Firebase Hosting	모바일 친화형 정적 사이트 배포 + CDN

📌 주의할 점

캐시 무효화(Invalidation): 파일 갱신 시 CDN에서 캐시도 무효화해야 함
Signed URL/Key: 민감한 파일은 인증된 요청만 허용 가능
HTTPS 적용: 모든 엣지 노드에서 TLS 연결 지원 필요

✅ 정리

CDN은 정적 콘텐츠를 사용자에게 더 빠르고 안전하게 전달하는 핵심 인프라
전 세계 엣지 서버에서 캐시를 제공하여 속도/안정성/보안 모두 향상
CloudFront, Cloudflare, Akamai 등 다양한 선택지가 존재

HelloPong

INTJ

이전 포스트

SPOF 란?

다음 포스트

Web Architecture

공부

🌐 Web Architecure 이란?

🧠 1. DNS

🔁 동작 흐름 (요청 1회 기준)

🎯 왜 필요한가?

🧵 실무에서 사용하는 DNS 시스템

🧠 Tip: DNS 캐시란?

✅ 정리

🧠 2. 로드 밸런서란?

🏗️ 언제 필요할까?

🔁 동작 방식

📦 로드 밸런서는 요청을 받아서

⚖️ 로드 밸런싱 알고리즘

🔍 수평 확장 vs 수직 확장

🛠️ 실무에서 사용하는 로드 밸런서

✅ 정리

🧠 3. Web App Server란?

🔁 동작 흐름

🧩 구성 요소

🛠 사용되는 언어 및 프레임워크 예시

✅ 정리

🧠 4. Database란?

📊 SQL vs NoSQL

🧾 1. SQL (관계형 DB – Relational)

🗃️ 2. NoSQL (비관계형 DB – Non-relational)

🔐 DB와의 연결

🧠 5. 캐시란?

🔁 동작 구조

🔥 왜 중요한가?

🧱 캐시 저장소 종류

⏳ TTL (Time To Live)

⚠️ 주의할 점

🧠 6. Job Queue란?

🔁 동작 흐름

📦 왜 필요한가?

🧵 실무 예시

🛠 기술 스택 예시

🧪 동작 예시 (Redis 기반 BullMQ)

⚠️ 주의할 점

🧠 7. Full-Text Search란?

🔁 동작 구조

🔍 어떻게 동작할까?

📘 역 인덱스란?

🛠 실무에서 사용하는 검색 엔진

✨ 기능 예시 (Elasticsearch 기준)

⚠️ 주의할 점

🧠 8. MSA(Microservices Architecture)란?

🔍 왜 분리할까?

🧱 서비스 분리 예시: Storyblocks

🛠 실무에서의 서비스 분리 패턴

⚠️ 주의할 점

🧠 9. Data Warehouse란?

📦 왜 필요한가?

🔁 데이터 웨어하우스 흐름

🧱 구성 요소

🛠 주요 기술 예시

📌 운영 DB와의 차이

✅ 정리

🧠 10. Cloud Storage란?

🔁 동작 흐름

🧱 대표적인 클라우드 스토리지 서비스

🔐 클라우드 스토리지의 특징

✅ 정리

🧠 11. CDN(Content Delivery Network)이란?

🌍 동작 원리

📈 왜 사용할까?

🧱 대표 CDN 서비스

📌 주의할 점

✅ 정리

SPOF 란?

고가용성(HA) 란?

0개의 댓글