Azure Service Fabric for Microservice Architecture Presented at Azure BootCamp 2016 Korea

1. 마이크로서비스아키텍처?
Azure Service Fabric으로 고고!
2016-04-16
Youngjae KIM
youngjae@bapul.net

2. 발표자 소개
• 김영재
• ㈜바풀 기술총괄
• C#, Java, Python
• 안드로이드 하기싫다…
• http://youngjaekim.wordpress.com
• 바로풀기 모바일서비스
• 국내 1위의 10대 학습 Q&A
• 250만개 질답, 일평균 4000개 질문 네이버지식인 학습분야의 3배
• Azure PaaS 99%, VM 1% SQL은 아직
• Azure 한국 출시 전부터 적용
• http://www.bapul.net

3. 시작하기 전에
• 이런 분들에게 좋습니다
• 현재 클라우드에서 웹서비스를 운영 중이신 분
• 마이크로서비스아키텍처를 들어보신 분
• 개발자 인생을 좀 더 편하게 살고싶은 분
• 이런 분들은 시간낭비
• 새로 나온 기술 배우기 싫으신 분
• 코딩 싫으신 분
• 아몰랑 Virtual Machine 만드시는 분

4. 오늘 다루는 내용
• 다룹니다
• MicroService Architecture 개요
• Microsoft Service Fabric 개요
• Service Fabric 기술적 특징
• Service Fabric 간단한 데모와 팁
• 다루지 않습니다
• Actor Model
• Akka 등 다른 MSA 프레임워크와의 비교
• Service Fabric 운영 중에 발견될 문제점 저도 라이브는 안해봤습니다
• Service Fabric 실제 효율 라이브를 해봐야…

5. 마이크로서비스아키텍처
만들기가 영 쉽지 않다!

6. 기존 구조와의 비교
출처: https://msdn.microsoft.com/en-us/magazine/mt595752.aspx
모놀리식 (monolithic) 마이크로서비스
서비스 단위

7. 마이크로서비스아키텍처
• 왜 등장했나?
• 작은 팀 단위 작업이 장려
• 인스턴스만 늘리기  인스턴스를 알차게 사용하고 싶음
• 제품 개발 사이클이 짧아짐
• 성공사례도 나옴: Amazon, Netflix, Skype 등
• 기존 개발 경험의 문제
• 일부 수정에 전체를 업데이트 해야 하는 부담 나눠봤자 덩어리가 여전히 크다
• 유닛테스트가 모든 것을 커버하기에 벅참 (또는, 유닛테스트에 더 적합함)
• 장애 발생시/일부 트래픽 폭주에 전체가 위협받음
문서 출처: https://msdn.microsoft.com/en-us/magazine/mt595752.aspx

8. 좀 더 나은 대안으로 등장
• MSA: Micro-Service Architecture
• 한 인스턴스에 서비스 분산으로 High-Availability 달성이 좀 더 수월함
• 설계부터 유닛테스트까지 좀 더 구분감 있음
• CQRS, DDD 등에 보다 투명하게 접근 가능
• 일부만 배포하므로 사실상 배포 사이클이 더 빠름
• 팀웍에 효율적
• 대표적인 프레임워크
• Akka / Akka.Net / Sinatra 등
• 보통 Akka + Docker + Linux 조합을 많이 사용하는 듯 하지만 실제 운
영 중인 서비스는 많지 않음. Scala 개발자도 적은데 많을리가…

9. 하지만! MSA 구현시 어려운 점
• 데이터 레이어의 재설계
• SQL 서버를 쓰든 Redis 캐시를 쓰든 하나만 쓰면 안됨
• 종전대로 하면 MSA를 제대로 구현하는 것도 아님
• State 보존에 대한 확신
• State 보존이 용이할 수록
데이터 레이어의 고민이 적어짐
• 서비스 별 의존성
• 하다보면 중복이 많아짐
• 하지만 이에 대해서는 일부러
허용하는 것도 있음

10. “이번 프로젝트 MSA로 설계해볼 사람?”

11. Azure Service Fabric
마이크로소프트의 영혼까지 끌어 모은 MSA 플랫폼

