Amazon Web Services ブログ

Amazon Redshift はそのサービスの開始以来、高度な複雑性を持つ分析ワークロードにも妥協を許さない高速処理で数千におよぶお客様の信頼を得てきました。2017 年にお客様にもたらした 3 倍から 5 倍のパフォーマンスゲインの実現には、ショートクエリの高速化、結果キャッシュ、遅延マテリアライゼーション、そのほか重要な多数の改善点が貢献しています。本記事では、Amazon Redshift の最新の改善活動や、パフォーマンス向上への絶え間ない取組みがお客様を支援している様子をご紹介します。また、今でも継続中の改善活動の評価に利用していた業界標準のベンチマークから得られたパフォーマンステストを考察します。 最新のパフォーマンス改善活動 AWS はそのデータウェアハウスの世界最大規模のデプロイメントによって、さまざまな分析ワークロードにわたる使用パターンを分析し、パフォーマンス向上のための機会を探り出します。そこから得た知見は数千におよぶお客様の利益にシームレスにつながる改善をもたらします。パフォーマンス面における過去 6 か月間の主な改善点は、次のとおりです。 メモリ重視型クエリ用途のリソース管理の改善: Amazon Redshift で結合時と集計時のメモリの消費および予約プロセスが向上しました。これにより、大多数のハッシュテーブルに対するキャッシュの効率性を向上させ、メモリ重視型の結合および集計操作の洩れの低減を最大で 1.6 倍改善しました。 コミットのパフォーマンス改善: コミットは書き込みトランザクションの主なコンポーネントとして、ETL (抽出、変換、ロード) ジョブといったデータアップデートおよびデータインジェスチョンのワークロード処理のパフォーマンスに直接インパクトを与えます。2017 年 11 月以降、コミットのパフォーマンスの最適化活動の一環として、複数コミットを 1 回の操作で行うバッチ処理、コミットロック性能の向上、データ局所性認識型のメタデータのデフラグ用プログラムなどを実現してきました。これらに代表される最適化活動は、HDD ベースのクラスターでかかるコミット時間の低減効果を平均で 4 倍にしています。大量トランザクション (Amazon Redshift のコミット操作の上位 5%) では、最適化効果は 7.5 倍になっています。 繰り返しクエリのパフォーマンス改善: Amazon Redshift の結果キャッシュ、ダッシュボード、可視化、ビジネスインテリジェンス (BI) ツールが繰り返しクエリを実行すると、パフォーマンスを大幅に向上します。さらに、結果キャッシュで解放されるリソースにより、他のすべてのクエリのパフォーマンスが向上します。 クエリ処理の改善: Amazon Redshift は繰り返しサブクエリ、述語を使用した高度分析用関数、重複作業を避けて工程を合理化することによる複雑なクエリプランなどの事例では、そのパフォーマンスは 2 倍から 6 倍高速化しています。 文字列操作の高速化: […]

