Author: AWS Japan Staff


【開催報告】AWS re:Invent 2017 Gaming re:Cap

こんにちは。ソリューションアーキテクトの吉田です。

12/13(水)、Amazonの目黒オフィスでゲーム関係のお客様向けにre:Invent 2017のre:Capイベントを開催しました。直前のご案内にもかかわらず、100名超のお客様にご参加いただき、おかげ様で大盛況のイベントとなりました。

 

– AWS re:Invent 2017 New Release for Gaming re:Cap –

まずはソリューションアーキテクトの畑より、re:Invent期間中に発表されたサービスと機能について解説しました。非常にたくさんのアップデートがあったため簡単な概要レベルのご紹介となりましたが、気になるサービスはぜひブログ記事やAWSドキュメントなどでチェックしてみてください。

 

– re:Invent 2017 ゲームセッションサマリー(1) –

次に、私吉田からre:Invent初日のGame Industry Dayで行われたブレイクアウトセッションやWorkshop、その他ゲームのお客様にチェックいただきたいセッションの概要についてご紹介しました。各ブレイクアウトセッションのSlideshareやYoutubeのリンクは資料に掲載してますので、ぜひご覧ください。

 

– re:Invent 2017 ゲームセッションサマリー(2) –

そして最後に、Amazon Game Servicesの下田より、2つの注目ブレイクアウトセッションとして、”Amazon Game Studiosのゲーム向けのイベントベースのアナリティクス事例”と”Gearbox社のBattlebornでのGameLift導入事例”について取り上げ、海外におけるゲーム開発の現状などにも触れながら詳細を解説しました。

 

AWS AppSyncの概要&デモ

懇親会では、プロフェッショナルサービスの塚越からぜひゲームのお客様にご利用いただきたいサービスとしてAWS AppSyncの概要とデモをご紹介しました。AppSyncはGraphQLのマネージドサービスで、DynamoDBやElasticsearch Serviceなど複数のデータソースへのGraphQL APIによるアクセス、ローカルとクラウド側へのリアルタイムデータ同期、そしてデバイスからサービスのエンドポイントをSubscribeすることでクラウド側からイベントをリアルタイムに受信することができるサービスです。特にモバイルゲームではご活用いただけるシーンが多くあると思いますので、ぜひチェックしていただければと思います。現在パブリックプレビューの申し込みを受付けております。

 

Gaming Tech Nightを開催します!

ゲーム開発者の方々向けにAWSを中心とした技術情報をお届けするために、Gaming Tech Nightを来年より定期的に開催します。弊社ソリューションアーキテクトによる技術情報のご提供やお客様からの事例紹介、そして各種ハンズオンなどを開催していきたいと思います。第1回は1月下旬の開催を予定しています。日程と内容が確定したらご案内差し上げますので、Connpassのグループ “Gaming Tech Night”をチェックいただければと思います。

 

– ソリューションアーキテクト 吉田

新世代のAmazon Linux 2 リリース

Amazon Web Services (AWS) が提供しているAmazon Linuxに新世代のAmazon Linux 2がリリースされました。他のサービスがそうであるようにAmazon Linux 2ではお客様からいただいた多くのフィードバックを元に作成されています。この新しいAmazon Linuxの特長をみていきましょう。

LTS(Long Term Support)の提供

これまでのAmazon Linuxはローリングアップグレードで定期的に新しいバージョンのパッケージが提供され続けることにより、常に最新の状態を維持できる環境として提供されていました。Amazon Linux 2でもこれは変わりませんが、加えてLTS (Long Term Support: 長期サポート)を提供する予定です。LTSでは5年間に渡りコアオペレーティングシステムにセキュリティパッチとバグフィックスを提供し続け、その間のユーザ空間のABI(Application Binary Interface)とAPI(Application Programming Interface)の互換性を維持します。互換性を維持しつつ安全なLinux環境を提供するのが目的であり、新しい環境に更新されることより互換性のある環境を長期に渡って使い続けることの方を望むお客様からのリクエストに応えるものです。

またコアオペレーティングシステムには無い、もしくは新しいバージョンのパッケージについてはAmazon Linux Extrasリポジトリから入手可能です。詳しくはamazon-linux-extrasコマンドのマニュアルを御確認ください。

LTSビルドは現在リリース候補(Release candidate)の状態として提供されており、評価を開始いただける状態です。

オンプレミス環境でのテストや開発が容易に

Amazon Linux はAmazon EC2やAmazon ECS (コンテナ環境)上で容易に利用いただけるディストリビューションですが、Amazon Linux 2ではこれらに加えて、VMware、Microsoft Hyper-V、Oracle VM VirtualBoxの仮想イメージを提供します。これによりオンプレミス環境でのテストや開発が容易になります。Amazon Linux 2を稼働させるには最小で512MBのメモリが必要です。

新しい環境とセキュリティの強化

Kernel 4.9やSystemdのサポート等、OS環境全体が刷新されています。またセキュリティ面でも必須パッケージを厳選することによりリスクを減らし、重要度が高いセキュリティパッチについてはOS起動時に自動的に適用する等、高いセキュリティレベルを保つための仕組みが組み込まれています。

今からご利用いただけます!

全ての商用リージョンでAMIが選択可能になっていますので、ぜひ御利用ください。HVMをサポートする全てのインスタンスタイプで御利用いただけます。Amazon LinuxをEC2上で利用する上で追加の費用は不要です(通常のAmazon EC2費用で利用可能)。DockerリポジトリにもAmazon Linux 2のベースイメージが準備済です。またフォーラムでは新しい告知に加えてみなさまからの利用のフィードバックをお待ちしております。

 

情報リソース

Amazon Linux  2ホームページ:https://aws.amazon.com/jp/amazon-linux-2/

FAQ:https://aws.amazon.com/jp/amazon-linux-2/faqs/

ドキュメント:http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html

AWS Forum (Amazon Linux):https://forums.aws.amazon.com/forum.jspa?forumID=228

リリースノート(原文):https://aws.amazon.com/jp/about-aws/whats-new/2017/12/introducing-amazon-linux-2/

Official docker repository :https://hub.docker.com/_/amazonlinux/

 

AWS 下佐粉 昭 (@simosako)

新発表 – Amazon CloudWatch AgentとAWS Systems Managerとの連携 – 統一されたメトリクスとログの収集をLinuxとWindowsに

WindowsとLinuxのインスタンスやオンプレミスサーバから、Amazon CloudWatchにメトリクスやログファイルを送信するために利用できる、いくつものエージェント、デーモン、そしてスクリプトをこれまで紹介してきました。こうした異なるツールから収集されたデータによって、計算リソースの状態や挙動を可視化することができ、値が正常域を外れた時や問題のある可能性が見られた時にアクションを起こすこともできます。CloudWatch Dashboardsでどんな欲しいメトリクスもグラフにすることができ、CloudWatch Alarmsでアクションを起こすこともでき、CloudWatch Logsでエラーメッセージを見つけるために検索もでき、カスタムの高解像度メトリクスサポートの利点も享受することができます。

新しい統一エージェント

2017年12月14日に、我々はさらに一歩進めて、新しい統一されたCloudWatch Agentをリリースしました。これはクラウドでもオンプレミスでも、LinuxでもWindowsでも実行でき、メトリクスとログファイルを取り扱えます。デプロイするにはAWS Systems Manager (SSM) Run CommandSSM State Manager、またはCLIを利用できます。以下が、いくつかの最も重要な機能になります:

単一のエージェント – メトリクスとログの両方を単一のエージェントで収集できます。これによって、セットアップ手順を簡略化でき複雑さを減らすことができます。

複数プラットフォーム / 複数環境 – 新しいエージェントはクラウドでもオンプレミスでも実行可能で、64-bit Linuxと64-bit Windows上で動かせ、HTTPプロキシもサポートしています。

設定可能 – 新しいエージェントは自動的に最も役に立つシステムメトリクスを取得します。さらに、CPUスレッド、マウントしたファイルシステム、そしてネットワークインタフェースといった、より詳細なメトリクスやサブリソースを数百集めることもできます。

CloudWatch親和性 – 新しいエージェントは標準の1分間隔メトリクスも、新しい1秒間隔の高解像度メトリクスもサポートしています。インスタンスID、イメージID、Auto Scaling Group名等のEC2のディメンジョンを自動的に含めてくれますし、カスタムディメンジョンの利用もサポートしています。全てのディメンジョンを使って、Auto Scaling Groupやアプリケーションにまたがった集約が可能です。

移行 – 既存のAWS SSMとEC2Configの設定から、簡単に新しいエージェントを使う様に移行することができます。

エージェントをインストールする

CloudWatch AgentはEC2インスタンスで動く場合にはIAM roleを使い、オンプレミスサーバで動く場合にはIAM userを使います。roleもしくはuserはAmazonSSMFullAccessAmazonEC2ReadOnlyAccessポリシーを持っている必要があります。以下が私のroleです:

これを既に実行中のインスタンスに簡単に追加できます (これは比較的新しいEC2の非常に便利な機能です):

SSM Agentをインスタンス上で既に実行しています。もしまだであれば、SSM エージェント をインストールし設定するの手順に従ってセットアップします。

