문득 머리에 스친 한가지 생각.

java 17 표준 패키지중 대중의 사용빈도가 가장 패키지가뭐야?

이럴수가!!!

너무나도 재밌어보이는 클래스들!

구경하느라 시간이 다 지나갔다...

그렇다면 코딩으로 음악을 만들수는 없을까?

import javax.sound.midi.*;

public class MidiTest {
    public static void main(String[] args) throws Exception {
        Synthesizer synth = MidiSystem.getSynthesizer();
        synth.open();
        MidiChannel[] channels = synth.getChannels();

        int channel = 0;  // 채널 0번 사용
        int velocity = 100;  // 세기

        // 도레미 (C4, D4, E4) 음계
        int[] notes = {60, 62, 64};  // MIDI note number

        for (int note : notes) {
            channels[channel].noteOn(note, velocity);
            Thread.sleep(500);  // 반 박자 정도 유지
            channels[channel].noteOff(note);
        }

        synth.close();
    }
}

언젠가 코딩음악 해보겠습니다.

번외

그밖의 외면받은 패키지들…

210.xx.xx.xx /- - /[16/Dec/2024:18:45:27 +0900] /"GET/ /shield/shield_list.php /HTTP/1.1" /200 /47464 "https://shield.market.com/shield/shield_list.php"/ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0"

위와 같은 로그정보가 있으면 각각 다음과 같은 정보로 분류 할수 있다. (물론 로그포맷은 Combined)

1. Client IP
2. Identity , username
3. Timestamp
4. HTTP Method
5. Request URL
6. HTTP Version
7. HTTP Status Code 
8. Response Size 
9. Referrer 
10. User-Agent 
11. logFormat

생각보다 유용한 정보가 많기에 원하는 데이터를 파싱해서 대시보드를 만들거나 솔루션에 도움이 되는 부분을 DB에 저장해서 분석자료로 활용하기에 좋다고 생각하였다.

가장먼저 파케이 파일 변환을 진행하게되는데,

보이는 것과 같이 용량이 어마어마하게 차이가난다. 대용량 로그 파일 관리를 위해 파케이 파일저장은 필수 인 것 같다.

Pandas를 활용해서 data frame을 만들고 파케이파일변환을 했으면 재료준비는 끝.

이제는 양념준비를 해야한다. 양념은 공격 탐지코드다.

각각 공격탐지 패턴은 교육내용과 GPT의 도움을 받아 작성하였다.

이제 플레이팅을 구상해야한다.

기본적인 차트 구성은 4개로 진행하고 왼쪽에는 서버를 목록화하여 고를 수 있게 구상하였다.

다음과 같은 과정을 겪어 DATA를 저장하거나 즉시 시각화(대시보드)를 구성하게되었다. 최신 로그를 가져오기위해 방화벽 예외신청과 같은 자잘한 난관을 겪고 결과적으로 아래와 같은 대시보드를 만들었다.

결과적으로 6개의 차트, 서버목록을 구성했지만 중요정보가 있기에 일부 가렸습니다.

결과물을 보니 파이썬의 다양한 라이브러리의 활용도는 무궁무진 한 것 같다. 기본적으로 Streamlit을 활용해서 빠르게 웹사이트를 구상하고 차트별 디테일을 챙겼다.

보안도 꾸준하게 관심을 갖고 다양한 것을 해봐야겠다. 오늘의 요리 끝.

API에서 Swagger가 적용이 되었다면, 위와 같이 바뀐 명세 확인을 위해 매번 swagger-ui를 들어가서 확인하는 번거로움이 있었다.

해당 의존성을 털어내고자 code generator를 적용하게 되었다.( Loosely coupling 정말 좋아합니다 )

적용기

1. 일단 설치

npm install @openapitools/openapi-generator-cli -g

※node 18버전 이상 가능 (nvm 이용해서 로컬에서 node 버전 여러개 보유 가능합니다.)

※Swagger Specification 사용시

npm install swagger-codegen -g

과 같은 다른 라이브러리 설치하여야합니다.

