스파크의 사용환경 발표(data bricks)


아래 슬라이드의 9페이지에 소개되어 있음.


https://www.slideshare.net/ydn/february-2016-hug-running-spark-clusters-in-containers-with-docker

February 2016 HUG: Running Spark Clusters in Containers with Docker from Yahoo! Developer Network




  • Spark in Standalone mode - 48%
  • Spark on YARN - 40%
  • Spark on MESOS - 11%


'scribbling' 카테고리의 다른 글

SRE 문화 만들기  (0) 2017.06.14
아파치 스파크 2017 발표 자료  (0) 2017.06.14
[펌] 스파크의 사용 환경 내용 - data bricks  (0) 2017.05.24
[성과] OKR  (0) 2017.05.23
[펌] uber 아키텍처  (0) 2017.05.22
goto 2017(chicago, 2017/5/1~2017/5/2) 자료 다운받기  (0) 2017.05.16
Posted by 김용환 '김용환'

[성과] OKR

scribbling 2017.05.23 11:12



한글 좋은 글, 링크
https://brunch.co.kr/@jjollae/8



영문


https://www.slideshare.net/HenrikJanVanderPol/how-to-outperform-anyone-else-introduction-to-okr


https://www.slideshare.net/mustansir78/guide-to-okr-objectives-key-results


https://library.gv.com/how-google-sets-goals-okrs-a1f69b0b72c7


책으로 보려면 아래 싸이트 가서 공짜 Perdoo-OKR-eBook.pdf를 다운받는다. 

https://info.perdoo.com/how-to-write-okrs



Posted by 김용환 '김용환'


EVOLVING DISTRIBUTED TRACING

https://eng.uber.com/distributed-tracing/



https://eng.uber.com/tech-stack-part-one/



qcon london -  REALTIME STREAM COMPUTING &ANALYTICS 

https://qconlondon.com/london-2016/system/files/presentation-slides/sudhittonse.pdf



oscon 2017 - wishful thinking

https://cdn.oreillystatic.com/en/assets/1/event/214/Wishful%20thinking%20Presentation.pdf

Posted by 김용환 '김용환'


5월 1/2일에 goto 2017 세션이 있었다. 자료는 아래 링크에 가면 자료를 다운받을 수 있다.


https://gotochgo.com/2017/schedule





* 세션 중 재미있는 것을 정리


1) Fast Data Architectures for Streaming Applications


https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/37/original/DeanW-GOTOChicago-2017.pdf





--> (결국 여기 접속) http://lightbend.com/fast-data-platform





2) Apache Beam 소개

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/27/original/Beam_Intro.pdf



3) 개발 문화에 대한 얘기https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/81/original/Video%20Transcoding%20at%20the%20ABC%20with%20Microservices%20-%20GOTO%20Chicago.pdf

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/43/original/Tim-Gross.pdf


4) microservice

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/74/original/gotochicago_from_a_startup_perspective.pdf


ABC 방송국의 microservice

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/81/original/Video%20Transcoding%20at%20the%20ABC%20with%20Microservices%20-%20GOTO%20Chicago.pdf



5) python-베이지안

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/121/original/LORENAMESA_GOTO%20Conf%20-%20Predicting%20free%20pizza%20with%20Python.%20Cowabunga%20dude!.pdf


6) jdk9

https://conf-assets.s3.eu-central-1.amazonaws.com/uploads/slides/conference_3/54/original/Javalution.pdf




'scribbling' 카테고리의 다른 글

[성과] OKR  (0) 2017.05.23
[펌] uber 아키텍처  (0) 2017.05.22
goto 2017(chicago, 2017/5/1~2017/5/2) 자료 다운받기  (0) 2017.05.16
간단한 http client - okhttp  (0) 2017.04.28
아파치 오로라(Apache Aurora)  (0) 2017.04.21
[메소스] DRF 알고리즘  (0) 2017.04.20
Posted by 김용환 '김용환'

간단한 java http client 가 있다. android도 지원하는 경량 java http client이다. 


OkHttp - http://square.github.io/okhttp



public static final MediaType JSON

= MediaType.parse("application/json; charset=utf-8");

OkHttpClient client = new OkHttpClient();

