Amazon Web Services ブログ

EI 対応の TensorFlow 1.12 で利用できる柔軟性のある新型 Python API を使用して、Amazon Elastic Inference で TensorFlow モデルをデプロイする

Amazon Elastic Inference (EI) が、TensorFlow 1.12 の最新バージョンのサポートを開始しました。EI は、新しくなってさらに使いやすくなった Python API 関数である EIPredictor を備え、EI アクセラレーターを使用してTensorFlow モデルをデプロイします。EI で TensorFlow モデルを実行するのに、TensorFlow Serving に代わって、この新しい Python API 関数を推論スクリプト内で使用できるようになりました。EIPredictor では簡単な実験が可能で、EI の有無でのパフォーマンスも比較できます。このブログ記事では、EIPredictor を使用して EI にモデルをデプロイする方法を説明します。 まず、この背景から始めましょう。Amazon Elastic Inference は re:Invent 2018 で発表された新しい機能です。EI は、スタンドアロンの GPU インスタンスを使用するよりも、コスト効果が非常に優れた新しい方法を提供し、深層学習推論ワークロードを高速化します。EI を使用すると、任意の Amazon SageMaker または Amazon EC2 インスタンスタイプにアクセラレーターをアタッチでき、GPU の高速化によってもたらされる低いレイテンシー、高スループットといった利点を、極めて低いコスト (最大75%) で実現できます。EI では、TensorFlow、Apache MXNet、および ONNX モデルをデプロイし、推論を実行できます。 TensorFlow Serving を使用して、EI […]

Read More

Amazon RDS for MySQL のパラメータ設定 パート 1: パフォーマンス関連のパラメータ

この記事では、RDS for MySQL インスタンスからベストパフォーマンスを引き出すために留意すべき最重要のパラメータを扱います。これらを調整して、ワークロードに適合させ、ベストプラクティスにも合致させることができます。

Read More

Amazon Comprehend Medicalで、極秘ヘルスケアデータを識別し、それを扱い作業する

AWSで、私は定期的にAWSのお客様およびAWS パートナーネットワーク (APN) のパートナー様と、人間の健康の形を変えるためにどのように技術を使っていらっしゃるかについてお話します。これらの企業はしばしば人間健康管理および電子健康記録のような様々なアプリケーションで使用する大量の健康データを生成します。 開発者は保護健康情報 (PHI)のような極秘データに関するコンプライアンス義務に準拠しながら、これらのアプリケーションで価値のある医療情報を使用する方法を見つける必要があります。当社のお客様およびAPNパートナー様がこれを今日行っている一部のアプリケーションは、臨床決定サポート、収益循環管理、および臨床試験管理です。 データをマスクするために複数の方法があり、各組織が内部リスク査定にも続く独自のアプローチを有しています。当社はお客様が組織の特定の実装手順について、リスク査定専門家に相談されることを推奨します。一般的に、データは2つの手順でマスクされます。一つ目として、PHIが識別されなければなりません。その後、通常安全ルールまたは専門家の判断によって、データを匿名化する、または非識別するアルゴリズムが使用されます。このアプローチは一時的に自身に状態マシンを使用させ、お客様の組織が各手順で独立的に必要とする事業論理を適用し、状態間で情報を渡します。 このブログ投稿で、私はどのようにAmazon Comprehend Medical、AWS Step Functions, および Amazon DynamoDBの組み合わせを使用して、極秘健康データを識別し、お客様のコンプライアンス目標をサポートするお手伝いをするかを実証します。私はその後、お客様がしばしば採用するパターンであるアーキテクチャーの、見込まれる拡張のいくつかを論じます。 アーキテクチャ このアーキテクチャは以下のサービスを使用します: 文字列体内のエンティティを識別するためのAmazon Comprehend Medical ワークフローを調整および実行するためのAWS Step FunctionsおよびAWS Lambda 再識別されたマッピングを保存するAmazon DynamoDB このアーキテクチャーおよび後続のコードはAWS CloudFormationテンプレートとして利用できます。 個別の構成要素 AWS上で構築された多くの近代的なアプリケーションのように、アーキテクチャー内の個別の構成要素はLambda関数として表されます。このブログ投稿で、私は3つのLambda関数を構築する方法をお見せします。 IdentifyPHI:Amazon Comprehend Medical APIを使用して、文字列体からカルテのようなPHIエンティティを検出および識別します。 MaskEntities:IdentifyPHIから入力としてエンティティを取り、文字列体でそれらをマスクします。 DeidentifyEntities: IdentifyPHIからエンティティを取り、各エンティティにハッシュを付け、そのマッピングをDynamoDBに保存します。 それぞれを通して順番に見てゆきましょう。 PHIを識別する 以下のコードはJSON体で読み込み、メッセージからPHIエンティティを抽出して、抽出されたエンティティのリストを返します。 from botocore.vendored import requests import json import boto3 import logging import threading comprehend = boto3.client(service_name=’comprehendmedical’) def […]

