라즈베리파이에 토이프로젝트로 끄적끄적 돌리고 있는 서비스들이 있습니다.

아직 외부에는 거의 오픈하지 않아(하나는 카카오 채널을 통해 접속 가능하도록..^^;;)

개인적으로 저만 사용하고 있었죠

(디비는 MongoDB를 사용중이였습니다.)

그런데 주말에 접속해보니 서비스중 하나의 페이지가 정상적으로 나오지 않았습니다.

"응..? 매일마다 정해져있는 정보를 보여주는 간단한 서비스라 딱히 장애날부분이 없을텐데.. 뭐지? 버근가..?" 라는 생각을 하며 월요일 확인해보니 

있어야할 디비 데이터가 없습니다..

(물론 백업이 있기에 간단히 복구 할수 있지만..)

"응? 왜 갑작이 데이터가 날아갔지?" 라는 생각을 하며 db 접속해보니 이상한 db가 하나 추가 된것을 확인했습니다.

허허허..털렸네요...

(물론 서비스중이 아니기에 비트코인을 보내고 복구할필요도 없지만 말입니다.. ㅎㅎ)

사실 제 시스템은 털기 아주 간단하긴 했습니다..

개인적으로 테스트로만 사용중이기 때문에 아주아주 취약한걸 알고도 보안을 전혀 신경쓰지 않았습니다.

(당연히 해야되는거지만.. 테스트용으로 구성한거라..^^;;;)

그래도 이렇게 들어와서 데이터를 날린다면 귀찮으니 조금의 보안을 위해 조치를 해보며

글을 남깁니다.

1. 먼저, 현재 라즈베리파이는, 공유기의 포트포워딩을 통해 접근할 수 있도록 열어 놓았고, 마찬가지로 DB 포트도 열려있습니다, IP 제한도 없고, 포트도 27017로 동일하게 열어 놓았었습니다.

-> DB 접근은 어플리케이션 IP만 및 제 개발 PC 만 열어놓아야 하는것이 맞겠지만, 이 부분은 여전히 편의성을 위해 설정하지 않을 예정입니다.

-> 포트를 27017을 그대로 사용하지 않고 임의의 포트로 수정하였습니다(무작위 아이피로 몽고 공식 포트로 찔려보는것이였을 꺼라 생각합니다.)

2. 계정은 생성해뒀지만, 최근 테스트를 위해 "authorization: disabled" 상태로 두었었습니다. 이러니 간단히 털수 있었겠죠

-> authorization: enabled 로 변경 하였습니다. 그리고 기존 계정은 삭제하고 새로 생성했습니다.

더더욱 많은 보안들을 적용할 수 있겠지만 아주 간단한 조치만으로도

왠만한 해킹들에 대해서는 막힐것이라 기대합니다

(또 털리면 다시 글을 남기게 되겠지요)

3. 서비스중 하나는 동적으로 데이터가 쌓이지 않아 백업이 다 되어 있지만, 하나의 서비스는 계속해서 크롤링하여 데이터를 쌓는데 백업이 되어있지 않았습니다.

(물론 실서비스가 아니기에 신경을 쓰지 않았지만요...)

-> 추후 데이터 백업 관련하여 적용해야겠습니다.

4. 이제 변경된 계정 정보 및 포트들을 적용해야하는데, spring config server를 사용하고 있기 때문에 간단히 git repo의 설정 정보를 변경하는것으로 간단히 적용되었습니다.

요약

1. 공식 포트를 그대로 사용하지 말자!(SSH 포트인 22라던지.. 디비포트 1521이나 27017이라던지)

2. 계정 보안을 켜두고 쓰자

3. 데이터는 늘 백업하자

로그레벨 동적 반영을 위하여

Controller를 하나 만들어서 처리할까 하다 이미 구현된 기능이 있을지 해서 검색해보니

이기 해당 기능이 actuator를 이용하여 처리가 가능하도록 되어있었습니다.

