[무작정 게임 퍼블리싱 플랫폼 구축기] 4. 서버 터지기 싫으면 바꿔야해

게임이 늘어난 이후에는 자연스럽게 서버도 더더더 늘어났습니다.

사용자가 늘면 서버를 늘린다!

스케일 아웃을 통해 게임별로 서버를 지정하여 dns기반의 로드밸런싱을 하였습니다.

스케일 아웃(Scale-Out)은 시스템이나 서비스의 부하를 분산시켜 처리 능력을 확장하는 방법입니다. 이를 위해 추가적인 서버나 자원을 사용하고, 부하 분산을 위한 로드 밸런싱(Load Balancing) 등의 기술이 사용됩니다. 스케일 아웃 방식을 사용하면, 대규모 트래픽이나 다수의 요청을 처리할 수 있으며, 시스템의 가용성과 성능을 향상시킬 수 있습니다. 스케일 아웃은 대부분 수평적 확장(Horizontal Scaling)으로 이루어지며, 서버를 추가하는 것이 주요 방법 중 하나입니다.

 

설명을 너무 잘해주니 글에서 설명할 필요가 없군요 

DNS 로드 밸런싱(DNS load balancing)은 서버의 부하를 분산시키기 위한 방법 중 하나로, DNS(Domain Name System)를 이용하여 여러 대의 서버 IP 주소를 반환하고, 클라이언트는 해당 IP 주소 중 하나를 선택하여 서버에 접속하는 방식입니다.

일반적으로, DNS 서버는 클라이언트의 DNS 쿼리를 받으면, 해당 도메인 네임의 IP 주소를 반환합니다. DNS 로드 밸런싱에서는, 이러한 DNS 서버에서 도메인 네임의 여러 IP 주소 중 하나를 랜덤하게 반환하거나, 혹은 특정 규칙에 따라 선택하여 반환합니다. 클라이언트는 이러한 IP 주소 중 하나를 선택하여 서버에 접속하면 됩니다.

이러한 방식으로 DNS 로드 밸런싱을 구현하면, 서버의 부하를 분산시키고, 네트워크 장애나 서버 다운 등의 문제가 발생했을 때 다른 서버로 자동적으로 전환하는 등의 기능을 구현할 수 있습니다. 또한, 서버를 추가하거나 제거할 때 DNS 레코드를 수정하는 것만으로도 쉽게 서버를 추가하거나 제거할 수 있어, 유연한 서버 관리가 가능합니다.

하지만, DNS 로드 밸런싱에는 몇 가지 단점이 있습니다. 예를 들어, 클라이언트가 DNS 결과를 캐시하고 있을 경우, DNS 레코드를 변경했을 때 클라이언트에 적용되기까지 일정 시간이 소요될 수 있습니다. 또한, IP 주소를 랜덤하게 반환하는 방식은 서버 부하가 고르게 분산되지 않을 수 있어, 서버 부하가 불균형하게 발생할 수도 있습니다.

플랫폼의 db부하 분산을 위해 데이터베이스도 duplication으로 이중화 하였습니다.

데이터베이스의 duplication(복제)은 주로 데이터를 안전하게 보호하기 위해 사용됩니다.

복제는 데이터베이스의 일부 또는 전체를 다른 위치의 데이터베이스에 복사하는 프로세스를 의미합니다. 이렇게 복제된 데이터베이스는 원본 데이터베이스와 동기화되어 있어, 원본 데이터베이스에 문제가 생길 경우에도 백업 데이터베이스를 사용하여 서비스를 유지할 수 있습니다.

복제는 데이터베이스의 가용성과 확장성을 높여주며, 사용자들이 데이터에 더 빠르게 접근할 수 있도록 지원합니다. 또한, 부하 분산을 통해 서비스를 더욱 안정적으로 운영할 수 있게 됩니다.

복제는 데이터베이스 관리에서 중요한 역할을 합니다. 하지만, 복제를 사용할 때는 데이터의 일관성과 동기화 문제를 고려해야 하며, 불필요한 복제는 성능 저하나 비용 증가의 원인이 될 수 있습니다. 따라서 데이터베이스 복제는 신중하게 고려해야 하는 기술입니다.

윈도우 서버들도 이때 리눅스로 교체했지요

지금에 와서 느끼는 것이지만 베어메탈을 받아

필요한 권한과 소프트웨어를 설치하고 쉘스크립트를 작성하는 작업을 매번 하면서

고통을 느꼈고 그 고통이 개선을 위한 욕구를 자극하지 않았나 싶습니다. 

서버가 늘어났어요

그럼에도 아키텍처적으로는 큰 진전은 없었는데

당시의 문제점을 짚어보면 크게 세가지였습니다.

첫번째로 많아진 서버의 관리 및 배포이슈였습니다.

두번째는 경험에 기반한 부하 분산이었습니다.

예상치 못한 공격이나 이벤트 트래픽을 감당하기엔 지금의 구조는 적합하지 않았습니다.

세번째는 DB이슈가 종종 일어나는 문제였습니다.

slave에 write가 발생하여 싱크가 깨지는 일이 종종 일어났습니다.

짧은 영어지만 일단 외국회사라..

이러한 문제점을 해결하고자 구조의 개선을 시도하였습니다.

자동화된 빌드와 배포를 위해 젠킨스를 도입하였고,

nginx를 배치하여 로드밸런싱을 시도하였습니다.

또한 모든 노드가 마스터가 될 수 있는 클러스터 구성을 시도하였습니다.

그 외에도 개발 웹서버의 성능 튜닝, 데이터베이스의 인덱스 튜닝, API의 응답속도를 늘리기위한

튜닝등을 진행하였습니다.

그리고 캐시서버의 도입과, 많아진 세션서버를 기존에 쿠키로 공유하던것을

Redis를 도입하여 세션서버를 구축하였습니다.

마지막으로 ddos공격을 막아주는 cloudplare라는 서비스를 도입하여 최상단에 배치하였습니다.

처음 보다는 나아졌지만 아직..

DB는 갈레라 클러스터를 처음으로 적용하고 많은 삽질을 했던 것 같습니다.

https://cusmaker.tistory.com/243

[CentOS] MariaDB 설치 및 Galera Cluster 구성

클러스터 구성이후에도 싱크는 replication 구조 못지 않게 너무 자주 깨지기도 했고

장비에 대한 메트릭 알림 구성도 없어서

하루종일 디스크 다찬줄도 모르고 연결과 복구를 8시간동안 반복했던 슬픈 기억이 있습니다.

 

이때가 1년쯤 지나고 나서의 모습이었던것 같습니다.

그동안에 크고 작은 이슈들을 겪으면서 장애에도 조금씩 익숙해지기 시작했습니다.

어느정도 경험치도 누적되고 여유가 생기니 

다른 개선할 포인트들을 찾기 시작했습니다.

다음글로 이어집니다.

https://cusmaker.tistory.com/265