ji-water commented 4 years ago

회의 내용

아키텍처

server - java springboot
client - react
DB - mysql
proxy - NGiNX

목표 설정 다듬기

목표 설정 예제)

[프로젝트 구현 조건]
1. 웹 서비스로 구현
2. Java언어 기반 스프링부트 프레임워크 사용
3. 팀원간의 협업 체계 갖추기
4. 프로젝트 프리징 이후에 시간이 "N"주 이상 남을 경우 +@ 구현하기

[팀 목표]
1. 준비된 협업 체계를 바탕으로 개발하여 "***********" 달성 하기
2. 정해진 스케쥴에 프로젝트 끝까지 완성하기
단, 완성 자체만으로 목적이 되지 않도록 일정, 팀빌딩, 팀워크에 대한 고민을 프로세스로 반영
3. 2번 목표를 위해서 Daily 미팅 진행해보고 

[개인 목표]
지원
1. 이번 프로젝트 기간에 1일 1커밋
2. 스프링 MVC패턴이 가지는 특징을 이해하여 설명할 수 있도록 하기
3. Mybatis 및 어노테이션 숙지하고 익숙해지기
4. Notion을 통해 하루동안 진행한 내용을 매일 정리 및 기록하기

지혜
1. Git으로 프로젝트에 버전관리, 이슈관리 활용하여 상황에 맞는 레파지토리 의미 찾기
2. 단순 지식 습득을 넘어 스프링부트 프레임워크 개념 이해하고 개발하기
3. 공부한 내용과 이해한 내용 구분하여 wiki 정리하기

윤형
1. 추천 시스템 이해하고 개발하기
2. Source Tree 이해하고 활용하기

git 관련

1. 2.

인증서버 jwt - 추가적 저장공간 필요x stateless server 지향 https://jwt.io/ (사용언어마다 라이브러리 설치가능)
아키텍처 예제

mojh7 commented 4 years ago

1. Git Workflow

TODO

[ ] 팀원들 이전 프로젝트 경험에서 Git 활용 정도 확인
[ ] Git Branch 사용 유무 정하기
[ ] Git Branch 사용할 경우 Git Branch 전략 세우기
[ ] Git Flow vs GitHub Flow vs GitLab Flow
우형 기술 블로그 글에서 개발자들은 작업을 시작하기 전에 Jira 티켓을 생성한다고 한다. ( Jira = 이슈 & 프로젝트 트래킹 소프트웨어 ) 우리 팀 목표 달성을 위해서 Jira 써보는 것은 우선순위 밀리지 않나 싶다. Git & Jira 연동이 되고 좋은 기능들이 있을 것 같긴 한데 Jira로 관리하는 것 자체가 작업량이 있어 보이면 Git Issues랑 Git Projects로 간단하게라도 관리하는 게 낫지 않을까 싶다.

참고

