AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。

Adobe、Pitney Bowes、デブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% 値下げします。エンタープライズ規模のアプリケーション、大規模にスケーラブルなウェブサイト、モバイルアプリケーションを、以前よりはるかにコスト効果の高い方法で構築および実行できます。リージョンおよびインスタンスタイプごとの最大の値下げ率を次に示します。

オンデマンドインスタンスの値下げされた新料金は、2017 年 7 月 1 日に有効になります。リザーブドインスタンスの新料金は本日有効になります。

— Jeff;

Ananth Vaidyanathan (EC2 Systems Manager のシニア製品マネージャー) および Rich Urmston (Pegasystems のクラウドアーキテクチャのシニアディレクター) によって書かれた次のゲスト投稿は、EC2 Run Command を使用して、SSH を用いることなく EC2 インスタンスの大量のコレクションを管理する方法を示しています。

— Jeff;

多くの場合、エンタープライズは管理対象環境および数千の Amazon EC2 インスタンスを持っています。Secure Shell (SSH) について悩むことなく、システムをセキュアに管理することが重要です。Amazon EC2 Systems Manager の一部である Run Command では、制御され管理可能な方法で、インスタンス (またはタグを使用してインスタンスのグループ) でリモートコマンドを実行できます。これは、Run Command サービスに毎日依存する Pega Cloud オペレーションにとって、生産性を向上するための優れた追加機能です。標準の IAM ロールとポリシーを通じた Run Command の制御、ドキュメントの定義による入力パラメーターの使用、コマンド出力を返すために使用される S3 バケットの制御が可能です。また、他の AWS アカウントや一般ユーザーとドキュメントを共有することもできます。全体として、Run コマンドは優れた一連のリモート管理機能を提供します。

SSH よりも優れる
Run Command が SSH よりも優れたオプションであり、Pegasystems がこれを主要なリモート管理ツールとして採用した理由を示します。Run Command にかかる時間が短い – インスタンスへのセキュアな接続では、接続するジャンプボックス、ホワイトリストに登録する IP アドレスなど、いくつかのステップが必要です。Run Command では、クラウド Ops エンジニアはノートパソコンから直接コマンドを呼び出すことができ、キーやインスタンス ID を探す必要はありません。代わりに、システムセキュリティは AWS 認証、IAM ロールとポリシーに依存します。Run Command オペレーションは完全に監査される – SSH では、実行できる操作に実質的な制御はなく、監査証跡もありません。Run Command では、呼び出された各オペレーションは CloudTrail で監査されます。これには、呼び出し元のユーザーの情報、コマンドが実行されたインスタンス、パラメーター、およびオペレーションのステータスが含まれます。お客様は完全なコントロールを持ち、システムでエンジニアが実行できる機能を制限することができます。Run Command には管理する SSH キーがない – Run Command は標準の AWS 認証情報、API キー、および IAM ポリシーを利用します。エンジニアは、企業認証システムとの統合を通じて、企業の認証情報と ID に基づいてシステムとやり取りします。Run Command は同時に複数のシステムを管理できる – Linux サービスのステータスの確認や、マネージドインスタンスのフリート全体のログファイルの取得などの簡単なタスクでも、SSH を使用すると手間がかかります。Run Command では、ID またはタグでインスタンスのリストを指定し、指定したフリート全体に対して並行してコマンドを呼び出すことができます。これにより、最小の Pega クラスターよりも多くをトラブルシューティングまたは管理する場合に、高い利用価値が得られます。Run Command により複雑なタスクの自動化が簡単に – 操作タスクの標準化では、正確なコマンドを記述する詳細な手順のドキュメントやスクリプトが必要です。フリート全体でこうしたスクリプトを管理またはデプロイするのは面倒です。Run Command ドキュメントにより、複雑な関数をカプセル化し、ドキュメント管理とアクセスコントロールに対応するための簡単な方法が得られます。ドキュメントは、AWS Lambda と組み合わせると、複雑なタスクを処理するための強力なオートメーションプラットフォームを提供します。

例 – Docker コンテナの再起動
Docker コンテナの再起動に使用されるシンプルなドキュメントの例を示します。これには 1 つのパラメーター (再起動する Docker コンテナの名前) があります。ドキュメントは AWS-RunShellScript メソッドを使用してコマンドを呼び出します。出力はサービスにより自動的に収集され、呼び出し元に返されます。最新のドキュメントスキーマの例については、「Systems Manager ドキュメントの作成」を参照してください。

{
  "schemaVersion":"1.2",
  "description":"指定された Docker コンテナを再起動します。",
  "parameters":{
    "param":{
      "type":"String",
      "description":"(必須) 再起動するコンテナの名前。",
      "maxChars":1024
    }
  },
  "runtimeConfig":{
    "aws:runShellScript":{
      "properties":[
        {
          "id":"0.aws:runShellScript",
          "runCommand":[
            "docker restart {{param}}"
          ]
        }
      ]
    }
  }
}

Pegasystems での Run Command の実行
Pegasystems プロビジョニングシステムは、Pega Cloud リソースのデプロイと更新に使用される、AWS CloudFormation 上にあります。この最上位にあるのは Pega Provisioning エンジンです。これは CloudFormation テンプレートおよび Ansible 戦略のライブラリを管理する、サーバーレスで Lambda ベースのサービスです。設定管理データベース (CMDB) は各デプロイおよび更新のすべての設定詳細と履歴を追跡し、階層ディレクトリの命名規則を使用してデータをレイアウトします。次の図は、さまざまなシステムの統合方法を示しています。

