Amazon Web Services ブログ

AWSの自社認証局への移行に備える方法

AWS Certificate Manager image

TLS (Transport Layer Security, 以前は SSL と呼ばれていました) はインターネットでやりとりされる情報を暗号化するために不可欠です。例えば、Amazon.com ではウェブサイト上の全トラフィックに TLS を使用していますし、AWS は AWS サービスへの安全な呼び出しに使用しています。

証明書と呼ぶ電子ドキュメントは、暗号化した接続を行う際にサーバのアイデンティティを証明します。アドレスバーに入力した Web サイトとブラウザが安全に通信しているかを検査するのに証明書は役立ちます。CA としても知られている 認証局 は、特定のドメイン名に対して証明書を発行します。ドメインが信頼された認証局から発行された証明書を提示すると、ブラウザやアプリケーションは通信を行っても安全だとわかります。

2016年 1月、AWS は AWS Certificate Manager (ACM) の提供を開始しました。このサービスは、AWS サービスで使用できる SSL/TLS 証明書を簡単に作成、管理できるようにします。証明書にはアマゾンの自社認証局 Amazon Trust Services から発行されたものを追加料金無しで利用できます。ブラウザやその他のアプリケーションが証明書を信頼するには、証明書の発行者がブラウザなどが信頼している認証局一覧である 信頼ストア に含まれている必要があります。もし信頼ストアに発行した認証局が含まれていない場合は、ブラウザはエラーメッセージ(参考例)を表示したり、アプリケーションは独自のエラーを表示します。AWS は Amazon Trust Services 認証局 があらゆるところで確実に使えるようにするために、2005年以降のほとんどのブラウザで信頼されているルート認証局である Starfield Services の認証局の一つを購入しました。これは Amazon Trust Services で発行された証明書を使うために何もする必要が無いことを意味しています。

AWS は Amazon Trust Services 認証局 からお客様に無料の証明証を提供してきました。これより AWS は Amazon EC2Amazon DynamoDB などのサービスにも Amazon Trust Services からの証明書を使用するよう移行して行きます。このブログ記事では、Amazon Trust Services 認証局を使う準備ができているか検証する方法について説明します。

証明書ストアに Amazon Trust Services の認証局群が含まれているか確認する

次の表は Amazon Trust Services の証明書一覧です。これらの証明書が使用しているブラウザの信頼ストアに含まれているか確認するには、表にあるそれぞれの Test URL をクリックして正常に表示されるか確認して下さい。問題がある場合は、この例 のようにエラーが表示されます。

識別名 (DN) サブジェクトの公開鍵 SHA-256 ハッシュ Test URL
CN=Amazon Root CA 1,O=Amazon,C=US fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 Test URL
CN=Amazon Root CA 2,O=Amazon,C=US 7f4296fc5b6a4e3b35d3c369623e364ab1af381d8fa7121533c9d6c633ea2461 Test URL
CN=Amazon Root CA 3,O=Amazon,C=US 36abc32656acfc645c61b71613c4bf21c787f5cabbee48348d58597803d7abc9 Test URL
CN=Amazon Root CA 4,O=Amazon,C=US f7ecded5c66047d28ed6466b543c40e0743abe81d109254dcf845d4c2c7853c5 Test URL
CN=Starfield Services Root Certificate Authority – G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US 2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92 Test URL
Starfield Class 2 Certification Authority 2ce1cb0bf9d2f9e102993fbe215152c3b2dd0cabde1c68e5319b839154dbb7f5 Test URL

証明書ストアに Amazon Trust Services の認証局群が含まれていなかった時に何をすべきか

Test URL の確認がどれか 1 つでも失敗した場合は、信頼ストアをアップデートする必要があります。信頼ストアをアップデートする最も簡単な方法は、使用している OS や ブラウザをアップグレードすることです。以下の OS では Amazon Trust Services の証明書群が含まれています。:

  • Microsoft Windows Vista, Windows 7, Windows Server 2008 以降のバージョン(2005年 1月以降のパッチがインストールされていること)
  • Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 以降のバージョン
  • Red Hat Enterprise Linux 5 (2007年3月), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
  • Ubuntu 8.10
  • Debian 5.0
  • Amazon Linux (全バージョン)
  • Java 1.4.2_12, Jave 5 update 2 以降のバージョン、Java 6, Java 7, Java 8 含む

全ての最新ブラウザはアマゾンの認証局を信頼しています。単にブラウザをアップデートする事で、ブラウザの証明書バンドルをアップデートすることができます。ブラウザをアップデートする手順はそれぞれの Web サイトで確認する事ができます。:

もしアプリケーションが独自の信頼ストアを使用している場合は、アマゾン ルート認証局群 をアプリケーションの信頼ストアに登録頂く必要があります。登録手順はアプリケーションやプラットフォームによって異なります。使用しているアプリケーションやプラットフォームのドキュメントを参照して下さい。

AWS SDK や CLI

ほとんどの AWS SDK や CLI は Amazon Trust Services 認証局への移行の影響を受けませんが、もし 2013年 10月 29日 より前にリリースされた Python の AWS SDK や CLI を使用している場合は、アップグレードする必要があります。.NET, Java, PHP, Go, JavaScript, C++ の SDK や CLI には証明書は含まれておらず、基礎となる OS から証明書が来ています。Ruby SDK では 2015年 6月 10日以降 は必要な認証局の少なくても1つが含まれています。それより前の Ruby V2 SDK には証明書が含まれていません。

証明書ピンニング

証明書ピンニング (certificate pinning) と呼ばれる手法を使ってドメインごとに信頼する認証局を限定している場合、ピンニングを調整して Amazon Trust Services 認証局を追加する必要があります。証明書ピンニングは、不正な証明書を使いアプリケーションを騙して違法ななりすましサイトへ接続させようとする攻撃への防御に役立ちます。特定の固定された証明書への制限は、送られてきた証明書が期待される証明書であることを確認することによって行われます。これは、サーバから受信した証明書の公開鍵のハッシュがアプリケーションが対象ドメインについて保存し期待しているハッシュと一致するかどうかをチェックすることによって行われます。もしハッシュが一致しなければ、アプリケーションは接続を中止します。

AWS は、証明書ピンニングの使用は将来的な可用性リスクを招くため、推奨していません。もしピンニングしている証明書が置き換えられると、アプリケーションは接続が行えなくなってしまいます。ピンニングが必要なユースケースの場合は、個々の証明書ではなく認証局をピンニングすることを推奨します。Amazon Trust Services 認証局をピンニングする場合、このブログ記事記載の全ての認証局全てをピンニングすべきです。

このブログ記事にコメントがる場合、(原文の)記事のコメントセクションに記載して送って下さい。もしこの記事について質問がある場合は ACM forum に新しいスレッドを作成して質問して下さい。

– Jonathan

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

※本記事を公開した2017/11/7の際、AWS CLIやPython SDK は 2015年2月5日 より古いバージョンを使っている場合に更新が必要としていましたが、2013年10月29日より古いバージョンが更新必要と修正させていただきます。

アプリ内にボイスインターフェースを開発する方法 Astro Technology

今回のブログは Astro Technology, Inc. の CTO である Roland Schemers 氏より寄稿いただきました。Astro は同社について次のように説明しています。「当社はユーザーやチーム向けに開発した人工知能を使用する Mac や iOS および Android 用のメールアプリを製作しています。アプリ内のメールボイスアシスタント、Astrobot Voice を使えば、Astro アプリを終了せずにメールを読んだり返信することができます。」

そして最近では Astrobot Voice という初のアプリに組み込まれているメールボイスアシスタントをリリースしたばかりです。これにより、iOS 向け AstroAndroid 向けアプリを終了する必要なく、メールの読み取り、管理、返信が可能になりました。

Astro が 6 月に Amazon Alexa スキルをリリースしてから、我々はより多くのユーザーが音声でメール管理をできるようにしたいと考えました。そこで、今回のブログではなぜ我々がこうした選択を取ったのか技術面から説明し、どのようにこれを実現しどういったテクノロジーを使用したのかご説明します。

アプリ内ボイスを構築する理由は?

当社では Amazon Echo を愛用しています。実際、Astro の新入社員には「ようこそ」という意味はもちろん、我々の Alexa スキルを社内で試験運用することを兼ねて、各自に Echo Dot を提供しています。結果として私達のスキルが上々であることが分かり、より多くのユーザー、そしてさらに様々な場所で取り入れられる方法を新たに見つけることもできました。そこでアプリ内ボイスを構築できるか、その可能性を探ってみることにしたのです。

ソフトウェアの選択

アプリ内ボイスの構築方法を決定する上で、我々はいくつものオプションを検討しましたが、その上でいくつかのポイントを念頭に置きました。

  1. まず、当社のテキストベースアシスタント (api.ai で実行) または Alexa スキルからできるだけ多くのコードやロジックを再使用することです。
  2. そして、正確な音声認識を使用してスムーズなユーザーエクスペリエンスを製作すること。
  3. さらに、手間の掛かる作業はサーバーに任せることです。

我々のタイムラインとエンジニアリングのリソースを考えると最初のポイントは重要でした。当社は小規模のスタートアップ企業なので、そうした時間の節約は大いに役立つからです。

そして、2 つめのポイントであるスムーズなユーザーエクスペリエンスを作ることは特にチャレンジでした。スケールといった点で Amazon Alexa の自然言語処理のレベルは明らかに優勢でした。そのため、正確性を伴うエクスペリエンスを作ろうとする上で、AWS サービスやそのディープラーニングテクノロジーを活用したいという点は我々にとって明白でした。

そして 3 つめのポイントにおいては、Astrobot Voice に OS レベルの API とサーバー側における開発の組み合わせが必要であることが分かっていました。初期導入では、コストを抑えながら大方の手間が掛かる作業をサーバーが行うようにしました。大方の作業をサーバーに任せることのメリットには、iOS と Android アプリ両方で共有するコード、そしてアプリストアに Astro アプリの更新したバージョンをプッシュする必要なく、サーバーでフロー変更を行えるようにするといった点があります。

スタック

iOS

