7. BCDR (Azure Paired Region)
https://azure.microsoft.com/ko-kr/documentation/articles/best-practices-availability-paired-regions/
Geography 쌍을 이루는 지역
북아메리카 미국 중북부 미국 중남부
북아메리카 미국 동부 미국 서부
북아메리카 미국 동부 2 미국 중부
북아메리카 미국 서부 2 미국 중서부
유럽 북유럽 서유럽
아시아 동남아시아 동아시아
중국 중국 동부 중국 북부
일본 일본 동부 일본 서부
브라질 브라질 남부(1) 미국 중남부
오스트레일리아 오스트레일리아 동부 오스트레일리아 남동부
미국 정부 미국 정부 아이오와 미국 정부 버지니아
인도 인도 중부 인도 남부
캐나다 캐나다 중부 캐나다 동부
8. 우리 나라는?
•BCDR ≥ 300 마일
•전부 충족하진 않음
•BCDR을 구현하지 않아도
SLA를 적용 받음
10. What is Resource Manager?
•Resource들의 집합
•Region에 관계 없이 Resource들을 관리할 수 있음
•한 눈에 어떤 서비스를 사용하고 있는지 확인 가능
•테스트 종료 또는 서비스 종료 시 손 쉬운 제거
•Life Cycle이 같은 Resource들 끼리 모으는 것이 좋음
•Export/Import 가 자유로워 Stack을 복제하기 쉬움
15. Cloud 벤더사간 Network 비교
구 분 Microsoft Azure Amazon Web Service Google Cloud Platform
기본 Network 정책 Public Private Public
Network의 종속 Region Region Global or Region
SLA 수준
99.9% 이상
(거의 모든 서비스에 대한
SLA 정의)
없음
(EC2, RDS, S3, Route53,
CloudFront만 정의)
99.9%
(거의 모든 서비스에 대한
SLA 정의)
VPN
Client to Site
Site to Site
Site to Site Site to Site
https://azure.microsoft.com/ko-kr/support/legal/sla/
16. VNet과 Subnet
•사용자가 정의할 수 있는 가상 네트워크
•VNet은 Region에 종속되며, Subnet은 VNet에
종속된다.
•Network는 최대한 용도에
따라 나눈다.
•Region내 VNet간 Peering이
가능
17. Default Route와 Route Table
•기본적으로 Local VNet간,
Internet, VPN의 경로가 지정
•사용자가 추가로 정의하여
특정 CIDR로 전달되는 트래픽을
가상 장비 또는 Black Hole로
보낼 수 있음
18. Security Group
•Network ACL과 동일한 Format
•Subnet 또는 vNIC에 연결
•기본 Network Tag가 존재
• VIRTUAL_NETWORK
• AZURE_LOADBALANCER
• INTERNET
•각 Resource는 1개의 SG만 연결
•TCP/UDP 패킷만 제어 가능
19. Security Group
우선
순위
원본 IP 원본 포트 대상 IP 대상 포트 프로토콜 Access
65000 VIRTUAL_NETWORK *
VIRTUAL_NETWOR
K
* * 허용
65001
AZURE_LOADBALANCE
R
* * * * 허용
65500 * * * * * 거부
우선
순위
원본 IP 원본 포트 대상 IP 대상 포트 프로토콜 Access
65000 VIRTUAL_NETWORK *
VIRTUAL_NETWOR
K
* * 허용
65001 * * 인터넷 * * 허용
65500 * * * * * 거부
Inbound Default Policy
Outbound Default Policy
21. Load balancer
•Layer 4 기반의 Load Balancer
•NAT Proxy가 존재하는 것이 아니라 Network
Infra에서
직접 Load Balancing 시켜주어 Traffic 제한이 없음
•Sticky Session 지원 불가
•Application Gateway를
통하여 Layer 7 LB도 가능
22. Traffic Manager
•DNS 기반으로 동작하며 우선순위, 가중치, 성능을
기준으로 Traffic을 분산
• 우선 순위: Primary Service에 문제가 생기면, Backup
Service로 연결을 이동합니다.
• 가중치: 설정한 가중치에 따라 Service Endpoint에
Traffic을 분산합니다.
• 성능: Client가 접속할 때 가장 성능이 좋은 Endpoint로
연결합니다. 예) Geographic locations
•Destination의 제한이 없음
25. IDC 에서는...
•Physical Server
• Server Mount, OS Install, Platform Setting...
• Hardware Fault로 인한 인력 낭비
• 문제 발생시... 전화기 들고 “전부 들어와!”
•Virtualization
• 미리 생성해 놓은 Templet을 복제하여 VM 생성
• Portal Site를 구성하여 사용자가 직접 제작
• Hardware의 그늘에서 벗어나진 못함
26. VM의 유혹과 함정
•CPU / VM 개수를 늘리면 성능이 잘 나올 꺼야
• Application이 지원해야 가능
• 간섭에 의해 예상보다 적은 성능이 나올 수 있음
•Network 격리를 위해서 vNIC를 여러 개 연결 해야지
• vNIC가 여러 개여도 물리적인 Network 격리는 불가능
• Security Group과 Gateway의 적절한 혼합이 중요
•vNIC를 여러 개 연결하면 성능이 높아질 꺼야
• Network 대역폭은 VM Resource에 종속
27. Shield VM
•Azure Data Center 에서 내 VM을 보진 않을까?
•Disk File을 유실해서 Data를 실제로 열어본다면?
•Windows – BitLocker
•Linux – DM-Crypt
29. Blob
Korea Central
Async
Korea Central Korea South
Async
Korea Central Korea South
LRS GRS RA-GRS
• 단일 Region내 3개 복제본
• Disk와 Node, Rack단위 장애
요소 분리하여 보호
• 쓰는 즉시 복제
• 매우 우수한 듀얼 RAID
• 두개 Region내 6개 복제본
• Region 단위 데이터를 보호
• 두번째 복제는 Async로 일어
남
• GRS + Read Access
• 별도의 Read Endpoint가 존
재
31. Azure가 접근 가능한 Resource는?
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Application
Data
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Application
Data
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Application
Data
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Application
Data
YourManaged
YourManaged
YourManagedAzureManaged
AzureManaged
AzureManaged
On-premise IaaS PaaS SaaS
YourManaged
Monitoring System
Networking
Storage
Servers
Virtualization
O/S
Middleware
Runtime
Application
Data
O/S
Middleware
Runtime
Application
Data
Application
Data Data
32. Azure Monitor
•기존 각 Resource에 존재한 Metric을 한 군데에
모아서 볼 수 있는 기능
•Audit 등 Monitoring에 필요한 모든 리소스의 모음
•Azure Status도 포함 됨
•OMS와 연동하여 추가 모니터링이 가능
•아직도 발전하는 중....
33. Alert
•기본적인 Monitoring Alert으로 임계 값 기준
•모 분모가 되는 데이터의 신뢰도를 고려하여 제작
•한번에 완벽한 Alert System을 구축할 수 없음
•E-mail Alert이 기본
•Webhook 주소 지정 시 해당 URL로 메시지 전달
•Runbook을 설정하여 Alert 발생 시 자동 처리도 가능
35. OMS / Security Center
•모든 Platform의 모니터링이 가능한 System
•Log 또는 Metric 기반으로 분석 또는 가시화 지원
•Security Center를 통해 보안에 대한 탐지 가능
•Near real time 분석으로 빠른 대응 가능
•설정에 따라 자동화된 처리 지원
40. VPN / Express Route
•On-premise와 Azure를 논리적으로 묶어줄 도구
•개발자 또는 Application이 Azure에 접근이 쉬워 짐
•VPN을 사용할 경우 ISP Issue에 대해 민감하게
반응해야 함으로 모니터링은 필수
•VPN 연결 시 VNet과의 통신이 자유로움
•Express Route의 경우 모든 Azure Service에 접근
가능
•Hybrid Cloud 어렵지 않아요.
50. 장애가 난다고!?
•Azure의 모든 Resource는 비정상 동작할 수 있음
•IaaS / PaaS / SaaS 등 서비스를 제공하기 때문에
보안 패치 또는 부득이한 재부팅이 필요
•언제나 Azure Status를 모니터링 할 필요가 있음
•내가 사용하는 서비스의 SLA는 꼭 확인이 필요
https://azure.microsoft.com/ko-kr/support/legal/sla/
52. Cloud... 정말 쌀까?
•Life Cycle이 2년 안쪽의 Spot성 Service에는 저렴
•Cloud가 저렴한 이유 중 가장 큰 요소는 인력비
•Virtualization Infrastructure를 구성할 수 있는
엔지니어가 있다면, Cloud는 오히려 과대 과금
시스템
•Azure는 모든 것을 해주는 것 같지만, 모든
제약사항을
53. 우리에게 중요한 건 서비스
•Cloud에서 서비스를 한다는 것은 모든 Resource는
HA구성이 되어야 함
•Infra 또는 Application의 단일 장애에 의해 전체
서비스
장애가 일어나지 않도록 구성되어야 함
•선 조치 후 분석을 위한 Log를 자세히 남기는 것이
중요
•Netflix에서 사용하는 Chaos Monkey의 도움도 고려