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

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

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

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

 

그럼 시작하겠습니다!

 

충격과 공포.. 내가 만든 이미지 캐싱은 반쪽짜리였다!

뿌듯하게 프로젝트는 마치고 한달이 넘어서야 구현했던 이미지 캐싱의 문제점을 발견하게 되었습니다.. 오늘은 어떤 문제점들이 있는지, 그리고 어떻게 개선했는지 그 과정을 정리해보도록 하겠습니다..

 

기존 이미지 캐싱 설계와 구현은,

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

여기에 있어요! 앞 글을 읽지 않아도 이해는 되시겠지만 더 수월하게 읽힐거예요!

 

문제 1 - NSCache의 정책 (부제: 문서는 읽어보고 썼니?)

첫번째 문제점은 NSCache에 대한 학습이 제대로 이루어지지 않은 상태에서 구현을 했다는 것이었습니다. 

저희는 NSCache를 이렇게 정적메모리에 올려두고 데이터를 캐싱하는 방법을 사용했는데요, 그때도 공식문서를 보긴 했지만..

이렇게 첫줄에 auto-eviction policies 라는 말만 보고 '아~ 알아서 해주는구나'라고 넘어가 버린거죠..

실제로는 아래에 프로퍼티 목록을 보게되면 countLimit과 totalCostLimit을 통해서 캐시 정책을 수행할 사이즈를 정해줄 수 있는데, 이 값을 디폴트로 사용하면 뭔가 NSCache가 다 알아서 해줄 것이라는 믿음이 그때는 있었던 것 같습니다. 왜 그랬니..

 

막상 문서로 들어가보면ㅋㅋㅋ 디폴트는 0이고 0일 때는 limit이 없다고 해요ㅋㅋㅋ 그러니까 말만 캐싱이지 그냥 메모리에 되는대로 다 저장하고 있었던거죠.. 

 

개발 단계에서는 친구데이터를 많이 추가하지 않고 팀원들이 각각 계정을 가진채로 4명의 데이터만 있었기 때문에 메모리를 많아 잡아먹는다는 걸 느끼지 못했던 것이었습니다ㅠ 

 

해결 - 정책을 개선하자: totalCostLimit

위에서 본 것 처럼 NSCache의 정책을 효과적으로 사용하기 위해서는 크기 제한을 만들어주는 것이 좋을텐데요, 두 종류의 제한이 있었습니다. 하나는 totalCostLimit이고, 하나는 countLimit이에요.

 

이름에서 유추가 가능하죠? totalCostLimit은 개수와 상관없이 NSCache에 저장된 데이터들의 cost에 제한을 두는 것이고, countLimit은 개수에 제한을 두는 방법입니다. 

 

저희 앱에서는 totalCostLimit을 사용하게 되었는데요, cost에는 어떤 값이든 다 사용할 수 있지만 이미지의 용량을 cost로 삼아서 일정 용량이 넘어가면 NSCache에서 데이터를 비워줄 수 있도록 의도했습니다.

그래서 기존에 이렇게 저장하던 이미지를,

이렇게 cost와 함께 저장하는 메서드를 사용해서 저장해주었습니다. imageData는 Data 타입이고, Data 타입의 count 프로퍼티는 바이트 카운트를 의미하기 때문에 바이트 단위의 파일 크기가 cost로 저장이됩니다.

 

그럼 이제 디폴트로 사용하지 않고 용량을 정해주어야겠죠?

먼저 이미지 캐시에 타입 메서드를 하나 추가하고 메서드를 통해 CostLimit을 주입할 수 있게 해주었습니다. 

 

그리고 SceneDelegate에서 앱이 시작될 때마다 

NSCache의 costLimit을 50메가바이트로 초기화해주었습니다.

 

잘 되는지 테스트하기 위해서는 제한 용량을 2메가바이트로 줄이고 확인해볼게요!

 

테스트 - 2.5 MB에서 캐싱 정책이 적용되는지 확인하기

먼저 테스트를 위해서 NSCacheDelegate를 추가적으로 채택해주었습니다. Delegate 메서드 중에서 willEvictObject가 있어서 NSCache에서 데이터가 지워질 때 어떤 데이터가 지워지는지 확인해보려고 해요.

 

추가적으로 memory hit 상황과 disk hit 상황에 대한 출력도 확인해봅시다.

제 친구 목록엔 이렇게 그리운 두 분이 있는데요, 앱을 실행하고 친구목록에 들어가면