次に、AWS Systems Managerを使ってCloudWatch Agentをインストールします:

これは数秒で終わります。これで、簡単なウィザードを使ってエージェントの設定ファイルをセットアップします:

ウィザードでは監視するログファイルのセットアップもできます:

ウィザードはJSON形式の設定ファイルを生成し、インスタンス上に保存します。その後、他のインスタンスへのデプロイを可能にするためにParameter Storeへのアップロードをするかどうかの選択肢を聞いてきます(ファイルを編集することでもっと詳細なメトリクスとログ収集の設定も可能です):

これでRunCommandを使いParameter Storeの設定名を与えて、CloudWatch Agentを起動することができます。

これは数秒で終わり、エージェントはすぐにメトリクスを送信開始します。先に述べた通り、エージェントはインスタンスの中やアタッチされたリソースの詳細なメトリクスを送信可能です。た取れば、以下は各ファイルシステムのメトリクスです:

監視しているログファイル毎に、各インスタンスで別々のlog streamがあります:

他のlog streamでできることと同様に、ログを見たり検索することができます:

今から利用可能です

新しいCloudWatch Agentは全てのパブリックAWSリージョンで利用可能です。AWS GovCloud (US)と中国内のリージョンは今後リリースしていきます。

エージェントには全く料金はなく、通常のCloudWatchのログとカスタムメトリクスの料金をお支払頂くだけです。

Jeff;

原文: New – Amazon CloudWatch Agent with AWS Systems Manager Integration – Unified Metrics & Log Collection for Linux & Windows (翻訳: SA岩永)

本番環境でAmazon Redshift Spectrum, Amazon Athena, およびAWS GlueをNode.jsで使用する

これはNUVIADの創設者兼CEOであるRafi Tonによるゲスト投稿です。NUVIADは、彼ら自身の言葉を借りれば、「ハイパーターゲティング、ビッグデータ分析、先進的な機械学習ツールを使ってプロのマーケティング担当者代理店、地元の企業に最先端のツールを提供するモバイルマーケティングプラットフォーム」です。

NUVIADでは3年以上にわたり、Amazon Redshiftを主なデータウェアハウスソリューションとして使用してきました。

当社は、ユーザーとパートナーが分析し広告キャンペーンの戦略を決定するための、大量の広告取引データを保存しています。リアルタイム入札(RTB)キャンペーンを大規模に実行する場合、ユーザーがキャンペーンの掲載結果の変化に迅速に対応する上で、データの最新性が極めて重要となります。我々は、シンプルさ、スケーラビリティ、パフォーマンス、およびニアリアルタイムで新しいデータを読み込む能力を評価し、Amazon Redshiftを選択しました。

過去3年間で、当社の顧客基盤は大幅に成長し、データも同様に増加しました。Amazon Redshiftクラスターは、当初の3ノードから65ノードにまで伸張しました。コストと分析のパフォーマンスのバランスを取るため、我々は頻繁に分析されない大量のデータを低コストで保存する方法を探しました。一方で、我々は依然として、ユーザークエリーに対してすぐにデータを利用できるようにしておき、高速なパフォーマンスについての彼らの期待に応えたいと考えていました。そして、我々はAmazon Redshift Spectrumに目を向けたのです。

この記事では、Amazon RedshiftをRedshift Spectrumによってモダンなデータウェアハウスとして拡張した理由について説明します。データの成長と、コストとパフォーマンスのバランスを取る要求とが、どのように我々をしてRedshift Spectrumの採用に至らしめたかを説明します。私たちの環境における重要なパフォーマンスメトリクスをご紹介し、また、増え続けるユーザーベースによる即時性の高いクエリーのためにデータを利用可能な状態に置きつつ、スケーラブルで高速な環境を提供する、その他のAWSサービスについても議論します。

ビジネス基盤としてのAmazon Redshift

当社のプラットフォームでは、最新のデータをお客様やパートナーに提供することが常に主要な目標でした。数時間前のデータを提供する他のソリューションがも検討しましたが、これは我々にとって十分ではありませんでした。可能な限り最新のデータを提供することにこだわりたかったのです。Amazon Redshiftによって、頻繁なマイクロバッチでデータをロードし、顧客がAmazon Redshiftに直接クエリーしてニアリアルタイムで結果を得ることが可能となりました。

利点はすぐに明らかになりました。当社のお客様は、キャンペーンが他のソリューションよりいかに速く実行されたかを知ることができ、また、常に変化し続けるメディアの供給価格と利用可能性の課題に早急に対応できるようになりました。彼らはとても幸せでした。

しかし、この方法ではAmazon Redshiftに長期間にわたって多くのデータを保存する必要があり、そして我々のデータは急速に増加していました。ピーク時には、65のDC1.largeノードを実行するクラスターを運用していました。Amazon Redshiftクラスタへの影響は明白であり、CPU使用率も90%にまで増加していました。

Amazon RedshiftをRedshift Spectrumへと拡張した理由

Redshift Spectrumは、データをロードすることなく、Amazon S3に格納されたデータに対して、強力なAmazon Redshiftクエリエンジンを使用してSQLクエリを実行する能力を提供してくれます。Redshift Spectrumでは、必要な場所に、我々が望むコストでデータを保存することができます。そしてデータを、ユーザーが必要とした時に期待通りのパフォーマンスで分析が行える状態にしておくことができるのです。

シームレスなスケーラビリティ、高性能、および無制限の同時実行性

Redshift Spectrumがスケールするプロセスはシンプルです。まず、Amazon S3をストレージエンジンとして利用し、事実上無制限のデータキャパシティを得ることができるようになります。

次に、より多くのコンピューティング能力が必要な場合は、Redshift Spectrumの数千ノードにおよぶ分散コンピューティングエンジンを使ってよりよいパフォーマンスを得ることができます。大量のデータに対して複雑なクエリーを投げるには最適です。

さらに、全てのRedshift Spectrumクラスターを同一のデータカタログにアクセスさせれば、データの移行に頭を悩ませることはなくなります。スケーリングは労力を必要とせず、かつシームレスなものになります。

最後に、Redshift Spectrumは潜在的に数千ものノードにクエリーを分散させるため、他のクエリーによって影響を受けることがなくなり、より安定したパフォーマンスが得られます。また、無制限の同時実行性(訳者註:クラスターを分けることで実現できます)が提供されることになります。

SQLを維持できること

Redshift SpectrumはAmazon Redshiftと同じクエリエンジンを使用します。従って、単一のテーブルで複雑なクエリを使用する場合も、複数のテーブルを結合する場合も、既存のBIツールやクエリー構文を変更する必要はありませんでした。

最近紹介された興味深い機能は、Amazon RedshiftとRedshift Spectrumの外部表の両方にまたがるビューを作成できるというものです。この機能を使用すると、Amazon Redshiftクラスター内の頻繁にアクセスされるデータと、Amazon S3上の頻繁にアクセスされないデータを、1つのビューでクエリーすることができます。

より高いパフォーマンスのためのParquet利用

Parquet は列指向のデータフォーマットです。Parquetは優れたパフォーマンスを提供するとともに、Redshift Spectrum(あるいはAmazon Athena)が極めて少ないデータのみをスキャンできるようにします。I/Oが少なくなれば、クエリーはより高速になり、そしてクエリー当たりのコストも低くなります。

Parquetに関する全ての情報は、https://parquet.apache.org/ または https://en.wikipedia.org/wiki/Apache_Parquet で得ることができます。

より低いコスト

コストの観点では、我々は、Redshift Spectrumを使用してデータを分析する上で、Amazon S3上のデータを標準レートで支払う他は、クエリーごとに発生するわずかな金額しか支払っていません。Qarquetフォーマットを利用すれば、スキャンするデータの量を大幅に削減できます。我々のコストは以前より低くなり、そして我々のユーザーは大規模で複雑なクエリに対しても迅速な結果を得ることができます。

Amazon RedshiftとRedshift Spectrumの性能比較から我々が学んだこと

Redshift Spectrumを最初に見たときに、まずテストを行いたいと思いました。Amazon Redshiftとの比較について知りたかったので、2つの重要な問いに着目しました。

  1. シンプルかつ複雑なクエリーに対して、Amazon RedshiftとRedshift Spectrumのパフォーマンス上の違いはどのようなものであるか?
  2. データフォーマットはパフォーマンスに影響するか?

移行フェーズ中、我々はデータセットをAmazon Redshiftと、S3上のCSV/GZIPおよびParquetファイルフォーマットとして格納しました。テストしたのは次の3つの構成です。

  • 28のDC1.largeノードを持つAmazon Redshiftクラスター
  • CSV/GZIPを使用したRedshift Spectrum
  • Parquetを用いたRedshift Spectrum

1か月分のデータを用いて、シンプルなクエリーと複雑なクエリーのベンチマークを実行しました。クエリを実行するのにかかる時間と、同じクエリを複数回実行したときに結果がどの程度一定になるかをテストしました。テストには、すでに日付と時間でパーティション済みのデータを使用しました。データを適切に分割すると、パフォーマンスが大幅に向上し、クエリー時間が短縮されます。

