SSL과 TLS의 관계

SSL(Secure Sockets Layer)은 넷스케이프가 1995년에 개발한 암호화 통신 프로토콜이다. 이후 보안 취약점이 발견되어 TLS(Transport Layer Security)로 대체되었다. 현재 사용되는 것은 TLS 1.2와 TLS 1.3이며, SSL 2.0과 3.0은 공식적으로 폐기되었다. 하지만 업계에서는 관례적으로 여전히 SSL 인증서라는 용어를 사용한다. 정확하게는 TLS 인증서이지만, 이 글에서도 통용되는 SSL 인증서라는 표현을 병행한다.

SSL 인증서가 하는 일

SSL 인증서는 두 가지 핵심 기능을 수행한다. 첫째, 서버의 신원을 인증한다. 사용자가 접속한 서버가 진짜 해당 도메인의 소유자가 운영하는 서버인지를 제3자(인증 기관, CA)가 보증하는 것이다. 피싱 사이트나 중간자 공격(MITM)을 방어하는 기반이 된다. 둘째, 통신 내용을 암호화한다. 클라이언트와 서버 사이에 전송되는 모든 데이터를 암호화하여 네트워크 도청자가 내용을 읽을 수 없게 만든다. 로그인 비밀번호, 결제 정보, 개인정보 등 민감한 데이터가 평문으로 노출되는 것을 방지한다.

TLS 핸드셰이크 과정

HTTPS 연결이 수립되는 과정을 TLS 핸드셰이크라고 한다. 클라이언트가 서버에 접속하면 서버가 자신의 SSL 인증서를 제시한다. 클라이언트는 해당 인증서가 신뢰할 수 있는 CA에 의해 서명되었는지 검증한다. 검증이 통과되면 양측이 대칭 키를 생성하기 위한 키 교환을 수행한다. TLS 1.3에서는 이 과정이 1-RTT(Round Trip Time)로 최적화되어 기존 TLS 1.2의 2-RTT보다 빠르게 연결이 수립된다. 핸드셰이크가 완료되면 이후 모든 통신은 대칭 키로 암호화된다.

인증서의 종류

인증서는 검증 수준에 따라 DV, OV, EV로 나뉜다. DV(Domain Validation)는 도메인 소유권만 확인하는 가장 기본적인 인증서다. 발급이 빠르고 무료(Let’s Encrypt)부터 저가까지 다양하다. OV(Organization Validation)는 도메인 소유권에 더해 조직의 실체를 확인한다. 기업 웹사이트에서 신뢰도를 높이기 위해 사용한다. EV(Extended Validation)는 가장 엄격한 검증을 거치며, 과거에는 브라우저 주소창에 녹색으로 기업명이 표시되었으나 현재 대부분의 브라우저에서는 이 시각적 구분이 제거되었다.

Let’s Encrypt와 자동 갱신

Let’s Encrypt는 ISRG(Internet Security Research Group)가 운영하는 무료 CA다. DV 인증서를 무료로 발급하며, ACME 프로토콜을 통해 인증서 발급과 갱신을 자동화할 수 있다. Certbot 클라이언트를 설치하고 cron에 갱신 스크립트를 등록해두면 90일 단위로 자동 갱신되어 인증서 만료로 인한 서비스 장애를 방지할 수 있다. 개인 서버와 소규모 서비스에서는 Let’s Encrypt가 사실상 표준이다.

HTTPS가 필수인 이유

구글 크롬은 HTTPS가 적용되지 않은 사이트에 안전하지 않음 경고를 표시한다. SEO 관점에서도 구글은 HTTPS 적용 여부를 검색 순위 요소로 반영한다. HTTP/2와 HTTP/3 프로토콜은 HTTPS를 전제로 동작하므로, 최신 웹 성능 최적화의 혜택을 받으려면 SSL 인증서 적용이 필수다.

SSL인증서 #TLS #HTTPS #LetsEncrypt #보안인증서 #TLS핸드셰이크 #서버보안 #DV인증서 #Certbot #웹보안

CDN의 기본 개념

