Amazon Web Services ブログ

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

これまで runbook で保たれていた情報や限定者のみ知ることができた情報など、複雑でレベルの高いオペレーションの自動化を可能にするクラウドコンピューティングは、従来の IT オペレーションを改善させることができます。特に小規模や成長段階の企業および団体でバックアップや復元操作を必要とするオペレーションが多く見られます。スナップショットのバックアップ生成や管理がしやすいため、AWS ユーザーの多くが Amazon Elastic Block Store (EBS) ボリュームを大いに利用しています。また災害対策や運用上の理由から、リージョン間でスナップショットのコピーを定期的に取っています。そこで本日、AWS は EBS に自動化のメリットとして新に EBS スナップショット用の CloudWatch Events を追加しました。このイベントを使用してクラウドベースのバックアップ環境に自動化したオペレーションを追加することができます。新しいイベントは次をご覧ください。

  • createSnapshot – 新たに作成した EBS スナップショットのステータスが Complete に変更すると開始します。
  • copySnapshot – スナップショットコピーのステータスが Complete に変更すると開始します。
  • shareSnapshot – スナップショットを AWS アカウントと共有すると開始します。

多くの AWS ユーザーがスナップショットのステータスをモニタリングしています。この操作を行うため、ユーザーは DescribeSnapshots 関数を何度も呼び出し、特定のスナップショットを探すためにページ分割出力を調べます。今後は新しいイベントを使用して先述のクロスリージョンコピーなど、さまざまなイベントベースの自動化が可能になります。スナップショットイベントの使用 この機能がいかにデータバックアップワークフローの自動化に役立つのか理解するため、別のリージョンに完成したスナップショットをコピーするワークフローを作成してみました。まず、適切なアクセス権限を付与する IAM ポリシーを作成します。次に createSnapshot イベントでアクションを実行する AWS Lambda 関数 (私の同僚が作成) を組み入れます。最後にイベントをキャプチャする CloudWatch Events ルールを作成し、Lambda 関数に転送します。まず、このポリシーで IAM ロール (CopySnapshotToRegion) を作成します。

次に新しい Lambda 関数を作成します (コードは Amazon CloudWatch Events for EBS で検索できます)。

次に CloudWatch Events コンソールにアクセスし [Create rule] をクリックしてから、正確に処理された createSnapshot イベントに対処できるように設定します。

名前を指定します。

テストするため自分のソースリージョンで新しい EBS スナップショットを作成します。

予想どおり関数が呼び出され、数秒内にスナップショットが目的のリージョンにコピーされました (実際に実行する場合、コピーの所要時間はスナップショットのサイズにより異なります)。

こうしたイベントを使用して、別のアカウントから共有されたスナップショットのコピーを作成することもできます。組織や団体そしてセキュリティ上のさまざまな理由から、AWS をご利用されている多くの方々が複数のアカウントにわたり容量を分割しています。この点に関する詳しいアドバイスについては AWS Multiple Account Security Strategy をご覧ください。5 つのモデルのうち 2 つについてはこちらをご覧ください。 今すぐ利用可能 新しいイベントは US East (Northern Virginia)US East (Ohio)US West (Northern California)US West (Oregon)Asia Pacific (Mumbai)Asia Pacific (Seoul)Asia Pacific (Singapore)Asia Pacific (Sydney)Asia Pacific (Tokyo)Europe (Frankfurt)Europe (Ireland)South America (Brazil) リージョンで今すぐ使い始めることができます。ぜひお試しください。皆様からのご感想をお待ちしています。

Jeff;

  PS – このようなシステムを構築してみたいという開発者、開発マネージャー、プロダクトマネージャーの方は EBS Jobs ページをご覧ください。

新機能 – 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。
  • メモリ – 15 GiB。
  • システムボリューム – 100 GB。
  • ユーザーボリューム – 100 GB。

