Amazon Web Services ブログ

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ついてはこちらをご覧下さい。

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

Amazon Aurora (MySQL)がR4インスタンスをサポート – 最大書き込みスループットが2倍に-

本日より、Amazon Aurora (MySQL)でR4インスタンスファミリーがご利用頂けるようになりました。R4インスタンスファミリーは新世代のメモリ最適化インスタンスでR3インスタンスファミリーよりも大きなL3キャッシュや高速なメモリを搭載することで性能の向上を行えます。

R4インスタンスファミリー内で最大のR4.16xlargeでは、64コア ・488GiBメモリを搭載しています。Amazon Aurora (MySQL)では、R4.16xlargeインスタンスをご利用頂くことで、R3.8xlargeインスタンスと比較して倍の最大200,000 writes/second の書き込み性能を発揮出来ます。

R4インスタンスファミリーはAmazon Aurora (MySQL) version 1.15からご利用頂けます。R4インスタンスはAmazon Aurora (MySQL)がご利用頂ける全てのリージョンでサポートしています。価格に関する詳細情報はこちらをご覧下さい。ハイエンドの商用データベースの速度と可用性をオープンソースデータベースのシンプルさとコスト効率でご利用頂ける、Amazon Aurora MySQL/PostgreSQLついてはこちらをご覧下さい。

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

新インスタンス- NVIDIA Tesla V100 GPUを最大8個搭載したAmazon EC2インスタンス P3

私たちは2006年に最初のm1.smallを発表した後も、お客様のご要望に応じて、そして常に進歩している最先端の技術を利用可能にするために、コンピュート能力、バースト可能な性能、メモリサイズ、ローカルストレージ、アクセラレータなどインスタンスを強化し続けています。

新しいP3インスタンス
本日、次世代のGPUを搭載したEC2インスタンスを4リージョンで公開しました。NVIDIA Tesla V100 GPUを最大8個搭載したP3インスタンスは、コンピュートインテンシブな機械学習、深層学習、流体計算、金融計算、地震解析、分子計算、ゲノム処理を想定して設計しました。

P3インスタンスは、最大2.7GHzで動作するIntel Xeon E5-2686v4プロセッサを搭載し、3種類のサイズを用意しています(VPCのみ、EBSのみ)

Model NVIDIA Tesla V100 GPUs GPU Memory NVIDIA NVLink vCPUs Main Memory Network Bandwidth EBS Bandwidth
p3.2xlarge 1 16 GiB n/a 8 61 GiB Up to 10 Gbps 1.5 Gbps
p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps
p3.16xlarge 8 128 GiB 300 GBps 64 488 GiB 25 Gbps 14 Gbps

各GPUは 5,120CUDAコアと640Tensorコアを備え、最大125TLOPSの混合精度浮動小数点演算、15.7TFLOPSの単精度浮動小数点演算、7.8TFLOPSの倍精度浮動小数点演算を可能とします。大きい2つのサイズでは、GPUはNVIDIA NVLink 2.0で相互接続され、最大300Gbpsデータレートで接続されています。これによりGPU間での中間結果やその他のデータのやりとりを、CPUやPCI-Expressを経由せずに高速に行うことが可能です。

Tensorコアとは?
このブログを書き始めるまで、私はTensorコアを聞いたことがありませんでした。大変有益なNVIDIA ブログの記事によると、Tensorコアは大きなDeep Neural Networkの学習や推論を高速化するために設計されています。各コアは、半精度(FP16)の4×4行列同士の積演算と、4×4の別の半精度もしくは単精度(FP32)行列の和演算を行い、半精度もしくは単精度の4×4行列の演算結果を保存することができます。以下にNVIDIAのブログ記事から図を転載します:

この操作は、Deep Neural Networkの学習処理において最も内部のループ処理であり、現在のGPUハードウェアが特定の市場のニーズに対して特化してどのように動作しているかを示しています。そして、Tensorコアの混合精度の性能は、16bitと32bitの浮動小数点の組み合わせを柔軟に扱えることを意味しています。

性能

