# arcus cache

jam2in

Front Cache? ARCUS와 같이 별도의 서버에서 캐싱을 수행하는 리모트 형태의 캐시 솔루션은 여러 애플리케이션에서 캐싱된 데이터를 서로 공유할 수 있는 장점이 있습니다. 하지만 리모트 캐시는 일시적인 많은 요청으로 인한 장비의 리소스 부족이나 대량의 네트워크 트래픽의 발생에 따라 데이터 응답 시간이 민감하게 영향을 받습니다. 이러한 문제는 클러스터를 확장하거나, 장비의 사양을 올려 해결할 수 있지만, 운영 비용이 증가하는 부담이 있습니다. 상대적으로 비용이 들지 않으면서 소프트웨어적으로 해결하는 방법이 있습니다. 바로 리모트 캐시 앞단에서 애플리케이션 장비의 로컬 메모리를 사용하여 데이터를 캐싱하는 방법입니다. 이를 프론트 캐시(Front Cache)라고 하며, 로컬 메모리에 캐싱한다고 하여 로컬 캐시(Local Cache)라고도 부릅니다. 로컬 메모리에 데이터를 캐싱해두는 것이 네트워크를 통하여 외부 서버에 캐싱하는 것보다 훨씬 빠릅니다. 네트워크 트래픽에 영향을 전

jam2in

