Amazon Web Services ブログ

Category: News

AWS IoT Greengrass 2.0 を発表 — オープンソースエッジランタイムと新しい開発者向け機能

AWS IoT Greengrass 2.0 を発表できて嬉しく思います。 AWS IoT Greengrass の新しいバージョンで、デバイスビルダーがインテリジェントデバイスソフトウェアの構築、デプロイ、管理を容易に実行できるようになります。 AWS IoT Greengrass 2.0 は、オープンソースエッジランタイム、豊富な事前構築済のソフトウェアコンポーネントのセット、ローカルソフトウェア開発用のツール、多数のデバイス上でソフトウェアを管理するための新機能を提供します。 AWS IoT Greengrass 2.0 エッジランタイムは Apache 2.0 ライセンスのもとでオープンソースとして、Github で利用できるようになりました。このソースコードを利用することで、アプリケーションの統合、問題のトラブルシューティング、AWS IoT Greengrass を使用した信頼性とパフォーマンスが高いアプリケーションの構築がより簡単に行えます。 IoT ユースケース、デバイスの CPU およびメモリリソースに基づいて、事前構築されたソフトウェアコンポーネントを追加または削除できます。たとえば、アプリケーションを使用してデータストリームを処理する必要がある場合にだけ、ストリームマネージャなどの事前構築された AWS IoT Greengrass コンポーネントを含めるか、あるいはデバイス上でローカルに機械学習推論を実行する場合にだけ機械学習コンポーネントを含めるかを選択できます。 AWS IoT Greengrass IoT Greengrass 2.0 には、デバイス上でアプリケーションをローカルで開発およびデバッグできる新しいコマンドラインインターフェイス (CLI) が含まれています。さらに、デバイス上のアプリケーションを視覚的にデバッグできる、新しいローカルデバッグコンソールがあります。これらの新機能を使用すると、クラウドを使用して実稼働デバイスにデプロイする前に、テストデバイス上でコードを迅速に開発およびデバッグできます。 AWS IoT Greengrass 2.0 は AWS IoT thing groups と統合されているため、ロールアウトレート、タイムアウト、およびロールバックを制御する機能を持つデバイス間で、デバイスをグループ単位で簡単に整理したり、アプリケーションデプロイを管理したりできます。 AWS IoT […]

Read More

プレビュー開始 – Amazon Managed Service for Prometheus (AMP)

オブザーバビリティは、クラウドインフラストラクチャを大規模に実行するために不可欠な側面です。リソースが正常で期待どおりに動作しており、システムがお客様に望ましいレベルのパフォーマンスを提供していることを把握しておく必要があります。 課題の多くは、コンテナベースのアプリケーションを監視するときに生じます。第一に、コンテナリソースは一時的なものであり、監視するメトリクスが多数あるため、モニタリングデータのカーディナリティが著しく高くなります。簡単に言えば、一意の値がたくさんあるということで、これらはスペース効率性に優れたストレージモデルを定義し、有意義な結果を返すクエリを作成することを困難にします。第二に、優れた設計のコンテナベースシステムは、多数の可動部分を使用して構成されているため、モニタリングデータの取り込み、処理、および保存は、それ自体がインフラストラクチャ上の課題となり得ます。 Prometheus は、アクティブなデベロッパーとユーザーコミュニティを抱える優れたオープンソースモニタリングソリューションで、コンテナから収集された時系列データに最適な多次元データモデルを備えています。 Amazon Managed Service for Prometheus (AMP) のご紹介 本日から、Amazon Managed Service for Prometheus (AMP) のプレビューが開始されます。この完全マネージ型ドサービスは、Prometheus との完全な互換性があります。同じメトリクス、同じ PromQL クエリをサポートし、150 を超える Prometheus エクスポータを利用することもできます。AMP は、高可用性を実現するために複数のアベイラビリティーゾーンにまたがって実行され、水平的なスケーラビリティのために CNCF Cortex が搭載されています。AMP は、何百万もの時系列メトリクスを取り込み、保存し、クエリするために簡単にスケールできます。 プレビューには、Amazon Elastic Kubernetes Service (EKS) および Amazon Elastic Container Service (ECS) のサポートが含まれます。これは、クラウドまたはオンプレミスで実行されているセルフマネージド Kubernetes クラスターの監視にも使用できます。 Amazon Managed Service for Prometheus (AMP) の使用開始 プレビューに参加したら、AMP コンソールを開いて AMP ワークスペースの名前を入力し、[Create] (作成) […]