クラウドシステム管理の場合、Pega オペレーションでは、 cuttysh と呼ばれるコマンドラインバージョンと、Pega Operations Portal と呼ばれる Pega 7 プラットフォームに基づくグラフィカルバージョンを使用します。両方のツールとも、Run Command を通じて、デプロイされた環境の CMDB の参照、設定の表示、デプロイされた EC2 インスタンスの操作が可能です。

CLI のウォークスルー
お客様のデプロイを調べ、Run Command を使用してインスタンスを操作する CLI のウォークスルーを示します。 cuttysh ツールを起動すると、CMDB のルートに移動し、プロビジョニングされたお客様のリストを表示できます。

% cuttysh
d CUSTA
d CUSTB
d CUSTC
d CUSTD

CMDB は、標準 Linux シェルコマンド ( cd、 ls、 cat、および grep などを使用して操作できます。s という接頭辞が付く項目は、表示可能なプロパティを持つサービスです。d という接頭辞が付く項目は、CMDB 階層でナビゲート可能なサブディレクトリです。この例では、ディレクトリを CMDB 階層の顧客の CUSTB 部分に変更し、さらに Dev ネットワークの env1 というプロビジョニングされた Pega 環境に変更します。このツールは、その環境用にプロビジョニングされたアーティファクトを表示します。これらのエントリはプロビジョニングされた CloudFormation テンプレートにマッピングされます。

> cd CUSTB
/ROOT/CUSTB/us-east-1 > cd DEV/env1

ls –l コマンドは、プロビジョニングされたリソースのバージョンを表示します。これらのバージョン番号は、Pega Cloud のバージョンを構成する CloudFormation、Ansible、その他のコンポーネントのソース管理により管理されたアーティファクトにマッピングされます。

/ROOT/CUSTB/us-east-1/DEV/env1 > ls -l
s 1.2.5 RDSDatabase 
s 1.2.5 PegaAppTier 
s 7.2.1 Pega7 

ここで、Run Command を使用して、デプロイされた環境とやり取りします。これを行うには、attach コマンドを使用して、やり取りするサービスを指定します。次の例では、Pega ウェブ層にアタッチします。CLI は、CMDB およびインスタンスタグの情報を使用して、対応する EC2 インスタンスを見つけ、それに関するいくつかの基本情報を表示します。このデプロイには 3 つのインスタンスがあります。

/ROOT/CUSTB/us-east-1/DEV/env1 > attach PegaWebTier
 # ID         State  Public Ip    Private Ip  Launch Time
 0 i-0cf0e84 running 52.63.216.42 10.96.15.70 2017-01-16 
 1 i-0043c1d running 53.47.191.22 10.96.15.43 2017-01-16 
 2 i-09b879e running 55.93.118.27 10.96.15.19 2017-01-16 

ここから、 run コマンドを使用して Run Command ドキュメントを呼び出すことができます。次の例では、 docker-ps ドキュメントをインスタンス 0 (リストの最初のインスタンス) に対して実行できます。EC2 はコマンドを実行し、出力を CLI に返します。CLI はその出力を表示します。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-ps
. . 
CONTAINER ID IMAGE             CREATED      STATUS        NAMES
2f187cc38c1  pega-7.2         10 weeks ago  Up 8 weeks    pega-web

同じコマンドおよび定義されたその他のドキュメントの一部を使用して、Docker コンテナを再起動するか、ファイルのコンテンツをローカルシステムに戻すこともできます。ファイルを取得すると、Run Command は同僚にリンクを渡す場合に備えて、コピーを S3 バケット内に残します。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-restart pega-web
..
pega-web

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 get-file /var/log/cfn-init-cmd.log
. . . . . 
get-file

データはローカルに /tmp/get-file/i-0563c9e/data にコピーされました
データは S3 (s3://my-bucket/CUSTB/cuttysh/get-file/data) でも利用できます

ここで、Run Command の機能を利用して、一度に複数の操作を実行します。次の例では、デプロイに 3 つの実行中のインスタンスをアタッチし、各インスタンスの稼働時間を確認します。 par (parallel) オプション ( run 用) を使用して、CLI はすべてのインスタンスで並列で稼働時間ドキュメントを実行するよう Run Command に伝えます。

/ROOT/CUSTB/us-east-1/DEV/env1 > run par uptime
 …
Output for: i-006bdc991385c33
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.42, 0.32, 0.30

Output for: i-09390dbff062618
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.08, 0.19, 0.22

Output for: i-08367d0114c94f1
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.36, 0.40, 0.40

コマンドが完了しました。
/ROOT/PEGACLOUD/CUSTB/us-east-1/PROD/prod1 > 

要約
Run Command は、システムへのアクセスを高速にして生産性を向上させ、インスタンスのグループに対してオペレーションを実行する機能を提供します。Pega Cloud のオペレーションは、他の操作ツールとともに Run Command を統合し、システム管理のためのクリーンでセキュアな方法を提供します。これにより、運用効率が向上し、管理されたデプロイでだれが何をできるかについて、より高度な管理が可能になります。Pega の継続的な改善プロセスにより、ユーザーがアクセスを必要とする理由が定期的に評価され、それらのオペレーションを、ライブラリに追加する新しい Run Command ドキュメントに変換します。その長期的な目標は、SSH を有効にしたクラウドシステムのデプロイを中止することにあります。ご不明の点またはご提案があれば、当社までコメントをお寄せください。

— Ananth および Rich

2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。

このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server（4013389）の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。

WannaCryによるAWSサービスへの影響

EC2 Windows

Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。

AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。

AWSのWindows AMIのリリースノートはこちらです。

WorkSpaces

Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。

Directory Service

AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。

Elastic Beanstalk

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

AWSサービスの効果的な使い方

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

AWSコンソール上でのAmazon Inspector 結果詳細画面例

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

推奨するAWSソリューション

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

• EBS Snapshot Scheduler – Amazon EC2にアタッチされているブロックストレージ(EBS)のバックアップをスケジュール管理できます
  https://aws.amazon.com/answers/infrastructure-management/ebs-snapshot-scheduler/
• Securing Windows EC2 Instances – EC2をセキュアに保つための推奨構成ガイドです
  https://aws.amazon.com/answers/security/aws-securing-windows-instances/

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山 隼人, セキュリティソリューションアーキテクト
坪 和樹, クラウドサポートエンジニア
長谷川 淳, クラウドサポートエンジニア

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。

その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。

ここで、この分野での最も重要なお知らせを簡単にまとめておきます：

2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました

2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました

2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました

2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました

2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました

2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました

2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました

2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました

現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています（SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています）。

私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました（閲覧には登録が必要）。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです：

SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します：

• より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード（34TBメモリ）まで構成できるようになりました
• 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します
• 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています

詳細をみてみましょう！

より大きなSAP HANAクラスタ
SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード（34TBメモリ）のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます（詳細は、SAP HANA認定ハードウェアディレクトリのx1.32xlargeインスタンスを参照してください）。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。

メモリ重視のX1ファミリの拡張
お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。

今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、（x1.32xlargeの2倍の）4TBのDDR4メモリ、128個のvCPU（4つの2.3 GHz Intel ® Xeon® E7 8880 V3プロセッサ）、高いメモリ帯域幅および大きなL3キャッシュを提供します。このインスタンスはVPC専用で、レイテンシとジッターを最小限に抑えながら、Elastic Network Adapterを使用して最大20Gbpsのネットワーク帯域幅を提供します。また、デフォルトでEBS最適化が行われており、最大14GbpsのEBSへの専用スループットが設定されます。

いくつかのシェルのスクリーンショットです。最初に、dmesgでブート時のカーネルメッセージを表示します：

次に、lscpuでvCPUとソケット数を他の多くの興味深い項目と共に表示します：

そして、topでは約900のプロセスを表示しています：

SAP HANA Studioの画面です：

以下の図からわかるように、この新しいインスタンスにより、大規模クラスタの認定と合わせて、EC2上でSAPを実行するためのスケールアウトオプションとスケールアップオプションの組合せを広げます。

長期的なメモリ重視のロードマップ
大規模なSAP導入の計画にはかなりの時間がかかることも分かっているので、ロードマップの一部を共有したいと考えています。

現在、サードパーティのコロケーション施設でより大規模なSAP HANA認定サーバを稼働させ、AWS Direct Connectを使用してAWSインフラストラクチャに接続することができますが、お客様は既に利用されているX1インスタンスのようなクラウドネイティブソリューションを必要としていると仰っています。

このご要望を満たすために、私たちはより多くのメモリを持つインスタンスを計画しています！2017年から2018年にかけて、8TBから16TBのメモリのEC2インスタンスを提供する予定です。これらの今後のインスタンスは、x1e.32xlargeと共に、より大きなシングルノードのSAP導入およびマルチノードのSAP HANAクラスタの作成、さらに他のメモリ重視のアプリケーションやサービスの実行を可能にします。また、小規模なインスタンスで限界に達するときに役立ついくつかのスケールアップへの余力も提供します。

できるだけ早く私たちの計画に関する詳細情報を共有していきます。

SAPPHIREで会いましょう
AWSは、SAPPHIREの539番ブースに出展しており、ブース内のシアターで私たちのチームやお客様、パートナーからの一連のセッションを予定しています。また、イベントを通じて多くのセッションに関与しています。例えば以下のようなものです（詳細は、SAP SAPIRE NOW 2017を参照してください）。

SAP Solutions on AWS for Big Businesses and Big Workloads – 5月17日水曜正午から、Bas Kamphuis (General Manager, SAP, AWS)とEd Alford氏 (VP of Business Application Services, BP)が講演

Break Through the Speed Barrier When You Move to SAP HANA on AWS – 5月17日水曜午後12時30分から、Paul Young氏 (VP, SAP)とSaul Dave氏 (Senior Director, Enterprise Systems, Zappos)が講演

AWS Fireside Chat with Zappos (Rapid SAP HANA Migration: Real Results) – 5月18日木曜午前11時から、Saul Dave氏 (Senior Director, Enterprise Systems, Zappos)とSteve Jones (Senior Manager, SAP Solutions Architecture, AWS)が講演

— Jeff;

追伸 – もし、SAPの経験をお持ちで、そのキャリアをクラウドで活かしたい場合は、プリンシパルプロダクトマネージャー（AWSクイックスタート）とSAPアーキテクトのポジションにご応募ください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。

今年のNVIDIAのGPU Technology Conferenceにて、AWSとNVIDIAはいくつかのイニシアチブにおいてパートナーとなりました。1つ目はとてもワクワクしている最新のVoltaベースのGPUインスタンスで、LSTMの学習が3倍高速になるように、AI開発者が接する世界を完全に別物にしてしまうと我々は考えています。2つ目は、AWSで動いているDeep Learning Institute (DLI)を通じて10万人以上の開発者をトレーニングする計画を発表しました。3つ目として、広い開発者コミュニティのために深層学習を大規模にスケール可能とするツールの共同開発です。

GTCでAWSは複数のセッションを行っており、Apach MXNetを使ってAmazon EC2のP2インスタンス上で学習をスケールさせたり、NVIDIAのJetson TX2 platformを使ってエッジ上でモデルを動かしたりしています。以下が今回の重要なパートナーシップと素晴らしいイノベーションの内容になります！

Volta – インスタンスとしてあなたの側にやってくる

Tesla V100はVoltaアーキテクチャベースで640のTensor Coreを備え、混合精度の深層学習において120テラフロップスという素晴らしいパフォーマンスを提供します。AWSはV100をAmazon EC2インスタンス上でサポートできるということに非常にワクワクしています。このサポートが意味するところは、成長しつづける深層学習のコミュニティがスパコン級の能力を活かしてより深いモデルを学習し、AIの限界を押し広げることができるということです。また、NVIDIAとのコラボレーションによって、AWSのエンジニアと研究者はApache MXNetのNeural machine translation (NMT)アルゴリズムを先行して最適化することができました。これによって開発者はVoltaベースのプラットフォーム上で可能な最も速い手法で学習をすることができます。まとめると、Voltaベースのインスタンスが開発者にとってとても人気のあるものになると期待しています！

深層学習を世界中の10万人以上の開発者に届ける

NVIDIAとパートナーとなって、AWS上でDeep Learning Instituteのコースを提供できることを嬉しく思います。DLIは、自動運転車、ヘルスケア、ウェブサービス、ロボティクス、動画分析、そして金融サービス等のための深層学習の応用利用をカリキュラムに含める様に拡大しています。カリキュラムには、講師主導のセミナー、ワークショップ、そして講座が含まれ、アジア、ヨーロッパ、アメリカに渡る開発者にリーチしようとしています。AWSのグローバルインフラストラクチャは42のアベイラビリティゾーン(8つの追加が計画中)と16のリージョン(3つがさらに計画中)を持っているので、AWSは多様な開発者達にリーチするのに最適なインフラストラクチャプラットフォームであります。

深層学習の人達に簡単な利用とスケールを届ける

昔は、深いネットワークを学習するために必要なレベルのパフォーマンスを得るためには、国立の研究所にあるスーパーコンピュータにアクセスする必要がしばしばありました。また、それを使うにはmessage passing interface (MPI)といった分散コンピューティングライブラリを理解して、複数のライブラリやいくつか依存するパッケージをセットアップできることが要求されました。スケーラブルな深層学習を開発者にとって簡単に使えるようにするというゴールに集中するために、AWSはNVIDIAとパートナーとなって最適化された開発者ツールを作ることにしました。これらのツールは、cuDNN、NCCL、TensorRT、そしてCUDA toolkitといったNVIDIA Deep Learning SDKライブラリを使ってビルドされています。開発者がこれらのツールを使うことで、もっと簡単に大量のGPUを数千万インスタンス時間規模でほとんどオーバーヘッドなくスケールできるということを見てきています。

クラウドからエッジへ深層学習を持ち込むためにコラボレーション

低電力デバイス上でのエッジの深層学習は、今日の深層学習の最も大きいトレンドの1つになります。レイテンシを抑えらることや、ネットワーク可用性のためのデータ局所性等、エッジにあるデバイス上でモデルを実行したい理由はたくさんあります。今週のGTCのAWSセッションにおいて、我々はP2インスタンス上で最新のモデルをどのように学習できるかをお見せします。また、最先端の人工知能の能力を低電力デバイスに持ち込むために、Jetson TX2 platformを含む多様な低電力デバイス上にどれだけ簡単にそのモデルをデプロイできるかもお見せしました。そして、AWS IoTやAWS Greengrassといったサービスを通じてこれらのデバイスを管理することができるので、end-to-endのAIワークフローを提供することができます。

さらに学ぶには

• GTCのAWS深層学習セッションをご確認下さい
• AWS Marketplace上のAWS Deep learning AMIを使って、今すぐ始めましょう

原文: AWS and NVIDIA Expand Deep Learning Partnership at GTC 2017 (翻訳: SA岩永)

AWS の拡大が進むに連れて、お客様へ提供するサービス価値も高めて行けるように努めています。サプライヤと協力してコスト低減を実現しながら、今まで以上に効率的でコスト効率が良い方法でハードウェアやソフトウェアを構築できるようにしています。定期的そして頻繁にコスト低減を行っているほか、お客様が AWS を利用する上で最適化できるオプションもご提供しています。たとえばリザーブドインスタンス (2009 年にリリース) は、オンデマンド料金に比べ Amazon EC2 ユーザーに大幅な割引を提供します。また、特定のアベイラビリティーゾーンで使用するキャパシティー予約においても同様です。AWS をご利用のお客様は様々な方法でリザーブドインスタンスを購入し管理されています。前払いでより大幅な値下げを利用するお客様もいれば、最初に何も払わずに小さな (とはいっても、かなりの額にはなりますが) 割引をご利用されるお客様もいらっしゃいます。また、その中間を取って一部前払いして先述の 2 つのオプションの間に位置する割引料金をご利用され、満足されている方もいます。このようにお客様の幅広い好みにお応えすべく、AWS では大半の現行世代のインスタンスタイプを対象に 3 年契約の前払いなしスタンダードリザーブドインスタンスをオプションを追加しました。さらに、前払いなしリザーブドインスタンス、コンバーティブルリザーブドインスタンス、汎用 M4 インスタンス (オンデマンドおよびリザーブドインスタンス) の料金の値下げも行うことになりました。これで 61 ^回目の AWS 料金の値下げとなります。詳細はこちらをご覧ください (すべての変更および値下げは即座に有効になります)。3 年契約のスタンダード RI で前払いなしのオプションを追加 – これまでは 1 年契約のスタンダード RI で前払いなしのオプションをご提供していました。そして本日より、3 年契約の C4、M4、R4、I3、P2、X1、T2 スタンダードリザーブドインスタンスで前払いなしのオプションも開始しました。前払いなしリザーブドインスタンスの料金を低く設定 – C4、M4、R4、I3、P2、X1、T2 インスタンスタイプで、前払いなし 1 年契約のスタンダードと 3 年契約のコンバーティブルリザーブドインスタンスを対象に、最大 17% までの料金値下げを行いました。新しい料金はインスタンスタイプやオペレーティングシステム、リージョンにより異なります。いくつかのリージョンにおける Linux の前払いなしリザーブドインスタンスの平均値下げは次の通りです。

コンバーティブルリザーブドインスタンスをより安価に – コンバーティブルリザーブドインスタンスはインスタンスファミリーや RI と関連のある他のパラメーターをいつでも変更できるようにします。これにより、アプリケーションの展開や変更の必要が発生した場合に RI インベントリを調整することができます。3 年契約のコンバーティブルリザーブドインスタンスの料金を大方の現行世代のインスタンス (C4、M4、R4、I3、P2、X1、T2) で、最大 21% まで値下げしました。いくつかのリージョンにおける Linux のコンバーティブルリザーブドインスタンスの平均値下げは次の通りです。

このような値下げは、その他ほぼすべてのリージョンでも有効になる予定です。M4 インスタンスをより安価に – M4 Linux インスタンスの料金を最大 7% まで引き下げました。新価格については EC2 リザーブドインスタンスの料金表ページと EC2 料金表ページまたは AWS 料金表 API をご覧ください。詳細 次のブログは EC2 リザーブドインスタンスモデルに追加した改良点の詳細情報について説明しています。

• 「EC2 リザーブドインスタンスの新たなインスタンスサイズの柔軟性 (New – Instance Size Flexibility for EC2 Reserved Instances)」 – このブログはインスタンスファミリーやリージョン内で複数のインスタンスサイズに単一の RI を使用する方法について説明しています。
• 「EC2 リザーブドインスタンスの更新 – コンバーティブル RI のリージョン別メリット (EC2 Reserved Instance Update – Convertible RIs and Regional Benefit)」 – このブログはリージョン別メリットと (リージョン内でどの AZ でもインスタンスを実行できるように、キャパシティーの予約を適用しない) インスタンスファミリーや他のパラメーターの変更を許可するコンバーティブル RI について説明しています。
• 「EC2 リザーブドインスタンスモデルを単純化 (Simplifying the EC2 Reserved Instance Model)」 – このブログは 3 つの支払いオプションを紹介しています (全前払い、一部前払い、前払いなし)。

詳細は AWS 料金表やリザーブドインスタンスのよくある質問をご覧ください。

— Jeff;

私達はAWS re:InventでFPGA搭載F1インスタンスの開発者プレビューを開始しました。 この発表に対する反応は素早く圧倒的でした！私たちは2000件以上のエントリーを受け取り、200人以上の開発者にハードウェア開発キット(HDK)と実際のF1インスタンスへのアクセスを提供することができました。

当時私が書いた記事で、私はこのように述べました：

この高度に並列化されたモデルは、計算集約型の問題を処理するカスタムアクセラレータを構築するのに理想的です。 適切にプログラミングされたFPGAは、ゲノム解析や地震解析、財務リスク分析、ビッグデータ検索、暗号化アルゴリズムなど多くのタイプのアプリケーションに30倍のスピードアップを提供する強力な能力を備えています。

プレビュー中に、パートナーや開発者はあらゆる種類の刺激的なツール、サービス、アプリケーションを開発しています。 それらについてちょっとだけ詳細を紹介します。

一般提供開始

本日、米国東部（バージニア州北部）リージョンでF1インスタンスの一般利用を開始しました、多くの時間が経過する前に他のリージョンにも展開する予定です。

私達は、プレビュー中にフィーチャーや機能を追加し、開発ツールをより効率的に使いやすくしました。 下記が概要です：

開発者コミュニティ – AWS FPGAデベロッパーフォーラムを立ち上げ、FPGA開発者が私たちとやりとりしたり、互いにやりとりする場所を提供しました。

HDKとSDK – EC2 FPGAハードウェア(HDK)とソフトウェア開発キットをGitHubに公開し、プレビュー中に受け取ったフィードバックに応じて多くの改善を行いました。

この改善には、Verilogに加えてVHDL (バーチャルJTAG、バーチャルLED、バーチャルディップスイッチ)、FPGA管理用のAWSライブラリ、FPGAランタイム、AWS OpenCLランタイムライブラリを含むOpenCLのサポートが含まれます。

FPGA Developer AMI – このMarketplace AMIには、RTLコンパイラとシミュレータ、OpenCL開発用 Xilinx SDAccelのフルセットのFPGA開発ツールが含まれており、C4、M4、R4インスタンスで使用するために全てチューニングされています。

FPGAのワーク

ここでは、我々のパートナーがF1で行っている印象的なものを紹介します。

Edico Genomeは、リアルタイムで実行される全ゲノムシーケンシングを提供することを期待して、F1インスタンスにDRAGEN Bio-ITプラットフォームを導入しています。

Ryftは、Elastic Stackを拡張したデータ解析と機械学習のアクセラレータであるRyft Cloudを提供しています。 Amazon Kinesis、Amazon Simple Storage Service(S3)、Amazon Elastic Block Store(EBS)、およびローカルインスタンスストレージからのデータをソースとし、大量のビット並列処理を使用してパフォーマンスを向上させます。 この製品は、低レベルのC、C++、Java、およびPython APIとともに、高度なJDBC、ODBC、およびRESTインターフェイスをサポートしています (詳細については、Ryft APIページを参照してください)。

Reconfigure.ioは、Goプログラミング言語を使用してFPGAをプログラムできるクラウドベースのサービスを開始しました。 goroutines (軽量スレッド)、channels、selectsなどの並行性指向の言語機能を活用しながら、クラウドベースの環境からコードをビルド、テスト、展開することができます。

NGCodecはRealityCodecビデオエンコーダをF1に移植し、ブロードキャスト品質のビデオを毎秒80フレームで生成するために使用しました。 彼らのソリューションは、1つのF1インスタンスで最大32の独立したビデオストリームをエンコードすることができます（詳しくは、彼らの新しい投稿、You Deserve Better than Grainy Giraffes、を読んで下さい)

学校と研究のFPGA

トップクラスの大学の研究グループと大学院のクラスは、AWS Educateを通じて我々に連絡し、F1インスタンスにアクセスすることを熱望していました。

UCLAのCS133クラス（パラレルおよび分散コンピューティング）は、3〜4週間以内に運用可能なF1ベースのFPGAラボを設立しています。 UCLAチャンセラーのジェイソン・コング教授によると、FPGA性能のデバッグ、機械学習の加速、SparkからFPGAへのコンパイル、およびシストリックアレイのコンパイルなど、F1をカバーするための複数の研究プロジェクトが展開されています。

先月、我々は、大規模なデータ研究の革新を促進するためにNSF(National Science Foundation)と協力していることを発表しました（助成金を申請する方法を見つけるためにAWSがNational Science Foundationと共同で革新を促進します）

AWS MarketplaceのFPGA

オリジナルの記事で共有したように、我々は開発者がFPGAを利用したアプリケーションやサービスを構築し、AWS Marketplaceに掲載するための完全なソリューションを構築しました。どのような種類のクールなものがそこに現れるのか、私は待つことができません！

— Jeff;

原文：EC2 F1 Instances with FPGAs – Now Generally Available (翻訳:SA小川)

AWS Identity and Access Management（IAM）ロールを利用すると、Amazon EC2上で動作するアプリケーションは一時的なセキュリティ資格を使用することにより安全に稼働することができます。また、アプリケーションが使用するAWSセキュリティ資格情報を利用者が管理する必要がないため、アプリケーションがインスタンスから安全にAPIリクエストが発行できます。先日、AWS CLI, AWS SDKを使用し、既存のEC2インスタンスにIAMロールを付加することで、アプリケーションに一時的なセキュリティ資格情報を使用できるようになりました。詳細は、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」を確認下さい。

そして今日から、EC2コンソール(マネージメント コンソール)からも、既存のEC2インスタンスにIAMロールをアタッチできるようになりました。 EC2コンソールを使用して、既存のインスタンスにアタッチされたIAMロールを置き換えることもできます。 このブログ記事では、EC2コンソールから既存のEC2インスタンスにIAMロールを割り当てる方法を示します。

EC2コンソールから、既存のEC2インスタンスにIAMロールをアタッチする

EC2コンソールから既存のEC2インスタンスにIAMロールを添付するには：

1. EC2コンソールに移動します

2. ナビゲーションペインでInstancesを選択します。

 3. IAMロールをアタッチするインスタンスを選択します。 IAMロールがまだアタッチされていないことを確認するには、インスタンスの[Description]タブのIAMロールの値が空であることを確認します。

4. [Actions]を選択し、[Instance Settings]を選択して、ドロップダウンリストから[IAMロールのアタッチ/置換]を選択します。

5. [Attach / Replace IAM role]ページから、添付するロール（この例ではEC2Role1を選択します）をドロップダウンリストから選択します。

注意：”Create new IAM role (新しいIAMロールの作成)”を選択することで、新しいロールを作成することもできます。 詳細については、「IAMコンソールを使用してIAMロールを作成するには」を参照してください。

6. IAMロールを選択したら、「Apply」を選択して次のステップに進みます。

私の場合、次のスクリーンショットに示すように、IAMの役割はEC2インスタンスに正常にアタッチされました。

ロールが目的のEC2インスタンスに関連付けられていることを確認するには、インスタンスの詳細ページに移動します。次のスクリーンショットのようにEC2Role1がIAMロールであることが確認できます。

この投稿に関するコメントがある方は、下記の「コメント」セクションに投稿頂きますと助かります。 ご質問やご提案がありましたら、IAMフォーラムの新しいスレッドからお問い合わせください。

– Mari

翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

2010 年に、EC2 インスタンスでのリソースへのタグ付け およびその他の EC2 リソースが発表されました。その発表以来、リソースあたりのタグ付けできる数が 10 から 50 へ引き上げられ、また、リソースグループとタグエディタの導入により、タグはより役に立つものとなりました。お客様はタグを使用して、所有権の追跡、コスト計算の処理の向上、コンプライアンスプロトコルの導入、および IAM ポリシーからのアクセスとリソースの管理などを行っています。AWS のタグ付けモデルでは、リソース作成とリソースのタグ付けという別個の機能を提供しています。これは柔軟性が高く、多くのユーザーに役立ってきましたが、リソースがタグ付けされていない状態で存在すると、時間枠が小さくなります。2 つの異なる機能を使用すると、リソースの作成だけは成功してもタグ付けが失敗し、リソースがタグ付けされていない状態になってしまいます。以下の 4 つの新たな機能により、タグ付けをより柔軟で役に立つ仕方で行えます。作成時のタグ付け – EC2 インスタンスと EBS ボリュームのタグはリソースを作成する API 呼び出しの一部として指定できます。タグの使用の強制 – EC2 インスタンスまたは EBS ボリュームの特定のタグは強制的に使用するように IAM ポリシーを記述できます。リソースレベルのアクセス許可 – 皆様からのリクエストにより、 CreateTags と DeleteTags 機能では、IAM のリソースレベルのアクセス許可がサポートされるようになりました。ボリューム暗号化の強制 – 新しく作成された EBS ボリュームに対して、暗号化を強制的に使用するように IAM ポリシーを記述できます。作成時のタグ付け EC2 インスタンスと EBS ボリュームのタグはリソースを作成する API 呼び出しの一部として指定できるようになりました (呼び出しがインスタンスとボリュームの両方を作成する場合は、インスタンスと各ボリュームに異なるタグを指定できます)。リソースの作成とタグ付けは自動的に行われ、オペレーション (RunInstances、CreateVolume、および、リソースを作成するその他の機能) が成功するには、両方が成功する必要があります。インスタンスやボリュームを作成した後に実行するタグ付けのスクリプトを構築する必要はもうありません。EC2 インスタンスを起動するときにタグを指定する方法は以下のとおりです (インスタンスが起動するときに、CostCenter および SaveSnapshotFlag タグも、作成されるすべての EBS ボリュームに設定されます)。

詳細については、「タグの使用」を参照してください。リソースレベルのアクセス許可 CreateTags と DeleteTags では、多くのお客様のリクエストにより、IAM のリソースレベルのアクセス許可がサポートされるようになりました。これにより、既存のリソースのタグキーおよび値をさらに制御できます。また、RunInstances と CreateVolume では、リソースレベルのアクセス許可がさらにサポートされるようになりました。これにより、作成時にリソースにタグ付けできるユーザーおよびグループを制御できます。さらに詳しくは、「AWS CLI または AWS SDK で使用するサンプルポリシー」を参照してください。タグの使用の強制 – 特定のタグを強制的に使用するように IAM ポリシーを記述できます。たとえば、次のような名前が付けられたタグの削除をブロックするポリシーを記述できます: 所有者 または アカウント。または、特定の既存のリソースに新しいタグを作成するのを許可しない「拒否」ポリシーを記述できます。IAM ポリシーを使用して、 Department と CostCenter タグの使用を強制すると、より正確なコスト配分レポートを作成するのに役立ちます。より強力なコンプライアンスとセキュリティポリシーの実装のために、 DeleteTags へのアクセスを、リソースがユーザー名でタグ付けされていない場合に限り制限することもできます。タグの使用を強制する機能により、リソースへのアクセス、所有権、コスト配分を正確に制御できます。以下は、すべての新しく作成されたボリュームに対し、costcenter および stack タグ (それぞれ「115」および「prod」の値を持つ) の使用を要求するステートメントです。

"Statement": [
    {
      "Sid": "AllowCreateTaggedVolumes",
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/costcenter": "115",
          "aws:RequestTag/stack": "prod"
         },
         "ForAllValues:StringEquals": {
             "aws:TagKeys": ["costcenter","stack"]
         }
       }
     },
     {
       "Effect": "Allow",
       "Action": [
         "ec2:CreateTags"
       ],
       "Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*",
       "Condition": {
         "StringEquals": {
             "ec2:CreateAction" : "CreateVolume"
        }
      }
    }
  ]

