Web Application Architecture

요즘(?) 웹 어플리케이션의 아키텍처는 저렇게 단순하지 않다.
클라이언트와 서버만으로 구성된 웹앱은 웹이 개발된 초기에나 존재했을 것이다. 
요즘 일반적인 Web Application Architecture 를 살펴보자.


아키텍처에 Application Server와 DBMS가 추가된 모습이다.

Application Server는 한국에서는 Web Application Server(WAS)라고 부른다. Web Server(WS)는 정적인 처리만 가능한데 WAS는 동적인 처리를 가능하게 한다. 동적? 정적? 무슨 소리인지.. 이해가 안되는게 정상이다. 여기서 동적인 것은 '유도리 있다'로 연상시키면 좋을 것 같다. 스택오버플로우에서 가져온 시나리오를 통해 이해해보도록 하자.

Scenario 1: Web server without an application server
you have an online store with only a web server and no application server. The site will provide a display where you can choose a product from. When you submit a query, the site performs a lookup and returns an HTML result back to its client. The web server sends your query directly to the database server (be patient, I will explain this one in our next nugget) and waits for a response. Once received, the web server formulates the response into an HTML file and sends it to your web browser. This back and forth communication between the server and database server happens every time a query is run.
Scenario 2: Web server with an application server
if the query you want to run has already been done previously and no data has changed since then, the server will generate the results without having to send the request to the database server. This allows a real-time query where a second client can access the same info and receive real time, reliable information without sending another duplicate query to the database server. The server basically acts as an intermediate between the database server and the web server. This allows the information pulled to be reusable while in the first scenario, since this info is embedded in a particular and "customized" HTML page, this is not a reusable process. A second client will have to request the info again and receive another HTML embedded page with the info requested -highly inefficient. Not to mention that this type of server is very flexible due to its ability to manage its own resources, including security, transaction processing, messaging and resource pooling.

시나리오 1 : 응용 프로그램 서버가없는 웹 서버

WS만 있고 WAS가 없는 쇼핑몰이 있습니다. 이 사이트는 제품을 선택할 수 있는 페이지를 제공합니다. 쿼리를 제출하면 사이트에서 조회를 수행하고 HTML 결과를 클라이언트에 반환합니다. WS는 사용자의 요청을 데이터베이스 서버에 직접 보내고 응답을 기다립니다. 수신된 WS는 응답을 HTML로 변환하고 웹브라우저로 보냅니다. 서버와 데이터베이스 서버 간의 통신은 쿼리가 실행될 때마다 발생합니다.


시나리오 2 : 응용 프로그램 서버가있는 웹 서버

WAS가 있는 쇼핑몰이 있습니다. 실행하려는 쿼리가 이미 완료되었지만 그 이후로 데이터가 변경되지 않은 경우, 서버는 데이터베이스 서버에 요청을 보낼 필요없이 결과를 생성합니다. 이를 통해 두번째 사용자가 동일한 정보에 액세스할 수 있고 또 다른 중복 조회를 데이터베이스 서버에 보내지 않고도 신뢰있는 실시간 정보 조회가 가능합니다. WAS는 기본적으로 데이터베이스 서버와 WS의 중간 역할을 합니다. 이렇게하면 첫번째 상황에서 가져온 정보를 재사용할 수 있습니다. 


아직까지도 이해가 안될 수 있다. 실체를 못봤으니 어찌보면 당연하다. ('라익'라는 과일이 있다고 생각해보자. '라익'을 '비타민이 풍부해서 노화방지와 장운동 개선에 도움이 되고, 혈압 강하에 탁월한 효과가 있다.'라고 설명하면 그게 무엇인지 정확한 개념이 잡히지 않는다. 사진을 보여주고 나서야 '아 이거구나!'라고 깨닭을 것이다.)


















댓글

댓글 쓰기

이 블로그의 인기 게시물

AWS RDS DB 인스턴스에 연결하기 (Oracle Database Instance)