Read More

エッジデバイスでの機械学習モデルの運用をシンプル化する Amazon SageMaker Edge Manager

今日は、エッジデバイスフリートでの機械学習モデルの最適化、セキュア化、監視、および維持を容易にする Amazon SageMaker の新機能、Amazon SageMaker Edge Manager についてお知らせしたいと思います。 エッジコンピューティングが情報テクノロジーにおける最もエキサイティングな展開のひとつであることは明らかです。実際に、コンピューティング、ストレージ、ネットワーキング、およびバッテリテクノロジーの絶え間ない進歩のおかげで、組織は、製造、エネルギー、農業、およびヘルスケアなどのさまざまな産業用途のために、多数の埋め込みデバイスを世界のあらゆる場所で日常的にデプロイしています。シンプルなセンサーから大型の産業用マシンにおよぶデバイスには、望ましくない状態が検出された場合にアラートを送信するなど、データをキャプチャして分析し、措置を講じるという共通の目的があります。 機械学習 (ML) の幅広いビジネス問題を解決する能力はすでに実証されているため、お客様は、ローカルデータからより深い洞察を得るための取り組みの一環として、モデルをクラウドでトレーニングし、それらをエッジにデプロイすることでエッジへの ML の適用を試みておられますが、エッジデバイスの遠隔性と制約された性質により、エッジでのモデルのデプロイメントと管理は困難を極めることがよくあります。 たとえば、複雑なモデルは大きすぎて収まりきらないことがあり、お客様は小規模で精度に欠けるモデルを使用することで妥協せざるを得なくなります。また、同じデバイスでの複数のモデルを使用した予測 (たとえば、異なるタイプの異常の検出など) には、ハードウェアリソースを節約するために、オンデマンドでモデルをロードおよびアンロードする追加のコードが必要になる場合があります。そして、現実世界は常に、どのトレーニングセットの予想よりも複雑で不規則なものであるため、予測品質の監視は大きな懸念となります。 お客様から助けを求められた AWS は、これらの課題の解決に乗り出しました。 Amazon SageMaker Edge Manager のご紹介 Amazon SageMaker Edge Manager は、ML エッジデベロッパーが、クラウドまたはエッジで使い慣れたツールを簡単に使用できるようにします。このため、モデルを本番稼働させるために必要な時間と労力を削減しながら、デバイスフリート全体のモデル品質を継続的に監視し、向上させることが可能になります。 ユーザーが Amazon SageMaker でトレーニング、またはインポートしたモデルを元に、SageMaker Edge Manager はまず Amazon SageMaker Neo を使用してハードウェアプラットフォーム向けにモデルを最適化します。2 年前にローンチされた Neo は、低フットプリントのランタイムによってデバイス上で実行される効率的な共通のフォーマットにモデルを変換します。Neo は現在、Ambarella、ARM、Intel、NVIDIA、NXP、Qualcomm、TI、および Xilinx によって製造されたチップを基盤とするデバイスをサポートしています。 次に、SageMaker Edge Manager はモデルをパッケージ化し、それを Amazon Simple Storage […]

Read More

新機能 – バイアスを検出し、機械学習モデルの透明性を向上させる Amazon SageMaker Clarify

