Category: Serverless

先日 (2020/06/10) 開催しました AWS Black Belt Online Seminar「サーバーレス イベント駆動アーキテクチャ」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200610 AWS Black Belt Online Seminar サーバーレスイベント駆動アーキテクチャ from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. オーダーサービスの例をとると、非同期になったことにより在庫が結果としてなかったなどの応答はどうやってクライアントに通知するべきでしょうか？ A. このような場合に備えて補償トランザクションを定義します。具体的には注文を受け付けた時点では即座に注文を受け付けた状態としてクライアント側に応答しますが、在庫確認処理で在庫が無かった場合、後から在庫が無かったので注文がキャンセル(または入荷するまで処理をペンディング)される旨をメールで伝えるなどの処理を行うことになります。補償トランザクションはビジネスと密接に関わるため、関連するステークホルダーと協議して決めることになるでしょう。 Q. 福井さんの Black Belt でサーバーレスパターンの解説をしてほしいです。 A. リクエストありがとうございます。前向きに検討させて頂きます。 Q. SQS とSNS はどう使い分けるのでしょうか？過去事例では SQS + SNS を組み合わせるケースが多いように思いますが、組わせるメリットは何でしょうか？ A. SNS はパブリッシュ(発行) / サブスクライブ( 購買)パターンを実現するサービスで、このパターンのメリットは発行者が購買者に対する知識を持つ必要がなく、発行者の実装に影響を与えることなく特定のトピックに関心がある購買者を自由に追加できる点にあります。さらに SNS には AWS Lambda、Amazon SQS、HTTP/S、Email、SMS […]

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System（EFS）をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン（AZ）にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud（EC2）インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ（関数、コンテナ、仮想サーバー）を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば： /tmpで使用可能な容量（512MB）より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する（一意のファイル名またはファイルシステムロックを使用）。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する（同時アクセス用のファイルシステムロックを使用）。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud（VPC）に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service（S3）またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

 昨年の re:Invent で、Amazon Managed Apache Cassandra Service (MCS) のプレビュー版を紹介しました。過去数か月の間に、このサービスは多くの新機能を導入し、今日 Amazon Keyspaces (Apache Cassandra 用) という新しい名前で一般公開します。 Amazon Keyspaces は Apache Cassandra 上に構築されており、フルマネージドのサーバーレスデータベースとしてご利用いただけます。アプリケーションは、既存の Cassandra Query Language (CQL) コードを使用して、まったくまたはほとんど手を加えずに Amazon Keyspaces からデータを読み書きできます。各テーブルでは、以下のように、ユースケースに応じて最適な設定を選択できます。 オンデマンドでは、実際に行った読み取りと書き込みに基づいて料金が発生します。これは、ワークロードが予測できないときに最適なオプションです。 プロビジョニングされた容量では、容量設定を事前に行うことで、予測できるワークロードのコストを削減できます。 また、Auto Scaling を有効にすることで、コストをさらに最適化できます。これにより、その日のトラフィックの変化に応じてプロビジョニングされた容量設定が自動的に更新されます。 Amazon Keyspaces の使用 私が子供の頃に構築した最初の「本格的な」アプリケーションの 1 つは、本用のアーカイブでした。それを今すぐ、以下を使用してサーバーレス API として再構築したいと思います。 データを保存するための Amazon Keyspaces。 ビジネスロジック用の AWS Lambda。 Amazon API Gateway と新しい HTTP API。 Amazon […]

 Amazon EventBridge は、アプリケーションを簡単に接続できるようにするサーバーレスイベントバスです。AWS サービスのデータ、独自のアプリケーション、Software-as-a-Service (SaaS) パートナーとの統合を使用できます。昨年の re:Invent では、EventBridge スキーマレジストリと検出のプレビューで、イベントの構造 (スキーマ) を中央に保存する方法を導入しました。また、Java、Python、Typescript 用にイベントを処理するコードを生成することにより、コード内のイベントの使用を簡素化しました。 本日より、EventBridge スキーマレジストリが一般公開され、リソースポリシーのサポートが追加されたことをお知らせいたします。リソースポリシーにより、異なる AWS アカウントと組織間でスキーマリポジトリを共有できます。このようにして、異なるチームの開発者は、別のチームが共有レジストリに追加したスキーマを検索して使用できます。 EventBridge スキーマレジストリリソースポリシーの使用 企業は、一般的にさまざまなサービスに取り組んでいるさまざまな開発チームを抱えています。より具体的な例を示すために、互いに通信を行う必要があるサービスに取り組んでいる 2 つのチームを見てみましょう。 CreateAccount 開発チームは、ウェブ/モバイルクライアントからリクエストを受信して、会社の新しい顧客アカウントを作成するフロントエンド API に取り組んでいます。 FraudCheck 開発チームは、新しく作成されたアカウントのデータをチェックするバックエンドサービスに取り組み、それらが偽物であるリスクを推定します。 各チームは、独自の AWS アカウントを使用してアプリケーションを開発しています。 EventBridge を使用すれば、次のアーキテクチャを実装できます。 フロントエンドの CreateAccount アプリケーションは、Amazon API Gateway を使用して、Python で記述された AWS Lambda 関数を使ってリクエストを処理します。新しいアカウントが作成されると、Lambda 関数はカスタムイベントバスで ACCOUNT_CREATED イベントを発行します。 バックエンドの FraudCheck Lambda 関数は Java で作成されており、ACCOUNT_CREATED イベントを受信して Amazon Fraud Detector […]

