Category: Compute

  Formula One Group（Formula 1、以下F1）がAWSと提携し、クラウド化プロジェクトを開始しました。 F1は、21か国で開催する国際自動車連盟 (FIA) 主催のF1世界選手権 (FIA Formula One World Championship) の推進を担っています。 F1はITインフラストラクチャの大部分をオンプレミスのデータセンターからAWSクラウドへ移行予定です。フルマネージドな機械学習サービスAmazon SageMaker、イベント駆動型サーバーレスのコンピューティングサービスAWS LambdaやAWS分析サービスなど、さまざまなAWSサービスを通じてレース戦略とデータ追跡システムを強化し、世界で5億人を超えるファンとレーシングチームに、より確実な統計と予測情報を提供します。 F1の放送システムに関しても、複数の施設に及ぶ膨大なコンテンツデータをAWSのクラウドストレージで管理し、AWS Elemental Media Servicesで映像処理を行うというクラウドによるワークフローへ移行しました。複数の国でレースを行うため、現地にIT運用センターを設営する必要がありますが、クラウドを利用することで現地に運び込む機材が少なくなるため、クラウドが提供する効率性に加えて実用性な面でも利点を得ることができます。 F1は、非常にデータドリブンな自動車レースです。各レースでは、各競技車両が実装する120個のセンサーが3 GBのデータを生成し、毎秒1,500データポイントが生成されます。 F1のデータ科学者は、過去65年間で蓄積されたレースデータを使って深度学習モデルをトレーニングします。例えば、適切なピットストップウインドウ（適正なピットのタイミング）の特定や、タイヤ交換のピットストップ作戦といった、レース中の予測を行うことが可能です。リアルタイムでデータ分析をして、ドライバーが限界点までパフォーマンスを出しているかどうかといった洞察を、視聴しているファンに提供します。Amazon Kinesisを使って、機械学習、分析に用いる動画をリアルタイムにAWSのワークフローに取り込み、旋回中の各競技車両の主要なパフォーマンスデータを高速処理し、 Amazon SageMaker を活用した機械学習の結果により、ドライバーのパフォーマンスを正確に把握することができます。 F1のイノベーションとデジタル技術のディレクター、ピート・サマラ氏（Pete Samara）は次のように述べています。「AWSは我々のニーズに対して、他のクラウド事業者に勝るスピード、スケーラビリティ、信頼性、グローバル展開、パートナーエコシステム、そして幅広いサービスを提供してくれます。Amazon SageMakerなどの機械学習サービスを活用することにより、強力な洞察と予測をリアルタイムでファンに提供することができます。 また、AWSのスケーラブルで高性能コンピューティングワークロードを、Formula 1 Motorsports部門が活用できていることも素晴らしいです。これにより、新車のデザインルールの開発時に、エアロダイナミクス（空力性能）チームが実行できるシミュレーションの数と品質が大幅に向上します。」 原文はFormula One Group Case Study https://aws.amazon.com/jp/solutions/case-studies/formula-one/ AWSでの機械学習について https://aws.amazon.com/jp/machine-learning/ AWS ビデオソリューションについて https://aws.amazon.com/jp/digital-media/aws-managed-video-services/   AWS Elemental Marketing 山下  

Lambda@Edge をより活用いただくために Lambda＠Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   AWS Summit Tokyo 2018の基調講演にてアナウンスしました、AWS Fargate の東京リージョン対応ですが、サービスが開始されましたのでお知らせいたします。 AWS Fargate は Amazon Elastic Container Service (ECS)の1モードとして動作しますので、マネージメントコンソールから「Elastic Container Service」を選択し、「クラスターの作成」をクリックすると、クラスターテンプレートとしてAWS Fargate を選択できるようになっています。 AWS Fargate は従来の ECS と異なり、サーバーやクラスターを管理することなくコンテナを実行できるという特徴を持っています。これによりコンテナを実行するために仮想マシンのクラスターをプロビジョニングしたり、設定やスケールの管理を行うことなく、アプリケーション開発に注力いただくことができます。   現在AWS Fargate はECSでサポートされていますが、Amazon EKS 対応も2018年中に予定されていますので、また続報をお伝えしたいと思います。 ドキュメント や FAQ も日本語化されていますので、合わせて確認してみてください。 – プロダクトマーケティング エバンジェリスト 亀田  

