Intelligent Caching and Packaging in an ABR Multi-format CDN

2012년에 나왔던 자료인거 같은데… 이전에 작성한 “Netflix, 그들의 콘텐츠 서비스 방식(Netflix and Fill)” 과 연관이 있어 보인다.

VOD를 처음 시작할때는 Caching이 필요하지 않았다. VOD가 초기 단계에 있었을 때 하나의 중앙 서버가 전체 노드를 지원했었고 콘텐츠는 SD 포맷으로만 제공 되었다. 한곳에서 콘텐츠를 관리했기에 Caching이 필요하지 않았다.

VOD가 많아짐에 따라 Caching이 필요하게 되었다. LRU는 지능형 Caching으로 진화했다.

Caching은 미래 행위를 예측하기 위해 과거 행위를 이용하려는 예측 활동이다. Caching은 삭제해야 할 콘텐츠를 결정하는 것이 중요하다. LRU는 사용 패턴에 관계없이 가장 오래동안 사용하지 않은 콘텐츠를 제거한다. Intelligent Caching은 전체 시청 시간을 기반으로 추가 조회 가능성에 대한 통계적 추론 기법을 가미한다.

이 장표를 소개할 시점의 CDN Caching 알고리즘의 주류는 LRU

예측 가능성을 향상 시키기 위해서는 동일한 콘텐츠에 대한 모든 스트림 요청이 동일한 edge streamer로 전달되어야 하며, Cluster Manager를 사용하여 콘텐츠 요청 경로를 지정해야 한다. Netflix의 경우 Control Plain으로 보면 될듯

동일한 Cache에서 같은 콘텐츠를 스트리밍하면 count가 증가하고 네트워크 사용률이 감소한다. 이렇게 되려면 Cluster Manager가 Edge를 Referring 해야 한다.

LRU caching은 콘텐츠 및 콘텐츠 위치, usage에 대한 정보가 없다. 즉, 가장 최근에 사용된 콘텐츠를 결정하고 나머지는 제거한다.

Intelligent caching은 Edge에 콘텐츠를 잘 갖다 놓고 여러 매개 변수를 사용하여 Edge에 저장된 Chunk의 실제 가치를 평가하기에 보다 효율적으로 동작한다.

Caching은 패키징 옵션의 영향을 받는다는 의미인데, 어떤 방식으로 패키징하고 Origin에 어떤 모양으로 담겨 있는지에 따라 Caching에 영향을 준다는 의미인듯…

Source: https://www.slideshare.net/briantarbox/2012-ncta-motorolaintelligent-caching-and-packaging-in-an-abr-multiformat-cdn-tarboxfinal

Read More

Netflix, 그들의 콘텐츠 서비스 방식 (Netflix and Fill)

