진행 상황

여행도 다녀왔고 5차 회의 이후 2번의 회의가 더 있었다.
마지막 회의인 1/3 까지의 내용을 우선 정리해보면,

1. Plugin & TexturePack & Map

플러그인은 게임 내부에서 특정 기능들을 활용할 수 있게 만들어주는, 일종의 java 모듈들의 집합이다. 게임 내에서 포탈 이동, 경제라는 개념을 만들어주기도 하며, 유저 차단, 귓속말 등 다양한 기능들을 만들 수 있다. 외부에서 가져오는 플러그인이 많기 때문에, 쓰기 쉽게 번역 작업을 진행해주었고, 플러그인끼리 충돌이 발생하는 부분은 수정을 해주었다. 또한 java를 이용해 일부 플러그인은 제작하였다.

텍스쳐팩은 게임 내의 스킨같은 것 이다. 일종의 UI 및 그래픽을 변경시켜주는 템플릿같은 느낌이라고 해야할까나.. 기존에 있는 텍스쳐팩의 코드를 약간 수정하여 우리 서버만의 느낌으로 제작하였다.

맵은 현재 컨셉을 잡고, 제작중에 있다. 맵 에디터를 활용해서 어떻게하면 유저 입장에서 불편함 없이 이용할 수 있고, 호기심이 생길만한 맵을 제작할 수 있을지 항상 고민하며 제작하고 있다.. 쉽지 않지만 이번주 내로 마무리 지으려 한다.

이 3가지는 모두 끝나면, 한번에 정리해서 올리겠다.

2. 서버 이주?..

12월 29일에 이사를 했다.
이사한 집은 LG 인터넷을 사용하기 때문에, 고객센터에 전화해서 고정 ip도 할당받고, 네트워크 설정부터 os 설정까지.. 생각보다 시간이 좀 걸렸다. (그래서 글이 뜸했던건 안 비밀..) 이제는 인프라 관련 세팅은 거의 끝났다고 판단해서, 본서버 용도로 사용할 것이기 때문에 신중하게 환경 구축을 마무리했다.

3. 웹 개발 시작

아직 템플릿에 간단한 시각화만 띄우는 수준이기는 하지만,
웹을 본격적으로 다루기 시작했다. 3명 다 웹 부분은 잼병이라.. 아직 갈 길이 멀다. 계속 공부하고 있으니, 진전이 있다면 그 때 글로 올릴 예정이다.

4. etc

• 관리자 그룹, 보안 세팅 완료
• 메인보드 자체의 rtc 부팅, centos systemd를 사용한 컴퓨터 자동 on/off 주기 설정
• 디스코드에 올라오는 서버 로그 및 서버 현재 상태를 조금 더 보기좋게 다듬었음. 추후 웹에서 다루기 쉽게 하기 위한 일종의 전처리 느낌
• 웹서버 도메인 연동
• cockpit을 이용한 서버 모니터링 시스템 구축

---

아직 진행중인 부분이 많아서 글로 정리하기는 너무 많기 때문에,
오늘은 저번 글 이후로 진행했던 부분 중 Cockpit을 이용한 서버 모니터링 환경 구축과 서버 on/off 자동화 설정에 대해 다뤄보려한다.

---

서버 모니터링 시스템

Cockpit이란?

Cockpit은 Linux Server Monitoring을 위한 Tool이다. GNU/Linux Server용으로 사용하기 쉽고, 가볍고 간단한 원격 관리자로써, 웹 브라우저를 통해 Live Linux Session을 제공하는 대화형 서버 관리 사용자 인터페이스다.

Debian 계열과 RHEL 계열 뿐만 아니라, Arch 계열 Linux 배포판에서도 이용할 수 있다. 또한, 사용자는 번거로움 없이 Linux 터미널과 웹 브라우저 사이를 쉽게 전환할 수도 있다.

서버 모니터링 시스템을 구축해야하는 이유?

다양한 이유가 있겠지만.. 우리가 구축한 이유는 다음과 같다.

1. 성능 최적화
   모니터링을 통해 시스템의 성능을 추적하고 분석하여, 병목 현상이나 성능 저하의 원인을 파악한다. 이를 통해 최적화 작업을 수행하여 더 효율적인 운영이 가능.

