Category: Analytics*


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

今日は、インスタンスフリートと呼ばれる Amazon EMR クラスターの新機能をご紹介します。インスタンスフリートは、インスタンスのプロビジョニングに広範囲な選択肢やインテリジェンスをもたらします。対応する加重容量やスポット入札価格 (スポットブロックを含む) を最大 5 つのインスタンスタイプのリストに追加できるようになりました。EMR は、クラスター作成時にこれらのインスタンスタイプの間でオンデマンドおよびスポット容量を自動的にプロビジョニングします。そのため、これまでよりも簡単かつ低コストに、希望のクラスター容量をすばやく取得して管理することができます。また、アベイラビリティーゾーンのリストを指定することもでき、EMR は、このうちのいずれかの AZ で最適にクラスターを起動します。また、EMR は、インスタンスをフリートの利用可能ないずれかのタイプに置換することで、スポットインスタンスの中断に備えてクラスターの再分散を続けます。その結果、クラスター容量全体を容易に管理できます。インスタンスフリートは、インスタンスグループの代わりに使用することもできます。グループと同様、クラスターには、マスター、コア、タスクフリートが作成されます。コンソールのアップデートを確認し、フリートの動作について詳しく調べてみましょう。EMR コンソールを開き、[クラスターの作成] ボタンをクリックします。なじみのある EMR プロビジョニングコンソールが表示されたら、左上隅付近にある詳細オプションに移動します。最新の EMR バージョン (インスタンスフリートは、5.0.x を除く 4.8.0 以上の EMR バージョンで使用可能) を選択し、[次へ] をクリックします。これで正常に表示されます。ハードウェアオプションの新しい [インスタンスフリート] を選択します。

Screenshot 2017-03-09 00.30.51ここで、コアグループを変更して、クラスターのニーズを満たす一組のインスタンスタイプを選択します。CoreFleetScreenshot

EMR は、最もコスト効率の高い方法で要件を満たせるように、各インスタンスフリートとアベイラビリティーゾーンの容量をプロビジョニングします。EMR コンソールでは、インスタンスタイプごとに vCPU を加重容量と簡単にマッピングできるため、vCPU を容量ユニットとして使用しやすくなります (コアフリートに合計 16 個の vCPU が必要)。vCPU ユニットが、インスタンスタイプの分量指定に関する条件に一致しない場合は、[Target capacity] セレクタを変更して、任意のユニットを追加し、容量を定義します (API/CLI によるキャパシティーユニットの消費量も変更されます)。クラスターがプロビジョニングされており、ユーザー定義のタイムアウト内に希望のスポット容量を入手できない場合は、オンデマンドインスタンスを終了またはフォールバックして、残りのキャパシティーをプロビジョニングできます。また、インスタンスフリートで使用されるこれらの機能はすべて、「AWS SDK」および「CLI」より入手できます。インスタンスフリートをプロビジョニングする方法を詳しく見てみましょう。まず、my-fleet-config.json に configuration json を作成します。

[
  {
    "Name": "MasterFleet",
    "InstanceFleetType": "MASTER",
    "TargetOnDemandCapacity": 1,
    "InstanceTypeConfigs": [{"InstanceType": "m3.xlarge"}]
  },
  {
    "Name": "CoreFleet",
    "InstanceFleetType": "CORE",
    "TargetSpotCapacity": 11,
    "TargetOnDemandCapacity": 11,
    "LaunchSpecifications": {
      "SpotSpecification": {
        "TimeoutDurationMinutes": 20,
        "TimeoutAction": "SWITCH_TO_ON_DEMAND"
      }
    },
    "InstanceTypeConfigs": [
      {
        "InstanceType": "r4.xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 1
      },
      {
        "InstanceType": "r4.2xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 2
      },
      {
        "InstanceType": "r4.4xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 4
      }
    ]
  }
]

これで、設定が完了し、AWS CLI の「emr」サブコマンドを使用して、この構成で新しいクラスターを作成できるようになりました。

aws emr create-cluster --release-label emr-5.4.0 \
--applications Name=Spark,Name=Hive,Name=Zeppelin \
--service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile="EMR_EC2_DefaultRole,SubnetIds=[subnet-1143da3c,subnet-2e27c012]" \
--instance-fleets file://my-fleet-config.json

 

追加料金をかけずに、今すぐこの機能を使用する場合は、「開始に役立つドキュメントはこちら」で詳細を確認できます。本記事を寄稿するにあたりご協力いただいた EMR サービスチームの皆様にこの場を借りて御礼申し上げます。

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 のための新しいインデックス効率パターン
  • Java REST クライアント: Java 7 で稼働してノード障害時に再試行 (またはラウンドロビン、スニッフィング、要求のログ記録) を処理するシンプルな HTTP/REST Java クライアント
  • その他の向上: 遅延ユニキャストのホスト DNS ルックアップ、再インデックス作成の自動並列タスク、update-by-query、delete-by-query、タスク管理 API による検索のキャンセル

Elasticsearch 5 による強力な新機能や機能強化により、サービスをより迅速に、より容易に提供することができ、さらにセキュリティの強化を図ることができます。マネージド型サービスである Amazon Elasticsearch Service を使うと、お客様は Elasticsearch による次のような機能を活用して、ソリューションを構築、開発、デプロイすることができます。

  • 複数のインスタンスタイプを設定
  • データストレージに Amazon EBS ボリュームを使用
  • 専用マスターノードによるクラスターの安定性の向上
  • ゾーン対応 – 同じリージョン内の 2 つのアベイラビリティーゾーンにまたがるクラスターノード割り当て
  • AWS Identity and Access Management (IAM) によるアクセスコントロールとセキュリティ
  • リソース用にさまざまな地理的場所やリージョンを活用
  • Amazon Elasticsearch ドメインのスナップショットによるレプリケーション、バックアップ、リストア
  • Amazon CloudWatch との統合による Amazon Elasticsearch ドメインメトリクスのモニタリング
  • AWS CloudTrail との統合による設定の監査
  • Kinesis Firehose および DynamoDB などの他の AWS のサービスとの統合による、リアルタイムストリーミングデータの Amazon Elasticsearch Service への読み込み