2. package.json 스크립트 설정

  "generate": "openapi-generator-cli generate -g typescript-axios -i https://test-api.com/api-docs -o ./src/api/apidocs -t src/api/apidocs/mustaches -c ./openapi.json --skip-validate-spec",

3. openapi.json 파일 생성

{
  "spaces": 2,
  "modelPackage": "src/model",
  "apiPackage": "src/api",
  "supportsES6": true,
  "withNodeImports": false,
  "useSingleRequestParameter": true,
  "enumNameSuffix": "",
  "withSeparateModelsAndApi": true
}

4. npm run generate

npm run generate

그러면 제가 설정한 src/api/apidocs 아래 생성된 파일들을 확인 할 수 있습니다. 아래는 생성된 예제 파일입니다.

5. 예제 파일 확인

/* tslint:disable */
/* eslint-disable */
/**
 * TEST- API
 * TEST API 문서입니다.
 *
 * The version of the OpenAPI document: 1.0
 * 
 *
 * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
 * https://openapi-generator.tech
 * Do not edit the class manually.
 */


// May contain unused imports in some cases
// @ts-ignore
import type { testResponse } from './test-response';

/**
 * 
 * @export
 * @interface testResponse
 */
export interface TestResponse {
    /**
     * 방패크기
     * @type {string}
     * @memberof TestResponse
     */
    'shieldSize'?: string;
    /**
     * 방패종류
     * @type {string}
     * @memberof TestResponse
     */
    'shieldType'?: string;
    /**
     * 방패생산일
     * @type {LocalDateTime}
     * @memberof TestResponse
     */
    'date'?: LocalDateTime;
    /**
     * 방패색깔
     * @type {string}
     * @memberof TestResponse
     */
    'color'?: string;...

결과

1. TypeScript를 쓰는 환경이라면 바로 Import해서 사용하면 되고 명세가 바뀔때마다 일일히 swagger-ui에 들어가 확인할 필요가없어집니다.

2. 해당 변수가 없거나 타입이 맞지 않다면 IDE에서 에러를 표시하기에 고생이 줄었습니다.

하지만 솔루션3의 접속정보는 변하지 않기에 솔루션 1,2 모두 같은 TABLE을 조회하고 수정하고 갱신한다.

아래는 솔루션과 테이블 조회 로직을 간단하게 나타낸 것이다.

2. 문제 확인

따라서 RSA테이블을 각각 두기 위해 기존 DB와 RSA테이블을 카피한 RDS를 추가 하였으며 암호화키를 조회,저장,갱신 하는 솔루션3의 소스코드를 하나의 소스로 가져가기 위하여

[sol1_properties] , [sol2_properties]

와 같이 properties를 통해 DB 접속 정보를 분리하기로 하였다.

3. 계획 수립 및 실행

문제해결 계획은 다음과 같다.

 [1]
 1-1 기존 RDS를 카피뜬 새로운 RDS 생성 및 RSA 테이블 생성
 1-2 기존 RDS의 RSA테이블 데이터를 새로운 RDS의 RSA테이블로 데이터 마이그레이션.

 [2]
 2-1 sol1_properties는 기존 RDS 접속정보기입
 2-2 sol2_properties는 새로운 RDS 접속정보 기입 

