다음 블로그는 Open Up의 도움을 받아서 작성되었습니다.
Redis 를 사용하는 방법은 여러가지가 있습니다. On-Premis 에서도 직접 서버에 Redis를 설치하고 이용하는 Self Managed 형태나 회사에서 제공하는 Managed 형태가 있습니다.(큰 N이나 K 같은 회사에서는 내부에서 관리해주는 일종의 Managed 형태로 Redis를 사용하고 있습니다.)
AWS와 같은 Cloud 서비스를 사용하는 경우에도 많은 경우 Managed 형태를 사용해야 하는지 아니면 Self-Managed 를 사용해야 하는지에 대한 고민을 많이 하게 됩니다. 그렇다면 어떤 걸 이용하는 것이 더 좋을까요?
결론부터 말하자면, 결국 Case By Case 입니다. 어떤 기준에서 선택하는가? 이 것을 쉽게 관리할 능력이 있는 사람이 있는가에 따라서 선택할 수 있는 옵션이 달라지게 됩니다.
일단 여기서는 AWS의 ElastiCache 와 EC2에서 직접 설치해서 사용하는 경우만 비교를 해야 할듯합니다.
먼저 가격에 대해서 비교를 해보도록 하겠습니다. 가장 민감한… 일단 가격 비교는 ap-northeast-2 아시아/서울 리전을 대상으로 했습니다.
| 사양 | AWS ElastiCache(USD/hour) | EC2(USD/hour) |
| t4g.medium | 0.094 | 0.0416 |
| t3.medium | 0.099 | 0.052 |
| m6g.xlarge | 0.363 | 0.188 |
| m6g.16xlarge | 5.806 | 3.008 |
| r6g.16xlarge | 7.862 | 3.904 |
| r5.24xlarge | 12.414 | 7.296 |
위의 가격은 ElastiCache를 사용하는 것과 EC2를 사용하는 것의 가격을 비교한 것입니다. 사양에 따라서 다르긴 한데, 대략 2배 정도의 가격 차이가 나는 것을 볼 수 있습니다.
두 번째는 CPU의 활용도 입니다. 위의 스펙의 사양을 보면 다음과 같습니다.
| 사양 | VCPU | Mem(GB) | Mem/VCPU |
| t4g.medium | 2 | 4 | 2GB |
| t3.meduim | 2 | 4 | 2GB |
| m6g.xlarge | 4 | 16 | 4GB |
| m6g.16xlarge | 64 | 256 | 4GB |
| r6g.16xlarge | 64 | 512 | 8GB |
| r5.24xlarge | 96 | 768 | 8GB |
Redis 는 기본적으로 Single Threaded 입니다. Redis 6나 AWS 의 ElastiCache 5.x에서 r5.2xlarge 부터는 내부적으로 Multi-Threaded IO를 이용해서 Read/Write 부분의 패킷처리를 한다고 하지만, 내부적으로 프로세스 처리의 기본은 Single Threaded 입니다. 즉 아무리 VCPU가 많아도 제대로 처리가 안될 수 있습니다.
그리고, ElastiCache 에서 어떻게 메모리를 관리하는지 알 수 없지만 NUMA아키텍처를 사용한다면 절반 이상의 메모리를 사용할 때 속도에 문제가 발생할 여지가 있습니다. (메모리를 절반 이하로 사용한다면 이슈가 없습니다.)
즉, vCPU를 활용하고 NUMA 이슈를 피하기 위해서, EC2에서 Redis를 직접적으로 운영한다면, CPU와 메모리를 더 효율적으로 사용할 수 있으므로, 좀 더 많은 Traffic을 이용할 수 있습니다. 이를 위해, 실제로 하나의 EC2 인스턴스에 여러 개의 Redis 인스턴스를 띄우게 됩니다. 용량이 클수록 적당히 많은 메모리를 할당하는 형태로 가지만, 하나의 Redis당 20GB 이상은 띄우지 않는게 관리가 용이합니다.
지금까지 Self-Managed 의 장점을 얘기했지만, 반대로 이 점들은 다시 Self-Managed의 단점이기도 합니다.
AWS의 ElastiCache는 기본적으로 도메인 기반의 Failover를 처리해줍니다. 예를 들어, charsyam-redis-master 라는 도메인을 이용하다가 장애가 발생하면, Replica 노드가 자동으로 charsyam-redis-master 라는 도메인을 가져가서, 클라이언트가 재접속 하는 것 만으로 Transparent 하게 Failover가 가능합니다.
예전에 카카오의 경우 RHA(Redis High Availabilty) 라는 기능을 만들어서 AWS의 ElastiCache 와 비슷한 방식의 Failover를 제공했습니다. 자세한 것은 https://tech.kakao.com/2016/03/18/redis-ha-dns/
즉, 직접적으로 EC2에서 Redis를 운영하신다면, 이런 부분을 직접적으로 관리를 해야 합니다. 적은 인력으로 이런 기능을 구현하고 관리하는 것은 쉬운 일이 아닙니다.
결과적으로 정리를 하면 비용적인 측면이 중요하다면, 그리고 충분한 관리 인력이 있다면 Self-Managed 가 더 효율적일 수 있습니다. 반대로 이런 부분에 대한 고민을 하지 않고, 다른 부분에 더 신경을 쓰고 싶다면 Managed Redis를 사용하는 것이 훨씬 더 유리하다고 생각합니다.
단순히 Failover 뿐만이 아니라, 모니터링이나 이런 부분에 대해서는 운영관리가 필요합니다.
만약에 저에게 너는 뭘 하고 싶냐고 하면, 저는 무조건 남이 관리해주는 거라고 말을 합니다. 즉, Managed가 훨씬 좋을듯 합니다.