[한글화 프로젝트] 8.인피니스팬

인피니스팬

번역: JBUG 이 글은 The Performance of Open Source Application 도서의 Infinispan 챕터를 번역한 것입니다. 원저자는 Manik Surtani이며 원문은 아래 원문링크를 클릭하시면 보실 수 있습니다. 원문링크

 

소개

인피니스팬(주1)은 오픈소스 데이터그리드 플랫폼이자 분산 인메모리 키/밸류 NoSQL 스토어이다. 소프트웨어 아키텍트는 보통 인피니스팬 등의 데이터그리드를 관계형 데이터베이스 같은 느린 데이터 저장소 앞단에 두어 성능 확장 목적의 분산 인메모리 캐시로 사용하거나 또는 관계형 데이터베이스를 대체하려는 목적으로 분산 NoSQL로써 사용한다. 어떤 경우든지 소프트웨어 아키텍처에서 데이터그리드를 도입하려는 주요 이유는 성능이다. 지연 시간 없이 빠르게 데이터에 접근하고자 하는 필요성은 급속도로 증가하고 있다. 그래서, 성능은 인피니스팬의 유일한 존재 이유이다. 인피니스팬 기반 코드는 극도로 성능 위주로 되어 있다.

 

개요

인피니스팬을 깊게 다루기 전에 인피니스팬을 일반적으로 어떻게 사용하는지 살펴보자. 인피니스팬은 미들웨어라는 소프트웨어 분류에 속한다. 위키피디아에 따르면 미들웨어는 웹사이트와 운영체제 혹은 데이터베이스 같은 애플리케이션 사이에 있는 서버상의 컴포넌트로 "소프트웨어 접착체로 설명될 수 있다". 미들웨어는 때때로 애플리케이션 개발자가 더 생산적이고 더 효율적이며 빠르게 유지보수와 테스트가 용이한 애플리케이션을 만들기 위해 사용된다. 이 모든 것들은 모듈화와 컴포넌트 재사용에 의해 이루어진다. 인피니스팬은 특히 애플리케이션이 수행하는 비즈니스 로직과 데이터 스토리지 계층 사이에 주로 위치한다. 데이터 저장과 읽기는 흔한 최대의 병목 구간이고 데이터베이스 앞에 인메모리 데이터그리드를 위치하는 것은 속도를 훨씬 빠르게 한다. 게다가 데이터 저장소는 때때로 잠재된 단일 장애점(a single point of potential failure)이다. 다시 말해, 인피니스팬을 기존의 데이터 저장소 앞에 둔다면 (또는 대체한다면) 애플리케이션은 훌륭한 탄력성(elasticity)과 확장성(scalability)을 갖게 된다.

 

누가 인피니스팬을 사용하는가?

인피니스팬은 텔레콤, 금융, 전자상거래, 제조, 게임과 모바일 플랫폼 등 많은 산업 분야에서 사용되고 있다. 데이터그리드는 대개 금융산업에서 많이 사용되어 왔는데 이는 개별 장비의 장애로부터 영향받지 않으면서 대용량 데이터에 대한 극도로 빠른 접근이라는 엄격한 요구사항 때문이었다. 이런 요구사항은 다른 산업으로 퍼졌고 인피니스팬이 다양한 분야의 애플리케이션에서 대중화 되는 데 일조했다.

 

라이브러리 또는 서버

인피니스팬은 자바(그리고 약간의 스칼라)로 구현되었고 두 가지 다른 방법으로 사용된다. 첫째는 라이브러리로 사용하는 것이다. 애플리케이션에 인피니스팬 JAR 파일을 포함하여 인피니스팬 컴포넌트를 프로그램 안에서 참조하고 인스턴스화하여 사용하게 된다. 이 경우에 인피니스팬 컴포넌트가 애플리케이션과 같은 JVM 위에 있고 애플리케이션 힙 메모리의 한 부분이 데이터그리드 노드에 할당된다.

 

그림1 인피니스팬을 라이브러리로 사용

 