String post(String url, String json) throws IOException {

RequestBody body = RequestBody.create(JSON, json);

Request request = new Request.Builder()

.url(url)

.post(body)

.build();

Response response = client.newCall(request).execute();

return response.body().string();

}





Posted by 김용환 '김용환'

어느 분이 마라톤보다 오로라가 좋다고 해서 자료를 찾아봤다.


오로라는 트위터에서 만들어진 오픈 소스로서 현재는 아파치 재단에 관리되고 있다. 



아파치 오로라의 주요 기능은 다음과 같다.

* 크론(cron) 작업, 오랫동안 실행하는 서비스, 작업 관리를 위한 메소스 프레임워크이다.

* 트위터에서 개발되었고 나중에는 아파치 라이선스를 가진 오픈 소스로 전환되었다.

* 오랜 기간동안 공유 자원 풀에서 오랫동안 실행하는 작업을 유지한다. 한 대의 장비에서 실패하면 다른 장비에서 작업을 다시 예약한다.

* 스케쥴러 자체이기 때문에 특정 스케줄링 요구 사항이 있는 시스템에는 권장되지 않는다.

* 어느 시점이든 특정 작업에 대한 코오스 그레인드(coarse grained) 자원을 제공한다.

* 다중 사용자를 지원한다.

* 설정 중복을 피하기 위해 DSL(Domain Specific Language)을 사용해 설정을 지정한다.



오로라와 마라톤은 유사한 기능들을 제공하며 둘 다 서비스 스케줄러로 분류된다. 둘 사이에는 세 가지 주요 차이점이 있다.


* 오로라는 설치하기 쉽지 않다. 오로라는 쓰리프트(thrift) API를 노출한다. 즉, 프로그램으로 상호 작용할 수 있는 쓰리프트 클라이언트가 필요하다는 것을 의미한다. 반면 마라톤은 최대한 Hello World를 빨리 실행할 수 있도록 도와준다. 많은 환경에서 해당 작업을 수행할 수있는 좋은 문서가 있고 갈 시간이 거의 없다. 그것은 REST API를 가지고 있고 마라톤은 설정을 위해 JSON을 사용한다.


* 오로라는 트위터와 같이 큰 회사에서 사용될 수 있도록 설계되었다. 예를 들어 트위터 클러스터에는 수만 대의 장비와 수백 명의 엔지니어가 있는데 마라톤으로 기능을 빨리 개발했지만 생산성이 떨어진다고 느꼈다.  이에 대한 적절한 예시로 Docker 지원 기능을 들 수 있다. 마라톤은 선점(preemption) 기능을 제공하지 않는다.


* 오로라는 아파치 소프트웨어 재단(ASF, Apache Software Foundation)이 소유하고 있다. 즉, 오로라는 아파치 커뮤니티에 의해 주도되는 아파치 소프트웨어 재단의 거버넌스 모델로 적용된다. 오로라는 사용자에게서 돈을 받지 않으며 현재 소프트웨어 개발 회사에게서 개발비를 받고 있지 않다. 마라톤은 메소스를 소유한 메소스피어(Mesosphere) 사의 소유이다. 메소스피어에게서 지원과 기능을 제공받으려면 유료로 진행될 수다..

Posted by 김용환 '김용환'

아파치 메소스의 DRF 관련



 최대 작업 수를 실행하고 자원을 가장 효율적으로 사용하기 위해 두 사용자의 자원을 어떻게 분배할 것인가 이다. 기존 알고리즘을 사용한다면 두 사용자 모두에게 동일한 크기의 자원을 할당할 수 있지만 이는 원하는 것이 아니다. 이러한 상황을 이기종 환경(heterogeneous environment)이라고 부른다.


아파치 메소스는 DRF(Dominant Resource Fairness)라는 알고리즘을 구현하며, DRF 알고리즘을 메소스의 자원 할당의 기본 정책으로 사용하고 있다.