この新しいバンドルは、WorkSpaces が現在実行されているすべてのリージョンで利用でき、上記に述べたいずれのデバイスでも使用できます。ライセンス込みのオペレーティングシステム (Windows Server 2008 と Windows 7 デスクトップエクスペリエンス) を実行するか、Windows 7 または 10 にご自分のライセンスを導入することができます。OpenGL 4.x、DirectX、CUDA、OpenCL、NVIDIA GRID SDK を使用するアプリケーションでは、GPU の利点を活用することができます。ペタバイトスケールのデータ分析と視覚化について検討を開始するときは、EC2RDSAmazon RedshiftS3Kinesis からこれらのインスタンスをすぐに利用できることを念頭に置いてください。大量の計算を行う分析をサーバー側で行い、隣接した WorkSpace で、視覚的に優れた方法でレンダリングできます。AWS のサービスのこの組み合わせを使えば、他の方法では得られないようなコスト効果やアーカイブ機能を備えたアプリケーションを作成できると確信しています。グラフィックスバンドルと他のバンドルには、もう 1 つ重要な違いがあります。基盤となるハードウェアの動作方法により、このバンドルを実行する WorkSpaces は、「Amazon WorkSpaces Update – Hourly Usage and Expanded Root Volume」という投稿で説明した AutoStop 実行モードと併せて使用した場合、ローカル状態 (実行中のアプリケーションと開いているドキュメント) を保存しません。WorkSpace から切断するか、長時間離れる場合は、開いているドキュメントを保存し、アプリケーションを閉じることをお勧めします。デモ 私は 3D アプリケーションを構築したり、CAD、CAM、CAE ツールを使用したりすることはありません。ただし、LEGO® ブリックのようなクールなデザインや作成は好きです。私は最新バージョンの LEGO Digital Designer (LDD) を起動して、デザインの向上のために時間を使いました。ベンチマークを実行する用意はありませんでしたが、GPU によって向上したバージョンは明らかにより高速に実行され、より高品質な仕上がりになりました。私が行った小規模なデザインスタディを示します。

デザインをすべてセットアップし、ビルドを開始する時間になりました。モニターを再配置して作業台から見えるようにするのではなく、Fire タブレットから Graphics WorkSpace にログインしました。ローカルコンピュータの能力は非常に控えめであったにもかかわらず、デザインを非常に迅速にスケールし、回転することができました。Fire の表示を次に示します。

おわかりのように、2 つのシーン (デスクトップと Fire) はそっくりです。作業台に移動し、いろいろと設定して、デザインを表示し、ブリックを見つけられるようにしました。

料金
Graphics WorkSpaces は、時間単位の課金オプションで利用できます。少額の固定月額料金 (インフラストラクチャとストレージのコスト) に加えて、その月の WorkSpace の時間単価での使用料金をお支払いいただきます。料金は US East (Northern Virginia) リージョンでは 22 USD/月 + 1 時間当たり 1.75 USD です。詳細については、WorkSpaces 料金表ページを参照してください。

Jeff;

新たに 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 に移動するために使用する機能です。AWS Management Console から Snowball をリクエストし、届き次第ネットワークに接続してデータを Snowball にコピーします。その後、AWS に送り戻せばこちらでそのデータをお客様が選択された AWS ストレージサービスにコピーします。Snowball はユーザーが指定し管理するキーを使用してデータを暗号化します。そして本日、AWS は Amazon DynamoDBAmazon Elastic Compute Cloud (EC2)Amazon Elastic Block Store (EBS)Elastic Load BalancingAmazon EMRAmazon GlacierAmazon Relational Database Service (RDS) (MySQL と Oracle)、Amazon RedshiftAmazon Simple Storage Service (S3) に続き Snowball を HIPAA 対象サービスのリストに追加しました。これにより対象サービス数は 10 件となりました。PHI やその他さまざまな機密性の高いデータを保存する場所として、安全で信頼性が高い AWS クラウドの提供に力を入れていることをお分かりいただけると思います。すでに AWS と事業提携契約 (BAA) を結んでいる場合は、今すぐ Snowball を使用して HIPAA アカウントにデータを移動することができます。HIPAA の対象サービスに Snowball が加わったことで、ヘルスケアやライフサイエンスにかかわる AWS のお客様はオンプレミスデータをすばやく Snowball に移動させ、上述したサービスのいずれかを使用してデータを処理することができます。たとえば、新しい HDFS のインポート機能を使用して、既存のオンプレミス Hadoop クラスターをクラウドに移動しスケーラブルな EMR クラスターを使用して分析することができます。また、既存のペタバイトスケールデータ (医療画像データ、患者記録など) を AWS に移動して HIPAA 対象の S3 または Glacier に保存することもできます。こうした実績があり使いやすいサービスは優れたデータ耐久性を備え、安価でご提供しています。

Jeff;

 

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 は可能な限り迅速かつ効率的に作業を進めます。

