왜 성능 테스트를 하는가

서비스를 오픈하기 전에 서버가 예상 트래픽을 감당할 수 있는지 확인하지 않으면, 런칭 당일 서버가 다운되는 사고가 발생한다. 성능 테스트는 서버의 처리 능력 한계를 사전에 파악하고, 병목 지점을 찾아 개선하기 위한 과정이다. 서버가 초당 몇 개의 요청을 처리할 수 있는지, 동시 접속자가 몇 명까지 올라가면 응답 시간이 급격히 느려지는지, 어느 지점에서 서버가 멈추는지를 측정한다.

성능 테스트의 유형

부하 테스트(Load Test)는 예상 트래픽 수준에서 서버가 정상적으로 동작하는지 확인하는 테스트다. 목표 동시 접속자 수와 요청량을 설정하고 일정 시간 동안 부하를 유지하면서 응답 시간, 에러율, 처리량을 측정한다. 스트레스 테스트(Stress Test)는 서버의 한계를 찾기 위해 부하를 점진적으로 증가시키는 테스트다. 서버가 정상 동작하는 최대 부하점(Breaking Point)을 파악하는 것이 목적이다. 스파이크 테스트(Spike Test)는 갑자기 트래픽이 폭증하는 상황을 시뮬레이션한다. 이벤트 오픈, 뉴스 바이럴 같은 순간적인 트래픽 급증에 서버가 어떻게 반응하는지 확인한다. 지구력 테스트(Soak Test)는 장시간에 걸쳐 일정 부하를 유지하면서 메모리 누수나 자원 고갈 같은 시간 의존적 문제를 탐지한다.

핵심 지표

성능 테스트에서 반드시 측정하는 지표가 있다. 처리량(Throughput)은 서버가 단위 시간당 처리하는 요청 수다. 보통 RPS(Requests Per Second)로 표현한다. 응답 시간(Response Time)은 요청을 보낸 시점부터 응답을 받는 시점까지의 시간이다. 평균값보다 95 퍼센타일, 99 퍼센타일 값이 더 중요하다. 평균은 정상이어도 상위 1% 사용자의 응답 시간이 10초를 넘으면 체감 품질이 나쁘다. 에러율(Error Rate)은 전체 요청 중 실패한 요청의 비율이다. 부하가 증가할수록 에러율이 급증하는 지점이 서버의 처리 한계다. 동시 접속자 수(Concurrent Users)는 동시에 서버와 통신하고 있는 클라이언트의 수다.

주요 성능 테스트 도구

Apache JMeter는 가장 널리 사용되는 오픈소스 성능 테스트 도구다. GUI 기반으로 테스트 시나리오를 설계하고, HTTP, HTTPS, JDBC, FTP 등 다양한 프로토콜을 지원한다. 복잡한 시나리오(로그인 후 특정 페이지 접근)를 구성할 수 있어 실제 사용자 행동을 모사하기 좋다. k6은 Grafana Labs가 개발한 현대적인 성능 테스트 도구다. JavaScript로 테스트 스크립트를 작성하며, CLI 기반으로 CI/CD 파이프라인에 통합하기 쉽다. Locust는 Python 기반 도구로, 테스트 코드를 Python으로 작성하므로 개발자에게 진입 장벽이 낮다. ab(Apache Bench)는 간단한 HTTP 성능 테스트에 사용되며, 명령어 한 줄로 빠르게 기초 성능을 측정할 수 있다.

테스트 결과 분석과 대응

성능 테스트 결과에서 병목이 발견되면 원인을 분석하여 대응한다. CPU가 병목이면 코드 최적화나 서버 증설을 검토한다. 메모리가 병목이면 캐싱 전략을 개선하거나 메모리를 증설한다. 디스크 I/O가 병목이면 SSD로 교체하거나 인덱스를 최적화한다. 네트워크가 병목이면 CDN 도입이나 대역폭 증설을 고려한다. 성능 테스트는 일회성이 아니라 코드 변경, 인프라 변경 시마다 반복 수행하는 것이 원칙이다.

성능테스트 #부하테스트 #JMeter #k6 #Locust #RPS #서버성능 #스트레스테스트 #병목분석 #서버운영

포트의 개념

네트워크 통신에서 IP 주소가 건물의 주소라면, 포트(Port)는 그 건물 안의 호수다. 하나의 서버(IP 주소)에서 여러 서비스가 동시에 동작할 수 있는 이유는 각 서비스가 서로 다른 포트 번호를 사용하기 때문이다. 웹서버는 80번(HTTP), 443번(HTTPS), SSH는 22번, 데이터베이스는 3306번(MySQL), 5432번(PostgreSQL)을 기본으로 사용한다. 클라이언트가 서버에 접속할 때 IP 주소와 포트 번호를 함께 지정하면, 운영체제가 해당 포트에서 대기 중인 프로세스에 요청을 전달한다.

포트 번호의 구분

