대용량 서비스 커뮤니티 스터디 - 1
이번 포스팅에서는 개인적으로 회사 동료 및 선배님들이랑 진행하고 있는 스터디에 대하여 다루려고 합니다.
스터디의 주 목적은 대용량 커뮤니티를 스터디 하면서 각자 배웠던것이라던가 구축하는 것들을 자료를 모아서 동영상을 만들자고 하던것이 목적입니다. 저 또한 이러한 목적에 도움이 되고 싶고, 개인 역량을 강화하고 싶은게 가장 큰 목적 입니다.
첫 2주간에 스터디에서 진행한 내용은 아래 슬라이드의 내용을 각자 한장씩 읽으면서 짧게 이야기를 나누는 것 입니다.
안정적인 서비스 운영
위의 슬라이드는 nhn 회사에서 사내 교육용으로 쓰이고 있는 피피티라고 합니다. 주로 대용량 서비스를 다루면서 어떻게 최적화 튜닝을 하는지에 대하여 다루고 있습니다.
주요 내용들은 슬라이드에 있지만 저도 개인 공부를 위해서 블로그에 포스팅 해봅니다.
간단하게 흐름은..
매우 간단한 웹사이트 구축 방법은 서버와 디비를 하나로 두는것. 여기에서 좀더 부하 분산을 위해서 서버를 2중화를 한다. 이중화 된 서버 앞에는 로드밸런싱을 하는 L7과 같은 물리적 장치를 둘 수 있다. 고가용성을 위해서 서버로 트래픽을 분배하지 않고, 장애가 발생되면 그때 바로 분배하는 방식이 있다. 서로 다른 서버간에 세션이 다르기 때문에 이는 문제가 된다. 예를 들어서 내가 로그인 한 정보가 다른 서버에서는 없기 때문에 갑자기 로그아웃 될수 가 있다. 따라서 이는 로드벨런싱에서 아이피는 같이 가게 하거나 공유 세션을 둘 수 있다. 빠르게 하려면 이를 메모리 디비로 활용 할 수 있다.
DSR 다이렉트 서버 리턴(Direct Server Return). 이 개념은 생소했다. 이는 파일 업로드 서버와 같이 대용량 데이터를 업로드 해야하는 경우, 로드벨런서 서버도 또한 해당 트래픽을 전부다 받게 된다. 이는 네트워크 상의 병목이 될 수 있다. 따라서 업로드를 해야하는 경우는 일단 업로드를 해야하는 서버에 라우팅을 한 후 업로드 연산은 로드 벨런서를 거치지 않게 하는 방식이다.
디비 분산
위의 서버 구성에서는 디비는 아직까지 하나다. 디비도 또한 무한정으로 업그레이드는 불가능하니 스케일 아웃이 가능해야한다. 처음 구조로는 마스터 슬레이브로 둘 수 있다. 마스터 슬레이브 각각 하나의 구조에서는 슬레이브는 장애시에만 사용하게 할수도 있다. 하지만 슬레이브를 추가하면 추가할수록, 복제에 대한 트래픽이 너무 많아 진다. 결과적으로 이러한 구조는 write연산이 병목일 경우에는 전혀 도움이 되지 않는다. 오히려 연산이 너무 많아질수 있다. 이러한 문제를 해결하기 위해서 샤딩 방법이 있다.
샤딩은 위와 같이 특정 사용자 등과 같은 컬럼 기준으로 디비를 분할하여 저장하는 방식이다. 저장된 위치는 다른 디비에 저장을 하는 방식이다. 네이버 카페와 같은 경우를 생각하면 일반적인 카페와는 달리 중고나라와 같이 그 자체가 커뮤니티를 이루는 사이트는 이를 위한 샤딩이 필요하다. 일반적인 샤딩 알고리즘을 사용할 경우 서버가 추가될 경우 문제가 발생할 수 있다. 주어진 요청을 서버의 갯수로 나눠서 서버에 저장하는 방식이나 해시 알고리즘을 사용하는 방식이나 궁극적으로는 서버가 추가될때 자동으로 재분배가 되기는 어렵기 때문에 직접 수기로 데이터를 마이그레이션 한 경험이 있는 분이 있었다. 구글에서 만든 오토 스케일 샤딩 알고리즘이 있다고 한다. https://research.google/pubs/pub46921/
위의 샤딩 부분에서는 사용자의 정보에 따라 디비만 라우팅 하였지만 웹, 세션 등을 전체적으로 묶어서 하나의 셀이라고 지칭 할 수 있다. 이때 매핑하는 디비를 하나 두어서 라우팅을 하면 된다. 이렇게 하면 장애가 나도 특정 사용자만 장애가 나는등의 부분적 장애 발생이 된다. 서로간의 연결 통로는 없기 때문에 장애가 전파되지는 않는다. 물론 셀디비가 죽으면 연산 자체가 안되는 큰 어려움이 있다. 또한 서버 자원이 막대하게 필요하다는 점도 있다.
이후 중간에 페이스북에서 장비 배포를 위해서 비트 토렌트를 사용한다고 한다. 여기서 말하는 비트 토렌트는 흔히 아는 p2p 다운로드 사이트로 보면 맞다.
여기서의 장점으로는 여러 서버가 각각 배포를 위한 서버가 될수 있다는 점과 그때문에 속도가 빠르다는 점이다. 하지만 단점으로는 파일이 조각조각 되어 있고 한번에 여러 조각을 받을 경우 디스크 연산이 많아서 서버 장비가 고장날 수 있다는 점이다.
빠른 롤백.
빠른 롤백의 내용이 어렵지는 않으나 직접 해본 경험이 있어서 공감이 된다. 본인은 광고 이미지가 저장될 서버 시스템을 일반적인 물리 서버인 NAS에서 사내에서 관리되고 있는 클라우드 서버로 옮기는 작업을 하였다. 여기서 문제는 광고가 나가지 않으면 법적인 문제가 생길 수 있고, 경우에 따라 실시간으로 수익감소가 될수도 있으며, 사용자는 빈화면을 봐야한다는 것이다. 또한 개발 서버랑 운영 서버는 시스템적으로 차이가 있을수밖에 없었고, 트래픽 자체도 다르다. 여러 문제를 고려해야해서 에러가 발생될 경우 약간의 컨피그 조절에 따라서 다시 NAS로 복귀할 수 있도록 이미지를 두번 올리면서 바로 전환이 가능하게 코드를 짜야 했다. 또한 이미지를 올리는 서빙 서버는 다른 서버였기 때문에 해당 담당자에게 양해를 구하고 redis에 저장된 url을 변환할 수 있도록 스크립트를 작성하였다. 작업을 하는데에 있어서 시스템을 위한 코드보다 장애 처리를 위한 코드가 2배이상 많았던것 같으나, 해당 시스템을 변환하는 것은 개발팀에게는 중요 성과가 아니기 때문에 우리로써는 하기 싫은 프로젝트 였고 리스크를 최대한 줄여야 했다. 결국 문제는 없었던게 다행이었으며 오히려 해당 스위칭 로직은 여전히 사용되는 점이 있다. 클라우드 시스템도 담당자가 있으며 담당은 당연 시스템을 업데이트 하고, 장애를 만들수밖에 없기 때문이다.
속도를 개선하는 방법중 write back이라는 방법이 있다. 디비 연산은 비싼 연산이기 때문에 비교적 빠른 저장소인 캐시 디비에 일단 저장후 연산의 결과를 모아서 디비에 저장하는 방식이다. 예를 들어서 조회수는 굳이 실시간 반영이 되지 않아도 된다. 또한 장애가 나서 조회수가 안올라가더라도 큰 문제는 없다. 이러한 경우는 Write Back을 고려할 수 있다. 우리의 가까운 예는 페이스북 좋아요를 들 수 있는데 경험상 좋아요가 가끔 누락되거나 반영이 느린경험이 최근에는 모르겠으나 느낀점이 있다.
디비에서 여러 쿼리를 한쿼리로 해결하기 위해서 동적 쿼리를 만드는 것을 많이 봐왔다. 동적 쿼리라는게 시스템상으로 있는게 아니라 String 문자열로 그때그때 쿼리를 짜서 실행시키는 것이다. 이것의 문제점은 String의 최대 길이가 넘어가면 짤리기 때문에 쿼리를 분할해야하며 이를 알려면 쿼리를 실행해봐야 한다. 또한 실행하기 이전에는 IDE에서 에러를 보여주지 않는다. 괄호 하나를 잘못 짰더라면 눈으로 디버깅하는 수밖에 없다. 또한 테스트도 어려워 진다. 무엇보다 문제점은 쿼리가 매번 새로 만들어질수밖에 없다 보니 디비 입장에서는 이쿼리를 최적화하기 난감하다. 그래서 DBA가 싫어하는 부분이 있다. 관리를 할수 없기 때문이며 JPA와 같은 entity 모델의 고질적인 단점이다. 이러한 경우는 쿼리를 직접 실행하여 성능을 측정하는 시스템을 개발해야한다. 페이징 쿼리가 동적 쿼리로 난발되어 있고, if 문을 통해서 조회조건을 변경하는 경우는 난이도가 극히 상승한다. 이경우는 굳이 동적쿼리가 아니라 where절을 잘 짜면 해결이 될 수 있는데 아쉬운 부분이 많다.
후기
아직 끝난것은 아니지만 그래도 피피티를 하나 끝냈으니 여기까지의 후기 입니다. 아직까지 많은 경험이 없다고 생각하는 4년차 개발자 이지만 전체적인 슬라이드 내용에서 뒷 내용은 공감이 되는 한편 앞에 있는 셀 아키텍쳐까지는 아직까지 경험이 없는것을 느꼈습니다. 이론적으로는 저렇게 스케일링이 가능하다고 하지만 지금 재직중인 회사에서는 하나의 큰 시스템을 다루기 때문에 로직적으로 샤딩을 하기 보다는 일단 비싼 장비를 사서 오래오래 쓰는 방식을 택하는 듯 합니다. 예를 들어 네이버 시스템이라면 여러 도메인이 있고 각 도메인 마다 비싼 장비를 살수는 없기 때문에 적당한 장비를 활용할 수 있습니다. 하지만 지마켓 옥션같은 경우 지마켓, 옥션에서 비싼 장비 한두개면 커버가 가능한 점이 있어서 위의 경험을 할 수 없다는 점이 있습니다. 이번 스터디가 잘 되어서 좋은 경험이 있었으면 좋겠습니다. 스터디를 하면서 이해를 하지만 이해만 하고가는 스터디보다는 실제로 경험을 해보고 싶은 느낌이 있습니다.
댓글
댓글 쓰기