今日は、お客様が機械学習 (ML) モデルのバイアスを検出し、ステークホルダーと顧客にモデルの動作を説明できるようにすることで透明性を高めるために役立つ Amazon SageMaker の新機能、Amazon SageMaker Clarify をご紹介します。 ML モデルは、データセットに存在する統計的パターンを学習するトレーニングアルゴリズムによって構築されるため、いつくかの疑問がすぐさま思い浮かびます。第一に、ML モデルが特定の予測にたどり着いた理由を説明できるようになるのか? 第二に、モデル化しようとしている現実問題をデータセットが忠実に表現しない場合はどうなるのか? そもそも、このような問題を検出することはできるのか? これらの問題は、認識できない形で何らかのバイアスを生じないのか? これから説明するとおり、これらは決して推論的な疑問ではなく、極めて現実的なもので、その影響は広範囲に及ぶ可能性があります。 バイアス問題から始めましょう。不正なクレジットカード決済を検出するモデルに取り組んでいることを想像してください。幸いにも、決済の大部分は正当なものであり、データセットの 99.9% を占めています。これは、不正決済が 0.1% のみであることを意味し、100,000 件のうち 100 件といったところです。二値分類モデル (正当な決済 vs. 不正な決済) のトレーニングでは、モデルが多数派グループに強い影響を受ける、つまりバイアスがかかる可能性が非常に高くなります。実際に、トリビアルモデルでは決済が常に正当であると判断されてしまうかもしれません。このモデルはまったく役に立たないものの、99.9% は正しいことになります! このシンプルな例から、データの統計的特性、そしてモデルの精度を測定するために使用するメトリクスをどれほど慎重に扱わなければならないかがわかります。 この過少出現問題には多数の派生タイプがあります。クラス、特徴、およびユニークな特徴量が増加しても、データセットには特定のグループについて少量のトレーニングインスタンスしか含まれていない可能性があります。実際、これらのグループの一部は、性別、年齢範囲、または国籍など、さまざまな社会的にセンシティブな特徴に該当することがあります。このようなグループの過少出現は、予測結果に不均衡な影響をもたらす恐れがあります。 残念ながら、悪意がまったくなかったとしても、データベースにバイアス問題が存在し、ビジネス、倫理、および規制面での影響を伴うモデルに取り込まれてしまう可能性があります。このため、モデル管理者が本番環境システムにおけるバイアスの潜在的な原因に注意することが重要になるのです。 では、説明可能性の問題についてお話しましょう。線形回帰や決定木ベースのアルゴリズムといったシンプルで十分に解明されているアルゴリズムでは、モデルを検証し、モデルがトレーニング中に学習したパラメータを調べ、モデルが主に使用する特徴を特定することは比較的簡単です。その後、このプロセスがビジネス慣行に沿っているかどうかを判断できます (つまり、「人間のエキスパートでもこうしただろう」と言うようなものです)。 しかし、モデルがますます複雑になるにつれて (深層学習さん、あなたのことです)、このような分析は不可能になります。スタンリー・キューブリックの「2001 年宇宙の旅」に出てくる先史時代の部族と同じように、私たちはしばしば、不可解なモノリスをまじまじと見詰めながら、それが何を意味するのか頭をかしげるしかありません。多くの企業と組織は、ML モデルを本番環境で使用する前に、それらを説明可能なものにする必要があるかもしれません。さらに、一部の規制では、ML モデルが重大な意思決定の一環として使用される場合に説明可能性が義務付けられている場合があり、この説明可能性は、最初にお話したバイアスの検出にも役立ちます。 こうして、データセットとモデルに存在するバイアスを検出し、モデルが予測を行う方法を理解するための援助をお客様から求められた AWS は、作業を開始し、SageMaker Clarify を考案しました。 Amazon SageMaker Clarify のご紹介 SageMaker Clarify は、AWS の完全マネージド型 ML サービスである Amazon […]

Read More

新機能 — Amazon SageMaker Feature Store で機械学習の機能を格納、発見、共有する

