Amazon Web Services ブログ

AWS Health Tools リポジトリを発表

今回は Tipu QureshiRam Atur を迎え、AWS Health / Personal Health Dashboard の Git リポジトリに関する最新情報についてご紹介します。

-Ana


改善操作の自動化やヘルスアラートのカスタマイズを可能にするコミュニティベースのツールソース、AWS Health Tools のリポジトリを本日リリースしました。AWS Health サービスは、AWS インフラストラクチャに影響するイベントにおいてユーザー独自の情報を提供します。これにより、予定済みの変更を実施しやすくしたり、ユーザーの AWS リソースやアカウントに関する問題のトラブルシューティングを促進することができます。また、AWS Health API は AWS リソースの基盤となる AWS サービスのパフォーマンスや可用性について、各ユーザーに適した情報を表示する Personal Health Dashboard を提供します。さらに Amazon CloudWatch イベントを使用すると、AWS Personal Health Dashboard (AWS Health) イベントのステータスで変更を検出し対応することができます。AWS Health Tools は AWS Health、Amazon CloudWatch イベント、AWS Lambda の統合を活用し、AWS インフラストラクチャに関するイベントへの対応の自動化をカスタマイズすることもできます。たとえば、AWS Health の問題に対応する上で CloudWatch イベントを生成した場合、AWS Health Tools を使用して AWS CodePipeline の一部となるデプロイメントを一時停止することができます。

AWSHealthToolsArchitecture

AWS Health Tools リポジトリは、AWS コミュニティが蓄積したアイデアと専門知識をユーザーが上手く活用することで、効率的に AWS Health イベントを利用できるようにします。リポジトリは無料で公開しているほか、独自のプラットフォームでホストされています。また、リポジトリにはフルソースコードが含まれているので、ユーザーは学びながら参加することができます。AWS のエキスパートと幅広い AWS ユーザーベースの専門知識を活用していけるよう、共に協力していくことを楽しみにしています。AWS Health Tools のサンプルはこちらをご覧ください。

こうしたツールを AWS アカウントで今すぐ使い始めるには GitHub の readme ファイルをご覧ください。

ご自分で作成した AWS Health Tools を AWS コミュニティと共有するには、このリポジトリの使用をおすすめします。

-Tipu Qureshi & Ram Atur

Amazon RDS – 2016 を振り返る

昨年は 294 件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。そこで今回は Amazon Relational Database Service (RDS) に焦点を当て、このファミリーが 2016 年に進歩を遂げたすべてのポイントに関する総集編をお届けします。去年、同チームは 4 つの主なエリアに注目しました。

  • 高可用性
  • 拡張モニタリング
  • セキュリティの簡略化
  • データベースエンジンの更新

では、これらのエリアを見ていきましょう。

高可用性
リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。高可用性の高いアプリケーションをお客様が構築できるようにするため、RDS は 2010 年初期からマルチ AZ サポートを提供しています (詳細は Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability をご覧ください)。データベースインスタンスの作成時にマルチ AZ 配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。また、RDS はクロスリージョンリードレプリカを作成しやすくします。高可用性を実現しやすくするため、AWS が 2016 年に行ったその他の機能強化については次のブログをご覧ください。

 

拡張モニタリング
MySQL、MariaDB、Amazon Aurora のサポートなど、拡張モニタリングで行った最初の大きなステップは 2015 年末のことでした (New – Enhanced Monitoring for Amazon RDS)。そして引き続き 2016 年にも新たなニュースをお届けしました。

 

セキュリティの簡略化
保管中または利用中にかかわらず、お客様のデータを保護するための暗号化を可能な限りシンプルで使いやすくしたいと考えています。昨年に施した強化機能については次をご覧ください。

 

データベースエンジンの更新
オープンソースコミュニティと商用データベースのベンダーは非常に速いペースで新機能を追加したり新しいリリースを製作しています。AWS はその作業を密接に把握し重要なリリースに合わせて、できる限り早急に RDS を更新できるように努めています。2016 年のリリース内容については次をご覧ください。

 

次回の投稿
今年はすでに大きな発表がありました (詳細は AWS 2017 年の最新情報をご覧ください)。最近お知らせしたニュース (PostgreSQL との互換性を備えた Aurora バージョン) はもちろん、その他にも色々ご用意しています。お楽しみに! RDS、Amazon AuroraAmazon ElastiCache を最大限に活用する方法を詳しく説明している AWS データベースブログへの参加もご検討ください。

Jeff;

追伸 – このブログ投稿には、去年 AWS Database Migration Serviceスキーマ変換ツールに施したすべての強化機能は含まれていません。このトピックについては別件でブログを投稿する予定です。

Streamlineのケーススタディ:Amazon GameLiftで加速リリース

Screenshot_ProletariatQuote_V2

Proletariatについて

ボストンに拠点を置くProletariatは、革新的なマルチプレイヤー体験の構築に焦点を当てたインディーゲーム企業です。5人のゲーム業界のベテランによって2012年に設立されました。彼らは、賞を獲得したWorld Zombinationの立案者です。World Zombinationは、プレイヤー同士が共に戦略を立て合ってゾンビや人間の大群を用いて街を破壊したり守ったりする巨大なオンラインゲームです。彼らの最新のマルチプレイヤーゲームであるStreamlineは、オーディエンスのインタラクティブなゲーム参加が特徴であり、ストリーミング配信者や視聴者が試合中にゲームプレイルールをリアルタイムに変更することができます。

課題

Proletariatは、3月のGDC 2016でStreamlineを公表し、ゲームストリーマーのプレミアムイベントである9月のTwitchCon 2016でベータ版を公開する予定であると告知していました。しかし、TwitchCon 2016のTwitch Prime一般公開に含めないかという話をAmazonが持ちかけたところ、ProletariatはStreamlineを誰でもプレイできるようにするために開発を加速することを決めました。彼らは興奮する一方で、自分たちの独自のゲームサーバソリューションが、管理に手間がかかり過ぎることと増加していくプレイヤー需要をサポートするために必要な機能が足りていないことを気にしていました。

Proletariatの独自のクラウドソリューションはAWS Elastic Container Service (ECS)を中心に構築されていました。AWS ECSは、AWS EC2インスタンス上のアプリケーションの管理を容易にしてくれるコンテナ管理のサービスです。サーバのヘルスチェックを実行したりプレイヤーを利用可能なゲームサーバに接続するなど、彼らは基本的なゲームサーバの機能を手動で操作していました。これらのプロセスによってプレイヤーの負荷が処理されますが、Streamlineが一般利用可能になってしまえば管理は手間がかかり過ぎるでしょう。また、彼らの独自のクラウドソリューションは、どのゲームサーバがアクティブなゲームセッションを保持しているかというこを特定することができませんでした。これは、サーバのキャパシティを手動で調整している間に誤ってアクティブなゲームセッションを縮小し、プレイヤーをStreamlineから切断してしましまう可能性があることを意味していました。単一のEC2インスタンス上で複数のゲームサーバプロセスを実行することができないので、テストをシンプルにすることも困難でした。各ゲームサーバはユニークな公開ポートを必要としますが、コンテナ内部からはその公開ポートを取得することができませんでした。

Proletariatは、ゲームサーバのホスティングにAWSの実績のあるインフラストラクチャを使い続けることを希望していましたが、必要な機能を構築するには数千時間はかかりそうでした。あっという間ににTwitchCon 2016の開催は近づき、ProletariatはAmazon GameLiftを紹介されました。Amazon GameLiftはAWSのマネージドサービスです。ゲームサーバのホスティングをシンプルにしサーバキャパシティを数分でスケールします。

「Proletariatのチームにとって選択肢は非常にシンプルでした。つまり、我々のクラウドインフラストラクチャを構築するのに数ヶ月を費やすためにエンジニアチームを雇うか、あるいはAmazon GameLiftで数分でデプロイするか、です。」とProletariat社CEOの Seth Sivakは言いました。

