본문 바로가기

Web

Web에 대한 주저리

WebRTC 기술에 호기심이 있었는데, 본격적으로 공부해볼 겸 블로그에 연재글처럼 써보려고 한다.

쓰기 전에 웹에 대한 전반적인 내용에 대해서 한번 정리해보고 가려고 한다.



1) 서론


웹 세상은 서버와 클라이언트의 통신으로 이루어진다.


웹 브라우저는 클라이언트에 해당한다. 서버에게 받은 수많은 텍스트(코드)들을 화면에 잘 나타내주는(렌더링) 역할을 한다.

네이버도. http://naver.com에 요청하면 받는것은 HTML, CSS, Javascript 등의 코드들일 뿐이지만, 사람이 이해하기 쉬운 화면으로 잘 렌더링해주는 역할을 브라우저가 한다.


서버는 클라이언트의 요청을 받고 응답을 보내주는 웹 서버 소프트웨어가 필요하다. 대표적으로 Apache, Nginx 등이 있다.

이런 서버 소프트웨어는 데이터를 주고받는 역할을 할 뿐이고, 요청을 받아 처리하여 응답을 만들어내는 역할은 따로 있다. PHP, NodeJS 등 런타임 환경이 그 역할을 한다. PHP 런타임은 PHP 언어로 작성된 코드를 수행하고, NodeJS는 V8이라는 Javascript 엔진을 기반으로 Javascript 언어의 코드를 수행한다. Javascript 언어는 옛날에는 클라이언트(프론트엔드)에서 주로 쓰이는 언어였지만, NodeJS와 함께 요즘은 서버(백엔드)에서도 많이 쓰이게 되었다.




옛날에는 Apache + PHP + MySQL 세 가지의 앞글자를 따서 APM 스택을 정말 많이 썼다. Apache는 웹의 굉장히 초기부터 써온 서버 소프트웨어이고, PHP는 C언어와 비슷한 문법이어서 쓰기 편하며 MySQL과의 호환도 매우 좋은 언어이다. 이 세 가지면 서버단의 코드 구현과 DB연동까지 뚝딱 쉽게 가능하다. 지금도 구글에 APMsetup 이라고 검색하면, 윈도우 환경에 APM 스택을 한번에 쉽게 깔아주는 설치 프로그램을 받을 수 있다.


(하지만 요즘 어디가서 PHP 얘기하면 반응이 안 좋다. 아직도 그딴거 쓰는 사람이 있냐고... 보안상 상당히 안 좋은 구조여서, 해커에게 서버의 데이터를 뺏기기 쉽다. 그래서 서버 프로그래머가 신경써야 할 부분이 상당히 많다. 그래도 몇 년 전까지는 "페이스북에서도 PHP를 일부 쓰거든요?" 라고 쉴드칠 수 있었지만, 페이스북에서도 그 PHP를 안 쓰려고 자체 프로그래밍 언어까지 만들어버렸다. - https://code.fb.com/developer-tools/hack-a-new-programming-language-for-hhvm/)



이후, Apache와 PHP 대신 NginX와 NodeJS를, 그리고 여기에 ExpressJS라는 라우팅 프레임워크와, AngularJS라는 MVC 프레임워크를 섞어서, MEAN 스택 (MongoDB + ExpressJS + AngularJS + NodeJS)이 등장했다. 이 MEAN의 특징은 전부 다 Javascript 언어로 이용한다는 것이다. 이후로 AngularJS 대신 React, VueJS 등의 프레임워크가 많이 생겼는데, 이것들도 Javascript 언어 기반이다.




2) 아주 간단한 서버-클라이언트 동작 방식



위와 같이 크롬으로 PHP 기반의 서버에 요청을 보낼 수 있는데, PHP 코드는 간략히 아래처럼 생겼다.

(Pseudo 코드입니다. 실제 API와 매우 다릅니다.)

<!doctype html>

<html>

  <head>

    <title>안녕하세요</title>

  <head>

  <body>

    <div>

      <?php

        $conn = mySQL_connect(ip, id, password);

        $result = mySQL_query($conn, "get user's name");


        echo $result["name"];

      ?>

      님 안녕하세요~

    </div>

  </body>

</html>



위 코드는 HTML 코드 중간에 PHP 코드가 삽입된 코드이다. 이는 클라이언트는 볼 수 없는 코드이고, 서버 측에 있는 PHP 확장자의 코드이다.

클라이언트가 보낸 요청값에 따라 저 DB에 요청하는 것의 결과값이 바뀐다.

그리고 완성된 결과물에는, 서버 언어(PHP, NodeJS 등)는 전혀 없이, HTML, CSS, Javascript 코드의 조합으로만 이루어진다.


<!doctype html>

<html>

  <head>

    <title>안녕하세요</title>

  <head>

  <body>

    <div>

      hyonzin 님 안녕하세요~

    </div>

  </body>

</html>



이것이 클라이언트가 서버에게 받은 응답이다. 이것을 화면에 렌더링하면 아래처럼 크롬 화면에 나타난다.



