'분류 전체보기'에 해당되는 글 460건

  1. 2020.02.07 Tomcat - currentThreadBusy
  2. 2019.12.05 AWS re:Invent 2019 12월 2일 키노트 요약
  3. 2019.09.16 Spring DI(Dependency Injection) - 비교 및 방법에 대해
  4. 2019.09.03 Java 모델 매핑 (4)
  5. 2019.07.19 MapStruct 가이드
  6. 2018.12.17 Docker command
  7. 2018.10.15 [KAFKA] 콘솔 명령어 모음 (1)
  8. 2018.09.29 AWS 보안
  9. 2018.09.28 AWS - 가상 서버 사용
  10. 2018.09.28 AWS란?

Tomcat에서 currentThreadBusy 값이 있다.
이 값은 thread의 수와는 별도의 수치이다.
Http Thread pool 의 ThreadPoolExecutor.getActiveCount()의 값으로서,
디폴트 설정인 경우에는 java.util.concurrent.ThreadPoolExecutor 를 사용한다

ActiveCount()의 개념은 현재 작업을 할당받고 일을 하고 있는 수이다.

Thread에는 다음과 같은 상태가 있는데 이 중에서 NEW가 아닌 상태들을 ActiveCount에서 카운팅하고 있다.

  • NEW: 스레드가 생성되었지만 아직 실행되지 않은 상태
  • RUNNABLE: 현재 CPU를 점유하고 작업을 수행 중인 상태. 운영체제의 자원 분배로 인해 WAITING 상태가 될 수도 있음
  • BLOCKED: Monitor를 획득하기 위해 다른 스레드가 락을 해제하기를 기다리는 상태
  • WAITING: wait() 메서드, join() 메서드, park() 메서드 등를 이용해 대기하고 있는 상태
  • TIMED_WAITING: sleep() 메서드, wait() 메서드, join() 메서드, park() 메서드 등을 이용해 대기하고 있는 상태. WAITING 상태와의 차이점은 메서드의 인수로 최대 대기 시간을 명시할 수 있어 외부적인 변화뿐만 아니라 시간에 의해서도 WAITING 상태가 해제될 수 있음.

그래서 서비스 중인 톰캣의 currentThreadBusy의 수치를 보면, 계속 처리하고 있는 스레드들이 있을 것이므로 어느정도 수치가 유지되는 것은 당연한 일이고 문제가 없다. 그러나 이 수치가 튀는 시점에는 GC, Network, DB등의 이유로 처리속도가 떨어지는 일이 발생했다고 추정할 수 있다.

 

Reference

Leave a Comment

정식 출시 서비스

EC2 인스턴스 Inf1 출시

  • 기계 학습 시 빠른 추론 가속화를 위해 AWS Inferentia 칩으로 구동 되는 4가지 크기로 Inf1 인스턴스를 출시
  • 64 teraOPS 및 8 비트 정수 데이터의 128 teraOPS 성능이 있는 전용 칩에는 고속 상호 연결 및 많은 메모리가 포함
  • 2 페타 OPS 이상의 추론 성능을 활용할 수 있음
  • G4 인스턴스와 비교할 때 Inf1 인스턴스는 최대 3 배의 추론 처리량을 제공하고 최대 40 %의 추론 당 비용을 절감

Amazon EKS on AWS Fargate 정식 출시

  • Amazon Elastic Kubernetes Service
  • AWS Fargate에서 Kubernetes 포드를 실행할 수 있음
  • 쿠버네티스 컨테이너 인프라를 프로비저닝하고 관리 할 필요가 없어서 AWS에서 Kubernetes 기반 애플리케이션을 간단하게 실행할 수 있음
  • AWS Fargate를 사용하면 비용 최적화되고 고 가용성 클러스터를 운영하기 위해 Kubernetes 운영 전문가가 될 필요가 없음
  • Fargate는 고객이 Amazon EKS 클러스터에 대한 EC2 인스턴스를 생성하거나 관리 할 필요가 없음

Amazon S3 Access Points

  • 손쉬운 공유 데이터셋 관리하기
  • 해당 엔드 포인트를 사용하여 데이터에 접근하는 방법을 설명하는 전용 액세스 정책이 있는 고유 한 호스트 이름
  • S3 액세스 포인트 이전에는 데이터에 대한 공유 액세스가 버킷에서 단일 정책 문서를 관리하는 것을 의미했음
  • 이제 다양한 권한을 가진 수백 개의 애플리케이션을 조사하여 시스템에 영향을 줄 수있는 병목 현상을 업데이트할 수 있음

Amazon Redshift

  • 차세대 인스턴스 타입 및 분석 최적화 스토리지
  • 새로운 RA3 인스턴스는 새로운 관리 형 스토리지 모델과 함께 작동하도록 설계됨
  • 새로운 관리형 스토리지는 규모, 성능 및 내구성을 위해 각 인스턴스에 S3가 지원하는 대용량 고성능 SSD 기반 스토리지 캐시를 제공
  • 데이터는 자동으로 적절한 계층에 배치되므로 캐싱 또는 기타 최적화의 이점을 얻기 위해 특별한 작업을 수행 할 필요가 없음
  • SSD 및 S3 스토리지에 대해 동일한 저렴한 비용을 지불하면 추가 인스턴스를 추가하거나 지불하지 않고도 데이터웨어 하우스의 스토리지 용량을 확장 할 수 있음

