Amazon Web Services ブログ

Category: re:invent

AWS IoT FleetWiseを使用して車両データをより効率的に収集する

この記事は、Collecting vehicle data more efficiently with AWS IoT FleetWise を翻訳したものです。 今日、私たちはコネクテッドカーをインターネット接続を備えた先進的な車両だと考えています。しかし、2030年までに世界中で販売される新車の 95% 以上がインターネットに接続されるようになり、この数は今日の車両の約 50%となるので、コネクテッドカーは、単に自動車と呼ばれるようになるでしょう¹。車両との接続性が向上すると、自動車メーカーは車両の品質、安全性、自律性を向上させる機会が得られますが、コネクテッドカーが生成する膨大な量のデータをいかに効率的に収集して活用するかということが課題となります。この投稿では、数百万台もの車両からデータを収集して変換し、ほぼリアルタイムでクラウドに転送する、簡単かつコスト効率の高い新しいサービスである AWS IoT FleetWise について説明します。データがクラウドに格納されると、車両全体の健全性の分析や、自動運転や先進運転支援システム (ADAS) を改善する機械学習 (ML) モデルのトレーニングなどのタスクに使用できます。

Read More

週刊AWS – re:Invent 2021特別号(2021/11/29週)

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 先週はAWS re:Inventが開催されましたね。各種キーノートやテクニカルセッションなどに、日本からもオンライン参加された方が多かったのではと思いますが、楽しんでいただけましたでしょうか? 期間中は例年通りエキサイティングな発表が多数ありました。そこで今号はre:Invent特別号として、いつもとは違いサービスのジャンルごとにいくつかピックアップ&サマリして紹介する形になっています。発表内容をほぼ網羅したセミナー「AWS Black Belt Online Seminar AWS re:Invent 2021アップデート速報」での資料と動画が以下に出ていますので、こちらも合わせてご覧ください。

Read More

AWS re:Invent2021のインダストリーセッション

AWS re:Invent 2021へご参加ください このブログは2021年11月5日に投稿された“Manufacturing and Industrial at re:Invent 2021”をデジタルトランスフォーメーションアーキテクトの戸田が翻訳したものです。 AWS re:Inventの開催10周年にあたる今年も1週間にわたってワークショップ、ブートキャンプ、デモ、お客様同士のネットワーキングセッションなど多くのコンテンツを予定しています。今年は2021年11月29日から12月3日にラスベガスで開催予定で現地での参加が困難な方向けにバーチャル開催も行います。 AWS re:Invent 2021の数百にも及ぶセッションの中で50がインダストリー向けのセッションです。これらのセッションでは先進的な取組をされている製造業、自動車、電力、エネルギーのお客様がAWSのエキスパートと共にクラウドテクノロジーを活用してデジタル化、可視化そして現場業務の最適化を実現している事例を学ぶ事が出来ます。

Read More
週刊AWS

週刊AWS – 2020/12/14週 (re:Invent 特別編集号)

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 3週間に渡って開催した AWS re:Invent 2020 のWave 1が終了しました。今回は初のオンライン開催でしたが、みなさま楽しんでいただけましたでしょうか?第1週と第2週のセッションの多くはオンデマンド配信が開始になっています。こちらにカテゴリ別に整理されていますので、見逃した内容がある方はぜひチェックしてみてください。 今号は引き続きre:Invent特別編集号として、筆者らが独断でピックアップした重要アイテムを紹介する形でお送りします。今号はKeynote (Werner Vogels)とLeadership Session (IoT)で発表されたものを中心にご紹介します。 それでは、先週の主なアップデートについて振り返っていきましょう。

Read More

re:Invent 2019 での Amazon Redshift

毎年開催される AWS re:Invent ラーニングカンファレンスでは、新製品とプログラムの発売に満ちた刺激的な時間を過ごすことができます。2012 年に行われた最初の re:Invent カンファレンスで、AWS は Amazon Redshift を発表しました。それ以来、何万人ものお客様にクラウドデータウェアハウスとして Amazon Redshift をご使用いただきました。2019 年、AWS はいくつかの重要な発表を行い、数十のセッションを開催しました。この記事では、re:Invent 2019 で Amazon Redshift に起こったことのハイライトをご紹介します。 AWS re:Invent 2019 での Andy Jassy の基調講演 Andy Jassy が AWS の新機能について話す際、新しい Amazon Redshift のノードタイプであるマネージドストレージ付き RA3、新しい 横串検索 (プレビュー) 機能、Export to Data Lake、Amazon Redshift 向けの Advanced Query Accelerator (AQUA) (プレビュー) をローンチします。YouTube で「AWS re:Invent 2019 – […]

Read More

re:Invent 2019 で AWS コミュニティリーダーを歓迎

