redis O(n) 명령어

KEYS : 패턴에 일치하는 모든 키를 반환

-> 최적화 방향 : 한꺼번에 다 가져오는게 아니라 순회 할 수 있도록 scan 명령 사용,

-> 그 사이사이에 다른 커맨드를 처리할 수 있어서 long blocking 방지

-> ex) scan 0

FLUSHALL : 레디스 서버의 모든 데이터(key,value)를 삭제한다.
FLUSHDB : 현재 선택한 DB의 모든 데이터(key,value)를 삭제한다.
-> async 시 별도의 쓰레드에서 background로 삭제하여 long blocking 방지

Delete Collections
Get All Collections
-> Collection은 너무 크게 유지 하지 않는것이 좋음, 하나당 몇천개 안쪽으로만..

"자동 커밋이 설정된 채 커밋할 수 없습니다"
"Could not commit with auto-commit set on"
commit 뿐 아니라 rollback도 마찬가지입니다.

고객사에서 Oracle을 업데이트하며 갑작이 위와같은 에러가 발생한다곤 합니다...

(과거 Oraccle JDBC Driver에서는 발생하지 않았지만... )
이전에는 엔진 코드를 다 변경해주기도 했지만..
지금까지 최근 Oracle에서만 발생하는 에러로 모든 commit과 rollback을 수정하는건 참 낭비스러운 작업입니다.

그래도 코드를 수정하지 않고도 해결할 수 있도록 Oracle에서도 호환성을 맞춰주기 위해 JVM 옵션을 하나 제공합니다.

-Doracle.jdbc.autoCommitSpecCompliant=false

docs.oracle.com/database/121/JAJDB/oracle/jdbc/OracleConnection.html#CONNECTION_PROPERTY_AUTO_COMMIT_SPEC_COMPLIANT

물론 가이드한다고 고객사가 이 옵션을 설정을 해서 해결한다는 보장은 없지만.. 
일단 옵션은 있습니다..

카프카는 파티션 갯수를 늘리고 다시 줄일수 없다고 해서

토픽을 삭제 후 다시 생성하기 위해

kafka-topics.sh 를 통해(window에서 테스트를 해서 실제로는 .bat)

topic을 삭제 했습니다.

그런데. . kafka 브로커가 다운되더니.. 부팅되지 않는 문제가 발생하기 시작했습니다.

(부팅시 에러는 삭제한 토픽 파일을 읽는데 파일 권한에러..인데.. 전혀 접근 권한 문제 일으킬만한건 없습니다)

그래서 이런저런 글들을 살펴보며 겪은 부분들을 남깁니다...

먼저 delete.topic.enable=true

를 설정 하지 않아서 kafka-topics로 삭제했을때 마크만 된 상태였습니다.

그래서 위 설정을 해줬지만 마찬가지로 정상 부팅은 되지 않았습니다

(지금 생각해보니 설정을 하고 kafka-topics로 다시 삭제를 해볼껄 그랬나봅니다..)

(그런데.. 생각해보니 kafka-topics로 삭제할때 IP:PORT는 zookeeper쪽을 입력해줬는데.. 의미가 있나.. 싶네요)

두번째로 시도한건 recovery-point-offset-checkpoint, replication-offset-checkpoint 수정 입니다.

글을 보니 다른 브로커로 파티션 옮길때 수정하는 것으로 보이던데

이 방법을 시도해본 이유는 

"나는 토픽을 삭제했는데 왜 해당 토픽 관련 에러가 나는것인가?, 해당 토픽 내용들을 다 삭제해야 겠다"

였습니다.

파일 구조는 recovery~~~나 replication~~ 이나 거의 유사 했고

0
59
__consumer_offsets 22 0
__consumer_offsets 30 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 4 0
__consumer_offsets 27 0
__consumer_offsets 7 0
__consumer_offsets 9 0
__consumer_offsets 46 0
topic3 0 0
__consumer_offsets 25 0
__consumer_offsets 35 0
__consumer_offsets 41 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 49 0
topic2 0 0
__consumer_offsets 47 0
__consumer_offsets 16 0
__consumer_offsets 28 0
__consumer_offsets 31 0
__consumer_offsets 36 0
__consumer_offsets 42 28
__consumer_offsets 3 0
__consumer_offsets 18 0
__consumer_offsets 37 0
bars 0 0
__consumer_offsets 15 0