Amazon Managed Apache Cassandra Service (MCS) 출시

  • 확장 가능하고 가용성이 높으며 관리되는 Apache Cassandra 호환 데이터베이스 서비스
  • MCS는 서버리스이므로 사용하는 리소스에 대해서만 비용을 지불하면 서비스는 트래픽에 따라 자동으로 테이블을 확장 및 축소함
  • 거의 무제한의 처리량과 스토리지로 초당 수천 건의 요청을 처리하는 애플리케이션을 구축 할 수 있음

Amazon Redshift

  • 신규 통합 질의 기능 및 데이터 레이크 내보내기 기능 출시
  • S3 데이터 레이크 및 PostgreSQL 및 Amazon Aurora PostgreSQL 데이터베이스 용 하나 이상의 Amazon Relational Database Service (RDS)에 저장된 데이터를 통합적으로 질의할 수 있음
  • Data Lake Export 기능은 분석에 최적화 된 효율적인 오픈 컬럼 스토리지 형식인 Apache Parquet 형식으로 Redshift 클러스터에서 S3로 데이터를 내보낼 수 있음

Amazon SageMaker Studio

  • 기계 학습 모델을 위한 통합 개발 환경
  • Amazon SageMaker Studio는 모든 ML 개발 단계를 수행 할 수있는 단일 웹 기반 비주얼 인터페이스를 제공함
  • 모델을 구축, 훈련 및 배포하는 데 필요한 각 단계에 대한 완벽한 액세스, 제어 및 가시성을 제공함

Amazon SageMaker Experiments

  • 기계 학습 훈련 과정 추적 및 관리 서비스
  • 기계 학습 모델에 대한 반복을 구성하고 추적 할 수 있음

Amazon SageMaker Debugger

  • 기계 학습 모델 성능 추적 기능
  • 일반적인 훈련 문제가 감지 될 때 경고 및 치료 조언을 생성 할 수도 있음
  • 모델 설명 방법의 초기 단계를 나타내는 모델 작동 방식을 해석 할 수 있음

Amazon SageMaker Model Monitor

  • 완전 관리형 자동 기계 학습 모델 모니터링
  • 개발자가 모델의 개념 편차를 감지하고 변경할 수 있음

Amazon SageMaker Autopilot

  • 고품질 기계 학습 모델 자동 구축 기능
  • Amazon SageMaker Autopilot은 ML 모델에 대한 완벽한 제어 및 가시성을 제공하는 업계 최초의 자동 기계 학습 기능
  • 기계 학습 경험이없는 사람들이 쉽게 모델을 생성하거나 숙련 된 개발자가 팀이 추가 반복 할 수있는 기준선 모델을 신속하게 개발하는 데 사용할 수 있음

Amazon SageMaker

  • Deep Graph Library 지원 시작
  • 2018 년 12 월 Github에서 처음 출시 된 DGL (Deep Graph Library)은 연구원과 과학자가 데이터 세트에서 Graph neural networks (GNN) 모델을 빠르게 구축, 훈련 및 평가할 수 있도록 해주는 Python 오픈 소스 라이브러리
  • 이를 활용하려면 도메인 지식, 컴퓨터 과학 지식 (Python, 딥 러닝, 오픈 소스 도구) 및 인프라 지식 (훈련, 배포 및 스케일링 모델)이 필요한데 이러한 기술을 모두 습득하는 사람은 거의 없으므로 Deep Graph Library 및 Amazon SageMaker와 같은 도구가 필요함

Amazon SageMaker Processing

  • 완전 관리형 데이터 프로세싱 및 기계학습 모델 평가 기능
  • 데이터 과학자와 ML 엔지니어가 Amazon SageMaker에서 사전 처리, 사후 처리 및 모델 평가 워크로드를 쉽게 실행할 수 있는 새로운 Python SDK
  • 본 SDK는 SageMaker의 내장 컨테이너 인 scikit-learn을 사용하며 데이터 세트 변환에 가장 인기있는 라이브러리

Amazon CodeGuru

  • Amazon CodeGuru는 자동화 된 코드 검토 및 애플리케이션 성능 권장 사항을 위한 기계 학습 서비스
  • 서비스 성능을 저하시키고 가장 비싼 코드 라인을 찾은 다음 코드 수정 또는 개선을 위한 특정 권장 사항을 제공
  • CodeGuru는 수백만 개의 코드 검토와 오픈 소스 프로젝트 및 Amazon 내부에서 프로파일 링 된 수천 개의 애플리케이션에 대한 기계 학습, 모범 사례 및 습득한 정보를 기반함
  • 리소스 누수, 잠재적 동시성 경쟁 조건 및 CPU주기 낭비와 같은 코드 문제를 찾아줌

AWS 로컬 영역(Local Zone) 출시 – 미국 로스 엔젤레스 지역

  • 캘리포니아 로스 앤젤레스 지역에서 로컬 영역(Local Zone)을 시작함
  • 새로운 유형의 AWS 인프라 배포 방식으로 특정 AWS 서비스를 특정 지역에 빠르게 제공함
  • 남부 캘리포니아 리전 내부에 로스 앤젤레스와 가용 영역에서 세분화 되어, LA 지역 사용자가 접근하는 서비스에 대해 매우 낮은 대기 시간 (1 자리 밀리 초)을 제공하도록 설계됨
  • 지연 시간에 민감한 트래픽이 높은 애플리케이션에 도움이 됨

