https://d2.naver.com/helloworld/10963 

저작자표시

'기타' 카테고리의 다른 글

DB 순위 비교 사이트  (0) 2019.07.31
Ant vs Maven Vs Gradle  (0) 2019.04.10
Oracle JDK 유료화의 논쟁, OpenJDK와의 차이  (0) 2018.11.03
DDD(Domain Driven Design)  (0) 2018.10.14
정규표현식(Regular Expression)  (0) 2018.07.08



자바 기준  사람들이 많이 사용하는 Redis Library는 다음과 같다.


  • Jedis
  • Lettuce
  • Redisson


...


기타 라이브러리는 아래에서 확인 가능하다.


https://redis.io/clients#java




Jedis 


- Jedis의 가장 큰 장점은 사용하기 쉽다.


https://github.com/xetorthio/jedis





Lettuce


- 쓰레드로부터 안전한 sync 그리고 async와 reactive(Concurrent API structed Observer Pattern) 사용을 위한 클라이언트

- 또한 코덱과 파이프라인 등 고급 설정을 지원한다.

- netty 기반 라이브러리

- JAVA8 이상에서 안정화



https://github.com/lettuce-io/lettuce-core




Redisson


- Jedis나 Lettuce에 비해 사용하기 까다롭다.

- redis 명령어와 같은 low-level 메소드를 제공한다.


- 기타 자세한 특징

: http://redisgate.kr/redis/clients/redisson_intro.php



https://github.com/redisson/redisson




Spring Data Redis  in Spring boot


- Redis를 마치 jpa repository를 이용하듯 인터페이스를 제공하는 스프링 모듈

- crudRepository를 지원하기 때문에 직관적이다. 

- Jedis, lettuce만 공식 지원,  Redisson은 현재 포함되지 않는다.





=> 주관적인 견해로 라이브러리를 선택할 때, 라이브러리 관리가 제대로 잘되고 있는지 그리고 내가 어떤 목적으로 쓸지가 중요한 것 같다.










저작자표시

'Cloud & NoSQL & Middleware > Redis' 카테고리의 다른 글

Spring 에서 lettuce가 jedis 보다 많이 사용되는 이유  (0) 2018.11.27
Single Thread  (0) 2018.11.17
SpirngBoot에서 Redis 연동(Jedis)  (0) 2018.08.09
Redis 명령어  (0) 2018.08.04
Redis Pub/Sub Model  (0) 2018.07.01

Single Thread Model

Redis는 대표적인 Single Thread Model 이다. 

이로 인해 처리가 긴 Transaction이 발생했을 때, 다른 request는 처리하지 못할 수 있다.

대표적으로 flushAll 명령어는 리스트 전체를 Scan하는 구조로 100만개 처리시 1초,1000만개 처리시 10초,  1억개는 100초가 소요된다.

이를 예방하기 위해 데이터를 전체 하나의   Collection에 넣는 것이 아닌 여러 Collection 에 나눠 처리하는 방안이 좋으며 각 Collection당 보통 10000개의 데이터를 저장한다,


다른 예로 데이터를 백업하는 경우에, 앞서 AOF(메모리 덤프 및 디스크 저장)와 RDB(매번 디스크에 Write IO) 방식이 있는 것을 살펴 봤다.

이런 경우 대량의 데이터를 처리하는 경우 성능 저하를 발생하는 또다른 요인이기 때문에, 일반적으로 Master-Slave Model로 레디스를 구성하며 Master Redis는 데이터의 처리를 담당하며 slave redis에서 백업을 진행하는 것이 좋다.


출처: http://bcho.tistory.com/829

https://www.slideshare.net/charsyam2/redis-acc?ref=http://bcho.tistory.com/829



Redis Sing Thread를 회피하기 위해 Scan 을 예로 들 수 있는데  더 자세히 알고 싶다면,  카카오 기술 블로그에 작성된 강대명 개발자의 의견을 꼭 한번 읽어 보는 것을 추천한다.

http://tech.kakao.com/2016/03/11/redis-scan/

