Amazon Web Services ブログ

Category: Analytics

Amazon EC2インスタンスにホストベースの侵入検知システムアラートの監視方法

AWSリソースを安全に保護するためのアプローチとして、予防のための仕組み、検知のため仕組みといったそれぞれのレイヤーでのアプローチを検討頂くことを推奨しています。たとえば、Amazon EC2インスタンスにホストベースのコントロールを組み込むことで、アクセスを制限し、システムの動作やアクセスパターンに伴う適切なレベルの可視性を準備できます。これらのコントロールには、ホスト上のネットワークトラフィック、ログファイル、およびファイルアクセスを監視・分析するホストベースの侵入検知システム(HIDS)を含むことが一般的です。 HIDSは、通常、警告、自動修復ソリューションと統合され、攻撃、許可されていない活動、疑わしい活動、環境内の一般的なエラーを検出し対処します。 このブログ記事では、Amazon CloudWatch Logsを使用してオープンソースセキュリティ(OSSEC)HIDSからのアラートを収集、集約する方法を示します。 また、CloudWatch Logs サブスクリプションを組み合わせることで、Amazon Elasticsearch Service(Amazon ES)に分析データと可視化のアラートを配信し、一般的なオープンソースであるKibanaを使用し可視化まで行います。また皆さんが、すぐに試せるようにCloudFormationテンプレートを用意しましたので、ほとんどのデプロイメント作業を自動化させています。このソリューションを使用して、EC2 全体の可視性と洞察を向上させ、セキュリティ修復活動を促進することができます。たとえば、特定ホストがEC2インスタンスのスキャンを検知したらOSSECアラートをトリガーし、VPCネットワークACL(Access Control List)またはAWS WAFルールを実装して、送信元IPアドレスまたはCIDRをブロックすることができます。 ソリューションの概要 次の図は、この記事のソリューションの概要を示しています。 ソリューションの仕組みは次のとおりです。 1. ターゲットEC2インスタンスでは、OSSEC HIDSは、CloudWatch Logs エージェントがキャプチャするログに基づきアラートを生成します。 HIDSは、ログ分析、整合性チェック、Windowsレジストリ監視、ルートキット検出、リアルタイムアラート、およびアクティブな応答を実行します。詳細については、「OSSEC入門」を参照してください。 2. CloudWatch Logs グループはにアラートがイベントとして送信されます。 3. AWS Lambdaを介してイベントをAmazon ESに転送するために、CloudWatch Logs サブスクリプションがターゲットロググループに適用されます。 4. Amazon ESにはログに記録されたアラートデータがロードされます。 5. Kibanaはアラートをほぼリアルタイムで視覚化します。 Amazon ESはすべてのAmazon ESドメインにKibanaを標準でインストールした形で提供されます。 デプロイ時の考慮事項 この記事では、主なOSSEC HIDSのデプロイは、Linuxベースのインストールで構成されています。インストールでは、アラートが各システム内でローカルに生成されます。このソリューションは、デプロイの対象リージョンはAmazon ESとLambdaに依存します。 AWSサービスの可用性に関する最新情報は、Regionテーブルで確認できます。また、EC2インスタンスが必要なコンポーネントを適切にプロビジョニングするために、インターネットアクセスとDNS解決を持つAmazon VPC(Virtual Private Cloud)サブネットを識別する必要があります。 デプロイのプロセスを簡素化するために、テスト環境向けにAWS CloudFormationテンプレートを作成しました。このテンプレートを使用して、テスト環境スタックを既存のAmazon VPCサブネットに自動的にプロビジョニングできます。 CloudFormationを使用してこのソリューションのコアコンポーネントをプロビジョニングし、警告分析用にKibanaを設定します。このソリューションのソースコードはGitHubで入手できます。 Cloud […]

Read More

Amazon Athena のパフォーマンスチューニング Tips トップ 10