新しいメトリックスは本日よりご利用いただけます。バーストバランスメトリックスは各汎用 (SSD) ボリュームで使用可能です。このメトリックスは CloudWatch コンソールで確認することができます。残りが少なくなるとアラームを発信するように設定することも可能です。このメトリックスはパーセントで表示されます。つまり 100% はボリュームが蓄積できるクレジット最大数に到達していることを意味します。この例では c4.8xlarge インスタンスを起動し 100 GB ボリュームをアタッチしました。

次にボリュームのバーストバランスが 40% 以下になった場合に通知を送信するよう、アラームを作成します (実際にはこの数値を大幅に下げることをお勧めしますが、バランスを低下させるには結構な時間がかかるので、ここではこの数値で設定しました)。

SNS サブスクリプションを確認し fio を実行してロードを生成します。

$ sudo fio --filename=/dev/sdb --rw=randread --bs=16k --runtime=2400 --time_based=1 \
  --iodepth=32 --ioengine=libaio --direct=1  --name=gp2-16kb-burst-bucket-test

バランスが低下していくのを観察します。

予想通り通知メールが届きました。

本稼働の状況ではボリュームのサイズを上昇させたり、アプリケーションの I/O の動作を細かく設定したり、バーストバケットをうまく活用していることをメモすることもできます。テスト終了後はランチを取りながらバーストバランスが上昇するのを観察しました (今回は更新済みの CloudWatch コンソールを使用しました)。

稀ではありますが、バーストバケットの消耗が予想以上に早いという場合は、gp2 ボリュームのサイズを上げてパフォーマンスを高めるか、99.9% の確率で一貫性を持つプロビジョンドパフォーマンスを提供するプロビジョンド IOPS SSD (io1) ボリュームに移行することもできます。

今すぐ利用可能
この機能は今すぐすべての AWS 商用リージョンでご利用いただけます。追加費用はありません。CloudWatch アラームには通常の料金が適用されます。

Jeff;

  PS – このようなシステムを構築してみたいという開発者、開発マネージャー、プロダクトマネージャーの方は EBS Jobs ページをご覧ください。

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

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

GT-Scan2 はゲノムで独自の位置を見つけることでシステムの効率性を高めます。これによりゲノム内にある別の位置で配列相同性が高い「オフターゲット」によって影響力を弱められないようにします。変更しやすい位置を見つけることで堅牢性を最適化します。「ゲノムの 3D 構成が CRISPR バインディングの役割を担うことはすでに知られていましたが、GT-Scan2 は Cas9 アクティビティにとって重量となる別のコンポーネントも活用する最初のツールです」と、コンピュテーショナルゲノムエンジニアリングを研究する Dr. Laurence Wilson は述べています。特にオフターゲット検索は数値計算タスクで各ロケーションにつき 30 億文字列という非常に長いゲノム配列を調査する必要があります。そのため、従来は高性能な計算力を備えたインフラストラクチャを持つ大規模な組織の研究者が行うタスクでした。GT-Scan2 は AWS Lambda 関数を使用し、この複雑な計算力をクラウドサービスとして提供することで、最適位置を見付けることができます。パーソナライズ治療を瞬時にスケール GT-Scan2 はイベント駆動型の AWS Lambda サービスが提供するすばやいスケーラビリティを利用します。標的化遺伝子は劇的に変動するため、これはパーソナライズ治療において非常に大切です。「オフターゲットの研究や堅牢性の分析は並行して実行できる各モジュラータスクに分けることができます」と、Aidan O’Brien は述べています。同氏は、AWS Summit 2016 で今年 4 月のアジアパシフィックリリースから数週間内にこのシステムを設計し導入、さらにそのサービスの直観的な性質を証明しています。通常、1 つのジョブの所要時間は 1 分未満でジョブ間の変動時間は 1 秒から 5 分です。数分内というロード時間の迅速な変動は、ランタイムの安定性を維持するにはオンラインになるのが遅すぎロードに数時間を要する新しいインスタンスとしての EC2 ベースソリューションを除外します。

GT-Scan2 は S3 で提供、サーバー側からの処理なしに静的ウェブアプリを実行できるようにします。JavaScript フレームワークを使用して、データベースから API Gateway を使い API コール経由で動的コンテンツ (ジョブの結果やパラメーター) を取得します (DynamoDB)

