<410 Step Functions 개요>
> workflow 를 State Machine 으로 모델링 할 수 있는 것 (1 state machine per workflow)
>> 상품 주문 / 데이터 처리 / 앱 내 로직 처리 등 원하는 프로세스에 사용 가능
>> 어떤 조건에서, 어떤 일이 일어나는지, 그 뒤에 어떤 일이 일어나는지 등을 워크플로우로 정의하면 됨
>> Workflow 는 JSON 으로 정의하고, 이에 대한 시각화도 지원된다
> Workflow 의 각 단계 (ex: 람다 함수, ECS 내의 Task, DD에 데이터 삽입 등) 를 Step Function 이 Orchestration 해준다
> Workflow trigger 을 위해서는 SDK API, API Gateway, CW Event 등이 사용된다
<Task States>
> 위그림에서 처럼 박스들이 표시되어 있는데, Step Function 은 이처럼 Task 로 구성된다
> State Machine 에서 특정 작업을 Invoke 하기 위해서 사용됨
>> ex: 람다 함수, Batch 작업, DD 작업, SNS/SQS, ECS Task 등등
> Activity 를 Run 할 수도 있다 (실행중인 활동?) (AWS 내의 SWF 라는 리소스와 유사하다고 함)
>> ex : EC2, ECS, On-premise 등
>> 대상 서버는 Step Function 으로 부터 작업을 가져와 작업을 수행하고 결과를 응답하는 그림
>> 서버가 Step Function 으로 부터 작업을 가져오는 것이므로 훨씬 더 자유롭게 원하는 일을 수행 가능
<EX : 람다 호출 하는 Task>
> 위 JSON 의 유형은 Task 이며, 리소느는 Lambda 함수 호출이다
> 함수에 Payload 를 입력값으로 전달하는 모습 (trigger 시 stdin)
> 그 이후로는 NEXT_STATE (다음 상태로 넘어감) 하게 정의되어 있고, timeout 이 발생했는지 확인하도록 한다
<Step Function - States>
> Choice State - 특정 브랜치 (혹은 기본 브랜치) 로 보낼 조건을 테스트
> Fail / Succeed State - 성공 / 실패 일 경우 Step Function 을 중지
> Pass State - input 을 output 에게 단순히 전달 / 고정 data 주입 등을 수행 (어떤 작업을 하진 않음)
> Wait State - 특정 시간동안, 혹은 특정 시각/날짜 도달까지 Workflow 를 멈춘다
> Map State - Step 을 동적으로 반복(?)
> Parallel State - 브랜치의 수행을 병렬적으로 진행
> 알아야 할 내용 : 병렬 상태!! 가 중요!
> 예시인데, 다음과 같이 흐름을 볼 수 있다
>> JOB 이 완료되지 않으면 지속 X Second Wait 하는 걸 볼 수 있다
>> Job 이 완료되거나 Fail 하거나 Workflow 가 종료되는 것을 알 수 있다
> Step Function 은 전체적으로 행해져야 하는 일을 작업들을 (Task State) 조율하고, State Machine 이 어떻게 정의되어야 하는지 정의한다.
>> 그냥 람다로 다 때리면 되는거 아님? 싶겠지만 실습에서 왜 필요한지 조금 알게 된다고 함
--------------------------------------------
<411 Step Function 실습>
> Step Function 으로 이동하면 다이어그램과, Design, 그리고 이에 대한 코드 (ASL) 즉, JSON 문서를 확인할 수 있다
> 예시로, 다음과 같은 구문을 확인해볼 수 있다
"States": {
...
"Hello World Ex":{
"Comment" : "이 state 에 대한 설명",
"Type": "Choice",
"Choices" : [
{
"Variable": "$.IsHelloWorldEx",
"BooleanEquals": true,
"Next": "Yes" // Yes State 으로 이동 (State 의 이름임)
},
{
"Variable": "$.IsHelloWorldEx",
"BooleanEquals": false,
"Next": "No" //No state 으로 이동
},
],
...
"Yes": {
"Type": "Pass",
...
> 이 구문에 해당하는 다이어그램은 다음과 같다
> 특정 변수가 True, False 를 확인해서 다음 State 로 이동
> 어쨌든 이렇게 Step Function 을 만들 수 있고, 이에 대해 Start Execution 을 할 때 input variable 들을 전달할 수 있다
>> 가령, 위 예시 실행시, stdin 변수로 "IsHelloWorldEx":false 인 JSON 문서를 전달했다면, False 로 인해 No State 로 이동시키고 Failure 을 발생시켰을 것이다.
--------------------------------------------
<412 Step Function Invoke Lambda 실습 >
> 새로운 Step Function 을 생성하면 좌측에 있는 UI 들을 끌어와 Lambda Invoke 등을 만들어 볼 수 있다.
> 위 그림은 강사의 제공 JSON 을 붙여넣은 것
> 람다 함수를 넣으면, 우측에서 바로 람다 Invoke 를 구성할 수 있다 (람다 함수 선택)
> 위 예제는 람다 함수는 who 라는 variable 을 받아서 콘솔에 출력한다 (딱히 람다가 하는 일은 없 ㅋㅋ 걍 출력)
> 그리고 람다의 출력에 대하여 "Stephane" 을 포함하는 값인 경우 Pass State 으로 이동하고, 아닐 겨우 Fail State 으로 이동하는 Workflow 이다
>> Lambda Invoke 는 따로 구성을 해주는데, 이 때 JSON 으로 보면 function name 은 비워져 있으므로, 만든 람다 함수의 ARN 을 붙여넣는다.
> 하다보면 State Machine 이 또 Lambda 를 호출하며, X-Ray 를 사용하므로 IAM Role 이 필요하다고 한다
>> 생성한다고 확인 버튼 뜨면 생성해주면 자동으로 필요한 권한들을 묶은 Role 을 만들어서 엮어준다.
> Execute 하고 input variable 을 "Stepahne Marrek" 으로 넣어주면, Pass State 으로 이동하게 되는걸 볼 수 있다. (그 외는 Fail State 로 이동한다)
> 뭔가 좀 큰 단위의 람다..? ㅋㅋㅋㅋㅋㅋ 어떤 람다보다 거대한 수행동작을 할 때 하는 일인듯!
> Input 과 output 들을 가지고 한 체계를 동작시키는.. (어떻게 보면 미니 App 같은..?!)
> UI 로 에어플로우 하는 느낌?
> 결과가 나오면, Execution 이 어떤 State 들을 따라서 이동했는지 Graph View 로 볼 수 있다
--------------------------------------------
<413 Step Function 오류 처리 >
> Task State 를 실행하다 발생할 수 있다다
>> ex : 정의가 잘못됨, Task 실패 (람다함수에서 예외발생 - 이 때, 람다에서 잡으면 Step Function 에선 별 신경 안씀)
> Step Function 은 Retry / Catch 로 잡을 수 있다. 이 때, 인 앱과 같이 리소스 내에서가 아니라, State Machine 자체에서 잡아야 한다
> 앱은 단순할 수록 좋기 때문, 또한, Retry / Catch 이력 및 실행 기록을 Step Function 에서 관리
> Predefined Error Code
>> States.ALL : 어떤 에러 이름과도 catch
>> States.Timeout : 태스크가 설정된 시간초과 초보다 길게 실행됨 or 활동으로부터 아무 신호도 못받음 (no heartbeat received)
>> States.TaskFailed : 태스크가 실행도중 실패
>> States.Permission : 태스크나 코드를 실행할 권한 불충분
> State 가 자체적으로 output 하는 error 들도 Step Function 에서 캐치 가능
< Retry 블록 >
> 위 그림처럼 Retry 가 필요한 상황일 경우를 명세해서 Error Type 에 대한 define 이 가능
>> Retry 하는 작업 횟수, 간격 드을 명시
>> 즉, TaskFailed 일 경우 30초 뒤에 한번 더 실행한다 이런것
>> BackoffRate 는 multiple 해서 지수 백오프를 구현하기 위함. 따라서 *2 를 해서 총 두번 이니까, 30초 뒤에 한번, 또 실패하면 60초 뒤에 한번, 이렇게 실행하는 것
> Max Attempt 가 도달하면, Catch 블록이 실행된다 (Retry 가 없으면 Max Attempt 도 없으니, 바로 Catch 인듯?)
>> 원래 람다 함수에서는 Error Control 변경하려면 재배포 해야 했으나, 지금은 외부에서 제어를 하기 때문에 재배포할 필요가 없다는 장점도 있음 (문서 내에서 간단하게 변경 가능)
< Catch 블록 >
> 똑같이 종류별 에러를 받을 수 있다
> Next 를 통해서 다음 State 를 어디로 보낼지 지정할 수 있다 (에러를 핸들링 하는 람다 따위로)
> RestulPath 란 것도 확인할 수 있는데, Next State 에 전달할 input 을 지정할 수 있다
>> 이 모든것들을 리소스, 인 앱 코드에서 하면 복잡도가 매우 올라가지만, 이를 Step Function (외부) 에서 함으로써 깔끔한 비즈니스 로직단을 유지할 수 있다
> $.error 로 표시되어 있는데, 이는 input 값에 오류를 포함시켜준다
> resultPath 로 error 를 input 에 넣어주라고 할 수 있다. 전달 Message JSON 에 error message 자체가 전달된다~!
> 다음 State 따위에서 에러를 확인하거나 할 용도로 사용 가능 (이를 분석, 이메일 등 디버깅에 활용하기 위해 전달)
>> 걍 exception 뒤로 던질 때 내용 던지는거임 ㅋㅋ
--------------------------------------------
< 414 Step Function 오류 처리 실습 >
> step-function-error 블루프린트로 람다를 만들 수 있다 (오류를 발생시킴)
> 새로운 state machine 을 만든다. 다음 JSON 을 추가
...
"States": {
"InvokeMyFunction": {
"Type": "Task",
"Resource": "<enter resource ARN here>",
"Retry": [
{
"ErrorEquals": [
"CustomError"
],
"IntervalSeconds": 1,
"MaxAttempts": 2,
"BackoffRate": 2
},
{
"ErrorEquals": [
"States.TaskFailed"
],
"IntervalSeconds": 30,
"MaxAttempts": 2,
"BackoffRate": 2
},
{
"ErrorEquals": [
"States.ALL"
],
"IntervalSeconds": 5,
"MaxAttempts": 5,
"BackoffRate": 2
}
],
"Catch": [
{
"ErrorEquals": [
"CustomError"
],
"Next": "CustomErrorFallback"
},
{
"ErrorEquals": [
"States.TaskFailed"
],
"Next": "ReservedTypeFallback"
},
{
"ErrorEquals": [
"States.ALL"
],
"Next": "CatchAllFallback"
}
],
"End": true
},
"CustomErrorFallback": {
"Type": "Pass",
"Result": "This is a fallback from a custom lambda function exception",
"End": true
},
"ReservedTypeFallback": {
"Type": "Pass",
"Result": "This is a fallback from a reserved error code",
"End": true
},
"CatchAllFallback": {
"Type": "Pass",
"Result": "This is a fallback from a reserved error code",
"End": true
}
}
> 위에서 만든 람다의 ARN 을 입력
> 추가하면 다음과 같은 형태로 State Machine 이 형성된다
> 에러 형태를 그냥 String 으로 확인하는 듯? 아까 람다에서 던진 에러가 CustomError 라는 객체를 던진다 (throw new CustomError)
> CustomError 객체 안에는 name = 'CustomError' 이고 errmsg 가 담겨 있음 (그냥 객체를 throw 로 전달, return 이 아니라)
> 위 statemachine json 에서 보면 이 CustomError 일 경우, 1초 뒤에 1번 재시도, 그 뒤로 2초 뒤에 한 번 재시도이다. 또한, Catch 도 있음
>> Catch 가 발생하면 CustomErrorFallback State 로 이동한다
> execute 하니까 람다함수가 당연히 CustomError 을 발생시키고, retry 블록으로 인해 재시도를 수행한다. 재시도를 두번 수행한다
>> 그 이후로 태스크가 종료되었고, CustomErrorFallback State 로 잘 이동한다
>> 즉, 생각한대로 이동함!
> 그 다음에는 Lambda 로 이동해서 CustomError 의 이름을 'Not Custom Error' 로 바꾼다!
>> 그 다음에 또 exceution 을 실행하면, 이번에는 CustomError 가 아니므로, ReservedTypeFallback 로 이동한걸 알 수 있다
>> TaskFailed 이기 때문 (람다가 그냥 실패함).
>> 둘 이외의 다른 종류의 에러는 CatchAllFallback 이 되는 것임을 위 JSON 을 보면 쉽게 확인할 수 있다
--------------------------------------------
<415 Wait For Task Token - 작업 토큰 대기>
> Step Function 이 Task 를 수행하는 중간에 멈출 수 있도록 한다 (Token 이 반환되는 것을 대기)
>> Task 내에서 다른 AWS 서비스의 작업, 사용자 승인, 3rd Party Integration, 타 시스템 호출 등등을 진행하느라 Wait 할 수도 있기 때문
> JSON 에서 Task 내의 Resource 필드에 .waitForTaskToken 을 추가한다
> 그러면 StepFunction 이 대기가 필요한걸 알고, SendTaskSuccess / SendTaskFailure API 호출로 인한 Task Token 을 반환받도록 대기한다 (서버 처럼 호출을 기다림)
> 가령, 위 그림처럼 [Check Credit] 하는 Task 는 타 서비스에 의존함
> 1. Task Token 이 포함된 SQS 에 Message 를 입력한다
> 2. 이 때 Message 내부에는 Resource 명에 .waitForToken 이 추가되어 있고, MessageBody 에는 위 그림과 같은 내용들이 포함되어 있다 (수신하는 Processor 가 StepFunction 에게 응답을 줄 때 필요한 토큰을 전달하는 것)
> 3. 타 작업을 수행하는 곳에서 SQS 에서 Poll Message 를 한다
> 4. 작업을 수행하면 SendTaskSuccess/Fail API 를 호출한다 - 처리 결과 및 아까 2번에서 받았던 TaskToken 을 그대로 실어서 전달
> 5. StepFunction 은 Wait 이 종료됨을 인지하고 후속을 진행한다
>> 장점: Step Function 자체도 필요에 따라 외부 서비스에 의존하는 작업을 수행할 수 있다는 점 (외부 메커니즘과의 통합 가능)
--------------------------------------------
<416 Activity Tasks - 활동 작업>
> Activity Worker : Step Function 에서 작업을 수행하는 구성 요소 (EC2, 람다, 모바일 기기 등에서 실행될 수 있음)
>> Activity Worker 를 사용해서 Task 를 수행시킬 수 있는 것
> GetActivityTask API 를 사용해서 Task 를 poll 한다 (실행되면서 주기적으로 Polling 실시)
> ActivityWorker 가 일을 마치면, SendTaskSuccess/Failure API 를 사용해서 응답을 보낸다
> Polling 을 할 때, 위에서 배운 것과 마찬가지로 해야할 일 (input) 과 Task Token (완료 후 응답 때 사용) 을 준다
> Activity Task 의 Point 는 수행할 Work 들을 (Task들) Polling 한다는 점이다
> WaitForTask 를 사용한 Callback Pattern 같은 경우는 StepFunction 이 Task 를 SQS 에 Push 를 하는 Push Mechanism 이다
>> 사실 일하는 놈의 입장에선 둘다 Polling 이긴 한데, Step Function 입장에서 보는 듯? 그리고 Activity Task 도 어쨌든 Worker 가 저쪽에 있으니까?
> Task Active 를 제어하는 변수들
>> TimeoutSeconds :: Failure 로 Task 를 취급하기 전에 어느정도 기다릴 수 있는지
>> Activity Worker 가 주기적으로 SendTaskHeartBeat API 를 사용해서 신호를 보낸다. 그리고 설정한 주기 이내에 Heartbeat 가 계속 들어온다면 Task 를 계속 ACTIVE 취급 (이 최대 대기 시간은 HeartBeatSeconds 로, StepFunction 구성시 설정)
> 모든 것을 고려해도 Activity Task 의 최대 대기 시간은 1년이다.
--------------------------------------------
<417 Step Function - Standard VS Express>
> Step Function 의 Workflow 를 수행시키는 방법은 두가지, Standard(default) 랑 Express 가 있다
> Express 에서는 비동기 / 동기 방식이 또 있다
> 기본
>> 최대 수행시간은 1년이고, Workflow 를 정확히 1회 수행, 초당 약 2000개의 표준 워크플로 실행 가능
>> 90일동안 기록이 보관. CW 를 사용해서 더 많은 로그를 보존 / 보관할 수 있다
>> 비용은 State Transition 이 발생하는 횟수대로 과금 (execution 횟수 아님!!)
>> Use Case : Idempotent 하지 않는 작업 (결과가 동일하지 않은?) 걍 일반 작업 아님?
> Express
>> 최대 수행시간은 5분, 매우 빠른 속도와 높은 용량, 초당 10만회 이상의 Executino 수행 가능
>> 추적 기능 없고 CW Log 를 사용해서만 가능
>> 비용은 실행 횟수, 기간, 메모리 사용량에 따라 과금
>> Use Case : IoT 데이터 처리, Streaming 등 매우 빠른 수행을 요구하는 거인듯?
> Express - Asynchronous
>> At-least Once 실행 모델
>> 결과를 딱히 기다리진 않음 (제대로 실행되었는지, 결과는 뭐였는지는 CW Log 에서 결과 확인)
>> ex : Message 보내기 (성공 여부는 딱히 기다리지 않고 일단 보낸다)
>> 최소 1회 모델 = 오류 발생시 SF 에서 자동 재시도를 할 수 있음 ==> 즉 동일한 작업이 두 번 실행될 가능성 존재 :: idempotence 를 관리(?) 해서 두번 동작한다고 두배의 처리가 되지 않아야 한다
> Express - Synchronous
>> At-most Once 실행 모델 (최대 1회)
>> 말 그대로 Workflow 가 완료되는 것을 대기, 응답을 수신
>> Workflow 자체로부터 즉각적인 응답이 필요한 것 ex) MSA 오케스트레이션시 모두 동작하는 것을 확인
>> 실패하더라도 SF 가 Workflow 를 재시동하지 않는다 = 기다리는 결과를 확인하고 재시도를 언제 할지 판단해서 사용자가 직접 구성해야함
--------------------------------------------
<418 App Sync>
> AppSync 는 GraphQL 을 사용하는 관리형 서비스이다
> GraphQL
>> 앱이 원하는 데이터를 쉽고 정확하게 찾을 수 있도록 도와주는 쿼리 언어.(API 의 새로운 형태)
>> 하나 이상 소스의 데이터를 Combine 해서 그래프로 만들 수 있다(?)
>>> GraphQL 데이터 소스는 NOSQL 데이터 저장소, RDB, HTTP API 등을 결합한다
> AppSync 의 GraphQL 은 Aurora, DD, ElasticSearch 등 다른 소스들과 통합된다. 또한, 원한다면 어떤 AWS 리소스로부터 데이터를 받아올 수 있는데 (Custom Source), 이 때 람다를 사용하면 된다
> AppSync 의 또다른 포인트는, WebSocket / WebSocket 의 MQTT 로 실시간 데이터 수신을 지원한다는 점이다
> (시험에 나올 수 있음) 모바일 앱에서, local data 에 접근하고 data synchronization (동기화) 를 하고 싶을 때, App Sync 는 이전에 나왔던(?) Congito Sync 란 오래된 서비스를 대체한다
> AppSync 를 사용하기 위해선 좌측 그림처럼 GraphQL 스키마를 업로드 해야한다
> Client 단에서는 GraphQL query 를 사용하려고 함 (우측 상단)
> AppSync 는 자신이 가지고 있는 Resolver 들을 사용하여 데이터를 찾는다. 리졸버 중 하나는 DD 가 될 수도 있는 것
> AppSync 는 데이터를 클라이언트에게 요청한 쿼리를 정확하게 응답 JSON 으로 만들 수 있어서 그 응답을 전달한다
>> 당연히 시험에서는 스키마, 쿼리 작성법 등에 대해 알 필요 없음 (위처럼 개략적인 모습)
> AppSync 의 중심에는 GraphQL Schema 가 있고, 데이터를 가져오는 법을 알려주는 Resolver 가 있음
> Resolver 는 direct integration 을 여러 대상과 할 수 있는데, 우측 모습들이다.
> AppSync 에서 일어나는 일은 CW 를 통해 확인 가능
<Security>
> Client (application) 에게 AppSync의 GraphQL API 와 소통할 수 있도록 권한을 주는 4가지 방법
>> API_KEY : API Gateway 에서 했던 것처럼 키를 만들고 유저에게 줌
>> AWS_IAM : IAM User/ Role / Cross-Account access 등을 연계하여 API 접근에 허용
>> OpenID_CONNECT (OIDC) : OIDC 공급자와 JWT 웹토큰을 통합하여 제공
>> Amazon_Cognito_UserPool : CUP 로 생성한 기존 사용자 풀과 integrate 하여 제공 / 이를 통해 다른 소셜 로그인 제공자들과도 연계 가능
>> HTTPS 를 원한다면, AppSYNC 앞에 CloudFront 를 사용하는 것을 권장!
--------------------------------------------
<419 App Sync 실습 / 개요>
> API 선택 : Merged API 는 GraphQL API 들을 조합한 API 로 훨씬 복잡함. 다루지 않음
> GraphQL Resource 를 선택하는데, DD 로 구성되는 resource 를 만들 수 있음
>> 바로 DD 를 만들게 됨, 생성한 뒤에 구성으로 이동 (실제 DD 를 가보면 생성되어 있음)
> Schema
>> DD 를 생성함으로써 기본적으로 구성된 스키마를 확인할 수 있음 (GraphQL 지식 영역)
>> AppSync -> GraphQL API를 활용해서 이 DD 와 연계해서 외부에 제공
> Queries : 이 GraphQL API 를 사용해볼 수 있는 곳
>> 샘플로 제시된 RUN 할 수 있는 것은 createStudent 와 listStudent 이다
>> createStudent mutation (함수API) 를 실행해보려고 하는데, 하단에 Query Variable 을 JSON 형태로 되어 있다. 이걸 input 으로 함수에 넣는 것인 듯 (Student 필드에 맞게 name, age 등이 JSON 으로 값을 기재함)
>> 여러개 만들고 list 해보면 다 확인되는 것을 알 수 있음
> 캐싱 설정 가능, GraphQL End Point, API ID 등등도 확인 가능
> 인증도 관리 가능 : API 키로 설정 및 관리 가능, CUP 로 설정 가능, IAM or OIDC 등으로도 설정 가능
> Metric 영역으로 모니터링도 가능하다
--------------------------------------------
<420 AWS Amplify>
> Amplify 는 Mobile & Web Application 을 만들 수 있도록 도와주는 리소스
> Amplify Studio : 프론트 / 백 모두 앱을 시각적으로 구축할 수 있도록 도와줌
> Amplify CLI : Studio 랑 똑같은데 CLI 로 하는거
> ~ Libraries : Cognito, S3 등 AWS 서비스에 앱을 연결하도록 도와줌
> ~ Hosting : AWS 에 배포하는걸 도움
<Amplify Studio & CLI>
> 모바일 & 웹 앱을 생성하기 위해 지원되는 도구 모음집
> mobile & web app 을 위한 EBS 라 생각
> init 을 통해 Amplify 앱을 초기 구성할 수 있다
> AWS 서비스를 사용한 Data Storage, Authentication, Storage, ML 등의 기능을 지원한다
>> 백엔드의 경우 DD, AppSync, Cognito, S3 등을 사용해서 지원함
>> 프런트 라이브러리의 경우 React, Vue, JS, IOS, Android Flutter 등을 바로 연계해서 사용할 수 있도록 지원한다
>> 안전성 / 보안 / 확장성을 보장함
>> CLI, Studio 등을 통해서 Build & Deploy 가 가능하다
<시험에 나올 수 있는 Amplify 의 주요 기능>
> Authentication : 별도의 설치 없이 즉시 사용 가능한 인증 기능 제공
>> Amazon Cognito 를 사용하여 registration, authentication, account recovery 등의 동작을 지원
>> MFA, Social Login 등을 지원
>> Pre-build UI Component 를 제공하여, 프런트 엔드에서 이를 사용 & Cognito 와 integrate 하기에 매우 용이
>> 세부적인 권한 관리가 가능 (fine-grained Authorization)
> Data Store : 저장소에 대한 API 로는 AppSync, 저장소 자체로는 DD 를 사용한다
>> 개발시 로컬 데이터로 개발 작업을 하면, Cloud 와 자동으로 동기화를 해줘서 저장소와 연계가 됨 (자동화, 복잡코드 X)
>> 전체적으로는 GraphQL & AppSync 로 동작
>> Amplify Studio 와 연계하여 데이터 모델링 시각화 작업도 가능
<Amplify Hosting>
> 최신 웹 앱을 Build & Host 가능, 빌드 테스트 배포와 같은 CI/CD 프로세싱 가능
> PR 미리보기, 사용자 지정 도메인, 모니터링 수행 가능
> Redirection & Custom Header 적용 가능, 암호화 가능 등등
>> Netlify & Vercel 과 같은 서비스들과 비슷함
> 코드를 저장소로부터 가져옴
>> CI CD 를 통해 Front End Build 하고 CF 같은 곳에 배포
>> 백엔드 CI CD 를 통해 Amplify 로 배포를 함
<Amplify 를 활용한 E2E Testing>
> Unit Test & E2E Test 가 가능
> "Test Phase" 에서 E2E Test 를 수행할 수 있다 (뭔 소린지 잘 모르겠음)
>> 목적 : Code 를 production 하기 전에 Regression 을 Catch 하는 것
>> 원하는대로 amplify.yml 을 통해 test step 을 구성하여 정의한다
>> 그리고 Cypress Test Framework 을 통해서 E2E 테스트를 생성할 수 있다 (이걸 사용하면 UI Report 를 제공해주고, 웹에서도 제어 가능? 뭐 그렇대)
<중요한 점 요약>
> 앱을 빌드하는 단계에서 단위 테스트를 실시 (코드가 해야할 일을 잘 수행하는지 확인)
> 앱을 배포할 때는 (staging) E2E 테스트를 Cypress 와 같은 도구를 사용해서 테스트 하는데, 앱이 예상대로 작동하는지 확인
--------------------------------------------
<421 AWS Amplify 실습>
> Amplify 로 가서 Build app 하면 Amplify Sutdio 를 통해 구성하기 시작 (CLI 를 통해서 할 수도 있음)
> Hosting Env 를 통해서 코드 저장소 or 로컬로 Web Hosting 을 할 수 있다
> BackEnd Env 를 통해서 백엔드 앱을 구성하는 Studio 로 이동할 수 있다 (Staging Environment)
>> 백엔드 구성을 통해 여러가지 리소스들과 Integrate 가능하다
> Content 관리 >> App Data Modeling 이 가능함, DD 와 직통으로 연계된다 (실제 DD 를 생성함)
> 이런거 하다가 CF 로 이동해보면, Amplify 의 동작은 CF 가 동작시킨다는 것을 확인할 수 있음
>> 이동해보면 Content 만든 이후로 Amplify Stack 들이 많이 생김. 그 중 하나에서 Event 를 보면 DD 생성 뭐 이런것도 확인할 수 있다
>> 참고로 생성된 DD 를 보면 내가 만들고자 한 Table 과 AmplifyDataStore 라는 Table 도 Amplify 와 연계하는 Metadata 들을 저장하기 위해 자동으로 생성되어 있음
> DD 를 생성하면 AppSYNC 도 생성되었음을 확인할 수 있다
> 아까처럼 Schema 로 이동하면 내가 모델링한 DD 에 대한 Schema API 를 제공하고 있음을 볼 수 있다
> 이렇게 간단히 UI 로 모델링 하면 뒷단에서 DB 와 API 를 자동으로 생성해준다 -> 진짜 빠르게 앱을 개발할 수 있음
> User Management 로 이동하면 당연히 Cognito 와 연계해서 인증을 확인할 수 있다 (바로 쉽게 생성 or 기존 Cognito 연계 가능)
>> Email Login, MFA, 회원가입시 추가할 정보, 등등을 간단히 할 수 있다
>> 이렇게 쉽게 인증/가입 방식을 구성하면, CF 는 뒷단에서 Cognito 를 구성해서 제공해준다
>> AWS 뒷단에 CF 라는 리소스가 얼마나 강력한지 느끼게 됨
> 이처럼 Storage 를 구성하면 AWS 는 S3 를 사용해서 구성해준다 (당연히 CF 로 구성)
> 그 밖에 여러가지 리소스들을 사용하는 것들을 할 수 있음
> 또한 UI Library 도 활용할 수 있다
--------------------------------------------
<퀴즈>
>
>
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 30 - AWS 보안 및 암호화 : KMS, SSM Param 스토어 (1) | 2024.10.23 |
|---|---|
| [CDA] 섹션 29 - 고급 자격 증명 (0) | 2024.10.21 |
| [CDA] 섹션 27 - 유저가 누군지 알아보는 Cognito (0) | 2024.10.06 |
| [CDA] 섹션 26 - 클라우드 개발 키트 (CDK) (0) | 2024.10.03 |
| [CDA] 섹션 25 - AWS 서버리스 : SAM (Serverless Application Model) (0) | 2024.09.20 |