CDN(Content Delivery Network)은 전 세계 여러 지역에 분산 배치된 엣지 서버(Edge Server)를 통해 콘텐츠를 사용자와 가장 가까운 위치에서 전달하는 네트워크 인프라다. 원본 서버(Origin Server)가 한국에 있을 때, 미국 사용자가 접속하면 태평양을 건너는 물리적 거리 때문에 응답이 느려진다. CDN은 콘텐츠의 복제본을 미국 내 엣지 서버에 미리 저장해두고, 미국 사용자의 요청을 해당 엣지 서버에서 처리한다. 물리적 거리에 의한 지연(Latency)을 최소화하는 것이 CDN의 핵심 목적이다.

CDN의 작동 원리

사용자가 CDN이 적용된 웹사이트에 접속하면, DNS 수준에서 사용자의 지리적 위치를 판단하여 가장 가까운 엣지 서버의 IP를 반환한다. 엣지 서버에 요청된 콘텐츠가 캐싱되어 있으면 즉시 응답한다. 캐시에 없는 경우 엣지 서버가 원본 서버에 요청하여 콘텐츠를 가져오고, 이를 로컬에 캐싱한 뒤 사용자에게 전달한다. 이후 같은 콘텐츠에 대한 요청은 캐시에서 처리하므로 원본 서버에 부하가 가지 않는다.

CDN이 전달하는 콘텐츠

CDN은 주로 정적 콘텐츠(Static Content)를 캐싱하여 전달한다. 이미지, CSS, JavaScript 파일, 폰트, 동영상 스트리밍 데이터가 여기에 해당한다. 이 파일들은 내용이 자주 변하지 않으므로 캐싱 효과가 높다. 최근에는 동적 콘텐츠에 대해서도 CDN이 역할을 확대하고 있다. TCP 연결 최적화, 경로 최적화, 원본 서버와의 영속 연결(Persistent Connection) 유지를 통해 동적 요청의 응답 속도도 개선한다.

CDN의 부가 기능

현대 CDN은 단순 캐싱을 넘어 다양한 부가 기능을 제공한다. DDoS 방어는 CDN의 대표적인 보안 기능이다. 전 세계에 분산된 엣지 서버가 공격 트래픽을 흡수하여 원본 서버를 보호한다. WAF(Web Application Firewall) 기능을 내장하여 SQL 인젝션, XSS 같은 애플리케이션 레벨 공격도 차단한다. SSL/TLS 인증서를 엣지에서 관리하여 HTTPS를 간편하게 적용할 수 있다. 이미지 최적화 기능은 사용자 디바이스에 따라 이미지 포맷(WebP, AVIF)과 해상도를 자동 변환하여 전송 용량을 줄인다.

주요 CDN 서비스

Cloudflare는 무료 플랜을 제공하여 개인 블로그나 소규모 서비스도 CDN을 쉽게 도입할 수 있다. DDoS 방어와 DNS 관리 기능이 강력하다. AWS CloudFront는 AWS 생태계와 긴밀하게 통합되어

모니터링 없는 서버 운영은 계기판 없는 운전이다

서버가 지금 정상인지, 자원이 얼마나 남았는지, 언제 문제가 터질지를 실시간으로 파악하는 것이 서버 모니터링이다. 모니터링 없이 서버를 운영하면 장애가 터지고 나서야 상황을 인지하게 된다. 사용자 불만 접수가 장애 알림보다 먼저 도착하는 상황은 서버 관리자에게 최악의 시나리오다. 모니터링은 장애를 사전에 감지하고, 성능 추이를 분석하며, 용량 계획의 근거 데이터를 제공하는 서버 운영의 핵심 인프라다.

무엇을 모니터링하는가

서버 모니터링의 대상은 크게 네 가지 계층으로 나뉜다. 첫째, 인프라 메트릭이다. CPU 사용률, 메모리 점유율, 디스크 사용량과 I/O 처리량, 네트워크 트래픽이 기본이다. 둘째, 애플리케이션 메트릭이다. HTTP 요청 수, 응답 시간(Latency), 에러율(Error Rate), 처리량(Throughput)이 핵심 지표다. 셋째, 로그 모니터링이다. 시스템 로그와 애플리케이션 로그에서 에러 패턴을 실시간으로 감지한다. 넷째, 가용성 모니터링이다. 서비스가 외부에서 정상 접속 가능한지를 주기적으로 확인하는 업타임 체크다.