音声認識の iOS API には AVSpeechSynthesizerSFSpeechRecognizer を使用しました。SFSpeechRecognizer は iOS 10+ でのみ利用することが可能なので、Astrobot Voice は iOS 10 および 11 でのみ使用できます。そのためアプリ開発者にとってこれが制限の要因になることもあるかもしれませんが、当社においては問題ありませんでした。

Android

Android では音声認識にスタンダード Android API を使用しました。これには Speech RecognizerText To Speech が含まれています。

iOS そして Android のどちらにおいても、サーバーが記録したテキストまたはテキストストリングを送信できるオプションもありました。コスト、時間的制約、レイテンシーを考慮した上で、当社では後者のオプションを選ぶことにしました。

サーバー

サーバー側では Amazon Lex を使用しました。api.ai ではなく Amazon Lex を選んだことで、すでに Alexa と同じロジックの多くを再使用し共有することができました。テキストベースバージョンの Astrobot と同じロジックをいくつか再使用することもできましたが、最終的には時間節約と、より良いエクスペリエンスを提供できる Amazon Lex を使用することにしました。そうすることで開発者 1 人あたり約 2~4 週間ほど時間を節約できました。Astrobot Voice の開発そして我々の Alexa スキルを磨いていく上で、今後も時間を節約していくことができるでしょう。

この先、Astro の有料バージョンを提供する際には (現在、当社アプリは無料)、音声入力には Amazon Lex そして音声出力には Amazon Polly を当社のオンデバイス音声認識と置換することで、さらに AWS サービスを活用して行きたいと考えています。そうすることでボットエクスペリエンスの質を改善することができます。

次に Astrobot Voice エクスペリエンスを作成するために、こうしたサービスがどのように連動するのか、その流れとアーキテクチャを図で示しました。

(more…)

Cost allocation tagsについて

AWS リソースにタグを付け、タグごとにコストの内訳を確認する機能は、以前から提供されていました。コスト配分の機能は 2012 年に開始され (「お客様の請求のための AWS コスト配分」を参照)、当社はその他のサービスのサポートを安定して追加してきました。最も最近では DynamoDB (「Amazon DynamoDB 用のコスト配分タグの概要」)、Lambda (「AWS Lambda がタグ付けとコスト配分をサポート」)、EBS (「新規 – AWS Snapshots 用のコスト配分」) が追加されました。

本日は、Amazon Simple Queue Service (SQS) 用のタグベースのコスト配分を発表いたします。これにより、キューにタグを割り当て、それを使用して、アプリケーション、アプリケーションステージ (キューを介して通信する疎結合アプリケーション用)、プロジェクト、部署、開発者など、目的とするあらゆるレベルでコストを管理できます。キューにタグを付けたら、AWS Tag Editor を使用して、対象のタグが付けられたキューを検索できます。

私のキューの 1 つに 3 つのタグ (appstagedepartment) を追加する方法をご覧ください。

