환경변수 정리

[singsangssong]

🔍 Description

• 현재까지 구현된 arcus-cli의 환경변수를 점검하고, 이를 어떻게 개선하면 좋을지에 관해서 검토하고자 합니다. 검토하는 내용은 아래와 같습니다.
  • 환경변수 목록 정리, 환경변수로 받는 것이 적절한지 검토
  • 환경변수 관련 가이드 작성
  • 환경변수와 구동인자 구분 기준 명확히 정리
  • viper 라이브러리 사용 여부

⏰ Implementation Idea

현재까지 사용하는 환경변수 목록

ZK_ADDR
- zookeeper의 단일 주소
- ex: "10.0.0.1:2181"
ZK_LIST
- zookeeper 앙상블을 이루고있는 주소 리스트
- ex: ZK_LIST="10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181"
ZK_PATH
- 원격 장비에 있는 zookeeper 경로
- ex: /Users/songseognhun/arcus/zookeeper
ARCUS_PATH
- 원격 장비에 있는 arcus 경로 
- ex:  /Users/songseognhun/arcus

• 아래 두 PR에서 사용하는 모든 환경변수 목록과 각 환경변수의 의미, 그 예시를 작성했습니다.
  • FEATURE: Add 'zookeeper start|stop|stat' command to manage zk ensemble #19
  • REFACTOR: refactor 'zookeeper init' to initialize ZooKeeper config files #21
• 이때, ZooKeeper 앙상블 모두에게 myid와 zoo.cfg파일을 생성하면서, ZK_ADDR과 ZK_LIST로 분할하기보다는 ZK_LIST로 통일하는 것이 좋아보입니다.
  • 의미표현상, 하나 혹은 여러 ZK주소를 받을 수 있다면 ZK_LIST가 가장 적절해보입니다.
  • ContextWithZkConn()에서도 여러 ZK주소에 connection을 맺기에 ZK_LIST라는 표현의 의미가 더 적절해보입니다.
    -그 외 경로를 가리키는 명령어는 여러 명령에서 사용할 여지가 있어보이므로, 계속 환경변수로 두어도 좋을 것 같습니다.

[namsic]

@oliviarla
현재 cli 도구에서 환경변수와 명령행 인자를 혼용하고 있어서 이에 대한 정리를 하려고 하는데,
인터페이스와 관련하여 의견 줄 수 있나요?

예를 들어, 현재 구현 기준으로는 서비스코드에 서버 추가하기 위해서 아래와 같이 명령을 수행해야 합니다.

ZK_ADDR=10.0.0.1:2181,10.0.0.2:2181,10.0.0.3:2181 ./arcus-cli memcached add serviceCode 10.0.0.1:11211 [g01 10.0.0.1:11311]

어떤 기능을 실행할 때 필요한 값을 입력받는 방법으로
환경변수를 사용하는 경우가 있고 인자로 전달받는 경우가 있는데, 둘의 구분 기준은 무엇인가요?

제가 생각했던 기준은 아래와 같습니다.

• 인자로 받을 때: 특정 기능에서만 필요한 경우, 입력받기에 너무 긴 변수가 아닌 경우에 인자로 받도록 하고있습니다. 예를 들어, acl group add 의 경우, group add라는 기능의 대상이기에 인자로 사용했습니다.
• 환경변수로 받을 때: 여러번 재사용하는 경우가 많은 경우, 한번 세팅하고 변하는 경우가 드문 경우에 환경변수로 받도록 하고 있습니다. 예를 들어 이번 서버 IP목록의 경우(zklist), 3개의 zk를 가정한다면 zklist="10.33.111.24:30000,10.34.108.181:30000,10.33.184.197:30000"로 길어지기에 환경변수로 받고자 했습니다.

이러한 구조가 사용하기에 어색하지 않을지, 더 직관적인 방식이 있을지 궁금합니다.

[oliviarla]

@namsic
전체적인 명령 종류에 대해 정리된 자료가 있나요?

[singsangssong]

@oliviarla @namsic

acl 명령

acl user add <groupName> <username[:password]:role>
acl user remove <groupName> <username>
acl user list <groupName>

acl group add <groupName>
acl group remove <groupName>
acl group list

• 환경변수: ZK_ADDR

