모노리식이든 마이크로 서비스이든 요구사항에 따라 계속 아키텍처 변화는 필요하다.


빅 데이터를 다루는 모노리식 아키텍처(SNS, Talk)에서는 요구에 따른 Nosql로 인한 아키텍처 변화가 상당히 크다..


상황에 따라 DB의 일부를 cassandra 또는 Hbase로 사용하기도 하고. redis 대신 memcached를 적절히 사용해야 하는 이슈들이 늘 산재되어 있다. 


migration 및 아키텍처 변화에 가장 큰 힘은 테스트 코드이다.




반면, 레거시 시스템 또는 마이크로 서비스에서는 점진적으로 서비스 아키텍처로 코드를 분리해 나가는 디자인 패턴을 strangler 패턴이라 한다. 


분위기 상 마이크로 서비스에서 얘기하는 내용으로서 마틴 파울러가 내용을 쓰면서 유명해 졌다..


https://www.martinfowler.com/bliki/StranglerApplication.html



(덧 붙이자면.. 이미 우리의 많은 선배들은 리팩토링, 구조 개선이라는 이름으로 진행해왔었다..


strangler 패턴은 마이크로 서비스의 신조어 단어이다.)


Posted by 김용환 '김용환'

댓글을 달아 주세요

http://isa-principles.org 독립적 시스템 아키텍처에 대한 설명이 있어서 번역해둔다. 




1. 시스템은 인터페이스(interface)를 제공하는 모듈(module)로 분할되야 한다. 해당 인터페이스를 통해서만 모듈에 접근할 수 있어야 한다. 따라서 모듈은 데이터베이스의 데이터 모델과 같은 다른 모듈의 구현 세부 사항에 직접 의존하지 않을 수도 있다.



2. 모듈은 독립성을 최대화하기 위해 별도의 프로세스, 컨테이너 또는 가상 시스템이 되야 한다.



3. 시스템은 두 가지 명확하게 분리된 레벨의 아키텍처를 결정해야 한다.


 - 매크로(macro) 아키텍처는 모든 모듈에 관련된 결정으로 구성된다. 추가될 모든 원칙은 매크로 아키텍처의 일부이다.


- 마이크로(micro) 아키텍처는 개별 모듈마다 다르게 정해질 수 있는 결정을 포함한다.



4. 통합(integration)을 선택하는 것은 제한되야 하고 시스템에서 표준화되야 한다. 통합은 동기식 및 비동기식 통신 또는 프론트 엔드에서 수행될 수 있다.



5. 통신은 REST 또는 메시징과 같은 작은 수의 프로토콜로 제한되야 한다. 인증과 같은 메타 데이터도 표준화되야 한다.




6. 각 모듈마다 지속적인 배포 파이프 라인이 존재해야 한다. 테스트는 모듈의 테스트가 독립적이야 하므로 지속적인 배포 파이프 라인의 일부이다.




7. 운영은 표준화되야 한다. 운영에는 설정, 배포, 로그 분석, 추적, 모니터링, 경보가 포함된다. 모듈에 매우 상세한 요구 사항이 있을 때는 표준에서 예외로 처리할 수 있다.




8. 운영, 통합, 통신 표준은 인터페이스 레벨에서 정의되야 한다. 예를 들어 프로토콜은 REST로 표준화될 수 있고 데이터 구조도 표준화될 수 있다. 그러나 각 모듈에서 다른 REST 라이브러리를 자유롭게 사용하는 것을 추천한다.




9. 모듈은 복원력이 있어야 한다. 다른 모듈을 사용할 수 없거나 통신 문제가 발생하면 오류가 발생하지 않을 것이다. 그들은 데이터나 상태를 잃지 않고 종료할 수 있어야 한다. 모듈을 실패하지 않고도 다른 환경(서버, 네트워크, 설정 등)으로 이동할 수 있어야 한다.





원문은 다음과 같다. 


  1. The system must be divided into modules that provide interfaces. Access to other modules is only possible through these interfaces. Therefore modules must not directly depend on implementation details of other modules, e.g. the internal data representation in a database. The rest of the principles define how modules might be implemented, and how ISA differs from other modularization approaches.

  2. Modules must be implemented as separate processes, containers, or virtual machines to maximize independence.

  3. The system must have two clearly separated levels of architectural decisions:
    • The Macro Architecture comprises decisions that cover all modules. All further principles are part of the Macro Architecture.
    • The Micro Architecture considers decisions which may be taken individually for each module.
  4. The choice of integration options must be limited and standardized for the system. The integration might be done with synchronous or asynchronous communication, and/or on the UI level.

  5. Communication must use a limited set of protocols like RESTful HTTP or messaging. Also metadata, e.g. for authorization, must be standardized. It might make sense to use just one protocol for each integration option.

  6. Each module must have its own independent Continuous Delivery pipeline. Tests are part of the Continuous Delivery pipeline so the modules must be tested independently.

  7. Operations should be standardized. This includes configuration, deployment, log analysis, tracing, monitoring, and alerting. There might be exceptions from the standard if a module has very specific requirements.

  8. Standards for operations, integration, or communication should be enforced on the interface level. For example, the communication protocol and data structures could be standardized to a specific JSON payload format exchanged using HTTP, but every module should be free to use a different REST library/implementation.

  9. Modules must be resilient. They must compensate unavailable modules or communication problems. They must be able to cope with unexpected shutdowns without losing data or state. It must be possible to move them to other runtime environments (hosts, networks, config etc).