대개 DRF 알고리즘을 대학 수준의 운영 체제 과목에서 가르친다. 작업 스케줄링(job scheduling)은 CPU에만 제한되지 않으며 메모리, 네트워크, 디스크와 같은 여러 자원이 존재한다. 그러나 자원 유형을 줄여 문제를 단순화하면 어떤 작업은 프로세서 집약적이고 다른 작업은 디스크 집약적이고, 또 다른 작업은 메모리 집약적이기 때문에 최대-최소 공정성(max-min fairness) 알고리즘이 실패(강력하지 않고 효율적이지 않음)하는 것을 볼 수 있다.


여기에 이기종 환경의 각 사용자에게 자원을 공평하게 분배할 수 있는 자원 스케줄링 메커니즘이 필요하다. 요컨대 DRF 알고리즘은 이기종 자원을 가진 시스템에 최대-최소 공평성 알고리즘을 적용한 것이다.



자원이 사용자 간에 동등하게 분배되지 않으면 DRF 알고리즘에 가중치가 적용된다고 말한다. 공유는 사용자별, 자원 수준별로 가중치를 적용할 수 있으며 사용자별이 더 많이 사용된다.


가중치가 적용된 알고리즘에는 가중치 외에 다음 기능을 더 가진다.


* 공정한 분배(envy freeness) : DRF 알고리즘은 다른 사용자의 자원 할당을 부러워할 필요가 없기 때문에 자유롭다. 가장 낮은 지배 점유율을 가진 사용자에게 자원을 제공하기 때문에 모든 사용자는 동일한 기회를 가질 수 있다.


* 파레토 효율(Pareto efficiency) : 특정 사용자의 통제 관심도를 높이면 자원에 대한 다른 사용자의 지배적인 참가가 비례적으로 감소한다. 한 사용자에게 더 많은 자원을 할당하면 다른 사용자에게 피해를 준다.

* 점진적인 충전(progressive filling) : DRF 알고리즘은 모든 사용자에 대해 동일한 비율로 지배 점유율을 증가시킨다. 다른 알고리즘은 수요에 따라 자원을 할당한다. DRF는 자원이 고갈되면 사용자가 자원을 해제하고, 다른 사용자가 재귀적으로 진행될 때 종료되며, 지배 점유율을 가진 사용자가 증가할 때까지 프로세스는  계속된다.

* 점유율 보장(share guarantee) : 모든 사용자의 지배 점유율 할당은 동일한 비율로 증가하므로 사용자를 동등하게 대우하고, 적어도 하나의 자원 일부는 보장된다.

* 전략 증명(strategy proof) : 사용자는 사용자 자신의 자원 요구를 위조할 수 없다. 한 사용자가 더 많은 자원을 요구하면 DRF 알고리즘은 사용자를 방해하지 않는다.


* 참고 자료

DRF 관련 논문
https://cs.stanford.edu/~matei/papers/2011/nsdi_drf.pdf
여기에 좋은 psedo 코드가 있다.

https://en.wikipedia.org/wiki/Envy-free_cake-cutting


분배 개념은 사회학적으로 나온 얘기였다. 전문용어를 여기서 배울 줄이야.
http://s-space.snu.ac.kr/bitstream/10371/52804/3/04%20envy-free.pdf





Posted by 김용환 '김용환'


출처 :

https://twitter.com/gosubpl/status/850668532832645120/photo/1


스칼라 컨퍼런스에서 Web과 Stream 선호도를 사람들한테서 받은 내용이 있었나보다..



Akka Http와 Akka Stream 이 대세인듯 하다.






Posted by 김용환 '김용환'



1. mesos containerizer 메소스 컨테이너라이저 공식 문서


http://mesos.apache.org/documentation/latest/containerizer/


http://mesos.apache.org/documentation/latest/container-image/



2. mesos와 컨테이너 설명 자료




Mesos and containers from Jiang Yan Xu




Mesos: A State-of-the-art Container Orchestrator from C4Media




3. SMACK 스택 

스파크와 메소스 관점에서 본 메소스 컨테이너라이저 실례


Data processing platforms with SMACK: Spark and Mesos internals from Anton Kirillov





Posted by 김용환 '김용환'


최근 트위터에서 장비 구성을 소개하는 기술 블로그를 작성했다.


https://blog.twitter.com/2017/the-infrastructure-behind-twitter-scale


메소스 기반으로 서비스를 구성하고 있음을 느낄 수 있었다. 