12. Azure Service Fabric
• Azure가 제시하는 MSA 프레임워크
• 저수준 실행 로직부터 고수준 Actor 패턴용 base class까지 제공
• Build 2016에서 본격 출시! General Availability라고도 합니다
• Microsoft 스타일의 개발 경험
• 어지간해서는 잘 동작함.
• VisualStudio의 고급스러운 개발경험. C# 사용하면 잘 생겨짐.
• 친절한 문서화.
• 다루기 쉬운 GUI.
• 들어올 땐 마음대로 였지만 나갈 땐 아니란다.
• 어차피 뭘 쓰든 마찬가지더군요
이미지출처: http://egloos.zum.com/mcchae/v/11148354

13. 닷넷과 다르다. 닷넷과는…!
• 닷넷프레임워크, Node.js, Java, C++ 지원
• 사실 Executable이면 기본적으로는 OK!
• Windows, Linux 머신에서 클러스터 구성 가능 (예정)
• 현재(2016.4) 윈도우 머신으로만 가능
• AWS에서 만들고 Azure TrafficManager로 연동 가능
• 최소 머신 5대만 있으면 뭐든 OK!
• 5년 넘게 검증했다고 함
• 거의 모든 Azure 서비스
• 거의 모든 최근 MS 웹서비스
이번 Build 2016 행사에서 노트북5대, AWS로 구동
https://channel9.msdn.com/events/Build/2016/B874

14. 본격 MSA를 위한 PaaS
In fact, Service Fabric is the only PaaS platform that offers stateful
microservices with state management and replication frameworks built
directly into its cluster management.
출처: https://azure.microsoft.com/ko-kr/blog/containers-docker-windows-and-trends/
Service Fabric은 Cluster 관리부터 State 관리와
Stateful MSA까지 완전히 제공하는 유일한 PaaS 플랫폼

15. 클라우드 서비스의 가상화 단계
이미지출처: https://docs.com/markharrison/5211/microsoft-cloud-platform?c=wsP4Jt

16. Service Fabric의 가상화 단계
Reliable Actor
Reliable Service
Guest Executable
더 가상화됨
더 제어 범위 많아짐

17. Service Fabric의 현재 시점 제약 (2016.04)
• 곧 나아지는 것
• 현재 언어 지원은 C# 1순위
• 리눅스/Docker 아직 지원 안됨
• 변화 없을 듯한 것
• 최소 VM 5개이므로 소규모 서비스에는 부적합
• 최대 1000개의 Virtual Machine 지원

18. Service Fabric 기본

19. 기본 구성
• VM 5개가 최소의 구성
• High Availability 달성
• 실제 서비스의 최소단위는 Stateful의 경우 3개
• 로컬=클라우드=온프레미스 런타임
• 로컬 클러스터와 클라우드의 온전히 동일한 동작 보장
• 그러므로 여러 곳에 클러스터 구성과 배포가 가능
• 총 3개의 동작 레이어
• Guest Executable: exe 파일을 실행
• Reliable Service: Stateful/Stateless 개념의 base class 제공
• Reliable Actor: 싱글스레드, Stateful, 리소스 공유, 수명주기 관리 등 제공

20. Service Fabric의 가상화 단계 (반복)
Reliable
Actor
Reliable Service
Guest Executable
더 가상화됨
더 제어 범위 많아짐

21. 중간 결론: 결국 설계의 문제로 귀결된다
• 코딩보다 설계를 잘 합시다.
• 코딩은 점점 쉬워지고 개발자의 가치는 설계로 발현되어야.
• 10번 설계하고 1번 코딩하는게 낫습니다.
• 하지만 현실은…gg
• 그럴 수 없는 환경이면 안타까운 일입니다.
• 프레임워크는 정교하게 알 필요가 없어지고 있음.
• 우리가 땅이 꺼질 걱정을 하며 살지 않습니다.
• JVM 튜닝보다 로직을 잘 만드는데 공을 들이는 추세.
• 좋은 프레임워크는 좋은 설계를 가능하게 함.
• 가능성을 빠르게 확인하고 적용해보기를 추천.

22. 알아야 할 개념
• Cluster
• Node
• Application
• Service
• Stateful Service / Stateless Service
• Reliable Collection
• Reliable Service / Reliable Actor
• Partition
• Upgrade Domain (UD)
• Remote Procedure Call Proxy

23. Cluster
• Service Fabric 하나의 운용 단위
• 가장 중요한 역할: High Availability에 대한 책임
• Service Replica 수로 reliability tier를 구분함: 3/5/7/9개.
• Node의 집합 (Node는 VM Set의 집합. VM Set은 VM의 집합)
• 수용된 Application의 URI를 관리, 모니터링
• IIS의 Application Pool과 유사 개념
• Node, Update 관리 등
Service Fabric 아이콘이
Cluster를 제대로 표현하고 있음

