Amazon Web Services ブログ

Category: Analytics

本番環境で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が少なくなれば、クエリーはより高速になり、そしてクエリー当たりのコストも低くなります。 […]

Read More

AWS Glue や Amazon Athena を用いたサーバーレスな Machine Learning 環境

属性をもとにデータセットを分割しなければならなかったことはありませんか?K-means はデータ分割を行うために最も頻繁に使用されている Machine Learning アルゴリズムの 1 つです。このアルゴリズムは異なるグループ (クラスター) にデータを分けることで機能します。各サンプルにはクラスターが指定されます。これは同じクラスターに指定されたサンプルが、他のクラスターにあるサンプルに比べて互いが類似しているようにするためです。 今回のブログでは AWS Glue を使用して、Amazon S3 にあるタクシー乗車のデータセットを例に K-means を適用し、そのデータをタクシーの座標に基づき 100 通りのクラスターに分割する方法を説明します。次に Amazon Athena を使用し、乗車数そして各クラスターのおおよその地域をクエリします。最後に Amazon Athena を使用して、最も乗車数の多かった 4 つの地域の座標を割り出します。AWS Glue と Amazon Athena では、ユーザーによるプロビジョンやサーバー管理を必要とせずに、こうしたタスクを実行することができます。 ソリューションの概要 今回は、過去のブログで使用したニューヨーク市のタクシーに関するデータセットを使用します: 「AWS Glue、Amazon Athena、Amazon QuickSight を使用して様々なプロバイダからのデータを調和、クエリ、視覚化する (Harmonize, Query, and Visualize Data from Various Providers using AWS Glue, Amazon Athena, and Amazon QuickSight)」2016 年 1 月のタクシー乗車に関する緑色のタイプから構成されたテーブルを使用します。 座標に基づいたデータセットを分割するために、Spark […]

Read 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 インスタンスホストにカスタムソフトウェアをインストールすることができないため、別のホスト […]

Read More

Amazon Kinesis Video Streams – コンピュータビジョン・アプリケーションのためのサーバーレスな動画データの収集と保存

携帯電話、防犯カメラ、ベビーモニター、ドローン、WEBカメラ、車載カメラ、さらには人工衛星まで、これらすべては高輝度で高品質の動画ストリームを生成できます。 住宅、オフィス、工場、都市、街路、高速道路は現在、膨大な数のカメラを備えています。これらのカメラは、洪水などの自然災害時に被害状況の調査を可能にし、公共の安全性を高め、子供が安全かつ健康であることを知らせ、無限に繰り返す「失敗」動画のための一瞬を補足し(個人的な趣味の話です)、身元の判定に役立つデータを集め、交通の問題を解決するなど、様々な場面で活用されます。 この動画データの洪水を扱うことは、言い表せないほど難しいことです。 入力ストリームには、個別に、または何百万という単位でデータが到着します。 ストリームには価値あるリアルタイムなデータが含まれており、遅延したり、一時停止したり、より適切なタイミングで処理するためにデータを脇に置いておいたりすることはできません。生のデータを取得すると、他の課題が発生します。動画データの保存、暗号化、索引作成などが頭に浮かびますね。価値を引き出すこと、つまりコンテンツに深く潜って、そこにあることを理解し、行動を起こすことは、次の大きなステップです。 新しい Amazon Kinesis Video Streams 2017年11月29日、リアルタイムストリーミングサービスであるAmazon Kinesisファミリーの新しいメンバーとして、Amazon Kinesis Video Streamsをご紹介します。 これによって、独自のインフラストラクチャを構築して動かすことなく、何百万ものカメラデバイスからストリーミング動画(または時系列にエンコードされたデータ)を取り込むことができます。 Amazon Kinesis Video Streamsは、入力ストリームを受け入れ、永続的かつ暗号化された形式で保存し、時間に基づいたインデックスを作成し、コンピュータビジョン・アプリケーションの作成を可能にします。 あなたはAmazon Recognition VideoやMXNet、TensorFlow、OpenCV、または独自のカスタムコード、つまりクールな新しいロボットや、分析、あなたが考え出すコンシューマー・アプリケーションを支えるあらゆるコードを使用して、入力ストリームを処理することができます。

Read More

Amazon Elasticsearch Service へのアクセスコントロールの設定

