Category: Serverless

特にサーバーについて考える必要がない場合は、時間はあっと言う間に過ぎていきます。AWS Lambda は 5 年目を迎えました。チームは常に、顧客がより簡単な方法で、アプリケーションを構築して実行できるようにする新しい方法を探しています。 ミッションクリティカルなアプリケーションがサーバーレスに移行するにつれて、顧客はアプリケーションのパフォーマンスをさらに制御する必要があります。 本日、プロビジョニングされた同時実行数を開始します。これは、関数を初期化し、2 桁のミリ秒以内に応答するためのハイパーレディを維持する機能です。 ウェブおよびモバイルバックエンド、レイテンシーの影響を受けやすいマイクロサービス、同期 API などの対話型サービスの実装に最適です。 Lambda 関数を呼び出すと、呼び出しは実行環境にルーティングされ、リクエストが処理されます。関数がしばらく使用されていない場合、より多くの同時呼び出しを処理する必要がある場合、または関数を更新する場合、新しい実行環境が作成されます。実行環境の作成は、関数コードのインストールとランタイムの開始を処理します。デプロイパッケージのサイズやランタイムとコードの初期化時間に応じて、新しい実行環境にルーティングされる呼び出しのレイテンシーーが発生する可能性があります。このレイテンシーは通常、「コールドスタート」と呼ばれます。 ほとんどのアプリケーションでは、この追加のレイテンシーは問題になりません。ただし、一部のアプリケーションでは、このレイテンシーは許容されない場合があります。 関数のプロビジョニングされた同時実行を有効にすると、Lambda サービスは実行環境のリクエスト数を初期化して、呼び出しに応答する準備ができるようにします。 プロビジョニングされた同時実行の設定 同じ Java コードを使用し、Amazon API Gateway によってトリガーできる 2 つの Lambda 関数を作成します。本番稼働ワークロードをシミュレートするために、これらの関数は、初期化段階で 1,000 万回、呼び出しごとに 20 万回の数学的計算を繰り返しています。計算は java.Math.Random と条件 (if …) を使用して、コンパイラの最適化 (反復の「ループ解除」など) を回避します。各関数には 1 GB のメモリがあり、コードのサイズは 1.7 MB です。 2 つの関数のいずれかでのみプロビジョニングされた同時実行を有効にして、同様のワークロードに対する反応を比較できるようにします。Lambda コンソールで、いずれかの機能を選択します。構成タブに、新しいプロビジョニングされた同時実行設定が表示されます。 設定を追加を選択します。プロビジョニングされた同時実行は、特定の Lambda 関数バージョンやエイリアスに対して有効にできます ($LATEST は使用できません)。関数のバージョンごとに異なる設定を指定できます。エイリアスを使用すると、これらの設定を適切な関数バージョンに簡単に有効化できます。私の場合、AWS SAM AutoPublishAlias 関数設定を使用して、最新バージョンに更新し続けるエイリアスライブを選択します。プロビジョニングされた同時実行の場合、500 と保存を入力します。 現在、プロビジョニングされた同時実行の構成は進行中です。実行環境は、私の入力に基づいて同時に着信するリクエストを処理する準備ができています。 この間、関数は利用可能なままで、トラフィックを処理し続けます。 数分後、同時実行が準備状態になります。これらの設定により、最大 500 件の同時実行リクエストで、それらを処理するための準備が整った実行環境が見つかります。それを超えても、Lambda […]

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第１回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは？」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは？ このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです（同じビルなので移動が楽！）。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう！   著者について 木村 公哉（Kimura, Koya） 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠（Uehara, Makoto） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

AWS Step Functions を使用すると、アプリケーションにサーバーレスワークフローのオートメーションを追加できます。ワークフローのステップは、 AWS Lambda 関数、Amazon Elastic Compute Cloud (EC2)、またはオンプレミスなど、どこでも実行可能です。ワークフローの構築を簡略化するために、Step Functions は AWS の複数のサービス (Amazon ECS、AWS Fargate、Amazon DynamoDB、Amazon Simple Notification Service (SNS)、Amazon Simple Queue Service (SQS)、AWS Batch、AWS Glue、Amazon SageMaker、および (ネストされたワークフローを実行するために) Step Functions 同士) と直接統合されています。 本日より、Step Functions は Amazon EMR に接続されました。これにより、最小限のコードでデータ処理および分析ワークフローを作成して、時間の節約、クラスターの使用の最適化を実現することができます。たとえば、機械学習用のデータ処理パイプラインの構築は時間がかかり、困難です。この新しい統合により、並列実行や前のステップにおける結果からの依存関係といったワークフロー機能のオーケストレーションや、データ処理ジョブを実行する際の障害および例外の処理が簡単になります。 具体的には、Step Functions ステートマシンで以下のことができるようになりました。 EMR クラスターの作成、終了 (クラスターの終了保護の変更も可能)。これを行うと、既存の EMR クラスターをワークフローで再利用したり、ワークフローの実行中にオンデマンドで作成したりできます。 クラスターの EMR ステップの追加、キャンセル。 EMR ステップは、クラスターにインストールされたソフトウェア (Apache、Spark、Hive、または Presto といったツールなど) […]

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください（なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください）。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール（ブラウザプラグインなど）を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

