[Azure bootcamp2017] Azure App Service로 서비스 탄탄하게 관리하기

https://doc.co/c7REb6
Azure App Service로
서비스 탄탄하게 관리하기
Azure Boot Camp 2017 @ MARU180
https://doc.co/c7REb6 (대소문자구분함)
김영재
2017-04-22

안녕하세요
• 바로풀기 CTO
• 100% Azure PaaS 구현
• Azure MVP (2014~)
• 대부분의 시간
• C#
• Azure
• Android
• Python
• iOS
• 커피
• 맥주

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

Azure App Service
• Azure의 1순위 서비스 중 하나: WAS 그 이상
• 기반은 IIS의 서브셋으로 구현 (이제는 IIS와 많이 달라짐. 보안/샌드박싱 때문)
• Linux Docker 지원 시작
• 발전 과정
• WebSites: 단순 IIS스러운 WAS + WebJobs
• App Service v1: 4개의 App 카테고리로 개편 (Web, Mobile, API, Logic)
• App Service v2: Azure Function, 부하분산 강화, Linux Docker, …
WebSites App Service v1 App Service v2

앱 서비스와 아이들
• App Service: 개별 프로세스
- ~ Plan: 한 개의 서버에 다 담을 수 있음
 가격은 서버 1대만!
- Web App: 프론트엔드
- WebJobs: Web App의 은밀한 보조
- Api App: Swagger 쓰면 편리함
- Logic App: 워크플로우 구성
- Function: WebJob을 꾸려서 만든
Serverless (Lambda보다 간편함)
- Mobile App: 푸시/SocialLogin/테이블

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

본론에 들어가기 전에
• App Service 구조를 깊게 살펴봅시다
• https://youngjaekim.wordpress.com/2017/04/03/번역-azure-앱서비스-
구조를-깊게-살펴봅시다/
• App Service Environment의 네트워크 구성
• https://msdn.microsoft.com/en-us/magazine/mt797651
• 왜 이것을 아는 것이 중요한가?
• 장애 또는 특이 상황에 대해 보다 정교한 이해와 대응이 가능

App Service 구조
• 언어를 만드는 언어가 있듯, PaaS를 만드는 PaaS가 있음.
• 내부는 Azure Cloud Service (classic)으로 구현됨
• 약 1,000개의 서버를 하나의 ‘확장 단위’로 관리함
• 확장단위 내에 구성요소 및 역할
• 프론트엔드: Layer-7 로드밸런서 + SSL 핸들링
• 웹 작업자(worker): 유저의 앱을 구동하는 런타임
• 파일 서버: Azure Blob Storage를 네트워크디스크로 마운트하는 역할
• API 콘트롤러: 앱의 실행/정지 등의 명령을 처리
• Publisher: 앱 배포용 FTP 프로토콜을 제공 (서비스용 아님)
• SQL: 앱 구동 메타데이터 저장
• Data Role: 내부 캐시 (유저가 쓰는게 아님)

그림으로 그려보면
프론트엔드
로드밸런서
Worker Pool
내부 관리용 API 콘트롤러
인바운드
트래픽
캐시(Data Role)
Blob Storage
File Server
(드라이브 마운트)
메타데이타
저장
앱
Cloud Service
런타임
Worker

App Service 구조
• Worker(앱 런타임)가 이미 돌고 있는 상태에서 확장 명령에 따라
앱을 복제하여 순식간에 확장  마법같은건 없음
• 확장/축소 완료 후 트래픽을 분산하므로 유실 없음

App Service의 네트워크 특성
• 1개의 인/아웃바운드 겸용 + 4개의 아웃바운드 전용=총 5개의 IP
• 고정IP 할당 가능. 앱을 정지하면 다른 IP로 바뀔 수 있음.
• 네트워크주소변환(Network Address Translation; NAT) 테이블의 한계
• B1/S1/P1 인스턴스 당 1,920 연결
• B2/S2/P2 인스턴스 당 3,968 연결
• B3/S3/P3 인스턴스 당 8,064 연결
• 앱 서비스 환경(ASE) 당 최대 64K 연결

App Service 구조
• App Service Environment (ASE)
• 독립된 확장 단위를 원할 때. Premium tier만 사용 가능
• 일종의 서버팜. 여러 개의 ASP를 호스팅
• 온전히 독립된 네트워크 인프라 설정 가능
• 최대 100개의 ASP 인스턴스 호스팅 가능
• 여러 지역에 걸쳐서 설정 가능 (네트워크, 부하분산 등)
• App Service Plan (ASP)
• 가상컴퓨터 확장세트(Virtual Machine Scale Set)라고 이해하면 됩니다
• 확장 단위 (중요)
• Region, Scale instances, Instance size (Small, Medium, Large), SKU (Free, Shared, Basic, Standard, Premium)
• VNET 설정 단위
• 리소스가 허용하는 한 여러 개의 App을 호스팅
• App
• 유저가 만든 앱 하나.
• .NET, Python, Node.js, JVM, …