이런식이였습니다, 자세한 정보를 추가로 찾아봐야겠지만

두번째 줄에 59는

두줄을 빼고 데이터부가 59라인이 있다는것을 말합니다.

(결국 마지막 데이터 줄은 61라인)

그래서 삭제할 토픽의 데이터의 offsets 디렉토리 정보와 토픽 정보를 라인을 삭제하고 두번째 라인에서 값을 빼줬습니다.

그후, 부팅해보니 수정했던 replication-offset-checkpoint 가 다시 삭제했던 내용들을 복원해놓고 있었습니다

(대체 토픽정보를 어디서 복원을 하는거지.. 레플리카 구성한것도 아니고..)

마지막 세번째, 파일들은 대략 다 열어 봤고 마지막 의심가는건 zookeeper밖에 없었습니다

zookeeper 데이터를 찾아보니 /brokers/topics 에 삭제했던 topic 정보가 남아있었습니다

rmr /brokers/topics/대상토픽

으로 삭제하고 

replication-offset-checkpoint를 수정 후

broker를 띄우니 잘 뜨는것을 확인했습니다.

지금은 토픽을 그냥 삭제하는데 발생한 이슈였지만.. 운영중에 갑작이 이렇게 부팅이 안되는 문제가 발생하면.....;;;;

kafka를 사용하는 방법도 더 해봐야겠지만

내부 파일 구조 체계들을 알아둬야 이런 난감한 상황에 잘 대처 할 수 있을것 같습니다

k8s 환경만 있다면 Argo 설치는 간단했습니다.

Argo 설치

kubectl create namespace argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/stable/manifests/install.yaml

네임스페이스(argo)를 만들고

yaml 파일을 apply 하면 끝 입니다.

Argo 설치 후 Pod 확인

kubectl get pod -n argo
NAME                                   READY   STATUS    RESTARTS   AGE
argo-server-55f5985454-gwlkv           1/1     Running   60         6d11h
workflow-controller-7dffbf956c-nv8vn   1/1     Running   0          6d11h

그리고 생성한 네임스페이스에 떠있는 pod을 확인해보면

두가지가 있는데(이전에 생성했던거라 AGE가 올라가 있습니다)

argo-server, workflow-controller 입니다.

Argo-Server

argo-server는 argo-ui로 기본적으로 2746을 포트로 하고 있고 브라우저를 통해 접속해보면

flow를 작성해서 submit 한다거나 모니터링이 가능합니다.

최근 2.5에서는 cron도 추가 된것을 확인 할 수 있습니다.

보통 저는 사용이 필요할때

kubectl -n argo port-forward deployment/argo-server 2746:2746

커맨드를 통해서 포트포워딩 하여 활용하고 있습니다.

Workflow-Controller

workflow-controller는 argo에서 사용하는 crd(커스텀 리소스)인 wf(WorkFlow)나 cwf(cronWorkFlow) 를 처리 합니다

Argo 기능들

Argo는 Step과 DAG(그래프 방식) 지원하지만

추가적인 기능들도 제공하고 있습니다.

추후 Argo를 통해 제공해야할 업무가 있어서

추가적인 기능들을 하나씩 파악하며 예제를 돌려보았습니다.

suspend & resume
- suspend 초, 분, 시, 일 단위 가능, 시간을 안주면 approve 방식으로도 가능
- resume은 UI에서 가능, argo cli에서도 가능

retry
- 재처리 duration(s,m,h,day)
- maxDuration, 이 시간동안 성공안하면 실패
- limit 

exit-handlers
- 워크플로우 상태에 따라 처리할수 있도록, {{workflow.status}}
- 마지막 종료 실패 결과를 운영자에게 알리기 위해서 주로 활용할듯 함(이메일, SMS)

volumeMounts
- 기존에 만들어둔 Volume을 마운트 시키거나, Flow내 LifeCycle을 갖는 Volume을 마운트 하여 Step간 파일 전달

Daemon Containers
- 워크 플로우가 실행되는 동안 사용될 컨테이너를 실행할 수 있음
- Step중에 Daemon으로 설정하게 되면 해당 Pod은 내려가지 않고 다음 Step 실행

