SdardewValley의 개발 농사

마이크로서비스 아키텍처에서 각 기능은 독립적인 소프트웨어 컴포넌트로 개발된다. 그리고 각 컴포넌트는 자체 데이터 저장소가 있고 다른 컴포넌트와는 명확한 API를 통하여 통신한다. Java와 스프링 프레임워크로 개발된 컴포넌트는 WAR 파일로 패키징되어 apache tomcat과 같은 웹 컨테이너에 배포된다. 이 글은 이런 마이크로 서비스에 대해서 자세하게 정리한 글이다. 독립 소프트웨어 컴포넌트의 장점 컴포넌트를 개별적으로 배포 및 업그레이드 가능 API를 통하여 기존 시스템과 통합 가능 기능의 일부를 기존의 기능으로 대체 가능 다른 컴포넌트와 상관 없이 여러 서버로 scale-out 가능 수직 스케일링의 한계 수직 스케일링(vertical scaling)이란? scale-up과 같은 말. 서버의 성능 ..

Before 마이크로서비스 마이크로서비스 전에는, 웹 애플리케이션은 monolithic architecture 형태였다. 이런 구조의 애플리케이션은 단일 소프트웨어로 산출된다. 이런 형태는 애플리케이션이 커지고 복잡해질 때 문제가 발생한다. 이런 애플리케이션은 변경이 있을 때, 애플리케이션 전체를 다시 빌드-테스트-배포 과정을 거치면서, 발생하는 비용이 증가한다. 이런 문제를 해결하기 위해 마이크로서비스가 고안되었다. 마이크로서비스의 등장 마이크로서비스는 일체형 애플리케이션을 작은 독립된 컴포넌트로 나누는 것이다. 이런 마이크로서비스는 나누어졌기 때문에 분산되었고, 독립된 컴포넌트이기 때문에 느슨한 결합을 가진다. 대형 애플리케이션에서 마이크로서비스를 사용하면 관리가 쉬워진다. 마이크로서비스는 위와 같은..

application.properties에 DB 설정을 하고 실행을 했는데 Exception이 발생했다. SQLNonTransientConnectionException을 검색한 방법으로 고쳐지지 않아, Public Key Retrieval is not allowed를 검색하니까 해결방법을 찾을 수 있었다. allowPublicKeyRetrieval=true 위의 문장을 추가해 주면 해결할 수 있는 Exception이었다. MySQL 8.0이상부터는 위의 문장을 추가해 주어야 한다. mysql -V로 mysql의 버전을 확인해 보니 8.0.28이었다. 위의 이미지는 application.properties를 캡처한 것이다. 보면 맨 뒤에 allowPublicKeyRetrieval=true을 추가해 주었다...

알고리즘 문제를 풀 때 정렬 기준을 따로 세워야 하는 상황이 많다. Java에서 미리 구현된 기준이 아닌 다른 기준으로 정렬하고 싶을 때 Comparable과 Comparator을 사용한다. Comparable은 인터페이스이다. 정렬 기준을 만들고 싶은 클래스에 implements를 한 다음 public int compareTo 메서드를 구현해 주면 된다. String 타입을 길이 순으로 정렬하고 싶을 때, String 클래스에 Comparable 인터페이스를 사용할 수 없다. 이럴 때 Comparator을 사용하면 된다. 개인적으로 Comparator은 java에 미리 정의되어 있는 자료형에 대한 정렬을 할 때 사용하거나, 2차원 이상의 배열을 정렬할 때 사용한다. 위는 백준 1181번 단어정렬이라는 ..

branch는 프로젝트를 독립적으로 관리하는데 도움을 준다. branch를 통해서 기존의 코드와 분리하여 작업을 진행할 수 있다. branch의 특징 가상 폴더: git은 작업 폴더를 복사하는 것이 아닌 가상 폴더를 생성한다. 독립적인 동작: 원본 폴더와 독립적으로 작업을 할 수 있다. 빠른 동작: blob으로 내부를 구조화 하여 브랜치 변경이 빠르다. blob은 파일의 내용이 저장되는 object이다. 브랜치 명령어를 사용하면 commit이 하나 생성되고 branch로 할당한다. 이런 해시 파일을 생성하여 브랜치가 더 빠르게 생성된다. $ git branch 브랜치 목록을 확인할 수 있다. 현재 브랜치 앞에는 *이 붙는다. branch 생성 $ git branch 브랜치명 commitID 브랜치를 생성..