シンプルなクエリー

最初に、月当たりの請求データを集計するシンプルなクエリーをテストしました。

SELECT 
  user_id, 
  count(*) AS impressions, 
  SUM(billing)::decimal /1000000 AS billing 
FROM <table_name> 
WHERE 
  date >= '2017-08-01' AND 
  date <= '2017-08-31'  
GROUP BY 
  user_id;

同一のクエリーを7回流し、レスポンスタイムを計測しています(は最遅、は最速を示しています)。

実行時間 (秒)
  Amazon Redshift Redshift Spectrum
CSV
Redshift Spectrum Parquet
実行 #1 39.65 45.11 11.92
実行 #2 15.26 43.13 12.05
実行 #3 15.27 46.47 13.38
実行 #4 21.22 51.02 12.74
実行 #5 17.27 43.35 11.76
実行 #6 16.67 44.23 13.67
実行 #7 25.37 40.39 12.75
平均 21.53  44.82 12.61

シンプルなクエリーについては、事前に我々が予想していた通り、データをローカルに保持しているAmazon RedshiftがRedshift Spectrumよりよい数値を示しました。

驚きだったのは、Parquetデータフォーマットを使用したRedshift Spectrumの性能が、“従来型の”Amazon Redshiftのそれを大きく上回ったことです。我々のクエリ-に関して言えば、Redshift SpectrumでParquetデータフォーマットを使用した場合、従来型Amazon Redshiftに対して平均40%の高速化が見られました。また、Redshift Spectrumは実行時間も安定しており、最遅と最速の差はわずかなものでした。

スキャンされたデータをCSV/GZIPとParquetで比較してみると、両者の差異もまた顕著であることがわかります。

スキャンされたデータ (GB)
CSV (Gzip) 135.49
Parquet 2.83

Redshift Spectrumの課金はスキャンされたデータに対してのみ行われるので、Parquetを使用した場合のコスト削減効果は明白です。

複雑なクエリー

次に、複雑なクエリーについて、同じ3つの構成を比較しました。

実行時間 (秒)
  Amazon Redshift Redshift Spectrum CSV Redshift Spectrum Parquet
実行 #1 329.80 84.20 42.40
実行 #2 167.60 65.30 35.10
実行 #3 165.20 62.20 23.90
実行 #4 273.90 74.90 55.90
実行 #5 167.70 69.00 58.40
平均 220.84 71.12 43.14

今度は、Redshift SpectrumでParquetを使用した構成は、従来型のAmazon Redshiftに対し80%もの平均クエリー実行時間削減が見られました!

結論:複雑なクエリーの場合、Redshift SpectrumはAmazon Redshiftに対し67%の性能向上をもたらします。Parquetデータフォーマットを使用することで、Redshift SpectrumのAmazon Redshiftに対する性能改善効果は80%に達します。我々にとって、この結果は大きなものでした。

様々なワークロードのためのデータ構造の最適化

S3のコストは比較的低く、またRedshift Spectrumのクエリーコストはスキャンされたデータに対してのみかかることから、我々はデータを様々な分析エンジンやワークロードごとに別々のフォーマットで保持しておくことが合理的であると思っています。S3上の単一データをポイントする、いくつものテーブルを持つことが出来る点を押さえておくことは重要です。全ては、いかにデータを分割し、テーブルパーティションを更新するか次第です。

データ配列

例えば、我々のシステムには毎分実行され、直近1分の収集データに関する統計情報を生成する処理があります。Amazon Redshiftでは、これは以下のようなクエリーをテーブルに対して実行することで実現できます。

SELECT 
  user, 
  COUNT(*) 
FROM 
  events_table 
WHERE 
  ts BETWEEN ‘2017-08-01 14:00:00’ AND ‘2017-08-01 14:00:59’ 
GROUP BY 
  user;

(”ts”は個々のイベントのタイムスタンプを保持する列を想定しています)

Redshift Spectrumでは、個々のクエリーがスキャンしたデータに対してのみ課金されます。データが時間単位ではなく分単位で分割されている場合、1秒分を見るクエリーのコストは60分の1で済みます。もし直近1秒のデータのみ指定するテンポラリーテーブルを使用するのであれば、不必要なデータの分のコストを削減することができるのです。

Parquetデータの効率的な作成

平均すると、我々はトラフィックを処理するために800ほどのインスタンスを保持しています。それぞれのインスタンスは、最終的にAmazon Redshiftにロードされることになるイベントを送信します。3年前に始めた際は、個々のインスタンスからS3にデータをオフロードし、その後定期的にCOPYコマンドを用いてS3からAmazon Redshiftにロードしていました。

近年、Amazon Kinesis FirehoseによってAmazon Redshiftに直接データを投入することができるようになりました。これは今では有効なオプションの一つですが、我々は3年にわたって完璧かつ効率的に動作してきた既存の収集方法を堅持していました。

しかし、Redshift Spectrumを導入することになり、状況が変わりました。Redshift Spectrumでは、以下のことを行う方法を見つけ出す必要がありました。

  • インスタンスからイベントデータを収集する。
  • データをParquetフォーマットで保存する。
  • データを効果的に分割する。

これを実現するため、我々はデータをCSVで保存し、その後Parquetに変換しています。Parquetファイルを生成するための最も効果的な方法は、以下の通りです。

  1. データを1秒間隔でインスタンスからKinesis Firehoseに送信し、S3の一時バケットに保存する。
  2. AWS LambdaおよびAWS Glueを用いて、データを1時間単位で集計し、Parquetに変換する。
  3. ParquetデータをS3に保存し、テーブルパーティションを更新する。

この新しいプロセスでは、データはKinesis Firehoseに送られる前により慎重に検証される必要がありました。壊れたレコードがパーティション内に1件でもあると、そのパーティションに対するクエリーは失敗するためです。

データ検証

クリックデータをテーブルに保存するために、以下のようなcreate table用のSQLを用意しました。

create external TABLE spectrum.blog_clicks (
    user_id varchar(50),
    campaign_id varchar(50),
    os varchar(50),
    ua varchar(255),
    ts bigint,
    billing float
)
partitioned by (date date, hour smallint)  
stored as parquet
location 's3://nuviad-temp/blog/clicks/';

上記のステートメントによって、いくつかの属性と共に新しい外部テーブルが定義されます(全てのRedshift Spectrumテーブルは外部テーブルです)。ここでは、’ts’はTimestamp型ではなくUNIXタイムスタンプとして保持しています。また、課金データはdeciaml型ではなくfloat型として保持します(詳細は後ほど説明します)。前述の通り、データは日時と時間で分割され、ParquetとしてS3上に保持されます。

まず、テーブル定義を取得する必要があります。これは下記のようなクエリーを実行することで実現できます。

SELECT 
  * 
FROM 
  svv_external_columns 
WHERE 
  tablename = 'blog_clicks';

このクエリーはテーブル内の全カラムをそれぞれの定義と共にリストします。

schemaname tablename columnname external_type columnnum part_key
spectrum blog_clicks user_id varchar(50) 1 0
spectrum blog_clicks campaign_id varchar(50) 2 0
spectrum blog_clicks os varchar(50) 3 0
spectrum blog_clicks ua varchar(255) 4 0
spectrum blog_clicks ts bigint 5 0
spectrum blog_clicks billing double 6 0
spectrum blog_clicks date date 7 1
spectrum blog_clicks hour smallint 8 2

このデータを使用して、データの検証スキーマを作成することができます。

const rtb_request_schema = {
    "name": "clicks",
    "items": {
        "user_id": {
            "type": "string",
            "max_length": 100
        },
        "campaign_id": {
            "type": "string",
            "max_length": 50
        },
        "os": {
            "type": "string",
            "max_length": 50            
        },
        "ua": {
            "type": "string",
            "max_length": 255            
        },
        "ts": {
            "type": "integer",
            "min_value": 0,
            "max_value": 9999999999999
        },
        "billing": {
            "type": "float",
            "min_value": 0,
            "max_value": 9999999999999
        }
    }
};
次に、このスキーマを用いてデータを検証する関数を作成します。
function valueIsValid(value, item_schema) {
    if (schema.type == 'string') {
        return (typeof value == 'string' && value.length <= schema.max_length);
    }
    else if (schema.type == 'integer') {
        return (typeof value == 'number' && value >= schema.min_value && value <= schema.max_value);
    }
    else if (schema.type == 'float' || schema.type == 'double') {
        return (typeof value == 'number' && value >= schema.min_value && value <= schema.max_value);
    }
    else if (schema.type == 'boolean') {
        return typeof value == 'boolean';
    }
    else if (schema.type == 'timestamp') {
        return (new Date(value)).getTime() > 0;
    }
    else {
        return true;
    }
}

Kinesis Firehoseを使用したニアリアルタイムのデータローディング

Kinesis Firehose上で、イベントを処理するための新しいデリバリーストリームを以下の通り作成しました。

Delivery stream name: events
Source: Direct PUT
S3 bucket: nuviad-events
S3 prefix: rtb/
IAM role: firehose_delivery_role_1
Data transformation: Disabled
Source record backup: Disabled
S3 buffer size (MB): 100
S3 buffer interval (sec): 60
S3 Compression: GZIP
S3 Encryption: No Encryption
Status: ACTIVE
Error logging: Enabled

