Amazon Web Services ブログ

最近の AWS リリースと公開した内容について

過去にも触れましたが、AWS ブログチームは皆さんが膨大な情報に圧倒されることなく、できる限り多くの AWS リリースや公開した内容について把握して頂けるように努めています。バランスを上手く取るため、定期的に新しい情報を皆さんにお届けし、こちらのリストも片付けるようにしています。今日ご紹介するのは次の通りです。

  • S3 オブジェクトのクロスリージョンレプリケーションをモニタリング
  • スポットフリーインスタンスのタグ
  • 12 のサービスとの PCI DSS コンプライアンス
  • WorkDocs の HIPAA 利用資格
  • VPC サイズ変更
  • AppStream 2.0 グラフィックデザインインスタンス
  • ServiceNow の AMS コネクタアプリ
  • クラウド内の Regtech
  • 新しく改訂されたクイックスタート

では、早速始めましょう。

S3 オブジェクトのクロスリージョンレプリケーションをモニタリング
S3 クロスリージョンレプリケーションについては数年前に説明しました。その時には、ソースバケットでバージョニングを有効にし、指定するリージョンとバケットを選択するだけでした。手動でレプリケーションのステータスを確認したり、ソースとデスティネーションバケットのインベントリ (毎日または毎週) を作成することができます。

クロスリージョンレプリケーション監視 (略名: CRR Monitor) ソリューションは、リージョンに渡るオブジェクトのレプリケーションステータスを確認し、ほぼリアルタイムでメトリクスやエラー通知を提供します。

詳細については「CRR Monitor の導入ガイド (CRR Monitor Implementation Guide)」と「CRR Monitor を導入するための AWS CloudFormation テンプレート (AWS CloudFormation template to Deploy the CRR Monitor)」をご覧ください。

スポットインスタンスのタグ
Spot インスタンススポットフリート (スポットインスタンスのコレクション) は、コンピューティング容量を取っておくためのアクセスを提供します。先日、スポットリクエストの一部としてタグ入力 (キーと値のペア) を許可し、タグを EC2 インスタンスに適用してリクエストを満たせるようになりました。

詳細については「スポットフリート EC2 インスタンスのタグ付け (Tag Your Spot Fleet EC2 Instances)」をご覧ください。

12 のサービスとの PCI DSS コンプライアンス
AWS セキュリティブログで最初に公開しましたが、つい先日 PCI DSS コンプライアンスプログラムに12 件のサービスを追加し、対象サービスの合計数は 42 件になりました。詳細については「コンプライアンスリソース (Compliance Resources)」をご覧ください。

WorkDocs の HIPAA 利用資格
その他のコンプライアンスにおいては、WorkDocs が利用可能なすべての AWS リージョンで Amazon WorkDocs が HIPAA 利用資格と PCI DSS コンプライアンスをアーカイブしたこともお知らせしました。

VPC サイズ変更
この機能は、まとまったアドレスを追加することで既存の Virtual Private Cloud (VPC) を拡張できるようにします。これにより柔軟性が高まるので増加しても対応しやすくなるでしょう。VPC ごとに 4 セカンダリ/16 CIDR まで追加できます。削除し新しく追加することで、セカンダリ CIDR を編集することもできます。VPC を選択しメニューから [Edit CIDRs] を選びます。

次に希望通りに CIDR ブロックを追加または削除します。

詳細については「VPC とサブネット (VPCs and Subnets)」をご覧ください。

AppStream 2.0 グラフィックデザインインスタンス
AMD FirePro S7150x2 サーバー GPU を使用し AMD Multiuser GPU テクノロジーを備えた新しい Amazon AppStream 2.0 のグラフィックデザインインスタンスは、今まで以上にコスト効率良くグラフィックアプリケーションを実行したりストリームすることを可能にしています。インスタンスは 2-16 vCPU と 7.5 GB から 61 GB メモリで 4 つのサイズから利用することができます。

詳細については「ストリーミンググラフィックアプリケーション向けの新しく低コストなインスタンスタイプ、Amazon AppStream 2.0 グラフィックデザインについて (Introducing Amazon AppStream 2.0 Graphics Design, a New Lower Costs Instance Type for Streaming Graphics Applications)」をご覧ください。

ServiceNow の AMS コネクタアプリ
AWS マネージドサービス (AMS) はエンタープライズ向けのインフラストラクチャ操作管理を提供します。これはクラウド導入を加速するように設計されており、リクエスト変更、パッチ管理、セキュリティやバックアップなどよくある操作を自動化することができます。

新しい ServiceNow 用の AMS 統合アプリ は、カスタムデプロイや API 統合なしに ServiceNow から AMS を操作できます。

詳細については「クラウド管理をより簡単に: AWS マネージドサービスと ServiceNow の統合 (Cloud Management Made Easier: AWS Managed Services Now Integrates with ServiceNow)」をご覧ください。

クラウド内の Regtech
Regtech (このブログを書きながら学びました) は regulatory technology の略で、クラウドコンピューティング、分析、Machine Learning といった最新技術を使用して規制上の問題に取り組むことです。