포트 번호는 0부터 65535까지 총 65536개가 존재하며, 세 구간으로 나뉜다. 0~1023번은 잘 알려진 포트(Well-Known Ports)로 주요 서비스에 국제적으로 예약되어 있다. HTTP(80), HTTPS(443), FTP(21), SSH(22), DNS(53), SMTP(25)가 이 범위에 속한다. 리눅스에서 이 범위의 포트를 사용하려면 root 권한이 필요하다. 1024~49151번은 등록된 포트(Registered Ports)로 특정 애플리케이션이 등록하여 사용한다. MySQL(3306), PostgreSQL(5432), Redis(6379)가 여기에 속한다. 49152~65535번은 동적 포트(Dynamic Ports)로 클라이언트가 서버에 접속할 때 임시로 할당되는 포트다.

리스닝 상태 확인

서버에서 현재 어떤 포트가 열려 있고 어떤 프로세스가 사용하고 있는지 확인하는 것은 보안 관리의 기본이다. ss -tlnp 명령어는 현재 TCP 리스닝 상태의 포트와 해당 프로세스를 보여준다. 과거에는 netstat이 사용되었지만, 최신 배포판에서는 ss가 더 빠르고 정보가 풍부하다. 출력 결과에서 0.0.0.0으로 바인딩된 포트는 모든 네트워크 인터페이스에서 접속을 허용한다는 의미이고, 127.0.0.1로 바인딩된 포트는 로컬에서만 접근 가능하다.

포트 보안 관리

서버에서 불필요한 포트를 열어두는 것은 공격 표면을 넓히는 행위다. 방화벽에서 필요한 포트만 명시적으로 허용하고 나머지는 전부 차단하는 화이트리스트 방식이 원칙이다. UFW를 사용한다면 ufw default deny incoming으로 기본 인바운드를 차단한 뒤, ufw allow 22, ufw allow 443처럼 필요한 포트만 개방한다. SSH 포트는 기본 22번을 변경하는 것이 일반적인 보안 관행이다. 자동화된 공격 도구 대부분이 22번을 대상으로 무차별 로그인을 시도하기 때문이다.

포트 포워딩

가정이나 사무실 네트워크에서 내부 서버를 외부에서 접근하게 하려면 포트 포워딩(Port Forwarding)이 필요하다. 공유기가 외부에서 특정 포트로 들어오는 요청을 내부 네트워크의 특정 IP와 포트로 전달하는 설정이다. 외부 포트 8080을 내부 192.168.0.100의 80번 포트로 연결하면, 외부에서 공인IP:8080으로 접속 시 내부 웹서버에 도달한다.

포트 충돌 해결

두 개의 서비스가 같은 포트를 사용하려고 하면 포트 충돌이 발생한다. 나중에 시작하려는 서비스가 Address already in use 에러를 내며 구동에 실패한다. ss -tlnp로 해당 포트를 점유하고 있는 프로세스를 확인하고, 불필요한 프로세스를 종료하거나 서비스의 설정 파일에서 포트 번호를 변경하여 해결한다.

포트 #서버포트 #방화벽 #포트포워딩 #UFW #네트워크보안 #리눅스 #SSH포트 #서버관리 #포트번호

왜 파일 권한이 중요한가

리눅스는 다중 사용자 운영체제다. 여러 사용자가 동시에 시스템에 접속하여 작업할 수 있다. 이때 A 사용자의 파일을 B 사용자가 마음대로 읽거나 삭제할 수 있다면 보안 사고가 끊이지 않을 것이다. 리눅스의 파일 권한 체계는 누가 어떤 파일에 대해 무엇을 할 수 있는지를 세밀하게 제어하는 시스템이다. 서버 운영에서 권한 설정 실수는 보안 취약점으로 직결되므로 이 체계를 정확히 이해하는 것이 필수다.

소유자, 그룹, 기타

리눅스에서 모든 파일과 디렉토리에는 세 가지 접근 주체가 정의된다. 소유자(Owner)는 파일을 생성한 사용자다. 그룹(Group)은 소유자가 속한 그룹이며, 같은 그룹에 속한 다른 사용자들의 접근 권한을 정의한다. 기타(Others)는 소유자도 아니고 해당 그룹에도 속하지 않는 나머지 모든 사용자를 의미한다. ls -l 명령어로 파일 목록을 조회하면 -rwxr-xr– 형태의 권한 문자열이 표시되는데, 이 10자리가 파일 유형(1자리)과 세 주체의 권한(각 3자리)을 나타낸다.

읽기, 쓰기, 실행

각 주체에게 부여할 수 있는 권한은 세 가지다. 읽기(r, Read)는 파일의 내용을 읽을 수 있는 권한이다. 디렉토리에 대해서는 디렉토리 내 파일 목록을 조회할 수 있는 권한을 의미한다. 쓰기(w, Write)는 파일을 수정하거나 삭제할 수 있는 권한이다. 디렉토리에 대해서는 해당 디렉토리 안에 파일을 생성하거나 삭제할 수 있는 권한이다. 실행(x, Execute)은 파일을 프로그램으로 실행할 수 있는 권한이다. 디렉토리에 대해서는 해당 디렉토리에 진입(cd)할 수 있는 권한이다.

