이번 주제는 ‘애플리케이션 스위치 제대로 알기’다. 잘 알고 있는 것 같으면서도 막상 잘 모르는 것이 L4~7 스위치로 통용되는 애플리케이션 스위치다. 이번 기고는 애플리케이션 스위치에 대한 진실과 오해를 짚고 넘어가야 될 필요성이 있어서 마련됐다. 애플리케이션 스위치의 전신인 로드 밸런서 탄생 이야기를 시작으로 그간 궁금했던 애플리케이션 스위치에 대한 모든 것을 6회에 걸쳐 살펴본다. <편집자>
최성열 시스코 APAC ANS CSE
sungchoi@cisco.com
네트워크 L4 스위치란 장비를 처음 접한 것이 강산도 변한다는 10년이 됐습니다. 그 동안 겪었던 많은 경험들을 네트워크타임즈 독자들과 함께하는 한다는 생각에 설레기도 하고 부담도 가네요. 오히려 몇 년 전이라면 조금 더 자신 있게 썼겠지만 지식과 경험은 알면 알수록 더 궁금해지는 것들이 많은지라.
혹자는 농담으로 ‘10년 동안 연구해온 달인’이라고 소개를 한 적이 있는데, ‘학문이나 기예에 통달해 남달리 뛰어난 역량을 가진 사람’이라는 ‘달인’을 아무데나 쉽게 가져다 쓸건 아니리라 생각합니다. 다만 기술은 공유돼야 한다는 생각에 독자 분들이 궁금해 하셨을 만한 내용들을 위주로 이야기를 해 나가겠습니다. 그럼 시작해 볼까요?
세상을 바꾼 인터넷
컴퓨터가 처음 외부와 소통을 할 때, 찌~~~지직하면서 연결되던 시대에는 인터넷이 아니라 PC통신이었다. 하이텔, 유니텔 등 PC통신은 그 당시 한참 유행이었고 사람들은 흥미로웠던 것 같다.
우리 집은 가난했기에 PC가 없었다. 그래서 한국통신에 가서 조그만 애들 장난감 같은 작은 모니터와 키보드가 있는 걸 하나 빌렸다. PC통신 전용단말기, 그래서 집에만 오면 하이텔이고 어디고 많이 돌아다녔다. 그런데 엄마가 그러셨다.
“성열아, 전화가 안 된다. 이상한 소리가 난다.”
“아, 그거요. 예. (어서 끊고) 한번 해보세요.”
PC통신 단말기 때문이라는 걸 아시고는 어머니는 내 PC통신 단말기를 싫어하셨다.(자장면을 싫어하시는 것과 같은 건가?)
1994년 그때 처음 인터넷을 만났다. 군대 가기 전 조그만 PC 조립/판매/유지보수를 하는 사무실에 출근을 했는데, 사장님이 뭔가를 열심히 연결하고 계셨다.
전화접속 인터넷이었다. 화면을 보여주셨다. 그 동안 텍스트 기반의 PC통신과는 달랐다.(물론 지금에 비하면, ㅋㅋㅋ) 그림 몇 개, 그리고 거의 텍스트 위주. 구글 메인 페이지를 생각하면 될 듯.
자, 이제 공부를 좀 해보자. 인터넷은 세상을 바꿔 놓았고, 초기의 웹 사이트들은 PC통신보다는 화려했지만 지금의 웹 사이트들 만큼 화려하지는 않았다. 그 말은 클라이언트가 접속을 그리 많이 하는 것도 아니고, 접속을 해도 별로 가져올게 없었다. 아마 지금 사람들이 접속해 보면 대부분 웃으리라. 아니 깜짝 놀랄 것이다.
그런데 우리가 많이 사용하는 네이버만이라도 한 번 보자. 사용자만이라도 얼마나 많겠는가? 필자만 해도 하루에 수 십 차례 들어가서 검색하고, 뉴스를 보고 그러는데, 그만큼 세상은 변했다. 개인 사용자라도 블로그, 카페, 개인 홈페이지를 어설프게 만들면 그건 외면의 시작이다.(내 카페라도 안 가겠다.)
회사? 그건 더더욱 그렇다. 쇼핑몰, 포털이 아닌 일반 회사들도 홈페이지를 빵빵하게 만들어야 사람들이 ‘이 회사 좀 하는 줄 안다’고 생각한다. 개인적으로 홈페이지가 엉망인 회사는 비즈니스적인 예의가 아니라고 생각한다. 그 만큼 중요한 것이다.
● 일단, 콘텐츠가 많다. 글, 그림, 사진, 다 화려해야 한다. 플래시, 동영상, 음악 등 대용량 콘텐츠들이 너무 많다.
● 접속자? 정말 많다. 셀 수 없을 조차 많다. 느린 거 절대 용서 못한다.(3초도 안 돼 떠난다)
● 그래서 결국 서버가 바쁘다. 넘 바쁘다. 성능 좋은 서버 아무리 사도 안 된다. 따라서 방법이 필요했다.
도대체 어떻게 해결 하지?
여기서 분위기를 좀 바꿔서 우리 이쁜 마토를 불러서 같이 이야기를 해 보도록 하자. 혼자 쓰려니 넘 심심하네. 우리 마토는 항상 궁금하다. 그래서 가끔 예리한 질문으로 곤란하게 만든다.
달: 안녕? 마토.
마토: 웅 오빠. 근데 오빠 얘기 보니까. 정말 궁금해지는데 서버 담당하는 사람들이 어떻게 문제를 해결 했을까? 쉽게 생각하면 그냥 큰 서버 사면되는 거 아닌가?
달: 아. 그거 그렇지. 쉽게 생각하면 그렇지. 처음에는 성능을 높이기 위해 CPU와 메모리를 확장하거나 서버를 좋은 걸로 사곤 했었지.
마토: 아 그렇구나, 보통 서버 도입할 때 보면 CPU, 메모리를 있는 장비에 더 추가하는 걸 이야기하는데. 장비를 새로 구매하는 것보다는 저렴하다고 하던데.
달: 그렇지. 그런데 이런 것들이 확장이 가능하더라도 도입한 서버를 처음부터 업그레이드 하는 게 아니라 몇 년 후에 서비스 규모가 커져서 해야 하기 때문에 업그레이드를 한다고 해도 생각만큼 성능을 확~ 올려주지는 않거든.
마토: 그럼, 그것보다는 성능이 좋은 서버로 교체하는 게 더 나을 수도 있겠다.
달: ㅋㅋ 그렇지? 사용자가 기하급수적으로 늘어나는데, 작은 서버로 서비스를 감당하기에는 좀 힘들지. 그런데 문제는 성능이야 10배, 20배 나아질 수는 있는데 큰 서버가 가격도 어마어마하게 비싸고, 아주 치명적인 문제가 하나 있거든.
마토: 치명적인 문제? 비싸고 좋은 서버가 무슨 문제가 있어? 문제도 안 생길 것 같은데. 빵빵해 보이잖아.ㅋㅋ
달: 서버가 그림처럼 커졌다면, 이제 달라진 게 뭐냐면. 그 회사의 서비스 규모가 커지고 중요한 수입원(?)이라는 거지. 사용자도 많아졌고. 이제는 더 이상 장난이 아니기 때문에 서비스가 다운된다는 건 그 동안의 경제적인 손실과 회사의 이미지, 그리고 사용자들 마져도 ‘아~~~ 이곳은 더 이상 내가 머무를 곳이 못 되는구나’라고 생각할 수 도 있거든. 물론 좋은 장비는 다운될 가능성이 적지만.
마토: 그럼 이중화 이런 거 하면 안 되나? 많이들 하는 거 같은데.
달: 흔히 고가용성(HA)이라고 부르는 이중화를 하면 되는데. 이것 또한 비용이 2배 가까이 들지. 좋은 방법이긴 한데 한 가지 더 생각하면, 서비스가 점점 확장되는데 능동적으로 대응이 힘들다는 거지. 언제까지나 큰 서버로만 확장하는 데는 한계가 있거든.
마토: 그렇구나. 뭐 좋은 방법이 있지 않을까?
달: 혹시 DNS를 이용한 로드 밸런싱이라는 거 들어봤니?
마토: DNS는 아는데, 이걸 이용한 로드 밸런싱은 잘 모르겠는데.
달: 그래? 그럼 이거 한번 볼래? 어때? 뭔가 좀 다르지?
마토: 어. 그렇네. 나도 nslookup 명령어는 쫌 써봤는데. 주소가 여러 개 나오네. 내가 알기로는 보통 한 개 씩만 나오는데. 이 사이트들(www.naver.com, www.google.com, www. cnn.com)은 여러 개씩 나오네.
달: ㅎㅎ 신기하지? 이게 바로 DNS를 이용한 로드 밸런싱이야. 외부에서 DNS 요청을 하면 같은 서비스를 하는 서버들을 여러 개 둬서 서비스 용량을 늘리는 거지. 내가 DNS 쿼리를 하면 A서버 IP를, 마토가 물으면 B서버 IP를. 서비스가 늘어나면 DNS 서버에 또 등록을 하면 되는 거지.
마토: 우와~ 신기한데. 그러면 서비스가 늘어날 때 마다 조금씩 늘려 가면 되겠네. DNS 변경은 돈이 드는 건 아니잖아?
달: 그렇지. DNS에는 존(Zone) 파일이라는 게 있는데 여기에다 이렇게 등록을 해 두면 돼.
달: 그러면 순서대로 192.168.1.1, 192.168.1.2, 192.168.1.3을 응답해 주는 거지.
마토: 그럼 서버들은 같은 콘텐츠들만 가지고 있으면 외부에서는 하나의 서버가 있는 것처럼 보이겠네?
달: 그렇지. 그래서 현재 대형 서버들을 운용하는 곳에서는 이렇게 운영하는 곳이 적지 않게 있거든. 내가 봤을 때는 정말 괜찮은 방법 같아. 모든 사이트 접속은 DNS를 반드시 거치게 돼 있으니까. 그런데 이 DNS 기반의 로드 밸런싱에는 문제가 있어. 뭐냐면 그들 서버들 중 하나가 다운될 경우, 그 IP로 DNS 응답을 받은 녀석은 서비스가 안 된다는 거지. 왜냐하면 일반적인 DNS 서버는 등록된 서버들이 살아있는지, 죽어있는지를 고민하지 않거든. 그것까지 하면 넘 힘들지 않겠어?
마토: 아, 그렇구나. 그럼 지금 이런 서버들은 어떻게 운용하지?
달: 저 서버라고 돼 있는 녀석들이 실제로는 서버 한 대가 아니라 우리가 이야기하려는 로드 밸런서를 하단에 둬 구성을 하면, 서비스를 보다 안정적으로 쓸 수 있겠지. ㅎㅎ 이야기가 점점 길어지네. 일단 그건 다음에 이야기하기로 하고. DNS를 이용하면 간단하게 확장을 할 수 있다는 게 중요한 거고. 우리가 로드 밸런서에서 이야기하는 라운드 로빈(Round Robin)은 순차적으로 분배를 해 준다는 거지.
달: 근데, 여긴 단점이 좀 있는데. 서버가 다운됐을 때 모른다는 거. 그걸 알고 복구 전까지 DNS에서 빼더라도 클라이언트의 DNS 캐시라는 것 때문에 그 서버로 자꾸 접속하려고 한다는 거. 이런 게 있는데 이거 설명 자꾸 하면 마토가 밤새 질문을 할 수도 있는데.
마토: ㅎㅎ 듣다 보면, 자꾸 궁금해져서.
달: 한 가지 더 있겠다. 혹시 클러스터링(Clustering) 이라고 들어봤니?
마토: 클러스터링? 들어본 것 같기도 한데. 그거 서버들 간에 정보 공유하고, 뭐 이러는 거 아닌가?
달: 들어본 것 같네. 클러스터링은 동일한 OS간에 동작하는 기술인데, 특정 서버(흔히 마스터)가 받아서 이를 여러 서버들로 분산시켜서 처리하는 기술이거든. 이렇게 하면 처음부터 좋은 서버를 도입하지 않고 서비스가 확장될 때마다 조금씩 추가하면 되거든. 리눅스의 LVS, 윈도우의 WLBS가 있고, 유명한 회사들은 보통 다 있거든.
마토: 우와 그래? 그럼 로드 밸런서 없이도 가능하겠네? 그럼 굳이 DNS나 로드 밸런서 같은 거 안 써도 되지 않나?
달: 음. 그럴 수도 있지. 그런데 이 클러스터링 방식은 일단 동일한 OS여야 하고, 거기에 사용되는 기술들이 별도 비용 없이도 사용할 수 있는 반면에 운영하는 사람들이 진짜 고급 엔지니어야만 하거든. 마토가 어떤 회사에 서버 관리자라고 해도, 완벽한 서비스 보장을 위해 자체적으로 그걸 운영한다는 건 쉬운 일은 아니지. 서비스 다운은 퇴사(?) ㅋㅋ 이렇게 될 수 도 있는데. 물론 로드 밸런서를 썼을 때는 해당 회사를 쪼면 되잖아. ㅎㅎ 농담이고. 다 장단점이 있는 것 같아. 하지만 로드 밸런서의 경우는 OS도 안 가리지, 그리고 필요한 다양한 기술들이 제공되니 그런 부담은 적겠지.
(전에 작은 회사에서 일할 때 방화벽, NAT, VPN 이런 걸 회사에 쓰려고 혼자 삽질(?)을 정말 많이 했던 적이 있었다. 회사에서 필요한 것이지만 직원들이나 네트워크를 위해 상용 장비나 소프트웨어를 도입하는 것은 작은 회사에서는 크게 중요하지 않게 생각한다. 괜한 돈이 들어간다는 생각하는 오너들도 많다.
그래서 내가 해 본 게, 리눅스를 이용해 NAT 서버, 윈도우를 이용해 VPN(PPTP, SSL), 메일서버, 웹서버 다 해 봤는데, 사람들이 그러더라, 안 될 때마다 우리 회사 네트워크(서버) 왜 이러니? 이거 누가 관리하는 거야. 도대체 일을 할 수가 없잖아)
이렇게 해서 하나 둘씩 전용 로드 밸런싱 장비가 나오게 되고, 이제는 서비스에서 없어서는 안 되는 솔루션이 됐답니다. 그게 로드 밸런서, L4~7 스위치, 그리고 요즘은 애플리케이션 스위치 등으로 불리기도 한답니다.
