웹서버는 수많은 요청을 어떻게 처리할까?

앞선 글에서는 URL을 따라 브라우저가 원하는 서버와 자료를 찾아가는 과정을 살펴보았다. 주소창에 입력한 한 줄의 주소 안에는 서버를 찾기 위한 도메인과 서버 안에서 원하는 자료를 가리키는 경로 등이 함께 들어 있었다. 브라우저는 이 정보를 이용해 요청을 만들고 인터넷을 통해 서버로 보냈다.

그렇다면 그 요청이 서버에 도착한 뒤에는 무슨 일이 벌어질까?

평소에는 별로 생각할 일이 없다. 뉴스 제목을 누르면 기사가 열리고 검색어를 입력하면 잠시 뒤 검색결과가 나타난다. 로그인을 하면 내 이름이 표시되고 쇼핑몰에서는 내가 주문했던 상품을 다시 확인할 수 있다.

그런데 같은 사이트를 이용하고 있는 사람이 나 혼자일 리는 없다. 방문자가 많은 사이트라면 같은 시간에도 누군가는 기사를 읽고, 누군가는 로그인하고, 다른 사람은 검색하거나 결제를 하고 있을 것이다.

이 요청들은 모두 서버 쪽으로 들어간다. 그래도 각 사용자에게는 자신이 요청한 결과가 돌아온다. 내가 검색한 내용이 다른 사람에게 전달되어서는 안 되고, 다른 사람의 주문내역이 내 화면에 나타나서도 안 된다.

우리가 웹페이지 한 장을 보는 짧은 시간 동안 서버에서는 이런 요청을 구분하고 처리하는 일이 계속되고 있다.

한줄 요약

웹서버는 브라우저에서 들어온 요청을 확인한 뒤 필요한 자료를 보내거나, 프로그램의 처리가 필요하면 해당 작업을 연결하고 그 결과를 다시 브라우저에 전달한다.

서버라고 하면 보통 커다란 컴퓨터부터 떠올린다

서버라고 하면 많은 사람이 전산실이나 데이터센터에 있는 장비를 먼저 떠올린다. 랙 안에 비슷하게 생긴 컴퓨터가 여러 대 꽂혀 있고 불빛이 계속 깜빡이는 모습을 본 적이 있다면 더욱 그럴 것이다.

실제로 그런 장비를 서버라고 부른다. 많은 사용자가 접속하는 서비스를 운영하려면 일반적인 개인용 컴퓨터보다 높은 성능과 안정성을 갖춘 장비가 필요한 경우가 많다.

다만 서버라는 이름은 장비의 생김새만으로 결정되는 것은 아니다. 어떤 서비스를 제공하고 있느냐도 중요하다.

웹사이트의 요청을 받아 처리하면 웹서버 역할을 할 수 있고, 파일을 보관하고 다른 컴퓨터에 제공하면 파일서버가 될 수 있다. 데이터베이스를 운영하는 장비라면 데이터베이스 서버라고 부른다.

집에서 사용하는 PC에도 웹서버 프로그램을 설치할 수 있다. 물론 많은 사람이 사용하는 실제 서비스를 가정용 PC 한 대로 운영하자는 이야기는 아니다. 서버라는 말이 반드시 특별한 모양의 컴퓨터만을 가리키는 것은 아니라는 뜻이다.

웹서버가 하는 일은 앞서 살펴본 HTTP와도 연결된다. 브라우저가 HTTP 요청을 보내면 웹서버는 그 요청을 받아 어떤 자료를 원하는지 확인한다. HTTPS를 사용하는 사이트라면 암호화된 통신 절차를 거쳐 이 요청이 오간다.

예를 들어 브라우저가 특정 이미지 파일을 요청했다면 웹서버는 해당 파일을 찾아 응답으로 보낼 수 있다. 존재하지 않는 주소를 요청했다면 정상적인 자료 대신 앞서 살펴본 404와 같은 상태를 돌려줄 수도 있다.

사진 한 장을 보내는 것과 로그인 처리는 다르다

웹사이트에 들어가면 사진과 아이콘, 글, 메뉴 등 여러 가지 내용이 한꺼번에 보인다. 브라우저는 화면을 만드는 데 필요한 자료를 서버에 요청한다.