Amazon Elasticsearch Service では、ダウンタイムなしで動的な変更を行うことができます。インスタンスの追加、インスタンスの削除、インスタンスのサイズの変更、ストレージ設定の変更、その他の変更を動的に行うことができますい。上記の機能のいくつかについて、その機能を具体例でご紹介します。先日の IT/Dev カンファレンスでは、Express.js、AWS Lambda、Amazon DynamoDB、および Amazon S3 を使用して、サーバレスで従業員オンボーディングシステムを構築する方法の説明を、プレゼンテーションさせていただきました。このデモでは、架空のオンボーディングプロセス用の従業員に関する人事データを収集して、DynamoDB に保存しました。収集された従業員データを、会社の人事部門が必要に応じて検索、照会、分析するシナリオを考えてみます。オンボーディングシステムを容易に拡張して、従業員テーブルが DynamoDB Streams を使用して Lambda を起動するようにし、必要な従業員の属性を Amazon Elasticsearch Service に保存することができます。この結果、次のようなソリューションアーキテクチャとなります。

従業員レコードが入力されてデータベースに保存されるたびに、従業員データを Amazon Elasticseach Service に動的に保存してインデックスを作成する方法のみに焦点を当てます。前述の既存のオンボーディングソリューションにこの拡張機能を追加するには、以下の詳細なクラウドアーキテクチャ図に示すように、ソリューションを実装します。

従業員の Amazon Elasticsearch Service へのロードプロセスを実装する方法を見てみましょう。これは上の図に示されている最初のプロセスフローです。Amazon Elasticsearch Service: ドメイン作成 AWS コンソールにアクセスして、Elasticsearch 5 が実行されている Amazon Elasticsearch Service を確認しましょう。ご想像どおり、AWS コンソールのホームから [分析] グループの [Elasticsearch Service] を選択します。

Elasticsearch ソリューションを作成するための最初のステップは、ドメインの作成です。お気付きのとおり、Amazon Elasticsearch Service ドメインの作成時に Elasticsearch 5.1 バージョンを選択できるようになりました。今日の本題は Elasticsearch 5 のサポート開始ですので、Amazon Elasticsearch Service でのドメイン作成にあたり、もちろん 5.1 Elasticsearch エンジンのバージョンを選択します。


[Next] をクリックし、インスタンスとストレージの設定を構成して、Elasticsearch ドメインを設定します。クラスターのインスタンスタイプとインスタンス数は、アプリケーションの可用性、ネットワークボリューム、およびデータのニーズに基づいて決定する必要があります。データの不整合や Elasticsearch のスプリットブレインの問題を回避するために、複数のインスタンスを選択することが推奨されるベストプラクティスです。そこで、今回はクラスター用に 2 つのインスタンス/データノードを選択し、EBS をストレージデバイスとして設定します。

具体的なアプリケーションに必要なインスタンスの数を理解するには、AWS データベースブログの「Get Started with Amazon Elasticsearch Service: How Many Data Instances Do I Need (Amazon Elasticsearch Service をはじめよう: 必要なインスタンス数の算出方法)」の記事を参照してください。あと必要なのは、アクセスポリシーを設定してサービスをデプロイするだけです。サービスを作成すると、ドメインが初期化され、デプロイされます。

これで Elasticsearch Service を実行することができました。次は、データを入力するメカニズムが必要です。DynamoDB Streams を使用して、Amazon Elasticsearch Service への従業員データの動的なデータロードプロセスを実装します。Amazon DynamoDB: テーブルとストリーム DynamoDB コンソールに着手する前に、まずは基本を簡単に確認しましょう。 Amazon DynamoDB はスケーラブルな分散 NoSQL データベースサービスです。DynamoDB Streams は、すべての CRUD オペレーションの順序付けられた時間ベースのシーケンスを DynamoDB テーブル内の項目に提供します。各ストリームレコードには、テーブル内の個々の項目のプライマリ属性の変更に関する情報が含まれています。ストリームは非同期で実行され、実質的にリアルタイムでストリームレコードを書き込むことができます。さらに、ストリームはテーブルの作成時に有効にでき、また既存のテーブルで有効にして変更することができます。DynamoDB Streams の詳細については、「DynamoDB 開発者ガイド」を参照してください。それでは DynamoDB コンソールから、OnboardingEmployeeData デーブルを確認しましょう。

このテーブルには、プライマリパーティションキー UserID があり、これは文字列データ型です。さらにプライマリソートキー Username があり、これも文字列データ型です。ここでは UserID を Elasticsearch のドキュメント ID として使用します。さらにこのテーブルではストリームが有効で、ストリームの表示タイプは New image です。表示タイプが New image に設定されたストリームには、更新された後に項目レコード全体を表示するストリームレコードがあります。ストリームが、変更前のデータ項目を提供するレコードを表示するようにすることもできます。また項目のキー属性のみを提供したり、古い項目と新しい項目の情報を提供したりすることもできます。AWS CLI を使用して DynamoDB テーブルを作成する場合、取得するキー情報は [Stream Details] セクションの下に表示される 最新のストリーム ARN です。DynamoDB ストリームには一意の ARN 識別子があります。これは DynamoDB テーブルの ARN の外にあります。ストリーム ARN は、ストリームと Lambda 関数の間のアクセス権限の IAM ポリシーを作成するために必要です。

IAM ポリシー あらゆるサービスの実装で第一に重要なことは、適切なアクセス権限を設定することです。このため、まずは IAM コンソールを使って、DynamoDB と Elasticsearch にアクセス権限を設定する、Lambda 関数のロールとポリシーを作成します。まず、DynamoDB ストリームを使用した Lambda の実行のための既存の管理ポリシーに基づくポリシーを作成します。

すると次にポリシーの確認画面に移ります。ここでは選択された管理ポリシーの詳細が表示されます。ここでは、このポリシーの名前を Onboarding-LambdaDynamoDB-toElasticsearch として、ソリューション用にポリシーのカスタマイズを行います。現在のポリシーでは、すべてのストリームがアクセス可能であることに注意します。推奨されるベストプラクティスは、最新のストリーム ARN を追加して、このポリシーで特定の DynamoDB ストリームのみがアクセスできるようにすることです。ポリシーを変更して、DynamoDB テーブル OnboardingEmployeeDataARN を追加し、ポリシーを検証します。変更されたポリシーは次のようになります。

