1. 부하 분산이란 무엇인가
새로운 웹사이트는 트래픽이 크지 않기 때문에 로드 밸런싱을 해서는 안 됩니다. 따라서 이런 일에 참여할 필요가 없습니다. 하지만 웹사이트 트래픽과 트래픽이 급격히 증가함에 따라, 단일 서버는 자체 하드웨어 조건에 의해 제한을 받아 이렇게 많은 방문자를 견디기 어렵습니다. 이 경우 선택할 수 있는 두 가지 옵션이 있습니다:
1. 단일 서버의 하드웨어를 듀얼코어에서 쿼드코어로 업데이트하고, 메모리를 늘리는 등의 작업.
2. 서버 수를 늘려 서버 부담을 분담한다. 네트워크 대역폭을 늘리고 서버의 처리 능력을 향상시키는 목적을 달성하기 위해서입니다.
첫 번째 방법은 항상 제한적인 수직 발전으로 이해할 수 있습니다. 두 번째 방법이 문제를 해결하는 올바른 선택입니다
부하 분산 방법은 두 가지 방향으로 나눌 수 있는데, 하나는 소프트웨어를 사용해 부하 분산을 달성하는 것이고, 다른 하나는 하드웨어와 소프트웨어를 결합한 하드웨어 부하 분산을 구현하는 것입니다
소프트웨어를 사용해 부하 분산을 달성하면, 부하 분산 달성 과정은 일부 시스템 자원을 소모하고 응답 시간을 증가시킵니다. 예를 들어, LVS, nginx, haproxy, apache 등은 방문자가 많지 않은 웹사이트에 적합합니다. sina와 163처럼 방문자가 많은 웹사이트라면, 하드웨어를 이용해 부하 분산을 구현하는 것이 가장 명확한 선택입니다.
요청 수, 루트 IP 주소, 트래픽 기반 알고리즘 등 다양한 부하 분산 알고리즘이 존재합니다. 제가 자주 사용하는 두 가지 알고리즘이 있습니다.
하나는 요청 건수에 따라 달라집니다
A, 각 서버가 고객의 요청을 고르게 공유할 수 있으며, 한 서버가 다운되더라도 부정적인 영향을 주지 않는다는 점을 인식할 수 있습니다.
b. 서버 간 상태는 세션과 같이 동기화되어야 하며, 이 상태를 동기화하기 위해 다른 수단이 필요합니다.
하나는 IP에 따른 것입니다
A, ip_hash 알고리즘은 IP를 서버에 매핑할 수 있어 세션 동기화 문제를 해결할 수 있습니다
b. ip_hash의 단점은 한 서버가 다운되면 해당 서버에 매핑된 사용자들이 우울해진다는 점입니다.
c, ip_hash 불균형 부하로 이어질 수 있습니다. 이제 강게 정부가 구글의 검색 키워드를 필터링하기 때문에 구글이 자주 열리지 않지만, 시간이 지나면 괜찮아질 것입니다. 이로 인해 구글 애호가들은 우울해졌고, 많은 사용자들이 에이전트를 찾기 위해 해외로 떠났습니다. 이런 경우 이 프록시들이 동일한 서버에 할당되어 불균형 부하와 심지어 장애가 발생할 수 있습니다.
둘째, 세션 진행이 무엇이며 그 기능은 무엇인가에 대해 말씀드리겠습니다
세션 홀드는 부하 분산 기능을 의미하며, 부하 분산을 수행하는 동안 동일한 사용자와 연관된 접근 요청이 동일한 서버에 분산되도록 보장하는 메커니즘입니다.
세션 홀드는 무엇을 하는지, 예를 들어
사용자 접근 요청이 서버 A에 할당되어 서버에 로그인한 후 짧은 시간 내에 이 사용자가 또 다른 요청을 보내면, 세션 보류 기능이 없다면 이 사용자의 요청은 서버 B에 할당될 가능성이 큽니다. 이 시점에서 서버 B에 로그인이 없으므로 다시 로그인해야 하지만, 사용자는 자신의 요청이 어디에 할당되었는지 모릅니다. 사용자의 느낌은 자신이 로그인했다고 생각하는데, 왜 다시 로그인해야 하는지, 사용자 경험이 매우 나쁩니다.
그리고 타오바오에서 무언가를 구매할 때, 로그인 = "뭔가 쏘기=" 주소 추가로 = "결제하기"에서 시작하면, 이것은 일련의 프로세스로, 하나의 작업 프로세스로도 이해할 수 있습니다. 이 모든 작업 프로세스는 하나의 서버에서 완료되어야 하며, 부하 분산기가 서로 다른 서버에 할당할 수 없습니다.
세션 홀드는 시간 제한이 있으며(ip_hash처럼 고정된 서버에 매핑된 서버 제외), 다양한 부하 분산 도구들이 이 세션 홀드 시간 설정, LVS, apache 등을 제공합니다. PHP 언어도 세션 홀드 시간을 설정할 session.gc_maxlifetime를 제공합니다
세션 대기 시간은 세션 생존 시간보다 더 길게 설정해야 하며, 이는 세션 동기화의 필요성을 줄일 수 있지만, 완전히 없앨 수는 없습니다. 그래서 세션 동기화는 여전히 해야 합니다.
셋째, 세션 동기화
왜 세션 동기화인가? 세션 유지에 대해 이야기할 때 언급된 적이 있습니다. 자세한 내용은 웹 클러스터에서의 세 가지 세션 동기화 방법을 참조하세요
웹 클러스터에서 세션 동기화에는 세 가지 방법이 있습니다
웹 클러스터를 진행한 후에는 세션 동기화를 먼저 고려해야 합니다. 부하 분산 후에는 같은 페이지에 대한 동일한 IP 접근이 서로 다른 서버에 할당되기 때문입니다. 그래서 이 글에서는 이 상황에 따라 이 문제를 해결하는 세 가지 방법을 제시합니다:
먼저, 데이터베이스를 이용해 세션을 동기화하세요
멀티서버 세션 동기화 시 이 방법을 사용하지 않았지만, 만약 이 방법을 써야 한다면 두 가지 방법을 생각했습니다:
1. 저사양 컴퓨터를 사용해 웹 서버의 세션을 저장할 데이터베이스를 구축하거나, 파일 서버에 이 특별한 데이터베이스를 구축합니다. 사용자가 웹 서버에 접속하면 세션 상황을 확인하기 위해 이 특수 데이터베이스로 가서 세션 동기화 목적을 달성합니다.
2. 이 방법은 세션이 저장된 테이블을 다른 데이터베이스 테이블과 함께 배치하는 것으로, 만약 mysql도 클러스터링되어 있다면 각 mysql 노드가 이 테이블을 가져야 하며, 세션 테이블의 데이터 테이블은 실시간으로 동기화되어야 합니다.
설명: 데이터베이스를 이용해 세션을 동기화하면 데이터베이스의 부담이 증가하는데, 이는 본질적으로 병목 현상에 취약합니다. 위 두 방법 중 첫 번째가 더 낫습니다. 이 방법은 세션이 독립적으로 배치되는 테이블을 분리하여 실제 데이터베이스에 가해지는 부담을 줄여줍니다
2. 세션 동기화를 위해 쿠키를 사용하세요
세션은 서버 측에 저장된 파일 상황이고, 쿠키는 클라이언트의 파일 상황입니다. 동기화는 어떻게 해야 하나요? 방법은 매우 간단하며, 사용자의 방문 페이지에서 생성된 세션을 쿠키에 넣어 쿠키를 중계 스테이션으로 사용하는 것입니다. 웹 서버 A에 접속해 세션을 생성하고 쿠키에 넣으면, 접근 권한은 웹 서버 B에 할당됩니다. 이 시점에서 웹 서버 B가 먼저 서버에 세션이 있는지 판단합니다. 없다면 클라이언트의 쿠키에 세션이 있는지 확인하러 갑니다. 없다면 세션이 실제로 저장되지 않았다는 뜻입니다. 쿠키에 세션이 있다면 말이죠. 쿠키 내 세소인을 웹 서버 B와 동기화하여 세션을 동기화할 수 있게 하세요.
참고: 이 방법은 구현이 간단하고 편리하며 데이터베이스 부담을 증가시키지 않지만, 클라이언트가 쿠키를 비활성화하면 세션이 동기화될 수 없어 웹사이트에 손실이 발생할 수 있습니다; 쿠키는 보안이 높지 않으며, 암호화되었지만 여전히 위조될 수 있습니다.
3. 세션 동기화를 위해 memcache를 사용해
멤캐시는 분산될 수 있으며, 이 기능이 없으면 세션 동기화에 사용할 수 없습니다. 웹 서버의 메모리를 결합해 '멤풀'이 될 수 있는데, 어느 서버가 세소인을 생성하든 이 메모리를 이 '멤풀'에 넣고 나머지는 모두 사용할 수 있습니다.
장점: 이렇게 세션을 동기화하면 데이터베이스 부담이 증가하지 않고, 쿠키 사용에 비해 보안이 크게 향상되며, 세션을 메모리에 저장하는 것이 파일에서 읽는 것보다 훨씬 빠릅니다.
단점: 멤캐시는 메모리를 여러 저장 블록 명세로 나누며, 블록과 크기가 존재합니다. 이 방식은 멤캐시가 메모리를 완전히 활용하지 못해 메모리 단편화를 유발하며, 저장 블록이 부족하면 메모리 오버플로우도 발생합니다.
넷째, 요약
위의 세 가지 방법 모두 실현 가능합니다
첫 번째 방법은 시스템 속도에 가장 큰 영향을 미치며 권장되지 않습니다;
두 번째 방법은 좋은 결과를 내지만, 안전 위험은 동일합니다;
세 번째 방법은 개인적으로 제가 가장 좋다고 생각하며, 모두에게 추천합니다;
|
게시됨 2015. 5. 14. 오전 12:16:44
|
|
|