저작자표시

'Cloud & NoSQL & Middleware > Redis' 카테고리의 다른 글

Spring 에서 lettuce가 jedis 보다 많이 사용되는 이유  (0) 2018.11.27
Redis Library  (2) 2018.11.17
SpirngBoot에서 Redis 연동(Jedis)  (0) 2018.08.09
Redis 명령어  (0) 2018.08.04
Redis Pub/Sub Model  (0) 2018.07.01


빌드

출처: https://www.mindmeister.com/ko/740843162/continuous-integration-workflow


1) 빌드 컨텍스트를 읽어 들인다.

-> 빌드 컨텍스트는 이미지를 생성하는데 필요한 각종 파일, 소스코드 등을 담고 있는 디렉토리이며 DockerFile이 있는 디렉토리이다.


2) 파일을 추가할 때도 사용된다. (ADD, COPY)






Dockerfile로 빌드 시 주의점


1) 하나의 명령어를 \로 나누어 가독성을 높인다.

2) RUN 명령어는 하나의 이미지 레이어가 될 수 있다. 여러 개의 Run 명령어를 && 옵션과 함께 되도록이면 하나로 묶자.


저작자표시

'Cloud & NoSQL & Middleware > Docker' 카테고리의 다른 글

Docker Max TCP Connection limit  (0) 2019.01.15
Dockerfile(2) - 기초 명령어 & 빌드 명령어  (1) 2018.10.30
DockerFile (1)  (0) 2018.10.15
Docker Network (3) - host, none, container network  (0) 2018.09.18
Docker Network (2) - 브리지(bridge) network  (0) 2018.09.17

https://okky.kr/article/490213


오라클 JDK가 내년부터 유료화 됨에 따라, 미래의 자바는 어떻게 될지.

저작자표시

'기타' 카테고리의 다른 글

Ant vs Maven Vs Gradle  (0) 2019.04.10
Thread 분석  (0) 2018.11.19
DDD(Domain Driven Design)  (0) 2018.10.14
정규표현식(Regular Expression)  (0) 2018.07.08
단축URL 서비스  (0) 2018.07.08

명령어


docker file은 한줄이 하나의 명령어가 되고 명령어를 명시한 뒤 옵션을 추가하는 방식. 스크립트와 동일하게 위에서 아래로 실행되며 명령어는 일반적으로 대문자로 표시한다.



FROM

 생성할 이미지의 베이스가 될 이미지. From 명령어는 Dockerfile을 작성할 때 반드시 한 번 이상 입력해야 하며, 이미지의 이름의 포맷은 docker run 명령어에서 이미지 읾을 사용했을 떄와 같다. 이미지가 도커에 없다면 자동으로 pull 한다.

 Maintainer

 이미지를 생성한 개발자의 정보. 일반적으로 메일 정보를 작성한다.

 LABEL

 메타데이터 추가. 메타데이터는 키 : 값 형태로 저장되며, 여러 개의 메타데이터가 저장될 수 있다. inspect 명령어로 이미지의 정보를 구해서 확인 할 수 있다.

 RUN

 이미지를 만들기 위해 컨테이너 내부에서 명령어를 실행한다.

 ADD, COPY

 파일을 이미지에 추가합니다. 파일은 Dockerfile이 위치한 디렉터리인 컨텍스트에서 가져온다. (dockerfile이 위치한 데릭터리에서 파일을 가져온다.)

ADD와 COPY의 차이점은 파일을 추가한다는 베이스는 동일하지만, ADD는 URL 및 .tar 파일의 추가가 가능하다. tar 파일의 경우 자동 압축해제된다.

 WORKDIR

 명령어를 실행할 디렉터리 지정한다.

 EXPOSE

 커파일의 빌드로 생성된 이미지에서 노출할 포트를 설정한다. 이미지에 노출됬다는 것은 호스트의 포트와 반드시 바인딩 되었음을 의미하는 것이아니며, 이포트를 호스트에서 사용할 수 있음을 의미한다.

 CMD

 CMD는 컨테이너가 시작될 때마다 실행할 명령어를 설정하며, dockerfile에서 한 번 만 사용할 수 있다.

 ENTRYPOINT

 ENTRYPOINT entrypoint는 cmd와 동일하게 컨테이너가 시작될 때 수행할 명령을 지정한다는 점에서 같다. 그러나 entrypoint는 커맨드를 인자로 받아 스크립트로 수행할 수 있다는 점에서 다르다.