ユーザーがジョブを送信すると、GT-Scan2 が API コール経由で DynamoDB テーブルにアイテムとしてジョブパラメーターを挿入します。これにより、ボトルネックを作らず自由でスケーラブルなソリューションを可能にします。このデータベースエントリは最初の Lambda 関数をアクティブ化し、ユーザー専用の DNA 配列 (ユーザーの送信時に自動取得) で推定上の CRISPR ターゲットをすべて検索します。CRISPR ターゲット候補の位置には一定のルールがあり、数秒で完了する 2 つめの DynamoDB テーブルに挿入される正規表現を使用して簡単に探すことができます。Lambda ベースのマイクロサービスを活用 ターゲット候補はすべて効率的なマッチングツールの Bowtie を使用してそのオフターゲットリスクを評価する必要があります。Bowtie では 30 億の文字列から形成されるゲノム配列の簡約表示のみが必要となるので、こうしたインデックスファイルのサイズが各 Lambda インスタンスのストレージ制限を超えることはありません。開発時に CSIRO チームをサポートした Adrian White (リサーチ & テクニカルコンピューティング、APAC) は「GT-Scan2 はゲノムを小さいブロックに分けて Lambada の仕様に合わせられるようにします」と述べています。一般的に GT-Scan2 は 500-1000 件の Lambda 関数をアクティブ化し、同時に DynamoDB にある推定上の異なるターゲットスコアも更新するようになっています。このプロセスの実行中にフロントエンドは API Gateway 経由でこのテーブルをポーリングし、結果が入り次第ウェブページを更新、サーバー側からのコンピューティングを不要にしています。「AWS の Lambda のおかげで、医療ゲノムエンジニアリングのアプリケーションをサポートでき、今後の流れに対応できるソフトウェアパッケージ開発に優れたフレームワークを使用することができました」と Dr. Bauer は語っています。「特に様々なジャンルの複雑な面に対応するために、さらに多くの Lambda 関数をランタイムで瞬時に起動しスケールできる点に感心しています。」Dr. Bauer は、使用期間のみのストレージ料金を支払うことや、ウェブサイトは動的コンテンツを含む静的ページで Angular 2 や API Gateway を通じて更新されるためにウェブサーバーのリソースとジョブが競合しないことや、コンピュートインスタンスの維持が不要 (OS のセキュリティパッチ) なことも、その他のメリットであると述べています。「Lambda が優れいているポイントの 1 つは、ユーザーが特定の CRISPR アプリケーションに適した別の機械学習アルゴリズムに簡単に切り替えられることです」と Dr. Wilson は述べています。

GT-Scan2 チーム – Denis Bauer、Laurence Wilson、Aidan O’Brien (左から)

「コンピュテーショナルゲノムエンジニアリングコミュニティは AWS Lambda テクノロジーを早期に導入したコミュニティの 1 つです」と Dr. Mia Champion (Scientific Computing テクニカルビジネス開発マネージャー) は言います。「GT-Scan2 が APCI Gateway や DynamoDB を使用することは、スケーラビリティを確保する上ですばらしいソリューションと言えます。エピジェネティクスをうまく使う方法も、CRISPR 検索を実施するために Lambda を使用する最近の他のアプリケーションとは一線を画しているポイントだと思います。医療アプリケーションで GT-Scan2 が導入されていくことを楽しみにしています。」

さあ、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 StreamsApache KafkaElasticsearchTwitter 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.3Zeppelin 0.6.2HBase 1.2.3についての、より詳細な情報については、Amazon EMRのドキュメントをぜひご確認下さい。(原文)

Amazon EMRでApache Flinkを利用する

Apache Flinkは、お客様の間でリアルタイムビッグデータアプリケーションを構築するために使われている、並列データ処理エンジンです。Flinkによって、例えばAmazon Kinesis StreamsApache 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 \
 --log-uri s3://myLogUri \
 --instance-type m3.xlarge \
 --instance-count 1 \
 --service-role EMR_DefaultRole \
 --ec2-attributes KeyName=YourKeyName,InstanceProfile=EMR_EC2_DefaultRole

Apache Flinkについてもっと知りたいという方は、Apache Flinkのドキュメントをご確認下さい。そして、EMRでのFlinkについてもっと知りたいという方は、ぜひAmazon EMRリリースガイドのFlinkトピックをご確認下さい。(原文)

翻訳: 半場 光晴

週刊 AWS – 2016 年 10 月 31 日

今週の投稿を実現するため、プルリクエストや新しいコンテンツについて内外部 25 名以上の寄稿者にご協力いただきました。皆様からのご協力に感謝申し上げます。

