Amazon Web Services ブログ

 小売、製造、ヘルスケアを含む多くの業界が IoT 対応デバイスを採用し、AI または機械学習 (ML) テクノロジーを使用して、デバイスが人間の介入なしに人間のような意思決定を行えるようにしました。自宅で AI/機械学習テクノロジーを使用して IoT 対応デバイスに電力を供給するなど、いくつかのユースケースを適用することもできます。 この記事では、AWS DeepLens、Amazon Rekognition、およびその他の AWS サービスを使用して車のナンバープレートを認識し、IoT ベースのガレージドアオープナーをトリガーする方法を紹介します。このソリューションを他の多くのユースケース (製造業など) に適用して、生産現場でのロボットやパッケージのフローを制御することができます。医療業界では、このソリューションを病院に適用して、顔認識またはスタッフのセキュリティバッジから一意のコードを読み取ったり検証したりする手順に基づいて、スタッフが制限された領域にアクセスすることを許可または拒否できます。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 AWS DeepLens デバイスを使用すると、エッジで深層学習を実行することができます。オブジェクトを検出し、オブジェクト検出モデルに対して実行します。モデルが車を検出すると、Amazon S3 にフレームをアップロードします。新しいイメージが S3 バケットに保存されると、AWS Lambda 関数がトリガーされ、Amazon Rekognition への呼び出しが開始され、Amazon DynamoDB テーブルの許可された値一覧とナンバープレートの比較が行われます。関数がナンバープレートを見つけると、AWS Secrets Manager からサードパーティーの API シークレットを取得し、サードパーティーの API をトリガーしてガレージのドアを開きます。 お客様はすでに IoT 対応のガレージドアを使用されているかもしれません。そしてほとんどのガレージドアオープナーはプログラムでガレージドアを開閉する、ある種の API を提供します。この記事では、IoT ベースのガレージドアオープナーを最初から作成するのではなく、既存のガレージドアオープナーを想定しています。 このプロジェクトでは、以下の AWS のサービスを使用します。 AWS DeepLens – Apache MXNet、TensorFlow、および Caffe […]

 チャットやメッセージングアプリケーションも広く普及しましたが、メールは最も投資利益率 (ROI) の高いユビキタスチャネルとして人気を維持しています。参入のハードルの低さ、価格の安さ、特定の受信者をターゲティングする機能が特徴です。組織のマーケティングおよび取引のメッセージがタイムリーに顧客に届き、より深いエンゲージメントを促進していることを確認するには、大規模なメール配信における専門知識を培ってきた、経験豊富で信頼できるメールサービスプロバイダーと連携する必要があります。 Amazon Simple Email Services (SES) は信頼性と柔軟性に富んだ手ごろな価格のメールサービスプロバイダーとして、2011 年から開発者およびデジタルマーケター向けにサービスを提供してきました。Amazon SES は、顧客とのやりとりにメールを使用しているあらゆる規模の企業に適した、信頼性が高く、コスト効率の良いサービスです。多くの企業が、機密性が高く、厳しいセキュリティポリシーを保持する業界に属しています。そのため AWS は Amazon SES のセキュリティおよびコンプライアンスの機能を強化しました。独自の RSA キーペアを使用した DKIM の設定、HIPAA 資格や FIPS 140-2 準拠のエンドポイントのサポート、地域拡大などが可能となりました。 このたび Amazon SES ユーザーは、AWS PrivateLink を使用した VPC エンドポイントを介して、安全かつ拡張可能な方法で、Virtual Private Cloud (VPC) から Amazon SES に直接接続できるようになりました。インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を使用せずに、VPC 経由で Amazon SES にアクセスできるようになりました。インターフェイス VPC エンドポイントを使用すると、VPC と Amazon […]

 機械学習 (ML) は、金融サービス業界 (FSI) から製造、自律走行車、および宇宙探査にいたるまで、世界中の業界に影響を及ぼします。ML はもはや学術機関および研究機関限定の単なる野心的なテクノロジーではなくなり、あらゆる規模の組織に利益をもたらす主力テクノロジーへと進化しました。しかし、ML プロセスにおける透明性の欠如と、結果として生じるモデルのブラックボックス的な性質が、金融サービスおよびヘルスケアなどの業界における ML の導入を向上させる上での妨げとなっています。 ML モデルを開発するチームにとっては、ビジネス成果に対する予測の影響が増加するにつれて、モデル予測を説明する責任も増加します。たとえば、消費者には、説明がなくても ML モデルから推薦された映画を受け入れる傾向があります。消費者がその推薦に同意するかどうかはわかりませんが、モデル開発者が予測を正当化する必要性は比較的低くなります。これに対して、クレジットローンの申し込みが承認されるかどうか、または患者に投与する薬の量を ML モデルが予測する場合、モデル開発者はその予測を説明する責任を負い、「ローンが拒否されたのはなぜですか」または「この薬を 10 ㎎ 飲まなくてはならないのはなぜですか」といった質問に対応する必要があります。 トレーニングプロセスに対する可視性を得て、人に対する説明が可能な ML モデルの開発が重要なのはこのためです。 Amazon SageMaker は、開発者およびデータサイエンティストが、あらゆる規模の ML モデルを迅速かつ簡単に構築、トレーニング、およびデプロイすることを可能にする完全マネージド型サービスです。Amazon SageMaker Debugger は Amazon SageMaker の機能で、リアルタイムおよびオフラインでの分析のためのモデルトレーニングプロセスに対する可視性を自動的に提供します。Amazon SageMaker Debugger では内部モデルの状態が定期的な間隔で保存され、トレーニング中のリアルタイムでの分析、およびトレーニング完了後のオフラインでの分析の両方を行うことができます。Amazon SageMaker Debugger はモデルのトレーニング中に問題を識別し、トレーニングされたモデルが行う予測への洞察を提供します。Amazon SageMaker Debugger には一連の組み込みルールが備わっており、これらは一般的なトレーニング問題を検知し、トレーニングが成功する上で重要な一般的な状態をモニタリングします。また、トレーニングジョブをモニタリングするカスタムルールを作成することも可能です。 この記事では、ML の説明可能性、人気の説明可能性ツールである SHAP (SHapley Additive exPlanation)、および Amazon SageMaker Debugger との SHAP のネイティブな統合について説明します。この記事の一環として、Amazon SageMaker […]

 アマゾン ウェブ サービス (AWS) は、Amazon SageMaker Studio 内で、ノートブックの一般提供を開始しました。Amazon SageMaker Studio は、機械学習 (ML) インスタンスタイプのオンザフライ選択、最適化されあらかじめパーケージ化された Amazon SagMaker イメージ、および Jupyter ノートブックの共有をサポートしています。作業を中断したりインフラを管理したりすることなく、例えば ml.t3.medium から ml.p3.2xlarge へ、あるカーネルを使用するインスタンスタイプのノートブックで、別のインスタンスタイプに切り替えることができます。インスタンスの移動はシームレスで、インスタンスの起動中も作業を継続できます。Amazon Sagemaker Studio ドメイン用に作成された Amazon Elastic File System (Amazon EFS) により、新しいインスタンスでノートブックとデータをすぐに利用できます。ドメイン内のすべてのユーザーは、EFS ボリューム上に作成されたホームディレクトリを取得します。 Amazon Sagemaker Studio でノートブックを使用 ML ワークフロー用に完全に統合された開発環境である Amazon SageMaker Studio を使用してノートブックにアクセスできます。Amazon SageMaker Studio のご利用を開始すると、さまざまなインスタンスタイプの柔軟姓を活用できるようになります。 次のスクリーンショットは、2 つのノートブックが並んで動作している様子を示しています。 左側のノートブックでは、2 vCPU と4 GiB のメモリを搭載するインスタンスを使用して、データサイエンス SageMaker […]

 コンテナは、クラウドアプリケーションの開発とデプロイにおける事実上の標準です。コンテナイメージでソフトウェアを公開すると、統合パッケージソリューション、バンドルソフトウェア、および必要なすべての依存関係をポータブルイメージ形式で開発者に提供します。このイメージはどこでも実行でき、デプロイメントにおけるインフラストラクチャ固有の側面を抽象化します。 ただし、どこでも実行できるということはお約束できます。一部のアプリケーションには、Linux と Windows の両方のサポートなど、特定のホストプラットフォームまたはオペレーティングシステムの要件があります。コンピューティングアーキテクチャは、別の変数です。特に EC2 で実行されている AWS Graviton ARM ベースのインスタンスで、その比率は優れた料金対パフォーマンスを備えています。今日まで、このようなコンテナイメージは、アーキテクチャ固有の命名規則を使用して Amazon ECR に公開およびデプロイする必要がありました。そのため、イメージライフサイクルの一部側面が複雑になりました。 本日、Amazon ECR のマルチアーキテクチャコンテナイメージを発表いたします。これは待望していた機能であり、同じイメージリポジトリから異なるアーキテクチャやオペレーティングシステムのコンテナイメージを簡単にデプロイできます。 内部のコンテナイメージ Amazon ECR は完全マネージド型のコンテナレジストリで、開発者はコンテナイメージを簡単に保存、管理、およびデプロイできます。高可用性かつスケーラブルで、簡単に使用できます。マルチアーキテクチャイメージの詳細を説明する前に、コンテナイメージ機能の基本的な側面について説明します。 「コンテナ」という用語は、プロセスを実行する分離済みコンピューティング環境を提供するための一連のオペレーティングシステムコンポーネント、コンピューティングリソース、および構成を指します。コンテナに指定されたリソースの 1 つが、そのファイルシステムです。コンテナイメージを参照する場合、このポータブル形式のファイルシステムと、参照するコンテナ構成およびその他のメタデータをご覧ください。Docker などの一般的なコンテナ開発ツールを使用すれば、開発者はソフトウェアまたはサービスと必要なすべての依存関係を含むコンテナイメージを作成できます。これにより、コンテナがポータブルなオプションになります。 コンテナイメージは、レイヤーとマニフェストといった 2 つのメイン部分で構成されます。各コンテナイメージには、ファイルシステムコンテンツの 1 つ以上のレイヤーがあります。マニフェストは、イメージを構成するレイヤー、およびそのランタイムの特性と構成を指定します。Docker のコンテナイメージ形式は、Docker イメージ仕様と関連するイメージマニフェスト仕様で定義されています。Open Containers Initiative は、ランタイムにとらわれない OCI イメージ仕様を定義しました。 Amazon ECR のようなイメージレジストリは、これらの仕様に準拠したイメージをリポジトリに格納し、特定の各イメージは 1 つ以上のタグによって参照されます。イメージは通常、イメージをプッシュおよびプルするときにソフトウェアやサービスのバージョンを指定する目的でタグ付けされます。これらすべてをまとめると、最初に Docker または別のコンテナランタイムで使用するコンテナイメージをプルしたとき、2 つの事像が起こります。最初に、指定されたイメージリポジトリとタグに基づいてマニフェストがローカルにプルされ、次に指定されたレイヤーからコンテナファイルシステムを組み立てるためにマニフェストが使用されます。 具体的な例として、docker inspect <image> コマンドを使用して、Docker 開発環境のローカルイメージのマニフェストを確認できます。ご覧のとおり、アーキテクチャやオペレーティングシステムなどのプラットフォーム特性は、イメージマニフェストによって明確に指定されています。では、さまざまなオペレーティングシステムやプラットフォームアーキテクチャに簡単にコンテナをデプロイするにはどうすればよいでしょうか。 今日まで、Amazon ECR のリポジトリにイメージを公開するとき、これらの特性をイメージタグで指定する必要がありました。または、同じソースからビルドされたプラットフォーム固有のイメージを独自のイメージリポジトリに保存することもできます。次に、コンピューティング環境に適したバージョンのイメージを明示的に参照して取得する必要があります。例: {aws-account-id}.dkr.ecr.{aws-region}.amazonaws.com/my-image-linux-arm64:2.7 […]

 2008 年に設立された Zalando は、ファッションとライフスタイルのためのヨーロッパをリードするオンラインプラットフォームで、3,200 万人以上のアクティブな顧客を抱えています。私は Zalando のリードデータエンジニアであり、これまで会社のクラウドジャーニーに貢献してきました。このブログ投稿では、Amazon Simple Storage Service (Amazon S3) が当社のデータインフラストラクチャの要となった経緯について説明します。最初に、データの洞察を得るための Zalando のビジネスニーズと、その歴史的なテクノロジースタックがどのように異種の情報を提供したかについて説明します。次に、特にデータレイクを構築するために Amazon S3 を使用して AWS への移行を決定した方法について説明します。最後に、従業員にデータへのアクセス権を付与することから、さまざまな Amazon S3 ストレージクラスを使用してストレージコストを最適化することまで、Amazon S3 の使用法がどのように進化してきたかについて説明します。 私が共有する経験と、データ駆動型企業をマルチペタバイト規模で運営するのに役立つベストプラクティスを確立した方法を学習のお役に立てていただければ幸いです。 Zalando のテクノロジーの生い立ち 2015 年、Zalando は、大規模なオンプレミスのモノリスとして実行されている IT 環境を有するファッション小売業者でした。インフラストラクチャの主要部分は、トランザクション側でも分析側でも、直接統合され、相互に依存していました。システムの複雑さが増すと同時に、細部を追加するためのチームの数も増えていきました。その後、会社は、「単なる」オンライン小売業者からファッションのプラットフォームへと変貌を遂げることを決定しました。その目標を設定することは、スケールに向けた準備を意味していました。現在と将来のビジネスニーズを検討した結果、会社がクラウドに移行するのは論理的な決定でした。当社は、複数のクラウドプロバイダーを評価し、耐久性、可用性、およびスケーラビリティにより、クラウドプロバイダーとして AWS を選びました。また、当社が将来活用できる可能性がある、AWS が提供するサービスの広範なエコシステムも考慮に入れました。Zalando のモノリシックインフラストラクチャはマイクロサービスに分割され、分離された開発および運用スペースにおける技術ランドスケープについてのエンドツーエンドの責任を持つチームの創設につながりました。 テクノロジーインフラストラクチャの変更は、会社のデータランドスケープに直接影響を及ぼしました。多くのコンポーネントからアクセスされる中央データベースは分散バックエンドになり、通信は REST API を介して行われました。トランザクションデータストアに直接接続する中央データウェアハウスは、直接的な到達可能性を有しない分散型のデータ生成に対応する必要がありました。これらの課題を克服するために、Zalando にデータレイクを構築することを目標とする中心的なチームが組まれました (図 1)。当初のデータレイクを開始する動機は 2 つありました。すなわち、この新しい分散環境に一元的なデータアーカイブを持つことと、会社の分散コンピューティングエンジンを作成することです。 図 1: Zalando のデータレイクアーキテクチャ リレーショナルデータベースのサイズ制限を解除した後、会社が潜在的に非常に高い価値のあるデータを生成していることがわかりました。当社には、増大するデータ量に対応できるデータストレージオプションが必要であり、当社が選択したオプションは、拡張性と信頼性を備え、手頃な料金で利用できるものである必要がありました。AWS のサービスポートフォリオを見ると、会社の新しい中央データレイクのベースレイヤーとして機能する選択肢が Amazon S3 […]

 ストレージコストの最適化という課題を最小限化する取り組みの一環として、本日は AWS Storage Gateway のファイルゲートウェイによる Amazon S3 Intelligent-Tiering ストレージクラスのサポートが開始されたことを発表します。お客様のワークロードには、変化し続ける、または不明確なストレージアクセスパターンが存在することが多く、最も頻繁にアクセスされるデータベースの特定が困難になります。たとえば、運用および財務チームは、異なるアプリケーションを使って同じデータにアクセスする必要があり、そのアクセスには季節的、またはピーク需要によって変化するパターンがあります。これは、IT 部門がどのデータセットを低頻度アクセス用に設計された低コストのストレージクラスに移動させることができるかを正確に判断しづらくする場合がありますが、 ファイルゲートウェイのお客様は今後、S3 Intelligent-Tiering を選択し、データアクセスパターンの変化に応じてストレージコストを自動的に最適化するために役立てることができるようになります。オブジェクト単位のわずかなモニタリングおよびオートメーション料金で、S3 Intelligent-Tiering は 2 つのアクセス階層、つまり高頻度アクセス用に最適化された階層と低頻度アクセス用に最適化された低コスト階層間でデータを自動的に移動させます。 ファイルゲートウェイは SMB および NFS プロトコルを使用して、ほぼ無制限のクラウドストレージへのファイルベースのキャッシュされたアクセスをオンプレミスアプリケーションに提供します。ファイルゲートウェイは、Amazon Simple Storage Service (Amazon S3) オブジェクトストレージへのファイルプロトコルアクセスを必要とする、オンプレミスおよび Amazon EC2 ベースのアプリケーションで使用できます。このローンチにより、ファイルゲートウェイで SMB および NFS ファイル共有を設定するときのストレージクラスとして S3 Intelligent-Tiering を選択することが可能になります。このブログ記事では、ファイルゲートウェイに対する S3 Intelligent-Tiering サポートの仕組み、使用する時と場合、およびこのストレージクラスを利用するためのファイル共有の設定方法といったこの階層の基礎について説明します。 概要 ファイルゲートウェイで S3 Intelligent-Tiering を使用することにより、ワークロードのデータアクセスパターンが不明確だというお客様は、このストレージクラスが提供する最適化を利用することができます。具体的に言うと、S3 Intelligent-Tiering は、パフォーマンスに影響を及ぼしたり、運用オーバーヘッドを発生させたりすることなく、コスト効率性が最も高い階層にデータを自動で移動させることで、お客様がストレージコストを簡単に最適化できるようにします。 ファイルゲートウェイの SMB または NFS ファイル共有データが S3 […]

 Amazon EventBridge は、アプリケーションを簡単に接続できるようにするサーバーレスイベントバスです。AWS サービスのデータ、独自のアプリケーション、Software-as-a-Service (SaaS) パートナーとの統合を使用できます。昨年の re:Invent では、EventBridge スキーマレジストリと検出のプレビューで、イベントの構造 (スキーマ) を中央に保存する方法を導入しました。また、Java、Python、Typescript 用にイベントを処理するコードを生成することにより、コード内のイベントの使用を簡素化しました。 本日より、EventBridge スキーマレジストリが一般公開され、リソースポリシーのサポートが追加されたことをお知らせいたします。リソースポリシーにより、異なる AWS アカウントと組織間でスキーマリポジトリを共有できます。このようにして、異なるチームの開発者は、別のチームが共有レジストリに追加したスキーマを検索して使用できます。 EventBridge スキーマレジストリリソースポリシーの使用 企業は、一般的にさまざまなサービスに取り組んでいるさまざまな開発チームを抱えています。より具体的な例を示すために、互いに通信を行う必要があるサービスに取り組んでいる 2 つのチームを見てみましょう。 CreateAccount 開発チームは、ウェブ/モバイルクライアントからリクエストを受信して、会社の新しい顧客アカウントを作成するフロントエンド API に取り組んでいます。 FraudCheck 開発チームは、新しく作成されたアカウントのデータをチェックするバックエンドサービスに取り組み、それらが偽物であるリスクを推定します。 各チームは、独自の AWS アカウントを使用してアプリケーションを開発しています。 EventBridge を使用すれば、次のアーキテクチャを実装できます。 フロントエンドの CreateAccount アプリケーションは、Amazon API Gateway を使用して、Python で記述された AWS Lambda 関数を使ってリクエストを処理します。新しいアカウントが作成されると、Lambda 関数はカスタムイベントバスで ACCOUNT_CREATED イベントを発行します。 バックエンドの FraudCheck Lambda 関数は Java で作成されており、ACCOUNT_CREATED イベントを受信して Amazon Fraud Detector […]

 AWS DeepRacer リーグは、賞品と栄光をかけて競うとともに、強化学習について楽しみながら学ぶ機会を提供します。モデルの構築、トレーニング、および評価には AWS DeepRacer 3D レーシングシミュレーターを使用でき、モデルがレースできることを確実にするために、結果を検証してモデルを改善することが可能です。 フォーミュラ 1 (F1) レースで優勝するには、技術的に洗練されたレースカー、一流のドライバー、極めて優れたクルー、そして (信じられないかもしれませんが) かなりの機械学習が必要です。AWS は過去数シーズンにわたって、かつてないほど速く、低燃費のレースカーを生み出すために機械学習を利用する方法を見つけるべくフォーミュラ 1 チームと連携してきました (詳細については、最速の車、最速のクラウド、および Formula 1 Works with AWS to Develop Next Generation Race Car をお読みください)。 スペシャルイベント AWS DeepRacer リーグでは、AWS DeepRacer コンソールで毎月新しい仮想レースを開催していますが、今月は特別なレース、Formula 1 DeepRacer ProAm Special Event を開催します。5 月中は、フォーミュラのドライバーたちとそのクルーによって構築およびチューニングされたモデルとレースする機会を求めて競い合うことができます。出場者は以下のとおりです。 ロブ・スメドレー – F1 のデータシステム担当ディレクター兼 AWS Technical Ambassador。 ダニエル・リカルド – グランプリで 7 度優勝し、29 […]

 RStudio は、統計計算とグラフィックスのための言語と環境である R の統合開発環境 (IDE) です。データサイエンティストとして、R と Spark (ビッグデータ処理フレームワーク) を統合して、大規模なデータセットを分析できます。sparklyr と呼ばれる R パッケージを使用して、大規模なデータセットのフィルタリングと集計を R スクリプトから Spark にオフロードし、R のネイティブの強度を使用して、Spark からの結果をさらに分析および視覚化できます。 RStudio で実行されている R スクリプトは、sparklyr を使用して Spark ジョブをクラスターに送信します。通常、R スクリプトは (sparklyr とともに)、Spark を実行する (Amazon EMR の) マシンのクラスターとは別のマシンにインストールされている RStudio 環境で実行されます。sparklyr が Spark ジョブを送信できるようにするには、RStudio マシンと Spark を実行しているクラスターの間にネットワーク接続を確立する必要があります。そのための 1 つの方法は、RStudio をエッジノードで実行することです。これは、クラスターのプライベートネットワークの一部であり、RStudio などのクライアントアプリケーションを実行するマシンです。エッジノードを使用すると、Hadoop のコアサービスを実行するノードとは別にクライアントアプリケーションを実行できます。エッジノードは、ローカルの Spark および Hive シェルへの便利なアクセスも提供します。 ただし、エッジノードのデプロイは簡単ではありません。それらのエッジノードには、Hadoop クラスターと同じバージョンの Hadoop、Spark、Java、およびその他のツールが必要であり、クラスター内のノードと同じ […]