APN コンサルティングパートナー Cognizant と協力し、TABB Group は先日、金融サービスにおける顧客に対し、なぜ規制やコンプライアンスが大きなチャレンジとなるのか、そして AWS がどのように役立つのか説明した思想的リーダーシップのドキュメントを公開しました。

新しく改訂されたクイックスタート
クイックスタートチームは新しいソリューションを次から次へと送り出し、既存のソリューションに向けて重要な更新を作成しています。概要は次をご覧ください。

Alfresco Content Services (v2) Atlassian Confluence Confluent Platform データレイク
Datastax Enterprise GitHub Enterprise Hashicorp Nomad HIPAA
Hybrid Data Lake with Wandisco Fusion IBM MQ IBM Spectrum Scale Informatica EIC
Magento (v2) Linux Bastion (v2) Modern Data Warehouse with Tableau MongoDB (v2)
NetApp ONTAP NGINX (v2) RD Gateway Red Hat Openshift
SAS グリッド SIOS Datakeeper StorReduce SQL サーバー (v2)

今回は以上です。

Jeff;

EC2 スポットインスタンスでワークロードの停止と再開が可能に

EC2 スポットインスタンスは EC2 のコンピューティング容量をオンデマンドレートの 90% オフまで許可することができます。特定のサイズのインスタンス数をリクエストできるようにしてから、スポットフリート自動スケーリングスポットフリートをサポートすることでスポットインスタンスをより便利そして柔軟にし、ユーザーが希望するレベルのコンピューティング容量を維持できるようにしました。

EC2 ユーザーはこれまでも EBS ボリュームをアタッチした状態を維持しながら実行中のインスタンスを停止させることができ、インスタンスの実行が再開すると停止した所から自動的に始めるアプリケーションの使用を可能にしていました。

スポットワークロードの停止と再開
そして本日、こうした 2 つの重要な機能を組み合わせ、容量が利用不可能になった場合または入札価格以下になった場合にインスタンスを停止 (終了する代わりに) することで、スポット入札やスポットフリートをセットアップできるようにしました。停止状態のインスタンスにアタッチしている EBS ボリュームは EBS-backed ルートボリュームと同様にそのまま維持されます。キャパシティが利用可能になるとインスタンスが開始し、アプリケーションのプロビジョニングや EBS ボリュームのセットアップ、データのダウンロード、ネットワークドメインへの参加などに時間を費やす必要なく引き続き実行することができます。

AWS をご利用されている多くのお客様がアプリケーションを強化してチェックポイントの作成と活用を行い、EC2 プロセスでの開始/停止の機能を利用することで耐障害性を向上させています。そうしたお客様はこのようなアプリケーションをスポットインスタンスで実行できるようになり、平均 70%-90% の節約を実現できます。

インスタンスが停止している間、EBS 最適化、ユーザーデータ、Ramdisk ID、Delete on Termination の属性を変更することができます。停止状態にあるスポットインスタンスはコンピューティング時間に対して料金を請求することはありませんが、アタッチ済みの EBS ボリュームの容量には通常料金が適用されます。

スポット入札またはスポットフリートの作成や停止/開始の使用を特定する方法については次をご覧ください。

主要事項
この機能はスポットインスタンスが利用可能なすべての AWS リージョンで今すぐご利用いただけます。これは新しい EC2 インスタンスと EBS ボリュームの秒単位による請求で上手く機能するように設計されており、スポットインスタンスが提供する以上のコスト節約の方法としても可能性があります。

EBS ボリュームは常に特定のアベイラビリティーゾーン (AZ) 内にあります。そのため、スポットとスポットフリートは特定の AZ が常にその AZ で再起動するようにリクエストします。

幅広く様々なインスタンスタイプが含まれている可能性のあるスポットフリートとこの機能を組み合わせる場合はご注意ください。フリートの構成は時間が経過するに連れて変更することもあるので、アカウントの IP アドレスや EBS ボリュームの制限にご注意ください。

この機能を使用した新しくクリエイティブな利用法について皆さんからの声が届くのを楽しみにしています。利用しているアプリケーションがスポットインスタンスには適さないと思っていた方や、中断時に対応するためのオーバーヘッドが高すぎるとお考えの方は、詳しく調べてみることをぜひお勧めします。

Jeff;

AWS CodePipeline, AWS CodeBuild, AWS Lambdaを使ったサーバーレス自動UIテスト

Webアプリケーションのユーザーインターフェイスをテストすることは、開発ライフサイクルの重要なパートです。 この記事では、 AWS CodePipeline, AWS CodeBuild, AWS Lambdaなどのサーバーレス技術を利用してUIテストを自動化する方法を説明します。

S3でホストされているUIテスト用のWebサイトを構築しました。Seleniumを使用して、Chrome、Firefox、PhantomJS、およびWebDriver Wire Protocolの実装であるGhost DriverのヘッドレスWebKitブラウザで、クロスブラウザのUIテストを実行します。 テストが実行されているブラウザに基づいて、Pythonを使ってChromeDriver、FirefoxDriver、またはPhatomJSDriverのテストケースを作成しています。