月曜日

10 月 31 日

火曜日

11 月 1 日

水曜日

11 月 2 日

木曜日

11 月 3 日

金曜日

11 月 4 日

土曜日

11 月 5 日

日曜日

11 月 6 日

新しい & 注目のオープンソース

  • awsapigatewayupsert は Lambda 関数の統合許可の管理をサポートする Swagger 2.0 JSON の定義から API Gateway インスタンスのアップサートとエクスポートを有効にします。
  • AWS IoT Embedded C ESP32 PortAWS IoT embedded C SDK のポートです。ESP32 プラットフォームが対象となります。
  • aws-lambda-go-net は変更なしに既存の Go ウェブアプリケーションを AWS Lambda で実行することを許可します。
  • pipeline-aws-plugin が AWS API と連携するために Jenkins パイプラインの手順を追加しました。
  • elastic-ci-stack-for-aws は、お客様の AWS VPC で実行中のビルドエージェントのシンプルで柔軟性の高い Auto Scaling クラスターです。
  • docker-aws-tools は AWS CLI を使用する Docker イメージで、AWS API と連動する上でよく使われるツールです。
  • js-aws は AWS の完全な JavaScriptification です。
  • aws-team-cost-reporter が CloudCheckr を使用し AWS チームのコストについて調べました。
  • lambda-cd は Lambda 関数の継続的配信における PoC (実証支援) です。
  • cloud-search-query は AWS CloudSearch 構造のクエリを構築するための ORM のようなラッパーです。

新しいお客様事例

  • Apposphere – AWS マーケットプレイスから AWS と bitfusion.io を使用し、Apposphere は顧客満足度を維持しながら前月比の 50 パーセントから 60 パーセントもスケールすることができます。テキサス州オースティンを拠点とする Apposphere モバイルアプリはソーシャルメディアチャネルからリアルタイムの情報を配信しています。
  • CADFEM – CADFEM は AWS を使用して規模の小さな技術系企業が利用しやすく大企業とも競争できるように、複雑なシミュレーションソフトウェアを製作しています。同企業は技術業界においてシミュレーションソフトウェアとサービスを専門としています。
  • Mambu – AWS を使用する Mambu は英国初のクラウドベースの銀行のリリースに協力しました。その後、同企業の成長は 10 倍増しにもなり、急激な成長を続ける金融工学分野で競争力を持つ存在になりました。Mambu は一体化した SaaS バンキングプラットフォームです。クレジット管理や預金商品をすばやくシンプルかつ手頃な価格で提供しています。
  • Okta – Okta は AWS を使用して何週間ではなく数日で新しいサービスを本稼働環境で使用できるようにします。Okta は強力なセキュリティ保護を実施しながら、いつでも複数のデバイスでアイデンティティ情報を使用し、ユーザーにアプリケーションのアクセス権を付与することができます。
  • PayPlug – 2013 年に設立されたスタートアップ企業の PayPlug はオンライン決済ソリューションを開発しました。e コマースのシンプルなサービスと簡単な統合で他社との差を明確にしています。2013 年に設立されたスタートアップ企業の PayPlug はオンライン決済ソリューションを開発しました。e コマースのシンプルなサービスと簡単な統合で他社との差を明確にしています。
  • Rent-a-Center – Rent-a-Center は米国、カナダ、プエルトリコ、メキシコで家具、電化製品、電子機器レンタルの業界をリードしていますRent-A-Center は AWS を使用して同社の新しい e コマースウェブサイトを管理し、ウェブサイトトラフィックの 1,000 パーセントスパイクをサポート、DevOps のアプローチを有効にしています。
  • 英国司法省 – 英国司法省 (MoJ) は AWS クラウドを使用して一体化を実現することで、英国市民に効率的かつ公正なサービス提供の強化に同技術を使用することができます。MoJ は英国政府の行政部です。MoJ は独自のオンプレミスデータセンターを備えていましたが、国民のニーズに基づく変更や適合を迅速に満たす力に欠けていました。デジタルサービスが増えていくに連れ、MoJ は AWS を使用して自動化、統合、サービス提供を行うようになりました。

新しい SlideShare プレゼンテーション

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

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

Jeff;

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 Cloud です。このアプリケーションは Amazon CloudFrontAmazon DynamoDBAmazon Elastic Compute Cloud (EC2)Amazon ElastiCacheAmazon Simple Storage Service (S3)AWS Direct ConnectAWS Lambda など複数の AWS サービスを使用しています。アーキテクチャの全体像は次のとおりです。

