Amazon Web Services ブログ

Category: Developer Tools

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

AWS Copilot によるコンテナアプリケーションの自動デプロイ

本投稿は Nathan Peck による記事を翻訳したものです アプリケーションをアイデアから人々に触ってもらえる実装に落とし込むのは複数のステップを含むプロセスです。設計が固まりコードが書かれると、どうやってそのアプリケーションをデプロイし、ユーザーのもとに届けるかというのが次のチャレンジとなります。その実現方法の1つが Docker コンテナを利用することであり、AWS Copilot のようなコンテナを実行するためのインフラストラクチャを自動的に構築してくれるようなツールです。もしあなたがまだ AWS Copilot のことをよく知らない場合は、以前のブログ記事「AWS Copilot のご紹介」をお読みいただくとその全体概要を掴んでいただけるかもしれません。 Copilot を利用すると copilot svc deploy のような CLI コマンドを実行することでアプリケーションのビルドやデプロイを実行することができますが、例えば複数の開発者が複数のサービスからなる規模のアプリケーションについて長期的な視点で考えた時には理想的な使い方とは言えません。この記事では、Copilot の基礎的な使い方に基づいてアプリケーションリリースの自動化を進める方法を紹介していきます。そこで、まずはコード変更をリポジトリにプッシュする度にコンテナアプリケーションをビルド、プッシュ、デプロイするという基本的なリリースパイプラインを動かすところから始めます。その後、複数のステージやテストを備え、プロダクションへのリリース前にそのアプリケーションが動作することを確認できるようなベストプラクティスをパイプラインを実装していきます。『本番環境で発見されたバグを修正し、それをユーザーに向けてリリースする』という現実世界のシナリオのウォークスルーが本記事のフィナーレです。 本日のアプリケーション あなたは “String Services” というオンライン文字列操作 API 界のトッププロバイダになることを狙っているスタートアップで働いているとしましょう。ある日、あなたの会社は “reverse.” と呼ばれる文字列操作のサービスを提供していくことを決めます。このサービスはどんな文字列もそのインプットとして受け入れ、逆向きの(reversed)文字列をその結果として返します。あなたの仕事はこの新しいサービスをデプロイし、この API を熱望するお客さまに届けることです。まずは Node.js で書かれたコードを見ていきましょう。 var getRawBody = require(“raw-body”); var http = require(“http”); var server = http.createServer(function (req, res) { getRawBody(req) .then(function (buf) { […]

Read More

AWS Systems Manager を使用したソフトウェアのパッチ適用

世界中の企業でクラウドコンピューティングの導入が急速に増加しており、クラウドジャーニー(クラウド活用を進める過程)の中で、さまざまな移行パターンが選ばれています。モノリシックなレガシーアプリケーションをそのまま使用してクラウドに移行することは「リフト・アンド・シフト」とも呼ばれるアプローチであり、クラウド移行の有力な手法の1つです。一方で、お客様が移行パターンについての知識を深めるにつれ、クラウドネイティブツールを最大限に活用できるようにリフト・アンド・シフト方式を最適化する必要があります。

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

AWS AppConfigとAWS CodePipelineの統合による機能リリースの自動化

昨年、AWS AppConfigをリリースしました。これはアプリケーション設定の作成、管理及び迅速なデプロイを行う、AWS Systems Managerの新機能です。AppConfigを使用すると、デプロイメントを行う前にアプリケーション設定を検証でき、制御及び監視可能な方法で設定をデプロイできます。 AWS AppConfigを使用すると、アプリケーションコードのデプロイメントとは独立して、設定の変更をデプロイ可能です。つまり、アプリケーション設定を更新しても、アプリケーションの再起動やサービスの停止を行う必要がありません。AWS AppConfigを使用すれば、アプリケーションは更新した設定をすぐに使用できます。具体的には、AWS AppConfig API、AWS CLIやAWS SDKを使用することで、更新した設定を取得することができます。 ローンチ以来、お客様はさまざまなユースケースにAWS AppConfigを採用しており、なかでもコードのデプロイメントとは独立して新機能をリリースする機能がトップユースケースの1つでした。アプリケーション設定のデプロイメントはコードのデプロイメントより高速です。なぜならコンフィグレーションファイルは、ビルドステージを必要とせず、アプリケーションを停止すること無く実行中にデプロイすることができるためです。 機能リリースにあたって、バックエンドサービスの設定とフロントエンドの設定を正しい順序で行う必要があります。そのためには、しばしば複数のチームや手作業を調停する必要があります。こういった手作業によるデプロイメントは、カスタマーエクスペリエンスに影響を与える作業遅延を引き起こす可能性があります。 複数の環境、アプリケーションやリージョンに、アプリケーション設定をデプロイするという手動タスクをシンプルにするために、我々はAWS AppConfigとAWS CodePipelineの統合を発表しました。このローンチは、お客様が AWSの数千のチームが使用するベストプラクティスを選択することを可能にします。それは、コード変更を機能リリースから容易に分離し、安全且つ効率的な方法でこれらの機能リリースを自動化するというものです。

Read More

Perforce Helix Core を AWS 上に構築する (Part3)

イントロダクション 3回にわたるAWSでのPerforce構築シリーズもこれで最後になりました。 Part1ではAWS 上で Perforce Helix Core を構築することの利点と技術的ポイントを俯瞰しました。 前回のPart2では AWS CloudFormation を用いてPerforceサーバーを構築する方法を解説しました。 今回のPart3では、Part2の手順7、CloudFormationの設定において「Enable Replica」をYesにしてReplica Serverの構築を有効にした場合のReplica ServerのSetup手順を紹介します。 Part2の手順で、Master Serverのみの構築を希望した場合は、こちらの手順は必要ありません。 もちろん、もう一度前回の記事の手順を最初からやり直して、Replica構築を有効にして、本記事の手順を実行していただくこともできます。 さて、実際の Replica server の構築手順ですが、これはAWS特有というわけではなく、Perforceの通常の構築手順に従って手動でコマンドを実行して行くというものになります。 それでは実際に手順を見ていきましょう! 事前準備 こちらのPart2の手順を実行していることが前提になります。実行されていない方はまずは前回の記事の手順を実行し、その際に必ず「手順7」の「Enable Replica」をYesにして有効にします。 こちらを参考にして東京リージョンで任意の名前のS3バケットを用意しておいてください。S3バケットの名前は全世界で一意の名前にする必要があります。 例えば次のようなS3バケットの名称にすると他のバケット名との衝突を避けることができます。 (例) perforce-test-[自分の名前]-[日付] など Replica Serverをセットアップする Replicaの動作を定義するには、Perforceのコマンドである“p4 configure set”コマンドを使用して、Master serverのdb.configファイルに構成情報を入力する必要があります。Replicaを作るにはまず最初にMaster serverを設定します。Master serverの設定が、後でReplica serverに複製されます。 Mater Server側で設定を行う まずは、Master Serverにsshログインします。下記では適宜、自分のssh keyとEIPアドレスに置き換えてください。 $ ssh -i ~/.ssh/general-key.pem p4admin@18.180.250.162 前回Part2でp4adminユーザーをサーバー側に作成していない場合は作成します。作成済みの場合はスキップして次に進みます。下記のコマンドを実行するとviが起動しますので内容を確認して、「:wq」をタイプして保存します。 [p4admin@master ~]$ p4 […]

Read More

[AWS Black Belt Online Seminar] AWS X-Ray 資料及び QA 公開

先日 (2020/05/26) 開催しました AWS Black Belt Online Seminar「AWS X-Ray」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200526 AWS Black Belt Online Seminar AWS X-Ray AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. beanstalk の X-Ray について、質問させてください。beanstalk で x-Ray を有効にした場合、x-Ray メドリックはどこで確認できますか?AWS X-Ray サービス画面に入って確認しましたが、表示されてませんでした。 A. トレースの収集からコンソールでの表示までに若干のタイムラグがございます。時間を置いてご確認いただければと思います。また、AWS Elastic Beanstalk の場合は AWS X-Ray の SDK をアプリケーションに組み込む必要があることもご留意ください。 Q. 使い方として、1ヶ月間ほど X-Ray で情報収集をして、性能情報の統計や分析が可能と考えて良いでしょうか? A. そういった使い方も可能です。サンプリング機能によるアプリケーションへの負荷と課金のコントロールが可能なため、本番環境において常時有効化して常にアプリケーションの状態を把握できるようにしておくことも可能です。また、負荷試験艦橋や開発環境においてサンプリングレートを上げて集中的にトラブルシュートや性能分析を行う、といったユースケースも多いです。 Q. X-Ray を停止せずにアプリケーション監視ツールとして使用しても大丈夫でしょうか? A. パフォーマンス悪化やエラーレートの上昇にしきい値を設けてモニタリングやアラートを設定するといった使い方は可能です。AWS X-Ray のトレースは […]

Read More

Perforce Helix Core を AWS 上に構築する (Part2)

イントロダクション 前回の記事では AWS 上で Perforce Helix Core を構築することの利点を説明し、実際の構成パターンと構築における注意点を解説しました。 本記事では、実際に Perforce Helix Core をAWS に構築する手順をご紹介します。手順といっても AWS CloudFormation テンプレートを用意しておりますので、大部分は自動化されています。AWS CloudFormation では、設定をjsonやyamlでファイルに記述するだけでAWS のリソースのプロビジョニングを自動化することができます。 今回作成するサーバー構成の全体像は下図のようになります。AWS Cloudと書かれた中にあるサーバ群を設定します。デフォルトは Perforce の Master Server だけを構築する設定になっていますが、手順の中で Read only の Replica server を設定することも可能です。今回はインターネットから直接アクセスできるPublic Subnetにサーバーを配置していますが、Private Subnetにサーバーを配置して、VPNや AWS Direct Connect を介してオフィスやデータセンタのみからアクセスできる閉域にすることも可能です。 本記事では、まずは Perforce の Master server を構築する手順を見ていきます。次の Part3 の記事で、Replica server の構築手順を紹介します。Replica server の設定では、いくつか手動でコマンドを実行していただく必要があります。 なお、今回構築する Perforce Server への接続には […]

Read More

Amazon DocumentDB (MongoDB 互換) の開始方法 – パート 2 – AWS Cloud9 の使用

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 このシリーズのパート 2 のこの投稿では、 AWS Cloud9 を使用した Amazon DocumentDB の開始方法を示します。最初の手順として、デフォルトの Amazon VPC にAWS Cloud9 環境と Amazon DocumentDB クラスターを作成します。デフォルトの VPC を作成する手順については、Amazon VPC の開始方法をご参照ください。この投稿では、mongo シェルを使用して AWS Cloud9 環境から Amazon DocumentDB クラスターに接続して、いくつかのクエリを実行する方法を示しています。このチュートリアルを完了にかかる費用は 0.30 USD 未満です。AWS リソースを作成する場合、AWS IAM のベストプラクティスに従うことをお勧めします。ローカルマシンで Amazon DocumentDB の使用を開始する方法の詳細については、「Getting started with […]

Read More