Amazon Web Services ブログ

AWS テクノロジーを使用して臨床試験の成果を改善する

  私たちはイノベーションの黄金時代に生きています。今では、個別化された医療によって、私たちが絶対に治癒できないと考えていた病気さえも治療できるようになりました。デジタル医療は、病気を抱えている人々がより健康になれるように手助けしています。私たちは、癌細胞を標的として根絶するために体の免疫システムを活用する方法をずっと探しています。ClinicalTrials.gov の報告によると、登録された研究は 2018 年に 293,000 件に達し、2000 年以来 250 倍の成長を遂げたことを表しています。 しかし、EvaluatePharma のデータを使用した Endpoints News の内部収益率 (IRR) の分析では、いくつか興味深い傾向が強調されています。製薬イノベーションが活気づいている現状は、登録された研究が大幅に成長したことによってサポートされています。しかし、IRR は 2000 年の約 17% から 2017 年の資本コストを下回るまで急激に減少する傾向を示しており、2020 年には 0% になると予測されています。 このブログ記事は、コンプライアンスに準拠した安全な方法で臨床試験データを収集、保存、処理、視覚化、そして実行するためのエンドツーエンドのワークフローに焦点を当てたシリーズの最初の記事です。このシリーズでは、また、人工知能と機械学習テクノロジーを臨床試験へ取り組んだアプリケーションについても説明します。この記事では、AWS のお客様が臨床試験を近代化するために使用する一般的なアーキテクチャパターンについて説明します。これらには、より良いエビデンス生成、コスト削減、品質の向上、アクセスの改善、および患者に向けて個人化された医療のモバイルテクノロジーが組み込まれています。 臨床試験の結果を改善し、コストを削減する バイオテクノロジーおよび製薬会社は、可能な限りリソースを効率的に使用することに対してプレッシャーを感じています。このプレッシャーにより、コストを削減しながら、プロセスを合理化し、高速化し、安全性を維持するためのあらゆる条件が求められます。ますます多くのライフサイエンス企業がバイオロジクス、CAR-T、および精密医療治療薬をターゲットにしており、より小さく、地理的に分散した患者セグメントに焦点が移っています。この変化により、これまで利用できなかった、非伝統的な情報源からデータを収集するという義務が増しています。これらの情報源には、モバイルデバイス、IoT デバイス、そして家庭用および臨床用デバイスが含まれます。ライフサイエンス企業は、これらの情報源から得たデータを従来の臨床試験データとマージして、薬の安全性と有効性に関する強力なエビデンスを構築します。 昨年の初めに、臨床試験改革イニシアチブ (CTTI) は、患者から総合的で高品質かつ帰属可能な実世界のデータを取得し、米国に提出するためのモバイルテクノロジーの使用に関する推奨事項を提供しました。食品医薬品局 (FDA)。モバイルテクノロジーを使用することで、ライフサイエンス企業は臨床試験への参加障壁を減らし、臨床試験の実施に伴うコストを削減できます。FDA、カナダ保健省、および英国医薬品庁 (MHRA) など、世界的な規制団体も、モバイルテクノロジーの使用を支持しています。モバイルテクノロジーによって、より効率的に患者を募集し、より早くエンドポイントに到達し、臨床試験を実施するために必要な費用と時間を削減することができます。 モバイルテクノロジーを使用して即席にデータを取り込むと、結果にすばやく到達し、コストを削減して、臨床試験の精度を向上させることができます。これは、特にモバイルデータの取り込みに人工知能および機械学習 (AI/ML) テクノロジーが追加されている場合に特に当てはまります。 それと共に、スマート臨床試験の新しい時代を迎えることができます。 同時に、市販されている超大型新薬に向けて設計された従来の臨床試験プロセスやテクノロジーは、新興産業のニーズを効果的に満たすことができません。このため、ライフサイエンス企業や製薬会社は、臨床試験の運用を進化させるための支援を必要としています。これらの事情により、臨床試験は新薬を市場に出すための最大の投資分野の 1 つになりました。 臨床試験でモバイルテクノロジーを従来のテクノロジーと併用すると、臨床試験の結果が改善され、同時にコストが削減されます。さまざまなテクノロジーの統合によって利用できるユースケースには、次のものがあります。 臨床試験における参加者の特定と追跡 臨床試験で募集する参加者の特定 臨床試験に参加している患者の教育と通知 標準化されたプロトコルの実装および臨床試験の参加者に関連情報を共有 有害事象と安全性プロファイルの追跡 新規バイオマーカーを特定するためのゲノムデータと表現型データの統合 臨床試験の管理をより良くするための臨床試験へのモバイルデータの統合 履歴データに基づいた患者コントロールアームの作成 治療、クレーム、およびレジストリデータセットに基づくコホートの階層化 […]

