Amazon Web Services ブログ

Category: Serverless

サーバーレス LAMP スタック – Part 6: MVC からサーバーレスマイクロサービスへ

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ この投稿では、マイクロサービスを使用してサーバーレス PHP アプリケーションを構築する方法をご理解いただけます。これまでご紹介してきた MVC フレームワークを利用した単一の Lambda 関数によるスケーラブルな Web ホスティングから、分離されたマイクロサービスモデルに移行する方法を示します。なお、このブログ投稿に付随するコード例は、この GitHub リポジトリにあります。 MVC アーキテクチャパターン 従来の LAMP スタックでは、多くの場合、Model-View-Controller(MVC)アーキテクチャを使って実装しています。これは、アプリケーションロジックをモデル、ビュー、およびコントローラの3つの部分に分離して実装する、確立された手法です。 モデル:この部分はアプリケーションのデータを管理する役割を果たします。その役割は、データベースから生データを取得したり、コントローラからユーザー入力を受け取ることです。 ビュー:このコンポーネントは表示に焦点を当てています。モデルから受け取ったデータをユーザーに提示します。ユーザーからの応答が認識され、コントローラコンポーネントに送信されます。 コントローラ:この部分はアプリケーションロジックを担当します。ユーザー入力に応答し、データモデルオブジェクトに対して相互作用を実行します。 データ、ロジック、およびプレゼンテーション層を分離するという MVC の原則により、1つの層での変更が他の層に与える影響を最小限に抑えることが可能です。これにより、開発プロセスがスピードアップし、レイアウトの更新、ビジネスルールの変更、および新機能の追加が容易になります。コンポーネント化によって、再利用とリファクタリングの適用性があがり、同時/並行開発がしやすくなります。 サーバーレス LAMP スタック サーバーレス LAMP スタックアーキテクチャについては、この投稿で説明しています。そこでは Webアプリケーションが 2つのコンポーネントに分割されています。アプリケーションにおける MVC フレームワークの役割をはたす単一の AWS Lambda 関数と、各応答を同期的に返す […]

Read More

サーバーレス LAMP スタック – Part 5: CDK コンストラクトライブラリ

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレス LAMP スタック用の新しい CDK コンストラクトライブラリが、開発者によるサーバーレス PHP アプリケーションの構築にどのように役立つかを学びます。 AWSクラウド開発キット(AWS CDK)は、クラウドアプリケーションリソースをコードで定義するためのオープンソースソフトウェア開発フレームワークです。開発者は、TypeScript、Python、C#、Javaなどの使い慣れたプログラミング言語でインフラストラクチャを定義できます。開発者は、インターフェイス、ジェネリクス、継承、メソッドアクセス修飾子など、言語が提供する機能を利用できます。AWS Construct ライブラリは、CDK アプリケーションで AWS リソースを定義するための API を公開するモジュールの広範なセットを提供します。 「サーバーレス LAMP スタック」ブログシリーズでは、ベストプラクティス、コード例、多くのサーバーレスコンセプトの詳細を紹介し、これらが PHP アプリケーションにどのように適用されるかを示しています。また、PHP 開発者のインスピレーションを刺激するのに役立つ、コミュニティからの貴重な貢献に焦点を当てています。 このサーバーレス LAMP スタックの各コンポーネントについては、一連のブログ記事で詳しく説明しています。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 サーバーレス LAMP […]

Read More

サーバーレス LAMP スタック – Part 4: サーバーレス Laravel アプリの構築

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプローチで Laravel アプリケーションをデプロイする方法を学びます。 これは「サーバーレス LAMP スタック」シリーズの4番目の投稿になります。過去の投稿はこちらです。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え Laravel は PHP 用のオープンソースの Web アプリケーションフレームワークです。フレームワークを使用すると、開発者は一般的なコンポーネントとモジュールを再利用することで、より速く構築できます。また、開発標準に準拠することにより、長期的なメンテナンスにも役立ちます。ただし、従来の LAMP スタックを使用して PHP フレームワークをスケーリングする場合は、まだ課題があります。サーバーレスアプローチを使用してフレームワークをデプロイすると、これらの課題の解決に役立ちます。 Laravel アプリケーションのサーバーレスインフラストラクチャへの展開を簡素化する方法は数多くあります。ここで紹介する方法では、AWSサーバーレスアプリケーションモデル(AWS SAM)テンプレートを使用しています。これによって、Laravel アプリケーションが単一の Lambda 関数にデプロイされます。この関数は、Bref FPM カスタムランタイムレイヤーを使用して PHP を実行します。AWS SAMテンプレートは、「サーバーレス LAMP スタック – パート3: […]

