[프로젝트] On-Premise & Cloud

dev/프로젝트

[프로젝트] On-Premise & Cloud

dev-everyday 2025. 1. 21. 19:44

1. On-Premise(온프레미스) 환경

기업이나 조직이 직접 물리적인 서버와 네트워크를 구축하여 자체적으로 관리하는 환경으로 기업이 소유한 데이터센터 또는 내부 인프라에서 애플리케이션을 운영한다.

보통 대기업들은 본인만의 IDC 센터가 있다. IDC는 Data Center의 약자로 기업이 직접 보유한 서버실이다.

IDC 센터는 기업 내부 사내망에 연결되어 있어 회사 내부에서만 접근할 수 있는 서비스도 있다.

일반적으로 사무실이나 가정은 외부로 나가는 공인IP(인터넷 회선) 하나를 공유해서 사용하지만 IDC 센터는 서버 트래픽을 감당해야해서 대량의 회선을 직접 구매하여 사용한다.

IDC 센터는 서버 트래픽을 감당해야 해서 대량의 회선을 직접 구매하여 사용한다.

인터넷 서비스 제공업체(ISP)에게 비용을 내고 전용 회선을 구매하는데 자체 IDC가 없다면 IDC 호스팅 업체를 이용하여 IDC 공간을 임대해서 서버를 운영한다.

온프레미스 환경에서는 서버 자원이 한정적이라 클라우드처럼 유연하게 서버를 추가(Scale-Out)할 수 없다.

사내 서비스나 사내 시스템을 구현하기 위해 온프레미스를 사용한다.

트래픽이 좀 적은 대외 서비스에서도 사용하는데 기본적으로 외부 트래픽을 허용 안하고 보안적인거 관리하는 게 네트워크 팀과 보안 팀이 하는 일이다.

온프레미스 환경에서도 쿠버네티스를 활용하여 대규모 트래픽을 처리하기도 한다.

물리 서버에 쿠버네티스를 설치하여 여러 개의 컨테이너(Pod)를 실행하는데 쿠버네티스가 CPU, RAM 등의 리소스를 자동으로 분배한다.

트래픽이 증가하면 자동으로 Pod를 확장(Scale-Out)할 수 있다.

트래픽이 들어오면 프록시 서버가 Pod들에 요청을 분산해서 처리하는데 로드밸런서나 프록시 서버(Nginx, HAProxy, Traefix)가 트래픽을 여러 Pod에 분산해서 성능을 극대화할 수 있다.

쿠버네티스란? 쿠버네티스는 컨테이너(도커 등)를 관리하는 오케스트레이션 툴이다.

Pod란? 쿠버네티스에서 동작하는 최소 단위로, 하나의 컨테이너 또는 여러 개의 컨테이너를 포함할 수 있다.

쿠버네티스를 사용하면 서버 내에서 여러 개의 애플리케이션(Pod)을 독립적으로 실행 가능하다.

2. Cloud(클라우드) 환경

AWS, GCP, Azure 등 클라우드 서비스 제공업체가 제공하는 IT 인프라를 사용해서 애플리케이션을 운영하는 환경으로 필요할 때만 자원을 할당해서 사용할 수 있다. 이를 On-Demand 방식이라고 한다.

개발한 서비스를 EC2(Elastic Compute Cloud)에 배포한다면 트래픽이 증가하면 자동으로 서버를 확장(Scale-Out)해야한다.

서버 형상을 그대로 복사하는데 이를 AMI(Amazon Machine Image)라고 한다. 도커 이미지랑 비슷하다고 생각하자.

AMI를 사용하여 서버를 복제하고 Auto Scaling을 통해 새로운 EC2 인스턴스를 자동 생성한다.

이걸 위해서 따로 설정을 해야하는데 보통 똑같은 앱을 최소한 2개를 띄우고 node group으로 묶는다.

load balancer가 node group을 end point로 잡고 요청을 보내고 ec2로 보낸다.

클라우드 용어 정리

EC2(Elastic Compute Cloud): AWS의 가상 서버
AMI(Amazon Machine Image): EC2의 스냅샷(이미지). 새로운 서버를 생성할 때 동일한 환경을 유지하기 위해 사용됨.
Auto Scaling: 트래픽이 증가하면 AMI를 복제하여 새로운 EC2 인스턴스를 자동으로 생성하여 확장(Scale-Out).
Node Group: 여러 개의 EC2를 묶어 하나의 그룹으로 관리.
Load Balancer: 사용자의 요청을 여러 개의 서버(EC2)로 분산시켜 부하를 조절.

로드 밸런서(Load Balancer)

줄여서 LB라고 하는데 LB는 트래픽을 여러 개의 서버로 분산하는 역할을 한다.

