이제는 모양이 제법 갖춰져가고
새로운 게임을 붙일때면 반복적인 일에 지루해 질때쯤
아키텍처 개선에 대한 욕구는 늘어갔습니다.
우선 제가 원하던 방향에 있어서 의식의 흐름에 의하면
개발자가 어떤 기능을 개발하면 잘 작동하는 코드리뷰와 TDD속에서
바로바로 배포하고 반영하는 애자일스러움을 지향하고자 기도 했는데요
애자일(Agile)은 소프트웨어 개발 방법론 중 하나로, 요구사항이나 환경의 변화에 유연하게 대처하며, 고객의 요구사항에 더 빠르게 대응하기 위한 방법론입니다.
애자일 방법론은 원활한 소통, 지속적인 피드백, 자가조직화 등을 중요한 가치로 여기며, 빠르게 변화하는 비즈니스 환경에서 고객의 요구사항 변화에 빠르게 대처할 수 있도록 합니다. 이를 위해, 애자일 방법론은 짧은 주기로 반복되는 개발 단계를 강조하며, 이를 '스프린트(Sprint)'라고 합니다.
애자일 방법론에는 여러 가지 종류가 있지만, 가장 널리 알려진 것은 스크럼(Scrum) 방법론입니다. 스크럼 방법론은 팀의 자율성을 강조하며, 개발 과정을 다음과 같은 세 가지 역할로 구성합니다. 프로덕트 오너(Product Owner), 스크럼 마스터(Scrum Master), 개발 팀(Development Team)
애자일 방법론은 빠르게 변화하는 시장에서 고객의 요구사항에 빠르게 대응할 수 있는 방법론으로, 최근에는 소프트웨어 개발 뿐만 아니라 다양한 산업 분야에서도 적용되고 있습니다.
하지만 실상은 이것 저것 기능들을 덕지 덕지 붙이느라 백엔드는 비대해졌고,
이런 비대해진 모놀로틱 백엔드는 배포에 부담을 갖게하므로, MSA로 쪼개야할 필요가 있었습니다.
모놀리틱(Monolithic) 백엔드는 소프트웨어 아키텍처의 한 종류로, 하나의 애플리케이션에서 모든 기능을 수행하는 단일 서비스입니다.
일반적으로 모놀리틱 백엔드는 큰 규모의 애플리케이션에서 사용됩니다. 이 구조에서는 데이터베이스, 프론트엔드, 백엔드, 로그인 등의 기능이 하나의 애플리케이션으로 통합되어 있으며, 이로 인해 애플리케이션의 배포와 유지보수가 간편해집니다.
하지만 모놀리틱 백엔드는 애플리케이션의 크기가 커지면서 유지보수, 확장성, 테스트, 배포 등의 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해 최근에는 분산 시스템 아키텍처인 마이크로서비스(Microservices) 아키텍처가 더 많이 사용되고 있습니다.
마이크로서비스 아키텍처에서는 서비스가 작은 기능 단위로 분리되어 있으며, 각 서비스는 독립적으로 개발, 배포, 유지보수가 가능합니다. 이러한 아키텍처는 유연성과 확장성이 뛰어나지만, 동시에 관리할 수 있는 서비스의 개수가 많아짐에 따라 복잡도가 높아지고, 개발자들이 전체 시스템을 이해하고 있어야 하는 부담이 생길 수 있습니다.
MSA로 쪼개려면 당연히 서버도 쪼개져야했기에, 이전방식처럼 서버에 매번 셋팅하는것이 아닌,
Dockerize를 통한 컨테이너 배포를 해야했고, 이를 위해선 그에 맞는 Cloud환경도 필요했습니다.
마침 당시 MS Azure를 사용할 기회가 있었으나,
지금 AWS처럼 성숙하지 않았던 시기라, 단순 EC2장비를 받아서 프로비저닝하는작업에도 많은 오류들이 있었던 기억이 납니다. (비용도 저렴하지않았고..)
DB의 경우에도 데이터가 쌓여가는걸 보자니 뿌듯하기도 하지만
언제 터질지 모른다는 불안감이 있었습니다.
이를 위해 파티셔닝이나 샤딩을 고민하기도 했습니다.
파티셔닝(Partitioning)과 샤딩(Sharding)은 데이터베이스의 성능을 향상시키기 위해 사용되는 기술입니다.
파티셔닝은 데이터베이스의 큰 테이블을 작은 조각으로 나누는 기술로, 하나의 테이블을 여러 개의 작은 테이블로 분리하여 여러 대의 서버에 분산하여 처리합니다. 이렇게 파티셔닝을 적용하면 데이터 처리 속도와 확장성이 향상되며, 데이터를 저장하는 서버의 용량 한계를 극복할 수 있습니다.
샤딩은 파티셔닝의 일종으로, 대규모 데이터베이스를 여러 개의 물리적인 서버에 나누어 저장하는 기술입니다. 각 서버에 저장되는 데이터는 일정한 규칙에 따라 분할되어 저장됩니다. 이렇게 샤딩을 적용하면 데이터베이스 서버의 부하 분산과 데이터 처리 속도 향상, 확장성 등의 이점을 얻을 수 있습니다.
파티셔닝과 샤딩은 데이터베이스의 성능을 향상시키는 기술로 중요하지만, 사용할 때에는 장단점과 구현 방법 등을 고려하여 적절한 선택이 필요합니다. 또한, 샤딩을 사용할 경우 데이터 일관성과 분산 시스템의 복잡도 등에 대한 고민이 필요합니다.
쌓인 데이터를 가지고 당시 알파고로 한창 붐이었던 AI를 활용하여
유저의 이탈 흐름 지점을 계산하고 해당하는 지점에 컨텐츠를 보완하여 리텐션을 올리는등의
상상은 상상으로만 남겨두었습니다.
아키텍처에도 정답이 있는 것은 아니라고 생각하지만
상황적으로 이런 필요에 의해 변화하는 것이라 생각했고
이를 뒷받침해줄 여유가 생긴다면 해보고 싶었지만
아쉽게도 상황은 그렇게 흘러가지 못했습니다.
모든건 핑계였다.
그리고는 한국으로 돌아오기 위해
다음 사람을 위해 문서화에 돌입하게 됩니다.
문서화도 개발만큼 중요한 작업이죠
다음 내용에서는 문서화에 대한 내용으로 이어가보겠습니다.
다음글 : https://cusmaker.tistory.com/267
[무작정 게임 퍼블리싱 플랫폼 구축기] 7. 모두를 위한 문서화
시스템에 대한 이해나 경험이 소수의 인원에게만 의존하는 것은 기술 부채라고 생각합니다. 그만큼 기존 인원이나 새로온 사람 모두가 이해할 수 있는 자료가 있고 없고는 업무 효율에 굉장히
cusmaker.tistory.com
'커리어' 카테고리의 다른 글
| [무작정 게임 퍼블리싱 플랫폼 구축기] 0. 목차 (1) | 2023.04.16 |
|---|---|
| [무작정 게임 퍼블리싱 플랫폼 구축기] 7. 모두를 위한 문서화 (2) | 2023.04.16 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 5. 개선 포인트를 찾아보자 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 4. 서버 터지기 싫으면 바꿔야해 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 3. 사이드 프로젝트도 틈틈히 .. (0) | 2023.04.08 |
