이 장을 읽으면서 이제까지 배운 파편화된 배경지식이 한데 모이는 즐거운 경험을 할 수 있었습니다. Spring 프로젝트를 비롯한 수많은 웹 프로젝트에서 사용하고 있는 DB중심의 아키텍처 구성과 다중화에 대해 작성한 글입니다.
아키텍처와 아키텍처 설계란?
아키텍처란 컴퓨터 '시스템을 만들기 위한 물리 레벨의 조합'입니다. 구체적으로는 하드웨어와 미들웨어(DBMS)의 구성을 말합니다. 따라서 아키텍처 설계는 어떤 기능의 서버, 저장소, 네트워크 기기를 사용할 것인지를 시스템의 목적과 기능에 따라 결정하는 것을 말한다. 아키텍처 설계는 물리 설계로 말할 수 있으나, 시스템의 뼈대를 구성하는 상위개념의 설계를 강조하기 위해 '아키텍처 설계'라고 말합니다.
목적과 기능에 맞는 아키텍처 설계를 빼놓고서 시스템 구축의 비용산출을 하는 것은 불가능하기 때문에 아키텍처 설계는 특히 시스템 개발 초반에 매우 중요한 단계입니다.
아키텍처의 역사
이제까지 사용한 아키텍처의 역사는 다음처럼 3단계로 나눌 수 있습니다.
1. Stand-alone(~1980)
2. 서버/클라이언트(1990~2000)
3. Web 3계층(2000~현재)
stand-alone
Stand-alone 아키텍처는 말 그대로 데이터베이스가 동작하는 머신(DB 서버)이 네트워크에 연결되지 않고 독립적으로 존재하는 것을 말합니다. 이 아키텍처에서는 미들웨어(DBMS)와 애플리케이션 소프트웨어가 같은 DB서버에서 동작합니다.
따라서 Stand-alone 구성이 보편적으로 사용되던 대에는 DB 서버를 사용하기 위해서는 반드시 서버실의 거대한 컴퓨터 앞에 앉아서 물리적으로 접근해야 사용할 수 있었습니다. 이 때는 여러대의 컴퓨터를 네트워크로 연결하여 같이 작업한다는 개념이 나오기 전이었고 인터넷과 LAN과 같은 통신기술이 지금처럼 발달하지 않았습니다.
자연스럽게 예상되듯, Stand-alone 구성에는 여러 단점이 있습니다.
- 물리적으로 접근해야하는 불편함
Stand-alone 아키텍처로 구현된 시스템을 사용하기 위해서는 서버실에 들어가 물리적으로 접근하여 서버 앞에 앉아 사용해야합니다. 따라서 서버에서 멀리 있지만 시스템을 사용해야할 경우에는 서버실로 찾아 가야하는 큰 불편함이 있습니다. - 동시에 접속이 불가함
네트워크에 연결되어있지 않아 하나의 시스템에 한 사용자만 접근하여 시스템을 사용할 수 있습니다. 사용 수요가 많은 날이면 여러명의 사람들이 서버실에 줄을 서야겠죠? - 가용성이 떨어집니다
가용성이란 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도를 말합니다. 가용성을 수식으로 표현한다면 정상적인 사용 시간(Uptime)을 전체 사용 시간(Uptime+Downtime(고장이나 보수 등으로 사용하지 못한 시간))으로 나눈 값을 말한다. 이 값이 높을수록 "가용성이 높다"고 표현합니다.
Stand-alone 아키텍처는 시스템이 운영되는 서버가 한 대 뿐이므로 해당 서버가 고장나거나 버그가 발생하면 서비스가 정지되기 때문에 가용성이 떨어집니다. - 확장성이 낮음
이 아키텍처는 성능의 개선 수단이 매우 제한적입니다. 시스템이 동작하는 서버가 한 대 밖에 없기 때문에 해당 시스템의 성능을 향상시키기 위해서는 머신의 성능 자체를 향상시키는 방법밖에 없습니다. 이 방법을 사용하여 향상 시키더라도 그동안 시스템은 정지되고 가용성이 더욱 낮아지게됩니다.
Stand-alone 아키텍처의 단점에 대해 구구절절 써 놓았지만 좋은 점도 있습니다. 구축이 간단하므로 규모가 작은 작업이나 테스트를 쉽게 할 수 있습니다. 또한 물리적인 접근만이 가능하므로 서버실의 문을 잘 단속하고 컴퓨터에 이상만 없다면 보안이 매우 철저할 수 밖에 없습니다. 하지만 단점이 너무커서 장점이 이를 도저히 커버할 수 없습니다. 이러한 Stand-alone의 몇몇 단점을 개선해서 나온 구성이 '클라이언트/서버' 입니다.
클라이언트/서버
먼저 클라이언트와 서버는 어떻게 구별하는지 간단히 알아보겠습니다.
서비스를 요청하는 컴퓨터를 클라이언트, 요청을 받아 이를 처리해서 응답하는 컴퓨터를 서버라고 합니다. 서버의 종류는 서비스의 대상에 따라 달라집니다(ex. 이메일을 서비스-메일서버)
물리적으로 1명의 사용자만 DB에 접근할 수 있는 Stand-alone의 단점을 개선하여 서버와 클라이언트를 분리하고 네트워크로 연결하여 복수의 클라이언트가 서버를 사용할 수 있는 구성이 클라이언트/서버 입니다. C/S, 클라서버, 2계층 구성이라고도 말합니다. 주로 기업내의 제한된 네트워크(LAN)에서 이용했습니다.
이 아키텍처의 단점은 불특정 다수가 사용하는 인터넷에서 DB에 접근할 경우 보안상의 문제가 생길 수 있다는 것과 클라이언트 환경에 따른 관리비용의 문제등이 있습니다.
관리비용의 문제에 대해 조금 더 자세히 보겠습니다. 인터넷을 이용한 웹 애플리케이션의 장점은 컴퓨터에서 브라우저만 있다면 어느 환경에서든 이용할 수 있다는 것입니다. 하지만 당시에는 PC에 설치하여 사용하는 애플리케이션(Native application)을 사용했습니다. 애플리케이션을 개발하는 기업에서는 당사의 제품을 배포, 업데이트하거나 버그 패치를 배포할 때는 클라이언트 환경에 맞게 각각 다르게 애플리케이션을 작성해야했습니다. 심지어 복잡한 프로그램을 업데이트하기 위해서는 개발자가 출장을 가서 업데이트를 하기도 했습니다. 이 때문에 기업에서는 천문학적인 비용이 들고 소비자 입장에서도 수많은 패치중 무엇을 다운받아야하는지 등의 어려움이 있었습니다.
이 때문에 나온 방법이 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리해서 서비스 관리비용을 줄이는 Web 3계층 아키텍처입니다.
Web 3계층
여기서 말하는 3계층이란 아래의 세 가지의 조합을 말합니다.
- 웹 서버
- 애플리케이션(=앱 서버)
- DB
그림
- 웹 서버
- 웹 서버는 클라이언트로 부터 온 HTTP요청을 받고 앱 서버에 전달해주고, 앱 서버에서 온 응답을 클라이언트에게 전달합니다. (가교역할)
- 웹서버에는 아파치, IIS(Internet Information Service)등이 있습니다
- 불특정 다수의 사용자가 DB에 접근하기 위해 요청을 받는 역할을 웹서버에 한정해서 DB 계층의 보안을 높일 수 있습니다
- 애플리케이션(앱 서버)
- 비즈니스 로직이 구현된 애플리케이션
- 요청 처리, DB로부터 데이터를 받아오고, 결과를 가공하여 반환하는 역할
- 비즈니스 로직을 이 계층에 집중(클라이언트->서버 관리)하여 관리비용을 낮춤
- 앱서버에는 Tomcat등이 있습니다
출처 : https://ko.wikipedia.org/wiki/%EA%B0%80%EC%9A%A9%EC%84%B1 (가용성)
