Amazon Web Services ブログ

週刊 AWS – 2016 年 11 月 7 日

先週 AWS で起こったことを見ていきましょう。プルリクエストを提出してくださった 17 名の内外の寄稿者に感謝いたします。 月曜日 11 月 7 日 CloudWatch の更新 – メトリクスから関連するログへを発表しました。 AWS で Microsoft Windows を CI/CD するためのクイックスタートリファレンスデプロイメントを公開しました。 ユーザーは組み込まれたサンプルデータを使用して Amazon Kinesis Firehose をテストドライブできることを発表しました。 Amazon RDS for SQL Server が Microsoft SQL Server 2016 をサポートするようになったことを発表しました。 が現実の世界における AWS のスケーラビリティについて投稿しました。 は Amazon ECS で Swift ウェブアプリケーションを実行する方法を説明しました。 はMicrosoft SQL Server Enterprise のワークロードを Amazon RDS に移行するシリーズのパート 1 […]

Read More

EBS スナップショットに CloudWatch Events を追加

これまで runbook で保たれていた情報や限定者のみ知ることができた情報など、複雑でレベルの高いオペレーションの自動化を可能にするクラウドコンピューティングは、従来の IT オペレーションを改善させることができます。特に小規模や成長段階の企業および団体でバックアップや復元操作を必要とするオペレーションが多く見られます。スナップショットのバックアップ生成や管理がしやすいため、AWS ユーザーの多くが ボリュームを大いに利用しています。また災害対策や運用上の理由から、リージョン間でスナップショットのコピーを定期的に取っています。そこで本日、AWS は EBS に自動化のメリットとして新に EBS スナップショット用の CloudWatch Events を追加しました。このイベントを使用してクラウドベースのバックアップ環境に自動化したオペレーションを追加することができます。新しいイベントは次をご覧ください。 createSnapshot – 新たに作成した EBS スナップショットのステータスが Complete に変更すると開始します。 copySnapshot – スナップショットコピーのステータスが Complete に変更すると開始します。 shareSnapshot – スナップショットを AWS アカウントと共有すると開始します。 多くの AWS ユーザーがスナップショットのステータスをモニタリングしています。この操作を行うため、ユーザーは DescribeSnapshots 関数を何度も呼び出し、特定のスナップショットを探すためにページ分割出力を調べます。今後は新しいイベントを使用して先述のクロスリージョンコピーなど、さまざまなイベントベースの自動化が可能になります。スナップショットイベントの使用 この機能がいかにデータバックアップワークフローの自動化に役立つのか理解するため、別のリージョンに完成したスナップショットをコピーするワークフローを作成してみました。まず、適切なアクセス権限を付与する IAM ポリシーを作成します。次に createSnapshot イベントでアクションを実行する 関数 (私の同僚が作成) を組み入れます。最後にイベントをキャプチャする CloudWatch Events ルールを作成し、Lambda 関数に転送します。まず、このポリシーで IAM ロール (CopySnapshotToRegion) を作成します。 次に新しい Lambda […]

Read More

新機能 – GPU を使用した Amazon Graphics WorkSpaces

おそらく、私の「Amazon WorkSpace がお気に入りです」という投稿からおわかりかと思いますが、私は一種のおたくです。その投稿を書いてから、自分ひとりではないこと、そして他にもたくさんの WorkSpaces おたくがいることがわかりました。AWS の多くのお客様は、ほとんど私と同じくらい、完全マネージド型でセキュアなデスクトップコンピューティング環境を楽しんでいます。お客様は、ユーザーとしての視点からは、Windows および Mac コンピューター、PCoIP ゼロクライアント、Chromebook、iPad、Fire タブレット、Android タブレットを含む、サポートされているさまざまなデバイスから、WorkSpace にアクセスできることを気に入っています。また、管理者としては、任意の数のユーザー向けに高品質のクラウドデスクトップをデプロイする機能に感謝しています。そして、最後にビジネスリーダーとしては、起動する WorkSpaces に対して時間単位または月単位で支払いが可能なことを気に入っています。 新しいグラフィックスバンドル これらのユーザーは、Value、Standard、Performance という、いくつかの異なるハードウェアを選択するバンドルにすでにアクセスできます。1 つまたは 2 つの vCPU (仮想 CPU) と 2~7.5 GiB のメモリにより、これらのバンドルはオフィスでの生産性の高いユースケースの多くに最適です。現在、私たちは GPU を使用した新しいグラフィックスバンドルを追加して WorkSpaces ファミリーを拡大しています。このバンドルは、CAD、CAM、または CAE ツールをオフィスで使用する 3D アプリケーション開発者、3D モデラー、エンジニアに最適なハイエンドの仮想デスクトップを提供します。そのスペックは次のとおりです。 ディスプレイ – 1,536 個の CUDA コアと 4 GiB のグラフィックスメモリを備える NVIDIA GPU。 プロセッサ – 8 個の vCPU。 メモリ – […]

Read More

新たに HIPAA に対応の AWS Snowball

