Amazon Web Services ブログ

Tag: Amazon RDS

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

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 この投稿では、サーバーレスアプリケーションで 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 インスタンスは、パブリックアクセスを防止するために仮想プライベートクラウド(VPC)内に作成されます。 Lambda 関数から Aurora データベースインスタンスに接続するには、同じ VPC にアクセスするようにその Lambda 関数を設定する必要があります。 RDS データベースに直接接続すると、データベースのメモリ不足が発生する可能性があります。これは、データベース接続の急増、または高速で開閉する多数の接続が原因です。これにより、クエリが遅くなり、アプリケーションのスケーラビリティが制限される可能性があります。この問題を解決するために、Amazon RDS Proxy が実装されました。 […]

Read More

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

本投稿は AWS サーバーレス アプリケーションのシニアデベロッパーアドボケートである Benjamin Smith による寄稿です。 これは、PHP 開発者向けの投稿シリーズの第一弾です。このシリーズでは、PHP でサーバーレステクノロジーを使用する方法を説明します。サーバーレスアプリケーションを構築するために利用できるツール、フレームワーク、戦略や、なぜ今始めるべきかについて説明します。 今後の投稿では、Laravel や Symfony などの PHP フレームワークとともに構築された Web アプリケーションに AWS Lambdaを使用する方法を示します。Lambda を Web ホスティング機能の代替として使用することから、分離されたイベント駆動型のアプローチに移行する方法を示します。最小限のスコープの複数の Lambda 関数を他のサーバーレスサービスと組み合わせて、パフォーマンスの高いスケーラブルなマイクロサービスを作成する方法について説明します。 まずは、カスタムランタイム API を使用して Lambda で PHP を使用する方法を学びます。サンプルコードについては、この GitHubリポジトリにアクセスしてください。 サーバーレスLAMPスタック 従来の PHP アプリケーションの課題 スケーラビリティは、従来の LAMP スタックの伝統的な課題です。スケーラブルなアプリケーションとは、非常に多様なレベルのトラフィックを処理できるアプリケーションです。PHP アプリケーションは、多くの場合、必要に応じて Web サーバーを追加することにより、水平方向にスケーリングされます。これは、リクエストをさまざまな Web サーバーに転送するロードバランサーを介して管理されます。サーバーを追加するたびに、ネットワーキング、管理、ストレージ容量、バックアップと復元のシステム、およびアセット管理インベントリの更新に関するオーバーヘッドが増加します。さらに、水平方向にスケーリングされた各サーバーは独立して実行されます。これにより、構成の同期が困難になる可能性があります。 従来の LAMP スタックアプリケーションによる水平スケーリング 各サーバーには独自のディスクとファイルシステムがあり、開発者がユーザーセッションを処理するメカニズムを追加する必要があることが多いため、新しいストレージの課題が発生します。 サーバーレステクノロジーを使用すれば、開発者のためにスケーラビリティが(自動で)管理されます。トラフィックが急増した場合、サービスが拡張され、追加のサーバーを展開する必要なく、需要に応えます。これにより、アプリケーションをプロトタイプから本番環境にすばやく移行できます。 サーバーレス LAMP アーキテクチャ 従来の Web […]

Read More

AWS LambdaでAmazon RDS Proxyを使用する

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

Read More

AWS 責任共有モデルと GDPR

EU の一般データ保護規則 (GDPR) には、データプロセッサー(取扱者)とデータコントローラー(管理者)の役割が記述されており、一部のお客様や APN(Amazon Partner Network)のパートナー各社から、こうしたGDPR上の役割が、AWS 責任共有モデルにどのような影響を与えるかといった質問をいただいています。今回は、GDPR の観点から、私たちとお客様にとっての責任共有について説明したいと思います。 AWS 責任共有モデルは GDPR によってどのように変わりますか? という質問への簡易な回答は「変わりません」ということになります。AWS は、お客様に提供するクラウド環境とサービスをサポートする基盤となるインフラストラクチャを保護する責任を負います。一方、データコントローラーまたはデータプロセッサーとして行動するお客様と APN パートナーは、クラウドに入れた個人データに責任を負います。責任共有モデルには、AWS とお客様、APN パートナーの様々な責任が示され、同じ分類の責任が GDPR の下で適用されます。 データプロセッサーとしての AWS の責任 GDPR によって、データコントローラーおよびデータプロセッサーに関する明確な規則と責任が導入されます。AWS のお客様が当社のサービスを使用して個人データを処理するとき、データコントローラーは通常 AWS のお客様 (および場合によっては AWS のお客様の顧客) です。また、あらゆるケースで、AWS は常にこのアクティビティに関してデータプロセッサーとなります。なぜなら、お客様は AWS のサービス管理との相互作用を通じてデータの処理を指示しており、AWS はお客様の指示を実行しているにすぎないからです。データプロセッサーとして、AWS は、当社のすべてのサービスを実行するグローバルなインフラストラクチャの保護に対して責任を負います。AWS を使用する管理者は、エンドユーザーのコンテンツと個人データを処理するためのセキュリティ構成の管理を含めて、インフラストラクチャの保護は当社の最優先事項であり、セキュリティ上の統制を検証するためにサードパーティーの監査に多額の出資をしています。そこで明らかになった問題があれば、AWS Artifact を通じてお客様にお知らせすることになります。当社の ISO 27018 レポートはよい例であり、特に個人データの保護に重点を置いてセキュリティ管理をテストしています。 マネージドサービスに対する AWS の責任は大きくなっています。マネージドサービスには、Amazon DynamoDB、Amazon RDS、Amazon Redshift、Amazon Elastic MapReduce、Amazon WorkSpaces 等があります。ゲストオペレーティングシステム (OS) やデータベースのパッチ適用、ファイアウォール構成、障害回復等の基本的なセキュリティタスクは AWS […]

Read More