Amazon Web Services ブログ

Category: Amazon API Gateway

サーバーレス 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

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能(GA)になりました

本投稿は、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 […]

Read More

[AWS Black Belt Online Seminar] Amazon API Gateway 資料及び QA 公開

先日 (2019/5/14) 開催しました AWS Black Belt Online Seminar「Amazon API Gateway」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190514 AWS Black Belt Online Seminar Amazon API Gateway from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. API GatewayかLambdaのどちらかの採用を検討するにはどのようにしたらいいでしょうか (とくにコスト面で) A. Web APIとして公開する場合は、AWS Lambdaの手前にAmazon API Gatewayを配置することによって疎結合化がなされ、実装を隠蔽化できるという利点があります。 ただシンプルにAWS SDK等を利用し直接Lambdaを呼び出したいケースであれば、必要な権限を呼び出し元のアプリケーションに付与した上でLambdaのみを利用する構成もご検討頂けます。 (例:呼び出し元がAmazon Elastic Compute Cloud (EC2) であればそのIAMロール、呼び出し元がブラウザやモバイルアプリであれば、Amazon CognitoのIDプールを利用したAWS Credentialsを利用)。 また、Lambda関数をバックエンドとしてHTTPリクエストを受け付ける他の方法としては、Elastic Load Balancing (ELB) の一種である Application Load […]

Read More

AWS Lambda と Amazon API Gateway で Express アプリケーションを実行

Express は Node.js のウェブフレームワークです。これを使用すると、「サーバーレス」ウェブサイトやウェブアプリケーション、API を簡単にデプロイできます。サーバーレス環境では、大方またはすべてのバックエンドロジックがステートレスのオンデマンドで実行します (詳細情報については Mike Roberts によるブログ「Serverless Architectures」をご覧ください)。今月初旬に公開したブログ (「API Gateway の更新 – API 開発を簡素化する新機能」) で紹介した新しい Amazon API Gateway 機能と AWS Lambda を併せて使用した場合、既存の Express アプリケーションをサーバーレスで実行することができます。API Gateway を使用すると API を中心に開発者のエコシステム構築を可能にする使用量プランなど追加機能を利用したり、キャッシュにより応答性と費用対効果に優れたアプリケーション構築を行うこともできます。 AWS は aws-serverless-express パッケージを提供することで Express アプリケーションから Lambda や API Gateway への移行をお手伝いしています。このパッケージには実例が含まれています、ぜひご活用ください。 Express コードとアプリケーションを API Gateway と Lambda に移行する場合に利用できる 2 つのリソースをご紹介します。 「Running Express Apps in AWS […]

Read More

API Gateway のアップデート – API 開発を簡素化する新機能

Amazon API Gateway で、堅牢でスケーラブルなアプリケーションバックエンドの構築と実行を簡単に素早く最近追加された使用プランで、API に関与するパートナー開発者のエコシステムを作成することができます。では、いくつかの用語を確認しながら始めましょう。 エンドポイント – HTTP リクエストに応答する URL (API Gateway によって提供される) です。これらのリクエストは、GET、PUT、POST などの HTTP メソッドを使用します。 リソース – エンドポイント内にある名前の付いたエンティティで、階層パスと呼ばれます。 動作 – 特定のリソース上で、HTTP リクエストに対応してコードが HTTP メソッドを使用して実行するアクションです。 統合 – エンドポイント、リソース、および HTTP メソッドと実際のアクションとの間でやり取りされる API Gateway マッピングです。 現在、API Gateway が提供する統合モデルを拡張して、新しい API エンドポイントの構築と既存のアプリケーションの移植を容易にするための複数の新しい機能をサポートしています。 greedy パス変数 – 一般的なパス ( /store/ など) に分類されるリクエストのグループのパスと動作を個別に指定する代わりに、パスへのすべてのリクエストを傍受してそれらを同じ機能にルーティングする、「greedy」ルートを指定できるようになりました。たとえば、単一の greedy パス (/store/{proxy+}) は、 /store/list-products, /store/add-product、および /store/delete-product) に対するリクエストを傍受します。 […]

Read More