[개안뽑] ④죄송합니다, 오늘은 출근 안 해도 됩니다. 제가 서버를 망쳐놨습니다

Picture

Member for

4 months

Real name

Keith Lee

Bio

Head of GIAI Korea
Professor of AI/Data Science @ SIAI

Input

2023-12-01 18:30

호기롭게 서버 이전하다가 망쳐서 하루 날리며 서버 이전을 시작했고,
2주일 만에 일단은 돌아가는데 무리없는 서버를 만들었고,
그 사이에 과거 개발이 만들어 놓은 웹페이지에 대한 불만만 잔뜩 쌓였다

10월 3일까지 서버 공부를 잔뜩 했다고 자신감이 좀 붙었던 그 무렵, 어차피 별 것 없겠지라는 생각으로 10월 7일~9일 연휴 사이에 서버 이전을 싹 완료하겠다고 자신만만하게 떠들었었다.

결과는 오늘 글의 제목에도 나와 있듯이 참혹했고, 10일 새벽에 출근하려는 직원들에게 아예 출근하지 말고 하루 더 쉬어라고 메세지를 보냈었다. 그 날 밤을 꼴딱 샜는데, 아예 우리 서버에 접속조차도 할 수 없었으니까.

만약에 사태에 대비해서 기존 서버에 썼던 NVMe를 그대로 놔뒀었는데, 10일 오전에 이전 서버용 NVMe를 다시 서버에 꽂아넣는데 정말 무력감이 샘솟다는게 이런 기분이구나 싶더라. 난 도대체 뭘 했나? 공부했다더니 시간만 버린건가? 개발자 없이 웹서비스는 커녕 서버 하나도 운용 못 하는 인간인 주제에 서버 이전을 하룻밤 만에 뚝딱 할 수 있다고 그렇게 거만을 떨었나?

출근하지 마세요, 서버 이전에 실패했습니다

10일 오전에 직원들에게 출근 안 해도 된다, 서버에 접속도 못 하는 상태다는 걸 Teams 채널에 쓰고 개인 메세지를 하나하나 보내는데, '병신력'이라는게 이런 거라는 생각이 또 들어서 속이 몹시 쓰렸다. 기존 서버에 쓰던 NVMe를 꽂아 다시 부팅을 하고, 개발자들이 만들어놨던 Apache 서버가 정상 작동하는지 확인하는 명령어를 치는데, 며칠간 쳐다보지도 않았던 Apache 명령어가 기억이 안 나서 구글링을 하는게 더 괴롭더라.

sudo systemctl restart nginx

라고 치는데 며칠간 익숙해져 있었는데, 꼭 1주일 전까지 꾸준히 쳐 왔던

sudo service apahce2 restart

라고 치는게 뭐랄까, 병장 말년에 제대하기 직전인데 갑자기 이등병으로 강등되어서 후임들한테 경례하고 기합받는 기분이라고 해야할까?

버리고 싶었던 웹사이트 접속을 하는 것도 괴롭고, Sucuri한테 방화벽 꺼 달라고 했는데 꺼지지도 않았는지 다시 접속 된다고 방화벽 재적용 된다는 알림 메일이 오는 걸 보고 있는 것도 괴롭더라. 그냥 모든 것이 다 괴로웠다.

일단 옮긴 서버에 접속이라도 되도록 해야겠다는 생각에, 그 날은 온라인으로 일하는 직원들에게 시킬 일만 던져놓고, 사무실 구석에 쳐박아 놨던 TS140을 꺼냈다. 출시된지 10년도 더 된, 내가 평소에 데스크탑 대용으로만 쓰던 서버용 컴퓨터인데, 성능이 안 나와서 이번 서버 리뉴얼에는 쓸 생각조차 안 했던 구형 서버다.

거기에 다시 Ubuntu 22.04를 설치하고, Nginx를 설치하려다가, 아니 이왕 안 되는거 그냥 최신버전을 설치하자고 막 찾아보던 중에, 오늘 새벽까지 망쳐놓은 서버에 설치했던 Nginx의 버전은 얼마였는지 문득 궁금해지더라. Nginx 홈페이지를 가 보니

Stable: 1.24.0 (2023/04/11)
Maintenance: 1.25.2 (2023/08/15)

이렇게 최신버전 날짜가 기록되어 있었는데, 며칠간 끙끙 앓았던 서버에 설치된 버전이

sudo apt-get install nginx

