대기업에서는 Proxy를  두어 외부 인터넷 연결을 제어한다. 


다만 내부 머신에서 외부 인터넷으로  제대로 패킷이 나가는지 테스트하려면 다음 코드로  테스트한다.



<Proxy.java>



import java.io.*;

import java.net.*;

import java.util.Properties;


public class Proxy {


    public static void main(String[] args) throws Exception {

String url = "http://repo.typesafe.com";


URL server = new URL(url);

HttpURLConnection connection = (HttpURLConnection)server.openConnection();

connection.connect();

InputStream in = connection.getInputStream();


        ByteArrayOutputStream baos = new ByteArrayOutputStream();

        byte[] buffer = new byte[1024];

        int readBytes = -1;


        while((readBytes = in.read(buffer)) > 1){

            baos.write(buffer,0,readBytes);

        }


        byte[] responseArray = baos.toByteArray();

System.out.println(new String(responseArray));


in.close();

    }

}



<사용법>



javac Proxy.javac


java -Dhttp.proxyHost=proxy.google.io -Dhttp.proxyPort=31281   -Dhttps.proxyHost=proxy. google.io  -Dhttps.proxyPort=31281     -Dhttp.nonProxyHosts="localhost|127.*|192.168.*|10.*|172.16.*|*.google.io"  Proxy


Posted by 김용환 '김용환'



구글 논문 - 코드 저장소는 단일화(monolithic)가 좋더라는 내용이 담겨 있다.


https://people.engr.ncsu.edu/ermurph3/papers/seip18.pdf




Posted by 김용환 '김용환'



CDC는 변경 데이터 캡처(Change Data Capture)의 약자로서 다른 소프트웨어가 이러한 변경 사항에 응답 할 수 있도록 데이터의 변경 사항을 모니터링하고 캡처하는 시스템의 오래된 용어이다. 

데이터웨어 하우스에는 CDC 지원 기능이 내장되어 있다. 업스트림 OLTP 데이터베이스에서 데이터가 변경되면 데이터웨어 하우스를 최신으로 유지해야 한다.




