개인적으로는 스칼라나 하스켈 못지 않게 어려운 (그리고 생각과는 많이 다른) 언어가 자바스크립트인 것 같다. 그 난해함에 추가되는 문제는 생태계가 가장 빠르게 변화하는 언어라 단순히 언어 스펙을 공부하는 것만으로는 충분하지 못하다는 것이다. 이 책은 이러한 문제를 조금은 해결 할 수 있는 책이 아닌가 생각이 된다.

프로그래밍을 전혀 모르는 사람에게는 의미 없는 책이지만, ES3 부터 자바스크립트를 사용한 개발자나, 다시 한번 ES6 수준에서 알고 있는 지식을 정리하려는 사람들에게 추천할 만한 내용을 가지고 있다.

예를 들면 "30"* 3 = 90 이 나온다던가 let a = [1,2,3,] 처럼 마지막 콤마를 허용한다는 것 같은 것... 
arrow function 에서 this나 arguments가 펑션과 좀 다른다는 것은 제대로 정리가 안된다면 매번 헷갈려 하는 이슈 들이다. (물론 "30"*3 처럼 난해한 표현식을 추천하는 것은 아니다)


책을 쭈욱 읽어가면서  이 책의 장점을 정리해 보았다.

1. 30페이지 정도 나뉜 챕터들은 주제가 명확히 분리되어 있고, 그 안에서는 원리/이론 - 기초 - 심화로 이어진다. 처음부터 읽어가지 않아도 필요한 부분만 참고할 수 있다.

2. 중간중간 NOTE 도 도움이 되고, 챕터별 마지막 요약은 한 번 리마인드 할 수 있는 기회를 줬다.

3. 책의 내용뿐 아니라 번역 역시 책의 퀄리티를 결정하는 중요한 요소인데 (개인적으로는 ) 만족스러웠고, 단어 옆에 원래 영어단어가 충분히 표현되어 있어서 헷갈림이 없었다.   


본문 중 일부분


하지만  책의 본래 목적이기도 하지만 타겟 독자층이 애매하지 않나 생각이 들었고,  책 내용적으로는 ES6 부분은 별도 표시를 해 줬더라면 좋지 않았을 까 해본다.  

6개월전 Vue.js를 운영툴에 적용한 이후, Java와 Kotlin, Scala로만 프로젝트를 진행하고 있었는데, 이 책을 한번 읽음으로서 다시 한번 자바스크립트를 복습 할 수 있는 좋은 기회가 되었다. 

신고

SPRINGBOOT로 AWS LAMBDA 이용하기

spring framework 2017.07.07 09:52 posted by dev.bistro