핵심 도구

오픈소스 모니터링 도구의 표준 조합은 Prometheus와 Grafana다. Prometheus는 시계열 데이터베이스(TSDB) 기반의 메트릭 수집 시스템이다. 각 서버에 설치된 Exporter(node_exporter 등)가 시스템 메트릭을 노출하면, Prometheus가 주기적으로 풀(Pull) 방식으로 수집한다. 수집된 데이터는 PromQL이라는 쿼리 언어로 조회한다. Grafana는 Prometheus에서 수집된 데이터를 시각화하는 대시보드 도구다. CPU, 메모리, 디스크 사용량을 실시간 그래프로 표시하고, 시간대별 추이를 한눈에 파악할 수 있다.

알림 설정

모니터링 데이터를 수집하는 것만으로는 부족하다. 임계치를 넘으면 즉시 알림을 받아야 장애를 사전에 대응할 수 있다. Prometheus의 Alertmanager를 사용하면 특정 조건이 충족될 때 Slack, 이메일, PagerDuty, 웹훅 등으로 알림을 발송할 수 있다. 예를 들어 CPU 사용률이 5분 이상 90%를 넘으면 Slack 채널에 경고 메시지를 보내는 식이다. 알림 규칙을 잘 설계하면 새벽에 터지는 장애도 즉시 인지할 수 있다.

APM과 분산 추적

마이크로서비스 환경에서는 하나의 요청이 여러 서비스를 거치므로 어느 구간에서 병목이 발생하는지 추적하기 어렵다. APM(Application Performance Monitoring) 도구가 이 문제를 해결한다. Datadog, New Relic, Elastic APM이 대표적이다. 분산 추적(Distributed Tracing)은 요청의 전체 경로를 trace ID로 연결하여 각 서비스 구간의 처리 시간을 시각화한다. Jaeger와 Zipkin이 오픈소스 분산 추적 도구의 대표다.

모니터링 설계 원칙

구글의 SRE(Site Reliability Engineering) 팀이 제안한 골든 시그널(Golden Signals) 네 가지를 기억해두면 모니터링 설계의 기준이 된다. Latency(응답 시간), Traffic(요청량), Errors(에러율), Saturation(자원 포화도)이다. 이 네 가지 지표를 대시보드에 배치하고 각각에 알림을 설정해두면 서버 상태를 종합적으로 파악할 수 있다.

서버모니터링 #Prometheus #Grafana #APM #알림설정 #골든시그널 #SRE #Datadog #서버운영 #메트릭수집

Docker가 등장한 배경

개발자의 로컬 환경에서는 잘 동작하던 애플리케이션이 서버에 배포하면 오류가 나는 상황은 매우 흔하다. 운영체제 버전, 라이브러리 버전, 환경 변수, 디렉토리 구조 등 환경 차이가 원인이다. Docker는 이 문제를 근본적으로 해결하기 위해 등장했다. 애플리케이션과 그 실행에 필요한 모든 의존성을 하나의 패키지(컨테이너)로 묶어 어떤 환경에서든 동일하게 동작하도록 보장한다.

이미지와 컨테이너

Docker의 핵심 개념은 이미지(Image)와 컨테이너(Container)다. 이미지는 애플리케이션 실행에 필요한 코드, 런타임, 라이브러리, 설정 파일을 모두 포함한 읽기 전용 템플릿이다. 컨테이너는 이 이미지를 기반으로 실제로 실행 중인 인스턴스다. 하나의 이미지에서 여러 개의 컨테이너를 동시에 띄울 수 있다. 클래스와 객체의 관계에 비유하면 이해가 쉽다. 이미지가 클래스, 컨테이너가 그 클래스로 생성된 객체다.

Dockerfile

Docker 이미지를 만드는 설계도가 Dockerfile이다. 베이스 이미지를 지정하고(FROM), 필요한 패키지를 설치하고(RUN), 소스 코드를 복사하고(COPY), 실행 명령어를 정의하는(CMD) 순서로 작성한다. Dockerfile을 docker build 명령어로 빌드하면 이미지가 생성된다. 이 Dockerfile을 Git에 함께 관리하면 누구든 동일한 이미지를 재현할 수 있어 환경 일관성이 보장된다.

