[한이음 2022] MSA기반 인사 관리 시스템 Popool

본 게시글은 2022년 한이음 ICT멘토링 공모전의에 참여하여 Popool 서비스를 개발한 과정과 소개를 담고 있습니다.

Introduce

대규모 트래픽에 유동적으로 대응 가능한 Micro Service Architecture 를 이해하고 설계하며 Netflix의 Eureka와 AWS Elastic Banstalk 서비스를 활용하여 클라우드 네이티브한 형태의 아키텍처를 구현

Role

Devops Engineer & Backend Engineer

Spring Cloud Eureka와 Spring Config Server 그리고 Github Actions를 활용한 MSA 멀티모듈 배포에 집중

Architecture

AWS Service	Amazon Elastic Beanstalk
	Amazon Simple Storage Service
	Amazon Relational Database Service
Deployment Pipeline	Github Actions
Web Framework	Spring Boot
	JPA
	Spring Cloud Eureka
	Spring Cloud Config
	Spring Cloud Gateway

Feature

• 서버 모니터링 및 대용량 처리할 수 있는 기술
• Auto scaling을 통한 대규모 트래픽 대응
• Spring Cloud를 활용한 MSA 서비스 구현

Experience for Spring

• MSA 아키텍처에서 필요한 주요 프레임워크 학습
• Spring Cloud Eureka
  • MSA 아키텍처에서 고가용성 달성의 핵심 기능을 담고 있는 프레임워크
  • 새로운 서버가 생성되거나 사라지게 되면 Eureka에서 이를 모니터링 하다가 상황에 맞게 Self Healing 혹은 Scale Out을 쉽게 할 수 있도록 지원
  • 모듈별로 서버가 분리되어있는 MSA 특성상 모든 서버의 상태를 일일이 분석하고 모니터링하기 어려운 만큼 Spring Cloud Eureka를 사용해 자동으로 상태를 체크할 수 있도록 하는 중요한 역할
• Spring Cloud Config
  • MSA 아키텍처에서 보안 정보를 담고 있는 프레임워크
  • 같은 역할을 하는 서버임에도 불구하고 replica로 설정되어 서버가 Scale In & Out 되는 경우 각각의 서버가 다른 Config 정보를 담고 있는 문제 발생
  • Config를 로컬에서 관리한다는 가정하에 A서버와 B서버가 배포되어있는 상태에서 Config를 변경하고 C 서버를 배포하면 A,B,C 서버의 Config 내용에 균열이 발생
  • A,B,C 서버 모두 Spring Cloud Config를 통해 연결해 놓았다면 Config 필요시 네트워크로 불러와서 동일한 Config를 확보
  • Config내용은 Github Private Repository에 작성하고 Spring Cloud Config를 Github Private Repository를 바라보게 하여 Github Private Repository에서 보안정보를 매니징할 수 있도록 설정
• Spring Cloud Gateway
  • MSA 아키텍처에서 특정 Request를 Route 시켜주거나 인증 그리고 전후처리 등을 지원하는 프레임워크
    • 모듈화된 다양한 서버의 최상단에서 요청이 어떤 모듈로 진행되어야하는지 전달해주는 역할
    • 로드밸런서에서 Header에 Authentication 하여 사용자의 진입을 제한할 수 있는 것처럼 Spring Cloud Gateway 또한 인증 혹은 필터링 가능
    • Spring Cloud Gateway를 활용하여 OAuth 또한 활용 가능

Experience for AWS

• Amazon Elastic Beanstalk
  
  • AWS ElasticBeanstalk은 코드 업로드 만으로 애플리케이션을 AWS에 배포하는 과정을 자동화하여 용량 프로비저닝, 로드 밸런싱, 오토 스케일링, 애플리케이션 상태 모니터링 및 배포를 자동으로 처리하며 이를 통해 애플리케이션을 실행하는 데 필요한 AWS 리소스를 간편하게 제어
  • 모듈 별로 각각의 인스턴스를 생성하여 MSA 아키텍처의 핵심 모듈을 구현
• Amazon Simple Storage Service
  
  • AWS S3는 AWS 전용 Storage 서비스
  • Deployment Pipeline를 활용하였으며 AWS S3에 압축된 형태로 코드를 저장하고 코드를 버저닝
  • 이후 AWS S3로 부터 코드를 불러와 AWS ElasticBeanstalk에 배포
  • 적재된 코드는 압축되어있으며 버전 별로 관리가 용이
  • HTML + CSS + Vanilla.js를 사용하여 간단한 정적페이지를 구현 후 S3에 배포
• Amazon Relational Database Service
  • AWS RDS는 AWS에서 Fully Managed로 제공하는 데이터베이스 서비스
  • MariaDB Database로 생성하여 Spring Boot의 JPA와 연결하여 사용
  • ERD를 그려서 JPA에 엔티티를 생성하고 관련해서 Data Transfer Object를 만들어 Swagger에 연동하거나 Validation을 수행하고 모듈간의 결합도를 낮추기 위한 용도로 사용
  • JPA만으로 부족했던 정보는 QueryDSL을 반영하여 쿼리로 요청

Experience for Github Actions

• Github Actions 멀티 모듈 배포
  • Github Repository에 모듈 별로 폴더가 나뉘어져 있고 특정 폴더의 코드 변화가 발생했을때 배포하는 방식
  • 한개의 폴더에 각각의 Gradle 파일이 존재하여 모듈별로 Build 하는 과정을 따로 생성
  • Build하여 생성된 jar 파일을 찾고 해당 파일을 AWS Elastic Beanstalk에 이동시켜 실행하는 방식
• Github Actions Workflow 파일
  • .github/workflow 에서 yml 파일로 Deploy Pipeline을 구축
  • Docker를 활용하여 Github Actions 내부에서 Build 하는 과정을 수행
  • AWS IAM에서 제공하는 Access Token과 Secret Access Key를 발급 받아 Credentials 진행
• Github Actions Secret Key
  • Github Actions 내부에서 사용되는 보안 정보를 암호화 하기 위한 방법
  • Deploy Pipeline 툴 특성상 배포에 사용되는 민감한 정보들이 담길 수 밖에 없는데 이를 Github Actions Secret Key를 사용하여 처리
  • MSA 아키텍처의 경우 배포시에만 사용하였으며 중요한 정보는 Spring Cloud Config에 저장

Improvement

• AWS Code pipeline
  • AWS Code pipeline 서비스를 사용했다면 공통모듈을 보다 효율적으로 배포할 수 있다.
  • Github Actions에서 모듈을 브랜치 별로 나누어 진행했어도 보다 효율적인 파이프라인이 구축 되었을 것이다.
• 트래픽 부하 테스트
  
  • MSA 아키텍처 구성을 마친 후 트래픽 부하 테스트 툴인 Apache JMeter를 사용했으면 더욱 좋았을 것이다.
  • 본 테스트는 한정된 자원속에서 MSA를 유지하기에 너무 많은 비용을 필요로 했기에 중단되었다.
• Only Spring Boot Framework
  • MSA 아키텍처는 여러 프레임워크의 통신까지도 고려하여 제작된 아키텍처이다.
  • Spring Boot만 활용하여 해당 프로젝트를 마감한 것이 아쉽다.

Github

https://github.com/Backble/popool