App Service 이해 ≒ App Service Plan 이해
• 하나의 ASP에 앱 2개를 띄우면 두 App 트래픽을 같은 ASP가 받음
• ASP 2개의 인스턴스로 수평 확장하면 App도 2배 (App 4개)
• VM에 여러 was 프로세스를 돌린다고 이해하는게 편함
• App은 [같은 resource group + 같은 region] 안에서만 ASP 이동 가능

소결론
App Service에서 가장 많이 신경써줄 것은

App Service로 서비스 관리
DevOps 까지는 아니고..그냥…관리

일단 WebApp을 하나 만듭시다
• 추가(Add) > 웹앱(Web App)
• 앱 서비스 계획(App Service Plan): 우리는 배포슬롯(Deployment Slot)이라는
기능을 사용할 것이므로 표준 계층(Standard tier)으로 만듭니다.
• 만들자마자 기본 html 페이지가 추가되어 있습니다.
• App Service Plan 이름은 뭐로 하나요?
• {프로젝트명-Heavy} 형식으로 하면 관리하기 좋음 (나름 시행착오의 결과…)
• Heavy, Light, Free

App Service 하나를 다 이해못할 정도
• ‘평범한 웹서비스 하나’를 띄우는데 어마어마하게 많은 기능 제공
• ‘요구사항 받아서 만들다보니…’
• 주요 기능
• SSL, CORS, custom domain
• Swagger 지원 및 Power BI 연동
• 지속통합/배포 제공: GitHub push 만으로 런칭
• 백그라운드 전용 프로세스 및 관리 제공: WebJobs
• 엔드포인트 모니터링 제공: Application Insights
• 스케줄 및 각종 규칙에 따른 수평/수직 확장
• 자체적으로 MySQL 인스턴스 제공
• Table, Mobile Push 등 다른 서비스 연계
• 등등등…

참고
• 많은 기능은 App Service 외에 별도의 서비스로도 존재.
• 기능이 조금씩 다르므로 취향에 맞게 선택해서 사용하면 좋음.
• Alerts: 이상 상황에 대한 알림
• 대안: Application Insights / NewRelic 등
• Traffic Routing
• 대안: Azure Traffic Manager
• Continuous Deployment
• 대안: CI Builder 소프트웨어/서비스 (TeamCity, Jenkins, AppVeyor, Travis 등)
• Authentication
• 대안: Auth0.com, 설치형 Oauth 서버 등

배포 옵션(Continuous Deployment)
• Git 기반은 모두 가능
• Dropbox, OneDrive의 정적 파일도 가능 (뭐 이런 것 까지…)

배포 슬롯(Deployment Slot)
• 교환(SWAP) 기능을 제공
• 테스트용, A/B테스트용 등으로 활용

고급 도구(Advanced Tools) 프로젝트 kudu
• 파일시스템을 터미널 안띄우고 보고 수정할 수 있음
• 각종 환경변수 및 프로세스 확인
• 급할 때는 로그도 바로 확인 가능
• 웹콘솔 기능으로 파이썬 패키지 설치도 가능

https://doc.co/c7REb6프로덕션에서 테스트(Testing in Production)
slot 별 라우팅
• Slot이 여러 개일 때 일정 비율로 분산: A/B 테스트 가능
• “?x-ms-routing-name={slot}”을 url에 넣으면 해당 슬롯으로만 이동
• 참고: 슬롯 삭제는 우클릭>Delete
A0
B0
A1 A2
B1 B2
2% ↓
15% ↑User

경고(Alerts)
• 조건에 따라 메시지를 보내는 경고 장치

인스턴스당 매트릭(Metrics per Instance)
App Service Plan
• App Service 관리의 가장 중요한 것은?  App Service Plan 쪼개기
• App Service Plan을 어떻게 나눌지를 판단하는 근거.
• 주의: 이 메뉴는 App Service Plan이 아닌 개별 App 메뉴 안에 있음.

Application Insights
• 강력추천 텔레메트리
• 끝점 별 응답시간
• 똑똑한 자동 알림
• 매 주 요약 이메일
• 무료도 훌륭함
• 단점: 보존기한 90일
• 좋은 조합
• ApplicationInsights + NewRelic

Logic App으로 모니터링
• “끝점을 모니터링하다 응답 없으면 Slack으로 알림을 보냅시다”
• 주안점
• 콘솔 없음
• 코딩 없음
• 100% PaaS
• 결과 예시
Azure WebApp 생성
Azure Logic App
Azure Scheduler
동작 확인

경품 퀴즈
• 다음 중 App Service Plan에서 관리하지 않는 것은?
• 인스턴스 개수
• 인스턴스 컴퓨팅파워
• 호스팅하는 앱의 실행과 정지
• 인스턴스의 VNET 설정

Thanks You
Q&A

[Azure bootcamp2017] Azure App Service로 서비스 탄탄하게 관리하기

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [Azure bootcamp2017] Azure App Service로 서비스 탄탄하게 관리하기

Ähnlich wie [Azure bootcamp2017] Azure App Service로 서비스 탄탄하게 관리하기 (20)

[Azure bootcamp2017] Azure App Service로 서비스 탄탄하게 관리하기

Hinweis der Redaktion