最近では、かかりつけの医師、歯科医、病院、その他のヘルスケアプロバイダーなどが多くのツールやテクノロジーを使用して機密性の高いデジタルデータを大量に生成しています。その他にも大量に生成されているデータには、ゲノム配列や数々のアクティビティ、フィットネストラッカーなどがあります。このように大量に押し寄せるデータから有益な情報を得たいと多くの人々が考えていますが、それと同時にこの種の情報が安全に保護された状態で保存され、責任ある方法で処理されることを望んでいます。米国では HIPAA (医療保険の携行性と責任に関する法律) がヘルスケアデータの保護を統制しています。多くの AWS ユーザーは、機密性の高いヘルスケアデータをクラウドに保存し処理できることを望んでいます。そこで AWS では HIPAA を対象とする複数の AWS サービスを提供することにしました。つまり、こうしたサービスを利用して保護医療情報 (PHI) を処理したり、HIPAA 対応のアプリケーションを構築することができます (Cleveland Clinic、Orion Health、Eliza、Philips、その他 AWS ユーザーの使用事例については HIPAA in the Cloud をご覧ください)。去年ご紹介した AWS Snowball について簡単にご説明します。これは AWS が所有するストレージアプライアンスで、大量のデータ (通常 10 テラバイト以上) を 1 回限りまたは定期的に AWS に移動するために使用する機能です。 から Snowball をリクエストし、届き次第ネットワークに接続してデータを Snowball にコピーします。その後、AWS に送り戻せばこちらでそのデータをお客様が選択された AWS ストレージサービスにコピーします。Snowball はユーザーが指定し管理するキーを使用してデータを暗号化します。そして本日、AWS は 、、、、、、 (MySQL と Oracle)、、 に続き Snowball を […]

Read More

C2 の汎用 SSD (gp2) ボリュームの新しいバーストバランスメトリックス

AWS ユーザーの多くが、2014 年の中半期にリリースした汎用 SSD (gp2) EBS ボリュームを使用して素晴らしい成果を得ています (詳しくは New SSD-Backed Elastic Block Storage をご覧ください。ご自分のワークロードでどのタイプのボリュームを使用すべきか決めかねている場合は、幅広い種類のデータベース、開発とテスト、ブートボリュームのワークロードにわたり価格とパフォーマンスのバランスが取れている gp2 をお勧めします。このボリュームタイプで興味深いポイントの 1 つはバースト機能です。gp2 のバースト機能は AWS の顧客ベースを観察し、実社会におけるワークロードの I/O パターンに合わせて設計されました。AWS のデータサイエンティスト達は、ボリューム I/O は非常にバースト性が高く短時間で急上昇し、バースト間には十分なアイドル時間があることに気付きました。予測不可能でバースト性を持つトラフィックの性質が gp2 バーストバケットを設計した理由です。小さなボリュームでも 3000 IOPS までのバーストを可能にするほか、アイドル時間中または低レベルで I/O を実行している場合にバーストバケットを補充できるようにすることができます。バーストバケットの設計はすべての gp2 ユーザーに一貫性のある予測可能なパフォーマンスを提供します。実際には gp2 ボリュームが完全にバーストバケットを消耗することは非常に少なく、ユーザーは使用パターンをトラッキングし必要に応じて調整できるようになりました。さまざまなボリュームタイプのパフォーマンス最適化と、ベンチマークと実際のワークロードの違いに関するドキュメントはすでに提供済みです (詳しくは I/O Characteristics をご覧ください)。最初のブログ投稿で説明したように、バーストクレジットは設定済み GB/秒ごとに 3 倍の割合で蓄積し、読み取りまたは書き込み 1 回ごとに 1 つ使用されるようになっています。各ボリュームは 540 万クレジットまで蓄積することができ、ボリュームごとに 3,000 クレジット/秒の割合で使用することができます。使用を開始するには希望するサイズの gp2 ボリュームを作成し、アプリケーションを起動します。ボリュームの I/O […]

Read More

ゲノムエンジニアリングのアプリケーション: クラウドを早期導入

オーストラリア連邦科学産業研究機構 (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 ターゲットの位置を示し、その高アクティビティや低アクティビティを記述するほか、オフターゲットの可能性も表示します。 […]

Read More

さあ、Amazon EMRで、Apache Flinkを使って、大規模なリアルタイムストリーム処理を実行しよう

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

Read More

週刊 AWS – 2016 年 10 月 31 日

今週の投稿を実現するため、プルリクエストや新しいコンテンツについて内外部 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 […]

Read More

CloudWatch の更新 – メトリクスから関連するログへ

数年前に 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 の名前空間にメトリクスが含まれている場合は、メトリクスフィルタを使用していない場合でも、そのロググループへのリンクが表示されます。この機能は今すぐ使い始めることができます。

Read More

MLB Statcast – David Ortiz、Joe Torre、Dave O’Brien をご紹介

私の同僚に十代の頃からボストンの野球チーム、レッドソックスの大ファンだという人がいます。その彼女が、つい先日レッドソックスの偉大な選手でありハンクアーロン賞も受賞した 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 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

Read More