Lambdaのメモリ割り当てを自動で最適化！！AWS Lambda Power Tuning | DevelopersIO
CX事業本部@大阪の岩田です。re:invent2019のセッションで知ったAWS Lambda Power Tuningを試してみたので簡単にご紹介します。 AWS Lambda Power Tuningとは？ Lambdaのメモリ割り当てを自動で最適化するためのツールです。Step Functionsを利用して対象のLambdaを様々なメモリ設定で実行し、どの設定値が一番パフォーマンスが良いのか？どの設定値が一番コスト効率が良いのか？といった情報をレポートしてくれます。 なにが嬉しいの？ Lambdaのチューニング手法として割り当てるメモリサイズを増やすという手法が広く知られています。メモリサイズを増やすことで、Lambda実行環境のCPUパワーや、利用可能なNW帯域が向上します。また、メモリサイズを増やすことで処理時間が短くなり、結果的にコストが下がるという効果も期待できます。しかし
Understanding AWS Lambda Proactive Initialization
AWS Lambda warms up your functions, such that 50%-85% of Lambda Sandbox initializations don't increase latency for users. In this article we'll define Proactive Initialization, observe its frequency, and help you identify invocations where your cold starts weren't really that cold. July 13, 2023 This post is both longer and more popular than I anticipated, so I’ve decided to add a quick summary: T
Lambda 実行環境 - AWS Lambda
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Lambda 実行環境 Lambda は、実行環境で関数を呼び出します。これにより、安全で分離されたランタイム環境が提供されます。実行環境は、関数の実行に必要なリソースを管理します。また、関数のランタイム、および関数に関連付けられた外部拡張機能のライフサイクルサポートも提供します。 関数のランタイムは、ランタイム API を使用して Lambda と通信します。拡張機能は、拡張機能 API を使用して Lambda と通信します。拡張機能は、Telemetry API を使用することで、関数からログメッセージとその他のテレメトリを受け取ることもできます。 Lambda 関数を作成する際に、関数に許可するメモリ容量や最大実行時間など、設定情報を指定します。Lambda
AWS Lambdaのデプロイパッケージをどの範囲で構築すべきか | DevelopersIO
サーバーレス開発を行う際にAWS Lambdaのデプロイパッケージをどの様な範囲で構築するべきなのか、Lambdaレイヤーはどう使えば良いのかについて私見をまとめました。 はじめに おはようございます、加藤です。AWSで本格的なサーバーレス開発を行う際につまづいたり、悩むポイントとしてLambdaのデプロイパッケージをどのような範囲にすべきかということがあります。デプロイパッケージをどうすべきか私の考えをまとめてみました。 何回か出てくるディレクトリ図については、あくまでをイメージを掴んで貰うためのもので、この通りにディレクトリを構成し動くことを保証するものではありません。具体的なAWS CDKを使った構築方法は来月ぐらいにでも別途ブログにする予定です。 デプロイパッケージとは デプロイパッケージは、関数のコードと依存関係を含むZIPアーカイブです。コンパイル言語（Go、Javaなど）の場
Lambdaのhandler外(メソッド以外)のコードは「コールドスタート時の1回だけ実行される」という話 | DevelopersIO
Lambdaのhandler外に、ライブラリの初期化コードなどを書く場合があります。 普段、何気なく書いていますが、Lambdaの仕組み的にhandler外(メソッド以外)のコードはコールドスタート時の1回だけ実行されます。 そのため、「現在時刻を変数に初期設定したとき、意図的に更新しない限り、Lambdaが複数回実行されても同じ時刻を指す」という状態になったりします。 注意：同じLambda環境の場合です。新しいLambda環境で実行される場合（スケールアウト、コード変更、時間経過など）は、それぞれのLambda環境で1回目と2回目以降で同様です。 実際に試してみました。 最初に結論 弊社岩田の資料より 下記の発表資料が超わかりやすいです！（他の内容もタメになるのでおすすめです！） Serverless Meetup Osaka #5 で「VPC Lambda×RDSのデメリットについて
モニタリングとログ記録 - AWS AppSync
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS AppSync GraphQL API をモニタリングし、リクエストに関連する問題をデバッグするには、Amazon CloudWatch Logs へのログ記録を有効にします。 セットアップと設定 GraphQL API の自動ログ記録を有効にするには、 AWS AppSync コンソールを使用します。 AWS Management Console にサインインして、AppSync コンソール を開きます。 API] ページで、GraphQL API の名前を選択します。 API のホームページのナビゲーションペインで、[設定] を選択します。 [ログ記録] で以下を行います。 [ログを有効にする] をオンにします。 リクエストレベルの詳細なロギングを行うに
KinesisとSQSの比較検討のため、Amazon Kinesis Data Streams のチュートリアルをやってみた | DevelopersIO
モバイルアプリサービス部の五十嵐です。 KinesisとSQSの比較検討のため、Kinesisをより知るために公式のチュートリアルをさわってみました。 前提知識として 前提知識として、ストリームとシャード、プロデューサーとコンシューマーなどの用語の意味を抑えておくといいと思います。AWS Black Belt Online Seminarのスライドがわかりやすかったので紹介しておきます。 AWS Black Belt Online Seminar 2017 Amazon Kinesis チュートリアル チュートリアル: Amazon Kinesis Data Streams を使用したウェブトラフィックの可視化 - Amazon Kinesis Data Streams 概要 このサンプルアプリケーションは、さまざまな URL からのシミュレート上の閲覧者の数を Kinesis data
AWS AppSync の GraphQL リクエストの未認証エラーを解決する
AWS AppSync で GraphQL リクエストを実行しているときの「Unauthorized」エラーのトラブルシューティング方法を教えてください。 簡単な説明 レスポンスで返される HTTP ステータスコードによって定義される Unauthorized エラーには、次の 2 種類があります。 401 Unauthorized: 認証情報がないか無効であるため、リクエストは AWS AppSync または認証モードのいずれかによって拒否されました。 Unauthorized タイプのエラーを伴う200 OK レスポンス:リゾルバーレベル以上の問題により、リクエストが拒否されました。 不正なエラーの原因を特定するには、ウェブブラウザで問題を再現してみます。次に、ブラウザのネットワークツールを使用して、HTTP 要求メッセージとレスポンスメッセージをキャプチャします。メッセージを分析して
PowerPoint プレゼンテーション
© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. AWS Webinar https://amzn.to/JPWebinar https://amzn.to/JPArchive Solutions Architect Amazon API Gateway [AWS Black Belt Online Seminar] © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ❏ ❏ ❏ Amazon API Gateway AWS Cloud9 © 2019,
【AWS】AWS APIの認証・認可の仕組みを理解する【Signature V4】 - Qiita
はじめに Amplifyを利用してアプリケーションを作る場合、Cognito User Pool／Cognito Identity Pool（Cognito Federated Identities）を利用してAPI GatewayでAuthorizationする方法が暗黙裡にデフォルトになっているように見えます。 よく使われるであろうと思われる割には、その仕組みについての説明があまり見当たらなかったので解説記事を書こうとしましたが、前提となる事項があまりにも多いことが分かったので、個別の記事として分離しました。 本稿では、AccessKeyIdやSecretAccessKeyの使われ方、AWS APIにおけるSignature V4の仕組みなどについて解説します。 API GatewayのAuthorization方式として「AWS_IAM」という項目を選択できますが、本稿の内容を理解す
AWS Lambdaに対するユニットテスト - public note
AWS Lambda に対するユニットテスト(以下、UT)で気をつけていることを言語化して、記録に残します。 結論 はじめに 実現したいこと 考えたこと 工夫したこと 具体例 処理内容 ディレクトリ構造 テストデータ Lambda Function テスト共通処理 テストコード まとめ 結論 AWSサービスに関わらない処理ステップを切り出して、先にテスト駆動開発で実装する、という考え方をしています。 はじめに AWS Lambda は、言わずと知れた FaaS(Function as a Service) です。 開発単位が関数であるために気軽につくりはじめることができますが、 心のままにコードを書いてしまうと、節々にAWSの要素が入り乱れてしまい、 結果としてUTができない成果物になってしまうことがありました。 こうなってしまうと、取りうる手段は二択です。 リファクタリングする そのまま
DynamoDB全くわからない、から、ちょっとわかるようになるまでの道しるべ | DevelopersIO
DynamoDBを利用するためのポイントをざっくりまとめた。 リンク集みたいな感じになっていますが、どこから手をつけて良いかわからない方は参考にしてみてください。 目次 DynamoDB概要 Amazon DynamoDB は、どのような規模でも信頼性が高いパフォーマンスを維持できる、非リレーショナルデータベースです。 完全マネージド型、マルチリージョン、マルチマスターのデータベースで、レイテンシーを 10 ミリ秒未満に維持でき、 組み込みのセキュリティ、バックアップと復元、インメモリキャッシュを利用できます。 Amazon DynamoDB DynamoDBの特徴 フルマネージドサービス データの格納と取得に特化（高度な最適化）されている 表結合など柔軟なクエリを発行するのは不得意 「値」とそれを取得するための「キー」だけを格納するというシンプルな機能を持った「Key-Valueストア」
DynamoDB の設計について考えてみる。 - Qiita
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
AWS Lambda（Python） の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │ ├── common.sh │ └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src
全部教えます！サーバレスアプリのアンチパターンとチューニング
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Keisuke Nishitani (@Keisuke69), Specialist SA, Serverless Jun 2, 2017 全部教えます！ サーバレスアプリのアンチパターン とチューニング © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. T H A N K S T O O U R F R I E N D S A T : © 2017, Amazon Web Services, Inc.
［速報］AWS、オンプレミス向けコンテナ基盤ソフトウェア「Amazon ECS Anywhere」「Amazon EKS Anywhere」発表、オープンソース化も。AWS re:Invent 2020
［速報］AWS、オンプレミス向けコンテナ基盤ソフトウェア「Amazon ECS Anywhere」「Amazon EKS Anywhere」発表、オープンソース化も。AWS re:Invent 2020 Amazon Web Services（AWS）の年次イベント「AWS re:Invent 2020」がオンラインで開幕しました。 初日の基調講演には同社CEO Andy Jassy氏が登場。 昨年までラスベガスの大規模会場で行われていたのと同様に（画面で見るかぎり、おそらくCGではなく本物の）ステージセットが用意され、効果音として要所で観衆の拍手やコールも再現されていました。 そのため、オンラインで見ている分には昨年までとほぼ変わらない基調講演です。 Jassy氏は、AWSはコンテナを実行するベストな場所であるとして、AWSスタイルのコンテナ管理を提供する「Amazon ECS（Elas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヘキサゴナルアーキテクチャを利用したLambda 関数のドメインモデルの実装 Live
Error on amazon SES: SendEmail operation: Illegal addres
API Gateway で WebSocket を利用したAPI作成 - Qiita
20200708サーバーレスでのAPI管理の考え方