이전에 다운로드 받았던 이미지 이기 때문에 콘솔에 디스크 히트가 찍히고, 캐싱된 데이터도 최신본이기 때문에 304가 조건부 요청의 응답으로 돌아온 것을 확인할 수 있었습니다. 그리고 디스크 캐시 히트가 되었으니 메모리 캐시를 갱신해야겠죠.

 

그런데 중간에 evicted가 찍혀있네요! etag를 보니 두번째 사진이 먼저 캐시에 올라가고 첫번째 사진을 캐시에 넣으려고 할 때 캐시에 있던 사진이 삭제된 것 같습니다! 지금 NSCache의 최대 허용 cost가 대략 2.5mb이니 한번에 하나의 사진만 캐시에 유지하게 되는거죠. 

 

잘 해결된 것 같습니다!

 

문제 2 - 디스크 캐시 정책

두번째 문제는 디스크 캐시 정책에 대한 부분인데요, 두가지 작은 문제로 다시 나눌 수 있었습니다.

 

2-1 메모리 캐시 갱신

가장 어이없었던 문제는 디스크 캐시가 히트되면 메모리 캐시를 갱신하지 않는다는 것이었습니다.(NSCache 정책의 예제는 이미 버그를 고친 코드로 테스트했습니다!) 

 

위 코드를 보시면 FileManager를 이용해서 파일이 존재하는지 한 번 확인하고 있으면 그대로 반환을 해주고 있는데요, 문제는 디스크 캐시가 히트되었을 때 메모리 캐시에 데이터를 넣어주고 있지 않고 있어요. 이렇게 구성되어 있으면 디스크에 저장되어 있는 데이터는 서버데이터가 바뀌기 전까지는 매번 메모리가 아닌 디스크에 접근하게 되니 좋은 방법이 아니죠. 메모리보다 디스크를 읽는 시간이 더 기니까요.

 

이 부분은 쉽게 수정할 수 있는 부분이라서 빠르게 수정했지만 처음부터 제대로 구현하지 못한 것 같아서 아쉽네요ㅠ

 

2-2 디스크 캐시 삭제

또 다른 문제점은 디스크에 한 번 저장된 데이터는 삭제하지 않는다는 것이었습니다. 친구가 늘어나면 늘어날수록 디스크에는 점점 이미지들이 쌓이고, 이건 앱 용량을 증가시키기 때문에 생각보다 좋지않은 상황이었어요.

 

해결 - 디스크 캐시 정책을 개선하자

정책 적용 기준

먼저 할 일은 2-2를 해결하는 것이었어요. 왜냐하면 디스크 캐시를 비워주는 기준을 용량으로 할지, 개수로 할지와 같이 더 세부적인 정책을 결정하게되면 메모리 캐시에 저장할 객체를 조금 수정해야 할 수도 있겠다고 생각했거든요. 

 

제가 생각한 방법은 두 가지가 있었습니다. NSCache 처럼 디스크에 저장된 사진이 일정 개수를 넘으면 삭제를 하거나, 일정 용량을 초과하면 삭제하도록 하는 방법이었죠. 

 

처음에는 메모리 캐시처럼 용량을 기준으로 처리하려고 했는데요, 생각보다 쉽지 않겠다고 생각했던게 그럼 File Manager로 모든 파일을 메모리로 가져와 읽어서 크기를 계산해주어야하고, 이런 과정이 한번 용량이 초과되기 시작하면 새로운 이미지를 다운받을 때마다 매번 발생하기 때문에 IO에 사용하는 오버헤드가 너무 크다고 생각했습니다. 

 

그래서 결국 일정 개수가 넘으면 데이터 중 하나를 삭제하기로 결정했습니다.

 

어떤 데이터를 삭제할건데?

NSCache는 내부적으로 삭제하는 알고리즘이 있기 때문에 이 부분까지 신경쓰지 않아도 되었지만, 디스크 캐시의 경우에는 직접 구현해야했습니다. 그래서 캐시 정책을 설정해야 했는데요, 일반적으로 캐시에 많이 사용하는 LRU(Least Recently Used) 알고리즘을 적용하기로 결정했습니다. 

 

