반응형
해당 글에서는 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 : 정의, 환경 설정
[JAVA] Spring Boot Cache 이해하고 설정하기 -2 : 사용 및 활용 예시
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 재 요청이 들어오는 경우 세션에서 사용자 인증을 체크하여 로그인된 인증 상태로 수행이 됩니다.
💡 JWT(JSON Web Token)
- 애플리케이션에서 ‘사용자 인증’을 위해 ‘인증’에 필요한 정보를 토큰에 담아서 암호화시켜 사용하는 인터넷 표준 인증방식을 의미합니다.
- 해당 이미지에서는 사용자가 API로 인증을 요청하였을 때, 최초 사용자 정보를 확인하고 토큰을 발급합니다. 발급된 토큰을 기반으로 API 호출 시 사용자의 인증을 체크하며 로그인된 인증상태로 수행이 됩니다
💡 API 세션 vs JWT
- 클라이언트의 인증과 상태에 대해서 사용을 한다면 세션보다는 JWT를 사용하는 것을 권장합니다. 이는 세션과 달리 서버에서 세션 상태를 관리하지 않아도 되므로 확장성과 유연성이 높습니다. 또한, 토큰에는 클라이언트와 관련된 정보를 포함시킬 수 있어 더 많은 자유도를 제공합니다.
💡 [참고] JWT에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
4. API 세션의 장단점
💡 API 세션의 장점
장점 | 설명 |
애플리케이션 간의 통합을 용이하게 만들어줍니다. | - 애플리케이션들 간의 데이터 및 기능을 쉽게 공유할 수 있도록 도와줍니다. - 이를 통해 다른 애플리케이션과의 연동이 간편해지며, 복잡한 시스템 간의 통합을 용이하게 합니다. |
개발 시간을 단축시킬 수 있습니다 | - 이미 구현되어 있는 기능을 활용할 수 있기 때문에 개발자는 필요한 기능을 직접 개발할 필요가 없습니다. - 이는 개발 시간을 단축시키고 개발 프로세스를 가속화하는 데 도움을 줍니다. |
개발자들이 다양한 기능을 활용할 수 있도록 합니다. | - 다른 애플리케이션에서 제공하는 다양한 기능을 활용할 수 있는 기회를 제공합니다. - 이를 통해 개발자는 필요한 기능을 직접 구현하지 않아도 되며, 다른 애플리케이션의 기능을 효과적으로 사용할 수 있습니다. |
💡 API 세션의 단점
단점 | 설명 |
보안 취약점이 존재할 수 있습니다. | - 외부 애플리케이션과의 통신을 위해 데이터를 주고받습니다. - 이로 인해 보안 취약점이 발생할 수 있으며, 악의적인 공격자가 API를 통해 시스템에 침입할 수 있는 가능성이 있습니다. |
변경이나 업데이트에 따른 호환성 문제가 발생할 수 있습니다. | - 애플리케이션은 API의 변경이나 업데이트에 민감할 수 있습니다. - API의 인터페이스가 변경되거나 기능이 변경되면, 해당 애플리케이션은 호환성 문제를 겪을 수 있습니다. |
API 제공자의 변경이나 중단으로 인해 애플리케이션에 문제가 생길 수 있습니다. | - 애플리케이션은 API 제공자의 변경이나 중단에 대해 취약할 수 있습니다. - 만약 API 제공자가 서비스를 중단하거나 제공하는 기능을 변경한다면, 해당 애플리케이션은 문제를 겪을 수 있습니다. |
오늘도 감사합니다. 😀
반응형