Author: AWS Japan Staff

オーストラリア連邦科学産業研究機構 (Commonwealth Scientific and Industrial Research Organization (CSIRO)) から、重要な新しいゲノム編集技術で AWS が活用されている件について寄稿いただきました。– Jeff 最近の分子工学技術ではゲノム編集を正確に行えるようになりました。この CRISPR-Cas9 という新技術は独自の DNA 配列でパターンマッチングを行い、ゲノム内で特定の場所を識別し編集できるようにプログラムすることが可能です。これは研究者にとってパワフルで新しいツールですが、ゲノム全体にわたりターゲットをスキャンし探すということは、これまでにない大規模なコンピューターの使用が必要であることも意味しています。今年始めにアメリカ国立衛生研究所 (US National Institutes of Health (NIH)) はヒトの健康においてこうした技術の使用を承認しました。これはがん治療に革命を起こす可能性を秘め、計算力においてもスピードが重視されることを意味しています。がん治療の新しいアプローチ およそ 5 人に 1 人はがんにかかるといわれている昨今、がん生存率は 2 倍になったといわれていますが、脾臓がんの場合はその確率が 1 % といったように生存率の低い種類のがんはまだあります。その理由は、主に健康な細胞組織に害を加えずに、がん細胞を消滅させる治療的介入を見つけることが困難だからです。従来とは異なる治療法を開発する上で、NIH が新たにトライアル承認した CRISPR-Cas9 はゲノム編集技術において飛躍的な進歩を可能にします。自然にがんと闘う細胞の特異的修飾により、患者は自分の免疫システムを強化させることができます。特定の血液がんや固形がんまたは黒色腫を患う患者を含む、現在行っている研究で幅広い範囲にわたり、この技術は異なる腫瘍に対し効力を発する可能性を持っています。計算に基づいたゲノムエンジニアリングにおけるクラウドサービスヒトの健康を対象としたこの新しいアプリケーションは、臨床ケアの時間的制約に応えるため CRISPR-Cas9 デザインの堅牢性と効率性を必要としています。AWS クラウドサービスをベースにして eHealth プログラム、オーストラリ連邦科学産業研究機構 (CSIRO) は、この問題に取り組むために新型のソフトウェアツール、GT-Scan2 を開発しました。「他の方法に比べて GT-Scan2 は遺伝子位置を高感度かつ特異性をもって特定することができます」と、トランスフォーメーショナルバイオインフォマティクスチームを率いる Dr. Denis Bauer は語っています。 GT-Scan2 はゲノム位置で特定した CRISPR ターゲットの位置を示し、その高アクティビティや低アクティビティを記述するほか、オフターゲットの可能性も表示します。 […]