この機能はすべての AWS リージョンで今すぐご利用いただけます。タグ付けの詳細については、「Amazon SQS キューにタグを付ける」を参照してください。タグを使用したコスト配分の詳細については、「コスト配分タグの使用」を参照してください。メッセージキューを使用して最新のアプリケーション用の疎結合マイクロサービスを構築する方法については、当社のブログ投稿 (「Amazon SQS および Amazon SNS による疎結合のスケーラブルな C # アプリケーションの構築」) を参照するとともに、当社の最近のウェビナー (「Amazon SQS and Amazon SNS を使用したアプリケーションの切り離しとスケール」) をご覧ください。

AWS re:Invent に参加される方は、「ARC 330: How the BBC Built a Massive Media Pipeline Using Microservices」というセッションにご出席ください。この話の中で、BBC がどのように SNS と SQS を使って BBC iPlayer アーキテクチャの伸縮性と信頼性を改善したかがわかります。

Jeff;

Getting Ready for AWS re:Invent 2017

AWS re:Invent の開催まで後わずか 40 日となったので、私の同僚と私は、お客様がラスベガスでの時間を有効に活用するためのヒントをいくつかご紹介します。いつもどおり、トレーニングと教育に重点を置き、それ以外の時間にはお楽しみイベントやレクリエーションも用意されています。

場所、場所、場所
re:Invent Campus はラスベガス商業地全体にわたって行われ、MGM Grand、Aria、Mirage、Venetian、Palazzo、Sands Expo ホール、Linq Lot、Encore でイベントが開催されます。各施設では、特定のトピック専用のトラックをホストします。

MGM Grand – ビジネスアプリ、エンタープライズ、セキュリティ、コンプライアンス、アイデンティティ、Windows。

Aria – Big Data & Analytics、Alexa、コンテナ、IoT、人工知能 & 機械学習、サーバーレス。

Mirage – ブートキャンプ、認証 & 認定試験。

Venetian / Palazzo / Sands Expo ホール – アーキテクチャ、AWS Marketplace & Service Catalog、コンピューティング、コンテンツ配信、データベース、DevOps、モバイル、ネットワーキング、ストレージ。

Linq Lot – Alexa ハッカソン、Gameday、ジャムセッション、re:Play パーティー、講演者との交流 & 挨拶。

Encore予約可能な会議会場

複数のトピックにご関心をお持ちの場合は、施設間を往復する re:Invent シャトルバスの活用を計画してください。

数多くのコンテンツ
re:Invent Session Catalog が利用できるようになり、関心のあるセッションの選択を今すぐ行うことができます。

アジェンダには 1100 以上のセッションがあるため、計画は不可欠です。最も人気の高いいくつかの「詳細」セッションは複数回行われ、その他のセッションは他の会場のあふれた部屋にストリーミングされます。当社は多くのデータを分析し、いくつかのシミュレーションを実行して、アクション満載のスケジュールを作成するための複数の機会をお客様に提供するため最善を尽くしています。

お客様のセッションの席をまもなく予約できるようになります (Twitter で@awscloud、またはその両方をフォローして、お知らせをお待ちください)。過去のフィードバックに基づいて、席の予約モデルを微調整しました。今年は、各セッションの席の 75% が予約され、その他の 25% が事前予約なしの参加者用に提供されます。事前予約なしの参加者に対しては、セッション開始の 10 分前から入場を開始します。

ラスベガスは眠ることはありません。お客様もそれに合わせてください! 今年は、深夜のセッション、ワークショップ、チョークトーク、ハンズオンラボにより、夜も忙しくなります。

セッションやコンテンツの詳細については、re:Invent 2017 のコンテンツに備えるための概要ビデオをご覧ください。

お楽しみイベント
1 日のトレーニングや学習を十分に行った後は、パブ巡りre:Play パーティーTatonka チャレンジ (今年は 2 会場)、ハンズオン LEGO アクティビティHarley Ride への参加をご検討ください。また、4K ランスピニングチャレンジフィットネスブートキャンプブルームホール (Amazon の長期にわたる伝統行事) で健康を維持してください。

ベガスでお会いしましょう
いつもどおり、可能な限り多くの AWS ユーザーとブログの読者にお会いできることを楽しみにしています。どうか遠慮なく私を呼び止めて話しかけてください。

Jeff;

AWS JapanがRed Hat Japan CCSP Partner of the Yearを受賞

Partner SAの河原です。10月20日にレッドハット社主催の年次カンファレンス「Red Hat Forum Tokyo 2017」が開催されました。同日に「Red Hat Partner Awards 2017 レセプションパーティー」があり、アマゾン ウェブ サービス ジャパン株式会社は、「CCSP Partner of the Year」を受賞いたしました。本日、レッドハット社より以下のニュースリリースが発行されましたので、授賞式の様子をご紹介します。

レッドハット、「Red Hat Japan Partner Awards 2017」を発表

これは、レッドハット社の認定クラウド&サービスプロバイダー(CCSP)としてクラウド市場の拡大に最も貢献したパートナーに贈られる賞です。レッドハット製品、技術をクラウド上で活用する環境として幅広いお客様層に支持され、継続的に高い売上成長を果たした点を評価いただいています。また、Red Hat Enterprise Linux(RHEL)に限らずRed Hat OpenShift Container PlatformやRed Hat JBoss Middlewareを活用した案件も創出し、ソリューションの拡大にも貢献したことが受賞の理由となっております。

Red Hat Forumでは、「Red Hat on AWS 最新の取り組みご紹介」と題したブレークアウトセッションも行い、AWS上にお客様がお持ちのサブスクリプションを持ち込むことが可能となるRed Hat Cloud Access、AWSと連携したAnsibleおよびOpenShiftによるデプロイメント自動化などをご紹介いたしました。AWS上にAnsible Tower by Red Hatを容易に構築できるAWS Quick Startはこちらから、AWS上にRed Hat OpenShift Container Platformを容易に構築できるAWS Quick Startはこちらをご参照ください。

AWSは、2008年からAmazon EC2インスタンス上でのRHELを提供しており、世界で第一号のRed Hat Premier Certified Cloud Providerに認定され、これまで豊富な実績と高い技術力を積み上げてきました。今後もお客様のご期待に応えてまいります。

東京に5番目のエッジロケーションを開設。アトランタ(A)からチューリッヒ(Z)までAmazon CloudFrontの接続拠点数が100箇所に

アマゾン ウェブ サービス(AWS)が、グローバルなコンテンツデリバリーネットワーク(CDN)のAmazon CloudFrontのリリースしたのは、約9年前の出来事になります。14の接続拠点からなる高性能なエッジネットワークとして始まったこの新しいサービスは、現在、世界中からの数百万ビューアーの接続に対応するまで成長しました。本日、Amazon CloudFrontの成長が最も著しい地域の一つである日本で100番目の接続拠点(89のエッジロケーションと11のリージョナルエッジキャッシュ)を発表できることを嬉しく思います。100番目の接続拠点(POP)は、東京で5番目そして、日本で6番目のエッジロケーションとなります。

「Amazon CloudFrontのグローバル展開におけるこの節目は、お客様のアプリケーションをよりセキュアで高速、かつ信頼性の高いものにしたいと言う私達のこだわりの成果です。」とAWS Edge Services VPのPrasad Kalyanaramanは、語っています。「東京を100番目の接続拠点のロケーションとして発表できることを特に嬉しく思います。新たなロケーションへの展開やLambda@Edge、AWS Shieldなどの革新的な技術の導入などを通して今後も私達のグローバルのお客様にサービスを提供して行くことを楽しみにしています。」

100番目の接続拠点が東京で展開されることについて日本でも特にご利用が大きい数社のお客様から激励のコメントを頂いています:
ソニー・インタラクティブエンタテインメント(SIE)は、PlayStation®のハードウェア及びソフトウェアの製造販売と、PlayStation™Network(PSNSM)などのサービスを手がけている会社です。

SIE、システム/ネットワークエンジニアリング オペレーション部門、課長の田中博規氏は次のように語っています。「このたびはCloudFront100番目のエッジロケーション開設おめでとうございます。CloudFrontは、PlayStation™Networkの安定的な配信と高いパフォーマンスを支える重要なサービスのひとつとなっています。同時に、ゲームコンテンツの高精細化・多機能化・大容量化に伴い、CloudFrontは、弊社のグローバルの利用帯域増に対応できる数少ないCDNサービスの一つです。ユニークで付加価値の高いCDNサービスとしてCloudFrontのさらなる発展を心より期待しています。」

キヤノン株式会社は、カメラ、ビデオカメラなどの精密機器を製造するメーカーです。キヤノン株式会社、映像事務機DS開発センター、主席の八木田 隆氏は次のように語っています。「CloudFrontの100番目のエッジロケーションがTokyoということを感慨深く感じると同時にエッジロケーションが増えていくことはとても喜ばしいことです。Amazon CloudFrontとCloudFrontのAWSサービスとの連携は、キヤノンのクラウドサービスのDynamic ContentsとStatic Contentsの両方の高速な配信に欠かせないものとなっています。ワールドワイドに展開されているCloudFront DistributionをAPIで簡単に制御できるため、我々のサービスの継続的統合と継続的デリバリー(CI/CD)及び自動化に寄与しています。」

三菱電機株式会社は、一般消費者から産業向けまで幅広い製品の製造とサービスを提供している会社です。三菱電機株式会社、インフォメーションシステム統括事業部、部長の岩城新一氏は次のように語っています。  「この度の100番目のエッジロケーション開設大変おめでとうございます。当社では3年前からCloudFrontを活用した大規模動画配信システムによるコンテンツ提供サービスを開始しております。開発当時を振り返りますと、システム設計段階からの手厚いご支援はもとより、システムのカットオーバー前の当社からの突然の負荷テストの依頼など無理なお願いも快く引き受けていただき、人的なサポート面でも大変お世話になったことを思い出します。また、御社の日米のチームがうまく連携していることもとても印象的でした。CloudFrontは立ち上げ初期のチューニング以降は一切問題がなく現在大変安定した配信をしています。Amazon CloudFrontの機能とエッジロケーションも継続して増えているので、日々急激に進化していることを肌で感じています。今後もCloudFrontがどのような進化を遂げていくのか期待をもって見守っていきたいと思っています。」

ディライトワークス株式会社は、ゲームの企画・開発・運営を行っており、その中でも『Fate/Grand Order』は現在、1,000万ダウンロードを突破しています。ディライトワークス株式会社、テクニカル・ディレクターの田村祐樹氏は次のように語っています。「ディライトワークスは、”ただ純粋に、面白いゲームを創ろう。”という開発理念のもとに、ゲームの創作をおこなっております。そこで重要な要素となるのが、より多くのユーザーにより高品質なコンテンツを届けることです。多くのCDNサービスがある中、高い品質、低いコスト、安定した配信と速いインバリデーションからAmazon CloudFrontの利用を決断しました。また、Amazon Route 53、AWS WAFやSSL証明書の自動更新が可能なAWS Certificate Manager(ACM)などの他のAWSサービスとの親和性も高いことにメリットを感じています。今後もCloudFrontとAWSから革新的なサービスに出会えることを期待しています。」

株式会社サイバーエージェントは、メディア事業、広告事業、ゲーム事業とインターネットを軸に様々な事業を展開しています。株式会社サイバーエージェント、メディア統括本部 最高技術責任者の福田一郎氏は、次のように語っています。「CloudFrontの100番目のエッジロケーションという節目が東京で迎えられるということを大変喜ばしく思います。CloudFrontが私達のサービスにとって、より安定・高速にサービス提供をするための一翼を担っていることは間違いありません。これからも、CloudFrontおよびAWSがより一層成長・発展していくことを願っております。」

Amazon CloudFrontの100の接続拠点は、23カ国、50都市と全世界に配置されています。この1年間で37のエッジロケーションを追加しネットワーク帯域を50%以上増設しています。追加された拠点には、新しく4カ国*と9都市が含まれまています: ドイツ、ベルリン;米国、ミネアポリス;チェコ共和国*、プラハ;米国、ボストン;ドイツ、ミュンヘン;オーストリア*、ウィーン;マレーシア*クアラルンプール;米国、フィラデルフィア;スイス*、チューリッヒ。

アマゾンウェブサービスは、ネットワークの拡大に積極的に取り組んでおり、 中東の新しいAWSリージョン開設の予定を発表できたことも嬉しく思います。その取組みに先立って2018年の第1四半期にアラブ首長国連邦に最初のエッジロケーションを解説します。

私達は、常に世界中のお客様により良いサービスを提供する方法を考えています。2016年のre:Inventカンファレンスでは、リージョナルエッジキャッシュという新しいキャッシュ階層の発表で11の接続拠点をネットワークに追加しました。これらの接続拠点は従来のエッジロケーションと比べ大きいキャッシュ容量がありエッジロケーションとお客様のオリジンサーバの間に配置されます。この配置によりビューアーにより近いところでお客様のコンテンツをより長い間キャッシュに残すことができるため、お客様のオリジンサーバの負荷を下げ、ファイルの取得を早くします。

私達は、CDNの評価は、世界にあるロケーションの数だけで決まらないないことも理解しています。Amazon CloudFrontの広大なネットワークに加え、ビジネス要件を満たすために必要な機能やパフォーマンスを満たせるように常にお客様の声に耳を傾けています。セキュリティは、私達にとって最大の優先事項であり、つい最近ではセキュリティポリシー機能のリリースとHIPAA対応を発表できたことを嬉しく思います。また数ヶ月前には、お客様がエンドユーザにより近い所でLambda関数が実行できるLambda@Edgeの一般提供をはじめました。また、開発者の利便性と使い勝手を良くするために、グローバルのキャッシュのインバリデーションと設定変更の伝搬にかかる時間を改善しました。CDNサービスによって、 インバリデーションや設定変更のパフォーマンスの定義が異なる場合があります。CloudFrontの場合、数ミリ秒でインバリデーションのリクエストを受け付け、殆どの場合60秒以内に「全世界のすべてのサーバーでキャッシュをクリア」したことを確認します。

 

話題性の高いロケーションでの拠点や新機能の追加以上に、私達は、世界中の様々な規模のお客様と共に協力できることを光栄に感じています。個人のブロガーや中小企業のオーナーから世界有数の大企業まで、私達にとって全てのお客様が重要であることお伝えすると同時に私達のグローバルなネットワークに加わっていただいていることを深く御礼申し上げます。

·         Amazon CloudFrontチームより

Amazon CloudFrontのご利用についてより詳しい情報をご希望の場合、こちらのWebページから最新のウェビナーの開催情報や資料を入手いただけます。

オンプレミスの利用者がAmazon Route 53経由でSUSE HAEで保護されたSAP HANAインスタンスに接続する方法

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

このブログ記事では、AWSクラウド上のSUSE Linux Enterprise High Availability Extension(SLES HAE)によって保護されているSAP HANAデータベースに、オンプレミスの利用者が接続できるようになる、Amazon Route 53エージェントについて説明します。このエージェントは、Amazon Route 53を介して利用者を振り分ける機能を提供します。

このエージェントを利用するには、SAP Note 2309342 – SUSE Linux Enterprise High Availability Extension on AWS for SAP HANAに記載されているような、オーバーレイIPアドレスエージェントを使用して実装された高可用性フェイルオーバー用のSLES HAEの設定が必要です。(SAPノートを参照するにはSAP Support Portalの認証情報が必要です)

Route 53エージェントは、SAP HANAデータベースを保護するクラスタリソース管理フレームワークであるPacemakerを含むSLES HAEの機能を拡張します。このエージェントとオーバーレイIPアドレスエージェントを組み合せた利用方法は、SAPセントラルインスタンス(CI)を含む、AWSクラウド上のSLESでサポートされるすべての構成のSLES HAEに対して適用できます。

Route 53エージェントは、現時点では未サポートのオープンソースツールとして利用可能となっており、ソースコードはこのブログ記事の中で公開します。現在、AWSとSUSEが協力し、サポート済みツールとして本家リポジトリから利用できるように調整しています。お客様のAWSアカウントでSAP HANAを構築した後、このエージェントをインストールできます。

Route 53エージェントの仕組み

現在のオーバーレイIPアドレスエージェントでは、仮想プライベートクラウド(VPC)内のアプリケーションサーバーは、そのVPC内の保護されたSAP HANAサーバーに接続できますが、オンプレミスのアプリケーションからの接続はできません。

そのため、RDPや踏み台サーバーを経由したVPC内で管理されたSAP HANA Studioなどのアプリケーションが必要となり、オンプレミスの利用者にはいくつかの不便が生じます。Route 53エージェントは、名前ベースのアプローチを使用してオンプレミスの利用者がVPCに接続できるようにすることで、この制限を回避します。2つのエージェントは並行して動作します。オーバーレイIPエージェントは、オーバーレイIPアドレスからアクティブなノードにトラフィックをルーティングします。Route 53エージェントは、SAP HANAサーバーの名前と紐づく現在のIPアドレスを更新します。

私は、ウェブサイトScaling Bitsに、DNS Name Failover for Highly Available AWS Servicesという記事で、このエージェントの内部動作を掲載しました。この記事では、Route 53のホストゾーンの更新方法について説明しています。

Route 53エージェントは、SAPから独立しています。また、SLES HAEのSAP NetWeaverセントラルインスタンス(CI)コンポーネントとも連動します。

前提条件

この記事では、SLES Pacemaker クラスタを含む、オーバーレイIPアドレスエージェントを既にインストールしていることを前提としています。さらに、Route 53エージェントには以下が必要です。

  • SLES HAE クラスタインスタンスがRoute 53レコードを更新するためのポリシー
  • rootユーザー用のAWSプロファイル
  • Route 53のプライベートホストゾーン

ポリシーの追加

以下のポリシーをSLES HAE クラスタインスタンスに追加して、Route 53のAレコードを更新できるようにします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1471878724000",
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:GetChange",
                "route53:ListResourceRecordSets",
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

rootユーザ用のAWSプロファイルの作成

エージェントは、AWSプロファイルを使用してAWS CLIコマンドを呼び出し、そしてオーバーレイIPエージェントでも同じプロファイルを使用します。ウェブサイトScaling Bitsで説明しているように、プロキシ設定が必要な場合もあります。

任意のプロファイル名を選択できます。エージェントはデフォルトの名前としてclusterを使用するため、必要に応じてリファレンスを修正する必要があります。

Route 53のプライベートホストゾーンの作成

エージェントは、Route 53 ホストゾーンのAレコードを更新します。つまり、お客様のAWSアカウント内に要求されるインフラストラクチャが必要です。プライベートホストゾーンの作成方法については、AWSドキュメントを参照してください。

以下の値が必要です。(ここでは値の例を示しています)

  • hostedzoneidZ22XDORCGO4P3T
  • fullnamesuse-service.awslab.cloud.mylab.corp. (最後のドットは重要です!)

エージェントのインストール

このブログ記事の最後に掲載しているソースコードをテキストファイルにコピーし、ディレクトリ/usr/lib/ocf/resource.d/aws 配下に置きます。このソースコードは、MITライセンスのもとで利用できます。

クラスタの設定

Pacemakerで、以下のようにクラスタの構成を編集(crm configure editコマンド)します。

primitive res_AWS_ROUTE53 ocf:aws:aws-vpc-route53 \
   params hostedzoneid=Z22XDORCGO4P3T ttl=10 fullname=suse-service5.awslab.cloud.mylab.corp. profile=cluster \
   op start interval=0 timeout=180 \
   op stop interval=0 timeout=180 \
   op monitor interval=300 timeout=180 \
   meta target-role=Started

以下の必須パラメータを適切な値に置き換えてください。

  • hostedzoneid: Route 53のホストゾーンID。これは、Route 53のレコードセットです
  • ttl: Route 53のAレコードの秒単位の有効期限(TTL)。(合理的なデフォルト値は10です)
  • fullname: IPアドレスをホストするサービスのフルネーム。例えば、suse-service.awslab.cloud.mylab.corp.(最後のドットは重要です!)
  • profile: rootアカウントのAWS CLIプロファイルの名前。/root/.aws/configファイルには、以下のようなエントリが必要です
    • [profile cluster] – clusterの場所にお客様のプロファイル名
    • region = us-east-1 (お客様が利用するAWSリージョン)
    • output = text (この設定も必要)

AWS固有の制約に関する設定

Route 53エージェントは、SAP HANAデータベースと同じノードで動作する必要があります。この制約により、必然的に同じノードに置かなければなりません。

以下の内容のaws-route53-constraint.txtというファイルを作成します。前述と同じリソース識別子を使用していることを確認してください。

colocation col_Route53 2000: res_AWS_ROUTE53:Started msl_SAPHana_SID_HDB00:Master
order ord_SAPHana 2000: cln_SAPHanaTopology_SID_HDB00 msl_SAPHana_SID_HDB00

この例では、SAP SIDがリソース名の一部としてコード化されています。この値は構成によって異なります。

このファイルを設定に追加するために、スーパーユーザーとして次のコマンドを実行します。ファイル名はaws-route53-constraint.txtです。

crm configure load update aws-route53-constraint.txt

まとめ

Route 53エージェントは、クラスタリソース管理フレームワークであるPacemakerとともに使用され、SAP HANAデータベースを保護するSLES HAEの機能を拡張します。また、アクティブなABAP SAPセントラルサービス(ASCS)サーバーを検出し、Route 53を介して利用者を振り分けることで、SAPセントラルインスタンスを保護することもできます。

エージェントは、SLES HAE SAPエージェントの依存エージェントとして実行されます。つまり、個々の管理を必要とはしません。

SLES HAEシステムにオンプレミスからの接続が必要な場合は、このエージェントをインストールすることをお勧めします。また、ご質問やご意見がある場合はお気軽にお問合せください。

Route 53エージェントのソースコード

#!/bin/bash
#
#   Copyright 2017 Amazon.com, Inc. and its affiliates. All Rights Reserved.
#   Licensed under the MIT License.
#
#  Copyright 2017 Amazon.com, Inc. and its affiliates

# Permission is hereby granted, free of charge, to any person obtaining a copy of
# this software and associated documentation files (the "Software"), to deal in
# the Software without restriction, including without limitation the rights to
# use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
# of the Software, and to permit persons to whom the Software is furnished to do
# so, subject to the following conditions:

# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
# OTHER DEALINGS IN THE SOFTWARE.

#
#
#
# OCF resource agent to move an IP address within a VPC in the AWS
# Written by Stefan Schneider , Martin Tegmeier (AWS)
# Based on code of Markus Guertler#
#
#
# OCF resource agent to move an IP address within a VPC in the AWS
# Written by Stefan Schneider (AWS) , Martin Tegmeier (AWS)
# Based on code of Markus Guertler (SUSE)
#
# Mar. 15, 2017, vers 1.0.2

#######################################################################
# Initialization:

: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs

OCF_RESKEY_ttl_default=10

: ${OCF_RESKEY_ttl:=${OCF_RESKEY_ttl_default}}

#######################################################################

usage() {
	cat <<-EOT
	usage: $0 {start|stop|status|monitor|validate-all|meta-data}
	EOT
}

metadata() {
cat <<END
<?xml version="1.0"?>
<!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="aws-vpc-route53">
<version>1.0</version>
<longdesc lang="en">
Update Route53 record of Amazon Webservices EC2 by updating an entry in a
hosted zone ID table.

AWS instances will require policies which allow them to update Route53 ARecords:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1471878724000",
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:GetChange",
                "route53:ListResourceRecordSets",
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Example Cluster Configuration:

Use a configuration in "crm configure edit" which looks as follows. Replace
hostedzoneid, fullname and profile with the appropriate values:

primitive res_route53 ocf:heartbeat:aws-vpc-route53 \
        params hostedzoneid=Z22XDORCGO4P3T fullname=suse-service5.awslab.cloud.sap.corp. profile=cluster \
        op start interval=0 timeout=180 \
        op stop interval=0 timeout=180 \
        op monitor interval=300 timeout=180 \
        meta target-role=Started
</longdesc>
<shortdesc lang="en">Update Route53 VPC record for AWS EC2</shortdesc>
<parameters>
<parameter name="hostedzoneid" required="1">
<longdesc lang="en">
Hosted zone ID of Route 53. This is the table of
the Route 53 record.
</longdesc>
<shortdesc lang="en">AWS hosted zone ID</shortdesc>
<content type="string" default="" />
</parameter>
<parameter name="fullname" required="1">
<longdesc lang="en">
The full name of the service which will host the IP address.
Example: suse-service5.awslab.cloud.sap.corp.
Note: The trailing dot is important to Route53!
</longdesc>
<shortdesc lang="en">Full service name</shortdesc>
<content type="string" default="" />
</parameter>
<parameter name="ttl" required="0">
<longdesc lang="en">
Time to live for Route53 ARECORD
</longdesc>
<shortdesc lang="en">ARECORD TTL</shortdesc>
<content type="string" default="${OCF_RESKEY_ttl_default}" />
</parameter>
<parameter name="profile" required="1">
<longdesc lang="en">
The name of the AWS CLI profile of the root account. This
profile will have to use the "text" format for CLI output.
The file /root/.aws/config should have an entry which looks
like:

  [profile cluster]
	region = us-east-1
	output = text

"cluster" is the name which has to be used in the cluster
configuration. The region has to be the current one. The
output has to be "text".
</longdesc>
<shortdesc lang="en">AWS Profile Name</shortdesc>
<content type="string" default="" />
</parameter>
</parameters>
<actions>
<action name="start" timeout="180" />
<action name="stop" timeout="180" />
<action name="monitor" depth="0" timeout="180" interval="300" />
<action name="validate-all" timeout="5" />
<action name="meta-data" timeout="5" />
</actions>
</resource-agent>
END
}

debugger() {
	ocf_log debug "DEBUG: $1"
}

ec2ip_validate() {
	debugger "function: validate"

	# Full name
	[[ -z "$OCF_RESKEY_fullname" ]] && ocf_log error "Full name parameter not set $OCF_RESKEY_fullname!" && exit $OCF_ERR_CONFIGURED

	# Hosted Zone ID
	[[ -z "$OCF_RESKEY_hostedzoneid" ]] && ocf_log error "Hosted Zone ID parameter not set $OCF_RESKEY_hostedzoneid!" && exit $OCF_ERR_CONFIGURED

	# profile
	[[ -z "$OCF_RESKEY_profile" ]] && ocf_log error "AWS CLI profile not set $OCF_RESKEY_profile!" && exit $OCF_ERR_CONFIGURED

	# TTL
	[[ -z "$OCF_RESKEY_ttl" ]] && ocf_log error "TTL not set $OCF_RESKEY_ttl!" && exit $OCF_ERR_CONFIGURED

	debugger "Testing aws command"
	aws --version 2>&1
	if [ "$?" -gt 0 ]; then
		error "Error while executing aws command as user root! Please check if AWS CLI tools (Python flavor) are properly installed and configured." && exit $OCF_ERR_INSTALLED
	fi
	debugger "ok"

	if [ -n "$OCF_RESKEY_profile" ]; then
		AWS_PROFILE_OPT="--profile $OCF_RESKEY_profile"
	else
		AWS_PROFILE_OPT="--profile default"
	fi

	return $OCF_SUCCESS
}

ec2ip_monitor() {
	ec2ip_validate
	debugger "function: ec2ip_monitor: check Route53 record "
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	ARECORD="$(aws $AWS_PROFILE_OPT route53 list-resource-record-sets --hosted-zone-id $OCF_RESKEY_hostedzoneid --query "ResourceRecordSets[?Name=='$OCF_RESKEY_fullname']" | grep RESOURCERECORDS | /usr/bin/awk '{ print $2 }' )"
	debugger "function: ec2ip_monitor: found IP address: $ARECORD ."
	if [ "${ARECORD}" == "${IPADDRESS}" ]; then
		debugger "function: ec2ip_monitor:  ARECORD $ARECORD found"
		return $OCF_SUCCESS
	else
		debugger "function: ec2ip_monitor: no ARECORD found"
		return $OCF_NOT_RUNNING
	fi

	return $OCF_SUCCESS
}

ec2ip_stop() {
	ocf_log info "EC2: Bringing down Route53 agent. (Will remove ARECORD)"
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	ARECORD="$(aws $AWS_PROFILE_OPT route53 list-resource-record-sets --hosted-zone-id $OCF_RESKEY_hostedzoneid --query "ResourceRecordSets[?Name=='$OCF_RESKEY_fullname']" | grep RESOURCERECORDS | /usr/bin/awk '{ print $2 }' )"
	debugger "function: ec2ip_monitor: found IP address: $ARECORD ."
	if [ ${ARECORD} != ${IPADDRESS} ]; then
		debugger "function: ec2ip_monitor: no ARECORD found"
		return $OCF_SUCCESS
	else
		debugger "function: ec2ip_monitor:	ARECORD $ARECORD found"
		# determine IP address
		IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
		# Patch file
		debugger "function ec2ip_stop: will delete IP address to ${IPADDRESS}"
		ocf_log info "EC2: Updating Route53 $OCF_RESKEY_hostedzoneid with $IPADDRESS for $OCF_RESKEY_fullname"
		ROUTE53RECORD="/var/tmp/route53-${OCF_RESKEY_hostedzoneid}-${IPADDRESS}.json"
		echo "{ " > ${ROUTE53RECORD}
		echo "	  \"Comment\": \"Update record to reflect new IP address for a system \", " >>	${ROUTE53RECORD}
		echo "	  \"Changes\": [ " >>  ${ROUTE53RECORD}
		echo "		  { " >>  ${ROUTE53RECORD}
		echo "			  \"Action\": \"DELETE\", " >>	${ROUTE53RECORD}
		echo "			  \"ResourceRecordSet\": { " >>	 ${ROUTE53RECORD}
		echo "				  \"Name\": \"${OCF_RESKEY_fullname}\", " >>  ${ROUTE53RECORD}
		echo "				  \"Type\": \"A\", " >>	 ${ROUTE53RECORD}
		echo "				  \"TTL\": ${OCF_RESKEY_ttl}, " >>	${ROUTE53RECORD}
		echo "				  \"ResourceRecords\": [ " >>  ${ROUTE53RECORD}
		echo "					  { " >>  ${ROUTE53RECORD}
		echo "						  \"Value\": \"${IPADDRESS}\" " >>	${ROUTE53RECORD}
		echo "					  } " >>  ${ROUTE53RECORD}
		echo "				  ] " >>  ${ROUTE53RECORD}
		echo "			  } " >>  ${ROUTE53RECORD}
		echo "		  } " >>  ${ROUTE53RECORD}
		echo "	  ] " >>  ${ROUTE53RECORD}
		echo "}" >> ${ROUTE53RECORD}
		cmd="aws --profile ${OCF_RESKEY_profile} route53 change-resource-record-sets --hosted-zone-id ${OCF_RESKEY_hostedzoneid} \
		  --change-batch file://${ROUTE53RECORD} "
		debugger "function ec2ip_start: executing command: $cmd"
		CHANGEID=$($cmd | grep CHANGEINFO |	 /usr/bin/awk -F'\t' '{ print $3 }' )
		debugger "Change id: ${CHANGEID}"
		rm ${ROUTE53RECORD}
		CHANGEID=$(echo $CHANGEID |cut -d'/' -f 3 |cut -d'"' -f 1 )
		debugger "Change id: ${CHANGEID}"
		STATUS="PENDING"
		MYSECONDS=2
		while [ "$STATUS" = 'PENDING' ]; do
			sleep	${MYSECONDS}
			STATUS="$(aws --profile ${OCF_RESKEY_profile} route53 get-change --id $CHANGEID | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $4 }' |cut -d'"' -f 2 )"
			debugger "Waited for ${MYSECONDS} seconds and checked execution of Route 53 update status: ${STATUS} "
		done

		return $OCF_SUCCESS
	fi

	return $OCF_SUCCESS
}

ec2ip_start() {
	# determine IP address
	IPADDRESS="$(ec2metadata aws ip | grep local-ipv4 | /usr/bin/awk '{ print $2 }')"
	# Patch file
	debugger "function ec2ip_start: will update IP address to ${IPADDRESS}"
	ocf_log info "EC2: Updating Route53 $OCF_RESKEY_hostedzoneid with $IPADDRESS for $OCF_RESKEY_fullname"
	ROUTE53RECORD="/var/tmp/route53-${OCF_RESKEY_hostedzoneid}-${IPADDRESS}.json"
	echo "{ " > ${ROUTE53RECORD}
	echo "    \"Comment\": \"Update record to reflect new IP address for a system \", " >>  ${ROUTE53RECORD}
	echo "    \"Changes\": [ " >>  ${ROUTE53RECORD}
	echo "        { " >>  ${ROUTE53RECORD}
	echo "            \"Action\": \"UPSERT\", " >>  ${ROUTE53RECORD}
	echo "            \"ResourceRecordSet\": { " >>  ${ROUTE53RECORD}
	echo "                \"Name\": \"${OCF_RESKEY_fullname}\", " >>  ${ROUTE53RECORD}
	echo "                \"Type\": \"A\", " >>  ${ROUTE53RECORD}
	echo "                \"TTL\": ${OCF_RESKEY_ttl} , " >>  ${ROUTE53RECORD}
	echo "                \"ResourceRecords\": [ " >>  ${ROUTE53RECORD}
	echo "                    { " >>  ${ROUTE53RECORD}
	echo "                        \"Value\": \"${IPADDRESS}\" " >>  ${ROUTE53RECORD}
	echo "                    } " >>  ${ROUTE53RECORD}
	echo "                ] " >>  ${ROUTE53RECORD}
	echo "            } " >>  ${ROUTE53RECORD}
	echo "        } " >>  ${ROUTE53RECORD}
	echo "    ] " >>  ${ROUTE53RECORD}
	echo "}" >> ${ROUTE53RECORD}
	cmd="aws --profile ${OCF_RESKEY_profile} route53 change-resource-record-sets --hosted-zone-id ${OCF_RESKEY_hostedzoneid} \
	  --change-batch file://${ROUTE53RECORD} "
	debugger "function ec2ip_start: executing command: $cmd"
	CHANGEID=$($cmd | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $3 }' )
	debugger "Change id: ${CHANGEID}"
	rm ${ROUTE53RECORD}
	CHANGEID=$(echo $CHANGEID |cut -d'/' -f 3 |cut -d'"' -f 1 )
	debugger "Change id: ${CHANGEID}"
	STATUS="PENDING"
	MYSECONDS=2
	while [ "$STATUS" = 'PENDING' ]; do
		sleep  ${MYSECONDS}
		STATUS="$(aws --profile ${OCF_RESKEY_profile} route53 get-change --id $CHANGEID | grep CHANGEINFO |  /usr/bin/awk -F'\t' '{ print $4 }' |cut -d'"' -f 2 )"
		debugger "Waited for ${MYSECONDS} seconds and checked execution of Route 53 update status: ${STATUS} "
	done

	return $OCF_SUCCESS
}

###############################################################################

case $__OCF_ACTION in
	usage|help)
		usage
		exit $OCF_SUCCESS
		;;
	meta-data)
		metadata
		exit $OCF_SUCCESS
		;;
	monitor)
		ec2ip_monitor
		;;
	stop)
		ec2ip_stop
		;;
	validate-all)
		ec2ip_validate
		;;
	start)
		ec2ip_start
		;;
	*)
		usage
		exit $OCF_ERR_UNIMPLEMENTED
		;;