2. 비용 관리 및 최적화
   리소스 사용량을 모니터링하여 필요없는 서버 리소스를 줄이고 불필요한 비용을 절감할 수 있다. 효율적인 자원 할당은 비용을 절감하고 ROI를 향상시킬 수 있다.

3. 예측 및 예방
   향후 장애나 문제를 예측하고 예방할 수 있다. 성능 데이터를 분석하고 경향을 모니터링함으로써 미래의 문제를 예측하고 대비.

추가로 개인적인 이유로는, 일단 Cockpit은 무료다. (사실 이게 중요,,) 그리고 이전 클라우드를 공부할 때 AWS cloutwatch 서비스였던 걸로 기억하는데, ec2 서버의 모니터링을 제공하는 서비스를 사용한 경험이 있다. UI 기반으로, 직관적으로 그래프 방식으로 볼 수 있다는 것이 굉장히 편리했다. 로컬에서 작동하는 우리 서버 역시, CLI 기반으로 서버의 현재 상태를 Live로 파악하는 것보다는 해당 방식처럼 모니터링 시스템이 따로 있는 것이 좋을 것 같다 판단하여 서비스를 구축해보았다.

---

과정

설치 과정은 매우 간단하다.
로컬 pc에서 root 계정으로 접속한 후,

yum install cockpit

cockpit을 설치.

enable --now cockpit.socket

cockpit 서비스를 활성화시킨다.

firewall-cmd --add-port=사용할포트/tcp --permanent
firewall-cmd --reload

기존 cockpit 서비스는 9090포트를 사용한다.
우리는 포트를 바꿔서 사용하였기에 방화벽도 다른 포트로 지정해주었다.
이후 포트포워딩 설정 및 특정 ip에서만 접속할 수 있도록 설정도 해주었다.

vi /usr/lib/systemd/system/cockpit.socket

다음 명령어로, cockpit 소켓을 열어 포트 설정도 해주었다.
(예시 이미지)
ListenStream 값을 수정해주면 된다.

추가적으로, google otp 설정도 해주었다.

vi /etc/pam.d/cockpit

cockpit에 로그인 할 때, ssh에 로그인할 때 2차 인증을 묻는 것 처럼 하도록 설정해주었다.

앞의 모든 설정까지 끝났다면, cockpit 서비스를 시작해준다.

systemctl start cockpit

실행이 잘 되고있다.

실행 모습

설정한 포트와 ip로 접속하면 다음과 같은 화면이 뜬다.
username과 password를 입력. (모니터링용 관리자 계정을 따로 생성해주었다. 간단한 부분이라 생략)

원래는 바로 넘어가야하지만, 2차 인증을 묻도록 설정해두었기에 2차 인증을 위한 코드를 물어본다.

메인 화면과 메뉴바에 다양한 기능들이 있다.
사실 이 기능은 몇 일 전에 구현했는데, 여러 테스트에 유용하게 사용하고있다.

Services 메뉴에 들어가면, 현재 실행중인 서비스 목록도 볼 수 있다. minecraft 서비스가 잘 돌아가고 있다고 한다.

터미널도 사용할 수 있다. SSH로 작업하기에, 잘 사용할 것 같지는 않다.
(뭔가 SSH가 보안 더 좋을 것 같달까나...)

사실 이 기능은 구현한지 몇 일 되었는데, 여러 방면에서 유용하게 사용하고 있다. 기능이 많지는 않지만, 그래서 더 우리 수준의 서버에는 맞지 않나.. 싶다.

main 서버 설정 이후, db서버도 같은 방식으로 환경을 만들어주었다.

---

서버 ON / OFF 자동화

앞에서도 언급했지만, 서버를 이주하게되면서 pc를 2대 사용하기로 했다.
하나는 main 서버 용, 다른 하나는 db 서버 용도로. 개발 측면에서도 그렇고, 이후 서버를 운영한다면 휴지기도 필요하기에 on/off 시간대를 정하여 자동화시키는 기능을 만들 필요가 있다고 생각했다.

아직 정식으로 서버를 오픈하지는 않았기에, 우리 팀원들이 주로 작업하는 시간대인 낮 12시 ~ 오전 6시 기준으로 자동으로 켜지고 꺼지도록 설정했다. (아침형 인간이... 아니다)

