[개안뽑] ⑩가볍게, 더 가볍게, 다 분리해야 가벼워진다

웹서비스 속도를 유지하려면 최대한 모든 기능을 분산시켜야
분산 서버 기술을 적용하는 것도 점점 쉬워지는 시대가 왔음
공부 안 하는 개발자, 예전에 머물러 있는 인력을 쓰지 말고, 빠르게 습득하는 개발자를 찾아야 함
굳이 한국에서 유니콘을 찾는데 돈과 시간을 쓰지 말고, 해외로 고개 돌리면 거기는 이런 능력이 상식임

앱 서비스를 하나 출시하고 사용자가 안 모여 골머리를 앓던 시절, 웹서비스로 확장하자고 개발들을 들들 볶았는데, 시간이 없으니까 워드프레스랑 연결시키자면서 DB만 연동시켜서 웹서비스를 출시했었다.

근데, 웹서비스에는 하루 유저가 1만명, 나중에는 10만명씩 몰려드는데 앱에는 가입자들이 거의 없더라. 결국엔 그 사업을 접었는데, 그 때 경험이 지금의 언론사 방식 웹서비스로 회사 방향성을 결정하는데 큰 영향을 줬다. 어떤 정보를 갖고 있고, 아무리 구글SEO를 잘 해놨더라도 언론사 기사들이 쏟아져 나오기 시작하면 구글이 더 상위에 배치해버리더라. 고생했지만 물거품이 된 셈인데, 언론사들이 하루 몇 백개 이상의 기사들로 이미 구글SEO 점수를 탄탄하게 받은 상태니까, 신생 회사가 따라가기가 쉽지 않았던 것이다.

그런 도전 와중에, 웹사이트 로딩 속도를 개선하겠답시고 여러 도전을 했었는데, 당시 개발팀장을 하시던 분이 이렇게 이야기하시더라.

좀 찾아보니 워드프레스도 웹서버 분산 처리하고, DB도 분리하고, 앞에 HA Proxy 붙이고… 이런 거 다 할 수는 있네요. 워드프레스로 저걸 할려면 새로 다 배워야 하는데, 그렇게 개발하느니 굳이 워드프레스 말고 다른 걸로 개발하는게 더 나을 것 같기는 한데…

시스템을 가볍게, 더 가볍게

사실 그 때 처음으로 분산 서버를 왜 해야되는지, 대형 네트워크 기반 시스템이 왜 필요한지, ‘최적화’라는게 단순히 프로그램을 잘 만드는 것 이상으로 복잡한 네트워크 도전이라는 것을 알게 됐다. 당시에는 돈을 좀 쓰더라도 저 사람들이 원하는대로 새로 시스템을 만들어야하는가는 생각도 많았는데, 오늘 글을 다 읽고 나면 이해되겠지만, 그 시점에 난 인력들을 다 내보내고 내가 모든 서비스를 직접 만들었어야 했다.

당시엔 타협점으로 워드프레스를 그대로 유지한 상태에서 매우 단순하게나마 3대의 소형 서버 컴퓨터를 Switch에 물리고, 하나의 독립 서버가 트래픽을 3대에 분리해주는 ‘분산 서버’를 구축하기는 했었는데, 제대로 돌아가지도 못했고, 그 서비스는 유저들이 올리는 음란물 관리에 실패해 결국엔 구글 서치 콘솔에서 확인한 SEO 점수가 0점으로 떨어지는 폭탄을 맞았었다.

유저들에게 글 올리는 기능을 원천적으로 차단하고, 댓글 기능도 엄격하게 막지 않으면, 아니 관리 인력을 24시간 풀 타임으로 빡빡하게 돌리지 않으면 온갖 음란물로 시스템을 망치는 인력들을 피할 수 없을 것 같다고 생각하는 중인데, 어차피 그런 조잡한 콘텐츠 올리는 인간들 아니면 고급 콘텐츠를 만들어 낼 능력이 없는 나라에서 굳이 그 쪽으로는 더 시간을 쓰지 말자는 결론을 얻게 됐었다. 차라리 영어권에 비슷한 서비스를 제공해주고, 가입자들에게 몇 단계의 인증 절차를 거쳐서 비슷한 진상 짓을 하면 법적으로 막대한 손해배상 소송을 맞도록 해 주는게 더 낫겠더라.

