<div id="readability-page-1" class="page"><div id="content">
		<main id="main" role="main">

					<div>
				
<article id="post-7242">
	

	<div>
		
<p>개발자라면 누구나 마음 속에 두고 있는 신기술이 있을겁니다.</p>



<h2>“언젠가는 꼭 써보고 싶다”</h2>



<p>위와 같은 소망을 담고 말이죠.<br>저에게는 Service Fabric이 그렇습니다.</p>



<p>Service Fabric은 K8S+Akka+PaaS의 특징이 결합한 형태라고 생각하면 됩니다. K8S, Akka를 그대로 쓸 수 있다는 뜻은 아니고 Container Orchestration, Routing/Scaling/Healing, Infrastructure Virtualization, Actor Model 등을 도입할 수 있다는 겁니다. 좀 더 간단한 표현으로는 “MSA(Micro Service Architecture) 종합선물셋트”입니다. 아래는 Service Fabric이 막 고개를 들기 시작할 때 제가 발표했던 자료입니다.</p>






<p>Service Fabric을 실서비스까지 적용해보지는 못했지만, 시험적으로 사용해봤을 때 많은 매력을 느꼈습니다. 매력 중 하나는 <a href="https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-reliable-collections">Reliable Collections</a>였습니다. 웹기술의 대부분은 stateless만 고려합니다. 즉, 같은 클라이언트가 요청해도 과거의 접속과 상태를 유지하는 것이 아니라 새로운 요청을 가정한 후, 클라이언트가 부수적으로 주는 쿠키 등 정보 조각을 이용하여 과거와 같도록 만든 것이지 원론적으로는 과거의 요청과 새로운 요청은 무관합니다.</p>



<p>과거의 요청과 새로운 요청을 잇기 위해 여러 단계와 과정이 있는데, 최종적으로는 DB까지 요청해서 확인을 하곤 하죠. 즉, 어플리케이션 로직과 무관하게 DB가 사라지면 어플리케이션이 바보가 되는 형태가 흔한 웹서비스의 3-tier architecture 입니다. (과거 값 + 1) 로직에 대해 ‘과거 값’을 DB에 의존해야 하는거죠. 어느새 우리가 너무 자연스럽게 3-tier 구성을 사용하다보니 ‘DB가 없으면 어플리케이션이 바보되는건 당연한거 아냐?’라고 생각하고 있었습니다. 하지만, 어플리케이션이 충분히 견고할 때는 DB가 필요없을 수도 있다고 생각한 것이 Service Fabric의 철학입니다.</p>



<p>Reliable Collections는 어플리케이션의 replica에서 정보를 계속 유지해서 이 문제를 해결합니다. 그 정보는 메모리일 수도 디스크일 수도 있고요. 그래서 데이터가 어플리케이션 로직 안에 하나의 자료구조 변수처럼 존재합니다. 흔한 ORM들이 ‘DB를 마치 하나의 자료구조 변수인 것처럼’ 인식시키는 개발 경험을 주지만, DB가 사라져도 자료구조 변수와 그 값이 온전히 남아있지는 않습니다.</p>



<hr>



<p>다시 본론으로 와서, <a href="https://docs.microsoft.com/ko-kr/azure/service-fabric-mesh/service-fabric-mesh-overview">Service Fabric Mesh</a>는 Service Fabric을 보다 가상화해서 Serverless(?: 개인적으로 이 표현을 좋아하지 않습니다) 경험을 줍니다…라고 생각했지만, 의외로 제가 위에서 강조한 Service Fabric의 강점과 큰 상관이 없어보입니다. Mesh 관련 피드백에도 “<a href="https://github.com/Azure/service-fabric-mesh-preview/issues/102">Reliable Collections 지원이 안되면 의미없음</a>“이라고 유저피드백이 있네요.</p>



<figure><div>
<p><span><iframe width="700" height="394" src="https://www.youtube.com/embed/L9lBH1oXy3Q?version=3&amp;rel=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;fs=1&amp;hl=ko&amp;autohide=2&amp;wmode=transparent" allowfullscreen="true" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation"></iframe></span></p>
</div><figcaption>▲ 인프라 설정을 json/yaml로 다루는 경험은 대안이 많은데…</figcaption></figure>



<p>대신 Mesh의 의도는 MSA 다수의 어플리케이션을 WebApp 배포처럼 쉽게 올릴 수 있도록 하는 것으로 보입니다. 다만, 위 영상의 인프라 구성 파일(json)을 보면 이것만의 강점이 뾰족하지는 않아보입니다.</p>



<p>즉, Mesh는 아직까진 Service Fabric의 인프라(auto healing/routing 등) 취급 경험만 의미하는 것으로 보입니다. 그래도 Reliable Collections 지원이 언젠가는 이뤄질테니 그 때까지는 기다려봐야 겠습니다.</p>




			
			
						</div>

	
</article>
			</div>

				
	
			


		
		</main>
	</div></div>

youngjae.kim

개발자라면 누구나 마음 속에 두고 있는 신기술이 있을겁니다. “언젠가는 꼭 써보고 싶다” 위와 같은 소망을 담고 말이죠.저에게는 Service Fabric이 그렇습니다. Service Fabric은 K8S+Akka+PaaS의 특징이 결합한 형태라고 생각하면 됩니다. K8S, Akka를 그대로 쓸 수 있다는 뜻은 아니고 Container Orchestration, Routing/Scaling/Healing, Infrastructure Virtualization, Actor Model 등을 도입할 수 있다는 겁니다. 좀 더 간단한 표현으로는 “MSA(Micro Service Architecture) … Azure Service Fabric Mesh는 아직 애매하다 계속 읽기

Azure Service Fabric Mesh는 아직 애매하다

댓글