개발에 관한 하고 싶은 이야기 : 파트1 - 웹 개발과 분산

이전 칼럼에서 메인 프레임 시대에 대해 다루었다.

 

그에 따라 2000년대 초반과 그 이전의 개발에 대해 다루고자 한다.

 

먼저 인터넷 시대 이전에는  메인 프레임의 시대다.

 

이전 설명과 같이 메인 프레임 시대는 내부 인트라넷, 즉, 내무망에 접속할 수 있는 전용 단말기를 이용해 서버에 접속하는 시대였다. 따라서 전용 단말기는 메인 프레임과 하나의 시스템을 공유하고 전용 역할을 부여받은 기기로써의 역할하였다.

 

당시 대부분의 메인 프레임서버는 전용 소프트웨어 + 데이터 베이스(또는 테입 저장 시스템)가 주를 이루었다.

현대의 도메인서버 + 웹서버 + WAS + DB 같은 복잡한 구조가 아닌 정말 심플한 구조 였다.

 

그림으로 표현하면 아래와 같다.

 

 

TCP/IP 통신으로 서버와 직접 패킷을 주고받는 형태로 개발된다.

또한 Database에 바로 접속하는 경우도 있다.

 

필자는 2013년에 거의 위와 유사한 시스템을 본 적이 있다. 2013년에 말이다.

 

자, 그럼 이런 형태가 어떻게 발전되었는지 살펴보자.

 

살펴보기에 앞서 하나의 전제를 두고자 한다.

새로운 기술은 과거의 문제를 해결하기 위해 현재에 존재한다.

 

과거의 메인 프레임에 기초한 기술들의 문제는 규모 및 지속성 등을 고려하지 않았다.

이는 즉, 수직적 확장만을 의미한다.

 

용량이 필요한가? 더 늘려라.

처리속도가 더 필요한가? 더 고사양 CPU로 변경한다.

램이 필요한가? 더 많은 램을 추가한다.

 

수직적 확장은 금세 벽에 부딪히고 늘어만 가는 데이터를 처리하지 못하고 모든 곳에서 문제가 발생한다.

따라서, 백업과 시스템 정비에 따른 정지가 반드시 필요하게 된다.

 

2010년까지 특수한 경우의 시스템들, 특히 Windows CE로 만들어졌던 단말기 시스템들은 직접적으로 Database에 접속하는 시스템도 있었고, 이런 경우 아무리 빠른 전용회선을 이용한다 하더라도 물리적 거리에 따른, 또는 접속하는 위치에 따른 속도 제한 또는 연결 상태의 불안전성에 따라 Database에 문제를 일으킬 수 밖에 없는 구조였다.

(Windows CE는 2023년 역사의 뒷 길로 사라졌다.)

 

현대의 대부분의 웹 시스템들은 위에 서술한 단점을 극복하기 위해 설계되고 만들어지게 되었다.

 

그럼 초기의 인터넷 시스템은 어떨까?

 

초기의 인터넷 시스템도 사실 크게 다르지 않다.

아래의 구조를 보자.

 

 

 

위 구조에 나타나 듯 초기의 인터넷도 DNS라는 사설 공급자에게 IP만 확인할 뿐, 메인 프레임과 동일한 구조를 갖는다.

다만, 전용 단말기가 아닌 PC나 모바일의 브라우저를 통해 접속할 뿐이다.

 

하지만 여기서 큰 차이점이 있다. 모든 시스템이 웹 서버를 거치고 사용자 단말, 즉, 브라우저는 해석된 결과만 전송받는다. Database와 분리되는 구조인 것이다.

 

위에 간단하게나마 Windows CE 시대에는 사용자 단말이 직접 Database에 접속한다고 이야기하였다.

만약 DB서버는 한국에 있고 접속하는 사용자는 미국에 있다고 가정한다면 모든 데이터 처리에 있어 거리에 따른 전송 지연이 DB 부하에 직접적 원인이 될 수 있다.

 

웹 시스템이라면 해석된 결과를 HTML을 통해서 전송받기에 실제 DB와 관련된 처리는 모두 웹 서버를 거쳐 진행되므로 부하문제나 응답성이 개선될 것이다.

 