この記事で紹介するAWS CloudFormationテンプレート、S3でホストされているテストおよびステータスWebサイト、AWS CodeBuildビルドスペックファイル、AWS Lambdaファンクション、テストを行うPythonスクリプトなどのリソースは、 serverless-automated-ui-testing GitHubリポジトリで公開しています。

 

S3にホストされるテストWebサイト: AWS CodeBuildはカスタムコンテナをサポートしているため、FirefoxとChromeブラウザのプレビルドを含むSelenium/standalone-FirefoxとSelenium/standalone-Chromeコンテナをそれぞれ使用できます。 Xvfbは、ディスプレイハードウェアなしで仮想メモリ内でグラフィカルオペレーションを実行します。 XvfbはインストールフェーズでCodeBuildコンテナにインストールされます。

 

Chrome and Firefoxテスト用のビルドスペック
ChromeとFirefoxのテストのビルドスペックには、複数のフェーズがあります:

  • 環境変数セクションには、ビルドプロジェクトの作成時またはビルドのトリガー時にオーバーライドされる一連のデフォルト変数が含まれます。
  • インストールフェーズの一部として、XvfbやSeleniumなどの必須パッケージがyumを使用してインストールされます。
  • pre_buildフェーズでは、テスト実行のためにテストベッドが準備されます。
  • ビルドフェーズでは、適切なDISPLAYが設定され、テストが実行されます。
version: 0.2

env:
  variables:
    BROWSER: "chrome"
    WebURL: "https://sampletestweb.s3-eu-west-1.amazonaws.com/website/index.html"
    ArtifactBucket: "codebuild-demo-artifact-repository"
    MODULES: "mod1"
    ModuleTable: "test-modules"
    StatusTable: "blog-test-status"

phases:
  install:
    commands:
      - apt-get update
      - apt-get -y upgrade
      - apt-get install xvfb python python-pip build-essential -y
      - pip install --upgrade pip
      - pip install selenium
      - pip install awscli
      - pip install requests
      - pip install boto3
      - cp xvfb.init /etc/init.d/xvfb
      - chmod +x /etc/init.d/xvfb
      - update-rc.d xvfb defaults
      - service xvfb start
      - export PATH="$PATH:`pwd`/webdrivers"
  pre_build:
    commands:
      - python prepare_test.py
  build:
    commands:
      - export DISPLAY=:5
      - cd tests
      - echo "Executing simple test..."
      - python testsuite.py

Ghost Driverはヘッドレスで動作するため、AWS Lambdaで実行できます。 Fire-and-forgetモデルに合わせて、CodeBuildを使ってPhantomJS Lambdaファンクションを作成し、Lambdaのテスト実行を並行して起動します。Lambdaで多くのテストを並行して実行できることは強力な機能です。

 

PhantomJS用のビルドスペック

PhantomJSテストのビルドスペックにも、複数のフェーズが含まれています。テスト実行にAWS Lambdaを使用しているため、前の例と少し異なります。

  • 環境変数セクションには、ビルドプロジェクトの作成時またはビルドのトリガー時にオーバーライドされる一連のデフォルト変数が含まれます。
  • インストールフェーズの一部として、SeleniumやAWS CLIなどの必須パッケージがyumを使用してインストールされます。
  • pre_buildフェーズでは、テスト実行のためにテストベッドが準備されます。
  • ビルドフェーズでは、PhantomJS Lambdaファンクションの作成に使用されるzipファイルが作成され、Lambdaファンクションでテストが実行されます。
version: 0.2

env:
  variables:
    BROWSER: "phantomjs"
    WebURL: "https://sampletestweb.s3-eu-west-1.amazonaws.com/website/index.html"
    ArtifactBucket: "codebuild-demo-artifact-repository"
    MODULES: "mod1"
    ModuleTable: "test-modules"
    StatusTable: "blog-test-status"
    LambdaRole: "arn:aws:iam::account-id:role/role-name"

