파이널 프로젝트 - 13주차 2일(3/14)

최수환·2023년 3월 14일
0

Kubernetes

목록 보기
57/75
post-thumbnail

프로젝트 착수 보고서

주제 / 아이디어 , 주제 선정 배경

  • 이전 블로그에서 작성하였던 여행관련 아이디어에서
    타당성 , 차별점을 추가하고 구체화를 하여 아래와 같이 최종 아이디어를 도출해냈다.

포스트 코로나 이후 여행 수요가 폭발적으로 증가하고 있다. 개인맞춤형 비대면 여행 컨텐츠 플랫폼 개발을 통해 관련분야 기술 경험을 해본다.

  • 프로젝트 구성
    • 여행컨텐츠, 컨테이너 관리/운영 플랫폼, 서비스 모니터링 및 관리 플랫폼
  • 기능
    • 믿을만한 패키지 여행사들이 자신들의 패키지 여행을 웹페이지에 등록하여 사용자들은 원하는 테마의 패키지를 선택할 수 있다. 또한 해당 패키지가 맘에들어 선택한 인원들끼리 같이 여행을 갈 수도 있다.
  • 차별점
    • 클라우드 기반으로 동작하여 각 서비스 기능들이 표준인터페이스를 통해 상호연동하고 장애나 업데이트시 빠른 패치와 복구가 가능한 서비스를 제공한다.
    • 수많은 패키지 여행사들의 패키지 제품을 한곳에 모아놓고 사용자는 마음에 드는 패키지를 선택할 수 있다.
    • 해당 패키지를 선택한 모르는 사람들과 같이 여행을 갈 수 있다.
  • 구성 : 패지키 여행사가 제공하는 패키지, 신청인원수, 후기, 추천수

📒 서비스이름 : 어디갈래

팀원 및 역할 분담

개발 : 팀원 1명
CI/CD : 팀원 2명
Monitoring : 팀원 2명

  • 이 프로젝트에서 나는 CI/CD 파이프라인 구축(파이프라이닝, 자동화)을 맡기로 하였다.

프로젝트 일정

2023-3-13 ~ 2023-4-12

협업 툴

구축환경 / 사용 기술

  • 구축환경 : AWS를 이용하여 클라우드 환경에서 작업을 할것이고 최종적으로 EKS클러스터로 배포하는 것

  • 사용기술

    • 개발 및 웹 서버

    • 컨테이너 관련

    • 클라우드 관련

    • CI/CD 관련

    • 모니터링 관련

AS IS - TO BE

AS IS

  • 많은 패키지 여행 컨텐츠 플랫폼들은 쓸데없이 많은 홍보 문구와 정보들 그리고 함정 약정들로 인해 패키지 여행의 가장 큰 장점인 편의성과 신뢰성이 제공되지 않습니다. 또한 많은 사람들의 불편함은 많은 패키지 여행중에 많은 비교를 해보고 정한다음 큰마음을 먹고 결제까지 진행을 했는데 인원수가 모자라서 여행이 취소가 되는 경우에 혹은 인기가 많은 패키지의 경우 많은 접속으로 인한 서버의 오류로 예약이 제대로 되지 않는 점이 불편한 점으로 꼽힌다.

TO BE

  • 패키지 여행사중에 믿을만한 패키지 여행사들을 모아서 자체적인 심사를 한 이후에 서비스에 등록을 하게 함으로써 신뢰성을 높이고, 서비스 등록을 하는 패키지여행의 정보를 가공하여 가장 필요한 정보인 목적지, 가는 인원수, 날짜, 확정여부 등을 전면에 배치하여 접근편의성을 높인다.
  • 인원수가 모자라서 여행이 취소가 되는 상황을 방지하기위해 최소 인원수 표기를 하는 등 크라우드 펀딩 서비스의 아이디어를 가져와서 고객들의 불안을 제거할 수 있다.
  • 또한 클라우드 네이티브의 인프라를 적용하여 고객의 요구를 충족하기 위해 신속하게 업데이트할 수 있는 확장성, 유연성 및 복원력이 뛰어난 애플리케이션을 구축하여 인기가 많은 패키지 여행에서의 예약 시스템에서 서비스를 무리 없이 소화할 수 있다.

프로젝트 관리 방안

  • 깃허브를 통해 코드의 형상관리를 한다.
  • 젠킨스를 통해 코드의 지속적인 통합을 자동화한다.
  • 아르고cd를 통해 코드의 지속적인 배포를 자동화 한다.
  • 프로메테우스를 통해 컨테이너들및 시스템의 상태를 지속적으로 감시함으로서 안정적인 서비스를 돕는다.

파이프라인 아키텍처 설계

CI/CD 파이프라인의 대략적인 흐름도이자 설계도이다. 또한 간단하게 모니터링하는 서비스까지 추가해보았다.

  • 개발자가 Jenkins가 Scm Poll하고 있는 git에 개발한 코드를 Push하면 Jenkins는 Scm Poll을 통해 해당 코드를 가져와서 Test와 Build를 하게 된다.
  • 성공적으로 Build가 되었다면 결과물로 war파일이 생성되게 된다. 이 war파일을 배포하기 위해 Java기반의 web application인 Tomcat서버를 생성하고 Tomcat서버의 특정 디렉터리에 옮기는 작업을 하는 Dockerfile을 Git에 같이 넣어놓는다. 이후 Kaniko를 이용해 이 Dockerfile을 Build하여 이미지로 만든다.
  • 생성된 이미지를 Docker Hub에 Push한다.
  • Docker Hub는 배포용 Git에 연동되어 있고, 새로운 이미지가 Push가 되면 배포용 Git의 Deployment에서 기존의 이미지에 Sed명령을 통해 새로운 Image로 바꾼다.
  • 새로운 Image로 바뀐 Deployment를 ArgoCD가 감지하여 새로운 Image가 적용된, 즉 새로운 버전의 웹으로 Rolling Update를 통해 배포한다.
  • 추후에 계속 작업을 하면서 변경사항이 생기게 된다면 조금씩 수정해나갈 예정이다.
profile
성실하게 열심히!

0개의 댓글