あとは、Amazon Elasticsearch Service のアクセス権限をポリシーに追加するだけです。Amazon Elasticsearch Service のアクセス権限のコアポリシーは次のとおりです。

このポリシーを使って、特定の Elasticsearch ドメインの ARN を、ポリシーのリソースとして追加します。これにより、ポリシーのセキュリティのベストプラクティスである、最小権限の原則を適用したポリシーを活用することができます。次のように Amazon Elasticsearch Service ドメインを追加して、ポリシーを検証して保存します。

カスタムポリシーを作成する最も望ましい方法は、IAM Policy Simulator を使用するか、またはサービスドキュメントの AWS のサービスのアクセス権限の例を参照することです。AWS のサービスのサブセットのポリシーの例については、こちらを参照することもできます。最小権限の原則によるセキュリティのベストプラクティスを適用して、必要な ES のアクセス権限のみを追加してください。上記は単なる一例です。アクセスを許可するために Lambda 関数が使用するロールを作成し、そのロールに前述のポリシーをアタッチします。

AWS Lambda: DynamoDB がトリガーする Lambda 関数 AWS Lambda は、アマゾン ウェブ サービスのサーバーレスコンピューティングサービスの中心となるものです。Lambda を使うと、サポートされた言語を使って、事実上あらゆる種類のアプリケーションやバックエンドサービスのコードを作成して実行できます。Lambda は、AWS のサービスまたは HTTP リクエストからのイベントに対応して、コードをトリガーします。Lambda はワークロードに基づいて動的にスケールします。コードの実行に対してのみ料金を支払います。DynamoDB ストリームが Lambda 関数をトリガーし、それによりインデックスが作成され、データが Elasticsearch に送信されます。もう 1 つの方法は、DynamoDB の Logstash プラグインを使用することです。ただし、Logstash プロセッサのいくつかは Elasticsearch 5.1 コアに組み込まれ、さらにパフォーマンスの最適化が向上されているため、今回は Lambda を使用して DynamoDB ストリームを処理し、Amazon Elasticsearch Service にデータをロードすることにします。では AWS Lambda コンソールを使って、Amazon Elasticsearch Service に従業員データをロードするための Lambda 関数を作成しましょう。コンソールでブランク関数設計図を選択して、新しい Lambda 関数を作成します。次に [Configure Trigger] ページに移ります。トリガーページで、Lambda をトリガーする AWS のサービスとして DynamoDB を選択し、トリガー関連オプションとして次のように入力します。

  • テーブル: OnboardingEmployeeData
  • バッチサイズ: 100 (デフォルト)
  • 開始位置: 水平トリム

[Next] をクリックすると、関数の設定画面に移動します。関数の名前を ESEmployeeLoad とし、この関数を Node.4.3 で作成します。

Lambda 関数のコードは次のとおりです。

var AWS = require('aws-sdk');
var path = require('path');

//すべての ElasticSearch ドメイン情報のオブジェクト
var esDomain = {
    region: process.env.RegionForES,
    endpoint: process.env.EndpointForES,
    index: process.env.IndexForES,
    doctype: 'onboardingrecords'
};
//作成された ES ドメインエンドポイントからの AWS エンドポイント
var endpoint = new AWS.Endpoint(esDomain.endpoint);
//AWS 認証情報は環境から取得される
var creds = new AWS.EnvironmentCredentials('AWS');

console.log('Loading function');
exports.handler = (event, context, callback) => {
    //console.log('Received event:', JSON.stringify(event, null, 2));
    console.log(JSON.stringify(esDomain));
    
    event.Records.forEach((record) => {
        console.log(record.eventID);
        console.log(record.eventName);
        console.log('DynamoDB Record: %j', record.dynamodb);
       
        var dbRecord = JSON.stringify(record.dynamodb);
        postToES(dbRecord, context, callback);
    });
};

function postToES(doc, context, lambdaCallback) {
    var req = new AWS.HttpRequest(endpoint);

    req.method = 'POST';
    req.path = path.join('/', esDomain.index, esDomain.doctype);
    req.region = esDomain.region;
    req.headers['presigned-expires'] = false;
    req.headers['Host'] = endpoint.host;
    req.body = doc;

    var signer = new AWS.Signers.V4(req , 'es');  // es: サービスコード
    signer.addAuthorization(creds, new Date());

    var send = new AWS.NodeHttpClient();
    send.handleRequest(req, null, function(httpResp) {
        var respBody = '';
        httpResp.on('data', function (chunk) {
            respBody += chunk;
        });
        httpResp.on('end', function (chunk) {
            console.log('Response: ' + respBody);
            lambdaCallback(null,'Lambda added document ' + doc);
        });
    }, function(err) {
        console.log('Error: ' + err);
        lambdaCallback('Lambda failed with error ' + err);
    });
}

Lambda 関数の環境変数は次のとおりです。

既存のロールのオプションで ESOnboardingSystem を選択します。これは先に作成した IAM ロールです。

Lambda 関数のための IAM ロールのアクセス権限を完成したら、Lambda 関数の詳細を確認し、ESEmployeeLoad 関数の作成を完了します。

Elasticsearch との通信を行う Lambda 関数の構築プロセスは、これで完了です。では、データベースへのデータ変更のシミュレーションを行って、関数のテストを行いましょう。

関数 ESEmployeeLoad は、オンボーディングシステムのデータベースでのデータの変更により実行されます。また、CloudWatch ログを確認することにより、Lambda 関数の Elasticsearch への処理を確認できます。さらに Lambda 関数を変更して新機能を利用したり、直接 Elasticsearch を使って新しい取り込みモードを利用することもできます。たとえば、従業員レコードドキュメントのパイプラインを実装することができます。

この関数を複製して、従業員レコードに合わせてバッジを更新する処理や、従業員データに対するその他のプリプロセッサを活用したりすることができます。たとえば、Elasticsearch ドキュメントのデータパラメーターに基づいてデータを検索する場合、検索 API を使用してデータセットからレコードを取得できます。

