[Java] API 캐시와 세션 이해하기

Java/이론 및 문법

[Java] API 캐시와 세션 이해하기

adjh54 2023. 10. 22. 18:56

728x170

해당 글에서는 API 캐시와 세션에 대해 이해를 돕기 위해 작성한 글입니다.

1) API 캐시(Cache)

💡 API 캐시(Cache)

- 웹 애플리케이션에서 반복적으로 요청되는 데이터의 응답을 저장하는 임시 저장소를 의미합니다. 이렇게 저장된 데이터는 이후 ‘동일한 요청’이 ‘발생’했을 때 캐시에서 가져와 응답 시간을 단축시키고 서버의 부하를 줄일 수 있습니다.

- API 캐시는 일반적으로 ‘서버의 메모리’에 저장이 되며 캐시의 유지 시간은 다양한 요인에 따라 결정되며 유효기간이 지나면 해당 캐시는 만료되고, 새로운 데이터를 가져와서 캐시를 갱신합니다.

1. API 캐시 사용목적

💡 API 캐시 사용목적

1. 동일한 ‘API 요청을 반복적’으로 수행하는 경우

- 캐시를 사용하면 이전에 받아온 응답을 재사용하여 시간과 자원을 절약할 수 있습니다. API 대역폭을 절약하고 서버의 부하를 줄일 수 있습니다.

2. ‘API 응답이 변하지 않는’ 경우

- 응답이 일정 기간 동안 동일하게 유지되는 경우, 매번 API를 호출하지 않고 캐시 된 응답을 사용함으로써 성능을 향상할 수 있습니다.

3. API 응답이 ‘자주 업데이트되지 않는’ 경우

- 자주 업데이트가 되지 않으면 데이터의 일관성을 유지할 수 있도록 도와줍니다.

2. API 캐시의 라이프사이클

💡 API 캐시의 라이프사이클(생명주기)

- 클라이언트에서 서버로 데이터 요청을 하는 경우에 대해 캐시의 라이프사이클에 대해 알아봅니다.

1. 요청
- 클라이언트가 API에 요청을 보냅니다.

2. 캐시 조회
- 서버는 요청된 데이터가 캐시에 이미 저장되어 있는지 확인합니다.

3.1. 캐시가 존재하는 경우
- 데이터가 캐시에 발견되면, 새로운 서버 요청 없이 클라이언트에게 반환됩니다.

3.2. 캐시가 존재하지 않는 경우
- 캐시된 데이터는 만료 시간이 있으며, 만료되면 새로 고쳐져야 할 상태로 간주됩니다.

4. 캐시 무효화
- 특정 경우에는 캐시 된 데이터가 만료 시간 이전에 업데이트나 변경으로 인해 무효화되어야 합니다.

5. 캐시 갱신
- 캐시된 데이터가 만료되거나 무효화된 경우, API는 서버에서 업데이트된 데이터를 검색하여 캐시를 업데이트합니다.

6. 응답
- API는 요청된 데이터를 클라이언트에게 반환합니다.

3. 클라이언트 캐시 vs API 캐시

💡 클라이언트 캐시

- 클라이언트 측에서 데이터를 저장하고 재사용하는 메커니즘입니다.

- 클라이언트는 이전에 요청한 데이터를 캐시에 저장하여 동일한 요청을 할 때 서버로부터 데이터를 다시 가져오지 않고 캐시에서 데이터를 로드할 수 있습니다.

💡API 캐시

- 서버 측에서 데이터를 저장하고 재사용하는 메커니즘입니다.

- 서버는 클라이언트의 요청에 대한 응답을 캐시에 저장하여 같은 요청이 들어올 때마다 데이터를 다시 계산하거나 데이터베이스에서 가져오지 않고 캐시에서 응답을 반환할 수 있습니다.

💡 클라이언트 캐시 vs API 캐시

- 클라이언트 캐시는 클라이언트 측에서 데이터를 저장하고 재사용하는 반면에, API 캐시는 서버 측에서 데이터를 저장하고 재 사용한다는 차이점이 있습니다.

💡 [참고] 클라이언트 캐시 vs API 캐시 비교표

분류	클라이언트 캐시	API 캐시
위치	브라우저의 로컬 저장소 또는 메모리	서버에 저장
저장소	브라우저의 로컬 저장소 또는 메모리	서버의 메모리 또는 디스크
범위	브라우저 내에서 제한됨	여러 클라이언트 간에 공유 가능
제어	브라우저에 의해 제어됨	서버에 의해 제어됨
네트워크 사용량	네트워크 요청을 줄임	네트워크 요청을 줄임
사용자 정의	브라우저에 의해 사용자 정의 가능	서버에 의해 사용자 정의 가능

4. API 캐시의 장/단점

💡 API 캐시 장점