組織が分析慣行を拡大し、データ科学者やその他の専門家を雇用するにつれ、ビッグデータのパイプラインはますます複雑になります。高度なモデルが毎秒収集されるデータを使用して構築されています。 今日のボトルネックは分析技術のノウハウではない場合がよくあります。むしろ、クラウドには適さないことがあるツールを使用した ETL (抽出、変換およびロード) ジョブの構築と維持の難しさがボトルネックになっています。 この記事では、この課題の解決策を示します。私は数年にわたり、地球のあちこちで記録された地震イベントの中途半端に構造化されたデータセットから始めます。私は地球の表面自体、つまり構造プレートストラクチャを形成する岩の性質に関する広範囲な洞察を取得して、Amazon QuickSightのマッピング機能を使用して視覚化ようとしました。

 新しいグラフデータモデルやクエリを作成する、あるいは、既存のグラフデータセットを探索するかどうかに関わらず、結果を視覚化できるインタラクティブなクエリ環境があると便利です。このブログ記事では、Amazon SageMaker ノートブックを Amazon Neptune データベースに接続して、これを実現する方法を紹介します。ノートブックを使用して、データをデータベースにロードし、クエリをして結果を視覚化します。 Amazon Neptune は高速かつ信頼性の高いグラフデータベースです。クエリワークロードで、接続をナビゲートし、エンティティ間の関係の強さ、重さ、または品質を活用する必要がある場合に理想的です。 Amazon SageMaker は、機械学習モデルの構築、トレーニング、および開発のための完全管理プラットフォームです。このブログの記事では、その機能に対応した SageMaker を使用し、ホストされた Jupyter ノートブックを提供します数回クリックするだけで、Jupiter のノートブックを作成し、それを Neptune に接続し、データベースのクエリを開始できます ソリューションの概要 このブログの記事で紹介されているソリューションは、以下のリソースを作成します。 3 つのサブネットと VPC S3 エンドポイントを持つ Neptune VPC 適切なサブネット、パラメータ、およびセキュリティグループを持つ、単一の r4.xlarge インスタンスを含む Neptune クラスター Neptune が S3 からデータをロードすることを許可するIAM ロール SageMaker Jupyter ノートブックインスタンス、IPython Gremlin 拡張モジュール、Gremlin コンソール、および一部のサンプルノートブックコンテンツ Neptune データベースのエンドポイントは、アカウントの新しい VPC にプロビジョニングされます。 SageMaker の Jupyter ノートブックは、Amazon SageMaker VPC […]

Database フリークな皆様、こんにちは！AWS DevDay Tokyo 2018 Database トラックオーナーの江川です。 2018 年 10 月 29 日（月）〜 11 月 2 日（金）にかけて、AWS DevDay Tokyo 2018 が開催されました。本記事では、11/1(木)に実施された Database トラックのセッション資料をご紹介します。 セッション資料紹介に先立ち、お客様セッションとしてご登壇いただいた、Sansan株式会社間瀬様、株式会社ソラコム安川様、Amazon Pay 吉村様にお礼申し上げます。併せて、ご参加いただいた皆様、ストリーミング配信をご覧いただいた皆様ありがとうございました。   ●お客様セッション資料 AWSサービスで実現するEightの行動ログ活用基盤(Sansan株式会社 間瀬哲也様) AWSサービスで実現するEightの行動ログ活用基盤 from Tetsuya Mase DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 from SORACOM,INC DynamoDBとAmazon Pay で実現するキャッシュレス社会 […]

Amazon EMR クラスターのような管理された Apache Hadoop 環境では、クラスター上のストレージ容量がいっぱいになると、それに対処する便利なソリューションはありません。この状況は、クラスター起動時に、Amazon Elastic Block Store (Amazon EBS) ボリュームを設定し、マウントポイントを設定するために発生します。そのため、クラスタの実行後にストレージ容量を変更することは困難になります。これに適したソリューションとしては、通常 、クラスターにさらにノードを追加し、データレイクにデータをバックアップしてから、より大きな記憶容量を持つ新しいクラスターを起動する方法があります。または、ストレージを占有するデータを消去してもよい場合は、通常、余分なデータを削除するという方法があります。 Amazon EMR で管理可能な方法により、この問題に対処する際の役に立つ、Amazon EBS のElastic Volumes 機能を使用してストレージを動的にスケールアップする方法を説明します。この機能で、ボリュームの使用中に、ボリュームサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプを変更することができます。変更が有効になっている間も、EMR クラスターを継続使用して、大きなデータアプリケーションを実行できます。

Oracle社の最新のアナウンスメントによると、Oracle社が提供するOpenJDKへの無料のLTS (Long-Term Support) は2019年1月までで終了することが示されています。ここで改めてAmazon Linux 2上でのOpenJDK 8およびOpenJDK 11ランタイムへのLTSが最短でも2023年6月30日までAmazonより提供されることをお伝えします。私達はOpenJDKコミュニティとコラボレーションし、また貢献することで私達のお客様にJavaランタイムの無料LTSをご提供いたします。 加えて、Amazon Linux AMI の最新リリースである Amazon Linux AMI 2018.03では、Amazon Linux 2への移行を容易にするため、OpenJDK 8ランタイムのサポートを最短でも2020年6月30日までAWSよりご提供します。AWSのサービスである、AWS LambdaやAmazon EMR、Amazon Elastic BeanstalkはAWSがサポートするOpenJDKビルドを使用します。

