서비의 다락방

버전 마이그레이션
https://www.slideshare.net/antgiann/upgrading-to-mongodb-40-from-older-versions


성능 측정
https://medium.com/@hartator/mongodb-4-2-vs-4-0-3-6-3-4-and-3-2-benchmarks-ee96a09ef231

흘러간 시간은 무상하고
난 내일도 살아 나가겠지

스프링 부트 2.0이 출시되었습니다.

가장 큰 변화는 Java 8을 최소 조건으로 요구하며 Java 9 지원을 확대하는것과
Spring 5.0의 새로운 기능을 사용할 수 있고
reactive 방식의 개발을 지향한다는 점입니다.

Spring 1.5를 2.0으로 마이그레이션 하기위한 가이드 문서는 이쪽( https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide )입니다.

저는 개인적으로 reactive 방식의 개발을 지원하는것에 관심이 있습니다.
스트림 프로세싱, non-blocking, 함수형(불변상태) 코드 작성이 주목을 받으며, 자바 진영도 RxJAVA 등을 통해 언어, 프레임웍 수준에서 리엑티브 방식의 구현을 위한 노력이 있어왔고 java 9는 RxJAVA 스타일의 리액티브 개발 언어가 될것이라고 한 흐름에서의 변화이기 때문입니다.