phases:
  install:
    commands:
      - apt-get update
      - apt-get -y upgrade
      - apt-get install python python-pip build-essential -y
      - apt-get install zip unzip -y
      - pip install --upgrade pip
      - pip install selenium
      - pip install awscli
      - pip install requests
      - pip install boto3
  pre_build:
    commands:
      - python prepare_test.py
  build:
    commands:
      - cd lambda_function
      - echo "Packaging Lambda Function..."
      - zip -r /tmp/lambda_function.zip ./*
      - func_name=`echo $CODEBUILD_BUILD_ID | awk -F ':' '{print $1}'`-phantomjs
      - echo "Creating Lambda Function..."
      - chmod 777 phantomjs
      - |
         func_list=`aws lambda list-functions | grep FunctionName | awk -F':' '{print $2}' | tr -d ', "'`
         if echo "$func_list" | grep -qw $func_name
         then
             echo "Lambda function already exists."
         else
             aws lambda create-function --function-name $func_name --runtime "python2.7" --role $LambdaRole --handler "testsuite.lambda_handler" --zip-file fileb:///tmp/lambda_function.zip --timeout 150 --memory-size 1024 --environment Variables="{WebURL=$WebURL, StatusTable=$StatusTable}" --tags Name=$func_name
         fi
      - export PhantomJSFunction=$func_name
      - cd ../tests/
      - python testsuite.py

各ケースに属するテストケースとテストモジュールのリストは、Amazon DynamoDBテーブルに格納されています。

CodeBuildプロジェクトに引数として渡されたモジュールのリストに基づいて、CodeBuildはそのテーブルからテストケースを取得し実行します。テストの実行状況と結果は別のAmazon DynamoDBテーブルに保存されます。 DynamoDBのステータステーブルからテストステータスを読み取り、表示します。
AWS CodeBuildとAWS Lambdaはテストを個別のタスクとして実行します。 AWS CodePipelineは、継続的デリバリーと並列実行によるテストの最適化を可能にするという点で、重要な役割を果たします。

AWS CodePipelineには、以下の4つのステージを持ったパイプラインが作られます:

  • Source (AWS CodeCommit)
  • UI testing (AWS Lambdaと AWS CodeBuild)
  • Approval (手動承認)
  • Production (AWS Lambda)

次の図に、パイプラインステージ、各ステージのアクション、およびステージ間の遷移を示します。

AWS CodePipelineで実装されるデザインは、次のようになります。


CodePipelineはソースリポジトリの変更を自動的に検出し、パイプラインの実行をトリガします。

UITestステージには、2つの並列アクションがあります:

  • DeployTestWebsiteは、S3にテストウェブサイトを展開するためのLambdaファンクションを呼び出します。
  • DeployStatusPageは別のLambdaファンクションを呼び出して、ステータスWebサイトをS3に並列にデプロイします。

次に、CodeBuildプロジェクトを起動する3つの並行アクションがあります:

  • TestOnChromeは、Chrome上でSeleniumテストを実行するためのコンテナを起動します。
  • TestOnFirefoxは、FirefoxでSeleniumテストを実行する別のコンテナを起動します。
  • TestOnPhantomJSはLambdaファンクションを作成し、テストケースごとに個別のLambdaファンクションを呼び出して、テストケースを並列実行します。

次の図のように、ステータスWebサイトでテスト実行のステータスを監視できます:

UIテストが正常に完了すると、パイプラインはApprovalステージに進み、通知が構成済みのSNSトピックに送信されます。指名されたチームメンバーは、テストのステータスを確認し、デプロイを承認または拒否します。承認されると、パイプラインはProductionステージに進み、そこでLambdaファンクションを呼び出し、ウェブサイトをプロダクションS3バケットに配備します。

は、CloudFormationテンプレートを使用して、継続的デリバリーパイプラインを設定しました。 GitHubから入手できるautomated-ui-testing.yamlテンプレートを利用して全機能のパイプラインを設定することが可能です。
テンプレートを使用してパイプラインを作成するときは、次の項目を指定します:

  • AWS CodeCommitリポジトリ
  • 承認通知を送信するSNSトピック
  • 成果物が格納されるS3バケット名


スタック名は、S3バケット名の一部になるため、S3バケット命名規則に従ってください。

スタックが正常に作成されると、次のようにテストWebサイトとステータスWebサイトのURLが[Outputs]セクションに表示されます:

 

まとめ

この記事では、AWS CodePipeline、AWS CodeBuild、AWS Lambda、および手動承認プロセスを使用してサーバーレス自動UIテスト用の継続的デリバリーパイプラインを作成する方法をご紹介しました。 Amazon EC2インスタンスまたはAWS Elastic Beanstalk上で実行されるWebサイトも同様の方法でテストできます。


著者紹介

Prakash PalanisamyはAmazon Web ServicesのSolutions Architectです。 Serverless、DevOps、Alexaを担当する他、Project Eulerでの問題解決をおこなっています。彼はまた、教育ドキュメンタリーを見て楽しんでいます。

(翻訳はSA千葉が担当しました。原文はこちら)

 

EC2 インスタンスと EBS ボリュームで 1 秒あたりによる請求が可能に

以前は処理能力へのアクセスが必要になるとサーバーを購入またはリースしなければなりませんでした。そのため、2006 年に EC2 をリリースした当時、インスタンスを 1 時間だけ使用し、使用した時間の分だけ支払えるようになったことは大きなニュースでした。この従量制モデルにより、お客様は様々なタイプのアプリケーションを開発したり実行するための新しい方法を考えるようになりました。

そして現在、AWS Lambda は短時間で大くの有用な作業を行えることを明らかに示しています。多くのお客様が、場合によっては数分という短時間で大量なインスタンスを活用できる EC2 インスタンスのアプリケーション構築を検討しています。

EC2 と EBS の秒単位による請求
10 月 2 日より、オンデマンド、リザーブド、スポット形式で起動した Linux インスタンスの使用は 1 秒単位で請求されるようになります。同様に、EBS ボリュームのプロビジョニング済みストレージも 1 秒単位で請求されるようになります。

また、1 秒単位による請求は Amazon EMRAWS Batch でも適用されます。

Amazon EMR – より素早く結果を得るために、当社のお客様は独自の EMR クラスターに容量を追加しています。クラスターにおける EC2 インスタンスの 1 秒単位による請求で、今まで以上にコスト効率良くノードを追加できるようになりました。

AWS Batch – お客様が実行するバッチの多くは 1 時間内に完了されています。AWS Batch はすでにスポットインスタンスを起動し終了しており、1 秒単位のバッチ処理はさらに経済的になるでしょう。

より高度な知識を備えているお客様は、ゲーム、テクノロジー、3D レンダリングフリートを管理している際に、最も有益なターゲットインスタンスを戦略的に選ぶことで EC2 から最大の価値を得られるようにするシステムを構築しています。秒単位の請求により、インスタンス管理におけるこうしたレイヤーを 1 つ取り除くことができ、すべてのお客様とワークロードにおいてコスト節約を実現できます。

これにより、多くのワークロードに掛かるコストの低下が見られると思いますが (価格の値下げについてはこちら)、この変更で最も大切なポイントは他にあります。つまり、この変更によりイノベーションを促進しコンピューティング関連の問題を新しい方法で見られるようになるのではないかと我々は考えています。継続的な統合のサポート改善にはどのように活用できますか?開発やテストといったワークロードの一時的な環境をプロビジョニングする方法を変えることはできますか?分析、バッチ処理、3D レンダリングにおいては?

クラウドコンピューティングのメリットの 1 つは、その伸縮性により必要に応じてリソースのプロビジョニングやプロビジョニング解除ができることです。使用量の請求を秒単位にすることで伸縮性を高めたりコスト節約が可能になるので、ユーザーはコンピューティングにおける継続的な向上を促進することができます。

主要事項
この変更は 10 月 2 日より、新たに起動またはすでに実行している Linux インスタンスを対象にすべての AWS リージョンで適用されます。各インスタンスには 1 分間の最低料金が課せられます。

現在、時間単位による請求が課せられている Microsoft Windows や Linux ディストリビューションを実行しているインスタンスには、秒単位による請求が適用されません。

リスト料金とスポットマーケット料金は、まだ時間単位の対象となっていますが、リザーブドインスタンスの使用量と同様に請求額は秒単位で換算されます (1 時間以内に複数のインスタンスを起動、使用、終了し、すべてのインスタンスでリザーブドインスタンスのメリットを利用することができます)。また、請求書には次のように 10 進数の形式で時間が表示されます。

リージョンごとの専用料金、EBS スナップショット、AWS Marketplace のサービスは、まだ時間単位で請求されています。

Jeff;

AWS Greengrassが、アジアパシフィック (東京)リージョンで利用可能になりました。

AWS Greengrassが、アジアパシフィック (東京)リージョンで利用可能になりました。AWS Greengrassが、Java 8、Node.JS 6.10 Lambdaランタイムに対応しました。また、AWS Greengrassで、Lambda関数、サブスクリプション、設定を削除することで、デプロイ済みのGreengrassグループをリセットできるようになりました。

AWS Greengrassは、接続されたデバイスでのローカル・コンピューティング、メッセージング、データと状態の同期を安全な方法で実行できるようにするソフトウェアです。AWS Greengrassによって、接続されたデバイスは、AWS Lambda関数を実行することが可能になります。現在、Python 2.7、Node.JS 6.10、Java 8が利用可能で、開発者に、より適切な言語を選択する柔軟性と、クラウド上のLambda関数との一貫性を提供します。Greengrass上でAWS Lambda関数を実行することによって、IoTデバイスによるローカルイベントへの高速な応答や、不安定なネットワーク環境下での動作を保障します。また、IoTデータのクラウドへの送信コストを最小限に抑えることができます。デプロイ機能のリセットがサポートされ、使用されなくなったGreengrassグループを削除することで、クラウドリソースをクリーンアップでるようになりました。Greengrass Coreをクリーンアップして、デプロイ前の状態に戻すこともできます。この機能によって、Greengrass Coreデバイスからデータを簡単に削除し、それに関連するデータをクラウドから削除することが簡単にできるようになりました。

サポートされているリージョンの一覧は、こちらをご覧ください。

AWS Greengrassの詳細については:
• 製品ページ
• ドキュメント

FAQ

Q: AWS Greengrassサービスは、どのAWSリージョンで利用できますか?

AWS Greengrassは、現在、下記のAWSリージョンで利用可能です。

・ 米国東部(バージニア北部)

・ 米国西部 (オレゴン)

・ 欧州 (フランクフルト)

・ アジアパシフィック (シドニー)

・ アジアパシフィック (東京)

 

AWS Greengrassは、上記のAWSリージョンのいずれかにアクセス可能であれば、ご使用の地域に関係なく利用可能です。

Q: どのLambda用言語をGreengrassにデプロイできますか?

Python 2.7、Node.JS 6.10、またはJava 8 Lambdaランタイムを使用するLambda関数は、Greengrass Coreにデプロイ可能です。GreengrassにデプロイされるLambda関数は、Greengrass Core SDKと一緒にパッケージ化する必要があります。 更に、DynamoDBなどのAWSサービスと簡単にやり取りするために、AWS SDKをLambda関数のパッケージに追加することもできます。

注:Greengrass Coreがオフライン状態の場合、Lambda関数が使用している一部のクラウドサービス(例えば DynamoDB)は、Lambda関数で使用できなくなります。オフライン状態では、これらのサービスへのAPIコールは失敗します。更に、Lambda関数のパッケージにGreengrass Core SDKとAWS SDKの両方を含める場合、各SDKで適切な名前空間を使用する必要があります。

Q: 全てのLambdaランタイム言語をインストールする必要がありますか?

Greengrass Coreで使用する言語のみをインストールする必要があります。

Q: Greengrass Coreを実行するために必要な技術的依存関係は何ですか?

AWS Greengrass Coreは、最小限のハードウェア要件を満たすデバイス上で、幅広いCPUアーキテクチャおよび、オペレーティングシステム上で動作するように設計されています。下記は、Greengrass Coreの実行に必要な依存関係です。

必要なソフトウェアパッケージと構成

  • SQLite – バージョン3以上
  • Python – バージョン2.7以上、 Node.JS 6.10 または、Java 8
  • Glibcライブラリ – バージョン 2.14
  • Linuxカーネル – OverlayFSを有効にしたカーネル・バージョン 4.4.11 以上
  • boto3(最新版)
  • botocore(最新版)
  • OpenSSL – バージョン 1.0.2 以上
  • libseccomp
  • bash

価格
最新情報については、このメールアドレスから、お問い合わせ下さい。AWSIoTSales@amazon.com
デバイス数が1万台を超える場合は、別途、お問い合わせ下さい。

リージョン別の料金設定:3〜10,000台のデバイス
AWS Greengrass には以下の 2 つの料金オプションがあります。 従量制または 22% の割引を受けられる年間契約。

製品およびサービス一覧 (https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)

 

10 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの焼尾です。AWS Black Belt オンラインセミナー10月の配信についてご案内させて頂きます。10月はソリューションカット、サービスカット共に、実践的なネットワークや認証といった内容や、データレイクを支える新サービス AWS Glue の紹介があります。また、企業様の上層部向けの AWS 解説も行います。

10月の開催予定

サービスカット
10/4(水) 18:00-19:00 Amazon GameLift
10/11(水) 18:00-19:00 Amazon Kinesis
10/18(水) 18:00-19:00 AWS Glue
10/25(水) 18:00-19:00 AWS Key Management Service

ソリューションカット
10/3(火) 12:00-13:00 AWSへのネットワーク接続とAWS上のネットワーク内部設計
10/10(火) 12:00-13:00 AWSにおけるアプリ認証パターンのご紹介
10/24(火) 12:00-13:00 エグゼクティブ向けAWS紹介

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

Amazon Redshift の CA 証明書更新についてのおしらせ

2017/09/26 更新: sslMode 設定が require の場合も,CA 証明書更新を行なっていただく必要がある旨を追記しました

Amazon Redshift は現在 CA 証明書の更新作業を行なっており、新しい証明書は AWS Certificate Manager (ACM) が発行したものとなります。これに伴い、現在 Amazon Redshift をご利用中の多くのお客さまにつきまして、Amazon Redshift クライアントの CA 証明書更新作業をお願いすることとなりました。該当するお客様に対しては、すでに Action Required: Amazon Redshift – SSL certificate expiring on October 23rd 2017 という題名のメールが届いているかと思います。

今回の更新作業の対象となるお客様は、以下の条件のすべてに当てはまる方々です。

  • Amazon Redshift クラスターに対して SSL で接続しており、sslMode 設定で require,verify-ca または verify-full を指定されている方
  • GovCloud(米国)、中国(北京)、中国(寧夏)以外のリージョンで Amazon Redshift を利用されている方

上記に該当するお客さまにつきましては、こちらを参考に、CA 証明書の更新を行なってください。対応期限は 2017/10/23 となりますので、早めの対応をお願いいたします。

なお Amazon Redshift ODBC / JDBC ドライバーについては、今後リリース予定の ODBC ドライバー Ver. 1.3.7.1000 および JDBC ドライバー 1.2.8.1005 にて,新しいクライアント CA 証明書に対応する予定となっております.

不明点などがありましたら、AWS サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。

 

 

大阪Cloud Road Showが開幕します。

いよいよ、AWS Cloud Roadshow 2017 powered by Intel®が始まります。

AWS Cloud Roadshow 2017 powered by Intel® は、広島、大阪、名古屋、福岡の 4 都市を巡る無料クラウドカンファレンスです。

明日第二弾大阪を開催いたします。

本イベントでは、各地域で活躍を拡げる著名企業様によるクラウド導入事例セッションや AWS クラウドの最新テクノロジートレンドをご紹介するテクニカルセッションなどを通して、AWS が提供する様々なサービスのベストプラクティスを知ることができます。

見どころのセッションをご紹介します。まずは、基調講演と導入事例トラックの2つです。

基調講演ではIoT GreengrassのServiceTeamよりSatyen Yadavが今後のロードマップについて発表をさせていただきます。

AWSのイベントは学習型イベントであることをかかげていますが、その中でもお客様から直接AWSを使った感想をお話いただくことを重視しています。そのセッションの中でも

2017/9/21 16:20 ~ 17:00 導入事例トラック
【パネルセッション】関西企業事例に学ぶ AWS で実現するデータベースマイグレーション」

は実際にAWSへデータベースをマイグレーションいただいたお客様にご登壇いただくパネルディスカッションとなっています。弊社西日本担当の柳生がモデレータを務めさせていただきます。

AWSでは多くのマイグレーション系のツールをご準備しています。その纏めのスライドを以下に転載しますので合わせて読んでみていただくとより理解が深ると思います。

なぜマイグレーション系のツールが必要となるのでしょうか。システムは立ち上げ当初はそのすべてが管理者により正しく管理され、全てが把握されています。しかし、時間の経過とともに、パッチが適応され、アプリケーションはバージョンアップを繰り返します。システムマイグレーションでは、まず最初のステップとしてシステムの全容の把握が必須となりますが、これがかなり大変な作業となります。AWSの各マイグレーション系のツールはこれらの作業をより簡便にするための機能を備えています。

例えばDMS(Database Migration Service)では、機械的に移設可能なデータベースのテーブルやスキーマなどを洗い出し、手作業が必要な部分を洗い出してくれます。また異なるデータベースエンジン間の移行をサポートすることにより、たとえば商用データベースからクラウド上のOSSベースのデータベースへの移設プロジェクトや同データベースエンジンにおける異なるバージョン間の移設プロジェクトをサポートします。

SMS(Server Migration Service)は2種類の使い方が可能となっています。メインのサーバ移行を行う場合と、AWS上にDRを構築する場合です。メインサーバの移設であれば、vCenter経由で仮想化されたサーバの移設が機械的に可能です。一方DR用途でマイグレーションを行う場合、日々変動するデータなどの差分移行が必要となります。従来のVM Import/Exportツールと異なり、差分移行をサポートしているのがSMSの大きな特徴です。

それらの使い勝手などお客様の声を是非直接聞いてみてください。

またサーバレスを中心としたお客様事例もあります。

そして最後はJAWS UG Nightがあります。今年は600名を超えるお申し込みをいただき、300名を超える規模で開催されます。秋の大運動会として、JAWS 初の大型ライブコーディング競技が開催される予定です。また、競技中に併設してAWSの最新アップデート纏めのセッションも予定されいます。

当日申し込みもできますので是非お越しください。

それではみなさんにお会いできることをAWSチーム一同おまちしております。

– プロダクトマーケティングエバンジェリスト 亀田 治伸

ディープラーニングネットワーク (GAN と Siamese) を組み合わせハイクオリティでリアルなイメージを生成

ディープラーニングはトレーニングに使用するデータの量と質に依存するため、企業は優れたイメージデータを得ようと多額の費用を投資をしています。通常、そうした企業はコストの掛かる人間による注釈を使ったり、製品や人物の写真を撮るなど、多大な作業を要しています。けれども、このアプローチはコストが掛かる上に拡張性もありません。コンピュータをトレーニングしてハイクオリティなイメージを生成すれば、コストを大幅に削減しビジネスの成長を促進することができます。

このブログ記事では、Amazon の私の同僚数人がまとめた「Semantically Decomposing the Latent Spaces of Generative Adversarial Networks」という学術論文で取り上げられているコンセプトを分かりやすく説明します。この論文は、Semantically Decomposed GANs (SD-GANs) の使用を可能にするため、Generative Adversarial Networks (GANs) と Siamese Networks (SNs) を実際に適用する場合について説明しています。

GANs と SNs は比較的高度なディープラーニングシンボルで、現実的な問題を解決するために各自または他のディープラーニングシンボルと組み合わせて使用することができます。こうしたシンボルを組み合わせると、AI アプリケーションは難しく複雑なビジネス上の問題をより多く解決できるようになります。たとえば、AI の主なチャレンジの 1 つは注釈やタグ付けしたデータの欠如です。ハイクオリティな注釈データには多大なコストが掛かるため、これを利用できるのは大規模で経済的に余裕のある企業に限られています。この論文で説明されているようなディープラーニングの方法を使うと、より多くの企業が質の高いデータを少ないサンプルから生成することが可能になります。

リアルなイメージを分析するために作成者が GANs や SNs そして SD-GANs をどのように使用し、同じ人物やオブジェクトのコントロールしたバリエーションで「偽」のイメージを生成する方法を説明します。パラメータやあなたが設定した「監視プロパティ」により、偽のイメージを別の視点から作成したものに見せたり、別の照明や、より良質な解像度を使用、もしくはそれに似たようなバリエーションを使用したかのように見せることができます。この論分で説明されているイメージ分析を使用すると、プロがフォトショップで加工したもの、または 3D モデルを使用して作成したかのように、実にリアルなイメージを作成することができます。

図 1: 論文で説明されている方法を使用して生成したサンプル各行は同じ顔のバリエーションを示しています。各列は同じ監視プロパティを使用しています。

Generative Adversarial Networks とは?

Generative Adversarial Networks (GANs) は、ニューラルネットワークの比較的新しいディープラーニングアーキテクチャです。これは 2014 年にカナダのモントリオール大学の Ian Goodfellow 氏と同僚達により開発されました。GAN は 2 つの異なるネットワークを敵対的にトレーニングするため、敵対的 (adversarial) と呼ばれています。ネットワークの 1 つが、実像を撮りできる限りの変更を加えることで、イメージ (またはテキストやスピーチなど他のサンプル) を生成します。そして、もう 1 つのネットワークは、そのイメージが「偽」か「本物」かを予測しようとします。G ネットワークという最初のネットワークは、より優れたイメージを生成することを学びます。D ネットワークという 2 つめのネットワークは偽のイメージと本物のイメージを見分けることを学びます。この判別力は徐々に改善されていきます。

(more…)

今すぐ利用可能 – 4TBメモリ搭載のEC2インスタンス

今年の初めに、最大16TBメモリ搭載のEC2インスタンスを提供する計画をお伝えしました。本日、4つのAWSリージョンで4TBのDDR4メモリを搭載した新しいx1e.32xlargeインスタンスが利用可能になったことを発表いたします。以前の記事で書いたように、これらのインスタンスは、SAP HANAなどのメモリ重視のインメモリアプリケーションのために設計されています。 既に多くのお客様が、既存のx1.32xlargeインスタンス上で本稼働SAPアプリケーションを実行しています。本日のリリースによって、これらのお客様は、より大きなデータセットを保管・処理できるようになり、非常に大規模な本番環境でも稼働できるようになりました。

x1e.32xlargeは、x1.32xlarge同様に、4ソケットのIntel Xeon E7 8880 v3 Haswellプロセッサ 2.3GHz (128vCPUs)で実行され、大きなL3キャッシュやメモリ帯域幅を持ち、CステートとPステート制御による最適なパフォーマンスを提供します。

ネットワーク面では、インスタンスごとに最大8つのElastic Network Interfaces(ENIs)をサポートし、Elastic Network Adapter(ENA)によって、EC2プレイスメントグループ内で起動したときに最大25Gbpsのネットワーク帯域幅を提供します。インスタンスはデフォルトでEBS最適化されており、EBSボリューム専用の14Gbpsの帯域幅があり、インスタンスあたり最大80,000IOPSをサポートします。インスタンスには、1,920GBのSSDボリュームのペアも含まれています。

【いくつかのメモ】
x1e.32xlargeに関して、いくつか覚えておくべき事項があります:

SAP認定 – x1e.32xlargeインスタンスは、SAP Business Suite on HANA(SoH)、SAP Business Warehouse on HANA(BWoH)、次世代ERPであるSAP S/4HANAや次世代データウェアハウスソリューションであるSAP BW/4HANAの本稼働HANA環境としてSAP社から認定およびサポートされる大規模なクラウドネイティブインスタンスです。もし、お客様が既にX1インスタンスでSAP HANAワークロードを実行されているのであれば、迅速かつ容易にスケールアップすることができます。SAP HANA on the AWS Cloud Quick Start Reference Deploymentは更新済みで、SAPとAWSのベストプラクティスに従って高い性能と信頼性を実現した構成の導入を支援します。SAP HANA Hardware DirectorySAP HANA Sizing Guidelinesも関連しています。

リザーブドインスタンス – リザーブドインスタンスのリージョン単位の柔軟性は、x1とx1eには適用されません。

【今すぐ利用可能】
x1e.32xlargeインスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、そしてアジアパシフィック(東京)リージョンで、AWS Management ConsoleAWS Command Line Interface(CLI)AWS SDKs、あるいはAWS Marketplaceを通じて、オンデマンドまたはリザーブドインスタンスとしてご利用いただけます。

また、X1インスタンスのいくつかのアップグレードについてもお伝えしたいと思います:

EBS – 本日のリリースで、現行のx1.32xlargeインスタンスにおいても、EBS専用の最大14Gbpsの帯域幅とインスタンスあたり80,000IOPSをサポートしています。

ネットワーク – 今週前半、現行のx1.32xlargeインスタンスがプレイスメントグループ内で最大25Gbpsのネットワーク帯域幅をサポートしたことを発表しています。

— Jeff;

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