 [3]
 3-1 소스관리의 용이성을 위해 원소스로 가져가는 솔루션3 (RSA키를 갱신,조회,저장 하는 솔루션)
 3-2 솔루션3를 서버1과 서버2에 clone
 3-3 서버1에서 솔루션3 구동시 솔루션1용 sol1_properties로 구동 
 3-4 서버2에서 솔루션3 구동시 솔루션2용 sol2_properties로 구동 

하기와 같은 작업을 운영서버에서 진행하기에 확실한 계획과 사전작업이 수반되었으며 모든 계획에 문제없이 진행되어 다음과 같이 <DB 분리작업> 은 솔루션 정지 이후 10분내로 완료되었다.

완성된 환경

(썸네일은 아주 대략적으로 그려본 아키텍쳐 구성도이다. 추후 충분히 바뀔 수 있다)

현재 진행은

EC2 생성 및 기본 설정 - S3 버킷 생성 및 EC2 연결 - nginx설치
-jdk,docker,mongoDB 설치 - mongoDB 연결확인

까지 되었으며 아래는 구성과정이다. 딱히 막힌 부분이 없어서 간략하게 글과 그림을 넣도록 하겠다.

1. AWS EC2 생성 및 설정

1. AWS EC2 생성 (Amazone Linux 2023)
2. 탄력적 IP부여
3. SSH 연결 테스트
4. 보안그룹 설정
5. JDK 21설치
6. 임시 도메인 부여 : http://npy-project.duckdns.org

보안 그룹 설정

SSH 연결 테스트 JDK 21 설치 완료

2.AWS S3 생성 및 설정

1.버킷 생성 2.버킷 정책 설정 3.IAM 정책 추가 4.IAM 권한 추가 5.EC2- Bucket 연결

버킷정책

S3 policy

3.Nginx 설치 및 도커 설치

4.mongodb 설치 및 연결확인

1.대용량 zip파일 업로드 ( 최대 300개의 PDF파일로 이루어진 ZIP파일 ,최대 3개)
2.Unzip & PDF Split ( java.util.zip 사용하여 Unzip후 멀티 스레드를 활용하여 2개의 PDF 파일로 스플릿)
3.Split한 파일 저장 

따라서 Unzip & split 로직과 최대 1800개의 PDF 파일을 저장하는 로직이 한번에 이루어진다.

그러기에 파일업로드시 몆분 가량 로딩바를 바라만 보고있고 정상적으로 진행이 되는지 사용자 입장에서 알수 없을 것이다.

이에 대하여 업로드 로딩바 구현을 하기로 하였다.

SSE 구현

Server-Sent-Event (SSE) 전체 흐름은

1. SSE Connect API 호출
2. Connect Complete 응답
3. 이벤트 API 호출
4. 이벤트 data 응답

심플하다. Connect API와 FileUpload API를 분리하여 아래 예제를 보자면

가장먼저 SSE 연결, 해제 , 에러처리 관련하여 Service를 구현하고

SseServiceImpl

@Service
@RequiredArgsConstructor
public class SseServiceImpl implements SseService {

  private final EmitterRepository emitterRepository;
  private final CodeDetailRepository codeDetailRepository;
  private final CodeDetailLanRepository codeDetailLanRepository;

  private static final Long DEFAULT_TIMEOUT = 5L * 1000 * 60;
  private static final Logger LOGGER = LoggerFactory.getLogger(SseServiceImpl.class);

  @Override
  public SseEmitter sseConnection(String eventId, String lastEventId) {
    SseEmitter sseEmitter = emitterRepository.save(eventId, new SseEmitter(DEFAULT_TIMEOUT));

    // SseEmitter의 완료, 시간 초과, 에러로 인한 전송 불가 시 sseEmitter 삭제
    handleException(sseEmitter, eventId);

    // 연결 직후, 데이터 전송이 없을 시 503 에러 발생. 에러 방지 위한 더미데이터 전송
    sendToClient(eventId, "Successfully Connected ::: " + eventId);

    // 클라이언트가 미수신한 Event 유실 예방, 연결이 끊켰거나 미수신된 데이터를 다 찾아서 보내준다.
    if (StringUtil.isNotEmpty(lastEventId)) {
      Map<String, SseEmitter> events = emitterRepository.findAllStartById(eventId);
      events.entrySet().stream()
          .filter(entry -> lastEventId.compareTo(entry.getKey()) < 0)
          .forEach(entry -> sendToClient(entry.getKey(), entry.getValue()));
    }
    return sseEmitter;
  }

  @Override
  public SseEmitter sseConnection(String eventId,
      String lastEventId, long timeOutInMilliSeconds) {
    SseEmitter sseEmitter = emitterRepository.save(eventId, new SseEmitter(timeOutInMilliSeconds));

    // SseEmitter의 완료, 시간 초과, 에러로 인한 전송 불가 시 sseEmitter 삭제
    handleException(sseEmitter, eventId);

    // 연결 직후, 데이터 전송이 없을 시 503 에러 발생. 에러 방지 위한 더미데이터 전송
    sendToClient(eventId, "Successfully Connected ::: " + eventId);

    return sseEmitter;
  }