1. 유저 znode를 생성합니다. 해당 그룹에 acl이 있을경우, -u -p를 통해 acl을 확인한 후 생성합니다.
2. 유저 znode를 제거합니다.
3. groupName에 속한 유저 리스트를 출력합니다. 해당 그룹에 acl이 있을경우, -u -p를 통해 acl을 확인한 후 생성합니다.
4. 그룹 znode를 생성합니다. -u -p를 통해 acl을 함꼐 생성할 수 있습니다.
5. 그룹 znode를 제거합니다.
6. 그룹 리스트를 출력합니다.

memcached 명령

memcached list [serviceCode]
memcached config <serviceCode> [options...]
memcached add <serviceCode> <ip:port>
memcached remove <serviceCode> [<ip:port>]
memcached start <serviceCode> [ip:port...]
memcached stop <serviceCode> [ip:port...]

• 환경변수: ZK_ADDR

1. zk에 등록된 memcached 서버를 출력합니다. 서비스코드가 있다면 서비스코드의 memcached 서버를 상세 출력하고, 서비스코드가 없다면 서비스코드에 관한 memcached의 전체 정보만 출력합니다.
2. 서비스 코드의 memcached 서버의 전역 옵션을 설정합니다. 입력한 [option...]의 내용을 그대로 저장합니다.(인자를 입력하지 않아도 됩니다.)
   • ex: memcached config servieCode -t 4 -c 100 -ml 100
3. memcached 서버 znode를 생성합니다. 인자로 받은 memcached 서버 주소를 arcus zk 규칙에 맞게 znode를 생성합니다.
4. memcached 서버 znode를 제거합니다. 인자로 받은 memcached 서버 주소를 arcus zk 규칙에 맞게 znode를 제거합니다.
5. 서비스코드의 memcached 서버를 구동합니다. 주소 인자를 입력하면 해당 memcached서버를 구동하고, 주소 인자를 입력하지 않으면 서비스코드 하위의 memcached 전체를 구동합니다.
   • 환경변수: ZK_ADDR, ARCUS_PATH
6. 서비스코드의 memcached 서버를 중지합니다. 주소 인자를 입력하면 해당 memcached서버를 구동하고, 주소 인자를 입력하지 않으면 서비스코드 하위의 memcached 전체를 중지합니다.
   • 환경변수: ZK_ADDR, ARCUS_PATH

ZooKeeper 명령

zookeeper init
zookeeper start
zookeeper stop
zookeeper stat

• 환경변수: ZK_ADDR

1. 각 ZK_ADDR마다 myid와 zoo.cfg를 생성합니다.
2. 각 ZK_ADDR마다의 zookeeper 서버를 구동합니다.
   • 환경변수: ZK_ADDR, ZK_PATH
3. 각 ZK_ADDR마다의 zookeeper 서버를 중지합니다.
   • 환경변수: ZK_ADDR, ZK_PATH
4. ZooKeeper 앙상블 서버의 stat을 출력합니다.

---

공통되는 환경변수외에 각 명령에서 추가로 필요한 환경변수는 해당 명령 설명 아래에 따로 작성해두었습니다.

[oliviarla]

@namsic
k8s와 유사하게 yml 파일 템플릿을 제공해서 기존 구동되어 있는 형상과 사용자가 yml에 정의된 형상을 자동으로 비교하는 건 어떤가요?
go process에서는 어떤 작업을 수행할 지 리스트업하여 보여주고, 사용자가 ok 하면 실제 수행하는 형태면 훨씬 편리할 것 같습니다. (start/stop도 yml 파일에 인자로 두어야 할 것입니다.)

(+ 현재 형상을 확인하는 명령은 따로 있는 것이 좋을듯 docker ps 같은 형태로?)

예를 들어 zk는 이미 ensemble 구성되어 있고 서비스 코드가 없는 경우, memcached add <service code>와 memcached start <service code> [ <node list> ]을 수행할 지 사용자에게 묻고, enter 누르면 하나씩 수행되는 형태가 될 수 있겠습니다.

[oliviarla]

@jhpark816 님께서는 위 의견에 어떻게 생각하시는지 궁금합니다.

[jhpark816]

@oliviarla @namsic
arcus tool 논의 시에 (1) 명령 방식과 (2) 형상 비교 방식이 모두 언급되었고,
처음에는 기존대로 명령 방식이 좋겠다고 했던 기억이 있습니다.
명령 방식이 기본적이고 간단한 방식이라 생각했던 것 같고,
형상 비교 방식은 그 이후에라도 필요하다면 제공할 수 있을 거라 생각합니다.