クラウドコンピューティングは世界的な現象ですが、コミュニティにとってロケーションは依然として重要です。たとえば、お客様からはよく、AWS User Group Community の規模、熱意、地理的範囲に感銘を受けているというお話を伺っています。ユーザーグループとコミュニティリーダーが行っている仕事は意義深いものです。 毎年、地域コミュニティのリーダーは re:Invent に足を運んで、それぞれのニーズを満たすように作られた一連のイベントに参加しています。半日のAWS コミュニティリーダーワークショップの一部として、リーダーたちはオリエンテーションセッションに参加し、We Power Tech(「多様で包括的でアクセス可能なテクノロジーの未来を構築する」) について学び、基調講演を視聴して、トレーニングセッションに参加します。re:Invent が終了したら帰国し、学んだ知識とスキルを技術コンテンツの作成および共有、コミュニティのさらなる育成に活かしています。 コミュニティリーダーシップ助成金 より多くのコミュニティリーダーが re:Invent に参加して有益な時間を過ごしてもらえるように、2018 年に助成金プログラムを開始しました。助成金は登録費、宿泊費、航空運賃を補助するもので、新興市場および十分な代表者がいないコミュニティの技術者に付与されました。 数名の受領者が AWS ヒーローとなり、2019 年はプログラムを拡張することにしました。インクルーシブな AWS コミュニティの構築に取り組んでいる人々を評価するため、受領者は 5 大陸の 14 か国から 17 人が選ばれました。さらに、We Power Tech は、別の補助金プログラム Project Alloy を開始し、会議の登録費、宿泊費、航空運賃を補助することでキャリアの最初の 5 年間で過小評価された技術者が re:Invent に参加できるようにしました。助成を受けた人は合計で、16 か国 102 人に上ります。 コミュニティリーダーシップ助成金を受け取り、re:Invent に参加できたのは、以下の参加者です。 Ahmed Samir – サウジアラビアのリヤド (LinkedIn、Twitter) – Ahmed は AWS リヤドユーザーグループ […]

Read More

新機能 – AWS ECS Cluster Auto ScalingによるECSクラスターの自動スケーリング

本日、AWS ECS Cluster Auto Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。 ECS Cluster Auto Scalingを有効にするには、Capacity Providerと呼ばれる新たな項目を設定する必要があります。1つのCapacity Providerは1つのEC2 Auto Scaling Groupに関連づきます。あるAuto Scaling GroupにECS Capacity Providerを関連付け、ECSクラスターにCapacity Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。 管理されたスケーリング。Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scaling Groupにアタッチされます。 管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。 これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。 Capacity Provier Reservation Capacity Provider Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。また、インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。 管理されたインスタンス保護 インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。 ユーザーの利点 これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。 単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。しかし同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。 既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。 スケールしてみよう! この機能をよく理解するには手を動かしてみるのが一番だと思います。 Amazon ECS Cluster Auto Scalingは、マネジメントコンソール、AWS CLI, Amazon ECS APIのいずれからも操作可能です。この例ではAWS CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。 まず2つのファイルを作成します。ひとつ目はdemo-launchconfig.jsonで、EC2 Auto Scaling Groupに起動するAmazon Elastic […]

Read More

Amazon Redshift の新機能 – データレイクエクスポートとフェデレーテッドクエリー

データウェアハウスは、トランザクション系システムや業務アプリケーションから届いたリレーショナルデータの分析に最適化されたデータベースです。Amazon Redshiftは高速でフルマネージドのデータウェアハウスであり、標準SQLや既存のビジネスインテリジェンス(BI)ツールを用いたデータ分析をシンプルかつ効率的に行うことを可能にします。 データウェアハウス内に格納されていないであろう非構造化データから情報を習得するためには、データレイクを構築するという手段があります。データレイクは、全ての構造化データと非構造化データをあらゆるスケールで格納可能な、一元化されたレポジトリです。Amazon Simple Storage Service (S3)上に構築されたデータレイクによって、ビッグデータ分析を行い、機械学習を用いて準構造化データセット(JSON、XMLなど)や非構造化データから知見を得ることが簡単に行えるようになります。

Read More

まもなく登場 – Graviton2プロセッサ搭載の汎用、コンピューティング最適化、メモリ最適化インスタンス

