Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
Tags
- 슬로우 쿼리
- 자연변수
- aws
- queryDsl #JPA #hibernate
- ContentCachingRequestWrapper
- jpa
- Duration-Based Cookie
- Routing Policies
- ChatGPT
- ReactAdmin
- hikari cp
- SSR #CSR
- superset-oracle
- 아파치 드루이드
- 람다 캡쳐링
- querydsl-sql
- reflection API
- afterCompletion
- 스프링
- CannotGetJdbcConnectionException
- RequestBody로깅
- Route53
- oracle
- Connection Draining
- 코딩삽질일기
- Application-Based Cookie
- Cross-Zone Load Balancing
- 네트워크 io
- 자바로그
- UNION 열
Archives
- Today
- Total
목록Routing Policies (1)
Forest Gump?
Route53 특성과 정책 정리
Route53 TTL 이란? TTL(Time to Live ) 설정은 Route53 레코드 생성시에 설정할 수 있습니다. 캐싱 된 시간을 초 단위로 설정이 가능한데, 100초로 설정 시 Client가 Route53 을 통해 쿼리를 보낼 시에 IP주소와 함께 설정 된 캐싱 시간인 TTL로 같이 주게 됩니다. 이런 구조로 되어 있으면, Client는 TTL정보를 캐싱 하여 다음번에 질의 할떄 Route53이 아닌, 기존에 캐싱 되어 있던 정보에 기록된 ip주소를 입력합니다. 이로인해 트래픽의 양을 조절 할 수 있습니다. 이는 요금 청구와도 연관이 있는데, AWS Route53 는 트래픽을 기준으로 요금이 청구 되기 때문에 적당한 TTL 설정이 필요합니다. 하지만 너무 긴 시간을 주게 되면, IP변경시에 잘못..
네트워크
2023. 8. 10. 13:07