esac

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

AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築する

データレイクは、大量の様々なデータを扱うという課題に対処するため、データを分析および保存するための方法としてますます一般的になっています。データレイクを使うと、組織は全ての構造化データおよび非構造化データを1つの中央リポジトリに格納できます。データはそのまま保存できるため、あらかじめ定義されたスキーマに変換する必要はありません。

多くの組織は AWS をデータレイクとして使う価値を理解しています。例えば Amazon S3 は高い耐久性があり、コンピューティングとストレージの分離をしながら、オープンデータフォーマットをサポートする費用対効果の高いオブジェクトの開始ができ、全てのAWS 分析サービスと連携します。Amazon S3 はデータレイクの基礎を提供しますが、他のサービスを追加してビジネスニーズに合わせることができます。AWS のデータレイク構築の詳細については What is a Data Lake? を参照してください。

データレイクを使う主な課題は、データの検索とスキーマやデータフォーマットの理解であるため、Amazonは AWS Glue をリリースしました。AWS Glue は Amazon S3 データレイクからデータ構造と形式を発見することで、迅速にビジネスの洞察を導き出すために要する時間と労力を大幅に削減します。AWS Glue は Amazon S3 上のデータを自動的にクロールし、データフォーマットを特定し、他の AWS 分析サービスで使用するためのスキーマを提案します。