숫자 표기법

권한은 숫자로도 표현된다. r=4, w=2, x=1이며, 이를 합산하여 한 자릿수로 나타낸다. rwx=7, rw-=6, r-x=5, r–=4, —=0이다. 세 주체의 권한을 순서대로 나열하면 755, 644 같은 3자리 숫자가 된다. chmod 755 script.sh는 소유자에게 읽기+쓰기+실행(7), 그룹에게 읽기+실행(5), 기타에게 읽기+실행(5)을 부여하는 명령이다. 644는 소유자가 읽기+쓰기, 나머지는 읽기만 가능한 권한으로 일반 파일의 기본값으로 많이 사용된다.

실무에서 흔한 권한 설정

웹서버에서 정적 파일은 644, 디렉토리는 755가 표준이다. 실행 스크립트는 755로 설정한다. 비밀 키 파일(SSH 개인 키, SSL 키 파일)은 600으로 소유자만 읽고 쓸 수 있게 제한한다. 777은 모든 사용자에게 모든 권한을 부여하는 것으로, 보안상 절대 사용하지 않는 것이 원칙이다. 웹 디렉토리를 777로 설정하면 외부 공격자가 악성 파일을 업로드하고 실행할 수 있는 경로가 열린다.

특수 권한

기본 rwx 외에 setuid, setgid, sticky bit라는 특수 권한이 존재한다. setuid가 설정된 실행 파일은 실행 시 파일 소유자의 권한으로 동작한다. passwd 명령어가 대표적이다. 일반 사용자가 실행해도 root 권한으로 /etc/shadow를 수정할 수 있는 이유가 setuid 때문이다. sticky bit는 디렉토리에 설정하면 해당 디렉토리 내 파일은 파일 소유자만 삭제할 수 있게 한다. /tmp 디렉토리에 기본 적용되어 있다.

리눅스권한 #chmod #파일권한 #리눅스보안 #rwx #setuid #서버보안 #리눅스기초 #파일시스템 #서버운영

단일 장애점의 위험

서버 인프라에서 가장 피해야 할 것이 단일 장애점(Single Point of Failure, SPOF)이다. 특정 구성 요소 하나가 고장 나면 전체 서비스가 중단되는 지점을 말한다. 서버 한 대, 네트워크 스위치 한 대, 전원 회선 하나에 모든 것이 의존하고 있다면 그 하나가 멈추는 순간 서비스 전체가 다운된다. 이중화(Redundancy)는 이 SPOF를 제거하기 위해 핵심 구성 요소를 두 개 이상 준비하는 설계 전략이다.

서버 이중화

가장 기본적인 이중화는 서버 자체를 두 대 이상 운영하는 것이다. 액티브-스탠바이(Active-Standby) 구성에서는 한 대가 서비스를 처리하고, 대기 서버는 평상시에는 유휴 상태로 있다가 주 서버가 다운되면 자동으로 전환(Failover)되어 서비스를 이어받는다. 액티브-액티브(Active-Active) 구성에서는 두 대 이상의 서버가 동시에 트래픽을 처리한다. 로드밸런서가 요청을 분산하므로 한 대가 다운되어도 나머지 서버가 전체 트래픽을 처리한다. 자원 활용률이 높고 확장성이 좋아 실무에서 더 선호되는 방식이다.

네트워크 이중화

서버가 이중화되어 있어도 네트워크 경로가 하나뿐이면 그 경로가 끊기는 순간 모든 서버에 접근 불가능해진다. 네트워크 이중화는 스위치, 라우터, 네트워크 인터페이스, ISP 회선을 이중으로 구성하는 것이다. 서버에 NIC(Network Interface Card)를 두 장 장착하고 본딩(Bonding) 또는 팀잉(Teaming)으로 묶으면 하나의 NIC가 고장 나도 통신이 유지된다. 상위 네트워크에서는 스위치 이중화와 LACP(Link Aggregation)로 경로 다중화를 구성한다.

스토리지 이중화

데이터 저장 영역의 이중화도 필수다. RAID 구성은 디스크 수준의 이중화이며, 더 높은 수준에서는 스토리지 장비 자체를 이중으로 배치한다. SAN(Storage Area Network) 환경에서는 듀얼 컨트롤러 스토리지를 사용하여 하나의 컨트롤러가 장애를 일으켜도 다른 컨트롤러가 I/O를 처리한다. 지리적 이중화는 서로 다른 데이터센터에 데이터를 복제하여 한쪽 데이터센터 전체가 불가용 상태가 되어도 서비스를 지속할 수 있게 한다.

전원 이중화