클라이언트와 서버의 아주아주 단순한 형태의 요청과 응답이다.




3) 많은 요청을 감당하기 위한 분산 처리


클라이언트가 많아서 위와 같은 통신이 매우 많을 경우를 대비해서, 클라이언트의 요청의 가장 앞단에 Load Balancer가 있어서 부하(Load)를 분산시키는 역할을 해주기도 한다.


위처럼 서버 3개가 있으면, 단순히 사용자 요청에 따라 순서대로 첫번째, 두번재, 세번째에게 요청을 골고루 나눠주는 것만으로도 Load를 잘 분산시켜줄 것이다. 물론 더 잘 분산시켜주는 정책도 많이 있을 것이다.


사용자의 요청이 유동적일 경우를 대비해서, 시스템 엔지니어들은 인프라를 잘 구성할 필요가 있다. 내가 알고 있는 한 방법은, Virtual Machine 또는 Docker Container를 이용해 자원 pool을 만들어두고, 더 많이 필요한 쪽에 더 많은 자원을 쓰도록 하는 것이다.




위는 8개의 "서버"와 4개의 "DB"를 예로 들었다. 만약 요청이 정말 없는 때에는 VM 또는 도커를 서버, DB에 한 개씩만 만들어두었다가, 요청이 늘어나는 것을 감지하면 VM 또는 Docker 컨테이너를 유동적으로 더 생성하고 그 IP를 Load Balancer 등에 등록해서, 요청을 분산시키게 만들 수 있다.


VM의 경우, 클라우드 시스템의 오픈소스인 OpenStack을 보면, 서버의 자원 사용량을 모니터링하여 몇 십 % 이상일 때 VM을 확장하는 방식을 자동화하는 기능이 있다. 그리고 사용량이 적으면 자동으로 축소해준다.

Docker의 경우에도, 위처럼 애플리케이션을 Docker Container 단위로 배포하고 확장하는 것을 자동화해주는 Kubernetes (줄여서 K8S) 기술을 구글에서 공개했다. Docker와 K8S를 공개함으로써 많은 곳에서 이를 이용해 애플리케이션을 배포하고 있다. 네이버의 경우에도, 동영상 플랫폼이나 쇼핑, 카페 등등 많은 카테고리가 있는데, 위처럼 Docker Container 단위로, Load가 많은 카테고리에 더 많은 Container를 자동으로 할당하는 방식을 이용하고 있다고 들었다.



4) 돈 없는데


위처럼 많은 요청을 감당하는 분산 방법을 알고있다고 해도, 물리적인 서버 자원이 충분하지 않다면 아무 소용이 없다.

그래서, 클라이언트에게 서버의 짐을 약간 지어주는 방법이 생겨났다.

서버는 중재자 역할만 하고, 클라이언트 하나가 서버 역할을 해서, 다른 클라이언트들이 그에게 달라붙어 서로 통신하는 것이다.




주로 스트리밍 서비스에서 이런 방식을 많이 쓴다고 한다. 고화질 동영상을 수많은 사람들에게 한꺼번에 전달해주려면, 서버에서만으로는 안 될 것이다. 스트리밍 영상을 같이 시청하고 있는 클라이언트끼리 주고받음으로써, 클라이언트에게 짐을 조금 주지만, 많은 사용자들이 안정적으로 영상을 볼 수 있게 된다.

게임에서도 워크래프트나 여러 스팀게임의 경우, 온라인상의 한 플레이어가 방을 만들고 다른 플레이어들이 그 방에 접속하는 경우, 이런 방식을 많이 이용한다. 물론 이는 웹 브라우저에서 일어나는 것은 아니어서 WebRTC는 아니지만, 유사한 방식을 이용한다. 워크래프트의 경우 6112번 포트로 요청을 받아 이러한 서버 역할을 하는데, 6112번 포트가 막혀있으면 방을 못 만든다. 공유기를 쓰는 경우에 이런 일이 벌어져서, 내 컴퓨터와 공유기 바깥 6112번 포트를 이어주는 port-forwarding을 해줘야 방 만드는 것이 가능해진다.


아무튼 이러한 WebRTC를 이용하면, 눈물나는 환경의 서버를 가지고도 클라이언트에게 짐을 맡겨서 어느 정도 서비스 운영이 가능해지기 때문에, 또한 스트리밍을 다루는 많은 회사에서도 이 기술을 요구하기 때문에, 공부를 시작해보고자 한다.




5) 공부하자


이상으로.. WebRTC 공부하려는 목적을 생각해보며, 웹의 전반적인 얘기를 생각나는대로 써보았다.

이 글을 쓰면서도 애매하게 알았던 것들을 확실히 해서 좋은 것 같다. 막연히 생각만 했던 WebRTC도 예제 등 정리하며 잘 공부해봐야겠다.





'Web' 카테고리의 다른 글

웹페이지 랭킹 알고리즘: HITS vs PageRank  (4) 2019.05.19
API 서버  (0) 2019.03.11