docker file에 entrypoint를 지정하거나 docker run 단계에서 entrypoint 옵션을 줄 수 있다.

 ENV

Dockerfile에서 환경변수를 지정한다. 이 환경변수는 Dockerfile 뿐 아니라 이미지에도 저장되므로 빌드된 이미지로 컨테이너를 생성하면 내부에서 사용할 수 있다. 

 ARG

 build 명령어를 실행할 때 추가로 입력을 받아 Dockerfile 내에서 사용될 변수의 값을 설정한다.

 USER

User로 컨테이너 내에서 사용될 사용자 계정이나 uid를 설정한다. 

 ONBUILD

빌드된 이미지를 기반으로 하는 다른 이미지가 Dockerfile로 생성될 때 실행할 명령어를 추가한다. 

 STOPSIGNAL

컨테이너가 정지될 때 사용될 시스템 콜의 종류를 지정한다. default는 SIGTERM으로 설정된다.

ex) STOPSIGNAL SIGKILL 

 HEALTHCHECK

healthcheck는 이미지로부터 생성된 컨테이너에서 동작하는 애플리케이션의 상태를 체크하도록 설정한다. 애플리케이션의 프로세스는 종료되지 않았으나, 애플리케이션이 동작하지 않을 때 사용된다. 

 SHELL

기본 Shell을 변경할 수 있다.

ex) SHELL ["/usr/local/bin/node"] 













빌드


docker build -t  mybuild:0.0   ./

  • -t 옵션 : 빌드할 이미지의 이름 지정

  • build:0.0 : 이미지의 이름과 버전

  • ./ : dockerfile이 위치한 디렉토리







* docker build 시 이전에 했던 이미지가 남아있는 채로 다시 빌드하면, 이전 빌드에서 사용했던 캐시를 사용하게 된다.

* 캐시를 사용하지 않으려면 --no-cache 옵션, 특정 이미지로 사용하려면 --cache-from 옵션을 주면 된다.


ex) docker build --cache-from nginix mynginix:0.0



저작자표시

'Cloud & NoSQL & Middleware > Docker' 카테고리의 다른 글

Docker Max TCP Connection limit  (0) 2019.01.15
Docker Build Context  (0) 2018.11.05
DockerFile (1)  (0) 2018.10.15
Docker Network (3) - host, none, container network  (0) 2018.09.18
Docker Network (2) - 브리지(bridge) network  (0) 2018.09.17

DockerFile


도커는 애플리케이션의 배포의 일련의 과정(copy, commit..) 등의 빌드 명령어를 제공하며 DockerFile에 기록한다.


Dockerfile은 사용자가 이미지를 어셈블하기 위해 명령 행에서 호출 할 수있는 모든 명령을 포함하는 텍스트 문서이다. docker 빌드 사용자를 사용하면 몇 가지 명령 줄 명령을 연속적으로 실행하는 자동화 된 빌드를 만들 수 있다.


DockerFile을 통해 직접 컨테이너를 생성하고 이미지로 커밋해야하는 번거로움을 덜 수 있을 뿐 아니라 git과 같은 개발 도구를 통해 자동화를 할 수 있다.


애플리케이션을 개발하는 용도 이외에 여러 목적으로 사용 가능하며, 결국 도커파일을 작성하는 이유는 배포의 유연성과 자동화와 연관 깊다.


 






https://docs.docker.com/engine/reference/builder/#usage

저작자표시

'Cloud & NoSQL & Middleware > Docker' 카테고리의 다른 글

