[우아한테크코스] 11월 1일 TIL
[infra] Caching
캐싱 메모리는 메모리 계층 중에 register memory 다음으로 빠른 메모리이다. 하지만 비싸다.
그래서 일반적으로 자주 사용되는 요청에 대해서만 캐시 메모리에 두고 사용하는 것이다.
시간, 공간, 순차에 따라서 캐싱할 수 있다.
캐싱의 작동 방식
- 캐시 공간을 마련한다. 낮은 시간복잡도로 접근 가능한 곳을 사용
- 데이터에 대한 요청이 들어오면 캐시 공간을 먼저 찾는다.
- 캐시에 데이터가 없으면 원본 데이터로 가서 데이터를 가져온다. 이 과정은 당연히 캐시에서 가져오는 것보다 오래걸리고 비용도 많이 든다.
- 캐시에 데이터가 있으면 가져온다.
- 안쓰이는 데이터는 삭제한다. 공간 확보를 위해서
우리는 이러한 캐싱을 cdn, redis를 이용해 적용했다.
CDN: 비싼 국제 회선을 줄이기 위해 각 세계에 캐시 서버를 두어 전송의 속도를 높여 부하를 분산하는 행위
redis: NoSQL DBMS로 요청에 대한 응답을 캐시해 database에 대한 접근 없이 응답을 바로 가져갈 수 있도록 함
웹캐시: 브라우저 캐시(html, css, js, image 등이 http 헤더에 캐시 지시자를 삽입해 캐시), 응답 캐시(server에서 생성한 html), 프록시 캐시(클라이언트에서 자주 오는 요청은 프록시에서 캐싱해 바로 제공)
실제로 웹프로그래밍이 동작하는데 캐싱은 많은 곳에 적용될 수 있다. java에서는 EHCache 사용
CDN의 캐싱 방법
사용자의 로컬에 가깝게 전략적으로 배치된 서버에 선별적으로 저장된다.
데이터 이동 거리를 줄여 네트워크 대기 시간을 감소할 수 있다.
-
ram & in-memory engine 사용
대규모로 데이터 검색 성능 향상되고 비용 절감
-
글로벌 엣지 로케이션 네트워크를 사용해 캐싱된 복사본을 고객에게 제공
고객과 가까운 엣지 로케이션을 사용해 응답 시간 단축
아시아에도 서울에 엣지 로케이션이 존재한다.
- 서버로 html, css, image 등의 요소를 불러올 것을 웹 브라우저가 요청
- dns는 end user와 가장 가까운 위치에 최적으로 배치된 CDN 서버에 End User를 매핑하고 CDN 서버는 캐싱된 응답 반환
- 서버가 파일을 못찾으면 다른 CDN 서버에서 컨텐츠를 찾아 응답 전송, CDN은 요청 프록시로 작동해 다음 요청 시 응답할 수 있도록 컨텐츠 저장
[infra] 암호화 방식, 암호화 알고리즘
-
공유링크 aes256
대칭키를 가지고 암복호화가 가능하도록 한다.
-
토큰 hs256(hmac sha256)
비대칭키를 가지고 암호화할때 공개키, 복호화할 때 개인키를 이용하도록 해서 로그인하면 공개키로 데이터를 암호화해 전달한다. 이렇게 암호화된 토큰을 우리는 개인키를 이용해 풀어서 올바른 사용자인지 검증한다.
제공자와 사용자가 모두 하나의 키인 Secret key를 가지고 서명 검증
-
비밀번호 BCryptPasswordEncoder
sha-1랜덤 salt 제공을 통해 보안이 좋아진다.
spring security는 동일한 salt로 다시 해시함수를 거쳐 같은 다이제스트를 가지는지 보고 반환한다.
해싱은 단방향 암호화로 복호화가 불가능하다.
공유링크는 단방향으로 해시함수를 거치는데 이러면 같은 데이터는 같은 값을 갖는다. 따라서 공유링크의 경우 맵의 id에 따라 같은 맵은 같은 공유링크를 갖도록 해도 문제가 없어서 진행했다.
매번 다이제스트가 같은 단방향 암호화의 문제점을 해결하고자 해시 함수를 여러번 수행하는 key stretching이 있다. 다이제스트를 알고리즘에 여러번 돌려 알아내기 어렵게 만드는 것이다.
거기서 원문에 임의의 문자열인 솔트를 덧붙이게 되면 다이제스트를 복호화하더라도 비밀번호를 알기 어려워진다.
반면에 암호화(encryption)은 양방향으로 암호화 복호화가 가능하다.