Amazon Web Services ブログ

階層とタグによるパラメータの組織化及びAmazon EC2 Systems Manager パラメータ ストアのAmazon CloudWatchイベント

このポストはアマゾンウェブサービスのソフトウェア デベロッパーエンジニアであるLusha Zhang によって書かれました。

 

Amazon EC2 Sysmtes Mangager の一部であるパラメータストアは、平文データ(データベース文字列)または秘密情報データ(パスワード、APIキーなど)を問わず、設定データを管理するための集中化された暗号化ストアを提供します。パラメータストアはAWS CLI、API、およびSDKを介して利用できるため、AWSラムダやAmazon ECSなどのAWSサービス間でパラメータを簡単に参照できます。

 

パラメータストアのその他の記事については、以下を参照してください:

 

パラメータストアは最近、階層化サポートとパラメータのタグ付け、及びCloudWatchイベント サポートをローンチしました。これらの機能によって大規模にパラメータを組織化し、管理することが可能になりました。このポストでは、これらの新しい機能を使ってセキュリティ機能を拡張し改善する方法を示します。

 

階層化パラメータ

パラメータストアの階層化サポートによって、組織構造に基づいたパラータの構造化が可能となります。これはパラメータの編成、クエリ、および権限管理のための強力なツールを提供します。

 

一般的なDevOpsのシナリオでは、開発、ベータ、本番の異なる環境に対してソフトウェアの展開を自動化します。例えば、デプロイメント設定を作成する時に、設定を保存するためにパラメータストアを利用できます。おそらく各デプロイメント環境に最低限の健全なホスト数やパーセンテージを設定しなければならず、それらを環境ごとに異なる値でパラメータストアに保存したいと思うでしょう。

 

Step1. デプロイメント設定のパスを作成する

次のコマンドを使用して、保存するパスとパラメータを作成します:

aws ssm put-parameter --name /DeploymentConfig/Prod/FleetHealth --value 75 --type String

aws ssm put-parameter --name /DeploymentConfig/Beta/FleetHealth --value 20 --type String

 

秘密情報を専用のパスの下に構造化することもできます。例えば、

aws ssm put-parameter –-name /DeploymentConfig/Prod/Password/SQLPassword –-value <password> --type SecureString

 

 

AWS マネジメント コンソールまたはAWS CLから取得したパスごとにパラメータをフィルタすることも可能です。

aws ssm describe-parameters --parameter-filters Key=Path,Option=Recursive,Values=/DeploymentConfig/Prod

 

SecureString型パラメータの利用方法の詳細については、「Ssytem Manager パラメータについて」を参照してください。

 

Step 2. パラメータを使用してデプロイメント設定を管理する

AWS CloudFormationテンプレートを使用してデプロイメント設定を作成した場合は、次の例のように本番ステージに対するFleetHealthを設定することが可能です。

#!/bin/bash

fleetHealth=$(aws ssm get-parameter --name /DeploymentConfig/Prod/FleetHealth --query Parameter.Value)

aws cloudformation create-stack --stack-name <stack_name> --template-url <templateurl> --parameters ParameterKey=FleetHealth,ParameterValue=$fleetHealth

 

再帰フラグをを使用して、本番またはベータ環境のすべての設定パラメータを取り出すことが可能です。そして選択したパラメータを取得するために返された設定階層をパースできます。

aws ssm get-parameters-by-path --path /DeploymentConfig/Prod –-recursive

 

 

階層へのアクセスを制御する

本番およびベータ環境のデプロイメント設定のためのパラメータ階層を作成したので、パラメータへのアクセスを制限したいかもしれません。おそらく開発チームは本番環境のパラメータへはアクセスせず、ベータ環境のパラメータのみにアクセスできる必要があります。

IAMを使用して、ベータ環境のパラメータ階層へのアクセスを制御します。例えば、次のIAMポリシーはユーザーに本番環境パラメータへのアクセスを制限します。

{
"Effect": "Deny",
"Action": [
"ssm:GetParametersByPath"
],
"Condition": {
"StringEquals": {
"ssm:Recursive": [
"true"
]
}
},
"Resource":“arn:aws:ssm:<region>:<account_id>:parameter/DeploymentConfig/Prod*"
}

 

ユーザーが次のコマンドを実行すると、AccessDeniedException を受け取ることになります。

aws ssm get-parameters-by-path --path /DeploymentConfig/Prod —-recursive

 

タグ付けされたパラメータ

タグを使用するとAWSリソースを容易に管理できます。パラメータをタグ付けして、グループ化したり、クエリを行うこともできます。同じデプロイメント設定の例を使用して、タグのキー値が「Password」でタグ値が「Beta」または「Prod」のタグを追加することができます。

aws ssm add-tags-to-resource --resource-type Parameter --resource-id  /DeploymentConfig/Beta/FleetHealth --tags Key=Password,Value=Beta

 

合体されたフィルタ結果を得るために、複数のフィルターを適用することもできます。例えば、Password タグキーと再起フラグつきの /DeploymentConfig/Beta パスを適用して、パスワードに関連したベータ環境のパラメータを取得することができます。

aws ssm describe-parameters --parameter-filters Key=tag:Password Key=Path,Option=Recursive,Values=/DeploymentConfig/Beta

IAMポリシーを使用してセキュリティ アクセスを管理できます。詳細については、「System Manager パラメータのアクセス制御」を参照してください。

 

CloudWatch イベント ルールからの変更通知の取得

パラメータ ストアがCloudWatch イベントのソースになりました。パラメータが作成、更新、削除される度にLambda 関数やSNSトピックのようなCloudWatchイベント ターゲットをトリガーするようにCludWatchルールをセットアップすることができます。

次の例は、CloudWatchルールを設定して、パラメータ更新のSNSトピックをトリガする方法を示しています。詳細については、「ステップ2:SNSトピックの作成」を参照してください。パラメータの更新に関する電子メール通知をトリガーするようにSNSトピックを設定したら、ターゲットのSNSトピックに関連付けるCloudWatchルールを作成します。 イベントパターンの値を編集して、通知を発生する特定のパラメータを指定することができます。

{
  "source": [
    "aws.ssm"
  ],
  "detail-type": [
    "Parameter Store Change"
  ],
  "detail": {
    "name": [
      "/DeploymentConfig/Prod/FleetHealth",
      "/DeploymentConfig/Beta/FleetHealth"
    ],
    "operation": [
"Update",
"Delete"
    ]
  }
}

 

/DeploymentConfig/Beta/FleetHealthパラメータの値を変更すると、CloudWatchイベントがメトリックに表示されます。

その間に作成したSNSトピックがトリガーされ、emailも受信できます。

 

結論

この記事では、パラメータを管理するためのいくつかの新しいパラメータ ストアの機能:階層化、タグ付け、CloudWatch 通知について示しました。階層化パラメータを使用するとプレインテキストと秘密情報の両方について設定データの構造化とアクセス管理が容易になります。タグ付けサポートはパラメータのグループ化とクエリを容易にする別の方法を提供します。CloudWatchイベントによって、パラメータの更新の通知をタイムリーに受け取ることができます。

 

筆者について

Lusha ZhangはAmazon EC2 System Managerチームのソフトウェア開発エンジニアです。彼女はAmazon Textbook RentalsからAWS Parameter Storeまで、Amazonでさまざまな製品に取り組んできました。仕事以外では、太平洋北西部でのサーフィンだけでなく、バイオリンやピアノの演奏も楽しんでいます。

 

(翻訳はSA福井が担当しました。原文はこちらです。)

 

Amazon Connect と Amazon Lex のインテグレーション

私のお気に入りのサービス、Amazon ConnectAmazon Lex に機能強化が施されました。セルフサービスの Amazon Connect はクラウドベースのサポートセンターで、ビジネスがより良いカスタマーサービスを低コストで簡単に提供できるようにしています。Amazon Lex は、音声とテキストを使用して会話型インターフェイスを構築するためのサービスです。この 2 つのサービスを統合することで、Lex の自動音声認識 (ASR) と自然言語理解 (NLU) の性能を利用し、優れたセルフサービスエクスペリエンスを顧客に提供することができます。この統合を有効にするため、Lex チームが 8kHz の音声入力サポートを追加しました。これについては後ほど詳しくご説明します。この機能のメリットは?顧客によるリクエストの大半をボットが解決できれば、電話での待ち時間を削減し、ユーザーは時間を無駄にすることなく製品を使用することができます。