実際の性能数値を提示することは、より簡易に実際のアプリケーションと関連づけられ、有意義だと考えています。8個のV100 GPUを搭載したp3.16xlargeでは、驚くことに単精度浮動小数点の乗算を1秒に125兆回可能です。

マイクロプロセッサの歴史を振り返って、1977年の夏に私が買ったIntel 8080Aチップを搭載したMITS Altairを考えてみます。2MHzクロックで秒間832回の乗算が可能でした。(このデータを使い、より速いクロックスピードに訂正しました)。p3.16xlargeは約1500億倍も高速です。しかし、その夏から12億秒が経過しました。言い換えると、過去40年に私のAltairが行なった計算に比べ、100倍以上の計算を1秒に実行することが可能となっています!

IBM PC用の追加オプションとして1981年の夏に発表された、革新的な8087数値演算コプロセッサーはどうでしょうか? 5MHzクロックで目的に特化したハードウェアで、秒間52,632回の乗算が可能でした。発表から11.4億秒が経ちましたが、p3.16xlargeは23.7億倍も高速で、当時の小さく貧弱なPCではまだ計算途中の演算が、今日では1秒で可能です。

では、Cray-1はどうでしょう?1976年に発表された最初のスーパーコンピューターは、160MFLOPSのベクトル演算が可能でしたが、p3.16xlargeは781,000倍高速です。当時に比べ、1500回も興味深い問題を繰り返し計算することが可能です。

P3と現在のスケールアウト型スーパーコンピュータの比較は難しくなっています。 スーパーコンピュータのコンポーネントとしてP3を捉え、必要に応じて使うことが可能です。

今すぐ起動できます
V100 GPUとTensorコアの利点を全て享受するには、CUDA 9cuDNN 7が必要です。これらのドライバやライブラリは最新のWindows AMIに追加されており、Amazon Linux AMIにも11月7日に追加予定です。新しいパッケージはAWSのリポジトリで利用可能ですので、必要に応じてすでに利用中のAmazon Linux AMIにインストールできます。

最新のAWS Deep Learning AMIには、Apache MxNet、Caffe2、Tensorflow(それぞれがNVIDIA Tesla V100 GPUをサポート)の最新リリースがプリインストールされており、Microsoft Cognitive ToolkitやPyTorchなどの他の機械学習フレームワークがNVIDIA Tesla V100 GPUのサポートをリリースするとすぐに、P3インスタンスをサポートするように更新されます。また、NVIDIA Volta Deep Learning AMI for NGCを使用することもできます。

P3インスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、アジアパシフィック(東京)のリージョンにて、オンデマンド、スポット、リザーブドインスタンス、Dedicated Hostとして利用可能です。

Jeff;

原文はこちらです。

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 はクラスター内の各データノードの VPC に Elastic Network Interface (ENI) を配置します。各 ENI はサブネットの IPv4 範囲内からプライベート IP アドレスを使用し、パブリック DNS ホスト名を受け取ります。ゾーン対応を有効にすると、Amazon ES は異なるアベイラビリティーゾーンで 2 つのサブネットにエンドポイントを作成することで、より優れたデータの耐久性を提供しています。

クラスター内のノード数には IP アドレスの三倍の数を確保しておく必要があります。ゾーン対応を有効にしている場合は、その数を分割できます。Amazon ES 専用の別のサブネットを作成するのが理想的です。

注意点:

  • 現在、既存のドメインを VPC に移動することはできません (その逆も同様)。VPC サポートを利用するには、新しいドメインを作成しデータを移行してください。
  • 現時点で Amazon ES は VPC 内にあるドメインの Amazon Kinesis Firehose をサポートしていません。

詳しくは「Amazon ES ドキュメント (Amazon ES documentation)」をご覧ください。

Randall

Amazon Lightsail の更新 – Windows 仮想プライベートサーバーの起動と管理

Amazon Lightsail については、去年公開したブログ「Amazon Lightsail – AWS のパワーと VPS のシンプルさ (Amazon Lightsail – the Power of AWS, the Simplicity of a VPS)」でご紹介しました。昨年の公開以来、何千人ものユーザーがこの Lightsail を使用して AWS の利用を始めたり、Linux ベースの仮想プライベートサーバーを起動するようになりました。