AWS Outposts

  • 정식 출시
  • 네이티브 AWS 서비스, 인프라 및 운영 모델을 사실상 모든 데이터 센터, 코로케이션 공간 또는 온프레미스 시설로 옮길 수 있음
  • 온프레미스 및 클라우드에 걸쳐 동일한 API, 동일한 도구, 동일한 하드웨어 및 동일한 기능을 사용하여 일관된 하이브리드 환경을 제공할 수 있음
  • 짧은 지연 시간 또는 로컬 데이터 처리 필요성에 따라 온프레미스에 유지되어야 하는 워크로드를 지원하는 데 사용할 수 있음
  • 서울 리전을 포함해서 주문 가능

미리 보기 출시 예고

Graviton2기반 EC2 인스턴스 (M6g, C6g, R6g)

  • 새로운 Graviton2 프로세서로 구동되는 새로운 Arm 기반 범용, 컴퓨팅 최적화 및 메모리 최적화 EC2 인스턴스를 출시 예고
  • 5 세대 (M5, C5 및 R5) 인스턴스에 비해 상당한 성능 이점을 제공하며 보안에 대한 기준을 높임

UltraWarm for Amazon Elasticsearch Service

  • 대용량 로그 분석을 위한 스토리지
  • 완전 관리 형 저비용 스토리지 계층 UltraWarm은 기존 옵션에 비해 거의 90 %의 비용 절감으로 최대 900TB의 스토리지를 제공
  • Kibana 인터페이스에서 자주 사용하는 데이터를 쿼리하고 시각화 할 수 있음

Amazon Kendra

  • Amazon Kendra는 기계 학습을 기반으로하는 매우 정확하고 사용하기 쉬운 엔터프라이즈 검색 서비스
  • 웹 사이트 및 응용 프로그램에 강력한 자연어 검색 기능을 제공하므로 최종 사용자는 회사 전체에 퍼져있는 방대한 양의 컨텐츠에서 필요한 정보를보다 쉽게 찾을 수 있음

Contact Lens for Amazon Connect

  • 기계 학습을 사용하여 고객 센터의 고객 대화 내 감정과 추세를 이해하는 Amazon Connect 용 분석 기능 세트
  • 고객 센터 수퍼바이저와 분석가는 상담원을 효과적으로 교육하고 성공적인 상호 작용을 복제하며 중요한 회사 및 제품 피드백을 식별하기 위해 호출에서 언급 된 특정 단어와 문구를 기반으로 트렌드, 컴플라이언스 위험을 감지할 수 있음

Amazon Fraud Detector

  • 온라인 결제 사기 및 가짜 계정 생성과 같은 사기성 온라인 활동을 쉽게 식별 할 수 있는 완전 관리형 서비스
  • 사기 수법의 변화를 고정된 규칙이 아니라 기계 학습을 사용하여 분석하여, 비즈니스와 관련된 데이터 세트 및 사기 행위를 기반으로 정확도를 높임

AWS Wavelength

  • 개발자에게 한 자리 밀리 초의 지연 시간으로 최종 사용자에게 서비스를 제공하는 애플리케이션을 구축 할 수 있는 기능을 제공
  • 기존 VPC를 파장 영역으로 확장 한 다음 EC2, EBS, ECS, EKS, IAM, CloudFormation, Auto Scaling 및 기타 서비스를 활용할 수 있음
  • AWS에 대한 지연 시간이 짧은이 액세스는 차세대 모바일 게임, AR / VR, 보안 및 비디오 처리 애플리케이션을 가능하게 함
  • 한국에서는 SK텔레콤이 버라이존, KDDI, 보다폰과 함께 파트너로 선정됨

Reference

[1] https://aws.amazon.com/ko/blogs/korea/aws-launches-previews-at-reinvent-2019-tuesday-december-3rd/

Leave a Comment

Dependency Injection

의존성 주입의 방법은 총 3가지가 있다.

Constructor Injection

  • Spring 4.3에서부터는 단일 생성자의 경우 Autowired Annotation 불필요함
@Service
public class Atin {
  private final Story story;

  @Autowired
  public Atin(Story story) {
    this.story = story;
  }
}

Field Injection

...

@Service
public class Atin {
  @Autowired
  private final Story story;
}

Setter Injection

...

@Service
public class Atin {
  private Story story;

  @Autowired
  public void setStory(Story story) {
    this.story = story;
  }
}

어떤 방법이 가장 좋을까?

여러 가지 방법이 있고, 어떤 형태로 하던 개발에는 문제는 없다.
그러나 프로젝트 개발, 그리고 회사의 팀에서 개발을 할 때는 공통된 코드 스타일 작성이 필요하다.

가장 추천하는 방법은 생성자 주입이다.
스프링 소스를 살펴보면 생성자 주입을 이용한 방법을 사용하고 있다.

생성자 주입이 좋은 내가 생각하는 이유는 다음과 같다.

  • 테스트 클래스 작성시 리플렉션을 이용하지 않고 주입할 수 있다.
  • POJO에 가깝다.
  • 특별한 경우가 아니라면, 의존관계에 있는 객체들은 반드시 의존관계 주입이 되어야 하며 그렇다면 생성자 주입이 그림상 맞다.