두 번째로 여러 개의 인피니스팬 인스턴스를 시작하고 클러스터를 만들어서 원격 데이터그리드로써 사용할 수 있다. 클라이언트 라이브러리들이 이미 많이 존재하고 클라이언트는 소켓 연결로 클러스터에 접속하게 된다. 이 방법은 각각의 인피니스팬 노드가 자신의 독립된 JVM 위에 존재하고 전체 JVM 힙 메모리를 자신이 직접 사용하게 된다.

 

그림2 인피니스팬을 원격 데이터그리드로 사용

 

피어투피어(peer-to-peer) 아키텍처

위의 두 가지 모두 인피니스팬 인스턴스는 네트워크 너머 서로를 감지하고 클러스터를 구성하며 클러스터 내 모든 서버들 위에 투명하게 펼쳐진 인메모리 데이터 구조를 애플리케이션에 제공하여 데이터를 공유하게 된다. 클러스터에 노드를 추가하면 총 용량이 증가하며 이는 애플리케이션이 이론적으로는 무한대의 인메모리 저장소를 가지게 됨을 의미한다.

 

인피니스팬은 피어투피어 기술을 사용하며 클러스터 내 각 인스턴스는 다른 모든 인스턴스와 동등하다. 이것은 단일 장애점이 없다는 것과 단일 병목 구간이 없다는 것을 의미한다. 가장 중요한 것은 여러 인스턴스들을 추가함에 따라 수평적으로 확장(scale out)하는 탄력적인 데이터 구조를 제공한다는 것이다. 그리고 몇몇 인스턴스를 중단하는 축소(scale back in)도 역시 가능한데, 이 모든 것이 기능 손실 없이 애플리케이션이 지속적으로 동작하는 중에 이루어진다.

 

인피니스팬 벤치마킹

인피니스팬 같은 분산 데이터 구조를 벤치마킹하는 데 있어서 가장 큰 문제는 도구들을 다루는 것이다. 확장(scale out) 또는 축소(scale back in)되는 동안 데이터를 저장하고 가져오는 성능을 측정하는 도구는 극 소수이다. 그리고 설정과 클러스터 크기가 다를 때 성능을 측정하거나 비교를 가능케 하는 비교 분석을 제공하는 것은 없다. 이를 위해 레이더건이 만들어졌다.

 

