Amazon Web Services ブログ

Amazon Aurora Serverless MySQL データベースを操作する Data API の使用

Amazon Aurora Serverlessは、自動スケーリングされる Amazon Aurora (MySQL 互換エディション) のオンデマンド型実装です。このデータベースは、スタートアップとシャットダウンや、アプリケーションからの要求に応じた容量のスケーリングなどを自動で行います。これにより、データベースインスタンスの管理を一切行うことなく、クラウドでデータベースの実行が可能になります。頻度と継続性が低く予想しにくいワークロードのためのシンプルでコスト効果が高い、1 つの選択肢だと言えます。 AWS は最近、Data API の一般的な可用性を発表しました。この機能により、MySQL 互換バージョンの Amazon Aurora Serverless データベースを、シンプルな API エンドポイントを使ってアクセスできるようになりました。アプリケーションが常にデータベースに接続するため生じる、管理上の労力も必要なくなります。AWS Lambda を使っていれば、VPC 内で起動する Lambda 関数による追加的なオーバーヘッドもなく、Data API により安全にデータベースアクセスが行えます。また、Data API では、AWS Secrets Manager に保存されたデータベース認証情報が使えるので、API 呼び出しの際の認証情報の受け渡しも必要ありません。 このブログ記事では、コード的なインフラストラクチャー (AWS CloudFormation) を使って、Aurora Serverless MySQL クラスターをプロビジョニングする方法を解説します。Data API から Aurora Serverless データベースに SQL コマンドを発行する方法を、複数のユースケースについてコード例を示し説明します。コード例について深く知りたい場合は、GitHub にある「full end-to-end sample Serverless application」をご参照ください。 次の図に示すとおり、Data API は AWS […]

Read More

Amazon RDS Performance Insights のカウンターメトリクスを Amazon CloudWatch にインポートする

Amazon RDS Performance Insights では、Amazon RDS データベースインスタンスをモニターでき、データベースのパフォーマンスの分析やトラブルシューティングが可能です。Performance Insights のデータは AWS Management Console で表示させることができます。また別の手段として、Performance Insights の公開された API を使い、ご自分が必要なデータを照会することもできます。この API を使って、データ取得や、既存のモニタリングダッシュボードへの Performance Insights データの追加、あるいは、ご自身のモニタリングツールの構築などが行えます。今回のブログでは、Cloudwatch へデータを送信するために、この API を使用します。 概要 Performance Insights では、システムパフォーマンスのモニタリングに使うため、オペレーティングシステムやデータベースカウンターについての、多様なメトリクスを収集します。各 Amazon RDS データベースエンジンには、Aurora メトリクスなど、一連のカウンターメトリクスが個別に備わっています。データベースパフォーマンスのトラブルシュートは、データベースの動作時刻を指定することで開始できますが、カウンターメトリクスも、データモニタリングのために、二次的ソースとして便利に利用できます。またこれらを、既存のシステムダッシュボードに統合すると便利です。 この記事は、データベースカウンターメトリクスに関心をお持ちの方すべてに向けたものです。まず、2 つある Performance Insights API の 1 つである GetResourceMetrics を取り上げます。これにより、Performance Insights からデータを取り出す AWS Lambda 関数を作成する方法と、別のモニタリングシステムにそれを統合する方法をご紹介します。この記事では、Boto3、Python3、AWS CLI、Performance Insights API を使用していきます。作業開始の前に、Performance Insights が有効化された Amazon […]

Read More
週間AWS

週刊AWS – 2019/7/1週

みなさん、こんにちは。AWSソリューションアーキテクトの下佐粉(しもさこ)です。 今週も週刊AWSをお届けします。このシリーズでは、毎日のようにリリースされるAWSの新機能や新サービスを一週間単位でコンパクトに紹介しています。毎週火曜か水曜ぐらいを目処に更新しています。 6月はAWS Summit Tokyo & AWS Summit Osakaという2つの大きなイベントがあったのですが、これの対応でバタバタしていたら7月になっていました。もう1年の半分が終わってしまったのかと思ってビックリしています。今回は7月第1週アップデートからのピックアップですが、米国は7/4が独立記念日(祝日)だった関係でアップデートは7/1~7/3からのピックアップになっています。 では先週のアップデートを見ていきましょう。

Read More

