250527 화요일 @ 30일차

어제는 일정이 있어서 오후부터 나가서 저녁늦게왔다.
이동간에 그냥 뭐 놀기엔 그래서 NDC 발표들을봤다, 
첫째로는 리니지2의 데이터베이스 전환
두번째는 다못봤지만 게임서버목차-시작출시까지.
두 발표들을 보면서 깨달은건 
그제 책을 읽었던 내용중 자동화,유닛테스트의 검증의 중요성들이 많이나왔는데,
이부분을 너무 간과해서는 안될것 같았다.
자동화와 유닛테스트가 어려울순있어도 해당부분이 개발하는데 있어서,
문제의 조기발견, 테스트, 개발 오류 검증을 게임의 크기에따라 오래걸릴수 있는것을 
시간을 줄일수있는 성과와 같다고 생각했다.
(특히나 리니지2의 경우는 개발중에 업데이트를 따라가면서 DB를 전환했다는 점에서 크게 다가왔다)
리니지2의 발표에서 또 알게되었던 SQL이 비슷비슷하고 나머지는 똑같다고생각했는데, 다른점이 의외로 조금씩 있었다는점.
물론 발표에 나오지 않은부분이 훨신 많겠지만 발표의 내용만 해도 꽤 많다고 느껴졌다.
예를들면 SQL함수 처리 결과라던지, 잘못된문자열 저장허용하지 않는다는점이나, IFNULL 컬럼에따른 형변환 안해준다던지..
odbc 기본으로 스레드세이프하게 작동안해서 설정이필요하다거나..
DB를 이용함에있어서 기본적인 설정을 알아둬야 할것같다고 느꼈다.

오늘은 게임서버 프로그래밍교과서를 읽었는데
우선 프라우드넷에 대해서 나왔다.
프라우드넷은 원격프로시저 호출의 기능을 포함하여,
네트워크 전반을 담당해주는것 같다,
뿐만아니라 클라이언트간 p2p통신도 가능하고 (서버의 허락 필요)
모바일 핸드오버기능도 탑재되있다.

다음으로는 데이터베이스의 내용이었는데
트리구조의 대한구조 acc(pk)->(fk)acc(pk)char->(fk)char(pk)item
그리고 트랜잭션에 의한 데드락 발생 위험
하지만 이 또한 서버에서 매 동작에 대해 DB접근 하는게 아니라
행동에 대해 결과를 서버에서 연산 후, DB에 저장하기 때문에 최소화 시킬수있다.
OS에서 나왔던 저널링파일시스템처럼  DB작업하기전 로그를 남기고 
정상 처리되면 로그를 지우는 방식도 트렌젝션을 대체할수 있다고 소개한다.
보안 주의사항으로는
관리자만 직접 다룰수 있게, 예를들어 API와같은 어떤 접근이 필요하다면 
해당 API를 이용하는 데이터베이스 계정을 새로 두어 지정테이블을 
조회만 가능하도록 하는 방법을 추천한다
또한 데이터베이스는 중요 데이터이기 때문에, 물리적으로 네트워크를 분리하는 방법도 있고, 
방화벽을 이용해서 다른 포트나 아이피를 막는방법도 권장된다.
또한 sql인젝션을 방지하기위해 매개변수화된 질의구문을 적극 사용하자.
(운영툴 제작시에도 혹시라도 잘못 된 데이터를 넣을까봐 전부 매개변수를 이용했다.)
책에서  ORM이라는것도 소개하는데, 
데이터베이스 필드정의에 따라 클래스들이 생성되거나.
클래스를 정의하면, 데이터베이스가 생성되는
ORM (객체관계매핑) 기법을 간단히 소개한다.

추천
+데이터베이스 기초 도서 찾아보기 (튜닝의 정의나, 명칭등을 알려면 보긴 해야할듯.)
+제 1~3 정규화 테이블 설계 기초사용법 찾아보기 (이건 모르니까 찾아봐야겠다.)
+Join같은 다양한 종류의 질의구문 문법 익히기. (이부분은 쿼리튜닝과도 직결되기 때문이다.)


