Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

Amazon Forecastを組み合わせたSAPでの販売予測

はじめに 販売予測とは、誰か (企業、営業担当者、小売業者など)が何か (製品やサービス)をどれだけ販売するかを予測するプロセスです。正確な予測の重要性を説明するために、オンラインで商品を販売するファッション小売業の場合を考えてみましょう。需要を正しく予測することで、適切なフルフィルメントの配置 (配送費用の削減)による適切なレベルの在庫管理 (運用コストの削減)ができ、お客様への迅速な配送 (顧客満足度の向上)ができます。信頼できる販売予測は、次のような重要な下流部門の決定を可能にし、組織の成功に大きな役割を果たすことができます。

Read More

Designing MQTT Topics for AWS IoT Core – ホワイトペーパーについて

皆さん、こんにちは! さっそくですが、本記事では AWS IoT Core における MQTT のトピック設計について記載されているホワイトペーパーの紹介をさせていただきます。 IoT システムを構築する場合、アーキテクチャやワークロード、デバイス選定、デバイス-クラウド間の通信設計、データ格納、デバイスのプロビジョニングや運用など様々な観点を考慮・検討する必要があると思います。その中の一つであるデバイス-クラウド間の通信設計において、IoT で比較的多く採用されている MQTT プロトコルが選択肢にあがることがあると思います。 MQTT プロトコルを利用した通信では、MQTT トピックという仕組みによりデバイス-クラウド間での情報をやりとりしますが、基本的にトピックの階層構造自体は自由に設計することができるため、デバイス情報や通信種別などに合わせて構造を統一的に設計するのではないでしょうか。それにより、接続するデバイス種別やデバイス-クラウド間を行き来する情報の種類が増加してもトピックの階層構造がシンプルに保たれ、更にトピック毎に通信に対するポリシー設定をすることでセキュリティ権限管理が可能となります。 ホワイトペーパー「Designing MQTT Topics for AWS IoT Core」では、複数の章にわたって AWS IoT における MQTT トピック設計のベストプラクティス、ガイドライン、方針が紹介されており、本ブログでは各章で説明されている内容について簡単ではありますがお伝えできればと思います。MQTT の概念や用語について理解していることが、本ホワイトペーパーを読みすすめる上での前提となっておりますので承知ください。 ホワイトペーパー(英語)はこちらからダウンロードすることができます。 概要 / 序章 本ホワイトペーパーでは、 IoT システムを構築する際に AWS IoT を利用した MQTT トピック設計を行うためのベスト・プラクティスに焦点が当てられています。AWS IoT Core では、通信やデバイス環境制約を考慮する必要がある IoT システム向けに設計された MQTT プロトコルがサポートされており、MQTT を利用する際に最初に検討すべき項目の1つであるトピック設計を実施する上で、MQTT 通信パターンや通信ワークフローを実現するための参考となるデザインパターンを以降の章で具体例を用いて説明しています。 MQTT 通信パターン IoT システムでは、デバイスからデバイスへ、デバイスからクラウドへ、クラウドからデバイスへ、デバイスからユーザーへ、またはユーザーからデバイスへなどの、複数の通信パターンをサポートする必要があります。IoT システムと […]

Read More

NIH STRIDESの成果として: 米・国立生物工学情報センターのコロナウイルスゲノム配列データセットをAWS上で公開

Amazon Web Services (AWS) と 米・国立衛生研究所 (National Institutes of Health :NIH) の米・国立生物工学情報センター (National Center for Biotechnology Information: NCBI) は、新型コロナウイルス感染症  (COVID-19) の研究を支援するためのコロナウイルスゲノム配列データセットの作成を発表しました。このデータセットは AWS Open Data Sponsorship Program によってホストされ、AWS 上の Registry of Open Data でアクセス可能であり、研究者がCOVID-19の研究で使うためにコロナウイルスの配列データに無料で素早く簡単にアクセスできます。 コロナウイルスのデータをクラウドに一元化 コロナウイルスゲノム配列データセット は、研究者が提出した次世代シーケンスのデータ(元のファイル形式)と、米・国立医学図書館 (National Library of Medicine : NLM) で NCBI によってホストされる SRA プロセスのシーケンスデータ(ETLファイルフォーマット)の集合体です。このデータセットは、NIH Science and Technology Research Infrastructure for Discovery,Experiments,and Sustainability […]

Read More

AWS Black Belt オンラインセミナーのご案内 (2020 年 9 月)