そして本日より、Window 仮想プライベートサーバーのサポートも追加しました。ほんの数分で、Windows Server 2012 R2 を実行している VPS や Windows Server 2016SQL Server 2016 Express を使う Windows Server 2016 を起動することができます。VPS を使用して、インフラストラクチャのセットアップや実行を必要とせずに .NET または Windows のアプリケーションを構築、テスト、デプロイすることができます。1 回または 2 回クリックするだけで、バックアップ、DNS 管理、オペレーションメトリクスにアクセスできます。

512 MB から 8 GB の RAM、1 または 2 vCPU、最大 80 GB までの SSD ストレージなど、サーバーには 5 つのサイズがあります。料金は 10 USD/月額からご用意しています (ソフトウェアライセンスを含む)。

512 MB サーバーを 1 か月間無料でご利用いただけます (最大 750 時間まで)。

Windows VPS の起動
Windows VPS を起動するには、Lightsail にログインし [Create instance] をクリックして [Microsoft Windows] プラットフォームを選択します。次に SQL Server 2016 Express を実行したい場合は [Apps + OS] をクリックします。Windows だけの場合は [OS Only] を選択します。

初回起動の後に Powershell スクリプトを使用してインスタンスをカスタマイズしたい場合は [Add launch script] をクリックしてスクリプトを入力します。

ご希望のインスタンスプランを選び、インスタンス名を入力してから起動する量を選択し [Create] をクリックします。

1 分ほどでインスタンスが実行されます。

インスタンスをクリックして [Connect using RDP] をクリックします。

これで組み込みブラウザベースの RDP クライアントを使用し接続を実行します (IP アドレスと別のクライアントの認証情報を使用することも可能)。

今すぐ利用可能
この機能は米国東部 (バージニア北部)米国東部 (オハイオ)米国西部 (オレゴン)欧州 (ロンドン)欧州 (アイルランド)欧州 (フランクフルト)アジアパシフィック (シンガポール)アジアパシフィック (ムンバイ)アジアパシフィック (シドニー)アジアパシフィック (東京) の各リージョンでご利用いただけます。

Jeff;

アイテリジェンスとAWSが協力してSAP顧客に価値を提供

itelligence(アイテリジェンス)とAWS: AWSクラウドを介してグローバルにSAPの価値とソリューションを提供することに注力している新しいAmazon Partner Network(APN)メンバーをご紹介します。
この記事は、Amazon Web Services(AWS)でSAP担当ジェネラルマネージャーを務めるBas Kamphuisによるものです。

 

https://www.prnewswire.com/news-releases/itelligence-announces-collaboration-with-amazon-web-services-for-cloud-solutions-300540532.html

 

世界中のトランザクションの76%がSAPシステムと何らかの形でつながっており、SAP社は引き続きERP(Enterprise Resource Planning)市場の首位を占めています。SAP社の主力ソフトウェア製品であるSAP ECC(ERP Central Component)をお使いの数万のお客様の100%が、このリリースのメンテナンスが終了する2025年までには、どこかに移行することになっているでしょう。これは、SAP S/4HANAやSAP BW/4HANAのような、インメモリデータベースSAP HANAによって強化されたイノベーションを促すためです。この変化の誘発により、SAPをご利用中のお客様とパートナーエコシステム全体が、SAPランドスケープを戦略的に見て、どのようにSAP HANAでデジタル変革を実現できるのか明確にすることを迫られています。

世界で最も成功しているSAPグローバルパートナーの1社であるアイテリジェンスは、現在SAPをご利用中のお客様の多くが直面しているこの状況と複雑さを理解しています。大規模なグローバル組織にサービスを提供し、何十年にもわたってSAP環境を実装、維持してきました。アイテリジェンスとAWSのパートナーシップは、賞を受賞するほどのSAPの実装および運用における専門知識と組み合わせて、お客様がAWSクラウドの利点(伸縮性、弾力性、セキュリティ、グローバルスケールなど)を享受できるよう注力していきます。お客様は、既存のビジネスオペレーションのリスクや混乱を招くことなく、今すぐAWSとSAPが提供するイノベーションの恩恵を受けることができます。