HEAD 포인터는 작업 중인 브랜치의 마지막 commit ID를 가리키는 참조 포인터이다. 작업 중인 브랜치의 마지막 commit ID이기 때문에 브랜치를 이동하면 HEAD 포인트로 변경된다. 이동한 브랜치의 마지막 commit을 바리키게 된다. HEAD를 통한 상대적 위치 HEAD 포인터는 기준점으로 사용된다. HEAD를 기준으로 상대적인 commit 위치를 지정할 수 있다. 이 때 사용되는 기호는 ~이다. HEAD 바로 이전의 commit은 HEAD~로 알 수 있다. HEAD~의 정보를 출력했을 때 HEAD 바로 직전 commit인 19fe로 시작하는 commit이 출력되는 것을 확인할 수 있다. 바로 직전 commit이 아닌 더 전의 commit은 숫자를 지정하면 된다. 2번째 commit은 HEA..

pull pull은 원격 저장소에서 현재 commit 보다 더 최신 commit 정보가 있을 때 내려 받는다. 받은 정보는 stage 영역이 아닌 원격 저장소를 위한 임시 브랜치에 저장한다. 이렇게 내려받은 commit들은 로컬 commit과 비교하여 현재 브랜치와 자동으로 merge한다. pull 명령어를 하더라도 충돌이 발생하여 자동으로 merge가 되지 않을 때가 있다. 이런 경우네는 fetch를 사용한다. fetch fetch는 원격 저장소를 위한 임시 브랜치에 코드를 내려 받는 것은 같다. 하지만 pull처럼 자동으로 commit을 merge하지 않는다. 단순히 commit들만을 가져 오는 것이다. 이 브랜치는 서버명/브랜치명 형태의 이름을 가진다. 이렇게 내려 받은 commit은 git mer..

commit 의미 있는 변경 작업들을 저장소에 기록하는 것 git은 변경된 부분만을 추출하여 기록한다. 변경된 내용만을 관리하고, 코드가 변경된 시간에 따라서 저장하는데 이를 commit이라고 한다. commit은 parent commit에 대해 변화된 부분만을 새로운 commit으로 생성하여 시간과 함께 기록한다. index.html 파일을 새로 생성하고 git status를 터미널에 입력했을 때 Untracked files라고 출력된다. 위의 파일은 git의해 변화가 추적되지 않는다. commit을 위해서는 위의 파일이 추적 가능한 상태가 되어야 하고 git add를 통해서 추적 상태로 변경을 할 수 있다. git add로 stage 상태로 파일이 변경되었다. git add를 한 뒤에 git stat..

인증과 인가 인증은 유저가 누구인지 확인하는 것이다. 로그인을 통해서 사용자가 누구인지 알 수 있다. 인가는 유저가 사용 가능한 자원을 정의하는 것이다. 로그인을 한 후 사용자는 이메일을 사용할 수 있다. 기본적인 인증 기본 인증은 다음과 같은 두 가지 절차를 거친다. 1. 아이디와 비밀번호를 인코딩하여 서버에 전송한다 2. 서버는 아이디와 비밀번호를 디코딩한 후, 사용자 정보가 저장된 데이터 베이스 혹은 인증 서버에서 아이디와 비밀번호를 비교한다. 위의 절차는 문제가 있다. 첫 번째로 디코더가 있다면 중간자 공격(MITM)을 통해 아이디와 비밀번호를 확인할 수 있어, 아이디와 비밀번호가 유출될 수 있다. HTTP 프로토콜을 사용할 수 없고, HTTPS를 사용해야 한다. 두 번째로 인증 서버와 인증 DB..

.gitignore .gitignore 파일을 통해서 개인 정보와 같은 민감한 데이터가 포함되어 repository에 올리고 싶지 않은 파일들을 관리할 수 있다. .gitignore에 포함된 파일이라면 추적 대상에서 제외되며, 작업하고 있는 디렉토리의 최상단에 두어야 한다. 표기법 # 주석을 적을 때 사용하는 기호이다. 위와 같이 파일 이름만 적으면 그 파일은 추적 대상에서 제외가 된다. #로 추적 제외 대상이 무엇인지 기입한다. * *은 모든 문자열이라는 의미에 기호이다. *.class라고 되어 있다면 class 파일을 모두 제외한다. 위의 기호는 glabbing 문자이다. 아래의 사이트에 내용이 정리되어 있다. https://linuxhint.com/bash_globbing_tutorial/ Bash..