AWS에서는 ELB(Elastic Load Balancer)라는 서비스를 제공하고 세 가지 유형이 존재한다. CLB, ELB, ALB.

a) CLB(Classic Load Balancer)

b) ELB(Elastic Load Balancer, NetworkLoadBalancer라고도 한다)

c) ALB(Application Load Balancer)

로드 밸런서는 구성 방식에 따라 L4와 L7으로 나뉜다.

L7은 OSI 7 Layer 중 Application Layer를 의미하고 L4는 Transaport Layer를 의미한다.

a) CLB(Classic Load Balancer)

예전 방식으로 현재 AWS에서는 비추천한다고 한다.

L4, L7 모두 지원하지만 최신 기능이 부족하고 비효율적이다.

현재는 ALB & NLB(a.k.a ELB)로 대체되는 중이다.

기존 시스템에서 유지보수가 필요한 경우 사용한다.

b) ELB(Elastic Load Balancer)

L4 네트워크 레벨에서 트래픽을 분산한다.

EC2 인스턴스 자체에 트래픽을 전달해서 애플리케이션 상태와 관련 없다.

HTTP 상태 코드 체크 없이 서버가 죽더라도 트래픽을 그대로 보낸다.

트래픽이 증가하면 자동으로 EC2 인스턴스를 추가하여 확장이 가능하다, 즉 Auto Scaling이 가능하다.

TCP, UDP 기반의 서비스에서 사용하고(웹소켓, DB 연결, 게임 서버 등) IP를 고정해야 하는 경우나 초당 수백만의 요청을 처리하는 고성능 서비스에서 사용합니다.

c) ALB(Application Load Balancer)

L7 어플리케이션 레벨(HTTP, HTTPS)에서 트래픽을 분산한다.

요청을 애플리케이션 레벨에서 분석해서 라우팅을 하는데 앱 상태를 체크해서 정상적인 서버에만 트래픽을 전달한다.

URL, Path, Host Header 기반 라우팅이 가능하다.

세션 유지도 가능하고(Sticky Sessions) 서버 상태를 주기적으로 체크하여 죽어있는 서버로 요청을 보내지 않는다..

주로 REST API 서비스(URL 기반 라우팅이 필요할 때)에서 사용한다.

로그인, 인증/인가 서버 분리할 때나 서버 상태를 체크하여 안정적인 서비스가 필요할 때 사용한다.

보통 온프레미스에서 LB 했다고 하면 ELB를 사용한다는 것이다.

온프레미스 환경에서 L7 애플리케이션 레벨 트래픽을 관리하는 로드 밸런서를 추가하려면 nginx와 같은 Reverse Proxy 서버를 배치해야한다.

HTTP 요청을 HTTPS로 변환하고(Nginx에서 한 번에 SSL 적용) 요청 사이즈를 제한하거나 트래픽을 분리할 수 있다.

ELB를 앱 개발에서 쓰는 이유는 고정 IP가 필요할 때 사용하고 보안 정책이나 방화벽 설정, 외부 시스템 연동 등의 이유로 고정 IP가 필요할 때 ELB를 사용한다.

ALB에서는 도메인을 추가해야하는데 L7 계층에서 동작하므로 도메인 기반 트래픽을 라우팅 가능하다.

ALB 앞에 Route 53(DNS 서비스)를 두어 도메인을 연결한다.

ALB는 클라이언트의 요청을 호스트 기반 또는 경로 기반으로 라우팅한다.

AWS 네트워크 구조 정리

a) AWS 환경

AWS 환경에서는 VPC(Virtual Private Cloud, 가상 프라이빗 클라우드)를 중심으로 다양한 네트워크 리소스가 구성된다.

AWS 클라우드 전체를 의미하며 여러 개의 VPC를 가질 수 있다.

b) VPC(Virtual Private Cloud)

AWS 내에서 가상의 네트워크를 구성하는 단위다.

개발 환경, 운영 환경 등의 용도로 여러 개의 VPC를 구성할 수 있다.

서브넷을 포함하며 IGW와 연결될 수 있다.

c) 서브넷(Subnet)

VPC 내에서 특정한 IP 대역을 가지는 네트워크 단위이다.

Public Subnet과 Private Subnet으로 구분되는데 Public Subnet은 EC2가 퍼블릭 IP를 가지며 외부에서 직접 접근이 가능하다.

Private Subnet은 퍼블릭 IP 없이 내부 네트워크에서만 접근 가능한 서브넷이다.

ALB는 보통 Public Subnet에 배포되는데 Private Subnet에 배포된 서비스는 직접 접근이 불가능하며 NAT Gateway를 통해 외부와 통신하거나 Bastion Host를 통해 접근해야 한다.