이미지
이전 포스팅에서 DB 인스턴스를 생성하는 방법 을 알아보았다. DB 인스턴스에 연결하기 위해서 먼저 연결에 사용되는 정보를 확인하는 방법을 알아보고나서, SQL*PLUS와 SQL Developer을 사용하여 DB 인스턴스에 연결하는 각각의 방법을 알아보자. 시작하기전, 현재 생성된 DB Instance는 Oracle EE 이고, 개발환경은 windows 환경임을 밝힌다. DB 인스턴스 연결에 사용되는 정보 확인 Amazon RDS에 생성된 Instance 클릭하여 인스턴스 정보를 확인합니다. ● Connect 섹션의 Endpoint 와 Port 는  dns_name  와  port  에 사용됩니다. ● Details 섹션의 DB Name (SID)은  database_name 에 사용됩니다. SQL*PLUS를 사용하여 DB 인스턴스에 연결 DB 인스턴스에 연결하는 명령어 스니펫은 다음과 같습니다. sqlplus user_name @(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST= dns_name )(PORT= port ))(CONNECT_DATA=(SID= database_name )))            user_name과 비밀번호 입력란에는 DB 인스턴스를 생성할 때 Step 2 : Spectify DB details - Settings - Master username & password에 지정한 값을 입력합니다. user_name ,  dns_name ,  port ,  database_name  를 각각 대체하여 입력하고 비밀번호까지 입력합니다. 그 결과 연결 성공 시 다음과 비슷한 출력이 나타납니다. 다음에 접속됨:              ...
자세한 내용 보기

tomcat server.xml ( 톰캣 서버 설정 )

이미지
server.xml을 통해서 tomcat이라는 web application server를 이해해보고자 한다. server.xml 설정에 목적이 있는 포스팅이 절대 아니다. 참고로 WAS는 J2EE 스펙(Servlet Container와 EJB Container의 기능)을 구현한 서버이지만, tomcat은 Servlet Container만 구현하고 EJB Container 기능은 없어서 WAS가 아니라는 사람도 있다. 그래서 ' 톰캣 == 서블릿 컨테이너 '라고 알고있어도 좋다. 무엇이든 제대로 알려면 공식 문서를 보는 것이 신뢰성도 높고 마음도 편하다. 그래서 아래 아파치 톰캣 config doc을 참조하여 tomcat WAS(서블릿 컨테이너)의 구조를 파악하려고 한다. https://tomcat.apache.org/tomcat-9.0-doc/config/index.html Top Level Elements  -  <Server>  is the root element of the entire configuration file, while  <Service>  represents a group of Connectors that is associated with an Engine. Connectors  - Represent the interface between external clients sending requests to (and receiving responses from) a particular Service. Containers  - Represent components whose function is to process incoming requests, and create the corresponding responses. An Engine handles all requests for a Service, a Host handles all requests fo...
자세한 내용 보기

Git resolving merge conflicts as Mark resolved (mark resolved 옵션으로 해결)

이미지
이전 포스팅 : Git merging branches (브랜치 합치기) 브랜치를 합치는 도중에 충돌이 일어날 수 있다. A브랜치와 B브랜치가 있다고 치자. A와 B브랜치의 같은 부분이 다른 코드로 작성되어 있을 때 두 개의 브랜치를 합치면 충돌이 일어난다. merge conflicts 해결방법 중에서 충돌이 일어난 코드를 자신이 직접 수정하여 해결하는 방법을 알아보자. Resolving merge conflicts - mark resolved 1. master 브랜치를 checkout한 상태(HEAD가 master브랜치인 상태)로 아래와 같이 testbranch2 브랜치를 생성한다. 2. testbranch2 브랜치를 checkout 한다. (HEAD : testbranch2 -> working directory가 testbranch2 상태가 됨 ; 그럴듯한 언어로 어떻게 말해야될 지 모르겠다 ) 3. Working Directory의 wow.java 파일이다. 1번에서 master가 checkout된 상태로 Commit: Working copy parent 옵션을 선택했기 때문에 master의 Working Directory와 동일하다. 4. 소스코드 'teacher' 를 추가한다(HEAD : testbranch2). 그리고 커밋한다. 5. master를 checkout하고 소스코드 'student'를 추가한다(HEAD : master). 그리고 커밋한다. 6. 현재 인덱스이다. 7. master 브랜치에 testbranch2 브랜치를 merge하기위해서, master 브랜치를 checkout하고 testbranch2를 우클릭하여  Merge testbranch2 into current branch 를 클릭한다. 8. Confirm Merge 확인창이 뜨면  확인 을 클릭한다. 9. (4),(5)번에서 소스코드의 같은 부분을 수정했기 때문에 ...
자세한 내용 보기