実装

Proletariatは、Amazon GameLift Server SDK for C++をダウンロードしUnreal Engineゲームサーバのビルドに統合し、ゲームサーバをAmazon GameLiftにアップロードしました。Unreal Engineゲームサーバを格納するために、5つのGameLiftインスタンスタイプのどれが自分たちのニーズに最も適しているかを判断する必要がありました。「リアルタイムゲームでは、ネットワークが最適化されたAmazon GameLiftインスタンスが必要でした。そのため、私達は一連のインスタンスにc4.xlarge.gameliftを選択しました。」とStreamlineのリードエンジニアである Cauê Waneck は言いました。「Amazon GameLiftは、各インスタンス上で4つのゲームサーバをサポートするように実行設定を構成することができます。これは、私達のゲームサーバがシングルスレッド構成であることを考えると完璧です。これにより、vCPUあたり1つのゲームサーバプロセスをうまく活用できるようになり、テストとイテレーションのプロセスが大幅にシンプルになります。」

独自に作成したNode.jsのマッチメイキングシステムとAmazon GameLift上のC++のゲームサーバ間のゲームセッションの新規作成を管理するために、ProletariatはAWS JapaScript SDK with Amazon GameLiftを使用しました。また、彼らはクイックマッチに利用可能なキャパシティを持つゲームサーバを見つけるために特殊なゲームセッションデータを使用しました。このデータは、サーバが新規プレイヤーを受け入れるべきかどうかを分類し、どのゲームセッションが利用可能なプレイヤースロットを持っているかを特定するのに役立ちました。「Amazon GameLiftは、大量のプレイヤーのマッチメイクを容易にし、待ち時間を減少させました。」とWaneckは言いました。「さらに、ゲームセッションをパーティーリーダーに関連付けるということが可能だったので、プレイヤーにカスタムゲームマッチの開催を可能にするというかたちでも役に立ちました。」

Proletariatは、アクティブなゲームを保持するインスタンスがスケールダウンされてプレイヤーをオフラインにしてしまうことを防ぐために、Amazon GameLift組み込みのゲームセッション保護の有効化も行いました。「Amazon GameLiftは保険のようなものです。サーバのスケーリング、とりわけ起動時のスケーリングにおいて安心を与えてくれます。」とWaneckは言いました。

AWS Command Line Interface (CLI) with Amazon GameLiftによって、彼らのビルドシステムにロジックを実装するときに新しいインスタンス群を起動してコマンドを再利用することが容易になりました。ゲームクライアントの更新をデプロイする際に、シンプルなコマンドを使用してAmazon GameLiftのエイリアスを利用し、プレイヤーを1つのインスタンス群から別のインスタンス群にダウンタイムなしで移動させました。また、CLIを使用して世界中のリージョンにゲームサーバをたった数分で起動しました。「Amazon GameLiftチームは私達を全面的にサポートしてくれました。私達が運用上の問題に取り組むのを助けるために24時間365日彼らがいてくれたのは嬉しいことです。」とWaneckは言いました。

わずか5日間で、ProletariatはAmazon GameLiftを使用し自信を持ってTwitchCon 2016にStreamlineをリリースしました。Amazon GameLiftによって数千時間の開発時間が節約され、代わりにStreamlineのコアである革新的なゲームプレイに磨きをかけることに専念しました。

詳細情報

Amazon GameLiftを用いた専用のゲームサーバのホスティングやスケーリングの方法の詳細をご覧ください。Streamlineについての詳細はplaystreamline.comをご覧ください。

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

JSONSerDe によるマッピングを使って,入れ子の JSON から Amazon Athena のテーブルを作成する

多くのシステムでは、イベント情報を記録するのに Java Script Object Notation (JSON) を使っています。JSON は効率的かつ柔軟ではありますが、JSON から情報を取り出すのは面倒です。

この投稿では、ログデリバリー手段としての Amazon Kinesis Firehose、ログ保存先としての Amazon S3、データの加工整形やデータベースへの挿入なしに ログに対して JSONSerDe を使って SQL クエリを投げる手段としての Amazon Athena を、緊密に連携させます。これらの処理は、完全にサーバーレスで行われます。コンピューティングリソースを準備する必要はありません。

Amazon SES を使えば、サービス間の全メッセージに対する詳細なログが入手でき、SES イベント発行によって、それを Firehose でも利用することができます。しかし、トレンドやコンプライアンスのデータに関する詳細ログのパースには、多額のインフラ投資や開発期間が必要となります。Athena は保存されているデータに対して、そのままのフォーマットで、コードを書いたりアーキテクチャ設計をしたりすることなく直接クエリできることにより、こうしたデータ探索に非常に適しています。その上、Athena では多くの標準 SQL クエリとシンタックスが利用可能です。

ウォークスルー: データセットの作成

まず、以下のような SES 送信イベントのデータセットをみてみましょう。

{
	"eventType": "Send",
	"mail": {
		"timestamp": "2017-01-18T18:08:44.830Z",
		"source": "youraddress@example.com",
		"sourceArn": "arn:aws:ses:us-west-2:111222333:identity/youraddress@example.com",
		"sendingAccountId": "111222333",
		"messageId": "01010159b2c4471e-fc6e26e2-af14-4f28-b814-69e488740023-000000",
		"destination": ["success@simulator.amazonses.com"],
		"headersTruncated": false,
		"headers": [{
				"name": "From",
				"value": "youraddress@example.com"
			}, {
				"name": "To",
				"value": "success@simulator.amazonses.com"
			}, {
				"name": "Subject",
				"value": "Bounced Like a Bad Check"
			}, {
				"name": "MIME-Version",
				"value": "1.0"
			}, {
				"name": "Content-Type",
				"value": "text/plain; charset=UTF-8"
			}, {
				"name": "Content-Transfer-Encoding",
				"value": "7bit"
			}
		],
		"commonHeaders": {
			"from": ["youraddress@example.com"],
			"to": ["success@simulator.amazonses.com"],
			"messageId": "01010159b2c4471e-fc6e26e2-af14-4f28-b814-69e488740023-000000",
			"subject": "Test"
		},
		"tags": {
			"ses:configuration-set": ["Firehose"],
			"ses:source-ip": ["54.55.55.55"],
			"ses:from-domain": ["amazon.com"],
			"ses:caller-identity": ["root"]
		}
	},
	"send": {}
}

 

このデータセットには、 SES の送受信に関する多くの価値ある情報が含まれています。インサイトを得るためにパース処理が必要な、同じ形式のデータセットが山ほどあります。まずはデータを取得しましょう。

1. SES のコンソールまたは CLI から、Firehose のデリバリーストリームを S3 に対しニアリアルタイムで送信、保存する configuration set を作成します。

NestedJson_1

2. SES を使ってテストメールを送ってみます。送信の際に、作成した configuration set を使用するよう指定します。

SES コンソールから指定を行う場合、More options を選択してください。Configuration Set を含む、いくつかのフィールドが表示されます。

NestedJson_2

また SES の検証手順や AWS CLI を使って、メールボックスシミュレータのアドレスにメッセージを送信できます。

$ aws ses send-email --to bounce@simulator.amazonses.com --from youraddress@example.com --subject "Bounced Like a Bad Check" --text "This should bounce" --configuration-set-name Firehose

3. ログが蓄積される S3 バケットを指定します。

NestedJson_3

ウォークスルー: Athena でクエリ

Amazon Athena は、Amazon S3 に置かれたデータに対し標準 SQL を使って簡単に分析を行える、インタラクティブなクエリサービスです。Athena を使うためにはサーバを用意する必要はなく、したがってインフラを管理する必要もありません。実行したクエリに対してのみ、料金が発生します。CSV,、JSON、ORC、そして Parquet といったさまざまな標準的なデータフォーマットに対応しています。