Read More

Amazon Comprehend Medicalを用いた臨床実体の抽出及び可視化

 Amazon Comprehend Medicalは機械学習(ML)を用いて高精度で医療情報を抽出する、HIPAAの対象となっている新サービスです。これは大量の構造化されていない医療テキストを処理するためのコスト、時間、手間を低減します。薬、診断、投与量のような実体や関係を抽出することができ、またPHI(保護医療情報)も抽出することができます。Amazon Comprehend Medicalを利用することで、エンドユーザーは解析が困難な為ほとんど解析目的で利用されることのない生の臨床メモから価値を得ることが可能になります。これらのメモから情報を抽出して電子カルテ(EHR)や治験管理システム(CTMS)のような他の医療システムと統合することには計り知れない価値が存在します。本来なら廃棄されるような生のメモにある情報を考慮することで長期的な患者への視点の生成を可能にします。 他の全ての当社APIレベルサービスと同様、Amazon Comprehend Medicalの焦点は開発者にとっての使い勝手です。当社はAPIコールを利用することで、あるいはコンソールで呼び出すことができる事前訓練済みモデルを提供します。結果は、解析可能かつ他の構造臨床データセットとの統合が可能な、構造化されたJSONファイルとして返されますAmazon Comprehend Medicalについてもっと詳しく知るには、プロダクトマニュアルをご覧ください。 こちらの例では、Amazon Comprehend Medicalを使用してどのように臨床実体を抽出、Kibanaダッシュボード上で視覚化できるかをお見せします。このソリューションはAWS CloudFormationテンプレートとして提供されているのでご自身の環境で簡単にデプロイが可能です。 ソリューションのアーキテクチャ 本アーキテクチャ図はソリューションの様々なコンポーネントをショーケースしています。以下は各コンポーネントの詳細です: あなたの生の臨床メモを格納するためAmazon S3をプラットフォームとして使用することができます。 Amazon Comprehend Medical APIを利用して、メモをループスルーして様々な臨床実体や関係をメモから抽出しましょう。また抽出された要素をフィルタリングして、メモからPHI(保護医療情報)を除外することもできます。これは下流分析でメモ内の識別不可能な要素を必要とするユースケースにおいて有用です。 抽出された実体を含むJSONファイルは解析されAmazon DynamoDBテーブルに挿入されます。このテーブルは経時的な全臨床実体のリポジトリとして機能し開発者によって下流統合のため利用されることができます。 DynamoDBテーブルはストリームが接続しています。このストリームはストリーム上のイベントによってトリガーされたAWS Lambda関数を利用して解析されます。 Lambda関数はAmazon Elasticsearch Service (Amazon ES)ドメインにレコードを挿入します。このドメインは全臨床実体情報によって最新の状態を維持することができます。 臨床実体を可視化するためKibanaダッシュボードがAmazon ESの上に構築されています。これはメモに関する分析情報及び検索機能を求めるエンドユーザー向けエントリポイントとして機能します。 ソリューションのデプロイに関する說明 ここではソリューションのデプロイのためAWS CloudFormationスタックを利用します。CloudFormationスタックは本ソリューションによって必要となるリソースを作成します。次が含まれます: S3 バケット DynamoDB テーブル Lambda 関数 必要なAWS Identity and Access Management (IAM) のロール この例では、us-east-1 (バージニア北部)のAWS リージョンを使用します。 IAMのユーザー名とパスワードを使って、AWS マネジメントコンソールにサインインしてください。下の「スタックをローンチ」アイコンを右クリックして新規タブで開きます。 […]

