요 근래 페이스북 같은데에 광고 올라오는거 보면
신입한테 대규모 대용량(은 왜?) 트래픽을 알려주겠다면서
그런 광고가 많이 나오던데
대규모는 사람이 많이 들어와서 대규모인데
대용량은 유저가 200TB씩 업로드 해서 대용량인가 하는 생각이 드는군요
근데 상식적으로 유저가 200TB씩 업로드 하는건 만나기 어려운 일이고
보통은 사람이 많이 몰리는 상태에 다들 관심이 많지 않겠습니까?
대용량 옮기는건 하드 뽑아서 비행기 타고 차 타고 이동하는게 제일 빠르고 저렴한 방법 아임미까
글이 너무 길어져서
대충 2부작 정도로 나눴습니다
목차
대규모 레이드 트래픽 하면 생각나는거
k8s? 쿠버네티스? Kubernetes?
이런거 생각하실 것 같군요?
왠지 다 같은 것 같지만
뭐, 다른거 생각하셔도
동적으로 스케일 아웃 되는 그런거일겁니다.
채신기술 쓰면 다 되는거 아니냐
그래요, 최신기술 다 좋죠
2024년 5월 24일 기준, 닷넷 LTS는 8.0이다
그리고 놀랍게도 이런 상황은 꽤 흔하게 있습니다
엄청 오래 전에 개발한것도 아니고 비교적 최근인 5년 이내에 새로 작성된 코드에서도
그런데 이런거 가져다가
"거 우리도 뭐 scale out이다 k8s다 하는 채신 기술 좀 해주소"
하면 되겠냐 하는 그런 말입니다.
네, 뭐.. 못하는건 아닙니다만...
대규모 레이드 트래픽 처리에 대한 기초 매커니즘
애초에 어떻게 처리하는지 모르는 분들을 위해 급하게 추가함
일단 뭐 어떻게 하냐 부터 알고 시작해야 되는거 아니겠습니까?
기초적으로는 서버에 직접 DNS 붙여서 들어가는걸 생각하실겁니다.
그런데 유저가 많이 몰려서 서버가 감당하지 못하는 상태가 되면 어떻게 하냐?
서버의 스펙을 높인다
흔히들 Scale up 이라 부르는 그겁니다.
말 그대로 서버의 스펙을 높여서 더 많은 처리가 가능하게 만들면 됩니다.
일단 이 방식에는 몇 가지 문제가 있는데
- 스펙을 올리려면 하드웨어를 뜯어야 하기에 서비스의 중단이 강제된다.
- 어느 선을 넘어가면 하드웨어의 가격이 크게 오른다.
- 스펙이 암만 높아도 작동중에 하드웨어에 문제가 생겨서 꺼지면 서비스가 중단된다.
그래서 일반적으로는 스펙을 높이는 방식은 잘 쓰지 않습니다.
서버의 갯수를 늘린다
흔히들 Scale out이라 부르는 그겁니다.
앞에 봤던 그림들보단 조금 복잡해지긴 했지만
딱 봐도 서버가 3개니까 저 중에 하나 죽어도
서비스가 죽진 않게 생기지 않았습니까?
그리고 로드밸런서가 죽어버리면
보통은 이런 방식으로 서버의 갯수를 늘려서
트래픽을 분산시켜 대응을 합니다.
대규모 레이드 트래픽을 감당해온 방식
전통적인 배어메탈 구매 방식
그... 곰철이 아니라 쌩 물리장비...
흔히들 블레이드 라던가 하는 서버를
여러개 충분히 사서 IDC에 갖다넣고
예상에 비해 사람이 더 많이 몰려서 서버가 부족하면
4대 명검 뽑아들고 얼른 서버 더 사서 갖다놓는 방식이죠.
클라우드가 없던 시절에는 다 이렇게 했습니다.
뭐 클라우드 이런거 다 조상님이 만들어주신게 아니라서
온라인 서비스들이 클라우드에서 운영된건
이제 10년 조금 넘었을 뿐이죠.
IDC가 뭐냐
춥고, 시끄럽고, 외로운 곳
이런 서버랙이 수백 수천대 있는 곳이 IDC 입니다.
서버랙 단위로 자리를 대여해주고 돈을 받죠.
감옥인가
자리가 곧 돈이기에 한 서버랙에 최대한 많은 서버를 집어넣어야 했고
한정된 공간에 많은 서버를 넣어야 하니 블레이드서버 라는 길죽한걸 쓰게 됩니다.
왜 회사에 놓는게 아니라 IDC냐 하면
- 인터넷 성능의 보장
- 정전 시 비상발전 시스템이 있어
ㅈ되기 전에긴급조치 할 시간을 벌 수 있음 - 화재시 빠른 진압
을 기대 - 쿨링 및 환기시스템
등등을 제공하기에 IDC에 갖다넣습니다.
스케일 아웃 by 휴먼
서버를 5개 사서, 백엔드를 3개 올려야 되는 상황이라고 가정해봅시다.
(하나는 로드밸런서로 써야하니 4개라 치고)
왜 저렇게 나눠서 넣었냐?
각각의 서버에 백엔드 그냥 몰아넣으면 안되냐?
이렇게 생각하실 수 있는데
만약 그런 상황에서 물리적 서버 하나가 죽어버리면
해당 서비스 자체가 걍 죽어버리는겁니다.
그래서 저렇게 나눠서 실행하는데,
만약 백엔드 애플리케이션의 자원 제한이 어려운 경우,
하나의 백엔드 애플리케이션이 폭주해서
물리서버 자체가 다 죽어버리는 경우도 생기기에
VM으로 관리하는 케이스도 많습니다.
배어메탈 + 가상화(VM)
기본적인 방법론은 원시적인 방식과 동일하나
VMWare의 ESXi 같은걸 사용해서
VM을 띄워서 관리하는 방식입니다.
VM 하나당 백엔드 하나 띄우고 그렇게 하는거죠.
이렇게 하면 백엔드 애플리케이션의 자원 제한을 하지 않아도
폭주해봤자 VM 하나 죽을 뿐이고 물리서버는 비교적 안전해집니다.
그리고 각각의 백엔드 애플리케이션을 띄우기 위한 환경을 만들어놓은
골든 이미지 (.iso) 파일을 준비해놓고
확장해야 할 때 다른 서버에 골든 이미지를 올리면
금방 스케일 아웃이 가능하다는 장점이 있습니다.
VM을 올렸을 때의 문제점
앞에선 장점만 얘기했는데, 단점도 있습니다.
이렇게 네트워크가 복잡해져서
개발자가 다 관리하기엔 꽤나 어려운 상태가 됩니다.
뭐, "내가 다 관리 가능함" 해도 좋기는 한데
개발자는 개발 해야지 네트워크 만지고 있는다고
한세월 보내고 있으면 그게 맞나 하는 생각도 듭니다.
인프라 관리하는 개발자면 해야지
빨리해!!
그 시대의 Scale Out
앞에선 스케일아웃 by 휴먼 이라 했지만
능력 좋으신 분들은 일찍부터
CPU 사용량 체크해서 동적으로 vm 생성하고
자동으로 로드밸런서 연결도 시키고
사용량 떨어지면 다시 줄이고
그런거 다 직접 구현해서
자동화 시키는 사람들도 있었습니다.
그런데, 역으로 생각하면
자동화가 이미 다 만들어져서 이용만 하면 되는 이 시대에도
Scale out by human 하시는 분들도 계십니다.
그러니까 채신기술 들이밀어도 안되는건 안되는거
클라우드와 k8s의 등장
클라우드에 서비스 올려서 운영한건
이제 10년이 조금 넘었기에 오래된 역사가 아닙니다.
클라우드에서 Scale out 기능 다 제공해주고
서버리스라는 개념이 생겨나며 더더욱 간편해지고
터지면 문자도 주고 메일도 주고 슬랙도 주고 말이죠
외계인 이제 구글갔냐 TPU라는거 만드는거 보니까
구글에서 외계인 고문해서 k8s라는게 나오면서
꼭 클라우드만이 아니더라도
배어메탈에서도 k8s 클러스터를 만들어서
조낸 어렵게 어렵지 않게 auto scaling 구현을
할 수 있는 시대가 되었습니다.
어? 뭐가 바뀐 것 같은데?
이런 시대인데도 코딩을 잘 못하면
클라우드에서도 Scale out by human 하고있고...
그런데 이미 IDC에 곰철이 배어메탈 많이 꼽아놨는데 어쩌냐
곰철이 일 안시키고 놀게 한다고 판다가 되진 않아... 충격
이미 IDC에 장비를 많이 사놓은 회사들은
클라우드를 안 쓸 수도 없고,
IDC에 있는 장비들 놀게 할 수도 없는 상황이 옵니다.
제가 이런거 직접 다뤄봤는데요
10년 넘으면 당시에 조낸 비쌌던 곰철이도 이제는 데탑이랑 비벼짐
근데 이런게 수십대 놀고있으면 문제긴 함
그래서 요즘은 클라우드에 배어메탈 등록해서
IDC의 자원을 최대한 활용한 뒤에
IDC의 자원을 다 쓰면 클라우드의 자원을 사용하도록
클라우드 제공사에서 기능을 제공하기도 합니다.
구글 클라우드의 Anthos같은거 써서 하이브리드 k8s 하려는 시도도..
우리 회사(클라우드메이트)가 국내 최초 사례를 했었..
https://cloud.google.com/customers/lge?hl=ko
와 회사 홍보 오졌다
차회예고
거지같은 서버를 붙잡고 Scale out을 시도하는
우리의 개발자쨔응
저글링같이 몰려드는 유저 앞에서
과연 서버를 지켜낼 수 있을 것인가
사장님은 뒤에서 이러고 있으면서
정작 돈은 한 푼도 안쓰고 있는데
우리의 개발자쨔응은 흐콰하지 않고
앞으로의 운명을 잘 헤쳐나갈 수 있을 것인가
그리고 신앙심을 깨우친 개발자쨔응
10개의 댓글
재밌네요 아무것도 모르는 입장에서 이해하기도 쉬워요! 개인적으론 RAID와 비슷하다는 생각도 들었어요
이미 IDC에 장비를 많이 사놓은 회사들은 클라우드를 안 쓸 수도 없고, IDC에 있는 장비들 놀게 할 수도 없는 상황이 옵니다.
이런 관점은 처음 생각해봤네요 ㅎ
IDC 센터에서 자본사람 개추