今回、 Amazon SageMaker Feature Store を発表できることを、非常に喜ばしく思います。この Amazon SageMaker の新機能により、トレーニングや予測ワークフローで使用するために精選されたデータの安全な保存、検出、共有などを、データサイエンティストや機械学習エンジニアが容易に実施できるようになります。 作業経験が豊富な方であれば、機械学習 (ML) モデルをトレーニングし適切なアルゴリズムを選択するためには、高品質のデータを供給することがいかに重要かをご存知だと思います。ML のワークフローとして、最初にデータをクリーニングするのは良い考えです。さらに通常は、欠損値の補完、外れ値の削除、その他の処理が行われることになります。さらに多くの場合では、「特徴エンジニアリング」 と呼ばれる (一般的なものと難解なもの両方の手法がミックスされた) 手法により、データの変換が行われます。 特徴エンジニアリングの目的とは、簡単に言えば、表現性が高まるようにデータを変換して、アルゴリズムの学習を助けるということです。例えば、多くの列型データセットには、住所などの文字列が含まれています。ほとんどの ML アルゴリズムにとって、文字列は無意味なので、これらを数値表現でエンコードしなおす必要が生じます。この住所の文字列の場合であれば、GPS 座標に置き換えることができます。この形式なら、位置の概念を学ぶアリゴリズムにとって、より表現性が高いものになります。言い方を変えると、データが新しい石油だとすれば、モデルが成層圏の精度を得るのに必要とする高オクタン価のジェット燃料に、その石油を変える精製プロセスが、特徴エンジニアリングだと言えます。 実際、ML の実務担当者達は、特徴エンジニアリング用にコードを作成し、そのコードを初期データセットに適用し、処理されたデータセットでモデルをトレーニングた上でその精度の評価を行うことに、多くの時間を費やしています。この作業は実験的な性質を持つため、たとえ最小規模のプロジェクトであっても、複数回の反復が必要になることがあります。同じ特徴エンジニアリングコードが何度も実行されることも多く、同じ操作の繰り返により時間と計算リソースが浪費されます。こういった事情は、大規模な組織では、さらなる生産性の低下を引き起こすこともあり得ます。多くの場合で異なるチームが同じジョブを実行していたり、以前の作業に関する情報がないために特徴エンジニアリング用のコードを重複して記述したりするのが、その理由です。 また、MLチームには、解決しなければならない別の難しい問題もあります。モデルは処理が施されたデータセットでトレーニングされるているため、予測のために送信されるデータにも、同じ変換を適用することが不可欠となるのです。これは多くの場合、異なる言語で書きなおした特徴エンジニアリングコードを予測ワークフローに統合して、予測の処理時に実行する、ということを意味します。また、こういったプロセスの全体により、時間が消費されるだけでなく、一貫性を損なう可能性もあります。なぜなら、データ変換の最も小さな差異でさえ、予測には大きな影響を与え得るからです。 これらの問題を解決するために、しばしば ML チームは、フィーチャストアを構築します。フィーチャストアとは、トレーニングや予測ジョブで使用される処理済みデータを保持および取得できる、中央リポジトリのことです。フィーチャストアは便利ですが、独自のストアを構築および管理することは、技術、インフラストラクチャ、そして運用の面で多大な労力を要し、実際の ML 作業のための貴重な時間を奪ってしまいます。こういった状況に対する、よりよいソリューションをお客様から求められ、当社では、新サービスを作ることになりました。 Amazon SageMaker Feature Store のご紹介 Amazon SageMaker Feature Store は、ML 機能のための完全マネージド型で一元化されたリポジトリです。インフラストラクチャを管理することなく、特徴データを安全に保管および取得できます。Feature Store は、Amazon SageMaker に組み込まれています。SageMaker は、あらゆるアルゴリズムをサポートしている、ML 用の完全マネージド型サービスです。さらに Feature Store は、ウェブベースの ML 用開発環境である Amazon SageMaker Studio とも統合されています。 SageMaker […]

Read More