Read More

新機能 – Network Load Balancer の TLS 終端

HTTPS プロトコルを使用してウェブサイトにアクセスすると、安全な通信チャネルを作成および維持するために、(正式には SSL/TLS ハンドシェイクとして知られている)興味深い作業が多く発生します。クライアント(ブラウザ)とウェブサーバーは、暗号に関してお互いの同意を得るために交渉し、キーを交換し、そしてセッションキーを設定するために協力します。確立されると、会話の両端にセッションキーを使用して、それ以降のトラフィックをすべて暗号化および復号化します。セッションキーはクライアントとサーバー間の会話固有のものであるため、第三者がトラフィックを復号化したり会話を妨害したりすることはできません。 新しい TLS の終端処理 今日は、Network Load Balancer で終端される TLS (Transport Layer Security) 接続を利用できるようにすることで、安全なウェブアプリケーションを構築するプロセスを簡略化しています(TLS は HTTPSで「S」を提供すると考えることができます)。これにより、バックエンドのサーバーは、トラフィックをすべて暗号化および復号化するコンピューティング集約型の作業から解放されます。また、その他にも多くの機能や利点を備えています。 ソース IP 保持 – NLB で TLS が終端されている場合でも、ソース IP アドレスとポートはバックエンドサーバーに提示されます。これは、同僚の Colm が言うように、「非常識な魔法」に近いです。 管理の簡素化 – 大規模の TLS を使用するということは、サーバー証明書を各バックエンドのサーバーに配布する責任があることを意味します。これにより、(場合によっては大量のプロキシサーバーを含む)余分な管理作業が発生し、また証明書のコピーが複数存在するため、攻撃対象領域が増大します。今日の発表は、複雑さをすべて取り除き、証明書の中央管理を可能にします。AWS Certificate Manager (ACM) を使用している場合、証明書は安全に保管され、定期的に期限切れとローテーションを管理し、何もしなくても自動的に更新されます。 ゼロデイパッチ – TLS プロトコルは複雑で、新たな脅威に対応するために実装が随時更新されます。NLB で接続を終端すると、バックエンドのサーバーが保護され、これらの脅威に対応する NLB を更新できるようになります。セキュリティを重視し、正式に検証された TLS/SSL プロトコルの実装である s2n を利用します。 コンプライアンスの向上 – 組み込みセキュリティポリシーを使用して、アプリケーションに適した暗号スイートとプロトコルバージョンを指定できます。これはお使いの PCI と […]

Read More
keras-logo

Amazon SageMaker で簡単に Keras を使う方法

