Amazon Web Services ブログ

Amazon Neptune のための Gremlin クエリヒントの紹介

Amazon Neptune は、高度に連結されたデータの保存とクエリのために最適化された、高速で信頼性に優れた完全マネージド型のグラフデータベースで、データにおける連結のナビゲートと活用に依存するオンラインアプリケーションに最適です。 Amazon Neptune は、SPARQL クエリ言語を使用してクエリできる W3C RDF グラフをサポートします。また、Gremlin グラフトラバース/クエリ言語を使用してクエリできる Apache TinkerPop プロパティグラフもサポートしています。 この記事では、Gremlin ユーザーが使用できるいくつかの新しい機能について検討していきます。今回は特に、クエリがどのように実行されるかをより良く制御できる新しいクエリヒント機能に注目します。 Gremlin クエリヒント Gremlin クエリヒントは、クエリがデータをトラバースする方法をより良く制御し、クエリ順序を最適化するかどうかを指定するために設計されています。このクエリヒントは、特にデータのシェイプを熟知している場合に便利です。 クエリヒントを適用するには、以下の withSideEffect Gremlin ステップを使用します。ここにある <hint-name> は適用されるヒントの名前に置き換え、<hint-setting> は適切な値に置き換えます。新しいヒントは、すべて Neptune# プレフィックスで始まります。 g.withSideEffect(‘Neptune#<hint-name>’,'<hint-setting>’) 現在利用可能なヒントとヒント設定を、以下の表に示します。各ヒントについては、この記事で後から詳しく見ていきます。 ヒント名 ヒント設定 アクション noReordering true Neptune はクエリの実行順序の最適化を試みません。これは、データがどのように編成されているかをユーザーが理解しており、Neptune が順序を変更して制約が適用されることがないようにしたい場合に最も有効です。 noReordering false Neptune は、最初に最も厳しい制約を適用するために、クエリの実行順序の最適化を試みます。これはデフォルトの noReordering 設定です。 repeatMode BFS 幅優先の方法でグラフをトラバースします。これは Gremlin の repeat ステップの使用時における Amazon Neptune のデフォルトバースモードで、多くのユースケースにとって望ましいモードです。ただし、多数の頂点を調べなければならない場合には、かなり多くのメモリを消費する場合があります。 […]

Read More

Amazon SageMaker 推論パイプラインと Scikit-learn を使用して予測を行う前に入力データを前処理する

Amazon SageMaker を使用すると、開発者やデータサイエンティストは大規模な機械学習 (ML) モデルを構築、トレーニング、調整、デプロイすることができます。目に見えないデータのリアルタイム予測またはバッチ予測のためにトレーニング済み ML モデルをデプロイできます。推論と呼ばれるプロセスです。ただし、ほとんどの場合、未加工の入力データは前処理する必要があり、予測で直接使用することはできません。これは、ほとんどの ML モデルが事前に定義された形式のデータを想定しているため、ML モデルでデータを処理するには、まず未加工データをクリーンアップして形式を設定する必要があるためです。 このブログ記事では、入力データの前処理に Amazon SageMaker の組み込みの Scikit-learn ライブラリを使用し、次に予測に Amazon SageMaker の組み込みの Linear Learner (線形回帰) アルゴリズムを使用する方法を説明します。Amazon SageMaker の推論パイプライン機能を使用して、ライブラリとアルゴリズムの両方を同じエンドポイントにデプロイするので、未加工の入力データを直接 Amazon SageMaker に渡すことができます。また、ML のワークフローをモジュール化し、トレーニングと推論の間で前処理コードを再利用して開発のオーバーヘッドやエラーを削減する方法も示します。 ここでの例 (GitHub でも公開されています) では、UCI 機械学習リポジトリからの abalone (アワビ) データセットを使用します。このデータセットには、性別、長さ、直径、高さ、殻の重さ、身の重さ、全体重、内臓の重さ、年齢など、アワビ (貝類の一種) に関するさまざまなデータが含まれています。  アワビの年齢を測定するのは時間がかかる作業であるため、アワビの年齢を予測するモデルを構築することで、物理的測定のみに基づいてアワビの年齢を推定することができ、アワビの年齢を手動で測定する必要がなくなります。 これを実現するために、まず Amazon SageMaker 組み込みの Scikit-learn ライブラリを使って簡単な前処理を行います。未加工のアワビデータに、SimpleImputer、StandardScaler、OneHotEncoder の変換器を使用します。これらは Scikit-learn の前処理ライブラリに含まれる一般的に使用されるデータ変換器であり、データを ML モデルに必要な形式に処理します。  次に、処理したデータを使用して、Amazon SageMaker の Linear […]

