오랜만에 블로그 글을 쓰는 것 같다.

마지막 취업글이 파견에 대한 이야기였으니 그로부터 몇 달이 지나 서울 본사로 올라와 근무 중 안 좋은 소식에 접했다.

문득 스타트업에서 처음 입사지원서를 낼 당시에 깊은 고민을 하지 않았던 요인들이 떠올랐다.

"스타트업은 불안정하다", "내가 하고싶은 일만 할 수 있는 게 아니다" 등등 여러 단점이 많았으나, 나는 더 다양한 경험과 마음속에 있던 모험심에 이끌려 지원했던 것 같다.

어떤 일이던 직접 경험해보기 전에는 단점에 대해 와닿지 못하는 것 같다고 생각하며 실제로 내가 이러한 소식을 겪을 줄도 꿈에도 몰랐다.

경영상의 이유로 회사를 나왔고, 지난주 다른 회사 면접을 통해 15일자로 입사를 하게 되었다.

사실 이직을 할 생각이 없는 것은 아니었으나 애매한 경력이라는 점이 마음에 많이 걸렸었다. 또 경력직으로 면접을 보았으나, 신입입사를 권유받았고 신입으로 입사를 하게 되었다.

결과적으로만 본다면 이직을 성공했기에 잘되었다고 느낄 수 있지만, 처음 회사를 급하게 나올 때 심정으로는 정해진 길에 따라 달리고 있는 기차에서 갑자기 튕겨져 나온 느낌이었다. 주변 사람들 역시나 각자의 레일에 따라 나아가고 있는 상황에서 갑자기 취준생으로 돌아온 기분이랄까..

재취업 준비를 하며 회사에서 했던 일을 정리하기도 하고.. 짧았던 회사생활에 대한 기억도 많이 해보았다.

다음 회사에선 지난 회사생활에서의 내 단점을 보완해야겠다는 마음도 있었고 신입이지만 조금 더 업무를 빠르게 적응하기 위해 자바 강좌도 다시 한번 돌려보고 있다.

그리고 회사를 찾을 때는 평판을 보는 것도 중요하지만 매출액, 투자 관련 정보도 그만큼 아주 중요하다는 걸 생각하게 되었다. ㅋㅋㅋ

이번 이직한 회사는 다행히 내가 사용하던 기술스택은 그대로이지만 도메인은 사실상 처음 접해보는 핀테크 분야이다.

이전 회사에서도 느껴보았지만 도메인에 대한 공부는 제조를 기준으로 했을 때는 1달 정도 걸렸는데.. 핀테크는 양이 많다고 알려져 있어 얼마의 기간이 걸릴지 모르겠지만 다시 신입의 마음으로 열심히 달려야 할 것 같다.

오늘은 ClickHouse Database 의 cluster를 구성해보려고 한다.

해당 글을 읽기 전 나는 혼자힘으로 구성해보고 싶다 하는 사람이 있다면 다음 공식문서를 한번 참고해보자.