  ...//이밖에 에러처리, failResult 등 로직을 구현 

본격적으로 SSE Connect MVC패턴을 구축한다.

Connect controller

@CrossOrigin(origins = "*", allowedHeaders = "*")
@RestController
@RequestMapping("/sse")
@RequiredArgsConstructor
public class SseController {

  private final SseService sseService;
  private final CurrentUserData currentUserData;

  @GetMapping(value = "/connect", produces = "text/event-stream")
  @Operation(summary = "SSE Emitter를 발급받기위한 API")
  public SseEmitter sseConnection(@RequestHeader(value = "Last-Event-Id", required = false, defaultValue = "") String lastEventId, SseConnectionRequestParam requestParam, HttpServletResponse response){
    return sseService.sseConnection(currentUserData.getUnqUserId(), lastEventId);
  }
}

Connect Service

  @Override
  public SseEmitter sseConnection(String eventId, String lastEventId) {
    SseEmitter sseEmitter = emitterRepository.save(eventId, new SseEmitter(DEFAULT_TIMEOUT));

    // SseEmitter의 완료, 시간 초과, 에러로 인한 전송 불가 시 sseEmitter 삭제
    handleException(sseEmitter, eventId);

    // 연결 직후, 데이터 전송이 없을 시 503 에러 발생. 에러 방지 위한 더미데이터 전송
    sendToClient(eventId, "Successfully Connected ::: " + eventId);

    // 클라이언트가 미수신한 Event 유실 예방, 연결이 끊켰거나 미수신된 데이터를 다 찾아서 보내준다.
    if (StringUtil.isNotEmpty(lastEventId)) {
      Map<String, SseEmitter> events = emitterRepository.findAllStartById(eventId);
      events.entrySet().stream()
          .filter(entry -> lastEventId.compareTo(entry.getKey()) < 0)
          .forEach(entry -> sendToClient(entry.getKey(), entry.getValue()));
    }
    return sseEmitter;
  }

와 같이 구현하여 Connect api호출시 Connect Complete 메세지와 Emitter를 응답받는다. 위에서 사용된 sendToClient는 기본 sseEmitter.send를 커스텀한 메소드이며

sendToClient

   @Override
  public void sendToClient(String eventId, Object data) {
    SseEmitter sseEmitter = emitterRepository.findByEventId(eventId);
    try {
      sseEmitter.send(SseEmitter.event()
          .id(eventId)
          .name("Connection")
          .data(data, MediaType.APPLICATION_JSON));
    } catch (IOException e) {
      sseEmitter.completeWithError(e);
      emitterRepository.deleteAllByKey(eventId);
      LOGGER.error(StringUtil.extractStackTrace(e));
    }
  }

와 같이 메소드를 구성한다.

이후 FileUpload API 호출 후 service에서 사용하는 로직에서 응답이 필요한 부분에 이 sendToClient를 호출하면 된다 .

Uploadfile Service

   public List<FileMst> uploadFilesAndSplit(UploadFileInfo uploadFileInfo, 
   String lastEventId, String eventId)
      throws ExecutionException, InterruptedException {
      ```//파일 unzip 로직
      sseService.sendToClient(eventId, fileName + " 파일 Unzip 완료!");
      ``` //파일 split 및 저장 로직 
      sseService.sendToClient(eventId, fileName + "파일 저장 및 Split 완료!");
      }

로드밸런싱 환경에서의 난관

하지만 로컬, 개발 환경에서는 하나의 서버만 존재하기에 문제가 되지않지만, 현재 운영서버에 올라간 솔루션은 AWS의 ALB로 2개의 web server로 로드밸런싱된 환경이며 2개의 API (Connect API, FileUpload API) 가 같은 web server로 갈 것이라는 보장은 없다. 즉,

간단한게 위와 같이 connect 는 web 1에 되었지만 FileUpload API는 web 2에 도달 할 수 있다는 것이다. 그 결과 web 1은 아무 응답도 주지않고 time-out이 되버린다.

해결

이에 대하여 /conect와 /file-write 를 동시에 즉, Connect API와 FileUpload API를 하나로 합치는 방법을 선택하였다.

ThreadPool을 사용는 java라이브러리인 ExecutorService 을 사용하여 Connect 먼저 응답 후 FileUpload 로직을 수행하도록 적용하였다.

기존 로직

1. 
[Conect API 호출]->[Connect controller]->[Connect Service]->[SendToClient(연결 완료)]

2. 
[FileUpload API 호출]->[FileUpload controller]->[FileUpload Service]->
[uploadFilesAndSplit]->[SendToClient(업로드 진행현황)]

변경 로직

[FileUpload API 호출]->[FileUpload controller]->[uploadFiles]->
[SendToClient(연결 완료)]->[FileUpload Service]->
[uploadFilesAndSplit]->[SendToClient(업로드 진행현황)]

uploadFiles 메소드