[1]의 블로그에 보면 해당 이유를 다음과 같이 설명하고 있다.

  • 단일 책임의 원칙
  • 테스트 용이성
  • Immutabiblity
  • 순환 의존성
  • 의존성 명시

그렇다면 생성자 주입이 가장 좋은 방법으로 생각해 볼 수 있다.
그런데 생성자를 만드는 방법이 꽤 불편하기도 한데 이럴 때 고려를 해 볼 수 있는 점이 lombok이다.

주입이 필요한 객체들을 final로 한 이후에 lombok의 @RequiredArgsConstructor를 사용하면 final로 지정된 객체들이 자동적으로 생성자 때 필요하게 되면서 편리하게 생성자 주입을 사용할 수 있다.

@Service
@RequiredArgsConstructor
public class TestController {
    private final StoryService storyService;
    private final TestService testService;

    ...
}

그러면 lombok을 통한 방법의 생성자 주입이 최선일까?
처음에는 이 방식이 편리해서 사용했고 편리했다.
그러나 이 방식에는 몇 가지 문제가 존재한다.

  • 주입하려는 bean이 1개가 아닌 경우에는 @Qualifier를 사용해야 하는데 lombok 이용시 불가능하다.
  • @Value와 같은 properties 등의 주입이 필요할 경우 불가능하다. 그렇다고 @Value경우는 필드 주입을 쓰게 되면 코드 통일성이 없어진다.
  • final로 지정된 클래스 변수들의 순서가 변경이 되면 생성자도 변경이 되며 TC등에서 문제가 발생할 수 있다.
  • 생성자에 특정 로직 작성이 필요한 등의 이슈가 발생하면 결국 직접 생성을 해줘야 한다.

그래서 결론은, 생성자 주입은 lombok을 사용하지 않고 직접 작성하는 것이 좋다.
다음은 spring sagan 소스이다. 참고용으로 넣어본다.
Spring 4.3 이후 버전이라서 Autowired도 필요가 없다.

@RestController
@RequestMapping(path = "/guides", produces = MediaTypes.HAL_JSON_VALUE)
public class GuidesController {

    private final GuideRenderer guideRenderer;

    private final GithubClient githubClient;

    private final RendererProperties properties;

    private final GuideResourceAssembler guideAssembler = new GuideResourceAssembler();

    public GuidesController(GuideRenderer guideRenderer, GithubClient github,
            RendererProperties properties) {
        this.guideRenderer = guideRenderer;
        this.githubClient = github;
        this.properties = properties;
    }

    ...
}

https://github.com/spring-io/sagan/blob/master/sagan-renderer/src/main/java/sagan/renderer/guides/GuidesController.java

Reference

[1] https://landsnail.tistory.com/entry/Spring-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85-%EB%B0%A9%EB%B2%95
[2] https://github.com/sieunkr/spring-tips/tree/master/spring-di
[3] https://javaslave.tistory.com/19

Leave a Comment

개발을 하면서 모델간 매핑을 많이 한다.
DTO, VO, Entity별로도 하고 DTO간 DTO 변환에도 사용한다.
개발자마다 각각 다양한 방식으로 이 부분에 대해 개발을 하는데 문제는 팀 내에서는 동일한 방식을 사용해야 한다.
팀 생산성상 중요하고, 코드리뷰에서 불필요하게 지적하는 시간을 줄일 수 있다.
중요한 점은 팀 내에서 협의하여 공통된 방식에 대해서 합의가 되어야 한다.
정해진 답은 없고, 프로젝트의 성격에 따라 다르겠지만 어느 정도 공통된 점들은 있다.

Model Object

시작하기에 앞서
모델 객체애 대해서 다시 살펴보면
DTO, VO, Entity, Domain Model로 나누어 볼 수 있다.

DTO

  • Data transfer object
  • 목적 : 데이터의 전달
  • 데이터의 전달을 위한 생성자와 getter, setter 로직만 들어가야 하며 기타 로직이 들어가서는 안됨

 

VO

  • Value Object
  • 목적 : 불변 객체로서 데이터 전달
  • 개발자들간 대화를 하다보면 VO에 대해서 특별한 정의를 없이 사용하며 DTO와 크게 다르지 않게 사용하는 경우가 있다.
    • 그러나 프로젝트 내에서 DTO와 VO를 특별한 의미없이 사용해서는 안된다. 나름대로의 목적을 정해야만 함
  • VO의 통상적으로 사용되는 의미는 불변(Immutable)의 의미
  • DDD에서 VO를 불변 객체로 소개

 

불변(Immutable) 객체

  • 한번 생성된 이후 수정되지 않는 의미
  • 데이터를 다룰 때, 종종 수정되어서는 안되는 데이터가 있는데 이를 개발단에서 중간에 수정되지 않게 막음
  • 동시성 프로그래밍(parallel programming)에서 멀티 스레드 처리시 발생하는 문제에서 벗어날 수 있음
  • 생성자 또는 빌더를 통해서만 값을 객체 생성 초기에 넣고, 그 이후로는 getter를 통해서 값을 갖고 오도록 처리

 