私たちの継続した協調では、SAPのイノベーションの活用、選択肢の拡大、コストの削減、そして価値の創造に費やす時間の短縮など、お客様が求める敏捷性を実現するためにお役立ていただける、AWSで加速するアイテリジェンスのより多くのオファリングの提供を目指しています。

現在、お客様にご活用いただけること:

  • AWSにデータセンターを移設して、オンプレミスの設備投資を廃止
  • ツールとベストプラクティスを活用して数週間かかっていたSAPシステム移行を数日で実施
  • 複数地域にまたがるビジネス継続性と災害復旧のアーキテクチャを活用して、企業のセキュリティを強化し、弾力性を向上
  • SAP HANA認定パブリッククラウドの中で最大の品揃えを持つAWS上に本稼働環境を移行し、SAPランドスケープを統合

また、アイテリジェンスのマネージドサービスにAWSを組み込むことで、お客様のIT環境の複雑さを軽減することができます。私たちは連携して、お客様のSAP環境を積極的に自動化、監視および保守するために、人工知能、機械学習やビッグデータなどのAWSサービスを統合していく計画があります。

私たちはアイテリジェンスとの関係について非常に興奮しており、SAPをご利用中のお客様に引き続き最高のソリューションとオファリングを提供するための共同イノベーションを続けていきます。AWS組織全体を代表して、私たちはアイテリジェンスのチームのコミットメントとリーダーシップに感謝を述べたいと思います。Amazon Partner Networkへようこそ。

Bas

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

今すぐご利用可能 – Amazon Aurora with PostgreSQL Compatibility

昨年後半、Amazon Aurora に PostgreSQL 互換のエンジンを追加する計画をお話しました。このアナウンスのすぐ後に、プライベートベータを開始し、今年の前半にはオープンプレビューを開始しました。このベータとプレビューの期間、非常に素晴らしい数多くのフィードバックをいただき、このサービスがお客様のニーズを満たし、期待値を超えることが確かなものになるように、できる限りのことをしました!

一般利用可能に
本日、Amazon Aurora with PostgreSQL Compatibility が一般利用可能となり、4つのリージョンで利用できるようになったことをお伝えします(その他のリージョンは今後対応していきます)。本サービスは、PostgreSQL 9.6.3 と互換性があり、そのストレージは、64 TB まで自動的にスケールし、そのバックエンドで 6つのレプリカを持ち、性能と可用性を高めています。

Amazon Aurora with MySQL Compatibility のように、このエディションはフルマネージドで、簡単にセットアップし、利用できます。性能の観点ではお客様自身で運用していた PostgreSQL と比較して、最大3倍のスループットを期待することができます(我々がどのようにこれを実現したかについては、Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases をご確認ください)。

新たにアップデートされた RDS Console から PostgreSQL と互換性のある Amazon Aurora インスタンスを起動することができます。まず、Amazon Aurora をエンジンとして選択し、PostgreSQL-Compatible をエディションとして選択し、[Next] をクリックします。

そして、インスタンスクラス、シングル(開発、テスト環境向き)/Multi-AZ(本番環境向き) デプロイメントの選択を行い、インスタンス名、管理者パスワードを設定し、[Next]をクリックします。

インスタンスクラスは、6つのモデルの中から選択可能です(2 から 64 のvCPUと 15.25 から 488 GiB のメモリ)。

db.r4 インスタンスクラスは新たに Aurora に追加され、トップエンドでより大きなサイズを提供します。 db.r4.16xlarge により、書き込み性能が向上され、これまで複数のデータベースでシャーディングしていたシステムを統合し、1つの Aurora データベースで運用できるようになるかもしれません。

次のページではより高度なオプションを設定できます。まず、VPC やPublicly Accessiblity の設定などのネットワークオプションです。

クラスター名やその他のデータベースオプションを設定します。暗号化も非常に簡単に利用でき、デフォルトで有効化されます; その際、あらかじめ用意されるデフォルトのマスターキーもしくは、ご自身でお持ちの鍵を選択可能です。