本投稿は、Senior Developer Advocate, AWS Serverless Applications のEric Johnsonの寄稿によるものです。 2015年7月、AWSはAmazon API Gatewayを発表しました。これにより、開発者はさまざまな種類のアーキテクチャのフロントに配置して安全でスケーラブルなAPIを迅速に構築できるようになりました。それ以来、API Gatewayチームは顧客向けの新しい機能とサービスを構築し続けています。 図1: API Gateway機能追加タイムライン 2019年初頭、チームは現在のサービスを評価し、API Gatewayの次の姿がどうあるべきか計画を立てました。新しい言語と技術によるプロトタイプを作成し、RESTおよびWebSocket APIの構築から学んだ教訓を適用し、そして、顧客のフィードバックを入念に調べました。その結果として、Amazon API GatewayのHTTP APIが完成しました。これは、より高速で、より低コストで使い易くなるように、ゼロから構築されたサービスです。要するに、HTTP APIはAPIを構築するためのより良いソリューションを提供します。APIを構築していて、HTTP APIが要件に合っている場合は、HTTP APIから始めるのが良いでしょう。   より速く ほとんどのユースケースで、HTTP APIはレイテンシを最大60％削減します。開発者は、最小限のレイテンシと最大限の機能を備えたアプリケーションの構築に苦心しており、アプリケーションプロセスに関係する各サービスがレイテンシを追加する可能性があることを理解しています。 図2: すべてのサービスがレイテンシを追加   これを念頭に置いて、HTTP APIは、API Gatewayサービスのレイテンシオーバーヘッドを削減するように構築されています。リクエストとレスポンスの両方を足し合わせても、すべてのリクエストの99％（p99）でHTTP APIからの追加レイテンシが10ミリ秒未満になります。   より低コストで Amazonでは、中核となるLeadership Principles の一つとして、Frugality（倹約）があります。私たちは、費用対効果の高い方法で物事を行い、その節約がお客様に還元されることを信じています。新しいテクノロジーが利用可能になり、ほぼ5年間にわたりAPI Gatewayを運用し得た専門知識により、より効率的に実行するためにHTTP APIを構築しました。 図3: REST / HTTP APIの価格比較 us-east-1の価格設定を使用して説明します。図3は、1か月あたりの1億回、5億回、および10億回のリクエストのコスト比較を示しています。全体的に、HTTP APIは、API Gateway REST APIと比較して少なくとも71％低コストです。   よりシンプルに HTTP […]

 クラウドでアプリケーションをビルドして実行するとき、どのくらい「正しくやっているか」を自問していますか? 実際、これは非常に良い質問です。私たちは良い答えを得るために、AWS Well-Architected フレームワークを 2015 年に公開しました。これは、ワークロードをベストプラクティスと比較し、改善方法に関するガイダンスを得るための正式アプローチです。今日、「Well-Architected フレームワーク」は、顧客とパートナーがクラウドアーキテクチャを設計および評価するための一貫した方法を提供します。この方法は、5 つの柱に基づいています。 優れた運用効率 セキュリティ 信頼性 パフォーマンス効率 コストの最適化 より多くのワークロード固有のアドバイスを提供するために、2017 年に「レンズ」の概念でフレームワークを拡張し、一般的な視点を超えて特定のテクノロジードメインに参入しました。現在、使用できるレンズは 3 つあります。 サーバーレス ハイパフォーマンスコンピューティング (HPC) IoT (モノのインターネット) 何かを改善するには、最初に何をどのように測定するかを決める必要があります。より構造化された方法でワークロードを確認できるようにするために、AWS マネジメントコンソールで利用できる無料ツールである AWS Well-Architected Tool を 2018 年にリリースしました。ここでは、ワークロードを定義し、5 つの柱に関する質問に答えることができます。 Well-Architected Tool はさまざまな方法で使用できます。以下に例を示します。 特定のアプリケーションで作業している場合、ツールを使用してリスクを評価し、改善すべき領域を見つけることができます。 複数のアプリケーションを担当している場合は、ツールを使用して、すべてのアプリケーションの現在のステータスを確認できます。 本日、レンズを Well-Architected Tool に適用する機能を追加しました。最初にサーバーレスレンズをご利用いただけます。 AWS Well-Architected Tool でサーバーレスレンズを使用する Well-Architected Tool コンソールで、ワークロードを定義することから始めます。現在、Amplify フレームワークを使用してモバイルアプリのバックエンドを構築しています。簡単なゲームになりますが、ユーザーのデータを保存するために DynamoDB グローバルテーブルを使用し、アプリケーションは 2 つの AWS リージョンで実行されます。AWS […]

