공부/f-lab

f-lab 9주차

heeyeon 2024. 5. 19. 15:34

1. 불변성의 장점

  • 생성 시점 이후 해당 객체의 상태를 변경할 수 없으므로, 실행 중인 쓰레드 간 서로의 간섭에 의해 생길 수 있는 동기화(synchronization) 문제에 대한 걱정을 안 해도 되게끔 해준다. (Thread safe 하다.)
  • side-effect에 대한 걱정이 없기 때문에 설계, 구현, 및 사용하는데 편리하다는 장점이 있다.
  • 프로그램 실행 간 exception이 발생하더라도 사용했던 객체들의 상태값은 변함이 없고, 이런 장점 때문에 캐시 해두고 사용한다면 효율을 극대화할 수 있다.

2. 세션 쿠키와 영구 쿠키

 

3. 쿠키는 서버에 요청을 보낼 때 자동으로 요청 헤더에 따라가는데 그 이유는? (쿠키의 사용 이유)

  • HTTP는 본질적으로 상태가 없는(stateless) 프로토콜로 다른 페이지를 요청했을 때 서버는 이전 요청의 상태를 기억하지 못한다. (각 요청은 독립적이기 때문에)
  • 그래서 쿠키를 요청 헤더에 포함시켜서 브라우저와 서버의 연속적인 상호작용에서 상태를 유지하기 위해 쓰인다. 
  • 상태 유지, 세션 관리, 사용자 식별, 환경 설정 저장, 사용자의 행동 추적과 분석을 가능하게 하기 위해 쿠키를 사용한다. 

4. 서버에서 생성되는 세션ID는 어떤 원리로 클라이언트의 쿠키에 저장이 되는지?

  • 클라이언트가 서버에 요청을 보내면, 서버는 해당 요청을 처리한 후 응답을 준비한다. 이 응답에는 세션 ID를 클라이언트에게 전달하기 위한 HTTP 헤더가 포함된다.
  • 서버는 HTTP 응답 헤더에 Set-Cookie 헤더를 추가하여 세션 ID를 쿠키로 설정한다. 이 헤더는 클라이언트에게 쿠키를 설정하라는 지시를 포함한다.
  • Set-Cookie 헤더는 여러 속성을 포함하고 있다:
      • sessionID=abc123xyz: 쿠키의 이름과 값이다. 여기서 세션 ID는 abc123xyz이다.
      • Path=/: 쿠키가 유효한 URL 경로를 지정한다. 루트 경로 /로 설정되어 있어 해당 도메인의 모든 경로에 대해 쿠키가 전송된다.
      • HttpOnly: 이 속성이 설정되면, 쿠키는 클라이언트 측 스크립트(JavaScript 등)에서 접근할 수 없습니다. 이는 XSS 공격으로부터 쿠키를 보호한다.
      • Secure: 이 속성이 설정되면, 쿠키는 HTTPS 연결을 통해서만 전송된다. 이는 쿠키의 전송 중 도청을 방지한다.
      • SameSite=Strict: 이 속성은 쿠키가 동일한 사이트의 요청에서만 전송되도록 한다. 이는 CSRF 공격을 방지하는 데 도움이 된다.
  • 클라이언트의 브라우저는 서버로부터 HTTP 응답을 받으면, Set-Cookie 헤더를 읽고 쿠키를 저장한다. 브라우저는 지정된 속성에 따라 쿠키를 로컬 저장소에 저장한다.
  • 이후 클라이언트가 동일한 서버에 요청을 보낼 때, 브라우저는 저장된 쿠키를 자동으로 요청 헤더에 포함시켜 전송한다. 이를 통해 서버는 클라이언트를 식별하고 세션 정보를 유지할 수 있다.

5. 데이터베이스 호출을 끝내면 ResultSet , Statement , Connection 순서대로 close를 호출해줘야하는데 이렇게 닫아주지 않으면 어떤 일이 발생할까요?

  • 메모리 누수 : 해당 객체들이 사용하던 메모리가 회수되지 않고 계속 점유된 상태로 남아있게 된다. 이로 인해 메모리 누수가 발생할 수 있으며, 결국 애플리케이션이 사용할 수 있는 메모리가 부족해질 수 있다.
  • 데이터베이스 연결 누수 
    • 데이터베이스 커넥션 풀을 사용하는 경우, 사용한 커넥션을 반환하지 않으면 연결이 점점 고갈된다. 연결이 고갈되면 새로운 연결을 생성할 수 없게 되어 애플리케이션이 데이터베이스와 상호작용할 수 없게 된다.
    • 데이터베이스 서버는 동시에 처리할 수 있는 연결 수에 제한이 있다. 닫히지 않은 연결이 많아지면 이 제한을 초과하게 되어 다른 애플리케이션이나 사용자들이 데이터베이스에 접근할 수 없게 된다.
  • 데이터베이스 락 문제 : ResultSet이나 Statement를 닫지 않으면, 데이터베이스의 특정 자원에 대한 락이 해제되지 않을 수 있다. 이는 다른 트랜잭션이 해당 자원에 접근하지 못하게 하고, 교착 상태(deadlock)나 성능 저하를 초래할 수 있다.