Entity & Domain Model

  • Etity는 ORM에서 DB Table와 매핑되는 모델 객체
  • Entity는 데이터 전달의 목적보다 DB Table과 객체를 매핑함으로서, 기존 JDBC API를 이용한 경우 데이터 정보만 전달하게 되면서 객체 지향적이지 않게 생기는 패러다임 불일치 문제를 해결하는 점이 중요
  • DDD를 할 경우에는 Entity를 도메인 모델로 사용한다. 이 경우 Entity에는 도메인 로직이 들어감
  • DDD 관점에서 볼 때, Domain Layer에 위치

 

매핑 개발

Service

여러 서비스에서 사용시 중복코드 발생
서비스 객체에 모델간 매핑 로직은 서비스 객체의 목적에 부합하지 않음

Model Object

  • 장점
    • 빠른 개발시 간편함
  • 단점
    • 서비스가 커지고, 모델간 다양한 매핑이 있을 경우 점점 모델 객체안에 메서드가 많아짐
    • 모델 객체에 모델간 매핑 로직은 모델 객체의 목적에 부합하지 않음
    • Entity안에 VO변환 로직을 넣고, VO안에 Entity 변환 로직을 넣게 된다면 (이러면 안되지만), 양방향 의존으로 인한 스파게티 코드 발생

Mapper

  • 모델간 매핑에 대한 책임
  • 역할 : 모델간 모델 매핑

mapper를 이용한 모델 객체를 사용하게 될 때, 다시 한번 결정을 해야 하는 것이 있다.
라이브러리들을 이용해서 모델간 매핑을 자동화를 할지, 아니면 직접 Mapper를 이용해서 모델간 매핑을 처리할지이다.

여러가지 라이브러리가 있는데 그 중에서 ModelMapper와 MapStruct에 대해 얘기해본다.

ModelMapper

  • 내부적으로 리플렉션을 사용. 그래서 사용을 하지 않는 것이 좋다.
  • 리플렉션으로 인한 성능 이슈 그리고 실제 동작시 발생하다보니 자칫 예상치 못한 결과가 발생할 수 있다.
  • 리플렉션을 쓰는 대표적인 것 중 하나로 Jackson ObjectMapper가 있는데, 이는 모델 변경이 아닌 모델의 포맷에 대한 변경이고 대안이 없기 때문에 사용한다.

MapStruct

  • 리플렉션 사용하지 않음
  • 컴파일시 생성
  • 레퍼런스
    • 국내는 적지만, 미국에서 점점 사용도가 높아지고 있음

 

MapStruct Example

MemberMapper.java

import org.mapstruct.Mapper;

@Mapper(componentModel = "spring")
public interface MemberMapper {

   MemberVO toVO(Member member);

}

 

Member.java

import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Getter
@Setter
@EqualsAndHashCode(of = { "memberId" }, callSuper = false)
@Table(name = "member")
public class Member extends BaseEntity {

   @Id
   @Column
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   private Long memberId;

   @Column
   private String memberName;

}

 

MemberVO.java

import lombok.Builder;
import lombok.Value;

import java.time.LocalDateTime;

@Builder
@Value
public class MemberVO {
   private Long memberId;
   private String memberName;
}

 

Kotlin에서 모델 매핑

  • Kotlin에서도 MapStruct를 쓰기도 함
  • 객체 생성 후에 기존 객체에 확장메서드(extenstion function)를 이용한 매퍼

Comments

  1. 이수민 2019.09.06 14:29 Permalink Modify/Delete Reply

    좋은 글 감사합니다~

    혹시 mapper 는 보통 어느 레이어에 두시나요?

    domain.model.member.Member
    domain.model.member.MemberDomainService
    application.member.dto.MemberDto
    application.member.MemberApplicationService

    domain.model.member.MemberMapper
    application.member.MemberMapper
    application.member.dto.MemberMapper
    application.mapper.MemberMapper
    mapper.member.MemberMapper

    Application Layer 에 위치하는게 가장 좋아보이기는 하는데,, 이런거는 정답도 없어서 더 고민되네요

    • 아틴 2019.09.06 15:19 신고 Permalink Modify/Delete

      Mapper는 특정 레이어에 종속적이라고 생각하지 않습니다. Mapper의 목적이 오브젝트와 오브젝트를 변환해주는 것이 목적이기 때문인데요.

      Domain Layer
      Application Layer
      Presentation Layer

      모델 오브젝트의 위치가 중요하다고 생각합니다.
      DTO1을 DTO2로 변경한다고 했을 때, 두 DTO가 모두 Presentation Layer로 같은 Layer에 있다고 하면 Mapper는 Presentation Layer에 있어야 한다고 보구요.

      DTO1은 Domain Layer에 있고
      DTO2는 Application Layer에 있다고 하면 Application Layer에 Mapper가 있어야 한다고 봅니다.

      단순히, 두 모델 오브젝트를 의존할 수 있는 Layer에 Mapper를 두는 것이 맞다고 생각하는 부분입니다.

      DTO1은 Domain Layer에 있고
      DTO2는 Application Layer에 있을 경우
      Mapper가 Domain Layer에 있으면 해당 Mapper는 DTO2를 참조할 수 없어서 매핑을 할 수가 없습니다. (레이어를 패키지로 분리했다면 의존할 수 있겠지만.)
      Application Layer는 Domain Layer를 의존하고 있지만 Domain Layer는 Application Layer를 의존하지 않아야 하기 때문입니다.

      domain.member.dto
      application.member.dto
      application.member.mapper

    • 이수민 2019.09.10 10:49 Permalink Modify/Delete

      모델 오브젝트의 위치에 따라 단순히 생각하면 되겠군요!

      감사합니다

  2. A.S.L 2019.09.09 21:20 신고 Permalink Modify/Delete Reply

    MapStruct 한글로 정리된 글 찾다보니 여기까지 왔네요.
    좋은글 감사해요~