라는 단순한 명령어로 1.24가 아니라 1.18이 설치되어 있던 걸 알게 됐다. 저렇게 기본 명령어를 치면 Ubuntu가 갖고 있는 버전을 그대로 설치하게 되는데, 이걸 최신 버전, 혹은 특정 버전을 설치하고 싶으면 '리포지토리(Repository, 이하 Repo)'를 따로 찾아서 지정을 해야한다는 것을 그 날 처음 알게 되기도 했다.

문득 궁금해서, 우리 직원들이 만들어 놓은 기존 서버에 깔린 LAMP stack은 도대체 버전이 어떻게 되나 봤더니,

Apache 2.2
MariaDB 10.1
PHP 7.4.33

이 설치되어 있더라. 모두 당시 Ubuntu 20.04를 설치할 때 기본으로 지정된 Repo에서 받은 버전들이다.

즉, 그들도 그냥 단순 명령어만 쳐서 설치했지, Repo를 직접 찾아가서 설치하는 일은 없었던 것이다.

DB속도가 느리니까 MariaDB를 여러 대 분산 서버로 쓸 수 없냐는 질문을 한 적이 있었는데, (이쪽 용어로 Scale out이라는 표현을 쓴다) 시간이 많이 걸린다는 답변만 들었는데, 그 날 버전 확인 후에 MariaDB 홈페이지를 찾아가서 보니 관련 기술이 그 이후 버전에서나 적용이 되어 있었고, 처음 설치할 때 아무 생각없이 Repo에서 다운 받은 걸 쓴 게 아니었다면 내가 Scale out을 이야기했던 시점에 훨씬 더 절차가 간편했었을 것이라는 것도 알게 됐다.

Nginx도 별로 뒤 돌아보지 않고 당시 최신 버전이었던 1.25.2를 설치했는데, 이게 또 버전이 업그레이드 되면서 기존에 돌아가던 셋팅이 없어질꺼라고 경고문이 뜨거나 (Deprecated), 아예 오류가 뜨는 경우도 있어서, 어디 돌아다니는 코드를 그대로 복사해서 될 문제가 아니라는 걸 대략 30분 정도의 삽질(?) 끝에 알게 됐다.

나도 겁을 먹고는 Repo에 있는 1.18 버전을 설치할려다가, 이게 도저히 자존심이 허락하질 않아서 1.24 버전을 설치하고 한참을 고생해서 결국 그 날 오후에는 Welcome to Nginx 화면을 볼 수 있었다.

LAMP (LEMP) stack 셋팅

그 다음은 DB와 PHP를 설치해서 워드프레스가 돌아가는 LAMP -> LEMP stack을 완성하는 거였는데, 여기서 위의 셋팅에 따라 DB를 분리하기로 했던 부분이 다시 대두된다.

직원들 출근하지 말라고 했던 날의 좌절감이 너무 커서 설명이 빠졌는데, 워드프레스라는 서비스는 LAMP (혹은 LEMP) stack 위에서 돌아가는 시스템이다. 반드시 L에 해당하는 Linux를 선택하지 않고 윈도우에서 돌리는 WAMP를 하는 경우도 있겠지만, 최소한 LAMP가 표준인데,

Linux
Apache
MySQL
PHP

의 첫 글자를 따서 이름이 붙었고, LEMP의 E는 Nginx를 '엔진 엑스'라고 읽기 때문에 '에'의 'E'를 갖고 와서 이름이 바꿔 붙은 것이다.

나는 Apache가 동적 접속을 지원하느라 정적 콘텐츠를 제공해주는 서비스에서는 큰 이득을 못 본다는 이야기를 듣고 'E'로 바꾸려던 중이었고, Apache가 가장 오래된 서버 기술이라 정보가 매우 많은 반면, Nginx는 상대적으로 역사가 짧은데다, 내가 아예 써 본적이 없던 상황이라 더더욱 힘들었었다. 속도 때문에 Nginx를 욕심냈지만 내가 막혔던 부분 중 하나가 각종 셋팅을 Apache에서 하듯이 .htaccess에서 하는게 아니라 Nginx 전용의 'Server block'이라는걸로 해야되는데, 거기서 @.@ 상태로 긴 시간을 보냈었다.

그 날, 그리고 그 주 내내 계속 Nginx를 PHP와 연동 시키는데서 막히던 중에 한 때는 Nginx보다 더 역사가 짧지만 속도가 훨씬 더 빠르고, .htaccess를 지원해준다는 LiteSpeed를 써 보기도 했는데, 서버 지식이 워낙 부족하다보니 결국 LiteSpeed 셋팅도 제대로 못하고 다시 Nginx로 돌아오기도 했다. 실제로 테스트 서버에서 Nginx를 돌리고 나서 실 서버 위에 기존 우리 회사 서비스들을 옮긴 것은 10월 17일 늦은 밤이나 되어서였다.

