[ksqlDB] High Availability를 위한 설정

ksqlDB에서 HA(High Availability)를 무슨 작업을 위해서 존재할까? HA는 한글로 고가용성이라는 명칭으로 해석된다. 고가용성은 클러스터로 묶여 있는 서버들 중에 일부가 다운되더라도 서비스에 영향이 없어야 한다. ksqlDB에서의 고가용성은 pull query에서 필요하다. pull query에서의 고가용성을 위해 materialized state를 다른 서버에 복제해둬야 한다. materialized state의 복제를 위해서 ksqlDB의 기본 설정에서 변경해야할 값이 있다.

 

1. ksqlDB 클러스터 서버들의 내부 통신

listeners=http://0.0.0.0:8088
ksql.advertised.listener=http://host1.example.com:8088

기본 설정에서는 listeners=http://0.0.0.0:8088 만 존재한다. listeners는 내부/외부 모든 곳에서 오픈 될 주소를 설정한다. listeners에 도메인이나 와일드카드 IP로 설정할 때, 다른 서버에서 도달하지 못할 가능성이 있다. 그래서 ksql.advertised.listener 설정에 내부 서버들에 접근하는 주소를 넣는다.

 

2. replica 관련

ksql.streams.num.standby.replicas=1
ksql.query.pull.enable.standby.reads=true

ksql.streams.num.standby.replicas는 복제할 개수를 적는다. active 서버가 다운되었을 때, 복제한 서버들 중에 하나가 그 역할을 이어받게 된다. 그래서 고가용성을 위해서 ksql.streams.num.standby.replicas는 반드시 1 이상의 값이어야 한다.

ksql.query.pull.enable.standby.reads는 active 서버가 다운되었을 때, pull query를 사용할 수 있도록 활성화하는 값이다.

 

3. reporting 관련

ksql.heartbeat.enable=true
ksql.lag.reporting.enable=true

ksql.heartbeat.enable은 다운된 서버를 빨리 발견할 수 있도록 도와주는 장치이다. true로 설정하면 각 서버는 서로 서로 heartbeats를 보낸다. 그리고 /clusterStatus API도 사용할 수 있게 한다. 아래 그림은 /clusterStatus의 실행 결과를 캡쳐한 것이다. hostAlive로 보이는 값에서 서버들의 상태를 확인할 수 있다.

/clusterStatus

ksql.lag.reporting.enable은 상태 저장소를 복제할 때 얼마나 복제가 지연되었는지를 리포트할 지 여부를 설정한다. 이 설정은 ksql.heartbeat.enable이 true로 설정되었을 때만 동작한다.

 

지연과 관련하여 추가적인 설정이 하나 더 있다. ksql.query.pull.max.allowed.offset.lag이다. 이 설정은 어느 범위의 복제 지연까지 허용할 지 결정한다. 기본설정은 모든 지연을 허용한다. pull query를 보낼 때 request에 아래와 같이 설정을 포함할 수도 있다.

"streamsProperties": {"ksql.query.pull.max.allowed.offset.lag": "100"})

 

4. 추가 팁

마지막으로 필자가 ksqlDB 설정을 하면서 실수로 발생하여 경험한 내용을 공유한다. ksqlDB의 클러스터를 만들 때, 여러 서버에 동일한 클러스터에 묶여있음을 구분하는 설정이 있다. ksql.service.id 이다. ksql.service.id가 다르다면 다른 클러스터로 인식한다.

필자는 ksql.service.id를 실수로 다르게 설정하고 HA 구성이 안된다고 오류를 본 적이 있다. HA 구성했다고 생각하고 table을 만든 서버와 다른 서버에서 pull request를 요청했을 때, 아래와 같이 오류가 발생했다.

ksql.service.id를 잘못 설정했을 경우

Hosts를 스캔할 수 없다는 오류가 나온다. 구글링을 해봐도 결과가 없었는데, 여러 서버에 설정이 다른지 비교하면서 ksql.service.id가 다르단 것을 발견했다. 클러스터로 묶여있지 않은데 관계없는 서버에 pull request를 날린 경우가 됐다.

 

5. 결론

이번 글에서는 ksqlDB를 클러스터로 묶어서 사용할 때 필요한 설정들을 정리해보았다. ksqlDB를 한대만 구축해서 사용하는 경우는 개발 환경 뿐일 수 있으니 서비스에 적용하기 전에 관련 설정들을 잘 숙지하는 것이 좋겠다. 그리고 필자 처럼 어처구니 없는 실수를 방지하기 위해서 서버들의 설정을 한 곳에서 관리하는 방법을 고민해 보는 것도 좋을 듯 싶다.