新機能 — Amazon SageMaker Pipelines が機械学習プロジェクトに DevOps 機能を提供

本日、 Amazon SageMaker Pipelines を発表することができまして、大変うれしく思います。これは Amazon SageMaker の新機能で、データサイエンティストやエンジニアが、エンドツーエンドの機械学習パイプラインを簡単に構築、自動化、スケールできるようになります。 機械学習 (ML) はもともと試験段階にあり、本質的に予測することはできません。数日から数週間かけてさまざまな方法でデータを分析および処理します。これは、ジオード (晶洞石) を壊して、貴重な宝石を見つけようとする作業のようです。次に、さまざまなアルゴリズムとパラメータを試しながら、最高の精度を求めて多くのモデルをトレーニングおよび最適化します。この作業は通常、アルゴリズムとパラメータの間に依存関係がある多くの異なる手順を伴い、手作業で管理するため、とても複雑になる可能性があります。特に、モデル系列の追跡は簡単ではなく、監査性やガバナンスを妨げます。最後に、上位モデルをデプロイし、参照テストセットに対するモデルの評価を行います。最後に、 と言いましたが、実際には何度も反復して、新しいアイデアを試し、新しいデータでモデルを定期的に再トレーニングします。 ML がどんなにエキサイティングであっても、残念ながら多くの繰り返し作業を伴います。小規模なプロジェクトでも、本番環境に移る前には何百もの手順が必要になります。こうした作業のせいで、時間の経過とともにプロジェクトの楽しさや興奮が失われていくだけでなく、監視する必要性やヒューマンエラーの可能性が大きくなります。 手作業を軽減し、トレーサビリティを向上させるために、多くの ML チームでは DevOps の理念を採用し、継続的インテグレーションと継続的配信 (CI/CD) 用のツールとプロセスを実装しています。確かにこれは正しい手順といえますが、独自のツールを作成することで、当初の予想よりも多くのソフトウェアエンジニアリングとインフラストラクチャ作業が必要な複雑なプロジェクトとなる場合が多いです。貴重な時間とリソースが実際の ML プロジェクトから奪われ、革新のペースがスローダウンします。残念ながら一部のチームでは、手作業でのモデルの管理、承認、デプロイに戻ることにしました。 Amazon SageMaker Pipelines のご紹介 簡単に言うと、Amazon SageMaker Pipelines で、ML プロジェクトの DevOps がトップレベルになります。この新機能により、データサイエンティストや ML デベロッパーは、自動化された、信頼性の高いエンドツーエンドの ML パイプラインを簡単に作成できるようになります。SageMaker は通常どおり、すべてのインフラストラクチャを完全に管理するため、お客様が作業を行う必要はありません。 Care.com は、高品質の介護サービスを見つけて管理するための世界をリードするプラットフォームです。Care.com のデータサイエンスマネージャーの Clemens Tummeltshammer 氏は次のように言います「 需要と供給が均衡な、力のある介護業界は、個々の家庭から国の GDP にいたる経済成長にとって不可欠です。私たちは Amazon SageMaker Feature Store と […]

Read More

機械学習用のデータを準備するためのビジュアルインターフェイス、Amazon SageMaker Data Wrangler のご紹介