Read More

サーバーレス LAMP スタック – Part 3: Webサーバーの置き換え

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート2:リレーショナルデータベース パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、Web サーバーを使用せずにサーバーレス PHP アプリケーションを構築する方法を学びます。 この投稿の後半で、bref および Serverless Visually Explained の作成者である Matthieu Napoli が FastCGI Process Manager の実装を Lambda 関数内で使うことでそれを可能にする方法を説明しています。Bref は、PHP 用のオープンソースのランタイム Lambda レイヤーです。 また、プライベート Amazon S3 バケットから静的アセットを安全に提供およびキャッシュするように Amazon CloudFront を構成する方法を示します。動的リクエストは、その後 Amazon API Gateway にルーティングされ、単一の […]

Read More

サーバーレス LAMP スタック – Part 2: リレーショナルデータベース

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート1:サーバーレス LAMP スタックの紹介 パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ この投稿では、サーバーレスアプリケーションで Amazon Aurora MySQLリレーショナルデータベースを使用する方法を学びます。Amazon RDS Proxy を使用してデータベースへの接続をプールおよび共有する方法と、構成を選択する方法を示します。この投稿のコード例は PHP で記述されており、この GitHubリポジトリにあります。なお、この概念自体は、AWS Lambda でサポートされている他のランタイム言語にも適用できますので、PHP に限定しない内容としてお読みいただけます。 サーバーレス LAMP スタック このサーバーレス LAMP スタックアーキテクチャについては、この記事で説明しています。このアーキテクチャでは、PHP Lambda 関数を使用して、Amazon Aurora MySQL データベースの読み取りと書き込みを行います。 Amazon Aurora は、MySQL および PostgreSQL データベースに高いパフォーマンスと可用性を提供します。基盤となるストレージは、最大64 テビバイト(TiB)まで需要に応じて自動的に拡張されます。 Amazon Aurora DB […]

Read More

新しいサーバーレス LAMP スタック – Part 1: 概要紹介

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 本シリーズの他のパートは以下のリンクからアクセスできます。また、関連するサンプルコードはこちらの GitHub リポジトリにあります。 パート2:リレーショナルデータベース パート3:Webサーバーの置き換え パート4:サーバーレス Laravel アプリの構築 パート5:CDK コンストラクトライブラリ パート6:MVC からサーバーレスマイクロサービスへ これは、PHP 開発者向けの投稿シリーズの第一弾です。このシリーズでは、PHP でサーバーレステクノロジーを使用する方法を説明します。サーバーレスアプリケーションを構築するために利用できるツール、フレームワーク、戦略や、なぜ今始めるべきかについて説明します。 今後の投稿では、Laravel や Symfony などの PHP フレームワークとともに構築された Web アプリケーションに AWS Lambdaを使用する方法を示します。Lambda を Web ホスティング機能の代替として使用することから、分離されたイベント駆動型のアプローチに移行する方法を示します。最小限のスコープの複数の Lambda 関数を他のサーバーレスサービスと組み合わせて、パフォーマンスの高いスケーラブルなマイクロサービスを作成する方法について説明します。 まずは、カスタムランタイム API を使用して Lambda で PHP を使用する方法を学びます。サンプルコードについては、この GitHubリポジトリにアクセスしてください。 サーバーレスLAMPスタック 従来の PHP アプリケーションの課題 スケーラビリティは、従来の LAMP スタックの伝統的な課題です。スケーラブルなアプリケーションとは、非常に多様なレベルのトラフィックを処理できるアプリケーションです。PHP アプリケーションは、多くの場合、必要に応じて Web サーバーを追加することにより、水平方向にスケーリングされます。これは、リクエストをさまざまな […]

Read More

VPC設定にAWS Lambda IAM条件キーを使用する