d) IGW(Internet Gateway)

VPC가 인터넷과 연결되도록 하는 게이트웨이이다.

퍼블릭 서브넷에 있는 리소스가 인터넷에 접근할 수 있도록 한다.

e) NAT Gateway(Network Address Translation)

private subnet에서 인터넷으로 나갈 때 사용하는 게이트웨이이다.

private subnet에 있는 서버가 인터넷을 통해서 외부 API 등을 호출할 수 있도록 해준다.

public subnet에 위치하며 internet gateway를 통해 인터넷과 연결된다.

f) ALB(Application Load balancer)

주로 Public Subnet에 배포된다.

외부에서 요청을 받아 private subnet에 있는 백엔드 서버로 트래픽을 전달한다.

g) Bastion Server(점프 서버)

보안 상의 이유로 private subnet에 직접 접근할 수 없도록 설정하는 것이 일반적인데 Bastion 서버를 public subnet에 배포하여 SSH 터널링을 통해 private subnet 내의 서버에 접근한다.

h) Node Group

Node Group이란 AWS에서 Kubernetes 클러스터의 노드(EC2 인스턴스)들을 묶어서 관리하는 단위다.

EC2 인스턴스를 관리하는 그룹으로 각 노드는 클러스터의 일부로서 애플리케이션을 실행하는 역할을 한다.

노드는 EC2 인스턴스로 실행되며 여러 개의 Node Group을 만들 수 있다(프론트엔드용, 백엔드용, 배치 작업용)

Public Subnet이나 Private Subnet에 배포할 수 있다.

i) RDS(Amazon Relational Database Server)

RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서버다.

사용자가 직접 데이터베이스 서버를 설정하고 운영할 필요 없이 AWS에서 자동으로 백업, 패치 적용, 장애 복구, 모니터링 등을 관리한다.

RDS는 보통 VPC zone에 속한다. VPC zone은 가용 영역(AZ, Availability Zone)이라고도 하는데 AWS 리전 내에서 물리적으로 분리된 데이터센터이다.

하나의 리전은 여러 개의 AZ로 구성되는데 서울 리전에는 ap-northeast-2a, ap-northeast-2b, ... 와 같은 여러 AZ가 존재한다.

Multi-AZ RDS를 구성하면 하나의 AZ에 문제가 생겨도 자동으로 다른 AZ로 페일 오버가 가능하다.

즉, RDS는 VPC 내의 특정 서브넷에 배포된다.

Redis 같은 third party 역시 VPC zone에 존재한다.

j) 리전(Region)

리전은 AWS의 데이터센터가 위치한 물리적인 지역으로 ap-northeast-2는 서울, us-east-1은 버지니아 등으로 이루어져 있다.

각 리전은 서로 독립적이며 리전 간 네트워크 트래픽은 추가 비용이 발생할 수 있다.

정리하자면 Region > AZ > VPC > Subnet > Node Group > EC2 로 생각하자.

k) S3(Amazon Simple Storage Service)

S3는 AWS에서 제공하는 오브젝트 스토리지 서비스다.

VPC 밖에서 글로벌하게 접근 가능한 스토리지이다.

정적인 파일(이미지, 동영상, 로그 파일, 정적 웹사이트 등)을 저장 및 제공하는 데 사용된다.

데이터는 버킷(Bucket) 단위로 저장되고 S3에 업로드한 파일은 객체 URL을 통해 접근 가능하다.

React 같은 SPA(Single Page Application)의 정적 파일을 S3에 업로드하여 배포할 수 있다.

S3는 기본적으로 정적 웹사이트 호스팅 기능을 제공하여서 index.html을 업로드하면 바로 웹사이트가 동작한다.

다만 도메인이 가독성이 떨어져서 이를 예쁘게 보기 위해 Route 53을 통해 DNS 매핑이 필요하다.

l) 클라우드프론트(CloudFront, AWS CND=Content Delivery Network 서비스)

AWS의 CDN 서비스로 전 세계 여러 지역에 분산된 엣지 로케이션(Edge Location)에서 캐싱하여 빠르게 컨텐츠를 제공한다.

주로 S3, ALB, EC2, API Gateway와 연동하여 사용하는데 한 번 접근한 파일을 캐싱하여 다시 요청하지 않게 하여 비용 절감 및 속도를 향상시킨다.

도메인 캐싱도 가능한데 웹사이트에 접근한 유저가 많을 경우 S3가 아닌 cloud front에서 바로 파일을 다운로드 할 수 있다.

또한 새로운 파일을 배포하면 CloudFront가 기존 브라우저 캐싱을 무시하고 새로운 리소스를 다운로드하여 제공한다.

m) Route 53(AWS DNS 서비스)