Amazon SageMaker は、すべての開発者とデータサイエンティストに機械学習モデルの構築、トレーニング、デプロイの手段を提供する AWS のマネージドサービスです。SageMaker は深層学習の主要なフレームワークをサポートしており、TensorFlow、Apache MXNet、PyTorch、Chainer などを用いてモデルを記述することができます。また、TensorFlow や MXNet をバックエンドとした Keras の高レベルな API を用いることで、モデルを簡単にすばやく作成することもできます。 これまで、Keras で書いたコードを SageMaker 上で動かす方法について、多くのお客様からご質問を頂いておりました。2018年12月に、SageMaker の TensorFlow ならびに MXNet のコンテナに、それぞれのフレームワークをバックエンドとする Keras がデフォルトでインストールされました。また両コンテナでは Script Mode をサポートしているため、SageMaker 外で開発した Keras のコードに、わずかな修正を加えるだけで動かすことができるようになりました。ここでは Keras 公式サンプルコードの mnist_cnn.py をなるべくそのまま利用して、SageMakerのTensorFlowとMXNetコンテナで実行する方法をご説明します。   TensorFlow Backend での Keras の使い方 トレーニングスクリプトの修正 AWS のマネージドコンソールから SageMaker ノートブックインスタンス (Jupyter/JupyterLab) を開き、Keras のリポジトリをクローンします (このブログのようにノートブックインスタンスの作成時に関連付けることも可能です)。keras/examples/mnist_cnn.py の中で以下の3点を修正します: 学習からモデルの保存までを train(args) 関数として定義します。ここでは次の手順で読み込む args […]

Read More

Amazon Neptune が東京リージョンに対応しました。

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング エバンジェリストの亀田です。 Amazon Neptune が東京リージョンに対応しましたのでご報告します。 Amazon Neptuneはフルマネージド型のグラフデータベースです。グラフデータは例えば以下の図のような、高密度に結合したリレーショナルデータのことを指します。 このようなデータを通常のリレーショナルデータベースに格納するためのテーブル設計はそれほど難しいものではありません。一方一度テーブルに格納された上記のデータをSQLを駆使しSelectを行い上記の図を復元することを考えた場合、そのSQL実行コストは大きいものになります。グラフデータベースである、Neptuneはあらかじめこれらのデータの取り扱いに特化した機能を有しおり、ACID属性が備わっています。 数十億のリレーションシップの保存とミリ秒台のレイテンシーでのグラフのクエリに最適化され、一般的なグラフモデルである Property Graph と W3C の RDF、それぞれのクエリ言語である Apache TinkerPop Gremlin と SPARQL がサポートされています。 また、可用性は99.99%を上回るよう設計されており、リードレプリカ、ポイントインタイムリカバリ、Amazon S3 への継続的なバックアップ、およびアベイラビリティーゾーン間のレプリケーション機能などがフルマネージドサービスとしてあらかじめ備わっており、ユーザーは開発に集中することができます。データ暗号化機能も AWS Key Management Service (KMS)  との連携によりサポートされ高いセキュリティを実現できます。 レコメンデーション機能も備わっており、以下のようなデータから、新しいデータの相関を抽出することが可能です。 さらに、個人の E メールアドレスに関連付けられた複数の人物、同じ IP アドレスを共有しているが別々の住所に住んでいる複数の人物など、リレーションシップパターンを簡単に検出するグラフクエリを構築することにより、不正検出の実装などに役出ることもできます。 この Amazon Neptune はソーシャルの相関図以外にも多くの用途があります。例えば以下のようなネットワークのログなどから以下のようなデータ相関を作成し、異常なイベントの発生時にその影響範囲の特定に役立てることができます。そして、例えば、ホストで悪意のあるファイルを検出した場合、Neptune では、悪意のあるファイルを広めたホスト間の接続を特定し、その接続をたどってそのファイルをダウンロードした元のホストを突き止めることができます。   Amazon Neptuneの利用には Gremlin か SPARQL のクライアントが必要となります。 https://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/intro.html のユーザーガイドを見て設定してみてください。 20180703 AWS Black Belt […]

Read More

Amazon DynamoDB が、7 歳の誕生日!

7 年前の今日、AWS の CTO であった Werner Vogels が Amazon DynamoDB のリリースを発表しました。そこで、2018 年と 2017 年の「最新情報」の記事を振り返って、DynamoDB の最近の成長を示すのもおもしろいだろうと考えました。こうした記事は、トランザクション、オンデマンドキャパシティモード、ポイントインタイムリカバリ、グローバルテーブル、バックアップとリストア、Auto Scaling など、さまざまな機能リリースをすべて説明しています。

Read More