可能性は無限です。データのニーズに応じて創造性を発揮しながら、優れたパフォーマンスを確保できます。Amazon Elasticsearch Service: Kibana 5.1 Elasticsearch 5.1 を使用しているすべての Amazon Elasticsearch Service ドメインでは、オープンソースの可視化ツールの最新バージョンである Kibana 5.1 が備えられています。可視化と分析のための補完プラットフォームである Kibana も、Kibana 5.1 リリースで機能強化されました。Kibana を活用すると、さまざまなグラフ、テーブル、マップを使用して、Elasticsearch データの表示、検索、操作を行うことができます。さらに、Kibana は大量データの高度なデータ分析を実行できます。Kibana リリースの主な機能強化は次のとおりです。

  • 可視化ツールの新しいデザイン: カラースキームの更新と表示画面活用の最大化
  • Timelion: 時間ベースのクエリ DSL による可視化ツール
  • コンソール: 従来 Sense と呼ばれていた機能がコア機能の一部となりました。以前と同様の設定を使って、Elasticsearch へのフリーフォームのリクエストを行うことができます
  • フィールドスクリプト言語: Elasticsearch クラスターで新しいスクリプト言語 Painless を使うことが可能
  • タグクラウドの可視化: 5.1 では、データの重要度による単語ベースのグラフィカルビューが追加されました
  • グラフの拡張: 前回削除されたグラフが復活し、さらに X-Pack の高度なビューが追加されました
  • Profiler の UI: ツリービューによる Profile API の拡張を提供
  • レンダリングパフォーマンスの向上: パフォーマンスを向上させ、CPU 負荷を低減

まとめ ご覧いただいたように、このリリースでは Elasticsearch ソリューションの構築に役立つ、広範な機能強化や新機能を備えています。Amazon Elasticsearch Service では新たに、15 個の Elasticsearch API と 6 つのプラグインをサポートします。Amazon Elasticsearch Service は Elasticsearch 5.1 の次のオペレーションをサポートします。

Elasticsearch でサポートされるオペレーションの詳細については、「Amazon Elasticsearch 開発者ガイド」を参照してください。また Amazon Elasticsearch Service のウェブサイトを活用したり、AWS マネジメントコンソールにサインインして開始することもできます。- Tara

 

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 をはじめよう: インスタンス数の見積もり方法をご覧ください。

データの送信やクエリをクラスタに対して行っていく中で、クラスタのパフォーマンスを元に、継続的にリソースのユーセージを評価しながら、シャード数を調整していきます。

シャードとは?

What is Shard

サーチエンジンには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)されるのを待ってから呼び出し元に書き込み成功のレスポンスを行います。プライマリとレプリカシャードはデータの保存に冗長性をもたらし、データのロスを起こりにくくします。

ES Cluster 1

この図の例では、Elasticsearchクラスタは3つのデータインスタンスを保持しています。緑と青の2つのインデックスがあり、それぞれ3つのシャードがあります。それぞれのシャードのプライマリは赤枠で囲われています。それぞれのシャードにはレプリカがあり、それらに枠はありません。Elasticsearchはいくつかのルールを元にシャードをインスタンスに配置します。最も基本的なルールとして、プライマリとレプリカのシャードを同じインスタンスに配置しない、というものが挙げられます。

最初にストレージにフォーカスする

お客様のワークロードには2つの種類があります: シングルインデックスとローリングインデックス。シングルインデックスのワークロードは、全てのコンテンツを保持する”source of truth”な外部のリポジトリを使い、データは一つのインデックスに保持されます。ローリングインデックスのワークロードは、データを継続的に受け取り、データはタイムスタンプによって(通常は1日24時間)異なるインデックスに保持されます。

それぞれのワークロードにおけるシャーディングの計算のスタート地点は、インデックスに必要なストレージサイズです。それぞれのシャードをストレージの単位として扱うと、いくつのシャードが必要になるかのベースラインを見出すことが出来ます。シングルインデックスのワークロードであれば、トータルのストレージ容量を30GBで割って最初に必要なシャード数を算出します。ローリングインデックスのワークロードの場合は一期間のインデックスのサイズを30GBで割ることで最初のシャード数を算出します。

シングルシャードを恐れるな!

もし、あなたのインデックスのサイズが30GB以下であるのであれば、一つのシャードのみを使うべきです。”more is better”というガッツフィーリングをお持ちの方もいらっしゃいますが、誘惑を断ち切りましょう! シャードは処理とストレージのエンティティであり、あなたが追加するシャードによってインデックスに対するリクエストはアディショナルなCPUに分散されて処理されます。必要以上のプロセッサーを使うことで、その管理や処理結果の結合などに追加で処理が必要になり、パフォーマンスが下がることにつながります。scatter-gatherなクエリおよびレスポンスにおけるネットワークのオーバーヘッドもかかるでしょう。

シャード数の設定

Elasticsearchのインデックス作成APIを叩いく際にシャード数を設定します。Amazon Elasticsearch ServiceでのAPIコールは以下のようになります:

>>> curl –XPUT https://search-tweets-EXAMPLE.us-west-2.es.amazonaws.com/tweet -d '{
  "settings": {
    "index" : {
      "number_of_shards": 2,
      "number_of_replicas": 1
    }
  }
}'

シングルインデックスのワークロードの場合、この設定を行うのはインデックスを最初に作成する際の1回のみですが、ローリングインデックスのワークロードの場合、インデックスを定期的に作成することになります。その場合は _template APIを使って、テンプレートにマッチする新しいインデックスには自動的に設定が適用されるようにします。

>>> curl –XPUT https://search-tweets-EXAMPLE.us-west-2.es.amazonaws.com/_template/template1 -d '{
  "template": "logs*",
  "settings": {
    "index" : {
      "number_of_shards": 2,
      "number_of_replicas": 1
    }
  }
}'

この例では、”log”というプレフィックスで作られたインデックスは、2つのシャードと1つのレプリカを保持します。

ワークロードに合わせた調整

今回カバーした内容は最もシンプルなシャーディングに関することでしたが、今後のポストではユーセージを元にしたシャード数の調整といったネクストレベルなところまで踏み込む予定です。もし、はじめたばかりであれば、30GBでインデックスのサイズを割り算することでシャード数を算出しましょう。データをインデックスに投入する前にシャード数を設定するのをお忘れなく。