Docker Hub와 레지스트리

Docker Hub는 Docker 이미지의 공개 저장소다. nginx, mysql, python, node 같은 공식 이미지를 누구나 무료로 다운로드(pull)할 수 있다. docker pull nginx 한 줄이면 최신 Nginx 이미지를 로컬에 받아올 수 있다. 기업 환경에서는 사내 전용 이미지를 보관하기 위해 프라이빗 레지스트리(Harbor, AWS ECR, GCP Artifact Registry)를 운영한다.

Docker Compose

실제 서비스는 단일 컨테이너로 동작하지 않는 경우가 많다. 웹 애플리케이션, 데이터베이스, 캐시 서버가 함께 동작해야 한다. Docker Compose는 여러 컨테이너의 설정을 docker-compose.yml 파일 하나에 정의하고, docker compose up 한 줄로 전체 스택을 한꺼번에 실행할 수 있게 해준다. 개발 환경에서 복잡한 멀티 컨테이너 구성을 간편하게 관리하는 도구로 사실상 필수다.

Docker의 한계와 오케스트레이션

Docker는 단일 호스트에서 컨테이너를 관리하는 도구다. 서버가 여러 대로 늘어나면 어떤 서버에 어떤 컨테이너를 배치할지, 컨테이너가 죽으면 어떻게 재시작할지, 트래픽 증가 시 컨테이너를 몇 개까지 늘릴지를 자동으로 판단하는 시스템이 필요하다. 이 역할을 하는 것이 컨테이너 오케스트레이션 도구이며, Kubernetes가 사실상의 표준이다. Docker가 컨테이너를 만들고 실행하는 엔진이라면, Kubernetes는 그 컨테이너들을 클러스터 규모에서 관리하는 지휘자다.

Docker #컨테이너 #Dockerfile #DockerCompose #DockerHub #컨테이너가상화 #DevOps #Kubernetes #서버배포 #이미지빌드

같은 가상화인데 무엇이 다른가

가상머신(VM)과 컨테이너는 모두 하나의 물리 서버에서 여러 격리된 환경을 구동하는 가상화 기술이다. 하지만 격리의 방식과 수준이 근본적으로 다르다. 이 차이를 이해하면 어떤 상황에 VM을 쓰고, 어떤 상황에 컨테이너를 쓰는 것이 적합한지 판단할 수 있다.

가상머신의 구조

VM은 하이퍼바이저 위에 완전한 운영체제(게스트 OS)를 포함한다. 각 VM은 자체 커널, 시스템 라이브러리, 애플리케이션을 독립적으로 갖추고 있다. 하이퍼바이저가 물리 하드웨어를 추상화하여 각 VM에 가상 CPU, 가상 메모리, 가상 디스크를 제공한다. 격리 수준이 매우 높아 하나의 VM에서 커널 패닉이 발생해도 다른 VM에 영향을 주지 않는다. 다만 각 VM마다 전체 OS를 포함하므로 디스크 점유량이 크고(수 GB~수십 GB), 부팅 시간이 수십 초에서 수 분까지 걸린다.

컨테이너의 구조