Amazon RDS for Oracle における UTL_FILE 問題の解決

 データベースと各種アプリケーションサーバー間でファイルを転送するための一般的な手法として、Oracle の機能である UTL_FILE があります。UTL_FILEを使うと、クライアントサーバーが POSIX 対応のディレクトリにファイルをコピーし、その後そこからファイルを読み取ることを可能にします。さらに、データベースが PL/SQL ルーチンを使用して、これらの同じファイルに対する読み取りと書き込みを行うことも可能にします。 しかし Amazon RDS 上のOracle Databaseへの移動時には、UTL_FILEを用いたファイル転送において問題が生じます。データベースはサーバ上のファイルの読み取りと書き込みを実行できるのですが、これらのディレクトリは外部システムに公開されていないため、外部システムはそれらにアクセスできません。この問題は、多くの組織にとって Amazon RDS for Oracle を導入する妨げとなっています。 このブログ記事では、この問題を解決するプロセスについて順を追って説明していきます。このプロセスは、Oracle PL/SQL ルーチンを使用して Amazon S3 バケットに Oracle RDS インスタンスを統合することによって問題を解決します。こうすることで、現在 UTL_FILE によって提供されている機能性に似た外部ファイル転送メカニズムが提供されます。 このブログ記事では、Amazon RDS for Oracle インスタンスの変更プロセスのみを取り上げます。追加の参照情報は、以下のドキュメントトピックで見つけることができます。これらは、RDS for Oracle インスタンスを作成して、そのインスタンスにアクセスするためのプロセスを説明しています。 Amazon RDS のセットアップ Amazon RDS の使用開始 Oracle DB インスタンスを作成して Oracle DB インスタンス上のデータベースに接続する また、以下のドキュメントトピックにも追加の参照情報があります。これらには、このプロセスをテストするための S3 バケットの作成プロセスが説明されています。 Amazon Simple […]

Read More

弊社のデータレイク物語:Woot.comはどのようにしてAWS上でサーバーレスデータレイクを構築したか

