웹 서비스 구조 - 확장 세 번째

이제 문제는, 템플릿 자체가 HTML gudxo

그러니까 HTML의 포맷을 가지고 있단 말이다.

 

즉 이 자체가 백엔드 개발임에도 불구하고 사용자단의 기계 형태에 영향을 받도록 되어 있으니까,

템플릿을 받아다가 뭔가 서버 작업을 해야 하고 이런 일들이 생기는 것.

-> 문제 : 유지보수하기가 굉장히 까다로워진다.

 

그래서 이 두 개를 완전히 분리하도록 시도.

 

동적 문서 => 핵심은 Data.

 

서버는 데이터만 신경써서 보내겠다!

 

• 클라이언트 입장에서 보면 request 의 의미는 서버에게 뭔가 입출력을 해달라는 것이다.
• 그래서 여기서 나오는 개념이 C / R / U / D 가 된다.
• 이걸 통칭해서 생성된 개념이 소위 RESTful API
• 결국 WAS 단에서 API도 구현을 해야 한다.
• 구현된 API에 의해서 어떤 코드가 작동을 하는데
• 그러면 이 RESTful API를 콜하는 것은 URL 형태로 클라이언트에서 뭔가 날아올 것이고 그게 컨트롤 제어 체계가 되어서, 거기에 어떤 모델의 데이터를 가져와서 그 API가 무엇을 해주고...
• 이 서버는 웹서버인데 RESTful 한 API 서버가 되는 것이다. 이런 형태로.

 

이제, 발생할 수 있는 문제

• 인터넷이 느려지면 이 서버는 끝장난다.
• 처리가 문제나면 WAS 가 느려진다.
• DB가 느려지면, 모든 게 다 느려진다.
• => 이러한 것을 방지 위해 "장애대응" 이라는 개념이 등장함.

질의 - 응답에 대한 "응답 시간"을 데이터베이스에서는 항상 모니터링 중이다.

JVM 개념과 하는 일.

 

결국 웹 서버가 잘 작동하는가 아닌가는 JVM을 쳐다본다.

이 모든 것을 관리/감독해주는 소프트웨어가 하나 있는데,

그게 APM이다. Application Performance Management System

 

APM이 대표적으로 하는 일

• 응답 시간 체크
• JVM 모니터링

 

이러한 형태를 종합해서 3-tier 가 된다.

 

그리고 보안문제는 이 3개의 방어체계로 막는다.

IPS / SSL / WAF

- 가장 앞단에는 무조건 하나의 IPS가 들어가 줘야 하는것이고

- 방화벽 역할 같은 WAF는 웹 서버 뒤로 넘어오기도 한다.