그 전까지는 호스팅 업체를 쓰거나 개발이 알아서 서버를 만드는 것만 봤기 때문에 서버를 셋팅한다는 것이 얼마나 힘든 일인지 몰랐는데, 고작 Nginx 하나를, 그것도 테스트 서버에서 돌리는데도 이렇게 힘들다는 걸 그 주간에 처음 알게 됐었다.

나중에 PHP 위에서 돌아가는 웹서버의 모든 콘텐츠를 html로 바꿔 Cache에 얹은 덕분에 웹사이트 서비스 속도를 큰 폭으로 개선한 부분을 공유하게 될 때 자세하게 Nginx 설정에 대해서 공유하는 글을 쓸 생각이다. 10일 이후 여러 사건을 겪으며 LiteSpeed가 유료 버전인만큼 장점은 있지만 Nginx도 그에 못지 않게 훌륭한 서비스라는 것도 알게 됐고, Apache를 몇 년간 별 생각없이 그대로 썼었던 것이 적어도 우리 회사 입장에서는 별로 좋은 선택이 아니었다는 점, 내가 이런 지식이 있었더라면 진작부터 Apache 대신에 Nginx를 쓰자고 하거나 LiteSpeed를 유료로 구매해서 썼겠다는 생각까지 들었었다. 역시 알아야 한다.

Maria DB와 PHP

다음으로 내가 고민했던 것은 Maria DB 셋팅이었다. 참고로 워드프레스가 추천하는 DB는 MySQL인데, Maria DB랑 거의 호환이 되고, MySQL 대비 관리가 잘 되고 무료고 등등의 이유로 쓰는 경우들이 많다. 그간 우리 회사는 DB를 웹서버 컴퓨터에 넣되, NVMe만 다른 디스크를 써서 시스템 읽기 속도를 조금이라도 더 높이자는 전략을 썼었는데, 공부를 하면서 그게 별 이득이 없는 뻘짓이었다는 것을 알게 됐다.

적절한 선택은 웹 서버와 데이터 서버를 분리하고, 두 서버간 연결만 지어놓고, 나중에 DB에 자원이 더 필요하면 DB를 Scale out, 즉 여러대의 서버로 같은 DB를 서비스하는 방식으로 만드는 쪽이 미래를 위해서도, 그 전에 당장 오늘의 서비스 속도를 위해서도 더 나은 방식이더라. 한 컴퓨터 안에서 CPU와 RAM을 자원을 뺏들려고 서로 싸우도록 만들 것이 아니라, 두 컴퓨터에 나눠 놓으면 그 만큼 더 많은 컴퓨터 자원을 써서 원하는 결과물을 뽑아내기 때문이다.

단, DB 정보가 이동해야하니까 두 서버 간의 데이터 이동용으로 내부망을 10G로 하는게 좋다는 추천을 받았는데, 그간 외부망은 기가랜으로 충분해도 내부망은 10G로 해야된다는 말이 무슨 뜻인지 이해를 못하다가 그 자료를 읽던 중에 무슨 말인지 피부에 와 닿더라. 평소에 SIAI 수업 시간에 CPU 코어가 많아도 코어간 데이터 공유하는 방식이 소켓을 잘못 셋팅하면 계산 효율이 떨어진다는 이야기를 해 왔는데, 정작 서버간 연결이라는 쪽으로 지식을 확장하는데서 나는 한 발자국도 못 나가던 바보였던 것이다. (사실 그것보다 DB의 Table마다 Key 값을 어떻게 정하고, Cache를 얼마나 배정해주고, 어떤 Query를 Cache에 집어넣고... 같은 지식이 훨씬 더 DB 속도 효율화에 중요한 정보라는 것을 나중에 알게 됐다는 점도 밝힌다. 이 시점까지도, 사실 지금도, 정말 난 까막눈이(었)다... 쩝)

https://webdock.io/en/docs/how-guides/database-guides/how-enable-remote-access-your-mariadbmysql-database

서버 관련 기초 지식이 피상적인 수준에 불과했던터라 거의 모든 예제 코드들을 다 테스트 서버에서 돌려보면서 작업했었는데, 위의 코드를 따라가면서 DB는 server와 client로 구분되고, 연결하려는 곳에는 client만 설치하면 된다는 걸 알게 됐다. 그리고 그 둘을 연결하는데 위의 이미지에 나온대로 TP-Link의 10G Switch를 써서 두 서버간 연결이 최대한 빠르게 되도록 셋팅했는데, 나중에 알고 보니 내가 쓴 서버 컴퓨터들의 LAN이 10G가 아니라 1G여서 저 Switch가 별 이득이 없더라. 결국 각 서버 컴퓨터에 10G를 지원해주는 PCIe 카드들을 하나씩 사서 꽂았다.

