마리코프 체인는 다음 상태를 결정하기 위해 현재 상태만 의존하는 상태 전이에 대한 통계 모델 방법으로서 


마르코프 체인은 다음 상태를 알기 위해 현재의 상태만 의존한다. 


상태를 따로 저장하지 않기 때문에 메모리가 없어도 된다. 





* 이해를 높일 수 있는 괜찮은 동영상






공부에 도움 되는 자료



* http://electronicsdo.tistory.com/entry/Markov-chain-%EB%A7%88%EC%BD%94%ED%94%84-%EC%B2%B4%EC%9D%B8




* R 로 설명한 마르코프 체인 코드 


http://blog.revolutionanalytics.com/2016/01/getting-started-with-markov-chains.html



Posted by '김용환'
,




참고 : http://www.artima.com/articles/dci_vision.html


객체는 폴리모피즘, 커플링, 응집도가 아니라, 사람들과 사람들의 멘탈 모델에 대한 내용이다. 


MVC는 멘탈 모델이지 관찰자 패턴이 아니다.












참고 http://dm-academy.github.io/aitm/aitm-instructor.html


In this situation, each person has their own “mental model” of what needs to be done, and their own tracking mechanism. We don’t know how the work is being transmitted: emails, phone calls, hallway conversations (”Say Sara, there is an issue with Customer X’s bill, can you please look into it?”)







참고 : http://designbyforest.tistory.com/entry/UX%EB%AA%A8%EB%93%A0-%EA%B8%B0%ED%9A%8D%EC%9E%90%EC%99%80-%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88%EA%B0%80-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EC%82%AC%EB%9E%8C%EC%97%90-%EB%8C%80%ED%95%9C-100%EA%B0%80%EC%A7%80%EC%82%AC%EC%8B%A4



03 사람들은 패턴 인식을 통해 사물을 인식한다.
-사람은 자동적으로 패턴을 찾음. 분류와 공백을 이용 패턴을 만들어 내는것이 좋음.
-아이콘 요소는 인지하게 만드는게 쉽고, 빠르게 인지하게 함.
-평면보다는 입체를 더 잘 인지. 단, 화면상에  표현된 입체 요소를 인지하고 이해하는 속도는 평면 요소에 비해 느릴수도 있음.


멘탈모델이란?
실세계의 특정 대상물이 어떻게 작동하는지에 대한 사람의 사고 과정에 대한 설명.
디자인 모델 - 디자이너의 개념모델을 말함.
사용자 모델 - 사용자가가 시스템과 상호 작용하는 과정에서 만들어낸 멘탈모델을 말함.


28 특정 유형의 인지 처리 과정은 더욱 까다롭다.
- 디자인할 때 사용자가 많이 생각하거나 기억하지 않아도 되게 한다. 이 두 가지는 인지 부하를 일으켜 많은 정신적 자원을 필요로 한다.
- 기회 비용에 대해 고민하라. 예를 들어 시각 부하나 운동 부하를 높여 인지 부하를 줄일 수 있는 곳이 있다.
- 사람이 선택하는 항목을 충분히 키워서 쉽게 도달할 수 있게 만든다.







참고 : http://egloos.zum.com/hisprite/v/3810333


멘탈모델은 
일. 서비스나 제품 기획에 지침이 될 수 있고
이. 사용자와 사업을 위해서 좋은의사결정을 내리도록 도와주며
삼. 장기적인 비전과 기회를 제시해 준다.







참고 : http://blog.naver.com/PostView.nhn?blogId=vinylx&logNo=220171087380&redirect=Dlog&widgetTypeCall=true


정의 및 가치

멘탈 모델의 활용 가치는 발생할 수 있는 문제점을 미리 파악하고, 통합적인 서비스 이해를 바탕으로 해결 방안을 도출할 수 있다는 데 있습니다. 이 모델은 이전 포스트에서 소개된 ‘친화도 맵’이라고도 불리는 ‘어피니티 다이어그램(Affinity Diagram) - 사용자의 공통된 행동자료를 의미상 가까운 것끼리 모아 놓은 다이어그램’과도 밀접한 관련이 있습니다. 즉, 다른 사람의 행동 동기, 사고 과정을 비롯한 감성적, 철학적 배경을 이해하기 위하여 그들과 대화하고, 행동 패턴을 도출하여 정리한 것이 ‘멘탈 모델’ 입니다. 여기서는 ‘행동(task)’이라는 단어는 행위, 생각, 기분, 철학 그리고 동기에 이르기까지 사람이 무언가를 이루거나, 무언가를 움직이거나, 특정한 상태에 이를 때 나타나는 모든 것을 포괄하는 의미로 정의하도록 하겠습니다.