이를 위해 Spring에서는 다음 영역에 리엑티브를 지원합니다.
Spring WebFlux ( https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html) 
Reactive Spring Data ( 카산드라, 몽고DB, 레디스, 카우치베이스 등의  NoSQL 류에 리엑티브 API 지원 )
Reactive Spring Security ( https://docs.spring.io/spring-security/site/docs/5.0.0.RELEASE/reference/htmlsingle/#jc-webflux )

상기와 같은 변화에 따라 WebFlux 와 같이 기존 Servlet 구현체로는 대응을 할 수 없는 부분은 Embedded Netty Server 를 리엑티브 서버로 사용하며 Blocking servlet API는 제공되지 않습니다.

이외에도 3rd-party 라이브러리 업데이트 ( tomcat 8.5 , flyway 5, hibernate 5.2, thymeleaf 3 ), http/2 지원, 어플리케이션 모니터링에 자체 metric 대신 micrometer ( micrometer.io ) 적용, 기본 database pool로 HikariCP 적용 등의 변화가 있습니다.

새로 집 장만해서 이사.
회사 회장님 육친 별세.
박근혜 구속 수감.

몽고DB의 취약점을 이용한 랜섬웨어가 있다고합니다. 근데.. 그걸 모방해서 Elasticsearch도 당하고 있다네요.
당하면 데이터를 삭제하고 비트코인 요구..


몽고DB측 기사는 이렇습니다.
https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data

zdnet의 elasticsearch 관련 기사는 다음과 같고요..
http://www.zdnet.com/article/first-came-mass-mongodb-ransacking-now-copycat-ransoms-hit-elasticsearch/

예방책은 몽고DB나 elasticsearch의 서비스 port를 public으로 열어놓지말고
사용자 접근제어 설정을 하고 방화벽, VPN, 프록시 서버 등을 이용해 접속하는것을 권고합니다.

“저는 하루에도 몇 번씩 변화합니다. 아침에 눈을 뜨면 한 사람이 있습니다. 그리고 잠을 청하러 갈 때면 거기엔 확실히 또 다른 한 사람이 있습니다.”

ISFP형 사람은 일반적으로 사람들이 생각하듯 야외 정원에서 앙증맞은 나무 그림을 그리고 있는 그런 유형의 예술가는 아니지만, 진정한 예술가 축에 속하는 이들입니다. 실상 상당수 많은 이들이 그러한 능력을 충분히 갖추고 있기도 합니다. 이들은 그들의 심미안이나 디자인 감각, 심지어는 그들의 선택이나 행위를 통하여 사회적 관습이라는 한계를 뛰어넘고자 합니다. 실험적인 아름다움이나 행위를 통해 전통적으로 기대되는 행동양식이나 관습에 도전장을 내미는 이들은 "저를 가둬두려 하지 마세요!"라고 수없이 외쳐댑니다.

자기 자신에 대한 만족

이들은 다양한 아이디어나 사람들로부터 영감을 받아 다채로우면서도 감각적인 삶을 살아갑니다. 그들이 받은 영감을 본인만의 시각으로 재해석하여 새로운 것을 발견하고 탐험함으로써 즐거움을 느끼기도 하는 이들은 그 어떤 유형의 사람보다 탐험이나 실험 정신이 뛰어납니다. 어디로 튈지 모르는 즉흥적인 성향으로 간혹 이들을 예측하는 것이 어려운데, 이는 가까운 친구나 사랑하는 사람들 역시 예외가 아닙니다.

그럼에도 불구하고 단연 내향적(I) 성향을 가지고 있는 이들은 스포트라이트를 벗어나 재충전을 위해 혼자만의 시간을 갖곤 하는데, 이는 간혹 주위 사람들을 놀라게 하기도 합니다. 하지만 이들이 혼자 있다고 게으르게 넋 놓고 앉아 있다는 말은 아닙니다. 이 시간은 그들이 가진 원리원칙을 재고하는 자기 성찰을 위한 시간으로, 과거나 미래에 집착하지 않고 순전히 그들이 누구인지 자신을 들여다보는 시간입니다. 그리고는 이들은 곧 언제 그랬냐는 듯이 사람들 앞에 변화된 모습으로 '짠'하고 나타납니다.

넘치는 열정을 쏟아부으며 정열적인 삶을 살아가는 ISFP형 사람은 다른 유형의 사람들에 비해 도박이나 익스트림 스포츠와 같이 위험성이 내재한 활동을 즐기는 경향이 있습니다. 그나마 다행인 것은 그들의 상황 조율 능력과 환경으로 말미암아 대부분의 사람보다 이에 소질이 있다는 것입니다. 다른 이들과 어울리는 것을 좋아하기도 하는 이들은 거부할 수 없는 그들만의 매력을 가지고 있습니다.

반대로 ISFP형 사람은 누군가로부터 비판을 받을 경우, 상황을 안 좋게 몰고 갈 수도 있습니다. 타인의 적절한 비판은 오히려 다른 관점으로 받아들여 새로운 방안을 모색하는 가치 있는 용도로 활용하기도 하는 반면, 신랄하거나 진중치 못한 비판은 자칫하면 그들의 화를 돋우어 그리 아름답지만은 않은 모습으로 분노를 표출하게 하기도 합니다.

ISFP형 사람은 타인의 감정을 잘 살피며 조화를 중요시 여깁니다. 그러한 이유로 이들이 만일 비판을 받는 경우, 분노에 사로잡혀 화가 누그러지기까지 꽤 오랜 시간이 걸립니다. 하지만 좋은 일이건 나쁜 일이건 영원히 계속되는 것은 없듯이, 일단 분노의 감정이 사그라지면 이들은 과거는 과거일 뿐이라고 치부하며 마치 아무 일도 없었다는 듯이 다시금 그들의 삶을 살아갑니다.

작은 것 하나하나 모두 인생의 의미

ISFP형 사람이 가장 어려워하는 것 중 하나가 미래를 설계하는 일입니다. 더 나은 미래를 위해 목표를 설정하고 이를 달성케 하는 건설적인 이상향을 찾는다는 게 그리 생각만큼 간단한 일이 아닙니다. 그럼에도 불구하고 관리자형 사람들과 달리 이들은 미래를 구체적인 자산이나 은퇴 계획이라는 틀 안에서 세우는 것이 아닌 다양한 경험을 통해 자아를 찾는 데 필요한 행동 계획을 세우는 데에 더 많은 투자를 하는 경향이 있습니다.

만약 이러한 목표나 믿음이 순수함에서 기인한 것이라면 이들은 누구보다도 사심 없는 마음으로 선행을 실천할 것입니다. 하지만 이는 반대로 말하면 누구보다도 자기중심적이며 속임수를 일삼으며 자기애에 사로잡혀 행동하는 이들로 비추어질 수도 있음을 의미합니다. ISFP형 사람은 그들이 하고자 하는 대로 그냥 내버려 두는 것이 가장 현명한 방법입니다. 물론 새로운 취미를 발견하고 실행하는 것이 생각처럼 쉬운 일은 아니지만, 하루하루 서두르지 않고 원하는 것이 무엇인지 곰곰이 생각하고 되새겨 본다면 그것이 무엇이 되었든 ISFP형 사람이 진정 좋아하는 것이 무엇인지 찾을 수 있을 것입니다.

ISFP형에 속하는 유명인

1. 정킷방을 운영하던 범서방파 구속

2. 검찰 조사중에 '네이처 리퍼블릭'의 정운호 대표의
100억대 도박 혐의 발견(삼성 선수들 도박도 발견)

3. 정운호가 변호사로 부장판사 출신 최유정 선임.

4, 이와중 정운호가 롯데그룹 면세점 선정 로비의혹이
드러남. 롯데에 검찰 조사가 들어가고 대규모 비자금
여부를 파헤침. (롯데그룹 이인원 부사장 자살)

5. 정운호와 최유정이 변호사 수임료 문제로 다툼
최유정 변호사법 위반으로 구속됨

6. 정운호의 이전 도박사실을 동업자 김모씨가 폭로
그 사건은 홍만표가 맡았던 걸 알게되고 홍만표 조사 시작
홍만표의 전관예우로 막대한 이득을 취한게 포착

7. 홍만표가 정운호에게 청와대 민정수석 우병우를 잡아놨으니 염려말라고 했던걸 발견. 우병우 게이트 시작

8. 넥슨에게 거액의 주식을 뇌물로 받은 진경준 게이트 조사중에 조선일보가 넥슨과 우병우의 부동산 비리 의혹을
제기함

9. 청와대가 빡쳐서 조선일보에게 '부패 기득권 세력'이라고 어그로 시전

10. 우병우를 놓고 청와대와 조선일보의 싸움이 계속되는데 빡친 조선일보가 K스포츠와 미르재단에 청와대가 압력을 넣어 기업들로부터 상납금을 내도록 했다는 기사를 냄.

11. 청와대는 이석수 특검으로 국면을 전환하는 한편
친박 김진태 의원이 조선일보의 송희영주필이 대우조선해양 사장에게 접대를 받았다고 폭로 박수환 게이트 터짐.
(청와대의 역공)

12. 송희영 주필이 사임하고 조선일보는 일단 꼬리를 내림으로써 일단락 되는 듯 했으나 한겨레가 조선일보가 꺼냈던
K스포츠와 미르재단의 중심에 최순실이 있다고 터뜨림으로써 최순실 게이트가 시작됨.

13. 한겨레와 조선일보의 이상한 좌우 콜라보레이션으로
최순실과 미르재단의 관계 최순실의 딸 정유라의 이대 부정입학 의혹이 제기됨. 또한 최순실 아버지 최태민과 박근혜,최순실과 박근혜의 관계들이 언론을 통해 대중에 퍼짐.
일설에는 박근혜 아바타설을 제기하며
'최순실이 박근혜 연설문까지 고쳐주는 사이다'라는 말을 했으나 다들 개소리로 치부함.

14. 박근혜가 최순실 어머니 생신 때 축가를 불렀다는 의혹 제기. 그리고 어제 JTBC가 최순실 컴퓨터에 박근혜의 연설문 파일이 수십개 발견됨으로써...

이 모든건 정운호가 도박질한 나비효과

제 업무와 관련있는 회사에서 10월19일 골프용품 할인행사를 한다고...
현재는 비공개 상태인 상품들의 가격을 어깨너머로 봤는데 골프 즐기는 사람에게는 가격 매리트가 꽤 있을것 같음.

http://golping.golfzon.com/event/Discount/blackDayEvent.do

함수형 언어 개발자는 일반적으로 다이어그램을 사용하지 않는다. (전부는 아니지만) 대부분의 함수형 언어 개발자는 OOP 언어 개발자가 UML을 통해 표현하는 객체사이의 관계를 types를 통해 기술하곤 한다.
이유는 함수형 프로그래밍에서 변경가능한 object 가 존재하지 않기때문에  "변경가능" 이란 상황이 극히 드물기때문에 객체사이의 관계를 다이어그램으로 표현하는게 필요하나거나 도움이된다거나 하지않기때문이다.
또한 한 function에서 다른 function을 호출할때 속성(property)은 설계된 디자인보다는 function이 호출하는 기능의 구현에 더 영향을 받는게 일반적이기때문이다.

함수형 언어에서의 UML표현이 꼭 필요한 상황이라면 types나 function의 개념을 설명할 수 있는 concept map 을 확인해 보기 바란다.

최근 프로젝트를 하나 진행하면서 데이터 파이프라인으로 아파치 카프카 0.10.0을 도입하였다.
기존 프로젝트에서 이미 0.8.1을 도입하여 진행한적이 있어 도입 자체는 부담이 없었고.. 0.9를 거치면서 producer, consumer API가 많이 정비되었고 0.10.0에 와서는 stream process 지원이 강화된 부분이 마음에 들어서이다.

개발 완료 후 QA를 진행하는데 특이한점이 나타났다. 카프카 토픽의 데이터가 일정주기로 다시 읽어지는 현상이 나타난 것이다. 토픽으로 새로운 데이터의 유입이 없는것과 다시 읽어지는 데이터가 과거 데이터인것을 확인하는 순간.. '머지 이건?!!'

0.8.1을 사용하는 이전 프로젝트에서는 consumer로 subscription을 하면 점검, 장애의 이유가 아니라면 브로커와 연결을 지속한 형태로 구현했는데, 이번에는 컨슈머가 짧은주기로 subscription, unsubscription을 반복하는 구성이 다른점이다.

현상만으로 보면 어떤 이유에서 컨슈머그룹의 offset 정보가 초기화 되는것 같았고 이를 토대로 코드와 카프카 설정을 몇 번을 리뷰했지만 특이사항을 찾지못하고 수일이 흘렀다. 한가지 특이사항이라면 offset이 리셋되는 주기가 일정한듯 한 현상이 보였다.

주말에 StackOverflow에서 카프카 관련주제를 검토하다가 드디어 해결의 단초를 찾았다.
결국 작성한 코드의 이슈는 아니고.. 0.9버전부터 변경된 오프셋 관리방식(0.8.x까지는 주키퍼가, 0.9부터는 카프카측에서 관리)과 새 버전 카프카 브로커  설정 기본값으로 인한 현상이었다.
키워드는 브로커 설정의 offsets.retention.minutes. 기본값이 1440분, 즉 24시간 유지라네...  0.10 문서 충분히 읽고 검토했다고 생각했는데... 이런 중요한 설정을 놓쳤을 줄은 상상도 못했다.

이와 관련한 이슈와 메일링 리스트
https://issues.apache.org/jira/browse/KAFKA-3806
https://mail-archives.apache.org/mod_mbox/kafka-dev/201606.mbox/%3CJIRA.12976894.1465398960000.46560.1465511841061@Atlassian.JIRA%3E

myBatis 로 개발 시 간혹 입출력 변수의 javaType 이나 jdbcType을 명시해 줘야 할 때가 있다.
이럴 때 참고하기위해 기록 해 둠.
참고로, myBatis의 jdbcType enum 정의는 http://www.mybatis.org/mybatis-3/apidocs/reference/org/apache/ibatis/type/JdbcType.html 에서 확인 가능.

https://msdn.microsoft.com/ko-kr/library/ms378878(v=sql.110).aspx

SQL Server 형식	JDBC 형식(java.sql.Types)	Java 언어 형식
bigint	BIGINT	long
binary	BINARY	byte[]
bit	BIT	boolean
char	CHAR	String
date	DATE	java.sql.Date
datetime	TIMESTAMP	java.sql.Timestamp
datetime2	TIMESTAMP	java.sql.Timestamp
datetimeoffset(2)	microsoft.sql.Types.DATETIMEOFFSET	microsoft.sql.DateTimeOffset
decimal	DECIMAL	java.math.BigDecimal
float	DOUBLE	double
image	LONGVARBINARY	byte[]
int	INTEGER	int
money	DECIMAL	java.math.BigDecimal
nchar	CHAR NCHAR(Java SE 6.0)	String
ntext	LONGVARCHAR LONGNVARCHAR(Java SE 6.0)	String
numeric	NUMERIC	java.math.BigDecimal
nvarchar	VARCHAR NVARCHAR(Java SE 6.0)	String
nvarchar(max)	VARCHAR NVARCHAR(Java SE 6.0)	String
real	REAL	float
smalldatetime	TIMESTAMP	java.sql.Timestamp
smallint	SMALLINT	short
smallmoney	DECIMAL	java.math.BigDecimal
text	LONGVARCHAR	String
time	TIME(1)	java.sql.Time(1)
timestamp	BINARY	byte[]
tinyint	TINYINT	short
udt	VARBINARY	byte[]
uniqueidentifier	CHAR	String
varbinary	VARBINARY	byte[]
varbinary(max)	VARBINARY	byte[]
varchar	VARCHAR	String
varchar(max)	VARCHAR	String
xml	LONGVARCHAR LONGNVARCHAR(Java SE 6.0)	String SQLXML

정기 점검으로 인해 운영중인 카프카/주키퍼를 재기동했더니  Unexpected exception, exiting abnornally java.io.EOFException 이 발생하면서 브로커가 정상적으로 동작을 하지 못하는 현상이 발생하였다.
원인은 Disk Full로 주키퍼의 트랜젝션 파일을 온전히 저장하지 못해서 발행하는 것이었다.

다음과 같은 조치를 통해 정상화 할 수 있다.

우선 카프카용 주키퍼의 데이터 경로 [KAFKA_HOME]/zookeeper-data/version2 에서
$ ls -lat 
명령으로 가장 최근에 만들어진 로그와 스냅샷 파일을 확인한 후
사이즈가 0이거나 마지막에 작성된 로그를 삭제하고 재기동하면 된다.

후속조치로는 [KAFKA_HOME]/logs 아래에 빼곡히 들어차 있는 controller.log , server.log, state-change.log 들을 주기적으로 삭제하는 스크립트를 만들고 크론으로 등록했다.
http://heyo.net/xe/prog_tip/1984
[code]
#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 
cd [KAFKA_HOME_PATH]/logs
find ./* \( -name 'controller.log.*' -o -name 'server.log.*' -o -name 'state-change.log.*' \) -mtime +30 -exec rm -f {} \;
find ./* \( -name 'controller.log.*' -o -name 'server.log.*' -o -name 'state-change.log.*' \) ! -name '*.Z' -mtime +7 -exec compress {} \;
[/code]