[Redis] Redis 사용방법, 세션 불일치 해결

* 개요

• 게임방의 상태를 보여주기 위해 게임방별로 멤버들의 정보를 담을 저장소가 필요하다.
• 이를 어디에 저장할것인가를 결정한다.
• 저장소는 세션 불일치 문제를 해결해야한다.
• 복잡성이 적어야 한다.

 

* 세션 불일치 해결방법

• sticky session
  • 로드밸런서가 사용자1의 요청을 해당 세션을 가지고있는 서버로 매핑시켜주는 방법
  • set-cookie = SERVERID=서버1 이런형식

• 매번 set-cookie를 해야해서 번거롭다.
  • 최악의경우 로드밸런싱이 무의미하다. (특성 서버로 요청이 몰리는경우)
  • 장애발생시 정보를 모두 잃게된다.
• 방법2 : 세션 클러스터링

• 단점 : 세팅이복잡하다. 복제 직전에 조회하는경우 데이터 정합성이 깨질수있다. 네트워크 비용증가.

 

• 방법3 : 세션 스토리지 (Disk, 인메모리)
  • Disk 방식장점 : 유실이 되지않는다.
  • 단점 : 느리다. -> 게임서버에 적합하지 않다.
  • 인메모리 비교 

  • 	Redis	Memcached
    코어	싱글 코어	멀티 코어
    자료구조	Strings, Set,, Sorted-Set, Hashes 등 다양한 자료구조 지원	Strings, Intergers만 지원
    데이터 저장	Memory, Disk	Memory
    속도	읽기, 쓰기 속도가 Memcached보다 느림 하지만 큰 차이는 없음	디스크를 거치지 않기 때문에 읽기, 쓰기 속도가 Redis보다 빠름
    복제	Master-Slave, Multi-Master Replication 방식 지원	지원 X
    내구성	Memcached보다 내구성이 뛰어남	Redis보다 내구성이 떨어짐
    영속성	영속성 데이터 사용	지원 X
    파이셔닝 방법	샤딩 지원	지원 X
    메모리 재사용	메모리를 재사용하지 않음, 명시적으로만 데이터 제거 가능	저장소 메모리를 재사용. 만료전에 더 이상 데이터를 넣을 메모리가 없으면 LRU 알고리즘에 따라 데이터 삭제
    만료일 지정 방식	만료일을 지정하면 만료된 데이터는 캐시처럼 사라짐	동일

 

• • 

    그래프 값이 낮을수록 좋은 것임

  • 게임이라는 특성상 쓰기작업도 많을것으로 예상되지만, 실시간 상태 조회도 많이 생길것으로 예상.
  • 레퍼런스가 많은 Redis를 선택.
  • 단점 : 문제가 생기면 모든 서비스 중단, 네트워크비용
  • 해결 : 마스터-슬레이브 복제, WAS와 Redis를 같은 EC2에 설치
  • 궁극적으로 Redis && 마스터-슬레이브 복제를 구현하고자 한다.

 

* Redis 알아보기

• 자료구조

• 메시징큐

• 데이터 영구저장 방법 RDB vs AOF
  • AOF : 과정까지 모두저장 (압축필요)
  • RDB: 그때의 상태만 저장

• save 900 1 // 900초동안 1개 이상의 key 변경시 rdb파일 재작성하라.

• 실시간 게임의 특성상 점수 등 상태 그대로 복원을 위해 AOF를 고려

 

• redis 아키텍쳐

• HA기능(자동 fail-over)? -> YES, 게임특성상 메인이 죽으면 자동으로 옮겨줘야함.
• 샤딩? -> No, 분산해서 데이터를 저장할만큼 데이터가 크지않음. 오버엔지니어링.
• Sentinel 아키텍처가 적절함.

• write 불가능 옵션을 꺼두자. 장애가능성이 있다. (Redis Server 모니터링은 필요!)
• 메모리가 찼을때, 가장최근에 사용하지않은 data를 삭제한다. // 기본값 -> 삭제안함 -> 서버 die

• MaxMemory는 가용메모리의 절반으로 설정하자!
• 레디스에서 데이터를 파일로 저장하고자 할 때 Copy-On-Write라는 기능을 사용합니다. 이 기능을 이용해야 백그라운드에서 파일로 데이터를 저장하는 동시에,  레디스에 연결된 기존 어플리케이션의 커넥션도 이슈 없이 대응할 수 있기 때문입니다. 이 Copy-On-Wrtie는 물리적으로 기존의 메모리를 복사해서 사용하기 때문에, 경우에 따라 레디스가 사용하는 총 메모리가 (maxmemory * 2)가 되는 상황이 발생할 수 있습니다.
  
  발표에서 말씀드린 '예상치 못한 장애' 란 이 Copy-On-Write 기능으로 인하여 레디스가 예상보다 많은 메모리를 사용하게 되어 OOM이 발생해 시스템에 장애가 발생할 경우에 대한 이야기였습니다.
  
  레디스에서 파일을 저장하는 경우란 RDB, AOF 등 백업을 위해 실제 데이터를 저장하는 경우와, 복제를 사용하는 경우. 이렇게 두가지입니다. 복제를 사용할 때에 마스터 서버의 백그라운드에서 RDB를 이용해 데이터를 저장한 다음 리플리케이션에서 복구하는 작업을 거치기 때문입니다.
  
  따라서 위와 같은 상황을 방지하기 위해 MaxMemory 값을 실제 메모리의 절반 이하로 줄이는 것을 권장드리고 있습니다.

• rss를 모니터링 하자!
• 삭제작업이 많을때 frag가 증가할수있다. // 삭제작업을 위해 os가 redis에 메모리할당, but 삭제로 간주 -> 논리적 메모리 사용량은 감소
• frag는 rss만 높은 증상을 말한다.
• 이때 activedefrag를 켜주면 도움이된다.

 

요약

• 세션 불일치 해결은 세션스토어 로
• Redis 아키텍쳐는 Sentinel 로
• 데이터 영구저장은 AOF 로
• 모니터링은 rss 로
• O(N) 명령어 사용금지

 

 

 

 

 

 

 

 

 

* 레퍼런스

https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EA%B0%9C%EB%85%90-%EC%86%8C%EA%B0%9C-%EC%82%AC%EC%9A%A9%EC%B2%98-%EC%BA%90%EC%8B%9C-%EC%84%B8%EC%85%98-%ED%95%9C%EB%88%88%EC%97%90-%EC%8F%99-%EC%A0%95%EB%A6%AC

[REDIS] 📚 레디스 소개 & 사용처 (캐시 / 세션) - 한눈에 쏙 정리

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%84%B8%EC%85%98Session-%EB%B6%88%EC%9D%BC%EC%B9%98-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0%EB%B2%95-%E2%B8%A2%EC%84%9C%EB%B2%84-%EB%8B%A4%EC%A4%91%ED%99%94-%ED%99%98%EA%B2%BD-%E2%B8%A5

🌐 세션(Session) 불일치 문제 및 해결 방법

https://www.youtube.com/watch?v=92NizoBL4uA