30.Redis, 운영 시 임계점에 대해서 알아 볼까요? ^^ CPU, Memory, Network에 대해서..

Redis 운영적 관점의 임계점에 대해서..

• 스케일 업과 스케일 아웃
  • 스케일업
    • 우수한 성능을 제공하는 부품을 조립하여 강력한 장비 한대를 구축.
      • 만약 성능이 떨어질 경우, 하드웨어를 업그레이드하여 개선하는 방식.
      • but, 비싸고, 성능 좋은 부품을 사용하더라도, 한대의 성능에는 한계가 반드시 있음.
  • 스케일아웃
    • 성능이 떨어질 경우, 논리적으로 서버대수를 추가해서 해결 가능하므로, 한계는 없다.
      • but, 현실적으로는 네트워크 대역폭등등에 의한 한계가 있게됨.
      • 이와 같은 한계점을 우리는 임계점이라고 부름.
• 임계점
  • CPU
    • Redis 는 데이터 저장과 조회에 단일 스레드를 사용함.
      • 즉, 멀티코어를 지원해도 오직 단일 코어만을 사용함.
        • 결과적으로, 멀티코어 시스템에서 실행되더라도 하나의 코어만을 사용하기 때문에 단일 코어 성능이 낮은 32코어 장치보다 단일 코어 성능이 높은 4코어 장치에서 더빠른 성능을 보이게됨.
    • 다른방안은 없을까?
      • 멀티코어 시스템의 성능을 최대로 끌어올리기위해서, Redis 인스턴스를 멀티코어 개수만큼 실행하는 방법을 생각해 볼 수 도 있음.
        • ex) 16코어일 경우 16개의 Redis 인스턴스 실행.
          • 그러나, 16개의 Redis 인스턴스가 점유한 코어의 리소스를 모두 사용한다면, 운영체제 운용에 필요한 리소스가 부족하게 되어 운영체제가 정상적으로 동작할 수 없게 되므로 결과적으로 다른 Redis 인스턴스도 응답 속도가 동시에 느려지게되는 결과를 초래하게됨.
  • Memory
    • 메모리 대역폭이란?
    • 1초에 전송할 수 있는 데이터의 양으로 정의 됨.
      • https://en.wikipedia.org/wiki/Memory_bandwidth
      • Memory bandwidth is the rate at which data can be read from or stored into a semiconductor memory by a processor.
        • 직독직해하자면
          • 메모리 대역폭은 비율이다/ 데이터를 반도체 메모리로부터 읽거나 저장되게 할 수 있는/ 프로세서로 의하여
        • Memory bandwidth is usually expressed in units of bytes/second.
          • 직독직해하자면
            • 메모리 대역폭은 / 보통 표현되는데 /  초당 bytes 단위로...
          • 두 구문을 다시 종합해서 우리말로 정리하자면, 아래와 같다.
            • 메모리 대역폭은 프로세서로 부터 데이터를 반도체 메모리로부터 읽거나 저장되게 할 수 있는 비율이고, 메모리 대역폭은 보통 초당 bytes 단위로 표현된다는 말... ^^;
      • 메모리 대역폭

        • 

          • 단일 시스템에서 4개의 인스턴스들이 점유하는 메모리 상태, 데이터 버스와 CPU 코어의 관계를 보여줌.
            • 다시말해서, 4개의 Redis 인스턴스가 동시에 명령을 처리한다고 가정하면,
              • Redis 는 명령어 처리를 위해 메모리에 접근
              • 조회된 데이터는 메모리 대역폭을 사용하여 데이터 버스를 통해서 해당 코어로 전송.
              • 결론적으로, 4개의 인스턴스가 메모리 대역폭을 나누어 사용함으로, 병목현상이 발생함.
            • 즉, 단일 시스템에서 다중 인스턴스를 실행하려면, 메모리 대역폭이 충분해야 함.
              • 서비스에 사용하는 시스템은 메모리 대역폭이 다르므로 적당한 인스턴스 수를 테스트를 통해서 구해야 함.
            • Redis 에서는 테스트를 위해서 redis-benchmark 명령어를 지원함.
          • 보통 메모리 대역폭이 충분하다고 가정하면 코어 개수의 1/2 보다 작은 수의 인스턴스를 실행하는 것이 적당하다고 함.
        • Redis 는 메모리에 데이터를 저장하기때문에, Redis 가 사용할 메모리의 크기를 지정하는 것은 성능과 가장 밀접한 관련이 있음.
          • Redis 의 설정 정보 (redis.conf)
          • 보통 Redis에 저장될 데이터의크기를 산정하면, maxmemory 설정에 값을 지정함.
          • 메모리 산정이 되지 않아, 해당 설정에 값이 없을 경우, Redis 에 데이터가 계속 추가되어 물리 메모리를 모두 사용하게됨.
            • 만약 이때, 사용 가능한 물리 메모리보다 더 많은 메모리를 사용하려고 할때 우리가 잘 알고 있는 Swap 공간이라는 가상 메모리 공간을 하드디스크에 생성하여 사용함.
            • 만약 Swap 공간도 부족할 경우는, 운영체제에서 동작중인 프로세스를 죽이는 OOM 킬러가 작동하게됨.
              • OOM(Out of Memory) 킬러
                • 참고페이지 : https://linux-mm.org/OOM_Killer
              • OOM 킬러를 피하기 위해서는 충분한 Swap 공간을 확보해야 함.
            • but, Swap 공간의 단점은 디스크이기 때문에, Redis 처리속도가 현저히 저하됨.
              • 약, 수십배 ~ 수백배(?) ㅡ_ㅡ; 정도 느려진다고 함.
            • 즉, 만약 응답속도가 중요한 서비스라면, 반드시 redis.conf의 maxmemory 설정에 설치된 물리 메모리 크기 이내의 값을 지정해야함.
              • 즉, 제가 하고 싶은 말은 Redis 사용 시 사용 메모리 산정이 필수임 ^^!;
        • 여기서 잠깐!) 레드헷 엔터프라이즈가 추천하는 Swap 공간 설정은 얼마일까요? 아래 Red Hat Enterprise Linux 권장 swap 크기는 어떻게 되나요라고 누가 물어봤네요 ^^
          • 참고 페이지 : https://access.redhat.com/ko/solutions/744483
        • 참고로, Redis 가 AOP or 스냅샷과 같은 영구 저장소를 사용하도록 설정되어 있다면, 스왑영역은 최소한 물리 메모리 크기 만큼의 스왑영역을 설정해야 된다고함.
          • 왜냐하면, AOF or 스냅샷을 위해 fork() 함수가 동작하면, 운영체제는 Redis 가 점유하고 있는 메모리 만큼의 메모리를 다시 할당하려고 시도하게 되기 때문에...
        • 만약, 지정된 Redis 의 메모리 크기보다 더 많은 데이터를 저장하려고 한다면, Redis는 오류 메시지를 전송하고 쓰기 요청을 실패처리함.
          • but,  이 상황에서는 읽기요청은 정상적으로 처리가되므로, 응답시간이 중요한 서비스에서는 반드시 메모리의 크기를 지정하고 사용하는 것이 유리하다고 함.
        • 그럼, Redis 에 저장된 데이터의 크기가 maxmemory 설정에 지정된 값을 초과하게되면 어떻게 될까?
          • Redis 의 쓰기 연산이 실패하게 되고, 이때 Redis는 저장 가능한 메모리 영역을 확보하기 위해서, 기존에 저장된 데이터를 지우게 되는데, 해당 동작은 환경설정의 정책에 따라서 달라지게됨.
            • maxmemory-policy 설정
  • Network
    • Redis 클러스터 구성에서 가장 많이 고려되어야 하는 임계점은 단연 네트워크임. ^^
      • 클러스터 물리 구성

        • 

          • 즉, 물리적인 구성에서 병목구간은 바로 네트워크임.
          • 네트워크 허브의 속도와 각 노드에 설치된 네트워크 카드의 속도를 1Gbps 라고 가정해보자.
            • 1Gbps의 속도를 가진 네트워크 카드의 이론상 최대 데이터 전송률은 약 125MB
              • 1Gbps 는 1000Mbps
                • bps 는 Bit Per Second 의 약자
              • 1000 / 8 = 초당 125MB, 즉 125MB 의 전송률로 계산됨.
            • but, 네트워크 하드웨어가 전송할 수 있는 실제 전송율은 약 100MB 내외라고 함.
            • 즉, 각 노드 별로 처리 가능한 요청을 했을 경우, 네트워크가 처리할 수 있는 데이터의 크기를 넘어서고 있어, 노드의 데이터가 전송되지 못하고 대기하게 되는 현상이 됨.
            • 만약 충분한 네트워크 대역폭을 확보하기 위해서 네트워크 허브를 10Gbps 장비로 교체한다고 하더라도, 순수한 데이터 전송 뿐만아니라, 복제를 위한 마스터와 슬레이브간 데이터 전송과 네트워크 단절에 의한 동기화 등등의 데이터가 있게되면 임계점에 쉽게 다다르게 됨. 
              • 대안으로는 아래 설정이 가능함.

              • 

                • 즉, 하나의 시스템에 2개의 네트워크 카드를 설치하고, 각각의 네트워크 카드를 다른 네트워크 허브에 연결하는 구성.
                  • 읽기/쓰기 와 관리/복제를 위한 트래픽의 분산, 예를 들면 아래와 같음.
                    • 192.168.10.* 대역의 IP 는 Redis 의 읽기 / 쓰기 연산 사용
                    • 192.168.100.* 대역의 IP 는 Redis의 관리및 복제를 위해 사용
                  • 대역폭의 분산으로, 네트워크 병목현상을 피해 가는 방안이 될수도...^^;

