If you need a refresher on AWS Step Functions then check out part 1 of this series: ruclips.net/video/BTLQjUb2EPk/видео.html (What is AWS Step Function? An in-depth overview)
Thank you :-) I also have lots of articles on my blog (theburningmonk.com) which you might find helpful, and you can also reach out to me directly for help as well
for Korean -- 지난 비디오에서 저는 AWS Step Functions이 무엇인지와 어떻게 작동하는지 설명했습니다. 비디오는 Step Functions을 사용하는 이유에 대한 의문으로 끝났습니다. 왜냐하면 Lambda 함수 내에서 모든 오케스트레이션을 쉽게 처리할 수 있기 때문입니다. 이번 비디오에서는 워크플로우를 구현하는 두 가지 옵션을 비교해 보겠습니다. 개인적으로는 단순한 워크플로우나 비용 최적화가 필요한 경우 Lambda를 사용하는 것을 선호하지만, 복잡하거나 비즈니스에 중요한 워크플로우에서는 Step Functions을 사용하는 것을 선호합니다. 이 비디오의 나머지 부분에서 제 생각을 설명하겠지만, Lambda destinations을 사용하여 여러 Lambda 함수를 함께 변경하는 것이 매우 제한된 경우에 유용하다는 점도 언급하고 싶습니다. 자세한 내용은 나중에 다루겠습니다. Lambda의 장점은 분명하고 간단합니다. Step Functions과 비교했을 때 Lambda는 더 단순합니다. 오류 처리, 분기 로직 등 Step Functions에서 할 수 있는 모든 것을 몇 줄의 코드로 Lambda에서 구현할 수 있습니다. 이미 익숙한 프로그래밍 언어로 작성하고 테스트할 수 있으며, 상태 머신이 많은 Lambda 함수를 사용할 경우 비용도 절감됩니다. 왜냐하면 Step Functions의 상태 전환 비용 외에도 Lambda 호출 비용을 지불하게 되기 때문입니다. 따라서 모든 오케스트레이션을 코드로 Lambda 함수 하나에 몰아넣으면 비용이 절감될 가능성이 높습니다. 하지만 코드가 단순히 DynamoDB를 호출하는 것이라면, 모든 Lambda 함수를 직접 통합으로 대체할 수 있어 Lambda 비용이 발생하지 않습니다. Express 워크플로우를 사용하면 Lambda와 비슷한 비용이 들기 때문에 이 경우 비용 차이는 크지 않을 수 있습니다. 그러나 이는 상황에 따라 다릅니다. Lambda 함수 하나로 모든 것을 처리하면 확장성 측면에서도 더 유리할 수 있습니다. 상태 머신이 많은 Lambda 함수를 사용하면 Step Functions과 Lambda의 비율 제한에 의해 확장성이 제한될 수 있습니다. 반면, 단순히 Lambda만 사용하는 경우 Lambda의 동시 호출 한도만 적용되며, 이는 Step Functions의 상태 전환 초당 한도보다 훨씬 높습니다. 따라서 시스템의 전체 확장성은 먼저 도달하는 한도에 의해 결정됩니다. Lambda를 사용할 때는 항상 공통 예산(CO-ART)과 사용자가 대기하는 동기 워크플로우, 최대 15분의 실행 시간이 충분한지 여부를 고려해야 합니다. 또한, 밀리초 단위로 실행 시간을 지불하기 때문에 대기 시간이 필요한 경우 비용 효율적이지 않습니다. 반면, Step Functions은 표준 워크플로우의 가격 모델이 대기 시간에 적합하며, 특히 워크플로우 실행을 시각화할 수 있어 디버깅이 매우 용이합니다. 이는 개발자뿐만 아니라 고객 지원 팀에게도 유용합니다. Step Functions 콘솔에서 실패한 실행을 빠르게 찾아 어디서 문제가 발생했는지 확인할 수 있으며, 모든 입력과 출력, 오류 메시지를 통해 문제를 쉽게 파악할 수 있습니다. Step Functions의 또 다른 강점은 모든 실행에 대한 완전한 감사 기록을 제공한다는 점입니다. 각 상태 전환이 언제 시작되고 끝났는지, 오류가 발생했는지 등을 자세히 기록하므로 디버깅이 매우 용이합니다. 또한, Step Functions은 거의 모든 AWS 서비스와 직접 통합할 수 있어 모든 것을 Lambda 함수로 처리할 필요가 없습니다. Lambda를 사용하지 않으면 공통 예산 문제도 발생하지 않으며, 더 예측 가능한 성능을 얻을 수 있습니다. 높은 최대 지속 시간과 콜백 패턴 구현 능력 덕분에 Step Functions은 매우 유연합니다. 개인적으로 Step Functions을 비즈니스에 중요한 워크플로우에 사용하는 것을 선호하는 이유는 더 견고한 오류 처리를 구현할 수 있기 때문입니다. 예를 들어, 단순한 태스크 상태에서 다양한 유형의 오류에 대해 지수 백오프를 사용한 재시도를 추가할 수 있습니다. 모든 재시도가 소진된 후 오류를 처리하기 위해 캐치 절을 추가할 수도 있습니다. Lambda에서도 몇 줄의 코드로 이를 구현할 수 있지만, Step Functions을 사용하면 이러한 오류 처리와 재시도를 상태 머신 외부로 분리할 수 있어 함수의 타임아웃 설정에 대해 걱정할 필요가 없습니다. 따라서 비즈니스에 중요한 워크플로우를 구축할 때 Step Functions을 사용하는 것이 훨씬 더 신뢰할 수 있는 애플리케이션을 만드는 데 도움이 됩니다. 물론, 이러한 신뢰성에는 추가 비용이 발생하며, Step Functions을 배우는 데도 학습 곡선이 존재합니다. Amazon State Language를 학습하고 구성 및 관리를 위한 추가 작업이 필요하기 때문에 단순한 워크플로우에는 너무 많은 오버헤드일 수 있습니다. 또한, Step Functions을 테스트하는 것이 어렵기 때문에 대부분의 사람들이 어려움을 겪습니다. 제 서버리스 테스트 과정에서는 Step Functions 테스트에 대한 전체 챕터를 할애하여 로컬 및 확장 테스트에서 Step Functions을 테스트하는 방법을 가르치고 있습니다. 현재는 PandaTube15 코드를 사용하면 15% 할인을 받을 수 있습니다. 앞서 언급한 Lambda destinations은 성공 시 Lambda 함수를 함께 연결하여 워크플로우를 구현하는 또 다른 방법입니다. 이 접근 방식은 매우 단순한 원홉 워크플로우에 적합합니다. 예를 들어, 비동기 함수가 이벤트 처리를 마치고 분석 이벤트를 제3자 시스템에 보내는 등의 보조 작업을 오프로딩할 때 유용합니다. 두 번째 단계가 실패하고 재시도될 경우, 원래 이벤트를 두 번 처리할 필요가 없습니다. 하지만 이러한 원홉 워크플로우를 넘어서는 경우에는 사용하지 않는 것이 좋습니다. Lambda to Lambda 체이닝은 제한된 가시성과 비동기 특성으로 인해 디버깅과 오류 처리가 어렵습니다. 활성 트레이싱을 X-Ray와 함께 사용하면 일부 정보를 볼 수 있지만, 기본적으로 샘플링이 많이 되어 대부분의 워크플로우 실행은 여전히 보이지 않습니다. 각 단계에 대해 경고 및 Dead Letter Queue를 설정해야 하며, 그렇지 않으면 문제가 발생했을 때 알 수 없고 데이터 손실이나 이벤트 손실이 발생할 수 있습니다. Step Functions을 사용하면 디버깅이 훨씬 쉬워지므로, 복잡성을 줄이고 빠르게 문제를 해결할 수 있습니다. 따라서 원홉 워크플로우를 제외한 다른 경우에는 Lambda destinations을 사용하지 않는 것이 좋습니다. 이번 Lambda 함수와 Step Functions을 사용한 워크플로우 구축 비교는 여기까지입니다. 이 비디오를 즐기고 새로운 것을 배웠다면, 좋아요를 누르고 채널을 구독해 주세요. 이는 저에게 큰 도움이 되며 서버리스 개발에 대한 더 많은 팁을 공유할 수 있게 해줍니다. 다음 시간까지, 감사합니다!
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Thank you for sharing your knowledge
If you need a refresher on AWS Step Functions then check out part 1 of this series: ruclips.net/video/BTLQjUb2EPk/видео.html (What is AWS Step Function? An in-depth overview)
Love your videos. As we're making moves to a more "monorepo" approach for our product, optimizing costs using Lambda APIs and API gateway.
Thank you :-) I also have lots of articles on my blog (theburningmonk.com) which you might find helpful, and you can also reach out to me directly for help as well
Awesome! Do you have a discord by chance? @@theburningmonk
for Korean
--
지난 비디오에서 저는 AWS Step Functions이 무엇인지와 어떻게 작동하는지 설명했습니다. 비디오는 Step Functions을 사용하는 이유에 대한 의문으로 끝났습니다. 왜냐하면 Lambda 함수 내에서 모든 오케스트레이션을 쉽게 처리할 수 있기 때문입니다. 이번 비디오에서는 워크플로우를 구현하는 두 가지 옵션을 비교해 보겠습니다. 개인적으로는 단순한 워크플로우나 비용 최적화가 필요한 경우 Lambda를 사용하는 것을 선호하지만, 복잡하거나 비즈니스에 중요한 워크플로우에서는 Step Functions을 사용하는 것을 선호합니다. 이 비디오의 나머지 부분에서 제 생각을 설명하겠지만, Lambda destinations을 사용하여 여러 Lambda 함수를 함께 변경하는 것이 매우 제한된 경우에 유용하다는 점도 언급하고 싶습니다. 자세한 내용은 나중에 다루겠습니다.
Lambda의 장점은 분명하고 간단합니다. Step Functions과 비교했을 때 Lambda는 더 단순합니다. 오류 처리, 분기 로직 등 Step Functions에서 할 수 있는 모든 것을 몇 줄의 코드로 Lambda에서 구현할 수 있습니다. 이미 익숙한 프로그래밍 언어로 작성하고 테스트할 수 있으며, 상태 머신이 많은 Lambda 함수를 사용할 경우 비용도 절감됩니다. 왜냐하면 Step Functions의 상태 전환 비용 외에도 Lambda 호출 비용을 지불하게 되기 때문입니다. 따라서 모든 오케스트레이션을 코드로 Lambda 함수 하나에 몰아넣으면 비용이 절감될 가능성이 높습니다. 하지만 코드가 단순히 DynamoDB를 호출하는 것이라면, 모든 Lambda 함수를 직접 통합으로 대체할 수 있어 Lambda 비용이 발생하지 않습니다. Express 워크플로우를 사용하면 Lambda와 비슷한 비용이 들기 때문에 이 경우 비용 차이는 크지 않을 수 있습니다. 그러나 이는 상황에 따라 다릅니다.
Lambda 함수 하나로 모든 것을 처리하면 확장성 측면에서도 더 유리할 수 있습니다. 상태 머신이 많은 Lambda 함수를 사용하면 Step Functions과 Lambda의 비율 제한에 의해 확장성이 제한될 수 있습니다. 반면, 단순히 Lambda만 사용하는 경우 Lambda의 동시 호출 한도만 적용되며, 이는 Step Functions의 상태 전환 초당 한도보다 훨씬 높습니다. 따라서 시스템의 전체 확장성은 먼저 도달하는 한도에 의해 결정됩니다. Lambda를 사용할 때는 항상 공통 예산(CO-ART)과 사용자가 대기하는 동기 워크플로우, 최대 15분의 실행 시간이 충분한지 여부를 고려해야 합니다. 또한, 밀리초 단위로 실행 시간을 지불하기 때문에 대기 시간이 필요한 경우 비용 효율적이지 않습니다. 반면, Step Functions은 표준 워크플로우의 가격 모델이 대기 시간에 적합하며, 특히 워크플로우 실행을 시각화할 수 있어 디버깅이 매우 용이합니다. 이는 개발자뿐만 아니라 고객 지원 팀에게도 유용합니다. Step Functions 콘솔에서 실패한 실행을 빠르게 찾아 어디서 문제가 발생했는지 확인할 수 있으며, 모든 입력과 출력, 오류 메시지를 통해 문제를 쉽게 파악할 수 있습니다.
Step Functions의 또 다른 강점은 모든 실행에 대한 완전한 감사 기록을 제공한다는 점입니다. 각 상태 전환이 언제 시작되고 끝났는지, 오류가 발생했는지 등을 자세히 기록하므로 디버깅이 매우 용이합니다. 또한, Step Functions은 거의 모든 AWS 서비스와 직접 통합할 수 있어 모든 것을 Lambda 함수로 처리할 필요가 없습니다. Lambda를 사용하지 않으면 공통 예산 문제도 발생하지 않으며, 더 예측 가능한 성능을 얻을 수 있습니다. 높은 최대 지속 시간과 콜백 패턴 구현 능력 덕분에 Step Functions은 매우 유연합니다. 개인적으로 Step Functions을 비즈니스에 중요한 워크플로우에 사용하는 것을 선호하는 이유는 더 견고한 오류 처리를 구현할 수 있기 때문입니다.
예를 들어, 단순한 태스크 상태에서 다양한 유형의 오류에 대해 지수 백오프를 사용한 재시도를 추가할 수 있습니다. 모든 재시도가 소진된 후 오류를 처리하기 위해 캐치 절을 추가할 수도 있습니다. Lambda에서도 몇 줄의 코드로 이를 구현할 수 있지만, Step Functions을 사용하면 이러한 오류 처리와 재시도를 상태 머신 외부로 분리할 수 있어 함수의 타임아웃 설정에 대해 걱정할 필요가 없습니다. 따라서 비즈니스에 중요한 워크플로우를 구축할 때 Step Functions을 사용하는 것이 훨씬 더 신뢰할 수 있는 애플리케이션을 만드는 데 도움이 됩니다. 물론, 이러한 신뢰성에는 추가 비용이 발생하며, Step Functions을 배우는 데도 학습 곡선이 존재합니다. Amazon State Language를 학습하고 구성 및 관리를 위한 추가 작업이 필요하기 때문에 단순한 워크플로우에는 너무 많은 오버헤드일 수 있습니다. 또한, Step Functions을 테스트하는 것이 어렵기 때문에 대부분의 사람들이 어려움을 겪습니다. 제 서버리스 테스트 과정에서는 Step Functions 테스트에 대한 전체 챕터를 할애하여 로컬 및 확장 테스트에서 Step Functions을 테스트하는 방법을 가르치고 있습니다. 현재는 PandaTube15 코드를 사용하면 15% 할인을 받을 수 있습니다.
앞서 언급한 Lambda destinations은 성공 시 Lambda 함수를 함께 연결하여 워크플로우를 구현하는 또 다른 방법입니다. 이 접근 방식은 매우 단순한 원홉 워크플로우에 적합합니다. 예를 들어, 비동기 함수가 이벤트 처리를 마치고 분석 이벤트를 제3자 시스템에 보내는 등의 보조 작업을 오프로딩할 때 유용합니다. 두 번째 단계가 실패하고 재시도될 경우, 원래 이벤트를 두 번 처리할 필요가 없습니다. 하지만 이러한 원홉 워크플로우를 넘어서는 경우에는 사용하지 않는 것이 좋습니다. Lambda to Lambda 체이닝은 제한된 가시성과 비동기 특성으로 인해 디버깅과 오류 처리가 어렵습니다. 활성 트레이싱을 X-Ray와 함께 사용하면 일부 정보를 볼 수 있지만, 기본적으로 샘플링이 많이 되어 대부분의 워크플로우 실행은 여전히 보이지 않습니다. 각 단계에 대해 경고 및 Dead Letter Queue를 설정해야 하며, 그렇지 않으면 문제가 발생했을 때 알 수 없고 데이터 손실이나 이벤트 손실이 발생할 수 있습니다. Step Functions을 사용하면 디버깅이 훨씬 쉬워지므로, 복잡성을 줄이고 빠르게 문제를 해결할 수 있습니다. 따라서 원홉 워크플로우를 제외한 다른 경우에는 Lambda destinations을 사용하지 않는 것이 좋습니다.
이번 Lambda 함수와 Step Functions을 사용한 워크플로우 구축 비교는 여기까지입니다. 이 비디오를 즐기고 새로운 것을 배웠다면, 좋아요를 누르고 채널을 구독해 주세요. 이는 저에게 큰 도움이 되며 서버리스 개발에 대한 더 많은 팁을 공유할 수 있게 해줍니다. 다음 시간까지, 감사합니다!