本日、Amazon SageMaker の新たな機能であるAmazon SageMaker Data Wranglerを発表できることを非常に嬉しく思います。これを利用することで、データサイエンティストやエンジニアは、ビジュアルインターフェイスを使用した機械学習 (ML) アプリケーションのデータ準備をより速く行うことができます。 データサイエンティストと機械学習エンジニアのグループに、機械学習における問題の調査に実際、どのくらい時間を費やすのかを尋ねるたびに、私はよく多くのため息と、それに続く「運が良ければ 20% です」というせりふに沿った答えを聞きます。その理由を尋ねると、答えはいつでも同じです、「データ準備に、常に時間の 80% を費やしています。」 実際、トレーニングのためのデータ準備は、機械学習のプロセスにおける重要なステップであり、そこで下手な仕事をしようとは誰も考えないでしょう。一般的なタスクは次のとおりです。 データの特定: 未加工データの格納場所の検索、データへのアクセス データの可視化: データセット内の各列の統計的性質の検証、ヒストグラムの構築、外れ値の調査 データのクリーニング: 重複の削除、欠損値のエントリの入力または削除、外れ値の削除 データの強化および特徴エンジニアリング: 列の処理によるより表現力のある特徴データの構築、トレーニングのための特徴データのサブセットの選択 新しい機械学習プロジェクトの初期段階において、これは直感と経験が大きな役割を果たす高度な手動プロセスです。データサイエンティストは、多くの場合、pandas や PySpark などのオープンソースツールやオープンソースツールの組み合わせを使用して、さまざまなデータ変換の組み合わせを試し、モデルをトレーニングする前にデータセットを処理します。その後、予測結果を分析し、反復処理を行います。同じくらい重要ですが、このプロセスを何度も繰り返しループするのは、時間がかかり面倒であると同時に、エラーが発生しやすくなります。 ある時点で、適切なレベルの精度 (または選択した他のすべてのメトリクス) に達すると、本番環境の完全なデータセットでトレーニングしたいと考えるでしょう。しかし、まずはサンドボックス内で実験した正確なデータ準備のステップを再現および自動化する必要があります。残念ながら、この作業のインタラクティブな性質を考慮すると、慎重に文書化していても、常にエラーの余地があります。 最後に大事なことですが、最終段階に進む前に、データ処理インフラストラクチャを管理および拡張する必要があります。今考えれば、このすべてを行うには、80% の時間では十分ではないかもしれません。 Amazon SageMaker Data Wrangler のご紹介 Amazon SageMaker Data Wrangler は、機械学習用に完全に管理された統合開発環境 (IDE) である Amazon SageMaker Studio に統合されています。数回クリックするだけで、データソースへの接続、データの探索と視覚化、組み込み変換および独自の変換の適用、自動生成されたスクリプトへの結果コードのエクスポート、マネージドインフラストラクチャでの実行が可能です。各ステップをより詳しく見ていきましょう。 もちろん、データ準備は、データを特定してアクセスすることから始まります。SageMaker Data Wrangler を使用すると、導入してすぐに Amazon Simple Storage Service […]

Read More

Amazon SageMaker JumpStart で事前構築済みモデルと機械学習ソリューションへのアクセスを簡素化する