저희 앱에서는 친구 프로필을 보거나 대결할 때, 그리고 친구의 목록을 볼 때 이미지 캐싱이 일어나기 때문에 자주 보기 않는 친구일 수록 앞으로도 더 보지 않을 가능성이 높죠. 그래서 LRU가 적합하다고 판단했습니다. LRU를 사용하지 않는다면 LFU(Least Frequently Used)도 좋은 옵션이 될 수 있을 것 같아요! 대결을 하지 않거나 관심이 없는 친구일 수록 이미지 사용 횟수가 적을 테니까요. 

 

구현 - 캐싱되는 이미지의 개수를 기준으로 LRU 적용

먼저 LRU를 적용하기 위해서는 마지막으로 사진을 사용한 시간을 기록해주어야했는데요, 이를 위해서 기존에 캐싱한 이미지와 ETag를 저장하던 객체를 조금 수정할 필요가 있어졌습니다.

따라서 이렇게 이미지 데이터와 ETag를 저장하던 자료구조를,

 

마지막으로 사진을 사용한 시간을 함께 저장할 수 있도록 했습니다.

 

이 과정에서 CacheInfo 타입이 추가되었는데요, 현재 구조에서는 이미지는 FileManager로 디스크에, ETag는 UserDefaults에 저장하고 있었습니다. 이 때문에 사용한 시간을 ETag와 함께 저장하기 위해서 인코딩/디코딩이 가능한 데이터 타입을 추가적으로 만들어주었습니다.

 

그리고 실제로 디스크에 저장할 때는, 기존에는 별 다른 정책이 없어서 아래처럼 간단하게 저장하던 로직을 더 복잡하게 구성하게 되었습니다.

이랬던 디스크 저장 로직이,

이렇게 복잡해졌습니다..ㅎㅎ

 

핵심적으로 추가된 부분을 천천히 복기해볼게요.

먼저 이 코드가 정책에 따라 데이터를 삭제하는 코드인데요, FileManager를 통해 캐시 디렉토리 내부에 있는 파일의 개수를 읽어옵니다.

그리고 그 개수가 50개를 초과하면 로직이 실행되는 구조입니다.

 

로직을 살펴보죠!

가장 먼저 UserDefaults에 저장된 모든 키와 키에 대한 값을 순회합니다. 여기서 반복문을 매번 돌아주어야하는 문제점이 있는데, 이미지를 개수로 저장하고 앱에서 UserDefaults에 로그인 여부와 같은 정보 외에는 별다른 정보를 저장하고 있지 않기 때문에 큰 문제는 아닐 것 같아요. 하지만 확장성을 생각하면 그다지 좋은 선택은 아닌 것 같습니다ㅠ

 

아무튼 먼저 value로 읽어온 데이터들 중에서 아까 새로 만들었던 CacheInfo 타입으로 디코딩이 가능한 데이터만 가져옵니다. 캐시에 사용하는 데이터만 가져오기 위해서요.

디코딩은 단순하게 JSONDecoder로 CacheInfo 타입으로 디코딩을 해주고 있어요.

그리고 디코딩해서 얻은 데이터의 마지막으로 사용한 시간을 확인하면서 가장 옛날에 사용한 데이터를 계속 갱신하게 됩니다.

 

여기서 Key는 디스크에서 이미지 저장 주소로 사용하는 이미지 요청 주소이고, value는 ETag와 lastRead를 가지고 있는 CacheInfo 객체이겠죠?

가장 오래전에 사용한 데이터를 골라내면 그대로 그 키 값을 인자로 넘겨 FileManager를 이용해 데이터를 삭제합니다.

 

삭제는 단순하게 디스크와 UserDefaults를 비워주는 방식으로 구현되어 있어요.

삭제가 끝나면 원래하던대로 새로운 이미지의 CacheInfo를 인코딩해 UserDefaults에 넣어주고, FileManager로 새로운 이미지를 저장한 뒤 전체 함수가 반환됩니다.

 

마지막으로 이미지를 사용할 때마다, 즉, 메모리 히트, 디스크 히트마다 lastRead 프로퍼티를 갱신해주어야겠죠?

그래서 사용한 시간을 갱신할 수 있는 함수를 하나 만들고 내부에서는 UserDefaults에 새롭게 값을 써주도록 구현했습니다.

이제 디스크 히트가 발생하면 구현하지 않아 문제였던 메모리 캐시에 데이터를 저장하고, 이미지의 사용시간을 업데이트 해주는 것 까지 진행하게 됩니다.

 

테스트 - 2개 까지만 저장 가능 

테스트를 위해서 디스크에 저장할 수 있는 이미지를 최대 2개로 설정하고 진행해보았습니다.

