cb-operator 등 Docker Compose 로 실행 시, kafka not ready 이면 DF 종료됨

[jihoon-seo]

What happened
:

docker-compose.yaml 에 아래와 같이 depends_on: 옵션을 명시해 두었는데도

    depends_on:
#     - cb-restapigw
      - cb-dragonfly-zookeeper
      - cb-dragonfly-kafka
      - cb-dragonfly-influxdb
      - cb-dragonfly-kapacitor

cb-operator 등 Docker Compose 로 실행 시, kafka not ready 이면 DF 종료됨

./operator info

[v]Status of Cloud-Barista runtimes
          Name                         Command               State                                                    Ports
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
cb-dragonfly                cb-dragonfly                     Exit 2
cb-dragonfly-influxdb       /entrypoint.sh influxd           Up       0.0.0.0:28083->8083/tcp, 0.0.0.0:28086->8086/tcp
cb-dragonfly-kafka          start-kafka.sh                   Up       0.0.0.0:9092->9092/tcp
cb-dragonfly-kapacitor      /entrypoint.sh kapacitord        Up       0.0.0.0:29092->9092/tcp
cb-dragonfly-zookeeper      /bin/sh -c /usr/sbin/sshd  ...   Up       0.0.0.0:2181->2181/tcp, 22/tcp, 2888/tcp, 3888/tcp
cb-ladybug                  /app/cb-ladybug                  Up       0.0.0.0:8080->8080/tcp
cb-restapigw                /app/cb-restapigw -c /app/ ...   Up       0.0.0.0:8000->8000/tcp, 0.0.0.0:8001->8001/tcp
cb-restapigw-grafana        /run.sh                          Up       0.0.0.0:3100->3000/tcp
cb-restapigw-influxdb       /entrypoint.sh influxd           Up       0.0.0.0:8083->8083/tcp, 0.0.0.0:8086->8086/tcp
cb-restapigw-jaeger         /go/bin/all-in-one-linux - ...   Up       14250/tcp, 0.0.0.0:14268->14268/tcp, 0.0.0.0:16686->16686/tcp, 5775/udp, 5778/tcp, 6831/udp, 6832/udp
cb-spider                   /root/go/src/github.com/cl ...   Up       0.0.0.0:1024->1024/tcp, 0.0.0.0:2048->2048/tcp, 4096/tcp
cb-tumblebug                /app/src/cb-tumblebug            Up       0.0.0.0:1323->1323/tcp, 0.0.0.0:50252->50252/tcp
cb-tumblebug-phpliteadmin   /usr/bin/caddy --conf /etc ...   Up       0.0.0.0:2015->2015/tcp, 443/tcp, 80/tcp

docker logs cb-dragonfly

[CLOUD-BARISTA].[INFO]: 2021-04-06 15:03:43 nutsdb-driver.go:32, github.com/cloud-barista/cb-store/store-drivers/nutsdb-driver.initialize() - ######## dbfile: /go/src/github.com/cloud-barista/cb-dragonfly/meta_db/dat
kafka is not responding dial tcp 172.18.0.6:9092: connect: connection refused
panic: dial tcp 172.18.0.6:9092: connect: connection refused

goroutine 1 [running]:
main.main()
        /go/src/github.com/cloud-barista/cb-dragonfly/pkg/manager/main/main.go:43 +0x3d8

What you expected to happen
:
kafka 가 ready 될 때까지 DF 가 기다림

How to reproduce it (as minimally and precisely as possible)
:
./operator run

Anything else we need to know?
:

Environment

• Source version or branch:
• OS:
• Others:

Proposed solution
:

Any other context
:

[seokho-son]

Kafka가 호스트의 사양 및 용량에 의해서 ready 상태로 가지 않을 수 있을텐데 df가 무한정 기다리게 되면 문제가 발생할 수도 있으려나요~? 참고^^

[dev-secloudit]

@jihoon-seo @seokho-son @powerkimhub
Kafka 연결 관련해서 최대 5회 5초의 간격을 기준으로 Kafka에 연결을 시도하고,
최대 5회 연결 시도 이후에는 CB-Dragonfly의 프로세스 구동을 중지하는 로직을 반영했습니다.

해당 PR: #79

[seokho-son]

@hyokyungk 이슈 대응 감사합니다.. ^^
혹시 최대 5회 연결 시도 이후에는 CB-Dragonfly의 프로세스 구동을 중지하기 보다는
CB-Dragonfly를 살려두고, Kafka 연결 오류를 알려주시는 것은 어떨까요? (Health check 메시지 등을 통해?)

CB-TB에서는 Dragonfly가 죽으면 이유를 알기 어렵기 때문입니다.. ^^

[dev-secloudit]

@seokho-son

해당 부분을 고려해본 결과, 몇 가지 이슈가 있는 것 같습니다.

프로세스가 구동 중일 때에는 일반적으로 모니터링 데이터 수집 및 처리가 이루어지고 있는 상태라고 판단할 수 있는데,
Kafka의 연결 오류가 실패한 후 모니터링 수집 기능이 동작하지 않는 상태에서 프로세스를 계속 살려 둘 경우 정상 상태인 지 에러 상태인 지 명확한 구분이 어려울 것 같습니다.
(Kafka 연결 외에 다양한 이유로 프로세스가 패닉 상태 및 에러 등 비정상 상태에 빠질 경우 프로세스를 중지시키고 있습니다.)

