1편

실전에 투입되면 어떻게 대규모 트래픽을 감당해야하나
우리 개린이들이 아, 요즘 개는 민감한 단어인가
알기 쉽게 설명을 해주겠다 이 말입니다.

목차

• Load Balancer
  • SPOF
  • Stateless
  • Stateful 하면 안돼?
  • 코드만이 아니라 인프라 환경도 마찬가지
• Dockerfile을 써야하는 이유
• 사실 가장 중요한건 코딩
  • 100명 들어오면 죽는 서버라고? 헛소리 하지마라
  • 단순 수식으로 계산해보자
  • 그러니까 코딩이 제일 중요하다
• 야 근데 뭐 도구같은건 설명이 없냐

Load Balancer

로드밸런서를 모르면 일단 시작을 못한다는 말입니다.
모르는 분들께선 검색을 먼저 하십시오

로드밸런서는 크게 2가지 종류가 있습니다.

• 로드밸런서 기능을 하는 물리장비
• Nginx, Envoy 같은 애플리케이션 레벨 로드밸런서

이 중에 물리장비는 딱히 알 필요가 없습니다.
평범한 경우에는 L4 장비를 만질 일이 잘 없거든요.
근데 있어갖고 직접 다뤄야 하면... 화이팅

SPOF

Single Point of Failure(단일 장애 지점)
이라는 말이 있습니다.

위 그림에서, 서버는 3개여서 셋 중에 하나 죽는다고
서비스가 죽을 것 같진 않은데
로드밸런서가 죽으면 그냥 ㅈ될 망할 것 같지 않습니까?

여기서는 로드밸런서가 SPOF가 되는겁니다.
그럼 어떻게 대응하냐?
뭐... 방법은 여러가지가 있는데

솔직히 말하자면
각자의 사정에 따라 알아서 잘 처리할 일
정도로 할 수 있겠습니다.

각자의 환경(자금, 장비, 지원 등)이 다르고, 그렇기에 정답도 없어서
심영처럼 '님' 을 외칠수가 없습니다.
에엑따

DB도 SPOF가 될 수 있는데... 화이팅입니다

Stateless

개발에 관심이 많아서 이런저런 글을 찾아다니며 읽는 분들이면
Stateful과 Stateless에 대해 언급하는 글을
언젠가 한 번이라도 본 적이 있을겁니다.

뭐, 직접적으로 저걸 검색하지 않아도
JWT같은걸 검색해도 나올겁니다.

어떻던가요?
Stateless를 지지하는 쪽이 많지 않던가요?

Stateful 하면 안돼?

지난 글에 만들어서 올린 짤인데
Stateful한 환경에서는 Sticky Session 방식이 강제됩니다.

만약, 서버가 하나 죽었다 쳐봅시다.
서비스 자체는 죽진 않겠지만
로드밸런서에 연결된 다른 서버로 넘어간 유저들은
갑자기 모든 인증이 풀려서
서비스 장애를 겪었다고 인식하게 될겁니다.

덤으로 Sticky Session에 대해 검색해보시면
무슨 문제가 있는지 알게 될겁니다.

코드만이 아니라 인프라 환경도 마찬가지

위 짤에 나왔던 것 처럼
'윈도우에서만 가능하다'
이런 느낌으로 환경이 강제되버리면
꼭 Scale out이 아니더라도
운영상 굉장히 힘들어집니다.

사실 닷넷3을 PHP3, Java6 같은걸로 바꿔도 비슷해집니다.
특히 PHP는 apache 설치, fpm 설치, mysqli나 pdo 설치, php-뭐시기 하는 유틸 설치/세팅 등등 에효 쒥쀍

그러니 최대한 LTS환경에서 코딩하고
php도 제발 LTS환경으로 composer같은거 쓰세요
Dockerfile로 빌드가 가능하도록 만드는게 베스트입니다.

Dockerfile을 써야하는 이유

Dockerfile을 작성해서 컨테이너로 만들 수 있으면 굉장히 유용합니다.
서버리스란걸 아실련지요?

초창기의 서버리스는 각 클라우드 제공사별 특별히 다른 방식의 코딩이 필요했는데
요즘은 그냥 컨테이너로 만들 수 있으면 서버리스로 가동할 수 있습니다.
클라우드 제공사에 종속되지 않고, 서버리스를 이용할 수 있는거죠.

