모두
모두콘텐츠
얼마 전 방문자가 하루 3천 명인 사이트의 이전 상담을 받았다. 운영자는 트래픽이 늘까 봐 큰 클라우드 서버부터 계약하려고 했다. 그런데 장애 기록을 보니 CPU가 부족했던 적은 없었다. 디스크가 꽉 찬 날 한 번, 백업 파일을 서버 안에만 둔 채 삭제한 날 한 번이었다. 서버를 고를 때는 막연한 방문자 수보다 실제 요청량과 복구 방법을 먼저 봐야 한다.
방문자 수를 초당 요청으로 바꾸는 방법
월 방문자 수만으로 CPU를 정하기는 어렵다. 같은 방문자 1만 명이라도 이미지가 많은 소개 페이지와 로그인·검색이 잦은 서비스는 서버가 처리하는 일이 다르다. 우선 하루 페이지 조회 수, 페이지 한 번을 볼 때 발생하는 동적 요청 수, 가장 붐비는 시간대의 집중도를 기록한다. 이미지와 글꼴처럼 캐시할 수 있는 파일은 따로 센다.
예를 들어 하루 3천 페이지 조회, 조회당 동적 요청 4개라면 하루 동적 요청은 1만 2천 건이다. 하루 평균은 초당 약 0.14건이다. 바쁜 시간에 평균의 10배가 몰려도 초당 약 1.4건이다. 이 수치는 서버가 감당해야 할 부하를 가늠하는 출발점이지, 특정 사양의 성능 보증은 아니다. 관리자 화면에서 대량 업로드를 하거나 예약 작업이 동시에 돌면 순간 부하는 더 커진다.
동시접속자 100명이라는 숫자도 그대로 CPU 100개 분량의 일로 바꾸면 안 된다. 사람이 화면을 읽는 동안 서버는 쉬고 있을 수 있다. 실제로는 초당 요청 수와 요청 한 건의 처리 시간이 중요하다. 초당 10건을 받고 각 요청이 0.2초 걸린다면, 단순 계산으로 동시에 처리 중인 요청은 평균 2건 정도다. 처리 시간이 2초로 늘면 같은 트래픽에서도 20건이 된다. 느린 데이터베이스 질의가 서버 사양보다 먼저 문제인 경우가 여기서 드러난다.
처음 사양은 작게 잡고 병목을 확인한다
캐시가 잘 되는 소규모 블로그라면 큰 클라우드 인스턴스가 출발점일 이유는 없다. 웹서버와 데이터베이스를 한 서버에서 운영하는 경우 1~2 vCPU, 메모리 2GB 안팎을 시험 사양으로 잡고 측정할 수 있다. 다만 상품마다 CPU 공유 방식과 디스크 성능이 다르다. 같은 숫자가 적혀 있어도 처리량까지 같지는 않다.
메모리는 운영체제, 웹서버, 애플리케이션, 데이터베이스가 함께 쓴다. 평소 사용량이 1.8GB인 서버에 2GB 요금제를 넣으면 업데이트나 백업 중에 여유가 없다. 메모리 부족으로 프로세스가 종료되는지, 디스크 대기 시간이 길어지는지, CPU 사용률이 특정 시간에만 치솟는지를 최소 며칠은 확인한다. 평균 사용률만 보면 짧은 장애를 놓친다. 응답 시간의 상위 구간과 오류율도 같이 본다.
용량 계산에는 전송량을 넣어야 한다. 페이지 한 번을 여는 데 평균 1MB가 전송되고 하루 3천 번 열린다면 단순 계산으로 하루 3GB, 30일에 약 90GB다. 반대로 하루 3만 번이면 약 900GB다. 이미지가 외부 캐시에서 제공되면 원본 서버의 전송량은 줄지만, 캐시 비용과 원본으로 되돌아오는 요청도 확인해야 한다. 요금표에서는 인스턴스 가격뿐 아니라 전송량 초과분, 저장 공간, 백업 보관료, 고정 주소 비용을 합산한다.
방문자가 적고 관리할 사람이 없다면 웹호스팅이 더 실용적일 수 있다. 운영체제 업데이트, 방화벽, 데이터베이스 백업을 직접 책임질 준비가 되었을 때 클라우드 서버의 자유도가 값어치를 한다. 무조건 상위 요금제로 올리기 전에 캐시 설정, 느린 질의, 불필요한 예약 작업부터 확인하는 편이 비용도 덜 든다.
이전할 때는 되돌아갈 길부터 만든다
서버 이전 사고는 복사 자체보다 전환 순간에 자주 난다. 새 서버에 파일과 데이터베이스를 옮긴 뒤 화면만 열어 보고 끝내면 로그인, 결제, 문의 메일 같은 기능을 놓치기 쉽다. 이전 전에는 현재 환경의 런타임 버전, 예약 작업, 환경 변수, 인증서, 업로드 경로를 목록으로 적는다. 데이터베이스 백업은 복원 가능한 형식인지 별도 환경에서 확인한다.
- 기존 서버의 파일과 데이터베이스를 백업하고, 백업 파일을 다른 저장소에도 둔다.
- 새 서버에서 주요 화면뿐 아니라 로그인, 글쓰기, 첨부 파일, 메일 발송을 시험한다.
- 전환 직전에는 쓰기 작업을 잠시 멈추고 마지막 데이터 차이를 반영한다.
- 트래픽을 전환한 뒤 오류율과 데이터베이스 연결 수를 살피며 기존 서버를 당분간 유지한다.
DNS의 TTL을 미리 낮추면 일부 이용자의 전환 지연을 줄일 수 있지만, 이미 남아 있는 캐시까지 즉시 지우지는 못한다. 구 서버와 신 서버에 쓰기가 동시에 발생하면 데이터가 갈라질 수 있다. 그래서 전환 시간, 쓰기 중단 범위, 실패 시 되돌릴 기준을 미리 정해야 한다. 이전 직후에는 구 서버를 바로 삭제하지 않는 편이 안전하다.
백업과 장애 확인 순서를 운영에 넣는다
자동 스냅샷이 켜져 있다는 사실만으로 백업이 완성되지는 않는다. 운영 서버와 같은 계정에만 백업이 있으면 계정 문제나 잘못된 삭제에 함께 영향을 받을 수 있다. 파일과 데이터베이스의 백업 주기를 따로 정하고, 다른 저장 위치에 사본을 둔다. 하루치 데이터 손실을 감당할 수 있는지와 몇 시간 안에 서비스를 복구해야 하는지를 먼저 정하면 주기와 보관 기간도 현실적으로 잡힌다.
복원 시험은 백업 파일을 내려받는 데서 끝나지 않는다. 새 환경에 실제로 복원해 로그인과 주요 기능이 동작하는지 확인해야 한다. 데이터베이스 파일은 있는데 업로드 파일이 없거나, 백업은 있는데 복호화 키를 찾지 못하는 사고를 여러 번 봤다. 복원에 걸린 시간까지 기록하면 장애 때 기대할 수 있는 복구 시간을 알 수 있다.
사이트가 열리지 않으면 먼저 모든 이용자에게 같은 증상인지 확인한다. 그다음 이름 해석, 인증서 만료, 네트워크 연결, 웹서버 프로세스, 애플리케이션 오류, 데이터베이스 연결, 디스크 여유 공간 순으로 범위를 좁힌다. 최근 배포나 설정 변경이 있었다면 시각을 맞춰 로그와 비교한다. CPU가 높다는 이유만으로 서버를 키우면 원인을 가릴 수 있다.
클라우드는 서버를 빨리 만들고 크기를 바꾸기 쉬운 도구다. 하지만 운영의 기본은 여전히 숫자를 재고, 변경을 기록하고, 백업을 직접 복원해 보는 일이다. 작은 사양에서 안정적으로 돌아간다면 그 상태가 그 사이트에 맞는 사양이다.