과정

게임 서비스가 실행중인 상태에서 DB가 꺼져있다면, 혹은 켜지거나 꺼지고있는 중이라면, 치명적인 오류가 생길 수 있기 때문에 (사실 이미 몇 번 있었다) DB서버와 메인 게임 서버, 두 서버의 실행 시간에 약간의 차등을 주었다.

• 메인 게임 서버 : 12:00:00 ~ 06:00:00
• DB 서버 : 11:55:00 ~ 06:05:00

5분씩 차이를 두어, DB 서버가 항상 조금 더 일찍 켜지고, 조금 더 늦게 꺼지게끔 설정해두었다.

1) OFF 설정

#!/bin/bash

systemctl stop minecraft

# sleep 4m

shutdown -h now

minecraft_shutdown.sh 스크립트 파일을 다음과 같이 만들어주었다.
너무 간단하기는 한데.. 굳이 설명하자면,
systemctl 명령을 통해 우선 minecraft 게임 서비스를 종료하고,
보통 종료할 때 평균적으로 1분정도 걸리기에(백업 서비스까지 포함되기 때문) 넉넉하게 4분정도 텀을 두고, shutdown 명령어를 사용하여 pc를 종료해주는 script이다.

이후 /etc/systemd/system 경로로 이동하여 2개의 서비스를 만들어준다.

minecraft_shutdown.service

[Unit]
Description=Minecraft Shutdown Service

[Service]
Type=simple
ExecStart=/home/hostadmin/scripts/minecraft_shutdown.sh # 서비스가 실행되면 해당 스크립트 파일을 실행하게끔 설정

[Install]
WantedBy=default.target

minecraft_shutdown.timer

[Unit]
Description=Schedule Minecraft Shutdown

[Timer]
OnCalendar=*-*-* 06:00:00	# 매일 06시에 트리거 설정
Persistent=True				# 항상 적용되는 타이머. 일종의 enable 느낌
Unit=minecraft_shutdown.service	# 타이머가 작동되면 해당 서비스를 실행

[Install]
WantedBy=timers.target

구조는 매우 간단하다.
service는 script를 실행하는 서비스로 만들고,
타이머 설정을 하여 service를 실행하는 타이머를 만드는... 그런 단순한 작업이였다.

systemctl enable minecraft_shutdown.timer
systemctl list-timers

타이머를 활성화시킨 후, 타이머 리스트를 출력하면

다음과 같이 시간 설정이 잘 된 것을 확인할 수 있다.

2) ON 설정

pc를 켜는 부분은 2가지 방법으로 설정해두었다.
하나는 이전 기록하였던 WOL 방식. 해당 방식은 아마 갑자기 서버가 꺼졌다던가 하는 비상 상황에만 사용할 것 같다.

다른 방식은 RTC 방식이다. 메인보드에서 간단하게 설정할 수 있다.

간단한 예시 이미지를 가져왔다. (Days) 부분만 매일 실행되도록 할 것이니 0으로 수정해주고, 원하는 시간을 설정하면 해당 시간에 맞춰 컴퓨터가 켜진다.

매우 간단한 설정이였지만.. 이 기능 역시 매우 유용하게 사용하고 있다. 일일이 컴퓨터 켜야할 일 없으니 좋다.

---

추후 회의 일정 (1/13)

다음 회의는 다음주 토요일인 1/13에 진행하기로 했다.

아마 당분간은 업로드가 좀 뜸할지도 모르겠다. (사실상 지금 해야할 부분이 기획의 영역이랄까..) 인프라는 어느정도 마무리되었기에, 게임 내부에서 설정해야 할 부분들이 우선인 상황이되었다.

혹시 추가적으로 사용하는 기술이 있다면, 언제든지 정리해서 업로드할 예정.

다음주 or 다다음주까지 게임 세팅이 끝난다면,

웹 제작 & QA 초기 설정 -> 디스코드 유저용(접속 2차 연동 등) -> 웹 backend 연동 마무리 -> 게임 규칙 및 이벤트 기획 등

대략적으로는 이런 순으로 개발 일정이 진행될 것 같다.