Amazon EMR リリース5.1.0 Amazon EMRリリース5.1.0で、Apache Flink 1.1.3と、バージョンアップしたApache Zeppelin(0.6.2)とApache HBase(1.2.3)が利用できるようになりました。また、Hueのinteractive notebookが、Prestoを用いたクエリをサポートしました。 Apache Flinkは、高スループットのデータソースに対して、簡単にリアルタイムストリーム処理を実行できる、ストリーミングデータフローエンジンです。順不同なイベントに対するイベントタイムセマンティクスや、exactly-onceセマンティクス、バックプレッシャー制御、そして、ストリーミングとバッチ処理どちらにも最適化されたAPIを兼ね備えています。さらに、Flinkは、Amazon Kinesis StreamsやApache Kafka、Elasticsearch、Twitter Streaming API、それから、Cassandraへのコネクターを持っており、さらに、Amazon S3(EMRFS経由)やHDFSにアクセスすることもできます。 AWSマネージメントコンソール、AWS CLI、または、SDKから、リリースラベル「emr-5.1.0」を選択して、リリース5.1.0のAmazon EMRクラスターを作成することができます。Flink、Zeppelin、それから、HBaseを指定して、これらのアプリケーションをクラスターにインストールすることができます。リリース5.1.0や、Flink 1.1.3、Zeppelin 0.6.2、HBase 1.2.3についての、より詳細な情報については、Amazon EMRのドキュメントをぜひご確認下さい。(原文) Amazon EMRでApache Flinkを利用する Apache Flinkは、お客様の間でリアルタイムビッグデータアプリケーションを構築するために使われている、並列データ処理エンジンです。Flinkによって、例えばAmazon Kinesis StreamsやApache Cassandraデータベースのような、たくさんの異なるデータソースを変換することができるようになります。バッチとストリーミングどちらのAPIも提供しています。また、Flinkは、これらのストリームやバッチデータセットに対するSQLも、多少サポートしています。多くのFlinkのAPIのアクションは、Apache HadoopやApache Sparkにおける分散オブジェクトコレクションの変換と、非常に類似しています。FlinkのAPIは、DataSetとDataStreamに分類されます。DataSetは、分散データのセットやコレクションの変換ですが、一方で、DataStreamは、Amazon Kinesisに見られるようなストリーミングデータの変換です。 Flinkは、純粋なデータストリーミング実行エンジンです。リアルタイムに以前のデータ変換結果を操作するためのパイプライン並列処理を有しています。つまり、複数の操作を並行して実行できます。Flinkのランタイムは、これらの変換パイプライン間のデータの交換をハンドリングします。また、例えバッチ処理を記述したとしても、同一のFlinkストリーミングデータフローランタイムが、その処理を実行します。 Flinkのランタイムは、2つの異なるタイプのデーモンで構成されています。スケジューリング、チェックポイント、リカバリーといった機能をまとめる責任を担うJobManagerと、アプリケーション内のストリーム間のデータ転送やタスクの実行を担うワーカープロセスであるTaskManagerです。それぞれのアプリケーションは、ひとつのJobManagerと、ひとつ以上のTaskManagerを持ちます。 TaskManagerの数をスケールさせることができますが、同時に「タスクスロット」と呼ばれるものを使って、並列処理をさらに制御しなければなりません。Flink-on-YARNでは、JobManagerは、YARNのApplicationMasterに内包されます。一方で、個々のTaskManagerは、そのアプリケーションのために割り当てられた別々のYARNコンテナに配置されます。 本日(11/3)、Amazon EMRリリース5.1.0でネイティブサポートしたことにより、AWS上でFlinkを実行することが、さらに簡単になりました。EMRがFlink-on-YARNの実行をサポートしたことにより、複数のジョブを受け付けるロングランニングクラスターを作成することも、利用中の料金のみにコストを抑えるために一時的なクラスターでショートランニングのFlinkセッションを作成することも、どちらも可能です。 ロギングや設定パラメータ用の設定分類を、EMRの設定APIを使って、Flinkがインストールされたクラスターに設定することもできます。 直接EMRコンソールから、もしくは、以下のようにCLIを実行すれば、今日からEMRでFlinkの利用を開始できます。 aws emr create-cluster –release-label emr-5.1.0 \ –applications Name=Flink \ –region us-east-1 \ […]

今週の投稿を実現するため、プルリクエストや新しいコンテンツについて内外部 25 名以上の寄稿者にご協力いただきました。皆様からのご協力に感謝申し上げます。 月曜日 10 月 31 日 2016 年 10 月 AWS ホットスタートアップ – Optimizely、Touch Surgery、WittyFeed をご紹介しました。 Amazon Redshift が南米 (サンパウロ) で利用可能になりました。 が 3 つの AWS クイックスタートについてエピソードを公開しました。 が AWS 公共セクターのひと月を振り返る – 10 月を公開しました。 が AWS と TeamCity でのエンドツーエンドの継続的配信およびデプロイパイプラインの構築についてブログを公開しました。 が Amazon RDS for PostgreSQL のトランザクション ID の循環に早期警告システムを実装する方法を公開しました。 Cloud Guru ブログが Amazon Alexa Analytics について投稿しました。 cloudonaut.io […]