あなたのシャーディングアドベンチャーのエピソードを是非お聞かせください!

Amazon Elasticsearch Serviceのより詳細な情報に関しては、https://aws.amazon.com/jp/elasticsearch-service/ をご覧ください。

 

原文:Get Started with Amazon Elasticsearch Service: How Many Shards Do I Need?(翻訳:篠原 英治)

 

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

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

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

(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データセットをスケジュールリフレッシュする

schedule refresh
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)

 

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

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。

こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。

暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。

o_Amazon_EMR_Encryption_1_

この投稿では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) による Spark の shuffle 暗号化
  • ディスクに溢れたデータ、またはシャッフルフェーズの最中にキャッシュされたデータ – Spark の shuffle 暗号化、またはLUKS 暗号化

暗号化の手順

この投稿のために、転送中、保存時の暗号化に使うためのセキュリティ設定を作りましょう。

  • EMRやS3にあるデータに対して、LUKS 暗号化やS3 クライアントサイド暗号化のための KMS キー
  • MapReduce のshuffle 暗号化で使用する SSL 証明書
  • EMR クラスタが立ち上げられる環境。プライベートサブベットで EMR を立ち上げて、S3 からデータを取得するための VPC エンドポイントを設定します
  • EMR セキュリティ設定

この手順で説明するすべてのスクリプトとコードスニペットは、aws-blog-emrencryption Github レポジトリから取得できます。

KMS キーの生成

この手順では鍵管理について、データやディスクを暗号化するために使用する暗号化キーを、簡単に生成、管理できるマネージドサービスの、AWS KMS を使用します。

2つの KMS マスターキーを生成します。ひとつは EMR外のデータを暗号化する S3 クライアントサイド暗号化キーとして、もうひとつはローカルディスクを暗号化するための LUKS 暗号化のキーとして使用します。 Hadoop MapReduce フレームワークは HDFS を使用します。Spark は、ワークロードの中でメモリから溢れた中間データを一時的に保存する先として、各スレーブインスタンスのローカルファイルシステムを使用します。

鍵を生成するために、kms.json という AWS CloudFormation スクリプトを使用します。スクリプトの中で、キーの エイリアス名またはディスプレイ名を指定します。エイリアスは “alias/エイリアス名” 形式で、エイリアス名はアルファベット、アンダースコア、ダッシュのみで構成される必要があります。

o_Amazon_EMR_Encryption_2

キーの作成が終わったら、Outputs として ARN が表示されます。

o_Amazon_EMR_Encryption_3

SSL 証明書の作成

SSL 証明書によって、Mapreduce のシャッフル中にデータがノード間を転送されるときに、データの暗号化が行われます。

o_Amazon_EMR_Encryption_4

この手順では、OpenSSL で 2048-bit RSA 秘密鍵による X.509 自己署名証明書を作成します。これを使って EMR クラスタのインスタンスにアクセスします。画面に従って、証明書発行に必要な情報を入力します。

cert-create.sh を使って、zip ファイルに圧縮した SSL 証明書を生成します。zip 圧縮済みの証明書を S3 にアップロードし、S3 のプレフィックスをメモしておきます。セキュリティ設定を構成するときには、この S3 プレフィックスを使用します。

重要
この例は、あくまで proof-of-concept のデモにすぎません。自己署名証明書を使うことは推奨されませんし、潜在的なセキュリティリスクを孕みます。実運用システムでは、信頼できる認証局が発行した証明書を使ってください。

カスタムプロバイダの証明書には、TLSArtifacts プロバイダインタフェースを使用してください。

環境の構築

EMR クラスタをプライベートサブネットに構築します。もしすでに VPC があり、パブリックサブネットにクラスターを立てたい場合には、このセクションを飛ばして、セキュリティ設定の作成のセクションに進んでください。

クラスターをプライベートサブネット内に立てるためには、以下のリソースが必要です。

  • VPC
  • プライベートサブネット
  • パブリックサブネット
  • 踏み台サーバ
  • マネージド NAT ゲートウェイ
  • S3 VPC エンドポイント

EMR クラスターをプライベートサブネットに立てる際には、クラスターに SSH で入るための踏み台サーバかジャンプサーバが必要になります。クラスターの起動が終わったら、KMS からデータキーを取得するためにインターネットに接続する必要があります。プライベートサブネットからは直接インターネットに接続できないので、マネージド NAT ゲートウェイ経由でトラフィックの経路を制御します。S3 に対して、高信頼性を確保して安全に接続するために、S3 VPC エンドポイントを使用します。

o_Amazon_EMR_Encryption_5

CloudFormation コンソールで、environment.json テンプレートを使って、環境構築用の新しいスタックを作成します。

パラメタとして、踏み台サーバのインスタンスタイプと、そのサーバに SSH アクセスするための EC2 キーペアを入力します。適切なスタック名とタグを指定します。例えば、私の作成したスタックのレビューステップのスクリーンショットは、以下の通りになります。

o_Amazon_EMR_Encryption_6

スタックの作成が終わったら、Outputs タブを開いて VPC、踏み台サーバ、プライベートサブネットのIDをメモしておきます。これらはあとで EMR クラスタを立ち上げる際に使用します。

o_Amazon_EMR_Encryption_7

セキュリティ設定の作成

セキュアな EMR クラスタを立ち上げる前の最終ステップは、セキュリティ設定の構成です。EMR の S3 クライアントサイド暗号化と、先ほど作成した KMS キーを用いたローカルファイルの LUKS 暗号化について、セキュリティ設定を作成します。さらに MapReduce のシャッフルで暗号化を行うために、先ほど作成して S3 にアップロードしておいた SSL 証明書も使用します。

o_Amazon_EMR_Encryption_8

EMR クラスターの立ち上げ

さて、これでプライベートサブネットに EMR クラスタを立ち上げることができるようになりました。まずサービスロールとして、サービスポリシー内の AmazonElasticMapReduceRole が EMR に割り当てられていることを確認します。デフォルトのサービスロールは EMR_DefaultRole です。詳しくはIAMロールを使用したユーザーアクセス権限の設定を参照してください。