고작 내 컴퓨터 뜯어서 수리나 할 줄 알았지, 네트워크 장비들에 대한 이해가 무지했던 탓에 벌어진 일이다.

그렇게 DB를 분산서버로 옮기는 것 까지는 했는데, 정작 PHP를 Nginx 위에서 돌리는 건 또 다른 문제였다.

PHP-FPM과 FastCGI Cache

Apache를 쓰는 가장 큰 이유가 동적 서비스 지원이고, Nginx는 동적 서비스 지원이 안 되기 때문에 PHP를 설치할 때 PHP-FPM이라는 걸 함께 설치해야 된다, 그리고 Nginx 자체적으로 FastCGI Cache라는게 있다는 문서는 읽었는데, 겨우 Nginx 설치해서 Welcome to Nginx나 봤고, MariaDB를 서버 컴퓨터 2번에 설치하고 연결한 수준인 주제에 이걸 따라가는게 또 하나의 도전이더라.

난 계속 503 Bad connection error 화면만 봤고, 우리 회사 서비스에 내 눈 앞에 있는 서버에 정보가 다 담겨 있는데 정작 나는 접속을 할 수 없는 상황이 계속 반복되었다. 이게 무슨 꼴이람?

처음에는 내가 욕하던 개발자들처럼 나도 그저 어디에서 찾은 설정 값을 복사해 붙여넣기만 바빴는데, 내가 욕하던 사람들이랑 같은 짓을 내가 따라하고 있다는 부끄러운 마음에 문서들을 하나씩 찾아 읽는 걸로 생각을 바꿨다. 이번에 설정한다고 끝이 아니라, 계속 내가 손을 봐야되는 서버잖아?

계속 자료를 찾아 읽던 중에, FPM라는 서비스가 무슨 역할을 해서 Nginx를 연결해주는지, 그래서 Nginx의 'Server block'이라는 곳 중 어디에 어떻게 정의를 해 줘야 하는지, FastCGI Cache라는건 뭔지, 2 layer cache라는건 뭔지 등등을 읽어가며 셋팅 값을 계속 조절했는데, 이건 10월 18일 새벽에 서버 이전했다고 직원들한테 알리고 난 다음에도 1달 동안 계속해서 설정 값을 바꿔야 했었다.

그 사이에 다른 프로그램들이 설치될 때마다 서버 접속 속도가 현격하게 느려지는 일도 자주 발생했고, 워드프레스를 쓰고 있는 직원들이 파일 업로드가 안 된다, 글 저장이 안 된다, 새 글 쓰기 창을 여러개 열었는데 계속 같은 글 위에 덧 씌우기만 반복된다 같은 수 많은 '버그 리포트'를 받았기 때문이다.

듣고 원인을 찾아서 다시 들어가보면 거의 대부분은 'Server block'에 값 하나를 내가 잘못 베껴 붙였거나, 우리 회사 사정에 안 맞는데도 불구하고 갖다 썼거나, 더 심하게는 시스템을 망치는 형태로 셋팅해놨기 때문이라는 걸 알게 됐다. 그런 걸 하나씩 찾을 때마다 이런 허접 서버를 쓰고 있는 직원들에게 미안하다는 생각도 들었고, 짜증날텐데도 큰 불평없이 묵묵히 일해주는 분들께 정말 고개를 들 수가 없었다.

어느 정도 기초 셋팅이 됐던 10월 24일, FastCGI Cache가 이제 제대로 돌아가는 것 같아서 파이낸셜 이코노미 웹페이지를 구글 페이지 스피드에 넣어봤다.

난 그전까지 한번도 성능에서 90점은 커녕 80점도 받아본 적이 없었다. 국내 최대 사이트인 네이버, 카카오의 홈페이지 점수를 보시면 알겠지만, 우리나라 웹사이트들 대부분이 점수가 높은 편이 아니다.

저 Lighthouse 기능을 처음 알게 된 게 2020년 초에 우리 회사에 있던 개발자 덕분이었는데, 그 때 우리 회사 웹사이트가 받은 성능 점수는 60점대 중반으로 기억한다. 뒤에 있는 접근성, 권장사항, 검색엔진 최적화도 매번 점수가 형편없이 나왔고, 구글의 서치 콘솔에도 매번 우리 회사 사이트가 온갖 문제가 다 있다는 지적만 받았는데, 평균 90점이 넘게 나오는 건 저 날 처음 겪었다.