詳細はこちらのケーススタディ Major League Baseball Fields Big Data, and Excitement, with AWS をご覧ください。

AWS re:Invent に参加される方は、肩を十分にほぐしてから Statcast 装置万端のバッティングケージにぜひお越しください。メジャーリーグの選手たちと自分の測定比較をすることもできます。

Jeff;

CodePipeline の更新 – CloudFormation スタックの継続的配信ワークフローの構築

2 つの AWS サービスを一緒に使用して生産性を高めるための新しい方法について記事を書き始めたときに、1980 年代の Reese ピーナッツバターカップの TV コマーシャルを思い出しました。2 つの有益なサービス (2 つのおいしい味) を組み合わせることで、さらにうまみのある新しいものが生まれます。

今日のチョコレート / ピーナッツバターの組み合わせは、AWS CodePipelineAWS CloudFormation が出会って生まれます。CodePipeline を使って、CloudFormation スタックの継続的配信パイプラインを構築できるようになりました。継続的配信を実行すると、コードの変更が毎回自動的にビルド、テストされ、本稼働環境へのリリースのために準備されます。ほとんどの場合、継続的配信のリリースプロセスには、手動と自動の承認ステップの組み合わせが含まれます。たとえば、自動化された一連のテストに合格したコードは、最終的な確認と承認のために開発マネージャーまたはプロダクトマネージャーにルーティングしてから、本稼働環境にプッシュできます。

この機能の重要な組み合わせにより、継続的配信の利点をすべて活用しながら、コードとしてのインフラストラクチャモデルを使用できるようになります。CloudFormation テンプレートを変更するたびに、CodePipeline はテストスタックを構築し、変更をテストして手動の承認を待ってから本稼働環境にプッシュするワークフローを開始できます。このワークフローでは多くの異なる方法でスタックを作成し、操作できます。

すぐ後で説明するように、ワークフローでは変更セットを生成して運用可能なスタックに適用する機能 (詳細については、「新機能 – AWS CloudFormation 用の変更セット」を参照) など、CloudFormation の高度な機能を活用できます。

セットアップ
私はこの機能の詳細について参照するため、CloudFormation テンプレートを使って継続的配信パイプラインをセットアップしました (これはコードとしてのインフラストラクチャの別の例です)。このテンプレート (こちらから入手可能で、詳細は こちらで参照可能) により、フル機能のパイプラインをセットアップできます。このテンプレートを使ってパイプラインを作成するときは、S3 バケットの名前とソースファイルの名前を指定します。

SourceS3Key は、S3 のバージョニングが有効な ZIP ファイルを指します。このファイルには、これから作成するパイプラインを介してデプロイされる CloudFormation テンプレート (WordPress のシングルインスタンスの例を使用) が含まれています。また、設定ファイルやパラメーターファイルなど、他のデプロイアーティファクトも含まれています。その例を次に示します。

[Create Stack] をクリックすると、わずか数秒で継続的配信ライン全体を準備できます。これを次に示します。

アクション
この時点で、CloudFormation を使ってパイプラインをセットアップしました。これで準備が整ったので、このパイプラインで新しい CloudFormation アクションを使用する方法をご覧いただくことができます。

2 番目のステージである、TestStage に注目しましょう。このステージは最初のステージによってトリガーされ、CloudFormation を使ってテストスタックを作成します。

このスタックは ZIP の test-stack-configuration.json ファイルのパラメーター値を使って作成されます。CloudFormation アクションごとに異なる設定ファイルを使用できるので、同じテンプレートをテストと本稼働に使用できます。

スタックが起動して実行されると、ApproveTestStack ステップを使って手動の承認を待ちます (“Waiting for approval above.” と表示されます)。私は開発マネージャーの役割を果たし、テストスタックが予期どおり動作、実行されることを確認したら、それを承認します。

承認後は、DeleteTestStack ステップによりテストスタックが削除されます。

これで、本稼働環境へのデプロイの準備がほぼ整いました。ProdStage は CloudFormation 変更セットを作成し、それを手動の承認用に送信します。このステージでは ZIP の prod-stack-configuration.json ファイルからのパラメーター値を使用します。これらのパラメーターを使って、小さい EC2 インスタンスで適切なサイズのテスト環境を起動し、同じテンプレートから大規模な実稼働環境を起動できます。