- Git Flow + [우형 기술 블로그](https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html) + [Git flow를 사용해 보자!](https://yujuwon.tistory.com/entry/GIT-FLOW-git-flow%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%B4-%EB%B3%B4%EC%9E%90) - Git + [초심자를 위한 Github 협업](https://milooy.wordpress.com/2017/06/21/working-together-with-github-tutorial/) - [Git Flow vs Github Flow](https://www.freshconsulting.com/git-development-workflows-git-flow-vs-github-flow/) - [Git, GitHub, GitLab Flow](https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/) - [Git을 이용한 협업 플로우](https://lhy.kr/git-workflow)

===

TODO2 - 좀 급하게 씀.

[ ] 각자 이전 프로젝트에서 사용했던 기술 스택 확인
[ ] 구체적으로 관심 가지는 언어, 프레임워크, db 등등 관심 기술 스택 확인
[ ] 팀원 일정 재확인

DB 모델링, 정규화

스케일 업, MSA 등등 여러 가지를 고려하여 아키텍처를 구성할 때 기존의 서비스를 보고 언제 어디서 어떻게 부하가 생기거나 병목 현상이 발생하거나 가정하여 고민하면 좋을 듯 게시판 만들기 프로젝트랑 크게 안 다를 것 같기도 해서 위의 고민을 바탕으로 실제 서비스 한다는 가정하에 발생할 문제를 대비하여 아키텍처를 구성하고 개발을 해보는 게 서버개발캠프 참여하면서 많은 배움을 얻어갈 수 있지 않을까? 생각

실제 서비스를 진행한다는 상황속에 고민하며 프로젝트 진행

ex

트래픽 몰리는 시간 출근, 퇴근, 웹툰 정기 업로드 시간 밤 11시~01시 쯤?(네이버 요일연재 기준)

이미지 저장, 이미지 압축 알고리즘

질문 거리 일부러라도 만들어 보기?

의도적으로 프로젝트, 아키텍쳐 등등의 질문거리를 미리 만들어보고 내용 찾아보고 서로 얘기해보고 정 모르겠다 싶은 것은 피드백을 통해서 답을 얻고, 내용 정리

이후에 있을 수도 있는 발표, 포트폴리오 관련 질문, 면접 대비

mojh7 commented 4 years ago

아키텍쳐, 프레임워크, 용어, 키워드 기타 등등

WS와 WAS

웹 서버 : 정적 컨텐츠(.html, .png, .css등)를 제공하는 서버

웹 어플리케이션 서버 : 동적 컨텐츠를 제공하기 위해 만들어진 애플리케이션 서버 (DB조회, 로직처리가 요구되는 컨텐츠)

HTTP 프록시와 웹 서버 기능

- 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능. - 캐싱을 통한 리버스 프록시 - 로드 밸런싱 - 고장 진단 - SSL 지원 - 캐싱을 통한 FastCGI 지원 - Name-, IP-기반 가상서버 - FLV 스트리밍 - MP4 스트리밍 모듈을 이용한 MP4 스트리밍 - 웹페이지 접근 인증 - gzip 압축 - 10000개의 동시 접속을 처리할 수 있는 능력 - URL 다시쓰기 (URL rewriting) - 맞춤 로깅 - 서버 사이드 기능 포함 - WebDAV

Ngnix	아파치 HTTP 서버
가벼움과 높은 성능을 목표로 한다. 웹 서버, 리버스 프록시 및 메일 프록시 기능을 가진다.
비동기 이벤트 기반 구조	스레드/프로세스 기반 구조

참고

- [WAS 와 웹 서버 차이 (WAS,Web Server) 그리고 아파치, 톰캣](https://jeong-pro.tistory.com/84) - [Ngnix 위키 백과](https://ko.wikipedia.org/wiki/Nginx)

Ngrinder

네이버에서 성능 측정, 부하 테스트 목적으로 jython(JVM위에서 파이썬이 동작)으로 개발 된 오픈소스 프로젝트

참고

- [[nGrinder]nGrinder란? & docker 설치 방법](https://brownbears.tistory.com/25) - [nGrinder 시작하기](https://nesoy.github.io/articles/2018-10/nGrinder-Start)

CI(지속적인 통합) & CD(지속적인 배포)

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "통합 지옥(integration hell)")를 해결하기 위한 솔루션

CI (Continuous Integration)

코드 버전 관리를 하는 VCS 시스템에 PUSH가 되면 자동으로 Test, Build가 수행되고 Build 결과를 운영 서버에 배포까지 자동으로 진행되는 이 과정을 CI (지속적 통합)이라고 합니다.

Build , Test를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시해 주는것을 CI라고 합니다.

CD (Continuous Delivery or Continuous Deploy)

지속적인 서비스제공, 지속적인 배포로 짧은 주기로 개발중인 소프트웨어를 배포하고 그 과정을 자동화 하겠다는 뜻.

로컬 PC에서 Java 코딩 -> git push -> Travis Ci로 build error 체크 -> 실패 경우 stop 성공한 경우 -> Build 결과를 AWS S3 전달, AWS S3에서 AWS CodeDeploy를 통해 EC2 배포 Amazon EC2에서 Ngnix를 통해 무정지 서비스?

Jenkins의 경우 설치형이라 EC2 하나 더 써야 됨.

참고

- [우형 블로그 - 라이더스 개발팀 모바일에서 CI/CD 도입, 젠킨스 & 도커 & 슬랙](https://woowabros.github.io/experience/2018/06/26/bros-cicd.html) - [CI/CD란 무엇일까요?](https://www.redhat.com/ko/topics/devops/what-is-ci-cd)

무정지 서비스, 무중단 배포

[스프링부트로 웹 서비스 출시하기 - 7. Nginx를 활용한 무중단 배포 구축하기] (https://jojoldu.tistory.com/267?category=635883)

무중단 배포 전체 구조

Scale Up, Out

일종의 Scale UP : 사양 추가, Scale Out : 장비 추가 웹사이트의 접속자가 증가하는 경우 scale out이 효과적. 세션의 숫자가 폭발하는 경우 scale up은 많은 효과를 기대할 수 없음. 많은 경우 비용이 적게 드는 scale out이 더 효과적 그렇지만 OLTP(온라인 트랜잭션 처리)가 빈번한 데이터베이스의 처리를 위해서는 scale up이 더 효과적이다.

로드 밸런싱

부하 분산을 위해서 가상(virtual) IP를 통해 여러 서버에 접속하도록 분배하는 기능을 말한다. 여러 대의 Server에게 균등하게 Traffic을 분산시켜주는 역할을 하는 것이 Load Balancer 이다.

참고

- [로드 밸런서 란?](https://nesoy.github.io/articles/2018-06/Load-Balancer) - [로드 밸런싱은 무엇인가?](https://server-talk.tistory.com/118)

HAProxy

여러 서버에 요청을 분산시키는 TCP 및 HTTP 기반 응용 프로그램을 위한 고 가용성 로드 밸런서 및 프록시 서버 를 제공하는 무료 오픈 소스

참고

- [L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy](https://d2.naver.com/helloworld/284659)

DB

참고

[MongoDB(몽고디비) Study - NoSQL 이란? 그리고 MongoDB 소개](https://cionman.tistory.com/44)

모놀리식(Monolithic) 아키텍처

모놀리식 아키텍처란, 마이크로서비스의 각광에 따라 마이크로서비스가 아닌 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다. 위의 그림에서 처럼 모든 모듈은 서비스 내부의 Product 형태로 종속되어 있으며, 서비스에만 집중할 수 있는 구조로 되어 있다. 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 가질 때, Monolithic 하다고 한다.

단순한 아키텍처 구조와 개발의 용이함이 큰 장점이지만 규모가 커짐에 따라 복잡도가 심각하게 증가

참고

- [전통의 소프트웨어 아키텍처 모델 - 모놀리식(Monolithic) 아키텍처](https://jins-dev.tistory.com/entry/전통의-소프트웨어-아키텍처-모델-모놀리식Monolithic-아키텍처) -[(마이크로 서비스 vs 모놀리식 아키텍처) MicroService vs Monolithic Architecture 간단 소개 및 주관적 의견](https://lion-king.tistory.com/29)

MSA (MicroService Architecture)

하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐

참고

- [(Spring Boot / Spring Cloud / MSA) 1. 왜 MSA를 선택하였을까?](https://lion-king.tistory.com/10) - [MSA, 기본적인 개념과 우버의 적용 사례](https://brunch.co.kr/@yesjun/2) - [블록을 조립하듯 앱을 조립하는'마이크로서비스'](https://blog.lgcns.com/1278)

API Gateway

API Gateway란?

Microservice Architecture(이하 MSA)에서 언급되는 컴포넌트 중 하나이며, 모든 클라이언트 요청에 대한 end point를 통합하는 서버이다. 마치 프록시 서버처럼 동작한다.

그리고

인증 및 권한, 모니터링, logging 등 추가적인 기능이 있다. 모든 비지니스 로직이 하나의 서버에 존재하는 Monolithic Architecture와 달리 MSA는 도메인별 데이터를 저장하고 도메인별로 하나 이상의 서버가 따로 존재한다. 한 서비스에 한개 이상의 서버가 존재하기 때문에 이 서비스를 사용하는 클라이언트 입장에서는 다수의 end point가 생기게 되며, end point를 변경이 일어났을때, 관리하기가 힘들다. 그래서 MSA 환경에서 서비스에 대한 도메인인 하나로 통합할 수 있는 API GATEWAY가 필요한 것이다. API GATEWAY를 도입하기 위해서 먼저 오픈소스를 찾아보았다. KONG, API Umbrella 등이 있었다. 별다른 고민은 없었다. 선택은 Netflix였다. 이유는 JAVA 프로젝트이며, 세계적으로 MSA를 가장 잘하고 있는 서비스이다. 무엇보다 Martinfowler 아저씨가 정의한 MSA환경, MSA에서의 문제점을 충분히 고려하여 설계된 모든 컴포넌트를 오픈소스화 하였기때문이다. 한마디로 Netflix가 잘 닦아놓은 길을 우리는 그대로 걸으면 된다. 물론 서비스가 다르고, 상황이 다르다. 우린 다만 필요한 것을 선택해서 취하면 된다.

API Gateway란? -2-

최근 서비스는 마이크로서비스 아키텍처 형태로 독립적인 기능을 수행하는 작은 단위의 서비스로 나누어 개발하고 있습니다. 작은 단위의 서비스로 분리함에 따라 서비스의 복잡도를 줄일 수 있으며, 변경에 따른 영향도를 최소화하면서 개발과 배포를 할 수 있다는 장점이 있습니다. 하지만, 여러 서비스의 엔드포인트를 관리해야 하는 어려움이 있으며 각 서비스의 API에서 공통적으로 필요한 기능을 중복으로 개발해야 하는 문제가 있습니다. API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리 할 수 있습니다. 모든 클라이언트는 각 서비스의 엔드포인트 대신 API Gateway로 요청을 전달합니다. API Gateway는 사용자가 설정한 라우팅 설정에 따라 각 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시 역할을 합니다. 그뿐만 아니라 API Gateway는 엔드포인트 서버에서 공통으로 필요한 인증/인가, 사용량 제어, 요청/응답 변조등의 기능을 플러그인 형태로 제공하고 있습니다. 플러그인을 사용하면 각 엔드포인트 API 서버가 구현하지 않아도 되기 때문에 개발자 입장에서는 개발 비용을 줄일 수 있습니다. ![image](https://user-images.githubusercontent.com/34932546/72547379-e5064300-38cf-11ea-95e3-b08a5c6cab53.png)

참고

- [배민 API GATEWAY - spring cloud zuul 적용기](https://woowabros.github.io/r&d/2017/06/13/apigateway.html)

TDD, Unit Test

기타 참고

3기 백엔드 참여자 후기 포함 내용

Scale Out & 무정지 서비스

CI & CD

Redis

스프링부트로 웹 서비스 출시하기 포함 내용(한 번 해볼 수 있는 것)

Springboot & Gradle & Github 프로젝트 생성

JPA로 간단 API 만들기 (아직 SI 환경에선 Spring & MyBatis 를 많이 사용하지만, 쿠팡/우아한형제들/NHN Entertainment 등 자사 서비스를 개발하는 곳에선 SpringBoot & JPA를 많이 사용하고 있습니다. 라고 합니다)

Test

Handlebars

yml

AWS EC2 & RDS 구축

EC2 Linux 환경 써보면서 느는 약간의 Linux 명령어

EC2 배포를 위해 쉘 스크립트로 deploy 스크립트 작성

Travis CI & AWS CodeDeploy로 배포 자동화 구축

Ngnix를 활용한 무중단 배포 구축