Read More

Serverless Tech/事例セミナー(2019年3月27日 実施) レポート Vol.1

「AWS re:Invent 2018」では多くのサーバーレス関連のアナウンスがありました。その中でも、Ruby や COBOL を始めとする開発言語対応の拡張やカスタムランタイム、共有ライブラリ管理機能(Layers)は、サーバーレスの成熟と広がりを感じさせるものでした。特に、日本で利用者の多い Ruby は長い間望まれていたことから、プロジェクトでの適用が急速に進みはじめています。 そこで、すでに利用し始めていただいているお客様として、ヴァル研究所様およびSansan様に2019年3月27日に実施のServerless Tech/事例セミナーで登壇いただき、その経験を共有いただきました。開発言語としてのRubyに対する熱い想いやモチベーションが伝わる講演内容でした。また、これからサーバーレスを検討される参加者のために、従来型開発との考え方の違いを、開発の観点からクラスメソッド様より説明がありました。 Vol.1 : 手段先行でも悪くはない!Ruby on LambdaではじめるServerless [本記事] Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     手段先行でも悪くはない!Ruby on LambdaではじめるServerless [資料はこちら] 株式会社ヴァル研究所 マーケティングテクノロジー部 CB開発チーム 福本江梨奈氏

Read More

Amazon EMR で Apache Spark アプリケーションのメモリをうまく管理するためのベストプラクティス

ビッグデータの世界における一般的なユースケースは、さまざまなデータソースからの大量のデータにおける抽出/変換 (ET) とデータ分析の実行です。多くの場合、この後でデータを分析してインサイトを取得します。このような大量のデータを処理するための最も人気のあるクラウドベースソリューションのひとつが Amazon EMR です。 Amazon EMR は、AWS での Apache Hadoop および Apache Spark などのビッグデータフレームワークの実行をシンプル化するマネージドクラスタープラットフォームです。Amazon EMR は、組織が複数のインスタンスを持つクラスターをほんの数分でスピンアップすることを可能にします。また、並列処理を使ってさまざまなデータエンジニアリングとビジネスインテリジェンスのワークロードを処理できるようにもしてくれます。こうすることで、クラスターの確立とスケーリングに関わるデータ処理の時間、工数、およびコストを大幅に削減することができます。 Apache Spark は、オープンソースで高速な汎用目的のクラスターコンピューティングソフトウェアで、ビッグデータの分散処理で広く利用されています。Apache Spark は、タスクの I/O と実行時間を削減するためにノード全体のメモリで並行コンピューティングを実行することから、クラスターメモリ (RAM) に大きく依存しています。 一般に、Amazon EMR で Spark アプリケーションを実行するときは、以下の手順を実行します。 Spark アプリケーションパッケージを Amazon S3 にアップロードする。 設定済みの Apache Spark で Amazon EMR クラスターを設定し、起動する。 Amazon S3 からクラスターにアプリケーションパッケージをインストールし、アプリケーションを実行する。 アプリケーションが完了したら、クラスターを終了する。 Spark アプリケーションを成功させるには、データと処理の要件に基づいて Spark アプリケーションを適切に設定することが大切です。デフォルト設定では Spark が利用できるクラスターのリソースのすべてを使用しない場合があり、物理メモリまたは仮想メモリの問題、あるいはその両方が発生する可能性があります。Stackoverflow.com では、この特定のトピックに関連する何千もの質問が提起されています。 […]

Read More

Amazon Aurora MySQL データベース設定のベストプラクティス