  @Override
  public SseEmitter uploadFiles(FileUploadRequestParam requestParam) {
    SseEmitter sseEmitter = new SseEmitter(DEFAULT_TIMEOUT);
    ExecutorService executorService = Executors.newSingleThreadExecutor();
    executorService.execute(() -> {
      uploadFilesAndSplit(requestParam, sseEmitter);
    });
    return sseEmitter;
  }

1개 사이즈의 ThreadPool 생성후 task를 할당하면 mainThread와 별개로 병렬처리 하게된다. 따라서 한번의 API호출로 두 로직이 수행되도록 하였다.

VPC : Virtual Private Cloud

• 퍼블릭 클라우드 환경에서 사용할 수 있는 고객 전용 사설 네트워크

NAT : Network Address Translation

• IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술 ( private IP <-> public IP)

• AWS에선 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

  

NAS :Network Attached Storage

• 스토리지를 빠른 속도의 네트워크로 연결하는 방식. LAN(Local Area Network)을 연결하여 사용하기 때문에 비용이 저렴 , 파일 서버

ELB : Elastic Load Balancer

• L4 스위치

ALB : Application Load Balancer

• L7 스위치

CLOUD FRONT

• HTML, CSS, JS 등 정적파일을 빠르게 로드 시키기 위해 사용

AMAZON S3 :Simple Storage Service

• 파일 서버 역할

RDS : Relational DB

• AWS에 올라간 관계형 DB

On-premise : 기업이 자체적으로 IT 인프라를 소유, 관리 및 운영하는 경우

아파치: 웹 서버용 소프트웨어 , HTTP 서버 , 정적인 데이터 처리

톰캣 : 아파치 재단의 WAS , 동적인 데이터 처리 , 톰캣은 was서버이지만 web서버의 기능도 갖추고 있다. dynamic(동적)인 웹을 만들기 위한 웹 컨테이너, 서블릿 컨테이너라고 불리며, 웹서버에서 정적으로 처리해야할 데이터를 제외한 JSP, ASP, PHP 등은 웹 컨테이너(톰캣)에게 전달한다.

was = web server+ web container apache = web 역할 서버 tomcat = was 역할 서버 apache tomcat = web+was 서버

Q) 그러면 tomcat만써도 되는거아닌가? A) 하지만 역할 분리 , 성능 등을 고려하여 was와 webServer를 분리한다.

즉 ,

1. http 요청이 들어오면
2. 아파치로 전달하고 정적인 데이터는 아파치에서 처리
3. 동적인 데이터는 아파치에서 ajp프로토콜을 사용하여 미리 지정한 소켓을 통해 특정 포트로 tomcat의 서블릿 컨테이너 (spring의 경우 dispatcherServelet) 로 전달
4. 이후 handler를 통해 이동한 뒤 mvc패턴에 의해 가져온 데이터를 응답.

아파치 톰캣 연동 및 통신과정

- 클라이언트 <-80-> 아파치 <-8009-> 톰캣 <-8080-> 클라이언트 (port 임의 설정)

- 아파치와 톰캣 연동은 [mod_jk], [mod_proxy], [mod_proxy_ajp] 3가지 방법 존재 

