Keycloak Infinispan 통신 방식 정리: udp, jdbc-ping, kubernetes

 

배경

keycloak은 여러 instance간 infinispan cache를 통해 세션 정보 등을 동기화한다. 그리고 이런 동기화에 쓰일 통신의 스택 정보를 KC_CACHE_STACK 옵션을 통해 설정할 수 있다.

 

https://www.keycloak.org/server/caching#_transport_stacks

 

 

26.0.1 버전까지 udp가 기본 스택이였으나 26.2.1로 버전업을 하면서 jdbc-ping 방식이 default로 변경되었다고 한다. 어짜피 k8s 환경이라 kubernetes 스택을 사용하고 있었는데, 이번 기회에 정리를 좀 하고 가야겠다는 생각이 들었다.

 

 

각 방식별 특징

 

1. UDP

UDP는 보통 네트워크에서 TCP/UDP로 OSI 7 Layer 개념에서 4 Level Layer로 알려진 방식이다. TCP 대비 직접 연결이 없고 순서가 보장되지 않으며 전송 속도가 빠른 것으로 알고 있다. keycloak에서 udp로 처리하면, 서로의 인스턴스를 서치할 때 멀티캐스트를 날려서 찾는다. 다시 말해 브로드캐스팅을 하여 다른 인스턴스를 찾는 방식인데 AWS나 k8s 모두에서 이러한 브로드캐스팅이 일반적으로 비활성화 되어있다. 아마 그래서 이번 업데이트에서 udp 방식을 deprecated 처리하지 않았나 싶다.

 

2. jdbc-ping

이번 업데이트에서 default 값으로 설정된 방식이다. 이 방식은 공유 데이터베이스에 노드 및 인스턴스 정보를 저장한다. 각 노드가 DB를 조회하여 클러스터의 구성원을 파악하는 방식이다. 엄청나게 대규모라면 DB에 부하를 줄 수도 있겠다.

 

멀티캐스트가 불가능한 kubernetes 등의 환경에서 주로 이용한다. TCP 통신을 하고,  DB에는 인스턴스 자신의 IP, 포트 정보를 insert하고 노드가 종료되거나 TTL이 넘게되면 정보를 삭제한다.

 

예시

CREATE TABLE JGROUPSPING (
    own_addr VARCHAR(200) NOT NULL,
    cluster_name VARCHAR(200) NOT NULL,
    ping_data BYTEA,
    timestamp BIGINT,
    PRIMARY KEY (own_addr, cluster_name)
);


INSERT INTO JGROUPSPING 
(own_addr, cluster_name, ping_data, timestamp)
VALUES
('192.168.1.10:7800', 'keycloak-cluster', decode('CAFEBABE...', 'hex'), 1714466439000);

 

JGroups에서 만든 기능이다. Java 기반의 클러스터링 시스템에서 모두 활용 가능하다.

WildFly	Keycloak의 기반 애플리케이션 서버. 동일한 방식으로 JDBC_PING 사용 가능
Infinispan	분산 캐시 시스템으로, 클러스터 노드 발견에 JDBC_PING 사용 가능
JBoss EAP	엔터프라이즈 Java EE 서버, JDBC_PING을 통해 HA 구성
Apache TomEE + JGroups	JGroups 설정 시 JDBC_PING 적용 가능
Custom Java App	JGroups를 직접 사용하는 Java 애플리케이션도 JDBC_PING 사용 가능

 

 

3. kubernetes

쿠버네티스의 Kubernetes API를 사용한다. 따라서 HTTP 통신을 한다. 같은 서비스에 속한 파드들을 찾아낸다. 따라서 headless service 등으로 파드를 서비스에 노출시켜야만 하는 요구 조건이 있다. 이렇게 구성하면 파드들을 감지한 뒤 서로 내부적으로는 TCP 통신 방식으로 클러스터를 구성한다. 즉 커널의 소켓을 열어 3 handshake 방식으로 통신한다.