この記事では、AWS Glue を使って Amazon S3 上のデータをクロールする方法と他のAWSサービスで使用できるメタデータストアを構築するプロセスを説明します。

AWS Glue の特徴

AWS Glue はフルマネージドのデータカタログとETL(抽出、変換、ロード)サービスで、データの発見、変換、およびジョブスケジューリングなどの困難で時間のかかる作業を簡素化し自動化します。AWS Glue はデータソースをクロールし、CSV, Apache Parquet, JSON などの一般的なデータフォーマットとデータタイプ用に事前作成された Classifire を使用してデータカタログを構築します。

AWS Glue はモダンなデータアークテクチャーのコンポーネントである S3, Amazon RDSAmazon AthenaAmazon RedshiftAmazon Redshift Spectrum と統合されているため、データの移動と管理をシームレスに調整します。

AWS Glue データカタログは Apache Hive メタストアと互換性があり、Hive, Presto, Apache Spark, Apache Pig などの一般的なツールをサポートしています。 Amazon Athena, Amazon EMR, Amazon Redshift Spectrum とも直接統合されています。

さらに AWS Glue データカタログには、使いやすさとデータ管理のための以下の機能があります。

  • 検索でデータを発見する
  • 分類されたファイルの識別と解析
  • スキーマの変更をバージョン管理