Sidecars
- 실행하는 Step의 Pod에 sidecar(한 pod 안에 같이 뜨는 컨테이너)를 지정할 수 있음

이미지 출처 : https://github.com/argoproj/argo/blob/master/docs/architecture.md

Argo 그리고 KubeFlow를 살펴보며

Argo의 경우에는 Step Step 마다 넘겨주는 artifact

그리고 KubeFlow는 pipeline에 넘기는 파일들을 어디서 저장하고 어떻게 넘겨주나 살펴봤더니

Artifact 서버 설정 파트가 있고, Argifact 서버 설정으로는 Cloud Storage 혹은 MINIO(Object Storage)를 설정하도록 되어있었습니다

(https://argoproj.github.io/docs/argo/docs/configure-artifact-repository.html)

(https://www.kubeflow.org/docs/pipelines/overview/pipelines-overview/)

Cloud 업체들이 지원하는건 일단 상용 서비스들일테니 우선 고려대상은 아니고

오픈소스인 MINIO를 잠시 살펴보았습니다.

MINIO, 어디서는 MINIO어디서는 Minio라고 적혀있고 어디서는 MinIO로 적혀있고

처음 봤을때 "민 아이오" 가 맞나? "미니오"가 맞나? 애매 했는데

MINIO 채널 유튜브를 보니 강의자 분이 "민 아이오"로 읽으시는걸 보며 "민 아이오"로 읽는게 맞는것 같습니다.

로고는 MINIO, 공식 홈페이지 타이틀은 MinIO...

(https://min.io/)

(https://github.com/minio/minio)

MINIO는 Object Storage며, Cloud Storage로 적합하다고 합니다

(AWS S3가 ObjectStorage의 표준이라고 볼수 있다고 하는데, S3와 호환을 지원한다고 합니다.)

공식 홈페이지에 따르면, 표준 하드웨어 환경기준 R/W 속도가 183GB/s , 171GB/s 라고 표기되어있습니다

(https://min.io/resources/docs/MinIO-Throughput-Benchmarks-on-NVMe-SSD-32-Node.pdf)

(https://min.io/resources)

(32노드, SSD 기준이네요)

(24노드 하드디스크 기준으로는 16GB/s, 9GB/s )

MINIO에는 "Bucket" 그리고 "Object" 라는게 존재합니다.

거의 파일의 "디렉토리" 그리고 "파일" 에 대응 된다고 보면 되는것 같습니다.

MINIO는 기본적인 Cli 커맨드로는 

파일 시스템처럼

ls(list 확인, bucket이나 object), cat(object의 내용 확인), cp(object 복사), rm(object 삭제) 등 익숙한 명령어를 지원하고

Bucket에 Event를 설정하여 변경을 감지 하는 부분도 물론 지원합니다.

(Webhook으로도 받을수 있지만 여러 큐 시스템이나, MySQL로도 이벤트를 받을 수 있습니다.)

데이터 조회도 SQL 로도 가능한것으로 보입니다.

MINIO 클라이언트는 자바, 자바스크립트, 파이썬, Go, .Net, Haskell 로 지원하고 있어 원하는 언어에 맞게 클라이언트 프로그램을 작성 할수 있도록 되어있습니다.

하드웨어 장애에도 데이터를 보호하기 위해 Erasure Code 라거나, 분산 처리 환경을 위해 여러 방식들을 지원하고 있는데 각 내용들은 필요해지면 추가적으로 살펴볼 예정입니다.

업무상 필요에 의해 

Container 기반 WorkFlow 엔진을 알아볼 필요가 있었습니다.

(배치의 Flow에 활용할까? 하는 부분 때문이죠)

물론 짧은 시간동안 알아봤기 때문에 깊이는 부족하지만 기억력이 좋지 않아 글로 남깁니다.

Argo(프로젝트 중 WorkFlow, https://github.com/argoproj/argo) 

vs

AirFlow(https://airflow.apache.org/)

Argo는 Container 기반, 즉 단계마다 KubeContainer를 각각 띄움

AirFlow는 AirFlow 서버가 떠있다 가정하고(airflow scheduler) 동작하는것으로 보여

필요한것은 Kube 기반이 필요했기 때문에 Argo를 살펴봤습니다.

Argo는 KubeFlow에도 활용되고 오픈소스 컨테이너 워크 플로우로 

Go로 작성 되어있습니다.

설치하는 부분을 살펴보면 workFlow를 처리하기 위한 커스텀 컨트롤러(workflow-controller) 를 설치하는 부분들이 나오고

(https://argoproj.github.io/docs/argo/docs/getting-started.html)

실제 workFlow를 사용하는것도 yaml파일에 kind를 Workflow(커스텀 리소스)를 활용해서 동작합니다.

Argo는 WorkFlow 기능을 제공하는 만큼 다양한 기능들을 제공하는데

(https://argoproj.github.io/docs/argo/examples/README.html)

단순 Flow를 위한 Step이나 더 복잡한 flow처리를 위한 DAG, 

종료에 따른 Flow처리를 위한 Condition 등 많은 기능들을 살펴보고 있는데

(사실.. 이 각 부분은 추가로 살펴볼 부분이...없...)

추가로 살펴볼 예정인것은 artifact 부분인데, 앞에 실행한 output 들에 대해

다른 Job을 처리시 넘겨주거나 할때 artifact를 통해 처리하는것 같아 보이고

(아직은 확실하지는 않지만..)

artifact storage로 'Minio'(Open Source Object Storage server) 라는 것들 지원한다고 합니다..

음.. 오브젝트 스토리지라...

저장소긴 한데.. Minio가 뭘해주는지 Job간 어떻게 데이터를 전달하는지 추가로 봐야할듯 합니다..

일단은.. 여기까지..

Zookeeper는 Zookeeper 단독으로도 사용되지만, 하둡이나 카프카 등 여러 다른 시스템들과 함께 활용되고 있지만

저의 경우에는 Zookeeper 자체에서 어떤 기능들을 제공하는지 조차 모르고 사용하기도 했습니다.

그래서 조금씩 파악중이며 조금씩 수정해갈 예정입니다.

Zookeeper는 기본적으로

• 메타 저장소

• 데이터 변화 감시를 위한 Watcher

• 데이터 snyc 혹은 분산 어플리케이션을 위한 lock 제공

• 간단한 설정을 통한 클러스터 지원
  와 같은 기능들을 제공하며(이것 말고도 많겠지만)

  참고로 메타는 각 노드에 저장되며, 노드는 트리구조로 되어있고, 트리를 쉽게 접근할수 있도록 파일시스템과 같이 접근할 수 있습니다(/data/node1/info).

  그리고 노드도 여러가지 종류들을 제공합니다.

  • Ephemeral Nodes
    • 세션동안 유지되는 노드, 연결이 끊어지면 삭제
  • Sequence Nodes
    • 고유명을 위한 노드
  • Container Nodes
    • 락을 위한 노드(3.5.3에 추가됬다고 하는데 사용을 아직 못해봤네요)
  • TTL Nodes
    • 마찬가지로 3.5.3에 추가

분산 어플리케이션들은 보통 Zookeeper의 클라이언트가 되고, Connection을 지속적으로 유지하고 있습니다.

Zookeeper에서 데이터 변화 감지를 위해 Watcher를 제공하기 때문에 polling을 하며 감시 할 필요 없이
동작만 CallBack 코드만 작성해 두면 되기에 훨씬 간결해 질 수 있습니다.

Watcher의 경우 노드 하나 변화에 Wacher를 설정할 수 있고, 노드 하위에 변화에도 대해 설정 할 수 도 있습니다.

• 데이터 변화에 대한 Watcher
  • get -w /data
• 데이터 하위 생성에 대한 Watcher
  • ls -w /data

Zookeeper를 활용하여 할수 있는 것들은 많겠지만
일단 간단하게 구현 해본 부분은 "분산 어플리케이션에서 서로의 노드 추가 삭제 감지 에 따른 동작"
상위 Node를 하나 생성하고, 어플리케이션마다 하위에 ephemeral + sequence Node를 생성하고
서로 상위 Node를 Watcher 하게 하면
간단히 분산 어플리케이션에서 어플리케이션 변화를 감지 할 수 있고
Watcher 코드에 대응되는 동작을 넣는것으로 간단히 "분산 어플리케이션 상황에서 각 어플리케이션 감지 및 동작" 을 처리 할 수 있습니다.

해당 글은 Zookeeper를 살펴보거나 사용할 때 마다 기록을 위해 업데이트 할 예정입니다.