첫 번째 ISA 원칙은 시스템이 모듈을 기반으로 개발되야 한다고 말한다. 이는 일반적인 내용이다.

두 번째 원칙은 매크로 아키텍처와 마이크로 아키텍처의 두 개의 아키텍처 레벨을 정의한다.

배포 모노리스에서 대부분의 결정은 매크로 아키텍처 레벨에서 이루어진다. 예를 들어 배포 모노리스에서는 하나의 프로그래밍 언어로 작성되기에 프로그래밍 언어는 매크로 아키텍처 레벨에 대한 결정이어야 한다. 프레임워크와 대부분의 다른 기술에서도 마찬가지이다. 실제로 마이크로 아키텍처에서 더 많은 결정을 내리기 위해 의미 있는 기회를 결정하려면 각 모듈은 원칙적으로 세 번째 원칙 상태를 기반으로 별도의 컨테이너에 구현되야 한다.

따라서 ISA에서는 마이크로 서비스가 컨테이너에서 동작하는 이유는 배포 모노리스에서 달성할 수 없는 기술적 자유이다. 따라서 마이크로 서비스는 아키텍처에 독립성과 낮은 결합도를 제공한다. 각 마이크로 서비스가 WAR이고 특정 애플리케이션 서버에서 함께 실행되는 접근 방식은 이 원칙에 맞지 않는다. 사실 자유로운 기술 선택과 견고성에 관한 절충안을 찾기가 매우 높기 때문에 실제로 해당 접근 방식은 일반적으로 별로 의미가 없다. 낮은 결합도가 중요하기 때문에 ISA와 마이크로 서비스는 실제로 모듈화에 근본적인 개선을 제공한다.

ISA의 목표는 최소한의 매크로 아키텍처를 결정하는 것이지만 어떤 결정은 여전히 매크로 수준에서 이루어져야 한다. 이는 나머지 원칙들을 설명하는 것이기 때문이다. 시작할 때 네 번째 원칙은 통합과 통신 방식을 표준화해야 한다고 명시한다.

통합과 통신에 특정 기술에 사용하기로 결정한다면 모든 모듈에 영향을 미치기에 매크로 아키텍처 레벨에서 수행해야 한다. 따라서 마이크로 서비스 시스템에서 매우 중요한 결정이다. 일반적인 통합 접근 방식과 통신 기술이 없는 시스템에 대해 시스템이라 말하기 어렵고 실제로 서로 통신할 수 없는 일부 서비스만 고려해야 한다.

다섯번째 원칙은 추적과 인증을 위한 메타 데이터가 표준화되야 한다고 명시한다. 해당 메타 데이터는 마이크로 서비스 간에 전송되야 하므로 매크로 아키텍처의 일부여야 한다.

여섯번째 원칙(독립 배포 파이프 라인)은 독립 배포 개념이 있다.

일곱번째 원칙은 마이크로 서비스의 운영이 표준화되야 한다고 말한다. 모든 운영 작업을 표준화 해야 한다는 의미가 아니다. 별도의 운영 부서에서 다수의 마이크로 서비스를 처리하는 유일한 방법은 표준화이다. 그러나 "우리가 따로 빌드하고 운영한다"라는 신념을 가진 조직이라면 마이크로 서비스 운영에 대한 표준은 필요치 않다.

실제로 표준화된 운영 방식은 모든 마이크로 서비스에 적합하지 않을 수 있다. 이 경우 팀은 자체 운영 기술을 제안해야 한다. 표준은 거의 의미가 없다.

여덟번째 원칙은 표준이 인터페이스 레벨에서만 정의되어야 한다고 명시한다. 일반적으로 사용되는 모든 프로그래밍 언어에서는 인터페이스와 클라이언트 라이브러리를 제공한다.

아홉번째 원칙은 탄력성을 설명한다.

Posted by 김용환 '김용환'

댓글을 달아 주세요





