Elastic Cashe
현재 많은 프로젝트들이 AWS과 높은 종속성을 가지고 있습니다. 여기서 개발자들이 검토해야 하는 부분이 DB에 대한 성능을 어떻게 끌어 올릴 수 있을 것인가 입니다. 성능을 끌어 올릴 수 있는 방법은 다양합니다.
- DB Scale을 증가시키다.
- Query문을 최적화 한다.
- DB에 대한 GET 요청을 분산시킨다.
여기서 개발자는 요청을 분산 시키는 방향이 제일 간단하고 효율적이기에 대체로 사용을 하고 있습니다. 그럼 AWS와 의존성이 높아진 프로젝트에서 어떠한 방식으로 분산 시킬 수 있는가를 고민하게 됩니다.
- EC2 내부에 새로운 DB를 구축한다.
- AWS에서 제공하는 서비스를 사용한다.
1번의 경우 EC2 서버 자체에 부하가 증가하기 때문에 그렇게 큰 효과를 보기 어려울 수 있습니다. 하지만 2번의 경우 별로의 서버를 하나 만드는 것과 같기에 좀 더 높은 효율을 얻을 수 있을 것 입니다. 결론적으로는 DB에 대한 부하를 줄이기 위해서 AWS에서 제공하는 Elastic Cashe를 사용한다는 것입니다.
Cashe
그렇다면 우리가 캐시를 사용하기 전에, 왜 캐시를 사용하려고 하는가에 대한 고민을 해보아야 합니다. 우선, 자신이 만드려고 하는 서비스에서 GET요청을 얼마나 많이 보내고 있는가를 고민해봐야 합니다. 수정작업이 많은 경우에는 캐시가 가지고 있는 이점을 사용하기 어려울 수 있습니다.
캐시가 가지고 있는 장점은 강력합니다. 바로 속도가 빠르다는 것입니다. 아래의 사진은 컴퓨터의 메모리의 계층으로 레지스터 다음으로 속도가 빠른 것은 캐시입니다. 그리고 서버의 부하를 줄 일수 있기 때문에 금액적인 부분을 절감할 수 있다라는 것입니다.
하지만 단점으로는 비싼 가격에, 용량이 작다라는 것입니다. 그리고 다른 단점으로는 서비스를 배포 하는데에 있어서 개발자는 서버의 안정성을 고민을 해봐야 하는데 단순히 같은 서버 내에 캐시를 적용한다고 하면은 안정성에서는 큰 이점을 가져오지 못한다는 것입니다.
서버의 안정성이 떨어지는 문제는 크나큰 문제를 불러들이기 쉽습니다. 단순히 Redis 프로그램이 다운이 되었을 뿐인데 서버 자체가 먹통이 되는 모습을 볼 수 있기 때문입니다. 그렇기 때문에 cashe를 위한 서비스를 별도의 서버를 만들어서 사용을 하여 서버의 안정성을 높일 수 있어야 합니다.
Memcashed VS Redis
AWS는 cashe 관련 시스템에서 두가지를 제공하고 하고 있습니다. 하나는 Memchaed 그리고 다른 하나는 Redis 입니다. 그러면 이 둘의 차이가 무엇일까요?
우선 Redis는 Memcashed보다 이후에 나온 프로그램입니다. 그렇다 보니 Memcashed보다 더 많은 기능들을 제공하고 있습니다. 아래는 각 서비스 마다 어떠한 기능을 제공하는가에 대한 표입니다.
가장 크게 눈에 띄는 부분은 Memchaed는 멀티쓰레드를 제공을 하고 있고, Redis 는 싱글쓰레드를 제공하고 있다는 것입니다.
그리고 또 다르게 눈에 띄는 부분은 MSA에 대한 지원 가능여부입니다. Redis의 경우 복제나 버젼 관리 트랜잭션등을 제공을 함으로써 여러 서버가 동시에 사용을 하여도 문제가 없고 Scale up에도 크게 무리가 없는 반면에 Memcahed는 하나만 제공함으로 불편한 부분들이 존재하고 있습니다. 그렇다고 해서 Memcached가 안정성이 떨어진다고는 할 수 없겠습니다.
Elastic Cashe VPC
Elastic Cashe를 접근을 하려고 하면은 EC2를 통해 Private하게 접근이 가능합니다. 즉, 외부에서는 바로 접근이 불가 합니다. 이러한 접근을 허용하기 위해서 VPC를 사용하는 이유 입니다.
AWS에서 VPC는 "Virtual Private Cloud"의 약자로, 클라우드 환경에서 사용자가 가상의 네트워크를 생성하고 구성하는 서비스를 말합니다. VPC를 사용하면 사용자는 AWS 클라우드 리소스를 독립적이고 안전한 네트워크 환경에 배포할 수 있습니다.
일반적으로 VPC는 사용자의 리소스(예: Amazon EC2 인스턴스, Amazon RDS 데이터베이스 등)를 호스팅할 수 있는 가상의 네트워크를 제공합니다. 이렇게 하면 사용자는 인터넷과 연결된 가상 네트워크 내에서 리소스를 구성하고 관리할 수 있습니다.
Lazy Loading
Lazy loading은 프로그램에서 자원을 필요로 할 때까지 그 자원을 로드하지 않고, 실제로 필요한 시점에 자원을 로드하는 방식을 말합니다. 즉, 자원을 필요로 하는 시점까지 로딩을 지연시켜서 불필요한 자원 로드를 방지하고, 필요한 자원만을 효율적으로 로드하여 자원의 낭비를 최소화하는 방법입니다.
이 개념은 주로 네트워크 요청이나 데이터베이스 쿼리 등의 작업에서 많이 사용됩니다. 예를 들어 웹 애플리케이션에서 이미지나 스크립트 파일과 같은 리소스를 lazy loading으로 처리할 수 있습니다. 사용자가 페이지를 처음 열었을 때 모든 이미지를 로드하지 않고, 사용자가 해당 이미지를 보려고 스크롤 등의 동작을 했을 때 해당 이미지만을 로드하는 방식입니다.
캐시(cache)와 결합해서 생각하면, 캐시를 사용하여 이미 로드된 자원들을 임시로 저장하고, 필요한 자원들을 미리 로드하여 빠른 접근이 가능하도록 할 수 있습니다. 이렇게 함으로써 네트워크나 디스크 액세스 등의 비용을 줄이고 성능을 향상시킬 수 있습니다.
Cashe HIT : server의 요청이 Cashe 내에 존재할 경우.
Cashe MISS : server의 요청이 Cashe 내에 존재하지 않는 경우.
Lazy loading은 자원이 실제로 필요로 할 때만 로드되기 때문에 초기 로딩 시간이 단축되고, 사용자 경험을 개선하는 데 도움이 됩니다. 또한, 대규모 애플리케이션에서 자원을 미리 로드하지 않으면 메모리나 네트워크 대역폭 등의 자원을 효율적으로 관리할 수 있어 전반적인 성능 향상에 도움이 됩니다.
Write through
캐시에서 Write Through(라이트 스루)는 데이터가 캐시에 쓰이는 방식 중 하나입니다. Write Through 방식은 데이터를 캐시에 저장하는 동시에 원본 데이터 저장소(예: 메인 메모리, 디스크 등)에도 데이터를 즉시 쓰는 방식을 의미합니다.
Write Through 방식은 데이터가 캐시에 쓰여지는 즉시 원본 데이터 저장소에도 쓰이기 때문에 데이터 일관성을 보장합니다. 캐시에 데이터가 저장되어 있으면 해당 데이터를 빠르게 읽을 수 있고, 원본 데이터 저장소에 데이터를 유지함으로써 데이터 손실이나 불일치 문제를 방지합니다. 그러나 데이터를 쓸 때마다 원본 저장소에도 쓰기 작업이 추가로 발생하므로, Write Through 방식은 일부 성능 저하가 발생할 수 있습니다.
Write Through 방식의 장점은 데이터 무결성과 일관성을 확보하는 것입니다. 특히 데이터가 중요하고 변경 빈도가 높은 경우, Write Through 방식을 사용하여 데이터 손실 가능성을 최소화하고 데이터 일관성을 유지할 수 있습니다. 반면에 단점은 빈번한 원본 저장소 쓰기 작업으로 인한 성능 저하가 있을 수 있다는 점입니다. 또한, 데이터를 쓸 때마다 원본 저장소에 쓰기 작업이 발생하므로 디스크 I/O 등의 오버헤드가 발생할 수 있습니다.
Write Through 방식은 데이터의 중요성과 일관성이 요구되는 시스템에서 적용됩니다. 반면에 성능이 더 중요하고 일시적인 데이터 불일치가 허용되는 경우에는 Write Back(라이트 백) 방식이 쓰이기도 합니다. Write Back 방식은 데이터를 먼저 캐시에 저장하고, 일정 시점에 변경된 데이터를 원본 데이터 저장소에 일괄적으로 쓰는 방식입니다.