みなさん。こんにちは。アマゾン ウェブ サービス ジャパン 株式会社 Well-Architected リードの高山です。 このたびクラウド設計・運用のベストプラクティス集である”AWS Well-Architected フレームワーク“に関して、最新の日本語版ホワイトペーパーを公開しましたのでお知らせします。このホワイトペーパーは、2018年6月に内容が更新された”AWS Well-Architected フレームワーク “ホワイトペーパー(英語版)を日本語に翻訳したものです。 ダウンロードはこちらから＞ AWS Well-Architected フレームワーク ホワイトペーパー(PDF) ■AWS Well-Architected フレームワークとは？ AWS Well-Architected フレームワーク(以下W-A)は、AWSのソリューションアーキテクト(SA)が、AWSのサービス開始から10年以上に渡り、様々な業種業界、数多くのお客様のアーキテクチャ設計および検証をお手伝いしてきた経験から作成したクラウド活用のベストプラクティス集です。具体的には「運用の優秀性」「セキュリティ」「可用性」「パフォーマンス効率」「コスト最適化」の5つの観点について、クラウドをより活用するための設計原則と、お客様システムがベストプラクティスに沿っているかを確認するための質問と回答で構成されています。 ■AWS Well-Architected フレームワークの活用について W-Aは設計・構築・運用の各フェーズでご活用いただけます。また一度だけではなく定期的にW-Aレビューを実施することで、よりWell-Architected(優れた設計がされた)なシステムを保つことが出来ます。活用方法については後述のBlackBeltオンラインセミナー「クラウド設計・運用のベストプラクティス集 “AWS Well-Architected Framework”」も是非ご参照ください。 一番大事なこと なお、オンラインセミナーでも触れていますが、W-Aの活用時に一番大事なことは(必ずしも全てをベストプラクティスに合わせるのがゴールではなく)「ベストプラクティスを理解した上で、ビジネス的な判断を行う」ことです。同時に「ベストプラクティスに適合させないことによる、各種リスクや改善点を顕在化させて認識し、チーム内に共有する」というのも非常に大事なポイントです。 ■今回のホワイトペーパー更新のポイント 運用の優秀性 構成を変更して、全ての基礎となる「運用の優秀性」を1つめの柱としました。ここでは「ビジネスの成功」を最終的な目標として、どのように準備して、どのように運用して、どのように進化させるべきかについてをご説明しています。ベストプラクティスには「ビジネスの成功可否を数値で判断するための各種メトリクスをあらかじめ定める」のような、一見するとAWSの範疇に収まらないのでは？という内容の記載もありますが、これはAWSが長年に渡ってお客様のシステム設計・構築・運用のお手伝いをする中で、非常に重要だと考えているポイントです。このようなメトリクスが事前に設定されていないために、ご苦労されているお客様をお見かけして来ました。 W-Aのレビュープロセス また「W-Aのレビュープロセス」についても記載しています。一部抜粋しますと… アーキテクチャのレビューは、一貫性のある方法と「誰も責めない」アプローチで詳細に行う必要があります。レビューは短時間 (数日ではなく数時間) で行います。これは話し合いであり監査ではありません。アーキテクチャをレビューする目的は、対応が必要な深刻な問題や、改善できる部分を特定することです。レビュー結果は、お客様の改善のためのアクションとなります。 など目的とレビューの進め方についてご説明しています。是非ご一読ください。 最新サービスの反映 セキュリティ関連のマネージドサービスを始めとして、前回のホワイトペーパー公開後に追加された各AWSサービスの内容を追加しています。 ■AWS Well-Architected 個別相談会のご案内 お客様は、ベストプラクティスに沿っているかの質問と回答(ホワイトペーパーの付録部分が該当します)を用いて、ご自身のシステムをセルフレビューいただけます。もし改善方法でお悩みであったり、より効率的な解決方法を知りたい場合は、AWSのSAにご相談いただくことも出来ます。是非「AWS Well-Architected 個別技術相談会」にお申込みください。 ■関連資料 AWS Well-Architected フレームワーク ホワイトペーパー(PDF) […]