시나리오는 먼저 친구 목록에 한 번 들어가서 이미지 두 개를 디스크에 캐싱해두고,

프로필 페이지로 이동해 제 프로필 사진을 캐싱하면 기존 이미지 중 하나가 지워지겠죠? 이때 삭제되는 사진이 minji 라고 해봅시다.

그리고 앱을 꺼서 메모리 캐시를 비워주고 다시 친구목록으로 이동하면 minji 사진을 다시 캐싱하기 위해서 사용한지 가장 오래된 이미지가 삭제되는지 확인해보면 될 것 같습니다. 어떤 파일이 삭제되는지는 FileManager에서 파일을 삭제할 때 그 경로를 콘솔에 찍어볼게요!

 

일단 친구목록에서 이미지를 다운로드 받는데 성공했습니다. 디스크에도 저장이 되었겠네요.

 

이제 제 프로필로 이동해보겠습니다.

 

제 프로필 사진을 새로 내려받았고, 한번에 두 개까지만 저장해야하기 때문에 제일 마지막에 찍힌 콘솔을 보면 여기서 minji 의 프로필 사진이 디스크에서 삭제되었습니다.

앱을 한번 꺼서 메모리 캐시를 비워주고 친구목록으로 다시 이동해볼게요! 

 

먼저 yujin에 대한 히트가 발생했어요! 304가 반환되었으니 이미지는 갱신하지 않지만 lastRead는 갱신되었겠죠? 그 다음엔 minji를 다운받습니다. 이번엔 최대 개수를 초과했으니 삭제를 해주어야하는데 yujin은 방금 사용했으니 가장 오래전에 사용된 제 프로필 사진이 삭제되겠네요.

 

그리고 마지막 콘솔에 보이는 것처럼 제 프로필 사진인 hunihun95가 삭제된 것을 확인할 수 있습니다.

 

마무리, 더 개선할 점

이렇게 해서 프로젝트 기간에는 구현에 급급해 놓친부분들을 개선했던 작업들을 정리해보았습니다. 사실 정리하면서 이런저런 버그들을 발견해서 급하게 수정하느라 시간을 많이 썼어요..ㅎㅎ 일단 처음 의도했던대로 잘 동작하지만 몇가지 개선하고 싶은 것들이 있었습니다.

 

1) UserDefaults, FileManager로 안나누고 CoreData로 한번에 관리하는게 나았을 수도 있겠다는 생각을 했어요. 단순히 lastRead 프로퍼티가 하나 추가된 것 뿐인데 너무 복잡해지더라구요.. 확장성을 위해서는 로컬 디비를 사용하는게 더 좋았을 수도 있겠다는 생각이 들었습니다.

 

2) 또, 디스크 캐시에서 LRU를 구현하면서 이게 진짜 맞나 싶은 생각이 많이 들었어요.. 어쨌든 UserDefaults에 있는 데이터를 전부 다 돌면서 디코딩을 시도해야하니까 좋지 않은 방법처럼 느껴졌거든요. 짧은 시간에 기존 구조를 그대로 유지하면서 처리를 하려다보니 지금은 이런 방법이 최선이라고 느꼈는데, 이후에 여유가 생긴다면 다른 방법으로, 그리고 용량을 기준으로 캐시 정책을 수행할 수 있게 하는게 최선이라는 생각이 들었습니다.

 

3) 개수로 정책을 설정하는 것에 대해서도 좋다고는 생각이 들지 않네요ㅠ 저희는 이미지를 따로 다운샘플링을 하지 않으니까 친구가 업로드한 이미지에 따라서 디스크캐시에 차지하는 용량이 천차만별이 될 것 같아요. 

 

4) 정책에 의해 디스크에서 이미지가 삭제되면 메모리 캐시에 있는 데이터도 비워주어야 할까요? 어차피 내부 정책에 의해 삭제가 될테고, 캐시의 목적은 히트를 만들어서 다운로드를 최소화하기 위해서라고 생각했기 때문에 메모리에 있는 데이터는 삭제해주지 않았습니다. 하지만 앱을 껐다가 키면 디스크에는 남아있지 않기 때문에 다시 다운로드받게 되겠죠. 이 부분은 더 고민해봐야할 것 같습니다.

 

오늘도 읽어주셔서 감사합니다! 저희팀의 프로젝트는 깃허브에서 확인할 수 있고, 위키에는 더 재미있는 내용들도 많으니 놀러오세요~~

 

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