모두
모두콘텐츠
얼마 전 회원 수가 3천 명인 커뮤니티의 서버 이전을 도왔다. 운영자는 회원이 많아져서 고사양 서버가 필요하다고 생각했는데, 접속 기록을 보니 실제로는 한 시간에 방문이 몰리는 때에도 여유가 있었다. 문제는 사양이 아니었다. 게시글 첨부파일이 백업에서 빠져 있었고, 이전할 서버에는 이미지 저장 공간도 부족했다. 커뮤니티홈페이지제작을 시작할 때 서버 요금제부터 고르면 이런 순서가 뒤집히기 쉽다.
회원 수보다 이용 방식을 먼저 적는다
처음에는 기능을 작게 잡는 편이 좋다. 게시판, 댓글, 검색, 회원가입, 신고와 관리자 기능이면 대개 운영을 시작할 수 있다. 쪽지, 실시간 채팅, 알림을 한꺼번에 넣으면 개발 범위뿐 아니라 운영 중 확인할 장애 지점도 늘어난다. 특히 채팅과 실시간 알림은 일반 게시판보다 접속을 오래 유지하므로 서버 구성을 따로 생각해야 한다.
회원 수는 서버 부하를 계산하는 기준으로 부족하다. 가입자가 1만 명이어도 하루 방문자가 100명이면 작은 서버로 충분할 수 있다. 반대로 회원이 500명이어도 특정 시간에 모두 새 글을 확인하고 이미지를 올리면 반응이 느려진다. 예상 하루 방문자, 한 사람이 읽는 페이지 수, 피크 시간대의 방문 비율, 첨부파일 크기를 적어야 한다.
예를 들어 하루 방문자 1천 명이 각자 10페이지를 읽으면 하루 1만 페이지 조회다. 그중 20%가 가장 바쁜 한 시간에 몰려도 시간당 2천 페이지, 평균으로는 초당 약 0.6페이지다. 물론 평균은 순간 급증을 가린다. 검색, 댓글 작성, 이미지 업로드는 읽기와 처리 비용도 다르다. 이 숫자는 요금제를 확정하는 답이 아니라 첫 부하 시험의 출발점으로 쓰면 된다.
만드는 방식은 수정할 사람을 기준으로 고른다
게시판 기능이 중심이고 개발 인력이 없다면 관리형 제작 도구나 기존 커뮤니티 소프트웨어가 현실적이다. 회원 권한, 스팸 차단, 신고 처리 기능이 이미 있는지 확인한다. 디자인을 자유롭게 바꾸거나 다른 서비스와 회원 정보를 연동해야 한다면 직접 개발이 맞을 수 있지만, 그때는 배포와 보안 업데이트를 맡을 사람도 필요하다.
선택할 때 데이터 반출 방법을 꼭 본다. 글과 댓글만 내보낼 수 있고 회원 정보나 첨부파일은 옮길 수 없다면 나중에 서비스 이전이 어려워진다. 관리자 화면에서 회원을 정지하거나 게시글을 숨긴 기록을 남길 수 있는지도 확인한다. 커뮤니티는 글을 올리는 기능보다 운영자가 문제를 처리하는 기능에서 차이가 난다.
도메인 소유권과 서버 관리 계정은 운영자 명의로 두는 게 안전하다. 제작을 외주로 맡기더라도 결제 계정, 도메인 갱신 알림, 백업 접근 권한을 한 사람의 개인 계정에만 묶어 두지 않는다. 실제 장애 때 접속 권한을 찾느라 복구가 늦어지는 경우가 있다.
서버 사양은 작은 구성에서 측정하며 늘린다
텍스트 게시판 위주이고 접속이 많지 않다면 저가 웹호스팅이나 관리형 서비스로도 시작할 수 있다. 서버를 직접 관리할 이유가 없다면 운영 부담까지 포함해 비교해야 한다. VPS를 고른다면 메모리 2기가바이트는 웹서버와 데이터베이스를 함께 돌릴 때 여유가 크지 않다. 작은 커뮤니티라도 4기가바이트 안팎에서 시작해 사용량을 확인하는 편이 운영하기 편할 수 있다. 이 수치는 프로그램 종류와 검색 방식에 따라 달라지므로 구매 기준으로 고정하면 안 된다.
요금제의 월 전송량은 방문자 수로 바꿔 본다. 한 페이지를 열 때 실제 내려받는 데이터가 평균 2메가바이트이고 월 10만 페이지가 조회된다면 단순 계산으로 약 200기가바이트가 전송된다. 이미지 최적화와 캐시 설정에 따라 크게 달라진다. 첨부파일을 원본 크기 그대로 보여주면 예상보다 빨리 한도에 닿는다. 페이지 용량과 월 전송량을 직접 측정한 뒤 비교하는 게 정확하다.
응답이 느리다고 곧바로 서버를 키우지 않는다. 먼저 CPU와 메모리, 디스크 여유 공간, 느린 데이터베이스 조회, 오류 기록을 함께 본다. 게시글 목록에서 불필요한 조회가 반복되거나 검색에 적절한 색인이 없으면 사양을 올려도 비용만 늘 수 있다. 반대로 메모리가 계속 부족하고 디스크 사용량이 꾸준히 늘어난다면 그때 증설 근거가 생긴다.
백업은 파일과 데이터베이스를 함께 복구해 본다
커뮤니티 데이터는 게시글과 회원 정보만이 아니다. 프로필 사진, 첨부파일, 설정 파일도 함께 있어야 원래 화면이 돌아온다. 데이터베이스를 백업한 시점과 파일을 백업한 시점이 크게 다르면 글은 있는데 첨부파일이 없는 상태가 생길 수 있다. 백업 대상과 주기를 먼저 정하고, 백업 파일을 운영 서버 밖에도 보관한다.
자동 백업이 성공했다는 표시만으로는 충분하지 않다. 별도 시험 환경에 복원해 관리자 로그인, 최근 글, 이미지, 첨부파일 다운로드를 확인해야 한다. 복원에 걸린 시간도 재 둔다. 하루치 글을 잃어도 되는지, 장애 뒤 몇 시간 안에 다시 열어야 하는지에 따라 백업 간격과 보관 방식이 달라진다.
보안 업데이트와 관리자 계정 관리도 운영 절차에 넣는다. 관리자에게는 필요한 권한만 주고, 비밀번호 재설정과 신고 처리 절차를 미리 정한다. 공개 전에 로그인, 글쓰기, 파일 업로드에 요청 제한이 있는지 확인하면 스팸이나 무리한 자동 요청으로 생기는 부담을 줄일 수 있다.
공개 전에는 이전 순서를 한 번 실행한다
새 서버에서 기능을 확인한 뒤 도메인 연결을 바꾸기 전에 기존 서비스의 글쓰기 중단 시점과 마지막 데이터 복사 시점을 정한다. 그다음 새 서버에서 로그인, 글쓰기, 검색, 이미지 표시, 인증서 적용 상태를 점검한다. 도메인 설정 변경은 이용자마다 반영 시점이 다를 수 있으니, 잠시 두 서버로 접속해도 데이터가 엇갈리지 않도록 계획해야 한다.
서비스를 연 뒤에는 첫 며칠간 오류 기록과 백업 결과, 저장 공간 증가량을 자주 본다. 커뮤니티는 처음부터 큰 서버를 쓰는 것보다 작게 열고 실제 사용량에 맞춰 키우는 편이 비용을 통제하기 쉽다. 다만 백업과 복원 연습만큼은 이용자가 적을 때부터 해 두는 게 좋다. 사람이 늘어난 뒤에는 작은 실수도 복구하기가 훨씬 까다로워진다.