フェイルオーバーの動作、スナップショットバックアップの保持期間、拡張モニタリングを通じて詳細な(OSレベル)監視メトリクスを有効にするか選択します。

設定を終えたら、[Launch DB Instance]をクリックして進めましょう!

新しいインスタンス(Multi-AZ を指定したので、プライマリとセカンダリが表示されています)が、数分で立ち上がり、稼働しています。

各 PostgreSQL-Compatible インスタンスは自動的に 44 個のメトリクスを CloudWatch へ発行します。

拡張モニタリングを有効にしていれば、各インスタンスはさらに インスタンスごとかつプロセスごとのメトリクスを発行します。これは、インスタンス起動時、もしくは [Modify Instance]を通じて、起動後に有効化できます。下記に、拡張モニタリングを有効化した際のいくつかのメトリクスを示しています。

[Manage Graph]をクリックして、どのメトリクスを表示するか設定できます:

プロセスごとのメトリクスも利用可能です。

最大15個のリードレプリカを作成し、読み込みのキャパシティをスケールすることが可能です。

各レプリカに対してのリクエストを負荷分散するために、クラスターごとに単一のリーダーエンドポイントが割り当てられます:

Perfomance Insights
先に述べたように、Performance Insights が自動的に用意されます。この Amazon Aurora の機能はデータベースエンジンと直接接続され、クエリが利用するデータベースリソース、そのリソースがどうレスポンスタイムに影響しているかを見ることにより、各クエリの内部を深く確認できます。これが最初の画面です:

各クエリがどれだけ同時実行されているかを把握するために、SQL クエリごとの詳細を確認できます。

Peromance Insights にはこのブログには収まらないほどのビューやオプションがまだまだあります。詳細については、Amazon Performance Insights を使用するをご確認ください。

Amazon Aurora with PostgreSQL Compatibility への移行
AWS Database Migration ServiceSchema Conversion Tool が、商用データベースやオープンソースデータベースに格納されているデータを Amazon Aurora に移行するサポートを行います。Schema Conversion Tool は、既存のデータベーススキーマ、コードのアセスメントを素早く行い、お客様が MySQL, PostgreSQL のどちらを選択すべきかをサポートしてくれるでしょう。新しい期間限定プログラムである、Free DMS プログラムにより、無料で DMS, SCT を利用して、Aurora に移行することができます。最大 6ヶ月まで複数のタイプの DMS インスタンスを無料でご利用いただけます。

もしすでに、PostgreSQL を使っているお客様にとって嬉しい点として、PostGISdblink を含む拡張モジュールをサポートしていることがあげられるでしょう。

Available Now
Amazon Aurora with PostgreSQL Compatibility は本日より、米国東部(北部バージニア)、欧州(アイルランド), 米国西部(オレゴン)、米国東部(オハイオ)でご利用可能です。その他のリージョンについてもできる限り早くサポートできればと思います。

Jeff;

(元記事はこちらをご参照ください。翻訳はソリューションアーキテクト江川が担当しました。)

 

 

 

【開催報告】第10回 AWS Startup Tech Meetup

こんにちは、ソリューションアーキテクトの篠原英治(@shinodogg)です。

AWSをご利用のStartup企業で働くエンジニアを対象とさせていただいているAWS Startup Tech Communityですが、10回目のMeetupを2017年10月19日にAmazon目黒オフィスで開催しました。カジュアルな雰囲気の中、各セッションともに実践的なQ&Aのやり取りで盛り上がり、私たちAWSの人間も含めた参加者の皆さま同士の非常に濃い学びの場となりました。

– Speee 森岡さん: ヌリカエのデータ集積基盤 on AWS

外壁塗装・屋根塗装の優良業者紹介サービスであるヌリカエのAmazon Kinesis Firehose、Amazon Athena、Amazon QuickSightを活用したデータ基盤について発表していただきました。

– freee 九岡さん: Kubernetes on AWS

全自動クラウド会計ソフトのfreeeにジョインされた九岡さんにk8sをAWS上で稼働させる際の考慮事項やTIPSについて発表していただきました。

– Lightning Talks

AWS 桑野

海外のAWSリージョンの活用方法をご紹介しました。

AWS 高山