Posted by '김용환'
,



lazy evaluation이 왜 빠른지 궁금할 때 보면 좋을 만한 자료가 있다.


참조

http://filimanjaro.com/blog/2014/introducing-lazy-evaluation/



strict evaluation(eagerly evalution)의 방법은 한 단계씩 차례차례 진행한다고 할 수 있다.




lazy evaluation은 한 번에 처리를 한다는 개념(마치 chunk 배치) 으로 보면 된다.



따라서 대부분의 경우는 이렇게 성능이 좋다.!!








전체적으로 lazy 방식이 성능이 좋다. 



하지만, 항상(무조건) 빠르다고 보장할 수는 없다. 대충 비슷할 수도 있기 때문에 테스트가 필요하다.



또한, 코드는 복잡해지기 때문에 유지보수성이 떨어질 수 있는 단점이 있다. 





view를 이용해 lazy와 eager 계산법으로 만든 예시를 소개한다.



val list = List(0, 1, 2, 3, 4, 5)
// eager evaluation : 조급한 계산법 (위키)
val evens = list.map(i => {
println(s"$i")
i + 10
}).filter(i => {
i % 2 == 0
}).take(2).foreach(println)

println("-------")

// view를 이용한 lazy evaluation : 느긋한 계산법 (위키)
val evensView = list.view.map(i => {
println(s"$i")
i + 30
}).filter(i => {
i % 2 == 0
}).take(2).foreach(println)

첫 번째 stream(eager)에 대한 결과는 다음과 같다.


0

1

2

3

4

5

10

12



두 번째 stream(view를 사용한 lazy) 결과는 다음과 같다.



0

30

1

2

32



첫 번째 stream은 list의 모든 엘리먼트를 조사하고 결과를 내지만,

두 번째 stream은 정확하게 필요한 내용만 조사하기 때문에 속도가 빠르다. 

Posted by '김용환'
,



deview 2016 발표자가 되었다면 풍부하고 실제적인 자료를 전달할 수 있을 터인데, 아깝게 채택되지 못했다.


새로운 것만이 좋은 주제가 아니라, 우리 개발자들이 잘 하고 있는 일을 더욱 개선하는 작업도 좋은 사례로 남기고 싶었다.



이 내용은 나 혼자한 것은 아니고 동료들과 함께 진행한 내용이며,  해당 내용을 간단하게 글로 정리한다. 


(Docker, Jenkins, Rspec에 대한 팁은 내 블로그에서 검색할 수 있을 것이다.)