Amazon Machine Learning で実行する社会的支援ロボットを使って車椅子の利用者に力を与える

Loro は社会的支援ロボットで、身体が不自由なユーザーが、周囲を見たり、感じたり、話したり、人々と対話したりするのを支援することによって、世界をよりしっかりと体験するのをサポートしています。  Loro は、さまざまな AWS 人工知能 (AI) サービス、特に機械学習 (ML) サービスを駆使して、幅広いユースケースで役立っています。 車椅子の利用者やその他の身体が不自由な人たちが直面する困難は、身体的な制約にとどまりません。社会的なやり取りや個人の健康と安全が、生活の中で絶えず直面する難題です。Loro の共同創設者 David Hojah 氏と Johae Song 氏は、車椅子に縛られた友人でメンターの Steve Saling に触発されて、これらの難題を軽減するために社会的支援ロボットを創作しようと決意しました。CTO の Hojah 氏は「Loro が肩に乗ったオウムのようにフレンドリーな伴侶になれればと思いました」と言葉をつづっています。 この「オウム」とそのコンパニオンアプリを徹底的にバックアップしているのが、AWS AI/ML です。  Among the services that work in concert to give Loro its assistive abilities are Amazon SageMaker and AWS DeepLens, as well as a wide combination of Amazon […]

Read More

AWS IoT Coreでブートストラップ証明書を使ったプロビジョニング

IoTデバイスを管理する上で、プロビジョニングは一つの重要な事項です。プロビジョニングとは、IoTデバイスをプラットフォームあるいはシステムに登録するプロセスです。デバイスのブートストラップ処理において、中間者攻撃などを防止するために、デバイスとIoTエンドポイントの間で相互認証を確立することが大事です。デバイス認証で現状最もセキュアな方法はデバイス証明書を使用することであり、一般的にデバイスアイデンティティ管理の第一選択肢でもあります。 このブログでは、AWS IoT CoreとAWS IoT Device Managementでブートストラップ証明書を使ったプロビジョニング方法について深掘りしていきます。AWS IoT Coreは、接続されたデバイスがクラウドのアプリケーションや他のデバイスとセキュアかつ簡単に通信することを実現するマネージド型のクラウドサービスです。AWS IoT Device Managementは大規模なIoTデバイスのセキュアなオンボード、管理、モニタリング、遠隔操作を実現するサービスです。 ブートストラップ証明書とは?なぜ必要なのか? 今回は、WiFi接続が可能な歯ブラシを取り扱う”SmartTeeth”という架空な会社のユースケースについて考えていきましょう。SmartTeethは歯ブラシの生産をサードパーティに委託しています。サードパーティの生産会社は、歯ブラシがクラウドと繋がる際のデバイス証明書を歯ブラシに組み込む必要があります。ただし、SmartTeethは歯ブラシが顧客の手元に届いてから、クラウドとどのような通信を許可するか制限したいと考えています。 初期の証明書は、歯ブラシがクラウドに繋がって自分自身を登録し、必要な権限一式が付与された証明書をリクエストすることのみを許可している状況が理想的です。さらに、このプロセスが自動化されており、SmartTeethの顧客からは透過的であること、そして歯ブラシが初めて接続する時、クラウドで必要なリソースが全て作成され、初期の証明書と実用フェーズの証明書を入れ替える部分をファシリテートする形が理想的です。 以下の図は歯ブラシの購入後に初期クレデンシャルを実用フェーズのクレデンシャルに置き換えるフローを示しています。     とあるSmartTeethの顧客がブートストラップ証明書をインストールするとします。ブートストラップ証明書は、デバイスの生産段階で各デバイスに実装される一意で低レベルの権限を持つ証明書です。この証明書には、デバイスがIoT Coreに接続し、最終的な証明書を取得するための特定のMQTTトピックとやりとりをする権限のみが定義されたAWS IoTポリシーが紐づいています。 デバイスプロビジョニングワークフロー ブートストラップ証明書を利用したデバイスプロビジョニングには3つのステップが含まれます: デバイス組立 デバイス登録 デバイスアクティベーション デバイス組立 デバイス組立とはデバイス生産プロセスにおいてサプライヤーが証明書をデバイスに埋め込むタイミングを指しています。このタイミングで一意なブートストラップ証明書がデバイスに格納されます。 このアプローチでは以下の条件を満たす必要があります: CA証明書がAWS IoT Coreに登録されており、デバイス証明書の自動登録が有効化されている デバイスには登録されたCA証明書によって署名されたデバイス証明書が生産時に格納されている デバイス登録 デバイス登録とはAWS IoT Coreのモノ(thing)としてデバイスを登録することを指しています。このプロセスでは以下の項目を実施する必要があります: AWS IoT Coreでモノとブートストラップ証明書を登録する IoTポリシーを作成し、ブートストラップ証明書にアタッチする ブートストラップ証明書とモノを関連づける 実用フェーズの証明書を(inactive状態で)AWS IoT Coreでプロビジョンする モノをAWS IoT モノのグループに、またはタイプを追加する ただし、これらを実施する前に、一つ重要なステップがあります。デバイスのサプライヤーは許可されたデバイスのリストを提供する必要があります(これをホワイトリストとも呼びます)。このファイルはデバイスIDのリストのみ、または他の属性情報を含んでいても構いません: cat ./allowed-device-list.txt demo001 demo002 demo003 デバイス登録プロセスでは、許可されたデバイスのリストに照会し、そのデバイスがサプライヤーにより保証されていることを確認します。また、ブートストラップ証明書が顧客指定のCAによって署名されていることも確認します。 […]