Read More

Amazon Aurora を使用して概念実証を作成する

お客様がクラウドに移行するにつれて、アプリケーションを実行する最良のツールを探しています。リレーショナル データベースを検討するとき、Amazon Aurora はよく選択されます。Amazon Aurora が MySQL および PostgreSQL とワイヤー互換であり、どちらよりも高いスループットを提供できることを考えれば、これは驚くようなことではありません。Aurora は、標準 MySQL データベースのスループットを最大 5 倍、標準 PostgreSQL データベースのスループットを最大 3 倍提供します。 顧客は Aurora を調査しながら、Amazon Aurora がアプリケーションに適しているかどうかを確認するために、一般的に概念実証 (POC) を構築します。以下に、POC を作成する際に考慮する点をいくつか示します。 Amazon Aurora は正しいツールなのか? データとデータベースについて考えるとき、重要な要素の 1 つはデータの速度です。一方では、データベースへの読み取りと書き込みの両方で、おそらく数千の接続と数十万の同時クエリでデータが非常に速く移動します。この速度では、クエリは通常、一度に比較的少数の行に影響します。さらに、データがこの速度でアクセスされるときは、レコードのようにクエリが一度に複数の列にアクセスするのが一般的です。このアクセス タイプでは、より実用的にデータを行単位で保存および取得することができます。このワークロード タイプの一般的な例は、オンライン トランザクション処理 (OLTP) システムです。 一方では、データの速度が遅くなるにつれて、ほんの一握りの接続と並行して実行されている少数のクエリしかない可能性があります。ただし、ここでは、完全なテーブルのスキャンを含め、行の範囲が何倍も大きいことがよくあります。この速度でクエリは、おそらくテーブルの行すべてに集中するよりは、通常、より小さな列のサブセットに集中します。この方法では、より実用的にデータをカラムナ形式で保存します。さらに、遅い速度での書き込みパターンは大きく異なります。ほとんどのデータは、高速では定期的に一括で読み込まれ、より高速ではほぼ一定で個々に書き込まれます。このワークロードタイプの一般的な例は、データ ウェアハウジングまたはオンライン分析処理 (OLAP) システムです。 Amazon Aurora は、主に高速データを処理するために設計されました。ワークロードに応じて、単一 r4.16xlarge の Aurora クラスターでは、1 秒間で 600,000 を超える SELECT ステートメントを処理できます。このようなクラスターでは、1 秒間で […]

Read More

新機能 – FreeRTOS カーネルでの RISC-V のサポート

FreeRTOS は、マイクロコントローラと呼ばれる小型でシンプルなプロセッサ用に設計された定評のあるオペレーティングシステムです。MIT オープンソースライセンスの下で利用可能であり、多くの異なる命令セットアーキテクチャ (ISA) で動作します。Amazon FreeRTOS は、Bluetooth Low Energy、Over-the-Air Updates (無線によるアップデート)、Wi-Fi のサポートを含む追加のネットワーキングおよびセキュリティ機能を提供する IoT 指向のライブラリのコレクションにより FreeRTOS を拡張します。 RISC-V は、シンプルで拡張性があり、実装が容易であるように設計された、無料でオープンな ISA です。RISC-V モデルのシンプルさと許容的な BSD ライセンスの組み合わせは、ライセンスコストをかけずに製造できる低コストのマイクロコントローラを含む、幅広い種類のプロセッサに最適です。RISC-V コアページから分かるように、RISC-V モデルはさまざまな方法で実装できます。シミュレータ、コンパイラ、デバッガなどの開発ツールも利用できます。 本日、FreeRTOS カーネルで RISC-V サポートを提供開始することを発表いたします。カーネルは RISC-V I プロファイル (RV32I と RV64I) をサポートし、任意の RISC-V マイクロコントローラをサポートするように拡張することができます。OpenISA VEGAboard、SiFive の HiFive ボード用の QEMU エミュレータ、Microchip M2GL025 Creative Board 用の Antmicro の Renode エミュレータの事前設定済みのサンプルが含まれています。 これまで以上に費用対効果が高いスマートデバイスを構築するための強力な新しいオプションになります! — Jeff; […]

