0822 ~ 0911

# 0822 ~ 0911

# 0823 - ELK

# ELK란?

ELK는 Elasticsearch, Logstash, Kibana의 앞글자를 따와서 만든 약어이다.

Elasticsearch는 검색 및 분석 엔진
Logstash는 데이터를 수집하여 변환 후 Elastic search같은 서버로 전송하는 데이터 처리 파이프라인
Kibana는 사용자가 수집한 데이터를 시각화하여 볼 수 있다.
즉, 데이터를 수집해 시각화 하는 오픈소스

ELK는 오픈소스로, 무료로 사용이 가능하다.
클라우드 같이 많은 데이터를 수집하는 서버는 로그가 많아 분석하는데 어려움이 존재하는데, 로그 파일의 용량이 커져 디스크 공간이 부족하거나, 특정 로그를 검색하기엔 너무 데이터가 많아 찾기 어려운 부분이 있다.
그래서 ELK를 사용하여 로그의 분석 및 검색을 효율적으로 할 수 있다는 장점이 있다. ㅇ여기에 데이터 수집을 하는 Filebeat가 추가되면서 ELK Stack으로 불리게 되었다.

# ELK Stack

# 1. Elastic search

Apache Lucene 기반의 Java 오픈소스 분산 검색엔진.
Elasticsearch는 Logstash로부터 받은 데이터를 검색 및 분석하여 필요한 정보를 얻을수 있다.
얼마나 빠르냐면 10년치 데이터를 OracleDB에서 검색하면 1달정도 기다려야 결과를 볼 수 있는데, Elasticsearch를 사용하여 검색하니 결과가 단 몇분만에 나올 수 있다.

# 2. Logstash

scv, DB 등 다양한 소스에서 로그 등의 데이터를 수집, 집계, 파싱하여 Elasticsearch로 전달.
서버측 데이터 처리 파이프 라인으로 데이터 수집 엔진이다.

# 3. Kibana

Elasticsearch와 함께 동작하도록 설꼐된 오픈소스 분석 및 시각화 플랫폼.
히스토그램, 선형 그래프, 원형 차트 등 다양한 차트 및 분석에 대해 시각화할 수 있는 기능을 제공.

# 4. Filebeat

서버에 에이전트로 설치하여 다양한 유형의 데이터를 Elasticsearch 또는 Logstash에 전송하는 데이터 전달자이다.
Filebeat은로그 데이터를 지정하는 inputs를 가지는데, 여기서 데이터가 발생할 때마다 수집하여 전송.

# 0829 - MockMvc vs Restassured

# MockMvc

# 사용목적

MockMvc는 웹 어플리케이션을 애플리케이션 서버에 배포하지 않고도 스프링 MVC의 동작을 재현할 수 있는 라이브러리이며 대부분 Controller Layer Unit Test(단위 테스트)에 사용된다.

실제 서버 환경과 동일한 @SpringBootTest를 사용할 필요가 없으므로 @WebMvcTest를 통해 Presentation Layer Bean들만 불로온다. 그리고 그 외 Bean은 Mock 객체 설정을 해주어 순수한 Controller 로직을 테스트한다.

# 의존성

MockMvc는 Spring Framework Test 클래스 중 하나다. 즉 Spring test 의존성이 추가되어있는 경우 별도의 의존성 추가를 하지 않아도 사용할 수 있다.

# 속도

MockMvc는 별도의 구성없이도 @WebMvcTest로 테스트를 수행할 수 있다. 물론 @SpringBootTest로도 수행할 수 있다. MockMvc를 @WebMvcTest로 수행하는 방법은 아래와 같다.

@WebMvcTest
@AutoConfigureMockMvc
public class ApiTest {
    @Autowired
    private MockMvc mockMvc;
    ...
}

# 가독성

@Test
public void getMember() throws Exception {
    mockMvc.perform(get("/members/1")
            .accept(MediaType.APPLICATION_JSON))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.id", Matchers.is(1)))
}

# RestAssured

# 사용목적

RestAssured는 REST 웹 서비스를 겁증하기 위한 라이브러리이며 대부분 End-to-End Test(전 구간 테스트)에 사용된다.

@SpringBootTest로 실제 요청을 보내서 전체적인 로직을 테스트한다. 실제 요청시 필요한 다양한 메서드도 제공한다.

# 의존성

RestAssured는 직접 의존성을 추가해줘야 한다.

dependencies {
    testImplementation 'io.rest-assured:rest-assured:3.3.0'
}

# 속도