본 글은 넷플릭스의 Tech블로그의 내용과 개인적인 의견을 포함하여 작성했습니다. (참조: https://medium.com/netflix-techblog/netflix-and-fill-c43a32b490c0)

새로운 콘텐츠가 출시 되면 CP(Content Provider)로부터 넷플릭스내의 콘텐츠 운영팀으로 Digital Asset이 전달 됩니다.

이 과정에서 Netflix Platform에 통합하기 위해 필수적인 품질관리, 인코딩등 다양한 유형의 처리 및 개선이 이루어집니다. 이 단계가 끝나면 관련 Digital Asset (Bitrate, Caption)이 다시 패키징되어 Amazon S3에 배포 됩니다.

배포 준비가 된 S3의 콘텐츠는 콘텐츠 운영팀에 의해 metadata flag가 지정되며, 이 시점에서 Open Connect 시스템이 인계받아 OCA(Open Connect Appliance)에 콘텐츠를 배포하기 시작합니다.

Proactive Caching

Netflix의 Open Connect와 다른 CDN과의 가장 큰 차이점은 Proactive Caching입니다. 사용자들이 시청할 시간과 시청 시간을 높은 정확성으로 예측할 수 있기 때문에 구성 가능한 시간대 동안 non-peak bandwidth를 사용하여 예측한 콘텐츠를 OCA에 다운로드 할 수 있습니다. 다른 CDN은 이것이 불가능하고 범용적인 Delivery Service를 제공해야 하므로, LRU기반의 Caching을 선호하지요. CDN 사업자가 콘텐츠를 예측할 필요는 없으니까요. 그들은 미디어 사업자가 아니니까요.

OCA Clusters

Netflix의 Fill pattern이 어떻게 동작하는지 이해하려면 OCA가 IX에 위치하거나 ISP 네트워크에 포함되어 있는지 여부에 상관없이 OCA 클러스터를 구성하는 방법을 이해해야 합니다.

OCA는 manifest cluster로 그룹화 됩니다. 각 manifest 클러스터는 적절한 콘텐츠 영역(콘텐츠를 스트리밍 할 것으로 예상되는 국가 그룹), 인기도 피드(이전 데이터를 기준으로 간략하게 정렬된 콘텐츠 목록)로 구성되고 보유해야 하는 콘텐츠의 수를 표시합니다. Netflix는 국가, 지역 또는 기타 선정 기준에 따라 독립적으로 인기 순위를 계산합니다.

Fill cluster는 shared content영역과 인기 피드가 있는 manifest cluster의 그룹입니다. 각각의 fill cluster는 Open Connect 운영팀에 의해 fill escalation policies와 fill master의 수로 구성됩니다.

아래의 다이어그램은 동일한 Fill cluster내의 manifest cluster의 예를 설명합니다.

Fill Source Manifests

OCA들은 네트워크내의 다른 OCA에 대한 정보, 콘텐츠, 인기도등을 저장하지 않습니다. 모든 정보는 AWS Control Plain에 집계되고 저장 됩니다. OCA는 주기적으로 Control Plain과 통신하여 Cluster 멤버들에게 storing하고 serving해야 할 콘텐츠 목록이 포함된 manifest 파일을 요청합니다. AWS Control Plain은 여러 고수준 요소를 고려하여 ranked list를 다운로드 할 수 있는 location을 response합니다.

• Title(Content) availability — Does the fill source have the requested title(content) stored?
• Fill health — Can the fill source take on additional fill traffic?
• A calculated route cost — Described in the next section. (아래 섹션에서 설명)

Calculating the Least Expensive Fill Source

S3(Origin)에서 모든 OCA에 직접 콘텐츠를 배포하는 것은 시간과 비용면에서 비효율적이므로 계층화된 접근법을 사용 합니다. Open Connect의 목표는 가장 효율적인 경로를 사용하여 콘텐츠를 전달하도록 하는 것입니다.

Least expensive fill source를 계산하기 위하여 각 OCA의 네트워크 상태 및 구성 매개변수를 고려합니다.

• BGP path attributes and physical location (latitude / longitude)
• Fill master (number per fill cluster)
• Fill escalation policies

Fill escalation policies는 다음과 같이 정의합니다.

1. OCA가 콘텐츠를 다운로드 하기 위해 갈 수 있는 hop 수와 대기시간
2. OCA가 정의된 hop 이상으로 전체 Open Connect 네트워크로 이동 할 수 있는지 여부와 대기시간
3. OCA가 S3(Origin)으로 갈 수 있는 여부와 대기시간

Control Plain은 Master로 지정된 OCA를 선택합니다. Master에 적용되는 fill escalation policies는 일반적으로 콘텐츠를 가져와서 non-master와 로컬로 공유하기 위한 지연시간을 줄여 최대한 멀리 도달 할 수 있게 합니다.

경로 계산에 대한 모든 입력이 주어지면, fill source 작업은 다음과 같이 작동합니다.

1. Peer fill — Available OCAs within the same manifest cluster or the same subnet
2. Tier fill — Available OCAs outside the manifest cluster configuration
3. Cache fill — Direct download from S3

Example Scenario

Fill master OCA가 S3로 부터 콘텐츠 다운로드를 완료 한 후 Control Plain에 콘텐츠가 저장되었음을 보고 합니다.

그 다음 다른 OCA가 Control Plain과 통신하여 해당 콘텐츠의 fill source 요청을 보내면 Fill master에서 fill option이 제공됩니다.

두 번째 계층의 OCA가 다운로드를 완료하면 상태를 보고하고 다른 OCA는 해당 콘텐츠에 대한 fill source 작업을 수행 합니다. 이 작업은 fill window내에서 계속 반복됩니다.

더 이상 필요없는 콘텐츠는 delete manifest에 저장되고 일정 기간 후에 삭제됩니다.

Netflix 사용자가 스트리밍을 시작하면 이 시간대의 fill source 작업이 끝나고, fill window가 다른 시간대로 이동하면서 fill source pattern이 계속 진행 됩니다. (Netflix는 글로벌 서비스이기에 각 지역별로 네트워크 유휴 시간대가 다름)

Challenges

Netflix는 항상 fill process를 개선하고 있습니다. Open Connect 운영팀에서는 내부 툴을 사용하여 Fill traffic을 지속적으로 모니터링합니다. member들에게 서비스를 제공해야하는 catalog의 임계값 비율을 포함하지 않는 OCA에 대한 alert이 설정되고 모니터링 됩니다. 이 경우에는 다음 Fill process 전에 해당 문제를 해결합니다. 신속하게 배포해야 하는 새로운 콘텐츠나 기타 수정 사항에 대해 주기적으로 fast-track fill을 수행 할 수 있습니다. 기본적으로 이러한 fill pattern을 사용하면서 배포 시간 및 프로세싱 시간을 줄입니다.

Netflix는 190개국에서 운영되고 있으며 전 세계 여러 ISP 네트워크에 수천 개의 장비가 내장되어 있기에 ISP에 대한 대역폭 비용을 최소화 하면서 OCA에 최신 콘텐츠를 빨리 얻을 수 있도록 하는데에 집중하고 있습니다.

끝으로

Netflix가 일반적인 Caching(LRU, NRU)방식이 아닌 Proactive caching 방식을 택한 이유는 그들이 가지고 있는 Network를 온전히 서비스를 위해서 사용하기 위함으로 보여진다. NRU, LRU는 Proactive caching에 비해 Miss가 발생할 확률이 존재하기에 이러한 대역폭도 서비스적인 측면에서는 아깝다는 그들의 집착이 보여진다. Netflix는 일반 CDN업체가 아닌 미디어 사업자이기에 가능한 얘기가 아닐까? 결국 그들의 생각은 OCP는 비교적 저렴한 x86기반의 하드웨어를 쓰고 네트워크를 최대한 활용하여 가성비 있는 Open Connect를 운영하고 그 남는 비용으로 콘텐츠를 제작하겠다 아닐까?

관련된 내용은 아래의 링크를 참조

• https://www.youtube.com/watch?v=KtSBbsSwq-g
• https://johannesbergsummit.com/wp-content/uploads/sites/6/2014/11/Monday_8_David-Fullagar.pdf

Read More

NGINX based vod packager 소개

 

일반적으로 NGINX Level에서는 HLS,DASH Streaming을 지원해준다. 이 부분은 굳이 NGINX가 아니더라도 Tomcat container와 같은 Application Server에서는 일반적으로 지원해주고 있다. (HTTP requst range 기반으로 작동되므로…)

하지만, Media Streaming을 위해서는 기본적인 Streamer 기능 외에 필요한 부분들이 있다. NGINX의 경우에는 이런 부분들을 3rd party 개발자분들이 module을 제작하여 Github를 통해 공개하고 있다.

NGINX에서 가장 유명한 VOD module은 nginx-rtmp-module이지만, 본 글에서는 nginx-vod-module에 대해서 다루고자 한다.

Features

• On-the-fly repackaging of MP4 files to DASH, HDS, HLS, MSS
• Working modes:
• Local: serve locally accessible files (local disk/NFS mounted)
• Remote: serve files accessible via HTTP using range requests
• Mapped: serve files according to a specification encoded in JSON format. The JSON can pulled from a remote server, or read from a local file
• Adaptive bitrate support
• Playlist support — mapped mode only
• Simulated live support (generating live stream from MP4 files) — mapped mode only
• Fallback support for file not found in local/mapped modes (useful in multi-datacenter environments)
• Video codecs: H264, H265 (DASH/HLS), VP9 (DASH)
• Audio codecs: AAC, MP3 (HLS/HDS/MSS), AC-3 (DASH/HLS), E-AC-3 (DASH/HLS), OPUS (DASH)
• Playback rate change — 0.5x up to 2x (requires libelcodec and libavfilter)
• Support for variable segment lengths — enabling the player to select the optimal bitrate fast, without the overhead of short segments for the whole duration of the video
• Clipping of MP4 files for progressive download playback
• Thumbnail capture (requires libavcodec)
• Decryption of CENC-encrypted MP4 files (it is possible to create such files with MP4Box)
• DASH: common encryption (CENC) support
• MSS: PlayReady encryption support
• HLS: Generation of I-frames playlist (EXT-X-I-FRAMES-ONLY)
• HLS: support for AES-128 / SAMPLE-AES encryption

생각외로 많은 기능을 제공해주고 있다. 물론 제약도 존재한다.

Limitations

• Track selection and playback rate change are not spported in progressive download
• I-frames playlist generation is not supported when encryption is enabled
• Tested on Linux only

Read More

HashiCorp사의 Consul, Consul Template 소개

HashiCorp에서 제공하는 Consul은 Service Discovery, Failure Detection, Multi Datacenter, KV Storage 기능을 제공합니다. HAproxy 혹은 Nginx와 같은 Software 기반의 Load Balancer를 Cloud 상에 구축한다고 가정해보면, 고려해야 할 사항은 아래와 같습니다.

• 부하량에 따라 LB가 Scale In/Out이 되어야 한다.
• 로드 밸런싱 대상이 되는 Backend 서비스가 Scale In/Out이 되면 LB의 Configuration이 실시간으로 변경되어야 하며, 각 LB에게 동기화가 되어야 한다.
• LB의 Health check가 수행되어야 한다.

이 정도로만 간추려봐도 LB하나를 도입하기 위해 해야할 일이 많아지게 됩니다. 분산 환경에서의 이러한 일을 처리하기 위해 예전에는 Apache Zookeeper를 이용하여 개발을 했었지만 이번에는 Consul을 이용해보기로 했습니다.

Apache Zookeeper와 HashiCorp의 Consul의 차이점은 아래와 같습니다.

Apache Zookeeper

• Written in Java
• Strongly consistent (CP)
• Zab protocol (Paxos like)
• Ensemble of servers
• Quorum needed (majority)
• Dataset must fit in memory

Zookeeper는 현재 많은 곳에서 활용되고 있지만, 몇가지 문제점을 지니고 있습니다.

Zookeeper : Problems

• Latency-dependent
• No multi datacenters support (very slow write)
• Client number limit (out of sockets)
• Designed to store data on the order of KB in size
• Possibly lost changes while reenabling watch
• TCP connection != service healthy (proxy)
• Change zk server is a problem

이러한 문제점들을 보완해서 나온 제품이 Consul입니다. Consul의 특징을 보시죠.

HashiCorp Consul

• Written in Go
• Service discovery
• Health checking
• Key / Value Store
• Multi datacenter support
• Agent / Server Concept
• Gossip protocol for all the nodes (discovery)
• Consensus protocol (Raft-based) for servers
• 3 consistency modes
• Access Control List (ACL)

Consul에서 제공하는 기능을 HAProxy에 적용을 해봤고 결과는 만족스럽습니다.

HAProxy는 GSLB or DNS RR로 상위 Client에서 접속을 시도하게 되게되고 이 경우 HAProxy를 HA구성(Active-Standby)을 해야 합니다.

HAProxy가 설치된 VM에 consul agent를 등록하고 별도의 config 파일을 만들어 HAProxy에 대해서 Health checking을 수행 합니다. LB 매커니즘이 Round Robin일 경우 HTTP로 health check를 하게되면 LB가 문제가 될 소지가 많기에, 저의 경우에는 별도의 script를 만들어서 health checking을 수행했습니다.

haproxy.cfg 파일을 중앙에서 관리하기 위해 haproxy.cfg.ctmpl 파일을 만들어 consul-template daemon을 구동합니다. haproxy.cfg.ctmpl내에 별도의 key를 만들어 이 정보를 Consul의 K/V store에서 관리 및 변경시 모든 node에 즉시 동기화가 됩니다.

이렇게 함으로써 HAProxy를 도입할때의 고려사항 중 일부가 해소가 되었습니다.

앞으로 남은 부분은 consul-ui에서 확인할 수 있는 alarm 및 기타 정보를 push 형태로 IaaS Management 쪽에 전달하는 부분만 보완하면 될 것 같습니다. consul-ui는 어디까지나 확인 용도이고 IaaS management tool과 Integration이 되어야 하기 때문입니다.

그동안 Zookeeper를 쓰면서 client number limit, TCP connection, store data design 부분에 대해서 고민이 있었는데, consul을 활용하면서 이런 부분이 어느정도 해소가 될 것으로 보여집니다.

관련하여 좋은 Tip이 있으면 같이 공유했으면 합니다.

Read More

외적 동기와 내적 동기

 

내적 동기란, 활동 자체에서 오는 만족과 즐거움 때문에 행동을 수반하는 능동적인 힘을 의미하며 외적 동기란, 활동을 함으로써 받게 되는 칭찬이나 상 때문에 행동을 수반하게 하는 수동적인 힘을 의미합니다.

일반적으로 회사에서는 인센티브(성과급)을 매개체로 직원들이 성과를 내도록 외적 동기를 부여합니다. 하지만, 이 보다 더 중요한 것은 일 그자체에서 오는 내적 동기를 부여하는 것이라고 생각합니다. 자신에게 선택권이 있으며 관련 기술과 지식을 갖추고 목표를 향해 나아가고 있다라는 느낌을 받을 때 열정적으로 일하게 되며, 이것이 내적 동기를 부여하는 것이라고 생각됩니다.

Read More

Best To-Do List 서비스

처음 사회 생활을 시작할 때 부터 업무 향상을 위해 여러 방법을 고민했었고, 그 중에 주로 사용해왔던 방법이 GTD(Getting Things Done) 였다. 얼마전까지 프로젝트내의 task관리 및 협업을 위해 아래에 언급된 서비스를 이용했다.

• Task 관리: Trello, Asana
• Communication: Slack, Glip

Task 관리 서비스들을 이용하면서 내가 느낀 사항들을 정리해보고자 한다. Trello와 Asana의 경우에는 UI가 직관적이다. 특히 Asana는 List 방식과 Beta 이긴 하지만, Trello와 같은 Kanban을 지원하기도 한다. 위 두 서비스를 사용하면서 느낀 부족한 점은

• One level Task 관리: Trello와 Asana는 One level의 Task관리를 지원한다. 물론 하나의 Task내에서 Sub task를 생성할 수 있지만, 직관적으로 한눈에 파악하긴 어려웠다. Sub task까지 포함해서 Two level 이하의 Task 관리는 지원하지 않는다.
• 직관적인 Kanban 이지만…, : Task를 생성할 때, 내가 해야 할 마우스 액션이 너무 귀찮았다. 물론 Asana의 List 방식에서는 큰 문제가 없었지만 Two level 이하는 지원하지 않기에…
• Outliner의 부재 : 위의 두 서비스에서는 Outliner를 지원하지 않는다. 물론 당연한 이야기이다. Task관리는 두 서비스를 이용하면서 Outliner는 Workflowy를 이용하는 방법도 있지만, 점점 관리해야 하는 서비스가 늘어나는 느낌이 들었다.

Outliner 방식을 지원하면서 Task관리를 할 수 있는 서비스가 있을까? 그래서 찾아봤다.

Workflowy

Outlines내에서 Deep level의 depth를 지원한다. 그리고 가장 유명한 서비스이다. 하지만 Document를 분리하여 관리하는 기능 부재로 인해 고려 대상에서 제외하였다.

Checkvist

Outlines내에서 Deep level의 depth를 지원하지만, 세련된 UX/UI가 오히려 나에겐 부담으로 다가왔다. iOS application을 아직 지원하지 않는다.

Dynalist

Outlines내에서 Deep level의 depth 지원 및 Folder/Document 관리 기능, Google Calendar sync 기능등 부족함이 없었다. 다만, iOS application을 현재 개발중이고 Checkbox가 항상 보이는 부분이 UI를 clunky하게 만든다.

Moo.do

Multi-level을 지원하고, Document 관리 기능 (Folder는 미지원, 이 부분이 아쉽다.) Google Calendar sync 기능, Gmail 연동 기능, Google Drive 연동 기능 그리고 iOS application 지원까지… 그리고 Checkbox에 대한 처리가 마음에 든다. 현재로써는 부족함이 없어 보인다. 결론은 Dynalist와 Moo.do 두가지중에 고민중이다. Moo.do가 가장 완벽한 기능을 제공해주고 있긴 하지만, Dynalist가 Trello에 생성한 Roadmap 보드를 보니 발빠르게 지원을 해줄 것 같은 느낌과 Moo.do에 비해 화면에 집중할 수 있는 UI 구성등이 끌린다.

당분간, 계속 고민을 할 것 같다.

Read More

MSA(Microservices Architecture)의 장점과 단점

 

마이크로 서비스는 대규모 소프트웨어 프로젝트를 마이크로 단위의 모듈로 분리하여 loosely-coupled한 구조로 만들고 API를 통해 서로 통신합니다.

지난 몇 년동안 마이크로 서비스에 대해서 많은 이야기가 있었습니다. 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합하며 인기가 높아지고 있습니다.

마이크로 서비스는 대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합 된 모듈로 분해하여 서비스를 제공하는 아키텍처 입니다.

각 개별 모듈은 개별적인 작업을 담당하며 간단하고 보편적으로 엑세스 할 수 있는 API를 통해 다른 모듈과 통신 합니다.

마이크로 서비스는 웹 기반의 복잡한 응용 프로그램을 설계하기 위한 또 다른 아키텍처입니다. 일반적으로 SOA(Service Oriented Architecture)와 비슷하게 바라보는 시각도 존재합니다만 엄연히 다른 아키텍처입니다.

그렇다면 SOA와 같은 기존 아키텍처의 문제점은 무엇일까요?

Java를 사용하여 기존 웹 프로그램을 만든다고 가정합시다. 가장 먼저 해야 할 일은 presentation layer (사용자 인터페이스)를 디자인을 하고 Business logic을 처리하는 Application layer와 구성 요소 간의 느슨한 결합을 가능하게 하는 Integration layer 그리고 마지막으로 데이터에 접근이가능하도록 Persistence layer를 디자인 하고 구현해야 합니다.

어플리케이션을 구동하기 위해 war or ear 패키지를 생성하고 이를 Tomcat or JBoss와 같은 Application server에 배포합니다. 모든 모듈이 war or ear로 패키징 되었기에 우리는 이것을 Monolithic이라고 부릅니다. 다시 말해서 별도의 구현 가능한 구성 요소가 존재해도 모두 하나의 지붕 아래에 패키징되어 있습니다. 아래의 그림을 참조하세요.

Monolithic 아키텍처: challenges

• 어플리케이션이 커질 수록 코드도 방대해지고 로드시에 IDE에 과부하가 걸릴 수 있습니다. 이런 부분은 개발자의 생산성을 저하시키는 요인이 됩니다.
• 하나의 war or ear에 모든 것을 포함하였기에 어플리케이션의 기술 스택을 변경하는 것을 주저하게 됩니다. 예를 들어서 일부 컴포넌트는 JVM내에서 동작하는 Groovy나 Scala와 같은 다른 언어를 사용하여 처리하려고 할 경우 이런 종류의 아키텍처를 사용하면 어떤 side-effect가 발생 할지 예측이 어려우므로 리펙토링을 해야 하지만 코드가 너무 방대해서 리펙토링을 하기가 어렵습니다.
• 어플리케이션내의 특정 기능이 실패하면 전체 어플리케이션에 영향을 미칩니다. 그리고 퍼포먼스가 나쁜 특정 함수/메소드의 영향이 전체 어플리케이션에 고통을 주게 됩니다.
• 이런 아키텍처에서의 scaling은 서버마다 동일한 war or ear을 배포하여 수행해야 합니다. 각각 서버는 동일한 리소스를 사용하게 되므로 이 것은 효율적인 방법이 아닙니다.
• 어플리케이션이 커질수록 개발자는 작은 단위로 작업을 축소할 수 있어야 합니다. Monolithic은 모든 것이 하나로 묶여 있기 때문에 개발자가 독립적으로 모듈을 개발하고 배포 할 수 없습니다. 그리고 개발은 협업으로 진행되므로 다른 개발자에 의존성때문에 개발 시간이 길어지게 됩니다.

위의 언급한 내용을 염두하고 마이크로 서비스에 대해서 알아보겠습니다.

마이크로 서비스

아키텍처의 중요한 포인트는 바로 확장성입니다. 많은 사람들이 확장성을 얘기 할 때는 The Art of Scalability라는 책을 인용합니다. 이 책에서는 Scaling을 세 가지로 정의합니다.

X 축은 horizontal(수평) application scaling (Monolithic 아키텍처에서도 가능)을 나타내며, Z축은 비슷한 것들을 분할하여 어플리케이션을 스케일링함을 의미합니다. (Z축은 데이터를 분할하여 사용자의 요청에 따라 해당 샤드에 redirect하는 샤딩 개념으로 이해하면 됩니다.)

Y축이 가장 중요하고 우리가 눈여겨 봐야할 대상입니다. 이 축은 기능적인 분해(해체)를 의미합니다. Monolithic에 포함되어 있는 다양한 기능을 독립적인 서비스로 바라보는 전략을 취합니다. 따라서 모든 기능을 전체 어플리케이션에 배포하지 않고 각각 서비스를 독립적으로 배포 할 수 있습니다.

이렇게 하면 개발자의 생산성이 향상되고 기능 변경시 side-effect 걱정 없이 변경하고 배포 할 수 있는 유연성을 제공합니다.

예전 Monolithic 방식과 비교해보세요.

마이크로 서비스의 장점

벤더사 중심의 SOA에 비해서 마이크로서비스는 Amazon, Netflix, eBay와 같은 글로벌 서비스 플레이어가 사용할 만큼 강력합니다.

Improves fault isolation : 단일 모듈의 장애에 대해 전체 어플리케이션은 크게 영향을 받지 않습니다.

Eliminates long-term commitment to a single technology stack : 각 개별 서비스에서 새로운 기술 스택을 시험하고자 한다면 바로 시작할 수 있습니다. 의존 관계가 기존 Monolithic 아키텍처보다 적고 유연합니다.

기능 단위로 서비스가 되기에 새로 조인한 개발자가 기능을 더 쉽게 이해 할 수 있습니다.

마이크로 서비스의 배포 및 가상화

마이크로 서비스기반의 어플리케이션을 배포하는 가장 좋은 방법은 컨테이너 가상화를 이용하는 것입니다. (Docker)

AWS와 같은 IaaS업체의 VM을 이용하여 마이크로 서비스를 배포할 수 있지만 작은 단위의 마이크로 서비스는 VM의 리소스를 전부 활용 하지 못해 비용 효율성을 저하 시킬 수 있습니다. 따라서 컨테이너 기반으로 배포를 하는 것이 유리합니다.

OSGI(Open Service Gateway Initiative) 번들을 사용하여 코드를 배포 할 수도 있지만, 이 경우에는 management and isolation tradeoff와 관련된 단점이 존재합니다.

마이크로 서비스의 약점

아래는 마이크로 서비스 설계와 관련된 잠재적인 약점에 대한 부분입니다.

• 분산 시스템 개발은 일반 개발보다 복잡합니다. 모든 것이 독립적인 서비스이기 때문에 각 모듈간의 인터페이스를 신중하게 처리 해야 합니다. 서비스중 하나가 응답하지 않게 될 경우에 대한 방어코드도 작성해야 합니다. 호출 대기 시간이 발생하게 되면 복잡한 상황이 발생할 수 있습니다.
• Multiple Databases 및 트랜젝션 관리가 어려울 수 있습니다.
• 마이크로 서비스 기반의 어플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.
• 마이크로 서비스의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.

하지만, 이런 부분들은 자동화 도구를 사용하면 해결 할 수 있습니다.

끝으로, 마이크로 서비스는 벤더사 중심이 아닌 서비스사 중심의 아키텍처이고 이미 글로벌 플레이어에 의해 검증이 되어 있습니다.

하지만, 좋은 아키텍처도 상황과 사람에 의해 달라지게 됩니다.

마이크로 서비스 아키텍처를 경험했거나 경험할 계획이 있으신가요?

참조

• http://cloudacademy.com/blog/microservices-architecture-challenge-advantage-drawback/

Read More