Read More

EdTech企業のスタートアップを加速するAWS EdStart日本でもいよいよ始動!

Amazon Web Serviceでは教育に関わるいろいろな取り組みを行っています。その一つが2018年にスタートしたEdStartというEdTech(※)のスタートアップ企業を支援するプログラムです。 学ぶ側、教える側双方が新しい学びの形を模索する中、データ分析やAI/MLを活用しパーソナライズされた学習教材や、学習効果を測定・分析しその後の学習に反映させる仕組みなどに注目が集まっています。 また、プログラミング教育の開始に伴い、ITと教育の関係はより密接になり、様々な教育の現場でより広く受け入れられることが予想されます。 AWSはアプリケーションのプラットフォームとしてだけではなく、分析、AI/ML含め様々な面でこれらのワークロードを支援することが可能です。 AWS EdStart は、EdTech企業向けのAWS のスタートアップ支援プログラムです。このプログラムは、成長が速いEdTech の市場の中でスタートアップ企業がクラウドの活用を通じてより速く成長するために次のようなベネフィットを参加企業に提供します。 ・AWS利用クレジット ・コミュニティ活動やマーケティング活動の支援 ・技術情報の提供 これらのベネフィットを活用することで起業家はより安心して費用対効果が高いスケーラブルなソリューションを構築することができます。教育に革新をもたらす大きな夢やビジョンをお持ちのEdTech企業の方は是非AWS EdStart にお申し込みください。 日本ではEdStartのベネフィットの一つであるコミュニティ活動支援の一環として、メンバー企業を中心に技術交流イベントを開催することになりました。参加企業からのテクノロジーのプレゼンテーションの他、AWSからはワールドワイドでのEdTech企業のAWS活用事例を紹介します。AWSはEdTechのコミュニティとともに教育を進化させていきたいと考えています。 【EdTech LT Night & Meetup 開催概要】 日時 2019年3月25日(月)午後6時半開始 場所 AWS Loft Tokyo プログラム、お申し込みはこちら。 問い合わせ:aws-jpps-qa@amazon.com パブリックセクター エデュケーションプログラム担当 澤 ※エドテック:EdTechとは、教育(Education)× テクノロジー(Technology)を組み合わせた造語で、教育領域にイノベーションを起こすビジネス、サービス、スタートアップ企業などの総称。ICT(情報通信技術)と既存産業に掛け合わせることで新しい価値を生み出す様々な「X-Tech」の中でも特に急成長している。

Read More

AWS上での非常に大規模なSAP S/4HANA展開のサポートを発表

Steven Jonesは、AWSパートナー部門のテクニカルディレクターかつグローバルテクニカルリードです。 先日、大学に通い、まだ進路に悩んでいる私の息子が、なぜアマゾンで働くのが好きなのか尋ねてきました。私は、Amazon Web Services (AWS)が、現在のコンピューターで実行される世界で最も要求の厳しいお客様のワークロードのためにどのようにサービスオファリングを構築しているか、またお客様のご要望に応えるために限界を超え、テクノロジーシフトを促進し続けている会社の一員であることが如何に幸せか、最善を尽くして説明しました。 一例として、昨年2018年秋に、大容量メモリが必要なSAP HANAワークロードのための、6、9、12TBメモリおよび最新世代のインテル® Xeon® スケーラブル (Skylake) プロセッサーを搭載したAmazon Elastic Compute Cloud (Amazon EC2) High Memory インスタンスの提供開始を発表しました。あれから、このAmazon EC2 High Memory インスタンスをビジネスクリティカルなワークロードの運用で利用されているお客様は、これらの生来のクラウドインスタンスがアプリケーションサーバや他のAWSサービスと同じ環境でシームレスに展開かつ統合できる容易さが大好きだと語ってくれています。このユニークなテクノロジーは、2019年のSAP Innovation Awardsに立候補しています。そして現在、High Memory インスタンスは、SAP認定クラウドインスタンスの中で最も大きなメモリを提供しています。

Read More

Amazon DynamoDB の大量の時系列データの設計パターン

