프로그래머 열정을 말하다 책을 봤다. 너무 재미있었다.

http://www.yes24.com/Product/Goods/6185848

원서는 My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers)  이다. 

https://www.amazon.com/Job-Went-India-Pragmatic-Programmers/dp/0976694018  (2005년에 쓰여진 책이라니!!)

44살의 개발자 아저씨가 보기에 정말 중요한 내용인 것 같다. 다 완벽하고 좋은 말은 아니지만...

개발을 계속 하고 싶고, 프로그래밍하는 것이 즐겁다면 꼭 보면 좋을 것 같다.

책 내용을 간결히 요약한 블로그가 있으니. 참고하길 바란다.

http://jehyunpark.github.io/book/2017/02/12/the-passionate-programmer.html

클라우드 시스템을 관리하는 기술(http://www.hanbit.co.kr/store/books/look.php?p_code=B9686521083)에서 발췌한 자료이다.

Site Reliability 관행

1. 개발자(coder)만 고용한다.

2. 서비스마다 SLA를 둔다.

3. 성능을 측정하고 SLA를 만족하지 못하는 사항을 보고한다.

4. 오류 계산을 활용하고 개시(lauch)들이 반드시 오류 예산을 지키게 한다.

5. 공통의 직원 풀에서 SRE팀과 개발팀에 인원을 공급한다.

6. 여분의 (운영팀의 수용 능력을 넘는) 운영 (OPS) 작업은 개발팀(DEV)로 흘러가게 한다.

7. SRE 운영 부하가 50%를 넘지 않게 한다.

8. 운영팀의 작업의 5%를 개발팀과 공유한다.

9. 호출대기 팀은 한 장소에 적어도 여덟 명으로 구성하거나 여러 장소들 각각에 적어도 여섯 명으로 구성한다.

10. 호출 대기의 한 교대 근무(shift) 기간에 발생하는 사건이 최대 2회를 넘지 않도록 한다.

11. 모든 사건에 대해 사후 분석(postmortem)을 수행한다.

12. 사후 분석이 누군가를 비난하는 기회가 되어서는 안된다. 사람보다는 공정과 기술에 초점을 두어야 한다.

아마존의 Redshift와 구글의 Bigtable을 고려한 적이 있었는데..

"빅 데이터를 지탱하는 기술"이라는 책에서 잠깐 내용을 소개하자면..

중요한 차이점이 하나 있는데. Redshift는 전용(dedicated)인 반면, Bigtable은 멀티테넌트 기반의 공유(shared) 자원 기반이라는 점이다.

따라서 Redshift는 다른 사용자가 사용할 없어서 성능이 안정적이다. 항상 일정한 성능이 나온다.

반면, BigTable은 데이터를 분산하기 때문에 고속화를 실현한다. 다수의 디스크에 데이터가 분산되는 형태를 갖는다. (muti-tenancy 구조이다.)

https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html

https://cloud.google.com/blog/products/gcp/bigquery-under-the-hood

https://dev.mysql.com/doc/refman/5.7/en/replication-multi-source-tutorials.html

2017년 우버에서 자기들이 사용하는 hoodie를 공유했다.

https://eng.uber.com/hoodie/

이게 개념적으로 kappa 아키텍처 (보통 우리가 쓰는 lamba 아키텍처의 다음 버전, incremtal )으로

HDFS에 metadata, index, data를 Spark 라이브러리로 구현한 오픈 소스(https://github.com/uber/hudi)이다.

스키마 이슈를 풀기 위해 avro를 사용하고 컬럼 기반의 최적화된 성능을 보장하기 위해 parquet를 사용다. 읽을 때는 컬럼 단위로 읽으니 Scan에 최적화된 Parquet, 저장할 때는 스키마 이슈없고 row단위로 저장하는 Avro를 사용한다. 컴파일 병렬화, 쿼리 병렬화, HDFS의 파일 이슈(쿼터)를 해결하기 위해 HDFS 블록 크기로 저장한다.

저장할 때 데이터를 정확히 partition 단위로 저장하고, HDFS 블록 크기만큼 채워서 저장한다. 그런식으로 계속 저장한다. 데이터의 변경은 bloom filter로 미리 저장한 위치를 빨리 찾도록 변경된 데이터를 추가하는 방식을 사용하고 있다. 

compaction은 시간제한이 걸려 있고 몇 분마다 비동기로 진행한다. 이때 compaction과 변경이 걸리면 이슈가 되니 lock을 zookeeper로 걸어 사용한다. 

유투브 발표 자료.

그리고 2018년 7월에 하나의 블로그를 올려놨다.

https://eng.uber.com/uber-big-data-platform/

나름 kappa 아키텍처 기반임에 틀림없다. 

중요한 포인트는 증분 데이터를 append함으로서 최종 값과 증분 값 모두 읽을 수 있다는 점이다. 

금융권 클라우드 이용 확대 방안 (pdf)

https://www.fsc.go.kr/downManager?bbsid=BBS0030&no=127829

요약:

열심히 일했던 카카오의 한 동료가 여의치 않게 퇴사하게 되었다. (1년 조금 안되게 함께 일했던 것 같다.)

하지만 능력있던 그 동료가 소설가로 신인상을 받게 되었다. 

너무 축하해 주고 싶다!!!!!

앞으로 계속 잘 되시기를!!!!

앞으로 책 나오면 잘 볼께요~

http://www.changbi.com/archives/76278?cat=3378

– 제21회 창비신인소설상

수상작: 장류진(張琉珍) 「일의 기쁨과 슬픔」

수상자 약력: 1986년생. 연세대 사회학과 졸업, 동국대 대학원 국어국문학과 수료

심사위원: 기준영 김성중(이상 소설가) 박인성 한영인 황정아(이상 문학평론가)

선정 이유: 「일의 기쁨과 슬픔」은 짧고 기민하게 잽을 날리는 가벼운 스텝의 복서를 연상케 한다. 회장의 심기를 거스르는 바람에 월급을 전액 카드 포인트로 받게 된 ‘거북이알’이 다시 포인트를 돈으로 전환하기 위해 중고거래에 나선다는 설정은 한숨이 나올 만큼 ‘웃픈’ 이야기지만 재벌총수가의 물의가 연일 보도되는 현실의 거울에 비추어보면 허무맹랑한 소리만은 아니다. 인물들이 나란히 판교 엔씨소프트 사옥 너머로 네모난 하늘을 바라보는 장면에서 보이듯 작품에 묘한 청량감이 있다고 할까. 꽉 짜인 로직을 뚫고 한줄기 바람이 통과하는 듯한, 세상은 만만치 않고 어이없는 일투성이지만 그 안에서 ‘소확행’이든 무엇이든 자기만의 방식으로 적응해나가는 청년세대의 기쁨과 슬픔이 생생하다.

소설 내용은 아래 링크..

https://magazine.changbi.com/q_posts/%EC%9D%BC%EC%9D%98-%EA%B8%B0%EC%81%A8%EA%B3%BC-%EC%8A%AC%ED%94%94/?board_id=2659

LB를 잘 모르는 개발자가 있어서 링크를 모았다.

개발자가 LB 장비를 이해하면 개발 아키텍처에 도움이 될 뿐 아니라

시스템 엔지니어/네트워크 엔지니어가 무엇을 하는지 많은 도움이 된다.

L4 스위치의 inline, DSR 비교

http://travelc.tistory.com/82

DSR과 헬쓰체크

(카카오 그림이지만 네이버와 거의 비슷하다고 볼 수 있다)

http://tech.kakao.com/2014/05/28/l3dsr/

GSLB

https://www.netmanias.com/ko/post/blog/5620/dns-data-center-gslb-network-protocol/global-server-load-balancing-for-enterprise-part-1-concept-workflow

트래픽이 많은 큰회사가 많이 사용한다.

(예, 네이버)

쿠버네티스 네트워킹(kubernetes networking)에 대한 쉬운 이해와 문서를 모아둠

이 문서를 가장 먼저 보길 바란다.

https://www.level-up.one/kubernetes-networking-pods-levelup/

https://www.level-up.one/kubernetes-networking-series-two/

https://www.level-up.one/kubernetes-networking-3-level-up/

그 다음에는 아래 문서를 보고.

https://speakerdeck.com/thockin/illustrated-guide-to-kubernetes-networking

이 문서를 보면 더욱 도움 될 것이다.

https://medium.com/@ApsOps/an-illustrated-guide-to-kubernetes-networking-part-1-d1ede3322727

https://medium.com/@ApsOps/an-illustrated-guide-to-kubernetes-networking-part-2-13fdc6c4e24c

쿠버네티스 정식 문서

https://kubernetes.io/docs/concepts/cluster-administration/networking/

참고로 오픈 스택 네트워킹(provider network, vlan, tunneling, north/south&east/west)애 대한 개념이 생길 것이다.

https://keithtenzer.com/2016/07/18/openstack-networking-101-for-non-network-engineers/

okhttp3와 moshi만 있으면 자바/스칼라 http 통신이 완전 편해진다.. 

okhttp3와 moshi는 json serialization/deserialization 개발 공부를 크게 낮춘다.

https://github.com/square/okhttp/wiki/Recipes

https://github.com/square/moshi