Author: AWS Japan Staff


異なる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(金)@西新宿会場

Amazon CloudWatch における高解像度メトリクスとアラーム

Amazon CloudWatch は 2009 年以来 AWS の重要な要素となっています。3 つの同時リリース (Auto ScalingElastic Load Balancing) の 1 つとして公開された CloudWatch は、AWS リソースや AWS クラウドで実行するアプリケーションをモニタリングする非常に強力なサービスに進化しました。CloudWatch カスタムメトリクス (2011 年にリリース) は CloudWatch でビジネスおよびアプリケーションメトリクスを保存できるようにし、グラフ表示や CloudWatch アラームをベースにアクションを開始することができます。数年間に渡り CloudWatch にいくつもの強化点を施してきたことは言うまでもありません。最近ではメトリクス保存期間の延長 (およびユーザーインターフェイスの更新)、ダッシュボードダッシュボードでの API/CloudFormation のサポートダッシュボードにアラームなどを追加してきました。

最初はメトリクスを 5 分間隔で保存していましたが、ユーザーから寄せられたリクエストに応え、2010 年にこれを 1 分間隔に変更しました (詳細モニタリング)。これについては高い評価を頂きましたが、そろそろレベルアップさせる時期が来ました。AWS をご利用されているお客様は 1 日に多数の動画をストリーミングしたり、フラッシュセールを行ったり、コードをいくつもデプロイしたりしています。さらに、状況が変わるに連れてすばやくスケールインまたはスケールアウトするアプリケーションも実行しています。こうした様々な状況において 1 分間隔では詳細性に欠けることになります。また、重要で一時的な増加を見逃してしまう可能性もあります。異種 (でありながら関連性のある) イベントを時間と関連付けるのは困難です。何か支障があった場合の MTTR (mean time to repair – 平均修復時間) に時間が掛かることもあるでしょう。

新しい高解像度のメトリクス
本日、高解像度のカスタムメトリクスを対象とするサポートを追加しました。また、今後 AWS サービスのサポートを追加することも計画しています。アプリケーションが 1 秒の解像度で CloudWatch にメトリクスを発行できるようになりました。発行後、数秒でメトリクスを画面で見ることができるほか、10 秒ごとに評価する高解像度の CloudWatch アラームをセットアップできます。

使用可能なメモリが低下するとアラームが起動すると想像してください。これは通常、頻度が低いサンプルではキャッチしにくい一時的な状態です。高解像度のメトリクスでは、数秒内に閲覧、検出 (アラームを使用)、対応することができます。

この場合、右側のアラームが開始しないので問題に気付くことがありません。

高解像度メトリクスの発行
高解像メトリクスを発行するには 2 つの方法があります。

  • APIPutMetricData 関数が StorageResolution パラメーターを許可するようになりました。このパラメーターを 1 に設定して高解像度メトリクスを発行します。スタンダードの 1 分間の解像度で発行するにはこれを排除 (または 60 に設定) します。
  • collectd プラグイン – 高解像度メトリクスのコレクションと発行をサポートするように collectd の CloudWatch プラグインを更新しました。そのため、 enable_high_definition_metrics パラメーターをプラグインの config ファイルで設定する必要があります。

解像度はメトリクスが古くなるに連れて低下するので、CloudWatch は徐々にロールアップするようになっています。スケジュール詳細は次の通りです。

  • 1 秒に設定したメトリクスは 3 時間使用可能です。
  • 60 秒に設定したメトリクスは 15 日間使用可能です。
  • 5 分に設定したメトリクスは 63 日間使用可能です。
  • 1 時間に設定したメトリクスは 455 日間使用可能です (15 か月)。

FIFO キューに対して GetMetricStatistics 高解像度メトリクスでは期間を 1、5、10、30 または 60 秒の倍数に指定することができます。標準メトリクスでは期間を 60 秒の倍数に指定することができます。

簡単なデモをお見せします
一番近い EC2 インスタンスを取得し collected および Python プラグインの最新バージョンをインストールします。

$ sudo yum install collectd collectd-python

次にプラグインのセットアップスクリプトをダウンロードし、実行可能にしてから実行します。

$ wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
$ chmod a+x setup.py
$ sudo ./setup.py

前もって適切な IAM ロールを作成済みなので、これをインスタンスに追加します。これはセットアップ中、自動的に検出されました。高解像度メトリクスを有効にするように促されます。

collectd が実行され、発行メトリクスが数秒で開始しました。CloudWatch コンソールを開き様子を見ます。

ズームインしてメトリクスの詳細を見ます。

memory.percent.used メトリクスを 10 秒間隔でチェックするアラームも作成します。これにより、短期間に大量のメモリがどこで使用されているか検出しやすくなります。

提供開始
高解像度のカスタムメトリクスやアラームはパブリック AWS リージョンで今すぐご利用いただけます。AWS GovCloud (US) でのサポートも近日中に提供する予定です。

従来通り、追加料金なしに毎月 10 件までのメトリクスを保存することができます。詳しくは「CloudWatch 料金表 (CloudWatch Pricing)」のページをご覧ください。高解像度メトリクスの料金は標準解像度メトリクスと同様です。より多くのメトリクスを使用すると、ボリューム層ベースで節約 (メトリクスごと) することができます。高解像度アラームの料金は 1 か月あたり各アラーム 0.30 USD です。

Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして

2017年7月19日前後より、Amazon Web Services(AWS)の一部のお客様に対し、“Securing Amazon S3 Buckets” という件名のメールをご送付させていただきました。Amazon S3 のバケットポリシーアクセスコントロールリスト(ACL)の設定の不備によって、Amazon S3 上の重要なデータが漏洩するセキュリティリスクに対する注意喚起となります。Amazon S3 のバケットポリシーや ACLの設定について、この注意喚起メールを必要な設定の見直しのきっかけにしていただければと思います。なお、メールを受け取られたお客様に、必ずしも問題があることを示すものではありません。

 

メールが送られた契機について

 

重要なデータが漏洩した事例のいくつかを調査した結果、バケット ACL を “All Users” や “All Authenticated AWS Users” に設定されているお客様はセキュリティリスクが高いと判断しています。該当するお客様は、設定の見直しを推奨すべくメールをお送り致しましたので、アクセスが広く許可されていることが本当に正しい状態か、今一度ご確認ください。

(more…)