本投稿は、Principal Solutions Architectである George Maoの寄稿によるものです。   更新 – (2020年6月30日 PDT): MySQLおよびPostgreSQL対応のAmazon RDS Proxyが一般にご利用可能になりました。 更新 – (2020年4月8日 PDT): PostgreSQL 互換の Amazon RDS Proxy (プレビュー)を発表しました。プレビューではバージョン10.11と11.5がサポートされています。 AWSサーバーレスプラットフォームは、デマンドに応じて自動的に拡張するアプリケーションを構築することができます。大量アクセスがある間、 Amazon API Gateway と AWS Lambda は負荷に応じて自動的にスケールします。 多くの場合、開発者は、Lambda関数からリレーショナルデータベースに保存されたデータにアクセスする必要が出てきます。しかし、Lambdaからデータベースへの多すぎるコネクションにより過負荷にならないようにすることは難しい場合があります。リレーショナルデータベースの最大同時接続数は、データベースのサイズによって異なります。 これは、各コネクションがデータベースサーバー上のメモリとCPUリソースを消費するためです。Lambda関数は数万の同時接続数までスケールできるため、それに対応するには、データベースはクエリを実行するだけでなく、コネクションを維持するためにより多くのリソースが必要になります。 スケーリングの詳細については、アーキテクチャブログの投稿「サーバーレスアプリを大規模に設計する方法」も参照してください。 RDSを使用したサーバーレスアーキテクチャ Lambdaは数万の同時リクエストに応じて簡単にスケールできるため、そのような状況において、この設計ではバックエンドのリレーショナルデータベースに高い負荷がかかります。通常は、リレーショナルデータベースは、Lambdaのスケーラビリティに応じた同時接続を受け入れるように設計されていません。 Amazon RDSのデータベースプロキシ 本日(2019年12月3日 PST)、Amazon RDS Proxyのプレビューを発表できることを嬉しく思います。 RDS Proxyは、アプリケーションとRDSデータベースの間の仲介役として機能します。RDS Proxyは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑えます。 データベースへのSQL呼び出しを行うアプリケーションには、RDS Proxyを使用できます。ただし、サーバーレスのコンテキストでは、これによりLambda利用の体験がどのように改善されるかに焦点を当てています。RDS Proxyは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。 Lambda関数は、データベースインスタンスではなくRDS Proxyと対話します。RDS Proxyは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDS Proxyは自動的にスケーリングされるため、データベースインスタンスでコネクション管理に必要なメモリとCPUリソースが少なくなります。また、暖機されたコネクションプールを使用することでパフォーマンス向上にもつながります。RDS Proxyを使用すると、アイドル接続のクリーンアップとコネクションプールの管理を処理するコードが不要になります。Lambda関数コードは、より簡潔でシンプルとなり、保守性が向上します。 Amazon […]

特にサーバーについて考える必要がない場合は、時間はあっと言う間に過ぎていきます。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） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。