ここで私は上役の役割を果たし、実稼働サイトの起動と運用を維持する責任を負います。実稼働環境へのデプロイで何が起こるかを確実に理解するため、変更セットを確認します。パイプラインを実行するのはこれが初めてであるため、変更セットは EC2 インスタンスとセキュリティグループが作成されることを示します。

次に、私はこれを承認します。

変更セットが承認されると、ExecuteChangeSet ステップの既存の実稼働スタックに適用されます。既存のスタックに変更を適用すると、既存のリソースは可能な場合は継続して機能し、アプリケーションの完全な再起動を回避します。通常、これはスタック全体を置き換えるよりも効率的で、破壊的ではありません。インメモリキャッシュのウォームアップ状態が維持され、コールドスタートアクティビティで発生する可能性のあるバーストが回避されます。

変更の実装
HTTPS のサポートを決定するとします。これを行うには、アプリケーションのセキュリティグループにポート 443 を追加する必要があります。CloudFormation テンプレートを編集し、新しい ZIP にこれを配置して、S3 にアップロードします。テンプレートに追加したコードは次のとおりです。

      - CidrIp: 0.0.0.0/0
        FromPort: '443'
        IpProtocol: tcp
        ToPort: '443'

次にコンソールに戻り、CodePipeline がすでに変更を検出してパイプラインが動作するよう設定したことを確認します。

パイプラインはもう一度実行されます。テストスタックを承認し、変更セットを点検して、既存のセキュリティグループを変更することを確認します。

次に進む前に、1 つ注意事項があります。パイプラインの CloudFormation テンプレートによって IAM ロールが作成され、これを使ってテストおよびデプロイスタックを作成します (これは新機能です。詳細については、「AWS CloudFormation サービスロール」を参照してください)。最適な結果を得るには、パイプラインを削除する前にスタックを削除します。これを行わない場合は、スタックを削除するためにロールを再作成する必要があります。

その他の情報
スペースと時間が足りなくなってきましたが、この新機能のその他の側面のついて、いくつか簡単に説明します。

パラメーターの上書き – CloudFormation アクションを定義する際に、テンプレートに対して定義されるパラメーター値の追加の制御が必要になる場合があります。これを行うには、[Advanced] ペインを開き、必要なパラメーター値の上書きを入力します。

アーティファクトのリファレンス – 状況によっては、以前のステージのパイプラインで作成されたアーティファクトの属性を参照する必要が生じます。たとえば、パイプラインの早い段階で Lambda 関数を S3 バケットにコピーし、結果として生じるアーティファクト LambdaFunctionSource を呼び出すとします。パラメーターの上書きを使って属性からバケット名とオブジェクトキーを取得する方法を次に示します。

{
  "BucketName" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "BucketName"]},
  "ObjectKey" : { "Fn::GetArtifactAtt" : ["LambdaFunctionSource", "ObjectKey"]}
}

JSON パラメーターへのアクセス – 新しい Fn::GetParam 関数を使って、アーティファクトに含まれる JSON 形式ファイルから値を取得できます。

Fn:GetArtifactAttFn::GetParam は、パラメーターの上書き内で使用されるよう設計されています。

S3 バケットのバージョニング – 私のパイプライン (Source アクション) の最初のステップでは、S3 バケットのオブジェクトを参照します。オブジェクトの S3 バージョニングを有効にして、変更ごとにテンプレートの新しいバージョンをアップロードします。

ソースとして S3 を使用する場合は、バージョニングを使用する必要があります (既存のオブジェクトに対する新しいオブジェクトのアップロードはサポートされません)。AWS CodeCommit または GitHub レポジトリをソースとして使用することもできます。

パイプラインウィザードの作成
私は、CloudFormation テンプレートを使ってパイプラインを作成することで、このブログ投稿を開始しました。コンソールで [Create pipeline] をクリックし、ウィザードを使って最初のパイプラインを構築することもできます (ソース、ビルド、およびベータデプロイステージを使用)。このウィザードでは、デプロイプロバイダーとして CloudFormation を選択することもできます。ベータデプロイステージでスタックや変更セットを作成または更新できます。

今すぐご利用可能
この新機能は今すぐご利用可能で、すぐに使用を開始することができます。詳細については、CodePipeline ドキュメントの「AWS CodePipeline を使用した継続的配信」を参照してください。

Jeff;