전력 공급이 중단되면 서버의 모든 구성 요소가 동시에 멈춘다. 서버급 장비는 이중 전원 공급 장치(Redundant PSU)를 기본 장착한다. 두 개의 PSU가 각각 독립된 전력 회선에 연결되어 하나의 회선이 끊겨도 나머지 PSU가 전력을 공급한다. 데이터센터 수준에서는 한전 이중 수전, UPS, 디젤 발전기가 다층으로 구성되어 정전 시에도 수 시간에서 수일간 무중단 전력을 보장한다.

이중화의 비용과 판단 기준

이중화는 모든 계층에서 비용이 2배 이상 증가한다. 서버 2대, 스위치 2대, 회선 2개, PSU 2개. 따라서 서비스의 가용성 요구 수준에 따라 이중화 범위를 결정해야 한다. 다운타임 1분당 매출 손실이 큰 서비스일수록 이중화 투자가 정당화된다. SLA(Service Level Agreement)에서 보장하는 가용성 목표가 이중화 설계의 기준이 된다.

이중화 #서버이중화 #SPOF #Failover #로드밸런싱 #고가용성 #네트워크이중화 #RAID #이중전원 #SLA

파일 시스템이란? ext4, XFS, Btrfs 비교

파일 시스템의 역할

파일 시스템(File System)은 운영체제가 디스크 위의 데이터를 조직하고 관리하는 체계다. 디스크의 물리적 저장 공간은 섹터 단위의 연속된 바이트에 불과하다. 파일 시스템이 이 바이트들을 파일과 디렉토리라는 논리적 구조로 변환하여 사용자와 애플리케이션이 데이터를 이름으로 찾고, 읽고, 쓸 수 있게 만든다. 어떤 파일 시스템을 선택하느냐에 따라 성능, 안정성, 최대 볼륨 크기, 스냅샷 기능 등이 달라지므로 서버 구축 시 용도에 맞는 선택이 중요하다.

ext4

ext4(Fourth Extended File System)는 리눅스의 기본 파일 시스템이다. 대부분의 리눅스 배포판이 설치 시 기본으로 ext4를 사용한다. 최대 볼륨 크기 1EB(엑사바이트), 최대 파일 크기 16TB를 지원한다. 저널링(Journaling) 기능으로 시스템 비정상 종료 시 데이터 손상을 최소화한다. 저널링이란 데이터를 디스크에 기록하기 전에 변경 내용을 별도의 저널 영역에 먼저 기록하는 방식이다. 정전이나 크래시 발생 시 저널을 참조하여 파일 시스템을 일관된 상태로 복구한다. 안정성이 검증되었고 호환성이 가장 넓어 범용 서버에서 무난한 선택이다.

XFS

XFS는 SGI가 개발한 고성능 저널링 파일 시스템이다. RHEL 7부터 기본 파일 시스템으로 채택되었으며, 대용량 파일과 높은 병렬 I/O 처리에 강점이 있다. 최대 볼륨 크기와 파일 크기 모두 8EB를 지원한다. XFS의 핵심 기술은 할당 그룹(Allocation Group)이다. 볼륨을 독립적으로 관리되는 여러 영역으로 분할하여 다수의 스레드가 동시에 서로 다른 영역에 쓰기 작업을 수행할 수 있다. 이 병렬성이 대규모 데이터베이스 서버, 미디어 스트리밍 서버, 빅데이터 스토리지에서 ext4보다 높은 성능을 발휘하는 이유다. 다만 파일 시스템 축소(shrink)가 불가능하다는 점은 운영 시 주의해야 한다.

Btrfs

Btrfs(B-tree File System)는 차세대 리눅스 파일 시스템을 목표로 개발되고 있다. 가장 큰 특징은 파일 시스템 레벨에서 스냅샷, 서브볼륨, 데이터 체크섬, 압축, 소프트웨어 RAID를 기본 지원한다는 점이다. 스냅샷은 특정 시점의 파일 시스템 상태를 즉시 복제하는 기능으로 COW(Copy-On-Write) 방식으로 동작하여 공간 효율이 높다. 데이터 체크섬은 디스크에 기록된 데이터의 무결성을 파일 시스템 레벨에서 검증하여 비트 로트(Bit Rot)를 탐지할 수 있다. NAS 운영체제인 시놀로지 DSM이 Btrfs를 옵션으로 지원하는 이유도 이 스냅샷과 데이터 무결성 기능 때문이다. 다만 RAID 5/6 지원이 아직 불안정하고, 프로덕션 환경에서의 검증 사례가 ext4나 XFS에 비해 적다는 점이 한계다.

선택 기준 정리

범용 서버, 안정성 최우선이라면 ext4가 가장 안전하다. 대용량 파일, 높은 병렬 I/O가 필요한 데이터베이스나 스트리밍 서버에는 XFS가 적합하다. 스냅샷과 데이터 무결성 검증이 필요한 NAS나 백업 스토리지에는 Btrfs가 매력적인 선택이다.