AWS が最近リリースした Model Server for Apache MXNet (MMS) v1.0 はサービス使用状態を管理するための新しい API を特徴としており、ランタイム中のモデルの動的ロード、レイテンシーの低減、高いスループットを可能にします。本記事では、新機能を詳しくご紹介するとともに、MMS v1.0 のパフォーマンス向上についてご覧いただきます。 Model Server for Apache MXNet (MMS) とは? MMS はモデルサーバーを提供するオープンソースのフレームワークで、スケーラブルなトレーニングおよび推論のための深層学習モデルのタスクを簡略化を目的に設計されました。下図に、MMS のスケーラブルにデプロイしたアーキテクチャの例を示します。 以下は、MMS v1.0 の主要な機能です。 MXNet、Gluon、ONNX ニューラルネットワークモデル対応用途に設計。 モデルアーカイブにパッケージされたカスタムコードを使用して、推論実行パイプラインの各ステップをカスタマイズ。 REST API エンドポイントを含む、軽量かつスケーラブルなサービススタックの事前設定。 ランタイム中のモデルのロード、アンロード、スケーリングを可能にする管理 API の公開。 大規模な推論のためのビルドおよび最適化済みのコンテナイメージ。 リアルタイムのオペレーションメトリクスを使用して、システムおよび API の健全性、パフォーマンス、ロードをモニタリング。 MMS のクイックスタート MMS 1.0 では、Java 8 以上の環境が必須です。サポート対象のプラットフォームごとにインストール方法を以下に示します。 # Ubuntu/Debian ベースのディストリビューション sudo apt-get install openjdk-8-jre # Fedora、Redhat […]

2017 年のサンタローザ火災やハリケーンハーベイのような自然災害は、毎年何百億 USD もの損害賠償をもたらし、住宅所有者の生活において経済的混乱を招きました。保険会社は影響を受けた家屋を評価するために最善を尽くしますが、評価を開始するまでに数週間かかることもあり、それでようやく家屋を修復し保護することができます。 プロパティデータ分析会社である EagleView 社 は、  AWS における ディープラーニング に取り組んでいます。 EagleView 社のデータサイエンスと機械学習の指導者である Shay Strong は、「通常、保険会社は所有物損害の評価のために損害査定人を派遣するが、その地域が浸水したり、アクセスできないために、対応するのに数週間かかる場合があります。「EagleView 社は、衛星、航空写真、無人機の画像を使い、AWS Cloud でディープラーニングを実行し、24時間以内に損害賠償を正確に評価します。住宅所有者に情報を提供し、次の段階へ準備を迅速に行うために、データを大手保険保険会社や小規模な地域の保険会社の両方に提供しています。 多くの場合、この迅速な処理により、損害賠償において数百万 USD を節約することができます。フロリダ州のハリケーンアーマーからの洪水の際、クライアントはこのタイムリーなデータを使用して、防水シートで家屋の一部を覆い、二次的な水害を防ぐことをできるようにしました。 損害査定人による不動産評価の精度と一致させるために、EagleView 社は嵐の影響を受けた地域の多次元空間 (空間、時間、スペクトル) 全てをカバーする豊富な画像セットを使用する必要があります。この課題を解決するため、EagleView 社は米国全土で、120 台以上の航空機を使用して 1 インチ以下の解像度で撮影します。ディープラーニング画像分類器、オブジェクト検出器、およびセマンティックセグメンテーションアーキテクチャを実行するために、画像を小さな画像タイル（しばしば区画固有のタイルまたは一般的な 256×256 TMS タイル）に分解します。各画像タイルは、対応する地理空間および時間座標と関連付けることができ、追加のメタデータとして保持され、学習プロセスおよび推論プロセスを通じて維持されます。推論後、地理空間データを使用してタイルが貼り合わされて、ニューラルネットワーク予測を含む、関心領域の情報を地理登録したマップを形成することができます。予測は、AWS Cloud で管理されている永続ストレージ用のプロパティレベルのデータベースに集約することもできます。 以下の図は、2017 年のハリケーンハーベイ後のテキサス州ロックポートの一部で、EagleView 社のディープラーニングモデルによる損傷予測の精度を示しています。左の画像の緑色の箇所は、人間の分析結果による壊滅的な構造的損傷が発生する土地を示します。右側の画像のピンクの箇所は、モデルが作成したセグメント化した損傷予測です。このデータの場合、モデルは人間の分析と比較してアドレス当たり 96 ％ の精度を持ちます。 「暫定的な前処理能にディープラーニングを使い、アドレスレベルの属性を生成する前に画像が良好であるかどうか (たとえば、曇っていないか、ぼやけていないかなど)、また画像に関心のある適切な土地が含まれているかどうかを見極めます。我々は中間神経網を鎖状につないで、画像を前処理して、土地属性を生成するニューラルネットの効率と精度を向上させています。」と Strong 氏は付け加えています。 EagleView 社は、Apache MXNet フレームワークを使用してディープラーニングモデルを構築しました。モデルは、 AWS 上の Amazon EC2 P2、P3、およびG3 GPU […]