Amazon Simple Queue Service (SQS) を使って AWS Lambda 関数をトリガーできるようになりました。これは私が個人的に 4 年以上前から楽しみにしてきた、重要な機能を提供する特別なアップデートです。皆さん、試用を待ち望んでいることでしょうから、昔話に興味のない方は下記を飛ばしてもらって結構です。 SQS は当社が立ち上げた初めてのサービスで、14 年前の 2004 年、AWS より公開されました。ご参考に、2004 年当時と言えば、商用ハードドライブは最大でも約 60 GB、PHP 5 が現れ、Facebook がちょうど開始したところ、テレビ番組のフレンズはシリーズが終了、Gmail はまだ珍しく、そして私はまだ高校生でした。振り返ってみると、今日の AWS を生み出した理念、つまり完全な管理体制、ネットワークにアクセス可能で、プリペイドで契約維持料なしといった方針は、SQS 開発の初期段階であった当時にも少し垣間見ることができます。現在、SQS は数多くの顧客が非常に大規模に使用しているサービスの中でも最も人気が高く、多くのアプリケーションの基本構成部分の 1 つとなっています。 これに対して、AWS Lambda は 2014 年に開催された AWS re:Invent (私はその日の参加者でした) にてリリースした比較的新しいサービスです。Lambda は、サーバーのプロビジョニングや管理を行わずにコードを実行できるコンピューティングサービスであり、2014 年にサーバーレスの革命を起こしたのです。Web およびモバイルバックエンドから IT ポリシーエンジン、データ処理パイプラインまで、幅広いユースケースに即座に採用されました。現在、Lambda は Node.js、Java、Go、C＃、Python のランタイムをサポートしているので、既存のコードベースの変更を最小限に抑え、新しいコードベースを柔軟に構築できます。さらにこの過去 4 年間で、Lambda の機能やイベントソースを多数追加したため、さらに迅速な仕事ができるようになりました。Lambda に SQS のサポートを追加することで、ポーリングサービスの実行や、SQS から SNS […]

はじめに 今回の記事では、先日一般公開された「Amazon QuickSightのプライベートVPC内のデータアクセス」の設定方法をご紹介します。この設定を行うことによって、Amazon QuckSight（以下、QuickSight）からプライベートサブネット内のAmazon RDS（以下、RDS）のデータベース、Amazon EC2内のデータベースへのアクセス、また AWS Direct Connect（以下、Direct Connect）を経由したオンプレミスのデータベースにアクセスして分析ダッシュボード、レポートを作成することが可能です。 なお本稿の情報は、2018年6月22日時点の以下のAWS公式ドキュメントをベースにしておりますが、最新の情報は設定前にご確認ください。 Amazon QuickSight: Amazon VPCを操作する 接続構成イメージ 以下で説明する手順を実行すると以下のようなイメージで構成されます。VPC内にあるプライベートサブネットの中にQuickSightアクセス用のセキュリティグループを定義することで、アタッチされるENI（Elastic Network Interface）経由でQuickSightが同一VPC内のデータベース（本例ではRDS）のあるプライベートサブネットに接続することが可能です。 図1. 構成イメージ（プライベートVPC内接続） また上記のように、QuickSightアクセス用のセキュリティグループを構成することで、オンプレミス環境にあるデータベースに対しても、Direct Connect経由でアクセス可能（オンプレミスデータベースへのルーティングが可能である前提）になります。 図2. 構成メージ（オンプレミスへの接続）   設定手順概要 １．QuickSight用のセキュリティグループ作成 AWSのマネージメントコンソールから「VPC → セキュリティグループ」を選択し、「セキュリティグループの作成」ボタンを押し、QuickSight用ENIのセキュリティグループを作成します。 図3. QuickSightアクセス用のセキュリティグループ作成   ２．作成したQuickSightアクセス用のセキュリティグループのインバウンドルール設定 ここで前の手順で作成したQuickSightアクセス用のセキュリティグループの「インバウンドルール」を設定します。何故、インバウンドルールを設定するかというと以下のドキュメントの引用のように、QuickSight用のENI（ネットワークインターフェイス）にアタッチされているセキュリティグループの通信はステートフルではないため、本例のRDSからの戻りの通信に対する受信ルールを追加する必要があるのです。 引用：Amazon QuickSight: Amazon VPCを操作する 「ただし、Amazon QuickSight ネットワークインターフェイスにアタッチされているセキュリティグループはステートフルではありません。つまり、送信先ホストからの戻りトラフィックは自動的に許可されません。この場合、ネットワークインターフェイスセキュリティグループに Egress ルールを追加しても機能しません。したがって、明示的に承認するために、受信ルールをセキュリティグループに追加する必要があります。」 図4. QuickSightアクセス用のセキュリティグループ設定上のポイント よって、以下の様にQuickSight用のセキュリティグループのインバウンドルールを以下の様に設定します。 図5. QuickSightアクセス用のセキュリティグループのインバウンドルールの設定例   ３．RDSのセキュリティグループの設定 次にRDSのセキュリティグループにQuickSightのセキュリティグループ経由のアクセスを許可する設定を行います。 AWSのマネージメントコンソールから「RDS → インスタンス」を選択し、該当のインスタンス名のリンクをクリックして、インスタンス詳細画面を表示します。 […]