컨테이너는 호스트 OS의 커널을 공유한다. 리눅스 커널의 namespaces와 cgroups 기능을 활용하여 프로세스 단위의 격리를 구현한다. namespaces는 프로세스가 볼 수 있는 자원의 범위(파일 시스템, 네트워크, PID 등)를 분리하고, cgroups는 각 컨테이너가 사용할 수 있는 CPU, 메모리, I/O의 양을 제한한다. 게스트 OS가 없으므로 컨테이너 이미지는 수십 MB 수준으로 가볍고, 시작 시간도 수 초 이내다. 성능 비교 VM은 하드웨어를 가상화하는 오버헤드가 존재한다. CPU 가상화는 VT-x, AMD-V 같은 하드웨어 지원으로 오버헤드가 크게 줄었지만, I/O 가상화에서는 여전히 네이티브 대비 성능 저하가 발생한다. 컨테이너는 커널을 직접 공유하므로 가상화 오버헤드가 거의 없다. 네이티브에 근접하는 성능을 보여주며, 같은 물리 서버에서 VM보다 훨씬 많은 수의 컨테이너를 구동할 수 있다. 보안과 격리 수준 격리 수준은 VM이 월등히 높다. VM은 각자 독립된 커널을 사용하므로 하나의 VM이 해킹당해도 다른 VM의 커널에 접근할 수 없다. 컨테이너는 커널을 공유하므로 커널 취약점이 발견되면 모든 컨테이너가 동시에 위험에 노출된다. 이 때문에 멀티테넌트 환경에서 서로 신뢰할 수 없는 워크로드를 격리할 때는 VM이 더 안전한 선택이다. gVisor나 Kata Containers 같은 프로젝트가 컨테이너의 격리 수준을 높이려는 시도를 하고 있지만, VM 수준의 격리에는 아직 못 미친다. 실무에서의 선택 기준 마이크로서비스 아키텍처, CI/CD 파이프라인, 빠른 스케일링이 필요한 환경에서는 컨테이너가 압도적으로 유리하다. 이미지 빌드, 배포, 롤백 사이클이 빠르고, Kubernetes 같은 오케스트레이션 도구와 결합하면 수백 개의 컨테이너를 자동으로 관리할 수 있다. 서로 다른 OS를 구동해야 하거나, 높은 보안 격리가 필수인 환경에서는 VM이 적합하다. 실무에서는 두 기술을 배타적으로 선택하기보다 VM 위에서 컨테이너를 운영하는 구조도 흔하다. #컨테이너 #가상머신 #Docker #VM #하이퍼바이저 #namespaces #cgroups #Kubernetes #서버가상화 #클라우드

왜 로드밸런서가 필요한가

서버 한 대가 처리할 수 있는 요청 수에는 한계가 있다. 트래픽이 늘어나면 서버를 여러 대로 늘려야 하는데, 이때 문제가 생긴다. 클라이언트가 어떤 서버로 요청을 보내야 할지 어떻게 결정하는가. 특정 서버에만 요청이 몰리면 그 서버는 과부하로 다운되고, 나머지 서버는 놀게 된다. 로드밸런서(Load Balancer)는 이 문제를 해결하는 장치다. 들어오는 요청을 여러 서버에 균등하게 분배하여 각 서버의 부하를 적정 수준으로 유지한다.

L4 로드밸런서와 L7 로드밸런서

로드밸런서는 동작하는 네트워크 계층에 따라 L4와 L7로 나뉜다. L4 로드밸런서는 전송 계층(TCP/UDP)에서 동작한다. 패킷의 출발지 IP, 목적지 IP, 포트 번호만 보고 분배 대상 서버를 결정한다. 패킷 내부의 데이터 내용은 검사하지 않으므로 처리 속도가 빠르다. L7 로드밸런서는 애플리케이션 계층(HTTP)에서 동작한다. URL 경로, HTTP 헤더, 쿠키, 호스트 이름 등 요청의 내용을 분석하여 분배 규칙을 세밀하게 설정할 수 있다. 이미지 요청은 이미지 전용 서버로, API 요청은 API 서버로 보내는 식의 콘텐츠 기반 라우팅이 가능하다.

분배 알고리즘

라운드 로빈(Round Robin)은 가장 단순한 방식으로 서버 목록을 순서대로 돌아가며 요청을 배정한다. 모든 서버의 성능이 동일할 때 효과적이다. 가중 라운드 로빈(Weighted Round Robin)은 서버별 성능 차이에 가중치를 부여하여 성능이 높은 서버에 더 많은 요청을 배정한다. 최소 연결(Least Connection) 방식은 현재 활성 연결 수가 가장 적은 서버에 새 요청을 보낸다. 요청 처리 시간이 들쑥날쑥한 환경에서 유리하다. IP 해시(IP Hash) 방식은 클라이언트 IP를 해싱하여 항상 같은 서버로 연결하므로 세션 유지가 필요한 서비스에 적합하다.

헬스체크