결론적으로 @SpringBootApplication 과 Main method으로 시작되는 startup은 불가능하지만, 그 부분을 생성자 부분으로 변경한 다면 사용 가능하다. 다만, 첫  시작은 dependency lookup 방식으로 bean을 가져와야 한다.
(이건 올해 초 얘기고, 지금은 https://github.com/spring-cloud/spring-cloud-function 을 이용하면 된다)

테스트환경

  • intellij 2016.3
  • gradle
  • spring-boot 1.4.3

intellij Spring Initializr 의 셋팅

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2017-01-14-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-6-38-44

이후 build.gradle은 다음과 같이 셋팅하였다. boot를 이용한 gradle의  task package 나  assemble는 main이 없기때문에 사용이 힘들고 maven shade 플러그인이나 gradle shadow를 이용한다.

참고 build.gradle
( plugin : https://github.com/johnrengelman/shadow 는 몇년전에 PR 1줄 했네…)

이후 https://github.com/bistros/test-springboot-lambda 으로 프로젝트를 구동 시켜봤지만 단순히 String을 리턴하는데도 2초씩 걸린다.  (handleRequest에서 스프링 프로젝트를 초기화 하니 당연히 느릴수밖에… source link )

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2017-01-14-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-7-14-56

그래서 다음처럼 생성자에서 초기화하도록 수정 (source link) 하였다.

%e1%84%89%e1%85%b3%e1%84%8f%e1%85%b3%e1%84%85%e1%85%b5%e1%86%ab%e1%84%89%e1%85%a3%e1%86%ba-2017-01-14-%e1%84%8b%e1%85%a9%e1%84%92%e1%85%ae-7-15-55


신고

zookeeper

분류없음 2017.06.30 09:30 posted by dev.bistro


* 주키퍼의 Origin
 – Yahoo 에서 개발
 – Pig 처럼 많인 프로젝트가 동물 이름이었고, 이러한 시스템들은 동물원의 동물과 같다고 느낌 -> 사육사(Zookeeper)

* 주키퍼가 사용된 예
 – HBase : 클러스터 마스터 선출과 가용 서버들의 목록을 저장 / 클러스터 메타데이터 관리
 – Kafka : 장애 감지/ 토픽 발견/ 토픽 생성 소모 상태를 관리
 – Solr : 솔라클라우드에서 클러스터의 메타데이터 저장, 업데이트 관리
 – Facebook message : 샤딩/ 장애복구/ 서비스발견을 관리
– Druid :  내부 통신에 이용

* 주키퍼 모드
 – Standalone : 단독 서버, 복제 안됨
 – quorum(쿼럼)

* Znode
 – 용량제한 1MB
 – ACL(접근권한관리)를 할 수 있다
 – 주키퍼는 모든 데이터를 메모리에서 관리하기 때문에 Znode역시 메모리에 올라간다
 – child 또는 바이트 배열의 데이터를 저장한다

* Znode Mode
 – Persistent Node : 명시적인 삭제 명령(delete)이 있기 전까지 계속 유지되는 Node
 – Ephemeral Node : Node를 생성한 ‘세션’ 이 유효한 동안에만 유지되는 Node. Ephemeral 는 child znode를 가질수 없다.
 – Sequence Node : (위의 2개의 노드는 각각 이 타입을 사용 할 수 있다)
                   생성지 Sequence가 자동으로 붙는 Node (ex task-00000001) 유일한 이름을 보장 / 생성 순서 확인 가능

* Watch
 – 1회성 작업이다. 계속 노티를 받으려면 클라이언트에서 매번 새로운 watch를 설정해야한다.
   : so, 알림을 받고 새로운 watch를 등록하려는 순간에 새로운 변경사항이 발생 할 수 있다.
         이 다음 새로 watch를 등록하면서 값을 읽기 때문에 놓치지는 않는다.
 – 클라이언트가 감시하는 znode의 변경 사항의 ‘순서’를 보장해준다
 – 데이터 변경/ Child변경 등에 따라 다른 종류의 알림을 생성한다.

* 쿼럼의구성
 – 1. server.1=127.0.0.1:2222:2223
   server.n각 항목은 서버 n이 사용하는 주소, 포트를 지정한다.3개의 필드
   첫번째 필드는 서버 주소, 2,3번째 필드는 쿼럼 통신, 리더 선출에 사용하는 TCP포트이다.
 – 서버가 시작할때 주키퍼는 data 디렉토리의 myid 파일에 있는 내용을 읽어서 자신의 ID를 인식한다



[기본적인 설정]

* clientPort
– default 2181, 클라이언트가 서버로 연결하기 위해 사용하는 TCP port
– clientPort보다 clientPortAddress 가 우선한다.
* dataDir
– 만약 앙상블이라면 여기에 id 파일이 존재하게 된다 (name:myid)
QuorumPeerConfig 에서 File myIdFile = new File(dataDir, “myid”) 확인할 수 있다.
– 스냅샷(데이터 트리의 복사본)이 완료될때 까지 디스크와 동기화 되지 않는다.

* dataLogDir
– default dataDir 값을 사용
– 트랜잭션 로그를 쓰기 때문에 많이 사용된다.

* tickTime
– default 3000, tick은 주키퍼가 사용하는 ‘시간의 기본 단위’
– 가장 짧은 클라이언트 세션 타임아웃 = 2 tick
* snapCount
– default 100000, 스냅샷들 사이에 트랜잭션 개수(zookeeper.snapCount)
– 주키퍼 재시작 -> 스냅샷을 읽는다 -> 스냅샷 이후 트랜잭션을 적용한다

* fsync.warningthresholdms
– default 1000 저장소 동기화 시간이 이 보다 길면 경고 발생한다. (FileTxtLog 의 commit() 참고 )

* globalOutstandingLimit
– default 1000 수정할 일은 ‘거의’ 없을 것이다.
– 주키퍼 서버가 요청을 처리하는 것보다 클라이언트들은 request를 더 할수 있는데 globalOutstandingLimit 에 근접하면 요청을 안받음
– NettyServerCnxn.disableRecvNoWait 을 보면 ‘Throttling – disabling recv…’ 로그를 생성하는걸 볼 수 있다.(여기 맞나?)

* autopurge.snapRetainCount
– 데이터를 제거할 때 유지해야하는 스냅샷의 갯수와 트랜잭션 로그 갯수
– 주키퍼는 주기적으로 GC가 일어난다. 이 때 유지해야하는 스냅샷의 갯수를 말한다. 기본은 3

* autopurge.purgeInterval
– GC(퍼징)이 발생하는 시간의 간격. 0이 아닌 숫자로 설정하면 GC의 주기를 뜻한다.
– 0 이면 GC는 자동적으로 수행되는 않고, zkCleanup.sh을 통해 수동으로 실행 가능

[클러스터 설정]
ㅁ 앙상블에 속하는 모든 주키퍼 서버들은 동일한 변수.값을 가지고 있어야 한다.

* initLimit
– default 환경에 따라 다 달라서 기본값이 없다
– 팔로워가 리더와 초기에 연결하는 시간에 대한 타임아웃, 틱 갯수
– 팔로워가 훨씬 뒤쳐진 경우 처음 연결할때 많은 양의 데이터 전송이 발생할 수 있다. (이땐 좀 늘여야한다)
– ex) 데이터 양의 크거나, 네트워크 속도가 느릴 경우
* syncLimit
– default 기본값 없고, 바드시 설정해야하는 값이다.
– 팔로워가 리더와 동기화 하는데에 대한 타임아웃 틱갯수로 설정
– 이 틱 시간 안에 팔로워가 리더와 동기화가 되지 않는다면 제거된다.
– 데이터의 양은 상관없다. 네트워크 속도 & 처리량에 따라 설정해야한다.
* leaderServers
– default yes
– 리더가 클라에게 서비스를 할것인가?
* server.x=[hostname]:n:n[:observer]
– x : 서버의 ID (data/myId 파일 내용에서 이 x를 읽고 server.x를 찾아 적용한다)
– n : 첫번째 : 트랜잭션 송신, 두번째 : 리더선출 (일반적으로 2888:3888)
– observer : 있으면 해당 서버는 옵저버를 나타낸다.
* electionAlg
– 리더 선출 알고리즘. 이지만 3.4.0 이후로 1개만 남는다
– QuorumPeer.createElectionAlgorithm()를 확인 ( code : new FastLeaderElection(this, qcm) )
– 참고doc : https://zookeeper.apache.org/doc/r3.4.8/zookeeperAdmin.html
[로깅]
ㅁ SLF4J 와 Log4j를 사용한다. log4j.properties를 classpath에 포함시키면 된다.

[동적 설정 변경 or 무중단 설정 변경]
ㅁ 이 기능은 trunk 에만 존재하며 3.5.0알파 이후에 추가되었다.
ㅁ 이전버전에서 가장 안전한 방법은 ‘한번에 하나의 변경 사항만 만들고 매 변경 사항마다 앙상블을 올렸다가(리더 설정까지) 내리는 것’
ㅁ dynamicConfigFile 파라미터

[클라이언트의 연결 문자열 관리]
ㅁ host:port,host:port,host:port 의 사용법은 제한적이다. 추가/제거가 어렵다.
ㅁ DNS 리졸브.. (하지만 쓸일 없을듯)
[트랜잭션, 스냅샷 로그, 에퍽 파일 보기]
ㅁ 트랜잭션로그 보기 : java -cp zookeeper-3.4.8.jar:lib/log4j-1.2.16.jar:lib/slf4j-log4j12-1.6.1.jar:lib/slf4j-api-1.6.1.jar org.apache.zookeeper.server.LogFormatter z1/data/version-2/log.300000001
—-
ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
16. 8. 8 오후 6시 13분 12초 session 0x356696bfcf20000 cxid 0x0 zxid 0x300000001 closeSession null
16. 8. 8 오후 6시 13분 12초 session 0x256696d24480000 cxid 0x0 zxid 0x300000002 createSession 15000
—-

ㅁ 스냅샷로그 보기 : java -cp zookeeper-3.4.8.jar:lib/log4j-1.2.16.jar:lib/slf4j-log4j12-1.6.1.jar:lib/slf4j-api-1.6.1.jar org.apache.zookeeper.server.SnapshotFormatter z1/data/version-2/snapshot.300000000
—-
/assign/worker1.example.com/task-00000000
cZxid = 0x00000100000017
ctime = Mon Aug 08 17:19:04 KST 2016
mZxid = 0x00000100000017
mtime = Mon Aug 08 17:19:04 KST 2016
pZxid = 0x00000100000017
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x00000000000000
dataLength = 0
—-
스냅샷로그에는 데이터와 ACL은 출력되지 않는다. 그래서 어떤 시점의 무슨일이 일어났는지를 보려면 2개 다 확인해야 한다.

ㅁ epoch file : acceptedEpoch, currentEpoch 파일은 주키퍼가 보고, 참여하는 에퍽 번호를 반영. 데이터의 일관성을 위해 반드시 필요한 파일( 즉 백업할때 데이터와 함께 해야한다)

[시스템의 캡처]
앙살블의 트랜잭션 로그, 스냅샷 파일을 랩탑의 주키퍼에 복사하면 동일한 서버 상태를 재현 할 수 있다.
이 것은 파일의 복사만으로 쉽게 백업할 수 있다는걸 뜻한다. 앙상블중 1대만 복사하면된다(주키퍼는 복제 서비스이다)

[포 레터 단어 for letter word]
ㅁ 원래 의미 4글자로 구성된 비속어를 뜻한다.
ㅁ 주요 목적은 telnet/nc 같은 간단한 툴로 시스템의 상태를 쉽게 체크할 수 있는 방법을 제공하는 것이다. 그래서 output은 사람이 읽을수 있는 형태이다.
ㅁ ruok, stat, srvr, dump 등등
ㅁ 하지만 주키퍼는 기본적으로 Dcom.sun.management.jmxremote 옵션이 있으므로 jconsole등으로 jmx를 보는게 더 유용하다.

스크린샷 2016-08-13 오후 12.19.32


ps. 1년전 정리한글 옮겨옴

신고
TAG zookeeper


티스토리 툴바