Saturday Azure Live 1701 Azure WebApp 개념원리
26
-
Upload
youngjae-kim -
Category
Technology
-
view
191 -
download
1
Transcript of Saturday Azure Live 1701 Azure WebApp 개념원리
저는요•바풀 기술총괄• 100% Azure 에서 동작
•Azure MVP (2014~)•대부분의 시간• C#• Android• Python• Azure•커피•맥주
잠깐 책 소개•책 난이도 ★ ★☆☆☆•무작정 따라하기 형식•스크린샷 많음•얼마나 팔린지 모름
번역이 재미있어졌다• 최신 기술 – Event Sourcing 처음 적용하기
• 최신 기술 – CQRS 처음 도입하기
• 최신 기술 – 이력을 기록하는 CRUD 구현하기 1부
• 최신 기술 – 이력을 기록하는 CRUD 구현하기 2부
• Microsoft Azure – Azure Service Fabric, 그리고 마이크로서비스 아키텍처• 위 모든 내용은 블로그에 있습니다 http://youngjaekim.wordpress.com
• 번역 관련 서적 추천• 번역의 탄생• 갈등하는 번역• 검색 , 사전을 삼키다
시작합니다 – Azure WebApp
DemoAzure WebApp + Flask: https://github.com/YoungjaeKim/AzureFlaskDemo
눈 여겨볼 부분• 예쁘다• 블레이드 (Blade) 라는 단위로 GUI 가 펼쳐진다• App Service Plan• Free/Basic/Standard/Premium• GitHub 자동 동기화 (sync) 및 배포• Logging: Filesystem / Blob• x86 / x64• Extensions ( 확장 기능 )• AlwaysOn • 브라우저 내에서 콘솔과 파일 작업• Application Insights
Azure WebApp = PaaS (Platform-as-a-Service)• PaaS 덕후 Azure•이제 Virtual Machine (VM) 은 그만 ~• PaaS 의 덕목•프로그램과 시스템의 격리 isolation
•더 빠른 장애 대응•정책적으로도 더 빠르게 복구함
•철학•시스템 운영에 멀어지게 + 코드와 로직에만 집중하게•생산성
Azure
기본구조앱 서비스 계획 : 인스턴스
1Web App 1: Azure-Demo
Logic App: Example1
…
Web App 2: Azure-Saturday
LoadBalancer
앱 서비스 계획 : 인스턴스2( 위와 같음 )
사용자
앱 서비스와 아이들• App Service: 개별
프로세스- ~ Plan: 한 개의 서버에 다 담을 수
있음 가격은 서버 1 대만 !
- Web App: 프론트엔드- WebJobs: Web App 의 은밀한 보조- Api App: Swagger 쓸 때 편함- Logic App: 각종 integration 전용- Function: WebJob 을 꾸려서 만든
Serverless (Lambda 보다 간편함 )- Mobile App: 푸시 /SocialLogin/
테이블( 저는 권장하지 않습니다 )
앱 서비스 계획 / 앱 서비스의 옵션• Plan: Free / Shared / Basic / Standard / Premium•기능 별 차이
•Scale Up: Small / Medium / Large•성능 별 차이
•Scale Out: 1~50•인스턴스 개수 차이
•주의 : 앱서비스와 앱서비스 계획은 다르다• Scale Up/Out: 앱 서비스 계획• Plan: 앱 서비스
앱 서비스 계획 / 앱 서비스의 옵션
https://azure.microsoft.com/ko-kr/pricing/details/app-service/plans/
눈 여겨볼 부분 중간점검• 예쁘다• 블레이드 (Blade) 라는 단위로 GUI 가 펼쳐진다• App Service Plan• Free/Basic/Standard/Premium• GitHub 자동 동기화 (sync) 및 배포• Logging: Filesystem / Blob• x86 / x64• Extensions ( 확장 기능 )• AlwaysOn • 브라우저 내에서 콘솔과 파일 작업• Application Insights
Demo – GitHub 자동 동기화Sync
여담 : GitHub 배포에 에러가 날 때도 있더라
GitHub.com 장애 자동배포 장애
내부 구조• 전형적인 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
없어질 수 있음
자유로운 확장
명확히 구분함
Always On?• 기본 (Basic tier) 이상에서만 켤 수 있음• 20 분 후 리사이클되는 것을 방지• Azure Scheduler 를 이용한 꼼수 가능
• 10 분에 한번씩 GET 을 보냄
눈 여겨볼 부분 중간점검• 예쁘다• 블레이드 (Blade) 라는 단위로 GUI 가 펼쳐진다• App Service Plan• Free/Basic/Standard/Premium• GitHub 자동 동기화 (sync) 및 배포• Logging: Filesystem / Blob• x86 / x64• Extensions ( 확장 기능 )• Always On • 브라우저 내에서 콘솔과 파일 작업• Application Insights
Application Insights• Azure 에서 제공하는 APM (Application Performance Management)
서비스• 유사 서비스 : NewRelic, LeanSentry• 깊은 모니터링과 얕은 모니터링 가능
• 얕은 모니터링 : 트래픽 , 속도 , 장애여부 등• 깊은 모니터링 : endpoint 별 퍼포먼스 , 전체 구조 등
Demo – C#C# 쓰면 좋은가 ?
번외편
Logic App 예시• Logic App + Azure Scheduler• 지정한 주소에 1 분마다 GET 을 수행하고 결과를 Logic App 으로 보냄• Logic App 은 Slack Integration 을 이용해서 메시지를 줌 .• 통계를 위해 특정 주소에 같은 내용의 이메일도 보냄 .
이 정도 쯤은 코딩 하나 없이 가능 !
어떻게 기술을 선택하는가나는 왜 Azure 를 선택했나
클라우드의 콩라인 : Azure [ 애저 ]•규모 : AWS >>> Azure >>>> GCP•그런데 왜 쓰나• VM 과는 다르다 ! VM 과는 !•가장 많은 리전 ( 서울도 올해 ! 상반기 런칭 !)• PaaS: Platform-as-a-Service• 다른건 ? IaaS (Infrastructure), Saas (Software)
•바로풀기• ( 아마도 ) 최초로 100% PaaS 로 동작하는 온라인서비스• 서버관리 필요 없습니다 . 코드만 짜서 push 하면 됩니다 .• 장애 대응도 빠름 : 시스템 부팅 없음 .
자랑거리
개념의 차이 설계의 차이• AWS• 각 콤포넌트의 구성과 결합에 초점• 인프라 덕후• 단점 : 넌 너무 VM 중심이야
• Azure• 플랫폼 위의 코드 구현에 초점• 생산성 덕후• 단점 : C# > Node.js > Java, Python
• GCP• 제공하는 API 사용에 초점• 서비스 덕후• 단점 : 장애 대응에 커뮤니케이션이 거의 없음
Thank you