결론

• Redis 운영 시 아래 임계점에 대한 고려가 반드시 필요함.
  • CPU
  • Memory
  • Network
• Redis 운영 시 설정들에 대해서 좀더 공부가 필요할 것 같음.
• 오늘도 Redis 운영시 알아야할 임계점 마술(?) 획득완료, 감사합니다. ^^

---

• 오늘의 명언 한마디
  • 투자를 고려하는 이들에게 하고 싶은 말
    • 첫번째, 멈추지 말고 꾸준히 오래 하라는 것이다.
    • 두번째, 목표와 전략을 뚜렷이 하라는 것이다.
    • 세번째, 인맥, 발품, 공부만큼은 반드시 챙기라는 것이다.
      • 오은석(북극성주)지음, "월급쟁이를 위한 부동산 경매" 중에서...

---

• 오늘의 영어 한마디
  • 질문) That music is horrible!
    • 끔찍한 음악이군!
  • 대답) I agree.
    • 맞아.
  • 해설
    • horrible 은 "끔찍한", 단순히 무섭다는 것뿐만아니라, 극도의 혐오감을 나타낼 때 쓰는 표현임.
      • 즉 소름끼치다라고 해석하는 경우가 많음.
        • 그밖의 표현으로는..
          • awful, uncomfortable 등이 있음.