Hive メタストアと互換性のある DDL ステートメントを用いて、データスキーマを定義することによって、Athena がデータを処理できるようになります。Athena は分散 SQL エンジンの Presto を使用して、クエリを実行します。また Apache Hive の DDL シンタックスによってテーブルやパーティションの作成、削除、変更を行います。Athena は schema-on-read と呼ばれるアプローチを採用しており、それによりクエリを実行するタイミングで初めてスキーマを付与することになります。クエリの結果を得るために、ログに含まれる各フィールドを、対応するカラムにマッピングすることになります。

もし Apache Hive にすでに慣れている場合には、Athena でのテーブル作成は非常に似たやり方で行えます。クエリエディター、ウィザード、JDBCドライバーのいずれかを使って DDL ステートメントを記述することで、テーブルを作成できます。テーブル作成の中で大事なのは SerDe (“Serializer and Deserializer” の略称) です。データフォーマットが JSON のため、Athena でもともとサポートされている org.openx.data.jsonserde.JsonSerDe を使って、データのパースを行います。その際には、Hive/Presto と JSON データセットにまつわる2つのよくある問題に対処しなければなりません。

  • 入れ子または複数階層の JSON
  • (マッピングの制御に使われる) 禁止文字

Athena のクエリエディタでは、最初の Athena テーブルを作る際には次のような DDL ステートメントを使います。LOCATION にはログが置かれている S3 のファイルパスを指定します。