장점	설명
네트워크 대역폭을 절약할 수 있습니다.	반복적으로 요청되는 데이터는 캐시에서 가져오므로 네트워크를 통해 데이터를 다운로드할 필요가 없습니다.
서버의 응답 시간을 단축시킵니다.	캐시에서 데이터를 가져오는 것이 서버에 요청하는 것보다 훨씬 빠르기 때문입니다.
서버의 부하를 줄일 수 있습니다.	동일한 요청이 반복적으로 발생할 때 서버는 한 번만 응답하고, 이후에는 캐시에서 데이터를 제공합니다.

💡 API 캐시 단점

단점	설명
캐시된 데이터의 업데이트 지연	- 캐시된 데이터는 일정 기간 동안 유효하며, 이 기간 동안 데이터가 업데이트되지 않으면 오래된 정보를 제공할 수 있습니다. - 사용자가 최신 정보를 필요로 할 때 문제가 발생할 수 있습니다.
캐시 일관성 문제	- 여러 사용자가 동일한 데이터를 요청할 때, 캐시된 데이터의 일관성을 유지하기 어렵습니다. - 데이터의 변경이 발생하면 모든 캐시를 갱신해야 하며, 이는 복잡성과 오버헤드를 초래할 수 있습니다.
캐시 크기 관리	- 저장소의 한정된 공간을 사용합니다. - 큰 크기의 캐시를 유지하면 비용이 증가하고, 작은 크기의 캐시를 유지하면 캐시 미스가 발생할 수 있습니다. 따라서 적절한 캐시 크기를 관리해야 합니다.
캐시 무효화 전략의 복잡성	- 캐시된 데이터를 갱신하거나 무효화하는 전략을 정의하는 것은 복잡할 수 있습니다. - 올바른 캐시 무효화 전략을 구현하지 않으면 오래된 데이터를 제공하거나 무효화되지 않은 데이터를 반환할 수 있습니다.

5. Spring Boot 환경에서 캐시 사용하기

💡 해당 내용에 대해서는 이전에 작성한 글을 참고하시면 Spring Boot 환경에서 캐시를 사용하는 방법을 확인하실 수 있습니다.

[Java] Spring Boot Cache 이해하고 설정하기 -1 : 정의, 환경 설정

해당 글에서는 API Cache에 대해서 이해하고 REST API 환경에서 이를 적용하는 방법에 대해서 작성한 글입니다. 1) 개발환경 구성 💡 개발환경은 MyBatis를 기반으로 RDBMS로부터 전달받은 데이터를 캐

adjh54.tistory.com

[JAVA] Spring Boot Cache 이해하고 설정하기 -2 : 사용 및 활용 예시

해당 글에서는 Spring Boot Cache를 이를 이용하는 방법에 대해서 이해를 돕기 위한 글입니다. [참고] Spring Boot Cache의 이론과 환경설정 방법에 대해 궁금하시다면 이전에 작성한 글을 참고하시면 도

adjh54.tistory.com

2) API 세션(Session)

💡 API 세션(Session)

- 클라이언트와 서버 간의 상태 및 인증 정보를 유지하기 위해 사용됩니다. 이를 통해 클라이언트 응용 프로그램은 서버와 상호 작용하고 데이터를 교환하거나 특정 작업을 수행할 수 있습니다.

1. API 세션 사용 목적

💡 API 세션 사용 목적

1. 사용자 인증 및 인가
- 사용자가 API를 사용하려면 인증 및 인가 과정을 거쳐야 합니다. API 세션은 사용자가 인증된 세션을 유지하며 API에 접근할 수 있도록 도와줍니다.

2. 데이터 저장 및 검색
- API 세션을 사용하여 데이터를 저장하고 검색할 수 있습니다. 세션을 통해 데이터베이스와의 연결을 유지하고 데이터를 조작할 수 있습니다.

3. 상태 및 세션 관리
- API 세션을 사용하여 사용자의 상태를 추적하고 세션 관리를 할 수 있습니다. 예를 들어, 사용자가 로그인한 상태인지 여부를 확인하거나, 사용자의 활동을 추적할 수 있습니다.

2. API 세션의 라이프사이클

💡 API 세션의 라이프사이클

- 일반적으로 API 서버가 재기동 되면 연결된 세션은 모두 제거됩니다. API 서버가 구동 중일 경우의 라이프사이클에 대해 알아봅니다.

1. 인증
- 사용자는 API에 대한 인증을 통해 세션을 시작합니다.

2. 활성화
- 인증이 완료되면 API 세션이 활성화됩니다. 이때부터 사용자는 API를 호출하고 데이터를 교환할 수 있습니다.

3. 유효 기간
- API 세션은 일정 시간 동안 유효합니다. 유효 기간은 서비스 또는 플랫폼에 따라 다르며, 일반적으로 몇 시간 또는 몇 일로 설정됩니다

