wacruit judge (dev) #87
Conversation
There was a problem hiding this comment.
@minkyu97 이제 k8s cluster 안정성을 위해 resources 설정을 100% 적용해나가려고 하고 있는데요. (특히 코테 채점 관련해서는 이게 더 중요해보입니다)
쉽지는 않겠지만 각 서비스에 대해 cpu / memory 의 requests / limits 설정을 어느 정도로 하면 좋을지에 대해서도 초안을 넣어주시면 좋을 거 같습니다. #85 PR, https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ 등도 참고해보세요. 정하기 어려우시겠지만 일단 넣어두시고 각 서버가 뭐하는 건지 구체적으로 알려주시면 저와 다른 분들이 추가 의견 드릴 수 있을 듯 합니다.
There was a problem hiding this comment.
조금 이따가 허들하는데 같이 논의해보고 답변드릴게요!
There was a problem hiding this comment.
@davin111
여러모로 바빴어서 리소스 산정이 늦어진 점 죄송합니다.
코딩테스트 채점이 주 목적인 만큼 몇 가지 실험을 진행해보았습니다.
https://www.notion.so/wafflestudio/wacruit-judge-1ac30ce869c94bd68e6bbf623b164650?pvs=4
실험 결과 서버는 적은 리소스를 주어도 문제가 없지만 워커의 경우 리소스가 너무 적다면 문제가 될 수 있어서, cpus의 경우 최소 1.0은 주어야할 것 같고 메모리는 운영팀 측에서 문제를 어떻게 내느냐에 따라 다를 수 있을 것 같습니다.
일단 dev 환경에서는 잘 작동하는지에 대해 최소한의 테스트만 진행한다면 cpus 0.5, memory 350MiB + a로 충분할 듯 싶고, prod 환경에서는 cpus 최소 1.0, 메모리는 문제에 따라 달라서 "350MiB + <워커 수> * <문제별 최대 메모리 사용량> + a" 정도 주어야할 것 같습니다. 만약 워커 수가 3, 문제의 최대 메모리 제한이 256MiB 라면 "350MiB + 3 * 256MiB" 약 1.2GiB 정도는 주어야 안전할 듯 싶습니다.
There was a problem hiding this comment.
@PFCJeong @davin111
먼저 두 분 와플 월드에 많은 수고를 해주고 계신 부분에 대해 감사하다는 말씀을 드립니다.
원식님이 말하신 대로 많은 리소스가 필요한 순간에만 별도 인스턴스를 파서 잠깐 이사를 하는 것도 좋은 방법이라고 생각합니다만, 저희는 현재 리크루팅 사이트를 리크루팅 기간에만 열어놓는 게 아니라 1년 내내 상시로 열어두고 코딩테스트 문제도 과거 리크루팅 전형에 대해 누구나 풀어볼 수 있도록 개방해둘 예정이라서요, 그렇게 된다면 어차피 리크루팅 기간이 끝난 이후에는 다시 와플 월드로 이사를 올 것 같습니다.
사실 와플 월드에 리소스 적으로 많은 여유가 있는 게 아니라 두 분이 새로운 앱을 추가하는 것에 대해서 조심스러운 스탠스를 취하고 있는 것으로 알고 있고 저도 충분히 납득하고 있는 부분입니다만, 그렇다면 와플 월드에 현재 리소스가 얼만큼 있는데 그 중 얼만큼이 사용 중이라 저희 앱을 추가하는 것이 어려운지에 대해 알려주시면 적어도 해당 제약 사항에 맞추어 개발 방향을 변경하는 등 다른 해결 방안을 모색할 수 있을 것 같습니다.
그리고 prod 환경은 둘째 치더라도 슬슬 프론트와의 작업 연계를 위해 적어도 dev 존 api라도 배포되면 좋을 것 같은데 이 PR에서 prod를 제외하고 dev 버전만이라도 위에서 말한 최소한의 리소스로 배포할 수 있을지에 대해 검토 부탁드립니다.
There was a problem hiding this comment.
이 PR 이 다소 오래 merge 되지 못하고 있어서 마음이 급하신 것은 이해하고 죄송합니다. 뭔가 답할 내용이 그 사이에 많이 쌓였네요. 메시지 끊어서 답해볼게요.
#88, #86 등 다른 PR 들을 보시면 아시겠지만 제가 웬만하면 다른 PR 들은 누가 올려주셨든 최근 상당히 빨리 리뷰 및 approve 를 해왔고, 빨리 merge 된 편입니다. 이 PR 에서도 제가 아주 빠르진 못했어도 꾸준히 소통을 이어왔고, 두 분 쪽의 작업을 기다린 시간도 있다고 생각합니다. 아무래도 낯선 서버인 만큼 좀 더 보수적인 고민이 필요한 건 사실이고요.
그리고 마음 속으로 생각하신 due 가 있고, 이것에 촉박해진 상황이 되었다면 따로 더 알려주시면 좀 더 빨리 보려고 하겠습니다. 어쩌면 앞으로 PR template 을 만들어 이런 걸 명시하도록 해도 좋겠단 생각이 드네요.
그렇다면 와플 월드에 현재 리소스가 얼만큼 있는데 그 중 얼만큼이 사용 중이라 저희 앱을 추가하는 것이 어려운지에 대해 알려주시면 적어도 해당 제약 사항에 맞추어 개발 방향을 변경하는 등 다른 해결 방안을 모색할 수 있을 것 같습니다.
저희 앱을 추가하는 것이 어려운지에 대해 라고 하셨는데, 어렵다고 한 적은 없고, 오히려 이런 서버 올리게 되어 재밌을 거 같다고 기대하고 있습니다... 소통이 늦어져 이렇게 오해하게 해드렸다면 죄송합니다.
약간 제 욕심일 수는 있지만 아쉬운 건, 와플 월드에 현재 리소스가 얼만큼 있는데 그 중 얼만큼이 사용 중이라 이런 내용이네요. 일단, '와플 월드'를 wafflestudio-cluster 환경 자체로 이해하고 답하자면, 이건 와플 GitHub 구성원 누구나 볼 수 있습니다. #infra-usage`에 공유했고, README에도 있듯이요. 물론 해당 툴에 낯선 입장에선 보거나 이해하긴 어려울 수도 있는 정보란 걸 이해하지만, 질문해주셨으면 언제든 더 잘 알려드리려고 했을 거 같아요.(제가 이 PR 에서 댓글 공세를 많이 받으시길래 언젠가 따로 DM 으로 말씀도 드렸던 거 같네요) 앞으로 좀 더 신경 써볼게요.
그리고, 아마 @minkyu97 @shp7724 두 분 다 있으실 거 같은데, AWS 계정이 있으면 단순히 EC2 들어가보셔도 EKS 용으로 node 가 5개 정도 상시적으로 떠있다는 걸 보실 수 있을 겁니다. (이 PR 이 올라올 당시엔 4개쯤이 상시 유지었으나 늘음)
별개로, 특히 infra-admin 이시기도 한 신홍 님은 grafana 아니더라도 kubectl top 명령어를 통해서도 리소스 정보를 확인하실 수 있긴 할 겁니다.
얘기하고 싶은 건, 리소스 정보는 대체로 누구나 파악하실 수 있긴 한 상황이고, 저한테 해당 정보를 꼭 의존하실 필요가 없다는 겁니다. 믿어주시는 것은 감사합니다. ㅎㅎ
더하여 아래처럼 얘기해주셨는데, 사실 어떤 서버라도 이 PR 에 붙은 dev 라는 이름처럼 (현재 prod 파일들도 있으니 제목을 수정해주시면 좋겠습니다) dev 에 대한 리소스 먼저 요청해주시는 게 좋기는 합니다. 저는 당연히 공감하고, 앞으로도 신규 리소스는 dev 만 포함시켜주시는 걸 권장드립니다. 그런데 지금 상황에서 파일을 다 지울 필요는 없고, 그냥 prod 의 Deployment의 replicas 를 0 으로 해주시면 원하는 효과가 날 거 같습니다.
그리고 prod 환경은 둘째 치더라도 슬슬 프론트와의 작업 연계를 위해 적어도 dev 존 api라도 배포되면 좋을 것 같은데 이 PR에서 prod를 제외하고 dev 버전만이라도 위에서 말한 최소한의 리소스로 배포할 수 있을지에 대해 검토 부탁드립니다.
사족으로, 최근 waffle-world 에 이뤄진 PR 이나 commit 들 보시면서, '뭐지? snutt 는 계속 열심히 보면서 딴 팀 건 방치하네' 라고 생각하셨다면... #team-snutt 보시면 아시겠지만 최근 2학기 수강편람 공개 이후 시즌상 중요한 시기인데 하필 여러 이슈가 겹쳐 발생하여 시간을 쪼개 장애 대응을 우선적으로 해왔다는 잡담을 공유드리고 싶습니다 😓
There was a problem hiding this comment.
@minkyu97 @shp7724 그런데 하나 사과드리고 싶은 건, 제가 #87 (comment) 이 댓글에서 node 하나가 2Gi 메모리라고 말했는데 4Gi 메모리입니다... 이건 순간적으로 착각했고요. 물론 계속 오해해온 건 아니고 #85 내용에서 볼 수 있듯 똑바로 알고 있다가 그냥 저때 잘못 생각했습니다.
근데 암튼 요지는 별로 다르진 않습니다. 지금 waffle-world 내 snutt 쪽 둘러보시거나 grafana 보시면 아시겠지만, 대부분 잠깐 도는 CronJob 이 아닌 서버는 가장 많이 먹는 녀석도 현재로서는 768Mi 입니다.
때문에 2Gi Pod 를 넣는다는 게 부담스러운 건 사실이고요. 특히 Node 에 단순히 application Pod 만 들어가지 않고 필수적으로/자동으로 들어가는 infra 관련 Pod (DaemonSet 으로 정의된) 들이나, 각 Pod 에 붙는 istio-proxy sidecar container 를 고려했을 땐 4Gi Node 에 2Gi pod 가 반드시 1개밖에 못 들어가는 상황이 됩니다.
그런데 그렇다고 해서 안 된다는 건 아니고, 어 이렇게 많이 필요할까? 리크루팅 기간이라고 해도 사람들이 항시 코테 풀고 있는 것도 아니고 리소스를 작게 잡아서 필요 시 Pod 개수 늘리는 방향으로 가는 게 좋진 않을까? 생각하고 질문을 드린 것입니다.
사실 어떻게 보면 타 서버들보다 와플 공식 리크루팅 위한 서버라 중요한데, 안 된다고 할 리는 없죠... 그리고 운영팀이니 좀 더 공감해주실 수 있겠지만 제가 좋아서 빡빡하게 구는 게 아니고, 동아리 비용을 어떻게든 줄여보려는 고민과 노력이라고 생각해주시면 감사하겠습니다. 설령 비용이 무제한이라 하더라도 리소스 최적화를 고민하는 게 올바른 자세이기도 할 거고, 학습 차원에서도 좋을 거고요.
경량화된 파드를 autoscaling 한다는 부분은 워커 파드 스펙에 메모리를 작게 할당하고 HPA를 설정하자는 말씀이시죠?
제가 k8s를 많이 안 써봐서 HPA를 구성하는 것이 resource의 request와 limit을 적절히 조절하는 것 대비 어떤 장점이 있는지 모르는데 이 경우에 HPA를 구성하는 것이 더 나은 이유를 좀 여쭐 수 있을까요??
위에 질문했던 것처럼, 최소 요구사항이 350Mi라는 걸 몰랐으니 특히 드린 말씀이긴 했습니다. 저런 최소 요구사항이 없다면, 요구량이 적을 땐 적은 리소스를 돌리고, 많을 때 많은 리소스를 돌리자는 일반론이긴 했습니다.
저희는 현재 리크루팅 사이트를 리크루팅 기간에만 열어놓는 게 아니라 1년 내내 상시로 열어두고 코딩테스트 문제도 과거 리크루팅 전형에 대해 누구나 풀어볼 수 있도록 개방해둘 예정이라서요
이런 생각을 하고 계시다면, 최소 요구사항을 경량화할 방법이 있는지 추후 더 찾아보면 좋을 거 같긴 합니다. 이런 내용도 요구사항의 일종이니 말씀 주시면 정말 좋아요.
그리고 위에 @PFCJeong 이 말씀주신 #87 (comment) 에 대해서 @minkyu97 님이 오해하고 계신 게 있는 거 같은데요. wafflestudio-cluster 바깥으로 뺀다는 식으로 이해하신 거 같은데, 그런 게 아니라 #107 같은 것처럼 특정 Pod 들을 특정 Node 에 배치하도록 설정할 수 있습니다. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
최근에 유저가 실제로 많이 사용하고 있는 서비스에 장애를 최소화하기 위해 적용했고, 해보니 그렇게 어렵지는 않아서 앞으로 필요 시 잘 써먹을 수 있을 거 같습니다. 이론적으론 yaml 몇 줄로 cluster 내부에서 Node 를 의도해서 Pod 들을 옮겨다닐 수 있습니다. 그러니까 여전히 cluster 내부에 있게 되는 거고, 사용 입장에선 거의 차이가 없습니다.
오히려 cluster 내부에 안 두려고 했다기보단, cluster 내 다른 서비스랑 서로 장애 영향 없도록 특히 관리 잘 해주면 어떨까, 같은 느낌도 있다고 생각해주시면 됩니다.
저는 특히 리소스 많이 사용할 리크루팅 기간에는 이렇게 해두면 확실히 좋을 거 같기도 하고요. (특히 여전히 좀 저에게 낯설고 약간 찝찝한 securityContext이 있기도 해서)
다만... 어차피 상시에도 운영해야한다면, 좀 고민이 되네요. 일단 dev 는 일반 Node 에 그대로 진행하고, dev 로 리소스 얘가 실제로 이것저것 해보면 얼마나 쓰는지 보고, 필요하다 판단되면 prod 에 대해서는 그렇게 진행을 고려해보면 될 거 같아요.
There was a problem hiding this comment.
@minkyu97 ⬆️ 위 답변 내용들도 보셨을까요? 시간 나실 때 읽어봐주시면 좋을 거 같아요.
There was a problem hiding this comment.
@davin111 알림을 못 봐서 확인이 늦었습니다 ㅠ
달아주신 코멘트에 여러 맥락이 있는 것 같아서 나눠서 답변을 드리자면,
- 그라파나는 제가 권한이 있는지 몰랐는데 깃헙 로그인 하니까 자동으로 권한이 부여됐는 걸 몰랐네요. 전 인프라 담당자 및 와플월드 담당자 분만 권한을 가지고 있는 걸로 잘못 알고 있었는데 제가 제대로 찾아보지 않고 다빈님이나 다른 분들에게 미룬 점 죄송합니다..
- 말씀하신대로 이 앱의 워커를 띄우기 위해서 350 MiB 가 최소 요구사항으로 보여서, 현재는 수평 스케일링을 하는 것보다 단일 팟에서 워커 수로 조절하는 방법이 현재로서는 더 나아보입니다. 당장은 시간이 많지 않아 개선이 어려울 수 있지만, judge0 를 사용하지 않고 celery 등으로 워커를 직접 개발하여 띄운다면, (1) wacruit-server와 중복되는 역할의 judge0 api 서버 필요 없음, (2) ruby on rails가 고정적으로 사용하는 메모리를 없앨 수 있음 등으로 경량화시킬 수 있을 것 같습니다. 이 부분은 긍정적으로 검토해서 빠른 시일 내에 결론을 내릴 수 있도록 하겠습니다.
- 그리고 원식님이 말씀해주신 방법은 제가 착각한 게 맞네요!.. 전 별도 ec2를 파서 진행하는 것으로 이해했습니다. 노드 셀력션으로 진행하는 거라면 딱히 단점이 없어보이네요 :)
- PR 제목은 수정하도록 하겠습니다.
SecurityContext의 사용이 클러스터에 어떤 영향을 줄지 몰라 찝찝함을 주는 것은 저도 동의합니다. 이 부분은 여러가지 테스트와 추가적인 리서치를 진행해서 클러스터에 영향 주는 것이 없는지 추가로 알아보도록 하겠습니다.- 마지막 부분에 prod 리소스 관련 얘기는 제가 좀 헷갈리는데요, 제 생각에는 리크루팅 기간이 끝나면 prod 존 리소스를 dev 존 만큼만 할당해두고, dev 존 레플리카셋을 0으로 설정해두면 어떨까 했는데 상시로도 리크루팅 기간만큼의 리소스(e.g. 2GiB memory)를 할당하는 것을 생각하신 걸까요??
저도 잠깐 사족을 달자면,, 절대 다빈님이나 다른 분들을 탓하거나 우리 앱만 늦게 해주네 이렇게 생각한 것은 절대 아니고요, 저도 당연히 이 앱이 많은 리소스를 먹는 만큼(채점 로직에서 트래픽 대비 많은 메모리를 필요로 하는 것은 어쩔 수 없지만요,,) 더 신중하게 검토해야하고 그만큼 처리가 늦어질 수 있다는 점에 대해서는 공감하고 있었습니다. 더불어 SNUTT 관련해서 이미 많은 시간 할애하고 계신 것도 당연히 이해하고 있습니다. 그런 부분에 있어 불만을 표했던 것은 아니었으니 이 부분은 오해하지 않아주셨으면 좋겠습니다 🥲 다빈님, 원식님, 한결님, 지혁님, 또는 그 외에 제가 모르는 많은 분들이 와플 인프라에 자발적으로 큰 도움을 주시는 데에 얼마나 감사하고 있는데요..
다만, 제가 빠른 merge를 검토 드렸던 것은 앞서 말씀드린대로 리크루팅 시작 기간이 얼마 남지 않았고, 자칫하면 새 운영팀이 요구한 리크루팅 기간에 차질이 빚어질 수 있었기에 dev 존 만이라도 먼저 merge 후 리소스는 천천히 재검토해보면 어떨까하는 생각이었고요, 절대 "아 왜 우리만 머지 안해줘!! 😤" 라는 느낌으로 떼를 쓰는 것은 아니었으니 혹시 오해하셨더라면 사과의 말씀 드리겠습니다.. 오히려 이 PR에 이렇게 많은 관심을 가져주신 데 대해서 너무너무 감사하고 있습니다 🙏
공용으로 사용할 수 있는 redis 가 있는 줄 몰랐네요!.. 요건 수정하겠습니다 |
|
아래 내용을 추가했습니다.
|
|
@shp7724 서버에서 서버를 호출하는 경우에도 vs 는 있으면 좋을 거 같습니다. 제거하신 이유가 잘 이해되진 않았어여. https://istio.io/latest/docs/ops/best-practices/traffic-management/#set-default-routes-for-services
|
|
@davin111 이런 구조였군요. Virtual Service 다시 추가했습니다. |
|
아, 얼마전에 elasticache 연결 테스트해본다고 올렸던건가보네요. |
davin111
force-pushed
the
feature/wacruit-judge-dev
branch
from
86ca51e
to
2003610
Compare
| cpu: 100m | ||
| memory: 192Mi | ||
| limits: | ||
| memory: 1Gi | ||
| cpu: 200m | ||
| memory: 192Mi |
There was a problem hiding this comment.
wacruit-judge 에 대한 이해도가 좀 부족해서 그런데,
직관적으로도 그렇고 #87 (comment) 이 설명을 참고해봐도 그렇고, worker 가 아마 주요할 거 같은데요. judge api server 는 구체적으로 어떤 것인가요? (뭔가 아키텍처 그림 그리신 게 있을 거 같기도 한데 그런 거 공유주셔도?)
#88 올려주신 wacruit-server 와도 또 별개인 거 같아서 궁금해서 여쭤봅니다.
일단은 얘는 리소스 작게 써도 되는 걸로 이해하고, dev / prod 에 적게 조절해봤습니다.
There was a problem hiding this comment.
@davin111
각 서버의 역할은 아래와 같습니다.
- wacruit-server
- 지원자 가입 및 자기소개서 제출
- judge-server로의 코드 제출 프록시
- 이외에 wacruit.wafflestudio.com을 렌더링하기 위해 필요한 정보 제공
- judge-server
- judge-worker
- 코드 실행
judge-server 자체는 많은 리소스(특히 CPU)가 필요 없지만, judge에서 사용하는 ruby on rails 환경이 메모리 사용량이 조금 많은 듯 하여 192Mi로는 부족할 수도 있을 것 같습니다. 이 부분은 일단 이대로 두고 실제 테스트 후 문제가 있다면 별도 PR로 조정 요청하겠습니다.
There was a problem hiding this comment.
@shp7724 judge-server 는 그럼 wacruit-server 에서 papi 로 코딩 답안 제출 같은 거 하는 서버라고 보면 되나요? judge-server 가 또 judge-worker 로 이를 넘기는 거고요.
새로운 리크루팅 서버 wacruit 의 채점용 서버입니다.
redis, worker, server 로 이루어져 있습니다.
wacruit-judge-worker 파드에
securityContext설정이 최대 권한으로 설정되어 있는데, 이는 채점 시에 cgroup을 이용한 격리 환경을 제공하기 위함이며, 본 서버의 핵심 코드들은judge0라는 유명 코딩 테스트 레포에서 가져왔으므로 큰 문제 없을 것으로 보입니다.테스트는 로컬에서 진행하였습니다.
w/ @shp7724