Category: Serverless

 昨年の 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年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 RDS Proxyを利用してみよう Amazon RDS Proxyは、プレビューであり、留意事項がいくつかあります。 現在、MySQLバージョン5.6または5.7で実行されるAmazon RDS MySQL、または、Aurora […]

特にサーバーについて考える必要がない場合は、時間はあっと言う間に過ぎていきます。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 […]