Docker Build Context  (0) 2018.11.05
Dockerfile(2) - 기초 명령어 & 빌드 명령어  (1) 2018.10.30
Docker Network (3) - host, none, container network  (0) 2018.09.18
Docker Network (2) - 브리지(bridge) network  (0) 2018.09.17
Docker Network (1) - docker0  (0) 2018.09.14

Domain


도메인은 소프트웨어가 취급하는 '어떤 활동이나 관심과 관계가 있는 지식'  즉, 소프트웨어가 해결해야되는 문제이다. 


소프트웨어의 복잡성이 증가하면, 도메인의 복잡성이 증가된다는 말로 직결된다.


예를 들면, 쇼핑몰 사이트를 구축한다고 했을 때 로그인을 해서 상품을 비교하고 주문을 하는 전체 과정이 도메인이 될 수 있다. 


(도메인의 한 루틴안에 비지니스 로직이 포함된다.)


도메인이 어떤 소프트웨어의 기능이라고 생각할 수 있는데 꼭 그렇지는 않다. 소프트웨어 전체가 도메인이 될 수 있고 시스템 자체가 도메인이 될 수 있다.




Domain Model


- 도메인을 분석하여 모델을 구분하는 일

- 도메인 모델링

- 도메인을 개념적으로 표현



기본 요소


1) Entity

2) Value

3) Aggregate

4) Repository

5) Service



Entity


- 모델을 표현

- 고유 식별값을 가짐

- 스스로의 라이프 사이클 소유


Value


- 고유의 키값을 가지지 않음

- 데이터의 표현

- 속성의 불변성



Aggregate


- 관련된 객체의 묶음



Repository


- Entity의 저장소



Service


- Domain 객체에 위치시키기 어려운 오퍼레이션을 가지는 객체 


- Service Domain의 operation은 일반적으로 Stateless 하다.


- 여러 도메인을 다룰 수도 있다.






출처 : https://www.slipp.net/wiki/pages/viewpage.action?pageId=24641881




=> 전체 큰 틀은 Repository 다.  Custom, Accout 2개의 Entity가 존재하며 Custom Entity는 name, address 등 value를 갖는다.


 => 각각의 집합체(aggregate) 경계를 통해 value를 접근할 수 있으며, root의 기본 값은 entity이다.


 => 서비스는 Entity가 처리할 수 없는 비지니스 로직을 수행한다. 


ex) 사용자에게 계좌정보를 메시지로 전달




Domain Driven Design


 도메인 패턴을 중심에 놓고 설계하는 방식


스프링프레임워크의 모체인 Interface21의 Ramnivas Laddad가 정리한 DDD의 세 가지 특징을 살펴보자.

​

첫째는 도메인 그 자체와 도메인 로직에 초점을 맞춘다는 것이다. 일반적으로 많이 사용하는 데이터중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다.

​

둘째는 보편적인(ubiquitous) 언어의 사용이다. 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말한다. 이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해진다.

​

셋째는 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것이다. 분석모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리이다.

​

물론 DDD는 방법론이 아니다. 따라서 이런 경우 이렇게 하라는 식의 접근법 보다는 원칙과 핵심가치를 설명해주고 그것에 어떻게 집중할 것인가에 주목하게 하는 것이다. 모든 애플리케이션의 핵심은 결국 그 애플리케이션을 사용할 도메인과 그 로직이라고 본다면 소프트웨어 설계와 구현도 그 부분이 핵심이 되는 것이 마땅하다는 것이 DDD의 개념이라고 생각하면 된다.



(http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000039170214&from=Mobile)




http://domainlanguage.com/ddd/

https://www.slideshare.net/baejjae93/ss-27536729

https://www.slideshare.net/madvirus/ddd-final



저작자표시

'기타' 카테고리의 다른 글

Thread 분석  (0) 2018.11.19
Oracle JDK 유료화의 논쟁, OpenJDK와의 차이  (0) 2018.11.03
정규표현식(Regular Expression)  (0) 2018.07.08
단축URL 서비스  (0) 2018.07.08
Cheat Sheet  (0) 2018.06.13

+ Recent posts

티스토리툴바