위에서 제시해주신 CB-TB에서 DF의 헬스체크를 확인하는 경우에는 별도의 /healthcheck API가 제공되고 있습니다.
CB-DF가 정상 동작 상태이며, API 서버가 정상적으로 Listen 하고 있을 경우에는 해당 API를 통해서 204 코드를 전달하니 해당 API를 활용해 프레임워크끼리의 헬스체크를 확인하는 방법은 어떨까요?

[seokho-son]

@hyokyungk health check api 는 TB에서 잘 활용하고 있습니다. 다만 DF를 외부에서 관리하려고하면 health check를 했을 때 단순히 응답이 없는 것으로만 나올 것이라..

아무래도 무슨 일로 DF가 정상 동작하지 않는 것인지 확인하려면 직접 호스트에 접속해서 log를 확인할 수 밖에 없을 것 같습니다. 이렇게되면 운영이 살짝 불편하고 자동화가 어려운 부분이 되겠죠. (DF 자체가 시스템 오류로 죽으면 어쩔 수 없겠지만..^^)

예를 들어, 카프카가 호스트 용량 부족으로 죽었고
DF가 이를 알고 간단하게나마 오류를 API를 통해 알려줄 수 있다면
외부에서 DF 호스트의 용량을 높혀서 DF호스트 및 DF 컴포넌트를 모두 신규로 띄울 수도 있을 것 같습니다 ~ ^^

[powerkimhub]

@hyokyungk (@seokho-son)

/---------------------------
cb-dragonfly-influxdb
cb-dragonfly-kafka
cb-dragonfly-kapacitor
cb-dragonfly-zookeeper
/---------------------------

추가적으로 의견 드립니다.

1. 장기적으로는, 활용하는 상기 서비스(4S)들에 대한 상태 관리가 필요해 보입니다.
2. DF 서버 내부에서도, 저들 상태에 따라 일부 서비스는 중단 시키거나 재개 시키거나 하는 방안이 필요해 보입니다.
3. 향후(조만간), K8S 위에 DF 및 4S 운영에 있어 문제가 발생하면, K8S에 의해 재가동시켜질 수 있기 때문입니다.
4. 추가적으로는 현재는 kafka IP로 연동중인데 name service 연동으로 수정되어야 할 거 같습니다.
5. 다만, 반영 시기는 타 프레임워크 진행 상황 및 DF 내부 타 부족 기능 개발을 고려하여 스케줄링하시면 좋을 듯합니다.

[dev-secloudit]

@powerkimhub @seokho-son

4개의 dependency가 있는 서비스의 상태 관리와 관련해서는 차차 방안을 마련해보도록 하겠습니다.

@seokho-son 께서 얘기해주신 연결 에러와 관련된 로그 정보를 전달하는 부분과,
@powerkimhub 께서 얘기해주신 일부 서비스를 중단/재개 하는 부분은 역할이 구분되어야 할 것 같습니다.

2번과 같이 일부 서비스를 중단/재개의 기능이 들어간다면,
docker, kubernetes 환경의 연결 및 접속 정보가 별도로 필요하기 때문에 필요한 데이터와 라이브러리들이 추가될 가능성이 있어 보입니다.
해당 부분은 추후 4S 운영 이슈의 비중이 커지게 된다면, 개발 방안을 구체화하여 고려해보도록 하겠습니다.

[seokho-son]

@powerkimhub @jihoon-seo

2 번 사항은 @hyokyungk 님께서 말씀하신 것 처럼.. cb-bridge (cb-operator) 차원에서 dockercompose나 k8s config 를 통해서 해결하는 것이 좋아 보입니다. (개별 서비스 동작 여부 확인 및 재시작하는 설정 등을 활용)

만약 2번에 대한 사항을 CB-DF에서 자체 해결하려고하면,
CB-DF가 CB의 배포에 관련된 사항을 인지해야 하므로, 시스템이 복잡해질 것으로 예상이 되며, 관리 포인트도 다중화 될 것 같습니다. (CB-DF가 자체적으로 자동화 및 안정성 보증할 수 있다면 상황이 다를 수 있겠습니다.)

일단 에러와 관련된 로그 정보를 전달하는 부분 정도로 보완해 보는 것이 어떨까요?

[jihoon-seo]

최근에, cb-operator repo의 CB Helm chart에,
etcd를 사용하는 CB FW 전부 (Spider, Tumblebug, Ladybug, Dragonfly, restapigw) 파드가
etcd ready 되도록 기다리는 initContainers를 추가했습니다.

• Related discussion: CB-FW returns error and gets stuck if etcd is not ready cb-operator#144
• Related PR: Add initContainers to wait for etcd cb-operator#147

@hyokyungk
이와 같이, CB Helm chart에서,
DF Helm chart에

cb-dragonfly-influxdb
cb-dragonfly-kafka
cb-dragonfly-kapacitor
cb-dragonfly-zookeeper

등이 ready 되도록 기다리는 내용을 (initContainers 방식으로) 추가하는 것은 어떠려나요? 😊