구글 드라이브 용량이 부족하거든.. (용량 부족하면 이메일도 가지 않는다)

필요없는 첨부파일 메일, 

용량 큰 중복 파일이 있는지 확인하고 지우고..

아래  URL에 접속해서 애매하게 남아있는 데이터를 지워야 한다.

https://drive.google.com/drive/search?q=is:unorganized%20owner:me

commit 정리하기에 정말 좋은 git rebase 참조 링크,

* 개념

http://dogfeet.github.io/articles/2012/git-merge-rebase.html

* rebase 활용 사례

https://wckhg89.github.io/archivers/rebase

MacOS에서 sudo 커맨드를 실행하면 다음과 같은 에러가 발생했다.

$ sudo -s

sudo: /etc/sudoers is owned by uid 502, should be 0

sudo: no valid sudoers sources found, quitting

sudo: unable to initialize policy plugin

$ su - root

Password:

su: Sorry

root 계정을 활성화하고 패스워드를 변경한다.

https://support.apple.com/ko-kr/HT204012

$ su - root

$ chown 0 /etc/sudoers

$ sudo

usage: sudo -h | -K | -k | -V

usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]

usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]

usage: sudo [-AbEHknPS] [-C num] [-g group] [-h host] [-p prompt] [-u user] [VAR=value] [-i|-s]

            [<command>]

usage: sudo -e [-AknS] [-C num] [-g group] [-h host] [-p prompt] [-u user] file ...

잘 동작한다. 

이전 메이븐과 그래들로 도커 빌드/데몬 생성이 가능해졌다.

https://github.com/GoogleContainerTools/jib

mvn compile com.google.cloud.tools:jib-maven-plugin:0.9.10:build -Dimage=<MY IMAGE>

gradle jib --image=<MY IMAGE>

문서는 다음을 참조한다.

https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html