- mod_jk : 
아파치와 톰캣을 연동하기 위한 아파치의 모듈로써AJP 프로토콜(web<->was protocol)을 이용하여 
아파치에 들어온 요청 중 톰캣이 처리할 요청을 AJP 포트(일반적으로 8009)를 통해톰캣에 전달하고 
그에 대한 응답을 받는 역할을 수행

+서버에 아파치와 톰캣을 올리는 간략한 과정

1. OS에 아파치와 톰캣 설치
2. mod_jk.so 설치 및 컴파일
3. workers.properties , httpd.conf 설정

당연한 얘기를 하는 것 같지만 오늘 다룰 builder 패턴과 관련이 있다.

builder 패턴이란?

디자인 패턴 중 생성 패턴에 해당 하며 생성 패턴에 속하는 패턴들은 객체를 생성, 합성하는 방법이나 객체의 표현 방법을 시스템과 분리해준다.

시스템과 분리에 포커스를 맞춰서 예시를 들자면 평소에 흔히 사용하는 생성자 패턴과 구현한 클래스가 아래와 같이 있다

@getter
@setter  
public class Shield {

  private int length;
  private String color;

  public Shield(int length, String color) {
    this.length = length;
    this.color = color;
  }

}

public class ShieldImpl {

  private int length =5;
  private String color = "red";

    Shield shield1 = new Shield(length, color);
    Shield shield2 = new shield() 
    shield2.setColor(color)
    shield2.setLength(length)
}

현재 2개의 param을 전달하지만 length,color,height,weight.. 등 param이 늘어날수록 가독성이 떨어지고 어떤 파라미터가 전달되는지 확인하기 쉽지 않다.

또한 setter를 사용하게된다면 코드상 의도파악과 객체의 일관성 유지에 좋지않다.

그렇기에 위 단점들을 보완하기위해 @builder 어노테이션을 사용하여 다음과 같이 빌더 패턴을 구현 할 수 있다.

@getter
@setter  
public class Shield {

  private int length;
  private String color;
  ...

 @builder
  public Shield(int length, String color, ...) {
    this.length = length;
    this.color = color;
    ...
  }

}

public class ShieldImpl {

  private int length =5;
  private String color = "red";
  ...

    Shield shield = shield.builder()
    .color(color)
    .length(length)
    ...
    .build()
}

이와같이 빌더 패턴을 구현하면 param주입이 명확하게 나타나고 있기에 코드 가독성이 증가하게된다.

SSL (443, Secure Socket Layer)

• 응용 계층 아래 위치 해서 http, ftp 등 통신 프로토콜과 조합해서 사용

SSH (22, Secure Shell)

• 원격 호스트 연결 인터넷 프로토콜 , RSA 사용
• private key, public key 둘다 보유한 서버가 클라이언트에 public key를 주고 암복화 후 세션키 비교 로직)

SSL-VPN

• 장소나 단말의 종류와 관계없이 내부 네트워크에 접속할 수 있는 SSL 기반의 가상 사설망(VPN).
• 개인 PC에서 SSL VPN 장비에서 ID 마다 할당해놓은 가상 IP를 부여받고 서버들에 대한 라우팅도 자동생성

IPS( Intrusion Prevention System)

• 기존에 정의되지 않은 침입이 발생하기 전에 실시간으로 침입을 막고 외부 침입으로부터 네트워크와 호스트를 보호하는 예방에 초점이 맞춰진 시스템
• 주로 시스템 콜(system call)을 검출하는 방법 등 사용 (시스템의 부하, 즉 로그가 많이 쌓일때 시스템콜)
• HTTP 대응 패턴 미비

IDS (Intrusion Detection System)

• 네트워크 트래픽에서 의심스러운 활동이 있는지 모니터링하고, 그러한 활동이 발견되면 경보를 발령하는 시스템
• 주로 시스템 로그나 감사로그를 통하여 침입을 탐지 (실시간 로그감지)

WAF (Web Application Firewall)