그중 서버에 이미 저장되어 있는 이미지 파일 하나를 요청했다고 해보자. 이 경우에는 비교적 일이 단순하다. 웹서버가 요청받은 파일을 찾아 보내주면 된다. 미리 만들어 둔 HTML이나 CSS 파일도 비슷하게 전달할 수 있다.

이런 자료를 흔히 정적 콘텐츠라고 부른다. 같은 파일을 요청했다면 누가 접속했든 기본적으로 같은 내용을 보내줄 수 있다.

그런데 로그인 화면에서 아이디와 비밀번호를 입력한 경우라면 이야기가 달라진다. 서버는 입력된 내용을 확인해야 한다. 정상적인 사용자라면 누구인지도 알아야 하고, 로그인한 뒤에는 그 사용자에게 맞는 정보가 나타나야 한다.

쇼핑몰에서 주문내역을 눌렀을 때도 마찬가지다. 주문내역이라는 이름의 HTML 파일 하나를 찾아 모든 사람에게 똑같이 보내는 방식으로는 처리할 수 없다. 내가 접속했다면 내 주문을 찾아야 하고 다른 사람이 접속했다면 그 사람의 주문을 찾아야 한다.

검색은 더 쉽게 차이를 볼 수 있다. 누군가는 '레이더'를 검색하고 다른 사람은 '인공지능'을 검색할 수 있다. 검색 화면은 같아 보여도 서버가 돌려줘야 하는 결과는 서로 다르다.

이처럼 사용자가 무엇을 입력했는지, 누가 요청했는지, 현재 저장되어 있는 데이터가 무엇인지에 따라 결과가 달라지는 내용을 동적 콘텐츠라고 한다.

규모가 있는 웹서비스에서는 이런 처리를 웹서버 혼자 모두 맡지 않는 경우가 많다. 웹서버가 먼저 요청을 받고, 로그인이나 검색처럼 별도의 처리가 필요한 작업은 웹 애플리케이션이 담당하도록 구성할 수 있다.

이 대목에서 WAS(Web Application Server)라는 용어도 자주 등장한다. 특히 국내 기업이나 공공 정보시스템을 접하다 보면 꽤 자주 볼 수 있는 이름이다.

웹서버와 WAS를 공부할 때 '웹서버는 정적 콘텐츠, WAS는 동적 콘텐츠'라고 외우는 경우가 많다. 처음 개념을 구분할 때는 도움이 되지만 실제 시스템이 언제나 그렇게 깔끔하게 나뉘는 것은 아니다. 사용하는 기술과 시스템 구성에 따라 역할을 나누는 방식은 달라질 수 있다.

누군가는 웹사이트가 느려지면 서버부터 의심한다

누군가는 웹사이트가 느려지면 흔히 “서버가 느린가 보다”라고 말한다. 틀린 말은 아니다. 실제로 서버에 문제가 생겨 화면이 늦게 뜨는 경우도 있다.

하지만 원인이 항상 웹서버에 있는 것은 아니다. 웹서버는 정상적으로 요청을 받고 있는데 뒤에서 필요한 데이터를 찾는 데 시간이 오래 걸릴 수도 있다. 다른 시스템에서 정보를 받아와야 하는데 그쪽의 응답이 늦는 경우도 있고, 네트워크 상태가 좋지 않아 데이터가 오가는 데 시간이 걸릴 수도 있다.

사용자는 이런 차이를 알기 어렵다. 버튼을 눌렀는데 한참 뒤에 화면이 바뀌면 그냥 사이트가 느리다고 느낀다.

서비스를 운영하는 쪽에서는 사정이 다르다. 어디에서 시간이 걸리고 있는지를 찾아야 한다. 웹서버까지 요청이 제대로 들어왔는지, 프로그램 처리가 늦어진 것은 아닌지, 데이터베이스가 제때 결과를 돌려주고 있는지, 다른 시스템과의 통신에 문제가 생긴 것은 아닌지 확인해야 한다.

서버의 CPU 사용률이 높아서 문제가 생기는 경우도 있다. 메모리가 부족할 수도 있다. 그런데 CPU와 메모리는 여유가 있는데도 서비스가 느린 경우 역시 얼마든지 있을 수 있다.

사용자가 보는 것은 결국 '화면이 늦게 뜬다'는 하나의 현상이지만 그 원인은 여러 곳에 숨어 있다.

짧은 생각