時系列データは、経時変化のパターンを示しています。たとえば、次のグラフの例に示すように、センサーを通じて環境データを記録するモノのインターネット (IoT) デバイスがあります。このデータには、温度、気圧、湿度、その他の環境変数が含まれる場合があります。各 IoT デバイスは定期的にこれらの値を追跡するため、バックエンドは毎秒最大数百、数千、または数百万のイベントを取り込む必要があります。 このブログ記事では、大量の時系列データを扱うシナリオ用に Amazon DynamoDB を最適化する方法について説明します。これを、自動化とサーバーレスコンピューティングを活用した設計パターンを使用して行います。 DynamoDB で大量のイベントを設計する 通常、データ取り込みシステムには以下が必要です。 現在の時間に関連する新しいレコードを取り込むための高い書き込みスループット。 最近のレコード用の低いスループット。 古いレコード用の非常に低いスループット。 このようなイベントをすべて単一の DynamoDB テーブルに格納する場合、ホットパーティション (最新のレコード) とアクセス頻度の低いパーティション (古いレコード) があります。アクセス頻度の低いパーティションは、プロビジョニングされた書き込み容量を、新しいレコードを保存しておきたいホットパーティションから逸らしてしまうため、最適ではありません。さらに、分析ニーズに適した期間を設計したいことがよくあります。たとえば、過去数日間または数か月間のデータを分析するとします。これらの期間の長さを調整することで、分析パフォーマンスとコストの両方を最適化できます。 DynamoDB の一般的な設計原則では、できるだけ少ない数のテーブルを使用することが推奨されていますが、時系列データでは、その設計原則に反して、各期間に複数のテーブルを作成します。この記事では、このようなアンチパターンを DynamoDB に使用する方法を説明しますが、時系列データには最適です。 オンデマンドキャパシティーモードを選択しない限り、すべての DynamoDB アクセスパターンは、読み取り容量単位と書き込み容量単位の異なる割り当てを必要とします。この記事では、レコードの読み書き頻度に基づいて、レコードを次の 3 つの異なるグループに分類します。 毎秒書き込まれる新しいレコード よく読み取られる最近のレコード あまり読み込まれない古いレコード 新たに取り込まれたレコードの書き込みスループットを最大にするには、期間ごとに新しいテーブルを作成し、最大数の書き込み容量単位と最小数の読み取り容量単位を割り当てます。また、各期間の終了前に次の期間のテーブルを事前作成して、現在の期間が終了したときにすべてのトラフィックをそのテーブルに移動できるようにします。古いテーブルへの新しいレコードの書き込みをやめると、その書き込み容量単位を 1 に減らすことができます。短期間の読み取り要件に基づいて、適切な読み取り容量単位もプロビジョニングします。次の期間が終了したら、読み取り容量や書き込み容量をオーバープロビジョニングしたくないので、割り当てられている読み取り容量単位も減らします。 また、新しい期間に切り替える頻度を見積もる際にも、分析上のニーズを考慮する必要があります。たとえば、昨年何が起こったのか分析したいと思った場合、4 つの並列クエリでデータをより効率的に取得して 4 つの結果セットを集計できるように、四半期ごとのテーブルを使用できそうです。 他のユースケースでは、前四半期のデータだけを分析したいと思うかもしれず、また毎月のテーブルを使用しようと考えるかもしれません。これにより、3 つの並列クエリを実行して分析を実行できます (四半期の各月に 1 回ずつ)。一方、この分析で特定の洞察が日単位で必要な場合は、日次テーブルを選択することを考えるかもしれません。 この記事の残りの部分では、日次テーブルを使用した後者のシナリオに焦点を当てます。昨日のデータが分析に適していて、より古いデータは頻繁にアクセスされないとします。真夜中の直前に新しいテーブルを作成し、真夜中の直後に古いテーブルの書き込み容量単位を減らすためにスケジュールされたジョブを設定しました。 このようにして、いつも以下があるようにします。 1,000 の書き込み容量単位と 300 の読み取り容量単位 (最大の書き込み数と一部の読み取り数) を持つ今日のテーブル。 1 […]

Read More

Docker on AWS: AWSのコンテナ関連サービスの選定例の紹介

