[iOS] 메이트러너: 이미지 캐싱 적용기(메모리 캐싱, 디스크 캐싱 그리고 ETag)

메이트 러너 앱 개발 과정을 공유하는 포스트입니다!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️

여기서 저희 프로젝트를 더 자세히 볼 수 있어요!

 

그럼 시작하겠습니다!

 

달리기 앱인데 캐싱이 왜 필요해..?

네 저희도 그럴 줄 알았습니다.. 

Firebase Firestore에서 프리티어로 제공하는 용량은 하루 다운로드 최대 1기가바이트인데 어차피 저희는 프로필 이미지 말고는 사진을 저장하지 않으니 큰 문제가 없을 것이라고 생각했죠..

 

그런데 우려가 현실이 됩니다.. 개발을 하면서 테스트하는 중에 갑자기 이미지가 다운로드되지 않으면서 402가 응답 코드로 돌아왔고, 확인해보니 사용량 초과로 요청이 거부된 것이었습니다.

 

원인을 분석해보니,

저희는 이렇게 생각보다 많은 화면에서 이미지를 다운로드하고 있었습니다. 더군다나 친구나 자신의 프로필 이미지만을 다운로드하기 때문에 매번 똑같은 이미지가 반복됩니다. 만약 이미지 캐싱을 사용한다면 계속 똑같은 이미지를 다운로드하지 않아도 되겠죠!

 

결국 저희는 이미지 캐싱을 적용하기로 결정했습니다..!

 

캐싱 설계

캐싱을 어디까지 지원해야할지 특히, 메모리 캐싱까지만 하면 좋을지, 디스크 캐싱까지 해야할지 생각을 해보았습니다. 우리 앱은 사용자가 앱을 켠 상태에서 많은 일을 하지 않고 러닝이 필요할 때 앱을 켜게 됩니다. 또, 프로필 이미지는 생각보다 자주 바뀌지 않죠. 그래서 단순히 메모리 캐싱만 적용하면 앱을 한 번 켰을 때만 캐싱된 이미지를 사용하기 때문에 캐싱 효과가 그다지 크지 않을 것입니다. 

 

효율적으로 제한된 서버 스토리지를 사용하고 자주 바뀌지 않는 프로필 이미지를 재사용하기 위해서 디스크 캐싱까지 모두 제공하기로 결정했습니다.

 

그리고 이미지 캐싱으로 유명한 KingFisher처럼 외부에서는 UIImageView는 캐싱에 대한 정보는 모른 채 이미지의 URL만 요청하면 이미지를 반환시켜주도록 하고 싶었습니다.

그래서 이렇게 UIImageView의 extension을 만들어두고 캐시 서비스를 통해 이미지를 전달받도록 구성했습니다.



전체적인 과정은 위와 같은데요, 이미지 요청이 시작되면 메모리 캐시를 확인하고, 없으면 디스크 캐시를, 그리고 디스크 캐시에도 없으면 네트워크에 데이터를 요청해서 이미지를 받아오는 과정으로 설계를 마무리했습니다.

 

메모리 캐싱

메모리 캐싱은 애플에서 제공하는 NSCache를 사용하기로 했습니다.

NSCache는 Key-Value 형태로 데이터를 캐싱할 수 있게 해 주는데요, 다운로드할 이미지의 URL을 키 값으로 삼아 이미지를 Data 타입으로 저장합니다. 

이렇게 구현하면 URL에 대한 데이터가 있으면 해당 데이터가 반환이 되고, 없으면 nil 이 반환이 되겠죠?

 

디스크 캐싱

메모리 캐시를 체크했을 때 nil이 반환되어 Miss가 되면 디스크 캐시를 확인합니다.

디스크 캐시는 디스크가 Miss 되면 nil을 반환하고, Hit 되면 코드에는 나와있지 않지만, 캐시 지역성의 원리를 살리기 위해 Hit 된 데이터를 메모리 캐시에 올리는 과정까지 포함됩니다.

 

디스크 캐시를 사용하기 위해서는 File Manager를 통해 파일 읽고 쓰기를 하고, 파일을 앱 샌드박스의 Libarary/Caches 위치에 요청했던 이미지 주소를 파일 이름으로 변경해 저장합니다.

뭔가 이상한데...?

구현을 마치고 캐싱이 잘 되는지 확인했고, 코드를 머지했습니다. 그런데 이상하게 사용자가 프로필 사진을 변경해도 다른 사용자들에게는 변경된 프로필 사진이 보이지 않는 현상이 일어났습니다. 캐싱에만 집중하느라 완전 중요한 한 가지를 놓쳐버린 것이죠..

 

친구의 프로필 사진을 한 번이라도 읽으면 디스크에 캐싱이 되고 그 이후부터는 항상 디스크 캐시에서 Hit 가 발생하기 때문에 서버로 이미지를 요청하지 않게 되는 문제였습니다. 즉, 로컬 데이터와 서버 데이터가 일치하는지 확인하는 과정이 생략되었던 것입니다.

 

로컬-서버 데이터 동기화 feat. ETag

결국 서버에 현재 우리가 가진 이미지가 최신 본인지 확인하는 과정이 필요했는데요, 이를 위해 ETag 개념을 학습하고 적용했습니다. 파이어베이스 스토리지에 이미지를 받는 데 성공하면, 서버는 아래와 같은 응답 헤더를 반환해줍니다.