AWS クラウドで新しい Amazon Aurora MySQL インスタンスを移行または起動した後、以下の質問のうち 1 つ以上を自問したことはありますか? 「次のステップは? どうすれば、最適に動作させることができるでしょうか?」 「既存のパラメータを変更する方が良いでしょうか?」 「どのパラメータを変更すれば良いでしょうか?」 自問したことがあるなら、何をすべきか(そして、何をすべきでないか)について、このブログ記事がガイダンスを提供できることを願っています。 この記事では、MySQL との互換性を持つ Amazon Aurora の設定パラメータについて説明、明確化し、推奨事項を提供します。こうしたデータベースパラメータとその値は、AWS クラウドで新しく作成または移行されたインスタンスの引き継ぎ、チューニング、再設定を行う場合に重要です。また、Amazon RDS for MySQL インスタンスから Aurora インスタンスに引き継がれるパラメータについても説明します。どの値がデフォルト値であり、どの値がインスタンスの安定性や最適なパフォーマンスにとって重要であるかを説明します。 変更を行う前の最も重要な考慮事項は、変更の背後にあるニーズや動機を理解することです。 ほとんどのパラメータ設定はデフォルト値で問題ありませんが、アプリケーションのワークロードの変化によりこうしたパラメータの調整が必要になる場合があります。変更を行う前に、以下の質問を自問してください。 再起動やフェイルオーバーなどの安定性の問題がありますか? アプリケーションでクエリをより高速に実行できますか? Aurora パラメータグループの初歩 Aurora MySQL パラメータグループには、DB パラメータグループと DB クラスターパラメータグループの 2 種類があります。バイナリログ形式、タイムゾーン、文字セットのデフォルトなど、一部のパラメータは DB クラスター全体の設定に影響を与えます。他のパラメータは、その範囲が単一の DB インスタンスに限定されます。 このブログ記事では、Aurora クラスターの動作、安定性、機能性に影響を与えるパラメータと、変更するとパフォーマンスに影響を与えるパラメータに分類して説明します。 どちらのタイプのパラメータも出荷時に事前にデフォルト設定されており、一部のパラメータでは変更が可能です。 パラメータグループの変更や操作の基本について、最新の情報をより深く理解するには、Aurora ユーザーガイドの以下のトピックを参照してください。 DB パラメータグループおよび DB クラスターパラメータグループを使用する Aurora MySQL パラメータ 本稼働データベースを変更する前に […]

Read More

【開催報告】AWSセミナー マイグレーション事例祭

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 4月9日に、「AWS セミナー マイグレーション事例祭」を開催いたしました。株式会社グリー 様、株式会社CyberZ様、株式会社マッチングエージェント様、ニフティ株式会社様をゲストにマイグレーションを進める上で良かった点や苦労した点、クラウド化したことによる効果、また今後クラウドで実現したいことなどに関して語っていだきました。130名近くの方にお申込みいただき、開催当日も満足度の高いお声を多くいただきました。 AWS マイグレーション お客様事例紹介 「グリーにおけるAWS移行の必然性」 グリー株式会社 開発本部 インフラストラクチャ部 マネージャー 竹ヶ原 大地 様 [slides] 「分析環境を AWS Athena に移行とその後1年間の運用課題を振り返る」 株式会社CyberZ 開発局 engineer 茂木 高宏 様  [slides] 「 AWS での漸進的なアーキテクチャ変更 at タップル誕生」 株式会社マッチングエージェント  サーバーサイドエンジニア 島谷 宙伸 様 [slides] 「リフト&シフトから始めるレガシー脱却への挑戦~大規模コンテンツ配信サービスの移行実例~」 ニフティ株式会社 WEB 事業部 WEB サービス開発グループシニアエンジニア 伊達 乾 様, 添野 翔太 様 [slides] AWSセッション 「ビジネス基盤をクラウドに移行する際のポイント」 アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 諸岡 賢司, 上原 誠 [slides]   まとめ […]

Read More

EC2 用の Amazon Elastic Inference 設定ツールを使用して、EI アクセラレータを数分で起動する