社会は自動運転技術を搭載した車両から数多くの恩恵を受けます。トヨタ・リサーチ・インスティテュート (TRI) が最優先事項の一つに掲げているのが、進化した最新の人工知能 (AI) を活用してより安全で、利用しやすく、環境にも優しい車両を生産することです。TRI はその目標達成に役立てるためアマゾン ウェブ サービス (AWS) の深層学習に着目しました。 TRI は、Amazon EC2 P3 インスタンスを利用することで、以前使用していた P2 インスタンスと比較して訓練時間が 4 倍も速くなり、訓練時間が数日から数時間に短縮されました。これにより、モデル車を素早く最適化した上で短期間でトレーニングを再度行い、テストカーやシミュレーション環境に展開してさらにテストすることができます。また、AWS の「pay-as-you-go」モデルと組み合わせて、P2 インスタンスに対して P3 インスタンスのパフォーマンスを大幅に向上させたことで、TRI の運用コストを削減しました。 自動運転のための深層学習モデルの作成 TRI は、その自動運転技術のため単一技術のスタックを開発し、2 つのモードを用意しました。保護者 (Guardian) モードと運転手 (Chauffeur) モードです。保護者モードでは、ドライバーは常に車輪と路面状態に気を配る必要がありますが、運転中の社内外の環境を絶えず監視することで衝突危機を認識した時に必要なタイミングで介入を行います。運転手モードも同じ技術を使用しますが、車両は常に制御されており、厳密に乗客を乗せられる乗用車です。 自律型車両を開発および展開するには、膨大な量のデータ、高性能コンピューティング能力、高度な深層学習技術を結集、格納、管理する能力と、車両内でリアルタイムに処理する能力が求められます。 TRI は PyTorch の深層学習フレームワークを利用することで深層学習コンピュータビジョンモデルを作成し、両運転モードで自動的に監視および制御を行えるようにしました。TRI には、深層学習モデルで使用するデータを収集するため、カメラ、レーダー、LIDAR (3D 空間でオブジェクト表現を生成するための制御およびナビゲーションに使用される技術) などのさまざまなタイプのデータ収集センサーが装備されたテストカーを数多く保有しています。テストカーは、様々な運航設計領域 (Operational Design Domains、ODD) を駆け抜け、車両 1 台につき 1 日合計テラバイト単位のデータを収集して記録します。このデータは、分析、機械学習の再学習モデルやシミュレーションのため、素早く検索、準備および利用可能な状態にする必要があります。 TRI は、正確なトレーニングモデルには、数兆マイルの試験走行が必要だと考えています。1 億台以上のトヨタ車が路上を走行している今日、ドライバーは様々な運転状況を経験します。車両のテストを補完するため、TRI はシミュレーションを用いてさまざまな希少条件やシナリオをモデル化します。シミュレーションでは、暴風雨、吹雪、日中・夜間の異なる時間帯のギラツキや、さまざまな路面状態や周囲の状況といった厳しい状況で、機会学習モデルがどのように反応するかをテストするフォトリアルデータストリームを生成します。 TRI は、新しいテストデータが利用できるようになると、研究アイデアを間髪入れずに模索し、モデルを素早くトレーニングして、更新版をテストカーに搭載し、テストを再実行できるようにします。 […]

最新の Amazon Linux AMI を取得するシンプルな方法が必要ですか？ AWS Systems Manager Parameter Store はすでに最新の Windows AMI を取得できます。今回、最新の Linux AMI も取得できるよう機能が拡張されました。各 Amazon Linux AMI は、固有の 公開パラメータストア名前空間 を持ちます。AMIの名前空間をクエリすることで、指定したリージョンのイメージIDを得ることができます。