Route 53은 AWS에서 제공하는 DNS 관리 서비스로 도메인을 관리하고 이를 S3, ALB, CloudFront 등에 매핑할 수 있다.

Route 53 -> 도메인 요청을 CloudFront로 전달 -> CloudFront가 S3에서 캐싱된 정적 파일 제공

n) 서드파티(Third Party)

AWS에서 제공하는 서비스가 아닌 외부에서 제공하는 서비스를 의미한다.

Redis, Elasticsearch 같은 서비스도 AWS에서 직접 제공하기도 하지만 Third Party로 운영할 수 있다.

Redis 같은 서드파티 서비스는 보통 VPC 내부에서 배포된다.

o) EKS(Amazon Elastic Kubernetes Service)

EKS는 AWS에서 제공하는 관리형 Kubernetes 서비스다.

k8s는 컨테이너화된 애플리케이션을 배포하고 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

EKS는 AWS 환경에서 쉽게 운영할 수 있게 지원하는 서비스다.

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포하고 스케일링, 관리할 수 있도록 해주는 플랫폼이다.

도커와 같은 컨테이너 기술과 함께 사용되고 여러 개의 서버에서 컨테이너를 실행하고 네트워크 및 자원을 관리한다.

EKS는 Kubernetes 클러스터를 쉽게 생성하고 관리할 수 있도록 제공되는 관리형 Kubernetes 서비스로 직접 운영할 필요 없이 AWS가 제어 플레인을 관리해준다.

3. 세션 vs 쿠키

세션

세션은 서버 측에서 관리되는 사용자 정보 저장소이다.

클라이언트가 서버에 요청할 때 세션 ID를 이용해 상태를 유지하는데 세션 정보는 보통 서버의 메모리나 데이터베이스에 저장된다.

세션은 서버 측에서 관리되고 클라이언트는 세션 ID만 가진다.

데이터 크기의 제한이 없고 브라우저를 닫거나 일정 시간이 지나면 세션이 만료된다.

동작 방식은 아래와 같다.

a) 사용자가 로그인하여 서버에서 세션을 생성하고 세션 ID를 클라이언트에게 쿠키로 전달한다.

b) 이후 요청마다 클라이언트는 세션 ID를 포함해 서버에 요청한다.

c) 서버는 세션 ID를 확인하여 해당 사용자의 정보를 유지한다.

쿠키

쿠키는 클라이언트에 저장되는 작은 데이터이다.

사용자의 로그인 정보, 설정, 방문 기록 등을 브라우저에 저장하여 다음 방문 시에도 유지할 수 있도록 한다.

HTTP는 무상태(Stateless) 프로토콜이므로 사용자의 상태를 유지하기 위해 쿠키를 활용한다.

쿠키의 특징은 클라이언트 측에 저장되고 크기가 4KB로 제한되고 만료 기간을 설정할 수 있다.

클라이언트에서 조작이 가능해서 보안에 취약하다.

동작 방식은 아래와 같다.

a) 사용자가 로그인하면 서버가 응답할 때 Set-Cookie 헤더를 포함하여 브라우저에 쿠키를 저장한다.

b) 이후 브라우저는 서버에 요청을 보낼 때 쿠키를 자동으로 포함한다.

c) 서버는 쿠키를 확인하여 사용자를 식별한다.

session_id는 쿠키 값이고 Path는 해당 사이트 전체에서 유효한 예시이고 HttpOnly는 JS에서 접근 불가능하다는 것이고 Secure를 통해서 HTTPS에서만 전송하고 만료를 1시간으로 설정한 것이다.

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; Max-Age=3600

그래서 보통 쿠키는 로그인 유지나 사용자 설정 저장, 방문 기록 저장에 사용하고 세션은 로그인 및 인증 정보 관리, 장바구니 기능에 사용한다.

4. TODO

- 도커 명령어 공부하기

- 도커 파일 작성법 공부하기

멀리 존재하는 TODO

- server랑 redis를 클라우드 환경에 띄우고 client A, B를 띄워서 pub/sub, session 구현해보기

- A가 admin이고 B가 user라고 할 때 A가 api 하나를 날려서 topic/1으로 보내면 서버는 topic/1으로 날라온 요청을 publishing하고 B는 subscribe하고 있다면 라이브하게 데이터를 내려 받는다. B가 보는 화면도 강제로 바꿀 수 있는데 redux 건드려서 변경할 수도 있고 푸시 알람이나 유저 컨트롤도 가능하다. admin은 publishing하고 B는 subscribe하고 B 개수만큼 n 개의 세션을 연결하는데 이런 경우에는 서버를 여러 대로 나눠서 세션을 나누고 redis가 endpoint로 설정된다.