더 축약해서 말하면 CS 개발과 Web 개발의 차이다.

 

웹 개발이 발전함에 따라 더 높은 응답성(인프라의 확충과 상향)과 수평적 확장이 가능하게 되었다.

 

웹 개발이 발전하는 과정에 2000년부터 2012년까지 Json과 Xml의 대결이 있었고, Xml은 복잡성과 더불어 처리 용량의 증가에 따라 역사에 뒤 안길로 사라졌고(하지만 아직도 그 잔재들은 남아 있다.) Json 포맷이 웹 서버 통신의 기본이 되었다.

(이후에 Xml, Soap을 대체하기 위한 Grpc가 나오게 되었다.)

 

초기 웹은 단순히 해석된 마크업 -Html-을 표시하는 기능에 불과했으나 Javascript의 발전에 따라, 또한 JQuery, Ajax가 등장함에 따라 매우 획기적인 변화를 겪는다. 바로 동적 화면을 구성할 수 있기 때문이다. 

(풀스택 개발자라는 명칭은 이때 등장했다. jquery로 화면을 조작하고 WAS에서 비즈니스 코딩을 하고 Database에 삽입, 수정, 삭제, 조회하는 쿼리를 작성하는 개발자를 풀스택 개발자라 한다.)

Api 통신을 통한 Request, Response는 웹 화면을 더욱 데스크톱 애플리케이션에 가깝게 만드는 동기가 되었고 매우 빠른 속도로 발전했다. (웹 표준의 발전에 따라, 또한 node.js의 등장에 따라, 또한 react, vue, next.js의 등장에 따라...)

 

자, 이제 분산 환경에 대해 알아보자.

아래의 그림을 살펴보자.

 

 

웹 서버는 2개가 되었고 서버에 접속하기 위해 사용자가 거쳐야 하는 장치에 로드밸런서가 추가되었다.

 

로그밸런서는 L7계층(OSI 7 Layer) 동작하는 서버 분산 장치이다.

그림에 나와 있든 이제 사용자는 직접 웹 서버에 연결되지 않는다. 대신 로드밸런서에 접속하고 로드밸런서에 Private IP로 웹 서버 IP가 할당되게 된다.

로드밸런서는 부하 분산의 역할도 맡고 있으므로 접속 사용자 설정에 따라 접속자는 유휴 상태의 서버에 분해하게 된다.

(실제적으로는 유후 상태라기보다 접속 IP 카운터로 접속자 제한에 따라 카운트하며 전달할 뿐이다.)

 

위와 같은 설정에 따라 사용자는 하나의 웹 서버에 연결되고 한번 연결된 서버에 따라 계속적으로 (브라우저를 닫고 재시작하지 않는 한) 로드밸런서에 할당된 IP에 연결되게 된다.

(TCP/IP의 특성에 따라  연결과 전송, 회신은 계속적으로 갱신되게 되는데, 로드밸런서는 접속자의 IP에 부여한 Gate역할을 하게 되고 하나의 문을 열어준 경우가 되며 이에 따라 하나의 Private IP를 강제로 연결하게 해 준다. 따라서 접속이 끊어지지 않는 한 -브라우저 종료 또는 접속 PC의 종료-, 접속된 사용자는 둘 중 하나의 웹 서버에 계속적으로 접속하게 된다.)

 

지금까지 서버 분산에 대해 다루었다.

 

파트 2부터는 데이터베이스 다중화에 대해 이야기해 볼 것이다. 이 부분은 클라우드 환경, 특히, Managed라고 표현되는 가상머신에 직접 데이터베이스를 설치하고 운영하는 것이 아닌 클라우드 제공자가 완전 관리하는 데이터베이스를 사용할 경우 다소 의미가 떨어지지만 발전사에 따른 과정을 이해한다는 점에서 의의가 있을 것이다.

 

그럼 파트 2에서...

 

 

 

참조 : 가상 면접 사례로 배우는 대규모 시스템 설계 기초