대표적으로 Debezium(발음은 디비지움이라 함, https://debezium.io/docs/contribute/)이 요즘 뜨고 있는데.. 기본적으로 다양한 데이터베이스 시스템 모니터링을 지원 하는 현대적이고 분산 된 오픈 소스 변경 데이터 캡처 플랫폼이다.



(https://vladmihalcea.com/a-beginners-guide-to-cdc-change-data-capture/ 참고)




 


<참조 링크 모음>

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


https://vladmihalcea.com/a-beginners-guide-to-cdc-change-data-capture/



https://medium.com/blablacar-tech/streaming-data-out-of-the-monolith-building-a-highly-reliable-cdc-stack-d71599131acb


https://developers.redhat.com/videos/youtube/QYbXDp4Vu-8/


https://www.youtube.com/watch?v=IOZ2Um6e430&feature=youtu.be


https://techmagie.wordpress.com/2018/04/01/accelerating-data-loading-into-data-lake-using-cdc/



https://www.ridicorp.com/blog/2017/10/30/binlog-collector/



https://www.confluent.io/blog/no-more-silos-how-to-integrate-your-databases-with-apache-kafka-and-cdc


https://www.linkedin.com/pulse/change-data-capture-postgresql-via-debezium-part-1-paolo-scarpino/


https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-your-data



https://wecode.wepay.com/posts/streaming-databases-in-realtime-with-mysql-debezium-kafka


https://debezium.io/blog/2018/12/05/automating-cache-invalidation-with-change-data-capture/


https://www.confluent.io/kafka-summit-sf18/change-data-streaming-patterns-for-microservices-with-debezium


https://engineering.linkedin.com/data-replication/open-sourcing-databus-linkedins-low-latency-change-data-capture-system




<고민꺼리>


CDC를 실제로 구현하기 위한 작업이 만만치 않은 것 같다.


GTID, bin 포맷, 운영이슈(MHA 등), 아키텍처





Posted by 김용환 '김용환'


여러 컨슈머가 동일 토픽에서 메시지를 읽을 때 사용하는 주요 패턴은  다음 2가지이다.


<로드 밸런싱(load balancing)>


각 메시지는 여러 컨슈머 중 특정 컨슈머에 전달된다. 따라서 컨슈머들(컨슈머 그룹)은 해당 토픽의 메시지를 처리하는 작업을 공유한다. 브로커는 메시지를 전달할 컨슈머를 임의로 지정한다. 이 패턴은 메시지를 처리하는 비용이 비싸서 처리를 병렬화하기 위해 컨슈머를 추가하고 싶을 때 유용하다. 또한 컨슈머가 죽으면 관련 컨슈머 그룹에서 나머지 실시간  컨슈머에게 나누어진다.


IBM 문서에 친절히 설명되어 있다.

https://www.ibm.com/support/knowledgecenter/ko/SSCGGQ_1.2.0/com.ibm.ism.doc/Developing/sharedsubscriptionsinjms.html



AMQP는 같은 큐를 소비하는 클라이언트를 여러 개 둬서 로드 밸런싱을 구현할 수 있다. JMS에서는 이 방식을 shared subscription이라 한다. 카프카에서는 load share라고 한다.



<팬 아웃(fan out)>


각 메시지가 모든 컨슈머에 전달된다. 컨슈머가 브로드캐스팅된 동일한 메시지를 서로 간섭없이 들을 수 있다. 


JMS에서는 토픽 구독, AMQP에서는 바인딩 교환이라는 용어를 사용한다. 카프카에서는 팬 아웃이라고 한다.



카프카의 경우, 컨슘될 때 카프카에서 메시지가 제거되지 않아서 소비자를 여럿 추가 할 수 있고 각 컨슈머는 자체 메시지 오프셋을 유지 관리할 수 있습니다. 물론 컨슈머는 서로 다른 컨슈머 그룹에 있어야 한다.





이 두 패턴은 함께 사용할 수 있다.




Posted by 김용환 '김용환'




저장 데이터가 커지면 1대의 장비에 다 저장할 수 없다.


이를 위해 DB에서는 샤딩(sharding)이라는 방식을 사용해 데이터를 분산 저장한다.(사실 플러스로 복제(replica)를 둔다)


hashing, dictionary-hashing, incremental sharding 이렇게 분리한다.



DB 외에 Nosql마다 비슷한 용어를 가지고 있다. 샤딩은 사실 파티션(partition)이라는 일반적인 단어로 포함할 수 있다.



파티션은 일반DB의 샤딩(공식 용어는 아니다),  몽고 DB, 일래스틱서치, 솔라의 샤드(shard)에 해당된다.


HBase에서는 리전(Region), 


구글 Bigtable에서는 테블릿(tablet),


카산드라(Cassandra)와 Riak은 vnode,


Couchbase에서는 vBucket이라 부른다.




Posted by 김용환 '김용환'



김창준 씨의 함께 자라기(애자일로 가는 길) 중 구글의 실험 내용을 정리한 아주 일부분만 발췌한다.



Oxygen Project : 구글이 관리자를 없애는 실험을 2002년에 실험했지만 결과는 좋지 않았다. 이에 인재 분석팀을 꾸려 뛰어난 관리자의 특징을 찾는 연구인 Oxgen Project를 2008년에 시작했다.


이후 Aristotle Project를 진행했고 2015년에 발표했다.

https://rework.withgoogle.com/print/guides/5721312655835136/



김창준씨가 중요하게 여긴 세 부분은 다음과 같다.


1. 팀에 누가 있는지(전문가, 내향/외향), 지능 등)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.



2. 5가지 성공적 팀의 특징을 찾았는데, 그 중 압도적 높은 예측력을 보인 변수는 팀의 심리적 안전감(내 생각, 의견, 질문, 걱정, 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음)이었다.


3. 팀 토론 등 특별히 고안된 활동(gTeams execise)라 불리는 활동인데, 10분간 5가지 성공적인 팀의 특징에 대해 팀원들이 답하고 팀이 얼마나 잘하는 요약 보고서를 보고, 결과에 대해 면대면 토론을 하고 팀이 개선하게 자원(교육 등)을 제공하는 것이라 한다.





참고로..


외국의 좋은 IT회사에서는 관리자는 면대면 토론을 항상 진행하고 멘토링을 진행한다고 한다. 심리적 안정감을 계속 주는 활동을 진행한다고 한다. 



https://rework.withgoogle.com/print/guides/5721312655835136/ 



팀은 무엇인가?  데이터를 모으고 효율을 측정하는 방법, 효율적인 팀을 정의하는 방법이 있다.


The researchers found that what really mattered was less about who is on the team, and more about how the team worked together. In order of importance:







참고할만한다. 문화를 만드는데 중요한 것 같다..





Posted by 김용환 '김용환'


ssh agent forwarding(에이전트 포워딩)에 sudo를 사용할 때 참고할만한 싸이트


https://gist.github.com/scottjacobsen/4281310




> sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK git clone git@github.com:my-github-account/my-repo.git


Posted by 김용환 '김용환'



jenkins pipeline 공부에 도움이 되는 것 같아 링크 중심으로 정리했다.



1. pipeline


pipeline 개념, 공식 문서

https://jenkins.io/doc/book/pipeline/


한글 - 사례

https://kingbbode.tistory.com/35


https://jojoldu.tistory.com/355


https://limsungmook.github.io/2016/11/09/jenkins-pipeline/




2. multi-branch


특정 branch 뿐 아니라 pr, branch도 테스트할 수 있다. jenkinsfile(pipeline)을 포함하면 금상첨화이다.


공식 문서

https://jenkins.io/doc/book/pipeline/multibranch/


사례


https://www.praqma.com/stories/jenkins-pipeline/




3. blue ocean에서 pipeline 편집하기


공식 문서

https://jenkins.io/doc/tutorials/create-a-pipeline-in-blue-ocean/


쉽게 파이프라인을 구성할 수 있다. 



ci/cd 실제 사례



Posted by 김용환 '김용환'



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

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



Posted by 김용환 '김용환'


클라우드 시스템을 관리하는 기술(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. 사후 분석이 누군가를 비난하는 기회가 되어서는 안된다. 사람보다는 공정과 기술에 초점을 두어야 한다.


Posted by 김용환 '김용환'