環境の設定セクションでメモしておいた VPC ID とサブネット ID の中で、EMR クラスタを立ち上げます。Network EC2 Subnet フィールドで、それらの値を選択してください。続いてクラスタの名前とタグを入力します。

o_Amazon_EMR_Encryption_9

最後のステップはプライベートキーの選択です。ここでは、セキュリティ設定の作成セクションで作っておいたセキュリティ設定を適用します。そして Create Cluster をクリックします。

o_Amazon_EMR_Encryption_10

これで作成した環境の上で、クラスタが立ち上がりました。続いてマスターノードに入ってスクリプトを実行します。EMR コンソールページからクラスタの IP アドレスを取得します。HardwareMaster Instance Group と選択して、マスターノードのプライベート IP アドレスをメモします。

o_Amazon_EMR_Encryption_11

マスターノードはプライベートサブネット内にあるので、まず踏み台サーバに SSH で入り、そこからさらにマスターノードに接続します。踏み台サーバと Hadoop マスタへの SSH については、ssh-commands.txt ファイルをみてください。踏み台サーバへのアクセスについてのさらなる詳細は、Securely Connect to Linux Instances Running in a Private Amazon VPC のエントリーを参照してください。

マスターノードに入った後は、Hive や Spark のスクリプトを実行します。動作確認用として、GitHub /code ディレクトリには PySpark の test.py と Hiveの test.q スクリプトが含まれています。

まとめ

この投稿の中で、データの暗号化が必要な複数のパターンについて述べ、各パターンでどうやって暗号化するかについての手順を説明しました。そして暗号化の前提要件である KMS キーの作成、SSL 証明書の発行、強力なセキュリティ設定による EMR クラスタの立ち上げについて、順を追って解説しました。そして VPC 内のプライベートサブネットでのクラスター起動によって、データをセキュアに
保つとともに、EMR クラスターにアクセスするために踏み台サーバを活用することができました。

もし疑問や助言があれば、ぜひおしらせください。

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

新リリース: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を一度に使えるようにしたり、パーミッションを数クリックで管理することが可能になります。これまで通りのディレクトリ操作のツールを使って管理できますし、企業のガバナンスポリシーに準拠させることも可能です。
以下の図は、どのように動作するのかを説明しています:

qs_ee_ad_setup_1

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設定についての説明があります)

Enterprise Editionを選択し、あなたのユーザコミュニティを管理するAWSマネージドのADを選択して、ディレクトリへのアクセス権限を与えます。そしてディレクトリにエリアスを追加し、それをQuickSightのアカウント名として使用します。最後にマネージドAD、もしくは信頼されたフォレスト(Trusted forest)上にあるADグループを選択し、QuickSightアクセス用に有効化します。

qs_ee_create_account_1

サインアッププロセスが完了すると、設定したグループに所属するユーザはQuickSightのアカウント名(ディレクトリエリアス)とADのクリデンシャルでQuickSightにログインをすることが出来るようになります。

パスワードの制限、タイムアウト、ユーザ管理は、そのAD(AWSに上、もしくはオンプレミス)上で設定し、所属企業のポリシーに従うことが可能です。既存のツールを使ってグループのメンバーシップをマネージでき、必要に応じてユーザを追加・削除する管理タスクを実行することが可能になります。

費用、および利用可能リージョン

Amazon QuickSight Enterprise EditionのAD連携機能はUS East(北バージニア)リージョンでのみ利用可能です。Enterprise Editionのもう一つの機能であるデータの暗号化については、US East(北バージニア)、US West (オレゴン)、EU (アイルランド)で利用可能です 。費用は1ヶ月・1ユーザあたり$18からで利用でき、10GB分のSPICEキャパシティが含まれます。このSPICEキャパシティはアカウント内のユーザで共有されます(QuickSightの無料枠(Free tier)や、4ユーザまで利用できる60日間トライアルでも、SPICEストレージが共有されるという考え方は同様です)。詳細はQuickSightの価格ページを確認してください。

すでにUS East (北バージニア)リージョンでMicrosoft ADのインスタンスを利用されている場合、無料枠やフリートライアルを使って、追加コスト無しでEnterprise Editionを本日から利用いただくことが可能です。

原文:https://aws.amazon.com/jp/blogs/aws/new-amazon-quicksight-enterprise-edition/

翻訳:下佐粉 昭 (simosako@)

S3のデータをAmazon Athenaを使って分析する

Amazon Athenaは対話型クエリサービスで、標準的なSQLを使ってAmazon S3の直接データを直接分析することを簡単にしてくれます。Athenaはサーバレスなので、インフラを構築したり管理する必要はなく、今すぐにデータ分析を始めることができます。Athenaはデータをロードしたり、複雑なETL処理をする必要すらありません。S3に保存されているデータに直接クエリすることができます。

Athenaは、クエリを実行する際に分散SQLエンジンのPrestoを利用しています。また、テーブルを作成、削除、変更、パーティションするためにApache Hiveも利用しています。Hive互換のDDL文や、ANSI SQL文をAthenaクエリエディタ内で書くことができます。複雑なJOINやウィンドウ関数、そして複雑なデータ型をAthenaで使うこともできます。Athenaはschema-on-readとして知られるアプローチを取っていて、クエリを実行する時にデータに対してスキーマを定義することができます。これによって、データロードやETLを必要としていません。

Athenaはクエリ毎にスキャンしたデータの量に応じて課金します。データをパーティションしたり、圧縮したり、またはApache Parquet等の列指向フォーマットに変換することでコストを抑えパフォーマンスを向上させることができます。詳しくはAthenaの料金ページをご覧ください。

この記事では、既に決められた形式のテキストファイルで生成されるElastic Load Balancingのログに対して、どのようにAthenaを使うかをお見せします。テーブルを作成し、Athenaで使われる形式でデータをパーティションして、それをParquetに変換してから、クエリのパフォーマンスを比較してみます。

(more…)

Auto Scalingを利用して、Amazon EMRのアプリケーションを動的にスケールする

Apache SparkやPresto、Apache Hadoopエコシステムを利用しているお客様は、ワークフローの完了次第クラスターを終了させることや、安価なAmazon EC2スポットインスタンスを利用してクラスターをリサイズをすることよってコスト節約するために、Amazon EMRの弾力性を活用しています。例えば、お客様は日次のETLや機械学習処理のためにクラスターを作成し、それらの処理が完了したらクラスターを終了させるということや、BI分析者がアドホックでレイテンシーの低いSQLをAmazon S3に置かれたデータに対して行えるよう、業務時間帯のみPrestoクラスターをスケールアウトする、ということが可能です。