다음은 nosql을들어가면서
데이터의 분산방식중 수평분산방식인 샤드를 소개한다
샤드는 테이블의 데이타 A,B,C를 
DB에 각각 DB1->A   DB2->B 이런식으로 분산하는데,
데이터를 해시함수로 샤드 DB를 지정하거나, 
별도 테이블을 두어 해당 데이터가 어디에 있는지 파악할수있게하는 방식이다.
이 방법은 서버자체가 분산되지 않은상태에서 했다면 생소한 방식이다.
또한 이런 분산 처리를 하게되면 원자성과 일관성이 보장되어야하는데,
데이터분산락처리를 할수있다. 단점으로는 역시나 락으로인한 성능 저하이다.

그리고 언제 한번들어보기만 마스터-슬레이브  다중화를 소개한다.
DB를 2개를 두어 가용성을 올리는방식인데, Db1개가 죽어도 다른 Db를 이용하여 서비스를
중단없이 이어갈수 있는 장점이다.
하지만 데이터를 갱신하는 과정을 통보식으로 바꾼다고 해도, 결국엔 데이터가 아주 짧은시간,
동기화 되지않은 과거데이터인 스테일데이터를 가져올수 있다는 단점도 있다.

나머지는 몽고디비의 기능들이나 기초적인 쿼리구문을 소개해준다.
find, update, remove..등

다음으로는 분산서버 구조다
단일서버로 구성이 되어있는데, 동시접속자수가 무제한으로 증가할때를 가정해보았다.
네트워크에도 과부하가 걸리고, 프로그램 처리량도 느려진다.
느려짐에따라, 메모리가 증가되며, 증가된 메모리는 스와핑이되면서 (보조기억장치영역으로 메모리사용)
더욱 문제가 악순환이 발생한다.

그래서 분산을 하는 과정을 서술하였다.
단일서버에서 과부하가 일어나 분산처리 ㅎ해야하는 지점을 찾아 분산처리하는게 좋다고한다.
불필요한 분산서버로 오히려 개발이 힘들어 질수 있기때문이다.
*코드프로파일러
또, 가끔은 코드 최적화를 하면서 해결되기도 하기 떄문이다.

데이터분산과 기능적 분산
데이터분산- 게임서버를 여러개로 나눈것과 같다. (로아로치면 루페온,카마인, ...) 기능은 같지만 데이터를 분산시킴
기능적분산- 한 기능을 나눈것, 채팅서버, 매칭서버 등등 (기능이 분산되어 서버다운시 특정 기능만 다운)

혼용도 가능하다~!

로직처리의 분산을 소개한다.
동기처리 - 다른서버에 연산을 던져놓고, 대기하는방식 + Lock필요
->정확히 나오지는 않지만 블락이 되는건지.. 궁금하다
비동기처리 - 서버에 연산을 던져놓고 다른작업 (이전회사에서 캐시재화처리 같은?)
두방식에는 역시나 통신이 필요하기 때문에 실제 코드 연산보다 네트워크 오버헤드가 더 클수가 있다.\
데이터복제기반 로컬처리 - 서버간 데이터는 동일하지만 통보식으로 동기화 필요,
이전에 나온내용인 마스터-슬레이브관계처럼 짧은시간의 스테일데이터 문제가있다.
*하이젠버그 : 찾아보려고하면 바로 사라지는 버그 , 하이젠베르크의 불확정성원리를 재치있게 표현한말이라고한다 ..ㅋㅋ

데이터 응집도에 따른 데이터 분리 
한 서버에서도 지역별로 데이터를 서로 상호작용을 할 일이 없을 경우에 분리를 하는 방식
마찬가지로 매칭을 할때에도, 랭크별로 분산데이터를 나누는것(롤에서 실버와 다이아가 만나지 못하는것과 같은)

분산 처리방식에서는 꽤나 재밌는부분이 많았고,
또한 고민을 많이해야한다는것, 
데이터를 분산시켜 성능 향상이 있지만,
분산으로 인한 데이터 무결성, 네트워크 지연 고려, 설계의 복잡도 등
분산을 무조건적으로 하는게 아니라 조건을 따져가면서, 최후순위로 고려해야 한다고 생각했다.
그중 가장 관심이 갔던거는 마스터-슬레이브를 이용한서버 가용성에 대한 부분이었다.
궁금한점은 코드가 동일하다면 M에서 장애가 발생하면 통지를 하면서 S에도 똑같이 장애가 발생하지않을까?라는 생각이든다.

내일은 해당 책을 마무리하고, 다른책들을 이제 서브로 하고 포폴위주로 해야겠다.
이번주 금요일에는 또 시골에 내려가야해서 단순 독서로 마무리해야 할것 같다 (노트북이없음..)