4. 만료
- API 세션의 유효 기간이 지나면 세션이 만료됩니다. 만료된 세션에서는 API 호출이 거부되며, 사용자는 다시 인증 과정을 거쳐 새로운 세션을 시작해야 합니다.

5. 재인증
- 만료된 세션에서는 사용자가 다시 인증을 수행하여 새로운 세션을 활성화할 수 있습니다.

3. API 세션 vs JWT 사용자 정보 체크

💡 API 세션 vs JWT 사용자 정보 체크

- 해당 부분에서는 API Session을 이용하거나 JWT를 이용한 사용자의 ‘인증’에 대해 확인하는 방법에 대해 확인하여 각각의 장단점을 확인해 봅니다.

💡 API 세션

- 해당 이미지에는 사용자가 API로 인증을 요청하였을 때, 사용자 정보를 확인하고 ‘인증’에 대한 반환으로 세션을 유지하며, API 재 요청이 들어오는 경우 세션에서 사용자 인증을 체크하여 로그인된 인증 상태로 수행이 됩니다.

https://www.baeldung.com/cs/tokens-vs-sessions

💡 JWT(JSON Web Token)

- 애플리케이션에서 ‘사용자 인증’을 위해 ‘인증’에 필요한 정보를 토큰에 담아서 암호화시켜 사용하는 인터넷 표준 인증방식을 의미합니다.

- 해당 이미지에서는 사용자가 API로 인증을 요청하였을 때, 최초 사용자 정보를 확인하고 토큰을 발급합니다. 발급된 토큰을 기반으로 API 호출 시 사용자의 인증을 체크하며 로그인된 인증상태로 수행이 됩니다

💡 API 세션 vs JWT

- 클라이언트의 인증과 상태에 대해서 사용을 한다면 세션보다는 JWT를 사용하는 것을 권장합니다. 이는 세션과 달리 서버에서 세션 상태를 관리하지 않아도 되므로 확장성과 유연성이 높습니다. 또한, 토큰에는 클라이언트와 관련된 정보를 포함시킬 수 있어 더 많은 자유도를 제공합니다.

💡 [참고] JWT에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.

[Java] Spring Boot Security 이해하기 -3: JWT(JSON Web Token) 이해하기

해당 글에서는 Spring Security의 인증을 위한 ‘JWT: JSON Web Token’를 이해하고 적용하기 위해 우선 이해를 목적으로 작성한 글입니다. 추후 적용을 위한 환경 설정 방법에 대해서 공유합니다. 💡 [참

adjh54.tistory.com

4. API 세션의 장단점

💡 API 세션의 장점

장점	설명
애플리케이션 간의 통합을 용이하게 만들어줍니다.	- 애플리케이션들 간의 데이터 및 기능을 쉽게 공유할 수 있도록 도와줍니다. - 이를 통해 다른 애플리케이션과의 연동이 간편해지며, 복잡한 시스템 간의 통합을 용이하게 합니다.
개발 시간을 단축시킬 수 있습니다	- 이미 구현되어 있는 기능을 활용할 수 있기 때문에 개발자는 필요한 기능을 직접 개발할 필요가 없습니다. - 이는 개발 시간을 단축시키고 개발 프로세스를 가속화하는 데 도움을 줍니다.
개발자들이 다양한 기능을 활용할 수 있도록 합니다.	- 다른 애플리케이션에서 제공하는 다양한 기능을 활용할 수 있는 기회를 제공합니다. - 이를 통해 개발자는 필요한 기능을 직접 구현하지 않아도 되며, 다른 애플리케이션의 기능을 효과적으로 사용할 수 있습니다.

💡 API 세션의 단점

단점	설명
보안 취약점이 존재할 수 있습니다.	- 외부 애플리케이션과의 통신을 위해 데이터를 주고받습니다. - 이로 인해 보안 취약점이 발생할 수 있으며, 악의적인 공격자가 API를 통해 시스템에 침입할 수 있는 가능성이 있습니다.
변경이나 업데이트에 따른 호환성 문제가 발생할 수 있습니다.	- 애플리케이션은 API의 변경이나 업데이트에 민감할 수 있습니다. - API의 인터페이스가 변경되거나 기능이 변경되면, 해당 애플리케이션은 호환성 문제를 겪을 수 있습니다.
API 제공자의 변경이나 중단으로 인해 애플리케이션에 문제가 생길 수 있습니다.	- 애플리케이션은 API 제공자의 변경이나 중단에 대해 취약할 수 있습니다. - 만약 API 제공자가 서비스를 중단하거나 제공하는 기능을 변경한다면, 해당 애플리케이션은 문제를 겪을 수 있습니다.

오늘도 감사합니다. 😀

그리드형