로드밸런싱을 구현하고자 합니다. > 설문게시판

설문게시판

로드밸런싱을 구현하고자 합니다. 정보

로드밸런싱을 구현하고자 합니다.

본문

SIR의 서버가 노후되어 이번에 교체하는 김에 로드밸런싱으로 구성을 하고자 합니다.

로드밸런싱에 대해 자세하게 설명한 책이 없어 며칠간 인터넷 검색을 하여 찾아낸 방법으로만 말씀 드리니 잘못된 점이 있다면 지적해 주세요.

 

 

(첫번째 방법) 

로드밸런싱을 하는 목적인 부하 분산에는 맞지 않지만 운영의 중단을 없앤다는 목적에는 어느정도 다가서는 것 같습니다.

1. 평소에는 서버A만 접속되며 서버B는 서버A의 데이터와 DB를 복사해 놓는 역할을 한다.

2. 서버A에 문제가 생겨 접속이 되지 않는 경우 서버B로 접속하여 운영을 이어나간다.

장점 : 설정 및 테스트가 쉽다.

단점 : L4 스위치를 사용하여 분산하는 효과가 없다. L4에서 이런 방식을 지원해 주는지 아직 확인되지 않음.

e7082d7a4b98f13c81748af3fc80fe88_1496883501_0343.png

 

 

(두번째 방법)

로드밸런싱을 하는 목적에 맞는것 같습니다. (자신이 없군요.)

1. L4 스위치에서 서버A, 서버B로 분산합니다.

2. 서버A와 서버B에 올라온 데이터는 양방향 rsync 합니다.

3. 디비A와 디비B에 올라온 데이터는 양방향 replication 합니다.

장점 : 부하 분산을 한다.

단점 : 설정이 어려우며 어느 한곳이 중단되면 원상복구가 어렵다. 데이터를 두곳에 보관하므로 하드웨어 사용이 두배로 늘어난다.

e7082d7a4b98f13c81748af3fc80fe88_1496884241_1667.png
 

 

현재는 위와 같은 방식으로 구성하는 것에 대해 생각하고 있습니다.

 

다른 한가지가 더 있는데 이것은 프로그램이 많은 부분 수정되어야 하는 방법이라 당장은 고려하고 있지 않습니다.

나중에 참고하기 위하여 설명을 하자면 그림과 같은 방식으로 구성됩니다.

 

(세번째 방법)

1. 서버A와 서버B는 양방향으로 rsync 합니다.

2. 디비A는 쓰는 용도로 사용하고, 디비B는 읽는 용도로 사용합니다.

장점 : 읽는 용도가 많은 웹사이트의 경우 효율이 월등이 좋은것으로 예상한다.

단점 : 설정이 어려우며 기존 프로그램의 소스코드 수정이 많아진다.

e7082d7a4b98f13c81748af3fc80fe88_1496884652_1115.png
 

 

위 방법들은 여러 사이트에서 소개한 정보를 조합하여 나름대로 구성해 본것으로 

로드밸런싱으로 구성하는데 맞는지는 확실하지 않습니다.

 

로드밸런싱에 대해 잘아시거나 관심 있으신 분들의 열띤 토론을 기대합니다.

댓글 전체

1번이 단순하며 간단합니다.
실 운영상에서는 장비 유지보수 및 전환 테스트겸 해서, 한달에 한번정도 A B 역할을 바꾸어 줍니다.
음 글 내용중간에 로드벨런싱을 구성하고자 하는 목적이 적혀있는데,
운영의 중단을 없앤다는 어떤 시점에 중단되는 것을 의미하는 것인가요?
(향후 어떤 이유로 인해 장비 유지보수가 생길경우?)
냑 서비스가 중단되어도 아무런 문제가 발생하지 않기 때문에, 로드밸런싱을 쓰지 않고 서버1, 디비1 쓰는걸 추천합니다.
제대로된 로드밸런싱은 3번째가 맞겠죠.

더 자세히는 서버A, 서버B HDD 또한 RAID 0+1 방식으로 해야 할거 같고, (.... 10년도 더되어서 기억이 가물가물...)

