웹 서비스를 위한 인메모리 아키텍처: 기술 기본 및 원칙

In-Memory란 데이터를 애플리케이션의 RAM에 저장할 때 데이터를 저장하고 디스크를 백업용으로 사용하는 개념의 집합입니다. 전통적인 접근 방식에서는 데이터가 디스크에 저장되고 메모리는 캐시에 저장됩니다. 예를 들어, 데이터 처리를 위한 백엔드가 있는 웹 애플리케이션은 이를 스토리지로 요청합니다. 이를 수신하고 변환하며 많은 데이터가 네트워크를 통해 전송됩니다. 인메모리에서는 계산이 데이터, 즉 스토리지로 전송되어 처리되고 네트워크의 부하가 줄어듭니다.

아키텍처 덕분에 In-Memory는 데이터 액세스 속도를 몇 배, 때로는 수십 배 더 빠르게 향상시킵니다. 예를 들어, 은행 분석가는 분석 애플리케이션에서 작년에 일별로 발행된 대출에 대한 보고서를 보고 싶어합니다. 이 프로세스는 기존 DBMS에서는 몇 분 정도 걸리지만 In-Memory에서는 거의 즉시 나타납니다. 이는 이 접근 방식을 통해 훨씬 더 많은 정보를 캐시할 수 있고 해당 정보가 "가까운" RAM에 저장되기 때문입니다. 응용 프로그램은 네트워크 및 디스크 속도에 따라 가용성이 제한되는 하드 드라이브에서 데이터를 요청할 필요가 없습니다.

In-Memory에는 어떤 다른 가능성이 있으며 이는 어떤 접근 방식입니까? 블라디미르 플리긴 - GridGain의 엔지니어. 이 리뷰 자료는 In-Memory를 사용해 본 적이 없고 시도해보고 싶거나 소프트웨어 개발 및 아키텍처 디자인의 최신 동향에 관심이 있는 웹 애플리케이션 백엔드 개발자에게 유용할 것입니다.

주의. 이 기사는 #GetIT Conf에서 Vladimir가 보고한 내용을 바탕으로 작성되었습니다. 자가 격리가 도입되기 전에 우리는 정기적으로 모스크바와 상트페테르부르크에서 개발자를 위한 모임과 컨퍼런스를 개최하여 동향, 현재 개발 문제, 문제 및 해결 방법을 논의했습니다. 지금은 컨퍼런스를 열 수 없지만, 지난 컨퍼런스에서 유용한 자료를 공유하는 시간이 되었습니다.

In-Memory를 사용하는 사람과 방법

In-Memory는 빠른 사용자 상호 작용이나 대량의 데이터 처리가 필요한 경우에 가장 자주 사용됩니다.

• 은행 예를 들어 고객이 애플리케이션을 사용할 때 지연을 줄이거나 대출을 발행하기 전에 고객을 분석하려면 In-Memory를 사용하세요.
• 사진 In-Memory를 사용하여 데이터 처리 및 분석을 아웃소싱하는 은행을 위한 서비스 및 애플리케이션의 성능을 향상시킵니다. 
• 보험 회사: 예를 들어 수년간의 고객 데이터를 분석하여 위험을 계산합니다.
• 물류회사. 예를 들어, 수천 개의 매개변수를 사용하여 화물 및 승객 운송을 위한 최적의 경로를 계산하고 배송 상태를 추적하기 위해 많은 데이터를 처리합니다.
• 소매. 인메모리 솔루션은 배송, 송장, 거래, 수천 개의 창고 내 상품 존재 여부, 분석 보고서 준비 등 고객에게 더 빠르게 서비스를 제공하고 대량의 정보를 처리하는 데 도움이 됩니다.
• В 만약 IoT 인메모리는 기존 데이터베이스를 대체합니다.
• 제약 예를 들어 기업에서는 In-Memory를 사용하여 약물 구성의 조합을 분류합니다. 