昨年のre:Invent 2018では、ArmベースのGravitonプロセッサ搭載の初代EC2インスタンス(A1)を発表しました。以来、コンテナ化されたマイクロサービス、ウェブサーバー、ログ等のデータ処理といったスケールアウト型のワークロードに対して、何千もの顧客がA1インスタンスを活用しています。 ArmアーキテクチャとA1インスタンスは早期の段階から、OSベンダー、ソフトウェアベンダー双方のコミュニティの強い協力を得られています。今やA1インスタンスに対して、Amazon Linux 2, Ubuntu, Red Hat, SUSE, Fedora, Debian, FreeBSDといった複数のLinux/Unixディストリビューションを選択できます。 さらに稼働させるサービスとしてDocker, Amazon ECS,  Amazon Elastic Kubernetes Serviceといったコンテナサービスを選択できますし、他にも多くのシステムエージェントや、AWS Developer ToolsやJenkinsを始めとする様々な開発ツールも動作します。 これまでにA1インスタンスに寄せられたフィードバックは強力かつポジティブなものばかりで、特にCPUインテンシブあるいはメモリインテンシブなワークロードをどんどんArmベースのサーバーで稼働させていきたいという声を受け取っていました。 Graviton2 本日、次世代のARMベースのEC2インスタンスの登場を先行発表します。このインスタンスはAWS Nitro Systemをベースに、新しいGraviton2プロセッサを搭載したものです。このプロセッサは7nm(ナノメートル)製造プロセスによるAWS独自設計によるもので、64ビットARM Neoverseコアをベースとして、浮動小数点演算処理の2倍の性能向上を含め、最大でA1インスタンスの7倍の性能を発揮するものです。また追加のメモリチャネルと1コアあたり倍加したキャッシュにより、メモリアクセス速度は最大で5倍まで向上しました。 これらの改良は、これまでのM5, C5, R5といった第5世代のインスタンスタイプを上回る、極めて大きな性能向上をもたらします。vCPUあたりの性能をM5インスタンスと比較したとき、初期のベンチマーキングでは次のような結果が得られました。 SPECjvm® 2008: +43% (推定) SPEC CPU® 2017 integer: +44% (推定) SPEC CPU 2017 floating point: +24% (推定) NginxでのHTTPSロードバランシング: +24% Memcached: +43% かつレイテンシの短縮 X.264ビデオエンコーディング: +26% Cadence XcelliumによるEDAシミュレーション: […]

Read More

EC2 Image BuilderによるOSイメージビルドパイプラインの自動化

社会人になったばかりの頃、開発チーム向けのOSイメージビルドの仕事がアサインされたのを今でも思い出します。時間はかかるし、エラーはよく出るし、再作成とスナップショット再取得をなんども実行する必要がありました。さらに、ご想像のとおり、そのあとには大量の手動テストが控えていたのです。 OSを最新に保つことの重要性は現在も変わりません。場合によっては自動化スクリプトを開発してくれるチームがあるかもしれませんが、いずれにせよVMのスナップショットを手動で取得するという作業は、多くのリソースを消費し、都度エラー対処が要求される、時間のかかる作業であることに変わりはありません。今日ここで、EC2 Image Builderを発表できることを大変うれしく思います。これは、自動化されたビルドパイプラインによる、簡単、かつ高速にセキュアなWindows ServerおよびLinux OSイメージをビルドし保守していくためのツールです。EC2 Image Builderで作成されたイメージは Amazon Elastic Compute Cloud (EC2)で用いることができ、また満たすべき情報セキュリティ基準を遵守できるよう、セキュリティを強化することができます。今後AWSは規制を受ける業界向けに、はじめの一手として使える“Security Technical Implementation Guide (STIG – セキュリティ設定チェックリスト)”に準拠したセキュリティ強化ポリシーを提供していきます。 EC2 Image Builderパイプラインに含めることのできる設定項目は、OSイメージのレシピ、基盤の構成、イメージの配布先、それからテスト構成です。さらに、セキュリティパッチを含むソフトウェアアップデートに応じて、イメージビルドを自動実行する機能も含まれます。パイプラインにより新たなイメージが作成されたタイミングで、各AWSリージョンにイメージを配布する前に検証すべきテストの自動実行を設定することもできます。またEC2 Image BuilderをEC2 VM Import/Export機能と併用することで、オンプレミスに存在するVMDK, VHDX, OVFそれぞれのフォーマットからなるVMイメージと連携することができます。自動テスト機能ではAWS提供のテストとユーザー定義のテストを組み合わせることもできます。 それでは、EC2 Image Builderの開始方法を見ていきましょう。 OSイメージビルドパイプラインの作成 AWSマネジメントコンソールのサービス一覧からEC2 Image Builderを選択し、EC2 Image Builderマネジメントコンソールに進みます。ここで”Create Image Pipeline”ボタンをクリックします。今回はAmazon Linux 2イメージをカスタマイズしてビルドすることにします。はじめの一歩はソースになるOSイメージを選択し、イメージに適用するビルドコンポーネントを指定し、実行するテストを構成するレシピを定義するところからです。 OSソースイメージの選択では、EC2 Image Builderの提供するAWS管理のイメージを選択しました(“Select managed images”).  この手順では他にも、自分で作成したAMIや共有されたAMIを選択することもできます。AMI IDを直接指定することができます。 “Browse images”ボタンを押すとAWS管理のイメージを選択する画面が開きます。イメージを選択するには、OS名のボックス右上のラジオボタンをクリックします。 続いてイメージに適用するビルドコンポーネントを指定します。これはインストールすべき追加ソフトウェアを指定する手順です。ウィザードの”Create build component”をクリックすると、ユーザー定義の新しいビルドコンポーネント作成のためのオプションを指定することができます。新規にビルドコンポーネントを作成するには、ビルドコンポーネントの名前(と説明書き), OS種別、コンポーネント暗号化のためのAWS Key […]

Read More