Dr. Jon Handler (@_searchgeek) は、検索技術を専門とする AWS ソリューションアーキテクトです。 Amazon Elasticsearch Service (Amazon ES) ドメインを保護することで、権限のないユーザーがデータにアクセスしたり変更したりすることを防ぐことができます。ほとんどのお客様は、IP アドレスベースまたは ID ベースのアクセスポリシーのセキュリティを望んでいますが、利便性からオープンアクセスを選択しています。オープンアクセスのドメインは、インターネット上の任意の当事者から Amazon ES ドメインへのデータの作成、表示、変更、および削除の要求を受け入れるため、このオプションはほとんどのお客様にとって適切なものではありません。 以前のブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」では、アクセスコントロールについて詳細に説明しました。このブログ記事では、ドメインの IAM ポリシーを開始する簡単な方法をいくつか紹介します。AWS Identity and Access Management (IAM) ポリシーを設定するにはいくつかの作業が必要ですが、この「予防的対策」により後で大量の作業が発生するのを防ぐことができます。 Amazon Elasticsearch Service における主要なアクセスコントロールの概念 Amazon ES が作成するドメインには、Elasticsearch クラスタ内のノードと複数の AWS サービスのリソースが含まれます。Amazon ESがドメインを作成すると、ドメインはサービス制御された VPC でインスタンスを起動します。これらのインスタンスの前面には Elastic Load Balancing (ELB) があり、ロードバランサーのエンドポイントはRoute 53 を通じて発行されます。ドメインへのリクエストは、ドメインの EC2 インスタンスにルーティングする ELB ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは […]

Read More

Amazon QuickSight の更新 – 地理空間の可視化、プライベートVPCアクセス、その他

AWSでは記念日を敢えて祝うことはあまりしません。100近いサービスによって、週に何度もアップデートを展開するのが当たり前になっています。(まるで週に何度もケーキを食べて、シャンパンを飲んでいるようなものです。)それは楽しそうに聞こえますが、我々はむしろ、お客様に耳を傾け、イノベーションを起こすことに多くの時間を費やしています。とは言うものの、Amazon QuickSight は一般提供開始から1年が経ちましたので、簡単にアップデートを紹介したいと思います! QuickSight の事例 本日、数万のお客様(スタートアップからエンタープライズまで、交通や法律、鉱業、医療などの様々な業界)がお客様のビジネスデータの分析とレポートのためにQuickSightを利用されています。 幾つか例を上げましょう。 Gemini は負傷した労働者を弁護するカリフォルニア弁護士に法的根拠の調達サービスを提供しています。彼らは、カスタムレポートの作成や一度限りのクエリの実行から、ドリルダウンとフィルタリングを使用した動的なQuickSightダッシュボードの作成と共有までを行っています。QuickSightは、販売パイプラインの追跡、注文のスループットの測定、注文処理パイプラインでのボトルネックの特定に使用されています。 Jivochat はウェブサイト訪問者とウェブサイトの所有者とを繋ぐ、リアルタイムメッセージングプラットフォームを提供しています。QuickSightを使用して、彼らはインタラクティブなダッシュボードを作成・共有しながら、元となるデータセットへのアクセスも提供しています。これにより、静的なスプレッドシートを共有するにとどまらず、誰もが同じデータを見ていることを保証し、現時点でのデータに基づいてタイムリーな決定を下すことを後押ししています。 Transfix は、小売業、食品・飲料、製造業およびその他の業種のFortune 500に名を連ねるリテールの荷送主に、荷物にマッチする配送業者を選択でき、ロジスティクスの可視性を高める、オンライン貨物市場です。QuickSightはBIエンジニアと非技術系ビジネスユーザーの両方に分析環境を提供しています。彼らはQuickSightを通じて、輸送ルート、運送業者効率性、プロセス自動化などのビジネスの鍵となる事柄や運営指標を吟味しています。 振り返り / 先読み QuickSightに対するフィードバックはとても役に立っています。お客様は、自社のBIインフラを設定または実行することなく、従業員がQuickSightを使用してデータに接続し、分析を実行し、データに基づいた高速な決定を下すことができていると教えてくれます。我々は頂いたフィードバックをすべて歓迎し、それを使用してロードマップを推進し、1年で40を超える新機能を導入してきました。以下はその要約です: 2016年12月 – QuickSight Enterprise Edition. 2017年2月 – Amazon Athenaをサポート; SPICEデータの自動リフレッシュ予約 2017年4月 – KPIチャート, CSVエクスポート, ADコネクタ; US East(Ohio)で利用可能に; AWS CloudTrailによる監査ログに対応 2017年5月 – Presto と Apache Spark のコネクタ; SAML 2.0によるフェデレーションシングルサインオン 2017年6月 – Amazon Redshift Spectrumのサポート; 1-ClickでS3分析の可視化 2017年8月 – Asia Pacific […]