詳細は AWS Glue 製品の詳細 を参照してください。

Amazon S3 データレイク

AWS Glue は S3 データレイクの必須コンポーネントで、モダンなデータ分析にデータカタログとデータ変換サービスを提供します。

 

 

上の図では様々な分析ユースケースに対してデータがステージングされています。最初にデータは生の形式で不変のコピーとして取り込まれます。次にデータは変換され各ユースケースに対してより価値あるものになります。この例では、生の CSV ファイルは Amazon Athena がパフォーマンスを向上しコストを削減するために使用する Apache Parquet に変換されています。

データはさらなる洞察を得るために他のデータセットとブレンドすることができます。AWS Glue クローラは、ジョブトリガーまたは事前定義されたスケジュールに基いてデータベースの各ステージごとにテーブルを作成します。この例では、S3 に新しいファイルが追加されるたびに AWS Lambda 関数を使って ETL プロセスを実行しています。このテーブルは、Amazon Athena, Amazon Redshift Spectrum, および Amazon EMR が標準 SQL または Apache Hive を使用して任意の段階でデータを照会するために使用できます。この構成は、さまざまなデータからビジネス価値を迅速かつ容易に導き出すためのアジャイルビジネスインテリジェンスを提供する一般的な設計パターンです。

チュートリアル

このチュートリアルでは、データベースを定義し、Amazon S3 バケットのデータを探索するクローラを設定し、テーブルを作成し、CSV ファイルを Parquet に変換し、Parquet データのテーブルを作成し、Amazon Athena でデータを照会します。

データを発見する

AWS マネージメントコンソールにサインインし AWS Glue コンソールを開きます。AWS Glue は分析のセクションにあります。対応リージョンは米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)で今後も対応リージョンは頻繁に追加していきます。

データの発見の第一歩はデータベースを追加することです。データベースはテーブルの集まりです。

  1. コンソールで Add database を選択し、Database name nycitytaxi と入力し Create をクリックします。
  2. 左側のメニューの Tables をクリックし、テーブルは列の名前、データ型の定義、およびその他のデータセットに関するメタデータで構成されています。
  3. データベース nycitytaxi にテーブルを追加します。手動またはクローラを使ってテーブルを追加できます。 クローラは、データストアに接続し、順位付けされた Classifier を使用してデータのスキーマを決定するプログラムです。 AWS Glue はCSV, JSON, Avro などの一般的なファイルタイプの Classifier を提供します。grok パターンを使用してカスタム Classifier を作成することもできます。
  4. クローラを追加します。Data store に S3 、Include path に s3://aws-bigdata-blog/artifacts/glue-data-lake/data/ を選びます。この S3 バケットには2017年1月のグリーンタクシーの全ての乗車データがあります。
  5. Next をクリックします。
  6. IAM role でドロップダウンから AWSGlueServiceRoleDefault を選択します。
  7. Frequency   Run on demand を選択します。クローラはオンデマンド実行やスケジュール実行が可能です。
  8. Database は nycitytaxi を選んでください。スキーマの変更をAWS Glueがどのように処理するのかを理解することが重要で、適切な処理方法を選択することが可能です。この例ではいかなる更新でも(データカタログ上)のテーブルが更新されます。 スキーマ変更の詳細については  Cataloging Tables with a Crawler を参照ください。
  9. 手順を確認して、Finish をクリックし、クローラは実行準備ができているので Run it now を選択します。
  10. クローラが終了すると、テーブルが1つ追加されます。
  11. 左側のメニューの Tables をクリックし data を選択します。この画面ではテーブルのスキーマ、プロパティ、およびその他の重要な情報を説明します。

データを CSV 形式から Parquet 形式に変換する

これでデータを CSV から Parquet に変換するジョブを設定して実行することができます。Parquet は Amazon Athena や Amazon Redshift Spectrum などの AWS 分析サービスに適したカラムナフォーマットです。

  1. 左側のメニューの ETL の下の Jobs をクリックし、Add job をクリックします。
  2. Name に nytaxi-csv-parquet を入力します
  3. IAM role AWSGlueServiceRoleDefault を選択します
  4. This job runs  A proposed script generated by AWS Glue を選択します。
  5. スクリプトを保存する任意の S3 パスを入力します。
  6. 一時ディレクトリ用のS3パスを入力します。
  7. Next をクリックします。
  8. データソースとして data を選択します。
  9. Create tables in your data target にチェックを入れる。
  10. Formatで Parquet を選択します。
  11. 結果を保存する新しい場所(既存オブジェクトがない新しいプレフィックス場所)を選択します。
  12. スキーマのマッピングを確認し、Finish をクリックします。
  13. ジョブを表示します。この画面では完全なジョブの表示を提供し、ジョブを編集、保存、実行することができます。AWS Glue がこのスクリプトを作成しましたが、必要に応じて自分で作成することもできます。
  14. Save をクリックし、Run job をクリックします。

Parquet テーブルとクローラを追加する

ジョブ終了したら、クローラを使って Parquet データ用の新しいテーブルを追加します。

  1. Crawler namenytaxiparquet を入力します。
  2. Data store で S3 を選択します。
  3. Include path で ETL で選択したS3パスを入力します。
  4. IAM roleAWSGlueServiceRoleDefault を選択します。
  5. FrequencyRun on demand を選択します。
  6. Databasenycitytaxi を選択します。

 

クローラが終了した後、nycitytaxi データベースには、CSVデータ用テーブルと変換された Parquet データ用テーブルの2つのテーブルがあります。

Amazon Athena でデータ分析する

Amazon Athena は、標準 SQL を使って Amazon S3 のデータを簡単に分析できるインタラクティブなクエリサービスです。Athena は CSVデータを照会することができますが Parquet のファイルフォーマットにするとデータクエリの時間を大幅に削減できます。詳細については Analyzing Data in Amazon S3 using Amazon Athena を参照してください。

Amazon Athena で AWS Glue を使用するには、Athena データカタログを AWS Glue Data Catalog にアップグレードする必要があります。Athena データカタログのアップグレード詳細については、この step-by-step guide を参照してください。

  1. マネージメントコンソール で Athena を開きます。 クエリエディタのデータベース nycitytaxi に2つテーブルが表示されています。

標準SQLを使ってクエリできます。

  1. nytaxigreenparquet を選択します。
  2. Select * From “nycitytaxi”.”data” limit 10; を入力します。
  3. Run Query をクリックします。

 

まとめ

この記事は AWS Glue と Amazon S3 を使ってデータレイクの基礎を構築することがどれほど簡単かを示しています。 AWS Glue を使って S3のデータをクロールし、Apache Hive と互換性のあるメタストアを構築することで、AWS のアナリティクスサービスと一般的な Hadoop エコシステムでこのメタデータを使うことができます。この組み合わせは強力で使いやすいため、より早くビジネスの洞察を得ることができます。

追加情報

詳細については次のブログを参照してください。

 

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

Amazon Kinesis Firehose, Amazon Athena, Amazon QuickSightを用いたVPCフローログの分析

多くの業務や運用において、頻繁に更新される大規模なデータを分析することが求められるようになっています。例えばログ分析においては、振る舞いのパターンを認識したり、アプリケーションのフロー分析をしたり、障害調査をしたりするために大量のログの可視化が必要とされます。

VPCフローログAmazon VPCサービス内のVPCに属するネットワークインターフェースを行き来するIPトラフィック情報をキャプチャします。このログはVPC内部に潜む脅威やリスクを認識したり、ネットワークのトラフィック・パターンを調査するのに役立ちます。フローログはAmazon CloudWatchログに格納されます。いったんフローログを作成すれば、Amazon CloudWatchログを用いて見たり取り出したりすることができるようになります。

フローログは様々な業務を助けてくれます。例えば、セキュリティグループのルールを過度に厳しくしすぎたことによって特定のトラフィックがインスタンスに届かない事象の原因調査などです。また、フローログを、インスタンスへのトラフィックをモニタリングするためのセキュリティツールとして使うこともできます。

この記事はAmazon Kinesis FirehoseAWS LambdaAmazon S3Amazon Athena、そしてAmazon QuickSightを用いてフローログを収集し、格納し、クエリを実行して可視化するサーバーレス・アーキテクチャを構成する手順を示します。構成する中で、Athenaにおいてクエリにかかるコストや応答時間を低減させるための圧縮やパーティショニング手法に関するベストプラクティスを学ぶこともできることでしょう。

ソリューションのサマリ

本記事は、3つのパートに分かれています。

  • Athenaによる分析のためにVPCフローログをS3へ格納。このセクションではまずフローログをLambdaとFirehoseを用いてS3に格納する方法と、格納されたデータにクエリを発行するためAthena上のテーブルを作成する方法を説明します。
  • QuickSightを用いてログを可視化。ここではQuickSightとQuickSightのAthenaコネクタを用いて分析し、その結果をダッシュボードを通じて共有する方法を説明します。
  • クエリのパフォーマンス向上とコスト削減を目的とした、Athenaにおけるデータのパーティション化。このセクションではLambda関数を用いてS3に格納されたAthena用のデータを自動的にパーティション化する方法を示します。この関数はFirehoseストリームに限らず、他の手段でS3上に年/月/日/時間のプリフィックスで格納されている場合でも使用できます。

パーティショニングはAthenaにおいてクエリのパフォーマンス向上とコスト削減を実現するための3つの戦略のうちの1つです。他の2つの戦略としては、1つはデータの圧縮、そしてもう1つはApache Parquetなどの列指向フォーマットへの変換があります。本記事では自動的にデータを圧縮する方法には触れますが、列指向フォーマットへの変換については触れません。本ケースのように列指向フォーマットへの変換を行わない場合でも、圧縮やパーティショニングは常に価値のある方法です。さらに大きなスケールでのソリューションのためには、Parquetへの変換も検討して下さい。