CREATE EXTERNAL TABLE sesblog (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

この DDL ステートメントでは、Presto のデータ型に合わせて JSON データセット内のフィールドを宣言しています。またオブジェクトのグループを扱うために、配列や構造体に似た、Hive のコレクション型を使用しています。

ウォークスルー: 入れ子の JSON

JSON が 3段階で入れ子になっていることにより、mail キーの定義はとてもややこしい形になります。この例では、他のさまざまなキーが入れ子になって内部に含まれた mail という構造体を、一番上の階層で作成します。mail には messageId や destination が2つめの階層として含まれます。timestamp フィールドは、バッククォート (`) 文字に囲まれています。timestamp は Presto のデータ型として予約語になっているため、テーブル作成において混乱が生じないように、予約語と同一名のカラムを定義する際にはバックォートで囲む必要があります。3番目の階層はヘッダデータになります。ここには 名前:値 のペアが複数含まれます。<name:string, value:string> の形をしたオブジェクトの配列として、スキーマの定義ができます。なお予約語のカラムを作成するためには、commonHeaders struct の中にある `from` のようにバックスラッシュで囲む必要があります。

これでテーブルが作成され、クエリを投げることができるようになりました!

SELECT * FROM sesblog limit 10;

この出力結果では、eventTypemail という2つの最上位階層のカラムが表示されていますが、これだとクエリした結果のデータが取得できた、以上の有益な結果は得られません。分析したいデータを取得するために、入れ子表記を使用したクエリを使うことができます。

“月曜日のキャンペーンで、宛先不明で戻ってきたメッセージはどれか?”

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID,
       mail.timestamp as Timestamp
FROM sesblog
WHERE eventType = 'Bounce' and mail.timestamp like '2017-01-09%'

“あるドメインで、宛先不明で戻ってきたメッセージは何件か?”

SELECT COUNT(*) as Bounces 
FROM sesblog
WHERE eventType = 'Bounce' and mail.destination like '%amazonses.com%'

“amazonses.com ドメインに戻ってきたメッセージはどれか?”

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID 
FROM sesblog
WHERE eventType = 'Bounce' and mail.destination like '%amazonses.com%'

データセットからユースケースに応じた結果を得るために、さらに突っ込んだクエリを書くこともできます。作成したテーブルでは、JSON イベント内の tags セクションについてはスキーマを指定していません。続いてはこれをみていきます。

ウォークスルー: マッピングにおける禁止文字の取り扱い

データセットに対する DDL を最初に書く際に、真っ先にぶつかる問題として、ログフォーマットを変更するのが困難であるということと、Hive ではデータ型を定義する際にコロン (:) が大きな役割を果たしているということが挙げられます。イベント内の tag セクションについて、各フィールドをパースするために、JSONSerDe を使う必要があります。このデータによって誰がメッセージを作成したのかがわかるため、監査やセキュリティのユースケースにおいて非常に大事なものです。

Athena のクエリエディタで、以下の DDL を実行して 2 つめの Athena テーブルを作成しましょう。LOCATION として、ログが置かれている S3 バケットを指定します:

CREATE EXTERNAL TABLE sesblog2 (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,ses_source_ip:string,ses_from_domain:string,ses_caller_identity:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

新しいテーブルを作成する際に、SERDEPROPERTIES の記述を書き加えます。これにより、SerDe に追加のパラメタを与えることができます。カラム名の真ん中に : を含んでいるデータを取り扱うための、マッピングのプロパティを記述します。これにより、ses:configuration-setses というカラム名に configuration-set というデータ型が指定されたものとして解釈されます。先ほどの記述と違い、この場合はバッククォートで囲むことはできません。JSON SERDEPROPERTIES のマッピングセクションでは、テーブル作成の際にあらゆる不正な文字を再マッピングしてしまいます。

例えば、ses データ内の ses:configuration-set に対して、先ほどの定義をすることで、Athena に対して ses_configurationset の形でクエリを投げることができます。このマッピングは、S3 嬢のデータに対しては一切変更を加えません。これは Hive の概念としてのみ取り扱われ、既存のデータを置き換えるものではありません。プロパティ内で 4 つのフィールドをマッピングして(コロンを含んだものをすべて、サポートされているアンダースコアに置き換えています)、tag の構造体を作成する際に、この新しいマッピングされた名前を使います。

これで、そのほかの認証・監査に関するカラムにアクセスできるようになったので、クエリを投げることでさらなる疑問を解決できます。

“すべての宛先不明なメッセージを作成したのは誰か?”

SELECT eventtype as Event,
         mail.timestamp as Timestamp,
         mail.tags.ses_source_ip as SourceIP,
         mail.tags.ses_caller_identity as AuthenticatedBy,
         mail.commonHeaders."from" as FromAddress,
         mail.commonHeaders.to as ToAddress
FROM sesblog2
WHERE eventtype = 'Bounce'

特筆すべき点として、mail.commonHeaders.”from” の取り扱いがあります。from は Presto の予約語なので、予約語と解釈させないためにダブルクォーテーション (“) で囲む必要があります。

ウォークスルー: SES カスタムタギングに対するクエリ

SES では AWS の外に対するメッセージに対して、カスタムタグをセットすることができるため、この mail.tag は非常に重要な意味を持ちます。大事なメッセージに tag を付与しておき、その tag を用いて Athena で分析することができます。例えばマーケティングキャンペーンを補足するためにキャンペーンタグを使いたい場合、SES CLI から -tags オプションを使ってタグを付与することができます:

$ aws ses send-email --to success@simulator.amazonses.com --from youraddress@example.com --subject "Perfume Campaign Test" --text "Buy our Smells" --configuration-set-name Firehose --tags Name=Campaign,Value=Perfume

この結果には、カスタムタグが付与されたエントリーが含まれます。

…
		"tags": {
			"ses:configuration-set": ["Firehose"],
			"Campaign": ["Perfume"],
			"ses:source-ip": ["54.55.55.55"],
			"ses:from-domain": ["amazon.com"],
			"ses:caller-identity": ["root"],
			"ses:outgoing-ip": ["54.240.27.11"]
		}
…

キャンペーンタグを管理するための 3 つめのテーブルを作成します。

CREATE EXTERNAL TABLE sesblog3 (
  eventType string,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:string,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,Campaign:string,ses_source_ip:string,ses_from_domain:string,ses_caller_identity:string>
              > 
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/' 

そして各メールに付与したカスタムタグを使ってクエリを実行することができます。

SELECT eventtype as Event,
       mail.destination as Destination, 
       mail.messageId as MessageID,
       mail.tags.Campaign as Campaign
FROM sesblog3
where mail.tags.Campaign like '%Perfume%'

NestedJson_4

ウォークスルー: プログラムによって hive-json-schema を使った DDL を作成

これらの全ての例では、SES のインタラクションタイプとして send のみをもとにして、テーブル作成を行っています。SES には他にも、delivery、complaint、bounce などのインタラクションタイプがあり、それぞれ複数の追加フィールドを持っています。これらに対応するために、すべての異なる SES eventTypes をパースし、1 つのテーブルとしてクエリできるようなマスター DDL を作成します。

適切に動作する JSONSerDe DDL を作業で記述するのは、退屈な上に間違いを起こしやすいので、ここでは AWS サポートでよく用いられている、オープンソースのツールを使用します。これを使った場合、コロンを含む SES カラムのマッピングのみ記述するだけになります。

このサンプル JSON ファイルには、すべての SES イベントタイプで取りうる全てのフィールドが含まれています。hive-json-schema を使うことで,入れ子になった JSON DDL を記述することができます。

こちらが全てのタイプの SES ログにクエリできる “マスター” DDL です:

CREATE EXTERNAL TABLE sesmaster (
  eventType string,
  complaint struct<arrivaldate:string, 
                   complainedrecipients:array<struct<emailaddress:string>>,
                   complaintfeedbacktype:string, 
                   feedbackid:string, 
                   `timestamp`:string, 
                   useragent:string>,
  bounce struct<bouncedrecipients:array<struct<action:string, diagnosticcode:string, emailaddress:string, status:string>>,
                bouncesubtype:string, 
                bouncetype:string, 
                feedbackid:string,
                reportingmta:string, 
                `timestamp`:string>,
  mail struct<`timestamp`:string,
              source:string,
              sourceArn:string,
              sendingAccountId:string,
              messageId:string,
              destination:string,
              headersTruncated:boolean,
              headers:array<struct<name:string,value:string>>,
              commonHeaders:struct<`from`:array<string>,to:array<string>,messageId:string,subject:string>,
              tags:struct<ses_configurationset:string,ses_source_ip:string,ses_outgoing_ip:string,ses_from_domain:string,ses_caller_identity:string>
              >,
  send string,
  delivery struct<processingtimemillis:int,
                  recipients:array<string>, 
                  reportingmta:string, 
                  smtpresponse:string, 
                  `timestamp`:string>
  )           
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  "mapping.ses_configurationset"="ses:configuration-set",
  "mapping.ses_source_ip"="ses:source-ip", 
  "mapping.ses_from_domain"="ses:from-domain", 
  "mapping.ses_caller_identity"="ses:caller-identity",
  "mapping.ses_outgoing_ip"="ses:outgoing-ip"
  )
LOCATION 's3://<YOUR BUCKET HERE>/FH2017/'

結論

この投稿では、AWS サービスのログで使われている JSON 形式のデータに対して、Amazon Athena のクエリを投げる実際的なユースケースを紹介しました。ユースケースの中には、宛先不明や迷惑メールフラグを集計するようなものがありました。その他にも、キャンペーンの効果検証のレポーティングのようなものもあります。さらに、どのインスタンスやユーザーがメールを送信したかといった、監査やセキュリティに関するものもありました。さらに入れ子の JSON を扱う方法や SerDe のマッピングについて触れることで、データを加工整形することなく元のフォーマットのままでクエリを投げることができました。

AWS QuickSight のような新しい ツールを使うことで、こうしたデータからダッシュボードを作成することができます。これによりデータのレポーティングがさらに簡単になります。Athena を QuickSight のデータソースとして使う方法は、こちらのブログ記事を参照してください。

さらに、クエリのパフォーマンスを向上させるための最適化を行ったり、、必要なデータだけをスキャンすることでスキャンデータ量を削減するためにパーティションを設定したり、といった改善を実施することができます。限られた時間内にレポートを出す必要があるときには、S3 のライフサイクル設定を使用して、古くなったデータを Amaazon Glacier に移動させたり、削除したりといった対応を取ることもできます。

原文: Create Tables in Amazon Athena from Nested JSON and Mappings Using JSONSerDe(翻訳: SA 志村)

AWS クイックスタートの更新 – Tableau、Splunk、Compliance、Alfresco、Symantec

AWS クイックスタートは AWS で人気のソリューションのデプロイをサポートします。各クイックスタートは AWS のソリューションアーキテクトやパートナーが設計し、セキュリティや高可用性における AWS のベストプラクティスを活用しています。テストまたは本番稼働環境ですぐにクイックスタートをご利用いただけます。シングルクリックで起動できるクイックスタートには、広範囲にわたる内容を取り上げたデプロイメントガイドと AWS CloudFormation テンプレートが含まれています。クイックスタートは次の 7 つのカテゴリに分類されています。

  • 開発運用
  • データベースとストレージ
  • ビッグデータと分析
  • セキュリティ & コンプライアンス
  • Microsoft & SAP
  • ネットワークとアクセス
  • その他

過去 2 か月間で 6 つの新しいクイックスタートをコレクションに追加し、合計数は 42 件になりました。次に、新しいクイックスタートの各カテゴリの概要をご紹介します。

Tableau Server (ビッグデータと分析)
AWS クイックスタートの Tableau ServerAWS Cloud で完全に機能する Tableau Server のデプロイをサポートします。デフォルト VPC でシングルノードを起動したり、新規または既存の VPC でマルチノードクラスターのデプロイメントができます。クラスターアーキテクチャについてはこちらをご覧ください: CloudFormation テンプレートは Tableau アクティベーションキーについてもプロンプトを表示します。

Splunk Enterprise (ビッグデータと分析)
AWS クイックスタートの Splunk Enterprise は、AWS クラウドで分散した Splunk Enterprise 環境のデプロイをサポートします。2 つ以上のアベイラビリティーゾーンと既存の VPC で開始したり、新しい VPC を作成することができます。アーキテクチャについてはこちらをご覧ください: テンプレートは S3 バケット名と Splunk ライセンスファイルへのパス (バケット内) のプロンプトを表示します。

UK OFFICIAL (セキュリティ & コンプライアンス)
AWS クイックスタートの UK-OFFICIAL は United Kingdom (UK) OFFICIAL により分類されたワークロードをサポートする、標準化された AWS クラウド環境をセットアップします。この環境は NCSC Cloud Security Principles と CIS Critical Security Controls にある対象サービスのガイドラインに準拠します (詳細はセキュリティコントロールマトリックスをご覧ください)。アーキテクチャについてはこちらをご覧ください:

Alfresco One
AWS クイックスタートの Alfresco One は、AWS クラウドで Alfresco One Enterprise Content Management サーバークラスターのデプロイをサポートします。既存の VPC にデプロイまたはパブリックサブネットやプライベートサブネットで新しい VPC をセットアップできます。アーキテクチャについてはこちらをご覧ください: クラスターを起動するには Alfresco のトライアルライセンスが必要です。

Symantec Protection Engine (セキュリティ & コンプライアンス)
AWS クイックスタートの Symantec Protection Engine は、1 時間以内に Symantec Protection Engine (SPE) をデプロイできるようにサポートします。デプロイが完了すると (新規または既存の VPC にデプロイが完了)、SPE の API を使用してマルウェア検出や脅威検出をアプリケーションに組み入れることができます。さらにプロキシと連携すれば、ウィルスやトロイの木馬またはその他のマルウェアが潜んでいないかトラフィックをスキャンすることもできます。アーキテクチャについてはこちらをご覧ください: クイックスタートを使用するには、SPE ライセンスを購入するか SPE AMI に登録してください。 クイックスタートの詳細についてはクイックスタートのよくある質問をご覧ください。クイックスタートの設計に参加するにはクイックスタート協力者向けガイドをご覧ください。

Jeff;

SAP Database Migration Option(DMO)を使ったAWSへの移行

Somckit Khemmanivanhは、Amazon Web Services (AWS)のSAPソリューションアーキテクトです。

このブログ記事では、SAP Software Update Manager(SUM)の機能であるDatabase Migration Option(DMO)を使って、AnyDBデータベースからAWS上のSAP HANAに移行する方法を説明します。SAPでは、SAP社がサポートするSAP HANA以外のソース・データベース(DB2、Oracle、SQL Serverなど)を指すときに、AnyDBという用語を使用しています。ここでは、オンプレミス・アーキテクチャからAWSへの移行オプションについて説明します(ここで留意すべきは、SAP HANAがターゲット・プラットフォームでない場合、他にも多くの移行オプションがあることです。詳細はホワイトペーパーMigrating SAP HANA Systems to X1 Instances on AWSをご覧ください)。

SAP HANAは完全なインメモリーで、列指向に最適化され、また圧縮されたデータベースです。 SAP社により認定されたSAP HANAシステムでは、160+ GB RAMから2TB RAMまでのシステムでSAP HANAデータベースをスケールアップ構成として稼働できます。また、最大14TBまでの認定されたスケールアウト構成も利用可能です。AWSであれば、このシステム構成の柔軟性により、ビジネスとITのニーズに合わせて拡張することができます。もしこれ以上のメモリーを要求するワークロードがある場合は、ぜひご連絡ください。私たちは、お客様要件にお応えできるよう取り組みたいと考えています。

DMOの概要については、SAP Community Networkをご覧ください。大まかには、AnyDBで稼働するSAPシステムをSAP HANAデータベースに移行する際にDMOを使うことができます。また、DMOにより、SAPシステムのソフトウェア・アップグレードとユニコード変換を移行時に合わせて行うこともできます(Enhancement Package(EHP) 8以降、ユニコードは必須)。 標準的なDMOのプロセスでは、ソースのAnyDBをターゲットのSAP HANAデータベースにオンラインかつ直接移行します。

sap-hana-dmo-process

図1: SAP HANA DMOのプロセス

移行先がAWS上のSAP HANAシステムである場合、この直接の移行プロセスを容易にするためにネットワーク接続を確立する必要があります。加えて、標準的なDMOのプロセスにおいて、SAP Note 2277055 – Database Migration Option (DMO) of SUM 1.0 SP18に記載されているように、特定の制限があります(SAPノートの参照には、SAP Service Marketplaceの資格情報が必要です) 。このSAPノートには、ネットワーク接続を介して(つまり、データセンター間で)DMO転送を実行する際の制限事項が説明されています。私たちが行ったテストと経験では、レイテンシーはDMOの実行時間に多少の影響を及ぼします。私たちは、お客様のアーキテクチャと設計を評価し、可能な解決策を提示する支援もいたします。 ぜひ、sap-on-aws@amazon.comまでお問合せください。

AWSでは、標準のDMOの範囲を超えた追加の移行オプションもご用意しています。AWSアドバンスドテクノロジーパートナーのATADATAが提供するATAmotionのような移行自動化製品を使うことで、ソース・システムを(オンプレミスのネットワークから)AWS上に複製し、複製されたシステムからDMOを使ってSAP HANAに移行できます。AWSのパートナーが提供するそれ以外の移行ツールやサービスは、AWSパートナーソリューションファインダーから探していただけますでしょうか。

一旦ソース・システムをAWS上に持ち込めば、AWSサービスの俊敏性と柔軟性を活用して、移行をテストしたり、本番移行を実施したりできます。シナリオの一例として、DMOによるダウンタイム最適化のテストを複数実施するなどがあります。それぞれのテストにおいて、EC2インスタンスのサイズ変更を活用することで、異なるシステムサイズや組合せを試すことができます。

大まかなプロセスとツールについて説明しましたので、ここからは2つの移行オプションに含まれる手順を説明します。まず、標準的なDMOの移行プロセスから始めます。このプロセスでは、現行のSAPシステムがオンプレミスのデータセンター内にあり、AWSに接続する必要のある単一のコンポーネントがDMOサーバーであることが前提となります。移行中、DMOサーバーはソース・データベースからターゲットのSAP HANAデータベースにデータをエクスポートします。この移行プロセスは以下のステップで構成されます:

      1. AWSアカウントを作成していない場合は作成します。
      2. WebサイトAWS Answersに掲載されているAWS Single VPC Designの図のように、データセンターとAWSリージョン間の仮想プライベートネットワーク(VPN)、またはAWS Direct Connect接続を確立します。設計上の考慮事項と詳細については、”Internal-Only VPC”の項を参照してください。vpc-connectivity-for-dmo

        図2: DMOによる移行のためのVPC接続

      3. SAP HANAデータベースインスタンスとSAPアプリケーションインスタンスを展開します(導入手順はSAP HANA Quick Startを参照してください)。
      4. DMOサーバーを構築します(DMOサーバーはオンプレミスでもAWS上どちらでも使うことができます)。DMOサーバーは 、ソースのデータベースサイズ、性能要求、システムリソース、およびダウンタイムなどの要件に応じて、独立したサーバーまたはSAPアプリケーションサーバーと同じ場所に配置できます(このステップの詳細はSAP社資料を参照してください)。
      5. オンプレミスのDMOサーバーとAWS上のSAP HANAデータベースインスタンス間の接続をテストします(詳細については、APNブログのAmazon VPC for On-Premises Network Engineersシリーズを参照してください)。
      6. DMOを使用して、オンプレミスのデータベースをAWS上のSAP HANAデータベースに移行します(詳細はSAP社資料を参照してください)。
      7. SAP HANAデータベースインスタンスに接続する新しいSAPアプリケーションサーバーをAWS上にインストールします(詳細はSAP社資料を参照してください)。

dmo-migration

図3: 標準的なDMOのアーキテクチャ

2つ目の移行オプションとして、AWSパートナーツールを使用してソース・システムをAWS上に複製した後、SAP HANAに移行する方法を説明します。このプロセスを使用するには、現行のSAPシステムがオンプレミスのデータセンター内に存在する必要があります。この手順は、標準的なDMOのプロセスに似ています:

      1. AWSアカウントを作成していない場合は作成します。
      2. WebサイトAWS Answersに掲載されているAWS Single VPC Designの図のように、データセンターとAWSリージョン間のVPN、またはAWS Direct Connect接続を確立します。設計上の考慮事項と詳細については、”Internal-Only VPC”の項を参照してください。
      3. AWS上にソース・システムを複製します。ATAmotionを使う場合は、ATADATAコンソールを使用してこの複製処理を実行します。
      4. SAP HANAデータベースインスタンスとSAPアプリケーションインスタンスを展開します(導入手順はSAP HANA Quick Startを参照してください)。
      5. AWS上にDMOサーバーを構築します。DMOサーバーは 、ソースのデータベースサイズ、性能要求、システムリソース、およびダウンタイムなどの要件に応じて、独立したサーバーまたはSAPアプリケーションサーバーと同じ場所に配置できます(このステップの詳細はSAP社資料を参照してください)。
      6. ステップ3の複製されたソース・システムに対してDMOで移行プロセスを実行します。AWS上の移行プロセスを完了します(詳細はSAP社資料を参照してください)。詳細については、SAP文書を参照してください。
      7. SAP HANAデータベースインスタンスに接続する新しいSAPアプリケーションサーバーをAWS上にインストールします(詳細はSAP社資料を参照してください)。

partner-migration図4: ATADATAを組み合わせたDMOのアーキテクチャ

次に、両方の移行オプションに共通するアーキテクチャーと設計のいくつかの側面について説明します。

ネットワーク接続(帯域とレイテンシー)

データセンターとAWS間のネットワーク接続には、転送する必要のあるデータ量がどれくらいなのか、移行をどれくらいの時間で完了したいかによって、VPNまたはAWS Direct Connectを使用します。転送するデータ量は、ターゲットのSAP HANAデータベースのサイズと相互関係にあります。例えば、ソースのデータベースサイズが2TiB未満の場合、ターゲットのSAP HANAデータベースのサイズは250から600GiBになります(この見積もりは、SAP HANAの標準的な1:4または1:5倍の圧縮率を前提としていますが、より高い圧縮率のときも見受けられます)。お客様はネットワーク越しに200から250GiBの転送を行う必要があります。SAP Note 1793345 – Sizing for SAP Suite on HANASAP Note 1736976 – Sizing Report for BW on HANAに記載のあるSAPサイジングレポートからターゲットのデータベースサイズを見積もることができます。

移行プロセス中に切断があるとデータを再送信する必要があるため、信頼性の高いネットワーク接続を確立することをお勧めします。AWS Direct ConnectはVPN接続よりも高い信頼性と帯域を提供します。

SAPアプリケーションサーバー

DMOはソース・データベースをターゲットのSAP HANAデータベースに移行するだけで、SAPアプリケーションサーバーを設定しません。そのため、DMOによる移行が完了した後、AWS上に新しいSAPアプリケーションサーバーを構築する必要があります。以下のような様々なインストールシナリオから選択できます:

組織の要件、制約、サイジング、コスト、複雑さ、その他のトレードオフに基づいて最適なインストールオプションを決定する必要があります。

SAPアプリケーションサーバーのインストールと設定プロセスを合理化するために、多くのAWSの技術が利用できます。これらには、AWS CloudFormationテンプレートスナップショットからのAmazon Machine Image (AMI)の作成、そしてAmazon EC2 Run commandなどがあります。このトピックについては、今後のブログ記事で説明する予定です。

SAP仮想ホスト名

SAPシステムは、DNSまたはローカルのホストファイルを通じてホスト名を解決します。私たちは、SAPシステムのSAP仮想ホスト名と組み合わせてDNSを使用することをお勧めしています。SAP仮想ホスト名を使用すると、AWS上で同じ仮想ホスト名を維持できるため、移行が容易になります。詳細は、SAP Note 962955 – Use of virtual or logical TCP/IP host namesを参照してください。

小さく始めましょう

SAPの移行は複雑で、潜在的な問題を最小限に抑えるためにも適切な計画が必要です。SAP on AWSとAWSそのものの理解を深めるために、まずは小規模なスタンドアロンSAPシステムを対象にすることをお勧めします。サンドボックス、開発、トレーニング、デモ、およびSAP IDES(Internet Demonstration and Evaluation System)環境がそのようなシステムとして見込めます。SAP DMOによる移行を続行しない場合は、現行のソース・システムを元通りお使いいただけます。再有効化するだけです。

ご不明な点がありましたらsap-on-aws@amazon.comまでご連絡ください。SAP on AWSでサポートが必要な特定の問題については、コンポーネントBC-OP-LNX-AWSもしくはBC-OP-NT-AWSのSAPへのサポートメッセージを作成してください。

読んでいただきありがとうございました!

— Somckit

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

AWSでの疎結合データセットの適合、検索、分析

あなたは刺激的な仮説を思いつきました。そして今、あなたは、それを証明する(あるいは反論する)ためにできるだけ多くのデータを見つけて分析したいと思っています。適用可能な多くのデータセットがありますが、それらは異なる人によって異なる時間に作成され、共通の標準形式に準拠していません。異なるものを意味する変数に対して同じ名前を、同じものを意味する変数に対して異なる名前を使用しています。異なる測定単位と異なるカテゴリを使用しています。あるものは他のものより多くの変数を持っています。そして、それらはすべてデータ品質の問題を抱えています(例えば、日時が間違っている、地理座標が間違っているなど)。
最初に、これらのデータセットを適合させ、同じことを意味する変数を識別し、これらの変数が同じ名前と単位を持つことを確認する方法が必要です。無効なデータでレコードをクリーンアップまたは削除する必要もあります。
データセットが適合したら、データを検索して、興味のあるデータセットを見つける必要があります。それらのすべてにあなたの仮説に関連するレコードがあるわけではありませんので、いくつかの重要な変数に絞り込んでデータセットを絞り込み、十分に一致するレコードが含まれていることを確認する必要があります。
関心のあるデータセットを特定したら、そのデータにカスタム分析を実行して仮説を証明し、美しいビジュアライゼーションを作成して世界と共有することができます。
このブログ記事では、これらの問題を解決する方法を示すサンプルアプリケーションについて説明します。サンプルアプリケーションをインストールすると、次のようになります。

  • 異なる3つのデータセットを適合させて索引付けし、検索可能にします。
  • 事前分析を行い、関連するデータセットを見つけるために、データセットを検索するための、データ駆動のカスタマイズ可能なUIを提示します。
  • Amazon AthenaAmazon QuickSightとの統合により、カスタム解析やビジュアライゼーションが可能です

(more…)

新機能 – TTL(Time to Live)機能を利用したDynamoDBアイテムの管理について

AWSを利用頂いている多くのお客様にDynamoDBは使用されています。速度と柔軟性がその理由で、Ad Tech( リファレンスアーキテクチャ )、Gaming( リファレンスアーキテクチャ )、IoT( リファレンスアーキテクチャ )、そして一貫した一桁のミリ秒のレイテンシを実現しアプリケーションを構築されています。また、DynamoDBはフルマネージドのデータベースで、テラバイトサイズのテーブルに対して毎秒何百万というリクエストを処理することができます。
多くのDynamoDBユーザーは、利用する時間が限られている、または時間の経過とともにアクセス頻度が低くなるデータを格納しています。 直近のログイン、試用版のサブスクリプション、アプリケーションのメトリックなどへの利用がそうです。 他にも保管できる期間に関する規制または契約上の制限の対象となるデータを保管します。 これまで、これらを実現するには独自の時間ベースのデータ管理を実装していました。 大規模なシステムでは、DynamoDBアイテムのスキャン、期間を管理するための日付属性の確認、および不要になったアイテムの削除要求を行う為のAmazon Elastic Compute Cloud(EC2)インスタンスを構築するなどの必要があり、これによりアプリケーションのコストと複雑さが増加していました。

新しいTime to Live(TTL)管理 について
この普及した重要なユースケースを合理化するため、新しくTTL(Time to Live)機能の提供を開始しました。 アイテムの有効期限を属性で指定する事により、テーブル単位でこの機能を有効にすることができます。
属性が指定され、TTL管理が有効になると(1回のAPI呼び出しで両方の操作が処理されます)、DynamoDBは期限切れのアイテムを見つけて削除します。 この処理は、自動的かつバックグラウンドで行われ、テーブルへの読み取りまたは書き込みトラフィックには影響しません。

DynamoDBストリームを使用することで(詳細は、「 DynamoDBアップデート – トリガ(Streams + Lambda)+クロスリージョンレプリケーションアプリケーション」を参照)。実際の削除を処理またはアーカイブすることができます。 ストリーム内の他の更新レコードと同様に、削除は24時間単位で行われます。 AWS LambdaおよびDynamoDB Triggersを使用して、期限切れのアイテムをコールドストレージに移動したり、ログに記録したり、他のテーブルを更新したりすることができます。

テーブルのTTLを有効にして、必要な属性を指定する方法は次のとおりです。

指定する属性はDynamoDBのNumber型かつ、 UNIX時間でTTLの指定を行います。
上のスクリーンショットからわかるように、DynamoDB Streamsを有効にすることもできます。また、TTLを有効にすると削除されるアイテムのプレビューを見ることもできます。

また、コードからUpdateTimeToLive関数を呼び出しテーブルにTTLの有効化設定することも、 AWSコマンドラインインターフェイス(CLI)からupdate-time-to-liveコマンドを使用しテーブルでTTLを有効化設定することもできます。

TTL の利用事例(TUNE様)

 AWSのお客様であるTUNEは既に、この機能をHasOffers製品の一部として活用しています。

HasOffersは、マーケティングキャンペーンの効果を分析し、大量の広告エンゲージメントデータをプロセスに保存するのに役立ちます。 キャンペーンの顧客定義の時間枠が過ぎると、データは不要になり、削除することができます。 TTL機能をTUNEで使用できるようにする前は手動で期限切れアイテムを識別し、古いデータを削除しました。 これは労力と激しく計算を必要とし、テーブルのプロビジョニングされたスループットの一部も消費する必要がありました。

今は各アイテムの有効期限を設定し、あとはDynamoDBに任せます。 失効したデータは自動的に消え、使用可能なスループットには影響しません。 その結果、TUNEは85テラバイトの古いデータを削除することができ、年間200,000ドル以上のコストを削減し、アプリケーションロジックも簡素化しました。

知っておくべきこと
あなたのアプリケーションにTTLを使用することを検討する際、留意すべきことがいくつかあります。

TTL属性 – TTL属性は索引付けまたは投影することができますが、JSONドキュメントの要素にすることはできません。 前述したように、Numberデータ型を持つ必要があります。 他の属性と同様に、IAMを使用してこの属性へのアクセスを制限することができます。 指定されたTTL属性を持たない項目は削除対象とはみなされません。 誤ったTTL値による誤った削除を避けるため、5年以上経過しているように見えるアイテムは削除されません。

テーブル – 新しいテーブルまたは既存のテーブルにTTLを適用できます。 テーブルのTTLを有効にするプロセスには最大1時間かかります。一度に1つのテーブルへの変更しか行うことはできません。

削除のバックグラウンド処理について – スキャンと削除はバックグラウンドで行われ、プロビジョニングされたスループットにはカウントされません。 削除時間は、期限切れアイテムの数と性質に応じて異なります。 期限切れの後、実際に削除が行われる前にはアイテムはまだテーブルに残り 、 読み取りとスキャンに表示されます。

インデックス – アイテムは、ローカルのセカンダリインデックスからすぐに削除され、グローバルセカンダリインデックスからは、最終的に一貫した方法で削除されます。

価格 – 内部スキャン操作、削除操作には費用は掛かりません。 アイテムが実際に削除されるまではストレージの支払いが発生します。

今すぐ利用可能
この機能は現在利用可能で、今すぐ使用することができます! 詳細は、「DynamoDBデベロッパーガイド」の「 TTL (訳注:翻訳時点では英語版のみです)」を参照してください。

 

Jeff; (翻訳は成田が担当しました。原文はこちら)

(速報) 2016年AWS Partner Network(APN) Award発表!

みなさん、こんにちは。Partner SA 酒徳です。

本日、東京ミッドタウン カンファレンスホールにてAWS Partner Summit 2017 – Japan が開催され、昨年2016年の功績を讃え、APN Awardの授与式も同時に行われました。
APN Awardは一年を通し、各分野において最もパフォーマンスを発揮されたAPNパートナー様が受賞されるアワードで、今年は下記5つの分野において受賞パートナー様が選出されました。

APN Awardを授与されましたパートナー様とその授与内容についてご紹介させて頂きます。

– APN Partner of the Year 2016
年間を通じて営業・技術・マーケテイング分野等のパートナーとしての総合力で判断し、 AWSのビジネスに最も貢献いただいたAPNパートナー様が受賞

– APN Rising Star of the Year 2016
APNに加入して頂き1年目にして、AWSビジネスに最も高く貢献頂いたAPNパートナー様が受賞

– APN Cloud Business of the Year 2016
AWSが企業のビジネスに大きく貢献いただき、市場に大きな影響を与えたAPNパートナー様が受賞

– APN Architecture of the Year 2016
AWSの利用アーキテクチャがクラウド利用上優れているものの中から、最も先進的、実用的、チャレンジングなものをAWS のソリューションアーキテクトが選定。同システムを構築したAPNパートナー様が受賞

– APN Reference of the Year 2016
お客様公開事例において、AWSが企業ビジネスに大きく貢献する事を示し、市場に大きな影響を与えたAPNパートナー様が受賞

それでは、早速受賞パートナー様をご紹介させて頂きます。

– APN Partner of the Year 2016
受賞パートナー:アイレット株式会社

 

logo_cloudpack500

 

受賞理由:昨年に引き続き、多くのAWS関連ソリューション、多数の顧客事例のリリースや 積極的なメディア活動を通じて、メディア、エンターテイメント、スタートアップ企業のみならず、企業や教育機関(大学)のAll‐in移行を手掛けるなど更なるAWSビジネスの拡大に貢献されました。 新サービスも積極的に採用して成功させる一方で、エンタープライズ案件も推進してきた結果、著しい売り上げ伸び率を示されました。

 

– APN Rising Star of the Year 2016
受賞パートナー:日本事務器株式会社
logo-NJC-M-01c
受賞理由:自社製の中堅企業/団体向け各種業務パッケージをAWS上で構築されました。日本中にAWSユーザーを拡大いただいただけではなく、自社のワークスタイル革新の一環としてAmazon WorkSpacesを導入。自社がモデルケースとなり、その知見をお客様に届けることを推進いただきました。結果として、この1年の売り上げ伸び率が新規パートナーの首位を記録されました。

 

– APN Cloud Business of the Year 2016
受賞パートナー:株式会社ソラコム

 

soracom

 

受賞理由:IoT通信プラットフォーム「SORACOM」を、AWSの機能をフル活用してAWS上にソフトウェアで構築し、IoT/M2Mに最適化された通信プラットフォームを日本発でグローバルに展開されています。AWS KinesisなどAWSの各種サービスとの親和性も高く、AWS IoTコンピテンシーの認定も受けられました。既に多くのユーザーがIoTの様々なシーンで活用する中で機能の追加、拡張を続けていらっしゃいます。

 

– APN Architecture of the Year 2016
受賞パートナー:株式会社野村総合研究所

 

logo_NRI

 

受賞理由:高速処理、高可用性、高セキュリティを求められる金融業界の証券トレードシステム領域に対して、AWS Lambda を始めとするAWSのマネージドサービスを活用したクラウドネイティブアーキテクチャを構築されました。またお客様の長期的なクラウドジャーニーを策定した上で、本プロジェクトをその第一歩として定義し、レガシーシステムからクラウドらしいアプリケーションへの移行と、クラウドネイティブの圧倒的な開発スピードと効率性を実証した点を高く評価させていただきました。

 

– APN Reference of the Year 2016
受賞パートナー:株式会社オージス総研
OGISRI
受賞理由:AWSを活用した国内最大規模の優れたIoTの成功例として、大阪ガス様のエネファーム事例を公開いただきました。さらに、AWSの各種イベント等でのご登壇のみならず各種メディアでの露出も多く、AWSビジネスに大きく貢献いただきました。ユーザー、事業者の双方に多大なメリットを提供しながら、全国への普及を含め国の燃料電池発電に関する目標達成をサポートする社会的公益性の高い事例でもあります。

 

受賞パートナーの皆様、本当におめでとうございます!
昨年は多くのパートナー様のお力沿いを得られ、AWS Japanとして飛躍の年となりました。今年も昨年以上にエコシステムの拡大、充実をテーマに更なるSuper Powerの原動力にAWSをご活用頂けますと幸いです。
2017年も引き続き、ご支援のほど宜しくお願い申し上げます。

pic_award

 

AWS Alliance一同

シャーディングされたシステムをAuroraに集約してリソースの消費を削減

リレーショナルデータベースを利用したワークロードで、スケーリングを考えないといけなくなった時に、一般的にスケールアップとスケールアウトと2つの手法が上げられます。一般的にスケールアップの方が簡単に行えます(単純にスペックのいいマシンを購入するなど)。一方スケールアウトは、それぞれ独立したホストで稼働している複数のサーバへ、データベースをシャーディングする必要があり作業が煩雑になります。

難しさにも関わらずスケールアウトとが最近のトレンドとなってきています。コモディティハードウェアとシステムリソースへの要求の増加に伴いワークロードを効率的にシャーディングする必要が出てきました。シャーディングされたシステムの1つの欠点として管理コストがあげられます。もし4つのシャードを持っているとすると、4つのデータベースを管理する必要があります。しかし、たとえそうだとしてもスケールアウトはスケールアップよりコスト効率がいい場面が多かったのです。特にAmazon RDSの様なマネージドデータベースの登場によりリレーショナルデータベースの管理を軽減することが出来るようになったのがその1つの要因です。

しかし、なぜ過去形なのでしょうか? Amazon Auroraの登場によりスケールアップという選択肢が戻ってきたのです。Amazon Auroraは非常にスケールし、MySQL互換のマネージドデータベースサービスです。Auroraは2 vCPU/4 GiBメモリというスペックのインスタンスから、32 vCPU/244 GiBメモリ搭載のインスタンスまでを提供しています。Amazon Auroraは需要に応じてストレージが10 GBから64 TBまで自動的に増加します。また、将来のリードキャパシティの増加に備えて15インスタンスまで低遅延のリードレプリカを3つのアベイラビリティーゾーンに配置することが可能です。この構成の優れている点は、ストレージがリードレプリカ間でシャーディングされている点です。

シャーディングされたシステムを1つのAuroraインスタンスに集約、もしくは少数のシャードに集約しAuroraで稼働させることで多くのコストを節約する事が可能です。これがこのブログポストでお話したいことの全てです。

シャーディングされたシステムをAuroraに集約するために – まずはじめに –

多くのシャーディングされたシステムは標準的な方法で行うことが可能です。データはカスタマーIDなどの特定のキーを元に分割されており、何かしらマッピングを行う機能を用いてシャードに分割されています。この方法には様々な種類があり、1例として参照用のデータを別のシステムか1つのシャードに格納したり、全てのシャードに参照用のデータを配置するなどがあります。どのようにデータを分割しても、シャーディングの複雑さは通常、アプリケーションレイヤーにあり、シャードの統合は比較的容易に行えます。

多分皆さんは今、”利点はわかった。ではどうやってAuroraにデータを移行するのか”という疑問をお持ちかと思います。今回の例では、MySQLを利用して4つのシャードを持つシステムを利用していると仮定したいと思います。また、各シャードは他のシャードが持っているデータを持っていないものとします。また1つのシャードが参照用のデータを持っている前提とします。現在の構成は以下の図の様な構成になっていると思います。mapは各シャードへのアプリケーショントラフィックを表しています。

ShardMap

MySQLを運用しているため、Aurora documentationに記載されている方法を利用を利用可能です。簡単に移行を行うために、まずはじめに参照データのみが格納されているインスタンス1を移行します。しかし、どのシャードを最初に移行するかはそれほど重要ではありません。 移行が完了すると、マッピング機能はインスタンス1ではなくAuroraインスタンスを指します。システムは次の図のようになります。

ShardMap1

残りのデータを移行する

この時点で、Auroraが特定のワークロードをどれくらいうまく処理しているか評価し、必要な調整を行う必要があります。設定に問題がなくなれば、他のデータを移行する準備は完了です。では、シャード2をAuroraインスタンスに移行しましょう。しかし、どうやって?

 

AWS Database Migration Service (AWS DMS)を是非ご活用下さい!AWS DMSはこのようなマイグレーションにも対応するように作られました。シャード2からAuroraインスタンスへデータをコピーするためにDMSをご利用になれます。更に、シャード2にとランアクションを実行しながらこれらの作業が可能です。DMSは初期データのロードが完了すると、それらのトランザクションデータをシャード2から収集しAuroraインスタンスに適用します。DMSは継続的にシャード2からAuroraインスタンスへデータを移行し、シャード2の代わりにAuroraインスタンスの利用を開始させるまで同期させます。シャード2からAuroraインスタンスへ切り替える準備が出来たら、シャード2へのトランザクションを停止し、DMSが最後のトランザクションをAuroraインスタンスへ適用するまで待ち、mapの設定を、シャード2に向いていたトラフィックを直接Auroraインスタンスへ向くように変更します。設定が完了すると、システムは以下のような状態になります。

ShardMap2

この時点から、Database Migration Serviceを残り2つのシャードをAuroraインスタンスへ移行するために利用出来ます。最終的にシステムは以下の様になります。

ShardMap3

 

複雑なシャードの扱い方

これでシャーディングされたシステムが1つのAuroraインスタンスへマイグレーションが完了し、コストを削減することが出来ました!しかし、MySQLを利用し、クリーンなシャードを利用しているとう仮定で話をすすめてきました。もしこれらの仮定にそぐわない場合はどうでしょうか?

それでは、シャードがクリーンな状態でない場合を見ていきましょう。例えば、システムが最初に2つのシャードで構成されていたとします。ある時点で、その2つのシャードを4つのシャードに分割したとします。 リシャードィングプロセスの一環として、シャード1と2のコピーを作成してシャード3と4を作成し、マッピング機能を更新しました。 結果は次のようになります。

AppTier

この図は状況が複雑であるように見えます。 理想的には、このようなリシャードィングの際に、シャードに関係のないデータ、つまりグレーアウトされたデータをパージします。 しかし、必ずしも必要というわけではないし、時には難しいこともあるので、データをそのままにしておく事があります。 この方法では使用されていない冗長なデータを保持する”汚れた”シャードが発生します。 これらのシャードを統合しようとすると、アクティブなデータの行が、削除すべき重複した行と衝突する問題が発生します。

何をすべきか? シャードの統合を行う前に、利用していない行を削除することができます。 しかし、特にマッピング関数がID値のハッシュ(一般的な方法の1つ)で構成されている場合、利用していない行を特定するのは難しいかもしれません。

諦めないで下さい! 別のオプションがあるかもしれません。 各シャード内のデータが1つのデータベースに含まれている場合は、DMSを使用して、システムの各シャードをAuroraインスタンス内の単一のMySQLデータベースに統合できます。 次に、既存のマッピング・スキームを使用して、Auroraインスタンス内の適切なデータベースにトランザクションを転送できます。 この例では、Auroraインスタンスは次のようになります。

ShardMap4

MySQL以外のデータベースを利用している場合

他の仮定として、データベースエンジンとしてMySQLデータベースを利用をしている前提がありました。もしそうでなければ? OracleまたはMicrosoft SQL Serverを使用する場合はどうなるでしょうか? 大丈夫です! AWS Schema Conversion Tool が役立ちます!

ドキュメントの最初で「AWS Schema Conversion Toolは、ソースデータベースのスキーマとカスタムコードの大部分をターゲットデータベースと互換性のあるフォーマットに自動的に変換することで、異種データベースの移行を容易にします」と述べています。シャーディングされたシステムでは、ストアドプロシージャとトリガを使用してデータベース内に組み込まれた多くのビジネスロジックは、通常すでにアプリケーション側に移動されています。 AWS Schema Conversion Toolで、ソースデータベースとしてサポートされているデータベースエンジンでシャーディングされたシステムを利用している場合、Auroraへの変換と統合が可能かどうかを調べる価値があります。 統合の恩恵を受けるだけでなく、オープンソースプラットフォームへの移行のメリットも得られます。

さらに踏み込んで

さらに詳細に興味がありますか? AWS Database Migration Service を使用して、シャーディングされたデータベースを1つ以上のAuroraインスタンスに統合する方法を説明する資料をまとめはじめました。 この例では、DMSチームが提供するMySQLサンプルデータベースのシャーディングバージョンを使用しています。 私たちはこのシャーディングされたバージョンをRDSスナップショットとして利用できるようにしました。 スナップショットは公開されているため、こちらの説明に従って試すことが可能です。それぞれ、説明中でmysql-sampledb-master-shard、mysql-sampledb-shard1、mysql-sampledb-shard2と呼ばれていたものです。

 

— Ed Murray (manager at Amazon Web Services) (翻訳は星野が担当しました。原文はこちら)