안녕하세요
요즘 로드밸런싱에 관심이 많아져서 찾아보고 있습니다.
다름이 아니라 로드밸런싱을 할 경우에는 서버를 여러개 생성을 해서 트래픽을 분산해주는 것이라고 알고 있는데, 이럴 경우 각 서버의 파일들은 어떻게 동기화 하는지 궁금합니다
각 서버들의 파일들이 각각 있어서 실시간으로 동기화 되는건지, 하나의 파일 서버가 모든 서버에 연결되어 있어서 파일을 통합적으로 관리하는 것인지 궁금합니다
-
?
Lv10 로드 밸런싱을 하는 경우 어디까지나 아파치 웹서버와 PHP의 처리능력만 늘어납니다.
DB는 반드시 별도서버로 둬야하고 업로드된 파일 역시 로컬에 저장하면 안되고
웹서버들끼리 공유할 수 있는 공간에 올려놔야 하죠. NFS이건 오브젝트 스토리지이건...
업로드된 파일의 다운로드는 CDN을 이용하면 성능 문제는 걱정할 필요없구요.
다만 그외 파일들은 전혀 공유할 수 없습니다. 그냥 똑같은 스태틱 파일들과 PHP 소스가여러대의 웹서버에 똑같이 존재하고 있는겁니다.
즉 캐쉬와 세션은 웹서버끼리 공유가 안됩니다.
그러므로 세션의 경우엔 DB기반 세션으로 바꾸던가(속도를 생각한다면 멤캐쉬나 REDIS 같은걸로..
아마 php.ini에서 옵션 바꾸면 세션을 간단히 멤캐쉬 기반으로 바꿀 수 있을텐데 그외엔 잘 모르겠네요.)
아니면 세션을 포기하고 쿠키에 의존하는 시스템으로 완전히 바꿔야만 합니다.
그리고 캐쉬 공유가 안되므로 캐쉬로 인해서 서로 다른 2 사용자가 동시에 서로 다른 화면을 볼 수 있습니다. 대개의 경우 별 문제는 안됩니다만 주의해야겠죠. 아니면 캐쉬도 별도의 멤캐쉬 서버를 구축해서 웹서버들이 함께 캐쉬를 공유하는 식으로 갈 수도 있겠지요. -
?
Lv10 
Lv7 우선 좋은 답변 감사드립니다 :D
웹서버랑 PHP의 처리능력만 늘어나는 것이군요
변동이 일어나는 파일은 모두 NFS같은 곳으로 보내야 하는 거구요...
그런데 NFS도 수용 능력에 한계(?)가 있을것 같은데
파일서버에 부하가 발생했을 경우에는 파일 종류(영상,이미지,텍스트)별로 나누어서 파일서버끼리 또 로드밸런싱을 해주나요?
예를 들면 서버 하나로는 도저히 버틸 수 없을 것 같은 유튜브 같은 곳은 파일 서버가 한곳이 아닐것일텐데....
이런 경우에는 랜덤으로 부하가 적은 파일서버에 업로드 한 후 불러올 때 업로드한 서버 주소를 가져오는 곳인가요? -
?
Lv10 
Lv37 세션과 캐시는 말씀하신 것처럼 memcache나 redis를 공유하면 그만입니다. 그런데 XE는 캐시 데이터를 memcache에만 저장하지 않고 files/cache 폴더 아래에도 온갖 잡다한 캐시파일들을 만들어놓고 써서 문제예요. 이 녀석들은 도저히 공유가 안 됩니다 ㅠㅠ
-
Lv7
Lv37 유튜브가 어떤 식으로 구현되어 있는지는 구글 내부자만 알겠지만... 원론적으로 생각해 보면 파일서버라는 것 자체가 따로 없을 겁니다. 구글은 이미 물리적인 장비 단위에 신경쓰는 레벨을 넘어선 지 오래 됐거든요. 백만 대를 묶어서 오브젝트 스토리지 서비스를 구축해 놓고, 하루에 천 대쯤 고장나도 상관없는 뭐 그런 경지에 다다르면 개별 서버는 직원 화장실의 휴지만큼도 신경쓸 가치가 없는 물건이 되어 버리지요. 실제로 서버 하나 고장난 것은 수리할 생각도 안 하고, 컨테이너 안에 있는 서버들 중 일정 비율 이상 고장나면 컨테이너를 통째로 갖다버린다고 하더군요. ㄷㄷㄷ
그리고 원본 파일이 업로드되어 있는 곳에는 절대 일반 유저들이 직접 접속할 수 없도록 되어 있을 겁니다. 여러 단계의 캐시를 거쳐서, 최종적으로 유저에게 노출되는 곳에 사본을 만들어 놓고 그것만 보여주겠지요. 국내에도 몇몇 통신사와의 계약으로 유튜브 캐시 서버가 구축되어 있다고 들었습니다.
여러 서버의 파일들을 실시간으로 동기화하기는 무척 어렵습니다. 몇 분 간격으로 동기화하는 솔루션은 많지만, XE처럼 캐시파일을 생성한 즉시 0.01초 내에 다시 읽어들여야 하는 시스템이라면 그것만으로는 부족하지요. DRBD나 GlusterFS 같은 것도 있지만 운용하기가 꽤 까다롭습니다. 작동 원리를 제대로 알지 못하고 무작정 세팅했다가는 여러 서버 중 하나라도 다운되었을 때 정상적인 상태로 되돌리기 위해 고생 좀 하실 거예요.
하나의 파일서버를 NFS로 공유하는 방식을 그나마 많이 사용합니다. 작동 원리는 간단하지만 속도가 무척 느립니다. XE 기준으로 files/attach 폴더는 이런 식으로 운용해도 상관없지만, files/cache나 files/member_extra_info 등을 NFS로 공유했다가는 속도 저하를 금방 체감할 수 있습니다. 코어, 모듈, 애드온 등의 소스코드도 NFS로 공유하면 로딩 속도가 크게 떨어집니다. (opcache 덕분에 많이 나아지긴 했지만, 이제는 캐시 갱신이 문제죠...) XE처럼 자잘한 캐시파일에 신경쓸 필요가 없는 그누보드나 워드프레스 사이트라면 첨부파일 폴더만 공유하고 소스코드는 각 서버에 따로 저장한 후 변경될 때마다 rsync나 버전관리툴 등으로 동기화하는 방법도 많이 사용합니다. 단, 이렇게 하려면 어느 서버의 파일을 먼저 수정한 후 어디에 커밋하여 어디로 동기화한다는 원칙을 분명히 세워놓고 꼼꼼하게 따라야 합니다. 순서가 틀리면 수정내역이 뒤죽박죽됩니다.
어떤 방식을 사용하더라도 이렇게 분명한 단점이 있기 때문에, 로드밸런싱을 고려하실 때는 대체 무엇을 얻기 위해 내가 이런 단점을 감수하고 있는지를 잘 따져보아야 합니다. 3배의 동접수를 감당할 수 있도록 서버 3대를 마련했는데 각 서버의 로딩속도가 3배 느려진다면 제자리걸음이잖아요. AWS 같은 곳에서 2코어짜리 서버 3대 만들어 놓고 수시로 rsync해가며 로드밸런싱 구현하는 사람들이야말로 시간낭비 돈낭비 하는 거예요. 그냥 로드밸런서 빼고 8코어짜리 1대 쓰는 것이 훨씬 빠르거든요. 공유가 일어나는 지점에서 병목현상이 장난이 아닙니다.
Vertical scaling(각 서버의 사양 업)이 충분히 가능한 범위인데도 불구하고 Horizontal scaling(서버 대수 증설)을 먼저 한다면 AWS 같은 회사들의 마케팅에 속았거나, 서버가 다운되더라도 사이트가 계속 돌아가도록 해야 한다!!!라는 이유로 가성비를 포기했거나, 둘 중 하나입니다. 성능을 따진다면 4코어짜리 16대 쓰는 것보다 32코어짜리 2대를 웹/DB로 나누어 쓰는 편이 비교할 수 없을 만큼 더 빠르거든요. 대한민국 커뮤니티 10위권에 들어가는 초대형 사이트를 제외하면, 동일한 역할을 수행하는 서버 여러 대를 로드밸런싱할 이유는 장애 대비 외에는 사실상 전무합니다.