1. 서버가 죽는 이유 1) 서버가 죽었다 란? '서버가 죽었다'라는 표현은 두 가지로 해석이 가능하다. 일부 요청이 실패한다. (대부분의 경우) 모든 요청이 실패한다. 모든 요청이 실패하는 경우에는 네트워크 장애 혹은 서버 자체의 문제로, 높은 트래픽으로 행이 걸렸을 때 발생한다. 이는 자연스럽게 해소할 수도 있으며, 애플리케이션 재시작을 통해 해결할 수도 있다. CPU 바운드 애플리케이션에서는 CPU 사용을 많이 필요로 하는 해시 연산을 다량 요청했을 때 실패했다. DB I/O 애플리케이션에서는 DB를 사용하는 게시글 INSERT와 SELECT를 다량 요청했을 때 실패했다. 이러한 많은 요청이 들어오면, 기다렸다가 처리하여 문제가 발생하지 않는다고 생각할 수 있다. 그럼에도 500에러 혹은 타임 아웃..

1. I/O 바운드 애플리케이션 1) application.yml 로컬 환경에서의 DB와 서비스 환경에서의 DB는 다르다. 이를 위해 두 환경에서 동작할 수 있도록 수정해주어야한다. 이러한 기능을 profile이라고 한다. 'application.properties' 파일을 이용할 경우, 여러 개의 파일로 나눌 수 있다. 단, 특정 profile이 활성화되지 않을 경우 'application-default.properties'가 기본적으로 로딩된다. 'application.yml' 파일을 이용할 경우, 한 파일에 profile 설정이 가능하다. 하지만 @PropertySource 어노테이션을 통해 값을 읽어 올 수 없다는 단점이 있다. 각각의 profile은 '---'로 구분된다. spring: prof..

1. I/O 바운드 애플리케이션 1) I/O 바운드 애플리케이션성능 향상 서버 스케일 아웃으로 인해 하드디스크도 서버와 함께 늘어날 것이고, 자기 하드디스크에 있는 데이터로만 처리하면 충분히 성능을 향상 시킬 수 있다. 하지만, 각자의 하드디스크의 데이터를 실시간으로 공유하기 어렵다는 문제를 가지고 있다. 따라서 서로 공유할 수 있는 저장소(DB)를 사용한다. 하지만 문제는 서버를 아무리 늘려도 DB의 성능이 낮다면 전체 서비스의 성능은 DB와 동일해진다(병목현상). 이를 해결하기 위해서는 DB의 성능에 의존적인 부분을 줄이고 전체 서비스의 성능을 향상시켜 더 많은 트래픽을 처리할 수 있도록 만들어야한다. 파일 I/O 바운드일 경우 서버를 늘려 성능을 올릴 수 있지만 DB I/O 바운드 애플리케이션은 ..

1. Maven vs Gradle Maven과 Gradle에서 가장 중요하게 봐야할 부분은 성능이다. Gradle이 Maven 보다 빌드에 소요되는 시간, 유연성, 종속성 곤리 등 다양한 측면에서 뛰어나다. Gradle이 약 2배 정도 빠르며 build cache를 사용했을 때 100배 빠른 성능을 보여준다. Maven의 경우 라이브러리가 종속될 경우, 특정 조건을 표현할 경우에 Maven이 이를 처리하기 복잡하다고 한다. 그에 비해 Gradle은 스크립트가 더 짧고 읽기 편하다는 특징을 가지고 있다. 의존성 관리 측면에서도 Gradle은 버전 충돌도 자동으로 관리해주기 때문에 Maven 보다 효율적이다. Gradle은 압도적인 성능과 간편함을 제공하지만, 메모리를 많이 사용한다는 단점이 있다. 1인 토..

1. Trello 1) Trello 란? Trello는 팀 프로젝트 협업 도구로, 효율성을 높이고 팀원들과의 소통을 위해 사용한다. 백엔드, 프론트엔드 등 세분화된 업무를 함께 진행하기 때문에 각자 어떤 업무를 맡고 있고, 각자의 목표가 어디에 있는지를 align하는 과정이 중요하다. 2) 구성 예시 보드 - 관리 프로젝트 목록 - 보드 내에 생성 가능한 목록으로, 하단의 카테고리 표와 동일 카드 - 리스트 내에 생성 가능한 항목을 의미 카테고리 설명 Backlog 앞으로 해야할 모든 것들을 뜻한다. 기획에 맞게 필요한 모든 업무를 backlog에 카드로 생성한다. 기술/페이지 윚로 티켓을 생성하는데, 기능 구분을 명확히 하여 나눈다. 백/프론트 구분이 있고, 한 사람에 하나씩, 하나의 기능을 포함한다...

1. Git-flow 1) Git-flow 란? 일반적인 개발 프로세스는 '기획-디자인-개발-QA-출시' 순으로 진행되며 주기적으로 앱을 출시 한다. 기획, 디자인, 서버 등 협업하는 인원들과 흐름을 맞춰서 진행하기 때문에 많은 인원이 이번 버전에 포함될 기능을 개발하는 것은 비효율적이게 된다. 따라서 우선순위에 따라 나열한 작업 중 우선순위가 높은 작업부터 선택하여 작업을 분담하고, 이번 버전에 포함될 필수 작업과 추후에 배포될 작업들을 병렬로 진행한다. 병렬로 처리하던 작업들이 완료되면, 가까운 배포 주기에 포함시켜 출시를 진행한다. 이러한 개발 프로세스를 잘 녹여내기 위한 모델로는 Git-flow가 있다. 처음 시작에는 master와 develop 브랜치가 존재한다. develop 브랜치는 mast..