메소스를 많이 활용한 것으로 나타나는 데, 특징적인 것은 코드 라인이 줄어들고 있다는 점이다. 




https://www.wired.com/2013/03/google-borg-twitter-mesos/에 따르면, 트위터의 메소스 역사를 살펴볼 수 있다.



These were Twitter engineers who had once worked at Google: John Sirois, Travis Crawford, and Bill Farner. They told Hindman that they missed Borg, and that Mesos seemed like the perfect way to rebuild it.



He and his fellow engineers continued to run Mesos as an open source software project, but at Twitter, he also worked to move the platform into the company’s data center and fashion something very similar to Google Borg.


트위터의 전직 구글 개발자는 메소스를 구글의 Borg(https://static.googleusercontent.com/media/research.google.com/ko//pubs/archive/43438.pdf)를 생각할 수 있다고 한다.






트위터에서 엔지니어링을 이끌었던 라이버가 트위터의 신규 서비스는 모두 메소스를 사용하도록 했다고 한다. 


http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140819141405

라이버트 CEO는 트위터의 엔지니어링을 이끌었던 인물이다. 그는 트위터의 신규 서비스에 모두 메소스를 사용하도록 했다. 트위터를 떠난 후 에어비앤비에서 메소스 상에 분석 환경을 구축했다. ETL 관리와 스케줄리을 위한 크로노스 아파치 메소스 프레임워크의 주요 저자기도 하다.




메소스의 특징을 한 장으로 표현하면 다음과 같다.



출처 : https://www.slideshare.net/mesosphere/apache-mesos-and-mesosphere-live-webcast-by-ceo-and-cofounder-florian-li





메소스는 다음과 같은 큰 특징이 있다.


  • 효율성(Efficiency) : 운영 체제와 같은 메소스 스케쥴링 기능은 애플리케이션(프레임워크)에서 CPU와 메모리를 관리한다.
  • 고가용성(High availability) : 아파치 주키퍼를 사용해 가용성을 높인다.
  • 모니터링 인터페이스(Monitoring Interface) : 메소스에는 클러스터 모니터링을 위한 넌블러킹(non-blocking) 웹 UI가 있다.
  • 자원 격리 : 리눅스와 도커(Docker) 컨테이너 아키텍처를 지원한다. multi tenancy를 지원한다. 
  • 확장성(Scalability) : 현재까지 현재 버전으로 최대 50,000개의 노드를 지원한다.

메소스 프레임워크는 메소스와 애플리케이션 간의 인터페이스이다.

프레임워크는 작업이 스케쥴링되고 실행되는 계층(layer)이다. 

프레임워크 구현은 애플리케이션에 의존적이어서 프레임워크와 애플리케이션이라는 용어를 불명확하게 사용하고 있다.
메소스 v.0.19.0 이전에는 메소스 프레임워크는 C++ 라이브러리인 libmesos와 바인딩을 해서 개발되었다. Mesos v.0.19.0부터는 개발자가 libmesos 라이브러리 호출없이 원하는 언어를 사용할 수 있도록 HTTP 기반 프로토콜이 도입되었다.

메소스 API를 사용하면 프로그래머가 메소스에서 애플리케이션을 실행하기 위한 자체 프레임워크를 작성할 수 있다.

프레임워크는 스케줄러(scheduler)와 익스큐터(executor)의 두 부분으로 구성된다.

  • 스케줄러(Scheduler) : 제공할 자원에 대한 결정을 내리고 클러스터의 현재 상태를 추적한다. 
  • 익스큐터(Executor) : 슬레이브 노드의 태스크 실행을 책임진다. 

현재 메소스 프레임워크의 목록은 다음과 같다. (특이할 점은 hbase가 없다..)
http://mesos.apache.org/documentation/latest/frameworks/




좀 더 내용을 살펴보려면 메소스 소개자료 1을 참조한다.

Introduction to Apache Mesos from tomasbart


메소스 소개자료 2이다. 



앞의 두 자료를 이해했다면, 아래 슬라이드를 참조하면 좋을 것 같다. 


Introduction to Apache Mesos from Joe Stein


2페이지에서 자료에서 나오는 링크는 다음과 같다.

http://static.usenix.org/event/nsdi11/tech/full_papers/Hindman_new.pdf

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

https://static.googleusercontent.com/media/research.google.com/ko//pubs/archive/41684.pdf




찾아보니 슬라이드 자료도 있다. 


Scaling Like Twitter with Apache Mesos from Mesosphere Inc.




* API 정리


메소스의 프로토콜 버퍼 api



Executor API
  • registered : 익스큐터와 메소스와 연결되면 호출된다.
  • reregistered : 익스큐터가 재시작된 슬레이브로 재등록할 때호출된다.
  • disconnected : 익스큐터가 슬레이브와 끊어졌을 때 호출된다.
  • launchTask : executor에서 작업이 시작될 때 호출된다.
  • killTask : 익스큐터에서 실행중인 작업이 종료될 때 호출된다
  • frameworkMessage : 프레임워크의 메시지가 익스큐터에 도착하면 호출된다
  • shutdown : 익스큐터가 현재 실행 중인 모든 작업을 종료해야 할 때 호출된다
  • error : 익스큐터와 익스큐터의 드라이버에서 치명적인 에러가 발생했을 때 호출된다



Executor Driver API

  • start : 익스큐터 드라이버를 시작한다
  • stop :  executor 드라이버를 중지한다.
  • abort :  드라이버를 중단하고 더 이상 익스큐터에 콜백을 만들 수 없도록 한다
  • join :  드라이버가 중지되거나 중단될 때까지 대기한다
  • run :  드라이버를 시작하고 즉시 join() 메서드를 호출한다.
  • sendStatusUpdate :  프레임워크 스케줄러에 상태 변경를 보낸다.
  • sendFrameworkMessage :  프레임워크 스케줄러에게 메시지를 보낸다.


Scheduler API

  • disconnected : 스케줄러가 마스터와의 연결이 끊어지면 호출된다
  • error : 스케줄러 또는 드라이버에 복구 할 수 없는 에러가 발생하면 호출된다
  • executorLost : 익스큐터가 종료되거나 종료될 때 호출된다
  • frameworkMessage : 익스큐터가 메시지를 보낼 때 호출된다
  • offerRescinded : 쿠폰이 더 이상 유효하지 않으면 호출된다
  • registered : 스케줄러가 메소스 마스터에 성공적으로 등록할 때 호출된다
  • reregistered : 스케줄러가 새로 선출된 메소스 마스터에 재등록할 때 호출된다
  • resourceOffers : 자원이 프레임워크에 제공되었을 때 호출된다
  • slaveLost : 슬레이브가 도달할 수 없다고 판단되면 호출된다
  • statusUpdate : 작업 상태가 변경되면 호출된다



Scheduler Driver API

  • abort : 더 이상 콜백이 스케줄러에 생성되지 않도록 드라이버를 중단한다
  • acceptOffers : 주어진 제안을 허용하고 허용된 제안에 대한 일련의 작업을 수행한다
  • acceptOffers : 상태 변경을 확인한다
  • declineOffer : 제안을 전체적으로 거부한다
  • declineOffer : 제안 전체를 거부하고 지정된 필터를 자원에 적용한다
  • join : 드라이버가 멈추거나 중단될 때까지 대기하고 현재 스레드를 무기한 차단한다.
  • killTask : 지정된 작업을 종료한다
  • launchTasks : 주어진 작업 집합을 실행한다
  • reconcileTasks : 해당 코드를 사용하면 프레임워크가 터미널이 아닌 작업의 상태를 확인할 수 있다
  • requestResources : 메소스의 자원를 요청한다
  • reviveOffers : 프레임워크에서 이전에 설정한 모든 필터를 삭제한다
  • run : 드라이버를 시작하고 즉시 조인한다(예, 블럭).
  • sendFrameworkMessage : 프레임워크에서 익스큐터 중 하나에게 메시지를 보낸다
  • start : 스케줄러 드라이버를 시작한다
  • stop : 해당코드는 스케줄러 드라이버를 중지한다. 또는 페일 오버(failover)가 없다고 가정하는 스케줄러 드라이버를 중지한다
  • suppressOffers : 메소스 마스터에게 프레임워크에 대한 제안을 보내는 것을 중지하도록 알려준다




Posted by 김용환 '김용환'