Connect または Amazon Lex の背景情報については、Jeff が過去に公開したブログ [1][2] をぜひお読みください。LEGO ファンの方は特にお楽しみいただけると思います。


では、この新しい統合の使用方法を見ていきましょう。Twitch チャンネルで構築したアプリケーションを使用して、このブログ用に内容を変更します。アプリケーションのコアでユーザーが Amazon Connect の番号を呼び出します。この番号はユーザーを Lex ボットに繋げ、AWS Lambda 関数を開始します。これは Lex のインテントをベースにしています。アプリケーションでできることは?

最良のコードエディタは何だと思いますか? 個人的には vim が好きです。コード編集を行うには最高のエディタです。私の同僚の Jeff は emacs を選んでいます。 これは素晴らしいオペレーティングシステム エディタです。もし、生まれつき指の関節が普通以上にあればの話しですが。そして同僚の Tara が選んだのは Visual Studio です。これも圧倒的に優れたエディタです。ということで、もっとも優れたエディタがどれか議論するのではなく、皆さんに投票してもらうのが良いのではないかと思います。バタフライに投票することもできますので、ご安心を。

投票に参加してみませんか?+1 614-569-4019 に電話し、あなたが最高のエディタだと思うものをお知らせください!皆さんの電話番号を保存したり、音声を録音することはありませんので、何回も vim に投票して下さって構いません。ライブで投票結果を見てみますか?  http://best-editor-ever.s3-website-us-east-1.amazonaws.com/.

さて、この仕掛けをどうやって構築したと思いますか?このブログでは各コンポーネントについて説明しますが、すでに LexLambda に触れているので、主に Amazon Connect コンポーネントについて焦点を当てることにします。ここでは、すでに皆さんが Connect インスタンスを実行中であることを前提とします。

Amazon Lex

まず Lex について説明します。まず、 VoteEditor という名前のボットを 2 つのインテントを使用して作成します。 VoteEditor に単一のスロットがあり editorConnectToAgent にはスロットがありません。editor スロットに様々なコードエディタ名を入れます (emacs は除去しておきましょうか)。

AWS Lambda

Lambda 関数も実にシンプルです。まず、Amazon DynamoDB テーブルを作成して投票結果を保存します。次に Lex (build_response) に応答するヘルパーメソッドを作成します – これでメッセージを Lex の分かりやすいレスポンス形式でラップできるようになります。後はフローロジックを特定するだけです。


def lambda_handler(event, context):
    if 'ConnectToAgent' == event['currentIntent']['name']:
        return build_response("Ok, connecting you to an agent.")
    elif 'VoteEditor' == event['currentIntent']['name']:
        editor = event['currentIntent']['slots']['editor']
        resp = ddb.update_item(
            Key={"name": editor.lower()},
            UpdateExpression="SET votes = :incr + if_not_exists(votes, :default)",
            ExpressionAttributeValues={":incr": 1, ":default": 0},
            ReturnValues="ALL_NEW"
        )
        msg = "Awesome, now {} has {} votes!".format(
            resp['Attributes']['name'],
            resp['Attributes']['votes'])
        return build_response(msg)

コードを理解できているか確認します。つまり、まだ存在しないエディタに票が入ったら、エディタに 1 票を追加するようにします。そうでなければ、そのエディタの票数を「1」増やします。エージェントのリクエストを受けたら、フローを終了してフレンドリーなメッセージを返します。どうです、簡単でしょう。後は投票結果を見るため、Lex ボットに Lambda 関数を使うように指示するだけです。次に進む前に、Lex コンソールですべて問題なく作用しているか確認することができます。

Amazon Connect

問い合わせフローで Lex ボットを使用する前に、Amazon Connect インスタンスにアクセスできるか確認します。そうするには、Amazon Connect サービスコンソールに行き、インスタンスを選択してから「問い合わせフロー」にアクセスします。ボットの追加先となる Lex のセクションが表示されます。

Amazon Connect のインスタンスが Lex ボットを呼び出せることが分かったところで、Lex ボットを含む新しい問い合わせフローを作成します。[Interact] カテゴリから [Get customer input] ウィジェットを介してフローにボットを追加します。

ウィジェットを起動すると、電話の数値キーから入力を許可するための [DTMF] タブ、または音声入力とその情報を Lex サービスに渡す [Amazon Lex] タブが表示されます。[Lex] タブを使用していくつかの事項を設定します。

様々なオプションがありますが、要するに使用したいボットを追加したり (ボットのバージョンも同様)、ボットで使用したいインテントや、ボットを紹介する小さなプロンプトを追加します (場合によっては顧客にコメントを入力するように促すなど)。

最終的にコンタクトフローは次のようになります。

実際には Lex ボットを介して多数のトランザクションをユーザーが実行できるようにする場合もあるでしょう。次に、エラーまたは ConnectToAgent のインテントで、ユーザーが実際のスタッフと対話ができるキューにユーザーを追加します。ユーザーの情報を収集し保存して、エージェントが利用できるように多機能のインターフェイスを追加します。これにより、エージェントは必要な情報をすべて把握した上でユーザーとの会話をすぐに始めることができます。

では次に Lex がサポートする 8kHz オーディオサポートの使用によるメリットについて説明します。Lex は、もともと電話から 8 kHz 入力以上の高音質でサンプルされた音声入力のみサポートしていました。現代のデジタル通信アプリケーションは、通常最低でも 16 kHz でサンプルされたオーディオ信号を使用しています。この忠実度が高いレコーディングでは「ess」(/s/) や「eff」(/f/) といった音の違いを聞き分けることができます。少なくても、そのようにオーディオ専門家は説明しています。それに比べ、電話は大幅に質の低いレコーディングを使用しています。人間と人間の耳というのは、低質の録音でも音声が何を言っているのか前後関係から把握するのに長けています (証拠は「NASA アポロのレコーディング (NASA apollo recordings)」をご覧ください)。ですから、電話のデジタルシステムは大方デフォルトで 8kHz サンプリングをセットアップに使用しています。帯域幅と忠実度において具合の良いトレードオフだと思います。電話の声がいつもと違うように聞こえるのは、そのためです。サンプリングレートの基本的な問題に加えて、携帯電話によるコールデータでは通話中に聞こえないという問題がよくあります (もしもし、聞こえますか? といった具合に)。多種多様の何千種類ものデバイスと何百社というメーカー、そして数えきれないほどの様々なソフトウェア実装があります。そこで、認識にまつわる問題はどうやって解決したらいいと思いますか?

Lex チームは、この問題への対処方法は音声入力に使用する一連のモデルを拡張し、8kHz モデルを含むことだと判断しました。8 kHz のテレフォニーオーディオサンプリングレートのサポートにより、音声認識の精度やサポートセンターとのやり取りの忠実度を高めることができます。これは、数多くのお客様が Amazon Connect をもっと利用できるようにと対応しているチームの素晴らしい努力の結果と言えるでしょう。

最後になりますが、Amazon Connect は外部開発者として使用できる PostContent エンドポイントと同じものを使うため、Amazon Connect を使用していないユーザーでも Lex で 8kHz を使用することが可能です。

以上となりますが、お楽しみいただけましたか? 詳細はいつも通り「ドキュメント (docs)」や「API リファレンス (API Reference)」をご参照ください。

Randall

異なるAWS CodeBuildビルドスペックファイルを使用した、同じソースからの複数ビルド作成

2017年6月、 AWS CodeBuildプロジェクトで別のビルドスペックファイル名または場所を指定できるようになりました
この記事では、異なるビルドスペックファイルを同じリポジトリで使用して、異なるビルドを作成する方法を説明します。この投稿のソースコードは我々のGitHubリポジトリにあります。
 