VPCフローログを分析するためのサーバレスアーキテクチャ

以下の図はそれぞれのサービスがどのように連携するかを示しています。

VPC_Flowlogs_Ian_Ben

VPCにフローログを作成すると、ログデータはCloudWatchログのロググループとして発行されます。CloudWatchログのサブスクリプションを利用することにより、S3に書き込むためにFirehoseを用いたLambda関数に対して、リアルタイムにログデータイベントを送り込むことが可能になります。

 

いったんS3にログデータが格納され始めれば、Athenaを利用してSQLクエリをアドホックに投入することができます。ダッシュボードを構築したり、画面からインタラクティブにデータを分析したりすることを好む場合には、Athenaに加えQuickSightによるリッチな可視化を簡単に構成できます。

Athenaの分析を目的としたS3へのVPCフローログの送信

この章では、Athenaによるクエリを可能とするためにフローログデータをS3に送信する方法を説明します。この例ではus-east-1リージョンを使用していますが、AthenaとFirehoseが利用できるのであればどのリージョンでも可能です。

Firehoseデリバリーストリームの作成

既存もしくは新しいS3バケットを格納先とするFirehoseデリバリーストリームを作成するためには、この手順を参考にして下さい。ほとんどの設定はデフォルトで問題ありませんが、格納先のS3バケットへの書き込み権限を持つIAMロールを選択し、GZIP圧縮を指定して下さい。デリバリーストリームの名前は‘VPCFlowLogsDefaultToS3’とします。

VPCフローログの作成

まず、この手順に従ってデフォルトVPCのVPCフローログを有効にしましょう。(訳注:デフォルトVPC以外の任意のVPCで構いません。)

Firehoseに書き込むLambda用のIAMロールの作成

Firehoseに書き込むLambda関数を作成する前に、Firehoseにバッチ書き込みを許可するLambda用のIAMロールを作成する必要があります。次のように定義されるインラインアクセスポリシーを組み込んだ‘lambda_kinesis_exec_role’という名前のLambda用ロールを作成して下さい。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "firehose:PutRecordBatch"
            ],
            "Resource": [
                "arn:aws:firehose:*:*:deliverystream/VPCFlowLogsDefaultToS3"
            ]
        }
    ]
}

 

CloudWatchログからFirehoseに配信するLambda関数の作成

ログイベントをCloudWatchから先に作成したFirehoseデリバリーストリームである‘VPCFlowLogsDefaultToS3’に配信するためのLamdba関数を作成するには、次の手順を実施します。

  1. Lambdaのコンソールから一から作成を選択して新しいLambda関数を作成します。
  2. 基本的な情報ページでは関数に‘VPCFlowLogsToFirehose’と名付けます。さらにロールには先の手順で作成した‘lambda_kinesis_exec_role’を指定します。
  3. 関数コードにおいて、Python 2.7ランタイムを選択し、このGitHub上のコードをコードパネルにコピーします。環境変数にはDELIVERY_STREAM_NAMEという名前の変数を追加します。この変数の値には本手順の最初に作成したデリバリーストリームの名前(‘VPCFlowLogsDefaultToS3’)を設定します。また、タイムアウトは1分にします。

o_vpc-flow_2

Lambda関数に対するCloudWatchサブスクリプションの作成

CloudWatchログにて、次の手順を実施します。

  1. VPCフローログのロググループを選択します(フローログを作成したばかりであればロググループが表示されるまで数分待つ必要がある場合があります)。
  2. アクションからLambdaサービスへのストリーミングの開始を選択します。

  1. 先の手順で作成したLambda関数 ‘VPCFlowLogsToFirehose’ を選択します。
  2. ログの形式は Amazpn VPC フローログ を選択します。

Athenaでのテーブル作成

Amazon Athenaは、特に他のインフラストラクチャをプロビジョニングしたり管理することなく、標準的なSQLによりS3に格納されたデータを問い合わせることを可能にします。AthenaはCSV、JSON、ParquetやORCなど様々な標準的なデータ形式を扱え、問合せ前にそれらのデータを変換する必要はありません。スキーマを定義し、そしてAWSマネジメントコンソールのクエリエディタやAthena JDBCドライバを使用したプログラムからクエリを実行するだけです。

AthenaはHiveメタストアと互換性のあるデータカタログにデータベースとテーブル定義を格納します。本記事では、フローログを1つのテーブル定義として作成します。テーブルに対するDDLについてはこのセクションの後半で述べます。DDL実行前に、次の点に注意しておいて下さい。

    • DDL上の<bucket_and_prefix>はFirehoseからフローログの書き込み先として実際に作成したS3バケットの名前に書き換えます(プリフィックスも含めるのを忘れずに)。
    • CREATE TABLE定義にEXTERNALというキーワードが含まれています。もしこのキーワードを除くと、Athenaはエラーを返します。EXTERNALキーワードはS3に格納されている元データに影響を与えずに、データカタログへテーブルメタデータを格納されるようにします。もし外部テーブルを削除したとしても、カタログからはメタデータが削除されますが、S3上のデータは維持されます。
    • vpc_glow_logsテーブルのカラムはフローログレコード上のフィールドにマッピングされます。フローログレコードはスペース区切りの文字列を含みます。各行のフィールドを解析するために、Athenaはどのようにデータを扱うべきかを示すカスタムライブラリとしてシリアライズ-デシリアライズクラス、またはSerDeを用います。
  • ここでは、スペース区切りのフローログレコードを解析するためにSerDe用の正規表現を指定します。この正規表現は”input.regex”というSerDeのプロパティによって提供されます。

Athenaのクエリエディタに以下のDDLを入力し、Run Queryをクリックして下さい。

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
Version INT,
Account STRING,
InterfaceId STRING,
SourceAddress STRING,
DestinationAddress STRING,
SourcePort INT,
DestinationPort INT,
Protocol INT,
Packets INT,
Bytes INT,
StartTime INT,
EndTime INT,
Action STRING,
LogStatus STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
    "input.regex" = "^([^ ]+)\\s+([0-9]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([0-9]+)\\s+([0-9]+)\\s+([^ ]+)\\s+([^ ]+)$") 
LOCATION 's3://<bucket_and_prefix>/';

 

Athenaでのデータ問合せ

テーブルを作成した後は、テーブル名の隣にある小さなアイコンからPreview tableを実行し、レコードセットのサンプルを確認しましょう(訳注:VPCフローログをクリーニングせずに投入しているため、サンプリングされる箇所によってはnullのレコードが表示される場合もあります)。

o_vpc-flow_5

フローログを調査するために様々なクエリを実行することができます。ここでは例として、拒否されたトラフィックの中からソースIPアドレスのトップ25を取得してみます。

SELECT sourceaddress, count(*) cnt
FROM vpc_flow_logs
WHERE action = 'REJECT'
GROUP BY sourceaddress
ORDER BY cnt desc
LIMIT 25;

o_vpc-flow_6

QuickSightによるログの可視化

QuickSightはわずか数度のクリックでAthena上のテーブルを可視化することを可能にします。AWSアカウントによってQuickSight上にサインアップすることができ、1GBのSPICEキャパシティ無料利用枠を持つユーザアカウント1つを取得できます。

QuickSightをAthenaに接続させる前に、ここで説明されている手順を参考に、QuickSightに対するAthena及び関連するS3バケットへのアクセス権限の付与を確認します。

QuickSightにログインし、Manage dataNew data setと選択します。データソースとしてAthenaを選びます。

o_vpc-flow_7

データソースに“AthenaDataSource”と名前を付けます。defaultスキーマ→vpc_flow_logsテーブルと選択します。

o_vpc-flow_8

Edit/Preview dataを選択します。starttimeとendtimeのデータは数値形式よりも日付形式が適しています。これらの2つのフィールドはフローログのキャプチャウィンドウとシステムに到達した時刻をUnix時間で表現しています。

o_vpc-flow_9

ここでSave and visualizeを選択します。

異なるstart timeのキャプチャウィンドウとその時の送信バイト数を見てみましょう。StartTimeとBytesをフィールドリストから選択することでそれが可能です。覚えておいて頂きたいのは、QuickSightはこれを自動的に通信量のタイムチャートとして可視化することです。異なる日付/時間単位への変更はとても簡単です。

vpc-flow_10

これは、1日の中の通信で大きなスパイクがあった例です。この例はプロットされている他の日と比べてこの日に大量の通信が発生していることを教えてくれます。

o_vpc-flow_11

データに含まれるポート、IPアドレスその他のファセットを通じて通信許可/拒否に関するリッチな分析を行うことも簡単です。作られた分析結果をダッシュボードとして同じ組織の他のQuickSightユーザに共有することもできます。

o_vpc-flow_12

クエリのパフォーマンス向上とコスト削減のためのデータのパーティション化

ここまで述べてきたソリューションでは、S3に対して頻繁にGZIP圧縮されたフローログを配置します。Firehoseはこれらのファイルをデリバリーストリームの作成時に指定したバケット内に /year/month/day/hour というキーで格納します。Athenaでvpc_flow_logsテーブルを作成した時に使用していた外部テーブル定義には、この時系列キースペース内にある全てのファイルが含まれています。

Athenaはスキャンされたデータの量に応じて、クエリ毎に課金されます。ここまでのソリューションでは、クエリを発行する毎にS3に配置されたすべてのファイルがスキャンされます。VPCフローログの数が増加するに従い、データのスキャン量も増加し、クエリの応答時間やコストの両方に影響を与えることになります。

データの圧縮、パーティショニング、そして列指向フォーマットへの変換によって、クエリのコストを削減し、パフォーマンスを向上させることが可能です。Firehoseにて、既に圧縮された状態でS3へデータを配置するように設定されています。ここではパーティショニングに着目します。(Apache Parquetのような列指向フォーマットへの変換については本記事の対象外とします)

テーブルをパーティショニングすることで、クエリ発行時のデータスキャン量を制限することができます。多くのテーブルに置いて、特に発行するクエリの大半に時間ベースでの範囲制限が含まれる場合には、時間別での分割が有効です。AthenaはHiveのパーティショニング形式を使用します。これにより、パーティショニングの体系が直接反映されたkey-valueペアを含む名前付けをされたフォルダにパーティションが分割されます(詳しくはAthenaのドキュメントを参照)。

