Category: Compute

先日 (2020/08/25) 開催しました AWS Black Belt Online Seminar「AWS EC2 Image Builder」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200825 AWS Black Belt Online Seminar AWS EC2 Image Builder from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 推奨として、AMI の作成は各リージョンで行った方がいい、あるいは１リージョンで作ったもののコピーがいい、などありますか？リージョン固有の何かがないかと懸念しています。 A. EC2 起動のために AMI はリージョンごとに必要になりますが、EC2 Image Builder はマルチリージョンへのイメージ出力に対応していますので、特別な考慮無く ImageBuilder は作成した AMI を必要なリージョンにコピーできます。ただし、香港やバーレーンなど一部のリージョンについては、サービス利用及びイメージを展開するために事前のリージョン有効化が必要です。また、EC2 Image Builder 実行時にソースイメージとして選択する AMI は、EC2 Image Builder と同じリージョンに存在する必要があります。 Q. スライド：EC2 […]

本投稿は 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 サーバーを追加することにより、水平方向にスケーリングされます。これは、リクエストをさまざまな […]

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

本投稿は、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状態に移行します […]

はじめに みなさんこんにちは、ソリューションアーキテクトの福嶋、渡邊です。AWS では 2018 年・2019 年と実施してきた自動車業界向けクラウドテクノロジーカンファレンス「AWS Autotech Forum」を夏と冬の2日間に拡大し、「AWS Autotech Forum 2020 Online #1」を8/7にオンラインにて開催させていただきました。オンライン開催第一回目となる今回は、MaaS、自動運転開発、コネクテッドカー、エッジコンピューティング、マップ／ロケーションサービス等の分野において、先進的な取り組みを志向する企業のビジネスリーダー、エンジニアの方々に向けて、お客様の新たなビジネスをご支援させていただく中で学んできた、汎用的に利用可能なプラクティスやテクノロジーの活用シーンを AWSのソリューションアーキテクトからご紹介させていただきました。 オープニング 自動車業界における AWS の取り組みとお客様事例 ソリューションアーキテクト安藤から皆様の新しいビジネスの企画立案に役立てていただくために、 AWS の活用事例や取り組みについてご紹介しました。 テクノロジートレンドの CASE (Connected/Autonomous/Shared/Electric) はすでに多くのお客様が取り組まれており、ビジネストレンドである MaaS への注目度も日増しに高まっています。 MaaS にはエマージングビジネスの側面と企業間アライアンスによる新プラットフォームビジネスの側面があり、AWS を活用いただくことで「価値創出への集中」「最新技術の活用」「試行錯誤の繰り返し」といったメリットをご享受いただけます。 セッションの中では実際に、 AWS をご活用いただいている企業の事例や CES 2020 において Amazon と AWS が共同で発表した自動運転で走行する電気自動車におけるカーシェアリングサービスのコンセプトデモを例に AWS をご利用いただくことによるメリットがどのようなビジネス効果を生み出しているかをご説明しました。 登壇資料: 自動車業界における AWS の取り組みとお客様事例 MaaS関連セッション AWS Connected Mobility Solution (CMS) のご紹介 ソリューションアーキテクト高野からは、コネクテッドモビリティのシステム開発に関する AWS […]

先日(2020/7/28)開催しましたオンラインセミナー
「 RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」
の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

数週間前、私は、新しい AWS Graviton2 Amazon Elastic Compute Cloud (EC2) インスタンスタイプである M6g の発表に関する投稿を書きました。それ以来、数百のお客様にコストパフォーマンスの大幅な向上を実感していただいています。これらのお客様の中には Honeycomb.io、SmugMug、Redbox、Valnet Inc. が含まれています。 6 月 11 日に、AWS Graviton2 プロセッサに基づく 2 つの新しいインスタンスファミリーを発表しました。すなわち、C6g と R6g が既存の M6g に追加されました。M ファミリーのインスタンスは、アプリケーションサーバー、ゲームサーバー、中規模のデータベース、キャッシングフリート、ウェブティアなど、幅広い汎用ワークロードに対応することを目的としており、多くの場面で活用できます。C ファミリーのインスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、広告配信、動画エンコーディング、ゲーム、科学的モデリング、分散分析、CPU ベースの機械学習推論など、コンピューティングを多用するワークロードに適しています。R ファミリーのインスタンスは、オープンソースデータベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリ使用量が多いワークロードに適しています。これらのインスタンスタイプの詳細と、それらがワークロードに関連する理由については、AWS の VP 兼 Distinguished Engineer である James Hamilton 氏のこの動画で詳細をご確認いただけます。 本日は、さらなるニュースを共有したいと思います。それは、これらの 3 つのファミリーすべてに「d」バリアントが追加されるということです。M6gd、C6gd、および R6gd インスタンスタイプは、NVM Express (NVMe) のローカルに接続された SSD ドライブ (最大 2 x 1.9 […]

先日 (2020/07/07) 開催しました AWS Black Belt Online Seminar「Amazon EC2 Deep Dive: AWS Graviton2 Arm CPU搭載インスタンス」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200707 AWS Black Belt Online Seminar Amazon EC2 Deep Dive: AWS Graviton2 Arm CPU搭載インスタンス from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 現在 ECR に登録してあるコンテナイメージは Graviton2 でそのまま動きますか？ A. コンテナイメージについては、Arm アーキテクチャ専用のものが必要になります。ECR 上で x86 、Arm 両方のイメージをホストする事も可能ですのでこちらの Blog 記事もご参照ください。 また、Arm 用イメージの作成方法については、M6g […]

先日 (2020/6/24) 開催しました AWS Black Belt Online Seminar「Container Service Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200624 AWS Black Belt Online Seminar Container Services Update from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 6月上旬に「今後数か月で、AWS Fargate は LATEST フラグをプラットフォームバージョン (PV) 1.4.0 に更新する予定です。」という通知がされていますが、「今後数か月」はどの程度の期間と考えればよいでしょうか？1.4.0 の移行のどちらを優先するかを決めたい考えております。 A. 現在アナウンスさせて頂いている時期は、2020-3Q、2020 年 7 月 – 9 月となっております。下記 Blog でもご案内しておりますが、正式な発表をお待ちください。 日本語訳：https://aws.amazon.com/jp/blogs/news/aws-fargate-platform-versions-primer/ 原文：https://aws.amazon.com/blogs/containers/aws-fargate-platform-versions-primer/ Q. Docker Engine を使っていたら、platform を […]

Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ 本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。 Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！ −トリ (皆さまからの Copilot へのフィードバック、心よりお待ちしております) 本記事は Nathan Peck による “Introducing AWS Copilot” を翻訳+加筆修正したものです Amazon ECS 向けの最初の公式コマンドラインツールは2015年に公開されました。2019年12月には、新たな体験を備えたコマンドラインツールのプレビューリリースを皆さまに紹介しました。お客様がこれまで以上に簡単にアプリケーションを Amazon ECS にデプロイできるよう、ゼロベースでデザインしたものです。そして本日、私たちはこの新たなコマンドラインツールの最新情報と、その新たな名前 – AWS Copilot – を紹介します。 AWS Copilot は、低レイヤなインフラの手動管理から脱却し、自身のアプリケーションとそのライフサイクルにフォーカスしたい ECS ユーザのためにデザインされました。Copilot は、ECS チームのエンジニアや […]