AWS Lambda のマネジメントコンソールに新しい「サーバーレスアプリケーションの作成」機能が追加されていることにお気付きですか? サーバーレス環境である Lambda ではすぐに処理実行環境が利用可能になり、Webのコンソールからロジックを実装するだけで容易にちょっとした処理を開発できます。一方で、この次のステップとして、 Lambda 関数だけでなく、アプリケーションとしての開発や管理ができていない 環境の再現（開発環境からステージングや本番環境へ）、デプロイの継続実行（CI/CD）の環境が整備できずに、Webコンソール上でいまだにコード変更している という話を聞くことがあります。実際には、デプロイ/環境設定のコード化（Infrastructure as Code: IaC）には AWS CloudFormation や Serverless Application Model（SAM）などがあり、CI/CD には CODEシリーズなどがあるのですが、サーバーレス開発を始めたばかりだと、そこへの次の一歩に二の足を踏まれているケースを見かけることがあります。 そんな方に向けた機能が、新しい「サーバーレスアプリケーションの作成」機能です。これを使うと、特定ユースケースのアプリケーションをテンプレートベースでひとまとめに作成し、CI/CD パイプラインまで一気に構築してくれます。 簡単に、この機能の利用ステップを紹介します。

マイクロサービスを使用すると、アプリケーションのスケーリングが容易になり、開発が高速になりますが、分散アプリケーションのコンポーネントを調整するのは大変な作業になりかねません。 AWS Step Functions は、各ステップが前のステップの出力を入力として受け取るステップで構成されるワークフローを設計および実行できるようにすることで、タスクの調整を容易にする完全マネージド型サービスです。たとえば、Novartis Institute for Biomedical Research は、Step Functions を使用して、クラスターの専門家に頼らずに科学者が画像分析を実行できるようにしています。 Step Functions は最近、コールバックパターンなどの非常に興味深い機能を追加して、人の活動とサードパーティサービスの統合を簡素化し、ネストされたワークフローを組み合わせてモジュール式の再利用可能なワークフローを組み立てました。今日、ワークフロー内の動的並列処理のサポートを追加します! 動的並列処理の仕組み ステートマシンは、JSON ベースの構造化言語である Amazon States Language を使用して定義されます。Parallel 状態を使用して、ステートマシンで定義された一定数のブランチを並列に実行できます。 現在、Step Functions は、動的並列処理のために新しい Map 状態タイプをサポートしています。 Map 状態を設定するには、完全なサブワークフローである Iterator を定義します。Step Functions の実行が Map 状態になると、状態入力の JSON 配列を反復処理します。各アイテムに対して、Map 状態は 1 つのサブワークフローを、潜在的に並列に実行します。すべてのサブワークフローの実行が完了すると、Map 状態は、Iterator が処理した各アイテムの出力を含む配列を返します。 MaxConcurrency フィールドを追加することにより、Map が実行する同時サブワークフローの数の上限を設定できます。 デフォルト値は 0 で、並列性に制限はなく、可能な限り同時に反復が呼び出されます。 1 の MaxConcurrency 値は、入力状態での出現順に Iterator を一度に 1 つの要素を呼び出す効果があり、前の反復が実行を完了するまで反復を開始しません。 新しい Map […]

 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、AWS Identity and Access Management (IAM) ポリシーは、Amazon Aurora リソースを管理できるユーザーを決定するアクセス許可を割り当てることができます。たとえば、IAM を使用して、DB クラスター、タグリソース、またはセキュリティグループを作成、記述、変更、削除できるユーザーを決定できます。Amazon Aurora では、データベースユーザーを IAM ユーザーとロールに関連付けることができます。 この記事では、AWS Lambda 関数を使用して IAM を使用して Amazon Aurora データベースにアクセスする方法を説明します。 概要 IAM データベース認証を使用して、DB クラスターに接続できます。この方法を使用すると、パスワードを設定ファイルに保存する代わりに、生成された認証トークンでデータベースにアクセスできます。Amazon Aurora は、アプリケーションから接続を作成するために 15 分間有効な AWS Signature Version 4 認証トークンを生成します。認証は IAM によって外部で完全に管理されるため、データベースに認証情報を作成する必要はありません。 チュートリアル 次の図は、ワークフローを示しています。 Lambda は、サーバーのプロビジョニングまたは管理を行うことなく、コードを実行するコンピューティングサービスです。Lambda は、必要な場合にのみコードを実行し、1 日あたり数回のリクエストから毎秒数千ものリクエストにまで自動的にスケールします。Lambda を使用するときは、コードに対してのみ責任があります。Lambda は、メモリ、CPU、ネットワークや他のリソースのバランスを提供するコンピュートフリートを管理します。Lambda は Lambda 関数を実行し、結果を返します。 コンソールで Lambda 関数を作成する方法は次のとおりです。 [AWS Lambda […]

本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。 AWS Lambda 関数が Amazon VPC ネットワークでどのように機能するかが大幅に改善されたことをお知らせします。 2019年9月3日（PST）のローンチ機能により、関数の起動パフォーマンスが劇的に改善され、Elastic Network Interface がより効率的に使用されるようになります。 これらの改善は、すべての既存および新しい VPC 接続の関数に追加費用なしで展開されています。 ロールアウトは 2019年9月3日（PST）から始まり、すべてのリージョンで今後数か月にわたって徐々に展開されます。 Lambda は2016年2月に初めて VPC をサポートし、AWS Direct Connect リンクを使用して VPC またはオンプレミスシステムのリソースにアクセスできるようになりました。 それ以来、お客様が VPC 接続を広く使用して、さまざまなサービスにアクセスしているのを見てきました。 Amazon RDS などのリレーショナルデータベース Redis 用 Amazon ElastiCache または Amazon Elasticsearch Service などのデータストア Amazon EC2 または Amazon ECS で実行されているその他のサービス 2019年9月3日（PST）のリリース機能により、LambdaとVPC 間のこの接続性が強化されます。 AWS Lambda がこれまで […]