Amazon Web Services ブログ

Category: Serverless

【開催報告】ビルシリーズ@住友不動産六本木グランドタワー 第1回

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

Read More

新着情報 – Step Functions を使用して Amazon EMR ワークロードをオーケストレートする

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 といったツールなど) […]

Read More

Amazon SNS, Amazon SQS, AWS Lambda のデッドレターキューによる耐久性のあるサーバーレスアプリケーション設計

この投稿は 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 […]

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作成した、その後…

本記事は「新しいサーバーレスアプリ作成機能で 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 […]

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作れます

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

Read More

新機能 – Step Functions が動的並列処理をサポート

マイクロサービスを使用すると、アプリケーションのスケーリングが容易になり、開発が高速になりますが、分散アプリケーションのコンポーネントを調整するのは大変な作業になりかねません。 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 […]

Read More

サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証

 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、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 […]

Read More

[発表] Lambda 関数が VPC 環境で改善されます

本投稿は AWS サーバーレス アプリケーションのプリンシパルデベロッパーアドボケートであるChris Munnsによる寄稿です。 元の投稿からの更新情報: 2019年11月28日(PST):  次のリージョンに対して、元の投稿に記載されている改善を完全に展開しました:中東(バーレーン)。 2019年11月25日(PST):次のリージョン、米国東部(バージニア北部)、米国西部(オレゴン)、カナダ(中央)、EU(ロンドン)、EU(ストックホルム)、およびアジア太平洋(香港)に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年11月6日(PST):次のリージョン、米国西部(北カリフォルニア)、EU(アイルランド)、EU(パリ)、アジア太平洋(ムンバイ)、アジア太平洋(ソウル)、アジア太平洋(シンガポール)、アジア太平洋(シドニー)、南アメリカ(サンパウロ)に対して、これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 2019年9月27日(PST):米国東部(オハイオ)、欧州(フランクフルト)、およびアジア太平洋(東京)の地域へ完全に展開しました。これらのリージョンのすべてのAWSアカウントには、元の投稿で概説した改善を展開しました。 既知の問題(2019年10月4日(PST)に更新): HashiCorp Terraformを使用している場合、サブネット、セキュリティグループ、VPCなどのVPCリソースは、この新しいモデルでのENIの動作方法の変更により破棄に失敗する可能性があります。この問題を解決するための手順と、詳細についてはこちらをご覧ください。 2019年9月3日(PST)の元の投稿: 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 または […]

Read More

GitOps を使用したサーバーレス時代における最新の CI/CD パイプライン構築

 AWS コミュニティヒーローで、Datree.io の CTO 兼共同創設者、Shimon Tolts 氏によるゲスト投稿。彼は開発者向けのツールとインフラストラクチャが専門分野で、100% サーバーレスの会社を運営しています。 近年、ソフトウェアの構築と配信の方法に大きな変化がありました。主にマイクロサービスに関するもので、コードを小さなコンポーネントに分割し、インフラストラクチャをコードとして使用し、Git を信頼できる唯一のソースとして利用することでこれらすべてを結び付けたのです。 この記事では、最新のソフトウェア開発の推移とさまざまな手段について説明しながら、サーバーレスの世界での選択可能なソリューションをご紹介します。さらに、現代にふさわしい便利なツールもご紹介します。 サーバーレスとは サーバーレスの開発とツーリングの魅力あふれる世界をご紹介する前に、サーバーレスとは何かを考えてみましょう。AWS のウェブサイトには、主に 4 つの利点があります。 サーバー管理の必要がない。 適応性のあるスケーリング。 価値に対する支払い。 高可用性の自動化。 サーバーレスとは​​管理やスケーリングを必要としないインフラストラクチャであると、私は考えています。 私の会社の Datree.io では、ワークロードの 95% を AWS Fargate で、そして残りの 5% を AWS Lambda で実行しています。当社はサーバーレスの会社であるため、AWS アカウントには Amazon EC2 インスタンスがありません。詳細については、以下をご参照ください。 io での導入事例 Migrating to AWS ECS Fargate in production CON320: Operational Excellence w/ Containerized Workloads Using […]

Read More

Amazon Aurora PostgreSQL Serverless が一般利用可能に

データベースは通常、ソフトウェアアーキテクチャの最も重要な部分であり、データベースの管理、特にリレーショナルデータベースの管理は容易ではありませんでした。このため、Amazon Aurora の自動スケーリングバージョンであり、アプリケーションのワークロードに基づいて自動的に起動、シャットダウン、スケールアップまたはスケールダウンできる Amazon Aurora Serverless を開発しました。 Aurora Serverless の MySQL 互換エディションは少し前から入手可能です。本日、Aurora Serverless の PostgreSQL 互換エディションが一般利用可能になったことをお知らせいたします。 詳細を説明する前に、Amazon Aurora 開発チームが、2019 年の米国計算機学会 (ACM) のデータ管理分科会 (SIGMOD) システム賞を受賞したことを祝福します。 Aurora Serverless を使用してデータベースを作成するときは、最小容量と最大容量を設定します。クライアントアプリケーションは、自動的にスケーリングされるリソースプールにワークロードをルーティングするプロキシフリートに透過的に接続します。リソースが「ウォーム」であり、リクエストに応えるために追加する準備ができているため、スケーリングは非常に高速です。   Aurora によるストレージの管理方法について、Aurora Serverless では変更はありません。ストレージ層は、データベースが使用するコンピューティングリソースから独立しています。事前にストレージをプロビジョニングする必要はありません。最小ストレージは 10GB です。データベースの使用量に基づいて、Amazon Aurora ストレージは自動的に最大 64TB まで 10GB 単位で増加し、データベースのパフォーマンスには影響しません。 Aurora Serverless PostgreSQL データベースの作成 それでは、Aurora Serverless PostgreSQL データベースを起動し、自動スケーラビリティが機能していることを確認しましょう。 Amazon RDS コンソールで、Amazon Aurora をエンジンとして使用してデータベースを作成することを選択します。現在、Aurora Serverless は […]

Read More