먼저 actuator를 사용하기 위해 pom.xml 에 추가합니다.(메이븐 기준으로)

<dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

설정 없이는 /actuator 로 확인할수 있는것들이 없지만 'management.endpoints.web.exposure.include' 에 항목들을 추가하여 추가적인 기능들을 사용할 수 있습니다.

logger 설정 및 확인을 위해 필요한 내용은 loggers입니다.

위와같이 설정 후 기동하게되면

'/actuator/loggers' 를 통해 모든 로거들의 로그레벨들을 확인할 수 있습니다.

'/actuator/loggers/로거명' 을 GET으로 요청하면 해당 로거만 나타나게 됩니다.

이제 목표인 로그레벨 동적 변경을 위해서는

'/actuator/loggers/로거명' 에 POST로 설정할 값을 보내주면 됩니다.

{"configuredLevel":null,"effectiveLevel":"INFO"} 를

{"configuredLevel":"ERROR","effectiveLevel":"ERROR"} 로 변경하고자 하면

헤더는 컨텐츠 타입을 application/json에 body에 {"configuredLevel":"ERROR","effectiveLevel":"ERROR"} 을 넣어 요청하도록 하면 됩니다.

Mono 혹은 Flux를 다룰때 map 혹은 subscribe 동작들을
subscribeOn()이나 publishOn()을 통해 다른 스레드에서 실행될 수 있도록 위임할수 있는데
인자는 Scheduler를 받습니다.


Spring WebFlux에서 Controller 스레드에서는 blocking 작업을 할수 없도록 되어있기에
필요한 경우에 subscribeOn() 를 사용하여 blocking 작업을 다른 스레드에서 사용할 수 있는데
Scheduler 종류마다 blocking 작업이 가능한 Scheduler가 있고 아닌 Scheduler 가 있습니다.
(non-blocking 스케줄은 블럭킹 작업이 불가능합니다.)

• parrallel
  • optimized for fast non-blocking executions
  • 속도 최적, non-blocking
• single
  • optimized for low-latency one-off executions
  • 스레드 하나를 공유함, non-blocking
• elastic
  • optimized for longer executions, alternative for blocking tasks where the number of active tasks can grow indefinitely
  • 긴작업에 최적, non-blocking 아님, blocking 작업 가능 스레드, 필요시 무한히 늘어남
• boundedElastic
  • optimized for longer executions, alternative for blocking tasks where the number of active tasks is capped
  • 긴작업에 최적, non-blocking 아님, blocking 작업 가능 스레드, 정해진 사이즈
• immediate
  • to run a task on the caller Thread
  • 콜러 스레드에서 실행
• fromExecutorService
  • 기존 java.util.concurrent.Executors 를 활용

이전에

List list = new ArrayList<>();

list.add(3);

int val = list.get(0);

에 대한 질문을 본적이 있습니다.

현재(지금까지 접했던)까지의 Java는 Generic에 primitive인 가 아닌 로 적어야 맞는것

그리고 list.add(3); 에서 auto-boxing 에 대해 언급했었습니다.

그리고 int val = list.get(0); 에서는 un-boxing이 일어나게 되죠

즉, 불필요한 객체가 생성되고 사라집니다.

검색을 하다보니 이부분을 "어쩔수 없다"가 아닌 해결해보려는 프로젝트가 있었습니다.

Valhalla 프로젝트

Valhalla 프로젝트에서는 크게 2가지 내용이 있었습니다.(https://openjdk.java.net/projects/valhalla/)

• Value Types
• Generic Spcialization(JEP 218)

그중 Generic Spcialization(JEP 218) 가 Generics over Primitive Types 에 다루고 있는 항목이였습니다.
https://openjdk.java.net/jeps/218

JEP(JDK Enhancement Proposal) 내용이기 때문에 언제 이루어질지 알수 없지만

하나씩 하나씩 추가되고 개선될때마다, 코틀린이나 스칼라가 아닌 자바

그 자체로 간편하고 더더욱 효율적인 언어가 될것을 기대한다.