레이더건은 다음 링크(http://aosabook.org/en/posa/infinispan.html#posa.infinispan.radargun)에서 자세한 설명을 볼 수 있다. 야후 클라우드 서빙 벤치마크(Yahoo Cloud Serving Benchmark), 그라인더(The Grinder), 아파치의 제이미터(Apache JMeter) 같은 다른 도구들은 인피니스팬을 벤치마킹하는 데 여전히 매우 중요하지만 많이 다루지는 않을 것이다. 이미 이들에 대한 설명이 인터넷에 많이 있기 때문이다.

 

레이더건(Rader Gun)

레이더건(주2)은 오픈소스 벤치마킹 프레임워크로써 밴치마크 수행(comparative and competitive), 확장성 측정, 데이터가 수집될 때부터의 보고서 생성을 위해 설계되었다. 레이더건은 특별히 인피니스팬 같은 분산 데이터 구조를 타깃으로 했고 인피니스팬 개발 시 병목 부분을 확인하고 해결하는 데 많이 쓰였다. 레이더건을 위한 더 많은 정보는 다음 링크(http://aosabook.org/en/posa/infinispan.html#posa.infinispan.radargun)를 확인하면 된다.

 

야후 클라우드 서빙 벤치마크

야후 클라우드 서빙 벤치마크(The Yahoo Cloud Serving Benchmark, YCSB)(주3)는 오픈소스 도구이고 원격 데이터 스토어가 다양한 크기의 데이터를 읽고 쓰려고 통신할 때 그 레이턴시를 테스트 하기위해 만들어졌다. YCSB는 모든 데이터 스토어를 단일한 원격 지점으로 다룬다, 그래서 노드가 클러스터에 추가되거나 지워지는 것과 같은 확장을 측정하지는 않는다. YCSB는 분산 데이터 구조에 대한 개념이 없고 클라이언트/서버 모드의 인피니스팬을 벤치마크할 때만 유용하다.

 

그라인더와 아파치 제이미터

그라인더(The Grinder)(주4)와 아파치 제이미터(Apache JMeter)(주5)는 각각 단순한 오픈소스 부하 생성기이며 소켓을 열고 기다리는 서버들을 테스트하는 데 사용한다. 이들은 스크립트로 사용 가능하며 YCSB와 같이 인피니스팬이 클라이언트/서버 모드로 사용될 경우를 벤치마킹하기 위해 쓴다.

 

레이더건

초기

인피니스팬 코어 개발팀에 의해 만들어진 레이더건은 캐시 벤치마킹 프레임워크(Cache Benchmarking Framework)(주6)라 불리는 소스포지(Sourceforge)의 프로젝트로 출발하였고 원래는 여러 가지 모드와 다양한 설정으로 실행하고 있는 내장 자바 캐시를 벤치마크하기 위한 목적으로 설계되었다. 비교도 가능하도록 만들어졌기 때문에 다양한 캐시 라이브러리에 대해 같은 벤치마크를 실행하거나 성능 회귀테스트를 위해 동일한 라이브러리의 여러 버전에 대해 테스트를 자동적으로 실행하곤 한다. 만들어지고 나서 레이더건이라는 새로운 이름을 얻었고 깃허브에 새로운 둥지(http://github.com/radargun)를 틀었다.

 

분산 기능

레이더건은 곧 분산 데이터 구조를 다루도록 확장되었다. 여전히 내장 라이브러리 테스트에 중점을 두었으며 분산 캐시 라이브러리의 인스턴스들이 올라갈 여러 서버에 복수개의 인스턴스를 띄울 수 있었다. 벤치마크는 클러스터의 각 노드에서 병렬적으로 실행되었다. 결과가 수집되고 레이더건 컨트롤러에 의해 보고서가 생성되었다. 확장성을 테스트하기 위해 자동으로 노드를 올리고 내리는 기능은 필수적인데, 수백 개 심지어 수천 개의 노드의 다양한 크기의 클러스터를 벤치마크하기 위해 수동으로 실행, 재실행하는 것은 불가능하고 비현실적이다.

 

그림3 레이더건

 

빠르지만 틀리다면 좋지 않다!

그 이후에 레이더건은 벤치마크의 각 단계를 실행하기 전후에 상태 확인을 수행하여 클러스터가 여전히 유효한 상태인지 확인하는 기능을 얻는다. 이것은 잘못된 결과를 미리 감지하게하고 많은 시간이 걸릴 수 있는 하나의 테스트 실행이 끝났을 때 수동 처리를 기다리지 않고 벤치마크를 재수행하도록 한다.

 

프로파일링

레이더건은 또한 프로파일링을 위한 인스턴스를 시작하여 각 데이터그리드 노드에 붙일 수 있고 프로파일러 스냅샷을 생성하여 부하 아래에서 각각의 노드가 어떠한지 살펴보게 한다.

 

메모리 성능

레이더건은 또한 각노드의 메모리 소비 상태와 메모리 성능을 측정할 수 있는 기능이 있다. 인메모리 데이터 스토어에서 성능은 얼마나 빠르게 데이터를 읽고 쓰느냐만이 아니라 얼마나 잘 메모리 소비를 고려하면서 수행하는가도 포함된다. 이는 자바기반 시스템에서 실제로 중요한데 가비지 컬렉션이 시스템 응답도에 불리한 영향을 끼칠 수 있기 때문이다. 가비지 컬렉션은 뒤에 더 자세히 다룬다.

 

메트릭(Metrics)

레이더건은 성능을 초당 트랜잭션 수로 측정한다. 이는 각 노드에서 포착되고 나서 컨트롤러에서 합해진다. 읽기와 쓰기 모두 측정되고 그 둘이 동시적으로 수행되지만 차트에는 별도로 표시된다. 레이더건은 읽기/쓰기 트랜잭션에 대한 평균값, 중앙값, 표준편차, 최대값, 최소값도 얻는다. 이들은 차트에 표시되지 않더라도 로그에는 남는다. 메모리 성능 역시 측정되는데 이는 주어진 순회(iteration)의 풋프린트를 통해 이루어진다.

 

확장성

레이더건은 확장 가능한 프레임워크이다. 고유의 데이터 엑세스 패턴, 데이터 타입과 크기를 끼워 넣을 수 있다. 나아가서 테스트하고자 하는 어떤 데이터 구조, 캐시 라이브러리나 NoSQL 데이터베이스에 대한 어댑터를 추가하는 것도 허용한다.

 

주요 의심점들

성능 병목을 가져오는 주요 의심점들이라 여겨지고 그래서 밀접한 조사와 잠재적으로 최적화의 후보가 되는 몇 가지 인피니스팬 서브시스템이 있다. 차례로 살펴보자.

 

네트워크

네트워크 통신은 인피니스팬 최고의 비용이 드는 부분으로 피어간 또는 클라이언트와 그리드 사이의 통신하는 데 사용된다.

 

피어 네트워크

인피니스팬은 노드 간 통신을 위해 오픈소스 피어투피어 그룹 통신 라이브러리인 제이그룹스(JGroups)(주7)를 사용한다. 제이그룹스는 TCP 또는 UDP 네트워크 프로토콜과 UDP 멀티캐스트를 이용하며 메시지 전달 보증, 재전송, 메시지 순서 배열과 같은 고수준 기능을 제공하며 이를 UDP같은 비신뢰적인 프로토콜 위에서도 가능케 한다.

 

제이그룹스를 네트워크와 애플리케이션의 성격에 부합하도록 time-to-live, 버퍼 크기, 스레드 풀 크기 등을 올바르게 설정을 조정하는 것은 결정적으로 중요하다. 또한 대량의 메시지가 여러 개의 작은 네트워크 패킷으로 쪼개질 때 제이그룹스가 번들링(bundling, 여러 작은 메시지를 단일 네트워크 패킷으로 조합하는 것)이나 프래그맨테이션(fragmentation, 역번들링)을 수행하는 방법을 아는 것도 또한 중요하다.

 

각 운영체제나 네트웍 장비(스위치, 라우터)의 네트워크 스택은 이런 설정에 맞게 조정되어야 한다. 운영체제의 TCP 송수신 버퍼 크기, 프레임 크기, 점보 프레임 등 이 모두가 데이터그리드 내의 최고 비용 컴포넌트가 효율적으로 동작하도록 하기 위해 각자의 역할을 한다.

 

netstat나 wireshark 같은 도구도 패킷 분석에 도움이 된다. 레이더건은 그리드에 부하를 걸 수 있다. 레이더건은 또한 병목 지점을 찾기 위해 인피니스팬의 제이그룹스 계층을 프로파일하는 데도 쓰인다.

 

서버 소켓

인피니스팬은 서버소켓을 생성하고 관리하기 위해 잘 알려진 네티 프레임워크(Netty)(주8)를 이용한다. 네티는 비동기 자바 NIO 프레임워크를 사용하며 운영체제의 비동기 네트웍 I/O 기능을 이용한다. 이는 몇몇 컨텍스트 스위칭 비용을 위해 리소스를 효율적으로 사용하게 한다. 보통 이는 부하가 걸리는 상황에서 매우 잘 동작한다. 

네티는 최적 성능을 내기 위해 여러 계층의 튜닝점을 제공한다. 버퍼 크기, 스레드 풀 같은 것을 포함한 이 값들은 운영체제의 TCP 송수신 버퍼와 잘 맞추어져야 한다.

 

데이터 직렬화

네트워크로 데이터를 전송하기 전에 애플리케이션 객체는 바이트로 직렬화(serialization)되고, 그리고 나서 데이터그리드로, 또 네트워크 너머 다른 노드로 보내진다. 바이트는 애플리케이션에 읽혀질 때 다시 객체로 역직렬화된다. 가장 일반적인 설정에서 약 20%의 시간이 요청을 직렬화와 역직렬화하는 데 사용된다. 

기본 자바 직렬화(역직렬화)는 악명 높을 정도로 느리고 변환된 바이트도 때때로 불필요하게 큰데 이는 네트워크로 더 많은 데이터를 보내야 한다는 말이다.

 

인피니스팬은 자체 직렬화를 사용하는 데 모든 클래스 정의가 스트림으로 쓰이지 않는다. 알려진 타입에 대해 각 타입이 한 바이트로 대표되는 마법의 숫자를 사용한다. 이는 직렬화, 역직렬화의 속도를 빠르게 할 뿐 아니라 네트워크 간 전송될 바이트 스트림을 훨씬 작게 한다. 하나의 Externalizer가 각각의 알려진 데이터 타입과 그 마법 숫자에 대해 등록되는데 이 Externalizer는 객체를 바이트로 또는 역으로 전환하는 로직을 포함한다.

 

이 테크닉은 각 노드끼리 교환되는 인피니스팬 내부 객체 같이 알려진 타입들에 대해 매우 잘 동작한다. 커맨드(commands)나 엔벨로프(envelopes) 등의 내부 객체는 externalizer와 대응되는 고유한 마법 숫자를 가지고 있다. 애플리케이션 객체는 어떨까. 기본적으로 인피니스팬이 알지 못하는 객체 타입을 마주친다면 그때는 기본적인 자바 직렬화를 사용하게 된다. 이것은 알려지지 않은 애플리케이션 객체 타입을 다루는 방법에 있어 약간 비효율적이긴 하지만 인피니스팬이 설치 후 별다른 설정 없이 바로 사용 가능하도록 한다.

 

이 문제를 피하기 위해 인피니스팬은 애플리케이션 개발자가 애플리케이션 데이터 타입을 위해서 externalizer를 등록하는 것을 허용한다. 애플리케이션 개발자가 각 애플리케이션 객체 타입에 대해 externalizer를 구현하고 등록할 경우, 강력하고 빠르고 효율적인 애플리케이션 객체 직렬화를 가능하게 한다.

 

이 externalizer 코드는 JBoss Marshalling(주9)이라는 별도의 재사용 가능한 라이브러리로 발표되었다. 이 라이브러리는 인피니스팬에 통합되어 있고 함께 배포되며 직렬화 성능을 높이기 위한 다른 여러 오픈소스 프로젝트에 의해 쓰이기도 한다.

 

디스크에 쓰기

인피니스팬은 메모리 위의 데이터 구조이기도 하지만 선택적으로 디스크에 영속화도 한다.

 

영속성(persistence)은 내구성(durability)을 위하거나─메모리에 있는 모든 데이터가 디스크에 역시 존재하므로 노드의 재시작이나 장애에도 살아남음─ 또는 메모리가 가득 찼을 때 넘치도록 설정된다. 마치 운영체제가 디스크로 페이징하는 것과 비슷한 방법으로 행동한다. 후자에서, 데이터는 메모리 공간을 확보하고자 데이터가 메모리로부터 제거될 때 디스크에 쓰여진다. 

 

내구성을 위해 영속성을 사용할 때, 영속성은 온라인(애플리케이션 스레드는 데이터가 디스크에 안전하게 쓰여질 때까지 대기한다) 또는 오프라인(데이터가 주기적/비동기적으로 디스크로 보내진다)이다. 후자의 경우, 애플리케이션 스레드는 영속성 처리를 위해 대기하지는 않지만 데이터가 디스크에 완전히 성공적으로 저장되었는지 확실하지 않다는 반대 급부가 있다.

 

인피니스팬은 여러 개의 캐시스토어(데이터를 디스크 또는 다른 2차 저장소에 저장할 수 있는 어댑터)를 추가하는 것이 가능하다. 현재 기본 구현체는 간단한 해시 저장 공간과 링크드리스트 구현체인데 각 해시 저장 공간은 파일시스템의 파일이다. 사용하기도 설정하기도 쉬운 반면에 최고 성능의 구현체는 아니다.

 

두 가지 고성능의 파일시스템 네이티브 캐시스토어 구현체가 로드맵 상에 있다. 둘 다 C로 쓰여지고 유닉스 시스템 위에서와 같이 가능한 경우에는 다이렉트 I/O를 사용하여 커널 버퍼와 캐시를 우회한다. 구현체 중 하나는 페이징 시스템 같은 용도에 최적화 될 것이며 랜덤 엑세스와 아마도 b-tree 구조를 갖게 될 것이다. 다른 하나는 내구성 있는 저장소로 최적화될 것이다 메모리에 저장된 것을 복제하게 될 것이다. 그래서 추가 전용 구조로 빠른 쓰기가 필요하지만 빠른 읽기와 찾기는 필요 없는 상황에 맞게 설계될 예정이다.

 

동기화, 잠금, 동시성

대부분의 기업용 미들웨어가 그렇듯이 인피니스팬도 현대의 멀티코어 시스템에 많은 관심을 두고 있다. 멀티코어의 SMP 시스템 내의 다수의 하드웨어 스레드뿐만 아니라 네트워크나 디스크와 통신 시 비블로킹, 비동기 I/O를 가능하도록 한 병행성을 이용하기 위해 인피니스팬의 핵심 데이터 구조는 공유 데이터 동시 접근을 위한 소프트웨어 트랜잭션 메모리 테크닉을 사용한다. 이는 명시적 잠금, 뮤텍스와 다른 형식의 동기화, 공유 데이터를 갱신 시 정확성을 체크하기 위해 비교하고 저장하는 연산 같은 테크닉을 최소화하게 한다. 그런 기술들은 멀티코어 SMP 시스템에서 CPU 사용률을 향상시킨다는 것이 증명되었고 코드의 복잡성이 증가함에도 부하 시의 성능에 기대했던 성과를 올렸다. 

소프트웨어 트랜잭션 메모리 접근을 사용하는 장점에 더해서 이는 하드웨어 트랜잭션 메모리 접근을 지원하는 CPU가 나왔을 때 최소한의 인피니스팬 설계 변경만으로 동기화를 더 강화할 수 있다는 점에서 미래 경쟁력이 된다.

 

인피니스팬이 사용하는 몇 가지 데이터 구조는 학술 논문에서 바로 나왔다. 사실, 인피니스팬의 비블로킹, 비잠금 데크(lock-free dequeue)(주10)는 그 최초의 자바 구현체이다. lock amortization(주11)과 adaptive eviction policies(주12)도 비슷한 예이다.

 

스레드와 문맥 전환

인피니스팬의 여러 서브시스템은 별도 스레드에서 비동기로 동작한다. 예를 들어 제이그룹스는 네트워크 소켓을 모니터하는 스레드를 만들어 메시지를 디코드하고 그것들을 메시지 전달 스레드로 보낸다. 이는 역시 비동기적이고 별도 스레드를 사용하게 되는 디스크 캐시스토어에 데이터를 저장하는 시도가 되기도 한다. 리스너는 변경에 대한 통지를 받게 되고 이 역시 비동기적으로 설정된다. 

이런 비동기 작업을 위한 스레드 풀을 다룰 때는 항상 문맥 전환(context switch) 오버헤드가 있다. 스레드는 적은 비용의 리소스가 아니라는 것은 언급할 가치가 있다. 잘 설정되고 적절한 크기의 스레드 풀은 인피니스팬의 비동기 기능 어떤 것을 사용하든지 매우 중요하다. 

특별히 주의해서 봐야할 영역은 (비동기 통신을 사용한다면) 비동기 전송 스레드풀이고, 최소한 각 노드가 동시에 처리할 것으로 예상하는 업데이트 수만큼의 스레드 풀을 확보하는 것이다. 비슷하게 제이그룹스를 튜닝할 때 OOB(주13)와 incoming 스레드 풀은 적어도 동시적으로 업데이트가 예상되는 수만큼은 커야 한다.

 

그림4 인피니스팬에서 스레드 사용

 

가비지 컬렉션

JVM 가비지 컬렉터에 관해 일반적으로 좋은 습관을 가지는 것은 모든 자바 기반 소프트웨어에 중요한 고려사항이고 인피니스팬도 예외가 아니다. 예외가 있다면 그것은 데이터그리드에 더 중요하다. 특정 동작 또는 트랜잭션 시에 일시적인 객체가 많이 생성되는 오랜 기간 동안 컨테이너 객체는 살아있어야 할 것이다. 그리고, 가비지 컬렉션의 정지 시간은 분산 데이터 구조에는 부정적인 효과를 갖게 되어서 노드가 응답하지 않고 장애 상태로 여겨지게 한다.

 

인피니스팬을 설계하고 만들 때 이것을 고려했다. 하지만 동시에 인피니스팬을 실행하도록 JVM을 설정할 때에도 많은 고려사항이 있다. 각 JVM은 다르다. 인피니스팬이 실행될 때 어떤 JVM에 어떤 최적값들을 설정할지 몇몇 분석이 있다. 예를들면 만약 OpenJDK(주15) 또는 오라클의 HotSpot JVM(주16)을 사용하고, JVM Concurrent Mark와 Sweep collector(주17)를 대용량의 페이지(주18)와 함께 사용할 때 각 JVM에 대해 12G 힙메모리가 가장 효율적인 것으로 보인다.

 

Azul's Zing JVM(주20)에서 사용되는 C4(주19)같은 무정지 가비지 컬렉터를 사용하는 것도 가비지 컬렉터로 인한 정지가 큰 이슈가 되는 곳에서는 고려해볼 만하다.

 

결론

인피니스팬 같은 성능 중심의 미들웨어는 모든 단계에서 성능을 고려하여 설계, 개발, 구성되어야 한다. 최선의 비블로킹, 비잠금 알고리즘을 사용하는 것으로부터, 만들어지는 가비지들의 성격을 이해하고 JVM 문맥 변경에 대한 적절한 설정을 알아내고 필요할 때는 (예를들어 네이티브 영속 저장소를 작성하는 것과 같이) JVM 밖에서 문제를 해결할 수 있는 정도까지, 모두 인피니스팬을 개발할 때 필요한 중요한 사고방식이다. 게다가 벤치마킹, 프로파일링 외에도 지속적인 통합 상황에서 벤치마킹을 수행할 수 있는 적절한 도구는 기능 추가에 따른 성능 희생을 만들지 않도록 도움을 준다.

 

 

1. Http://www.infinispan.org

2. Https://github.com/radargun/radargun/wiki

3. Https://github.com/brianfrankcooper/YCSB/wiki

4. Http://grinder.sourceforge.net/

5. Http://jmeter.apache.org/

6. Http://sourceforge.net/projects/cachebenchfwk/

7. Http://www.jgroups.org

8. Http://www.netty.io

9. Http://www.jboss.org/jbossmarshalling

10. Http://www.md.chalmers.se/~tsigas/papers/Lock-Free-Deques-Doubly-Lists-JPDC.pdf

11. Http://dl.acm.org/citation.cfm?id=1546683.1547428

12. Http://dl.acm.org/citation.cfm?id=511334.511340

13. Http://www.jgroups.org/manual/html/user-advanced.html#d0e3284

14. Http://howtojboss.com/2013/01/08/data-grid-performance-tuning/

15. Http://openjdk.java.net

16. Http://www.oracle.com/technetwork/java/javase/downloads/index.html

17. Http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#cms

18. Http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html

19. Http://www.azulsystems.com/technology/c4-garbage-collector

20. Http://www.azulsystems.com/products/zing/virtual-machine