ボリューム暗号化の強制 新たにサポートされるようになった追加の IAM リソースレベルのアクセス許可を使用して ( RunInstances と CreateVolume)、作成された EBS ブートボリュームまたはデータボリュームに対して、暗号化を強制的に使用するように IAM ポリシーを記述できます。これを使用すると、規制要件に対応でき、エンタープライズセキュリティポリシーを実施し、必要な監査要件に従ってデータを保護できます。以下はサンプルステートメントで、 RunInstances と CreateVolume の IAM ポリシーに組み込み、EBS ボリュームの暗号化を強制できます。

"Statement": [
        {
            "Effect": "Deny",
            "Action": [
                       "ec2:RunInstances",
                       "ec2:CreateVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*"
            ],
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        },

詳細について、また、サンプルポリシーを見るには、「AWS CLI または AWS SDK で使用するサンプルポリシー」および「Amazon EC2 の IAM ポリシー」を参照してください。今すぐ利用可能 ご覧の通り、リソース作成時のタグ付けと新しいリソースレベルのアクセス許可の組み合わせ、およびタグの操作関数により、EC2 リソースへのアクセスを追跡し制御できます。この新しい機能は、AWS GovCloud (US) と China (Beijing) を除くすべてのリージョンで今すぐ利用できます。AWS Management Console、AWS Command Line Interface (CLI)、AWS Tools for Windows PowerShell、または AWS API から、今すぐ使用を開始できます。いずれ、他の EC2 リソースタイプのサポートを追加することも計画しています。詳しくは今後お知らせします。

— Jeff;

去年、AWS が NICE 買収の契約に署名したこと、そして両社が協力し合い高パフォーマンスと科学計算において今まで以上に優れたツールとサービスを開発していく予定であることをブログでお知らせしました。そして本日、NICE EnginFrame 2017 をリリースするに至りました。この製品は AWS Cloud のパワー、スケール、柔軟性を活用する技術的および科学的なアプリケーションのセットアップと実行のプロセスをシンプルにするように設計されています。1 時間以内に、完全に機能する HPC クラスターをセットアップし、シンプルなウェブベースのユーザーインターフェイスを介してアクセスすることができます。すでに EnginFrame を使用している場合は、引き続きオンプレミスで実行したりクラウドに移動することができます。

AWS Inside
クラスター (1 つ以上のクラスターを起動することも可能) は Virtual Private Cloud (VPC) 内にあり、複数の AWS サービスや機能を使用して構築されています。そうした機能とは Amazon Linux AMI、共有 Amazon Elastic File System、NFS スタイルのファイルストレージ、ユーザー認証の AWS Directory Service、トラフィック管理の Application Load Balancers などを実行している Amazon Elastic Compute Cloud (EC2) インスタンスなどです。このようなマネージド型サービスはワークロードや作業に集中しやすくすることができます。システムソフトウェアのアップグレード、パッチ、処理やストレージのスケーリング、そして自分でクラスターを構築した場合に伴うその他の責任などを心配する必要がありません。EnginFrame は AWS CloudFormation テンプレートから起動します。パラメーター化し自己完結型のテンプレートは、起動する各クラスターが同じ様に設定されることを確実にします。テンプレートを実行すると 2 つの異なる CloudFormation スタック (AWS リソースの集合) が作成されます。

Main Stack – このスタックは自分のクラスターが共有している EFS ベースのストレージと、デフォルトのクラスタースタックへの受信リクエストをルートするアプリケーションロードバランサーをホストします。このスタックは IAM ロールや SSL 証明書のセットアップや管理を担う一連の AWS Lambda 関数のホストでもあります。

Default Cluster Stack – このスタックはメインスタックが管理し、手間の掛かるタスクを処理する場所になっています。このクラスターは CfnCluster によりサポートされています。不要になったコンピューティングノードを終了することで必要に応じてスケールアップやスケールダウンを行うことができます。EnginFrame も実行します。

EnginFrame ポータル
クラスターを起動すると、ウェブベースの EnginFrame ポータルを使用して連係動作します。このポータルはアプリケーション (バッチとインタラクティブの両方) とデータ、ジョブへのアクセスを許可します。ご自分 (もしくはクラスターの管理者) は、バッチアプリケーションや特定のファイルタイプに関連付けられているアクションのテンプレートを作成することができます。EnginFrame にはジョブの出力を追跡できるようにするインタラクティブなファイルマネ―ジャとスプーラービューが含まれています。このリリースで、NICE は同時に複数のファイルをアップロードできるようにする新しいファイルアップローダーを追加しました。ファイルアップローダーは一般的によく使用されているファイルをキャッシュすることでアップロード時間を削減することもできます。

EnginFrame の実行
EnginFrame を詳しく理解するために AWS で使用する EnginFrame のクイックスタートのページを開始してみました。リージョンには US East (Northern Virginia) リージョンを選択し [Agree and Continue] をクリックしました。

自分の AWS アカウントにログインし CloudFormation コンソールにアクセスしました。CloudFormation テンプレートの URL はすでに入力済みだったので [Next] をクリックしました。

スタックを設定します。名前を指定しネットワーク設定をセットアップしてパスワードを入力しました。

EC2 キーペアを選び自分のクラスター用に設定をセットアップしました (EC2 の新しいユーザーであれば、まず作成してからダウンロードする必要があります)。[Next] をクリックします。

足跡のためにタグ (キーと値) を入力します。ただしこの場合は IAM ロールとアドバンスドオプションはそのままにし、もう一度 [Next] をクリックします。

次のページで設定を確認し (ここでは表示していません)、CloudFormation が私の代わりにいくつかの IAM リソースを作成することを了承します。次に [Create] をクリックします。

CloudFormation が必要な AWS リソースをすべて作成、設定、連係させます (このプロセスは約 30 分ほど掛かるので犬の散歩をするのに丁度いいでしょう‘）。

EnginFrame クラスターのステータスが CREATE_COMPLETE になったらそれをクリックし Output のセクションを開いて EnginFrameURL を探します。

URL は自己署名の SSL 証明書を使用する Application Load Balancer を参照するようになっているので、意図的にそのサイトにアクセスすることを確認する必要があります。

今起動した CloudFormation で EnginFrame が実行しています。ユーザー名 efadmin とスタック作成時に設定したパスワードでログインしました。

この時点でサービスを作成することができます。最初はまずシンプルに、アップロードしたファイルを圧縮するだけのサービスにしました。青色のタイトルバーで [Admin’s Portal] をクリックし、次にアクセスします。

[Manage] > [Services] > [New] をクリックしてサービスを定義します。

[Submit] をクリックし [Job Script] タブを選択したらデフォルトスクリプトにラインを追加し [Close] をクリックしてアクションウィンドウを閉じます。

新しいサービスを保存し [Test Run] をクリックして希望通りに動作するか確認します。デスクトップからファイルをアップロードし [Submit] をクリックしてジョブを起動します。

ジョブが私のクラスターで実行するようにキューが登録されます。

今回紹介したのは EnginFrame の機能のごく一部に限ります。

可用性と料金
EnginFrame 2017 は今すぐご利用いただけます。お支払いいただくのは使用した分の AWS リソース (EC2 インスタンス、EFS ストレージなど) となります。評価期間の最初の 90 日は無料で EnginFrame をご利用いただけます。その後は同時ユーザー数をベースにライセンスの元で EnginFrame をご利用いただけます。

— Jeff;