Amazon Athena は、S3 に保存されたデータに対して標準 SQL で簡単に分析を行える、インタラクティブクエリサービスです。Athena はサーバーレスのためインフラ管理の必要がなく、また実行したクエリのぶんだけ料金を支払うかたちになります。Athena は簡単に使えます。Amazon S3 上のデータに対してスキーマを定義し、標準 SQL でクエリを投げるだけです。 このブログポストでは、クエリパフォーマンスを改善するための 10 個の Tips をご紹介します。Tips には、Amazon S3 に置かれたデータに関するものと、クエリチューニングに関するものがあります。Amazon Athena は Presto を実行エンジンとして使用しているため、ここでご紹介する Tips のうちのいくつかは、Amazon EMR 上で Presto を動かす際にも当てはまります。 このポストは、読者の方が Parquet, ORC, Text files, Avro, CSV, TSV, and JSON といった、さまざまなファイルフォーマットについての知識を持っていることを前提としています。 ベストプラクティス: ストレージ このセクションでは Athena を最大限に活用するために、どのようなデータ構造にするべきかについて議論します。ここで議論する内容は、Amazon EMR 上の Spark, Presto, Hive で Amazon S3 のデータを処理する場合にも、同様に当てはまります。 […]

Read More

R で Amazon Athena を活用する

データサイエンティストはしばしば、R から SQL クエリを投げるときに、その裏側のビッグデータ基盤のインフラ管理を気に掛けなければなりません。Amazon Athena はインフラ管理の必要がなく、標準 SQL で簡単に S3 上のデータを直接分析できる、インタラクティブクエリサービスです。R と Amazon Athena の連携によって、データサイエンティストはインタラクティブな分析ソリューションのための、強力なプラットフォームを手に入れることができます。 このブログポストでは、Amazon EC2 インスタンス上で動作する R/RStudio から Athena に接続します。 事前準備 Athena との連携を開始する前に、以下のステップを完了してください。 AWS アカウントの管理者に依頼して、Athena にアクセスするのに必要な権限を、Amazon の Identity and Access Management (IAM) コンソール経由で、自身の AWS アカウントに付与してもらってください。具体的には、IAM にあるデータサイエンティストのユーザーグループに対して、関連する Athena のポリシーをアタッチします Amazon S3 バケットに、ステージングディレクトリを作成してください。Athena はクエリする対象のデータセットと、クエリ結果を置く場所として、このバケットを利用します。このポストでは、ステージングバケットを s3://athenauser-athena-r とします 注意: このブログポストでは、すべての AWS リソースは us-east-1 リージョンに作成します。ほかのリージョンでも Athena が利用可能かどうか、製品およびサービス一覧で確認してください。 EC2 上での […]

Read More

新機能 – Amazon EMR インスタンスフリート