이 ETag는 서버의 데이터가 변경될 때마다 함께 바뀌는데요, 마지막으로 이미지를 가져왔을 때의 ETag를 보관하고 있다가 서버가 가진 ETag와 비교하는 방식으로 로컬 이미지와 서버 이미지가 동일한지 확인할 수 있었습니다.

 

ETag를 적용하기 위해서 가장 먼저 캐싱의 대상을 이미지의 Data 타입에서 ETag까지 포함하는 새로운 타입으로 변경했습니다.

이렇게 클래스 하나를 만들고, 이미지와 ETag를 함께 저장할 수 있도록 했습니다.

 

그럼 캐시가 다루어야 할 데이터도 바뀌겠죠?

이렇게 위에서 새로 정의한 타입을 값으로 가지는 캐시로 변경되었습니다. NSCache의 값으로 Struct를 사용하는 것이 불가능해서 모델이지만 class로 타입을 만들어주었습니다.

 

디스크 캐싱도 변경이 되어야 하는데요, 문제는 Data와 String 타입의 프로퍼티를 가지고 있는 클래스를 한 번에 파일에 저장할 수 있는 방법이 없었습니다.

 

그래서 ETag는 이미지 URL을 키 값으로 삼아 UserDefaults에, 이미지 데이터는 기존처럼 파일에 저장하는 방식으로 구현을 했습니다.

그리고 디스크가 Hit 되었는지는 동일하게 디스크에 URL이름으로 저장된 이미지가 있는지 확인하는 방법으로 구현했습니다.

 

조건부 GET으로 ETag 확인하기

캐시 구조는 변경되었고 이제 ETag를 이용해 서버로부터 데이터의 최신 여부를 검증받으면 되는데요, 이를 위해서 조건부 GET을 이용해 ETag가 일치하지 않으면 새로운 데이터를 응답으로 받고, ETag가 일치하면 일치한다는 응답받도록 했습니다.

 

조건부 GET을 사용하기 위해서는 헤더에 If-None-Match의 값으로 현재 이미지의 ETag를 보내면 됩니다.

이렇게요!

 

만약 ETag가 일치하면 서버는 304: Not Modified와 함께 비어있는 응답을 주고, ETag가 일치하지 않으면 200: OK 응답과 함께 새로운 이미지를 반환합니다. 그리고 그 헤더에는 새로운 ETag도 담겨있겠죠.

 

그럼 이제 전체적인 캐싱 흐름을 이해하기 위해 가능한 캐싱 과정들을 시나리오로 나눠서 봅시다!

 

시나리오 1: 메모리 캐시 히트 - ETag 일치

먼저 이미지 요청이 들어오면 캐시 서비스 객체는 메모리 캐시를 확인해봅니다. 메모리 캐시가 히트되는 상황이니 해당 URL에 대한 CacheableImage 인스턴스가 있겠죠? 그리고 이 안에는 ETag와 이미지 데이터가 들어가 있습니다.

 

하지만 이 캐싱된 이미지가 최신 본인지 확인하기 위해서 ETag를 헤더에 담아 서버에 GET 요청을 보냅니다.

 

ETag 역시도 일치하는 상황이기 때문에 서버는 304를 응답으로 주고 서비스 객체는 이를 확인한 뒤 NSCache에 있던 이미지 데이터를 그대로 반환합니다.

시나리오 2: 메모리 캐시 히트 - ETag 불일치

이번에는 서버에서 200OK와 함께 새로운 이미지를 주는 경우인데요, 이때는 서버에서 받은 최신 이미지와 ETag로 캐시를 초기화해주어야 합니다. 그래서 먼저 메모리 캐시에 새로운 CacheableImage 인스턴스를 만들어서 캐시를 업데이트해주고, 새로운 ETag를 UserDefaults에, 이미지는 캐시 디렉토리에 써주게 됩니다. 

 

그리고 최종적으로는 서버로부터 받은 최신 데이터가 반환됩니다.

 

코드는 이렇게 구현되어 있습니다. 위에서 설명했던 방법대로, 캐시에 매칭 되는 데이터가 있으면 조건부 get을 시도하고, 메모리 캐시, 디스크 캐시가 모두 실패하면 네트워크로 요청을 보내게 됩니다. 

 

캐시 적용 후..

캐시를 적용한 이후에도 테스트를 위해 계속해서 앱을 사용하게 되었는데요, 캐싱 이후부터는 아래처럼 데이터 전송량이 크게 줄어든 것을 확인할 수 있었습니다..!

마무리

캐싱을 구현하면서 ETag라는 새로운 개념도 학습하게 되고, 조건부 Get의 요청이나 응답도 공부할 수 있어서 구현 과정이 즐거웠습니다! 앞으로도 유용하게 사용할 수 있을 것 같아요!

 

혹시나 잘못된 내용이 있다면 댓글로 알려주시면 더 좋을 것 같습니다!

 

저희 프로젝트에 대해 더 궁금하시다면 깃허브 저장소에도 놀러 오세요!

https://github.com/boostcampwm-2021/iOS06-MateRunner

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️

 

추가

이미지 캐시 구현에 부족한 부분들이 있어서 이를 개선한 과정을 별개의 포스트로 담았어요! 확인해보시면 재미있을거에요!

[iOS] 메이트러너: 반쪽짜리 이미지 캐시 개선하기