2017-01-14에 강남역 토즈에서 발표한 세미나 발표자료입니다.

1. Azure WebApp 개념원리
2017-01-14
김영재
youngjae@bapul.net

2. 저는요
• 바풀 기술총괄
• 100% Azure에서 동작
• Azure MVP (2014~)
• 대부분의 시간
• C#
• Android
• Python
• Azure
• 커피
• 맥주

3. 잠깐 책 소개
•책 난이도 ★ ★☆☆☆
•무작정 따라하기 형식
• 스크린샷 많음
• 얼마나 팔린지 모름

4. 번역이 재미있어졌다
• 최신 기술 – Event Sourcing 처음 적용하기
• 최신 기술 – CQRS 처음 도입하기
• 최신 기술 – 이력을 기록하는 CRUD 구현하기 1부
• 최신 기술 – 이력을 기록하는 CRUD 구현하기 2부
• Microsoft Azure – Azure Service Fabric, 그리고 마이크로서비스 아키텍처
• 위 모든 내용은 블로그에 있습니다  http://youngjaekim.wordpress.com
• 번역 관련 서적 추천
• 번역의 탄생
• 갈등하는 번역
• 검색, 사전을 삼키다

5. 시작합니다 – Azure WebApp

6. Demo
Azure WebApp + Flask: https://github.com/YoungjaeKim/AzureFlaskDemo

7. 눈 여겨볼 부분
• 예쁘다
• 블레이드(Blade)라는 단위로 GUI가 펼쳐진다
• App Service Plan
• Free/Basic/Standard/Premium
• GitHub 자동 동기화(sync) 및 배포
• Logging: Filesystem / Blob
• x86 / x64
• Extensions (확장 기능)
• AlwaysOn
• 브라우저 내에서 콘솔과 파일 작업
• Application Insights

8. Azure WebApp = PaaS (Platform-as-a-
Service)• PaaS 덕후 Azure
• 이제 Virtual Machine (VM)은 그만~
• PaaS의 덕목
• 프로그램과 시스템의 격리 isolation
• 더 빠른 장애 대응
• 정책적으로도 더 빠르게 복구함
• 철학
• 시스템 운영에 멀어지게 + 코드와 로직에만 집중하게
• 생산성

9. Azure
기본구조
앱 서비스 계획: 인스턴스1
Web App 1: Azure-Demo
Logic App: Example1
…
Web App 2: Azure-Saturday
Load
Balancer
앱 서비스 계획: 인스턴스2
(위와 같음)
사용자

10. 앱 서비스와 아이들
• App Service: 개별 프로세스
- ~ Plan: 한 개의 서버에 다 담을 수 있음
 가격은 서버 1대만!
- Web App: 프론트엔드
- WebJobs: Web App의 은밀한 보조
- Api App: Swagger 쓸 때 편함
- Logic App: 각종 integration 전용
- Function: WebJob을 꾸려서 만든
Serverless (Lambda보다 간편함)
- Mobile App: 푸시/SocialLogin/테이블
(저는 권장하지 않습니다)

11. 앱 서비스 계획/앱 서비스의 옵션
• Plan: Free / Shared / Basic / Standard / Premium
• 기능 별 차이
• Scale Up: Small / Medium / Large
• 성능 별 차이
• Scale Out: 1~50
• 인스턴스 개수 차이
• 주의: 앱서비스와 앱서비스 계획은 다르다
• Scale Up/Out: 앱 서비스 계획
• Plan: 앱 서비스

12. 앱 서비스 계획/앱 서비스의 옵션
https://azure.microsoft.com/ko-kr/pricing/details/app-service/plans/

13. 눈 여겨볼 부분 중간점검
• 예쁘다
• 블레이드(Blade)라는 단위로 GUI가 펼쳐진다
• App Service Plan
• Free/Basic/Standard/Premium
• GitHub 자동 동기화(sync) 및 배포
• Logging: Filesystem / Blob
• x86 / x64
• Extensions (확장 기능)
• AlwaysOn
• 브라우저 내에서 콘솔과 파일 작업
• Application Insights

14. Demo – GitHub 자동 동기화
Sync

15. 여담: GitHub 배포에 에러가 날 때도 있
더라
GitHub.com 장애 자동배포 장애

16. 내부 구조
• 전형적인 WAS (Web Application Server) 그 자체
• Advanced Tools > GO 클릭 > Environment
• SERVER_SOFTWARE=Microsoft-IIS/8.0
• 앱 프로세스별 소비량 확인: Metrics per Instance (App Service plan) 에서 토글
• Filesystem: 언제든 사라질 수 있음
• 로그를 FileSystem에 저장하면 사라질 수 있음
• 대안은?  Blob(Azure Storage)으로 설정
• 다양한 Extension 제공
• 프로그램이 설치된 후 경로를 지정하여 사용
• 과정이 명확해서 문제 파악에 좋음
Disk
OS
WAS
Process
없어질 수 있음
자유로운 확장
명확히 구분함

17. Always On?
• 기본(Basic tier) 이상에서만 켤 수 있음
• 20분 후 리사이클되는 것을 방지
• Azure Scheduler를 이용한 꼼수 가능
• 10분에 한번씩 GET을 보냄

18. 눈 여겨볼 부분 중간점검
• 예쁘다
• 블레이드(Blade)라는 단위로 GUI가 펼쳐진다
• App Service Plan
• Free/Basic/Standard/Premium
• GitHub 자동 동기화(sync) 및 배포
• Logging: Filesystem / Blob
• x86 / x64
• Extensions (확장 기능)
• Always On
• 브라우저 내에서 콘솔과 파일 작업
• Application Insights

19. Application Insights
• Azure에서 제공하는 APM (Application Performance Management) 서비스
• 유사 서비스: NewRelic, LeanSentry
• 깊은 모니터링과 얕은 모니터링 가능
• 얕은 모니터링: 트래픽, 속도, 장애여부 등
• 깊은 모니터링: endpoint 별 퍼포먼스, 전체 구조 등

20. Demo – C#
C# 쓰면 좋은가?

21. 번외편

22. Logic App 예시
• Logic App + Azure Scheduler
• 지정한 주소에 1분마다 GET을 수행하고 결과를 Logic App으로 보냄
• Logic App은 Slack Integration을 이용해서 메시지를 줌.
• 통계를 위해 특정 주소에 같은 내용의 이메일도 보냄.
 이 정도 쯤은 코딩 하나 없이 가능!

23. 어떻게 기술을 선택하는가
나는 왜 Azure를 선택했나

24. 클라우드의 콩라인: Azure [애저]
• 규모: AWS >>> Azure >>>> GCP
• 그런데 왜 쓰나
• VM과는 다르다! VM과는!
• 가장 많은 리전 (서울도 올해! 상반기 런칭!)
• PaaS: Platform-as-a-Service
• 다른건? IaaS (Infrastructure), Saas (Software)
• 바로풀기
• (아마도) 최초로 100% PaaS로 동작하는 온라인서비스
• 서버관리 필요 없습니다. 코드만 짜서 push하면 됩니다.
• 장애 대응도 빠름: 시스템 부팅 없음.

25. 개념의 차이  설계의 차이
• AWS
• 각 콤포넌트의 구성과 결합에 초점
• 인프라 덕후
• 단점: 넌 너무 VM 중심이야
• Azure
• 플랫폼 위의 코드 구현에 초점
• 생산성 덕후
• 단점: C# > Node.js > Java, Python
• GCP
• 제공하는 API 사용에 초점
• 서비스 덕후
• 단점: 장애 대응에 커뮤니케이션이 거의 없음

26. Thank you