Leave a Comment

최근에 MapStruct라는 것에 대해 알게 되었는데 이거 상당히 좋다.
국내에는 관련 글이 거의 없지만 해외쪽에 관련들 글들이 많아서 보고 있다.

다 좋은데 하나 아쉬운 점은 기본 생성자와 빌더를 통해서만 처리를 한다는 점이 아쉽다.

 

Reference
[1] 맛보기  https://stylishc.tistory.com/138
[2] Guide https://mapstruct.org/documentation/dev/reference/html/ 
[3] https://mapstruct.org/
[4] Example 1 https://www.credera.com/blog/technology-solutions/mapping-domain-data-transfer-objects-in-spring-boot-with-mapstruct/
[5] Example 2 https://github.com/mapstruct/mapstruct-examples
[6] Example 3 https://github.com/arberg/mapstruct-test
[7] Immutable 미지원 관련 https://github.com/mapstruct/mapstruct/issues/1755

 

MapStruct – Java bean mappings, the easy way!

Java bean mappings, the easy way! Get started Download

mapstruct.org

 

MapStruct 1.3.0.Final Reference Guide

The mapping of collection types (List, Set etc.) is done in the same way as mapping bean types, i.e. by defining mapping methods with the required source and target types in a mapper interface. MapStruct supports a wide range of iterable types from the Jav

mapstruct.org

 

MapStruct 맛보기

mapStruct mapStruct Summary & Why? 타입 세이프하게 bean 매핑을 도와주는 어노테&#..

stylishc.tistory.com

 

 

 

Leave a Comment

Docker command


Docker default command

Docker container run 명령

docker container run <Docker Image name> <command>


ex) docker container run ubuntu:latest /bin/echo 'Hell oWorld'


Docker Version

docker version


Docker System Info

docker system info


Docker disk

docker system df


Docker nginx install

docker pull gninx


Docker image list

docker image ls


Docker run nignx

docker container run --name webserver -d -p 80:80 nginx


Docker process

docker container ps

docker container stats webserver


Docker nginx command

docker stop webserver

docker start webserver




Docker Image

Docker Hub

https://hub.docker.com

공식 Docker 이미지는 목록 상자에서 'Official'을 선택하면 표시됨


Docker Store

https://store.docker.com/


Docker image

image name  [:tag name]

ex: debian:7


Docker image download

docker image pull [option] image-name[:tag name]

ex) docker image pull centos:7

ex) docker image pull -a centos

ex) docker image pull gcr.io.tensoflow/tensoflow


Docker image list

docker image ls [option] [repository-name]

option) -all, -a, --gigests, --no-trunc, --quiet, -q


DCT 기능

Docker 이미지의 정당성을 확인하는 기능, 위장이나 변조를 막기 위함

https://docs.docker.com/engine/security/trust/content_trust/#image-tags-and-content-trust


Docker image inspect

이미지 상세 정보 확인

docker image inspect centos:7









'Infra' 카테고리의 다른 글

Docker command  (0) 2018.12.17

Leave a Comment

로컬에서 카프카 사용시 자주 쓰는 콘솔 명령어 모음


서버 시작

./bin/zookeeper-server-start.sh -daemon config/zookeeper.properties ./bin/kafka-server-start.sh -daemon config/server.properties



토픽 조회

./bin/kafka-topics.sh --list --zookeeper localhost:2181



Producer

./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic topicname



Consumer

./bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topicname --from-beginning



Topic 생성

./bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic topicname



kafka-console-consumer.sh 상세

https://gerardnico.com/dit/kafka/kafka-console-consumer



kafka-consumer-offset-reste 상세

https://www.letmecompile.com/kafka-consumer-offset-reset/



카프카 오프셋 리셋하고 다시 받기

kafka-consumer-groups.sh --bootstrap-server kafka-domain:port --group kafkalocaltestatin --topic topicname --reset-offsets --to-datetime 2018-12-12T00:00:00.000 --execute kafka-console-consumer.sh --bootstrap-server kafka-domain:port --topic topicname --consumer-property group.id=kafkalocaltestatin


'Infra > NoSQL&Cache' 카테고리의 다른 글

[KAFKA] 콘솔 명령어 모음  (1) 2018.10.15
Redis 설치 및 커맨드 정리  (0) 2018.08.12
MongoDB 명령어  (0) 2014.03.09
JBoss - Infini Span  (0) 2013.11.20
분산 캐시 Memcached  (0) 2013.11.19

Comments

  1. psb8232 2020.11.26 02:32 Permalink Modify/Delete Reply

    유용한 내용 정말 잘 배우고 가용~

Leave a Comment

AWS 보안

시스템 보안 : IAM, 보안 그룹, VPC

  • 책임공유환경 (shared-responsibility)

    • AWS와 사용자가 책임을 공유한다는 의미

AWS가 지는 책임

  • 자동화된 모니터링 시스템과 DDOS 공격을 방지하는 강력한 인터넷 접근 감시를 통한 네트워크 보호

  • 민감한 영역에 접근했던 직원에 대한 뒷조사 수행

  • 수명이 다한 스토리지 디바이스를 물리적으로 파기함으로써 장치 해제

  • 데이터센터의 물리적, 환경적 보안 보장 (화재 예방, 직원 보안 등)

