1. googleforgames/agones 소개
agones는 kubernetes에서 세션형 게임서버를 운영하기 위한 도구입니다. 세션형 게임서버는 유저가 방에 접속하고 방에서 게임을 진행 후 방이 없어지고 다시 방이 생성되는, 즉 방 단위로 인게임이 진행되는 게임 서버를 의미합니다. agones는 방을 kubernetes위에서 custom resource(CR)로 추상화시켜 컨테이너화된 게임서버를 쉽게 제어할 수 있도록 스케일링과 업데이트를 관리합니다.
agones에서 주요 개념 중 gameserver, fleet, fleetautoscaler라는 개념이 있는데, 이를 먼저 소개합니다.
- gameserver: 직접 관리자가 운영하는 게임서버 컨테이너가 포함된 파드. 게임서버 관리의 최소 단위
- fleet: 게임서버의 묶음을 관리하는 단위. 스케일링 정책과 replicas를 명시
- fleetautoscaler: fleet이 어떻게 확장되어야 하는지를 정의하는 리소스
보통 fleet, fleetautoscaler를 운영에서 많이 사용할 것으로 보이는데, fleet을 통해 어떤 이미지로 gameserver를 배포할지, 또 업데이트 정책은 어떻게 될지 명시하고 fleetautoscaler CR을 배포하여 확장 가능한 세션형 게임서버를 구현할 수 있도록 도와줍니다.
2. 이슈 탐색 및 이슈 소개
이슈 선정은 스터디에서 몇 가지를 추천해 주셨습니다. 그 추전 과정과 선정 과정을 간단히 설명드리면 다음과 같습니다.
먼저 agones에 존재하는 good first issue를 파악해 봅니다. 보통 많은 사람들이 사용하는 오픈소스의 경우 이슈를 여러 태그에 나눠서 분류합니다. 그중에서 초보자들이 진입하기 쉽고 오픈 소스에 기여하는 지점으로 활용되는 태그가 good first issue인데 해당하는 태그의 이슈 중 몇 가지를 소개해 주셨습니다.
그 중에서 가장 직관적인 이슈를 선정했습니다. 해당 이슈는 다음과 같습니다.
대략적인 내용은 이렇습니다.
- agones를 배포하고 fleet과 fleetautoscaler를 배포한 상태에서 maxReplicas를 50, minReplicas를 10, Buffer를 5로 지정했다고 합니다.
- gameserver가 1~2개가 할당됐습니다.
- Scaling Limited이 grafana 대시보드에서 True로 출력됩니다.
그리고 밑에서 다른 분이 조사한 대략적인 내용은 이렇습니다.
- EKS 쓰는데 저도 발생해요. 그런데 이는 의도된 것으로 보입니다.
- flag가 scale-in, scale-out의 조건에서 flag가 true가 되도록 구현되어 있기 때문입니다.
- 해당 함수의 주요 부분은 다음과 같습니다.
func applyBufferPolicy(b *autoscalingv1.BufferPolicy, f *agonesv1.Fleet) (int32, bool, error) {
// ...
if replicas < b.MinReplicas {
replicas = b.MinReplicas
limited = true
}
if replicas > b.MaxReplicas {
replicas = b.MaxReplicas
limited = true
}
return replicas, limited, nil
}함수를 확인했을 때 replicas의 수가 클 때와 작을 때 제한된다는 것과 이것은 애초에 의도된 상태임을 알 수 있었습니다.
3. PR열기
이슈만 파악된 상태에서 바로 PR을 올리겠다고 이슈에 올렸습니다.
그러자 maintainer분이 100% 이슈인지 확인할 수 없다, 무엇을 업데이트하려고 하시냐고 물어보셨고 docs를 업데이트할 예정이라고 답장했습니다.
이 이슈와 관련된 문서에 대한 당시의 설명은 다음과 같습니다.
- kubernetes API에서
scalingLimited(bool): ScalingLimited indicates that the calculated scale would be above or below the range defined by MinReplicas and MaxReplicas, and has thus been capped.
- metrics 소개 문서에서
agones_fleet_autoscalers_limited: The fleet autoscaler is capped (1)
kubernetes API문서에는 ScalingLimited가 MinReplicas와 MaxReplicas의 범위를 벗어났는지를 기준으로 하고 있지만, metrics 소개 문서에는 그냥 제한된다고 설명되어 있었습니다.
그래서 metrics 부분 문서를 업데이트하고 문제가 발생하는 함수를 리팩터링 해서 PR을 올리는 것으로 방향을 잡았습니다.
아래는 PR 링크입니다.
먼저 코드 부분의 리팩터링을 다음과 같이 진행했습니다.
func applyBufferPolicy(b *autoscalingv1.BufferPolicy, f *agonesv1.Fleet) (int32, bool, error) {
// ...
scalingInLimited := false
scalingOutLimited := false
if replicas < b.MinReplicas {
replicas = b.MinReplicas
scalingInLimited = true
}
if replicas > b.MaxReplicas {
replicas = b.MaxReplicas
scalingOutLimited = true
}
return replicas, scalingInLimited || scalingOutLimited, nil
}기존 limited으로만 제한되던 부분을 scalingInLimited와 scalingOutLimited부분으로 분리했습니다. 그리고 grafana 대시보드의 Scaling Limited -> Scaling out/in Limited으로 변경하고 위의 metrics 문서의 부분도 수정해서 PR을 올렸습니다.
PR이 머지되는 과정에서 maintainer분과 간단한 변수명, 문서 설명 수정을 진행했습니다. 이후 빠르게 머지되어 현재 agones 문서에서 수정된 부분을 확인할 수 있습니다.
4. 후기
흔히 오픈 소스를 이해할 때 하는 방법이 오픈 소스의 전체 그림을 크게 보고 작은 부분으로 깊게 내려가는 top-down방식으로 접근하게 됩니다. 그러나 이번 기회에 작은 이슈로부터 시작해서 PR을 올리고 이후 전체 오픈 소스의 구조를 보는 bottom-up방식으로 진행했는데, 생각보다 작은 feature부터 시작해서 올라가도 기여를 할 수 있고 오히려 빠르게 프로젝트를 살펴볼 수 있다는 것을 알았습니다.
오픈 소스에 기여하고 싶은 개발자를 위해 good first issue를 남기는 부분도 인상적이었고, 만약 사내에도 이렇게 쉽게 기여할 수 있는 부분을 good first issue로 남겨둔다면 이후 새로운 개발자 온보딩을 진행할 때도 좋은 흐름이 될 수 있겠다고 생각했습니다.
또 기술보다 다른 사람과 비동기적으로 의사소통해야 하는 점에 있어서, PR 이후 과정은 커뮤니케이션 능력이 중요하다는 것도 해당 기회에 알 수 있게 됐습니다.
이번 스터디로 오픈 소스 기여를 처음으로 해봤는데, 앞으로 종종 기회가 있으면 또 도전해보려고 합니다. 그리고 이번 기여가 또 다른 기회를 열게 하는데, 이 부분은 다음에 또 포스팅해보겠습니다.
