Tag Archives: lambda

AWS 推出了 Live 時全自動上字幕的功能

AWS 推出了在直播時就自動上字幕的功能:「Introducing Live Streaming with Automated Multi-Language Subtitling」,其實就是把現有的服務兜出來:「Live Streaming with Automated Multi-Language Subtitling」。

The solution deploys Live Streaming on AWS which includes AWS Elemental MediaLive, MediaPackage, Amazon CloudFront. The solution also deploys AWS Lambda, Amazon Simple Storage Service, Amazon Transcribe, and Amazon Translate.

對於比較沒那麼要求翻譯品質的情況也許可以玩看看...?

DynamoDB Autoscaling 的各種眉眉角角...

AdRollDynamoDB Autoscaling 的踩雷記錄,裡面有些資訊如果不是跳下去玩應該不會注意到 (魔鬼藏在細節裡的感覺):「Managing DynamoDB Autoscaling with Lambda and Cloudwatch」。

第一個提到的問題是 autoscaling 的觀察對象:

Ideally, the table should scale based on the number of requests that we are making , not the number of requests that are successful.

另外一個是 autoscaling 遇到完全不用的情況下不會 scale down,看起來是某種保護機制。但這使得平常只有拿來讀取的表格在跑完 batch job 後得自己處理 write scale down 問題:

Additionally, at the time of implementing this algorithm, the DynamoDB capacity could not be brought down automatically if the consumption was exactly zero, which can happen if you write to your table in batch instead of realtime, for example.

This meant that, when enabling autoscaling, tables that were read in realtime, but written to in batch, still needed manual intervention to bring the write capacity down after our jobs were done writing.

另外一個問題是 scale down 是有次數限制的:

Another interesting point that might bite users is that capacity decreases are an expensive operation for AWS, so they’re limited.

The number of decreases cited in the documentation can be achieved under very special conditions, since you need to have 4 decreases in the first hour of the day plus one for each of the remaining hours, for a total of 4 (first hour) + 23 (1 hourly) = 27.

後面就是自己研究什麼 algorithm 可以調整的更細,然後用 lambda 重寫... 最後省下 30% 的成本:

Here is where we detected our costs for our batch tables dropping to around 30% of the initial cost.

AdRoll 的規模應該是不小,所以為了省 30% 可以花不少力氣在上面...

AWS Lambda 可以直接掛進 ALB 了...

AWS 這次對 Lambda 還發表了不少功能,除了前面提到透過 Layout 支援其他語言以外 (e.g. Ruby),這邊要再提到另外一個重要的功能。

這次是 ALB 可以直接呼叫 lambda function 了:「Lambda functions as targets for Application Load Balancers」。

以前還得靠 API Gateway 整半天 (因為版本設定),現在直接用 ALB 接就可以了?而且 ALB 這邊有規劃對應的 quota:

There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of data processing to AWS Lambda targets.

這樣就更接近 serverless 了...

AWS Lambda 支援 Ruby 2.5 以及其他語言

AWS 宣佈 Lambda 支援 Ruby 2.5:「AWS Lambda Supports Ruby」。

另外宣佈可以透過 Layer 的方式讓任何程式語言在上面跑 (前面提到的 Ruby 看起來就是用這個方式支援的):「New for AWS Lambda – Use Any Programming Language and Share Common Components」。

The Runtime API is the future of how we’ll support new languages in Lambda. For example, this is how we built support for the Ruby language.

Amazon API Gateway 推出分級收費 (降價)

Amazon API Gateway 推出分級收費:「Amazon API Gateway Announces Tiered Pricing」。

原先的費用不變,大多數的地區是超過 333M reqs/month 的部分降價了... (不過雪梨跟南非是超過 1B reqs/month,而且北卡超過 333M 的部分也只降個零頭,實際比較深的折扣還是在 1B),333M reqs/month 這個量換算下來需要 11.1M reqs/day,平均值要 128 reqs/sec,看起來是設計給整個站都搬上去的折扣方案 (不然就是本身量就超大)。

AWS Lambda 也提供 SLA 了

在「AWS Lambda announces service level agreement」這邊看到 AWS Lambda 提供 99.95% 的 SLA :

We have published a service level agreement (SLA) for AWS Lambda. We will use commercially reasonable efforts to make Lambda available with a Monthly Uptime Percentage for each AWS region, during any monthly billing cycle, of at least 99.95% (the “Service Commitment”).

不過這種東西都是宣示意味比較重 (至少表示 AWS 認為產品穩定度夠上 SLA),倒不是希望會用到...

AWS Lambda 可執行時間提昇

AWS Lambda 的執行時間限制從本來的 5 分鐘變成 15 分鐘了:「AWS Lambda enables functions that can run up to 15 minutes」。

You can now configure your AWS Lambda functions to run up to 15 minutes per execution. Previously, the maximum execution time (timeout) for a Lambda function was 5 minutes.

不過相較於時間拉長,我比較希望能用 Lambda 接 auto scaling,內建的條件設定還是有點陽春...

各家 Serverless 服務冷啟動 (Cold Start) 的時間

看到「Serverless: Cold Start War」這篇分析了 AWS LambdaAzure FunctionsGoogle Cloud Functions 的冷啟動特性。

裡面分析了多久沒有 request 會需要冷啟動、記憶體的大小對於冷啟動速度的影響、程式語言的影響,以及程式大小的影響。

對於量很少,但是又很在意速度的人來說也許可以研究一下。不過只要有點量 (就算一分鐘只有一次) 應該都不會遇到這塊問題...

Amazon EBS Snapshot 支援 Lifecycle Management

以往用 Amazon EBS Snapshot 需要用 Lambda 當 cron job 建立 snapshot,以及管理要存的數量 (要刪掉舊的),現在 AWS 直接提供服務幫你處理:「New – Lifecycle Management for Amazon EBS Snapshots」。文章的截圖就說明了這個新功能:

不收另外的費用,不過目前只有開放三區,東京不在裡面:

You can create and use Data Lifecyle Manager policies at no charge; you pay the usual storage charges for the EBS snapshots that it creates.

Data Lifecycle Manager is available in the US East (N. Virginia), US West (Oregon), and EU (Ireland) Regions.

先繼續用 Lambda,等東京有的時候再換過去...

SQS 可以打進 Lambda 了...

在昨天的 AWS 台北高峰會上,AWS 的人有提到這個功能應該要正式推出了,果然在回來不久後就看到消息了:「AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources」。

We can now use Amazon Simple Queue Service (SQS) to trigger AWS Lambda functions! This is a stellar update with some key functionality that I’ve personally been looking forward to for more than 4 years. I know our customers are excited to take it for a spin so feel free to skip to the walk through section below if you don’t want a trip down memory lane.

這算是 Serverless 架構下很自然會想要做的一環,當 SQS 裡面有東西的時候就呼叫 Lambda 起來做事,以往一般會透過 SNS 在中間接起來 (或是拿 S3 惡搞,因為 S3 也可以串 Lambda...),現在可以直接串了:

By adding support for SQS to Lambda we’re removing a lot of the undifferentiated heavy lifting of running a polling service or creating an SQS to SNS mapping.

這個功能本身不收費,但他需要的 SQS API call 與產生的 Lambda 當然是需要收費的:

There are no additional charges for this feature, but because the Lambda service is continuously long-polling the SQS queue the account will be charged for those API calls at the standard SQS pricing rates.