정보시스템에서 장애나 성능 저하를 볼 때 겉으로 드러난 현상만 보고 원인을 단정하기는 어렵다. 웹사이트가 느리다는 말 하나에도 서버, 프로그램, 데이터베이스, 네트워크 등 여러 원인이 있을 수 있다. 문제가 생긴 지점을 찾는 일이 생각보다 중요한 이유다. 하지만 누군가는 엔지니어가 뚝딱하면 나온다고 생각한다. 그래서 트러블 슈팅에 오랜 시간이 걸리는 것을 못참는 경우가 종종 있다.

그런데 수천 명이 한꺼번에 접속하면 어떻게 될까

서버에 한 사람의 요청만 들어온다면 처리 방법을 이해하기 어렵지 않다. 요청을 받고 필요한 일을 처리한 뒤 결과를 보내면 된다.

실제 웹서비스에서는 여러 사람의 요청이 계속 들어온다. 규모가 큰 서비스라면 그 수가 훨씬 많아진다.

여기서 먼저 생각해 볼 수 있는 방법은 들어온 순서대로 하나씩 처리하는 것이다. 첫 번째 요청을 모두 처리한 뒤 두 번째 요청을 처리하고, 그다음 세 번째 요청을 처리하는 식이다.

사용자가 몇 명 되지 않고 모든 작업이 금방 끝난다면 큰 문제가 없을 수도 있다. 하지만 어느 한 요청이 오래 걸리기 시작하면 문제가 생긴다. 앞의 작업이 끝나기를 기다리느라 뒤에 들어온 요청들이 계속 밀릴 수 있기 때문이다.

실제 서버 프로그램은 많은 요청을 다루기 위한 방법을 사용한다. 여러 작업을 나누어 처리하기도 하고, 어떤 작업이 데이터나 외부 시스템의 응답을 기다리는 동안 다른 요청을 먼저 처리하기도 한다. 여러 CPU 코어를 이용해 작업을 나눌 수도 있다.

구현 방법은 서버 프로그램이나 개발 환경에 따라 다르다. 여러 실행 단위를 두는 방식도 있고 많은 연결에서 발생하는 이벤트를 효율적으로 처리하도록 만든 방식도 있다.

이런 차이는 평소 웹사이트를 이용할 때는 거의 보이지 않는다. 사용자는 주소를 입력하거나 버튼을 눌렀을 뿐이고, 서버 안에서는 다른 사용자들의 요청과 함께 처리되고 있다.

사람이 더 몰리면 서버도 나눠서 쓴다

공연이나 스포츠 경기 예매를 해본 사람이라면 예매 시작 시간에 사이트가 갑자기 느려지는 경험을 한 번쯤 해봤을 수 있다. 인기 상품 판매나 중요한 결과 발표처럼 특정 시간에 사람이 몰리는 서비스에서도 비슷한 일이 생긴다.

평소에는 충분했던 서버가 짧은 시간에 쏟아지는 요청을 감당하지 못하는 것이다.

처음에는 서버의 성능을 높이는 방법을 사용할 수 있다. CPU를 더 좋은 것으로 바꾸고 메모리를 늘리면 한 서버가 처리할 수 있는 일도 많아진다.

그런데 계속 한 대의 성능만 높일 수는 없다. 장비에도 한계가 있고 비용도 빠르게 늘어난다. 무엇보다 중요한 서비스를 서버 한 대에만 맡겨두면 그 서버에 문제가 생겼을 때 서비스 전체가 영향을 받을 수 있다.

그래서 큰 웹서비스에서는 여러 대의 서버가 같은 서비스를 나누어 맡는 구성을 볼 수 있다.

여러 서버가 준비되어 있다면 들어오는 요청도 적절하게 나눠줄 필요가 있다. 이 일을 하는 장치나 소프트웨어를 로드밸런서(Load Balancer)라고 부르고, 요청을 나누는 일을 로드밸런싱(Load Balancing)이라고 한다.

서버가 세 대 있다고 해서 단순히 첫 번째, 두 번째, 세 번째 서버에 차례로 보내는 방법만 있는 것은 아니다. 어느 서버에 현재 연결이 적은지, 정상적으로 서비스를 제공하고 있는지 등을 확인하여 요청을 보내는 방법도 있다. 서비스의 성격에 따라 적용하는 방법도 달라진다.