抽出、変換、ロード(Extract, Transform, Load, ETL)操作は、現在のエンタープライズデータレイクのバックボーンにひとまとまりとして形成されています。rawデータを役に立つデータセットへ変換し、最終的には、洞察可能な状態に変換します。ETLジョブは通常１つまたは１つ以上のデータソースからデートを読み、様々な種類の変換を適用し、結果を利用準備できているターゲットに書き込みます。ETLジョブのソースとターゲットはリレーショナルデータベースであるAmazon RDS(Amazon Relational Database) もしくはオンプレミス、データウェアハウスとしてAmazon Redshift 、オブジェクトストレージとしてAmazon Simple Storage Service(Amazon S3) のバケットなどがあります。Amazon S3は、AWSでデータレイクを構築するという状況において特に一般的です。 AWSは、ETLジョブの作成とデプロイを支援するAWS Glueを提供しています。AWS Glueは抽出・変換・ロードを行うフルマネージドなサービスであり、お客様が簡単に自分のデータとして準備、ロードできるものとなります。他のAWSサービスでもETLジョブを実装、デプロイすることも可能です。 AWS Database Migration Service(AWS DMS)、Amazon EMR(ステップAPIの利用)、さらにAmazon Athenaも含まれます。   ETLジョブワークフロー統合へのチャレンジ 多様なETLテクノロジーを含むETLワークフローをどのように統合できるでしょうか？ AWS Glue、AWS DMS、Amazon EMRなどのサービスは、Amazon CloudWatch Eventsをサポートしており、ETLジョブを連動させることができます。 Amazon S3は、中心に置かれたデータレークストアでもあり、CloudWatch Eventsをサポートしています。しかし、CloudWatchイベントのみに依存するということは、ETLワークフローの視覚的表現が1つもないことを意味します。また、全体的なETLワークフローの実行ステータスを追跡し、エラー・シナリオを処理することは困難になります。 本ブログでは、AWS Step FunctionsとAWS Lambdaを使用して、任意の複雑なETLワークフローでさまざまなテクノロジを含む複数のETLジョブを編成する方法を説明します。

ブロックチェーンの利用には、数多くの潜在的な利点があります。ブロックチェーンとは、検証可能かつ変更不能な方法でトランザクションを記録できる分散型データ構造です。ユースケースに応じ、コスト削減、速度や効率性の改善、企業コンプライアンスの強化、回復力やスケーラビリティの向上を実現できる可能性があります。 ブロックチェーンを早期に取り入れた人々は、金融、ヘルスケア、電子政府、非営利組織などの分野で、その革新的な使い道を発見しているところです。ブロックチェーンは、当初は仮想通貨 Bitcoin を支える主要テクノロジーとして開発されたものでした。 ブロックチェーンの使い道については、その設計から実に多くの機会が生じています。基本的には、幾千ものノードで構成されることが多い、大規模な分散型システムです。ブロックチェーンにおいては、ユーザーのアクティビティ、イベント、例外、その他の状態変化を見抜くことが困難な場合があります。しかし、AWS 分析サービスでは、ブロックチェーンアプリケーションを分析できるようにするとともに、その分野に関する重要な情報を提供します。 ウォークスルー この記事では、以下を実現する方法について説明します。 AWS Blockchain Templates を利用した Ethereum ブロックチェーンのデプロイ スマートコントラクトのデプロイ AWS Lambda、Amazon Kinesis、Amazon Athena に基づいたコントラクトの、サーバーレス分析パイプラインの構築 この Ethereum のデプロイやブロックチェーン分析は、幅広いブロックチェーンシナリオでの用途に、容易に適合させることができます。 前提条件 この記事は前提として、AWS と Ethereum に精通しているユーザーを対象としています。次のドキュメントでは、この記事で説明する手順を実行する際に役立つ背景知識を提供しています。 An introduction to Ethereum Deploying a smart contract to Ethereum An Introduction to Solidity Smart Contracts 加えて、このブログ記事からさらに多くを学ぶには、Amazon Kinesis、AWS Lambda、Amazon QuickSight、Amazon Athena にも精通していると便利です。詳細は、下記を参照してください。 Writing SQL on Streaming Data […]

本日（訳注：2018年5月31日）から、Amazon Elastic Container Service（Amazon ECS）およびKubernetesによって管理されるサービスの統合サービスディスカバリーを活用することができます。私たちは最近、Amazon Route 53 Auto Naming（オートネーミング）APIを使用してサービス名のレジストリを作成および管理することにより、コンテナ化されたサービスの発見と相互接続を容易にするECSサービスディスカバリーを導入しました。サービス名は、一連のDNSレコードセットに自動的にマップされます。これにより、コード内でサービスを名前（backend.example.comなど）で参照可能となり、実行時にサービスのエンドポイントを名前で解決するためのDNSクエリを記述することができます。 私たちは、Kubernetesユーザーにもオートネーミング APIが活用できるようにするため、オートネーミング APIをKubernetesもサポートするように拡張しました。この統合によって、オートネーミング APIによって管理されるサービスレジストリにKubernetesのサービスとイングレスを自動的に複製できるようになりました。 Kubernetesクラスタの外部にあるクライアントから、フレンドリーなサービス名を使用してこれらのサービスエンドポイントを簡単に解決できます。この統合を可能にするために、私たちはKubernetesインキュベータープロジェクトであるExternal DNSにコントリビュートしました。 これにより、Amazon ECSで実行されるサービスから、Route 53へのシンプルなDNSクエリを作成することで、Kubernetesで動作するサービスを発見して接続することができます。