ARCUS Single Cache (Dev.) 는 AWS Marketplace에서 ARCUS 캐시를 쉽고 빠르게 경험할 수 있도록 구성된 AMI입니다. AMI(Amazon Machine Image)는 인스턴스 시작하는 데 필요한 소프트웨어(OS, Application) 등이 포함된 템플릿으로, 사용자들이 EC2 인스턴스를 통해 실행할 수 있습니다. ARCUS Single Cache (Dev.)는 AMI 구성을 통해 개발자들이 ARCUS 캐시를 체험해 볼 수 있도록 one-click deployment 형태로 제작되었습니다. 링크: [AWS ARCUS Single Cache (Dev.)](https://aws.amazon.com/marketplace/pp/prodview-rb

jam2in

지난 블로그 글인 ARCUS에서 데이터 영구 보존을 위한 Persistence 기능의 개요와 사용법에서 ARCUS 데이터 영속성을 소개드리고 telnet과 memtier_benchmark 도구로 ARCUS 인스턴스에 명령 요청하여 사용하는 것까지 보여드렸습니다. ARCUS 데이터 영속성 기능이 추가되더라도 기존 캐시와의 성능 차이가 크지 않도록 데이터 영속성 기능의 수행 오버헤드를 최소화하여 ARCUS의 기존 고성능을 보장하도록 구현하였다고 언급하였습니다

jam2in

ARCUS 공통 모듈은 Spring AOP 기술을 활용하여, Java 응용의 코드 수정 없이 선언적인(declarative) 방식으로 응용의 캐시 대상 API에 ARCUS 캐시를 쉽게 적용할 수 있는 기능을 제공합니다. ARCUS 캐시의 적용 방식으로는 캐시 대상 API에 Annotation을 부여하는 방식과 Property 파일에 캐시 대상 API 정보를 명시하는 방식이 있습니다. ARCUS 공통 모듈에 대한 자세한 설명은 - [Java 환경에서 기본 패턴의 캐시 적용을 돕는 ARCUS 공통 모듈](https://velog.io/@jam2in/Java-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EA%B8%B0%EB%B3%B8-%ED%8C%A8%ED%84%B4%EC%9D%98-%EC%BA%90%EC%8B%9C-%EC%A0%81%EC%9A%A9%EC%9D%84-%EB%8F%95%EB%8A%94-ARCUS-%EA%B3%B5%ED%86%B5-%EB%AA%A

jam2in

서비스 운영중에 부하가 집중되어 성능에 문제가 발생할 때 이를 해결하기 위한 방법으로 스케일 업(scale up)과 스케일 아웃(scale out)이 있습니다. 스케일 업은 단순히 서버의 하드웨어를 더 좋은 것으로 교체하는 것으로, 가장 간단한 해결방법이지만 서비스를 재구동 해야하며 성능 증가에 한계가 있습니다. 반면 스케일 아웃의 경우 컴퓨팅 파워를 병렬로 증설하는 것으로 스케일 업과 비교하여 지속적 확장이 가능하다는 장점이 있지만 추가적으로 분산 아키텍쳐 및 정책을 수립해야하기 때문에 복잡성이 증가합니다. ARCUS는 클러스터 기능을 통해 스케일 아웃을 지원하며 이를 통해 서비스의 요청을 분산 저장하고 부하를 분산합니다. 이 글에서는 데이터를 분산 저장할 때 선택할 수 있는 아키텍쳐와 정책들을 소개하고 ARCUS는 어떻게 데이터를 분산하여 저장하는지 소개합니다. 데이터 분산 아키텍쳐 일반적으로 데이터를 분산 저장할 때 고려할 수 있는 분산 구조는 노드 간에 데이터를 공유하

jam2in

ARCUS 인메모리 캐시 시스템은 캐시 용도에 맞게 고성능 데이터 처리 목적으로 메모리를 저장소로 사용합니다. 휘발성 메모리를 사용함에 따라 시스템 장애나 장비 교체, 업그레이드 등의 이유로 시스템이 종료되면 저장해둔 모든 데이터가 사라지는 특징을 갖고 있습니다. 캐시 용도가 아닌 데이터 저장 용도이면서 캐시와 같은 고성능을 제공하는 저장소에 대한 요구가 있어서, ARCUS 캐시 시스템에서도 데이터를 영구히 보존할 수 있는 데이터 영속성(Persistence) 기능을 개발하였습니다. 본문에서는 ARCUS 데이터 영속성 기능을 소개해 드리고, 사용법을 간단히 알려드리겠습니다. ARCUS Persistence 개요 ARCUS 데이터 영속성은 스냅샷(Snapshot)과 명령 로깅(Command Logging) 방식으로 디스크에 캐시 데이터를 기록해두고, 이를 이용하여 완벽하게 데이터를 복구하는 기능을 제공합니다. 데이터 영속성을 제공하기 위하여, ARCUS 인스턴스는 아래 그림과

jam2in

캐시를 처음 적용해보는 개발자라면, 애플리케이션에 캐시를 어떻게 적용할 지에 대한 방향을 제대로 못 잡을 수 있습니다. 애플리케이션에 캐시를 적용할 수 있는 패턴은 매우 다양합니다. 그 중 가장 일반적으로 사용되는 Demand-fill 패턴에 대해 알아보고, 이 방식을 애플리케이션에 그대로 적용했을 때 발생할 수 있는 문제들을 알아보겠습니다. 마지막으로 이러한 문제들을 해결하기 위한 방법으로 사용되는 Spring AOP에 대해 간략히 알아보고, Spring AOP를 활용한 Java 라이브러리 ARCUS 공통 모듈에서 제공되는 기능을 소개하고자 합니다. Demand-fill Demand-fill 캐싱 방식은 애플리케이션에서 데이터 조회 요청이 들어올 때, 먼

jam2in

여러 응용 서비스들에서 서비스 응답 속도를 빠르게 하고 조회 처리량을 늘리기 위하여, 확장 가능한 인메모리 캐시 시스템을 적용하는 것이 일반화되었다. 응용 서비스의 원본 데이터는 DB 같은 영구 저장소에 저장하고, 그 중에 자주 조회되는 데이터는 인메모리 기반의 캐시 시스템에 보관하여 반복된 조회 요청을 빠르게 처리함으로써 응용 서비스의 성능을 확대한다. 이러한 캐시 시스템은 어떤 고장이 발생하더라도 중단 없는 캐시 서비스를 제공하는 fault tolerance 특성을 가져야 한다. 캐시 시스템에 필요한 fault tolerance 의미를 설명하고, ARCUS 캐시 시스템에서 fault tolerance를 어떻게 제공하는 지를 소개한다. 캐시 시스템의 fault tolerance 의미 캐시 시스템은 DB 같은 원본 데이터 저장소에서의 조회 결과를 저장하고 반복된 조회 요청을 빠르게 처리하는 고성능의 인메모리 저장소이

jam2in

최근 많은 기업들이 어플리케이션 아키텍처로서, 기존 모노리스 아키텍처 방식을 버리고 마이크로 서비스 아키텍처를 도입하면서 자연스럽게 소프트웨어의 운영 방식에도 많은 변화가 일어났습니다. 수많은 서비스들을 빠른 시간내에 배포하는 작업이 빈번히 요구되는 운영 환경 조건들을 충족해줄 수 있는 컨테이너 기술들이 인기가 많아짐에 따라 자연스레 분산 컨테이너 환경을 자동화할 수 있도록 돕는 대표적 오케스트레이션 툴인 Kubernetes를 점차 활용하고 있는 추세입니다. Kubernetes의 스케줄링, 스케일링, 자가 회복, 리소스 관리 등 어플리케이션 서비스의 운영 자동화를 위한 컨테이너 오케스트레이션 기술이 주는 이점은 무궁무진합니다. 하지만 기존 On-Premise 환경에 구동되고 있는 어플리케이션, 외부 솔루션들을 Kubernetes로 이전하기 위한 작업은 쉽지