@namsic
arcus-cli 구현하더라도
arcus-cli 사용법에 대한 문서화를 미리 만들고 공유하여 리뷰 받아주면 좋겠습니다.
문서는 간결하면서도 그 내용이 정확해야 합니다.

[oliviarla]

@jhpark816
저는 의견이 조금 다릅니다.

직접 arcus shell 사용해보니, 형상 비교 하는 방식이 훨씬 자동화된(진화된) 형태라서 편리할 것으로 생각합니다. (여기 인터페이스보다는 json 입력받는 게 훨씬 직관적으로 느껴졌습니다.)
요즘 추세가 명령형이 아닌 선언형 프로그래밍이기도 하고요. (k8s의 방식도 그렇고, claude code, gemini 등 AI 툴들도 CLI를 통해 특정 작업을 하라고 선언하면 구체적으로 어떤 작업을 진행하고 있는지 직접 결정하여 사용자에게 알리는 Agent 방식을 사용합니다. )

명령어를 하나하나 입력하는 것은 human error가 있을 수도 있고 어떤 인터페이스를 제공할 지에 대해 계속 고민해야 하지만,
형상 비교하는 방식을 사용하면 yml 파일 구조, 내부 동작 방식만 결정하면 되기 때문에 개발하기에 더 편리할 것으로 보입니다.

[jhpark816]

@namsic

• 운영자가 다양한 운영 상황에 유연하게 대처하기 위해, 명령 방식과 형상 비교 방식 중 어떤 방식이 나은가요?
• 명령 방식이 먼저 구현되어 있어야, 형상 비교 방식의 구현이 쉬울 것 같습니다. 어떤가요?

[namsic]

• 운영자가 다양한 운영 상황에 유연하게 대처하기 위해, 명령 방식과 형상 비교 방식 중 어떤 방식이 나은가요?

상황에 따라 다르지만, 선언형 인터페이스(형상 비교 방식)가 사용하는 입장에서 더 직관적입니다.

• as-is 상태가 어떤지, 내가 원하는 상태를 만들기 위해 어떤 작업이 필요한지를 몰라도
  원하는 최종 형상을 명시해 두고 적용하는 것만으로 작업이 완료됩니다.
• 같은 명령을 여러 번 실행해도 멱등성이 보장됩니다.
• 여러 메이저 운영 / 배포 도구들이 yaml 기반의 선언형 인터페이스를 채택하고 있습니다.
  • kubectl
  • ansible
  • AWS CloudFormation

• 명령 방식이 먼저 구현되어 있어야, 형상 비교 방식의 구현이 쉬울 것 같습니다. 어떤가요?

형상 비교 방식을 사용한다고 하면, 명령 방식을 함께 사용하면 안 되고 항상 형상 비교 방식으로만 운영해야 합니다.
(zkCli로 cache_server_mapping znode를 만드는 것도 안 됩니다.)

예를 들어, A B C 3개 노드 형상으로 apply하여 클러스터 생성해 둔 상태에서,
arcus-cli 명령 방식으로 캐시 서버 D를 추가한 경우(또는 zkCli로 직접 znode 생성한 경우에도 마찬가지)
나중에 형상 비교 방식을 사용하면 D가 다시 제거됩니다.

k8s에서 ArcusMemcached 리소스 memlimit 100으로 설정하여 apply한 뒤에
memlimit을 200으로 변경한다고 할 때 yaml 파일을 수정한 뒤 apply해야 정상 변경되고,
구동 중인 캐시 서버에 직접 config memlimit 200 명령을 보내면 pod 재구동 등의 이벤트 발생 시
변경했던 memlimit이 다시 100으로 돌아가는 것과 유사한 맥락입니다.

[namsic]

참고 사항으로, 이전에도 아래와 같이 형상 비교 방식에 대한 검토가 있었습니다.

• 설정 파일 사용 여부 결정 #25
• Memcached 설정 파일 구조 결정 #23
• ZooKeeper 설정 파일 구조 결정 #24

[jhpark816]

형상 비교 방식을 사용한다고 하면, 명령 방식을 함께 사용하면 안 되고 항상 형상 비교 방식으로만 운영해야 합니다.

이 부분은 알고 있습니다.

명령 방식이 먼저 구현되어 있어야, 형상 비교 방식의 구현이 쉬울 것 같습니다. 어떤가요?