( https://clickhouse.com/docs/en/intro )

( 사실 공식문서를 직접 읽고 따라해보는것이 제일 좋은 경험이라고 생각한다. )

비교적 ElasticSearch 와 비슷하면서도 특징이 다른 ClickHouse를 사내에서 사용했고 이번 기회에 분산저장구조를 구성해보던 중 ClickHouse와 관련된 정보를 블로그에서는 찾기가 많이 어려웠기 때문에..

(나는 결국 공식문서를 참고해서 하나부터 열까지 만들어보았으나) 비교적 쉽게 설명해보려고 한다.

이전 Hadoop 의 맵리듀스를 이용해보기위해 분산 저장 구조를 구축해본 경험이 있어 환경구성에서는 비교적 어렵게느꼇던 것은 없었다.

처음은 Virtualbox 에서 가상머신을 3개 만들어보자 물론 꼭 가상머신을 사용해야하는것은 아니며, 자신이 사용하기 편한 가상환경을 구성해도 좋고 실제 컴퓨터를 3대로 구성해보아도 좋다.

해당 글은 가상머신을 기준으로 구성했다.

이렇게 3개의 머신을 구성하고 OS 는 Rocky Linux 8 버전을 사용했다 Linux파일은 다음 사이트를 참고해서 iso파일을 사용환경에 맞게 다운받자. (https://rockylinux.org/download/)

이 후 가상머신을 바로 시작하고싶으나 그 전 한 가지 설정을 더 해주자

여기서 중요한 점은 네트워크 어댑터 관련 설정이다.

왜 네트워크 설정이 필요할까 ? 

위 3대의 가상머신은 현재 서로의 존재를 모르는 상태이다.

옆집에 누가살고있는지 통성명(?)도 안한 상태이다.

저 3대의 가상머신은 구동시킨 우리PC(로컬)의 ip를 이용하기만 하는 녀석이다.

그렇기때문에 우리가 이 가상머신들 사이에 브릿지를 둬서 옆집에는 김xx씨, 이xx씨(host name, host ip)가 살고있다는 것을 알려주자.

가상머신의 설정을 보자

설정 - 네트워크 탭을 확인해보면 기본 네트워크 설정인 NAT으로 되어있을 것이다.

이 NAT은 현재 우리 PC의 아이피를 이용해 가상머신 속에서 인터넷을 사용하고 있는 상태 라고 보면 된다.

우리는 여기서 두번째 어댑터를 만들어보자.

여기서 설정해주어야 할 것은 호스트 전용 어댑터 설정과 무작위 모드를 설정해주어야한다

무작위 모드는 사실 가상머신에 허용 과 모두 허용 중 원하는것으로 설정하자.

설정이 끝났다면 

다운받은 리눅스 디스크를 가상머신에 등록하고 실행시키자

나는 현재 환경을 따로 추출해둔 것을 사용했기때문에 위치가 

IDE 가 아닌 SATA에 있지만 따라하는 분들은 저 위에 비어있음에 등록해야 한다.

이어서 리눅스가 실행되었다면 리눅스에 설정을 또 한번 해주자..

(아직 설정할게 더 남아있다)

다운받은 리눅스를 등록해주고 실행하자.

이후 언어를 선택하고 들어가면 다음과 같은 화면이다

우린 여기서 밑줄친 3개의 비밀번호, 파티션, 네트워크 설정을 꼭 해주자

파티션과 비밀번호는 알아서 설정하면 되고 특별한건 네트워크설정을 들어갔을 때 어댑터가 두개 보일 것이다.

여기서 enp0s3어댑터는 초기 1번 네트워크어댑터로 NAT를 의미하고 우린 이걸 켜주자.

이어서 설치가 끝났다면 우린 clickhouse 데이터베이스를 설치하기 전 네트워크 환경에대한 구성을 마지막으로 해주어야한다.

현재 이웃이 서로 알아볼 수 있는 다리까지는 놓여있으나 아직 이름은 모르는 상태이다. 우린 이제 이웃의 이름과 아이피를 만들어주고 알아볼 수 있도록 각각의 가상머신에 이 정보를 기입해주자.

지금부터는 각각의 가상머신에 모두 설정해주어야한다. 

해당 경로의 파일을 들어가서 다음과같이 작성해주자

중요한건 아래 3줄이다. 특정 ip, hostname 을 정의해서 host(가상머신)끼리 알아볼 수 있도록 하는 것이다.

이후 방금 hosts에서 설정한 ip가 이웃들 사이에서 알아볼 수 있는 주소 이기 때문에

저 주소를 설정 해주자.

vim /etc/sysconfig/network-scripts 를 들어가보면 우리가 처음 가상머신을 생성할 때

만들어두었던 네트워크 어댑터가 표시되고 이중에서 이웃과 통신할 목적으로 생성한 어댑터는 s8이다.

만약 네트워크어댑터를 추가하지않고 저 경로로 접속했을 경우에는 s3어댑터만 존재하는것을 테스트해볼 수 있다.

우리는 이제 저 s8어댑터에 대한 아이피를 고정으로 설정해줄 것이다.

즉

두번째 어댑터는 이웃과의 통신을 위해 생성했던 것이고 이 어댑터에 이웃들이알아볼 수 있는 주소를 적어두어야 편지를 주고받을 수 있기 떄문에 ..?? 라고 생각하면 조금 더 쉬울 것 같다.

여기서 BOOTPROTO 를 none or static 중 하나로 설정해주고

IPADDR, GATEWAY를 설정해준다

고정 IP 를 사용 할 것이기에 직접 명시해주어야 한다.

이제 위 방식을 그대로 3개의 가상머신은 또 각각의 ip와 hostname으로 설정을 동일하게 진행하자

이후 각각의 가상머신의 방화벽을 해제해주면 설정은 끝난다.

방화벽 해제하는법은 다음을 따라하자

우선 방화벽을 끄고

systemctl stop firewalld.service

이후 컴퓨터를 다시 재부팅했을 때 서비스가 실행되지 않도록 disable해주자

systemctl disable firewalld.service

이후 network를 재부팅해주자

systemctl restart network (network service가 없다면 무시하자)

마지막으로 방화벽의 상태를 확인하면 환경설정은 끝난다.

systemctl status firewalld.service

위 순서를 그대로 아래사진으로 표현해보겠다.

자 이 방화벽도 역시나 3개 다 해주자.. (귀찮겠지만 꼭 필요하다)

다음 글에서는 이제 clustering 에 필요로 하는 데이터베이스인 클릭하우스 설치부터 작성하겠다.

Spring Web Layer

오늘은 Spring Web Layer에 대해 알아보자.

위 사진을 보면 Web, Service, Repository, DTOs, Domain Model이 존재하는데 각 Layer계층 속 controller, service, 등이 포함되어 있고 프로젝트를 구성할 당시 각 레이어에 목적에 맞게 나누어 개발을 진행한다

스프링 웹 아키텍처와 관련하여 아래 레퍼런스 문서를 살펴보면 가장 크게 두가지 원칙을 따르는 것이 기본으로 소개한다.

1. 관심사 분리(SoC(Separation of concerns)) 원칙

• 참고문서 - (https://en.wikipedia.org/wiki/Separation_of_concerns)
• 관심분리라는 원칙을 간단하게 알고넘어가자면 각 부분(클래스 혹은 기능)이 별도의 관심사를 다루도록 컴퓨터 프로그램을 섹션분리하기 위한 설계원칙이다.
• 여기서 관심사란 무엇일까? 를 한번 생각해보자. 관심사는 쉽게 말해 행동이라고 정의하고 이해하면 조금 더 이해하기 쉬웠던 것 같다.

  public void First(Object o) {
    log.info("First Function Call");
    System.out.println("My Parameter : " + o.toString());
    // Logic ...
  }
  public void Second(Object o) {
    log.info("Second Function Call");
    System.out.println("My Parameter : " + o.toString());
    //Logic ...
  }

  공통된 코드(관심사)를 확인할 수 있을 텐데 이러한 관심사들을 적절하게 나누는 것을 의미한다.

  public void printInfo(String functionName, Object o) {
    log.info("{} Function Call", functionName);
    System.out.println("My paramter : " + o.toString());
  }
  
  public void first(Object o) {
    printInfo("First", o);
    // Logic ...
  }
  public void second(Object o) {
    printInfo("Second", o);
    //Logic ...
  }

  이렇게 공통된 관심을 하나의 함수로 구현하여 분리했다
• 위 코드의 로그와 프린트 부분을 하나의 함수로 바꾸어 구현한다면 다음과 같이 구현할 수 있다.
• 아래 코드를 확인해 보자

위 사항을 조금 더 Spring입장으로 바라본다면 횡단 관심사(Cross-cutting concerns)라고 부르고 이 횡단관심사는 핵심로직이 아닌 위와 같이 로그, 프린트, 파라미터객체, 트랜잭션 등 을 의미한다.

이런 횡단관심사는 다시 또 AOP를 통해 횡단 관심사 분리를 할 수 있으니 AOP에 대한 설명을 한번 더 확인해 보면 좋을 것 같다.

2. KISS(Keep It Simple Stupid) 원칙

참고문서 - (https://en.wikipedia.org/wiki/KISS_principle)

• 키스원칙이라 불리며 KISS는 "Keep it simple, stupid", "keep it short and simple", "keep it short and sweet" 의미이다
• 간단하게 말하자면 코드를 단순하게 만드는 것이 좋고 불필요하게 장황하거나 복잡해지는 것을 피하라는 의미로 이해하면 좋겠다.

본론으로 돌아와서 위 두 가지를 간단하게 요약하자면 한 가지 기능만을 작동하도록 함수를 구현하되 단순하게 코드를 구성하라는 의미가 된다.

이러한 원칙을 따르며 각 레이어에 대한 특징을 살펴보자.

1. Web Layer
   • 가장 앞단으로써 Spring MVC의 동작과정 속 DispatcherServlet처럼 클라이언트의 요청을 가장 처음으로 응답받는 곳이다. 그래서 이 WebLayer가 포함하고 있는 요소들도 Controller를 포함한 예외나필터가 포함되어 있다.
   • 또한 클라이언트의 첫 요청이기에 인증 및 권한 관련 부분도 여기에 해당한다.
2. Service Layer
   • Web Layer보다 아래 속하며, 트랜잭션 경계 역할을 수행한다 또 서비스계층의 공용 API를 제공하고 권한부여등의 기능을 담당한다 쉽게 말해 WebLayer단에서 필요한 작은 기능단위들을 구현되어 있는 Layer라고 생각하면 좋을 것 같다.
3. Repository Layer
   • 웹 애플리케이션의 최 하위계층으로 사용되는 데이터의 저장소와 통신을 담당합니다 쉽게 말해 데이터베이스와 통신역할을 수행한다.
4. DTOs
   • DTO들의 집합을 의미한 것이고 DTO(Data Transfer Object)는 데이터 전송을 목적으로 하는 객체다
   • 이 객체는 애플리케이션 계층 간 데이터를 전달하는 용으로 사용된다.
5. Domain Model
   • 도메인 모델은 다시 3가지로 나눌 수 있다
   • 1. 도메인 서비스
        • 도메인 서비스는 쉽게 말해 비즈니스로직이라 말하는 로직적인 관점들이 포함된 작업을 제공하는 비저장 클래스이다.
     2. 엔티티
        • 엔티티는 전체 수명주기동안 변경되지 않고 유지되는 개체이다.
     3. 개체
        • 개체는 속성이나 사물 등을 설명하며 고유 ID나 수명 주기가 없다

각 레이어 중 웹 레이어는 데이터 전송 개체만 처리해야 하고 서비스계층은 DTO를 매개변수로 사용해야 한다.

또 레포지토리계층은 엔티티를 매개변수로 사용해야 하며 각 계층에서의 구현을 통해 적절한 계층의 요소를 사용하는 것에 익숙해진다면 지금 설명하는 것들이 이해하는데 큰 도움이 될 거라 생각된다.

마지막으로 DTO사용이 필수적인지에 대한 질문에 따른 답변을 확인해 보자

실제로 구현시에 엔티티를 그냥 컨트롤러에서 반환하는 식으로도 구현을 진행할 수 있는데 이러한 DTO가 반드시 사용해야 하는 건지 의문을 가질 수 있다. 실제로 나도 VO와 DTO가 많이 헷갈리기도 했고...

그러나 위 사진을 자세히 보게 된다면 Public, Private으로 표현된 부분이 이 의문에 대한 시원한 답변이라 생각한다.

말 그대로 엔티티, 도메인모델들은 클라이언트입장에서는 감춰지고 보이지 않아야 하며 이 모델들 역시나 클라이언트 친화적으로 생성된 것이 아니기에 DTO를 통해 도메인을 숨기며 맞춤형 DTO로 제공할 수 있다는 점에서 사용한다

그리고 DTO를 변경하지 않는 한 도메인 모델의 변화에도 상관없이 제공될 수 있기에 운영, 유지보수 측면에서 장점이라 생각이 들었다.

오늘은 이것으로 Spring Web Layer에 대하여 알아보았다.

Reference

1. https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-w ay/
2. https://velog.io/@smallcherry/Spring-스프링-웹-계층-Spring-Web-Layer
3. https://jiwondev.tistory.com/122

Spring MVC동작과정

Spring MVC는 어떤 순서로 동작할까?

이를 설명하기에 앞서 MVC라는 것이 무엇인지 모르는 분들을 위해 간략하게 설명하고 넘어가고자 한다.

MVC(Model, View, Controller)를 뜻하는 소프트웨어 설계 디자인패턴 중 하나다.

[이미지 출처] (https://hanamon.kr/mvc%EB%9E%80-mvc-design-pattern/)

위 그림과 같이 각 목적에 맞게역할을 나누어 개발함으로써 운영, 관리 측면에서 효율적이고 디버깅이나 가독성이 증가하게 된다.

실제로 우리가 옷장에 옷을 정리할때 그리고 주방에 식기류를 정리할 때 등 옷장, 주방 등의 공간을 나누어 해당 공간에 맞게 물건을 정리하는 것처럼 Controller, View, Model 역할에 맞게 소스코드를 정리해 두어 나중에 더 찾기 쉽고 관리하기 편해진다.

본론으로 돌아와 Spring MVC는 그럼 어떤형태를 가지고 있을까?

위 MVC 디자인패턴의 구조를 그대로 "Spring으로 가지고온다면 어떤 형태 일까?"를 생각해 보자

[이미지출처] (https://velog.io/@solchan/Spring-Spring-MVC%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80)

다음과 같은 형태로 구성되어 있다 잘 보면 처음 설명했던 MVC 중 Model이 무엇인지 모를 수 있는데 Service가 Model의 역할을 한다고 보면 된다.

스프링 공식문서에도 이 Spring MVC에 대해 자세한 설명이 나와있으니 한번 참고해 보면 좋을 것 같다.

[공식문서] (https://docs.spring.io/spring-framework/docs/current/reference/html/index.html)

위 그림을 자세하게 살펴본다면 처음으로 Client의 요청은 DispatcherServlet과 만나게 된다. 이 DispatcherServlet은 클라이언트의 여러 요청에 맞는 공유 알고리즘을 제공하며 다양한 요청에 맞는 응답을 제공한다.

정리하자면 HTTP Protocol을 통해 들어오는 클라이언트의 여러 가지 요청을 제일 앞단에서 받아 적합한 컨트롤러에게 위임하는 프론트 컨트롤러(Front Controller)로 이해하고 넘어가자. (DispatcherServlet하나만 가지고 게시글 한 개를 쓸 만큼의 내용이 많기 때문에 지금은 간단하게만 이해하고 넘어간다)

이처럼 이 DispatcherServlet이 Spring MVC pattern에서 함께 사용된다.

이후 HandlerMapping과 ControllerAdapter(HandlerAdapter)를 알아보자.

이 HandlerMapping은 위 DispatcherServlet을 설명하던 중 여러 요청에 따라 특정 컨트롤러를 찾아서 알맞은 응답을 반환해 준다 라는 말 중 "특정 컨트롤러를 찾는"부분에 해당한다.

이 HandlerMapping이 선택한 Controller를 가지고 맞는 BLO(비즈니스로직)을 HandlerAdapter가 호출하며 요청에 맞는 로직이 작동하는 방식이다.

마지막으로 ViewResolver를 통해 결과를 보여줄 화면에 해당하는 View를 가지고 DispatcherServlet이 응답 결과를 생성한다.

이 하나의 과정이 Spring MVC가 동작하는 방식이며 단순히 글만 보고서는 완벽하게 이해가 안 될 수 있으니 동작과정 속 키워드를 한 번씩 검색해 보길 바란다.(DispatcherServlet, HandlerMapping, HandlerAdapter, ViewResolver 등)

오늘은 Spring MVC의 동작과정에 대하여 알아보았다.

Reference

1. https://docs.spring.io/spring-framework/docs/current/reference/html/index.html
2. https://mangkyu.tistory.com/18
3. https://velog.io/@hsw0194/Spring-MVC-HandlerMapping의-동작방식-이해하기-1편