opentsdb 소스(https://github.com/OpenTSDB/opentsdb )를 살펴보니.. 큰 특징은 다음과 같다.

<내용>

1. grafana를 지원한다. (사실 이것 때문에 쓰는 것임)

2. hbase 쿼리 튜닝은 되어 있지 않다(start, end로 해서 읽어옴, 대용량 데이터에 엄청 취약)

3. gpgl 이다. (소스를 건들 수 없다)

    OpenTSDB is free software and is available under both LGPLv2.1+ and GPLv3+.

4. 성능을 위해 async hbase(Defered)를 사용했다. (그러나 성능 이슈는 앱의 쓰레드 부분이 아니라 쿼리 부분에서 발생한다)

5. 야후 개발자 한명이 혼자 다 개발한다. 따라서 확장성에서 취약하다. 아저씨 코드이다. 

6. 현재 3.0 개발중(google bigtable도 깔끔하게 지원될 것 같다)

7. 데이터가 많아지면 트래픽에 굉장히 취약하다. 대용량 환경에서는 druid가 답이다. 

7. 2.3까지 pre-aggregation, google big table/cassandra 지원은 완벽하지 않다. hbase 빼고는 답이 없다. (대용량에 취약하다.)

8. druid vs opentsdb 

https://community.hortonworks.com/questions/89810/druid-vs-opentsdb-for-tick-data.html

https://www.popit.kr/time-series-olap-druid-%EC%9E%85%EB%AC%B8/ (람다 아키텍처 지원)

https://groups.google.com/forum/#!topic/druid-development/bPJbWO-g4aw

https://java.libhunt.com/compare-opentsdb-vs-druid

<세부 내용>

1. 원래 opentsdb의 의도는 한 대의 host, network를 모니터링을 위해 만들어졌다. kafka* 이런식의 모아보기 용은 아니다.

2. 키 구성

row key : metric_uid + timestamp + tagk1 + tagk2 + <tagkN> + <tagvN>

timestamp 

tagk1=tagv1

tagk2=tagv2

3. 키 검색 순서

time range -> metric -> tags

따라서 동일한 그룹핑 단어가 많아지면 성능은 좋지 않다.(data. agg. 으로 시작하는 단어)

4. opentsdb 2.0부터 4개의 테이블이 생성된다.

data

uid

tree

metadata 테이블 : name <--> id 매핑

5. tagk 길이 제한

rowkey에 저장해야 하기에 5개 태그 미만으로 저장해야 한다.

6. opentsdb가 api에 예민(host 정보 없으면 에러 출력), 성능이 약해서 opentsdb 앞단에 opentsdb compatible api g/w를 사용해야 잘 감싸는 서버가 필요하다. 따라서 custom, 모아보기 기능도 쉽게 진행할 수 있다. 

<opentsb를 활용한 프로젝트>

https://github.com/turn/splicer : 여러 opentsdb 클러스터와 redis를 두어 모니터링(더이상 운영 안됨)

https://github.com/facebookarchive/beringei : facebook에서는 인메모리 TSDB용으로 개발(더이상 운영 안됨)

<참고>

Opentsdb 좋은 공부 자료

http://tsunanet.net/~tsuna/hbasecon-2014-opentsdb-2.0.pdf

http://opentsdb.net/misc/opentsdb-oscon.pdf

http://Marp의 opentsdb 튜닝가이드 https://mapr.com/blog/hbase-key-design-opentsdb/

http://opentsdb.net/docs/build/html/user_guide/backends/bigtable.html

다음은 opentsdb를 분석하며 대충 그려놓은 그림이다. 자료가 없어서 이를 참조하면 좋을 것 같다. 

윈도우 10에 리눅스 ps 커맨드와 같은 Get-Process -Name 커맨드,

리눅스 kill 커맨드와 같은 taskkill 커맨드가 있다.

보니까.ci 소요 시간이 10분이내가 적절하다고 보는 분들이 많았다..

https://semaphoreci.com/blog/2017/03/02/what-is-proper-continuous-integration.html

https://semaphoreci.com/blog/2017/03/16/measure-and-improve-your-ci-speed.html

https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

https://www.google.co.kr/search?q=ten+minutes+continuous+integration&oq=ten+minutes+continuous+integration

어떻게든 ci 속도를 10분으로.. 고민해야된다..

내가 예전에 진행했던 3000개 테스팅에 대한 CI 속도는 10분이내였다.

구글의 public dns가 8.8.8.8만 있는 줄 알았는데.. 8.8.4.4도 있었다.  역시 위키를 봐야..... 

https://en.wikipedia.org/wiki/Google_Public_DNS

Google Public DNS operates recursive name servers for public use at the IP addresses 8.8.8.8 and 8.8.4.4 for IPv4 service, and 2001:4860:4860::8888 and 2001:4860:4860::8844, for IPv6access.^[5][6]

http://knight76.tistory.com/entry/Apache-NIFI

최근까지 NIFI를 상용에서 쓰고 있었지만.. 아주 간단한 곳에서 사용하고 있다. 

테스트했던 환경은 중량급 서버 (32 core, 64 Memory) 에 4대를 사용해서 테스트했다.

내가 내린 결론은 대용량(하루 최소 5T 용량) 또는 복잡한 환경에서는 쓰지 않기를 바란다.

현재 NIFI의 한계는 threashold가 넘어가는 클러스터링 장애가 발생하고 나서 복구가 무척 어렵다. (재시작 3번 해야 복구된다.) 따라서 로그가 유실되며 재처리할 수 있는 작업 컴포넌트가 현재 없다.

또한 로그가 현재 부실한 편이라 정확한 어떻게 하기 어렵다. 장애 발생 후 재시작 이후에 여전히 설정이 traffic을 받는 구조라 썩 좋지 않다.

그러나, 이런한 단점에도 NIFI는 계속 좋아질 가능성이 보이고 있으며,

소스 구조가 java bean에 맞춰 착실하게 개발되어 있어 컴포넌트 추가 개발이 쉽다는 큰 장점이 있다..

좋은 성능 튜닝 참조 자료

https://community.hortonworks.com/articles/7882/hdfnifi-best-practices-for-setting-up-a-high-perfo.html

ruby의 irb/pry 조합과 동일하게 사용할 수 있는 파이썬 조합이다.

1. ipython

찾은 링크는 다음과 같다. 

https://gist.github.com/Integralist/a2f01ab4aabb786268d5006da5013c9e

pip install ipython만 하면 된다.

pry처럼 정확히 

2. pdb

https://docs.python.org/3/library/pdb.html

http://pythonstudy.xyz/python/article/505-Python-%EB%94%94%EB%B2%84%EA%B9%85-PDB

3. pudb

https://github.com/inducer/pudb