Track 4 Session 3_ 利用 AWS Step Functions 建構穩健的業務處理流程
•Télécharger en tant que PPTX, PDF•
1 j'aime•599 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Track 4 Session 3_ 利用 AWS Step Functions 建構穩健的業務處理流程
Similaire à Track 4 Session 3_ 利用 AWS Step Functions 建構穩健的業務處理流程 (20)
Plus de Amazon Web Services
Plus de Amazon Web Services (20)
Track 4 Session 3_ 利用 AWS Step Functions 建構穩健的業務處理流程
- 1. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 利用 AWS Step Functions 建構穩健的 業務處理流程 Scott Li T r a c k 4 | S e s s i o n 3 Cloud Support Engineer Amazon Web Services
- 6. Is this you? “I want try/catch/finally”“I want to retry failed tasks” A “I want to sequence tasks” BA “I want to select tasks based on data” B C A ? “I want to run tasks in parallel” BA
- 7. Coordination must-haves • Easy to build & operate • Scales out • Doesn’t lose state • Deals with errors/exceptions • Auditable
- 8. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 9. AWS Step Functions Features Visualize in the Console Define in JSON Monitor Executions
- 10. Workflow Type Standard Workflows • Long-running, durable and auditable workflows • 2000 per second (stared rate) • 4000 per second (state transition) • Log events on console & CloudWatch Log • Ｍax execution time of 1 year • $0.025 per 1,000 state transitions Express Workflows • Simplified capabilities, geared for speed and scale • Supporting event rates up to 100,000 per second • No logging events on console • Max execution time of 5 mins • Pay per use at $1.00 per 1M requests and $0.000001 per request Flexibility to select the right workflow type for your needs, or integrate them together where needed
- 11. Orchestrating Your Business Logic with Eight States The Amazon States Language is a JSON-based, structured language used to define your state machine
- 12. Tasks: Activity Hybrid workflows with servers and instances Long poll On premises server Worker requests tasks from Step Functions
- 13. Tasks: Callback Call an external resource. Pause workflow for a callback event from the resource. Wait for as long as you need – minutes, days, weeks, or months: • Human activity • Third party API • Legacy application Start End Callback Task Next Task
- 14. Callback tasks : Human Activities Call an external resource. Pause workflow for a callback event from the resource. Wait for as long as you need – minutes, days, weeks, or months: • Human activity • Third party API • Legacy application
- 15. AWS Step Functions: Input and Output Processing
- 16. AWS Step Functions: Input and Output Processing
- 17. AWS Step Functions: Input and Output Processing
- 18. AWS Step Functions: Input and Output Processing
- 19. Service Integrations Step Functions invokes the task and pauses until the task completes Request AWS Fargate Amazon ECS AWS Batch AWS Lambda Amazon SQS Amazon SNS Amazon DynamoDB Amazon SageMaker AWS Glue Amazon EMR
- 20. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 21. An Image Processing Workflow Mountains People Snow • Make a thumbnail • Identify features • Store image metadata
- 23. Build Workflows Using Service Integrations AWS Lambda AWS Lambda Mountains People Snow Amazon DynamoDB Amazon SNS Amazon DynamoDB
- 24. Payment and Order Processing Flow Storing payment information Authentication and Payment AWS Step Functions workflow Processing shipmentUpdating Payment Status Financial Organization Fail
- 25. Workflow-Driven AWS CodePipeline Actions
- 26. Workflow-Driven AWS CodePipeline Actions
- 27. Workflow-Driven AWS CodePipeline Actions
- 28. Workflow-Driven AWS CodePipeline Actions
- 29. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 30. Use Cases for AWS Step Functions Process data Automate tasks Modernize monoliths Orchestrate applications
- 31. Challenge • Transcode ~350 news video clips per day into 14 formats each – as quickly as possible Results • Able to process video segments in parallel • Reduced processing time from ~20 min to ~2 minutes • The bigger the source video, the more segments, the bigger the savings Thomson Reuters Serverless split video transcoding Industry: Media & Entertainment Solution: Big Data / Machine Learning Architecture: Serverless
- 32. coinbase Buy and sell digital currency Challenge • Secure, reliable, immutable deployments with visibility by their engineers • Scale to multiple AWS accounts easily and quickly Results • Reduced new account deployment from days to seconds • Increased the time a deployment can reliably run from 2 hours to 48 hours • Mission critical services deployment rate rose 7%
- 33. Challenge • Make a very old, very critical monolithic billing application easier to modify & maintain • Improve account billing process • High refactoring risk Results • Able to refactor gradually and safely • Able to process multiple accounts at once (concurrency) • Stable and improved performance (parallelism) • Enhanced observability • Simple evolution to Lambda Yelp Transformed a decade-old monolith to microservices Industry: Internet Solution: Application modernization Architecture: Serverless
- 34. Challenge • Workflow management platform for video teams has to be able to process high volumes of media, transcode to different formats, cost- effectively Results • Improved performance and lower costs • Code is easily managed and debugged • Increased code releases 20x using CI/CD • Better performance, expect to scale to running 1,000 state machines a minute Frame.io Custom solution to optimize real-time transcoding Industry: Media & Entertainment Solution: Digital Supply Chain Architecture: Microservices
- 35. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 36. Business Processes on AWS Step Functions AWS Step Functions lets you build visual workflows that enable fast translation of business requirements into technical requirements. You can build applications in a matter of minutes, and when needs change, you can swap or reorganize components without customizing any code. Build and update apps quickly AWS Step Functions manages the logic of your application for you, and implements basic primitives such as branching, parallel execution, and timeouts. This removes extra code that may be repeated in your microservices and functions. Write less code AWS Step Functions manages state, checkpoints and restarts for you to make sure that your application executes in order and as expected. Built-in try/catch, retry and rollback capabilities deal with errors and exceptions automatically. Improve resiliency
- 37. Best Practice • Use Timeouts to Avoid Stuck Executions • Use ARNs Instead of Passing Large Payloads • Avoid Reaching the History Quota • Handle Lambda Service Exceptions • Avoid Latency When Polling for Activity Tasks • Choosing Standard or Express Workflows
- 38. Thank you! © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Notes de l'éditeur
- 企業級應用通常架構在三個主要的部分： 使用者介面：用來接收來自使用者的輸入並呈現結果 邏輯處理：由各式各樣的子功能所組成 資料庫：提供資料查詢和儲存 隨著功能需求的增加, 應用的維護和部署的複雜度也會隨著提高。因此將應用微服務化變成是一個越來越熱門的選擇和趨勢，而微服務化的主要概念就是將各個子功能拆開並單元化，形成一個分散式的應用，以達到易維護和部署的目的。
- AWS Lambda 是在 AWS 上一個作為微服務化並構建成為一個分散式應用的熱門選擇。不管您的應用是與資料庫查詢和儲存或要透過 message queue 做溝通，甚至是與第三方服務供應商做互動都可以輕易地完成。並且使用 Lambda function 來構建應用，您無須管理伺服器，也無需為應用在請求量大時為擴展傷腦筋, 透過Lambda function日誌和各式各樣的 CloudWatch 指標，可以滿足使用者在除錯和維運上的需求
- 使用 Lambda function 所構建而成的應用, 請求通常是沒有狀態的（Stateless） ，要如何規劃並且指揮每一個 Lambda function 的協同運作並形成一個高效能高可用的應用即為一個非常重要的課題
- 更進一步來看，再協調並指揮 Lambda function 時，您可能會需要 function 按照順序去做配合, 或者是根據使用者所輸入的資料選擇的不同的工作處理，抑或是將輸入的資料, 並行處裡不同的工作, 也可能要依據並且在執行時發生錯誤或是暫時性問題的時，確保這些沒有執行成功的工作可以順利完成
- 一個良好的工作流程應該具備有這些要素： 隨時隨地可以很容易的進行修改，並且馬上就可以進行運作 並且可以隨著請求量大增時，自動進行擴展然後不會因為擴展而失去工作狀態的追蹤和協調 具備有重試的機制，以應對可能發生的問題 維運的工程師可以透過良好的日誌功能進行狀態監控
- AWS Step Functions 就是用來建構這樣的工作流程的一個很好選擇
- AWS Step Functions 就是由定義各式各樣工作的狀態幾所組成，其使用 Amazon State Language[1] 來定義狀態機，並且使用的是開發者熟悉的 JSON 格式，定義完成之後馬上將定義好的流程視覺化，在流程執行的過程中提供日誌的功能讓管理者輕鬆監控執行狀態 [1] https://docs.aws.amazon.com/step-functions/latest/dg/concepts-amazon-states-language.html
- https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html Standard: 2000 per second started rate 4000 state transition Charged by Express: 100000 per second started rate Nearly unlimited state transition per seconds
- - Pass state can inject some fixed data into the state machine, - The Map state ("Type": "Map") can be used to run a set of steps for each element of an input array. While the Parallel state executes multiple branches of steps using the same input, a Map state will execute the same steps for multiple entries of an array in the state input.
- GetActivityTask taskTokenA token that identifies the scheduled task. This token must be copied and included in subsequent calls to SendTaskHeartbeat, SendTaskSuccess or SendTaskFailure in order to report the progress or completion of the task. TimeoutSeconds Heartbeat Wait up to 1-year
- 在 callback pattern 中，Step Functions 可以暫停工作流程，直到目標服務（例如 Amazon SNS, SQS, AWS Lambda 等等）透過 Step Functions API回傳 token 後再繼續執行工作流程，這樣的 pattern 讓您可以加入一些使用場景，例如需要加入人類互動場景如 review 和 approval 之類的管理流程 In a callback pattern, Step Functions pauses execution of the workflow until your application returns a token through the Step Functions application programming interface. This helps you automate workflows for applications that need human activities such as review and approval of documents or creating and managing work items in a customer support application. You can also use the callback pattern to build custom integrations with third-party services. Step Functions supports callback patterns with Amazon ECS, Amazon SNS, Amazon SQS, AWS Fargate, and AWS Lambda.
- https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-human-approval.html In the email account you used for the Amazon SNS topic earlier, open the message with the subject Required approval from AWS Step Functions. The message includes separate URLs for Approve and Reject.
- Use "Parameters" field to create a collection of key-value pairs that are passed as input. The values of each can either be static values that you include in your state machine definition, or selected from either the input or the context object with a path. For key-value pairs where the value is selected using a path, the key name must end in .$. ResultPath can completely replace the input with the result of the task. {“ResultPath”:”$”} Discard result: {“ResultPath”:null} Collect result : {“ResultPath”:$.”result”}
- Use "Parameters" field to create a collection of key-value pairs that are passed as input. The values of each can either be static values that you include in your state machine definition, or selected from either the input or the context object with a path. For key-value pairs where the value is selected using a path, the key name must end in .$. ResultPath can completely replace the input with the result of the task. {“ResultPath”:”$”} Discard result: {“ResultPath”:null} Collect result : {“ResultPath”:$.”result”}
- Use "Parameters" field to create a collection of key-value pairs that are passed as input. The values of each can either be static values that you include in your state machine definition, or selected from either the input or the context object with a path. For key-value pairs where the value is selected using a path, the key name must end in .$.
- Use "Parameters" field to create a collection of key-value pairs that are passed as input. The values of each can either be static values that you include in your state machine definition, or selected from either the input or the context object with a path. For key-value pairs where the value is selected using a path, the key name must end in .$. ResultPath can completely replace the input with the result of the task. {“ResultPath”:”$”} Discard result: {“ResultPath”:null} Collect result : {“ResultPath”:$.”result”}
- https://github.com/aws-samples/aws-codepipeline-stepfunctions This action invokes a Lambda function (1) called the State Machine Trigger Lambda, which, in turn, triggers a Step Functions State Machine to process the request (2). The Lambda function sends a continuation token back to the pipeline (3) to continue its execution later and terminates. Seconds later, the pipeline invokes the Lambda function again (4), passing the continuation token received. The Lambda function checks the execution state of the state machine (5,6) and communicates the status to the pipeline. The process is repeated until the state machine execution is complete. Then the Lambda function notifies the pipeline that the corresponding pipeline action is complete (7). If the state machine has failed, the Lambda function will then fail the pipeline action and stop its execution (7). While running, the state machine triggers various Lambda functions to perform different tasks. The state machine and the pipeline are fully decoupled. Their interaction is handled by the Lambda function.
- Developers have been able to use CodePipeline to build sophisticated automation pipelines that often require a single CodePipeline action to perform multiple tasks, fork into different execution paths, and deal with asynchronous behavior. For example, to deploy a Lambda function, a CodePipeline action might first inspect the changes pushed to the code repository. If only the Lambda code has changed, the action can simply update the Lambda code package, create a new version, and point the Lambda alias to the new version. If the changes also affect infrastructure resources managed by AWS CloudFormation, the pipeline action might have to create a stack or update an existing one through the use of a change set. In addition, if an update is required, the pipeline action might enforce a safety policy to infrastructure resources that prevents the deletion and replacement of resources. You can do this by creating a change set and having the pipeline action inspect its changes before updating the stack. Change sets that do not conform to the policy are deleted.
- Developers have been able to use CodePipeline to build sophisticated automation pipelines that often require a single CodePipeline action to perform multiple tasks, fork into different execution paths, and deal with asynchronous behavior. For example, to deploy a Lambda function, a CodePipeline action might first inspect the changes pushed to the code repository. If only the Lambda code has changed, the action can simply update the Lambda code package, create a new version, and point the Lambda alias to the new version. If the changes also affect infrastructure resources managed by AWS CloudFormation, the pipeline action might have to create a stack or update an existing one through the use of a change set. In addition, if an update is required, the pipeline action might enforce a safety policy to infrastructure resources that prevents the deletion and replacement of resources. You can do this by creating a change set and having the pipeline action inspect its changes before updating the stack. Change sets that do not conform to the policy are deleted.
- Developers have been able to use CodePipeline to build sophisticated automation pipelines that often require a single CodePipeline action to perform multiple tasks, fork into different execution paths, and deal with asynchronous behavior. For example, to deploy a Lambda function, a CodePipeline action might first inspect the changes pushed to the code repository. If only the Lambda code has changed, the action can simply update the Lambda code package, create a new version, and point the Lambda alias to the new version. If the changes also affect infrastructure resources managed by AWS CloudFormation, the pipeline action might have to create a stack or update an existing one through the use of a change set. In addition, if an update is required, the pipeline action might enforce a safety policy to infrastructure resources that prevents the deletion and replacement of resources. You can do this by creating a change set and having the pipeline action inspect its changes before updating the stack. Change sets that do not conform to the policy are deleted.
- Thosoms Reuters 是個媒體與資訊供應商 ，每天提供大量的新聞, 訪談等影片給用戶。原本使用 Ffmpeg (singled thread) 30秒長就需要30秒，一小時訪談影片就會需要一小時，那樣慢慢的處理影片轉檔工作，之後他們時做了新的影片轉檔機制，搭配 AWS Step Functions 將原本只能慢慢從頭做到尾的轉檔工作，變成可以從影片中的關鍵影格並行處理，大大提升影片製作效率！ Most people have at least heard of Thomson. They have a lot of publications and a lot of TV channels and if you consume any news at all, it’s probably hard to get through the course of a day without reading some of their stories or watching some of their video clips. There’s the problem. They have lots of video incoming, which is as usual. The incoming clips are, fortunately for them, all in the same format, so unlike many media companies, they don’t have too much of an input-conversion problem. However, they vary wildly in length, from a 3-second clip of a bomb going off to a half-hour-long interview with a newsmaker. They need to convert for delivery and this is news, so they need to do it fast. Historically they’ve used Ffmppeg, which you know about if you’re in this business, it’s what everybody uses. The problem is that it’s single-threaded, and so if you want to transcode a half-hour video, well, you can easily end up waiting a half-hour for Ffmpeg, which is not what you want. It turns out that if you look at a stream of video frames, some of them are special and are called “Keyframes”. Results show that the actual video processing time of each segment is pretty much static at around 3s for a 0.5s segment. The initial identification of keyframes within the source video does depend on the size of the source video as you have to tick through the whole video to identify the keyframes. We’re currently doing further experimentation to make this stage more efficient to save even more time. This could feasibly take the processing of ANY video down to a few seconds. APPROACH (for each video to each format): Derive keyframe locations within source video Split source video on keyframe boundaries Process segments in parallel (typically 0.5s of video each segment) Concat all resultant segments together RESULTS: Processing time for 15min video down from ~20min to ~2min The bigger the source video, the more segments, the bigger the saving LESSONS LEARNED: Used S3 events to trigger processing of segments due to Step not supporting dynamic number of tasks Used S3 URLs to stream source video in Lambda rather than having to copy full file (avoids exhausting disk space) Scaling to 1000 Lambda easier than scaling 1000 EC2’s!
- Coinbase – digital currency exchange MAD principles: release features and update services quickly, reliably, securely. Need for changes in their deployments: Reduced deployment time investment from days to seconds Increased reliability of deployments Were able to deploy more frequently: iterating, innovating
- 原本單一且巨大的 billing 系統只能批次的一筆筆處理每個帳戶billing事務，透過 AWS Step functions 拆解成幾個子系統，變可以在同一時間處理好幾個帳戶的帳務問題，大大提升了執行效率 Yelp is focused on local businesses - they’re around to help you find what you're looking for, whatever city you happen to be in When you buy something on Yelp, such as food delivery, restaurant reservations, advertising contracts and so on, all of those different products go through a set of teams in the revenue and commerce side of the company that are responsible for processing payments, making sure they get the right money at the right time from people who owe it to Yelp, and then paying out money that they owe to other people. Their subscription billing process handles recurring purchases, and it's really important. Monthly invoicing for advertising accounts Business critical, happens at scale (>100k accts) Older code, evolved over ~10 years They have 3 steps to subscription billing: bill all accounts, create invoices and collect all accounts, in the middle of a much larger scheduled job. They were chaining one after another, operating over all accounts at Yelp. Yelp wanted to make this system a lot better and improve it, wanted to take advantage of new technologies like serverless, but needed to dig out from 10 years of maintenance costs and burdens and had a couple of challenges Why haven’t we refactored this before? It was too big, too messy, and frankly, it worked and they were scared to touch it What made refactoring this up hard? Refactoring this whole system at once was very complicated. It spanned teams, on-call rotations, conceptual subsystems and quite a bit more. Doing any of these was really hard, expensive and frankly dangerous. There also wasn't any API for this business practice, it was essentially a job that ran nightly, and if you never touched it, it kept doing the same thing and the company makes money. So API is a really generous word for what it was. That makes it really hard to turn it into something like lambdas that require a little bite-sized functionality and it makes it really hard to turn it into services if you just don't know what's in the middle of this process - and that's where Step Functions came in Solution To improve their old subscription billing process and to be able to use these nicer technologies in the future, Yelp turned to Step Functions to help with the gradual refactoring. Their business-critical process lived in the sequence of three jobs and they decided to take the first of those steps - billing of accounts - and move that onto step function state machine Unfortunately scoping it down to just billing of accounts didn't actually solve our problem that didn't magically make this easy to do. That big box of functionality was written a long time ago, had gotten modified and had grown organically over those ten years and so it was still complicated, and they didn't really know what was going on inside of it. If they changed it and broke it they might not have any feedback to tell us they were in trouble you need to go reverse whatever you just did. It also had a lot of old kind of complex logic. Python's greatest skill is not concurrency and over the years they had had problems with scaling this out. They were processing a hundred thousand accounts a night and didn’t want it to take more than 24 hours - ideally a lot less than that. They built out a custom parallelism framework to make that possible, so very roughly we took all the accounts we needed to bill, broke them into chunks and farmed out the work to other individual processes. They started here in the refactoring. They took that high level goal - bill all the accounts - and instead of breaking it into chunks said we can have each individual accounts job billing one account in a step functions workflow, then do a bunch of these in parallel Turns out it has only one state which had all of the code and they literally lifted it out and put it in the middle of a workflow as a single step But they got to act like we're a service now and now have an API interface they can manage - really basic stuff we get from just moving into this single step workflow When they started they were able to use these activity tasks API driven workflows and essentially just talked back and forth with Amazon over their API is to get work and tell that that we had succeeded Using SFN as the engine for handling concurrency meant they could easily scale up or down the degree of concurrency by just submitting more workflows at once instead of needing to provision more machines to handle the additional capacity – right off the bat Yelp got a boost in efficiency of the parallelism They also had improved observability. One problem we had is our old process could get slow it could get slow for every single account and then 24 hours later we would be 10% through our day and we'd say oh what happened that was unfortunate right we want fast feedback when stuff is slowing down and we want to get yelled at really quickly so we can put in these timeouts and we can say this activity needs to take no more than 20 minutes we can put in little heartbeats and we can say if I don't check in with you every minute something is going wrong please don't wait 20 minutes to tell me that the whole thing is screwed up and there's really good flexible support for this and we also got better observability. Old world: Broken accounts have to block all other accounts; recovery is incredibly urgent and time-sensitive New world: “Normal” errors are handled explicitly, Decouple error handling behavior from actual billing behavior, very obvious metrics (did we hit the “handle failure” state too much today?) when things go wrong I talked about that first workflow having just one step right build a whole account do all this stuff but one of the first changes we made was to actually break out two use cases away from that and essentially decouple the error handling so if things were going really well that's awesome we're going to have this handle success state that basically just tells us at Yelp hey it worked and if things go poorly we're going to have a handle failure state and in the beginning we didn't put any complexity into this we're essentially just saying let's represent the fact that it didn't go well in the future maybe we want to page somebody maybe we want to wake Scott up in the middle of the night and say hey you need to go look at something it's broken but for now we're just going to literally have a state that says a thing is going wrong in in one particular workflow so we can keep track of it and one really benefit here is we can say no matter what happens here whether a thing went well or a thing went poorly the state machines shouldn't die in the middle of it right I'm explicitly representing failure here in a way that should theoretically be cleanly handled and if we can automate what to do in the case of failure the account itself can still get billed in a consistent way if not a finally successful way and for us when we're handling money being able to be consistent is worth a tremendous amount And, if when they decide the time is right, we can flexibly pick individual tasks and move them over to lambdas and SFN stays with us the whole way from monolith to serverless, helping us quickly build more efficient and resilient systems. Benefits Really safe refactoring now so when we take that middle bill account step and we say I wish that this were more parallel Amazon step functions has an ability to run things in parallel we can break apart one big task into three parallel tasks I'm not handling any parallelism any joining any waiting for completion which I love doing because it's hard and instead I get to focus on writing really bite-sized functionality in here and so that kind of brings us to what this has to do with building towards serverless. One of the things that we really found was wonderful is step functions isn't very opinionated on how my architecture looks it's happy to support me if I want to write a workflow with one activity and step functions isn't going to judge me or not run if I'm just running a ton of code inside of one activity for 20 minutes at a time but as I sort of refactor my own system as I get ready to move towards a more bite-sized more decoupled future it's there to keep up with us and in the meantime it's providing some really valuable stuff even before I'm in this decoupled serverless microservices future so it's got a lot of ability to add parallelism. It's really segmenting my work into different activities that can't talk to each other except through the step function itself and we get this observability of any errors or of how the system is working and that strong foundation for the future experimentation is what we've gotten really excited about so again just running through the history of what we just described: started out with one big function doing all the stuff and that was where we were when we began put it into a workflow right and the workflow did all the stuff in one big function no big changes there started to decouple it so we took out that error handling we were made ourselves aware of the success and failure and the difference between the two cases so that we could write code that handled them explicitly started to do this refactoring more aggressively over time so we were able to say hey let's break out a parallel state because we think we can we can think it'll make individual functionality more targeted and to the point so I can write something that just knows how to do bookkeeping for the upgrades product versus ad campaign product versus something and all my code gets Dumber in the process longer-term we get to do this sort of directionally: if we think serverless is the right answer if we think lambda is something that's relevant to us, step functions is happy for us to make individual activities lambda functions this is nice from my perspective because I don't want to rush into these kinds of things I want to be ready for it and decide it's the right choice step functions will support us whether we're all on these API driven sort of old school batch jobs or if we want to go ahead and try one lambda function or a few lambda functions where we think they're appropriate - either way the framework still works
- 使用 Step Functions 將功能拆解成一個一個小部分，程式碼更好維護和除錯，code release 效率提高了 20倍，並得到更好的整體效能 Frame.io is a leading workflow management platform for video teams. Frame.io built their own custom solution. Frame.io is a general-purpose toolkit for doing lots of useful things with videos. And, quite sensibly, they decided to offload the actual video processing into the cloud. From small production agencies to major broadcast media companies, video teams of all sizes rely on Frame.io to streamline their media review and collaboration process. Frame.io uses Step Functions to process media, transcode to different formats, create thumbnails, and much more. No fleet code required No deployment code required Frame.io broke everything down into tiny segments, so they could always do the transcoding in a Lambda function. These guys sometimes need to process way bigger chunks, so for those they think an ECS task is a better choice, both because they might run into Lambda limits, and for economic reasons – if you’re going to keep a Docker container running hot for an appreciable number of minutes, you might save some money, compared to Lambda. Anyhow, they were trying to stich this together in a pub/sub architecture and experiencing some pain. Use a collection of Step Functions to process user media files. Job poller pattern is used to run ECS batch tasks. Choice states decide whether to use AWS Lambda or AWS ECS to run transcodes, depending on the duration and file size of the source. Began with SNS for internal service to service messaging, but realized that CloudWatch Events could do everything with more flexibility than SNS, and trigger our Step Functions without a Lambda proxy. Frame.io now has a reliable process for manipulating videos, with a code that is easily managed and debugged, which allows them to increase their code releases 20x. They are also experiencing better overall performance and expect to scale to running 1,000 state machines a minute.
- 容易新增修改工作流程 透過 choice, parallel 等等機制，可以減少應用中可能的程式碼重複 Retry 機制，讓您的應用，在發生問題的時候可以確保工作可以順利完成
- No timeout is set for the activity worker by default, so Step Functions will keep waiting. Explicitly configure timeout in order to prevent from stuck executions ARNs: Storing parameters on S3 and only pass the configuration to the step functions (Executions that pass large payloads of data between states can be terminated. If the data you are passing between states might grow to over 32 KB) AWS Step Functions has a hard quota of 25,000 entries GetActivityTask is designed to provide taskToken exactly once. If a taskToken is dropped while communicating with an activity worker, a number of GetActivityTask requests can be blocked for 60 seconds waiting for a response until GetActivityTask times out. For production systems, we recommend at least 100 open polls per activity ARN's at each point in time. If one poll gets blocked, and a portion of those polls queue up behind it, there are still many more requests that will receive a taskToken to process work while the GetActivityTask request is blocked.