cafe24 호스팅을 떠나며

끝났다.

처음부터 “끝났다”로 시작하니 무슨 말인가 싶은 사람들이 많을 것이다. 그런 사람들을 위해 캡처 화면 하나를 준비했다. 워드프레스는 아직 해지 신청이 완료되지 않은 상태의 캡처지만, 이미 이 글을 AWS 서버에 올린 상태로 쓰고 있으니 사실상 해지했다고 봐도 무방하겠다.

그렇다. 이 글은 cafe24 호스팅을 떠나며 그동안의 소회를 적는 글이다.

문제의 시작

필자는 독서일기 앱을 개발하면서, 애플리케이션 쪽에서는 기본 처리만 하고 서버에서 iOS와 AOS를 공통으로 처리하는 구조를 쓰고 있다. 시간을 따져보면 참 오래됐는데, 8년 전 cafe24 호스팅을 통해 올려놓은 Java 서버를 지금까지 그대로 사용해왔다.

문제는 그 사이 기술이 너무 많이 발전했다는 점이다. 이제는 사용자가 로그인할 때 암호화된 비밀번호를 해제하는 정도의 작업에서도 OOM(메모리 부족 오류)이 터지기 시작했다. 근본 원인은 명확했다. 기반이 Java 1.8에 Tomcat 8 버전이었으니, 확장성은커녕 서버 사양 업그레이드 자체가 시급한 상황이었다. 여기에 별도로 운영하던 DB 호스팅도 MySQL 중 상당히 구형 버전이라 함께 발목을 잡고 있었다.

이 글은 이런 사양 문제로 시작해서 결국 AWS까지 흘러 들어오게 된 과정을 편하게 풀어보려 한다. 혹시 비슷한 고민을 하는 사람이 있다면 도움이 되길 바란다.

서버 사양 변경

가장 먼저 시도한 것은 기존 서버의 사양 변경이었다. 우선 이 지긋지긋한 Java 1.8과 Tomcat 8 버전에서 벗어나야 했다. 정작 필자가 쓴 글 중에는 Java 21에 대한 글도 있는데, 막상 본인 서버는 Java 1.8이라니. 아무리 생각해도 더는 미룰 수 없는 문제였다.

그래서 cafe24 공식 가이드대로 업그레이드를 시도했지만, 예상 밖의 벽에 부딪혔다. 필자의 서버는 현재 버전 이상으로 업그레이드가 불가능한 상품이었던 것이다.

바로 1:1 문의를 남겨본 결과, 필자가 사용 중인 JSP 광호스팅이라는 상품은 현재 판매하지 않는 구형 상품이라 사양 업그레이드 자체가 불가하다는 답변을 받았다. 짐작해보면 단독 상품이었다면 업그레이드에 무리가 없었겠지만, 한 서버를 여러 명이 나눠 쓰는 공유 호스팅 구조상 내 사양만 따로 올리는 게 불가능했던 모양이다. 차라리 현재 운영 중인 Java 17 버전 호스팅으로 계정을 옮겨주면 좋았을 텐데, 그런 서비스는 제공하지 않는다는 점이 아쉬웠다. 이후 결제한 상품의 가격이 기존과 동일했기에 더 아쉬운 마음이 들었다.

cafe24의 답변은 결국 “신규 상품을 신청하라”였다. 이미 Tomcat 10.0.x, Java 17 기준으로 로컬과 개발 환경 점검을 마친 상태였기 때문에 딱히 망설일 이유는 없었다. 신규 서버를 결제하고 세팅을 마치니 확실히 쾌적해졌다. 사실 고백하자면 기존 서버에는 더 이상 쓰지 않는 테스트 소스도 꽤 쌓여 있었는데, 이번에 사양을 올리면서 불필요한 자원도 함께 정리한 덕분인지 WAR 배포 속도부터 기존보다 빨라진 게 체감됐다.

접속 불능

문제는 여기서 끝나지 않았다. 소스를 배포하고 서버를 기동시켰는데, 분명 서버는 올라왔지만 접속이 되지 않았다. Forbidden 오류가 떴다.