보안 표준

사용자의 책임

  • 공격자가 데이터를 읽거나 조작하는 것을 방지하기 위해 네트워크 트래픽 암호화하기 (예 : HTTPS)

  • 트래픽을 보안 그룹과 ACL로 제어하는 VPN의 방화벽 구성하기

  • 가상 서버의 OS와 추가 스프트웨어에 대한 패치 관리

  • IAM을 활용하여 S3나 EC2 같은 AWS 자원으로의 접근을 최소화한으로 제한하는 접근 관리 구현

소프트웨어 업데이트

보안 업데이트 확인

  • SSH로 아마존 리눅스 EC2 인스턴스 로그인

  • 오늘의 메시지 표시 확인 (예 : 3 package(s) needed for security, out of 28 available)

서버 시작시 보안 업데이트 설치

  • 서버 시작시 모든 업데이트 설치

    • 사용자 데이터 스크립트 추가 yum -y update

  • 서버 시작시 보안 업데이트만 설치

    • 사용자 데이터 스크립트 추가 yum -y --security update

  • 명시적으로 패키지 버전 정의

    • 버전 넘버로 구별하여 업데이트만 설치

실행 중인 서버에 보안 업데이트 설치

  • 서버 수가 적다면 일일히 로그인하여 실행 할 수 있겠지만 서버 수가 많다면 불가함

  • 서버의 목록을 얻고 그들 모두를 대상으로 보안 업데이트를 하도록 하는 스크립트 작성 필요

AWS 트래픽 보안

기본 규칙

  • 모든 인바운드 트래픽은 거부

  • 모든 아웃바운드 트래픽은 허용

  • 여기에 인바운드 트래픽을 허용하기 시작

  • 아웃바운드 트래픽에 대한 규칙 추가시 기본 설정은 모두 허용에서 모두 불허로 전환되고 추가 규칙만 예외적으로 허용됨

보안 그룹

  • 보안 그룹은 인스턴스와 같은 AWS 자원에 연결할 수 있어야 함

  • 보안 그룹 규칙

    • 방향 (인바운드 또는 아웃바운드)

    • IP 프로토콜 (TCP, UDP, ICMP)

    • 출발지/목적지 IP 주소

    • 포트

    • 출발지/목적지 보안 그룹(AWS에서만 작용)

ICMP 트래픽 허용

  • ping을 허용하려면 ICMP(internet Control Message Protocol) 트래픽을 허용해야 함

  • 기본적으로 모든 인바운드 트래픽이 차단되므로 ping도 실패함

  • 보안 그룹에 인바운드 ICMP 트래픽을 허용하는 규칙을 추가해야 함

SSH 트래픽 허용

CIDR example

  • 10.0.0.0/0 : all

  • 10.0.0.0/8 : 10.0.0.0 ~ 10.255.255.255

  • 10.0.0.0/16 : 10.0.0.0 ~ 10.0.255.255

  • 10.0.0.0/24 : 10.0.0.0 ~ 10.0.0.255

바스티언 호스트 (bastion host, 점프 박스 jump box)

  • 하나의 특정 서버만 SSH를 통해 접근할 수 있도록 하게 하는 것

  • 유일하게 SSH 접속이 허용된 호스트

가상 사설 클라우드 (VPC, Virtual Private Cloud)

  • 사설 네트워크망 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 범위 주소 사용 가능)

  • VPN 엔드포인트에 서브넷, 라우팅 테이블, 접근 제어 목록 및 게이트웨이를 만들 수 있음

  • 적어도 2개의 서브넷은 있어야 함, 공용과 사설

  • 공용 서브넷은 인터넷 경로

  • 사설 서브넷은그렇지 않음

  • VPC는 주소 공간 10.0.0/16을 사용


Reference

  • AWS in Action


'Infra > AWS' 카테고리의 다른 글

AWS 보안  (0) 2018.09.29
AWS - 가상 서버 사용  (0) 2018.09.28
AWS란?  (0) 2018.09.28
AWS (Amazon Web Services) - 공부자료  (0) 2018.09.02

Leave a Comment

AWS 가상 서버

가상 어플라이언스 (virtual appliance)

  • 하이퍼바지어에서 실행할 수 있는 OS와 사전 구성된 소프트웨어를 포함하는 이미지

  • 하이퍼바이저의 일이란 하나 이상의 가상 어플라이언스를 실행하는 것

  • 고정된 상태로 포함되어 있어서 시작할 때마다 정확히 같은 결과를 얻을 수 있음


AMI

  • AWS에서 가상 어플라이언스의 이미지

  • 가상 서버의 EC2 서비스를 사용하기 위한 특별한 가상 어플라이언스

  • OS, 추가 소프트웨어 및 그것들의 구성을 포함하는 읽기 전용 파일 시스템으로 구성

  • OS의 커널은 포함하지 않음

  • 커널은 아마존 커널 이미지(AKI, Amazon kernel image)에서 로드됨

  • AWS에 소프트웨어를 배포하는데 사용할 수 있음


