search

jam2in / arcus-java-client

Arcus Java client
Apache License 2.0
0 stars 0 forks source link

replication 사용 플래그 설정의 재검토. #33

Closed jhpark816 closed 7 years ago

jhpark816 commented 7 years ago

java client에서 replication 사용하기 위해서는 해당 replication flag를 설정해야 합니다.

이러한 불편함이 replication 적용에 하나의 장벽이 되는 건지 다시 한번 논의해 봅시다.

whchoi83 commented 7 years ago

과거에는 replication flag 를 사용하지 않고 /arcus_repl znode 가 존재하면 무조건 replication client 로 동작하도록 동작했었다가 아래 이슈로 처리해서 현재의 모습으로 수정었습니다. https://github.com/jam2in/arcus-task/issues/19

이때 이슈를 올렸던 것과 마찬가지 의견으로 NAVER와 같이 /arcus 와 /arcus_repl 을 하나의 ZooKeeper Ensemble 에서 운영하는 경우를 생각해보면 어떤 방식으로든 client 에서 이중화 설정을 하는 것이 필요해 보입니다.

whchoi83 commented 7 years ago

replication 을 적용하면서 "불편함"이 장벽이 되는 경우를 생각해보면, 운영 중인 cloud 에 replication 을 적용하는 경우라고 생각됩니다.

이 경우에는 replication 에서 사용하는 znode 구조상 cache node 와 응용 모두 재기동이 필요하고, replication 적용에 필요한 작업양을 생각해보면 replication flag 설정 하기 위한 코드 한 줄 추가는 "장벽"이 아닌 "무시"해도 되는 수준이 아닌가 합니다.

replication flag 의 적용이 불편함이 되려면, 하나의 ZooKeeper ensemble 에, 일반 cloud 와 replication cloud 가 동일 서비스 코드로 존재하고 이것을 필요에 따라 교체할 수 있어야 할 때가 아닌가 판단됩니다. 하지만 이런 경우가 존재할지 의문입니다.

위 의견과 별개로 개인적인 판단으로는 replication 을 사용하기 위한 코드의 한 줄 추가가 "불편함"으로 바라봐야 하는 것인지 의문입니다. 제가 생각하지 못한 상황이나 이슈가 있을 수도 있으니, 의견 주시면 좀 더 고민해보도록 하겠습니다.

jhpark816 commented 7 years ago

OK... 알겠습니다.. 이 이슈는 흔적으로만 남겨 두고 담당자를 변경해 두었다가, 나중에 다른 생각이 있으면 다시 쳐다보든지 아니면 close 할 께요.

jhpark816 commented 7 years ago

Repl Cloud 또는 Normal Cloud를 판별하는 기존 방법은 ZK root directory name 뿐만 아니라 service code도 확인하며, 아래 순서대로 판별합니다.

단계 1) /arcus_repl/cache_list/{service code} znode 존재 여부 확인

단계 2) /arcus/cache_list/{service code} znode 존재 여부 확인

주의할 사항은 arcus_repl 디렉토리와 arcus 디렉토리 모두에 동일한 service code가 있을 경우입니다. 이 경우가 발생하지 않도록 운영자가 잘 관리해야 하는 부분입니다.

whchoi83 commented 7 years ago

현재 버전으로 코드가 수정된 이유는 https://github.com/jam2in/arcus-task/issues/19 이슈의 논의 결과였습니다. 이중화를 지정하는 방법이 있으면 좋겠다는 의견이 있으셔서 https://github.com/jam2in/arcus-task/issues/19 이슈를 생성해서 진행했었습니다. (이중화 말고도 기타 다른 플래그 의견도 있으셨습니다.) 혹시 당시에 설정 방법이 있으면 좋겠다고 생각하셨던 이유가 있으신가요? 있다면 본 논의에 도움이 될 것 같습니다.

jhpark816 commented 7 years ago

사실, 명시적인 설정이든 아니든 코드 변경은 무시할만한 수준입니다.

문제는, 응용 개발 부서에서 기존 application 담당자가 바뀔 수 있다는 것입니다. 필요에 의해 cache cloud(사실 replication enabled cloud)를 변경하고 나니, 기존 application이 동작하지 않는다는 문제가 발생하여 이러한 문의가 많이 들어온다는 것이고, NAVER 계열사에서 외국인 개발자로 부터도 이러한 문의가 들어와서 ARCUS 서스테이닝에 부담이 커진다는 것이 문제가 됩니다..

그리고, 응용 개발에서는 하나의 application code 를 가지고 여러 환경(여러 config 설정)에서 운영이 가능하였으면 한다고 합니다. 그 의미는 common application code가 있고 이를 여러 서비스의 application에서 이용하는 것 같습니다.

jhpark816 commented 7 years ago

예전 repl 설정 코드를 넣은 이유는 대략 아래 이유입니다.

whchoi83 commented 7 years ago

코드의 변경 자체에 문제를 말씀드리려는 것이 아니라, ARCUS 의 정책을 어떻게 가져가야 할 것이냐의 관점으로 질문 드린 것입니다. 기존 코드의 수정 때도 그런 관점으로 질문을 드리고 논의해서 결정했던 것으로 기억합니다.

코멘트 주신 의견들을 고려하면, (같은 응용 코드로 이중화 / 일반 환경 모두 사용할 수 있도록) 현재 가장 간단한 방법은 (arcus-java-client library 를 사용하는) 응용에서 jvm -D 옵션을 이용해 replication 설정을 하도록 하는 것입니다. (log4j 설정하는 방법과 동일하게)

그 외에도 라이브러리가 동작할 때 property 파일을 보고도록 하는 것도 있을텐데 (이것도 log4j 와 비슷합니다) 응용입장에서 arcus-java-client 의 설정 파일이 별도로 존재하는 것에 대해서 어떻게 생각할지 모르겠네요.. 논의가 필요할 것 같습니다.

whchoi83 commented 7 years ago

@minkikim89 본 이슈는 결론난 것으로 알고 있는데 최종 결론난 것을 코멘트로 정리한 뒤 close 했으면 합니다.

minkikim89 commented 7 years ago

이슈 정리:

flag는 사용하지 않는 것으로 결정내리고 해당 설정을 deprecate 시켰습니다. 이유는 ARCUS 서스테이닝 부담을 줄이기 위해서 입니다. 즉, application 코드를 고치지 않고 normal <-> replication cluster를 가능하게 하기 위함입니다.

현재 동작 구현은

주의할 사항은 arcus_repl 디렉토리와 arcus 디렉토리 모두에 동일한 service code가 있을 경우가 존재하지 않도록 운영자가 잘 관리해야한다는 점입니다.