• 레이어 3 및 4에서 작동
• HTTP 프로토콜 베이스로 하는 공격만 탐지 및 차단 (DOS,DDoS 등)
• 외부 사용자와 웹 응용 프로그램 사이에 위치하여 모든 HTTP 통신을 분석
• 웹 애플리케이션에 도달하기 전에 악성 요청을 감지하고 차단
• 보호 대상 리소스가 HTTP (S) 웹 요청에 응답하는 방식을 제어하는 데 사용
• 웹 액세스 제어 목록 (ACL) 을 정의한 다음 요청 들어올때마다 WAF에게 전달 ( 미리 요청 차단, 요청 수 세기 등 필요한 로직 적용 )

ACL (Access Control List)

• 시스템 리소스와 관련된 권한 목록이다.
• 목적지 주소, 포트번호, 프로토콜로 특정 패킷을 필터링 하는 트래픽 필터링 기능을 가짐. (접근 제한 ,라우팅 경로 조정 기능 수행)

1.SubQuery 사용

repository에서 서브쿼리 , @subselect을 이용하여 queryDsl에서 만든 뷰를 entity처럼 사용하기

예시

@Data
@Entity
@Immutable
@Subselect(
   "SELECT SHIELDNM FROM SHIELDTABLE
 WHERE SHIELDCOLOR ='RED'"
)
@Synchronize({"ShieldTable"})
public class ShieldTableView implements Serializable {

  @Id
  @Column(name = "SHIELD_NM")
  @Schema(description = "방패 이름", nullable = false)
  private String shieldNm; 
  ...
}

하지만 @subselect 어노테이션을 사용한 쿼리가 자체가 성능이 매우 안좋은 쿼리이고 다시 또 querydsl에서 사용하게된다면 더욱 좋지않다. 트래픽이 많은 서비스에서는 지양하는게 좋다.

2.JPQL 사용

repository에서 @query 어노테이션을 사용하여 native 쿼리를 이용. 동적으로 받아야할 값들은 @Param으로 받기

예시

