웹과 게임에서 다르게 사용되는 캐시

성능 향상을 위해 다양하게 이용되는 캐시

이 캐시마저, 게임과 웹에선 다르게 적용되는데, 이에 대한 질문을 꽤 여러번 받았다. 그 과정에서 설명했던 내용을 글로 정리해보고자 한다.

    • 사용자에게 보낼 HTML 캐시
    • API 파라미터에 대한 동일한 응답을 위한 캐시
    • DB 처리 전의 중간 저장소로의 활용.
    • 동일한 URL의 정적 데이터 (이미지, js, css 파일 등)에 대한 캐시
    • 메모리에 임시 데이터를 저장하는 경우가 매우 드뭄.
      • Ehcache 등을 통한 캐시가 그런 방식 아니냐라고 물어볼 수도 있지만, 게임에서의 메모리 활용과는 궤를 달리하는 측면이 큼.
    • 서버의 스케일 인/아웃의 유연함을 위해, API 호출이 특정 서버로만 전달되게 구성하는 경우가 적다.
      • 이는 메모리에 캐싱 해둔 데이터가 과거 데이터 일수 있음을 감안해야 할 수 있거나, 이를 동기화 하는 별도의 추가 작업이 필요함을 의미한다.
      • 또한 session의 경우 만료 시점에 캐싱 해둔 데이터를 DB에 반영한다거나 이에 대한 대비를 하는 작업은 웹 관점에서도 데이터 유실의 리스크가 있기때문에 쉽게 선택하기 어려운 측면이 있다.
      • Session 만료 체크를 polling 하기도 껄끄러울 뿐더러, 캐싱하던 session 데이터를 서버 종료 시점에 push 해주어야 하고, 서버 크래시라도 발생한다면 게임 쪽에서 종종 발생하는 백섭 같은 데이터 유실로 이루어 질 수 있기 때문이다.
    • 분산 캐시는 어떠한가?
      • 특정 서버에서의 변경된 내용으로 인해 캐싱 내용이 변경 될 경우, 이를 연관 서버들에게 전파해, 캐시 데이터를 다시 동기화함을 말한다.
      • 조금은 늦게 캐시가 동기화 되어도 문제 없을 법한 것들 위주로 캐싱한다.
      • 조금의 오차도 용납되지 않을 중요 데이터일 경우 어차피 웹에서도 캐시를 쓰기 어렵다.
  1. 게임
    • 웹 서버를 이용하지 않는 경우를 전제함.
    • 이미 메모리에만 들고 있는 임시 데이터가 존재하는 경우가 대 다수.
      • 주로 소켓과 물려있는 메타 정보를 저장하는 세션에 저장.
      • 세션끼리 공유하는 데이터들을 메모리에 보유.
        • 필드 (=Zone)
        • 채널
    • 동일한 요청이라고해도, 이미 바뀌었을 가능성이 매우 높기에 동일한 요청 파라미터라해도 캐싱하는 것이 무의미하다.
      • 가능한 컨텐츠는 일부 존재 할 수 있을 듯.
      • 우편함이라거나, 인벤토리 같은 진입점을 제어하고, 진입점 변경시 캐시 클리어 방식으로 웹과 비슷하게 사용 가능할 것 같다.
    • 게임은 브로드 캐스트를 자주 사용하는 편인데, 이벤트가 발생하면 새로운 요청을 클라이언트가 보내는 것이 아니라, 서버가 적합한 대상자에게 브로드 캐스트함으로써 실시간 동기화해야 하기 때문이다.
      • 특히 이동, 전투 등의 과정에서 ms 단위의 동기화가 어긋나도 버그라고 느끼는 게임에서는 캐싱할 수 있는 정보고 극도로 한정되어있다.
    • 그렇다면 과연 게임에서의 캐싱의 주 사용처는?
      • 메모리에 들고 있는 내용은 언젠가 DB에 반영되어야 할 데이터기 때문에, DB 저장 전의 중간 저장소로 사용하는 경우가 많다.
        • DB 처리 속도는 게임의 데이터 변화량보다 느릴 때도 많기 때문에, 메모리 연산을 통한 응답을 주어야만 반응성을 유지시킬 수 있기 때문이다.
      • 캐싱 용도로 저장된 데이터를 공유하는 용도로도 쓰인다.
        • DB 억세스를 직접하면, Read IO만으로도 DB에 부담을 줄 수 있다.
        • 적절한 키로 분배해놓은 캐시 서버로부터 데이터를 얻어옴으로써, DB에 부담을 줄이는 선택을 한다.
      • 심지어는 중국이나 국내 일부 업체는 DB의 트랜잭션 같은 처리를 전혀 사용하지 않고, 캐시 서버, 어플리케이션 서버 등에서 철저히 제어함으로써의 성능 극대화마저 노릴 정도니 접근 자체가 완전히 다르다고 해도 무방하겠다.

이상 웹과 게임에서의 캐시 처리에 대해 비교를 해보았다.

사실 게임에서는 캐시 서버 마저도, 범용 레디스 같은 캐시 디비를 쓰지 않고, 커스텀하게 짜는 경우가 많았다. 이는 게임 개발자들이 오픈 소스를 응용또는 학습의 부족이라고 치부 하는 사람들도 있을 수 있으나, 그렇진 않다.

응답성 극대화라거나, 국지적 쓰루풋의 극대화, 비동기 프로그래밍 도구 부족으로 인한 문제, 레디스의 메모리 기반 처리량, 제약에 대한 해결 등의 다양한 이유가 있었음을 한번쯤은 언급하고 싶었다.

Comments

comments powered by Disqus