티스토리 뷰
11 / 26 (일)
이 날의 세션은 크게 Java9 new feature, Java with HTTP/2, JSON-B/JSON-P 이다. (그리고 각각의 특징들이 Spring 5에 적용되었다는 그런 인상)
Java9, Spring 5의 특징적인 부분은 최근 Public Cloud가 대세이어선지, MicroSerivce Architecture에 대한 수요를 고려한 변화들이 많았던 점이다. (Spring은 2018에 Spring Cloud Function, API Gateway 등을 지원한다고 한다 ㅡㅡ?)
Java 9 Project jigsaw의 Modularity가 특히 그렇다. 패키지 위에 모듈을 둠으로써 기존 패키지 기준으로 되어 있던 자바 기반의 오픈소스들에 제약이 있을 수 있음에도 불구하고, 최근 Cloud 환경으로 생태계가 변화함에 따라 IoT 등 작은 머신에서 적은 리소스를 가지고도 자바가 구동 가능하도록 release 된 듯하다. 이에 따라 모듈간에 Dependency가 생길 것이고(JavaBase - JavaLogging) 계층구조도 달라져(모듈 층위가 생김에 따라 Depth가 깊어짐) 생소했다. 물론 마이그레이션 관련 이슈에 대한 고민의 흔적도 보였다(Multi-Release Jar Files). 버전별로 로딩해서 구동해야할 클래스를 적재적소에 배치할 수 있게 되었다. 그러나 이에 복잡도가 증가하는..
Java 9에서 추가적으로 특징적이었던 부분은 jshell과 GC, 그리고 unified logging(JVM/GC)이다. (사실 세션 중에 Jlink가 추가되어 Java.base@9 등 버저닝을 보여주는 부분, Disable Reactive, SHA-1 certificates, Deprecate the Applet API 등에 대한 이슈들도 자세히 다루셨으나, 그다지 고민하지 않았던 부분이라 그런지..)
jshell .. java shell이란 의미로 파이썬과 같이 Read-Eval-Print Loop 의 형태를 가진다. 이 부분도 최근 Cloud 쪽 Serverless Architecture를 고려한 aws lambda, api gateway 등에서 interactive한 환경이 필요해져 나온 것으로 보인다. java 8 lambda를 보면서도 느꼈는데, 갈수록 각 언어들이 닮아가는 것 같다.
그리고 GC. Java 7과 8 버전 성능상 차이가 많았던 것이 JVM 관련 기능 개선이라면, 이번에는 G1이 GC default가 되었다는 것. G1은 Low-pause collector로, JVM의 맹점을 다소 해결할 수 있다는 부분에서 성능상 큰 이점이 있을 것으로 기대된다.
추가적으로, JVM과 GC의 logging이 단일화되었다는 점이 인상깊었다. 지금껏 파일로 떨궈 logging collector로 수집하고 분석하던 방식에서 이제는 VM단에서 로깅할 수 있게 되었다는 것.
Spring 5에서 기억나는 부분은 spring-jcl로 로깅이 대체되어 log4j든 slf4j든 알아서 매핑된다는 것, Spring MVC에서 HTTP/2를 지원한다는 것, Multipart 에서 MaxUploadSizeExceedException이 생겼다는 것, Controller에서 ResponseStatusException으로 처리할 수 있게 된 것, (RestTemplate을 대신하여) Reactive Web Client, 그리고 .. RouterFunction . 서버에서 받는 Request를 Functional하게 사용 가능해졌다. 파이썬을 잘 모르지만 파이썬인듯 ㅡㅡㅋ
HTTP/2
Binary Web 세대 ?? 이제 RESTful 학습하기 시작했는데, 선도기술을 다루는 분들은 역시 다르다 ㅠㅠ 바이너리 실행코드(web assemble) + 바이너리 프토토콜(HTTP/2) 의 구조로 어플리케이션 실행 플랫폼으로서의 최적화된 웹을 지향하는 것 같다. 이에 브라우저 위에서 바이너리 RPC 프로토콜을 실행할 여지도 커지며, 게임 / 지도 등 고 성능이 필요한 클라이언트 환경에서 고려해볼만하다고 하셨다.
세미나는 직접 HTTP/2를 적용하면서 현 시점에서의 한계등을 보이는 형태로 진행되었다. (관련 링크)그런데 왜 HTTP/2로 변경해야 하는가? 당연한 이야기겠지만, 성능 면에서 우위를 점한다고 한다. (예제 링크) Server push를 하면 돔파싱을 할 필요 없이 큐잉하면서 문서를 이해하고 나서 파일을 받게 되어 더 효율적인 파일별 캐쉬가 가능해진다고 한다. 한번 커넥션 되고 나면, Server push를 통해 자원을 한번에 내림으로써 리소스 사용도 개선된다. (예제로 H2가 적용된 것은 네이버, 아닌 것은 github을 가지고 비교하였다.)
demo를 진행하면서 느꼈던 점은 실제로 적용하기 위해서는 고려할 부분들이 많다는 것이다. 일단 apache 2.4.27 이후의 prefork모드에서는 HTTP/2 module이 사용이 불가하다. 그리고 안정화되더라도 연결당 자원 소모가 큰 구조로 HTTP/2에 어울리지 않으며, event MPM 역시 nginx보다 성능에서 뒤쳐진다. HTTP/2는 persistent connection 이기 때문에 nginx가 유리하다고 한다. 그런데 nginx는 server push가 불가하다. 따라서 브라우저와 HA proxy 사이 구간을 HTTP/2로 구성할 것이 권유된다. (내부는 아직은 그냥 HTTP 1.1 쓰는 것으로..)
Introduce JSON-B, JSON-P, JPA 2.2 Specification (관련링크)
초반에 json을 format을 짜고 patch 하는 부분들이 꽤 흥미로웠다. 그런데 성능이 아직 jackson에 밀린다. 당분간 jackson을 쓰라고 하신다 ㅡㅡ;
끝나고 트램과 찜닭을 먹었으나, 기분이 나아지질 않았다. 소고기를 먹으려다 실패해서인가..
11 / 24 (금) ~ 25 (토)
"축복받은 자는 망각하는 자이다. 큰 실수에도 얻는게 있기 때문이다." 출렁이는 파토스에 또다시 침몰할듯한 공포가 엄습했다. 이 곳을 벗어나야한다는 본능에 이끌려 전화기를 들었다.
맛있는 것을 먹었다. 기분이 좋아졌다. (효과가 굉장했다 !)
크리스마스 트리를 만들었다. 기분이 좋아졌다. (처음엔 공허한 가지들에, 역시 트리는 나무여야 한다고 되뇌었으나 장식을 다하고 나니 꽤 그럴듯한 그림이 나왔다. 역시 불빨이..)
맛있는 것을 먹었다. 기분이 또다시 좋아졌다. (효과가 굉장했다 !)
성당엘 갔다. 이번 주는 전례력으로 한 해의 마지막으로 그리스도왕 대축일, 추수감사 미사 등을 드린다. (그 다음주터 성탄절까지 대림시기를 보낸다.) 내 생일은 11월 말일로, 매년 생일이 다가오면 자연스레 한 해동안 감사했던 일들을 회고한다. 올 한해도 좋은 인연들에 따스했던 한 해여서 감사하다.
11 / 23 (목)
사건의 발단은 honux의 node js수업이었다. 얼마전 node js 정리했던 기억이 나서, 잠깐 머리 좀 식힐겸 청강하였다. 어쩌면 honux로부터 'node js는 웹 브라우저 외의 다른 환경에서도 javascript를 실행할수 있게 해주는 runtime(실행환경)' 이란 말을 듣고 싶었는지도 모른다. 수업은 node js 개념 설명, 3tier 구조 설명, node js 실습 등으로 진행되었는데, 막바지에 다다라 ejs 설정을 하기에 앞서 ngrok를 활용하였다. 로컬에 올린 서버를 올린 후 해당 포트를 인자로 넣어 ngrok를 실행하면(ngrok.exe http 3000) SSL 터널링을 하는 것을 확인할 수 있다. 그리고 ngrok.io 에 임의의 URI를 할당하여 redirect 하는 구조인듯 하다.
오랫만에 SSL VPN 관련 내용을 보다가 자연스럽게 IPsec, pptp 등을 확인하고 있었는데.. 이상한 점을 발견했던 것.
2계층이라고ㅡㅡ? 2계층에서 어떻게 VPN을 구성한다는 거지?? 이 질문에 대한 답을 찾느라 하루가 날라갔다. 나도 모르는 새에 2계층을 Ethernet Protocol로 한정하여 생각했던 부분이 문제였고, 덕분에 PPP에 대해 찾아보았다. 이전에 frame-relay 실습할 때도 dlci에 대해서 그다지 생각않았었던 것 같은데.. 흠.. 어쨌든 덕분에 옛날 모뎀 시절 네트워크를 구성할 때 지점간 연결을 위해서 어떤 고민들이 있었는지도 생각해보는 계기가 되었다. (네트워크계의 인터페이스)
(그리고 사고가 mpls에 이르자, 이전에 GCP 행사 후 네트워크 구성 방식을 보던 중 packet processor 란 녀석이 label을 붙인다는 것이 이해가 안되었는데, mpls에서 말하는 label과 같은 개념인건가 하는 생각을 하게되었다. 아무튼 2계층에서 처리를 하니 네트워크 비용이 훨씬 절감되는듯..)
애플리케이션은 코드로 대화하듯, 네트워크는 프로토콜 슈트로 대화한다(?)
이번에 자료 조사하면서 네트워크는 정말 어렵고 네트워크 엔지니어들이 참 대단하다는 생각이 들었다. 그리고 이번에 TLS에 대해서도 좀 정리를 했는데, 이번 주말에 VPN과 TLS 그리고 전에 하다만 Node JS(websocket 및 socket IO) 등을 정리하면서 시간을 보내야겠다.
11 / 21 (화) ~ 22 (수)
javascript를 잘 모르니 REST로 구현하려던 Backend 쪽 설계까지 흔들렸다. 이번 Trello Project는 Spring Data Rest를 활용하여 개발 중이다. 사실 Trello의 다양한 기능을 구현하기보다는 기본 뼈대(Board, Deck, Card 작성 정도.. Card는 기본 Text 만 입력하는 정도로..)만 작성하고 개발 환경 구성(CI/CD, Docker, DB Migration 등), 보안과 성능(Spring Security 및 Oauth, TLS 설정, 트랜잭션, 성능 모니터링, 부하분산 등)에 초점을 맞추고 있다. 그런데 그 기본 뼈대를 만드는데에서부터 해메고있다 ㅡㅡ. 하지만 여러 삽질과 주변의 도움덕분에 HATEOAS에 대해 좀 더 생각해볼 수 있는 시간들이 되었다. 가장 해결하기 힘들었던 부분은 OneToMany(1:다) 관계를 REST로 구성하는 것이었다. Deck과 Card를 기준으로 보자면, 처음에는 javascript에서 Deck의 식별자를 알아내 이를 Card 생성시에 deck_id 값으로 넣으려 했다. (그런데 지금 생각해보니 이 논리가 맞기는 하다. 단지 REST하지 않았을 뿐) javascript상에서 nth child로 넣자니 Deck 삭제 과정에서 DB와의 sync가 맞지 않을것 같고, POST http://localhost:8080/api/decks/1/cards 로 JSON 형태로 값을 넣어도 204 (no content) 가 뜰 뿐 값이 입력되질 않았다. (그리고 이때까지만해도 204 도 에러라고 생각했다.)이런 방식으로 해결되지 않자, JPA 설정이 잘못되었나 싶어 단방향, 양방향으로 세팅해보기도 하고 여러 옵션들을 추가해보았지만 결과는 여전했다. 그래서 repository에 추가 옵션을 두어야 하는가도 싶었지만, 관련 내용을 찾아볼 수 없었다.해결하고보니, backend 쪽 코드에도 ajax 쪽에도 문제는 없었다 ㅡㅡ.특정 Deck에 Card를 넣고 싶으면, 1) Deck 생성, 2) Card 생성, 3) Deck에 Card 넣기 의 단계로 작업을 진행하여야 하는 것이다. (관련 예제)
아, uri-list라니 ㅡㅡ. 이런 방법밖에 없는 것일까.. 분명 더 효율적인 방법이 있을거라 생각되지만. 일단은 이정도로 해결하고 Spring Security 작업을 진행하였다. 이제 Brian과 함께할 시간이 얼마 남지않은 관계로 수요일 저녁에는 간단하게 술 한잔을 했다. 고기집에서 Oauth에 몰입한 Brian이 너무 보기 좋았고, 덕분에 나도 어깨너머로 동작방식을 경험할 수 있었다. 이 날은 정말 오랫만에 많이 웃었던 것 같고, 좋은 인연들을 만났음에 또 한번 감사함을 느꼈다.
11 / 20 (월)
Docker에 대한 이해가 부족했다. Docker는 컨테이너 내부를 Host OS와 격리하기 위해 Linux의 namespace 기술을 이용한다. namespace에는 pid namespace(프로세스 격리), net namespace(NIC 관리), ipc namespace (InterProcess Communication 즉, 내부 프로세스 통신 자원에 대한 접근 관리), mnt namespace (mount 관리), uts namespace (커널 격리와 버전 식별) 등으로 구성되어 있다. 그리고 Docker의 각 컨테이너에게 자원을 할당하기 위해서는 cgroups를 이용한다. 단순한 파일시스템 수준의 분리라고 생각했는데, Docker는 namespace기술을 사용하여 brdige와 각 컨테이너의 Virtual NIC를 생성한다. (IP는 기본적으로 172.17.0.0/16 대역에서 할당받는다.)재미있는 점은 link 명령으로 연결시에 해당 컨테이너의 /etc/hosts에 이를 등록해준다는 점이다. 그리고 이를 통해 통신한다.
따라서 내가 실수했던 점은 trello (WAS) 빌드하는 부분에서 application.properties 설정을 잘못했던 점이다.
만약 # docker run --name trello -d -p 8080:8080 --link mysql:mysql com/jwp-trello-be 이런 형태로 link를 걸었다면,
1 | spring.datasource.url=jdbc:mysql://mysql:3306/trello | cs |
이부분에 IP가 아니라 지금처럼 mysql:3306의 형태로 url이 들어가야 했던 것.
2. gradle 빌드도구
이제 연결도 되었겠다, gradle로 빌드시에 docker 이미지를 바로 생성하는 셋팅을 시작했다. 그런데 gradle 도구에 대한 이해 부족으로 오전을 날렸고, 또다시 pobi의 도움을 얻어 해결했다 ㅠㅠ
문제는 바로 이 녀석 -> https://spring.io/guides/gs/spring-boot-docker/
스프링 문서가 업데이터 되지 않았던 것. gradle-docker plugin repository가 바뀌었고, 이에 classpath 추가시에 "synchronize gradle projects with workspace failed due to an error connecting to the gradle build" 에러가 발생했던 것. 해당 문제 해결 후에 # ./gradlew clean build docker 명령으로 gradle 빌드시 docker 이미지를 생성할 수 있다.
여기서 mavenCentral()은 http://repo1.maven.org/ 를 의미하며, 추가하려는 classpath가 해당 사이트에 없으면 저런 에러가 나오는 듯 싶다.
3. Docker로 3 Tier 구성
nginx -> trello(was) -> mysql 의 3tier 구성을 하여, 80 port로 접근시에 nginx가 reverse proxy하는 것을 docker로 구현하는 것에 성공했다. HTTP에 대해 약간이나마 공부를 해서인가, 위의 로그를 보니 동일 요청을 할 경우 status code가 304(수정되지 않음) 으로 리턴하여 네트워크 비용을 줄이는 것이 보인다 ㅡㅡ.
물론 docker 실습이 끝난 것은 아니다. mysql 버전이 올라가서일까, docker 이미지 생성시에 설정관련하여 나는 에러를 잡지 못했고, docker compose도 에러가 발생한다. 일단은 작은 성공에 만족하며, 추가적인 내용은 trello 개발 후에 진행할까 한다.
trello 개발과 관련하여 보안 쪽 이론부분을 훑어보았고 brian, tram과 trello 구조에 대해 논의해보았다. pobi에게 컨펌받고 나서 개발 작업을 진행할듯 하다.
몸이 무거워 간만에 밤코를 하지않고 집에갔고, 오랫만에 잠이랄 것을 잤고, 정말 오랫만에 무언가로부터 도망치는 꿈을 꾸었다. 무엇이었을까.
'Log > .TIL' 카테고리의 다른 글
| [TIL]171204-1210 (0) | 2017.12.10 |
|---|---|
| [TIL]171127-1203 (0) | 2017.11.29 |
| [TIL]171113-1119 (0) | 2017.11.15 |
| [TIL]171106-1112 (0) | 2017.11.07 |
| [TIL]171030-1105 (0) | 2017.10.31 |