Amazon EMRリリース4.xと5.xで新しくサポートされたAuto Scalingによって、お客様は、クラスターのノードを、より簡単に追加(スケールアウト)や削除(スケールイン)できます。スケーリングの動作は、EMRから提供される5分間隔のAmazon CloudWatchメトリクスによって、自動的にトリガーされます。トリガーになるメトリクスには、メモリ利用、未実行アプリケーションの状態、HDFS利用、に関連するいくつかのYARNメトリクスも含まれます。

EMRリリース5.1.0には、2つの新しいメトリクスが導入されました。YARNMemoryAvailablePercentageとContainerPendingRatioです。これらは、Apache SparkやApache Tez、そして、Apache Hadoop MapReduceのような、スケーラブルなYARNベースのフレームワーク向けの、クラスターの利用状況を知るのに便利なメトリクスです。さらに、お客様は、カスタムCloudWatchメトリクスをAuto Scalingポリシーに利用することもできます。

以下は、最大40・最小10インスタンスで、一度に1インスタンスずつ増減する、インスタンスグループに対するAuto Scalingポリシーの例示です。インスタンスグループは、YARN内の利用可能なメモリが15%を下回ると、スケールアウトし、75%を上回るとスケールインします。また、インスタンスグループは、割り当てられているYARNコンテナに対するYARNコンテナの未実行率が0.75になった場合も、スケールアウトします。

さらに、お客様は、EMR 5.1.0のクラスターによってノードが終了される際に、スケールダウンの振る舞いを設定することができます。デフォルトで、EMRは、いかなるタイミングで終了リクエストが投げられたとしても、インスタンス時間単位の境目に実施されるスケールインイベントの最中のみ、ノードの停止を行います。これは、EC2は、いつインスタンスを終了したかに関わらず、時間単位で請求をするためです。この振る舞いによって、クラスター上で実行されているアプリケーションは、コスト効率をより高く、動的にスケールする環境で、インスタンスを利用することができます。

反対に、5.1.0より前のEMRリリースでは、お客様は、以前のデフォルト設定を利用できます。インスタンス時間単位の境目に近接しているかどうかを考慮せず、ノードを終了する前に、ノードをブラックリストしたり、タスクを排出したり、ということが可能です。いずれの振る舞いにおいても、EMRは、まず最も動きの少ないノードを削除しますし、HDFSの不整合を招き得る場合は、終了処理をブロックします。

EMRコンソール、AWS CLI、または、AWS SDKのEMR APIを利用して、Auto Scalingポリシーの作成や変更ができます。Auto Scalingを有効にするためには、Auto Scalingで容量の追加・削除を行うための権限を付与すべく、追加のIAMロールをEMRに与える必要があります。さらに詳細な情報は、Amazon EMRでのAuto Scalingを確認して下さい。また、もし、EMRでのAuto Scalingに関して、ご質問や公開したい面白い事例などございましたら、コメントを下に書いていただければと存じます。

原文: Dynamically Scale Applications on Amazon EMR with Auto Scaling (翻訳: 半場 光晴)

Amazon QuickSightが一般提供開始 – 高速で利用が簡単なビッグデータ用ビジネスアナリティクス

1,500以上のスタートアップからグローバルエンタープライズまでのAWSカスタマーが参加したプレビュー期間を経て、 Amazon QuickSightが一般提供開始(Generally Available:GA)になった事を発表いたします!去年、プレビューへのお誘いのブログエントリで、私は以下のように書きました:qs_net_tty_1

これまではビジネスインテリジェンス(Business Intelligence, BI)を実現するには対処方法が不明確で複雑な作業が大量に必要でした。インフラとソフトウェアをセットアップし、ユーザが不満に思わないようにシステムをスケールさせるために多くの費用が必要で、データからモデルを作成するために高給のコンサルタントを雇う必要がありました。システムが出来上がったあとは、ユーザは複雑なユーザインターフェースに不満を覚え、モバイルデバイスからデータを分析できるようにするリクエストを受けることになります。さらにNoSQLやストリーミングデータも含めて分析したいですって?幸運を祈ります!

Amazon QuickSightは、高速で使いやすくクラウドの力で構築されたビジネスアナリティクスをトラディショナルなオンプレミスBIシステムと比較して1/10のコストで提供します。QuickSightは数分で利用開始することが可能です。ログインし、データソースを指定すればデータを可視化(Visualize)できるようになります。その背後でSPICE(Super-fast, Parallel, In-Memory Calculation Engine)があなたのクエリを高速に処理し、結果を美しく可視化します。

データにディープダイブする

私が会話したお客様はみな、保存したデータからより多くの価値を得たいを考えておられました。彼らは価値を生む可能性がデータの中に埋もれており、そのデータが日々増えているということを理解していました。しかし、データから価値を取り出すことはとても高くつき、難易度が高いということを学習し、しばしば落胆していました。オンプレミスのビジネスアナリティクスツールは高価なライセンスが必要であり、既存のインフラに大きい負荷を追加する必要がありました。このライセンスコストと高い難易度は、ツールを利用できる人間をごく一部に制限してしまっていました。これらの要因が合わさることにより、多くの組織は自分たちが本当にビジネスアナリティクスの機能に投資をできる状態には無いと結論付けてしまっていました。

QuickSightはこういった状態を変えます!サービスとして実行され、全てのタイプ・全てのサイズの組織にビジネスアナリティクスをもたらします。高速で使うのが簡単であり、既存のインフラに負荷を追加することなく、わずか1ユーザあたり1ヶ月$9からという費用で利用を開始することが可能です。

使い始めるとすぐに分かるように、QuickSightは異なる場所に格納された多種多様なサービスのデータにアクセスすることが可能です。Amazon Redshiftデータウェアハウスや、Amazon Relational Database Service (RDS) 、S3上に置かれたフラットファイルからデータを取得することが可能です。オンプレミス上のMySQL、PostgreSQL、SQL Server、もしくはMicrosoft ExcelのスプレッドシートやSalesforce等の外部サービスにもデータコネクターを使うことでアクセスが可能です。