本記事ではこれからAWS上でDockerコンテナを活用される方向けに、AWSのコンテナ関連サービスのどれを選択すると良いかの一例を紹介します。前提としては、example.com社の技術者Aさんが、自社のWebサービスをAWS上で構築するにあたって構成を決めるために、AWSのソリューションアーキテクト(SA)に相談するという流れの記事になります。AWSのどのサービスを使うかのご参考に是非ご覧ください。※こちらの選定はあくまで一例です。要件によっては選択すべきAWSのサービスが異なる点、予めご了承ください。

Read More

AWS CloudFormation を使用して、推奨されるベストプラクティスによって Amazon Aurora PostgreSQL DB クラスターをデプロイする

このブログ記事では、Amazon Aurora PostgreSQL クラスターのクイックスタートリファレンスデプロイメントを構築する方法について説明します。クラスターはセキュリティと高可用性のための AWS のベストプラクティスに基づいており、AWS CloudFormation を使用して速やかに作成できます。必要に応じてカスタマイズできる CloudFormation の一連のサンプルテンプレートを見ていきます。 Amazon Aurora は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、ハイエンドの商用データベースのパフォーマンスと可用性、ならびにオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 PostgreSQL 互換エディションの Aurora は、同じハードウェアで動作する標準 PostgreSQL の最大 3 倍のスループットを実現します。これにより、既存の PostgreSQL アプリケーションおよびツールを変更することなく実行できます。PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組み合わせは、商用データベースの移行にとって理想的なターゲットです。 Aurora PostgreSQL で道筋を始めて、AWS Well-Architected フレームワークの推奨ベストプラクティスに基づいて AWS リソースを設定したい場合は、ここで提供されている CloudFormation テンプレートを使用できます。 アーキテクチャの概要 下の図は、アーキテクチャの図であり、これから設定しようとしているものの簡単な要約です。 サンプルの CloudFormation テンプレートは、ネットワークインフラストラクチャとアーキテクチャの図に示されているすべてのコンポーネントをプロビジョニングします。CloudFormation テンプレートを次の 3 つのスタックに分割しました。 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ、S3 ゲートウェイエンドポイント、AWS Secrets Manager インターフェイスエンドポイント、およびその他のネットワークコンポーネントを設定する CloudFormation […]

Read More

Amazon EMR の伸縮性と回復力を高めるための Spark の機能強化

お客様は Amazon EMR の伸縮性を利用して、ワークフローが完了したとき、またはより軽いジョブを実行するときにクラスターをスケールしてコストを節約しています。これは、低コストの Amazon EC2 スポットインスタンスでクラスターを起動する場合も同様です。 Amazon EMR の Automatic Scaling 機能により、お客様はクラスターの使用状況やその他のジョブ関連のメトリックスに基づいて、クラスターを動的にスケーリングできます。これらの機能は、リソースを効率的に使用するのに役立ちますが、実行中のジョブの途中で EC2 インスタンスがシャットダウンすることもあります。これにより、計算とデータが失われる可能性があり、それがジョブの安定性に影響を与えたり、再計算による重複作業を招いたりする可能性があります。 実行中のジョブに影響を与えずにノードを適切にシャットダウンするために、Amazon EMR は Apache Hadoop の廃止メカニズムを使用しています。このメカニズムは Amazon EMR チームが開発し、コミュニティに還元したものです。これはほとんどの Hadoop ワークロードではうまく機能しますが、Apache Spark ではそれほどうまくいきません。Spark は現在、ノードの損失に対処する際、さまざまな問題点に直面しています。これにより、失われたタスクやデータをリカバリおよび再計算しようとしてジョブが停滞したり、場合によってはジョブがクラッシュしたりすることもあります。Spark の未解決問題のいくつかについての詳細は、以下のリンクを参照してください。 フェッチのエラーに関連した問題 シャットダウン中のノードを追跡し、それらのノードに対するタスクのスケジューリングを回避する これらの問題のいくつかを回避し、お客様が Spark を使用して Amazon EMR の伸縮性機能を最大限に活用できるようにするために、Amazon EMR では、オープンソースの Spark をカスタマイズしてノードの損失に対する回復力を高めることができます。再計算は最小限に抑えられ、ジョブはノードのエラーおよび EC2 インスタンスの終了からより迅速にリカバリできます。これらの改善点は、Amazon EMR リリースバージョン 5.9.0 以降で反映されています。 このブログ記事では、問題に対処するためにオープンソースの Spark でノードの損失に対処する方法と、Amazon EMR の改善にまつわる問題点の概要について説明します。

Read More