문제는 가입자들에게 여러 단계의 인증 절차 시스템을 만들어 붙이는 일이다. 갖다 쓸 수 있는 해외 솔루션은 널려있지만, 뭘 하나를 붙일 때 마다 서비스 속도는 계속 느려진다. 그런 단점을 어떻게 하면 최소화할 수 있을까?

뭐든지 분리할 수 있는 것들은 다 분리한다

워드프레스는 1개의 서버 위에 1개의 워드프레스를 설치하고, 그 위에서 모든 기능을 다 돌리는 방식으로 구성되어 있다. 때문에 몇 개의 무거운 플러그인만 얹어도 서비스가 느려질 수밖에 없는데, 해결책은 위의 개발팀장님이 말씀하셨던대로 각종 기능들을 분산하는 것이다. 이게 개발팀이라는 사람들이, 특히 ‘짬이 쌓인’ 개발자들이라는 사람들이 하는 ‘속도 개선’ 작업 중 일부다.

내가 가장 먼저 진행했던 것은 ‘데이터베이스(DB)’ 분리였다.

워드프레스가 기본으로 쓰는 DB가 MySQL인데, 호환성이 높다고 알려진 (and 속도가 눈곱만큼 더 빠르다는) MariaDB로 바꿔 설치했고, 그 DB를 워드프레스가 설치된 웹 서버와 다른 ‘데이터 서버’에 설치해서 서로 연결만 시켜놨다. 서비스가 작을 때는 큰 문제가 안 되지만, 지금 파비리서치만 해도 DB가 1GB가 넘기 때문에 데이터 로딩에 상당한 시간이 걸린다. 물론 각종 최적화를 통해 모든 데이터를 불러오는게 아니라 필요한 데이터만 불러오는 방식을 쓰고 있기는 하지만, 같은 서버에 두 프로그램을 설치해놓으면 두 프로그램이 서로 하드웨어 자원을 차지하기 위해 싸우기 때문에 느려질 수밖에 없다.

깔끔하게 병렬처리가 되어서 웹 서버와 데이터 서버가 같이 일을 하고, 결과물을 결합해서 서비스에 쓰이면 참 좋겠지만, 그렇게 고급 프로그래밍을 하기는 만만치 않다. 아예 소켓을 분리해서 CPU와 RAM을 특정 기능에 배분해버리는 방식으로 1개 컴퓨터를 가상의 N개 컴퓨터로 만들 수는 있겠지만, 심지어 개발자들이 좋아하는 도커(Docker)로 실험도 해 봤지만, 그다지 큰 성능 개선 효과를 못 봤다. 내가 더 잘 알았으면 굳이 ‘실험충’이 되지 않고 논리적으로 성능 개선 효과가 그다지 크지 않겠다는 것을 바로 판단했을텐데, 역시 무지는 죄다. 이후 도커는 설정 환경이 완전히 달라지는 탓에 다른 설정과 충돌이 일어날 것이 예견되는 곳에만 쓰는 것으로 관점을 바꿔 버렸다.

데이터 서버, 검색 서버, 결제 서버, 이미지 서버… 분리할 내용들이 왜 이렇게 많을까?

우리 언론사 및 블로그를 묶어 파비리서치로 만들었을 때만해도 도커를 썼는데, 이걸 데이터 서버로 이전하고 나니 확실히 컴퓨터에 주는 부하도 크게 줄어들었고, 성능상의 개선도 피부로 체감이 됐다. 무거워져도 데이터 서버만 힘들지, 웹서버는 힘들 이유가 없는 상황이 된 것이다.

그 다음 내가 도전하려고 했으나 아직 마음에 들게 진행이 안 된 것이 이미지 서버 이전이다. 이미지 파일이 언론사 마다 심한 경우에는 50GB가 넘는데, 폴더 하나에 몰려있는 경우에는 그 폴더를 읽는데도 엄청난 시간이 걸린다. 파일 I/O가 이렇게 무거운 상황이 생기는 것을 피하기 위해 폴더들을 다 분리했고, 분리해도 무거운 폴더들은 더 폴더들을 잘게 쪼갠 다음, 아예 DB에 기록된 이미지 파일 저장 위치도 변경해버렸다.

처음에는 괜히 DB를 뜯어고치다가 큰 문제가 생길까봐 플러그인을 썼는데, 더 이상하게 서비스를 꼬아버리길래 결국은 내 손으로 직접 DB 값을 뜯어고치게 됐다. 그 플러그인 작성자에게 너네 서비스 이상하다고 많이 화를 냈는데, 언젠가는 고쳐놓겠지?ㅋ