前提要件

AWS CLIをインストールして設定しておく必要があります。

ソリューションの概要

共有ライブラリを作成するために使用されるCプログラム(cbsamplelib.c)と、そのライブラリを使用するための別のユーティリティプログラム(cbsampleutil.c)を作成しました。 Makefileを使ってこれらのファイルをコンパイルします。

このサンプルアプリケーションをRPMとDEBパッケージに入れてエンドユーザーが簡単に展開できるようにする必要があります。 RPM用のビルドスペックファイルを作成しました。ビルドスペックで設定されたこのコードとRPMスペックファイル(cbsample.rpmspec)をコンパイルしてRPMパッケージを作成するには、makeを使用します。同様に、DEB用のビルドスペックファイルも作成しました。このビルドスペックで構成されたコントロールファイル(cbsample.control)に基づいてDEBパッケージが作成されます。

 

RPMビルドプロジェクト:

次のビルドスペックファイル(buildspec-rpm.yml)は、ビルドスペックバージョン0.2を使用します。ドキュメントで説明されているように、このバージョンは環境変数の構文が異なります。このビルドスペックには、複数のフェーズがあります。

  • installフェーズの一部として、yumを使用して必要なパッケージがインストールされます
  • pre_buildフェーズでは、必要なディレクトリが作成され、RPMビルドスペックファイルを含む必要なファイルが適切な場所にコピーされます
  • buildフェーズでは、コードがコンパイルされ、RPMスペックに基づいてRPMパッケージが作成されます

artifactセクションで定義されているように、RPMファイルはビルドアーティファクトとしてアップロードされます。

version: 0.2 

env: 
  variables: 
    build_version: "0.1" 
	