로드밸런서의 핵심 기능 중 하나가 헬스체크(Health Check)다. 백엔드 서버들에 주기적으로 상태 확인 요청을 보내 정상 응답이 돌아오는지 확인한다. 응답이 없거나 에러 코드를 반환하는 서버는 분배 대상에서 자동으로 제외하고, 복구되면 다시 포함시킨다. 이 자동 장애 탐지와 제거 기능이 서비스의 가용성을 보장하는 핵심 메커니즘이다.

하드웨어와 소프트웨어 로드밸런서

전통적으로 F5 BIG-IP, Citrix ADC 같은 전용 하드웨어 장비가 대규모 트래픽 환경에서 사용되었다. 높은 성능과 안정성을 제공하지만 가격이 수천만 원에서 수억 원대다. 소프트웨어 로드밸런서로는 Nginx, HAProxy가 대표적이며, 오픈소스로 무료 사용이 가능하다. 클라우드 환경에서는 AWS ALB/NLB, GCP Cloud Load Balancing 같은 매니지드 서비스가 하드웨어 관리 부담 없이 로드밸런싱을 제공한다.

로드밸런서 #로드밸런싱 #L4 #L7 #라운드로빈 #HAProxy #Nginx #헬스체크 #서버확장 #트래픽분산

프록시의 기본 개념

프록시(Proxy)는 대리인이라는 뜻이다. 프록시 서버는 클라이언트와 목적지 서버 사이에 위치하여 요청과 응답을 중계하는 중간 서버다. 클라이언트가 직접 목적지 서버에 연결하는 대신, 프록시 서버를 거쳐 통신하는 구조다. 이 중간 단계가 왜 필요한지 의문이 들 수 있지만, 프록시는 보안, 캐싱, 접근 제어, 익명성 확보 등 다양한 목적으로 활용되는 핵심 네트워크 인프라다.

포워드 프록시

포워드 프록시(Forward Proxy)는 클라이언트 측에 위치하여 클라이언트의 요청을 대신 전달하는 프록시다. 기업 네트워크에서 직원들의 인터넷 접속을 관리할 때 대표적으로 사용된다. 모든 웹 요청이 포워드 프록시를 경유하도록 설정하면, 관리자는 특정 사이트 접속을 차단하거나, 접속 로그를 기록하거나, 대역폭을 제한할 수 있다. 클라이언트의 실제 IP를 목적지 서버에 노출하지 않아 익명성을 확보하는 용도로도 사용된다. Squid가 대표적인 오픈소스 포워드 프록시 소프트웨어다.

리버스 프록시

리버스 프록시(Reverse Proxy)는 서버 측에 위치하여 외부 요청을 내부 서버로 분배하는 프록시다. 포워드 프록시가 클라이언트를 보호한다면, 리버스 프록시는 서버를 보호한다. 클라이언트는 리버스 프록시의 IP만 알고, 실제 백엔드 서버의 존재와 IP를 알 수 없다. Nginx와 HAProxy가 리버스 프록시로 가장 널리 사용된다. 실무에서 리버스 프록시가 수행하는 핵심 역할은 다음과 같다. 로드밸런싱으로 트래픽을 여러 백엔드 서버에 분산한다. SSL 종료(SSL Termination)를 처리하여 백엔드 서버의 암호화 부담을 제거한다. 정적 파일을 캐싱하여 백엔드 서버 부하를 줄인다. 요청 필터링으로 악의적인 트래픽을 사전에 차단한다.

캐싱 프록시

프록시 서버는 자주 요청되는 콘텐츠를 로컬에 캐싱하여 동일한 요청에 대해 목적지 서버까지 가지 않고 바로 응답할 수 있다. 기업 내부에서 수백 명이 동일한 OS 업데이트 파일을 다운로드할 때, 캐싱 프록시가 첫 번째 다운로드 결과를 저장해두면 이후 요청은 내부 네트워크에서 즉시 처리된다. 외부 대역폭 사용량이 줄고 응답 속도가 빨라진다.

투명 프록시

투명 프록시(Transparent Proxy)는 클라이언트가 프록시의 존재를 인식하지 못하는 상태에서 동작하는 프록시다. 네트워크 장비 수준에서 트래픽을 가로채어 프록시로 리다이렉트하는 방식이다. ISP가 콘텐츠 필터링이나 캐싱 목적으로 사용하기도 하고, 공공 와이파이에서 접속 인증 페이지(Captive Portal)를 띄우는 데도 투명 프록시가 활용된다.