今日は、インスタンスフリートと呼ばれる クラスターの新機能をご紹介します。インスタンスフリートは、インスタンスのプロビジョニングに広範囲な選択肢やインテリジェンスをもたらします。対応する加重容量やスポット入札価格 (スポットブロックを含む) を最大 5 つのインスタンスタイプのリストに追加できるようになりました。EMR は、クラスター作成時にこれらのインスタンスタイプの間でオンデマンドおよびスポット容量を自動的にプロビジョニングします。そのため、これまでよりも簡単かつ低コストに、希望のクラスター容量をすばやく取得して管理することができます。また、アベイラビリティーゾーンのリストを指定することもでき、EMR は、このうちのいずれかの AZ で最適にクラスターを起動します。また、EMR は、インスタンスをフリートの利用可能ないずれかのタイプに置換することで、スポットインスタンスの中断に備えてクラスターの再分散を続けます。その結果、クラスター容量全体を容易に管理できます。インスタンスフリートは、インスタンスグループの代わりに使用することもできます。グループと同様、クラスターには、マスター、コア、タスクフリートが作成されます。コンソールのアップデートを確認し、フリートの動作について詳しく調べてみましょう。EMR コンソールを開き、[クラスターの作成] ボタンをクリックします。なじみのある EMR プロビジョニングコンソールが表示されたら、左上隅付近にある詳細オプションに移動します。最新の EMR バージョン (インスタンスフリートは、5.0.x を除く 4.8.0 以上の EMR バージョンで使用可能) を選択し、[次へ] をクリックします。これで正常に表示されます。ハードウェアオプションの新しい [インスタンスフリート] を選択します。 ここで、コアグループを変更して、クラスターのニーズを満たす一組のインスタンスタイプを選択します。 EMR は、最もコスト効率の高い方法で要件を満たせるように、各インスタンスフリートとアベイラビリティーゾーンの容量をプロビジョニングします。EMR コンソールでは、インスタンスタイプごとに vCPU を加重容量と簡単にマッピングできるため、vCPU を容量ユニットとして使用しやすくなります (コアフリートに合計 16 個の vCPU が必要)。vCPU ユニットが、インスタンスタイプの分量指定に関する条件に一致しない場合は、[Target capacity] セレクタを変更して、任意のユニットを追加し、容量を定義します (API/CLI によるキャパシティーユニットの消費量も変更されます)。クラスターがプロビジョニングされており、ユーザー定義のタイムアウト内に希望のスポット容量を入手できない場合は、オンデマンドインスタンスを終了またはフォールバックして、残りのキャパシティーをプロビジョニングできます。また、インスタンスフリートで使用されるこれらの機能はすべて、「AWS SDK」および「CLI」より入手できます。インスタンスフリートをプロビジョニングする方法を詳しく見てみましょう。まず、my-fleet-config.json に configuration json を作成します。 [ { “Name”: “MasterFleet”, “InstanceFleetType”: “MASTER”, […]

Read More

Amazon Elasticsearch Service が Elasticsearch 5.1 をサポート

Amazon Elasticsearch Service は、オープンソース検索および分析エンジンである Elasticsearch を容易にデプロイ、運用、拡張できるようにするマネージド型サービスです。このたび Amazon Elasticsearch Service で Elasticsearch 5.1 および Kibana 5.1 がサポートされるようになったことを、ここにお知らせいたします。Elasticsearch 5 は非常に多くの新機能と機能拡張を備えており、Amazon Elasticsearch Service をご利用のお客様はそれらを活用いただけるようになりました。今回の Elasticsearch 5 のリリースには、次のような内容が含まれています。 インデックス作成のパフォーマンス: ロックの実装の更新および非同期のトランザクションログ FSYNC による、インデックス作成のスループットの向上 取り込みパイプライン: 受信データは一連の取り込みプロセッサを適用するパイプラインに送信できます。これにより検索インデックスに必要なデータに正確に変換できます。単純な付加アプリケーションから複雑な正規表現アプリケーションまで、20 個のプロセッサが含まれています Painless スクリプティング: Amazon Elasticsearch Service は Elasticsearch 5 のための新しい安全でパフォーマンスに優れたスクリプト言語である、Painless をサポートします。スクリプト言語を使用すると、検索結果の優先順位を変更したり、クエリでインデックスフィールドを削除したり、検索結果を修正して特定のフィールドを戻したりすることができます。 新しいデータ構造: 新しいデータ型である Lucene 6 データ構造をサポートし、半精度浮動小数点、テキスト、キーワード、さらにピリオドが含まれるフィールド名を完全にサポートします 検索と集計: リファクタリング検索 API、BM25 関連性計算、Instant Aggregations、ヒストグラム集計と用語集計の機能強化、再設計されたパーコレーターと完了サジェスタ ユーザーエクスペリエンス: 厳密な設定、本文とクエリ文字列パラメーターの検証、インデックス管理の向上、デフォルトで廃止予定のログを記録、新しい共有割り当て API、ロールオーバーと圧縮 API […]

Read More

Amazon Elasticsearch Service をはじめよう: シャード数の算出方法

Dr. Jon Handler (@_searchgeek) は検索技術にスペシャライズした Amazon Web Services のプリンシパルソリューションアーキテクトです。 Elasticsearch および Amazon Elasticsearch Service(Amazon ES) のブログポストシリーズへようこそ。ここでは今後もAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。 いくつのシャードが必要? Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。Elasticsearchではインデックス作成の際にシャード数を設定します。既存のインデックスのシャード数を変更することは出来ないため、最初のドキュメントをインデックスに投入する前にシャード数を決定しなければなりません。最初はインデックスのサイズからシャード数を算出するにあたって、それぞれのシャードのサイズの目安を30GBにします。 シャード数 = インデックスのサイズ / 30GB インデックスのサイズ算出に関しては、AWS Solutions Architect ブログ: 【AWS Database Blog】Amazon Elasticsearch Service をはじめよう: インスタンス数の見積もり方法をご覧ください。 データの送信やクエリをクラスタに対して行っていく中で、クラスタのパフォーマンスを元に、継続的にリソースのユーセージを評価しながら、シャード数を調整していきます。 シャードとは? サーチエンジンには2つの役割があります: ドキュメントを元にしたインデックスの作成と、インデックスの中からマッチしたドキュメントを引き当てる検索です。インデックスが小さければ一つのデータ構造で一台のマシンで事足りるでしょう。しかし、大量のドキュメントにおいては、インデックスを保存するのに一台のマシンでは足りませんし、ピースに分割されたインデックスから検索結果を求めるためのコンピュート能力も足りません。Elasticsearchではこれらのピースのことをシャードと呼びます。それぞれのドキュメントは計算結果に基いてシャードにルーティングされます。デフォルトではドキュメントのIDのハッシュ値に基づいたルーティングになります。 シャードは ストレージ(storage) の単位であり、また 処理(computation) の単位でもあります。Elasticsearchはシャードを独立した形でクラスタ内のインスタンスにデプロイし、インデックスの処理をそれぞれで並列に行います。Elasticsearchという名前の通り”elastic”なものであると言えるでしょう。クラスタにインスタンスを追加する場合、Amazon Elasticsearch Serviceは自動的にシャードのリバランスを行い、クラスタ内のインスタンスにシャードを再配置します。 ストレージ(storage)においては、シャードはそれぞれ別のもの(distinct)です。シャード内のドキュメントは、他のシャードに重複して保持されることはありません。このアプローチによってシャード毎の独立性を保っています。 処理(computation)においても、シャードはそれぞれ別のもの(distinct)です。それぞれのシャードはドキュメントが処理されて生成されたApache Lucene indexのインスタンスです。インデックスには全てのシャードが含まれるため、クエリや更新リクエストのプロセスにおいて、それぞれのシャードはお互いに協調して機能する必要があります。クエリのプロセスにおいては、Elasticsearchはインデックス内の全てのシャードにクエリをルーティングします。それぞれのシャードはローカルで個別に処理を行い、それぞれの結果をアグリゲートして最終的にレスポンスします。書き込みリクエストにおいては(ドキュメントの追加、もしくは、既存のドキュメントの更新)、Elasticsearchはリクエストを適切なシャードにルーティングします。 Elasticsearchには2つの種類のシャードがある Elasticsearchには2つの種類のシャードがあります – プライマリシャードとレプリカシャードです。プライマリシャードは全ての書き込みリクエストを受け付けます。プライマリシャードは新しく追加されたドキュメントをレプリカにパスします。デフォルトでは、書き込みがレプリカに確認(acknowledge)されるのを待ってから呼び出し元に書き込み成功のレスポンスを行います。プライマリとレプリカシャードはデータの保存に冗長性をもたらし、データのロスを起こりにくくします。 この図の例では、Elasticsearchクラスタは3つのデータインスタンスを保持しています。緑と青の2つのインデックスがあり、それぞれ3つのシャードがあります。それぞれのシャードのプライマリは赤枠で囲われています。それぞれのシャードにはレプリカがあり、それらに枠はありません。Elasticsearchはいくつかのルールを元にシャードをインスタンスに配置します。最も基本的なルールとして、プライマリとレプリカのシャードを同じインスタンスに配置しない、というものが挙げられます。 最初にストレージにフォーカスする お客様のワークロードには2つの種類があります: シングルインデックスとローリングインデックス。シングルインデックスのワークロードは、全てのコンテンツを保持する”source of […]

Read More

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

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

Read More

SPICEデータのスケジュールリフレッシュがAmazon QuickSightに追加されました

Amazon QuickSightにSPICEデータのスケジュールリフレッシュ機能が追加されました。以下はAWS Bigdata Blogに掲載されたブログの翻訳です。 Jose KunnackalはAmazon QuickSightのシニアプロダクトマネージャ 2016年11月に私達はAmazon QuickSightをローンチしました。これはクラウドのパワーで稼働し、お客様のデータをクイックかつ簡単に分析するビジネスアナリティクスのサービスです。QuickSightはSPICE (Super-fast, Parallel, In-Memory Calculation Engine)というフルマネージドのデータストアを持っており、これにAWSやオンプレミス、クラウドサービスのデータを格納することで超高速なビジュアライゼーションを可能にします。SPICEに格納したデータはQuickSight上にあるボタンをクリックするだけでいつでもリフレッシュ(新しいデータの取り込み)を行うことが可能です。 本日、リフレッシュのスケジュール実行機能をローンチいたします! SPICEデータセットをスケジュールリフレッシュする SPICEデータセットを選択し、スケジュールリフレッシュを指定します。その後、タイムゾーン、リフレッシュ頻度、およびスケジュールの開始日時を指定します。 スケジュールを適切に設定することで、SPIPCEのデータセットや分析、ダッシュボードを元のデータソースに同期させることが可能になります。 スケジュールリフレッシュはサポートされるすべてのデータソース、つまりAWS、クラウドサービス、およびオンプレミスにあるデータに対して有効であり、全サポートリージョンのすでに作成済のデータセットについても利用可能です。手動でのリフレッシュと同様に、データセットのリフレッシュ状況のサマリを確認することが可能です。 データのスケジュールリフレッシュによって高いパフォーマンスを発揮するインタラクティブなダッシュボードをQuickSightとSPICEでシンプルに実現可能です。データリフレッシュのために所定の時間にQuickSightにログインする必要もありませんし(もしくはうっかり忘れることもなくなります)、QuickSightを活用して高速でインタラクティブなビジュアライゼーションを多くのユーザに提供することにフォーカスできます。 QuickSightのパワーをぜひ今日から体験してみてください – 無料枠がありますのでぜひサインアップを!もしご質問などがありましたら、コメントを残してください。 (訳注:QuickSightには全機能を60日間試せるFree Trialがあります。また、機能は制限されますが無料でずっと利用できるFree Tierも用意されています。詳しくはこちらをご確認ください。) 原文:https://aws.amazon.com/jp/blogs/big-data/scheduled-refresh-for-spice-data-sets-on-amazon-quicksight/ 翻訳:下佐粉 昭 (@simosako)  

Read More

暗号化を用いたセキュアな Amazon EMR

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。 こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。 暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。 この投稿ではEMRのセキュリティ設定による、複数段階のデータ暗号化のセットアッププロセスを概観します。暗号化について深く見ていく前に、データ暗号化が必要な状況を整理しましょう。 保存時のデータ Amazon S3にあるデータ – EMRのS3クライアントサイド暗号化 ディスク上のデータ – Linux Unified Key System (LUKS) による、Amazon EC2 のインスタンスストアボリューム(ブートボリュームを除く)、クラスターインスタンスにアタッチされた Amazon EBS ボリューム 転送中のデータ EMRからS3に転送中のデータ、またはその逆 – EMR の S3 クライアントサイド暗号化 クラスター内のノード間で転送中のデータ – Secure Socket Layer (SSL) による MapReduce の in-transit 暗号化と、Simple Authentication と Security Layer (SASL) による […]

Read More

新リリース:Amazon QuickSight Enterprise Edition

私がAmazon QuickSightについて初めて書いたのは2015年のことで(Amazon QuickSight 高速で簡単に利用できるビッグデータ用BI(Business Intelligence), 従来型ソリューションの1/10のコストで実現)、その際にStandard EditionとEnterprise Editionを用意することをお知らせしました。 Enterprise Edition 先月、私達はAmazon QuickSightのStandard Editionをリリースしました。本日、Enterprise Editionをリリースいたします。Standard Editionの機能に加え、Enterprise EditionにはActive Directoryとの統合と、データ暗号化(Encryption at Rest)が実装されています。 Enterprise EditionはAWSのマネージド・サービスとして提供しているMicrosoft Active Directory (AD)(Managed Microsoft AD)を使った認証をサポートします。これにより、AWS上で稼動しているMicrosoft ADやオンプレミスにある信頼関係をもったADを使ってQuickSightへのサインインできるようになります。どちらの方法であるにせよ、シングルサインオン(SSO)によって、ユーザがQuickSightを使い始めるのをよりクイックに、また管理を減らすことが可能になります。 あなたが企業でのQuickSight管理者であった場合、大量のユーザに対してQuickSightを一度に使えるようにしたり、パーミッションを数クリックで管理することが可能になります。これまで通りのディレクトリ操作のツールを使って管理できますし、企業のガバナンスポリシーに準拠させることも可能です。 以下の図は、どのように動作するのかを説明しています: QuickSightはSPICE (Super-fast, Parallel, In-memory Calculation Engine) によって、分析用のアドホッククエリに対して高いスケーラビリティを実現しています。Enterprise Editonはデータをアマゾンによって管理されている鍵で暗号化してSPICE内に保存し、これによりさらなるデータ保護の層を追加しています。 Enterprise Editionを始動させましょう 管理者側の作業としては、Amazon QuickSight Enterprise Editionをセットアップするのはとても簡単です。作業には、必要とされるパーミッションを持つIAMでログインします。(ドキュメントの”Sign Up for Amazon QuickSight With an Existing AWS Account“を参照してください。”Set your IAM Policy“にIAM設定についての説明があります) […]

Read More