모두
모두콘텐츠
얼마 전 하루 방문자가 2만 명인 사이트에서 서버를 늘려야 한다는 이야기를 들었다. 그런데 지표를 보니 CPU는 한가했고, 장애가 난 시간에는 데이터베이스 연결만 꽉 차 있었다. WAS서버는 방문자 수만 보고 키우면 비용은 늘고 원인은 그대로 남기 쉽다.
WAS서버가 맡는 일부터 구분한다
웹서버는 정적 파일 전달과 요청 분배를 주로 맡는다. WAS는 로그인 확인, 주문 처리, 데이터 조회처럼 요청마다 결과가 달라지는 작업을 실행한다. 실제 구성에서는 웹서버가 앞에서 요청을 받고 WAS로 넘기는 경우가 많다. 둘을 같은 장비에 설치할 수도 있고, 규모가 커지면 분리할 수도 있다.
처음부터 장비를 나눌 필요는 없다. 작은 서비스라면 웹서버와 WAS를 한 대에서 운영해도 된다. 대신 자원 사용량은 따로 봐야 한다. 이미지 전송 때문에 네트워크 사용량이 높아진 것인지, 느린 데이터 조회 때문에 WAS의 요청 대기열이 쌓인 것인지에 따라 손볼 곳이 다르다.
WAS가 느리다고 CPU가 늘 바쁜 것도 아니다. 외부 API 응답을 기다리거나 데이터베이스에서 연결을 얻지 못하면 CPU 사용률은 낮은 채로 응답 시간만 길어진다. 그래서 평균 CPU 하나보다 요청 수, 응답 시간, 오류율, 연결 대기 시간을 함께 보는 편이 정확하다.
방문자 수를 초당 요청으로 바꿔 본다
사양을 잡을 때는 하루 방문자보다 가장 바쁜 시간의 초당 요청 수가 쓸모 있다. 예를 들어 하루에 동적 요청이 10만 건이고, 피크가 하루 평균의 10배라면 대략 초당 12건이다. 10만 건을 8만6400초로 나눈 뒤 10을 곱한 값이다. 이 수치는 출발점일 뿐이다. 행사 시작 직후처럼 요청이 몇 분에 몰리면 별도 피크를 측정해야 한다.
동시에 처리 중인 요청도 계산할 수 있다. 초당 12건에 평균 처리 시간이 0.2초라면 동시에 실행 중인 요청은 평균 약 2.4건이다. 처리 시간이 2초로 늘면 같은 유입에서도 약 24건이 된다. 동시접속자 100명이라는 숫자만으로 필요한 스레드가 100개라고 판단하면 안 되는 이유다. 화면을 읽고 있는 사용자와 서버가 지금 처리 중인 요청은 다르다.
메모리는 운영체제와 데이터베이스가 쓰는 양을 먼저 빼고 계산한다. WAS가 자바 기반이라면 힙 최대치만 볼 일이 아니다. 스레드 스택, 메타데이터, 네이티브 메모리도 필요하다. 가령 메모리 2GB 장비에 힙을 2GB로 지정하면 여유가 없다. 같은 장비에 데이터베이스까지 둔다면 더 작게 시작하고 실제 사용량을 측정해야 한다.
저장 공간도 평균 사용량보다 증가 속도와 백업 공간이 중요하다. 로그가 하루 500MB씩 쌓이면 한 달에 약 15GB다. 순환 정책이 없으면 저렴한 서버도 디스크가 먼저 찬다. 반대로 요청량이 작고 응답 시간이 안정적이라면 1~2개 가상 CPU와 2GB 안팎의 메모리로 시작할 수 있는 서비스도 많다. 정확한 값은 사용 언어, 데이터베이스 배치, 요청당 작업량에 따라 달라진다.
서버를 늘리기 전에 병목을 확인한다
평소보다 응답이 느려졌다면 먼저 어느 구간에서 시간이 쓰이는지 나눈다. 웹서버 대기, WAS 실행, 데이터베이스 조회, 외부 서비스 호출 시간을 구분하면 원인이 보인다. 초당 요청은 그대로인데 데이터베이스 조회 시간만 늘었다면 WAS를 두 대로 늘려도 데이터베이스 부담만 더 커질 수 있다.
WAS의 작업 스레드와 데이터베이스 연결 풀도 함께 맞춰야 한다. 스레드를 200개로 늘리고 연결 풀을 10개로 둔다면 데이터 조회가 필요한 요청은 연결 앞에서 기다린다. 그렇다고 연결을 무턱대고 늘리면 데이터베이스가 감당하지 못할 수 있다. 요청 대기 시간과 데이터베이스의 활성 연결 수를 보면서 한 번에 조금씩 조정하는 편이 안전하다.
응답 시간은 평균만 보면 느린 요청이 가려진다. 보통은 95백분위 응답 시간과 오류율을 같이 확인한다. 평균이 0.2초여도 20건 중 1건이 5초씩 걸리면 실제 사용자는 답답함을 느낀다. CPU가 지속해서 높고, 요청 대기열도 늘며, 코드와 조회 쪽에서 뚜렷한 병목이 없을 때가 서버 증설을 검토할 시점이다.
이전과 장애 대응은 복구 절차까지 준비한다
WAS서버를 옮길 때는 새 장비의 사양보다 되돌리는 순서가 먼저다. 애플리케이션 버전, 환경 변수, 비밀 정보, 업로드 파일 위치, 데이터베이스 연결 설정을 목록으로 만든다. 새 서버에서 헬스 체크가 통과해도 로그인과 파일 업로드, 결제 같은 주요 흐름은 직접 확인해야 한다. 단순한 첫 화면 응답만으로 이전 성공을 판단하기 어렵다.
데이터베이스를 함께 옮긴다면 백업 파일이 있다는 사실만으로 안심할 수 없다. 별도 환경에 복원해 보고, 복원에 걸린 시간과 데이터가 어느 시점까지 돌아오는지 기록해야 한다. 매일 백업하더라도 사고 직전 최대 하루치 데이터가 빠질 수 있다. 이 손실이 허용되지 않는 서비스라면 백업 주기와 복구 방식을 더 촘촘하게 설계해야 한다.
장애가 나면 최근 배포와 설정 변경부터 확인한다. 그다음 웹서버의 오류 응답, WAS 프로세스 상태, 메모리 부족 여부, 디스크 여유, 데이터베이스 연결과 느린 조회 순으로 좁혀 간다. 무작정 재시작하면 잠시 살아날 수 있지만 원인을 보여 주던 로그와 상태를 놓칠 수 있다. 가능하면 재시작 전에 시각과 지표를 남겨 두는 게 좋다.
운영하면서 가장 아까운 비용은 작은 서버를 쓴 비용이 아니라, 복구 방법을 몰라 멈춰 있는 시간이었다. 필요한 사양은 측정해서 늘리면 된다. 백업 복원과 되돌리기 절차는 평소에 한 번 실행해 봐야 사고가 났을 때 쓸 수 있다.
