💡 가비아에 자세하게, 친절하게 정리된 것이 있으니 잘 읽어보고 정리하였다.
가비아 땡큐~!
현재 대부분의 사람들은 인터넷을 이용해 정보를 얻고 업무를 진행하며 일상생활에서도 많은 도움을 주는 역할로 자리잡았다. 그만큼 없으면 문명의 발달도 없었을 것이다.
아무리 성능 좋은 서버라고 해도 모든 트래픽을 감당할 순 없다.
회사들은 서버를 추가적으로 구비를 하고 여러 대의 서버에 동일한 데이터를 저장해 수많은 트래픽을 효과적으로 분산 시킬 필요가 있다.
그런데 다수의 서버를 운영한다고 해서 모든 클라이언트의 응답에 일관성 있게 응답할 수 있을까?
아니다! 로드밸런싱이 필요한 이유는 트래픽을 다수의 서버에 분산시켜주는 기술이 필요 하고, 한 서버에 트래픽이 몰리는 현상을 막을 수 있다.
💡 트래픽 관련 용어 정리한 글이다.
용어 정의
로드 밸런서는 서버에 가해지는 부하를 분산시켜주는 기술을 의미한다.
로드 밸런서의 아키텍쳐를 보면서 이해하면 쉽다.
클라이언트(유저)와 서버풀(ServerPool) 사이에 위치하며, 한 대의 서버로 부하가 집중적으로 걸리지 않게 분산시켜주는 역할을 해 최적의 퍼포먼스를 하게 도움을 주는 녀석이다.
출처 : 가비아 블로그
이전 회사는 한 기업의 투자를 받아 웹 개발을 진행해 준 경험이 있는데, 서버를 어느정도의 용량까지 투자해야하는지에 대한 고민을 한 적이 있었다. 이 고민에 대해서 만약, 다수의 서버를 구성해도 예상 외의 상황에 유저 몰림현상이 일어난다면, 어떻게 해야할까? 라는 의문을 품었던 적이 있었다.
그때 당시 백엔드 팀장급한테 가서 물어보니 “우리는 지금 다수의 서버를 구축해놓은 상태이고, 만약 서버가 컨트롤 할 수 있는 유저의 수보다 더 유저가 방문하고 이용하게 된다면 서버는 어쩔 수 없이 터질 것이다. 이거는 어쩔 방법이 없다.” 라고 대답을 들은 적이 있다.
하지만 과연 방법이 없을까?
아닐거다! 만약 나와 회사가 LoadBalencer 의 개념을 알았으면 달랐을 것이고,
지금 생각해보면, 시니어의 부재와 나의 경험 미숙, 기초지식 부족이 이유였을 것이라는 생각이 든다.
No~!
여러 대의 서버를 두고 해야하는 만큼 비용적인 문제가 크기 때문에 서비스의 초기 상태에는 당연하게 힘들 것이다.
만약 서비스 초기 상태라면, 클라이언트의 수도 적으니 한 대의 서버로 요청-응답을 진행하다가 사업이 확장되거나 클라이언트의 수가 늘어나고 사용량이 많아지면 다음의 2가지 방법 사용을 고려해봐야한다.
출처 : 가비아 블로그
Scale-up
Scale-up 의 경우, 서버 자체의 성능을 확장하는 것이다.
예 : i3 ⇒ i7 으로 성능 버전 up! 시키기! (고 성능으로 승부!)
Scale-out
💡 Scale-out 로 선택했다면, 여러 대의 서버로 트래픽이 균등하게 분배되는 *로드밸런싱이 꼭 필요!*
Scale-out 의 경우, 기존 서버와 동일 혹은 낮은 버전의 서버를 증대시키 것이다.
예 : i3 를 한 대 추가로 구매해 운영하기! (물량으로 승부!)
단점 관리할 게 많아진다. 마이크로서비스 처럼!
💡 다양한 로드밸런싱의 알고리즘 5 가지를 정리해보겠다.
네트워크 통신 시스템은 크게 7 가지 계층으로 나뉜다. (OSI 7 layers)
각각의 계층이 L1, L2, L3, L4, L5, L6, L7 에 해당한다. 상위 계층 에서 사용되는 장비는 하위 계층의 장비가 갖고 있는 기능을 모두 가지고 있으며, 상위 계층으로 갈수록 더욱 정교한 로드밸런싱이 가능한다.
예를 들어 카카오 데이터 센터 화재 사건이 있다.