このデリバリーストリームはイベントデータを毎分または100MBごとに集計し、データをS3バケットにCSV/GZIP圧縮ファイルとして書き込みます。データが検証された後は、Kinesis Firehose APIに安全に送信することができます。


if (validated) {
    let itemString = item.join('|')+'\n'; //Sending csv delimited by pipe and adding new line
    let params = {
        DeliveryStreamName: 'events',
        Record: {
            Data: itemString
        }
    };

    firehose.putRecord(params, function(err, data) {
        if (err) {
            console.error(err, err.stack);        
        }
        else {
            // Continue to your next step 
        }
    });
}

これで、イベントデータを1分ごとに単一のCSVファイルとしてS3に保管することができるようになります。ファイルはKinesis Firehoseによって、UTC時間プレフィックスをYYYY/MM/DD形式で付加する形で自動的に命名され、その後オブジェクトがS3に書き込まれます。日付と時間をパーティションとして使用しているので、命名規則と場所はRedshift Spectrumスキーマに適合するよう変更する必要があります。

AWS Lambdaを使用したデータ分散の自動化

ファイルを別のロケーションにコピーするためのS3 PUTイベントをトリガーとする、シンプルなLambda関数を作成しました。ただしS3イベントは、我々のデータ構造と処理フローに適合するようリネームしています。先に触れた通り、Kinesis Firehoseによって生成されたファイルは事前に定義された構造で階層化されています。例えば以下のようなものです。

S3://your-bucket/your-prefix/2017/08/01/20/events-4-2017-08-01-20-06-06-536f5c40-6893-4ee4-907d-81e4d3b09455.gz

後は、オブジェクト名をパースして最適な形に再構成するだけです。我々のケースでは、以下のようにしています(このオブジェクトはLambda関数に渡されたもので、S3に書き込まれた当該オブジェクトに関するデータを保持しています)。

/*

	object key structure in the event object:

your-prefix/2017/08/01/20/event-4-2017-08-01-20-06-06-536f5c40-6893-4ee4-907d-81e4d3b09455.gz

	*/

let key_parts = event.Records[0].s3.object.key.split('/'); 

let event_type = key_parts[0];
let date = key_parts[1] + '-' + key_parts[2] + '-' + key_parts[3];
let hour = key_parts[4];
if (hour.indexOf('0') == 0) {
 		hour = parseInt(hour, 10) + '';
}

let parts1 = key_parts[5].split('-');
let minute = parts1[7];
if (minute.indexOf('0') == 0) {
        minute = parseInt(minute, 10) + '';
}

これで、必要に応じてファイルを2つの宛先に再配布することができるようになります。一つは分単位の処理タスク、もう一つは時間単位での集計です。

    copyObjectToHourlyFolder(event, date, hour, minute)
        .then(copyObjectToMinuteFolder.bind(null, event, date, hour, minute))
        .then(addPartitionToSpectrum.bind(null, event, date, hour, minute))
        .then(deleteOldMinuteObjects.bind(null, event))
        .then(deleteStreamObject.bind(null, event))        
        .then(result => {
            callback(null, { message: 'done' });            
        })
        .catch(err => {
            console.error(err);
            callback(null, { message: err });            
        }); 

Kinesis Firehoseはデータを一時フォルダーに保管します。このオブジェクトを、直近1分に処理されたデータを保管する別のフォルダーにコピーします。このフォルダーは、ずっと大きなデータセットをスキャンせずに処理できるよう、小さなRedshift Spectrumテーブルに接続されています。同じデータを、1時間分のデータを保管するフォルダーにコピーし、後で集計してParquetに変換できるようにします。

データを日付と時間に分割しているので、処理対象の分が1時間の最初の1分(つまり0分)だった場合は、以下のクエリーを実行してRedshift Spectrumテーブル上に新しいパーティションを作成しています。

ALTER TABLE 
  spectrum.events 
ADD partition
  (date='2017-08-01', hour=0) 
  LOCATION 's3://nuviad-temp/events/2017-08-01/0/';

データが処理されテーブルに追加されたら、Kinesis Firehoseの一時領域および分単位のフォルダーから処理済みデータを削除します。

AWS GlueおよびAmazon EMRを使用したCSVのParquet変換

CSVデータをParquetに変換する時間単位ジョブを実行する上で、我々の知る限り最もシンプルなやり方は、LambdaとAWS Glueを利用する方法です(AWSビッグデータチームの素晴らしい協力に感謝します)。

AWS Glueジョブの作成

このシンプルなAWS Glueジョブが行っていることは以下の通りです。

  • 処理対象のジョブ、日付、時間のパラメーターを取得
  • Sparkコードを実行するためのSpark EMRコンテキストを作成
  • CSVデータをDataFrameに読み込み
  • データをS3バケット上にParquetとして書き込み
  • Redshift Spectrum / Amazon Athenaテーブルパーティションを追加または修正
import sys
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import boto3

## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME','day_partition_key', 'hour_partition_key', 'day_partition_value', 'hour_partition_value' ])

#day_partition_key = "partition_0"
#hour_partition_key = "partition_1"
#day_partition_value = "2017-08-01"
#hour_partition_value = "0"

day_partition_key = args['day_partition_key']
hour_partition_key = args['hour_partition_key']
day_partition_value = args['day_partition_value']
hour_partition_value = args['hour_partition_value']

print("Running for " + day_partition_value + "/" + hour_partition_value)

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

df = spark.read.option("delimiter","|").csv("s3://nuviad-temp/events/"+day_partition_value+"/"+hour_partition_value)
df.registerTempTable("data")

df1 = spark.sql("select _c0 as user_id, _c1 as campaign_id, _c2 as os, _c3 as ua, cast(_c4 as bigint) as ts, cast(_c5 as double) as billing from data")

df1.repartition(1).write.mode("overwrite").parquet("s3://nuviad-temp/parquet/"+day_partition_value+"/hour="+hour_partition_value)

client = boto3.client('athena', region_name='us-east-1')

response = client.start_query_execution(
    QueryString='alter table parquet_events add if not exists partition(' + day_partition_key + '=\'' + day_partition_value + '\',' + hour_partition_key + '=' + hour_partition_value + ')  location \'s3://nuviad-temp/parquet/' + day_partition_value + '/hour=' + hour_partition_value + '\'' ,
    QueryExecutionContext={
        'Database': 'spectrumdb'
    },
    ResultConfiguration={
        'OutputLocation': 's3://nuviad-temp/convertresults'
    }
)

response = client.start_query_execution(
    QueryString='alter table parquet_events partition(' + day_partition_key + '=\'' + day_partition_value + '\',' + hour_partition_key + '=' + hour_partition_value + ') set location \'s3://nuviad-temp/parquet/' + day_partition_value + '/hour=' + hour_partition_value + '\'' ,
    QueryExecutionContext={
        'Database': 'spectrumdb'
    },
    ResultConfiguration={
        'OutputLocation': 's3://nuviad-temp/convertresults'
    }
)

job.commit()

備考:Redshift SpectrumとAthenaは共にAWS Glueデータカタログを使用するため、Athenaクライアントを使用してパーティションをテーブルに追加することができました。

float、decimalおよびdoubleについていくつか注意点があります。decimalを使用することは、Redshift SpectrumとSparkで取り扱いが異なることから、予想より多くの困難を伴いました。Redshift SpectrumとSparkでdecimalを使用する度に、以下のようなエラーが発生したのです。

S3 Query Exception (Fetch). Task failed due to an internal error. File 'https://s3-external-1.amazonaws.com/nuviad-temp/events/2017-08-01/hour=2/part-00017-48ae5b6b-906e-4875-8cde-bc36c0c6d0ca.c000.snappy.parquet has an incompatible Parquet schema for column 's3://nuviad-events/events.lat'. Column type: DECIMAL(18, 8), Parquet schema:\noptional float lat [i:4 d:1 r:0]\n (https://s3-external-1.amazonaws.com/nuviad-temp/events/2017-08-01/hour=2/part-00017-48ae5b6b-906e-4875-8cde-bc36c0c6d0ca.c000.snappy.parq

いくつかの浮動小数点フォーマットを試した結果、Spark上ではカラムをdoubleで定義し、Spectrumではfloatで定義するのが唯一有効な組み合わせであることがわかりました。課金データをSpectrumではfloat、Sparkコードではdoubleで定義しなければならない理由はここにあります。

変換を実行するためのLambda関数の作成

次に、次のようなPythonコードを用いて、AWS Glueスクリプトを1時間ごとに起動するためのシンプルなLambda関数を作成しました。

import boto3
import json
from datetime import datetime, timedelta
 
client = boto3.client('glue')
 
def lambda_handler(event, context):
    last_hour_date_time = datetime.now() - timedelta(hours = 1)
    day_partition_value = last_hour_date_time.strftime("%Y-%m-%d") 
    hour_partition_value = last_hour_date_time.strftime("%-H") 
    response = client.start_job_run(
    JobName='convertEventsParquetHourly',
    Arguments={
         '--day_partition_key': 'date',
         '--hour_partition_key': 'hour',
         '--day_partition_value': day_partition_value,
         '--hour_partition_value': hour_partition_value
         }
    )