파일시스템 #ext4 #XFS #Btrfs #리눅스 #저널링 #스냅샷 #COW #서버스토리지 #디스크관리

DHCP란 무엇인가

DHCP(Dynamic Host Configuration Protocol)는 네트워크에 접속하는 장치에 IP 주소를 자동으로 할당하는 프로토콜이다. 우리가 카페 와이파이에 연결하면 별도 설정 없이 바로 인터넷을 사용할 수 있는 이유가 DHCP 서버가 자동으로 IP 주소를 배정해주기 때문이다. DHCP가 없다면 네트워크에 접속할 때마다 수동으로 IP 주소, 서브넷 마스크, 게이트웨이, DNS 서버 주소를 입력해야 한다.

DHCP 작동 과정

DHCP의 IP 할당 과정은 DORA라는 4단계로 이루어진다. Discover 단계에서 클라이언트가 네트워크에 접속하면 브로드캐스트로 DHCP 서버를 찾는 메시지를 보낸다. 아직 IP 주소가 없으므로 출발지 주소를 0.0.0.0으로, 목적지를 255.255.255.255로 설정하여 전체 네트워크에 뿌린다. Offer 단계에서 DHCP 서버가 이 메시지를 수신하고, 사용 가능한 IP 주소와 네트워크 설정 정보를 제안한다. Request 단계에서 클라이언트가 제안된 IP 주소를 사용하겠다는 요청을 보낸다. Acknowledge 단계에서 DHCP 서버가 최종 승인하고, 해당 IP 주소를 클라이언트에게 할당한다.

IP 임대와 갱신

DHCP가 할당하는 IP 주소는 영구적이지 않다. 임대 시간(Lease Time)이 정해져 있으며, 기본값은 DHCP 서버 설정에 따라 다르지만 보통 24시간에서 7일 사이다. 임대 시간의 50%가 경과하면 클라이언트는 자동으로 갱신 요청을 보내 임대를 연장한다. 장치가 네트워크에서 분리되고 임대 시간이 만료되면 해당 IP는 주소 풀에 반환되어 다른 장치에 재할당될 수 있다. 이 메커니즘 덕분에 유한한 IP 주소 자원을 효율적으로 관리할 수 있다.

DHCP 서버의 위치

가정 환경에서는 공유기(라우터)가 DHCP 서버 역할을 겸한다. 공유기 관리 페이지에서 DHCP 범위, 임대 시간, 예약 설정을 변경할 수 있다. 기업 네트워크에서는 Windows Server의 DHCP 서비스나 리눅스의 ISC DHCP Server, dnsmasq가 전용 DHCP 서버로 운영된다. 대규모 네트워크에서는 DHCP 릴레이 에이전트를 구성하여 서로 다른 서브넷의 DHCP 요청을 중앙 DHCP 서버로 전달하는 구조를 사용한다.

DHCP 예약과 서버 운영

서버는 IP 주소가 변경되면 안 되므로 DHCP를 통한 유동 IP 할당은 적합하지 않다. 서버에는 고정 IP를 수동으로 설정하거나, DHCP 예약(Reservation) 기능을 사용한다. DHCP 예약은 특정 장치의 MAC 주소에 항상 같은 IP를 할당하도록 DHCP 서버에 등록하는 것이다. DHCP의 편리함과 고정 IP의 일관성을 동시에 확보할 수 있다. NAS, 프린터, IoT 기기처럼 내부 네트워크에서 고정 주소가 필요한 장치에 유용하다.

DHCP 보안 이슈

DHCP는 인증 메커니즘이 없다는 보안 취약점이 있다. DHCP 스푸핑(Spoofing) 공격에서 공격자가 네트워크에 악성 DHCP 서버를 설치하면, 클라이언트에게 가짜 게이트웨이 주소를 배포하여 트래픽을 가로챌 수 있다. 엔터프라이즈 네트워크에서는 스위치의 DHCP 스누핑(Snooping) 기능으로 인가되지 않은 DHCP 서버의 응답을 차단하여 이 공격에 대응한다.

DHCP #IP할당 #네트워크기초 #DORA #DHCP서버 #IP임대 #고정IP #DHCP예약 #네트워크보안 #서버네트워크

대역폭의 기본 개념

대역폭(Bandwidth)은 네트워크 연결이 단위 시간당 전송할 수 있는 최대 데이터량을 의미한다. 흔히 도로의 차선 수에 비유된다. 차선이 넓을수록 동시에 더 많은 차량이 지나갈 수 있듯이, 대역폭이 클수록 동시에 더 많은 데이터를 전송할 수 있다. 단위는 bps(bits per second)이며, 서버 환경에서는 Mbps(메가비트)나 Gbps(기가비트)를 사용한다. 주의할 점은 비트(bit)와 바이트(Byte)의 차이다. 1Gbps는 초당 약 125MB의 데이터를 전송할 수 있다는 의미이지 1GB가 아니다.