Amazon Elastic Inference (EI) 設定ツールは、EI をすぐに使い始めることができる Python スクリプトです。 Amazon Elastic Inference を使用すると、低コストの GPU によるアクセラレーションを Amazon EC2 および Amazon SageMaker のインスタンスに適用して、深層学習推論の実行コストを最大 75 パーセント削減することができます。初めてEIを使用する場合は、アマゾン ウェブ サービス (AWS) PrivateLink VPC エンドポイント、IAM ポリシー、セキュリティグループルールなど、設定が必要な依存関係がいくつかあります。この作業を早く行えるように、EI 設定スクリプトを使用すると、必要なリソースを作成することで作業を簡単に始めることができて、EI アクセラレータを数分で起動できるようになります。このブログ記事では、スクリプトの使用方法、スクリプトの機能、実行時に予想されることについて説明します。 高レベルで言うと、このスクリプトは以下のことを行います。 AWS Elastic Inference サービスに接続できるようにする IAM ポリシーを使用して、インスタンスの IAM ロールを作成します。 インスタンスがアクセラレータと通信できるようにするために必要な入力ルールと出力ルールを使用してセキュリティグループを作成します。 目的のサブネット内に AWS PrivateLink VPC エンドポイントを作成します。 選択したオペレーティングシステム用の最新の AWS Deep Learning AMI (DLAMI) を使用して、EI アクセラレータで目的の EC2 インスタンスを起動します。 前提条件 EI を設定するには、以下でリンクされているスクリプトを実行します。以下のエンティティに依存しています。 […]

Read More

Amazon RDS で機密データを保護するためのベストプラクティスの適用

このシリーズの最初の投稿では、AWS のデータストアに適用できる一般的なセキュリティの概念とそれに対応する AWS のセキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。この 2 回目の投稿では、こうした概念を Amazon RDS データベースで実装する方法を説明します。 実装例の多くはすべての RDS データベースエンジンに共通していますが、一部は個々のエンジンの種類によって異なる場合があります。このような場合は、MySQL との互換性を持つ Amazon Aurora の実装例を含めますが、他のデータベースエンジンの情報を入手する場所についても説明します。 それでは、最初の投稿で説明した順序でセキュリティの概念の実装を見ていきましょう。 データの分類とセキュリティゾーンモデリング データの分類とセキュリティゾーンモデリングに関するおさらいとして、以下をご覧ください。ここで提供されているより詳細な説明、およびデータの分類とセキュリティゾーンモデリングの背景にある概念については、このシリーズの最初の投稿を参照してください。 データの分類 この投稿で後述するセキュリティコントロールのどれを適用するかを決定するには、データの分類を理解してください。たとえば、どちらもこの投稿の後半で説明しますが、データのトークン化やセキュリティのマイクロセグメンテーションなど、特殊なセキュリティコントロールは必要ないかもしれません。これらが不要であるケースとしては、データベースにクレジットカード番号や社会保障番号などの機密性の高いデータがない場合があります。 セキュリティゾーンモデリング セキュリティゾーンを設計したら、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。サブネット全体をネットワークフロー制御バリアとして使用できるようにすることをお勧めします。この投稿の後半の「セキュリティグループとネットワーク ACL」セクションで、ネットワーク ACL を使用してセキュリティゾーンを実装する方法を示します。 セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS Answers サイトの AWS 単一 VPC の設計を参照してください。 徹底的な防御 RDS 内での徹底的な防御のためのセキュリティコントロールの詳しい説明に入る前に、この投稿の後半で説明するセキュリティ設定について説明している RDS 起動ウィザードのセクションを見てみましょう。 セキュリティ設定を取得するには、AWS […]

Read More

Okta を ID プロバイダーとして Amazon Redshift へのアクセスとフェデレーションする

データベースのユーザーとアクセスを管理することは、気が遠くなるほど大変でエラーが発生しやすい作業です。これまで、データベース管理者は、ユーザーがどのグループに属しているのか、およびユーザー/グループがどのオブジェクトの使用を許可されているのかを判断する必要がありました。これらのリストはデータベース内で管理されており、社内ディレクトリから簡単に外れる可能性があります。 フェデレーションを使用すると、企業のアイデンティティプロバイダー (IdP) 内のユーザーおよびグループを管理し、それらをログイン時に Amazon Redshift に渡すことができます。前回の記事、「IAM と Amazon Redshift を使用して、データベースユーザー認証を簡単にフェデレーションする」で、Active Directory Federation Service (AD FS) を ID プロバイダーとして使用するフェデレーションワークフローの内部について説明しました。 この記事では、ID プロバイダーとして Okta に焦点を当てます。Okta.com のトライアルアカウントを設定し、組織のディレクトリ内にユーザーとグループを構築し、Amazon Redshift へのシングルサインオン (SSO) を有効にする方法を段階的に説明します。データウェアハウス内でグループレベルのアクセス制御も維持しながら、これらすべてを実行できます。 この記事の手順は、次のセクションで構成されています。 ID プロバイダー (Okta) の設定 – Okta をセットアップします。これには、ユーザーを論理グループにまとめる作業が含まれます。 AWS の設定 – ID プロバイダーと AWS 間の信頼関係を確立するロールと、Okta が Amazon Redshift へのアクセスに使用するロールを設定します。 ID プロバイダー (Okta) の詳細設定 – 作成したロールを入力して Okta の設定を完成させます。また、どのグループを […]

