| no | 요구 기능 | 기대사항 | 구현 방법 | 분석 ( 불만족 부분, 그에 해결방안 ) |
|---|---|---|---|---|
| 1 | 정적 data 통신 | 정적소스만 보여주기 | 웹 서버 | 불만족 스런 부분 - 동적은 안됨 |
| 1.2 | 동적 data 통신 | 동적 통신 추가 | WAS | 불만족 스런 부분 - 역할이 과함 • 이미지 제공 + 애플리케이션 코드 제공 - |
| 1.2.1 | 데이터(정적,동적) 통신 분담시키기 | WAS가 역할이 많아, 잘 죽으므로, 죽었을때 오류화면을 고객에게 인지 또는 역할 분담하여 정상구동 확률을 높이기 | 정적 리소스는 웹서버가 처리 • 웹서버는 애플리케이션 로직은 와스에 요청을 위임 | WAS는 중요한 애플리케이션 로직 처리만 전담가능 • 시스템 리소스를 확실하게 쓸 수 있음. - 구성 (WEB, WAS, DB ) • 정적리소르는 파일을 불러오기만 하면되서 정상적으로 살아있음. • 애플리케이션 로직이 동작하는 WAS는 잘 죽음. 1.=> web서버에 오류화면HTML을 제공해, 고객에게 지금서비스가 불가하다는 것을 보여줄수 있음. 2.=> cdn 정적리소스를 캐쉬할수 있도록해서 제공하고 3.=> 데이터만 주고받을때는(API), 와스로만도 가능 |
웹 어플리케이션
1. 웹 프로젝트의 (필수, 선택) 구성
| no | 요구 기능 | 조건 | 구현 방법 | 분석 ( 불만족 부분, 그에 해결방안 ) |
|---|---|---|---|---|
| 1 | 보통 웹에서 데이터 통신 | HTTP 기반으로 동작 | http | HTTP -> 거의 모든 형태의 데이터 전송 가능 • HTML, TEXT • IMAGE, 음성, 영상, 파일 • JSON, XML (API) • 거의 모든 형태의 데이터 전송 가능 |
| 1.1 | 웹에서 정적 데이터만 제공 | HTTP 기반으로 동작하는 서버 | 웹 서버 | nginx, apache |
| 1.2 | 웹에서 동적 데이터도 제공 | HTTP 기반으로 동작하는 동적서비스 서버 | WAS | 톰캣, jetty, Undertow |
| 2 | 브라우저와 서버사이 통신할때, 서버 연결(tcp,...)부터 서블릿 객체 (http메세지를 서블릿이 제공하는 객체(req,res)로 개발자가 데이터에서 꺼내쓰고, 담을 수 있게)해줌. | http정보를 작업할 수 있는 request/response객체 | 서블릿 | 브라우저가 form으로 서버 요청시 ->연결부터 메세지형태까지 누가 만들어 주는걸까? • 브라우저가 http 메세지를 형태 생성하는 작업들이 서블릿이 하는거 • 웹 애플리케이션 서버를 처음부터,, 끝까지 직접 구현할 경우 •• HTTP 메세지를 풀어해쳐야한다. (요청메세지는 텍스트라 몇글자씩 띄어쓰기해서 읽으면된다. ="파싱한다" • 서블릿을 지원하는 WAS 사용할 경우 •• 코드로 서블릿을 만들 수 있음. •HTTP스팩을 떠올리면서 메세지에 어떤 구성으로 전달되는 구나를 알면 좋음 •간단하게 응답,요청할때 http에 데이터를 실어서 보내면된다 •WAS에서 response,request데이터를 새로 만듬.(WHY? 요청마다 다 다르기때문에 새로만드는게 맞다 ) |
| 2.1 | 고객이 동시요청할경우 처리와 서버 종료시 연관 작업 종료 | 동시요청, 서블릿 구동주기 ok | 서블릿 컨테이너 | ex. 톰캣 • 서블릿 컨테이너는 서블릿을 지원하는 WAS를 지칭 • 서블릿 컨테이너는 서블릿 객체를 생성,초기화,호출,종료하는 생명주기를 관리 • 서블릿 객체는 싱글톤으로 관리 •CASE1.고객의 요청이 올 때마다 계속 객체를 생성하는 것은 비효율 • CASE2.최초 로딩시점에 서블릿 객체를 미리 만들어두고 재활용 •CASE3. 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근 -> 서블릿을 새로 만들 필요가 잇을까요? 우리는 비즈니스 로직만 작성하기때문에, 요청올때마다 new해서 생성하는것은 비 효율적입니다. 객체가 의미없이 만들어지니까요. 싱글톤으로 1개만 만들고, 같은 서버라면 A,B가 요청하면 같은 서블릿 인스턴스에 접근해서 이 로직을 실행합니다. •CASE4. 공유변수 사용 주의 -> 싱글톤이기 때문에 잘못 샛팅하면 A가 로그인했는데, B의 정보가 나올 수 있다. •CASE5.서블릿 컨테이너 종료시 함께 종료 • JSP도 서블릿으로 변환되어서 사용 •동시 요청을 위한 멀티 쓰레드 처리 지원 |
| 2.2 | 쓰레드 풀로 쓰레드를 유지해 비용을 낮추고, 성능을 올린다. 이 작업은 WAS에 포함되어 개발자는 비즈니스로직에만 집중하도록 가능하게 한다. | 동시요청과 쓰레드 | - 서블릿 객체를 누가 호출하지? -라인 하나하나씩 실행해주는 쓰레드, 쓰레는 한번에 하나의 코드 라인만 수행 -따라서, 동시처리가 필요하면 하나더 추가. - 요청마다 쓰레드 생성하게 되면 문제, 장점 : 쓰레드는 생성 비용이 매우 비싸다. -> 고객이 요청올때마다 쓰레드를 생성하면, 응답속도가 늦어진다. 생성시 cpu를 많이 잡아먹어서, 고객의 요청이 너무 많이오면 이미 차버린 CPU,메모리 임계점을 넘어서 서버가 죽을 수 있다. 쉉장 풀처럼 쓰레드 풀에서 놀고 있다가 가져다 씀. 응답을 다 하고나면, 쓰레드를 죽이는게 아니라, 쓰레드풀에 다시 넣는다.( 쓰레드를 빌려주는 개념 ) 쓰레드가 정의된 개수보다 많으면, 대기/거절 액션을 한다. 대기는 wait, 거절은 아예안되는거. -쓰레드 풀 특징: 필요한 쓰레드를 쓰레드 풀에 보관하고 관리하단다. 최대 쓰레드가 사용중이면, 기다리는 요청을 거절하거나 특정 숫자만큼 대기하도록 설정 할 수 있다. 장점: 쓰레드가 미리 생성되어 있으므로 생성종료하는 비용(CPU가 절약되고, 응답시간이 빠르다. 최대치 안에서 잘 작동된다. -쓰레드 풀 성능팁 : WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread)를 잘 설정하는 것이다. => 적어도 서버 cpu는 50%는 써야 성능이 있다고 말한다. AWS가 인스턴스 늘리는데 최적화되있다고 AWST서버를 늘리면 안됨. 막상 보면 cpu가 10%쓴경우도 있음. -쓰레드 풀의 적정 숫자 : 서비스의 복잡도(DB두번 호출), 메모리, IO에 따라 달름. 병목현상을 찾아서 튜닝하면됨.-멀티 쓰레드에 대한 부분은 WAS가 처리 : 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨. 개발자는 마치 싱글 쓰레드 프로그램밍을 하듯이 편리하게 소스코드를 개발.(비지니스 로직만 짜면됨) 주의 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)은 주의해서 사용. -> 멀티쓰레드로 요청하기때문에 공유변수인 싱글톤스프링빈은 조심해야한다. |
백엔드 개발자 입장에서 UI 기술
- 백엔드
| no | 항목 | 수준 | 내용 |
|---|---|---|---|
| 1 | HTML | 정적으로 어떻게 제공할꺼야? 동적으로 제공되는 페이지 어떻게 제공할꺼야? HTML이 아니라 데이터를 어떻게 제공할꺼야 ? | 1. 정적 리소스 전달. <br/ > 웹브라우저 <> 웹서버 ( 폴더/web/... ) <br/ > 2. 동적으로 필요한 HTML 파일을 생성해서 전달. <br/ > 웹(HTML파일 해석:) 브라우저 <> WAS (DB조회한 후, 동적으로 HTML 생성 JSP, 타임리프 ) <br/ > HTTP API 데이터를 전달 <br/ > HTML이 아니라 데이터를 전달, 주로 JSON형식 사용. 다양한 시스템에서 사용할때, ( 필수조건 : 데이터만 주고 받음. 앱(IOS)/웹(PC) 클라이언트 to 서버 OR HTTP API - 주문'서버' to 결제'서버' => UI 클라이언트 접접, 기업간 데이터 통신. |
| 2 | HTTP | ||
| 3 | API | ||
| 4 | CRS | ||
| 5 | SSR | 서버 사이드 렌더링 ( 최종적으로 HTML은 서버에서 동적으로 모두 결정된다 ), 주로 정적인 화면에 사용. 클라이언트 사이드 렌더링 ( HTML을 받는게 아니라, HTML결과를 자바스크립트를 사용해 웹브라우저에서 동적으로 생성해서 적용한다. 클라이언트쪽에서 HTML을 만든다고 해서 클라이언트 사이드 렌더링이라한다. ), 주로 동적인 화면에서 사용. |
구성 (사양)
- 백엔드
| no | 요구 기능 | 기대 사항 | 구현 방법(1/2) | 구현 방법(2/2) | 분석 ( 불만족 부분, 그에 해결방안 ) |
|---|---|---|---|---|---|
| 1 | 웹 어플리케이션 | 자바 + 통신 ( Http 데이터, 동기방법 ) | (시스템 구성도 사양) 자바 1.8버전, springframework | 서블릿,JSP,MVC 패턴 | 불만족 스런 부분 - 동적은 안됨 |
검토
- 브라우저와 서버통신 작업을 순차적으로 나열하면 이해하기 쉽다
서블릿(브라우저와 서버 통신의 전반적인 작업 수행; 따라서 http통신 메세지를 서버에서 사용가능한 서블릿객체(req,res를제공) ) 과 멀티스레드(서블릿 호출관리 따라서 멀티작업을 수행).
서블릿
- 서블릿은 브라우저와 서버통신 사이의 순차적인 작업들 중 여러 역할을 분담하기 위해 발생했다.
- 서블릿은 객체다. (request, response 데이터를 톰캣에서 생성하는데, 생성시점은 요청할때마다 한다.)
쓰레드
서블릿객체를 호출하는 아이다.
- 동시작업시 멀티쓰레드가 된다.
- 작업이 완료된 후, 쓰레드를 제거하는대신 쓰레드 풀에 살게하여 고비용의 생성작업 대체하여 비용절감하였다.