그렇게 분리해도 여전히 마음에 안 드는 상태라 외부의 CDN (Contents Delivery Network)이라는 것도 여러 개를 테스트 해 봤는데, 이 글을 쓰는 시점에는 Cloudflare라는 서비스를 쓰고 있다. 우리 회사 서버 앞에 설치되어서 이상한 트래픽은 알아서 걸러주고, 웹페이지들은 ‘캐싱’해서 들고 있다가 같은 정보라면 보여주는 방식으로 서비스 속도를 개선할 수 있단다.

해외 커뮤니티들을 보면 CDN으로 Cloudflare를 추천하는 경우가 많은데, 캐시된 콘텐츠를 보여주는 비율인 ‘Hit’이 그렇게 높질 않아서 당장 서비스 로딩 속도에 큰 도움은 안 되는 상황이다.

예전에 우리 개발팀이 붙여놨던 Amazon S3가 또 생각이 나긴 하는데, 어떤 달은 8만원, 또 어떤 달은 35만원, 이런 식으로 들쭉날쭉하게 비용이 왔다갔다하던 S3를 굳이 다시 쓰고 싶은 생각은 없다.

괜찮은 NVMe를 Raid 1번으로 연결해서 자료가 날아가는걸 방지하려고 4x4x4x4 카드를 하나 구매 해 놨는데, 오류가 나서 아직 이전이 마무리 안 된 상황이다. 저게 깔끔하게 이전이 되고나면 이미지 파일 불러오는 것도 웹 서버가 하는게 아니라 다른 서버가 처리하니 그만큼 로딩 속도가 더 빨라지겠지. Amazon S3 쓰는게 더 비용이 저렴하지 않냐고? 컴퓨터 한 대가 고작 50만원 남짓이고, 전기세라고 해봐야 5만원도 안 되는데, 한 달 요금이 고무줄처럼 왔다갔다 하는 외부 클라우드 서비스 쓰기 싫다. 3달만 지나도 내가 직접 셋팅한게 비용이 더 저렴할 것이다.

검색 서버는 Elastic search, 결제 서버는 Rest API로 연동

워드프레스가 지원해주는 검색 기능은 MySQL (혹은 MariaDB)의 기본 검색 기능이다. 매우 느리고, 서비스에 부하도 많이 준다. 안 그래도 DB가 할 일이 많은데, 검색까지 계속 돌아가고 있으면 성능 압박은 더 심해질 수밖에 없다.

이걸 어떻게 해결해야 할까?

예전에 내부에서 자체 검색 엔진을 만들겠다고 Elastic search를 한참 봤던 적이 있다. 물론 진짜 구글, 네이버를 따라 잡겠다는 생각으로 만든 서비스는 아니고, 우리 회사 서비스들을 묶은 검색 엔진을 하나 만들어 볼려고 봤던 건데, 무리할 것 없이 모든 기사들을 JSON파일로 압축해서 던지고, 그걸 Elastic search에서 검색하도록 만들어주면 DB가 일을 하는게 아니라 Elastic search가 일을 하는 방식이 되어서 서비스를 좀 가볍게 돌릴 수 있겠더라.

이것도 굳이 무리할 것 없이 플러그인을 하나 쓰면 간단하게 해결이 된다

ElasticPress – WordPress plugin | WordPress.org

저 검색이 카테고리 검색, 태그 검색 등등의 매우 상세한 검색들을 다 지원해주는데, 계속 바빠서 메뉴를 못 만들어 넣는 중이다. 조만간 해결이 되겠지.

또 결제가 서비스를 엄청나게 무겁게 만들었던 기억이 있어서, 이번엔 워드프레스 결제 기본 플러그인인 ‘우커머스(Woocommerce)’를 어떻게 분리할 수 있는 방법이 없을까 한참을 찾아봤다.

워드프레스가 좋은게, 이렇게 누군가 찾고 있으면 자기가 돈 벌고 싶은 애들이 관련 기능들을 다 만들어놓고, 무료 버전으로 약간 기능을 풀고, 고급 기능들은 유료 버전으로 바꿔놨다. 여기도 Zapier부터 시작해서 유사한 서비스들이 치열하게 경쟁하는 시장이더라.