Read More

Amazon SageMaker の因数分解機械アルゴリズムを拡張し、レコメンデーション上位 x 件を予測しています。

Amazon SageMaker により、機械学習ワークロードで複雑なビジネス上の問題に対応するために必要な柔軟性が向上します。組み込みアルゴリズムを使用すると、すぐに開始できます。 このブログ記事では、組み込みの因数分解機アルゴリズムを拡張してレコメンデーション上位 x 件を予測する方法について、概説します。 この手法は、ユーザーに対し一定数のレコメンデーションをバッチ処理で生成する場合に最適です。例えば、この手法を使用して、ユーザーと製品購入に関する大量の情報から、あるユーザーが購入しそうな上位 20 製品を生成することができます。その後、将来的にダッシュボードへの表示やパーソナライズメールマーケティングなどで利用するため、このレコメンデーションをデータベースに保存できます。AWS Batch または AWS Step Functions を使用して、このブログで概説する手順を自動化し、定期的な再トレーニングや予測を行うこともできます。 因数分解機は、汎用教師あり学習アルゴリズムで、分類と回帰の両方のタスクに使用できます。このアルゴリズムは、レコメンデーションシステムのエンジンとして設計されました。このアルゴリズムでは、二次係数を低ランク構造に制限しながら、特徴について二次関数を学習することで協調フィルタリング手法を拡張します。この制限は、過学習を避け、また非常にスケーラブルであるため、大きな疎データによく適してします。これにより、入力特徴が何百万である一般的なレコメンデーションの問題に対するパラメーターが、何兆とあるのではなく、何百万となるようにします。 因数分解機のモデル方程式は、つぎのように定義されます。 次のようなモデルパラメータが推定されます。 ここでは、n は入力サイズ、k は潜在空間のサイズです。これらの推定されるモデルパラメータを使用して、モデルを拡張します。 モデルの拡張 Amazon SageMaker の因数分解機アルゴリズムを使うことにより、ユーザーと項目のようなペアについて、これらが合致する程度に基づき、そのペアのスコアを予測できます。レコメンデーションモデルの適用時、ユーザーを入力すると、そのユーザーの好みに合致する上位 x 件の項目リストを返すようにしたい場合がよくあります。アイテム数が多くなければ、可能性のあるアイテムすべてに対しユーザーと項目のモデルをクエリすることができます。ただし、この手法では項目数が多くなるとうまくスケールできません。このシナリオでは、Amazon SageMaker k 近傍法 (k-NN) アルゴリズムを使用して、上位 x 件の予測タスクを高速化できます。 以下の図は、このブログ記事で扱う手順のおおまかな概要を示しています。これには、因数分解機モデルの構築、モデルデータの再パッケージ化、k-NN モデルのフィッティング、および上位 x 件予測の作成が含まれます。 先に進めるため、手引きとなる Jupyter ノートブック をダウンロードすることもできます。以下の各セクションは、このノートブックのセクションと対応していますので、読みながら各ステップのコードを実行できます。 ステップ 1: 因数分解機モデルの構築 手引きとなる Jupyter ノートブックのパート 1 で、因数分解機モデルの構築手順を確認します。因数分解機モデルの構築に関する詳細は、因数分解機アルゴリズムのドキュメントを参照してください。 ステップ 2: モデルデータの再パッケージ化 Amazon SageMaker 因数分解機アルゴリズムでは、Apache […]

Read More

Amazon DynamoDB: アドテックのユースケースと設計パターン

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。 こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。 完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70% 削減されたと推定しています。 この記事で使用される用語 この記事では、以下のデータモデリングと設計パターンの用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。 アドテックのユースケースと設計パターン ユースケース データモデリングまたは設計パターン RTB および広告ターゲティングでのユーザープロファイルの保存 1:1 モデリング、1:M モデリング […]

Read More