Read More

MXNet モデルサーバーを使った PyTorch 推論のデプロイ

トレーニングと推論は、機械学習 (ML) 開発サイクルの重要な要素です。トレーニングの段階で、特定の問題に対処するためのモデルを教えます。このプロセスを通じて、本番稼働で使用する準備ができたバイナリモデルファイルを入手できます。 推論については、TensorFlow Serving や Model Server for Apache MXNet (MMS) など、モデルデプロイ用のフレームワーク固有のいくつかのソリューションから選択することができます。PyTorch は、PyTorch でモデルサービングを実行するためのさまざまな方法を提供します。 このブログ記事では、MMS を使用して PyTorch モデルをサーブする方法を説明します。 MMS はオープンソースのモデルサービングフレームワークであり、大規模な推論のための深層学習モデルをサーブするように設計されています。MMS は、本番稼働での ML モデルのライフサイクルを完全に管理します。MMS は、コントロールプレーンの REST ベースの API と共に、ロギングやメトリクスの生成など、本番ホストのサービスに必要な重要な機能も提供します。 以下のセクションでは、MMS を使用して PyTorch モデルを本番環境にデプロイする方法について説明します。 MMS による PyTorch モデルのサービング MMS は、ML フレームワークに依存しないように設計されています。言い換えれば、MMS はあらゆるフレームワークのバックエンドエンジンとして機能するのに十分な柔軟性を備えています。この記事では、PyTorch で MMS を使用した、堅牢な本番稼働レベルの推論について説明します。 アーキテクチャ 次の図に示すように、MMS はモデルをモデルアーカイブの形式で使用します。 モデルアーカイブは、Amazon S3 バケットに配置することも、MMS が実行されているローカルホストに配置することもできます。モデルアーカイブには、推論を実行するためのすべてのロジックとアーティファクトが含まれています。 また、MMS では、ML フレームワークおよびその他の必要なシステムライブラリを事前にホストにインストールする必要もあります。MMS は ML […]

Read More