대역폭과 처리량, 지연의 관계

대역폭은 파이프의 굵기, 처리량(Throughput)은 파이프를 통해 실제로 흐르는 물의 양, 지연(Latency)은 물이 파이프의 한쪽 끝에서 다른 쪽 끝까지 도달하는 시간에 대응한다. 대역폭이 1Gbps여도 네트워크 혼잡, 패킷 손실, 프로토콜 오버헤드 등으로 실제 처리량은 이보다 낮다. 지연은 대역폭과 독립적인 지표이며 물리적 거리, 라우팅 경로, 처리 시간에 의해 결정된다. 대역폭이 아무리 넓어도 지연이 높으면 실시간 통신에서 체감 속도가 느려진다.

서버 호스팅에서의 대역폭

서버 호스팅이나 VPS 서비스를 선택할 때 대역폭은 가장 중요한 스펙 중 하나다. 제공 방식은 크게 두 가지로 나뉜다. 월간 트래픽 할당 방식은 한 달에 사용할 수 있는 총 전송량을 정해두는 것이다. 1TB/월이라면 한 달 동안 들어오고 나가는 데이터의 합이 1TB를 넘으면 추가 과금되거나 속도가 제한된다. 포트 속도 보장 방식은 네트워크 인터페이스의 최대 속도를 명시하는 것이다. 1Gbps 포트라면 순간 최대 전송 속도가 1Gbps까지 가능하다.

대역폭이 부족하면 발생하는 문제

웹 서비스의 경우 대역폭이 부족하면 동시 접속자 수가 늘어날 때 페이지 로딩 속도가 급격히 느려진다. 이미지, CSS, JavaScript 파일의 전송이 지연되어 사용자 경험이 저하된다. 스트리밍 서비스는 버퍼링이 발생하고, API 서버는 응답 시간이 길어진다. 극단적인 경우 서버의 네트워크 인터페이스가 포화 상태에 도달하여 새로운 연결 자체를 거부하게 된다. 이것이 대역폭 고갈로 인한 서비스 장애다.

대역폭 최적화 방법

정적 파일을 CDN으로 분산하면 원본 서버의 대역폭 소모를 대폭 줄일 수 있다. 이미지 최적화(압축, WebP 변환, 적절한 해상도)로 파일 크기를 줄이는 것도 효과적이다. HTTP 응답에 gzip 또는 Brotli 압축을 적용하면 텍스트 기반 콘텐츠(HTML, CSS, JS)의 전송량을 60~80% 절감할 수 있다. 불필요한 API 호출을 줄이고, 캐싱 헤더를 적절히 설정하여 동일 리소스의 재전송을 방지하는 것도 대역폭 관리의 기본이다.

대역폭 모니터링

서버의 네트워크 사용량은 실시간으로 모니터링해야 한다. 리눅스에서 iftop은 인터페이스별 실시간 트래픽을 확인할 수 있고, vnstat는 일별, 월별 트래픽 통계를 제공한다. Prometheus의 node_exporter가 네트워크 인터페이스 메트릭을 수집하면 Grafana에서 시계열 그래프로 시각화할 수 있다.

대역폭 #네트워크대역폭 #서버트래픽 #Throughput #Latency #CDN #트래픽최적화 #서버호스팅 #Brotli #네트워크모니터링

이메일은 어떻게 전달되는가

이메일을 보내고 받는 과정은 단순해 보이지만, 그 뒤에서는 여러 프로토콜이 역할을 나눠 동작한다. 메일을 보내는 데 사용되는 프로토콜과 받는 데 사용되는 프로토콜이 다르다. 발신에는 SMTP, 수신에는 POP3 또는 IMAP이 사용된다. 이 세 가지 프로토콜의 차이를 이해하면 메일 서버의 구조가 명확해진다.

SMTP 발신 프로토콜

SMTP(Simple Mail Transfer Protocol)는 이메일을 보내는 데 사용되는 프로토콜이다. 기본 포트는 25번이며, 암호화 전송에는 587번(STARTTLS) 또는 465번(SMTPS)을 사용한다. 사용자가 메일 클라이언트에서 발송 버튼을 누르면, 메일은 SMTP 프로토콜을 통해 발신 메일 서버(MTA, Mail Transfer Agent)로 전달된다. 발신 MTA는 수신자의 도메인에 대한 MX 레코드를 DNS에서 조회하여 수신 메일 서버를 찾고, SMTP로 메일을 해당 서버에 전달한다. 메일 서버 간의 중계도 전부 SMTP로 이루어진다. SMTP는 오직 발신과 중계만 담당하며, 수신자가 메일을 읽는 과정에는 관여하지 않는다.

POP3 수신 프로토콜