本投稿は、Senior Developer Advocate, Julian Woodの寄稿によるものです。 AWS Identity and Access Management(IAM)条件キーを使用して、AWS Lambda 関数のAmazon Virtual Private Cloud(VPC)設定を制御できるようになりました 。 IAM条件キーを使用すると、IAMポリシーステートメントが適用される条件をさらに絞り込むことができます。関数を作成および更新する権限を付与するときに、IAMポリシーで新しい条件キーを使用できます。 VPC設定の3つの新しい条件キーは、lambda:VpcIds、lambda:SubnetIds、そして、 lambda:SecurityGroupIds です。キーにより、ユーザーが1つ以上の許可されたVPC、サブネット、およびセキュリティグループに接続された関数のみをデプロイできるようにすることができます。ユーザーが許可されていないVPC設定で関数を作成または更新しようとすると、Lambdaは操作を拒否します。 LambdaとVPCの関係を理解する Lambdaの実行環境はすべて、Lambdaサービスが所有するVPC内で動作します。 Lambda関数は、Lambda API を呼び出すことによってのみ呼び出すことができます。関数が実行される実行環境への直接のネットワークアクセスはありません。 非VPC接続のLambda関数 Lambda関数がカスタマーアカウントのVPCに接続するように構成されていない場合、関数はパブリックインターネットで利用可能なすべてのリソースにアクセスできます。これには、他のAWSサービス、APIのHTTPSエンドポイント、またはAWS外のサービスとエンドポイントが含まれます。関数はVPC内のプライベートリソースに直接には接続できません。 VPC接続のLambda関数 Lambda関数を設定して、カスタマーアカウントのVPC内のプライベートサブネットに接続できます。 Lambda関数がカスタマーアカウントVPCに接続するように設定されている場合も、そのLambda関数は引き続きAWS LambdaサービスVPC内で実行されます。この場合、Lambda関数はすべてのネットワークトラフィックをカスタマーアカウント内VPC経由で送信し、このカスタマーVPCのネットワーク制御に従います。これらのコントロールを使用して、セキュリティグループ とネットワークACL を設定し関数が接続可能な範囲を制御できます。Lambda関数からの送信トラフィックは独自のネットワークアドレス空間から送信され、VPCフローログ を使用してネットワークを可視化できます。 パブリックインターネットを含むネットワークロケーションへのアクセスを制限できます。 カスタマーアカウント内のVPCに接続されたLambda関数は、デフォルトではインターネットにアクセスできません。関数にインターネットへのアクセスを許可するには、送信トラフィックをパブリックサブネットのネットワークアドレス変換(NAT)ゲートウェイ にルーティングできます。 Lambda関数を設定してカスタマーアカウント内のVPCに接続すると、AWS Hyperplane によって管理される共有Elastic Network Interface(ENI)が使用されます。この接続により、VPC-to-VPC NATが作成され、クロスアカウントに接続されます。これにより、Lambda関数からプライベートリソースへのネットワークアクセスが可能になります。 AWS Lambda サービスVPCからVPC-to-VPT NATを利用しカスタマーVPCへ Hyperplane ENIは、Lambdaサービスが制御し、カスタマーアカウント内のVPCに存在するマネージドネットワークインターフェースリソースです。複数の実行環境がENIを共有して、カスタマーアカウントのVPC内のリソースに安全にアクセスします。カスタマー側からのLambda実行環境(LambdaサービスVPC内)への直接のネットワークアクセスは出来ないことにご注意ください。 ENIはいつ作られるのか? Lambda関数が作成されるか、そのVPC設定が更新されると、ネットワークインターフェイスの作成が行われます。関数が呼び出されると、実行環境は事前に作成されたネットワークインターフェースを使用し、そのインターフェースへのネットワークトンネルをすばやく確立します。これにより、コールドスタート時のネットワークインターフェースの作成と接続に関連していたレイテンシが削減 されています。 どのくらいの数のENIが必要か? ネットワークインターフェイスは実行環境全体で共有されるため、通常、関数ごとに必要なネットワークインターフェイスはほんの一握りです。アカウント内の関数全体で一意のセキュリティグループとサブネットのペアごとに、個別のネットワークインターフェイスが必要です。同じアカウントの複数の関数が同じセキュリティグループとサブネットのペアを使用する場合、同じネットワークインターフェイスを再利用します。このように、複数の関数を備えているが、ネットワークとセキュリティの構成が同じである単一のアプリケーションは、既存のインターフェース構成の恩恵を受けることができます。 関数のスケーリングは、ネットワークインターフェイスの数に直接関係しなくなりました。Hyperplane […]

Read More

AWS Lambda関数の状態の追跡