この投稿では、当社が受け継いできた関係データベース上に構築されたデータウェアハウスの代替としての、cloud-nativeデータウェアハウスの設計についてお話します。 設計過程のはじめで、最も簡単に見える単純なソリューションは、関係データベースから他のものへのリフト&シフトマイグレーションです。しかし、当社は一歩戻り、まずはデータウェアハウスで何が本当に必要とされているかに焦点を当てることに決めました。当社はどのようにして、正しいツールを適した業務に使用することにより、従来のオラクルデータベースをより小さなマイクロサービスに分離できるかに着目し始めました。当社の方法はAWSツールを使用するだけではありませんでした。さらに、それはcloud-native技術を使用して当社を最終状態に持っていくためにマインドシフトすることでした。 このマイグレーションには既存データもマイグレートさせながら新規のデータを流入させるために、新規の抽出、変換、ロード(ETL)パイプラインが必要でした。このマイグレーションのため、AWS Glueに統合されることにより、当社は多くのサーバーを除去し、完全にサーバーレスのデータウェアハウスに移行することができました。 このブログ投稿で、当社は以下をご覧に入れます: 当社がデータウェアハウスのためにサーバーレスデータレイクを選択した理由。 Woot’sシステムのアーキテクチャー図。 マイグレーションプロジェクトの概要。 当社のマイグレーションの結果。 アーキテクチャーおよび設計の関係 こちらは当社が考慮した設計重点の一部です: 顧客体験。当社は常にお客様が必要とすることから始め、そこから戻るように業務を行いました。当社のデータウェアハウスは様々なレベルの技術専門性を持った人々による事業を渡って使用されます。 当社は異なるタイプのユーザーが運用の中に識見を持つ能力に焦点を当て、全体的な顧客体験を向上させるために、より良いフィードバックメカニズムを提供します。 最小限のインフラストラクチャーメンテナンス。「Wootデータウェアハウスチーム」は本当にたった一人の人です-Chaya! このため、当社がcloud-native技術を使用することができるAWSサービスに集中することは当社にとって重要です。これらは需要が変化し、技術が進化するにつれ、未分化性のインフラストラクチャーの管理といった困難な仕事を取り除きます。 データソースの変化に対する応答性。当社のデータウェアハウスは内部サービスの範囲からデータを取得します。弊社の既存のウェアハウスでは、これらのサービスへのいずれの更新でETL業務および諸表で手動による更新が必要でした。これらのデータソースのための応答時間は当社の主要関係者にとって重大なことです。このために当社は高性能アーキテクチャーの選択に向けたデータ主動のアプローチが必要でした。 生産システムからの分離。当社の生産システムへのアクセスは固く結びついています。複数のユーザーを許容するため、当社はそれを生産システムから分離し、複数のVPCsでのリソースをナビゲートすることの複雑さを最小化する必要がありました。 これらの要件に基づき、当社は運営面およびアーキテクチャーの面の両方で、データウェアハウスを変更することを決定しました。運営の観点から、当社はデータ摂取の目的で新規の共有応答モデルを設計しました。アーキテクチャーの面で、当社は従来の関係データベースに代わってサーバーレスモデルを選択しました。これら2つの決定は、当社がマイグレーションで行った、すべての設計および実装の決定を動かすこととなりました。 当社が共有応答性モデルに移行するにあたって、複数の重要な点が浮上しました。第一に、当社のデータ摂取の新しい方法はWootの技術組織にとっては主要な文化シフトでした。過去に、データ摂取は専らデータウェアハウスチームの担当で、サービスからデータを引っ張るためにカスタム化されたパイプラインが必要でした。当社は「押し、引かない」にシフトしました:サーバーがデータウェアハウスにデータを送信するべきである。 これが共有責任が行き着いたところでした。初めて、当社の開発チームがデータウェアハウスのサービスデータ全体の所有権を持ちました。しかし、当社は開発者にミニデータエンジニアになってほしくありませんでした。代わりに、当社はデータをプッシュするために、彼らに開発者の既存のスキルセットに適合する簡単な方法を示しました。データは当社のウェブサイトで使用される技術の範囲でアクセス可能である必要がありました。 これらの検討されたことは当社をサーバーレスデータウェアハウス向けの、以下のAWSサービスを選択することに導きました。 データ摂取用Amazon Kinesis Data Firehose データ保存用Amazon S3 データ処理用AWS Lambda および AWS Glue AWS データマイグレーションサービス (AWS DMS) および データマイグレーション用AWS Glue 統合およびメタデータ管理用AWS Glue クエリおよびデータ視覚化用 Amazon Athena および Amazon QuickSight 以下のデータグラムは当社がどのようにこれらのサービスを使用するかをハイレベルで示します。 トレードオフ これらの構成要素は共に当社のすべての要件を満たし、共有責任モデルを実行可能にしました。しかし、当社はリフト&シフトマイグレーションをもう一つの関係データベースと比較し、数回のトレードオフを行いました。 最大のトレードオフは先行投資の努力対進行中のメンテナンスでした。当社はすべてのデータパイプラインをもって効果的に白紙の状態から開始し、新しい技術を当社のすべてのウェブサイトサービスに導入しました。これには複数のチームを渡り協力的な努力が必要となりました。最小限の現行メンテナンスは核心要件でした。当社が使用するサーバーレスコンポーネントの管理されたインフラストラクチャーの優位点を利用するために、当社は快くこのトレードオフを行いました。 もう一つのトレードオフは非技術ユーザー対ビッグデータテクノロジーを利用することの有用性のバランスを取ることでした。顧客体験を核心要件にすることは、当社がこれらのトレードオフを検討するときに、意思決定を導くのを助けました。最終的には、他の関係データベースへの切り替えは、当社のお客様が同じ体験をするだけで、より良い体験をするわけではなかったのです。 Kinesis Data Firehose および […]

Read More