그래서 결제만 담당하는 웹페이지를 아예 따로 만들고, 우리 서비스와 Rest API로 연동시켜줬다. 이걸 개발을 시켜놨을 때는 앱 사용자들에게 푸시 메세지 하나 보내는 것도 Rest API를 썼던 기억이 나는데, 기능 개발에 시간이 걸리니까 날 더러 직접 Rest API에 접속해서 메세지를 보내는데 쓸 수 있는 Postman을 깔아라고 했던 기억도 있다.

이번엔 플러그인에 $50 남짓만 주면 간단하게 한 웹사이트가 다른 웹사이트와 연동하는 Rest API를 붙일 수 있게 됐다.

더 이상 결제 때문에 웹사이트가 느려질 이유가 사라진 것이다.

분리형 서버 만들기가 어렵지 않은 시대

아마 위의 내용들이 무슨 말인지 이해가 안 되어서 ‘개발 어렵네’라고 생각하는 분들이 꽤나 될 것이다. 한국인의 종특이다. 비전문가인 나 같은 사람이 이렇게 쉽게 했다고 주장하면 잠깐의 검색으로 정보 습득을 하고 저 사람이 어떤 작업들을 했는지 가늠하는 것이 상식일텐데, 한국은 그런 상식이 작동하질 않더라. 생각하기 싫으니까 누군가에게 일을 시켜야 된다는 말을 서슴없이 내뱉고, 그 전에 뭔가 찾아서 읽고 이해할려는 의지가 있는 인력이 거의 없다.

그런데, 찾아서 읽으려는 의지만 있으면 개발자 10명을 투입해서 3달이나 걸렸던 그 분산 서버를, 혼자서 1~2달 만에, 그것도 풀 타임이 아닌 상태에서, 훨씬 더 고차원적으로 돌릴 수 있을만큼 쉽게 작업할 수 있도록 정보가 널려있다. 단지 한국어로는 그런 자료가 희귀할 뿐이다.

개발자 다 됐네

개발에 돈 왜 썼냐? 첨부터 네가 하지

와 개발 진짜 별거 아니네, 너만큼은 아니겠지만 나도 하겠다

주변에서 이런 표현들이 나오는 것은, 그래도 주변에서는 영어로 문서를 읽고 이해하는데 큰 어려움이 없는 사람들, 평소에 찾아서 읽는 것이 습관처럼 된 인력들이 있기 때문일 것이다.

그러나, 한국인의 종특상 개발자라는 사람들 중에 자기 분야인데도 위에서 내가 한 것과 같은 작업에 관련된 정보를 검색하고, 혼자서 이것저것 해 보면서 이해하는 사람을 찾기는 쉽지 않다. 영어로 된 문서를 읽고 이해할 수 있는 능력이 ‘프리미엄’인 것 이전에, 아예 무슨 일이건 딱 주어진 설명서대로 그대로 따라가는 것에서 탈피할 수 있는 인력, 한국어로라도 좋으니까 자료를 찾아서 읽고 지식의 지평을 늘릴 수 있는 인력도 거의 없는 것이 한국인 인력들의 현실이다.

물론 한국인 개발자 중에 아닌 사람들, 내 힐난에 억울한 분들도 있겠지. 근데 그런 분들 찾는 검색 비용을 쓰느니, 위에 쓴 것과 같은 만만한 업무들은 해외 개발자를 쓰거나, 이미 모든 걸 다 갖춰놓은 해외 호스팅 서비스를 쓰는 편이 백번은 더 맞는 전략이다.

요즘 인기리에 방영 중인 고려거란전쟁의 주인공 중 한 사람인 고려 현종은 자녀들까지 모두 명군으로 역사책에 기록되어 있고, 실제로 귀주대첩 압승 이후 1020년~1100년까지 고려는 전성기를 구가했다. 근데 그 명군으로 기록된 현종의 후예들은 평소에도 책을 놓지 않고 열심히 공부한 황제들이었는지, 오죽하면 ‘글 읽기를 게을리하는 인재는 필요없다’는 기록들이 남아있을 정도다. 지식의 성장 속도가 지금보다 터무니 없이 느리던 그 시대는 말할 것도 없고, 요즘 같은 시대에 읽지 않는 인재, 읽을 능력이 없는 인재들에게 돈을 쓰고 받게 되는 서비스는 실패작이 되거나, 성공하더라도 2023년, 2024년의 서비스가 아니라 2015년 이전의 서비스 수준을 받게 된다.

바보에게 돈을 쓰는 것이 진정한 바보다. 나는 바보였다.