

Great Architect & Artist
지혜 있는 자는 궁창의 빛과 같이 빛날 것이요 많은 사람을 옳은 데로 돌아오게 한 자는 별과 같이 영원토록 빛나리라 (단 12:3)
Amazon, eBay, Netflix 같은 많은 조직들에서 Microservice Architecture Pattern이라고 알려져 있는 기술을 채택하여 이러한 문제를 해결하고 있다. Microservice Architecture는 하나의 괴물같은 monolithic application을 만드는 대신에, 더 작고 서로 연결되어 있는 서비스들의 집합으로 application을 나누는 것이다.
일반적으로 서비스는 order management(주문관리), customer management(고객관리), 등과 같은 별개의 특징이나 기능 집합으로 구현되어 있다. 각각의 microservice는 그 자체에 다양한 어댑터에 대한 비즈니스 로직을 가진 6각형의 아키텍처를 가지는 mini-application이다. 어떤 microservice는 다른 microservice나 application client에 의해서 호출되는 API를 제공하고, 다른 microservice는 Wen UI를 구현할 수도 있다.
런타임시에는 각각의 instance는 클라우드 VM이나 Docker container 상에 실행되기도 한다.
예를 들면, 앞서 기술된 시스템을 분해하면, 다음과 같은 다이어그램으로 표현할 수 있다.
Application의 개별 기능은 각각의 microservice로 구현되어 있다. 더욱이 web application은 더 간단한 web application의 집합으로 나누어져 있다. (택시 호출 서비스 예제에서 보면, 한 명의 운전 기사가 한 명의 승객과 매칭되는 경우). 이것은 특정 user, device, 혹은 특별한 use case별로 개별 경험을 더 쉽게 배포하게 한다.
각 backend service는 REST API를 제공하고, 대부분의 service들은 다른 service가 제공하는 API를 사용한다. 예를 들어, Driver Management(기사 관리)는 잠재적 이동에 대해 활동 가능한 운전 기사에게 알려주는데 Notification Server를 사용한다. UI service들은 web page들을 렌더링하기 위해 다른 서비스들을 호출한다. 서비스들은 메시지 기반의 communication에 async방식을 사용한다. 서비스간의 communication에 대해서는 추가로 나중에 자세히 다룰 것이다.
몇몇 REST API는 기사나 승객에 의해 사용되는 mobile app에서 이용한다. 그러나 이러한 app들은 backend service이 직접 접속할 수 없다. 대신에 communication은 API Gateway로 알려진 중재자를 통해 가능하게 된다. API Gateway는 로드밸런싱, caching, access control, API metering, monitoring과 같은 부분들을 처리해야 한다. 이러한 부분들은 nignx를 사용하여 효과적으로 구현할 수 있다.
Microservice architecture pattern은 scalability(확장성) 3D Model에 대한 최고의 책인 "The Art of Scalability"에 나오는 Scale Cube의 Y축 Scaling에 대응된다. 다른 2개의 Scaling 축은 load balancer 뒤에서 실행중인 여러 개의 동일한 application 복사본으로 구성된 X축 Scaling과 요청의 속성(예를 들면, row의 primary key나 고객의 identity)이 특정 서버에 대한 요청으로 route하는데 사용되는 Z축 Scaling(혹은 data partitioning)이 있다.
Application들은 일반적으로 3가지 Scaling 타입을 함께 사용한다. Y축 Scaling은 이 섹션 첫번째 그림에서 보여주는 대로 application을 microservice로 분해한다. Runtime 시점에 X축 Scaling은 load balancer 뒤에서 처리량과 가용성을 위해 각 서비스에 대해 여러 개의 instance를 실행한다. 어떤 application들은 service를 partition하기 위해 Z축 Scaling을 사용하기도 한다.
다음 다이어그램은 Trip Management 서비스가 Amazon EC2 서버 상에 Docker로 어떻게 배포되는지를 보여준다.
Runtime시에 Trip Management 서비스는 여러 개의 instance로 구성되어 있다. 각 서비스 instance는 Docker container로 제공된다. 가용성을 높이기 위해서 docker container들은 여러 개의 cloud VM에서 돌아간다. Service instance 앞단에는 여러 instance로 요청을 분산하는 nginx와 같은 load balancer가 있다. Load balancer는 caching, access control, API metering, monitoring과 같은 여러 가지 관심 사항들을 취급할 수 있어야 한다.
Microservice Architecture Pattern은 특히 application과 database 사이의 관계에 중요한 영향을 준다. 서로 다른 service간 하나의 database schema를 공유하는 것보다는 각각의 서비스가 독자적인 database schema를 갖는다. 다른 한편으로 이러한 접근은 Enterprise-Data Model 관점에서는 이상하다. 또한, 어떤 데이터들은 종종 중복되기도 한다. 그러나 서비스별 database schema를 갖는 것은 microservice를 통해 혜택을 보기 원한다면, 본질적인 부분이다. 왜냐하면, microservice는 느슨한 연결(loose coupling)을 보장하기 때문이다. 다음 다이어그램은 예제로 제시된 application에 대한 database architecture를 보여주고 있다.
각각의 서비스는 자체적으로 데이터베이스를 가지고 있다. 게다가, 서비스별로 소위 polyglot
persistence architecture(상황에 맞게 최적화된 구조로 데이터를 구분하여 저장하는 아키텍처)라고 불리는 가장 최적의 데이터베이스 타입을 사용할 수 있다.
예를 들어, 잠재적인 승객에게 가장 가까운 운전 기사들을 찾아야 하는 Driver Management(기사 관리)는 geo-query(지리기반 질의)를 지원하는 데이터베이스를 사용해야만 한다. 표면적으로는 MSA는 SOA와 유사하다. 두가지 모두 서비스들의 집합으로 구성된 아키텍처이다. 하지만, MSA는 WS 표준과 ESB가 없는 SOA라고 생각하면 된다.
Microservice 기반 application은 WS 표준보다 굉장히 단순하고, REST와 같은 가벼운 프로토콜을 사용한다. 또한 ESB 사용을 지양하고, microservice 자체적으로 ESB 유사한 기능을 구현한다. Microservice Architecture Pattern은 정규 스키마(canonical schema)와 같은 SOA의 다른 부분도 거부한다.
그동안 서로간의 변형을 통해서 어떻게 RDD를 생성하는지를 알아보았다. 하지만, 어떤 경우에는 Dataset을 가지고 직접적으로 어떤 일을 하고 싶을 수도 있다. Action은 RDD operation의 두 번째 형태이다. Action은 driver program에 마지막 값을 되돌려 주거나 외부 storage system에 데이터를 쓰는 작업을 수행한다. Action은 RDD를 호출하는 곳에서 필요로 하는 변형에 대해서 평가하기 때문에 실제적인 ouput을 만들어낼 필요가 있다.
앞의 섹션의 log example에서 계속해서 살펴보자면 badLinesRDD에 대해 어떤 정보를 출력하고 싶을 수도 있다. 그렇게 하기 위해서는 2가지 action을 사용할 수 있다. count()는 숫자를 센 값을 리턴하고, take()는 RDD의 element collection을 리턴한다. 샘플코드는 3-15, 3-17에서 볼 수 있다.
Example 3-15. Python error count using actions
print "Input had " + badLinesRDD.count() + " concerning lines"
print "Here are 10 examples: "
for line in badLinesRDD.take(10):
print line
Example 3-16. Scala rror count using actions
println("Input had " + badLinesRDD.count() + " concerning lines")
println("Here are 10 examples:")
badLinesRDD.take(10).foreach(println)
Example 3-17. Java error count using actions
System.out.println("Input had " + badLinesRDD.count() + " concerning lines")
System.out.println("Here are 10 examples:")
for (String line : badLinesRDD.take(10)) {
System.out.println(line);
}
위의 예제에서, driver program에서 작은 숫자의 RDD element를 추출하기 위해서 take()를 사용했다. Driver에 정보를 출력하기 위해서 반복하여 출력했다. RDD는 전체 RDD를 추출하기 위해서 collect() 함수를 가지고 있다. 만약 프로그램 필터에서 RDD를 아주 작은 크기로 줄여서 내부적으로 다루고자 하는 경우에 유용하게 사용할 수 있다. 다만, 전체 dataset은 collect()를 사용하여 하나의 machine의 메모리 크기에 적합해야 한다는 것을 유념해야 한다. 따라서 collect()는 large dataset을 대상으로는 사용하지 않아야 한다.
대부분의 경우, RDD는 driver에 직접적으로 collect()함수를 사용하여 데이터를 추출할 수 없다. 왜냐하면 dataset이 너무 크기 때문이다. 이러한 경우에는 HDFS나 Amazon S3와 같은 분산 저장환경에 데이터를 쓰는 경우가 일반적이다. 또한 saveAsTextFile() action, saveAsSequenceFile()이나 다양한 내장된 형태로 다른 많은 action을 사용하여 RDD의 내용을 저장할 수 있다. 데이터를 추출하는 다른 option에 대해서는 Chapter 5에서 다룰 것이다.
새로운 action을 매번 호출할 때마다 전체 RDD가 "맨 처음부터"(from scratch) 계산되어야 한다는 것을 아는 것이 중요하다. 이러한 비효율성을 피하기 위해서 44페이지에서 "Persistence (Caching)"으로 다루는 중간 결과를 유지할 수 있다.
Introduction to Lucene's API : 다른 Lucene Pakcages들의 high-level summary
Materials
Apache Lucene은 고성능의 full-featured text search engine library이다. 여기 indexing을 하고 searching을 하는데 Lucene을 어떻게 사용하는지 예제가 있다. (기대한 결과를 check하기 위해 JUnit을 이용한다.)
Lucene API는 몇가지 package로 구분된다.
Lucene을 사용하기 위해서, Application은 다음과 같이 해야 한다.
Fields를 추가하기 위해서는 Document를 생성해야 한다.
IndexWriter를 생성하고 addDocument()를 통해서 document를 추가해야 한다.
String으로부터 Query를 생성하기 위해서는 QueryParser.parse()를 호출해야 한다.
IndexSearcher를 생성하고 search() method에 query를 전달해야 한다.
간단한 code example은 다음과 같다.
IndexFiles.java : directory에 있는 모든 파일들에 대해서 index를 생성한다.
SearchFiles.java : query를 입력하고, index를 검색한다.
이것을 설명하기 위해서 다음과 같이 실행해 보라.
Lucene은 Java 기반 Full-text search engine이다.
Lucene은 완전한 application이 아니라, 검색 기능을 제공하고자 하는 Application에 쉽게 사용할 수 있는 code library이고 API를 제공한다.
Apache Lucene 5.2.1에 대한 official documentation에 대해서 정리해 보고자 한다. 추가적인 문서는 Wiki(http://wiki.apache.org/lucene-java)에서 살펴볼 수 있다.
다음 섹션은 getting started guide를 제공하고자 하는 목적으로 작성되었다.
다음 3가지 유형의 사용자를 대상으로 한다.
1) Application에 Apache Lucene을 처음 설치하고자 하는 사용자
2) Lucene 기반 Application을 개발하거나 수정하고자 하는 개발자
3) Lucene 개발에 참여하거나 기여하고자 하는 개발자
Lucene에 대한 깊은 개념이나 상세한 내용을 다루지는 않는다.
Lucene demo, its usage, and sources : Command-line Lucene demo에 대한 tutorial.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/754