Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Microsoft Graph 웹후크 쉽게 이해하기: 끝없는 폴링 대신 실시간 알림 (AI 더빙)

Transcript

Microsoft Graph 웹후크 쉽게 이해하기: 끝없는 폴링 대신 실시간 알림 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?
0:08
이번 1월, M365 컨이더 커진 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 실용적인 지식을 함께 경험하세요.
0:18
뻔한 슬라이드 나즈루한 유행원은 없습니다.
0:21
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제를 다룹니다.
0:29
IT 전문가, 개발자, 비즈니스 리더 등 여러분 모두를 위한 세션이 준비되어 있습니다.
0:35
10일간의 긴 일정 동안 다양한 기술을 탐구하고 글로벌 커뮤니티와 교류할 수 있습니다.
0:40
라이브로 시청하고 조직에 바로 적용할 수 있는 실무 인사이트를 얻어가세요.
0:44
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 바로 등록하세요.
0:51
M365 con.net에 접속하여 오늘 바로 자리를 확보하세요.
0:56
주소는 M365 con.net입니다.
0:58
M365 con.net에서 참여하시고, 1월 라이브 세션에서 뵙겠습니다.
1:05
여러분 안녕하세요.
1:06
M365 FM 위 마이크로소프트 지식나겟, 날리지 너겟츠에 오신 것을 환영합니다.
1:10
저는 진행을 맡은 밀코 피터스입니다.
1:12
오늘의 주제는 마이크로소프트 365로 개발하는 사람이라면 누구나 들어봤지만,
1:15
명확하게 설명할 수 있는 사람은 드문 내용입니다.
1:17
그래프 웹북이란 도대체 무엇일까요?
1:19
왜 기존 방식 대신 웹북을 사용해야 할까요?
1:21
중요한 편지를 기다리고 있다고 상상해보세요.
1:23
우편함에 가보지만, 비어있습니다.
1:25
다시 돌아옵니다.
1:26
10분 뒤에 다시 확인합니다.
1:27
여전히 아무것도 없습니다.
1:28
하루 종일 이런 일을 반복하며 시간과 에너지를 낭비하게 되죠.
1:31
그게 바로 폴링, 폴링입니다.
1:32
이제 다른 세상을 상상해보세요.
1:33
편지가 도착하는 순간 우체부가 초인종을 누릅니다.
1:35
직접 확인할 필요가 없습니다.
1:36
대리 울리기만을 기다리면 되죠.
1:38
그게 바로 웹북입니다.
1:39
이번 에피소드가 끝나면 그래프 웹북이 무엇인지,
1:41
왜 지속적인 확인을 대체하는지,
1:42
그리고 전체 구조가 어떻게 작동하는지 이해하게 될 것입니다.
1:45
폴링의 문제점.
1:46
자세히 살펴보겠습니다.
1:47
웹북이 왜 중요한지 이해하려면,
1:49
왜 폴링이 비효율적인지 알아야 합니다.
1:51
오늘날 대부분의 애플리케이션은 이런 방식으로 작동합니다.
1:53
앱이 답변을 필요로 합니다.
1:54
마이크로소프트 그래프에 묻죠.
1:56
이봐, 새로운 사용자 있니?
1:57
그래프가 답합니다.
1:58
아니, 그러면 앱은 잠시 기다렸다가 다시 묻습니다.
2:01
이제 새로운 사용자 있니?
2:02
여전히 아니라고 합니다.
2:03
반복되는 이 과정이 바로 폴링입니다.
2:05
친구에게 소식이 있는지,
2:06
계속 전화를 거는 것과 같다고 생각하면 됩니다.
2:08
전화를 걸고,
2:09
상대가 받으면 물어보고,
2:10
없다고 하면 끊죠.
2:11
그리고 5분 뒤에 또 전화하고,
2:12
또 다시 반복합니다.
2:13
상대방의 시간과 여러분의 시간을 모두 낭비하는 셈입니다.
2:15
아마 상대방도 짜증이 날 겁니다.
2:17
이제 수천 개의 앱이 동시에 마이크로소프트 그래프를 상대로
2:19
이런 짓을 한다고 상상해보세요.
2:20
모든 앱이 몇 분마다 폴링하며,
2:22
똑같은 질문을 던지고,
2:23
똑같은 답변을 받습니다.
2:24
그건 너무 불필요한 소음입니다.
2:26
마이크로소프트는 너무 공격적인 폴링을,
2:27
스로틀링, 스로틀링, 이라 부르며,
2:29
일부 개발자들은,
2:30
그래프 강옥, 그래프 제일, 이라고도 부릅니다.
2:31
요청을 너무 많이 보내면,
2:32
마이크로소프트는,
2:33
자, 이제 그만, 이라고 제동을 겁니다.
2:35
앱이 보내는 호출 횟수를 제한하는 것이죠.
2:37
일단 스로틀링이 걸리면 모든 것이 느려집니다.
2:39
정상적인 요청들이 쌓이게 됩니다.
2:40
앱이 제대로 작동하지 않게 되죠.
2:42
언제 풀릴지는 아무도 모릅니다.
2:44
도대체 얼마나 많은 요청을 말하는 걸까요?
2:45
앱이 사용자 변경사항을 확인하기 위해,
2:47
5분마다 폴링한다고 가정해봅시다.
2:48
시간당 12번의 요청이 발생합니다.
2:50
하루 종일이면 288번이며,
2:52
이건 단 하나의 리소스에 대한 것입니다.
2:54
그룹, 파일, 메시지,
2:56
캘린더 일정까지 폴링한다면,
2:57
하루에 수천 번이 불필요한 요청이 쌓입니다.
3:00
대부분은 변경사항이 없어 아무런 결과도 반환하지 않지만,
3:02
호출은 계속 이루어집니다.
3:04
그리고 중요한 점은,
3:05
5분마다 폴링해도 실시간 업데이트를 받을 수 없다는 것입니다.
3:08
마지막 폴링 1분 후에 변경사항이 생길 수도 있습니다.
3:11
그러면 다음 4분 동안은 그 사실을 알 수 없죠.
3:13
리소스는 낭비하고 골든타임은 놓치게 되는 겁니다.
3:15
이제 이벤트 기반 방식과 비교해봅시다.
3:17
몇 분마다 마이크로소프트 그래프를 호출하는 대신,
3:19
마이크로소프트 그래프가 당신을 호출할 때까지 기다리는 방식입니다.
3:22
리스너를 설정하는 것이죠.
3:23
변경사항이 생기면 그래프가 알림을 보내줍니다.
3:25
직접 전화를 걸 필요가 없습니다.
3:26
벨이 울릴 때 받기만 하면 됩니다.
3:28
웹북, 웹북, 이란 무엇일까요?
3:29
웹북이란 정확히 무엇일까요?
3:31
가장 간단하게 정의해보겠습니다.
3:33
웹북은 어떤 사건이 발생했을 때 자동으로 전송되는 HTTP 요청입니다.
3:36
요청하지 않아도 서버가 알아서 데이터를 밀어넣어줍니다.
3:39
초인종을 생각하면 이해가 쉽습니다.
3:41
밖에 서서 몇 분마다 문을 두드려 확인할 필요가 없습니다.
3:43
초인종을 설치하세요.
3:44
누군가 도착하면 초인종을 누를 겁니다.
3:46
당신은 벨소리를 듣고 문을 열어주면 됩니다.
3:47
초인종이 당신 대신 감시를 해주는 셈이죠.
3:49
웹북은 때때로 역방향 API라고도 불립니다.
3:52
일반 API는 앱이 요청하면 서버가 응답하는 방식입니다.
3:55
앱이 주도권을 쥐고 있죠.
3:56
웹북은 서버가 앱으로 요청을 보냅니다.
3:59
서버가 주도권을 가지고 기다리게 하는 대신 데이터를 바로 보내주는 것입니다.
4:02
마이크로소프트 그래프 도웹북을 사용하는데
4:04
마이크로소프트는 이를 변경 알림, 체인지 노티피케이션즈 이라고 부릅니다.
4:07
이름만 다를 뿐 같은 개념입니다.
4:09
마이크로소프트 365에서 변경사항이 생기면
4:11
그래프가 당신이 제공한 URL로 HTTP 포스트를 보냅니다.
4:15
그 포스트 요청 안에는 무엇이 변경되었는지에 대한 정보가 담겨 있습니다.
4:18
알림을 받을 수 있는 항목은 매우 다양합니다.
4:20
테넌트의 새 사용자가 생성되거나
4:21
시어포인트 위 파일이 업데이트되거나
4:23
팀즈에서 메시지가 전송되거나
4:25
일정 이벤트가 변경되거나
4:26
그룹의 새 멤버가 추가되는 경우 등이 있습니다.
4:28
이 모든 상황에서 알림을 트리거할 수 있습니다.
4:30
실제 사례를 하나 들어보겠습니다.
4:32
시간추적 시스템을 운영하는 회사가 있다고 가정해봅시다.
4:34
새 직원이 입사할 때 자동으로 계정을 생성하고 싶습니다.
4:37
웹북크가 없다면 몇 분마다 사용자 엔드포인트를 폴링하여
4:40
새로운 인원이 있는지 확인해야 합니다.
4:41
웹북크를 사용하면 사용자 생성 이벤트에 구독할 수 있습니다.
4:44
누군가 합류하면 그래프 가앱에 알림을 보냅니다.
4:47
앱은 알림을 수신하고 검증한 뒤 몇 주 안에 계정을 생성합니다.
4:51
폴링도 낭비되는 요청도 없습니다.
4:53
다른 예시를 보겠습니다.
4:55
영수증이 업로드되는 시어포인트 문서 라이브러리가 있습니다.
4:57
웹북크가 없다면 라이브러리를 지속적으로 폴링해야 합니다.
5:00
웹북크를 사용하면 파일이 추가되는 즉시 그래프가 알려줍니다.
5:03
앱은 파일을 가져와 영수증 인지 확인하고 자동으로 처리합니다.
5:06
그것이 바로 웹북크의 강력함입니다.
5:08
앱이 계속해서 새로운 소식 있나요? 라고 묻는 대신
5:11
무언가 발생했을 때 시스템이 알려주도록 하는 것입니다.
5:13
더 효율적이고 안정적이며 훨씬 빠릅니다.
5:16
마이크로소프트 그래프 웹북크 작동 방식
5:18
이제 웹북크가 무엇인지 웹북링이 문제인지 아셨을 겁니다.
5:21
마이크로소프트 그래프 웹북크가 실제로 어떻게 작동하는지 살펴보겠습니다.
5:24
흐름은 생각보다 간단합니다.
5:26
핵심은 구독, 알림, 그리고 여러분의 엔드포인트 이 세 가지입니다.
5:30
첫째, 구독을 생성합니다.
5:32
마이크로소프트 그래프에 이 특정 항목이 변경될 때 알려져 라고 요청하는 것입니다.
5:36
무엇을 지켜보고 어디로 소식을 보낼지 그래프에 세부 정보를 제공합니다.
5:39
알림을 신청하는 것과 같다고 생각하면 됩니다.
5:41
관심있는 항목을 시스템에 알리고 연락처 정보를 제공하는 것이죠.
5:44
둘째, 마이크로소프트 그래프가 해당 리소스를 지켜봅니다.
5:46
변경사항을 모니터링합니다.
5:48
사용자 생성, 파일 업데이트, 메시지 수신과 같은 이벤트가 발생하면 그래프가 이를 감지합니다.
5:52
셋째, 그래프가 알림을 보냅니다.
5:54
제공하신 URL 로 HTTP 포스트를 전송합니다.
5:57
해당 포스트에는 무엇이 변경되었는지에 대한 정보가 포함되어 있습니다.
6:00
여러분의 엔드포인트가 이를 수신하고 애플리케이션이 처리합니다.
6:03
전반적인 흐름은 간단합니다.
6:04
구독하고 그래프 가지켜보고 변경사항이 생기면 그래프가 포스트를 보냅니다.
6:08
이 세 가지 구성요소를 조금 더 자세히 살펴보겠습니다.
6:10
구독은 알림을 받기 위한 여러분의 요청입니다.
6:13
테넌트에 새 사용자가 추가되면 알려져 라고 말하는 것과 같습니다.
6:16
요청을 마이크로소프트 그래프로 보내면 그래프가 이를 저장합니다.
6:19
그 시점부터 그래프가 여러분을 대신해 지켜보기 시작합니다.
6:22
알림은 그 자체로 경고이며 그래프가 귀하의 엔드포인트로 보내는 HTTP 포스트입니다.
6:26
포스트 부문에는 어떤 리소스가 변경되었는지 어떤 유형의 변경이 발생했는지 언제 발생했는지와 같은 변경사항에 대한 세부정보가 포함됩니다.
6:32
귀하의 엔드포인트는 열어두는 문과 같습니다.
6:34
이 포스트 요청을 받도록 구성된 서버의 URL입니다.
6:37
그저 수신하고 빠르게 응답하기만 하면 됩니다.
6:39
그게 전부입니다.
6:40
수신측의 복잡한 로직이 필요하지 않습니다.
6:42
알림을 받고 확인하고 처리하기만 하면 됩니다.
6:45
이제 이것을 폴링과 비교해 보십시오.
6:46
폴링을 사용하면 수백개의 겟 요청을 보내 각각 새로운 것이 있나요? 라고 물어봐야 합니다.
6:50
대부분의 경우 답변은 아니요입니다.
6:52
웹북을 사용하면 알림이라는 단 하나의 포스트만 있으면 됩니다.
6:55
그게 전부입니다.
6:56
수백개 대신 하나의 메시지면 충분합니다.
6:58
효율성 차이는 엄청나며 엔드포인트가 복잡할 필요도 없습니다.
7:01
공개적으로 액세스 가능하고 HTTPS를 사용하며 빠르게 응답하기만 하면 됩니다.
7:05
빠르게 응답한다는 것이 무엇을 의미하는지는 곧 이야기하겠습니다.
7:08
하지만 핵심 아이디어는 간단합니다.
7:10
엔드포인트가 대기하고 그래프가 호출하고 귀하가 응답하면 끊입니다.
7:14
구독 만들기.
7:15
그렇다면 이것을 실제로 어떻게 설정할까요?
7:17
구독을 만드는 과정을 단계별로 살펴보겠습니다.
7:20
먼저 마이크로소프트 그래프 위 특정 URL로 HTTP 포스트 요청을 보내는 것으로 시작합니다.
7:24
해당 URL은 HTTPS colon slash graph.microsoft.com slash v1.0 slash subscriptions입니다.
7:29
구독 엔드포인트에 바로 포스트를 보내는 것입니다.
7:32
해당 요청 본문에 구독하려는 세부 정보를 포함합니다.
7:35
제공해야 할 4가지 주요 필드가 있습니다.
7:37
첫 번째는 알림 URL입니다.
7:39
이것은 귀하의 엔드포인트 URL이며 마이크로소프트 그래프가 알림을 보낼 위치입니다.
7:43
그래프가 인터넷에서 도달할 수 있어야 하므로 HTTPS여야 하며 공개적으로 액세스할 수 있어야 합니다.
7:47
두 번째는 리소스입니다.
7:49
이것은 그래프에게 무엇을 지켜봐야 할지 알려줍니다.
7:51
마이크로소프트 그래프 리소스 경로를 지정합니다.
7:53
예를 들어 사용자 변경 사항을 감시하려면 유저즈를,
7:56
받은 편지함의 새 이메일을 감시하려면 미, 메일 폴더즈, 인박스, 메세지즈를 지정합니다.
8:00
리소스는 그래프에게 귀하가 무엇에 관심이 있는지 정확히 알려줍니다.
8:03
세 번째는 변경 유형입니다.
8:04
이것은 그래프에게 어떤 종류의 변경 사항을 알릴지 알려줍니다.
8:07
생성, 크리에이티드, 업데이트, 업데이티드, 삭제, 딜리티드 또는 이들의 조합을 지정할 수 있습니다.
8:11
따라서 새 사용자가 생성되는 것에만 관심이 있다면 변경 유형을 크리에이티드로 설정합니다.
8:14
업데이트도 중요하다면 크리에이티드와 업데이티드로 설정합니다.
8:17
네 번째는 만료 날짜와 시간입니다.
8:19
구독은 영원히 지속되지 않으므로 이것은 구독이 만료되는 시점입니다.
8:23
날짜와 시간을 설정하면 그래프는 그 시점 이후로 알림 전송을 중단합니다.
8:27
최대 기간은 감시 중인 리소스에 따라 다릅니다.
8:29
사용자 및 그룹의 경우 최대 기간은 약 3일입니다.
8:32
SharePoint나 OnDrive 위 드라이브 항목은 최대 30일까지 가능합니다.
8:36
각 리소스 유형별 문서를 확인해야 합니다.
8:38
언급할 가치가 있는 선택적 필드인 클라이언트 상태, 클라이언트 스테이트, Vs입니다.
8:41
이는 직접 만드는 비밀 문자열입니다.
8:43
원하는 무엇이든 될 수 있습니다.
8:45
이미 문자열, GUID 등 선택하기 나름입니다.
8:48
마이크로소프트 그래프는 알림을 엔드포인트로 보낼 때 마다이 값을 포함하며
8:52
여러분은 이를 사용해 알림이 구독에서 온 것인지 검증합니다.
8:55
누군가 엔드포인트에 가짜 알림을 보내려 하면
8:57
클라이언트 상태 값이 일치하지 않아 즉시 거부할 수 있습니다.
9:00
간단하지만 중요한 보완 조치입니다.
9:03
구독을 만드는 것은 신문배달을 신청하는 것과 같습니다.
9:06
신문사의 주소를 알려주는 것과 같습니다.
9:08
그것이 바로 알림 URL입니다.
9:10
원하는 섹션을 알려주는 것은 리소스 및 변경 유형이며
9:13
배달 기간을 정하는 것은 만료 일시입니다.
9:16
그것이 바로 만료 일시입니다.
9:17
나머지는 신문사가 알아서 처리합니다.
9:19
하지만 문제는 구독이 만료된다는 점입니다.
9:21
구독을 생성하고 잊어버려서는 안 됩니다.
9:24
만료 시간이 지나면 그래프는 알림 전송을 중단하고
9:27
구독은 사라집니다.
9:28
알림을 계속 받으려면 구독 엔드포인트에
9:32
새 만료 일시를 포함한 패치 요청을 보내
9:34
구독을 갱신해야 합니다.
9:36
즉 구독 생성은 첫 단계일 뿐 마지막이 아닙니다.
9:39
수명 주기를 관리해야 합니다.
9:41
이에 대해서는 나중에 더 자세히 다루겠습니다.
9:43
유효성 검사 핸드쉐이크입니다.
9:44
구독이 활성화되기 전 절대 건너 뜰 수 없는 단계가 하나 있습니다.
9:48
마이크로소프트 그래프는 구독 요청을 받는 즉시
9:50
알림을 보내지는 않습니다.
9:51
먼저 엔드포인트가 실제 존재하며
9:53
알림을 받을 준비가 되었는지 확인해야 합니다.
9:55
작동 방식은 다음과 같습니다.
9:56
구독을 생성하기 위해 포스트 요청을 보내면
9:58
마이크로소프트 그래프는 즉시 알림 url로 테스트 포스트를 보냅니다.
10:02
그 테스트 포스트에는 발리데이션 토큰이라는 퀄이
10:05
매개변수가 포함됩니다.
10:06
이는 단순히 임의의 문자열입니다.
10:08
엔드포인트는 해당 토큰을 받아 일반 텍스트 응답으로
10:10
다시 보내야 하며 반드시 10초 이내에 수행해야 합니다.
10:12
택배기사가 물건을 배달하는 상황을 생각해보세요.
10:15
기사가 문 앞에 와서 여기가 맞나요?
10:16
라고 묻습니다.
10:17
확인해 주시겠어요?
10:19
서명을 해야 합니다.
10:20
그렇지 않으면 기사는 그냥 돌아갑니다.
10:21
기사는 물건을 두고 가지 않습니다.
10:23
그냥 떠나버립니다.
10:24
여기서 일어나는 일도 정확히 이와 같습니다.
10:26
마이크로소프트 그래프는 중요한 알림을 보내려 합니다.
10:28
라고 말하는 셈입니다.
10:29
올바른 주소에 올바른 수신자인지 증명하세요.
10:32
엔드포인트는 검증 토큰을 그대로 반환하여
10:34
그래프에 네 여기 있습니다.
10:37
라고 응답합니다.
10:38
수신 대기 중입니다.
10:39
알림을 보내주세요.
10:40
이제 많은 개발자가 실수하는 부분을 말씀드리겠습니다.
10:43
검증 토큰은 json이나 html이 아닌 일반 텍스트
10:46
즉 평문으로 반환해야 합니다.
10:47
그리고 응답에는 반드시 텍스트, 플레인으로 설정된 콘텐츠 유형 헤더가 있어야 합니다.
10:51
json으로 감싸거나 어떤 방식으로든 인코딩하여 보내면 검증에 실패합니다.
10:55
구독이 생성되지 않을 것입니다.
10:57
마이크로소프트 그래프가 오류를 반환하면 무엇이 잘못되었는지 알 수 없어 곤란해집니다.
11:00
알아두어야 할 또 다른 기술적 세부사항이 있습니다.
11:02
마이크로소프트 그래프 위 검증 서비스는 tls1.3을 안정적으로 지원하지 않습니다.
11:06
tls1.2로 협상합니다.
11:08
따라서 엔드포인트가 tls1.3 연결만 허용하면
11:11
애플리케이션 코드가 실행되기도 전에 검증 핸드 쉐이크가 실패합니다.
11:14
최소한 검증 단계에서는 엔드포인트가 tls1.2를 지원하도록 해야 합니다.
11:19
그 이후에는 실제 알림에 대해 원하는 tls버전을 적용할 수 있습니다.
11:23
다행인 점은이 검증 핸드 쉐이크가 구독당 한 번만 발생한다는 것입니다.
11:27
알림이 올 때 마다 처리해야 하는 것이 아니라 처음 한 번만 처리하면 됩니다.
11:31
그래프가 엔드포인트가 유효함을 확인하면
11:33
해당 구독이 유지되는 동안에는 이를 신뢰합니다.
11:36
따라서 이 과정을 한 번만 제대로 처리하면 됩니다.
11:39
알림 처리와 보안, 검증 핸드 쉐이크가 완료되고 구독이 활성화되면
11:43
마이크로소프트 그래프가 알림을 보내기 시작합니다.
11:46
그렇다면 실제로 알림은 어떤 모습일까요?
11:48
변경 사항이 발생하면 그래프는 본문에 json 객체를 담아
11:52
엔드포인트로 http 포스트를 보냅니다.
11:54
해당 객체에는 변경된 리소스, 생성 업데이트 삭제와 같은 변경 유형,
11:59
타임스탬프가 포함됩니다.
12:00
또한 구독을 생성할 때 설정한 클라이언트 상태 값도 포함됩니다.
12:04
그것이 바로 메시지가 실제임을 확인하는 비밀 문자열입니다.
12:07
알림이 도착했을 때 가장 먼저 해야 할 일은 다음과 같습니다.
12:10
클라이언트 상태를 검증하는 것입니다.
12:11
알림에 포함된 값과 구독 생성 시 저장해둔 비밀 값을 비교하세요.
12:15
일치하지 않으면 가짜일 수 있으므로 즉시 폐기하세요.
12:18
누군가 잘못된 데이터를 처리하도록 시스템을 속이려는 것일 수 있습니다.
12:21
엔드포인트가 공개 인터넷상에 있기 때문에 이는 매우 중요합니다.
12:24
url을 아는 사람이라면 누구든 포스트를 보낼 수 있습니다.
12:27
클라이언트 상태 검증이 없으면 실제 마이크로소프트 그래프 알림과 가짜 알림을 구분할 방법이 없습니다.
12:33
간단한 확인 절차이지만 이것이 첫 번째 방어선입니다.
12:36
알림이 정상임을 확인했다면 신속하게 응답해야 합니다.
12:39
마이크로소프트 그래프는 3초 이내에 200번대 http 응답을 기대합니다.
12:43
더 오래 걸리면 그래프가 이를 감지합니다.
12:45
이런 일이 너무 자주 발생하면 그래프는 여러분을 다르게 대하기 시작합니다.
12:48
스로틀링, 스로틀링 방식은 다음과 같습니다.
12:50
10분 동안 응답의 10% 이상이 3초를 초과하면
12:53
마이크로소프트 그래프는 기아의 엔드포인트를 느림으로 표시합니다.
12:56
그러면 새로운 알림이 10분 동안 지연됩니다.
12:59
결국 도착은 하지만 실시간 전달은 불가능해집니다.
13:03
상황이 더 악화되어 응답의 15% 이상이 10초를 넘어가면
13:06
그래프는 기아의 엔드포인트를 삭제됨으로 표시합니다.
13:09
이 상태에서는 알림이 10분 동안 완전히 삭제됩니다.
13:12
가장 무서운 부분입니다.
13:13
삭제된 알림은 복구할 수 없습니다.
13:15
사라져버리면 다시는 되찾을 수 없습니다.
13:17
통화 중인 전화선이라고 생각하세요.
13:19
빨리 받지 않으면 발신자는 나중에 다시 시도합니다.
13:22
하지만 끝내 받지 않으면 발신자는 결국 포기합니다.
13:24
마이크로소프트 그래프가 발신자이고 여러분의 엔드포인트가 전화기입니다.
13:28
빨리 받지 않으면 메시지를 잃을 위험이 있습니다.
13:30
그렇다면 모범 사례는 무엇일까요?
13:32
즉시 수신 확인을 하고 비동기식으로 처리하세요.
13:34
엔드포인트는 클라이언트 상태를 확인하고
13:36
알림을 수락한 뒤 200 또는 200이 응답을 가능한 한 빨리 반환해야 합니다.
13:41
그런 다음 알림을 Q에 넣어 백그라운드에서 처리하세요.
13:44
에이저 Q, 서비스 버스, 심지어 간단한 데이터베이스 테이블도 좋습니다.
13:48
핵심은 응답 주기를 빨리 끝내고
13:49
백그라운드 작업자가 무거운 작업을 처리하도록 하는 것입니다.
13:52
보안 관련 한 가지 더, 엔드포인트는 반드시 HTTPS여야 하며 예외는 없습니다.
13:56
마이크로소프트 그래프는 HTTP 엔드포인트로는 알림을 보내지 않습니다.
13:59
또한 엔드포인트는 공개적으로 액세스할 수 있어야 합니다.
14:02
방화벽이나 VPN 뒤에 있다면 그래프가 접근할 수 없습니다.
14:05
개발 중에는 N그럭 같은 도구를 사용하여 로컬 머신으로 공개터널을 생성할 수 있습니다.
14:09
하지만 운영 환경에서는 엔드포인트가 그래프가 찾을 수 있는 곳에 위치해야 합니다.
14:14
알림 수명 주기 유지하기,
14:15
구독을 설정하고 알림이 원활하게 흐르며 모든 것이 좋아 보일 겁니다.
14:19
하지만 많은 사람들이 간과하는 부분이 있습니다.
14:22
구독에는 만료 날짜가 있습니다.
14:24
영원히 지속되지 않습니다.
14:25
모니터링하는 리소스에 따라 최대 구독 기간은 보통 3일에서 7일 사이입니다.
14:30
셰어포인트 위 드라이브 항목 같은 일부 리소스는 최대 30일까지 가능합니다.
14:33
하지만 핵심은 연구적이지 않다는 것입니다.
14:36
구독을 생성하고 잊어버려서는 안 됩니다.
14:38
잡지 구독과 비슷하다고 생각하세요.
14:40
가입하고 잡지를 받기 시작하면 모든 것이 좋습니다.
14:43
하지만 구독이 끝나기 전에 갱신하지 않으면 잡지는 더 이상 오지 않습니다.
14:46
여기서도 마찬가지입니다.
14:47
구독이 만료되면 마이크로소프트 그래프는 알림 전송을 중단합니다.
14:50
아무런 반응이 없다는 것을 깨닫기 전까지는 이를 인지하지 못할 수도 있죠.
14:53
따라서 갱신 전략이 필요합니다.
14:55
갱신 방법은 간단합니다.
14:56
구독 아이디를 사용하여 구독 엔드포인트에 패치 요청을 보내고
14:59
만료 날짜와 시간을 미래의 새로운 날짜로 업데이트하면 됩니다.
15:02
그러면 구독 기간이 연장됩니다.
15:05
현재 만료일이 지나기 전이라면 얼마든지 반복할 수 있습니다.
15:08
마이크로소프트 그래프는 수명 주기 알림이라는 기능을 통해 이를 도와줍니다.
15:13
구독을 생성할 때 수명 주기 알림 url이라는 별도의 url을 제공할 수 있습니다.
15:18
마이크로소프트 그래프는 특정 상황이 발생하면 이 url로 알림을 보냅니다.
15:22
구독이 곧 만료되거나 액세스 토큰이 만료 예정이거나 앱의 권한이 변경될 때처럼 말이죠.
15:27
이러한 수명 주기 알림은 미리 알려주는 역할을 합니다.
15:30
구독이 언제 끝날지 추측할 필요가 없습니다.
15:32
그래프가 구독이 몇 시간 뒤에 만료됩니다.
15:35
갱신이 필요할 수 있습니다.
15:36
라고 알려주니까요.
15:37
잡지사에서 구독이 곧 끝난다는 알림을 보내주는 것과 같습니다.
15:41
주의를 기울이고 있다면 매우 유용하죠.
15:43
하지만 만약 문제가 발생하면 어떻게 될까요?
15:45
엔드포인트가 잠시 중단되거나 너무 느려서 알림이 누락될 수도 있습니다.
15:49
그럴 땐 어떡하죠?
15:50
거기서 델타퀴리가 필요합니다.
15:51
델타퀴리는 마지막 확인 이후 무엇이 변경되었나요?
15:54
라고 물어볼 수 있는 마이크로소프트 그래프의 별도 기능입니다.
15:56
그리고 다른 것은 제외하고 변경사항만 반환합니다.
15:59
작동방식은 다음과 같습니다.
16:00
리소스, 예, 사용자에 대해 델타퀴리를 처음 실행하면
16:03
그래프는 테넌트의 모든 사용자를 반환합니다.
16:05
하지만 델타 링크라는 특별한 링크도 추가로 반환합니다.
16:08
이 링크를 저장해두세요.
16:09
다음번에 동일한 커리를 실행할 때의 델타 링크를 사용합니다.
16:12
그러면 모든 사용자를 다시 가져오는 대신
16:14
마지막 요청 이후에 변경된 사용자만 받게 됩니다.
16:16
신규 사용자, 업데이트된 사용자, 삭제된 사용자가 여기에 해당합니다.
16:19
그게 전부입니다.
16:20
매번 백과 사전 전체를 읽는 대신
16:22
새로운 소식, 목록만 확인한다고 생각하면 됩니다.
16:24
훨씬 빠르고 데이터도 적게 듭니다.
16:26
이제 스마트한 패턴을 알려드릴게요.
16:28
웹북과 델타퀴리를 결합하는 것입니다.
16:30
웹북을 사용하여 변경사항을 알리고
16:35
설명해드리겠습니다.
16:36
웹북은 빠르지만 완벽하지는 않습니다.
16:37
알림이 유실되거나 구독이 만료되거나
16:39
엔드포인트가 다운될 수 있기 때문이죠.
16:41
하지만 델타퀴리는 신뢰할 수 있습니다.
16:42
언제든 실행할 수 있으며
16:43
마지막 확인 이후 변경된 모든 목록을 가져올 수 있습니다.
16:46
따라서 알림을 놓지 더라도 나중에 따라잡을 수 있습니다.
16:49
일반적인 흐름은 다음과 같습니다.
16:51
사용자 변경에 대한 웹북 구독을 설정하세요.
16:53
초기 델타퀴리를 실행하여
16:54
기준 상태를 가져오고 델타 링크를 저장합니다.
16:57
사용자 변경을 알리는 웹북가 도착하면
16:58
저장된 델타 링크를 사용하여 델타퀴리를 실행하세요.
17:01
그러면 정확한 변경사항을 얻을 수 있습니다.
17:03
변경사항을 처리한 다음
17:04
해당 응답에서 새로운 델타 링크를 저장합니다.
17:06
다음번에 웹북가 오면 이 과정을 반복합니다.
17:09
알림을 놓치거나 구독이 만료되더라도
17:11
델타퀴리를 다시 실행하기만 하면 됩니다.
17:13
놓친 모든 정보를 얻을 수 있습니다.
17:15
일종의 안전장치인 셈입니다.
17:16
웹북은 속도를 제공하고
17:18
델타퀴리는 안정성을 제공합니다.
17:19
이 둘은 함께 사용하면 매우 강력합니다.
17:21
실제 사례와 다음 단계입니다.
17:24
내일 새로운 직원이 회사에 입사한다고 상상해보세요.
17:26
인사팀 담당자가 마이크로소프트 엔트라 아이디에서
17:29
계정을 생성하면
17:30
그 하나의 동작으로 연쇄 반응이 시작됩니다.
17:33
사용자 변경에 대한 웹북 구독을 설정했다면
17:34
마이크로소프트 그래프가 즉시 이를 감지하여
17:37
엔드포인트로 포스트 요청을 보냅니다.
17:38
그 다음 벌어지는 일은 다음과 같습니다.
17:40
엔드포인트가 알림을 수신하고
17:42
클라이언트 상태를 검증한 후
17:43
비밀각과 일치하면 정상적인 요청임을 알 수 있습니다.
17:46
3초 이내에 202 액셉티드 응답을 반환하여 알림을 확인하고
17:50
배경 작업자가 이를 처리합니다.
17:52
작업자는 사용자가 생성되었음을 확인하지만
17:54
알림에 모든 세부 정보가 포함되지는 않으므로
17:57
저장된 델타 링크로 델타 커리를 실행합니다.
17:59
그러면 새 사용자의 전체 정보인 이름
18:01
이메일, 부서, 직함, 관리자 등
18:03
필요한 모든 항목이 반환됩니다.
18:05
이제 작업자는 그 정보를 바탕으로
18:07
파사근태 관리 시스템에 새 직원의 계정을 생성합니다.
18:10
환영 이메일을 보냅니다.
18:12
적절한 배포 목록에 해당 직원을 추가합니다.
18:14
이 모든 과정은 인사팀이 엔트라 아이디에서
18:16
계정을 생성한 후 몇 조 내에 이루어집니다.
18:18
폴링은 없습니다. 수동 단계도 없습니다.
18:20
지연도 없습니다.
18:21
반대의 경우를 생각해보세요.
18:23
웹북크가 없다면 몇 분마다 사용자 엔드포인트를 폴링해야 하며
18:26
하루에 수백 번 요청을 보내야 합니다.
18:27
그래도 새 사용자를 확인하는데 몇 분이 걸릴 수 있습니다.
18:30
웹북크를 사용하면 즉시 처리됩니다.
18:32
알림 한 번, 델타 커리 한 번 이면 끝납니다.
18:34
그것이 진정한 가치입니다.
18:35
시스템이 더 빠르고 효율적으로 변하며
18:37
제한, 스로틀링에 걸릴 확률도 낮아집니다.
18:39
끊임없이 그래프에 업데이트를 묻는 대신
18:40
무슨 일이 생기면 그래프가 알려주도록 하는 것입니다.
18:43
통합을 구축하는 방식의 근본적인 변화입니다.
18:45
이제 여러분이 시도해볼 것을 제안합니다.
18:47
현재 폴링 방식으로 처리 중인 프로세스 하나를 떠올려보세요.
18:49
공용 사소함에서 새 이메일을 확인하고 계신가요?
18:52
셰어포인트 라이브러리에서 파일 변경 사항을 확인하고 계신가요?
18:55
인사 시스템의 사용자 업데이트를 모니터링하고 계신가요?
18:57
폴링 대신 웹북을 사용할 수는 없을까요?
18:59
대부분의 경우 가능하며
19:00
모든 것을 직접 구축할 필요는 없습니다.
19:02
빅�빅 الر jut Foods
19:05
기술을 служ업을 그에 Panetta
19:05
육지의 사용자 업데이트를 통해
19:06
원하는 방법 주변 pelo 펴링
19:08
기술을 사용하는 방법을 바라볼 것이ございます.
19:09
London
19:10
버전
19:11
uses
19:13
다
19:15
문한
19:17
유
19:26
세
19:29
이메일