꼭 서버리스나 쿠버네티스를 쓸게 아니라도
컨테이너로 만들면 굉장히 편리한 점이 많습니다.

VM에 배포하려고 해도
docker run 으로 대충 실행하면 잘 돌아가구요
php 버전 맞추고, fpm 설치해서 apache설정에 넣어주고, php-뭐시기 유틸 설치해서 그것도 apache 설정에 넣어주고 이ㅈㄹ 안해도 된다 이런 말입니다

CI/CD 및 롤백 같은거 할 때도 좋은 점이 많구요.
VM/서버리스/k8s 다 잘 돌아가니 운영하다 환경 바꾸기도 수월합니다.

아 대충 잘 모르겠다 이러시는 분들은
실무에서 개발자는 여기까지만 알면 되는 도커 / 쿠버네티스
를 보시면 되겠습니다.

사실 가장 중요한건 코딩

종종 이런거 쓰시는 분들 있는데,
그... 2020년 넘어서 이런 오래된 버전으로 자의에 의해 새로운 서버 만드시는 분들은
........그......아닙니다

사실 버전을 뭘 쓰든
코딩을 잘 하면 성능은 좋을 수 있다고 생각하는 쪽이긴 한데...
코딩을 잘 하시는 분들은 새 버전으로 잘 따라 오시던데...

그러니까...
막 최신기술 무조건 다 따라가야돼!
이런게 아니라 업계의 흐름은 따라가야 하지 않나
이런 말입니다.

2024년에 Ubuntu 12.04 쓰고 있으면
문제이지 않습니까?

잡담은 대충 여기까지만 하고
코딩을 잘 해야된다는게 무슨말이냐면

100명이 접속하면 죽는 서버
vs
10000명을 수용할 수 있는 서버

이런 식이 되면 비용 차이가 어마어마하다는 말입니다.

100명 들어오면 죽는 서버라고? 헛소리 하지마라

옛날에 거쳐왔던 회사중에
in-house 시스템에 "점심 메뉴 랜덤 추천" 해주는
이스터에그(?)가 있었는데

입사했을 때 들었던 설명 중에
"저걸 쓰지 마라. 회사 내 시스템이 다 죽어버린다"
였습니다.

총원이 400명쯤 되는 회사였는데
대충 한 20~100명쯤이 돌리면 죽는다는 소리였겠죠?

대충 랜덤값 만들어서 주면 되는데
나름 특별하게 만들고 싶었는지 이런저런 수식을 더 추가해놨는데
문제는 그 연산을 유저의 frontend-side에서 하는게 아니라
백엔드에서 처리해주고 있었다는겁니다.

그래서 과장이 아니라 진짜 100명이 들어오면 죽는 서버였습니다.
하필 PHP였다

그런게 그 회사에만 있는 특별한 경우냐 하면
꼭 그렇지도 않습니다.

단순 수식으로 계산해보자

대충 vm 1개에 월 2만원이라 치고 계산해봅시다.

10000명 수용 가능한 서버가 한 번 Scale out 하는 상황이면
100명 들어오면 죽는 서버는
10000 / 100 = 100 이니까 100번은 넘게 Scale out 해야될겁니다.

단순 수식으로만 해도
vm 100개(200만원) vs vm 2개(4만원)
이렇게 됩니다.

가격이 50배 넘게 차이나는 겁니다.
이게 미니멈 계산이니 좀 더 높다 이런 말입니다
Windows면 라이센스 비용땜에 vm 더 비싼거 감안하면 ㄷㄷ

그러니까 코딩이 제일 중요하다

일단 서비스가 뒤1지면 안될테니
대표님들은 처음엔 이런 태도일겁니다.
첫 달 명세서 받고나면 빨리 돈 줄이라고 닥달하겠지 ㄷㄷ

그러니 예외적인 케이스를 제외하면
앞서 말했던 것들을 잘 지켜서 하는게 좋습니다.

저도 예외적인 케이스를 만들어봐서 잘 압니다.
메타버스 만든다고 RTC서버 돌리고 그러면
그것들은 예외적인 케이스라 어쩔 수 없거든요

그런걸 제외하면 Scale out 가능한 구조로
코딩을 해야 합니다.

야 근데 뭐 도구같은건 설명이 없냐

인터넷에 검색했을 때 나오는 도구들은
2차적인 것들 입니다.

1차적인 것들이 제대로 갖춰지지 않으면
그 위에 뭘 갖다 얹어봤자 의미가 없습니다.