Nginx의 FastCGI Cache라는게 이렇게 좋은 거구나, 저렇게 웹페이지에 이미지를 잔뜩 넣어서 무거워졌는데도 불구하고 쉽게 성능 점수를 낼 수 있구나는 생각도 했고, 워드프레스가 역시 구글 검색 엔진이 좋아하는 각종 SEO 셋팅을 기본으로 갖고 있고, 내가 테마를 잘 고르고 디자인이 잘 작업해준 덕분에 기본만 해도 평균 90점을 넘길 수 있는 서비스가 됐다는 생각에 뭐랄까... 감동의 쓰나미? 같은게 밀려왔다.

서버 이전한다고 호언장담했던 대표가 그래도 2주일간 꾸역꾸역 작업해서 저렇게 갖고오니 직원들도 이젠 서버에 이상한 일 안 터지고 잘 작업할 수 있겠지? 라는 안도감을 보여줬던 기억도 있다.

장막 뒤에서 있었던 삽질

뒤에서는 온갖 종류의 문제들이 연이어 터졌었다. PHP를 처음에는 8.1을 설치했다가 8.2로 올라가면서 약간 성능 개선이 더 있었다는 글을 보고 PHP 버전 업그레이드를 했더니 갑자기 서버 접속이 안 되더라. 그 때도 오전에 1시간 남짓 서버 접속을 못했었는데, 그래도 그간 경험치가 쌓인 덕분인지 후닥닥 PHP를 전부 다 삭제하고, 불안 하니까 서버 재부팅을 한번해서 PHP 8.2를 새로 설치했는데, 다행스럽게도 서버 접속은 원활하게 됐었다. 근데 PHP8.1-FPM이라고 써놨던 Nginx의 'Server block'을 안 고친채로 그대로 돌아간 탓에 서비스 접속이 괴상(?)하게 됐는데, 번쩍 8.1이라고 썼던 기억이 나서 그 설정 파일을 후닥닥 찾아 고쳤던 기억도 있다.

그 사이에 서버 보안은 몰라도 워드프레스가 추천하는 기본 보안 설정들은 하나씩 다 해 줬는데, 역시 10월 24일에 웹사이트 성능 테스트를 하면서 처음으로 '사이트 건강 상태'에 '양호'라는 메세지를 보게 됐다. 그 날 내가 회사 게시판에 쓴 메세지가

저 '양호' 띄우는게 그간 불가능했는데, 사업시작하고 만 5년만에, 워드프레스 갖고 논지 6년만에 처음으로 저 상태로 끌어올렸습니다.

구글 페이지 스피드에서도 디자인 작업 빼면 나머지는 안정적으로 90점을 넘는군요. 70점 넘기도 힘든 웹사이트 돌리고 있었는데ㅋㅋ 저거 100점 받는게 꿈의 점수인데...

였는데, 전문가 분들이야 어떻게 생각할지 모르겠지만, 그간 우리 회사에 어떤 개발자가 와도 저걸 '양호', 평균 90점으로 만들어 내 준 분이 없었다. 혼자서 서버 갈아엎겠다고 시작한지 1달이 채 되지 않은 시점에 (눈에 보이지 않는 수 많은 부분이 매우 조잡한 상태이긴 했지만) 저걸 만들어내고 나니, 그 때부터 내가 개발을 왜 뽑았었었나는 아쉬움, 후회, 괴로움 같은 게 밀려왔었다.

특히, 10월 24일 이틀 전인 22일에 이전에 공유했던대로 SIAI 홈페이지에 이미지 주소들을 이미 없어진 스위스 웹사이트 주소를 그대로 넣어놨던 탓에 접속 속도가 매우 느렸었던 상황을 확인해서 더더욱 괴롭더라. 난 도대체 누구를 믿었어야 했나?

저 때도 수 많은 문제를 겪고 있었고, 지금 글을 쓰는 이 시점에도 여전히 수 많은 문제가 산재해 있다. 어쩌면 모든 걸 다 못 고칠 수도 있고, 고친다고해도 적지 않은 시간이 들 것이다. 보통은 이런 상황이면 사람 1명 뽑자, 혹은 여러 명 뽑아야 된다, 외주 서비스를 써야 한다는 이야기가 나오고, 나도 거기에 귀가 얇아질 것 같은데, 내가 그간 뽑았던 개발자가 몇 명이지? 뽑아서 될까? 너무 회의적인가?

그렇게 4일간 바뀐 성능을 체감했던 직원들이 금요일에 남긴 업데이트로 오늘 글을 마무리한다.