こんにちは!AWS Webinar チームです。 「暑さ寒さも彼岸まで」。 そんな日が近々くることを望んでやまない 9 月にお届けする AWS Black Belt オンラインセミナーのご案内です。 まだまだ残暑が残る日々ですので、クーラーで冷えた快適なお部屋(熱中症の心配ゼロ)からぜひご視聴ください。 9 月は、3 本のアジェンダを配信予定です!興味のあるトピックはぜひご登録ください。 視聴方法: オンラインセミナー登録ページよりお申し込みください 9 月のスケジュール AWS IoT Events 2020 年 9 月 16 日 (水) | 18:00 – 19:00 | IT 知識レベル:★★★☆☆ | AWS 知識レベル:★★☆☆☆ AWS IoT Events のサービスの紹介と、AWS IoT Events を利用して最低限のコーディングでデバイスやシステムの状態を管理する方法について、ユースケースと合わせてご紹介します。 対象者 IoT デバイスやサービスを構築しようとしている技術者の方 本セミナーで学習できること AWS IoT Events のサービスの機能 各種ユースケース […]

Read More

[AWS Black Belt Online Seminar] AWS Shield Advanced 資料及び QA 公開

先日 (2020/08/18) 開催しました AWS Black Belt Online Seminar「AWS Shield Advanced」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200818 AWS Black Belt Online Seminar AWS Shield Advanced from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Shield Standard で「すべてのインターネットに面した AWS リソースが対象」とありましたが、EIP をアタッチした EC2 インスタンスも透過的に Shield Standard が適用されると思って間違いないでしょうか?(ELB か CloudFront が必要だと思っていました) A. はい。ほとんどの一般的な DDoS 攻撃に対する対策が適用されております。こちらのドキュメントをご参照ください。 Q. Shield Standard や他社製品を利用しているケースでアドバンスを検討するポイント(アドバンス利用のメリット)はありますでしょうか? A. Amazon CloudWatch により […]

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
Weekly AWS

週刊AWS – 2020/8/17週

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 毎日本当に暑い日が続きますね。さて初のオンライン開催となるAWS Summit Onlineまであと2週間少々になりました。オンライン開催ですので、全国どこからでも、涼しい部屋からご参加いただけますし、オンデマンド視聴でいつでも観ていただくことが可能になっています。セッション申し込みが開始になっていますので、ぜひサイトをチェックしてみてください。私は「Architecting and Building – ログデータ用のデータレイク&分析環境をクイックに構築するには?」と「Amazon QuickSight BASIC ハンズオン ~ QuickSight の基本操作を 50 分で学ぶ~」を担当していますので、よろしければご覧になってください。 AWS Summit Online 2020 年 9 月 8 日 (火) ~ 9 月 30 日 (水) オンラインで開催 それでは、先週の主なアップデートについて振り返っていきましょう。

Read More

AWS Well-Architected Framework のセキュリティの柱をアップデートしました

お客様からのフィードバックと新しいベストプラクティスに基づいて、AWS Well-Architected Framework のセキュリティの柱をアップデートしました。この記事では、セキュリティの柱のホワイトペーパーと AWS Well-Architected Tool の変更点の概要を紹介し、新しいベストプラクティスとガイダンスについて説明します。 AWS は、お客様がセキュアで高パフォーマンス、耐障害性、効率的なインフラストラクチャを構築することを支援するために、Well-Architected Framework を開発しました。Well-Architected Framework は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱から成り立っており、お客様、パートナー、AWS 内の各チームからのフィードバックを受けて、定期的にフレームワークを更新しています。またホワイトペーパーに加えて、AWS Well-Architected Tool も用意されており、ベストプラクティスに照らし合わせてアーキテクチャをレビューすることもできます。

Read More

[開催報告] Amazon Interactive Video Service ローンチセミナー

2020 年 8 月 18 日に新しいサービス Amazon Interactive Video Service (Amazon IVS) について、サービス概要と使い方を実演でご説明するほか、ゲストスピーカー様(株式会社ディー・エヌ・エー様)より現場での活用をご紹介していただくイベントを開催しましたので、その資料公開とともに内容をブログでお届けします。 Amazon IVS は、コンテンツの取り込み、処理、配信までの動画ワークフローを一括でまとめられるマネージド ライブストリーミング ソリューションです。汎用ストリーミングソフトウェアから Amazon IVS を介し、ウェブサイトやアプリへ低遅延のままライブストリームを配信できます。

Read More