검색결과 리스트
글
사커킹
2018년 1월 ~ 2018년 5월, 월드 사커킹 개발팀
사용 언어 및 라이브러리: C#, SuperSocket, MSSQL,
간단한 업무 내용
- Jenkins를 이용한 서버 개발 프로세스 구축
- 서버 빌드 및 배포, 테이블 패치 및 배포, 관리 서버 빌드 및 배포, 테이블 논리적 오류 검증 등을 Jenkins 프로세스에 추가
- Super socket을 이용한 서버 아키텍쳐 설계 및 구현
- 게임 컨텐츠 구현
- 서버 구현 후 소프트 런칭까지 할당된 작업 시간 4개월
설정
트랙백
댓글
글
아처리킹
2017년 3월 ~ 2018년 5월, 아처리킹 개발팀
링크 : https://itunes.apple.com/kr/app/%EC%95%84%EC%B2%98%EB%A6%AC-%ED%82%B9/id1121971067?mt=8
사용 언어 및 라이브러리: C#, Proudnet, Linq to MySQL
간단한 업무 내용
- Jenkins를 이용한 개발 프로세스 구축
- 업무를 효과적으로 처리하기 위한 자동화툴 개발 및 적용, 관리 서버 런처 배포 자동화 시스템 구축
- 게임 컨텐츠 개발 및 운영
설정
트랙백
댓글
글
무 정지 서버 업데이트
2017년에 작성을 시작하여 바쁘다는 핑계로 마무리가 되지 않은 글을 마무리하지 못했는데 그래도 내용이 재미있기 때문에 3년이 흐른 지금 공개로 설정합니다.
참고로 요즘은 많은 서비스가 서버를 멈추지 않고 버전 업데이트를 진행합니다.
서비스를 정지하지 않고 서버 점검을 할 수 있어야하는 이유가 무엇일까?
고민할 필요 없다. 새벽에 출근하지 않기 위함이며 빨리 집에가기 위함이다. 개발자들에게 그것보다 중요한 이유가 필요한가?
세션형 온라인 게임에서 무 정지 서버 업데이트를 처리하기 위한 대략적인 개요는 대략 이러하다.
- 서비스 이용 시 서버 어플리케이션이 변경되는 것을 유저가 느낄 수 없도록 해야 한다.
- 패치 시 프로그래머 이외에 실제 작업자가 직접 패치 및 배포 작업을 할 수 있어야 한다. 즉 작업이 쉬워야 한다.
- 작업이 쉽도록 하기 위해서는 빌드 및 배포 아키텍처가 제어 인터페이스 뒤에서 드러나지 않아야 한다.
- 히스토리를 한눈에 알 수 있어야 한다.
위의 조건들을 만족하기 위해 빌드 자동화 및 배포 기능을 만족하는 툴 프로그램 제작 후 젠킨스를 이용해 해당 툴을 실행 시킨다.
젠킨스의 장점은 아래와 같은 빌드 설정들을 파라미터로 툴에 전달이 가능하며 빌드 전후 이벤트를 셋팅할 수 있고 사용이 쉽다.
위의 그림은 일반적인 세션형 서버 아키텍쳐이다. 최소한 본인이 경험한 다섯번의 프로젝트는 위와 크게 다르지 않으며 MMORPG 같은 경우만 게임 서버간의 관계 구조가 조금 다를 뿐... 단순화 시키면 위와 비슷하다. AWS 사용은 무 점검을 위한 필요 조건은 아니다.
그러면 서버 패치 시 서비스를 중지 시키는 이유는 무엇일까?
1. 소스 코드에 버그가 있어 어쩔 수 없이 새로운 빌드의 서버 프로그램을 시작해야 하는 경우
2. 서버 프로그램이 데이터 로드나 환경 셋팅을 프로그램이 시작되면서 초기화될 때만 처리할 수 있는 구조인 경우
3. DB 테이블 변경을 적용하기 위해 서버 프로그램이 갱신되어야 하는 경우
4. 유저 접근을 차단하고 DB 작업이 필요한 경우
무 정지를 위해 기본적으로 크게 다섯 가지 정도 고려할 사항이 있다.
1. 최신 버전의 서버 어플리케이션에서 다양한 하위 버전의 클라이언트 수용이 가능해야한다.
- 구버전 서버가 구동 중인 상태에서 신버전 서버 프로세스가 시작되면 높은 버전의 서버로 유저 진입이 가능해야 한다.
- 유저가 모두 빠진 구버전 서버 프로세스는 자동으로 종료될 필요가 있다.
- 버전별 매칭이 가능해야 한다.
2. 데이터 및 DB 패치
- 데이터 변경 및 DB 변경에 대한 규칙 설정은 초반에 결정해야한다. 자동화하기 위해서는 규칙이 있어야 한다.
- 데이터 로드용 구조체 생성은 자동화될 필요가 있다. 관리 대상이 늘어나면 사람은 실수 한다.
- 서버 프로그램은 재시작하지 않고 변경된 데이터를 로드할 수 있어야 한다.
- DB 스크립트를 이용한 패치도 자동화되어 있어야 한다.
- DB 패치 후 구버전 서버도 문제 없이 구동이 가능해야 한다.
3. 서버 빌드 및 배포 방법
- 반드시 자동화를 초반에 고려해야 한다. 나중으로 미루고 구현하는 경우는 거의 본적이 없다.
- 히스토리 추적이 쉽고 간단해야 한다.
- 파트 구분 없이 작업자가 직접할 수 있어야 한다. 패치는 프로그래머만 해야 하는 그런 거 없다. 모두가 하면 다 같이 편해진다.
- 위의 항목이 가능하기 위해서는 프로세스에 점증 시스템이 반드시 필요하다.
수많은 데이터를 관리하는 담당자에게 반복되는 패치 오류를 지적하는 것도 무책임하다. 최소한 데이터 타입, 논리적 모순, 링크 검증 등
빌드 단계에서 자동으로 확인해 줄 시스템은 프로그래머가 구축해야 한다. 필터링 되지 않은 문제들을 검증 시스템에 추가해나가면 데이터
패치 오류 문제는 정말로 많이 감소한다.
4. 서버 기능과 코드 관리
- 큰 작업 단위로 조건부 컴파일을 이용하고 안정화되면 반드시 정리한다.
- 기능 변경이나 서버 설정이 바뀐다고 빌드를 다시 하는 경우가 없어야 한다. 데이터 및 DB 변경으로 컨트롤할 수 있게 설계하자.
하드코딩 좀 하지마.
5. 서버 스케일 정보
- 서버 운용 정보 주기적 갱신 후 해당 정보를 이용하여 클라 접속을 제어한다.
- AWS를 이용한다면 아키텍처 구상 단계에서 GameLift를 고려해본다.
그러면 최신 버전의 서버 어플리케이션에서 다양한 하위 버전을 수용하기 위해 고려할 사항으로는 무엇이 있을까? 일반적으로 데이터 드리븐방식으로 프로그램을 구현하기 때문에 데이터값이 변경되는 것은 문제가 없지만, 데이터 타입 변경이나 컬럼이 추가되는 등의 경우는 호환성 유지에 걸림돌이 될 수 있다.
[구버전 소스 코드]
enum Color
{
Red,
Yellow,
Max
}
class TableHeaderFlower
{
string name;
Color color;
int count;
}
[구버전 데이터]
|
string |
Color |
int |
1 |
Rose |
Red |
10 |
2 |
... |
... |
... |
위와 같이 정의된 꽃에 대한 데이터가 다음과 같이 변한다면
[신버전 소스 코드]
enum Color
{
Red,
Yellow,
Green,
Max
}
class TableHeaderFlower
{
string name;
Color color;
int count;
string languageOfFlowers;
}
[신버전 데이터]
|
string |
Color |
int |
string |
1 |
Rose |
Red |
10 |
장미 꽃 말 |
2 |
녹색 꽃 |
Green |
1 |
녹색 꽃 말 |
열거형 멤버와 데이터 컬럼이 추가되었다.
열거형 멤버만 추가될 수도 있다 여러가지 변경이 복합적으로 발생할 수도 있다.
일반적인 상황이라면 구버전 빌드는 구조가 변경된 데이터를 읽어올 때 Green이라는 열거형 멤버와 꽃말이라는 추가된 컬럼 때문에 정상적인 실행이 되지 않을 가능성이 높다.
...
내용은 앞으로 계속 추가하도록 하겠습니다...
RECENT COMMENT