public interface ShieldTableRepository 
extends JpaRepository<ShieldTable>,
    QuerydslPredicateExecutor<ShieldTable> {
 @Query(value = "SELECT SHIELDNM FROM SHIELDTABLE
 WHERE SHIELDCOLOR = :shieldColor  nativeQuery = true)
  List<Shield> findByShildNm(
  @Param("shieldColor") String shieldColor);
  ...

위 2가지 방법중 성능과 특정 기간동안의 통계 데이터를 가져오는 것(동적으로 날짜값을 사용해야하므로) 을 고려하여 2번을 선택하였다.

3. 문제 발생

[WARN]org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logExceptions (SqlExceptionHelper.java:137) - SQL Error: 1861, SQLState: 22008 (ORA-01861: 리터럴이 형식 문자열과 일치하지 않음 )

로컬환경에서는 문제가 없이 쿼리를 수행하고데이터를 잘 가져왔다. 하지만 개발배포 이후 개발환경에서 문제가 발생! 이에 대하여 검색한 결과 OS의 Lang설정이 달라 문자 열을 묵시적으로 날짜로 변환을 못해서 발생하는 오류 였다. OS 환경변수인 NLS_LANG 설정에 영향을 받으므로 모든 애플리케이션 서버의 LANG을 세팅해주는 방법도 있었지만 번거로우므로 쿼리에서 모두 날짜형식을 지정해주는 방법을 택하였다.

예시

SELECT SHIELDNM 
FROM SHIELDTABLE B
LEFTJOIN (SELECT TO_CHAR(MAKEDT,'YYYY/MM/DD') AS MAKEDT
FROM SHILEDTABLE) A
ON A.MAKEDT= B.REPAIRDT 

에서

ON A.MAKEDT= B.REPAIRDT // X
ON A.TO_CHAR(MAKEDT,'YYYY/MM/DD')= B.REPAIRDT // 날짜 형식 지정

으로 바꿔주니 정상적으로 쿼리가 수행되었다.

롬복(Project Lombok)은 자동으로 편집기에 연결하고 도구를 구축하여 Java를 더욱 멋지게 만드는 Java 라이브러리입니다. 다시는 다른 getter 또는 equals 메소드를 작성하지 마세요. 하나의 주석으로 클래스에 모든 기능을 갖춘 빌더, 로깅 변수 자동화 등이 포함됩니다. 출처: https://projectlombok.org/

즉, 자주쓰는 getter, setter 등의 반복 메서드 작성 코드를 줄여주는 코드 다이어트 라이브러리 이다.

예시

public class Shield {

  private int length;

  private String color;

  public void setLength(int length) {
    this.length = length;
  }

  public void setColor(String color) {
    this.color = color;
  }

  public int getLength() {
    return length;
  }

  public String getColor() {
    return color;
  }

  public Shield(int length, String color) {
    this.length = length;
    this.color = color;
  }

}

이와 같은 클래스가 있다면

@Getter
@Setter
@RequiredArgsConstructor
public class Shield {

  private int length;

  private String color;
}

와 같이 @Getter,@Setter 어노테이션을 활용하여 코드 길이를 간소화 시킬 수 있으며

@data
public class Shield {

  private int length;

  private String color;
}

와 같이 @data 어노테이션을 이용하여 한번에 표시 할 수 있다. @data어노테이션은

@Getter @Setter @ToString @EqualsAndHashCode @RequiredArgsConstructor

을 자동 적용해준다.

이밖에 @NonNull, @Builder ,@AllArgsConstructor, @NoArgsConstructor 등이 있다.

기본적으로 스프링은 제어의 역전 특징이 있다. 제어의 역전 (IoC)는 객체에 대한 권한을 프레임워크가 가지고 있으며 객체 생명주기를 프레임워크가 제어한다. 그래서 제어의 역전이라함. 따라서 스프링이 직접 관리 하기 위해 객체를 등록해줘야하는데 이것이 bean이다. 실제로 @bean 어노테이션을 사용해서 등록한다. @controller, @service, @repository 등 이러한 어노테이션들은 component로 간주하여 빈으로 등록된다. 이와 관련하여 빈을 생성하고 의존관계를 설정하는 기능을 담당하는 IoC 컨테이너이자 클래스인 beanfactory가 존재하며 추후에 이와 관련하여 scope, singleton과 prototype 등에 관하여 다룰 예정이다.

2.DI (Dependency Injection)

의존성 주입이라 하는 DI (Dependency Injection)는 객체의 의존관계를 외부에서 넣어주는 것을 뜻한다. 다시 1번을 보자. 스프링은 IOC특징이 있으며 빈을 등록해서 객체를 관리한다. 그 빈들을 스프링 컨테이너 에 담아 bean들을 관리하는데, 여기서 스프링 컨테이너에서 각 빈들에 대한 관계를 정리해줘야 하지않겠는가. 예를 들어 학용품이라는 객체와 연필이라는 객체를 빈으로 등록했으면 필요에 의해 둘을 사용할때 둘의 관계를 알아야 프레임워크가 관리할텐데 그때 필요한 것이 DI이다.** 프레임워크가 객체를 관리(IOC)하고, 실행시 객체 간의 관계를 결정(DI)함 으로써 **객체들간의 결합도를 낮추는 장점이 있다.

3.@Autowired

DI에 대한 개념을 이해했으니 어떻게 의존성을 주입하는가? 대표적으로 @Autowired 어노테이션을 사용하는 것이다. 특정 클래스에서 필요한 객체를 다룰 때 @Autowirded 를 사용하면 스프링 컨테이너에서 빈으로 등록한 객체의 의존성 주입을 알아서 넣어준다.

@Service
public class ShieldRepairServiceImpl implements ShieldRepairService {

 @Autowired
 private HammerRepository hammerRepository;//@Repository를 사용하여 빈으로 등록한 레포지토리

4.@RequiredArgsConstructor

@Autowired에 대해 알아봤으니 @RequiredArgsConstructor에 대해 추가적으로 알아보자. 간단하게 의존성 주입 종류(생성자,setter,field)중에 생성자 주입을 자동으로 해준다. 즉 생성자를 만들고 @Autowired를 사용하여 의존성을 주입후, 필드가 새로 생길 떄 마다 생성자를 수정하는 번거로움이 없어지고 자동으로 관리해준다.

''' 읽기 쉬운 글쓰기'를 지향 할 것이며 사실에 기반하여 글을 작성하겠습니다.