リザーブドインスタンスの活用方法をご紹介しました。

pixiv 小芝さん

pixivにおけるAWSの活用についてご紹介いただきました。

– ネットワーキング

セッション以外の時間でも参加者の皆さま同士での活きたノウハウの共有が行われました。写真左:Gunosy小出さん、写真右:Sansan間瀬さん。

先日一周年を迎えたVoicy窪田さんとAWSソリューションアーキテクトの福井と半場。

– 次回開催に向けて

AWSをご利用のStartup企業のエンジニアの皆さまをお招きして、カジュアルにディスカッションできる場として、次回は年明け頃に開催予定です。我こそは!というStartupエンジニアの方は是非お近くのAWSジャパンの人間にお気軽にお声がけください。

Amazon Redshift Spectrumによるセキュリティとコンプライアンスのためのデータベース監査ログの分析

(補足:本記事は2017年6月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

クラウドサービスの採用が増加するにつれて、組織は重要なワークロードをAWSに移行しています。これらのワークロードの中には、セキュリティとコンプライアンスの要件を満たすために監査が必要な機密データを格納、処理、分析するものがあります。監査人が良くする質問は、誰がどの機密データをいつ照会したのか、いつユーザが最後に自分の資格情報を変更/更新したのか、誰が、いつシステムにログインしたかということです。

デフォルトでは、Amazon Redshiftは、ユーザーの接続情報、変更情報、アクティビティに関連するすべての情報をデータベースに記録します。ただし、ディスク領域を効率的に管理するために、ログの使用状況と使用可能なディスク容量に応じて、ログは2〜5日間のみ保持されます。より長い時間ログデータを保持するには、データベース監査ロギングを有効にします。有効にすると、Amazon Redshiftは指定したS3バケットに自動的にデータを転送します。

Amazon Redshift Spectrumにより、Amazon S3に格納されたデータにクエリすることを可能にし、さらにAmazon Reshift のテーブルと結合することも可能です。 Redshift Spectrumを使い、S3に格納されている監査データを確認し、すべてのセキュリティおよびコンプライアンス関連の質問に答えることができます。AVRO、Parquet、テキストファイル(csv、pipe delimited、tsv)、シーケンスファイル、およびRCファイル形式、ORC、Grokなどのファイルをサポートしています。 gzip、snappy、bz2などのさまざまな圧縮タイプもサポートしています。

このブログでは、S3に保存されたAmazon Redshift の監査データを照会し、セキュリティーやコンプライアンスの質問への回答を提供する方法を説明します。

作業手順

次のリソースを設定します。

  • Amazon Redshift クラスタとパラメータグループ
  • Amazon Redshift に Redshift Spectrumアクセスを提供するIAMロールとポリシー
  • Redshift Spectrum外部表

前提条件

  • AWS アカウントを作成する
  • AWS CLI にて作業ができるように設定する
  • Amazon Redshift にアクセスできる環境を用意する。(psqlやその他クライアント)
  • S3バケットを作成する

クラスタ要件

Amazon Redshift クラスタは、次の条件を満たす必要があります。

  • 監査ログファイルを格納しているS3バケットと同じリージョンにあること
  • バージョン1.0.1294以降であること
  • ログ蓄積用のS3バケットに読み込み、PUT権限を設定されていること
  • AmazonS3ReadOnlyAccessとAmazonAthenaFullAccessの少なくとも2つのポリシーを追加したIAMロールにアタッチしていること

Amazon Redshift のセットアップ

ユーザーのアクティビティーをロギングするために、新しいパラメータグループを作ります。


aws redshift create-cluster-parameter-group --parameter-group-name rs10-enable-log --parameter-group-family Redshift-1.0 --description "Enable Audit Logging" 
aws redshift modify-cluster-parameter-group --parameter-group-name rs10-enable-log --parameters '{"ParameterName":"enable_user_activity_logging","ParameterValue":"true"}'

Amazon Redshift クラスタを上記で作成したパラメータグループを使い作成します。

aws redshift create-cluster --node-type dc1.large --cluster-type single-node --cluster-parameter-group-name rs10-enable-log --master-username <Username> --master-user-password <Password> --cluster-identifier <ClusterName>

クラスターが出来るまで待ち、作成されたらロギングを有効にします。

aws redshift enable-logging --cluster-identifier <ClusterName> --bucket-name <bucketname>

※S3のバケットポリシーなどはこちらを御覧ください。
※もしくは下記のようにマネージメントコンソールからログ用のS3のバケットを新規で作成するとバケットポリーが設定された状態のバケットが作成できます。

 

Redshift Spectrumをセットアップします。

Redshift Spectrumをセットアップするために、IAM ロールとポリシー、External Database,External Tablesを作成します。

IAM ロールとポリシー

Redshift データベースからS3バケットにアクセスするためのIAMロールを作成します。
RedshiftAssumeRole.json ファイルを作成し、下記のコマンドを実行してください。

aws iam create-role --role-name RedshiftSpectrumRole --assume-role-policy-document file://RedshiftAssumeRole.json

RedshiftAssumeRole.json
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
			"Service": "redshift.amazonaws.com"
		},
		"Action": "sts:AssumeRole"
		}
	]
}