24. Node
• Node는 VM/VM Set의 묶음이자 Service 배치 기준
• Node Type
• Node를 묶어서 각 Node마다 다른 VM 적용 가능
• 로드밸런싱에 직접 연결됨
• Primary (필수) / Non-primary
• Primary = Reliable 보장 = 최소 3개 이상이어야 함
• Application에서 Node의 상태를 점검하고 자원 재배치하는데
활용

25. Application
• Service의 묶음
• Packaging, Deployment, Versioning, Routing, Scaling, …
• ALM에서 말하는 그 Application 개념
• Develop, Deploy, Test, Upgrade, Maintain, Develop
• 전 과정에 대해 Service Fabric만의 방법론이 갖추어져 있음
• Microservice계의 ALM 풀스위트라 할만 함!
• 이것저것 조합할 필요도, 궁합 맞출 필요도 없음.
• https://azure.microsoft.com/en-us/documentation/articles/service-fabric-
application-lifecycle/
이미지출처: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-model/

26. Service: Code, Config, Data
• 업그레이드 가능한 하나의 구동 단위
• 패키징
• Code: 실행 코드.
• Config: Key-value의 XML 파일.
• Data: 주로 읽기전용의 리소스 (이미지파일 등)
• 모두 독립적으로 업그레이드 가능
• VM 리스타트는 없다!

27. Service: Stateful / Stateless
• Reliable Service가 제공하는 두가지 형태의 Service
• Stateful
• Service Fabric의 자랑거리
• 최소 단위 3개 (primary 1: replica 2)
• Stateless
• 평범한 WebApp PaaS와 동일
• 상태 보존이 필요 없는 것
• 수명 주기 관리가 쉬움
• Replica가 없어도 됨
이미지출처: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-scenarios/
가장_흔한_구성.jpg

28. Reliable Collection
• 패기 넘치는 단어! Reliable
• Stateful Service에서 제공하는 컬렉션
• ReliableQueue
• ReliableDictionary
• 테스트해보니…
1GB 장애  re-allocation에 약 50ms 소요. VM마다 다를 듯
• Replica: memory/disk 모두 저장됨 (persistence)
• 캐시, DB도 이것으로 대체하라는데?!
• 콜드 데이터만 DB로 저장하는 방법
• 일부 데이터는 통째로 들고있어도 좋을 듯
• 어차피 disk replica인건 Database HA도 매한가지
우리에게 이런 단어가 가능하단 말인가?!

29. Partition
• State를 나누어 접근하는 단위
• 한 번 만들면 못바꾼다!
• 최대 long(Int64) 범위 가능.
• 예시: LowKey="-9223372036854775808" HighKey="9223372036854775807"
• 그러므로 처음 설계할 때 가장 많은 수의 파티션을 가정하자.
From a Service Fabric perspective, there is nothing that prevents you from starting
out with a higher number of partitions than anticipated for your scenario. In fact,
assuming the maximum number of partitions is a valid approach.
“파티션이 많아도 SF에는 별 차이 없으니
최대한의 파티션으로 설계하라“
출처: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-concepts-partitioning/

30. Reliable Service / Reliable Actor
Reliable Services APIs Reliable Actor APIs
유형 여러 엔티티 타입을 관리하고 쿼리해야 함 작은 단위의 독립적인 로직과 상태로 구성
데이터 관리 Reliable collection 사용할 일이 많음 데이터보다 싱글스레드로 처리하는 오브젝트가 많음
State 관리 State 관리를 직접 하고 싶음 State 관리는 자동으로. 로직에 집중하고 싶음
서비스간 통신
서비스 간 통신에 프로토콜을 직접 구성하고 싶음
(REST, WebSockets, WCF 등)
Service Fabric이 알아서 해주면 좋겠음
파티션 구성 Stateful 서비스에 대해 파티션 구성을 직접 하고 싶음 Service Fabric이 알아서 해주면 좋겠음
* 한 줄 요약: Reliable Actor는 Actor model 구현에 집중하도록 Reliable Service의 기능을 보다 추상화한 것.
출처: https://azure.microsoft.com/en-us/documentation/services/service-fabric/