Amazon RDS および Amazon Aurora のデータベースエンジンに適切な暗号化オプションを選ぶ

 AWS クラウドのデータベースやデータストアの暗号化をデフォルトで選択するお客様の数は、ますます増えています。この流れは、さまざまな規制の枠組みにおいて機密データ (個人特定可能な情報 [PII、Personally Identifiable Information] など) の意味が発展していくのにともなって、勢いを増すばかりです。最新のデータベース暗号化の中から、パフォーマンスや各製品での迅速な反復を維持したまま最適なものを選ぶ方法について教えてほしい、というお客様からの要望も AWS に寄せられています。 そこで今回の記事では、Amazon RDS MySQL、MariaDB、Amazon Aurora MySQL の各データベースエンジンで使用できる、暗号化の方法をご紹介します。この記事は、ワークロードやビジネスのニーズに最も適した暗号化の方法を見つける一助となることを目指しています。なお簡略化のため、上記のエンジンをここでは “RDS MySQL 関連” のエンジン、または “MySQL 関連” のエンジンと呼びます。 概要 RDS で利用できる暗号化の方法は、次の 3 つのカテゴリーに分けることができます。 保存時のデータの暗号化。これには、プラットフォーム全般の機能およびデータベースエンジンそれ自体の機能が含まれます。 送信中のデータの暗号化。これは、データベースとクライアント間のネットワークを移動するデータを確実に保護する方法です。 レプリケーション中に送信されるデータの暗号化。ひとつ前のカテゴリーと大きな違いはありませんが、こちらはデータベースサーバー間のデータレプリケーションのトラフィックに用いられる方法です。 次に、それぞれのカテゴリーを詳しく見ていき、ニーズに合わせて最も効果的に実装する方法をご紹介します。 保存時のデータの暗号化 RDS MySQL 関連のデータベースエンジンを使用している AWS の多くのお客様は、RDS リソースの暗号化に依存しています。RDS により暗号化されたリソースを使うと、データは保存時に、データベース (DB、Database) インスタンスの基盤となるストレージ、その自動バックアップ、リードレプリカ、スナップショットを含めて暗号化されます。この機能は、データの暗号化にオープン標準の AES-256 暗号化アルゴリズムを使用しています。このアルゴリズムはデータベースエンジンに対して透過的です。 Amazon EBS では、RDS MySQL と MariaDB 向けに、基盤となるストレージとスナップショット機能が提供されます。Aurora では、専用の、分散されたログ構造のストレージサービスが使用されています。暗号化された Aurora DB […]

Read More

Amazon SageMaker のバッチ変換を使用して予測結果を入力データに関連付ける

大規模なデータセットに対して予測を実行するときは、実行前にいくつかの入力属性を削除することをお勧めします。これは、これらの属性が信号を伝達しない、または機械学習 (ML) モデルのトレーニングに使用するデータセットの一部ではなかったという理由からです。ジョブの完了後、予測結果をすべてまたは一部の入力データに分析用としてマッピングすることにも役立ちます。 たとえば、ID 属性を持つデータセットを考えてみましょう。一般に、観測 ID は特定の ML 問題に対する信号を伝送しないランダムに生成した番号か連続番号です。このため通常、観測 ID はトレーニングデータ属性の一部ではありません。しかし、バッチ予測を行う場合は、出力に観測 ID と予測結果の両方を 1 つのレコードとして含めることもできます。 バッチ変換機能は Amazon SageMakerで、Amazon S3 に格納されているデータセットに対して予測を実行します。以前はバッチ変換ジョブの作成前に入力データをフィルター処理し、ジョブの完了後に予測結果を目的の入力フィールドに結合する必要がありました。Amazon SageMaker のバッチ変換を使えば、予測を実行する前に属性を除外できるようになりました。CSV、テキスト、JSON 形式のデータを使用すると、予測結果を部分的または全体の入力データ属性と結合することもできます。このため、追加の前処理や後処理が不要となり、ML プロセス全体が高速化します。 この投稿では、この新しい機能を使用して Amazon SageMaker のバッチ変換ジョブの入力データをフィルター処理し、予測結果を入力データセットの属性と結合する方法を説明します。 背景 Amazon SageMaker は ML のワークフロー全体を対象にした完全マネージド型サービスです。このサービスは、データにラベルを付けてデータを準備し、アルゴリズムを選択して、モデルのトレーニングを行い、デプロイ用にモデルを調整および最適化を行い、予測を行い、実行します。 Amazon SageMaker はバッチ変換ジョブの開始時に、リソースのプロビジョニングを管理します。ジョブが完了するとリソースを解放するので、ジョブの実行中に使用したリソースに対してのみ支払うことになります。ジョブが完了すると、Amazon SageMaker は指定された S3 バケットに予測結果を保存します。 バッチ変換の例 UCI の乳がん検出のためのパブリックデータセットを使って、特定の腫瘍が悪性 (1) または良性 (0) である可能性があるかどうかを検出するバイナリ分類モデルをトレーニングします。このデータセットには各腫瘍の ID 属性が付属しています。これらはトレーニングと予測の際に除外されます。ただし、バッチ変換ジョブからの各腫瘍の悪性腫瘍について予測した確率を使用して、ID 属性を最終的なアウトプットに戻し、記録します。 手引きとなる Jupyter ノートブックもダウンロードできます。この記事の以下の各セクションはノートブックのセクションに対応していますので、読みながら各ステップのコードを実行してください。 設定 […]