AmazonS3ReadOnlyAccess および AmazonAthenaFullAccess の2つのポリシーをアタッチします。

aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess --role-name RedshiftSpectrumRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess --role-name RedshiftSpectrumRole

作成したロールをAmazon Redshift クラスタに追加します。 <ClusterName> と <accountNumber> を自身のものに置き換えます。

aws redshift modify-cluster-iam-roles --cluster-identifier <ClusterName> --add-iam-roles arn:aws:iam::<accountNumber>:role/RedshiftSpectrumRole

ここまでの操作で、Amazon Redshift クラスタから S3 にアクセスできるように、Redshift Spectrum は設定されました。

External DatabaseとSchema

Amazon Redshift データベースにログインして、外部データベースとスキーマ、外部表を作成し、S3 に格納されたデータにアクセスできるよう設定します。

例えばpsql でアクセスする場合は下記がコマンド例になります。
本手順で作成している場合は、dev という名前のデータベースが作成されています。

psql -h <ご自身の設定したものを確認して変更ください>.ap-northeast-1.redshift.amazonaws.com -p 5439 -U dbadmin -d dev -W

Amazon Redshift で作成された外部データベースは、Amazon Athena データカタログに格納することが出来、Athena からも直接アクセスできます。

※本Blog (英語版)が書かれたあとにAWS Glue がリリースしておりますので、こちらも参考にしてください。

監査ログデータを照会するには、Amazon Redshift で外部データベースとスキーマを作成します。 DDL を実行する前に、以下のアカウント番号、ロール名、リージョン名を更新してください。

CREATE external SCHEMA auditLogSchema
FROM data catalog
DATABASE 'auditLogdb'
iam_role 'arn:aws:iam::<AccountNumber>:role/<RoleName>'
REGION '<regionName>'
CREATE external DATABASE if not exists;

REGION パラメータは、Athena データカタログのリージョンを指定します。 デフォルトの値は、Amazon Redshift クラスタと同じリージョンになります。(東京リージョンは、ap-northeast-1 になります。)

外部表の作成

Redshift Spectrum は S3 上のデータに対してクエリ可能になる外部表が作成可能です。 外部表は読取り専用であり、 現在、Spectrum を使用して S3 上のデータを変更することはできません。外部表は、表名の前にスキーマ名を付けた形で指定します。

3つの異なる監査ログ・ファイルを照会するための下記3つの表を作成します。

・ユーザーDDL:ユーザーが実施した DDL(CREATEやDROPなど)を記録します。
・ユーザー接続:成功または失敗したすべてのログオン情報をログに記録します。
・ユーザーアクティビティ:ユーザーが実行したすべてのクエリを記録します。
ユーザーDDL とユーザー接続のデータファイル形式は、パイプ区切りのテキストファイルです。 どちらのファイルもgzipユーティリティを使用して圧縮されています。 ユーザーアクティビティログはフリーフローテキストです。 各クエリは新しい行で区切られます。 このログも、gzip ユーティリティを使用して圧縮されています。