고객이 인메모리 솔루션을 사용하는 방법과 이를 직접 구현하는 방법에 대한 몇 가지 예를 말씀드리겠습니다.

인메모리를 기본 스토리지로 사용

우리 고객 중 한 명은 미국의 대규모 의료 과학 장비 공급업체입니다. 그들은 In-Memory 솔루션을 주요 데이터 저장소로 사용합니다. 모든 데이터는 디스크에 저장되며, 활발하게 사용되는 데이터의 하위 집합은 RAM에 보관됩니다. 저장소 액세스 방법은 GDBC(Generic Database Connector) 및 SQL 쿼리 언어 등 표준입니다.

이를 통칭하여 IMDB(In-Memory Database) 또는 메모리 중심 저장소라고 합니다. 이 솔루션 클래스에는 많은 이름이 있으며 이것이 유일한 이름은 아닙니다. 

IMDB 기능:

• In-Memory에 저장되고 SQL을 통해 액세스되는 데이터는 다른 접근 방식과 동일합니다. 동기화되어 있으며 표시 방식과 처리 방식만 다릅니다. 트랜잭션은 데이터 간에 작동합니다.

• IMDB는 디스크보다 RAM에서 정보를 검색하는 것이 더 빠르기 때문에 관계형 데이터베이스보다 빠릅니다. 
• 내부 최적화 알고리즘에는 지침이 더 적습니다.
• IMDB는 애플리케이션의 데이터, 이벤트 및 트랜잭션을 관리하는 데 적합합니다.

IMDB는 ACID(원자성, 일관성 및 격리)를 부분적으로 지원합니다. 그러나 "내구성"을 지원하지 않습니다. 전원이 꺼지면 모든 데이터가 손실됩니다. 문제를 해결하려면 스냅샷(하드 드라이브의 데이터베이스 백업과 유사한 데이터베이스의 "스냅샷")을 사용하거나 트랜잭션(로그)을 기록하여 재부팅 후 데이터를 복원할 수 있습니다.

내결함성 응용 프로그램을 만들려면

내결함성 웹 애플리케이션의 고전적인 아키텍처를 상상해 봅시다. 이는 다음과 같이 작동합니다. 모든 요청은 웹 밸런서를 통해 서버 간에 분산됩니다. 이 시스템은 서버가 서로 중복되어 만일의 사태에 대비해 백업을 하기 때문에 안정적이다.

밸런서는 한 세션의 모든 요청을 하나의 서버로 엄격하게 전달합니다. 이는 스틱 세션 메커니즘입니다. 각 세션은 로컬에 저장되고 처리되는 서버와 연결됩니다. 

서버 중 하나에 장애가 발생하면 어떻게 되나요?

아키텍처가 중복되므로 서비스는 영향을 받지 않습니다. 그러나 우리는 죽은 서버 세션의 일부를 잃게 될 것입니다. 그리고 동시에 이러한 세션에 연결된 사용자도 있습니다. 예를 들어, 고객이 주문을 하고 갑자기 그를 사무실 밖으로 쫓아냅니다. 그는 다시 로그인하여 모든 작업을 다시 수행해야 한다는 사실을 알게 되면 기분이 좋지 않을 것입니다.

웹 애플리케이션은 많은 수의 사용자를 지원해야 하며, 그들이 편안하게 작업할 수 있도록 속도를 늦추지 않아야 합니다. 그러나 거부되면 후속 요청이 있을 때마다 세션 저장소와 통신하는 데 걸리는 시간이 늘어납니다. 이로 인해 다른 사용자의 평균 대기 시간이 늘어납니다. 하지만 그들은 예전보다 더 오래 기다리고 싶어하지 않습니다.

이 문제는 미국의 대규모 PASS 제공업체인 다른 고객처럼 해결될 수 있습니다. In-Memory를 사용하여 웹 세션을 클러스터링합니다. 이를 위해 로컬이 아닌 중앙의 In-Memory 클러스터에 저장합니다. 이 경우 세션은 이미 RAM에 있으므로 훨씬 더 빠르게 사용할 수 있습니다.