Read More

Amazon DynamoDB からのデータストリームを AWS Lambda と Amazon Kinesis Firehose を活用して Amazon Aurora に格納する

Aravind Kodandaramaiah は AWS パートナープログラムのパートナーソリューションアーキテクトです。 はじめに AWS ワークロードを実行するお客様は Amazon DynamoDB と Amazon Aurora の両方を使用していることがよくあります。Amazon DynamoDB は、どのような規模でも、一貫した、数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高い NoSQL データベースサービスです。データモデルの柔軟性が高く、パフォーマンスが信頼できるため、モバイル、ウェブ、ゲーム、広告、IoT、他の多くのアプリケーションに最適です。 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、オープンソースデータベースのコスト効率性と簡素性を備えた、高性能の商用データベースの可用性とスピードをあわせもったエンジンです。Amazon Aurora は、MySQL よりも最大 5 倍のパフォーマンスを発揮するだけでなく、商用データベースのセキュリティ、可用性、および信頼性を 10 分の 1 のコストで実現します。 DynamoDB と Aurora を連携させるために、カスタムウェブ解析エンジンを構築して、毎秒数百万のウェブクリックが DynamoDB に登録されるようにしたとします。Amazon DynamoDB はこの規模で動作し、データを高速に取り込むことができます。また、このクリックストリームデータを Amazon Aurora などのリレーショナルデータベース管理システム (RDBMS) にレプリケートする必要があるとします。さらに、ストアドプロシージャまたは関数内で SQL の機能を使用して、このデータに対してスライスアンドダイスや、さまざまな方法でのプロジェクションを行ったり、他のトランザクション目的で使用したりするとします。 DynamoDB から Aurora に効率的にデータをレプリケートするには、信頼性の高いスケーラブルなデータレプリケーション (ETL) プロセスを構築する必要があります。この記事では、AWS Lambda と Amazon […]

Read More

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 RDS, Amazon Athena, Amazon […]

Read More

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

多くの業務や運用において、頻繁に更新される大規模なデータを分析することが求められるようになっています。例えばログ分析においては、振る舞いのパターンを認識したり、アプリケーションのフロー分析をしたり、障害調査をしたりするために大量のログの可視化が必要とされます。 VPCフローログはAmazon VPCサービス内のVPCに属するネットワークインターフェースを行き来するIPトラフィック情報をキャプチャします。このログはVPC内部に潜む脅威やリスクを認識したり、ネットワークのトラフィック・パターンを調査するのに役立ちます。フローログはAmazon CloudWatchログに格納されます。いったんフローログを作成すれば、Amazon CloudWatchログを用いて見たり取り出したりすることができるようになります。 フローログは様々な業務を助けてくれます。例えば、セキュリティグループのルールを過度に厳しくしすぎたことによって特定のトラフィックがインスタンスに届かない事象の原因調査などです。また、フローログを、インスタンスへのトラフィックをモニタリングするためのセキュリティツールとして使うこともできます。 この記事はAmazon Kinesis Firehose、AWS Lambda、Amazon S3、Amazon 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にフローログを作成すると、ログデータは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”: [ […]

Read More

Amazon Elasticsearch Service が VPC をサポート

本日より、NAT インスタンスやインターネットゲートウェイを必要とせずに Amazon VPC から Amazon Elasticsearch Service ドメインに接続できるようになりました。Amazon ES の VPC サポートは設定も簡単で信頼性が高く、セキュリティをさらに強化することができます。VPC サポートでは、その他のサービスと Amazon ES 間のトラフィックはパブリックインターネットから分離されており AWS ネットワーク内で維持されます。既存の VPC セキュリティグループを使用してネットワークアクセスを管理できます。また、AWS Identity and Access Management (IAM) ポリシーを使って保護機能を強化することもできます。Amazon ES ドメインの VPC サポートは追加費用なしにご利用いただけます。 ご利用開始にあたって VPC での Amazon Elasticsearch Service ドメインの作成は簡単です。クラスター作成に使ういつもの手順を行い [VPC access] を選択します。 これだけです。その他の手順はありません。これで VPC からドメインにアクセスできるようになりました。 主要事項 VPC をサポートするにあたり、Amazon ES は少なくても 1 つの VPC サブネットにエンドポイントを配置します。Amazon ES はクラスター内の各データノードの […]

Read More