次のクエリのS3 バケットの場所を自身のバケットになおして実行してください。

CREATE external TABLE auditlogschema.userlog
(
userid INTEGER,
username CHAR(50),
oldusername CHAR(50),
action CHAR(10),
usecreatedb INTEGER,
usesuper INTEGER,
usecatupd INTEGER,
valuntil TIMESTAMP,
pid INTEGER,
xid BIGINT,
recordtime VARCHAR(200)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.connectionlog
(
event CHAR(50) ,
recordtime VARCHAR(200) ,
remotehost CHAR(32) ,
remoteport CHAR(32) ,
pid INTEGER ,
dbname CHAR(50) ,
username CHAR(50) ,
authmethod CHAR(32) ,
duration BIGINT ,
sslversion CHAR(50) ,
sslcipher CHAR(128) ,
mtu INTEGER ,
sslcompression CHAR(64) ,
sslexpansion CHAR(64) ,
iamauthguid CHAR(36)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.activitylog
(
logtext VARCHAR(20000)
)
row format delimited
lines terminated by '\n'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

guest ユーザーを作成して簡単な作業をしログを作成する。

ユーザー “guest”  を作成してログインし、 “person” という表を作成します。次に、テーブルに対してクエリーを実行します。

管理ユーザーとしてログインし、新しいユーザー “guest” を作成します。

CREATE USER guest PASSWORD 'Temp1234';

ユーザー  “guest” としてログインし、以下の DDL を実行します。

CREATE TABLE person (id int, name varchar(50),address VARCHAR(500));

INSERT INTO person VALUES(1,'Sam','7 Avonworth sq, Columbia, MD');
INSERT INTO person VALUES(2,'John','10125 Main St, Edison, NJ');
INSERT INTO person VALUES(3,'Jake','33w 7th st, NY, NY');
INSERT INTO person VALUES(4,'Josh','21025 Stanford Sq, Stanford, CT');
INSERT INTO person VALUES(5,'James','909 Trafalgar sq, Elkton, MD');

guest  でログインしている間に、person テーブルでいくつかのクエリを実行して、アクティビティログを生成します。

SELECT * 
  FROM person;

SELECT * 
  FROM person 
 WHERE name='John';

次に、上記で作成した3つの外部表(それぞれのログ)毎に、1つのクエリーの具体例を説明します。

ユーザーDDL ログ

次のクエリは、ユーザー guest がその日に実行した作業が確認できます。

SELECT username
,action
,recordtime 
  FROM auditlogschema.userlog 
 WHERE action in ('create','alter','drop','rename') 
   AND username='guest';

ユーザー接続ログ

次のクエリでは、ユーザー guest がログインした remotehost名、時刻を確認できます。

SELECT event
,recordtime
,remotehost 
  FROM auditlogschema.connectionlog 
 WHERE length(username) >0 
   AND username='guest' 
ORDER BY recordtime;

ユーザーアクティビティログ

次のクエリは、誰がいつ、person表 にアクセスしたか、またその際に流したクエリを確認できます。

SELECT pu.usename
	,substring(logtext,2,strpos(logtext,'UTC')+1)UTCTime
	,substring(logtext,strpos(logtext,'LOG:')+5) query
  FROM auditlogschema.activitylog al,pg_user pu
 WHERE logtext like '%xid=%'
   AND logtext not like '%SELECT 1%'
   AND logtext not like '%SET %'
   AND logtext like '%from person%'
   AND substring(substring(logtext,strpos(logtext,'userid=')+7),1,strpos(substring(logtext,strpos(logtext,'userid=')+7),' '))=pu.usesysid;

 

まとめ

このBlogでは、Amazon Redshift に新たに追加された機能 (Redshift Spectrum) を使用して、S3に格納されている監査ログデータを照会し、セキュリティおよびコンプライアンス関連の質問に簡単に回答する方法について説明しました。

Amazon Redshift Spectrum は2017年10月20日現在、東京リージョンでも利用可能となっております。

Amazon Redshift Spectrum の詳細については、こちらをご覧ください。 新機能についての詳細は、「Get Started」をご覧ください。

翻訳:パートナーソリューションアーキテクト 相澤