本日、Amazon SageMaker の新機能である Amazon SageMaker JumpStart の提供を開始したことを発表します。人気の高いモデルのコレクション (別名「モデルズー」) および一般的なユースケースを解決するエンドツーエンドのソリューションに、ワンクリックでアクセスして機械学習ワークフローを高速化することができます。 近年、機械学習はビジネスプロセスの改善と自動化に役立つ技術であることが証明されています。実際、過去データでトレーニングされたモデルは、金融サービス、小売、製造、通信、ライフサイエンスといった幅広い業界において結果を高精度に予測できます。しかし、これらのモデルの使用には、データセットの準備、アルゴリズムの選択、モデルのトレーニング、精度の最適化、本番稼働環境へのデプロイ、パフォーマンスの経時的モニタリングといった、一部の科学者やデベロッパーだけが有しているスキルと経験が必要になります。 モデルの構築プロセスを簡素化するために、機械学習コミュニティは、モデルズーと呼ばれる、人気の高いオープンソースライブラリによるモデルのコレクションを作成しました。モデルズーは多くの場合、リファレンスデータセットで事前トレーニングされています。例えば、TensorFlow Hub や PyTorch Hub では、デベロッパーは多数のモデルをダウンロードして、コンピュータビジョンや自然言語処理などのアプリケーションに統合することができます。 モデルのダウンロードは第一歩にすぎません。デベロッパーはその後、TensorFlow Serving および TorchServe モデルサーバーといったさまざまなツール、または独自のカスタムコードを使用してモデルをデプロイし、評価とテストを行う必要があります。モデルを実行したら、デベロッパーは受信データの適切な形式を把握する必要があります。これは以前からの悩みの種です。毎回ここで頭を抱えているのは私だけではないでしょう。 もちろん、完全な機械学習アプリケーションには通常、多くの不確定要素があります。データを事前処理して、バックエンドから取得した追加データでエンリッチメントを行い、モデルに投入する必要があります。予測は多くの場合、後処理され、さらなる分析や視覚化を行うために保存されます。モデルズーは有用ですが、役に立つのはモデリング段階でのみです。完全な機械学習ソリューションが提供できるようになるまでにデベロッパーが行うべき作業は、まだたくさんあります。 そのため、機械学習エキスパートには、プロジェクトのバックログが殺到します。一方で経験の少ないプラクティショナーは、開始するまでに苦労します。これらの障壁は大変苛立たしいものです。お客様からもこの問題への対処を求められました。 Amazon SageMaker JumpStart のご紹介 Amazon SageMaker JumpStart は、機械学習用の完全な統合開発環境 (IDE) である Amazon SageMaker Studio に統合されているため、モデルやソリューションなどを直感的に見つけることができます。ローンチ時の SageMaker JumpStart には、以下が含まていれます。 不正検出や予知保全といった、一般的な機械学習ユースケースに対応する 15 以上のエンドツーエンドソリューション コンピュータビジョン (画像分類、物体検出) および自然言語処理 (文章分類、質問応答) に対応する、TensorFlow Hub および PyTorch Hub で公開されている 150 以上のモデル […]

Read More

AWS Audit Manager で監査の準備を簡素化