数年前に Amazon CloudWatch で OS とアプリケーションログファイルを保存しモニタリングする方法について説明しました。最近では多数の AWS ユーザーがログのフィルタを作成して、その結果を CloudWatch メトリクスとして発行し、何か問題があった場合にアラームを送信するようにしています。たとえばウェブサーバーログに無効なインバウンドリンクを表す 404 エラーや、オーバーロードの状態を意味する 503 エラーがあるか監視しています。モニタリングやアラームは大量のログデータを要約する上で優れたツールですが、場合によっては別の視点が必要になることもあります。まず、概要ではフィルタにより識別されアラームを送信する原因となったログファイルエントリをすばやく見つけなければなりません。多くの AWS ユーザーがそうであるように、何百、何千ものインスタンスを実行し複数のタイプのログファイルをモニタリングしている場合、こうした作業は針山から 1 本の針を見つけるようなものです。そこで本日、AWS はそうした作業を簡易化するため CloudWatch の新しいオプションをリリースしました。たとえばこのグラフに表示されている 17:00 頃の ERROR メトリクスについて理解したいとします。 クリックとドラッグで時間範囲を限定します。 ログアイコンをクリックし (他のアイコンと同様にグラフ上にマウスをかざすと表示されます)、目的のログファイル (ERROR) を選択します。 CloudWatch が 2 つめのタブで開きます。指定した時間範囲でフィルタする前の目的のログファイルが表示されます。次に内容を見るためにエントリを展開します (この例で使用した特定のエラーはデモ用なのでシンプルにしました)。 この機能はメトリクスの発行にログファイルのフィルタを使用する場合に便利です。では、特定のログファイルに関連していない CloudWatch システムメトリクスの場合はどうでしょう?先の手順を使用できますが、この場合はメニューから [View logs in this time range] を選択します。 指定した時間範囲の CloudWatch ロググループすべてがグラフに表示されています。 この時点でアプリケーションのアーキテクチャに関する知識をもとに意思決定を行ったり調査したいロググループを選択しやすくなります。目的の時間範囲内だけを表示するため、ロググループ内のイベントは再びフィルタにかけられます。グラフで Lambda の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

