모두
모두콘텐츠
얼마 전 하루 방문자가 3천 명인 사이트를 쿠버네티스로 옮겨야 하느냐는 상담을 받았다. 기존 서버는 거의 놀고 있었고, 실제 문제는 배포할 때마다 파일을 직접 덮어써서 되돌리기 어렵다는 점이었다. 이런 경우 클라우드네이티브 전환은 서버를 여러 대 늘리는 일보다 배포와 복구 방식을 바꾸는 일에서 시작한다.
먼저 방문자가 아니라 부하를 잰다
하루 페이지 조회 수만으로 서버 사양을 고르면 빗나가기 쉽다. 하루 10만 페이지 조회는 평균으로 나누면 초당 약 1.2페이지지만, 접속이 특정 시간에 몰리면 순간적으로 20페이지를 넘을 수 있다. 한 페이지를 열 때 이미지와 스크립트까지 서버가 직접 보내는지, 화면을 만들면서 데이터베이스를 몇 번 조회하는지도 중요하다.
운영 중인 사이트라면 최소 일주일치 지표를 본다. CPU 사용률의 평균과 높은 구간, 메모리의 실제 사용량, 초당 요청 수, 응답 시간의 상위 구간, 데이터베이스의 느린 쿼리를 함께 확인한다. 특히 CPU 평균이 15%여도 짧은 시간에 100%에 붙고 응답 시간이 튄다면 평균값은 별 도움이 안 된다. 캐시가 비어 있을 때와 평소 상태도 따로 재야 한다.
작은 콘텐츠 사이트는 2코어와 메모리 2~4GB 한 대로도 충분한 경우가 많다. 다만 이는 출발점일 뿐이다. 이미지 변환을 서버에서 하거나 검색·예약 기능이 무거우면 같은 방문자 수에서도 필요한 사양이 달라진다. 처음부터 큰 서버를 사기보다 현재 부하에 여유를 조금 두고, 부족할 때 어떤 지표를 보고 늘릴지 정해 두는 편이 낫다.
클라우드네이티브에 필요한 것부터 적용한다
클라우드네이티브라는 말 때문에 컨테이너와 쿠버네티스를 한 번에 도입하는 경우가 있다. 그런데 서버 한 대에서 돌아가는 블로그라면 배포 자동화, 설정 분리, 상태 점검부터 손보는 편이 효과가 크다. 같은 프로그램을 어느 환경에서든 같은 방식으로 실행하고, 이전 버전으로 빠르게 돌릴 수 있으면 운영 부담이 꽤 줄어든다.
애플리케이션 파일은 배포할 때 새 버전으로 교체하고, 비밀번호와 접속 정보는 실행 환경의 설정으로 분리한다. 방문자가 올린 파일을 컨테이너 안에만 두면 재시작이나 재배포 때 사라질 수 있다. 업로드 파일은 별도 저장 공간에 두고, 로그인 상태를 서버 메모리에 보관한다면 서버를 늘리기 전에 세션 저장 방식도 바꿔야 한다.
서버가 여러 대 필요해지는 시점은 측정값으로 판단한다. 한 대의 자원이 반복해서 부족하거나, 점검 중에도 서비스를 유지해야 하고, 배포 때 중단을 피해야 한다면 복수 인스턴스와 부하 분산을 검토할 만하다. 쿠버네티스는 그다음 선택지다. 관리해야 할 서비스가 적은데 운영자가 제어 영역과 네트워크까지 떠안으면 장애 지점만 늘 수 있다.
요금은 서버 가격 밖에서 늘어난다
클라우드 비용을 비교할 때 컴퓨팅 요금만 보면 실제 청구액과 차이가 난다. 데이터베이스, 저장 공간, 백업 보관량, 외부로 나가는 전송량, 로그 수집 비용을 함께 계산해야 한다. 예를 들어 페이지당 전송량이 1MB이고 하루 10만 페이지가 조회된다면 단순 계산으로 하루 약 100GB가 전송된다. 이미지 캐시와 콘텐츠 전송망 적용 여부에 따라 원본 서버에서 나가는 양은 크게 달라진다.
동시접속 수도 그대로 서버 사양으로 바꿀 수 없다. 화면을 읽는 100명과 동시에 검색 요청을 보내는 100명은 부하가 다르다. 실제로는 초당 요청 수, 요청 하나가 쓰는 CPU 시간, 데이터베이스 대기 시간으로 환산해야 한다. 짧은 부하 시험을 돌릴 때는 응답 시간과 오류율이 어느 지점부터 나빠지는지 기록한다. 그 지점이 서버를 늘릴 기준이 된다.
무료나 저가 요금제로도 운영 지표에 여유가 있다면 그대로 써도 된다. 다만 백업 공간과 복구 방법은 요금제와 별도로 확인해야 한다. 서버가 저렴해도 복구할 수 없는 데이터는 다시 만들기 어렵다.
이전 전에 복구 절차를 끝까지 실행한다
서버 이전에서 가장 자주 빠지는 것은 백업 파일을 실제로 열어 보는 일이다. 데이터베이스 덤프가 생성됐다는 기록만으로는 부족하다. 별도 환경에 복원해 게시물 수와 최근 수정 데이터가 맞는지 확인하고, 업로드 파일도 몇 개 골라 직접 열어 본다. 복원에 20분이 걸리는지 4시간이 걸리는지 알아야 중단 시간을 설명할 수 있다.
이전 순서는 단순하게 잡는다. 현재 서버의 데이터와 설정을 보관하고, 새 환경에서 같은 버전의 프로그램을 띄운다. 백업을 복원한 뒤 내부에서 주요 화면과 로그인·글쓰기 기능을 확인한다. 전환 직전에는 새 글이 양쪽 서버에 나뉘어 저장되지 않도록 쓰기 작업을 잠시 멈춘다. 트래픽을 옮긴 뒤에도 이전 서버는 바로 지우지 말고 되돌릴 시간을 남긴다.
SSL 인증서의 갱신 방식과 만료 알림도 이때 확인한다. 인증서가 자동 갱신되더라도 새 서버에서 갱신 작업이 실행되는지, 실패 알림을 받을 수 있는지는 별개다. 실제로 이전은 성공했는데 몇 달 뒤 인증서가 만료돼 접속 장애가 나는 일이 있다.
장애가 나면 확인 순서를 고정한다
사이트가 느리거나 열리지 않을 때 곧바로 서버 사양부터 올리면 원인을 놓친다. 먼저 접속이 전부 실패하는지 일부 기능만 실패하는지 구분한다. 이어서 최근 배포와 설정 변경, 인증서 상태, 애플리케이션 오류 로그를 본다. 그다음 CPU·메모리·디스크 여유와 데이터베이스 연결 수, 느린 쿼리를 확인한다. 디스크가 가득 찼는데 서버를 더 큰 사양으로 바꾸는 식의 대응을 피할 수 있다.
운영 화면에는 적어도 응답 시간, 오류율, 자원 사용량, 백업 성공 여부가 보여야 한다. 알림도 수치를 넘었다는 이유만으로 계속 울리게 만들면 금방 무시하게 된다. 이용자가 실제로 겪는 오류와 복구에 필요한 신호부터 고르는 편이 좋다.
내가 운영하는 사이트라면 새 기술을 붙이기 전에 복원 시험 날짜부터 잡는다. 배포를 되돌릴 수 있고, 백업을 복원할 수 있으며, 부하가 늘어난 근거가 보일 때 서버를 늘려도 늦지 않다. 작은 사이트일수록 이런 순서가 비용과 장애 시간을 함께 줄여 준다.