리자님이 다 알고 잘 적어 주셔서, 첫번재 Active, Standby 방식은, 자원이 비효율적인 방식이죠.
S전자, K통신사 같은경우 예전에 제가 보거나 알기로는 슈퍼돔들은 Active, Standby로 되어 있었는데, 지금은 잘 모르겠습니다. 그만큼 자원이 풍부한 환경에서나 적합하지, 효율성으로 사용하고자 하시기 때문에, 두번째, 세번째를 고민해 보시지 않을까 싶고, 세번째가 가장 정확하겠죠.

E해변 같은 쇼핑몰에서는 웹서버40대 인가???, DB 서버도 다수 돌려서 막 얽혀 있는거 같던데, 처리해야할게 많다면, 세번째 방식으로 가는게 효율적이지 않나 싶습니다.




걍 아무말이나 대잔치 인듯 ㄷㄷㄷ
rsync 양방향은 위험합니다.
싱크하다 문제가 잘 생깁니다.
문제 발생 직후 싱크시 멀쩡한 파일들이 삭제되기도 합니다.
싱크중에는 파일, 디렉터리들이 root 권한으로 변하는데 뭔일로 멈추면 또한 골치입니다.
rsync뿐만 아니라 unison, lsyncd 등도 같은 문제가 있습니다.
cron을 짧게 잡을 수밖에 없고 A, B간에 기준이 왔다 갔다하는 거라 이런 툴로 감당이 안됩니다.
때문에 nfs, san 등을 서버들이 공용으로 마운트하는 방법을 쓰기도 합니다.
생각보다 웹서버간 온전한 싱크는 난제입니다.
직전회사에서 40대 정도 로드밸런싱 구성을 잡은적이 있긴한데
윗분말씀대로 양방향 rsync 는 안하시는게 낫습니다.

제가했던 경험으로 말씀드리면 개발서버 쪽에서  rsync 를 통해 실 웹서버로 전달을 하고
이때 문제가 되는 (그누에서는  data 폴더겠네요) 이미지 업로드 폴더의 경우 따로 서버를 빼서
처리를 했습니다.

백업시에 일일이 exclude 하는게 귀찮아서기도 하고 이미지 서버가 따로 있기도 해서였습니다만
L4로 분산을 하더라도 라운드 로빈방식으로 처리되면 해당 유저는 접속해있는동안 계속 한서버만
바라보니 큰 문제는 되지 않습니다.

디비의 경우에는 세번째 방법이 가장 적합해 보입니다.
replication 을 잡는 경우 마스터는 쓰기용도 슬레이브는 읽기 전용으로 쓰는게 일반적인 형태입니다.
단점으로 제시하신 소스코드의 설정이 많아진다 라는 부분은
쿼리문에 따라 접속을 따로 처리해서 한방에 처리가 가능하기도 합니다.

마리아 디비를 혹시 쓰신다면 갈레라 클러스터도 참고해보세요
댓글 하나하나가 많은 도움이 되고 있습니다.
주말동안 댓글에 나온 내용으로 충분히 찾아본후 다음주에 테스트 서버에서 실제로 세팅해 봐야겠습니다.
지금까지 글 남겨주신 회원님들 정말 정말 감사합니다.

회원님들께서만 아시는 내용이 있다면 계속 계속 글 남겨주세요. (__)
웹서버는 말그대로 웹서버 기능만 하고 파일은 별도로 구축된 NFS에 저장하면 웹서버를 여러개 구축할 경우
각 웹서버에서는 NFS를 마운트하기만 하면 파일 관리는 한개서버로 가능하지 않을까 싶네요. DB는 3번이 맞는 방식이라 보여지구요.
분산이나 안정성 위주로 생각하시면 차라리 AWS 나 KT 클라우드 서버로 구축하시는게 좋을것 같습니다.
가비아나 이런데는 클라우드 기술이 좀 빈약하구요.
L4 사용해서 로드밸런싱이나 백업을 쓰게 되면 이론상으로는 간단한데 실제 서비스가 깨졌을때 복구하려면 상당한 경험자가 아니면 복구하는데 시간이 오래걸립니다. 페일오버가 자동적으로 일어나는게 아니라서 DB 리플리케이션의 경우에도 복구가 쉽지 않습니다.
전체 354
설문게시판 내용 검색

회원로그인

진행중 포인트경매

  1. 참여67 회 시작24.04.19 15:40 종료24.04.26 15:40
(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT