인메모리 컴퓨팅
IT 위키
더 많은 작업
인메모리 컴퓨팅(IMC, In-Memory Computing)은 데이터를 디스크가 아니라 주기억장치(RAM)에 두고 저장·처리하여, 디스크 입출력 지연 없이 대량 데이터를 실시간으로 처리하는 컴퓨팅 방식이다.
전통적인 시스템은 데이터를 디스크에 두고 필요한 부분만 메모리로 읽어 처리하므로, 처리 시간의 대부분이 디스크 입출력에 쓰인다. 메모리 접근은 디스크보다 수천~수만 배 빠르다. 64비트 운영체제로 주소 공간 제약이 풀리고 메모리 가격이 내려가면서, 업무 데이터 전체를 메모리에 올려 두고 처리하는 것이 현실적인 선택이 되었다. 인메모리 컴퓨팅은 이렇게 메모리를 주 저장소로 삼는 데이터베이스, 데이터 그리드, 분석 엔진 등을 아우르는 말이다.
메모리 칩 안에서 연산을 수행하는 메모리 내 처리(PIM, Processing-In-Memory)와는 다른 개념이다. PIM 은 반도체 구조의 이야기이고, 인메모리 컴퓨팅은 데이터를 어디에 두고 처리하느냐는 소프트웨어 아키텍처의 이야기다.
| 유형 | 설명 | 예 |
|---|---|---|
| 인메모리 데이터베이스(IMDB, MMDB) | 데이터 전체를 메모리에 두는 DBMS. SQL 과 트랜잭션(ACID) 지원 | SAP HANA, Oracle TimesTen, Altibase, SQL Server In-Memory OLTP |
| 인메모리 데이터 그리드(IMDG) | 여러 서버의 메모리를 묶은 분산 키-값 저장소. 수평 확장 | Hazelcast, Apache Ignite, Oracle Coherence |
| 인메모리 분석·처리 엔진 | 중간 결과를 메모리에 두고 반복 연산 | 아파치 스파크 |
| 인메모리 캐시 | DB 앞단에 자주 쓰는 데이터를 둠 | Redis, Memcached |
| 인메모리 스트림 처리 | 유입 이벤트를 메모리에서 실시간 처리 | 복합 이벤트 처리(CEP) 엔진 |
데이터를 메모리에 두기만 하면 끝나는 것이 아니다. 메모리 용량은 디스크보다 작고 전원이 꺼지면 내용이 사라지므로, 인메모리 시스템은 다음 기법으로 데이터를 관리한다.
- 컬럼 기반 저장(Column Store) — 같은 컬럼의 값을 연속으로 저장한다. 집계·분석 질의에서 필요한 컬럼만 읽고, 값이 비슷해 압축률이 높다. 행 기반 저장은 한 건 단위의 갱신이 많은 OLTP 에 유리하므로 둘을 함께 두는 시스템이 많다.
- 압축 — 사전 인코딩(Dictionary Encoding), 런 길이 인코딩(RLE), 비트 패킹으로 메모리 사용량을 줄이고, 압축된 상태로 바로 연산한다.
- 메모리 최적화 자료구조 — 디스크 블록에 맞춘 B+트리 대신 캐시 라인에 맞춘 인덱스와 포인터 기반 구조를 쓴다. 버퍼 관리자가 필요 없다.
- 파티셔닝 — 데이터를 나누어 여러 코어·노드가 병렬 처리한다.
- 삽입 전용(Insert-only)·다중 버전 동시성 제어(MVCC) — 갱신을 새 버전 추가로 처리해 잠금 경합을 줄이고, 읽기와 쓰기가 서로 막지 않게 한다.
- 잠금 없는 구조(Lock-free/Latch-free) — 디스크 대기가 없으므로 잠금이 병목이 된다. 원자적 연산으로 경합을 없앤다.
- OLTP 와 OLAP 통합(HTAP) — 같은 데이터에서 트랜잭션과 분석을 동시에 처리해 별도 데이터웨어하우스로의 적재(ETL) 지연을 없앤다.
- SIMD·병렬 처리 — 컬럼 데이터를 벡터 명령으로 한꺼번에 처리한다.
모든 데이터를 메모리에 둘 수 없으면 자주 쓰는 데이터(Hot)는 메모리에, 덜 쓰는 데이터(Warm·Cold)는 SSD·디스크에 두고 접근 빈도에 따라 이동시킨다.
| 구분 | 디스크 기반 DBMS | 인메모리 DBMS |
|---|---|---|
| 주 저장소 | 디스크 (메모리는 버퍼 캐시) | 메모리 (디스크는 로그·백업) |
| 최적화 대상 | 디스크 입출력 횟수 | CPU 캐시 효율, 메모리 대역폭 |
| 인덱스 | 블록 단위 B+트리 | 메모리 최적화 인덱스 |
| 버퍼 관리 | 필요 | 불필요 |
| 응답 시간 | 밀리초 | 마이크로초 |
| 비용·용량 | 용량당 비용 낮음 | 용량당 비용 높음, 용량 제약 |
| 장애 회복 | 데이터 파일 기반 | 로그·스냅샷·복제로 재적재 필요(재시작 시간) |
- 실시간 결제·이체 승인, 증권 주문 체결, 실시간 이상거래 탐지(FDS), 실시간 리스크·한도 계산, 대고객 조회 부하 분산
- 원장(System of Record)은 기존 DBMS 에 두고, 고빈도 조회·계산 데이터를 IMDG 나 캐시에 올리는 캐시 계층형
- 원장까지 인메모리 DBMS 로 옮기는 전면 전환형
- 기존 DB 와 동기화는 Write-Through(동시 기록), Write-Behind(지연 기록), 변경 데이터 캡처(CDC)로 한다.
| 고려사항 | 대응 |
|---|---|
| 데이터 영속성 보장 | 동기식 로그 기록, 동기 복제, 무손실 회복 검증 |
| 가용성·재시작 시간 | 이중화·다중 노드 복제, 스냅샷 주기 최적화, 장애 전환 훈련 |
| 정합성 | 분산 환경의 트랜잭션 일관성, 원장 DB 와의 동기화 검증 |
| 용량 계획 | 데이터 증가율과 압축률을 반영한 메모리 산정, 계층화 |
| 비용 | 메모리·라이선스 비용과 성능 이득 비교 |
| 보안·규제 | 메모리 데이터 암호화, 접근 통제, 금융 규제의 백업·복구 요건 준수 |