6. 커넥션 과정은 비용이 많이 드는데, 왜 그런가요?

  • 네트워크 연결 설정: 클라이언트와 데이터베이스 서버 간의 네트워크 연결을 설정하는 것은 시간이 많이 소요됩니다. 특히, 데이터베이스 서버가 원격에 있는 경우 네트워크 지연(latency)도 고려해야 합니다.
  • 메모리 할당: 새로운 커넥션을 설정하면 서버는 해당 커넥션을 처리하기 위한 메모리를 할당해야 합니다. 이에는 버퍼, 캐시, 기타 연결 관련 데이터 구조가 포함됩니다.
  • 스레드 생성: 많은 데이터베이스 시스템은 각 연결을 처리하기 위해 새로운 스레드를 생성하거나 기존 스레드 풀에서 스레드를 할당합니다. 스레드 생성과 관리에는 오버헤드가 발생합니다.
  • 쿼리를 요청하는 과정은 TCP 기반으로 동작하기 때문에 커넥션을 열고 닫는 과정이 오래 걸린다.

7. 톰캣에는 스레드 풀이 있습니다. 이 스레드 풀은 왜 존재하는걸까요?

  • 서버에 들어오는 요청마다 각각의 스레드를 만들어 처리하고 처리가 끝나면 스레드를 버리는 식으로 동작한다면 스레드를 생성하는 시간 때문에 요청 처리가 오래 걸린다.(커널이 개입해서 커널 레벨에서 스레드가 생성되기 때문에)
  • 스레드가 계속 생성되면 컨텍스트 스위칭이 자주 발생하고 cpu 오버헤드 증가 
  • 스레드 수가 증가하면서 메모리 부족 
  • 스레드 풀을 사용하면 처리가 끝난 뒤 스레드를 버리지 않고 스레드 풀에 보관했다가 다른 요청이 들어오면 재사용
  • 여러 작업을 동시에 처리해야 할 때 사용 

8. 커넥션 풀과 스레드 풀의 개수는 어떤 상황에서 어떻게 맞추면 좋을지?

  • 커넥션 풀의 개수 고려 사항
    • 동시 사용자 수 : 동시에 접속하는 사용자가 많으면 더 많이 생성한다.
    • 쿼리 실행 시간 : 각 쿼리의 실행 시간이 길다면 더 많은 커넥션이 필요할 수 있다.
    • 데이터베이스 성능 : 데이터베이스 서버가 처리할 수 있는 최대 연결 수를 고려해야 한다.
    • 애플리케이션 논리 : 애플리케이션이 얼마나 자주 데이터베이스에 접근하는지와 트랜잭션 길이에 따라 달라질 수 있다.
    • 일반적으로 커넥션 풀의 크기는 10~30
  • 스레드 풀의 개수 고려 사항
    • CPU 코어의 수 : 스레드 수는 CPU 코어 수와 밀접하게 관련된다. 너무 많은 스레드는 오히려 컨텍스트 스위칭 오버헤드를 증가시켜 성능 저하를 초래할 수 있다.
    • 작업 특성 : /O 바운드 작업(네트워크, 파일 입출력 등)이 많은 경우 더 많은 스레드를 사용할 수 있지만, CPU 바운드 작업이 많은 경우 CPU 코어 수에 맞추는 것이 좋다.
    • 응답 시간 요구사항 : 응답 시간이 중요한 애플리케이션이라면 스레드 수를 늘려 병렬 처리를 최대화할 수 있다.
    • 일반적으로 CPU 코어 수 * 2
  • 모든 요청이 db에 접근하는 것 아니기 때문에 스레드 풀의 개수는 커넥션 풀의 개수보다 많아야 한다.

 

9. JWT. 인증, 인가 관련된 내용 자유롭게 학습하기