POP3(Post Office Protocol version 3)는 메일 서버에 저장된 이메일을 클라이언트로 다운로드하는 프로토콜이다. 기본 포트는 110번, 암호화 포트는 995번이다. POP3의 기본 동작은 메일을 클라이언트로 다운로드한 뒤 서버에서 삭제하는 것이다. 서버에 사본을 남기는 옵션을 설정할 수도 있지만, 설계 자체가 단일 기기에서 메일을 관리하는 것을 전제로 한다. 장점은 메일이 로컬에 저장되므로 오프라인 상태에서도 읽을 수 있다는 점이다. 단점은 여러 기기에서 메일을 동기화하기 어렵다는 점이다. PC에서 다운로드한 메일은 스마트폰에서 볼 수 없고, 읽음 상태나 폴더 분류도 기기 간에 공유되지 않는다.

IMAP 수신 프로토콜

IMAP(Internet Message Access Protocol)은 POP3의 한계를 극복하기 위해 설계된 프로토콜이다. 기본 포트는 143번, 암호화 포트는 993번이다. IMAP은 메일을 서버에 유지한 채 클라이언트에서 접근하는 방식이다. 메일의 읽음 상태, 폴더 구조, 플래그가 서버에 저장되므로 PC, 스마트폰, 태블릿 어디서든 동일한 메일함 상태를 확인할 수 있다. 현재 대부분의 메일 서비스가 IMAP을 기본 프로토콜로 채택하고 있다. Gmail, Outlook, 네이버 메일 모두 IMAP을 지원한다.

실무에서의 메일 서버 구성

자체 메일 서버를 구축하려면 발신(SMTP)과 수신(IMAP/POP3)을 각각 처리하는 소프트웨어가 필요하다. Postfix가 SMTP 서버(MTA)로 가장 널리 사용되고, Dovecot이 IMAP/POP3 서버로 대표적이다. 여기에 SpamAssassin으로 스팸 필터링을 추가하고, SPF, DKIM, DMARC 레코드를 DNS에 설정하여 발신 메일의 인증과 위변조 방지를 처리한다. 다만 자체 메일 서버 운영은 스팸 평판 관리, 보안 업데이트, 가용성 유지 부담이 크기 때문에, 소규모 환경에서는 Google Workspace나 Microsoft 365 같은 매니지드 서비스를 사용하는 것이 현실적인 선택이다.

SMTP #POP3 #IMAP #메일서버 #Postfix #Dovecot #이메일프로토콜 #SPF #DKIM #메일보안

cron의 개념

cron은 리눅스 및 유닉스 시스템에서 특정 시간에 명령어나 스크립트를 자동으로 실행하는 작업 스케줄러다. 서버 운영에서 반복적으로 수행해야 하는 작업은 끝없이 많다. 로그 정리, 데이터베이스 백업, 시스템 업데이트 확인, 모니터링 스크립트 실행, 캐시 초기화 등이 대표적이다. 이런 작업을 관리자가 매번 수동으로 실행하면 누락과 실수가 불가피하다. cron은 이 문제를 해결하는 리눅스 서버 운영의 기본 도구다.

crontab 문법

cron 작업은 crontab(cron table) 파일에 정의한다. crontab -e 명령어로 편집하고 crontab -l로 현재 등록된 작업을 확인한다. 각 줄은 하나의 작업을 정의하며, 5개의 시간 필드와 실행할 명령어로 구성된다. 시간 필드는 왼쪽부터 분(0-59), 시(0-23), 일(1-31), 월(1-12), 요일(0-7, 0과 7 모두 일요일)이다. 예를 들어 매일 새벽 3시에 백업 스크립트를 실행하려면 0 3 * * * /home/user/backup.sh라고 작성한다. 별표(*)는 해당 필드의 모든 값을 의미하고, 슬래시(/)는 간격을 지정한다. */5 * * * *는 5분마다 실행을 의미한다.

실무 활용 예시

가장 흔한 활용은 데이터베이스 백업 자동화다. 매일 새벽 2시에 mysqldump로 백업 파일을 생성하고, 7일 이상 된 백업 파일을 자동 삭제하는 스크립트를 cron에 등록한다. 로그 압축과 정리도 cron의 단골 업무다. logrotate가 내부적으로 cron을 통해 동작하며, 커스텀 로그 관리가 필요하면 별도 스크립트를 등록한다. SSL 인증서 자동 갱신도 cron을 활용한다. Let’s Encrypt의 Certbot은 갱신 명령어를 cron에 등록하여 인증서 만료 전 자동으로 갱신을 시도한다. 서버 상태를 주기적으로 체크하여 이상 시 알림을 보내는 헬스체크 스크립트도 cron으로 자동화한다.

주의사항