Read More

Amazon SageMaker での Apache MXNet 1.4 と Model Server のサポート

Apache MXNet は ディープニューラルネットワークのトレーニングとデプロイに使用するオープンソースの深層学習ソフトウェアフレームワークです。 データサイエンティストや機械学習 (ML) の開発者の多くが深層学習モデルの構築の際、その柔軟性と効率性から MXNet を好んで使用しています。 Amazon SageMaker では MXNet を含むすべての ML フレームワークとライブラリにおいて、カスタマーエクスペリエンスの向上に取り組んでいます。MXNet 1.4 の最新リリースでは、インターネット無料モードで MXNet コンテナを使用したり、Model Server for Apache MXNet (MMS) を使った深層学習モデルを推論用にデプロイしたりできるようになりました。 Model Server for Apache MXNet (MMS) は深層学習モデルを推論用にデプロイする作業を簡素化するオープンソースのツールセットです。MMS を使用すると、MXNet やその他のフレームワークモデルを簡単に、素早く、そして大きな規模で提供できます。詳細については、「Model Server for Apache MXNet v1.0 release」をご参照ください。 MXNet 1.4 の更新には、ネットワークの分離、Julia バインディング、実験的な制御フロー演算子、JVM メモリ管理、グラフの最適化と量子化、使いやすさの向上など、いくつかの新機能が含まれています。変更ログ情報については、「Apache MXNet (incubating) 1.4.0」をご参照ください。 Amazon SageMaker のトレーニングとデプロイ済み推論コンテナは、デフォルトでインターネットに対応しています。新しい MXNet コンテナを使用すると、インターネット無料モードでコンテナを使用できます。そのため、セキュアかつ隔離された環境内でトレーニングジョブを実行できます。 Amazon SageMaker をトレーニングまたは推論コンテナへの外部ネットワークにアクセスさせたくない場合は、トレーニングジョブやモデルの作成時にネットワークの分離を有効にできます。 MXNet […]

Read More

AWS DMS と AWS Glue を使用して進行中のデータレイクの変更を読み込む

Amazon S3 にデータレイクを構築することは、組織に無数のメリットをもたらします。多様なデータソースへのアクセスし、ユニークな関係の決定、カスタマイズされたカスタマーエクスペリエンスを提供するための AI / ML モデルの構築、消費のための新しいデータセットのキュレーションの加速などを可能にします。ただし、オンプレミスであれ AWS であれ、運用データストアから継続的に変化する更新をキャプチャしてデータレイクに読み込むと、時間がかかり管理が困難になる可能性があります。 この投稿では、Oracle、SQL Server、PostgreSQL、MySQL などの定評があるデータベースソースから進行中の変更をデータレイクに読み込むソリューションをデプロイする方法を示します。このソリューションは、新規および変更されたデータを Amazon S3 にストリーミングします。また、適切なデータレイクオブジェクトを作成および更新し、設定したスケジュールに基づいてソースに似たデータのビューを提供します。その後、AWS Glue Data Catalog は、分析サービスが使用するために、新しく更新され重複除外されたデータを公開します。 ソリューションの概要 このソリューションを 2 つの AWS CloudFormation スタックに分割します。この投稿で参照する AWS CloudFormation テンプレートは、パブリックの S3 バケットからダウンロードすることもできますし、後で紹介するリンクを使用して起動することもできます。同様に、この投稿の後半で参照されている AWS Glue ジョブもダウンロードできます。 最初のスタックには、再利用可能なコンポーネントが含まれています。一度だけそれをデプロイする必要があります。以下の AWS リソースを起動します。 AWS Glue ジョブ: 未処理の S3 ファイルから重複排除され最適化された parquet ファイルへの読み込みプロセスのワークフローを管理します。 Amazon DynamoDB テーブル: それぞれのデータレイクテーブルのデータ読み込み状態を保持します。 IAM ロール: これらのサービスを実行して、S3 にアクセスします。このロールには、昇格された権限を持つポリシーが含まれています。これらのサービスにだけこのロールを割り当て、IAM ユーザーまたはグループには割り当てないでください。 AWS […]

Read More