nginx proxy

음.. 계속 말하겠지만. 난 돈 쓰는걸 많이 싫어하는 편이다.

투자에 인색하다고 하지 말아라.

특별한 투자 없이 처리할 수 있고 비용을 줄일 수 있으면 줄이는 게 당연한 것이다.

비록 난 대표는 아니지만 내 회사라는 마음이 있고 회사 돈을 아낀다면.. 그게 맞다는 것이다.

하지만 고민할 수 있는 위치가 아니거나 고민하다가 시간을 많이 소비한다면 오히려 그건 회사에게 더 실이 될 수 있으니 조심하자. (인건비가 요즘 장난 아닌지라...)


자. 최근 테라급 데이터를 다루다보니 당연히 눈길이 스토리지 서버에 갈 수 밖에 없는 상황이 생기고 스토리지가 생기더라도 아무리비싸고 좋고 훌륭한 raid를 써서 사용하더라도 결국 사고터지만 백업에 의존하는 상황이 생기기 마련이다.


그러다보니 스토리지를 과감히 포기하고 다른 방법을 택해보았다.


역시 돈이 없기 때문에 L4를 사용할 생각 조차 하지 않았다.

그리고  LVS는 몇 번 구축했지만 내가 원하는 성능을 내지를 못 했다.

내 욕구에 충족하는 수준이 nginx proxy이다.

이 놈 멋지다....

단순 i/o라면 발란스 관리하는 놈만 만들면 아주 아주 퍼팩트한 운영이 가능하다.


방법은 아래와 같다.



 
 192.168.0.x
Proxy 1  --monit-> Proxy 2   -monit->  Proxy 3  -monit -> Proxy 1 (cycle 모니터링)


Web 192.168.101.x 대역        
Web 192.168.101.1(10TB)  <-- sync --> Web 192.168.101.2(10TB) (cycle 모니터링)


Web 192.168.102.x 대역        
Web 192.168.102.1(10TB)  <-- sync --> Web 192.168.102.2(10TB) (cycle 모니터링)


Web 192.168.103.x 대역        
Web 192.168.103.1(10TB)  <-- sync --> Web 192.168.103.2(10TB) (cycle 모니터링)




1) Proxy 들은 각자 1명씩의 Proxy를 감시하여 Proxy 장애를 모니터링 하게 된다.
2) 각 Web의 대역은 서로 service 및 모니터링을 관활하게 된다. (실 운영은 2대보다 많아야지?)
3)  외부에서 접속이 할 경우 proxy 에서 rewrite 를 활용하여 서버에서의 응답을 return 처리
4) Proxy 에서는 Web 대역을 모니터링하여 upstream 을 조정 및 발란스 처리


1-4번까지의 기능의 데몬을 만들면... 오픈 소스를 통하여 대용량 스토리지처럼 운영할 수 있게 된다.


음...

좀 이해가 안되나?..

그냥 고민해보면... 디게 쉽다.

이런식으로 현재 운영을 하고 있는데... 물론 100% 동일하지는 않고 부수적인 것들이 좀 있기는 하지만... proxy 상단에 cdn이 있고 뭐 등등...

암튼 기본적인 이런 형태면 트래픽에 따른 proxy 추가와 용량에 따른 Web 대역을 늘리는 것으로 100 * 10TB정도의 용량은 가능해지게 된다. ㅡㅡ;;

물론 현재 초기 시범 서비스라... 이게 정답인지는 모르겠다...



어떤이는 이렇게 말한다.. 아 복잡해 걍 스토리지 몇대 넣고 L4넣죠... 라고 하는...


누군 그게 좋은지 몰라서 그러냐... 돈이 없다. 돈이 없어.