프록시와 VPN의 차이

프록시와 VPN은 모두 중간 서버를 거치는 구조이지만 동작 계층이 다르다. 프록시는 애플리케이션 레벨에서 특정 프로토콜(HTTP 등)의 트래픽만 중계한다. VPN은 네트워크 레벨에서 모든 트래픽을 암호화된 터널로 감싼다. 보안 수준은 VPN이 높고, 특정 서비스의 캐싱과 접근 제어에는 프록시가 적합하다.

프록시서버 #리버스프록시 #포워드프록시 #Nginx #HAProxy #캐싱프록시 #네트워크보안 #로드밸런싱 #VPN #서버인프라

서버 가상화의 개념

서버 가상화(Server Virtualization)는 하나의 물리 서버 위에 여러 개의 독립된 가상 서버(Virtual Machine, VM)를 구동하는 기술이다. 물리 서버 한 대가 CPU, 메모리, 디스크 자원을 충분히 갖추고 있어도 단일 OS만 실행하면 자원 활용률이 낮은 경우가 많다. 가상화는 이 유휴 자원을 논리적으로 분할하여 여러 OS와 서비스를 동시에 운영함으로써 하드웨어 투자 대비 효율을 극대화한다.

하이퍼바이저란

하이퍼바이저(Hypervisor)는 물리 하드웨어와 가상 머신 사이에서 자원을 분배하고 격리하는 소프트웨어 계층이다. 각 VM은 자신이 독립된 물리 서버 위에서 동작하고 있다고 인식하지만, 실제로는 하이퍼바이저가 CPU 시간, 메모리 공간, 디스크 I/O, 네트워크 대역폭을 중재하고 있다. 하이퍼바이저의 핵심 역할은 격리(Isolation)다. 하나의 VM에서 장애가 발생해도 같은 물리 서버 위의 다른 VM에 영향을 주지 않는다.

Type 1 하이퍼바이저

Type 1(베어메탈) 하이퍼바이저는 물리 하드웨어 위에 직접 설치되어 동작한다. 호스트 OS가 따로 존재하지 않으며, 하이퍼바이저 자체가 하드웨어를 제어한다. VMware ESXi, Microsoft Hyper-V(Server Core), Citrix Hypervisor(구 XenServer), KVM이 대표적이다. KVM은 특이하게 리눅스 커널 자체가 하이퍼바이저 역할을 겸하는 구조로, 리눅스 커널 모듈로 동작하면서 각 VM을 일반 리눅스 프로세스로 관리한다. Type 1은 하드웨어에 직접 접근하므로 오버헤드가 적고 성능이 우수하여 서버 환경의 프로덕션 가상화에 사용된다.

Type 2 하이퍼바이저

Type 2(호스팅) 하이퍼바이저는 기존 운영체제(호스트 OS) 위에 애플리케이션으로 설치된다. VirtualBox, VMware Workstation, Parallels Desktop이 대표적이다. 호스트 OS를 거쳐야 하므로 Type 1 대비 성능 오버헤드가 크다. 서버 프로덕션 환경보다는 개발자의 로컬 테스트 환경, 교육 목적에 주로 사용된다.

가상화가 가져온 변화

가상화 이전에는 서비스 하나당 물리 서버 한 대를 배정하는 것이 일반적이었다. 보안 격리와 장애 격리를 위해 불가피한 선택이었지만, 서버 자원 활용률이 평균 10~15%에 불과했다. 가상화 도입 후 하나의 물리 서버에서 수십 개의 VM을 운영할 수 있게 되면서 자원 활용률이 60~80%까지 올라갔다. 서버 구매 비용, 전력 소모, 데이터센터 공간이 획기적으로 절감되었다. 또한 VM은 스냅샷 생성, 복제, 마이그레이션이 가능하므로 운영 유연성이 비약적으로 향상되었다.

가상화와 클라우드의 관계