일단 서버 자체의 문제는 아니었다. 인증서를 확인해보니 와일드카드로 cafe24 호스팅에 정상적으로 붙어 있었고, HTTPS 연결도 됐고 인증서 상태도 정상으로 보였다. 그런데도 접속이 안 됐다. nginx 설정 문제인가 싶어 cafe24에 문의를 남겼다. 접속 불가 같은 이슈는 24시간 대응이라고 알고 있었는데, 실제 답변은 다음 날 오전 9시가 넘어서야 왔다.

그마저도 처음 받은 답변은 황당했다. 담당자는 소스를 배포하지 않고 접속을 시도해서 그렇다고 했다. 분명 WAR 배포 로그와 초기 캐시 갱신, 서버 Started 로그까지 다 확인한 상황이었는데 소스를 안 올렸다는 답변이 돌아오니 어이가 없었다.

재문의 끝에 담당자는 앞선 답변이 착오였다고 정정했다. 제대로 확인하지 않고 답변한 것으로 보이지만, 일단 착오였다고 해두자. 최종 확인 결과는 이랬다. 와일드카드로 잡힌 SSL 인증서 자체가 잘못 설정된 것이고, JSP 호스팅 상품은 애초에 인증서를 제공하지 않는 상품이라 접속이 안 되는 것이었다.

도메인 이전 문제

시간을 날린 게 아쉬웠지만 이미 결제한 이상 서둘러 이전을 진행해야 했다. 기존 도메인의 DNS 전환과 인증서 재발급 작업을 검토했는데, 여기서 또 다른 문제가 나타났다.

도메인의 DNS는 필자가 직접 전환하면 되지만, 인증서는 cafe24를 통해서만 발급받을 수 있는 상품이었다. 지금 라이브 서비스가 돌아가고 있는 상태에서, 도메인을 전환하기 전에는 인증서 설치 자체가 불가능하다고 했다. 즉 DNS를 옮기는 순간 HTTP 연결만 되는 상태로 바뀌는 것이다. 인증서를 빠르게 설치해도 한 시간은 걸린다고 하니, 그 사이 서비스 중인 사용자들이 겪을 문제가 눈에 뻔히 보였다.

그래서 신규 도메인을 하나 구매하고 거기에 인증서를 발급받는 방법을 택했다. 그 도메인이 지금 메인으로 쓰고 있는 readiary.kr이다. 신규 도메인에 인증서까지 한 번에 설치하니 한 시간 남짓 걸렸다. 만약 기존 도메인을 그대로 전환하면서 인증서까지 새로 신청했다면 그 사이 서비스가 상당히 불안정했을 것이다. 결과적으로 돌아보면 신규 도메인을 택한 게 옳은 선택이었다.

후속 처리

문제는 여기서 끝이 아니었다. 작업을 마치고 나니 기존 서버와 도메인이 계속 눈에 밟혔다. 이걸 그냥 폐기(decom) 처리해야 하나 고민했지만, 도메인도 기존 용도로는 더 이상 쓸 수 없게 되어 사실상 유휴 상태가 된 참이었다.

고민 끝에 기존 서버는 배치(batch) 전용으로 돌리기로 했다. 배치 작업은 외부 접근을 차단하고 내부에서만 처리하면 되니 문제가 없었다. DB도 애초에 신규 호스팅 내부가 아닌 별도 DB 호스팅을 쓰고 있었기 때문에 접근성 문제도 없었다.

그래서 소스 분리 작업에 들어갔다. Git으로 브랜치를 따서 작업했기 때문에, 기존 Java 1.8 소스에서 배치 기능만 남기는 작업은 어렵지 않게 끝났다.

배치를 기존 서버에 올리고 정상 동작까지 확인하면서, 1차로 진행하려 했던 API 서버 사양 업그레이드는 이렇게 일단락됐다.

다음 편에서는 AWS로 옮긴 이후에도 다시 발생한 OOM 문제와, 결국 AWS Lightsail로 옮기게 된 과정을 다룰 예정이다.