タイムリーにエビデンスを収集して監査をサポートしたいとお考えではないでしょうか。しかしこれは手作業のためエラーが発生しやすく、場合によっては分散プロセスとなり、非常に困難な課題と化すおそれがあります。ビジネスがコンプライアンス要件の対象となる場合、監査の準備によって生産性が大幅に低下し、結果的に中断を余儀なくされる場合もあります。また、オンプレミスのレガシーシステム用に設計された従来の監査プラクティスをクラウドインフラストラクチャに適用する際に、問題が発生することも考えられます。 一般データ保護規則 (GDPR)、医療保険の携行と責任に関する法律 (HIPAA)、ペイメントカード業界データセキュリティスタンダード (PCI DSS) といった、進化する複雑な規制やコンプライアンス標準に対応するには、エビデンスを収集、検証、統合する必要があります。 また、AWS 使用量が、進化するコンプライアンス制御の要件にどのようにマッピングされているかを、常に再評価し続ける必要があります。要件を満たすには、データの暗号化がアクティブになっていたことを示す必要があり、さらに、サーバー設定の変更を示すログファイル、アプリケーションの高可用性を示す図、必要なトレーニングを完了したことを示すトランスクリプト、ソフトウェア使用量がライセンスの規定を超えていないことを示すスプレッドシートなども必要になる場合があります。この作業は、時には数十人のスタッフやコンサルタントを巻き込んで、数週間続きます。 AWS Audit Manager は、監査の準備に役立つフルマネージド型サービスです。一般的な業界標準および規制に適合する事前構築済みフレームワークを提供し、エビデンスの継続的な収集を自動化できます。今すぐに利用可能です。AWS リソースの使用に関するエビデンスの継続的かつ自動的な収集によって、リスク評価や規制および業界標準へのコンプライアンスを簡素化できます。また、監査に備えた体制を継続的に維持できるようになり、より迅速で中断の少ない準備プロセスを実施できます。 カスタマイズ可能な組み込みのフレームワークにより、クラウドリソースの使用状況をさまざまなコンプライアンス標準の制御にマッピングし、監査に適した用語を使用して、エビデンスを監査に備えたイミュータブルな評価レポートに変換できます。また、オンプレミスのインフラストラクチャの詳細や、ビジネス継続性計画、トレーニングのトランスクリプト、ポリシー文書などの追加のエビデンスを検索、フィルタリング、アップロードして、最終的な評価に含めることも可能です。 通常、監査の準備には複数のチームが関与します。そこで、委任ワークフロー機能を使用すれば、対象分野のエキスパートに管理を割り当ててレビューを行わせることが可能になります。例えば、ネットワークセキュリティに関するエビデンスのレビューを、ネットワークセキュリティエンジニアに委任できます。 最終版評価レポートには、要約統計量と、関連するコンプライアンスフレームワークの正確な構造に従って整理されたすべてのエビデンスファイルが入ったフォルダが含まれます。エビデンスが収集されて単一の場所に整理されるとすぐにレビュー可能になるため、監査チームはより簡単にエビデンスを検証し、質問に回答し、修復計画を追加できるようになります。 Audit Manager の開始方法 まず、新規の評価を作成して設定しましょう。Audit Manager コンソールのホームページで [Launch AWS Audit Manager (AWS Audit Manager を起動)] をクリックすると、[Assessments (評価)] リストに移動します (コンソールのホーム左側のナビゲーションツールバーからもアクセス可能)。そこで [Create assessment (評価を作成)] をクリックして、新規の評価の設定ウィザードを開始します。まず、評価に名前を付け、オプションで説明を入力します。次に、評価に関連付けられたレポートを保存する Amazon Simple Storage Service (S3) バケットを指定します。 次に、評価のフレームワークを選択します。さまざまな事前構築済みフレームワークや、自分で作成したカスタムフレームワークから選択することができます。カスタムフレームワークは一から作成することもできますが、既存のフレームワークに基づいて作成することもできます。ここでは、事前構済みの PCI DSS フレームワークを使用します。 [Next (次へ)] をクリックすると、評価の対象とする AWS アカウントを選択できます (Audit […]

Read More

新発表 — Amazon EMR on Amazon Elastic Kubernetes Service (EKS)

数万社のお客様が、Amazon EMR を使用して、Apache Spark、 Hive、HBase、Flink、Hudi、および Presto などのフレームワークでビッグデータ分析アプリケーションを大規模に実行しています。EMR は、これらのフレームワークのプロビジョニングとスケーリングを自動化し、さまざまな EC2 インスタンスタイプでパフォーマンスを最適化して、価格とパフォーマンスの要件を満たします。お客様は現在、Kubernetes を使用して組織全体でコンピューティングプールを統合しています。Amazon Elastic Kubernetes Service (EKS) で Apache Spark を管理しているお客様の一部には、EMR を使用して、フレームワークのインストールと管理、AWS のサービスとの統合などの手間のかかる作業を排除したいと考えているお客様もいらっしゃいます。さらに、EMR が提供するより高速なランタイムや開発およびデバッグのツールも活用したいと考えています。 本日、Amazon EMR on Amazon EKS の一般提供を発表いたします。これは、EMR の新しいデプロイオプションであり、EKS でのオープンソースのビッグデータフレームワークのプロビジョニングと管理を自動化できます。EKS で EMR を使用すると、同じ EKS クラスターで Spark アプリケーションを他のタイプのアプリケーションとともに実行し、リソース使用率を向上させ、インフラストラクチャ管理を簡素化することができます。 他のタイプのアプリケーションと同じ EKS クラスタに EMR アプリケーションをデプロイできるため、リソースを共有し、すべてのアプリケーションを運用および管理する単一のソリューションで標準化できます。最新のフレームワークへのアクセス、パフォーマンスが最適化されたランタイム、アプリケーション開発用の EMR Notebooks、デバッグ用の Spark ユーザーインターフェイスなど、現在 EC2 で使用しているのと同じ EMR 機能をすべて EKS で利用できます。 Amazon EMR は、アプリケーションをビッグデータフレームワークを使用してコンテナに自動的にパッケージ化し、他の […]

Read More