QuickSightはお客様の利用に合わせてスケールします。ユーザやデータソースを追加したり、新たなデータを追加した場合でもDC上でハードウェアを増強したり、長期契約のライセンスを追加購入する必要はありません。

ツアーに出かけましょう

QuickSightをめぐるツアーに出かけましょう。組織の管理者が、すでに私をQuickSightに招待(Invite)してくれています。これでもうログインしてスタート出来る状態にすでになっています。こちらがメインスクリーンです:

qs_main_screen_turn_on_how_are_you_gentlemen_1

Redshiftクラスターからデータを取得するところから始めたいと思います。Manage dataをクリックして、存在するデータセットを確認します:

qs_all_my_data_are_belong_to_me_1

欲しいものが無いようですので、New data setを押して別の方法をとることにします:

qs_data_sources_to_the_edge_3

Redshift(Manual connect)をクリックし、認証情報を入力します。これでデータウェアハウスにアクセスできるようになりました(もし私が自分のAWSアカウント内にRedshiftクラスターを稼動させている場合は、自動ディスカバリによりデータソースとして最初から現れているでしょう):

qs_new_data_source_dude_2

QuickSightはデータウェアハウスをクエリし、スキーマ(テーブルのセット)の一覧と、存在するテーブル一覧を見せてくれます。publicというスキーマを選択し、all_flightsテーブルから始めることにします:

qs_pick_a_table_1

ここで2つの選択肢があります。テーブルをSPICEにインポートしてアナリティクスの速度を上げる方法、もしくはクエリをウェアハウスで直接実行する方法です。ここではSPICEにデータをインポートします:

qs_import_spice_dune_1

もう一度2つの選択肢があります!Edit/Preview dataを選択してどの行や列をインポートするかを選択するか、もしくはVisualizeをクリックして全データをインポートし、楽しいパートをすぐに開始するかです!ここではEdit/Previewを選択しましょう。左側にフィールド(Fields)が確認でき、ここから必要な列だけにチェックボックスを付けて選択することができます:

qs_data_see_me_3

New Filterを選択してポップアップメニューからフィールドを選択し、フィルター(絞り込み条件)を作成することもできます:

qs_edit_my_filter_baby_1

それぞれの選択肢(フィールドを選択、列を選択)によりSPICEにインポートするデータをコントロールすることが可能です。つまり可視化したいデータを自分でコントロールすることができ、メモリをより効率的に利用することを可能にします。準備が完了したら、Prepare data & visualizeをクリックします。この時点でSPICEにデータがインポートされ、そのデータを使った可視化が可能になります。ここではシンプルにフィールドを選択して開始します。例えばorigin_state_abbrフィールドを選択して、それぞれの州を出発点としたフライトがどれぐらいあるのかを確認します:

qs_air_by_state_1

右側の縮小ビュー(右側の縦長いスクロールバー)を使うと追加の情報を得られます。スクロールアップ・ダウンして表示するレンジを調整することが可能です。データからもっと知見を得るためめに上部の2つ目のフィールドをクリックします。flightsをクリックし、ソート順をdescending(大きい順)とし、スクロールバーで一番上までスクロールします。これにより、それぞれの州からどれぐらいのフライトがあるかを自分のデータから取得し、確認することができます:

qs_air_by_state_and_flights_1

QuickSightのAutoGraph(オートグラフ)は、選択したデータをもとに自動的に適切なビジュアルを使用します。例えば、fl_data_fieldを追加すると、州ごとの折れ線グラフが表示されます:

qs_origin_flight_date_line_1

また、クエリやデータ型、もしくはデータの特質に応じてQuickSightは他の表現方法を提案します:

qs_try_this_instead_2

縦&横棒グラフ、折れ線グラフ、ピボットテーブル、ツリーマップ、パイチャート、ヒートマップなど多くの他のビジュアルから自分で選択することも可能です:

qs_pick_a_vis_1

効果的なビジュアルを作成した後は、それらをキャプチャし、ストーリーボードに結果をまとめることによって、データドリブンのストーリーを伝えることが可能になります:

qs_story_1

これらビジュアルを同僚と共有することも可能です:

qs_share_the_love_1

最後に、作成したビジュアルにモバイルデバイスからアクセスしてみましょう:

qs_ip_image1_1   qs_ip_image2_1b

価格とSPICEキャパシティ

QuickSightは1ユーザかつ1GBのSPICEのキャパシティを無料で永続的に利用することが可能です。これによりAWSユーザは追加コスト無しでビジネスインサイトを得ることが可能になります。Amazon QuickSightのStandard Editionは$9/月で開始することができ、それには10GBのSPICEキャパシティが含まれています(詳細はプライスのページをご覧ください)。

SPICEキャパシティの管理は簡単です。メニューからManage QuickSightを選択し(変更にはQuickSightのADMIN権限が必要です):

qs_manage_menu_1

すると現在の状況を確認できます:

qs_yum_pumpkin_spice_1

Purchase more capacity をクリックしてキャパシティを追加購入することが出来ますし、:

qs_more_spice_please_1

Release unused purchased capacityをクリックすることで使用していない分のSPICEキャパシティを削減することが可能です:

qs_take_my_spice_please_1

今日から使い始めましょう

Amazon QuickSightは、US East (Northern Virginia)、US West (Oregon)、 EU (Ireland)リージョンで提供されており、今日から使い始めることが可能です。

このブログポストの長さにも関わらず、まだQuickSightの表面を少しなぞって紹介しただけにすぎません。みなさんはすでに無料でQuickSightを利用開始できますので、ぜひサインアップしていただき、ご自身のデータをロードし、QuickSightを分析に活用してください!

— Jeff

翻訳:下佐粉 昭 (simosako@)

※日本語版補足) Amazon QuickSightのオンラインセミナーが12月14日(水)18時~19時で開催予定です。Webブラウザがあればどこからでもご覧いただける無料のセミナーです。

以下よりお申込みください。

https://connect.awswebcasts.com/qs-webinar-20161214/event/event_info.html

https://aws.amazon.com/jp/about-aws/events/webinars/