本投稿は、AWS Lambda の Senior Developer Advocate, Chris Munns の寄稿によるものです。 AWS Lambda関数は、AWS Identity and Access Management(IAM)ロールやAmazon Virtual Private Cloud(Amazon VPC)、ネットワークインターフェイスなど、正常に実行するために他のAWSサービスのリソースを必要とすることがよくあります。関数を作成または更新すると、Lambdaはユーザーに代わって、関数の実行を可能にするのに必要なリソースをプロビジョニングします。ほとんどの場合、このプロセスは非常に高速で、関数を呼び出したり変更する準備はすぐにできます。ただし、この種のアクションで時間がかかってしまうこともあります。 リソースが作成または更新されているときの関数の現在の「状態」をより把握できるように、AWS LambdaのLambda APIアクションによって返される関数情報にいくつかの追加属性が含まれるようになりました。この変更は、関数の呼び出し方法やコードの実行には影響しません。 この投稿では、Lambda関数が到達する可能性のある多様な状態、それらに遷移する条件、およびLambdaサービスが関数をさまざまな状態に遷移させる方法について説明します。詳細については、AWS Lambdaのドキュメント、Lambda APIを使用した関数の状態のモニタリング をご覧ください。 Lambda関数の状態について Lambda関数が通過する主なライフサイクルは2つあります。これは、Lambda関数が初めて作成されるのか、それともすでに存在し更新されるのかによって異なります。フローに入る前に、関数の状態について説明します。 Pending Pendingは、すべての関数が作成されたときに通過する最初の状態です。Pending中にLambdaはリソースを作成または設定しようとします。関数はアクティブ状態のときにのみ呼び出すことができるため、関数を操作する呼び出しやその他のAPIアクションは失敗します。関数作成直後に関数の呼び出しや更新をするように構築された自動化処理は、関数がPendingからActiveに移行したかどうかを最初に確認するように実装する必要があります。 Active 関数の最初の作成中にリソースの構成またはプロビジョニングが完了した後、Activeになります。関数は、Active状態でのみ呼び出すことができます。 関数の更新中、状態はActiveに指定されたままですが、Activeな関数の更新の状態を表すLastUpdateStatusと呼ばれる別の属性があります。更新中、呼び出しは、更新操作が正常に完了するまで関数の以前のコードと設定内容にて実行され、更新完了後、新しいコードと設定が使用されます。 Failed Failed状態は、リソースの設定またはプロビジョニングのいずれかが失敗したことを表す状態です。 Inactive Lambdaサービスが設定されたリソースを回収するのに十分な時間アイドルになっている関数は、Inactive状態に移行します。Inactive状態の関数を呼び出すと、失敗し、それらのリソースが再作成されるまで関数はPending状態に設定されます。リソースの再作成に失敗した場合、関数はInactive状態に戻ります。 すべての状態について、StateReasonとStateReasonCodeの2つの属性が設定されています。どちらも問題のトラブルシューティングのために存在し、現在の状態に関する詳細情報を提供します。 LastUpdateStatusについて InProgress InProgress状態は、既存の関数で更新が行われていることを示します。関数がInProgress状態にある間、関数呼び出しは関数の以前のコードと設定にルーティングされます。 Successful Successful 状態は、関数の更新が完了したことを示します。関数が更新されると、次の更新までこの状態がセットされたままになります。 Failed Failed状態は、関数の更新が失敗したことを示します。変更は中止され、関数の以前のコードと設定がActive状態のままになり使用可能となります。 すべてのLastUpdateStatus値には、LastUpdateStatusReasonとLastUpdateStatusReasonCodeの2つの属性が設定されています。これらは、更新に関する問題のトラブルシューティングに役立ちます。 関数状態のライフサイクル ある状態から別の状態への関数状態の遷移は、関数に対して実行されるアクションに完全に依存しています。関数の状態から状態に手動で移動する方法はありません。 関数の状態のライフサイクル   すべての関数について、主要な状態のライフサイクルは次のようになります。 作成時に、関数はPending状態になります 必要なリソースが正常に作成されると、Active状態に移行します リソースまたは関数の作成が何らかの理由で失敗すると、Failed状態に移行します […]

Read More

[AWS Black Belt Online Seminar] What’s New in Serverless 資料及び QA 公開

先日 (2020/07/28) 開催しました AWS Black Belt Online Seminar「What’s New in Serverless」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200728 AWS Black Belt Online Seminar What’s New in Serverless AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. EventBridge については 「Lambda ⇒ EventBridge ⇒ Lambda」 といった AWS サービス間の連携も可能という認識です。ただし, 従来の方法ですと 「Lambda ⇒ SQS ⇒ Lambda」 といったものもあったと思いますが, 何か使い分けのポイントなどはありますでしょうか? A. サービス間の統合を担うという意味では共通していますが、サービスの特徴が異なります。 Amazon SQS はメッセージキューイングサービスで、キューはメッセージの保持もすることから、設定された保持期間 (60 秒から 14 日間)の永続性が担保されます。また順序性担保が必要なワークロードでは FIFO キューを使用することもできます。 […]

Read More

[AWS Black Belt Online Seminar] サーバーレス イベント駆動アーキテクチャ 資料及び QA 公開

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

Read More