서버가 충돌하면 밸런서는 클래식 아키텍처에서와 같이 충돌한 서버에서 다른 서버로 요청을 보냅니다. 그러나 중요한 차이점이 있습니다. 세션은 In-Memory 클러스터에 저장됩니다. 서버는 타락한 서버의 세션에 액세스할 수 있습니다.

이 아키텍처는 전체 시스템의 내결함성을 높입니다. 게다가 스틱 세션 메커니즘을 완전히 포기하는 것도 가능합니다.

하이브리드 트랜잭션 분석 처리(HTAP)

일반적으로 트랜잭션 시스템과 분석 시스템은 별도로 유지됩니다. 분리되면 메인 베이스에 부하가 걸립니다. 분석 처리의 경우 분석 처리가 트랜잭션 프로세스를 방해하지 않도록 데이터가 복제본에 복사됩니다. 그러나 복사에는 지연이 발생합니다. 지연 없이 복제하는 것은 불가능합니다. 이 작업을 동시에 수행하면 기본 베이스도 느려지고 승리할 수 없습니다.

HTAP에서는 모든 것이 다르게 작동합니다. 동일한 데이터 저장소가 애플리케이션의 트랜잭션 로드와 완료하는 데 오랜 시간이 걸릴 수 있는 분석 쿼리에 사용됩니다. 데이터가 RAM에 있으면 분석 쿼리가 더 빠르게 실행되고 데이터베이스가 있는 서버의 로드가 (평균적으로) 줄어듭니다.

하이브리드 접근 방식은 트랜잭션 처리와 분석 사이의 벽을 허물어줍니다. 동일한 스토리지에서 분석을 수행하면 RAM의 데이터에 대해 분석 쿼리가 실행됩니다. 훨씬 더 정확하고 해석하기 쉽고 적절합니다.

인메모리 솔루션 통합

(상대적으로) 간단한 방법 - 모든 것을 처음부터 개발하다. 우리는 데이터를 디스크에 보관하고 핫 데이터를 메모리에 저장합니다. 이는 서버 재부팅이나 중단 시에도 살아남는 데 도움이 됩니다.

데이터가 디스크에 저장될 때 작동하는 두 가지 주요 시나리오가 있습니다. 첫 번째로 우리는 클러스터 또는 부품의 충돌이나 정기적인 재부팅이 발생하더라도 살아남기를 원합니다. 이를 간단한 데이터베이스로 사용하려고 합니다. 두 번째 시나리오에서는 데이터가 너무 많으면 그 중 일부가 메모리에 남아 있습니다.

처음부터 모든 것을 구축하는 것이 불가능하다면 In-Memory를 이미 기존 아키텍처. 그러나 모든 In-Memory 솔루션이 이에 적합한 것은 아닙니다. 세 가지 필수 조건이 있습니다. 인메모리 솔루션은 다음을 지원해야 합니다.

• 아래에 위치할 데이터베이스(예: MySQL)에 연결하는 표준 방법입니다.
• 스토리지와의 상호 작용 논리를 다시 작성하거나 변경하지 않는 표준 쿼리 언어;
• 트랜잭션 - 상호 작용의 의미를 보존합니다.

세 가지 조건이 모두 충족되면 통합이 가능합니다. 우리는 애플리케이션과 데이터베이스 사이에 In-Memory Data Grid를 배치합니다. 이제 쓰기 요청은 기본 데이터베이스에 위임되고, 데이터가 캐시에 없는 경우 읽기 요청은 기본 데이터베이스에 위임됩니다.

예를 들어 비즈니스 분석 등을 위해 데이터에 대한 빠른 액세스 및 처리가 중요한 경우 In-Memory 구현을 고려해 볼 수 있습니다. 구현을 위해 새 아키텍처를 설계할 때 두 가지 방법을 모두 사용할 수 있습니다.

출처 : habr.com