私の同僚に十代の頃からボストンの野球チーム、レッドソックスの大ファンだという人がいます。その彼女が、つい先日レッドソックスの偉大な選手でありハンクアーロン賞も受賞した David Ortiz (別名 “ビッグパピ”) と、殿堂入りした Joe Torre、アナウンサーの Dave O’Brien (ESPN および NESN) と共に、ビッグパピのメジャーリーグ引退を記念した面白いビデオ制作に携わりました。ご覧のようにビッグパピがクオンティファイドセルフをシリアスに受け止め、引退後も競争力が衰えないように AWS を使用した Statcast でさまざまなことを測定しています。 MLB Statcast は高解像度カメラとレーダー装置を使用してボール (20,000 メトリックス/秒) と選手たち (30 メトリックス/秒) の位置をトラックし、1 試合ごとに 7 テラバイトのデータを生成します。そして、これをすべて保存し処理しているのが です。このアプリケーションは 、、、、、、 など複数の AWS サービスを使用しています。アーキテクチャの全体像は次のとおりです。 詳細はこちらのケーススタディ Major League Baseball Fields Big Data, and Excitement, with AWS をご覧ください。 に参加される方は、肩を十分にほぐしてから Statcast 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。 今日のチョコレート / ピーナッツバターの組み合わせは、 と が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。 この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。 すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。 セットアップ 私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。 SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。 [Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。 アクション この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい […]

はメールの到達精度に注目し意図した受信者にメールが無事届くように努めています。以前公開したブログ (Introducing the Amazon Simple Email Service) では、いくつかの要因が到達精度に影響を与える点について説明したほか、複数のインターネットサービスプロバイダー (ISP) との信頼関係や、多数の苦情やバウンスしたメールなどについても取り上げました。 本日、SES 対象の送信メトリックスの新しいセットをリリースしました。この機能には 2 つの側面があります。 イベントストリーム – 重要なイベント (送信、拒否、配信、バウンス、苦情など) が発生するたびに JSON 形式のレコードを に発行するように SES を設定することができます。 メトリックス – にメトリックス集約を発行できるように SES を設定することができます。各メッセージに 1 つまたは複数のタグを追加して CloudWatch ディメンションとして使用することができます。メッセージにタグを追加することで、キャンペーン、チーム、部署に基づいて到達精度をトラッキングできます。この情報はメッセージやメール戦略の微調整に利用できます。 詳しくは のブログ Email Sending Metrics をご覧ください。

現在、 には 2,700 件を超えるソフトウェア製品がリストされています。数万という AWS の顧客が、925 以上の独立系ソフトウェアベンダー (ISV) の製品を検索して購入し、使用を開始しています。 今日は、 を通じてソフトウェアを購入している皆さんに、ご自分の連絡先情報 (氏名、肩書き、電話番号、電子メールアドレス、組織名) を選ばれたソフトウェアベンダーと共有し、製品サポートのリクエストを単純化、合理化する方法を提供したいと思います。ベンダーは、プログラムを通じて連絡先情報にアクセスし、各自のサポートシステムに保管することで、購入者のアイデンティティを簡単に検証し、より良いサポートを提供することができるようになります。このプログラムへの参加は、任意です。販売者は、プログラムに参加するかどうかを選択でき、購入者は、連絡先情報を共有するかどうかを選択できます。 購入者にとっての製品サポート接続 この機能を試してみるため、私は、Barracuda Web Application Firewall (WAF) を起動しました。オプションを選択し、Accept Software Terms & Launch with 1-click ボタンをクリックすると、連絡先情報を共有するかどうかを選択するオプションが表示されました。 そこで、氏名などの連絡先情報を入力しました。 ここでは、サブスクリプションごとに最大 5 つの連絡先が入力できます。 必要であれば、連絡先情報を後で追加、変更、削除することもできます。 私がすでに持っている製品で Product Support Connection が有効になっているなら、ここで連絡先の詳細を追加することもできます。 販売者にとっての Product Support Connection 私が、ISV で、このプログラムへの参加を希望している場合は、AWS Marketplace 販売者/カタログ業務チーム (aws-marketplace-seller-ops@amazon.com) に連絡します。すると、プログラムに登録され、連絡先情報の入手に使用するセキュリティが確保された API へのアクセスが可能になります。私は、プログラムの条件に従い、サポートシステムまたは CRM システム内の各連絡先を 1 営業日以内に登録しなければならず、連絡先は、サポート目的にしか使用できません。詳細については、 の AWS […]

The Amazon Linux AMI は、EC2 上で実行しているアプリケーションにセキュアで安定した、高パフォーマンスの実行環境を提供します。リモートアクセスが制限され (ルートログインや必須の SSH キーペアがない)、重要でないパッケージがほとんどインストールされていない AMI は、優れたセキュリティプロフィールを誇ります。 たくさんの顧客から、この Linux イメージをオンプレミスで、特に開発ワークロードやテストワークロードの中で使用したいというリクエストがありました。 クラウドとオンプレミスでの使用に適した Amazon Linux Container Image の提供開始を今日発表することができ、光栄です。イメージは EC2 コンテナレジストリから入手できます (アクセス方法については、イメージの入手をお読みください)。AMI と同じソースコード、同じパッケージで構築されているため、コンテナの導入がスムーズに実行できます。そのままで使用することも、独自のイメージを作成するための土台として使用することもできます。 それを試してみるため、私は、作成したばかりの EC2 インスタンスを起動し、Docker をインストールし、新しいイメージを入手して実行してみました。その後、cowsay と lolcat (と依存関係) をインストールし、上記のイメージを作成しました。 このイメージの詳細については、Amazon Linux Container Image をお読みください。 このイメージは、 で使用することもできます。詳細については、Amazon ECR イメージを Amazon ECS で使用するをお読みください。

は AWS リソースと AWS で実行しているアプリケーションをモニタリングするサービスです。これはメトリックスの収集とトラッキング、ログファイルのモニタリング、アラーム設定、AWS リソースの変更に対応することができます。 本日、AWS は CloudWatch に追加した複数の重要な強化機能をリリースしました。 メトリックス保存期間の延長 – CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。 メトリックスの選択をシンプルに – CloudWatch コンソールで必要なメトリックスの検索と選択が簡単になりました。 メトリックスのグラフ化を改善 – 選択したメトリックスのグラフ化が今までより簡単かつ柔軟になりました。 それらについて説明します。 メトリックス保存期間の延長 2009 年に CloudWatch をリリースした当時 (New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch) システムメトリックスの保存期間は 14 日間でした。その後、CloudWatch に自分のメトリックスを発行できるようになっても、保存期間は従来と変わりませんでした。AWS 利用者の多くが、より長い期間にわたりデータへのアクセスや閲覧を望んでいます。季節ごとの要因を検出して理解したり、毎月の成長傾向の確認、前年同期比の分析を実行するためです。 こうしたユースケースをサポートするため (そして多くの方々のリクエストにお応えするため)、CloudWatch ですべてのメトリックスを 15 か月間保存できるようになりました。追加費用はありません。全体のデータ量を合理的な範囲に抑えるため、履歴データは詳細度が低いレベルで保存されます。詳しくは次をご覧ください。 1 分間内のデータポイントは 15 […]