Firehoseにより作成されたこのフォルダ構造(例:s3://my-vpc-flow-logs/2017/01/14/09/)は、Hiveパーティショニング形式(例:s3://my-vpc-flow-logs/dt=2017-01-14-09-00/)とは異なります。しかし、ALTER TABLE ADD PARTITION文を用いると、手動でパーティションを追加してそのパーティションをデリバリーストリームによって作成されたキー空間の一部分に割り当てることができます。

ここでは、S3で新しいファイルを受信した際にALTER TABLE ADD PARTITION文を実行するためにLambda関数とAthena JDBCドライバを使い、自動的にFirehoseのデリバリーストリームに対する新しいパーティションを作成する方法を示します。

Athenaにてクエリを実行するLamba用のIAMロールの作成

Lambda関数を作成する前に、Lambdaに対してAthena上でクエリを実行することを許可するためのIAMロールを作成する必要があります。ユーザーガイドも参考に、次のように定義されるインラインアクセスポリシーを組み込んだ ‘lambda_athena_exec_role’ という名前のロールを作成して下さい。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "arn:aws:logs:*:*:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "athena:RunQuery",
                "athena:GetQueryExecution",
                "athena:GetQueryExecutions",
                "athena:GetQueryResults"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:ListMultipartUploadParts",
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::aws-athena-query-results-*"
            ]
        }
    ]
}

パーティション化されたvpc_flow_logテーブルの作成

前の手順でAthena上に定義したvpc_flow_log外部テーブルはパーティション化されていません。‘IngestDateTime’という名前のパーティションを付したテーブルを作成するために、元のテーブルを削除して、次に示すDDLにてテーブルを再作成します。

DROP TABLE IF EXISTS vpc_flow_logs;

CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
Version INT,
Account STRING,
InterfaceId STRING,
SourceAddress STRING,
DestinationAddress STRING,
SourcePort INT,
DestinationPort INT,
Protocol INT,
Packets INT,
Bytes INT,
StartTime INT,
EndTime INT,
Action STRING,
LogStatus STRING
)
PARTITIONED BY (IngestDateTime STRING)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
    "input.regex" = "^([^ ]+)\\s+([0-9]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([0-9]+)\\s+([0-9]+)\\s+([^ ]+)\\s+([^ ]+)$") 
LOCATION 's3://<bucket_and_prefix>/';

Athenaのパーティションを生成するためのラムダ関数の作成

次の手順でLamda関数を作成します。

  1. GitHub上にあるLambda Javaのプロジェクトをクローンします。
  2. READMEファイルの手順に従って、ソースをコンパイルし、出力された.jarファイルをS3のバケットにコピーします。
  3. Lambdaコンソールから関数の作成を開始し、一から作成を選択します。
  4. 基本的な情報ページでは、名前に‘CreateAthenaPartitions’、既存のロールとして’lambda_athena_exec_role’を選択し、関数の作成をクリックします。
  5. 関数コードページに遷移しますランタイムからJava 8を選択します。
  6. コードエントリタイプは、Amazon S3からのファイルのアップロードを選択します。S3リンクのURLには、先ほどアップロードした.jarファイルへのURLを入力します。
  7. ハンドラには’com.amazonaws.services.lambda.CreateAthenaPartitionsBasedOnS3Event::handleRequest’と入力します。
  8. このLambda関数のためには、いくつかの環境変数を設定する必要があります。
  • PARTITION_TYPE: [Month, Day, Hour]のうちどれかの値を設定します。この環境変数はオプションです。もし設定しなかった場合、Lambda関数はデフォルトとして日次でパーティションを作成します。例:’Hour’
  • TABLE_NAME: <データベース名>.<テーブル名>という形式で指定します。必須です。例:‘default.vpc_flow_logs’.
  • S3_STAGING_DIR: クエリの出力が書き込まれるAmazon S3のロケーション。(Lambda関数はDDL文だけを実行していますが、Athenaはその結果もS3に対して書き込みます。前の手順で作成したIAMポリシーでは、クエリ出力バケット名は‘aws-athena-query-results-’で開始されると仮定しています)
  • ATHENA_REGION: Athenaが動作するリージョンです。例:’us-east-1′

o_vpc-flow_13

  1. 最後に、タイムアウトを1分に設定して保存します。

S3上の新しいオブジェクトをLambda関数に通知するための設定

VPCフローログデータを含むS3バケットのプロパティページにおいて、Eventsペインを開き、通知の追加を押して新たな通知を作成します。

  • 名前: FlowLogDataReceived
  • イベント: ObjectCreated(All)
  • 送信先: Lambda function
  • Lambdaドロップボックスから‘CreateAthenaPartitions’を選択

これで、FirehoseによりS3バケットにファイルが配置される度に、‘CreateAthenaPartitions’ 関数がトリガーされます。この関数は新たに受信したオブジェクトのキーを解析します。キーの year/month/day/hour という部分に基づいて、関数作成の際に環境変数で指定したPARTITION_TYPEの設定(Month/Day/Hour)に従い、そのファイルがどのパーティションに属するかを判断します。次に、このパーティションが既に存在するかどうかをAthenaに問い合わせます。存在しなければ新たにパーティションを作成し、S3のキー空間の関連部分にマッピングします。

このロジックを詳しく見てみましょう。時間単位のパーティションを作成するために ‘CreateAthenaPartitions’ 関数を作成し、Firehoseによりちょうどフローログデータのファイルが s3://my-vpc-flow-logs/2017/01/14/07/xxxx.gz に配信されたと仮定します。

新しいファイルのS3キーを見て、Lambda関数はそれが’2017-01-14-07’という時間単位のパーティションに属すると推測します。Athenaを確認すると、そのようなパーティションはまだ存在していないため、次のDDL文を実行します。

ALTER TABLE default.vpc_flow_logs ADD PARTITION (IngestDateTime='2017-01-14-07') LOCATION 's3://my-vpc-flow-logs/2017/01/14/07/';

もしLambda関数が日次のパーティションとして作成されていた場合には、新しいパーティションは‘s3://my-vpc-flow-logs/2017/01/14/’ とマッピングされます。月次であれば ‘s3://my-vpc-flow-logs/2017/01/’ となります。
パーティションは、各ログがS3に取り込まれた日時を表しています。これは、各パーティションに含まれる個々のレコードのStartTimeやEndTimeの値よりも後の時間であることに注意して下さい。

Athenaを用いたパーティション化されたデータへの問合せ

これで、問合せはパーティションを利用できるようになりました。

SELECT sourceaddress, count(*) cnt
FROM vpc_flow_logs
WHERE ingestdatetime > '2017-01-15-00'
AND action = 'REJECT'
GROUP BY sourceaddress
ORDER BY cnt desc
LIMIT 25;

過去3時間以内に取り込まれたデータを問い合わせるには、次のような問合せを実行します(ここでは時間単位のパーティショニングを行っていると仮定します)。

SELECT sourceaddress, count(*) cnt
FROM vpc_flow_logs
WHERE date_parse(ingestdatetime, '%Y-%m-%d-%H') >= 
      date_trunc('hour', current_timestamp - interval '2' hour)
AND action = 'REJECT'
GROUP BY sourceaddress
ORDER BY cnt desc
LIMIT 25;

次の2つのスクリーンショットが示しているのは、パーティションを利用することでスキャンするデータ量を減らせるということです。そうすることで、クエリのコストと応答時間が削減できます。1つめのスクリーンショットはパーティションを無視したクエリの結果です。
vpc-flow_1o_6
2つめのスクリーンショットは、WHERE句でパーティションの使用を指示したクエリの結果です。
o_vpc-flow_17
このように、パーティションを用いることで2つめのクエリは半分の時間で済み、データのスキャン量は最初のクエリの1/10以下にできたことがわかります。

結論

以前は、ログ分析というのは特定のクエリのためだけに大規模なデータを準備しなければならなかったり、大規模なストレージやマシンリソースを準備したり運用したりする必要がありました。Amazon AthenaとAmazon QuickSightによって、ログデータの発行から格納、分析、そして視覚化まで、より柔軟性高く実現することができるようになっています。クエリを実行してデータを視覚化するのに必要なインフラストラクチャに焦点を当てるのではなく、ログの調査に集中できるようになるのです。

著者について

ben_snively_90
Ben Snively – a Public Sector Specialist Solutions Architect. 彼は政府や非営利団体、教育組織の顧客におけるビッグデータや分析プロジェクトについて、AWSを用いたソリューションの構築を通じた支援に従事しています。また、彼は自宅にIoTセンサーを設置してその分析も行っています。

 

Ian_pic_1_resized
Ian Robinson – a Specialist Solutions Architect for Data and Analytics. 彼はヨーロッパ・中東・アジア地域において顧客が持つデータを結びつけることによる価値の創出のためにAWSを利用することを支援しています。また彼は現在、1960年代のダーレク(Dalek)の複製を修復する活動をしています。
(翻訳はSA五十嵐が担当しました。原文はこちら)

関連文書

Analyze Security, Compliance, and Operational Activity Using AWS CloudTrail and Amazon Athena

Amazon Aurora (MySQL) Asynchronous Key Prefetchにより、Join性能を10倍以上に高速化

Amazon Aurora (MySQL)はJoinクエリを一桁以上高速化可能なasynchronous key prefetch (AKP)機能をリリースしました。

この機能は、Batched Key Access(BKA)JoinアルゴリズムとMulti-Range Read(MRR)最適化を使用するクエリに適用され、データ・セットがbuffer pooやquery cacheにない場合のパフォーマンスを向上させます。 我々のテストでは、上記の条件を満たすクエリでコールドバッファプールを使用した場合、クエリのレイテンシが10倍以上向上しました。

この機能は、Amazon Aurora version 1.15からご利用頂けます。Amazon Auroraドキュメント中のベストプラクティスの項目を是非ご覧ください。

ハイエンドの商用データベースの速度と可用性をオープンソースデータベースのシンプルさとコスト効率でご利用頂ける、Amazon Aurora MySQL/PostgreSQLついてはこちらをご覧下さい。

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