Spec by Example이라 했지만, (자세한 내용은 https://en.wikipedia.org/wiki/Specification_by_example를 참고한다)

Acceptance Test(인수 테스트)라고 좋고, Integration Test, Functional Test도 괜찮다. 

격리된 환경에서 서비스를 예제로 테스트하는 테스트 환경(Spec by Example)을 Docker로 빠르게 처리하는 방법을 진행했고, 이를 간단히 소개한다.





나는 그동안 직장 생활을 하면서 애플리케이션(또는 플랫폼)을 Spec by Example를 진행한 서비스/플랫폼을 거의 본적이 없다. (간단한 test unit이나 ui 속도 체크, js 속도 체크 정도는 있었지만, 그 이상의 통합 테스트가 없었다)


그리고, 나는 테스트의 의미를 깊이 생각하지 못했다. 개발하기도 바쁜데, 어떻게 테스트 코드까지 짜야하나 하는 불편함이 가지고 있었다. SKP에서 SI업체에서 만든 코드(정리 안된 코드, 테스트 없는 코드)를 받으면서, 정말 어이가 없는 환경에 대한 깊은 고민이 있었다. 테스트 코드에 대한 중요성을 생각하게 되었고, ansible을 공부하게 되었다.(deview 2014 발표)






<거대한 공룡과 싸우기 위해 

필요한 다양한 방패와 무기가 있어야 한다는 그림인데,

여전히 그 때나 지금이나 현실은 조금도 변함이 없는 것 같다. 나에게는 언제나 개발을 대할 때는 이런 것 같다. 
특히 대용량 서비스는 더 장난 아니다.>

이미지 참조 : https://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886







반면, 상용 서비스에서 통합 테스트 환경은 네이버 뉴스에서의 javadoc을 이용한 Functional Test 정도인 듯 하다. (소문에 따르면 지금은 사라졌다고 들었다).

http://d2.naver.com/helloworld/87523



지금 회사에 와서 서비스 개발하면서 가장 큰 수확은 바로 Spec By Example( 통합 테스트 환경)이었다. 수십 개의 컴포넌트가 유기적으로 동작하기 위한 테스트 환경이 Jenkins + Rspec을 기반으로 이미 구축되어 있었다. 

(혹시,,

Rspec을 잘 모른다면, https://semaphoreci.com/community/tutorials/getting-started-with-rspec를 읽으면 좋은 시작점이 될 것이다. 

Jenkins + RSpec 연동을 위해서는 https://sephinrothcn.wordpress.com/2014/04/24/run-rspec-with-jenkins/을 참조하면 좋을 것 같다)


(참고로 Rspec 말고도 최근에는 여러 Spec By Example 프레임워크가 나오고 있다.)






Ruby를 전혀 몰랐지만, Rspec을 통한 테스트 환경이 얼마나 서비스를 강력하게 만드는지 깨닫게 되었다.

격리된 환경에서 수십 개의 컴포넌트(자바 서버, MariaDB, Redis, ES, Mongo 등등......)에 수천 개의 시나리오 테스트가 동작하는 구조로 튼튼한(robust)할 수 있었다.


- 최대한 상용 환경과 비슷하다. 

- 리눅스, Mac OS에서 잘 동작한다.

- 인수 인계 문서가 필요없다. 시나리오 코드가 결국 어떻게 동작되는지를 설명한다.

- 코드 리팩토링하더라도 Spec 이 깨지는 일을 찾아내 문제를 빨리 해결할 수 있다.

- API를 기반으로 하기 때문에 스토리지를 변경하는 마이그레이션(Migration)을 쉽게 할 수 있다.

- 버전 별 API가 진행된다. 

- 운영을 하지만, Spec이 있기 때문에 

- Continuous Deployment의 근간, Continous


이외에 수 많은 장점이 있었다.





수천 개의 테스트를 시퀀셜(sequencial)로 진행될 때 가상 장비에서 50분이 넘어가기 시작했다. 이를 위해 병렬로 테스트를 진행하려 했지만, Rspec의 이슈가 아니라 수 천개의 테스트를 돌리다보니 서비스의 제약 사항을 넘지 못해 병렬로 진행하는 것은 실패했다.


중형 장비를 사용해 50분의 소요시간을 20분대로 줄였다.


이후, 시간이 흘러 Spec By Example 코드가 많아지면서 중형 장비가 다시 57분이 되었다. 


이를 해결하기 위해 여러 개발자와 함께 Docker와 Redis를 준비했다.그래서 8~9분 대로 줄어들도록 진행했고, Continuous Delivery(테스트가 성공되면 자동 개발 서버 배포)를 진행시켰다. 만족도는 좋았다!!!

Devops의 시간을 절약했다!!






이제 그 얘기를 진행한다. 


보통 Continuous Integration, Continuous Delivery, Continous Deployment의 근간은 Spec By Example이라고 생각한다. 그리고, 절제된 아키텍처가 필요했다.


Docker를 활용했지만, Docker의 이미지에 모든 것을 넣지 않았다. 변경이 자주 될만한 컴포넌트와 변경이 자주 안될만한 컴포넌트로 나눴다. 



변경이 자주 되지 않은 이미지를 Docker 이미지로 만들었다. 무척 큰 용량의 이미지가 생성된다.


- Docker 이미지를 생성한다

- Docker 이미지를 registry에 업로드한다. 

- Docker 이미지를 테스트 중형 서버에 배포된다. 




Jenkins에서 Job이 돌면서 Docker에 추가될 부분을 추가하고 여러 중장비에 Docker 이미지를 잘 사용할 수 있도록 했다.(정확히 말하면 병목 지점을 최대한 병렬화했다)


- 소스 커밋이 되면, Jenkins job 실행한다. (multijob + multijob)

- Job 실행시 docker 이미지를 사용해서 여러 데몬을 띄워 최대한의 성능을 낸다.

- 결과를 취합한다. (rspec + redis)

(주의할 사항은 Docker가 메모리 사용량이 높기 때문에 메모리에 대한 관리가 특별히 필요하다)

- 수천 개의 테스트를 모두 통과(정상)하면 개발 서버에 자동으로 배포한다. - Continuous Delivery



그리고, 여러 대의 중장비에 수십 개의 테스트 환경으로 분할할 때는 제대로 만든 분배 알고리즘이 만들었고, 잘 동작했다.


 



이를 기반으로 QA없이 테스트를 진행하고 빠른 Spec By Example을 통해 배포 시간을 최대한 줄였다. 








배운점 : 

1. 병목부분을 정확하게 아는 것이 중요하다. 

2. Docker, RSpec, Jenkin가 무엇인지 아는 것은 쉽지만, 제대로 아는 것은 쉽지 않다. 

   Docker를 무조건 이미지로 만들고 다운로드하는 것은 Continuous Integration에 적합치 않을 수 있다. 

   효율적인 구조로 만드는 개선 노력이 필요하다.

3. Docker를 여러 대의 중장비에 수십 개의 테스트 환경(Spec By Example)으로 동작시킬 때는 

     중장비를 사용하는 것이 좋다. 






소감 : 외국의 모델을 따라하는 게 아니라, 세계에 없는 우리 만의 모델을 만들었다는 점에서 기분이 좋았고, DevOps 사례로 남을 듯 하다. 


다음 시도 : 일부러 프레임워크를 쓰지 않았다. robust한 환경을 위해 Mesos + Marathon 대신 Google의 Kubernetes를 적용해서 반-자동화를 테스트해보고 적용할 예정이다. 





Posted by '김용환'
,


개발, 테스트와 관련된 용어이다. 



경계 조건은 영어로 edge case로서, 하나의 매개변수 값이 극단적인 최대값 또는 최소값이어서 로직에 문제가 발생할 수 있는 경우를 말한다. 

더 상세히 말하면..알고리즘에 처리하는 데 있어서 입력 매개변수의 유효 범위는 정해진다. 입력 범위가 다양해 질 수 있다. 따라서 테스트를 사용해서 입력 범위를 확인(validate)할 수 있다. 


예측이 될 수도 있고, 예측이 안될 수도 있지만, 문제를 어떻게든 해결할 수 있다.




복합 경계 조건은 영어로 corner case로서, 변수와 환경적인 요소로 인해서 로직에 문제가 발생할 있는 경우를 의미한다. 코드가 변경되지 않았는데, 테스트가 잘 성공하다가 실패할 때, 어떤 요인 때문에 발생할 수 있다.  랜선이 문제가 많거나 습도가 높은 컴퓨팅 환경 때문에 영향을 받을 수도 있다. 


재현, 테스트가 무척 어렵다.









Posted by '김용환'
,




Mesos 가 예제가 많길래 가장 영향력이 있는 줄 알았는데.



2016.9월.. docker cluster management할 수 있는 툴을 조사해봤다. 




구글의 Kubernetes, Docker Swarm, Apache Mesos, Hashicorp nomand, Coreos Fleet 정도가 있는 것 같다.



mesos가 많이 알려져 있어서 1등 인줄 알았건만, 현실은 역시 구글의 Kubernetes,


 2 등은 Docker swarm 이다. 





Posted by '김용환'
,



일반적인 HTTP 성능 테스트를 진행할 때,

일반적인 벤치마크는 웹 서버에서 요청을 처리한 시간을 먼저 저장하고, 클라이언트로 전달되기 직전 시간(응답 시간) 사이의 경과된 시간을 측정한다. 하지만, 웹 서버는 서버에서의 지연 시간(전문용어 latency)만을 측정하지 그 이후는 측정되지 않는다. 


바로 이 문제를 조율된 누락 문제(coordinated omission)라 한다. 성능 벤치마크시 많이 간과하기도 한다. 백분위수가 높거나 TPS가 어이 없이 높다면 의심할 필요가 있다. 


괜찮은 벤치마크일수록 요청을 보낸 순간과 클라이언트에서 응답을 실제로 받는 순간 사이의 시간을 명확히 측정한다. 즉 좋은 HTTP 성능 벤치마크라면, 클라이언트에서 HTTP 요청의 응답을 제대로 받은 순간까지의 시간을 측정할 수 있을 것이다. 


(그래서 Load Runner가 대단한 툴이라 생각하고 있다..)



참고로 더 자세한 내용을 보기 원하면, 두 개의 링크를 참조한다.


https://www.quora.com/In-Java-what-is-Coordinated-Omission



특히 아래 링크는 공부하기 좋은 자료가 있다.


https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ





참고로,  조율된 누락 문제를 언급한 툴로 elasticsearch rally에 있었다. rally의 현재 이슈에 대해서 elasticsearch 블로그에서 잘 설명되어 있어서, 관련 내용을 살펴보는 것도 좋을 것 같다.


https://www.elastic.co/kr/blog/announcing-rally-benchmarking-for-elasticsearch




아래 이슈에서 열심히 토론 중이다.


https://github.com/elastic/rally/issues/64







Posted by '김용환'
,





네이트 실버의 <신호와 소음>이라는 책 뒷 부분에 아래 글이 있어서 참 좋았다. (오래만에 본 정말 최고의 책이었다.)

이 책에서 인용한 글의 원문은 Serenity Prayer이었다.



예측은 아주 중요하고 그 때문에 더욱 어렵다. 소음에서 신호를 분리하려면 과학적 지식과 자기 인식을 갖추어야 한다. 즉, 객관적 실체와 주관적 실체를 교차시켜야 한다. 우리가 예측할 수 없는 것에 대한 겸손함과 예측할 수 있다는 것을 예측할 수 있는 용기, 그리고 이 둘 사이의 차이를 아는 지혜가 필요하다.




기도문에 있는 라인홀트 리버라는 신학자가 설교에 쓴 기도문이라고 한다.



https://ko.wikipedia.org/wiki/%ED%8F%89%EC%98%A8%EC%9D%84_%EB%B9%84%EB%8A%94_%EA%B8%B0%EB%8F%84


God, give us grace to accept with serenity the things that cannot be changed, courage to change the things that should be changed, and the wisdom to distinguish the one from the other.
(주여, 우리에게 우리가 바꿀 수 없는 것을 평온하게 받아들이는 은혜와 바꿔야 할 것을 바꿀 수 있는 용기, 그리고 이 둘을 분별하는 지혜를 허락하소서.)



참조

http://www.aahistory.com/prayer.html

Posted by '김용환'
,



BBC에서 BBC 홈페이지를 어떻게 만들었는지 간단하게 소개한 내용이 있다.


http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d



여기에서 주목할 내용은 Continuous Delivery를 위해 Acceptance test 용으로 mocha라는 툴을 썼다고 나온다.


http://mochajs.org/

https://github.com/mochajs/mocha



star가 10,000개가 넘을 정도로 인기가 좋다. 기회가 된다면 써봐야지..




describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  }); 

});


Posted by '김용환'
,

카산드라(Cassadra)라는 Nosql을 사실상 주도하는 DataStax가 2015년 아우렐리우스(https://github.com/thinkaurelius/titan)사의 그래프 DB(정확히 말하면 Titan)를 샀었다. 더 이상 아우렐리우스 그래프 DB를 관리하지 않고, 그 인력을 바탕으로 이번(2016.4)에 새로나온 Cassandra 엔터프라이즈 버전에 그래프 엔진을 추가했다.

가장 큰 특징은 그래프 DB 표준을 기반으로 한 것이라 한다.


https://tctechcrunch2011.files.wordpress.com/2016/04/datastax-studio.jpg?w=1316&h=782

http://www.datastax.com/products/datastax-enterprise-graph
http://techcrunch.com/2016/04/12/datastax-adds-graph-databases-to-enterprise-cassandra-product-set/
http://www.ciokorea.com/print/29328

Posted by '김용환'
,