Amazon Web Services ブログ

ユーザーとその同僚がモバイルデバイスを使用して社内ウェブサイトとアプリケーションに容易にアクセスできるようにします。当社の目標は、ワークフォースに貴重なインターネットコンテンツへの制御されたアクセスを提供する一方で、強力なセキュリティプロファイルを維持することです。 Amazon WorkLinkを紹介 今回は、Amazon WorkLink について説明したいと考えています。コンテンツを修正したり、移行する必要なく、社内ウェブサイトとアプリケーションにシームレスなアクセスが得られます。Amazon WorkLink は完全に管理された従量制のサービスで、組織のニーズに合わせてスケール自在です。セットアップと実行が容易で、既存のサイトやコンテンツを移行したり、修正したりする必要はありません。モバイルデバイスからアクセス可能なドメインに対して完全なコントロールを取得し、ユーザーベースを管理するために、既存の SAML ベースのアイデンティティプロバイダー (IdP) を使用できます。 Amazon WorkLink は、Virtual Private Cloud (VPC) を通じて社内リソースにアクセスできます。リソースは、その VPC 内 (たとえば、EC2 インスタンスでホストされるアプリケーション)、それとピアリングする別の VPC 内、またオンプレミスに存在することができます。オンプレミスの場合、リソースは IPsec トンネル、AWS Direct Connect、または新しい AWS Transit Gateway 経由でアクセスできなければりません。VPC で実行中のアプリケーションは、AWS ネットワークのすべてのトラフィックを維持しながら、AWS PrivateLink を使用して AWS サービスにアクセスできます。 お客様のユーザーはセキュアで、非侵襲的な閲覧経験が得られます。法人のコンテンツは AWS クラウド 内でレンダリングされ、セキュアな接続を通じて各デバイスに配信されます。今後数週間以内に iOS 12 を実行するデバイスのサポートを、Androind 6+ のサポートで開始します。 Amazon WorkLink の内部 Amazon WorkLink は、作成する各 WorkLink […]

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 […]

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

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 […]

 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 マネジメントコンソールにサインインしてください。下の「スタックをローンチ」アイコンを右クリックして新規タブで開きます。 […]

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 と […]

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 […]

みなさん、こんにちは。アマゾン ウェブ サービス、プロダクトマーケティング エバンジェリストの亀田です。 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 […]

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

 データベースと各種アプリケーションサーバー間でファイルを転送するための一般的な手法として、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 […]