netflix는 로그 분석을 위해 druid와 elasticsearch를 활용한다. 



http://www.slideshare.net/g9yuayon/elasticsearch-in-netflix 

http://www.slideshare.net/deview/213-event-processingtalkdeviewkoreakey

Netflix 발표 자료에 Elasticsearch 내용이 아주 쪼~~금 설명되어 있다. 

더 설명해주었으면 좋았을 뻔.



129 페이지 


Favor Index Rolling Over TTL 

A dedicated service manages index rolling
 

Uses index template and routing


정확하지는 않지만, 이런 뜻으로 여기진다. 

Elasticsearch가 indexing의 압박이 좀 많아서, indexing하니라 너무 오래 걸리면 search가 영향을 받을 수 있으니.

alias(http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.htmlhttp://www.elasticsearch.org/blog/aliases-ftw/)를 주어 유연성있게 여러 index를 만들어 썼을 것이라는 추측을 해본다.



131 페이지


Worth Trying G1

 Not recommended by ES team, 

but
 Has fewer and shorter GC pauses
 

Occasional SIGSEGV, but it’s okay


삭제가 많고 상대히 트래픽이 많은 부분에 Elasticsearch를 써보고 있는 상태에서 GC를 테스트해보았다.

Elasticsearch의 Data Node에 G1을 써보니. GC 시간이 확실히 좋아졌다. 최신 jdk 8 에 설치해서 customize한 CMS(디폴트 CMS)에 비해서는 확실히 cpu가 15~20% 이상 증가되었다. GC 시간이 중요한 포인트라면 쓰는 것도 좋을 것 같다. 




Posted by 김용환 '김용환'

댓글을 달아 주세요




Operating System

For the operating system, we use FreeBSD version 10. This was selected for its balance of stability and features, a strong development community and staff expertise. All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers. The result has been a positive open source ecosystem that lowers our development costs and multiplies the effectiveness of our efforts..

Web Server

We use the Nginx web server for its proven scalability and performance. The audio and video components that comprise each Netflix streaming title are served directly to the customer client software via HTTP.

Routing Intelligence Proxy

We use the BIRD Internet routing daemon to enable the transfer of network topology from ISP networks to the Netflix control system that directs clients to sources of content.



참고 자료

https://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.pdf

https://openconnect.itp.netflix.com/

https://openconnect.itp.netflix.com/software/index.html

http://bird.network.cz/

Posted by 김용환 '김용환'

댓글을 달아 주세요



정보통신산업진흥원(NIPA) 산하 소프트웨어 공학센터 에 "실용적인 소프트웨어 아키텍처 리뷰"를 작성했다. 사실은 직접 겪은 디테일한 내용을 적고 싶었다. 그러나 리뷰라는 것이 실수를 올바르게 고쳐주지만, 실수를 하는 사람입장에서는 공격으로 올 수 있는 부분들이 많아. 차마 많은 내용을 넣지는 못했다. 그러나 내용의 진의만큼은 독자들이 좋게 봐주리라 생각된다.


(나중에 세미나에서 발표하게 되면 실 사례를 꼭 얘기할 수 있을 것 같다.)



http://www.software.kr/mbs/swkr/jsp/board/view.jsp?spage=1&boardId=183&boardSeq=2585049&mcategoryId=&id=swkr_040500000000


94호_공학_트렌드_품질고도화를_위한_실용적인_소프트웨ᄋ



다음편은 여기로..

http://knight76.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EA%B3%B5%ED%95%99%EC%84%BC%ED%84%B0-%EA%B8%B0%EA%B3%A0-%ED%92%88%EC%A7%88%EA%B3%A0%EB%8F%84%ED%99%94%EB%A5%BC-%EC%9C%84%ED%95%9C-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%A6%AC%EB%B7%B0-2



Posted by 김용환 '김용환'

댓글을 달아 주세요



원문
http://likelink.co.kr/28971

한국어 번역 
http://yisangwook.tumblr.com/post/82871139092/dropbox-carousel-fast-sqlite-cache




The big lesson we learned from building the Dropbox app photos tab was: don’t block the user! Instead of requiring changes to be propagated to the server synchronously, we built Carousel from day one as an eventually consistent system. With mobile networks still slow and unreliable, we knew this would be the only way to deliver a Dropbox-backed gallery that felt fast and local.

The asynchronous, delta-based design to our mobile library empowered us to build an app that was much faster than the Dropbox photos tab. This design enabled us to hide the latency between client and server from the user. In the next installation of this series, we’ll go into more depth on the latency between disk and memory, and how optimizing that was also critical to making the app feel fast.


Posted by 김용환 '김용환'

댓글을 달아 주세요



http://www.oss.kr/oss_repository10/517682


MariaDB/Mysql 을 잘 사용하고 있는 사례. 

현재 카카오톡은 아래 아키텍처로 구성 중. (역시 이성욱님이라면... 가능할 것 같다. MariaDB 관련 새책이 나왔음. )




Posted by 김용환 '김용환'

댓글을 달아 주세요

Posted by 김용환 '김용환'

댓글을 달아 주세요


 

UI 쪽의 응답시간을 최적화함으로서 사용자들에게 조금이나마 기다리지 않도록 노력하는 시도가 많이 있습니다.

웹사이트 최적화 기법 (http://www.yes24.com/24/goods/2961377?scode=032&srank=2 ) 이런 책이 나와서 사실.. 더욱 더 부채질하게 되었습니다.

 

튜닝 요소는 다음과 같습니다. (1~5번은 일반적인 내용, 6번은 제가 생각하는 내용)

 

1. Cache Control 이용 - FileETag 등등.

2. CSS Sprite 활용 

3. js, stylesheet 를 합치기 <- 회사 script framework 쓰면 됨.

  js의 위치에 따라서 튜닝요소가 많긴 합니다.

4. 이미지 캐쉬 서버는 하나로 통일 (dns 서버 최대한 안찾게.)

5. deflate 활용  (gzip 다운로드)

6. mpm 설정 튜닝 - prefork.  등등

 

(최대한 파일은 적게, dns도 적게 하면 성능효과가 많이 납니다.)

  

관심있으신 분은 http://blog.pages.kr/254 보시고 참조하시면 좋을 것 같습니다.^^ 사진도 많고, 슥 보기에는 좋은 것 같네요. 윈도우 서버라 그런지 더더욱 좋네요.

 

Posted by 김용환 '김용환'

댓글을 달아 주세요



2010년 3월에 동경에 가서 Java Monitoring에 대해서 발표했다..
한국에서는 그리 중요하게 여기지 못했던 반면, 이곳은 나를 환영해주었다.. 감격했다..


칭찬같은 것은 잘 적지 않는 편이지만, 그냥 기록을 위해서 담담히 적어본다.


PPT도 이야기의 전개도 매우 알기 쉬웠습니다.
개발자에게 있어서 좋은 것을 추구하는 진지함이 잘 전해졌습니다.
내용도 「있으면 좋겠다」라고 생각되는 툴의 소개로, 매우 흥미로왔습니다.
자신의 부족한 부분에도 깨달을 수 있고, 매우 가치가 있었습니다.
시스템적인 시선으로 개발을 생각하는 계기가 되었습니다.
설명이 알기 쉽고 좋았다. 듣기 쉬웠다.
감시로 서버 운영이 편해질 것 같다.
PPT도 재미있었고, Monitoring Tool로의 물건도 좋았다고 생각합니다.
여러가지 모니터 정보를 일원 관리하고 있는 것이 대단해.또, 그것을 뛰어난 UI로 제공하고 있는 것이 좋다고 생각했습니다.
좋은 정보(이었)였습니다.
훌륭한 툴(이었)였습니다.
Japan에서도 적용하고 싶을 정도의 좋은 것이었습니다.
모니터의 툴이 대단하네요.감시의 중요성을 느꼈습니다.
모니터링은 UI가 중요하다라고 생각했습니다.
꼭 일본에도•••!
일본측도 적용을•••
Java의 상세를 조사해 있어, 유익한 데이터였다.
Monitoring에 대해서, 개략에서도 이해할 수 있어 좋았다고 생각합니다.
일본에서도 꼭 도입 해 주기를 바랍니다.
언제나 개선하고 싶은, 해 주기를 바라다고 생각한 것에의 정보의 입수를 할 수 있어 좋았다고 생각합니다.
분석등에 활용할 수 있을 것 같다.
툴 설명으로 끝나 버렸다.구체적인 만드는 방법을 알고 싶었다.
평상시 보이기 힘든 곳을 잘 아는 좋은 툴이라고 생각합니다.
툴의 정보 수집 논리를 알고 싶습니다.
일본에서도 도입해 주었으면 한다.
개발자중에서도 모니터링은 매우 중요하기 때문에, 참고가 되었습니다.
역시 시각화(적절히) 되면 상황이 파악하기 쉽다고 생각했다.
백엔드 시스템에 멋진 UI
저런 모니터링을 작성해 주실 수 있으면 확실히 개발에 집중할 수 있게 된다고 생각합니다.
자료가 많아, 어디를 보면 좋은가 이해하기 어려웠다.
매우 편리 할것 같다
빨리 일본에 도입해 주세요!

Posted by 김용환 '김용환'
TAG 발표, 일본

댓글을 달아 주세요