cron 작업 설정 시 자주 발생하는 실수들이 있다. 첫째, 환경 변수 문제다. cron은 사용자의 셸 환경을 상속하지 않는다. 로그인 셸에서는 잘 동작하던 스크립트가 cron에서 실패하는 가장 흔한 원인이다. 스크립트 내에서 필요한 환경 변수를 명시적으로 선언하거나, 명령어를 절대 경로로 작성해야 한다. 둘째, 출력 관리다. cron 작업의 표준 출력과 표준 에러가 처리되지 않으면 시스템 메일로 쌓인다. 출력을 로그 파일로 리다이렉트하거나 /dev/null로 버리는 처리가 필요하다. 셋째, 중복 실행 방지다. 이전 실행이 끝나지 않았는데 새 실행이 시작되면 충돌이 발생할 수 있다. flock 명령어로 락 파일을 잡아 동시 실행을 방지하는 것이 안전하다.

systemd 타이머와의 비교

최신 리눅스 배포판에서는 systemd 타이머가 cron의 대안으로 부상하고 있다. systemd 타이머는 서비스 유닛과 타이머 유닛을 분리하여 관리하며, 부팅 후 경과 시간 기반 스케줄링, 의존성 관리, 로그 통합(journald)이 가능하다. 다만 설정이 crontab보다 복잡하고, 단순 반복 작업에는 cron이 여전히 직관적이라 양쪽 모두 실무에서 활발하게 사용되고 있다.

cron #crontab #리눅스자동화 #서버자동화 #백업자동화 #스케줄러 #systemd타이머 #셸스크립트 #서버운영 #리눅스기초

서버 마이그레이션의 정의

서버 마이그레이션(Server Migration)은 서버의 데이터, 애플리케이션, 설정을 기존 환경에서 새로운 환경으로 이전하는 작업이다. 물리 서버에서 클라우드로 이전하거나, 클라우드 제공자를 변경하거나, 노후화된 하드웨어를 교체하거나, 데이터센터를 이전할 때 발생한다. 서비스 중단을 최소화하면서 데이터 무결성을 유지하는 것이 마이그레이션의 핵심 과제다.

마이그레이션 유형

크게 세 가지 유형으로 나뉜다. 리호스팅(Rehosting)은 기존 시스템을 그대로 새 환경으로 옮기는 방식이다. 리프트 앤 시프트(Lift and Shift)라고도 부르며, 애플리케이션 코드를 수정하지 않고 인프라만 변경한다. 가장 빠르고 위험이 낮지만 새 환경의 기능을 충분히 활용하지 못한다. 리플랫포밍(Replatforming)은 핵심 아키텍처는 유지하되 일부를 새 환경에 맞게 최적화하는 방식이다. 데이터베이스를 자체 운영에서 RDS 같은 매니지드 서비스로 전환하는 것이 대표적인 예다. 리팩터링(Refactoring)은 애플리케이션 자체를 클라우드 네이티브 아키텍처로 재설계하는 방식이다. 비용과 시간이 가장 많이 들지만 장기적으로 가장 큰 효율을 얻을 수 있다.

사전 준비 단계

마이그레이션의 성공은 사전 준비에 달려 있다. 첫째, 현재 인벤토리를 정리한다. 서버 수, 각 서버의 역할, OS 버전, 설치된 소프트웨어, 데이터 용량, 네트워크 구성을 빠짐없이 문서화한다. 둘째, 의존성을 매핑한다. 서버 간 통신 관계, 외부 API 연동, 데이터베이스 연결 정보, 공유 스토리지 참조 관계를 파악한다. 이 의존성을 놓치면 마이그레이션 후 특정 서비스가 동작하지 않는 사고가 발생한다. 셋째, 마이그레이션 전 반드시 전체 백업을 수행하고 복구 테스트를 완료한다.

데이터 마이그레이션

가장 신경 써야 할 영역이다. 데이터 용량이 크면 전체 복사에 수 시간에서 수일이 걸릴 수 있다. 초기 풀 카피를 먼저 수행하고, 전환 시점에 변경분만 동기화하는 증분 동기화 방식이 일반적이다. rsync는 파일 시스템 동기화에 가장 널리 사용되는 도구다. 데이터베이스는 논리적 덤프(mysqldump, pg_dump)와 물리적 복제(XtraBackup, pg_basebackup)를 상황에 맞게 선택한다. 실시간 서비스 중이라면 마스터-슬레이브 복제를 설정하여 무중단에 가까운 전환이 가능하다.

전환과 검증

데이터 동기화가 완료되면 DNS를 새 서버의 IP로 변경하여 트래픽을 전환한다. DNS TTL을 사전에 짧게 설정해두어야 전환이 빠르게 반영된다. 전환 직후에는 모든 서비스의 정상 동작을 확인하는 체크리스트를 순서대로 점검한다. 웹페이지 로딩, API 응답, 데이터베이스 쿼리 결과, 파일 접근, SSL 인증서 적용 상태, 로그 기록 정상 여부를 모두 확인한다. 문제가 발생하면 DNS를 원래 서버로 되돌려 롤백할 수 있어야 하므로, 기존 서버는 최소 1~2주간 유지한다.

서버마이그레이션 #클라우드이전 #리호스팅 #데이터이전 #rsync #DNS전환 #서버이전 #백업 #인프라관리 #클라우드