phases: 
  install: 
    commands: 
      - yum install rpm-build make gcc glibc -y 
  pre_build: 
    commands: 
      - curr_working_dir=`pwd` 
      - mkdir -p ./{RPMS,SRPMS,BUILD,SOURCES,SPECS,tmp} 
      - filename="cbsample-$build_version" 
      - echo $filename 
      - mkdir -p $filename 
      - cp ./*.c ./*.h Makefile $filename 
      - tar -zcvf /root/$filename.tar.gz $filename 
      - cp /root/$filename.tar.gz ./SOURCES/ 
      - cp cbsample.rpmspec ./SPECS/ 
  build: 
    commands: 
      - echo "Triggering RPM build" 
      - rpmbuild --define "_topdir `pwd`" -ba SPECS/cbsample.rpmspec 
      - cd $curr_working_dir 
	  
artifacts: 
  files: 
    - RPMS/x86_64/cbsample*.rpm 
  discard-paths: yes 

cb-centos-project.jsonをリファレンスとして使用して、CLIコマンドの入力JSONファイルを作成します。このプロジェクトでは、codebuild-multispecというAWS CodeCommitリポジトリと、buildspec-rpm.ymlという名前のビルドスペックファイルを使用します。 RPMパッケージを作成するには、カスタムイメージ名を指定する必要があります。私はDocker Hubの最新のCentOS 7イメージを使用しています。CodeBuildServiceRoleという名前のIAMロールを使用しています。これには、CodeBuildServiceRole.jsonで定義されたものと同様の権限が含まれています。 (必要に応じて、ポリシー内のリソースフィールドを変更する必要があります。)

{ 
    "name": "rpm-build-project", 
    "description": "Project which will build RPM from the source.", 
    "source": { 
        "type": "CODECOMMIT", 
        "location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec", 
        "buildspec": "buildspec-rpm.yml" 
    }, 
    "artifacts": { 
        "type": "S3", 
        "location": "codebuild-demo-artifact-repository" 
    }, 
    "environment": { 
        "type": "LINUX_CONTAINER", 
        "image": "centos:7", 
        "computeType": "BUILD_GENERAL1_SMALL" 
    }, 
    "serviceRole": "arn:aws:iam::012345678912:role/service-role/CodeBuildServiceRole", 
    "timeoutInMinutes": 15, 
    "encryptionKey": "arn:aws:kms:eu-west-1:012345678912:alias/aws/s3", 
    "tags": [ 
        { 
            "key": "Name", 
            "value": "RPM Demo Build" 
        } 
    ] 
}

cli-input-jsonファイルが準備できたら、次のコマンドを実行してビルドプロジェクトを作成します。

$ aws codebuild create-project --name CodeBuild-RPM-Demo --cli-input-json file://cb-centos-project.json 
{ 
	"project": { 
		"name": "CodeBuild-RPM-Demo", 
		"serviceRole": "arn:aws:iam::012345678912:role/service-role/CodeBuildServiceRole", 
		"tags": [ 
			{ 
				"value": "RPM Demo Build", 
				"key": "Name" 
			} 
		], 
		"artifacts": { 
			"namespaceType": "NONE", 
			"packaging": "NONE", 
			"type": "S3", 
			"location": "codebuild-demo-artifact-repository", 
			"name": "CodeBuild-RPM-Demo" 
		}, 
		"lastModified": 1500559811.13, 
		"timeoutInMinutes": 15, 
		"created": 1500559811.13, 
		"environment": { 
			"computeType": "BUILD_GENERAL1_SMALL", 
			"privilegedMode": false, 
			"image": "centos:7", 
			"type": "LINUX_CONTAINER", 
			"environmentVariables": [] 
		}, 
		"source": { 
			"buildspec": "buildspec-rpm.yml", 
			"type": "CODECOMMIT", 
			"location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec" 
		}, 
		"encryptionKey": "arn:aws:kms:eu-west-1:012345678912:alias/aws/s3", 
		"arn": "arn:aws:codebuild:eu-west-1:012345678912:project/CodeBuild-RPM-Demo", 
		"description": "Project which will build RPM from the source." 
	} 
}

プロジェクトが作成されたら、次のコマンドを実行してビルドを開始します。ビルドが開始されたら、ビルドIDを取得します。ビルドIDを使用してビルドのステータスを取得することができます。

$ aws codebuild start-build --project-name CodeBuild-RPM-Demo 
{ 
    "build": { 
        "buildComplete": false,  
        "initiator": "prakash",  
        "artifacts": { 
            "location": "arn:aws:s3:::codebuild-demo-artifact-repository/CodeBuild-RPM-Demo" 
        },  
        "projectName": "CodeBuild-RPM-Demo",  
        "timeoutInMinutes": 15,  
        "buildStatus": "IN_PROGRESS",  
        "environment": { 
            "computeType": "BUILD_GENERAL1_SMALL",  
            "privilegedMode": false,  
            "image": "centos:7",  
            "type": "LINUX_CONTAINER",  
            "environmentVariables": [] 
        },  
        "source": { 
            "buildspec": "buildspec-rpm.yml",  
            "type": "CODECOMMIT",  
            "location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec" 
        },  
        "currentPhase": "SUBMITTED",  
        "startTime": 1500560156.761,  
        "id": "CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc",  
        "arn": "arn:aws:codebuild:eu-west-1: 012345678912:build/CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc" 
    } 
} 

$ aws codebuild list-builds-for-project --project-name CodeBuild-RPM-Demo 
{ 
    "ids": [ 
        "CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc" 
    ] 
} 

$ aws codebuild batch-get-builds --ids CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc 
{ 
    "buildsNotFound": [],  
    "builds": [ 
        { 
            "buildComplete": true,  
            "phases": [ 
                { 
                    "phaseStatus": "SUCCEEDED",  
                    "endTime": 1500560157.164,  
                    "phaseType": "SUBMITTED",  
                    "durationInSeconds": 0,  
                    "startTime": 1500560156.761 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "PROVISIONING",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 24,  
                    "startTime": 1500560157.164,  
                    "endTime": 1500560182.066 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "DOWNLOAD_SOURCE",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 15,  
                    "startTime": 1500560182.066,  
                    "endTime": 1500560197.906 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "INSTALL",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 19,  
                    "startTime": 1500560197.906,  
                    "endTime": 1500560217.515 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "PRE_BUILD",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 0,  
                    "startTime": 1500560217.515,  
                    "endTime": 1500560217.662 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "BUILD",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 0,  
                    "startTime": 1500560217.662,  
                    "endTime": 1500560217.995 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "POST_BUILD",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 0,  
                    "startTime": 1500560217.995,  
                    "endTime": 1500560218.074 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "UPLOAD_ARTIFACTS",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 0,  
                    "startTime": 1500560218.074,  
                    "endTime": 1500560218.542 
                },  
                { 
                    "contexts": [],  
                    "phaseType": "FINALIZING",  
                    "phaseStatus": "SUCCEEDED",  
                    "durationInSeconds": 4,  
                    "startTime": 1500560218.542,  
                    "endTime": 1500560223.128 
                },  
                { 
                    "phaseType": "COMPLETED",  
                    "startTime": 1500560223.128 
                } 
            ],  
            "logs": { 
                "groupName": "/aws/codebuild/CodeBuild-RPM-Demo",  
                "deepLink": "https://console.aws.amazon.com/cloudwatch/home?region=eu-west-1#logEvent:group=/aws/codebuild/CodeBuild-RPM-Demo;stream=57a36755-4d37-4b08-9c11-1468e1682abc",  
                "streamName": "57a36755-4d37-4b08-9c11-1468e1682abc" 
            },  
            "artifacts": { 
                "location": "arn:aws:s3:::codebuild-demo-artifact-repository/CodeBuild-RPM-Demo" 
            },  
            "projectName": "CodeBuild-RPM-Demo",  
            "timeoutInMinutes": 15,  
            "initiator": "prakash",  
            "buildStatus": "SUCCEEDED",  
            "environment": { 
                "computeType": "BUILD_GENERAL1_SMALL",  
                "privilegedMode": false,  
                "image": "centos:7",  
                "type": "LINUX_CONTAINER",  
                "environmentVariables": [] 
            },  
            "source": { 
                "buildspec": "buildspec-rpm.yml",  
                "type": "CODECOMMIT",  
                "location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec" 
            },  
            "currentPhase": "COMPLETED",  
            "startTime": 1500560156.761,  
            "endTime": 1500560223.128,  
            "id": "CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc",  
            "arn": "arn:aws:codebuild:eu-west-1:012345678912:build/CodeBuild-RPM-Demo:57a36755-4d37-4b08-9c11-1468e1682abc" 
        } 
    ] 
}

DEB ビルドプロジェクト:

このプロジェクトでは、buildspec-deb.ymlというビルドスペックファイルを使用します。 RPMビルドプロジェクトと同様に、このビルドスペックには複数のフェーズが含まれています。ここでは、Debianコントロールファイルを使用してDEB形式のパッケージを作成します。ビルドが成功すると、ビルド成果物としてDEBパッケージがアップロードされます。

version: 0.2 

env: 
  variables: 
    build_version: "0.1" 

phases: 
  install: 
    commands: 
      - apt-get install gcc make -y 
  pre_build: 
    commands: 
      - mkdir -p ./cbsample-$build_version/DEBIAN 
      - mkdir -p ./cbsample-$build_version/usr/lib 
      - mkdir -p ./cbsample-$build_version/usr/include 
      - mkdir -p ./cbsample-$build_version/usr/bin 
      - cp -f cbsample.control ./cbsample-$build_version/DEBIAN/control 
  build: 
    commands: 
      - echo "Building the application" 
      - make 
      - cp libcbsamplelib.so ./cbsample-$build_version/usr/lib 
      - cp cbsamplelib.h ./cbsample-$build_version/usr/include 
      - cp cbsampleutil ./cbsample-$build_version/usr/bin 
      - chmod +x ./cbsample-$build_version/usr/bin/cbsampleutil 
      - dpkg-deb --build ./cbsample-$build_version 

artifacts: 
  files: 
    - cbsample-*.deb

ここでは、cb-ubuntu-project.jsonをリファレンスとして使用して、CLI入力JSONファイルを作成します。このプロジェクトは同じAWS CodeCommitリポジトリ(codebuild-multispec)を使用しますが、同じリポジトリ内の別のbuildspecファイル(buildspec-deb.yml)を使用します。デフォルトのCodeBuildイメージを使用してDEBパッケージを作成します。同じIAMロール(CodeBuildServiceRole)を使用します。

{ 
    "name": "deb-build-project", 
    "description": "Project which will build DEB from the source.", 
    "source": { 
        "type": "CODECOMMIT", 
        "location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec", 
        "buildspec": "buildspec-deb.yml" 
    }, 
    "artifacts": { 
        "type": "S3", 
        "location": "codebuild-demo-artifact-repository" 
    }, 
    "environment": { 
        "type": "LINUX_CONTAINER", 
        "image": "aws/codebuild/ubuntu-base:14.04", 
        "computeType": "BUILD_GENERAL1_SMALL" 
    }, 
    "serviceRole": "arn:aws:iam::012345678912:role/service-role/CodeBuildServiceRole", 
    "timeoutInMinutes": 15, 
    "encryptionKey": "arn:aws:kms:eu-west-1:012345678912:alias/aws/s3", 
    "tags": [ 
        { 
            "key": "Name", 
            "value": "Debian Demo Build" 
        } 
    ] 
}

CLI入力JSONファイルを使用して、プロジェクトを作成し、ビルドを開始し、プロジェクトのステータスを確認します。

$ aws codebuild create-project --name CodeBuild-DEB-Demo --cli-input-json file://cb-ubuntu-project.json 

$ aws codebuild list-builds-for-project --project-name CodeBuild-DEB-Demo 

$ aws codebuild batch-get-builds --ids CodeBuild-DEB-Demo:e535c4b0-7067-4fbe-8060-9bb9de203789

RPMおよびDEBビルドが正常に完了したら、ビルドパッケージのアーティファクトセクションで設定されているS3バケットを確認します。ビルドプロジェクトでは、ビルドプロジェクトの名前でディレクトリを作成し、内部にアーティファクトをコピーします。

$ aws s3 ls s3://codebuild-demo-artifact-repository/CodeBuild-RPM-Demo/ 
2017-07-20 16:16:59       8108 cbsample-0.1-1.el7.centos.x86_64.rpm 

$ aws s3 ls s3://codebuild-demo-artifact-repository/CodeBuild-DEB-Demo/ 
2017-07-20 16:37:22       5420 cbsample-0.1.deb

ビルド開始時のBuildspecのオーバーライド:

ビルドを開始するときに既存のプロジェクトのビルドスペックファイルをオーバーライドすることもできます。 RPM全体ではなくlibs RPMパッケージを作成する場合は、buildspec-libs-rpm.ymlという名前のビルドスペックファイルを使用します。このビルドスペックファイルは、以前のRPMビルドと似ています。唯一の違いは、別のRPMスペックファイルを使用してlibs RPMを作成することです。

version: 0.2 
env: 
  variables: 
    build_version: "0.1" 

phases: 
  install: 
    commands: 
      - yum install rpm-build make gcc glibc -y 
  pre_build: 
    commands: 
      - curr_working_dir=`pwd` 
      - mkdir -p ./{RPMS,SRPMS,BUILD,SOURCES,SPECS,tmp} 
      - filename="cbsample-libs-$build_version" 
      - echo $filename 
      - mkdir -p $filename 
      - cp ./*.c ./*.h Makefile $filename 
      - tar -zcvf /root/$filename.tar.gz $filename 
      - cp /root/$filename.tar.gz ./SOURCES/ 
      - cp cbsample-libs.rpmspec ./SPECS/ 
  build: 
    commands: 
      - echo "Triggering RPM build" 
      - rpmbuild --define "_topdir `pwd`" -ba SPECS/cbsample-libs.rpmspec 
      - cd $curr_working_dir 

artifacts: 
  files: 
    - RPMS/x86_64/cbsample-libs*.rpm 
  discard-paths: yes

先ほど作成したのと同じRPMビルドプロジェクトを使用して、新しいビルドを開始し、 `-buildspec-override`パラメータの値をbuildspec-libs-rpm.ymlに設定します。

$ aws codebuild start-build --project-name CodeBuild-RPM-Demo --buildspec-override buildspec-libs-rpm.yml 
{ 
    "build": { 
        "buildComplete": false,  
        "initiator": "prakash",  
        "artifacts": { 
            "location": "arn:aws:s3:::codebuild-demo-artifact-repository/CodeBuild-RPM-Demo" 
        },  
        "projectName": "CodeBuild-RPM-Demo",  
        "timeoutInMinutes": 15,  
        "buildStatus": "IN_PROGRESS",  
        "environment": { 
            "computeType": "BUILD_GENERAL1_SMALL",  
            "privilegedMode": false,  
            "image": "centos:7",  
            "type": "LINUX_CONTAINER",  
            "environmentVariables": [] 
        },  
        "source": { 
            "buildspec": "buildspec-libs-rpm.yml",  
            "type": "CODECOMMIT",  
            "location": "https://git-codecommit.eu-west-1.amazonaws.com/v1/repos/codebuild-multispec" 
        },  
        "currentPhase": "SUBMITTED",  
        "startTime": 1500562366.239,  
        "id": "CodeBuild-RPM-Demo:82d05f8a-b161-401c-82f0-83cb41eba567",  
        "arn": "arn:aws:codebuild:eu-west-1:012345678912:build/CodeBuild-RPM-Demo:82d05f8a-b161-401c-82f0-83cb41eba567" 
    } 
}

ビルドが正常に完了したら、CodeBuild-RPM-Demoビルドプロジェクトフォルダの下にあるアーティファクトS3バケットにパッケージが表示されているかどうかを確認します。

$ aws s3 ls s3://codebuild-demo-artifact-repository/CodeBuild-RPM-Demo/ 
2017-07-20 16:16:59       8108 cbsample-0.1-1.el7.centos.x86_64.rpm 
2017-07-20 16:53:54       5320 cbsample-libs-0.1-1.el7.centos.x86_64.rpm

まとめ

この記事では、同じソースリポジトリ内の複数のbuildspecファイルを使用して、複数のAWS CodeBuildビルドプロジェクトを実行する方法を紹介しました。また、ビルドを開始するときに別のビルドスペックファイルを提供する方法も示しました。
AWS CodeBuildの詳細については、AWS CodeBuildのドキュメントを参照してください。ステップバイステップガイドを使用して、AWS CodeBuildを使い始めることができます。
 
(翻訳はSA千葉が担当しました。原文はこちら)

Now Available – Lumberyard Beta 1.10

本日、546以上の改善、修正、および機能を備えた最大リリースであるLumberyard Beta 1.10のリリースを発表しました。こちらからダウンロードできます。
昨年2月にリリースされて以来、元コードの50%以上を修正、書き換えを行いました。皆様ののフィードバックのおかげで、いくつかの大きな進歩を遂げましたが、まだやるべきことはたくさんあります。この行程のお手伝いができ興奮しております。
今回のリリースにはいくつかのハイライトがあります。(全リリースノートはこちらにあります)

 

Order-independent Transparency

ゲーム上で透明なオブジェクトをレンダリングするのはチャレンジングです。ワイングラスを例に:グラフィックスエンジニアは、すべての表面を正しく表示し、特に表面やリフレクションの順序が乱れている場合は、すべてのリフレクションを正しく取得するのに時間がかかることを知っています。Order-independent Transparency(OIT)はこれを解決します。
今年GDCでNVIDIA Researchと協力してOITを垣間見ることができ、そして今回のLumberyard 1.10に統合することができました。私たちは常にゲーム開発を簡単にする方法を探し求めていますが、リアルタイムレンダリングで可能性を押し広げています。皆様がOITの力をどのように活用するかを待たせることはありません。

画面の左側には、Order-independent Transparencyを有効にしており、その利点がわかります。

 

Temporal Anti-Aliasing

私たちはすべてのjagged edges (aka jaggies) やゲーム中のちらつきを処理してきました-多くの点で、それに慣れていました。しかしそれはもう必要はありません。Temporal Anti-Aliasingを使用すると、リアルタイムレンダリングによる欠点をより簡単にスムーズに処理し、ゲーム中で映画のような品質に近づけることができます。
それにすぐ直面し、映画では数秒のCGI効果で数百時間を費やすこととなります。しかし、ゲームでは、すべてをリアルタイムで実行する必要があります。Lumberyardの高度なレンダリング技術と一緒に、Temporal Anti-Aliasingは、プロジェクトにおいてハイレベルの視覚的忠実度を成し遂げるのに役立てます。

画面の左側には、 Temporal Anti-Aliasingを有効にしており、その利点がわかります。

 

何百もの追加機能と最適化

皆様のフィードバックのおかげで、今回のリリースではさらに重要な調整と修正が行われました。

  • component entity workflowsでワークフローに35の改善点を 導入し、イテレーション時間を短縮しました。たとえば、Entity Inspectorで複数選択(CTRLとSHIFTのクリック)したり、コンテキストメニューからワンクリックでエンティティとコンポーネントをスライスのデフォルトに戻したり、Entity Outlinerのコンポーネントを有効または無効にしたり、エンティティのアイコンをカスタマイズができるようになりました。
  • Cloud Gems には50以上の改善点が追加され、プレイヤーコミュニティの管理性を向上させました。新しい機能は、Cloud Gems Portalから数回のクリックで新しいユーザーを作成したり、パスワードをリセットしたり、プレーヤーを停止する機能が含まれました。
  • さらに、エディタをカスタマイズした新しいdocking systemmaterial editorのパフォーマンス向上など、多くの機能を備えています。

Lumberyardの新しいdocking system

 

皆様のご意見をお聞かせください

いつものように、あなたの考えをお聞かせください。リリースから18カ月しか経っておらず、いろいろな意味でまだ始まったばかりです。あなたのフィードバックや提案の多くを組み込むのを待っています。だからこそお聞かせください。Lumberyardについての詳細は、チュートリアルを参照し、コミュニティフォーラムにアクセスでき、ドキュメントを確認することができます。

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

AWS Twitchチャンネルで GameDay エッセンシャルズ (番組)のご紹介

Unicorn.Rentals という LARM (Legendary Animal Rental Market – レジェンダリーアニマルレンタルマーケット) を専門にする企業で、あなたが新しい職に就いたと想像してみてください。もしチャンスがあれば、何を引き換えにしてもユニコーンと遊んでみたいと思わない子供はいるでしょうか?そして、我が子を喜ばせるなら何でもしてやりたいと思うのが親心というものでしょう。そして今が 2017 年であると想定し、Unicorn.Rentals が現在もアニマルレンタルマーケットの業界をリードする存在であるとします。

その時点で、あなたは全く別の次元に入り込む寸前にいます。宇宙や時間のない空間。そう、こんな感じに。 無限です。光と影、そして科学と迷信の中間にあるその場所は、1 人のクラウド知識から始まります。素晴らしい想像の世界にあなたを導き、そこには影と物質が待っているのです。これよりあなたは GameDay Essentials のゾーンに足を踏み入れることになります。

まぁ、別の次元とまではいかなくても、かなりすごい場所ではあります。多分、おそらく? その判断はあなたにお任せします。どちらにしても、今回 AWS Twitch チャンネルの「GameDay Essentials」をご紹介できることを大変嬉しく思います。GameDay Essentials は、先述した Unicorn.Rentals のような状況にある企業の「新入社員トレーニングプログラム」です。アマゾン ウェブ サービスを使用し、企業で上手く仕事をこなしていくために新入社員がクラウドコンピューティングに関する知識を高め、トレーニングする様子が分かります。

GameDay Essentials では、Unicorn.Rentals というスタートアップ企業の成長に加担すべく、実践的なコンピューティングを実際に行っていきます。初回エピソードの「Recon」は 7 月 25 日に公開され、CloudTrailCloudwatch でのロギングサービスに関する情報を提供したほか、設定へのアクセスや AWS アカウントにある既存のインベントリリソースを識別する方法について解説しました。「エピソード 1 – Recon (Episode 1–Recon)」はこちらからご覧いただけます。6 つのシリーズから構成されるシーズン 1 のその他のエピソードは毎週火曜日の午前 11:30 (太平洋標準時) に公開されます。次回 3 つのエピソードでは次のトピックを取り上げています。

  • エピソード 2 – スケーリング: スケーリングのテクニックや自動スケーリンググループを実装するための詳細を把握し、アプリケーションインフラストラクチャをスケールする方法を説明します。公開日は 8 月 1 日です 
  • エピソード 3 – 変更: ウィンストン・チャーチルの名言に「向上とは変化である。パーフェクトになるには頻繁に変化していくことである。(“To improve is to change; to be perfect is to change often”)」というのがあります。GameDay エピソードは変化することが成功へのキーポイントであるという点を取り上げています。ネイティブ AWS セキュリティやデプロイツールを使用して変更をトラッキングし管理する方法や、変更事項にチームで対応する方法についても解説しています。公開日は 8 月 8 日です
  • エピソード 4 – 分離: 大方、IT 業界に携わる人であれば、緊密に連携したシステム作成は避けるべきであると理解しています。そこで、このエピソードでは大まかに連携しているシステムがどのように動作しているのかを説明し、そうしたシステムで発生するエラーを診断するために必要な情報を解説します。公開日は 8 月 15 日です 

まとめ

前回の GameDay Essentials では、使用を始める上で必要な情報を説明し、クラウドコンピューティングや AWS プラットフォームについて解説しました。GameDay Essentials は AWS が提供する別のライブコーディングに関するエピソードに参加し、毎週 AWS Twitch チャンネルの「AWS でライブコーディング (Live Coding with AWS)」や「AWS Maker Studio」で取り上げられています。

AWS Twitch チャンネルに毎週アクセスして別の次元を訪れてみませんか? 聴覚、視覚、クラウドの異次元をぜひお楽しみください。これは想像の異次元です。GameDay Essentials ゾーンと私達は呼んでいます。「トワイライトゾーン」のようでしょう?「GameDay Essentials」は AWS チャンネルの Twitch でご覧いただけます。AWS のクラウドコンピューティングをインタラクティブな方法で学べます、ぜひお楽しみください。

Tara

Lambda@Edge – エッジで HTTP リクエストを”賢く”処理する

昨年、Lambda@Edgeプレビューをアナウンスし、お客様に近いロケーションでHTTPリクエストを”賢く”処理する方法を説明しました。プレビューに応募しアクセスを許可された開発者は Lambda@Edge を有効に活用し、非常に有用な多くのフィードバックをいただきました。プレビュー中に HTTP レスポンスの生成、CloudWatch Logs のサポートを追加し、フィードバックに基いてロードマップを更新しました。

一般提供の開始

本日、 Lambda@Edge の一般提供を開始できることを嬉しく思います。次のように利用できます:

  • A/B テストを行うために cookie を検査し、 URL を書き換える
  • ユーザーエージェントヘッダに基づいて、特別なオブジェクトを返す
  • オリジンにリクエストを許可する前に、特定のヘッダを検索することでアクセスコントロールを実装する
  • ヘッダを追加、削除または変更して様々なキャッシュ済オブジェクトに誘導する
  • HTTP レスポンスを生成する
  • 古い URL 形式のサポート
  • ヘッダや URL を変更または簡略化して、キャッシュ使用率を改善する
  • 他のインターネットリソースへ HTTP リクエストを行い、その結果を使用してレスポンスをカスタマイズする

(more…)

Active Directory証明書サービス(AD CS)によるAmazon WorkSpacesマネージドデバイス認証の構成

ソリューションアーキテクトの渡邉(@gentaw0)です。Amazon WorkSpacesで、クライアント証明書によるマネージドデバイス認証が可能になりました(新機能 – Amazon WorkSpaces 用のマネージド型デバイスの認証)。マネージドデバイス認証を使用すると、あらかじめIT管理者が許可したデバイスからのみ接続を許可することで認証のセキュリティを強化することが可能になります。マネージドデバイス認証は現在、WindowsおよびMac OS Xに対応していますが、iOS、Android、Chrome OS、ウェブ、およびゼロクライアントデバイスからのアクセスをそれぞれ許可またはブロックすることも可能です。

マネージドデバイス認証はセキュリティ強化のための強力な機能ですが、使用するためには認証局(CA)や証明書の配布など公開鍵基盤(PKI)のための仕組みを用意する必要があります。この記事では、Active Directory証明書サービス(AD CS)を使用してクライアント証明書の発行とデバイスの管理をおこなう方法について解説します。

まず、Active Directory証明書サービス(AD CS)をEC2インスタンス上にインストールします。サーバーマネージャーの「役割の追加」から「Active Directory証明書サービス」を選択することでインストールが可能です。今回は、スタンドアロンのルートCAとしてインストールしますが、本番環境ではエンタープライズCAとすると証明書の発行をActive Directoryアカウントと連動して自動的におこなうことが可能です。また、「証明機関Web登録」をインストールすることによってWebサーバー(IIS)の役割があわせてインストールされます。

Active Directory証明書サービスのインストールが完了すると、クライアント証明書の発行と管理が可能になります。まずはAD CSからルート証明書をエクスポートしてAmazon WorkSpacesのディレクトリにインポートします。Amazon WorkSpacesコンソールで「Directories」→「Update Directory Details」を選択し、「Access Control Options」のセクションでBase64エンコードされたルート証明書を貼り付けることでインポートが可能です。

ルート証明書をインポートしたあと、「Only Allow Trusted Windows Devices to Access WorkSpaces」および「Only Allow Trusted MacOS Devices to Access WorkSpaces」のチェックボックスをオンにすることで適切なクライアント証明書がインストールされていないWindowsまたはMac OSデバイスからのアクセスを禁止することができるようになります。また、その他のデバイスタイプについてはプラットフォームごとにアクセスを許可もしくは禁止することが可能です。

次に、クライアント証明書の発行およびインストールをおこないます。ここでは証明機関Web登録を使用してクライアント証明書をリクエストしていきます。WebブラウザからActive Directory証明書サービスのWebサイトにHTTPSでアクセスして、「証明書を要求する」を選択することでリクエストをおこなうことが可能です。

「証明書の要求」では、「証明書の要求の詳細設定を送信」を選択して「証明書の要求の詳細設定」で「このCAへの要求を作成し送信する」を選択します。識別情報に必要な内容を入力し、証明書の種類では「クライアント認証証明書」を選択して要求を送信すると、クライアント証明書のリクエストがActive Directory証明書サービスに送信されます。発行したクライアント証明書をエクスポートする必要がある場合は「エクスポート可能なキーとしてマークする」にチェックしてください。

証明書の要求が完了すると、ステータスが保留中になります。リクエストを承認するためには、サーバーマネージャーでActive Directory証明書サービスを開き、「保留中の要求」からリクエストを承認します。

ふたたびWebブラウザでActive Directory証明書サービスのWebサイトにアクセスし、「保留中の証明書の要求の状態」を選択すると証明書のステータスを確認することが可能です。発行されたクライアント証明書をインストールするか、エクスポートした証明書をクライアントデバイスにコピーします。クライアントデバイスにルート証明書がインストールされていない場合は、あわせてルート証明書もインストールしておく必要があります。

WorkSpaces Client側にクライアント証明書がインストールされていない場合は、以下のようなメッセージが表示されます。クライアント証明書が適切にインストールされていると通常通りのログイン画面が表示され、自分のWorkSpaceにログインできるようになります。

マネージドデバイス認証を利用することで、管理者が許可していないデバイスからWorkSpacesに接続することをふせぐことができるためいままでよりセキュリティを強化することができます。このブログ記事で紹介した手順で、Active Directory証明書サービスを使用してマネージドデバイス認証をかんたんに検証することができます。その他、マネージドデバイス認証の詳細についてはこちらを参照してください。

AWS ホットスタートアップ – 2017年7月

今月も引き続き、ホットなスタートアップ企業を紹介していきます。日々、スタートアップ企業は革新的であっと言わせるようなビジネス、アプリケーション、製品を世界中で製作しています。AWS では毎月、AWS を使用して何か優れたことをしているスタートアップ企業を紹介しています。

7 月は学習に関する企業を集めました。次の企業は様々な方法で知識や技術を拡張するためのツールやリソースへのアクセス提供に重点を置いています。

今月のスタートアップ企業をご紹介します。

  • CodeHS – 中高生を対象に、使って楽しくアクセスしやすいコンピュータサイエンスのカリキュラムを提供しています。
  • Insight – データサイエンス分野の技術的な才能を伸ばすための集中的なフェローシップを提供しています。
  • iTranslate – 90 か国語以上の言語で読み取り、書き取り、会話ができるサービスを世界中で提供しています。

CodeHS (カリフォルニア州サンフランシスコ)

2012 年、スタンフォード大学の学生だった Zach Galant 氏と Jeremy Keeshin 氏は、コンピュータサイエンスを専攻していました。そして初級レベルのクラスの教育助手をしていた時に、ある傾向に気が付いたのです。多くの学生が、もっと小さい頃からコンピュータサイエンスに関わっていたかったということです。大学 4 年の時に Zach と Jeremy は中高生が楽しく、アクセスしやすいコンピュータサイエンス教育を提供するチャンスを作るために CodeHS を立ち上げました。CodeHS はウェブベースのカリキュラムで、指導者のリソース、レッスンプラン、専門的能力の開発チャンスで成り立っています。カリキュラムは時間節約を意図して作られた指導者用のツールを伴い、レッスンプランや採点、学習者のコードの評価、クラスルームの管理ができます。

CodeHS は、すべての生徒が将来に向けて意義ある影響力を培えるように取り組んでいます。また、コードを学ぶことは読解力と共に現代の新たな基礎的能力であると考え、そうした技術を身に着けることで生徒がより深く個人の興味や学習を拡大していくことができると見ています。CodeHS が設立された 2012 年には、コンピュータサイエンスのコースを提供している米国内の高等学校は 10% ほどでした。Zach と Jeremy は学校や学区が簡単に取り組めるようにするためのソリューションを提供することで、その現状を変えることに努めてきました。CodeHS により、何千人もの指導者がトレーニングを受け、何百何千人という世界中の生徒達に指導できるようになりました。CodeHS を使用するにあたり必要なのはインターネットとウェブブラウザだけです。生徒はオンラインでコードを書き、実行することができます。指導者は生徒が何に取り組んでいるか、そして進み具合などをすぐにチェックすることができます。

Amazon EC2Amazon RDSAmazon ElastiCacheAmazon CloudFrontAmazon S3 は CodeHS が世界中の学校のニーズに応えられるようにするため、同社のサイトをスケールできるようにしています。CodeHS はブラウザで生徒のコードをコンパイルし実行することに AWS を利用しています。これは、AP コースをサポートする Java のようなサーバー側の言語を教える上で非常に大切なポイントです。使用率は学校のスケジュールにより上下しやすいため、Amazon CloudWatchELB を使用して、生徒がコードを実行している時に簡単にスケールアップすることができ、シームレスな体験を可能にしています。

ぜひ CodeHS のウェブサイトをご覧ください。ご自分の教育機関でコンピュータサイエンスのコース導入をご検討の場合はこちらをご覧ください。

Insight (カリフォルニア州パロアルト)

2012 年に設立された Insight は、新しい教育モデルを築き、データチームの雇用における最適化やデータプロフェッショナルの転職をサポートしています。過去 5 年に渡り、Insight は市場動向を上手く把握し、Data ScienceHealth Data ScienceData EngineeringArtificial Intelligence など、いくつものプロフェッショナルトレーニングフェローシップを提供してきました。大企業そしてスタートアップ企業が適切な技術や経歴そして個性を携えた人材を探すことは簡単ではありません。Insight は最高の人材を集めるために 7 週間の集中講座から成るフェローシップを行っています。現在に至るまで、Insight は Amazon、Google、Netflix、Twitter、The New York Times を含む 350 社を超える企業に 1,000 人以上の卒業生を送り込んできました。

Insight のデータエンジニアリングチームはオープンソースやテクノロジーにおける現在のエコシステムに精通しており、この分野でベストプラクティスの指導を提供しています。様々なデータアドバイザリや指導において、テクニカルチームは常に外部グループと共同で作業を行っていますが、Insight パートナーの大半がプロフェッショナルセッションに参加しています。企業は Insight のオフィスを訪れ、カジュアルな環境でフェローと話し合い、どういったプロジェクトに取り組んでいるのか、そしてどのようにチームが成長しているのか、といった詳細を伝えます。こうしたセッションはフェローが実に優れたインタビュープロセスを経験できるので、とても価値があり企業もやる気のある新しいチームメンバーに呼応しています。

ビッグデータパイプラインからいままでにない機能への貢献、そして業界標準のオープンソースへの取り組みなど、Insight のフェローシップで重要な面は実践的な仕事を行うチャンスがあることです。Insight はフェロー全員が使用できるように無料で AWS リソースを提供しているほか、データエンジニアリングチームから指導を受けることも可能にしています。通常、フェローは Amazon S3Amazon EC2Amazon KinesisAmazon EMRAWS LambdaAmazon RedshiftAmazon RDS およびその他のサービスを使用しています。AWS を利用する経験は業界で実際に仕事をしていく上で、フェローに揺るぎないスキルを提供しています。フェローシップは現在ボストン、ニューヨーク、シアトル、ベイエリアで提供されています。

データインフラストラクチャ、人工知能、最先端のデータ製品の傾向に関する詳細については Insight の公式ブログをご覧ください。

 

iTranslate (オーストラリア)

2008 年に App Store が公開され次第、iTranslate の設立者は何か大きなことに関わるチャンスをそこに見い出しました。4 人から成るこのグループは、iPhone とアプリが世界を変えると信じ、独自のアプリを製作するためにブレインストーミングを行いました。そこで翻訳とモバイルデバイスは自然な組み合わせであると考え、2009 年に iTranslate を製作しました。iTranslate の目的は、旅行者や学生、ビジネスプロフェッショナル、社員、医療関係のスタッフが、すべての言語で世界中のどこにいても読み書きや会話を可能にすることです。このアプリでは、ユーザーがテキスト、音声、ウェブサイトを様々なプラットフォームでほぼ 100 か国語に渡り翻訳することができます。そして現在、iTranslate は会話の翻訳や辞書アプリの分野をリードし、そのダウンロード件数は 6,000 万件を超え、毎月のアクティブユーザー数は 600 万人にもなりました。

iTranslate はディスラプティブ技術やイノベーションで言語の壁を排除し、ユーザーがリアルタイムで翻訳することを実現しています。このアプリにはオフライン翻訳、ウェブサイトや音声翻訳、言語の自動検出を含む生産性を最適化するように設計された様々な機能が含まれています。また、最近になって iTranslate はスマートイヤホンに重点を置いている Bragi と協力し、世界初の「ear translation」デバイスをリリースしました。Dash Pro はユーザーの耳に直接翻訳を流しつつ、自由にコミュニケーションを取ることを可能にしています。

iTranslate は Amazon Polly が公開されるとすぐにそれを使い始めました。CEO の Alexander Marktl 氏は「業界をリードする翻訳および辞書アプリの企業として、iTranslate の目的はユーザーが世界中ですべての言語で読み書き、会話ができるようにする最高のツールを提供することです。Amazon Polly は、我々が高品質かつ自然に合成された音声を効率的に生成することを可能にしています」と、語っています。安定性があり使い勝手が簡単な API、低レイテンシー、フリーキャッシュを使用することで、iTranslate は同社のアプリに機能を追加していくに連れてスケールすることを可能にしています。ユーザーは音声の速度を変えたり、女性または男性の声に変えることができる点も楽しんで使っているということです。同社製品の品質、速度、信頼性を確かにするため、iTranslate は Amazon EC2Amazon S3Amazon Route 53 も利用しています。

iTranslate を使用するにはこちらで同社ウエブサイトをご覧ください。

—–

ご覧いただきありがとうございました。

-Tina

CloudFormation スタックセットを利用した 複数のAWSアカウントやリージョンを横断したリソース展開

AWS CloudFormation は、AWS を利用するお客様の Infrastructure as Code モデルの実現に役立ちます。環境やアプリケーションを手作業でセットアップする代わりに、テンプレートを構築しそれを使用することで必要な全てのリソース ― これら一連のリソースは CloudFormation スタックと呼ばれます ― を作成します。このモデルでは、手作業に起因する失敗が発生する可能性が排除され、効率性が増し、時間が経過しても一貫した設定が保証されます。

本日、CloudFormation がよりいっそう便利になる新機能についてご紹介したいと思います。この新機能は、複数の AWS アカウントおよび/または複数のリージョンを利用する状況において Infrastructure as Code を実践するときにお客様が直面する課題の解決に役立つように設計されています。

アカウント ― 以前お話したように、多くの組織で多数の AWS アカウントが使用されます。AWS アカウントを階層化し、組織単位、あるいはOU(詳しく知りたい場合は「AWS Organizations – 複数の AWS アカウントのポリシーベースの管理」をお読みください)へグルーピングするために AWS Organizations が利用されています。事業、アプリケーション、そしてデベロッパーに対して複数のアカウントが運用されます。またアプリケーション毎に、開発、テスティング、ステージング、そして本番のそれぞれに対して別々のアカウントが作成されることもあります。

リージョン ― 巨大な(かつ今なお成長し続ける)AWS のリージョンもまた大いに活用されています。2つかあるいはそれ以上のリージョンにまたがるグローバルアプリケーションが構築され、洗練されたマルチリージョン・ディザスタリカバリ・モデルが実装されています。また、S3AuroraPostgreSQL、そして MySQL のデータをリアルタイムにレプリケートし、国や地域の規制にしたがって機密データを保管および処理するための場所を選択します。

複数のアカウントやリージョンへのこのような展開は、ガバナンスと一貫性に関していくつかの新しい課題をともないます。新しく作成される各アカウントが社内の標準に従って設定されていることを確認したいと、お客様は言われます。とりわけ、IAM ユーザーと IAM ロール、VPC と VPC サブネット、セキュリティグループ、コンフィグルール、ロギング、そして AWS Lambda 関数を、信頼性があり一貫した方法でセットアップしたいと望まれます。

スタックセットのご紹介

これらの重要なご要望を解決するために、本日 CloudFormation スタックセットをリリースしました。CloudFormation テンプレート内に AWS リソースの設定を定義すると、それから数回のクリックで複数の AWS アカウント及び/あるいはリージョンにそれらを水平展開できるようになりました。上述したクロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップに、この機能を活用できます。一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。

この機能は、常にクロスアカウントベースで動作します。管理者のアカウントによって、1つ以上のスタックセットが保持されるとともに1つ以上の対象アカウントへのデプロイが制御されます。この管理者アカウントは引き受け可能な IAM ロールを保持しなければいけません。また、対象アカウントは管理者アカウントに対して信頼を付与しなければいけません。どのようにこの作業を行うかについては、スタックセットのドキュメント必要な条件をお読みください。

各スタックセットは、CloudFormation テンプレートを参照しアカウントとリージョンのリストを持ちます。全てのオペレーションは、スタックセット内の アカウント × リージョン の組み合わせそれぞれに対して適用されます。もしスタックセットが3つのアカウント(A1, A2, そしてA3)と4つのリージョン(R1, R2, R3, そしてR4)を参照する場合:

  • リージョンR1: アカウントA1, A2, そしてA3.
  • リージョンR2: アカウントA1, A2, そしてA3.
  • リージョンR3: アカウントA1, A2, そしてA3.
  • リージョンR4: アカウントA1, A2, そしてA3.

テンプレートをデプロイすると、まずアカウント/リージョンの組み合わせの1つに対して CloudFormation スタックの作成が開始されます。テンプレートは、各リージョン(順序を制御)と各リージョン内の複数のアカウント(並列度を制御)に順にデプロイされます。スタックの作成が失敗した場合にデプロイを終了するエラー閾値を設定することも可能です。

既存の CloudFormation テンプレートを使用することも可能ですが(アカウントとリージョンをまたいで動作する準備が整っていることを確認するよう注意してください)、新しいテンプレートを作成しても良いですし、あるいは AWS が予め用意するサンプルのテンプレートを使用することもできます。現在、一部のリージョン(中国を除く全てのパブリックリージョン)をサポートしていますが、そう長い時間をかけずにその他のリージョンにも展開できると予想しています。

スタックセットの使用

CloudFormation のコンソールからCloudFormation API を介して、あるいはコマンドラインからスタックセットを作成しデプロイすることが可能です。

コンソールなら、Create StackSet をクリックして開始します。自分自身のテンプレートを使うこともできますし、用意されたサンプルのテンプレートを使うこともできます。一連のサンプルの一番最後にある Add config rule encrypted volumes を使用してみます:

View template をクリックしこのテンプレートとテンプレートに記述されているルールの詳細を確認します:

このスタックセットに名前を付けます。今回選択したテンプレートはオプションのパラメータを受け取りますが、この値はこのタイミングで入力することができます:

次に、アカウントとリージョンを選択します。アカウント番号を直接入力するか、AWS 組織単位(OU)を参照するか、あるいはアカウント番号のリストをアップロードすることができます:

リージョンを設定しデプロイの順序を制御することができます:

デプロイメントのオプションを設定することも可能です。設定が完了したら Next をクリックして次に進みます:

スタックセットにタグを設定することができます。設定したタグは、このスタックセットのデプロイによって作成される AWS リソースに適用されます。

デプロイが始まり、コンソール上でデプロイのステータスを追跡することができます:

スタックのセクションを開いて各スタックを確認することが可能です。最初は各スタックのステータスは OUTDATED となっており、テンプレートがまだスタックにデプロイされていないことを示しています。問題なくデプロイが完了すると、ステータスは CURRENT に変わるでしょう。スタックがうまく削除できない場合には、ステータスは INOPERABLE に変わります。

この最初のデプロイが終わった後は、 Manage StackSet をクリックし、アカウントかリージョンあるいはその両方を追加したり、更にスタックを作成したりすることが可能です。

現在利用可能

この新機能は、現在利用可能であり追加料金なしに使い始めることができます(作成されたAWSリソースに対してのみ料金をお支払い頂きます)。

Jeff;

追伸 ― もし、役に立つテンプレートが出来上がって他のAWSユーザにも共有したいと思ったら、私達の AWS Labs GitHub リポジトリにプルリクエストを送ってください。

原文:Use CloudFormation StackSets to Provision Resources Across Multiple AWS Accounts and Regions(翻訳:SA畑史彦)

 

3つのトレーニングコースを新設(※日本では2コース開催)

エキスパートから学ぶことができる AWS トレーニングでは、実践的なスキルや AWS クラウドの活用方法について知識を増やすことができます。本日より、トレーニングブートキャンプでもっとも人気のある 3 つ (AWS re:InventAWS グローバルサミット でお馴染みです) のコースが、AWS によるインストラクター主導トレーニングの一部として含まれるようになりました。

こうした 1 日コースはエキスパートトレーナーから専門的なトピックの詳細を学びたい方を対象にしています。

コースカタログ一覧で詳細を見たり、お近くで開催される講座を AWS トレーニングと認定ポータルで検索することができます。チーム専用にプライベートのオンサイトトレーニングセッションをご希望の場合は、こちらからお問い合わせください。

Jeff;


日本ではお客様向けの新規2コースを9月から開始:

AWS Summit Tokyo 2017 のBoot Campメニューで選考提供した以下の2コースを、この秋より定期コースとしてリリースします。いずれも1日コースです。お申込みいただけるようになりましたら、改めてご案内致します。

·         Running Container-Enabled Microservices on AWS: 9/19(火)@西新宿会場

·         Building a Serverless Data Lake: 10/27(金)@西新宿会場