여러 서버를 사용하는 데에도 신경 써야 할 부분은 생긴다. 조금 전까지 한 서버에서 처리하던 사용자의 다음 요청이 다른 서버로 들어갈 수도 있기 때문이다. 로그인 상태나 여러 서버가 함께 사용하는 데이터도 생각해야 한다.

서버를 여러 대 놓는 것만으로 끝나는 일이 아닌 셈이다.

그렇다면 내 주문내역은 서버 어디에 있을까

앞에서 쇼핑몰 주문내역 이야기를 했다. 사용자가 주문내역을 누르면 서버가 그 사람의 주문을 찾아 보여준다고 했다.

그런데 생각해 보면 서버는 그 정보를 어디에서 가져왔을까?

회원이 몇 명 되지 않고 주문도 몇 건뿐이라면 정보를 관리하는 일이 그다지 어려워 보이지 않는다. 하지만 실제 쇼핑몰에는 회원정보뿐 아니라 상품명, 가격, 재고, 주문번호, 주문일자, 배송상태처럼 계속 쌓이는 정보가 많다.

이런 정보를 프로그램이 실행되는 동안 메모리에만 가지고 있을 수는 없다. 오늘 서버를 껐다가 내일 다시 켰다고 어제의 주문기록이 사라져서는 안 된다. 몇 년 전에 가입한 회원의 정보도 필요할 때 다시 찾을 수 있어야 한다.

이때 등장하는 것이 데이터베이스다.

웹 애플리케이션에서 주문정보가 필요하다면 데이터베이스에 저장된 내용 가운데 해당 사용자와 관련된 자료를 찾는다. 필요한 정보가 돌아오면 이를 이용해 사용자가 볼 화면을 만들 수 있다.

게시판도 크게 다르지 않다. 사용자가 글을 작성하면 그 내용은 저장되어야 하고, 나중에 다시 게시판에 들어왔을 때도 읽을 수 있어야 한다. 검색을 했다면 수많은 글 가운데 조건에 맞는 자료를 찾아야 한다.

우리가 보는 웹페이지 한 장에는 이렇게 그때그때 찾아온 정보가 섞여 있을 수 있다. 회원 이름이나 주문내역, 상품의 재고 수량 같은 정보가 처음부터 HTML 파일 하나에 모두 적혀 있었던 것은 아니다.

정보시스템의 규모가 커지면 이 관계도 더 복잡해진다. 웹서버가 여러 대일 수도 있고, 데이터베이스 역시 한 대가 아닐 수 있다. 필요한 정보가 다른 정보시스템에 있어 그쪽에 요청해야 하는 경우도 생긴다.

기업이나 공공기관에서 사용하는 정보체계를 들여다보면 한 시스템 안에서도 여러 서버와 프로그램, 데이터베이스가 연결되어 있는 모습을 어렵지 않게 볼 수 있다. 앞으로 군 정보체계를 이야기할 때도 이런 구조는 다시 만나게 될 것이다.

서버까지 왔으니 이제 저장된 정보를 볼 차례다

URL을 입력하면서 시작한 요청은 인터넷을 지나 서버까지 왔다. 서버에서는 요청받은 파일을 보내기도 하고, 프로그램을 실행해 사용자에게 맞는 결과를 만들기도 했다. 접속자가 많아지면 여러 요청을 함께 처리해야 했고, 한 서버로 부족하다면 여러 서버가 일을 나눌 수도 있었다.

여기까지 오면 웹사이트가 화면 몇 장과 서버 한 대로 이루어진 것이 아니라는 사실도 조금 보인다. 사용자가 보는 화면 뒤에는 요청을 받는 곳이 있고, 실제 업무를 처리하는 프로그램이 있으며, 오랫동안 보관해야 하는 정보도 있다.

다음에 살펴볼 것은 그 정보다.

회원 한 명의 이름을 저장하는 것은 어렵지 않다. 회원이 백만 명이 되고 주문과 게시물까지 계속 쌓이면 얘기가 달라진다. 필요한 정보를 찾을 때마다 처음부터 하나씩 뒤질 수도 없다.

그 많은 정보는 어떤 모양으로 저장되어 있고, 컴퓨터는 그중 원하는 것을 어떻게 빠르게 찾아낼까?

다음 글에서는 서버 뒤에서 이런 정보를 보관하고 찾아주는 데이터베이스를 이야기해 보려 한다.