RestAssured는 별도의 구성없이 @WebMvcTest를 사용하지 못한다. 사용하기 위해선 아래와 같이 @SpringBootTest로 수행해야 한다.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class Test {
    @LocalServerPort
    public int port;

    @BeforeEach
    void setUp() {
        RestAssured.port = port;
    }
    ...
}

@SpringBootTest로 테스트를 수행하면 등록된 Spring Bean을 전부 로드하기 때문에 시간이 오래 걸린다. 반면에 @WebMvcTest는 Presentation Layer의 Bean들만 로드하기 때문에 시간이 상대적으로 빠르다.

# 가독성

@Test
public void getMember() {
    given().
            accept(MediaType.APPLICATION_JSON_VALUE).
    when().
            get("/members/1").
    then().
            log().all().
            statusCode(HttpStatus.OK).
            assertThat().body("id", equalTo(1)); 
}

RestAssured는 BDD 스타일로 작성할 수 있고 가독성이 좋다.

# 0904 - 객체지향 설계 5원칙 SOLID (SRP, OCP, LSP, ISP, DIP)

# SOLD란?

객체지향 설계는 긴 세월과 수많은 시행착오를 거치며 5가지 원칙이 정리되었다. 이것을 객체지향 설계의 5원칙이라고 하며, 앞글자를 따서 SOLID라고 한다.
1. SPR(Single Responsibility Principle) : 단일 책임 원칙
2. OCP(Open Closed Principle) : 개방 폐쇄 원칙
3. LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
5. DIP(Dependency Inversion Principle) : 의존 역전 원칙 이 원칙들은 응집도는 높이고 결합도는 낮추자는 고전 원칙을 객체 지향의 관점에서 재정립한 것으로 볼 수 있다.

# SRP = 단일 책임 원칙

어떤 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 한다.

SRP가 안지켜진 사례
- 변수레벨
  - 하나의 속성이 여러 의미를 갖는 경우
  - 어떤 곳에서는 쓰고, 어떤 곳에선 안쓰는 속성이 있는 경우
- 메소드레벨
  - 분기처리를 위한 if문이 많을 경우

# OCP = 개방 폐쇄 원칙

소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다. 즉, 자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀 있어야 한다는 것이다. 이것은 interface를 통해 구현하여 해결한다.
현실의 예를들면 상점직원이 아무리 바뀐다고해서 손님이 상품을 구매하는 데는 지장이 없다.

# LSP = 리스코프 치환 원칙

서브타입은 언제나 자신의 기반타입으로 교체할 수 있어야 한다. 즉, 하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 수행하는데 문제가 없어야 한다. 이것은 OOP 4대 특성의 상속, 인터페이스 원칙이 잘 지켜진다면 LSP는 자동으로 잘 적용된 것이다. (주로 조직도, 계층도 관점에서의 상속이 LSP를 위배하는 문제가 생긴다)

# ISP = 인터페이스 분리 원칙

클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다. ISP는 SRP와 비슷하지만 인터페이스를 통한 다른 해결책을 제안하고 있다. 예를들어 class 사람 implemnets 군인 이면 군인 홍길동 = new 사람() 을 통해 군인 인터페이스의 메소드만을 사용하도록 제한하는 것이다. SRP 였다면 class를 나누겠지만, 일반적으론 ISP보다 SRP를 권장한다.

# DIP = 의존 역전 원칙

고차원 모듈은 저차원 모듈에 의존하면 안된다. 추상화된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야 한다. 자주 변경되는 클래스에 의존하지 말자.로 요약 할 수 있다. 즉, 자신보다 변하기 쉬운 것에 의존하지 말라는 것이다. 해결방법은 OCP와 비슷한데, 구체적인 class가 아닌, 인터페이스에 의존함으로써 DIP를 해결한다.

0815 ~ 0824 0912 ~ 0918

0822 ~ 0911

# 0822 ~ 0911

# 0823 - ELK

# ELK란?

# ELK Stack

# 1. Elastic search

# 2. Logstash

# 3. Kibana

# 4. Filebeat

# 0829 - MockMvc vs Restassured

# MockMvc

# 사용목적

# 의존성

# 속도

# 가독성

# RestAssured

# 사용목적

# 의존성

# 속도

# 가독성

# 0904 - 객체지향 설계 5원칙 SOLID (SRP, OCP, LSP, ISP, DIP)

# SOLD란?

# SRP = 단일 책임 원칙

# OCP = 개방 폐쇄 원칙

# LSP = 리스코프 치환 원칙

# ISP = 인터페이스 분리 원칙

# DIP = 의존 역전 원칙

Description