f-lab 10주차

1. 컨텍스트 스위칭이란?

https://s7won.tistory.com/11 참고

https://www.youtube.com/watch?v=Xh9Nt7y07FE&list=PLcXyemr8ZeoQOtSUjwaer0VMJSMfa-9G-&index=2 참고

 

2. CPU 스케쥴링이란? / 관련 기법

https://www.youtube.com/watch?v=LgEY4ghpTJI&list=PLcXyemr8ZeoQOtSUjwaer0VMJSMfa-9G-&index=9 참고

• 프로세스 상태가 러닝에서 다른 상태로 바뛰면 cpu가 비어있지 않게 다음으로 실행할 프로세스를 레디큐에서 선택하는 역할
• 디스패쳐는 이 선택된 프로세스가 cpu에서 실행될 수 있도록 하는 역할
• 비선점 스케쥴링
  
  • 프로세스가 종료되거나 i/o작업으로 넘어가거나 자발적으로 다른 프로세스에게 양보하는 경우
  • 운영체제가 개입하지 않고 프로세스가 자발적으로 하는 것
  • 신사적, 협력적, 느린 응답성
• 선점 스케쥴링
  • 비선점 상황 + 프로세스 실행이 다 안 끝나도 개입하는 상황
  • 적극적, 강제적, 빠른 응답성, 데이터 일관성 문제 발생 가능
• 스케쥴링 알고리즘
  • first come first served : 먼저 도착한 순서대로 처리
  • shortest job first : 프로세스의 다음 씨피유 처리 시간이 가장 짧은 프로세스부터 실행
  • shortest remaining time first : 남은 씨핑 처리시간이 가장 짧은 프로세스부터 실행
  • priority : 우선순위가 높은 프로세스부터 실행
  • round robin : 타임 슬라이스로 나눠진 씨피유 타임을 번갈아가면서 실행
  • multilevel queue : 프로세스들을 그룹화해서 그룹마다 큐를 두는 방식

3. 커넥션 풀 크기가 클 때의 단점

https://www.youtube.com/watch?v=zowzVqx3MQ4&t=180s 참고

• 메모리 사용 증가 : 많은 커넥션을 필요로 하지 않는 경우 메모리 사용량이 크게 증가
• 커넥션 유지 비용 증가 : 각  데이터베이스 커넥션은 일정량의 시스템 리소스를 사용하는데 너무 많은 커넥션을 유지하면 CPU와 메모리 사용량이 증가하며, 이는 다른 애플리케이션이나 시스템의 성능 저하를 유발
• 데이터베이스 과부하 : 너무 많은 커넥션이 동시에 열리면 데이터베이스 서버에 과부하를 줄 수 있다. 이는 데이터베이스 성능 저하와 연결 실패로 이어질 수 있다.

4. 커넥션 풀의 크기를 정의하는 본인만의 공식 정해오기

☝ 공식 가이드
pool size = Tn x (Cm - 1) + 1 

Tn :  쓰레드의 최대 개수
Cm :  동시에 사용하는 커넥션의 최대 개수

 

모니터링 환경 구축(서버 리소스, 서버 스레드 수, DBCP 등)
백엔드 시스템 부하 테스트 : 트래픽을 점점 늘려가면서 테스트 (nGrinder)
request per second (단위 초당 몇개의 요청까지 처리할 수 있는지), avg response time (요청에 대한 평균적인 응답 시간)
두가지를 확인
백엔드 서버, DB 서버의 cpu, 메모리 등 리소스 사용률 확인

max-connections를 먼저 확인하고 사용할 백엔드 서버 수를 고려하여 
maximunpoolsize 결정

 

5. JWT의 장단점

• 장점
  • • 토큰 검증만을 통해 사용자 정보를 확인가능 하여 추가 검증 로직이 필요 없다.
    • 매번 세션이나 데이터베이스 같은 인증 저장소가 필요 없다.
    • 사용자가 늘어나더라도 사용자 인증을 위한 추가 리소스 비용이 없다.
    • 다른 서비스에 공통 스펙으로 사용이 가능하여 확장성이 높다.
• 단점
  • • base64 인코딩 정보를 전달하기에 전달량이 많다.
    • 토큰이 탈취당할 시 만료될 때까지 대처가 불가능하다.
    • Payload부분은 누구든 디코딩하여 확인할 수 있다.

6. 리프레시 토큰이 등장한 이유

토큰은 탈취될 수도 있다는 단점이 있는데 만료시간을 짧게 설정해두면 탈취가 되더라도 그 토큰을 사용하는 데 제한이 있다. 액세스 토큰의 만료 시간을 짧게 설정해두고 서버에서 관리하는 리프레쉬 토큰의 만료 시간을 길게 설정해두고 사용하면 이러한 단점을 해결할 수 있다.

 

7. 왜 세션/쿠키 인증 방식 대신에 JWT토큰을 썼나요?

• 서버에 상태를 저장할 필요가 없기 때문에 별도의 서버를 더 추가하지 않아도 돼서 확장하기에 좋다.
• 사용자의 인증 정보가 토큰 자체에 있기 때문에 다른 데이터를 서버에 요청할 필요가 없기 때문에 성능이 향상된다.
• 자체적인 만료 시간을 가지고 있어 만료에 대한 관리가 편리하다.

8. DispatcherServlet이란?

• 서블릿 컨테이너의 가장 앞단에서 HTTP 프로토콜로 들어오는 모든 요청을 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러
• 프론트 컨트롤러 : 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러, 공통의 로직에 대한 처리 가능
• DispatcherServlet의 흐름
  1. 클라이언트에서 요청이 오면 DispatcherServlet이 요청을 받는다.
  2. HandlerMapping을 통해 요청에 맞는 컨트롤러를 찾아낸다.
  3. 찾아낸 컨트롤러를 Handler Adapter를 통해 해당 컨트롤러의 메서드를 실행시킨다.
  4. 컨트롤러는 요청을 처리한 뒤 해당 요청에 대한 결과와 뷰에 대한 정보를 다시 DispatcherServlet에 전달한다.
  5. 받은 정보로 DispatcherServlet 은 View Resolver를 뷰 파일을 찾는다.

 

9. JSP/서블릿 서버 기준으로 요청이 들어오고 응답이 나가는 과정 설명

1. 클라이언트 요청: url 요청
2. 웹 서버: 요청 수신 후 서블릿 컨테이너로 전달
3. 서블릿 컨테이너: /myapp/hello.jsp 요청을 수신
4. JSP 컴파일 과정: hello.jsp가 서블릿으로 변환되고 컴파일됨
5. 요청 매핑: /myapp/hello.jsp 요청을 컴파일된 서블릿에 매핑
6. 서블릿 초기화: 서블릿이 초기화되지 않은 경우 init() 호출
7. 요청 처리: 서블릿의 doGet() 또는 doPost() 메서드 호출
8. 비즈니스 로직: 데이터베이스 조회, 연산 등 수행
9. 응답 생성: 서블릿이 HTML, JSON 등을 생성
10. 응답 반환: 클라이언트에 응답 전송( HttpServletResponse 객체 이용)
11. 클라이언트 수신: 브라우저가 응답을 렌더링하여 사용자에게 표시