Amazon CloudWatch Eventsを使用してこの関数を1時間ごとに実行しました。この関数は、‘convertEventsParquetHourly’という名前のAWS Glueジョブを起動して直近の1時間を処理し、ジョブ名とパーティションの値をAWS Glueに渡します。

Redshift SpectrumとNode.js

我々の開発スタックはNode.jsを基本としています。Node.jsは大量のトランザクションを処理する必要のある、高速・軽量なサーバーでの利用に適しています。しかし、Node.js環境にはいくつかの制約があるため、ワークアラウンドを用意し、別のツールを使うなどして、処理を完結させる必要がありました。

Node.jsとParquet

Node.jsにはParquetモジュールが欠けていたため、データをCSVからParquetへ効率的に移行するためには、AWS Glue / Amazon EMRによる処理を実装する必要がありました。本来は直接Parquetに保存したいところですが、他に妥当な方法が見つかりませんでした。

現在進められている興味深いプロジェクトの一つに、Marc VertesによるParquet NPMの開発があります(https://www.npmjs.com/package/node-parquet)。まだ正式リリースには至っていませんが、このパッケージの進捗は注視するに値すると考えています。

Timestampデータ型

Parquetドキュメンテーションによると、Timestampデータは64-bit integerとしてParquetに保存されます。しかしながら、JavaScriptのネイティブの数値型は整数レンジに53ビットのみを割り当てた64-bit doubleであり、64-bit integerはサポートしていません。

このため、Node.jsではTimestampを正しくParquetに保存することができません。解決策は、Timestampを文字列として保存し、クエリー内でTimestampとしてキャストすることです。この方法による性能劣化は一切観察されませんでした。

 

知見

我々のトライアンドエラーの経験から、以下のような知見を得ることができるかと思います。

知見 #1: データ検証は極めて重要である

前述の通り、パーティション内に壊れたエントリーが一つでもあると、そのパーティションに対するクエリーは失敗します。特に、Parquetを使用している場合は、シンプルなCSVファイルに比べて修正が困難です。Redshift Spectrumでスキャンする前に、データを検証するようにして下さい。

知見 #2: データを効率的に構造化および分割する

Redshift Spectrum(あるいはAthena)の最大の利点の一つは、ノードを常時起動しておく必要がないことです。実行したクエリーによってスキャンされたデータに対してのみ、課金が行われます。

異なるクエリーのために、データを異なる並びで保持しておくことは、この点では非常に有益です。例えば、時間ベースでクエリーを実行するために日付と時間でデータを分割し、user_idベースでクエリーを実行するためにuser_idと日付で分割した別のパーティションを持つことができます。これにより、あなたのデータウェアハウスはより高速かつ効率的になるでしょう。

正しいフォーマットでデータを保管する

可能な場合はParquetを利用して下さい。高速なパフォーマンス、より少ないスキャンデータ、列指向フォーマットによる効率性など、Parquetの効果は絶大です。ただし、Kinesis Firehoseで直接に利用することはできないため、独自のETLの仕組みを実装する必要があります。AWS Glueは素晴らしいオプションです。

頻繁なタスクには小さなテーブルを作成する

Redshift Spectrumを利用し始めた頃、我々はAmazon Redshiftのコストが一日当たり何百ドルも跳ね上がっていることに気づきました。丸1日分のデータを毎分、不必要にスキャンしていることに気づいたのはその後のことです。同じS3バケットないしフォルダーに対して複数のテーブルを定義できる利点を活かし、頻度の高いクエリーには一時的で小さなテーブルを用意するようにして下さい。

知見 #3: 最適なパフォーマンスのためにAthenaとRedshift Spectrumを組み合わせる

Redshift Spectrumへの移行は、同様にAWS Glueのデータカタログを使用しているAthenaの利点を活かすことにも繋がりました。シンプルでクイックなクエリーをAthenaで捌きつつ、より複雑なクエリーにはRedshift Spectrumを使ってAmazon Redshiftのクエリーエンジンを使う、といったことができます。

Redshift Spectrumは複雑なクエリーを実行することに秀でています。プレディケイトフィルタリングや集計といった計算能力依存のタスクの多くをRedshit Spectrum層にプッシュダウンすることができ、クエリーが消費するクラスターの処理能力を大幅に抑制できます。

知見 #4: パーティション内でParquetデータをソートする

sortWithinPartiions(sort_field)を用いてパーティション内でデータをソートすることで、さらなる性能改善を達成することができます。例えば以下のようにします。

df.repartition(1).sortWithinPartitions("campaign_id")…

結論

我々は、コアデータウェアハウスとして3年以上利用してきたAmazon Redshiftに非常に満足していました。しかし、我々のクライアントベースとデータ量が飛躍的に増加したことから、Amazon Redshiftを拡張し、Redshift Spectrumのスケーラビリティ、性能、コストの利点を活用することを決断しました。

Redshift Spectrumは事実上無制限のストレージ領域を利用すること、コンピュート能力を透過的に拡張すること、および我々のユーザーに極めて高速に結果を提供することを可能にしてくれます。Redshift Spectrumによって、我々はデータを望む場所に望むコストで保管し、そしてユーザーが望む時に彼らが期待するだけの性能で分析を行えるよう、データを利用可能な状態にしておくことができるのです。

著者について

テクノロジーリーディングカンパニーでの15年とアドテク業界での7年の経験を経て、Rafi ToniはNUVIADを設立しそのCEOに就任しました。新しいテクノロジーを探索し、現実世界で現実のマネーを生み出すカッティングエッジな製品やサービスに反映することを楽しんでいます。起業家としての経験から、Rafiは新規テクノロジーへの早期適応と実践的なプログラミングこそが大きな市場価値を生み出すと信じています。

 

 

(翻訳はプロフェッショナルサービス仲谷が担当しました。原文はこちら

re:Invent Recap – Windows によるエンタープライズイノベーション推進に関するアナウンスについて

私の同僚であるSandy Carterが先週の AWS re:Invent にてエンタープライズイノベーション戦略について共有しました。以下に彼女のステージでのアナウンス内容についての概略をお伝えいたします。 – Jeff;


 

“私はこの会社にイノベーションを起こしたいと思っていますが、成功できるかどうか自信がありません…”。私は自らの経験の中で、こういった懸念の言葉を何度も企業の経営幹部の方から伺いました。実際、最近のプライスウォーターハウスクーパースの調査では、93%の経営幹部がイノベーションを起こすことで企業の成長を達成するという事を信じていますが、そのうち半数の方々がその革新的なアイディアを速やかに市場に投入してゆく事に課題を持っている、という結果が出ています。

多くのお客様が企業におけるイノベーションを起こすことに苦労しておられるので、私はAWS re:Inventのこのステージ上から、奇跡的なイノベーションに成功された皆様の体験を共有していただけることに大変興奮を感じております。Johnson & Johnson 社から Parag Karnik 氏、Hess Corporation 社からBill Rothe 氏、Just Eat 社からDave Williams 氏そして Pitney Bowes 社からはOlga Lagunova 氏に、その素晴らしい成功体験と創造性をシェアして頂ける事に感謝いたします。

 

 

昨週にAWSから発表したもののうち、私は特に以下の企業におけるイノベーションを推進する新製品とプログラムについて興奮を覚えています :

AI: 深層学習向け “Amazon Machine Image (AMI) on EC2 Windows”

re:Inventでも共有しましたが、すでにInforのようなお客様はAWS上で展開、提供される業界特化型アプリケーションにAIを取り入れることに成功されております。我々はWindowsデベロッパーの方にも、MXNetTensorFlowCaffe2といった著名なフレームワークと取り入れ、簡単に素早くAIや機械学習への取り組みを開始していただきたいと考えています。これらを実現するために、我々はre:Inventにて新しく Deep Learning AMI for Microsoft Windowsをアナウンスいたしました。このAMIは機械学習アプリケーションのためのWindows Serverベースの大規模な深層学習のモデルトレーニング環境を簡単にそして素早く構築できるものです。

IoT: SQLとIoTデータの可視化と分析

市場予測によれば、2020年までに310億ものIoTデバイスが生まれるといわれています。AWSはWindowsを利用する全てのお客様が、そういったデバイスから得られるデータを有効活用できるようになる事を望んでいます。例えばPitney Bowes社は今や13万ものIoTデバイスのストリームデータをAWSで管理しています。そして機械学習を用いて顧客体験を向上させ、効率を改善し新しいサービスを充実させることに成功しています。AWS IoT Analyticsを活用して、IoTデータの分析を実行しIoTアプリケーションや機械学習のユースケースをより正確に判断するのに役立つ解析を行う事ができます。AWS IoT Analyticsは、SQL ServerのトランザクションデータなどのコンテキストメタデータでIoTデバイスのデータを自動的に補完させることができます。

AWS上での.NETデベロッパー向け機能の追加

AWS上のWindows開発者のために提供した快適な開発体験を支援する拡張に加えて、AWS LambdaおよびAWS CodeBuildに来年初頭より.NET Core 2.0サポートを追加することを発表しました。.NET Core 2.0には、Razorページ、.NETフレームワークとのより良い互換性、前バージョンの2倍以上のAPIなど多数の新機能が含まれています。この発表によりLambdaとCodeBuild上で、最新の.NET Core機能を利用してサーバーレスおよびDevOps環境を構築することができます。

Windowsアプリケーションの容易なバックアップ (VSSサポート)

我々は最近Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポートをアナウンスしました。これによってAmazon Elastic Block Store (EBS) を使いWindowsインスタンス上で稼働しているアプリケーションに対して、バックアップを取得するためのカスタムスクリプトやインスタンスのシャットダウンをすることなくVSSスナップショットを取得することが可能となります。Windowsアプリケーションをバックアップする際の運用負荷を取り除く事が可能となります。

BYOL方式におけるライセンスの最適化

AWSでは、お客様のワークロードのニーズに最も適した様々なインスタンスタイプとファミリを提供しています。お客様がもしvCPUカウントでライセンスされたソフトウェアを使用している場合は、vCPU数を微調整してライセンス費用を最適化するご要望があるかもしれません。私はここに、EC2のインスタンスを2つの側面でより適切にコントロールするための機能をアナウンスいたします:
1. vCPUベースのライセンス費用を節約するために、新しいインスタンスを起動するときにカスタムのvCPU数を指定できます。例えばSQL Serverのライセンスなどです。
2. 一部のハイパフォーマンスコンピューティング(HPC)アプリケーションのように、シングルスレッドCPUが適しているワークロードに対してハイパースレッディングテクノロジを無効にすることができます。これらの機能を使用することで、独自のライセンス(BYOL)を所有されているお客様はライセンス使用を最適化し節約することが可能となります。

Server Migration Service for Hyper-V Virtual Machines

Hess社のBill Rothe氏がre:Inventで共有していたように、Hess社ではSQL Server、SharePoint、SAP HANAなど幅広いワークロードのクラウドへの移行を成功させました。 AWS Server Migration Service(SMS)は、このようなエンタープライズでの移行をさらにサポートするために Hyper-V仮想マシン(VM)の移行をサポートするようになりました。AWS Server Migration Serviceにより、オンプレミスのHyper-V環境からAWSへの大規模なサーバー移行をより簡単に行うことができます。AWS Server Migration Serviceによって、稼働中のサーバーボリュームの増分レプリケーションを自動化し、スケジューリングし、追跡管理することが出来ます。複製されたボリュームは転送中に暗号化され、新しいAmazon Machine Image (AMI) として保存され、AWS上のEC2インスタンスとして起動可能となります。

Microsoft Premier Support for AWS End-Customers

マイクロソフトとAWSが優れたカスタマーエクスペリエンスを確保するための、新しいサポート統合プログラムを提供できることを嬉しく思います。マイクロソフトのプレミアサポートは、AWSがお客様を支援するのをサポートする事が出来るようになりました。AWSサポートエンジニアはMicrosoftワークロードを実行するAWSのお客様の代わりに、直接Microsoftサポートにエスカレーションすることができます。

ベストプラクティスツール: HIPAA コンプライアンスとデジタルイノベーションワークショップ

我々はこの11月に、AWSを使用してHIPAA準拠のアプリケーションを構築する方法を解説したHIPAAに焦点を当てたホワイトペーパーを更新しました。来年第1四半期には、一般的な医療系ユースケースでの強固なセキュリティ、コンプライアンス、リスク管理に関するHIPAAクイックスタートを拡張した導入ガイド提供する予定です. 私は自身のre:Inventセッションの中で、デジタルイノベーションワークショップをお客様に提供出来ることを嬉しく思い、より多くのお客様がこのワークショップを利用するのを楽しみにしています。

AWS: The Continuous Innovation Cloud

我々とお客様の共通のテーマは、AWSの継続的なイノベーションによっておお客様の改革を実現するという事です。継続的なイノベーションとは、日々より新しくより良いサービスを受けられるという事に他なりません。これは時には新しいサービスや機能の形をとっていたり、時には目に見えない部分の環境がよりよくなっていく形であったりもします。私はぜひ皆さんにも最近AWSが発表したサービスベストプラクティスを活用して、イノベーションの旅をどのように加速させることができるか体験していただきたいと思っています。Windowsワークロードを移行される場合には、ぜひAWSセールス担当者またはAWS Microsoft Workload Competencyパートナーと話し合って、どのようにすればマイグレーションを効率的に行えるかを検討する対話を開始していただければと思います。

– Sandy Carter, Vice President, AWS

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.

 

 

 

翻訳はSA松崎が担当しました. 原文はこちらです

AWS Single Sign-On 紹介

12/7 にリリースされた AWS Single Sign-On (AWS SSO) サービスをご紹介します。このサービスにより、複数の AWS アカウントやビジネスアプリケーションへの SSO アクセスを簡単に集中管理できるようになります。AWS SSO はユーザポータルを提供するため、ユーザは既にある企業内の認証情報を使ってアサインされた全ての AWS アカウントやアプリケーションを確認して、アクセスできます。AWS SSO は AWS Organizations と統合されており、組織内にある複数の AWS アカウントへのアクセスを管理できます。加えて、AWS SSO は Security Assertion Markup Language (SAML) 2.0 をサポートしており、AWS SSO アプリケション設定ウィザートを使って SAML が利用できるアプリケーションへの SSO アクセスにも広げることができます。AWS SSO は Salesforce、BOX、Office 365 など多くのビジネスアプリケーションとの SSO 連携が組み込まれており、簡単に設定が行なえます。

このブログ記事では、以下の 3 つの質問に答えることで AWS SSO を使い始めに役立つよう説明します。:

  1. AWS SSO はどんなメリットを提供するか?
  2. AWS SSO の主要機能は何か?
  3. どうやって使い始めればいいか?

(more…)

AWS利用におけるマネージドサービスの重要性

ラスベガスで開催された re:Invent が終わり、日本各地で、パートナーやユーザーコミュニティ、弊社による re:Capイベント(まとめイベント)が行われています。

ウェブページ「AWS re:Invent 2017 で発表された新しい機能とサービスの詳細」で新しく発表されたサービスの一覧がまとまっていますので、是非ご覧ください。

今回Amazon EC2では、C5インスタンスM5インスタンスH1インスタンスBare Metalインスタンス、等いくつかの新サービスの発表がありました。

それらに加えてとても多くのマネージドサービスの発表がされています。

私は、プロダクトマーケティング エバンジェリストとして外部でお話をさせていただく機会が多いのですが、予てより、AWSをより安価に、より効果的に、ご利用いただくためにはマネージドサービスの活用が不可欠です、というお話をさせていただいています。今回AWS re:Inventで多くのマネージドサービスが新たに発表され、お客様から、AWSは複雑になりそのキャッチアップが大変だ、というお話をいただいたこともありました。改めてマネージドサービスの重要性について費用面からまとめてみたいと思います。

ここでは、AWSの中で一番簡単なマネージドサービスであるAmazon S3を例にご紹介いたします。

(more…)

Amazon Kinesis を用いた Databaseの継続的な変更

Emmanuel Espina は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。

このブログ記事では、Amazon Kinesis を使用して変更をストリーミングすることによって、中央リレーショナルデータベース を他のシステムと統合する方法について説明します。

次の図は、分散システムにおける一般的なアーキテクチャ設計を示しています。これには、「」と呼ばれる中央ストレージと、この中央ストレージを消費するいくつかの派生「衛星」システムが含まれます。

この設計アーキテクチャを使用して、リレーショナルデータベースを中央データストアとして使用し、このシステムのトランザクション機能を利用してデータの整合性を維持することができます。このコンテキストにおける派生システムは、この変化の事実の単一ソースを観察し、それらの変更を変換し、フィルタリングし、最終的にはその内部インデックスを更新する全文検索システムとすることができます。もう 1 つの例は、OLAP クエリに適した列形式ストレージです。一般に、中央リレーショナルシステムの個々の行を変更する際にアクションを取る必要のあるシステムは、派生データストアに適した候補となります。

これらの種類のアーキテクチャの単純な実装では、変更された行を検索するために派生システムが定期的にクエリを発行し、本質的に SELECT ベースのクエリで中央データベースをポーリングします。

このアーキテクチャのより優れた実装となるのが、非同期の更新ストリームを使用するアーキテクチャです。データベースには通常、行のすべての変更が格納されるトランザクションログがあるため、この変更のストリームが外部オブザーバシステムに公開されている場合、これらのシステムにこれらのストリームを添付して行の変更を処理およびフィルタリングできます。ここでは、中央データベースとして MySQL、メッセージバスとして Amazon Kinesis を使用して、このスキーマの基本的な実装をご紹介します。

通常、MYSQL バイナリログは、マスター上のすべての変更を読み取ってローカルに適用する読取りレプリカに公開されます。この記事では、変更をローカルデータベースに適用するのではなく、Amazon Kinesis ストリームに変更を公開する、一般化されたリードレプリカを作成します。

このメソッドの重要な点の 1 つは、コンシューマーが SQL クエリを受け取らないことです。SQL クエリは公開される可能性もありますが、一般的なオブザーバーは、SQL 互換のデータレプリカを維持しない限り、SQL にはあまり関心がありません。代わりに、変更されたエンティティ (行) を 1 つずつ受け取ります。このアプローチの利点は、コンシューマーが SQL を理解する必要はなく、事実の単一ソースは誰が変更を消費するのかを知る必要はないということにあります。これは、さまざまなチームが、必要なデータ形式で調整することなく作業できることを意味します。さらに都合がいいことに、Amazon Kinesis クライアントはが特定の時点から読む機能を備えているため、各コンシューマーは独自のペースでメッセージを処理します。これが、メッセージバスがシステムを統合するための結合されていない方法の 1 つとなる理由です。

この記事で使用されている例では、行フェッチャーは中央データベースに接続する通常の Python プロセスであり、リードレプリカをシミュレートします。

データベースは、Amazon RDS または MySQL の任意のインストールのいずれかになります。RDS の場合、フェッチャープロセスは RDS インスタンスホストにカスタムソフトウェアをインストールすることができないため、別のホスト (たとえば EC2) にインストールする必要があります。外部インストールの場合、フェッチャープロセスはデータベースと同じホストにインストールできます。

マスター MySQL インスタンスの準備

MySQL マスター (真実の単一のソース) は、それが通常のレプリケーションのマスターであるかのように設定する必要があります。個々の変更された行を受け取るには、Binlog を有効にして ROW 形式で作業する必要があります。(そうしないと、SQL クエリだけになってしまいます。)詳細については、MySQL サイトの「バイナリログ」を参照してください。

バイナリログを有効にするには、my.cnf 設定ファイルに次の 2 行を追加します。

log_bin=<path to binlog>
binlog_format=ROW

すべての接続 (たとえば、init_connect または JDBC などのデータベース API を使用) のグローバルまたはセッションレベルで、トランザクション分離レベルをコミット済み読み取りに設定することによって、行ベースのロギングを取得できます。

RDS (MySql 5.6+) を使用している場合は、簡単です。定期的なバックアップを有効にして (バックアップが有効になっていなければバイナリログは無効になります)、パラメータグループ変数 binlog_format を ROW に更新することによって、必要な設定を作成できます。(これは、パラメータグループの RDS ダッシュボードから行うことができます。)

アクセス権限の追加

RDS で作成されたデフォルトのユーザーを使用している場合は、既にこれらのアクセス許可がある可能性があります。そうでない場合は、REPLICATION SLAVE 権限を持つユーザーを作成する必要があります。詳細については、「レプリケーション用のユーザーの作成」を参照してください。

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

Amazon Kinesis ストリームの作成

Amazon Kinesis ストリームと boto3 クライアントの認証情報が必要です。クライアントの認証情報の詳細については、「Boto 3 ドキュメント」を参照してください。

Amazon Kinesis コンソールを開き、[ストリームの作成] を選択します。

使用するストリームの名前とシャード数を入力します。この例では、1 つのシャードがあります。

数分後、ストリームで行の変更を受け入れる準備が整います。

CLI ユーザーに権限を割り当てる

AWS Identity and Access Management (IAM) を使用して、このストリームにアクセスする CLI ユーザに権限を与えることができます。

この例では、そのユーザーは KinesisRDSIntegration です。ユーザーを作成したり、既存のユーザーを使用することはできますが、Amazon Kinesis ストリームへの書き込み権限を追加する必要があります。

ストリームに固有のポリシーを作成できます。この例では、Amazon Kinesis に完全にアクセスできるスタンダードポリシーを使用しています。

マスターに接続して変更を公開する

Python パブリッシャーが必要とするライブラリをインストールするには、次のコマンドを実行します。

pip install mysql-replication boto3

詳細な手順については、次を参照してください。

https://github.com/noplay/python-mysql-replication

https://boto3.readthedocs.io/en/latest/guide/quickstart.html

ここに、マジックを実行する Python スクリプトがあります。<HOST>、<PORT>、<USER>、<PASSWORD>、および <STREAM_NAME> の各変数を設定値に置き換えることを忘れないでください。

Python

 

import json

import boto3



from pymysqlreplication import BinLogStreamReader

from pymysqlreplication.row_event import (

  DeleteRowsEvent,

  UpdateRowsEvent,

  WriteRowsEvent,

)



def main():

  kinesis = boto3.client("kinesis")



  stream = BinLogStreamReader(

    connection_settings= {

      "host": "<HOST>",

      "port": <PORT>,

      "user": "<USER>",

      "passwd": "<PASSWORD>"},

    server_id=100,

    blocking=True,

    resume_stream=True,

    only_events=[DeleteRowsEvent, WriteRowsEvent, UpdateRowsEvent])



  for binlogevent in stream:

    for row in binlogevent.rows:

      event = {"schema": binlogevent.schema,

      "table": binlogevent.table,

      "type": type(binlogevent).__name__,

      "row": row

      }



      kinesis.put_record(StreamName="<STREAM_NAME>", Data=json.dumps(event), PartitionKey="default")

      print json.dumps(event)



if __name__ == "__main__":

   main()

このスクリプトは、変更された各行を JSON 形式でシリアル化された Amazon Kinesis レコードとして公開します。

メッセージを使用する

これで、変更されたレコードを使用する準備が整いました。あらゆるコンシューマーコードが動作します。この記事のコードを使用すると、次の形式でメッセージが表示されます。

{"table": "Users", "row": {"values": {"Name": "Foo User", "idUsers": 123}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"values": {"Name": "Bar user", "idUsers": 124}}, "type": "WriteRowsEvent", "schema": "kinesistest"}
{"table": "Users", "row": {"before_values": {"Name": "Foo User", "idUsers": 123}, "after_values": {"Name": "Bar User", "idUsers": 123}}, "type": "UpdateRowsEvent", "schema": "kinesistest"}

まとめ

このブログ記事では、擬似リードレプリカと Amazon Kinesis を使用して、変更ストリームをデータベースのレコードに公開する方法を説明しました。多くのデータ指向の企業が、これに類似したアーキテクチャを使用しています。この記事で提供されている例は、実際の本番環境には対応していませんが、この統合スタイルを試して、エンタープライズアーキテクチャの拡張機能を改善するために使用できます。最も複雑な部分は、おそらく Amazon Kinesis の背後で既に解決されているものでしょう。接着剤の役割を果たすものを提供する必要があります。

その他のリソース

すべてのソフトウェアエンジニアがリアルタイムデータの統合抽象化について知っておくべきこと

Databus に搭載されているすべてのもの: LinkedIn のスケーラブルで一貫性のある変更データキャプチャプラットフォーム

 

Alexa for Business: ワークプレイスでAmazon Alexaデバイスの利用

私の日常生活にはAlexaよりも多くのものが統合されています。私は、Echoデバイスと利用可能なAlexa スキルを家のライトをつけたり、ドアベルを鳴らしてる人を確認するためにEcho Showにビデオをながしたり、1週間単位で多くのTo Doの状態を確認したり、音楽を再生したするなど多くのことを行ってます。私は家族のメンバーに、今では生きていけないと思われないあらゆる種類の活動のために、自分のEchoデバイスでAlexaスキルを有効にすることさえできます。ずっと古い世代にいる母(私が言ったことは内緒にしてください)は、母のEchoデバイスと私がベーキングレシピを保管するために作ったカスタムAlexaスキルを使ってます。彼女は、また、最新の健康や美食情報のスキルを探すことを楽しんでいます。私は仕事に行くときに何かが欠けているように感じてます。例えば、単にカレンダーから次のアポをAlexaに聞くこともできないのです。

Alexaを仕事のためのアシスタントとして利用したい人のために、エキサイティングなニュースがあります。ビジネス及び組織に皆様が知っており、好きなAlexaをスケーラブルな形で職場に持ち込むことができる新しいサービス、Alexa for Businessサービスを発表できることを嬉しく思います。Alexa for Businessサービスは、Alexaを仕事場に持ち込み業務の効率化をはかりたいだけでなく、Echoデバイスやプライベートスキルの有効化及び企業ユーザ管理をするためのツールとリソースを提供いたします。

Alexa for Buisnessで職場をよりスマートに

Alexa for Businessは、皆様が知っており、好きなAlexaを仕事場にもちこみ、すべてタイプの人たちの生産性をサポート、共有されたEchoデバイス及び個人保有のEchoデバイスの管理を支援します。仕事場では、共有されたデバイスは、誰もが利用するために共有の場所に設置することができ、ユーザは、職場でも家でもパーソナルデバイス利用することができます。

エンドユーザは、共有のデバイス、または、個人のデバイスを利用することができます。以下がそれぞれのデバイスでできることです。

共有のデバイス

  1. 会議室からミーティングに参加:”Alexa、ミーティングを開始して”という言うだけです。Alexaは、ビデオ会議装置の電源をつけ、電話会議用電話番号にダイヤルし、ミーティングに参加できます。
  2. オフィス関連の手助け:カスタムスキルを利用することでオフィス関連の意思決定の手助け、空いている会議室を探す、設備の故障の報告、用品のオーダーができます。

個人のデバイス

  1. 電話とメッセージの利用が可能:Alexaは、ハンズフリーで電話をかけることやメッセージ送信ができます
  2. 自動的に会議にダイヤルイン:Alexaは、家、職場、または、外出先でも声によりミーティングに参加できます。
  3. インテリジェント アシスタント:Alexaが、クイックにカレンダーをチェックし、ミーティングのスケジュールを助け、To-Doリストを管理し、リマインダーをセットできます。
  4. 情報の検索:Alexaは、Salesforce、ConcurやSplunkのような人気のビジネスアプリケーション内の情報を見つけるのに役立ちします

管理者が利用できるコントロールの一部を次に示します:

  1. 共有のAlexaデバイスのプロビジョニングと管理:Alexa for Businessコンソールを使用して、職場の共有デバイスをプロビジョニングして管理できます。各デバイスごとに、会議室の指定などの場所を設定したり、デバイスのパブリックスキルとプライベートスキルを割り当てることができます。
  2. 会議室の設定を構成する:簡単な「Alexa、会議を開始して」を使用して会議を始めることができます。Alexa for Businessでは、会議室の設定を構成したあと、Alexaを使用して会議を開始し、会議室設備を制御したり、部屋のAmazon Echo デバイスから直接ダイヤルインすることができます。
  3. ユーザー管理:Alexa for Businessアカウントで個人のAlexaアカウントを登録するために、組織内のユーザーを招待することができます。ユーザーが登録されると、カスタム プライベート スキルを有効にして、個人用のAlexaアカウント、職場または自宅のいずれかのデバイスで使用することができます。
  4. スキルの管理:組織が作成したパブリックスキルとカスタムプライベートスキルを共有デバイスに割り当て、登録されたユーザーがプライベートスキルを利用できるようにすることができます。スキルグループを作成して、特定の共有デバイスに割り当てることができます。
  5. プライベートスキルを構築し、Alexa for Business APIsを使用する:Alexa Skill Kit を利用し、自分のスキルを作成します。Alexa Skills Storeに公開することなく、Alexa for Businessアカウントで共有デバイスや登録ユーザーが利用できるようにすることができます。 Alexa for Businessは追加のAPIを提供しています。このAPIを使用してスキルにコンテキストを追加し、管理タスクを自動化できます。

それでは、Alexa for Businessの流れをみてみましょう。まず、AWSコンソールにログインし、Alexa for Businessサービスにアクセスします。

 

ログインした直後、Alexa for Businessのダッシュボードをご覧いただけます。見ての通り、部屋や共有デバイス、ユーザ及びスキルの管理ができます。また、会議、カレンダー、およびユーザーの招待状を制御する機能を提供します。

 

まず、私はAlexaデバイスをセットアップすることから始めます。 Alexa for Businessは、複数のデバイスを設定し、それらをWi-Fiネットワークに接続し、Alexa for Businessアカウントに登録するデバイス設定ツールを提供します。これは、個人的なAlexaデバイスの設定プロセスとはまったく異なります。 Alexa for Businessでは、一度に25台のデバイスをプロビジョニングできます。

私のデバイスがプロビジョニングされたら、私はこれらのデバイスを置く場所(私の会議室など)のロケーションプロファイルを作成できます。 Alexa for Businessコンソールでは、これらの場所を「部屋」と呼んでいます。私は部屋のプロフィールメニューに行き、部屋のプロフィールを作成することができます。ルームプロファイルには、デバイスの起床ワード、アドレス、タイムゾーン、測定単位、および発信通話を有効にするかどうかなど、部屋のAlexaデバイスの一般的な設定が含まれています。

次のステップは、設定したデバイスのスキルを有効にすることです。私はAlexa Skills Storeのスキルを有効にするか、プライベートスキル 機能を使用して自分自身で構築し、Alexa for Businessアカウントで利用できるようにすることができます。共有デバイスのスキルを有効にするには、スキルメニューオプションにアクセスし、スキルを有効にします。スキルを有効にしたら、それらをスキルグループに追加して、スキルグループを自分の部屋に割り当てることができます。

ビジネスのためのAlexaについて私が本当に好きなものは、Alexaを使って電話会議にダイヤルすることです。これを有効にするには、[会議]メニューオプションに行き、[プロバイダーの追加]を選択します。 AmazonではAmazon Chimeを使用していますが、異なるプロバイダのリストから選択することもできますし、必要に応じて独自のプロバイダを追加することもできます。

私がこれを設定したら、 “Alexa、会議に参加する”と言うことができます。 Alexaは私のAmazon Chime会議IDを要求します。その後、私のEchoデバイスは自動的にAmazon Chime会議にダイヤルします。 Alexa for Businessは、会議をすばやく開始するインテリジェントな方法も提供します。私たちはすべて会議室に入り、会議IDまたは電話番号を見つけることができませんでした。ビジネス向けのAlexaを使用すると、社内カレンダーにリンクすることができます。Alexaは私の会議情報を把握し、自動的にダイヤルできます。会議IDは必要ありません。ここでそれを行う方法は次のとおりです。

Alexaは部屋のビデオ会議機器を制御することもできます。これを行うには、私が持っている設備のスキルを選択し、設備提供者を選択し、私の会議室で有効にするだけです。 Alexaに私の会議に参加するように頼んだら、Alexaは部屋の機器からダイヤルインし、何もせずにビデオ会議システムを起動します。

次に登録ユーザに切り替えましょう。

私のAlexa for Businessアカウントにユーザーを招待できるように、私の組織のユーザー招待状を設定することから始めます。ユーザーが組織内でAlexa for Businessを使用できるようにするには、管理コンソールから電子メールでユーザーの招待状を送信して、自分のAlexaアカウントにサービスを登録するよう招待します。私が選択すると、ユーザーの登録メールをカスタマイズして、追加のコンテンツを含めることができます。たとえば、組織のAlexaスキルに関する情報を追加できます。スキルは、招待を受け入れて登録プロセスを完了した後に有効にすることができます。私のユーザは、会議通話への自動ダイヤル、Microsoft Exchangeカレンダーのリンク、プライベートスキルの使用など、Alexa for Businessの機能を使用するために参加する必要があります。

ユーザー招待状をカスタマイズしたので、ダッシュボードの[ユーザー]メニューに移動して電子メールアドレスを入力することで、自分の組織のAlexa for Businessを利用するようにユーザーを招待します。これにより、私の組織に参加するためのリンクが記載されたメールが送信されます。ユーザーは、自分のAlexaデバイスが登録されているAmazonアカウントを使用して参加します。 Jeff Barrを私のAlexa for Businessに参加してもらいましょう。

Jeffは私のAlexa for Businessアカウントに登録した後、彼は、私が登録ユーザ向けに有効にしたプライベートスキルを見つけることができ、彼の仕事のスキルにアクセスでき、彼の自宅のオフィスにあるEcho含む彼個人のどのデバイスからでも会議に参加できます。

サマリ

Alexa for Businessのコンソールとサービスの機能について簡単に解説しました。 Alexa for BusinessのWebサイトを表示したり、AWSドキュメントの管理者ガイドとAPIガイドを読んだり、Alexa for BusinessコンソールのGetting Startedビデオを見たりすることで、Alexa for Businessの詳細を知ることができます。

“Alexa, Say Goodbye and Sign off the Blog Post.”

 

– Tara

翻訳はSA榎並が担当しました
原文:こちら

AWS CloudTrail にAWS Lambda 関数の実行ログ機能を追加

AWS CloudTrail Lambda データイベント機能を利用することで、AWS Lambda関数の実行ログを取得できます。今まではLambda管理イベントだけが記録されていましたが、この機能により、関数がいつ誰によって作成、変更、削除されたかという情報も提供します。そしてこれにより、Lambdaデータイベントを記録したり、どの関数が実行されたか、そしていつ誰がどのAPIコールを呼び出したのかという詳細情報も得ることができます。全てのLambdaデータイベントはAmazon S3バケットやAmazon CloudWatch Eventsに送られ、CloudTrailによってイベント記録されたときに応答させることが出来ます。例えば、過去3日間に実行されたLambda関数をすぐに特定することができ、また、それらのAPIコールのソースを特定することもできます。また、不適切なLambda実行を検出した際、不明なユーザーやロールによるAPIコールの制限を迅速に実施することも可能です。

AWS CloudTrailコンソールやAWS CLI、SDKを使うことで、AWS Lambdaデータイベント機能を有効にすることが可能です。新しいトレールを作成するか既存のトレールを編集することで、どのLambda関数のログを取得するかを表示したり選択したりすることが可能です。

AWS CloudTrail Lambdaデータイベントは現在、全てのパブリックリージョン、AWS GovCloud (米国)、中国(北京)で利用可能です。ぜひこちらにてサポートされる全リージョンをご確認ください。

 

AWS CloudTrail のさらなる詳細情報:
製品ページ(日本語)
サポートされるサービス(日本語)
ドキュメント(日本語)
リリースノート(英語)

原文: AWS CloudTrail Adds Logging of Execution Activity for AWS Lambda Functions  (Posted On: Nov 30, 2017)
翻訳担当: PSA市崎