위의 질문에 대해서는 어떻게 생각하나요? (명령 방식은 형상 비교 방식의 구현에서 내부적으로 사용하겠다는 의미입니다.)
arcus-cli 개발이 완료되어야 하는 일정은 어떻게 되나요?

[jhpark816]

운영자가 다양한 운영 상황에 유연하게 대처하기 위해, 명령 방식과 형상 비교 방식 중 어떤 방식이 나은가요?

위의 질문은 편의성 관점에서 질문한 것이 아니고,
운영 상의 여러 위험(HW 고장, SW 오류, power off 등등)에 대해 대처하는 데에 있어 어떤 방식이 나은 지를 질문한 것입니다.

[jhpark816]

@namsic @oliviarla
여러 문제 상황을 충분히 잘 고려하여 설계 및 구현하고 안정적으로 운영할 수 있다면,
그리고 사용 방식의 자유도를 줄이고 우리가 정의하는 방식으로만 사용하게 한다면
"형상 비교 방식"이 나을 수 있다는 생각이 듭니다.
구현 및 운영 경험이 적고 일정을 맞추어야 하는 현 상태에서 판단할 때,
앞서의 질문들을 던진 것임을 참고 바랍니다.

[namsic]

• 명령 방식이 먼저 구현되어 있어야, 형상 비교 방식의 구현이 쉬울 것 같습니다. 어떤가요?
• 명령 방식은 형상 비교 방식의 구현에서 내부적으로 사용하겠다는 의미입니다.

내부적으로는 당연히 znode를 만들거나 ssh로 명령을 전송하는 로직이 공통으로 구현되어야 할 것이고,
명령 방식을 먼저 구현한다고 해서 형상 비교 방식의 구현이 쉬워지는 것은 아닙니다.

기능 측면에서 arcus-cli가 하는 일은 아주 단순한 편이고,

• znode create/delete
• ssh + shell 명령 실행(start, stop)
• 서버에 srvr, stats 명령 전송

각 기능을 실행하기 위해 필요한 값을 사용자로부터 입력받고 가공하는 로직이 주를 이루게 됩니다.
이러한 로직은 인터페이스에 따라 크게 달라질 수 있는 부분입니다.

arcus-cli 개발이 완료되어야 하는 일정은 어떻게 되나요?

• 필요 시 acl 관련 기능만 먼저 릴리즈할 수 있습니다.
• @singsangssong 인턴 마치기 전까지 naver/arcus 저장소의 arcus.sh 제거하고 대체해 넣는 것이 목표입니다.

편의성 관점에서 질문한 것이 아니고,
운영 상의 여러 위험(HW 고장, SW 오류, power off 등등)에 대해 대처하는 데에 있어 어떤 방식이 나은 지를 질문한 것입니다.

보편적인 운영 시 조작을 배제하고 엣지 케이스 발생 시의 상황만 놓고 보면 당연히 명령 방식이 유연하게 대응하기에 낫습니다.
이 때도 arcus의 동작 방식을 충분히 이해하고 있다는 전제이고, 그렇지 않으면 명령 방식이라고 대처하기에 특별히 더 유용하지는 않을 것입니다.

운영자가 각 동작의 semantic, 현재 클러스터 상태, arcus 동작 방식 등을 충분히 이해하고 사용해야 함
아마 고객사 또는 arcus를 사용해 보려는 외부 사용자가 사용하기에는 복잡할 것

arcus-cli를 아래 중 어떤 도구로 만들 것인지 결정해야 합니다.

1. 외부인도 쉽고 간편하게 클러스터 구성/운영할 수 있는 도구인지,
2. 내부 동작을 충분히 숙지하고 실 서비스 운영하는 사람을 위한 보조 도구인지,

한 개 도구로 모든 요구사항 만족하는 silver bullet을 만들 수는 없을 것으로 생각하고, 저는 전자를 목표로 진행해 왔습니다.

[jhpark816]

잼투인이 arcus 운영하기 위해 사용하는 도구는 따로 두고(아마 arcus-tool 일 것 같음),
외부인이 사용하기 편하게 제공하려는 용도라는 것이죠?
그러면, 설계 진행해 주세요.

지금까지 개발한 것이 있으니,명령 방식의 사용법도 정리해 주고
형상 비교 방식의 인터페이스에 대해 설계를 진행해 주세요.