31. Update Domain (UD)
• Service의 update는 몇 개의 Node 묶음을 한 단위로 수행.
• 3가지 모드의 update
• Monitored (기본값): Health check 후 자동 rolling.
• Unmonitored Auto: health check 없음. 자동 rolling
• Unmonitored Manual: health check, rolling 모두 수동.
• Update Domain 조절을 할 수 있음
• 하지만 딱히 안해도 됨
• UD 많음 = 더 촘촘한 업데이트 구간.
• 많으면: 서비스가 더 안정적으로 넘어가지만 느림.
• 적으면: 일시적 자원 부족이 있을 수 있음.
• 유사 개념: Fault Domain (FD)
• 장애 상황 대응을 위한 단위.
• UD와 같을 수도 다를 수도 있음.
이 경우 Node:UD=1:1

32. Remote Procedure Call
• Service 간에 있는 메소드를 원격 호출
• 서비스간 통신을 코딩하기에 수월해짐
• Reliable Service에서는 ServiceProxy라는 것으로 제공
• 다시 말해, 더 낮은 수준인 guest executable로는 구현 안됨.
• Interface로 정의한 후 proxy를 만들어서 메소드 실행
IChatService proxy = ServiceProxy.Create<IChatService>(chatServiceInstance, new ServicePartitionKey(1));
proxy.AddMessageAsync(message);

33. 일단 해보자!
Azure Service Fabric Party Cluster

34. 무료로 마음껏 테스트해볼 수 있습니다!
• http://tryazureservicefabric.eastus.cloudapp.azure.com/
• 각 클러스터는 4시간 가량 동작
• 동작 후 완전히 리셋
• 언제든 새로 시작 가능
• 주의: 누구에게나 공개됨

35. 준비물
1. Visual Studio 2015
2. Service Fabric SDK
• https://azure.microsoft.com/en-us/documentation/articles/service-fabric-get-started/
3. 샘플 프로젝트
• https://github.com/azure-samples/service-fabric-dotnet-getting-started
위에 모든 것이 무료입니다.
Visual Studio Community Edition 역시 무료!

36. WordCount 샘플 프로젝트
• 볼만한 것: 각 서비스의 포트가 어떻게 열리는지 알아봅시다. Reliable Collection도 살펴봅시다.
• https://github.com/Azure-Samples/service-fabric-dotnet-getting-started
• Services＼WordCount＼WordCount.sln
WordCount.WebService WordCount.Service
Internet
http get
rest put
http/json
Html
JS
Web
Api
Web
Api
http/html
Partitions
A, B, C, …
rest post

37. Chatter 샘플 프로젝트
• 볼만한 것: ServiceProxy를 이용한 RPC Repository Pattern을 살펴봅시다.
• https://github.com/Azure-Samples/service-fabric-dotnet-getting-started
• Services＼ Chatter＼Chatter.sln
Chat.Web ChatService
Internet
http get
Html
JS
Proxy
Message
Repository
Message
Collection
Partitions
(DateTime key)
Default stackWeb
Api
rest
rest
ServiceProxy

38. 패턴
• Paolo Salvatori 님이 제안하는 Service Fabric 적용 패턴 및 예시
• Observer-pattern
https://github.com/paolosalvatori/servicefabricobserver
• Click Analytics
https://github.com/paolosalvatori/servicefabricclickanalytics
• IoT Hub
https://github.com/paolosalvatori/servicefabriciothubdemo
• Event Hub integration
https://github.com/paolosalvatori/servicefabriceventhubdemo
• Asynchronous Competing Actors
https://github.com/paolosalvatori/servicefabricasynchronouscomputingactors

39. 참고자료
• MSA & Service Fabric
• https://msdn.microsoft.com/en-us/magazine/mt595752.aspx
• MSA 개요
• http://martinfowler.com/articles/microservices.html
• 마이그레이션 참고1
• https://azure.microsoft.com/ko-kr/documentation/videos/azurecon-2015-migrating-your-application-to-azure-service-
fabric/
• Azure Service Fabric Documentation
• https://azure.microsoft.com/en-us/documentation/services/service-fabric/
• Docker & Container & MSA & Service Fabric
• https://azure.microsoft.com/ko-kr/blog/containers-docker-windows-and-trends/
• 마이그레이션 참고2
• https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cloud-services-migration-worker-role-
stateless-service/

40. Thank You
Azure 유저그룹: https://www.facebook.com/groups/krazure/