인스턴스 유형과 인스턴스 패밀리

  • 인스턴스의 이름

    • 모두 동일한 방식을 따름

  • 인스턴스 패밀리

    • 같은 초점을 가진 인스턴스 유형

  • 세대 (generation)

    • 같은 유형의 다른 업그레이드 된 버전이 출시될 경우의 개념

  • 1세대, 2세대 등으로 구분

  • 인스턴스 크기

    • CPU, 메모리, 스토리지, 네트워크의 능력을 정의

    • 가상 서버의 크기는 언제든지 변경 가능


키를 잊어버렸을 경우

  • 가상 서버에 로그인하려면 키가 필요함

  • 가상 서버는 인증용으로 비밀번호 대신 키를 사용

  • 공개키 방식이 비밀번호 입력 방삭보다 훨씬 안전

  • 윈도우는 SSH 클라이언틀 내장하지 않으므로 별도로 Putty, PuTTYgen이라는 도구를 사용해야 함


가상 서버 상태

  • 시작

    • 중지된 가상 서버를 시작할 수 있는 상태

  • 중지

    • 실행 중인 가상 서버를 중지 가능함

    • 비용이 청구되지 않는 상태(네트워크 연결 스토리지 등의 자원을 제외하고)

    • 나중에 다시 시작 가능

    • 네트워크 연결 스토리지를 사용하면 데이터를 그대로 남아있게 됨

  • 재부팅

    • 재부팅하는 경우

    • 데이터가 손실되지 않음

  • 종료

    • 삭제를 의미

    • 종료한 가상 서버를 다시 시작할 수 없음

    • 네트워크 연결 스토리지, 공용 및 사설 IP 주소와 같은 종속성도 함께 삭제됨


공인 IP 주소

  • IPv4 주소는 아무 부족함

  • 일래스틱 IP 주속 고갈을 방지하기 위해 서버와 연결되지 않은 일래스틱 IP 주소에 비용이 청구됨



Reference

- AWS in Action - 가상 서버 사용하기 : EC2






'Infra > AWS' 카테고리의 다른 글

AWS 보안  (0) 2018.09.29
AWS - 가상 서버 사용  (0) 2018.09.28
AWS란?  (0) 2018.09.28
AWS (Amazon Web Services) - 공부자료  (0) 2018.09.02

Leave a Comment

AWS란?

아마존 웹 서비스 (Amazon Web Service)

  • 추상화된 각기 다른 계층에 컴퓨팅, 저장 공간, 네트워킹 솔루션을 제공하는 웹 서비스의 플랫폼

  • 공용 클라우드



클라우드 컴퓨팅

  • IT 자원의 공급과 소비를 은유적으로 빗댄 용어

  • 관리 노력과 서비스 공급자의 상호 작용을 최소화하면서 신속하게 제공하거나 해제할 수 있는 구성 가능한 컴퓨팅 리소스의 공유 풀에 어디서나 편리하게 필요한 시점에 네트워크로 접근할 수 있게 하는 모델



클라우드 유형

  • 공용 (Public)

    • 조직이 관리하고 일반 대중이 사요하도록 개발된 클라우드

  • 사설 (Private)

    • 하나의 조직 범주 내에서 IT 인트라를 공유하고 가상화하는 클라우드

  • 하이브리드 (Hybrid)

    • 공용 클라우드와 사설 클라우드의 혼합형


클라우드 컴퓨팅 서비스 분류

  • 서비스로의 인프라 (IasS, Infrastructure as a Service)

    • 가상 서버를 이용하여 컴퓨팅, 스토리지, 네트워킹 기능 등과 같은 기본적인 자원을 제공

  • 서비스로서의 플랫폼 (PaaS, Platform as a Service)

    • 클라우드에 사용자 지정 애플리케이션을 배포할 수 있는 플랫폼을 제공

  • 서비스로서의 소프트웨어 (SaaS, Software as a Service)

    • 인트라와 클라우드에서 실행되는 소프트웨어를 결합


AWS 상호작용

  • 관리 콘솔

    • 웹 기반 관리 콘솔

  • 명령줄 인터페이스 (CLI, Command-line interface)

    • AWS와의 작업을 자동화하는데 일반적으로 사용함

    • 젠킨스와 같은 지속적 통합 서버의 도움으로 인프라 일부를 자동화하려는 경우에 적합한 도구

    • 여러 CLI 호출을 모아놓은 스클립트로 인프라 자동화를 할 수 있음

    • 윈도우, 맥, 리눅스 및 파워셸 지원

  • SDK

    • 애플리케이션에서 AWS를 호출할 때 사용

    • 원하는 프로그래밍 언어로 애플리케이션 로직에 AWS를 통합할 수 있음

  • 블루프린트(blueprint)

    • 시스템에 관한 설명

    • 그 시스템의 모든 서비스와 종속성을 포함

    • 기술된 시스템을 실체화하는데 필요한 조치나 순서에 대해서는 아무 언급도 하지 않음

    • 구성 요소가 많거나 복잡한 환경을 제어해야 하는 경우 사용

    • 클라우드 인프라의 구성을 자동화하는데 좋음



Reference

- AWS in Action



'Infra > AWS' 카테고리의 다른 글

AWS 보안  (0) 2018.09.29
AWS - 가상 서버 사용  (0) 2018.09.28
AWS란?  (0) 2018.09.28
AWS (Amazon Web Services) - 공부자료  (0) 2018.09.02

Leave a Comment


to Top