Amazon Translate は、良心的な価格で迅速かつ高品質な翻訳を実現するニューラル機械翻訳サービスです。本日、113 の新言語ペアの提供が開始されます。フランス語からスペイン語など、現在サポートされている言語間を単一の API リクエストで翻訳することができるようになりました。この更新により、サポートされる言語ペアの数が 24 から 137 に拡大されます。サポートされる言語ペアはすべて、最先端のニューラル機械翻訳アルゴリズムに基づいています。このドキュメントページでサポート対象言語ペアの完全なリストをご覧ください。 これまで、X <> Y ペア (X 語と Y 語のどちらも英語以外の言語) を翻訳する場合には、2 つの翻訳コールを順に実行する必要があり、X 語を英語に翻訳した後で、英語の出力を Y 語に翻訳しなければなりませんでした。つまり、実際に必要な翻訳を得るためには、翻訳を 2 度実行しなければならないということです。新しい拡大によって、この余分なステップが取り除かれると共に、X <> Y 翻訳のコストが実質上 50 パーセント削減され、翻訳が迅速化されます。 パリに拠点を置くスタートアップ企業、Clevy は、従業員からのよくある質問に自動的に返答するチャットボットを組織が作成、デプロイ、および維持することを可能にするプラットフォームを提供しています。これらの質問は、HR、IT サポート、および変更管理など、社内における事柄である場合がほとんどです。そのボットを通じて、Clevy は世界各国 100 万人を超える従業員にサービスを提供しています。Clevy は、このチャットボットを多言語対応とするために、その背景で Amazon Translate を使用しています。ボットは単一の言語で作成されますが、ユーザーは現在、10 もの他言語で質問することができます。質問が来ると、Clevy は Amazon Comprehend を使ってソース言語を検知します。次に、Clevy は Amazon Translate を使って質問をボットの言語に翻訳し、それを Clevy 独自の自然言語処理 (NLP) アルゴリズムで処理できるようにします。最後に、ユーザーに対して、ユーザーの元の言語で回答が返されます。例えば、英語でボットを作成する顧客は、世界各国の従業員が 10 の他言語で質問し、回答を得ることがきるようにすることもできます。 そのボットに多言語処理を追加することは、Clevy […]