퍼블릭 클라우드의 기반 기술이 바로 서버 가상화다. AWS EC2 인스턴스를 생성하면 그것은 아마존 데이터센터의 물리 서버 위에서 하이퍼바이저가 할당한 VM이다. 사용자는 물리 서버의 존재를 인식할 필요 없이 VM을 생성, 삭제, 확장할 수 있다. 가상화가 없었다면 클라우드 컴퓨팅이라는 개념 자체가 성립하지 않았을 것이다.

서버가상화 #하이퍼바이저 #VMware #KVM #VirtualBox #가상머신 #Type1 #Type2 #클라우드 #서버운영

SSH의 정의

SSH(Secure Shell)는 네트워크를 통해 원격 서버에 안전하게 접속하기 위한 암호화 통신 프로토콜이다. 기본 포트는 22번이며, 클라이언트와 서버 사이의 모든 통신 내용을 암호화하여 도청과 변조를 방지한다. 서버 관리자가 데이터센터에 직접 가지 않고도 자신의 노트북에서 서버를 제어할 수 있는 것은 SSH 덕분이다. 리눅스 서버 운영의 가장 기본적인 도구이자 관문이다.

SSH 이전의 세계

SSH가 등장하기 전에는 Telnet이라는 프로토콜이 원격 접속에 사용되었다. 문제는 Telnet이 데이터를 평문(Plaintext)으로 전송한다는 점이다. 로그인 시 입력하는 아이디와 비밀번호, 이후 실행하는 모든 명령어와 출력 결과가 암호화 없이 네트워크를 통해 전달된다. 같은 네트워크에서 패킷 스니핑 도구를 사용하면 이 모든 내용을 그대로 볼 수 있다. SSH는 1995년 핀란드 헬싱키 공대의 Tatu Ylonen이 이 보안

RAID의 기본 개념

RAID(Redundant Array of Independent Disks)는 여러 개의 물리 디스크를 하나의 논리적 장치로 묶어 데이터 안정성이나 성능을 향상시키는 기술이다. 서버 환경에서 디스크 한 대가 고장 나면 그 위에 저장된 데이터는 전부 소실된다. RAID는 이 단일 장애점(Single Point of Failure)을 제거하기 위해 설계되었다. 디스크를 묶는 방식에 따라 여러 레벨로 나뉘며, 각 레벨마다 성능, 안정성, 용량 효율의 트레이드오프가 다르다.

RAID 0 스트라이핑

데이터를 여러 디스크에 분산 저장하는 방식이다. 2개 디스크에 데이터를 번갈아 기록하므로 읽기와 쓰기 속도가 이론상 2배로 향상된다. 하지만 중복 저장이 전혀 없기 때문에 디스크 하나만 고장 나도 전체 데이터가 손실된다. 안정성이 0이므로 서버 환경에서는 단독 사용을 권장하지 않는다. 영상 편집 같은 임시 작업용 고속 스토리지에 제한적으로 사용된다.

RAID 1 미러링

동일한 데이터를 두 개의 디스크에 동시에 기록하는 방식이다. 한쪽 디스크가 고장 나도 다른 쪽에 완전한 복제본이 있으므로 데이터 손실 없이 운영을 지속할 수 있다. 읽기 성능은 두 디스크에서 병렬 읽기가 가능하므로 향상되지만, 전체 용량의 50%만 실사용 가능하다. 2TB 디스크 2개를 묶어도 사용 가능 용량은 2TB다. OS 디스크나 중요 데이터베이스 볼륨에 많이 적용한다.

RAID 5 패리티 분산

최소 3개 디스크가 필요하며, 데이터와 패리티 정보를 모든 디스크에 분산 저장한다. 패리티란 나머지 디스크의 데이터를 복원할 수 있는 오류 정정 정보다. 디스크 하나가 고장 나면 나머지 디스크의 데이터와 패리티를 조합하여 손실 데이터를 재건(Rebuild)할 수 있다. 용량 효율이 높아 N개 디스크 중 N-1개 분량을 실사용할 수 있다. 서버 환경에서 가장 보편적으로 사용되는 RAID 레벨이다. 다만 리빌드 중에 추가 디스크 고장이 발생하면 전체 데이터가 소실되는 위험이 있다.

RAID 6과 RAID 10

RAID 6은 RAID 5에 패리티 블록을 하나 더 추가하여 동시에 2개 디스크 고장까지 견딜 수 있다.