[AWS]Athenaについて(その3　パーティション編)

2018.08.09

お世話になっております。pinocoです。

前回、S3上のデータファイルに対しAthenaでクエリを投げるところまでやりました。

今回はパーティションについて見て行きたいと思います。

1.Athenaのパーティションについて

データのパーティション分割

らしいです。

みなさんどうです？この一文でどの程度、わかりましたでしょうか？

ちなみに私の絶望的な理解力では「便利がいいんだな」くらいでした。

それだけ書いて投稿して本件についてはCaseClose、塩漬けにする、と言う選択肢も

浮かばなかったといえば嘘になりますが

そうしてしまうとブログとして成り立たっていないばかりか

私は社内で石を投げられてしまいます。小石と言うには大きいほどの。

なので掘り下げるしかありますまいて。

2.実際にやってみる

何もない私には、この手しか残っていないわけで、

まずはやってみて、経過や結果から知識と徳を積んでいくスタイルです。

で、紆余曲折を経てなんとかなったわけなんですが、

混乱をもたらさないように先に結果を書いておきます。

"state","gender","year","name","occurences"

"AK","F","2012","Emma","57"

"AK","M","2012","James","51"

"AL","F","2012","Emma","317"

・・・

#!/bin/bash



input_fname=TopBabyNamesbyState.csv

if [ ! -e $input_fname ]; then

  echo "[ERROR]:InputFile not Exist"

  exit 1

fi



if [ ! -e output ]; then

  mkdir output

fi



y_ar=`q -H -d ',' "select distinct year  from TopBabyNamesbyState.csv"`

for i in $y_ar; do

 q -H -d ',' "select * from $input_fname where year = '$i'" > ./output/$i.csv

 aws s3 cp ./output/$i.csv s3://xxxxxxxx/year=$i/

done

CREATE EXTERNAL TABLE IF NOT EXISTS test.test2 (

  `state` string,

  `gender` string,

  `year` int,

  `name` string,

  `occurences` int 

) PARTITIONED BY (

  year int 

)

ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'

WITH SERDEPROPERTIES (

  'serialization.format' = ',',

  'field.delim' = ','

) LOCATION 's3://xxxxxxxx/'

TBLPROPERTIES ('has_encrypted_data'='false')

CREATE EXTERNAL TABLE IF NOT EXISTS test.song2 (

  `state` string,

  `gender` string,

  `ys` int,

  `name` string,

  `occurences` int 

) PARTITIONED BY (

  year int 

)

ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'

WITH SERDEPROPERTIES (

  'serialization.format' = ',',

  'field.delim' = ','

) LOCATION 's3://xxxxxxx/'

TBLPROPERTIES ('has_encrypted_data'='false')

MSCK REPAIR TABLE song2

Partitions not in metastore:

~ snip ~

Repair: Added partition to metastore song2:year=1910

Repair: Added partition to metastore song2:year=1911

~ snip ~

Repair: Added partition to metastore song2:year=2011

Repair: Added partition to metastore song2:year=2012

では実際に確かめて見ましょう。

まずはパーティションを設定していない1つのCSVファイルに対しクエリを投げて見ます。

結果：RunTime：1.55 sec, 　DataScanned 225.32KB

フルスキャンしてますね。

では次にパーティションで分割してるファイルにクエリを投げます。

結果：RunTime：1.95 sec, 　DataScanned 2.06KB

ん？RunTimeがさっきより長くなっとる気がします。

これはきっと小さいファイルを扱っているからパーティション処理周りのオーバーヘッドが

パーティション分割によるファイルスキャンの最適化の恩恵を上回ったのかなと、

大きいファイルにしたらいい線で改善するのでは、と勝手に推測しました。

ちなみにスキャンしたデータ量は100分の1程度でした。

1910年〜2012年のデータを年単位で分割したので、だいたい想定通りだと思います

パーティション効いてますねー

最後のパターンはパーティション分割済みのテーブルで「パーティションに使用したキー(カラム)をWhere句から外した」

パターンをやってみたいと思います。

結果：RunTime：2.89 sec, 　DataScanned 215.07KB

遅い上に全スキャンと言うなかなか香ばしい結果でした。

一番最初に実施した検証より7KB程少ないのですが、何処へ出かけたかはわかりません。

これで、Athenaのパーティションについての検証は終わりにしたいと思います。

今回のケースだと既に存在するファイルを取り回して検証しましたが、

ユースケース的にはログ解析とか多そうなので、そっち方面も時間があれば触ってみたいと思います。

次は、putするファイル形式で早くなるのか、とGlueでどう楽になるのか、についてを

お送りしたいと思います。

[AWS]AWS Configでルール違反検知　その２

2018.08.08

こんにちは。

middleと申します。

前回に引き続き、壁の話をお送りしたいと思います。

どうぞよろしくお願いいたします。

★今回のお題

セキュリティグループの開けてはいけないポートを開けてしまった時、検知したい

その１　背景〜使用するサービス選択

その２　AWS Configとは　←本日はこちら

その３　カスタムルール作成①

その４　カスタムルール作成②

その５　AWS Config設定〜まとめ

★AWS Configとは

（公式サイトより引用）

AWSリソースの設定をルールに基づきチェック（評価）してくれるサービスということで、まさに今回のお題にうってつけです。

ルールに則している場合は「準拠」、反対にルールに違反している場合には「非準拠」と評価されます。

そしてそのルールですが、あらかじめAWS側で用意されている「マネージドルール」と、自分で作成する「カスタムルール」の2種類にわかれます。

「セキュリティグループの開けてはいけないポートが開いていない」というルールはマネージドルールとして用意がないので、これをLambdaで作成する必要がある、というわけです。

また、カスタムルールと一口に言っても、フォーマットがありほとんどデフォルトで使えるようなものもあれば、一から書かないといけない場合もあります。

残念ながら今回は後者です。

ただ、githubで参考になりそうなものがいくつか公開されています。

これらを拝見してどうにかすれば、きっとカスタムルールくらいちょちょいのちょいでしょう。

★ルールの流れ

githubで拝見したルールを参考に、こんな感じで考えました。

①

開けていいポート定義

②

削除済みリソース

→ルール適用の対象外にする

③

セキュリティグループ以外のリソース

→ルール適用の対象外にする

④

開いているポート範囲が「すべて」だった場合

→非準拠　※要検討

⑤

開いているポートが、開けていいポート（①で定義したポート）に該当しなかった場合

→非準拠

⑥

それ以外

→準拠

上記の通り、「開けていいポート」以外が開いていたらNG、というカスタムルールを作ります。

実のところgithubに「開けてはいけないポート」が開いてたらNG、というルールがあったのですが、私のこだわり（後述）でこちらを利用するのはやめたのでした。

②に関しては、参考にしたものがこのように削除済みリソースについての評価を入れていたので、真似です。

（検証はしておらず憶測で恐縮ですが、削除済みリソースも評価されてしまうのではないかと）

④に関しては次回記載します。

★こだわり（余談）

「開けてはいけないポート」と「開けていいポート」の数を比較した場合、圧倒的に前者が多いことが予想されました。

例えば現在80番ポートのみ開けていいとしたら、「開けてはいけないポート」は「0番〜79番」、「81番〜65535番」です。

ここで仮に、「22番ポートも開けてOK」となった場合どうでしょう。

「開けてはいけないポート」は「0番〜21番」、「23番〜79番」、「81番〜65535番」になります。

めんどくさい……（私だけでしょうか）

つまり運用（ポート定義）が煩雑？　になってしまうという懸念です。

個人的な感覚ですが、「開けていいポート」が「80番」から「22番と80番」になる方が、圧倒的に楽だと思ったわけです。

言ってしまえば好みです。

★言語選択

AWS Lambdaで関数を書くにあたり、8月8日現在、以下の言語に対応しています。

・Node.js

・Python

・Java

・C#

・Go

（公式サイトより引用）

今回はPythonを選択してみました。

どうせどの言語も未経験なのでこの際何でもOKなのですが、参考にするのがPythonで書かれていたので、こちらでトライです。

一旦以上です。

Lambda関数がどうなったかは次回お送りします。

よろしくお願いいたします。

[AWS]Athenaについて(その2　動作編)

2018.08.06

大変お世話になっております。pinocoです。

前回、抽象度の高いところでAthenaやAthenaの周辺環境について整理しました。

今回はとりあえず触ってみて、

どんな感じで設計すればいいかな、

ということを頑張ってまとめてみようと思います。

1.前回なんとなくわかったこと

・Athena自体の料金は「クエリごとにスキャンされたデータ量」で算出される(S3は別途通常の使用料金)

・Athenaのデータ処理はオンメモリで行われる

この2点からAthenaでクエリ発行時に読み込むデータ量を減らすアプローチが、

なんとなく性能的にも、お財布的にも優しそうである

ということがわかった気がしました。

では、とりあえずAthenaを動かしてみて

具体的にアプローチとして取れる手を整備していきたいと思います。

2.とりあえずAthenaの動作環境を整える

Athenaを実際に動かそうと思って一番最初に考えたのが

データをどう準備するかな、というものでした。

「public  datasets」で、ざっと検索してみると

kaggleやAWS、なんならgithubにawesome-public-datasets

なんて言うOpenDataのまとめ情報もあり、

なんだかすごく助かるなーと言う気分になったのですが

後ろに控えているパーティション分割のことを考えると

割とどんなカラム持ってれば適合しそうか、2秒くらい悩みます。

なぜ2秒で済んでいるかと言うと、実は「どうしたらいいのかなー」から

ビタイチ思考が進まないため「どうしたらいいのかなー」→ timeout(2sec)と言う

絶望的な構造です。思考とは一体どう言う状態を指すのか再度捉え直したい、そう思いました。

でその末にTop Baby Names in the USを選択します

データ量としては約230KBなので、フルスキャンで10MB(10MB以下は切り上げ)

バッチ組んで延々フルスキャンするクエリを結構投げ続けるみたいなことをしなければ、

Athenaのクエリで私の財布が粉微塵に爆発四散阿鼻叫喚な自体は避けられるはずです(多分)

<余談>BigQueryだとドキドキを緩和するdry run(クエリ実行時の走査バイト数の確認)があった気がしましたが

　　　　Athenaだと何が該当しそうかすぐにはわかりませんでした。

じゃあ実際にS3に放り込んで、テーブル作ってクエリを投げてやったりましょう。

とりあえず事前に適当なバケットに先ほど取得したデータを放り込んでおきます。

AthenaのコンソールからCreateDataBaseが見つからないので

とりあえずCreate tableを選択すると、「[超訳]Glue使おうや、楽やで」と言う

表示が「手動でやるんや」と並んで出てきます。

が、Glueの利点を噛みしめるためにも、一度手動でいばらの道を通ってみます。

人生は選択の連続なのですね。

↓Databaseも新しく作って、先ほどのデータが入っているbucketを指定してテーブルを作成します。

↓データはCSVなのでCSVを選択

↓カラムは1個づつ定義できそうな画面だったのですが、Bulk addみたいなのがあったので、それで指定しました

↓最後にパーティション作成するかって感じの画面になりましたが、データがパーティションに適合した形式ではないためそのまま行きます

↓予想通りヘッダー行が入ってて、深くため息をつきます。

気をとり直して、ざっと作り直します。

作り直した。※ヘッダ消して再度データファイルをuploadしてテーブル作り直し

ようやく準備が整ったので、クエリを実際に投げてみようと思います。

私の生まれた年にどんな名前をつけるのが流行ったのかみてみます。

select name ,gender, sum(occurences) as summary 

from "test"."test" 

where year = 1983

group by name, gender

order by summary desc

やー！

女の子はジェニファー、男の子はマイケルが入ってきました！

ここで３位にクリストファーがきているのもなかなか興味深いです。

画面中程にDataScannedとスキャンされたデータサイズが書いてありますが、

225.32KBになっているので、S3上に配置したcsvを全て読み込んでいるのがわかります。

では州別で同じようにみてみましょう。

select name ,gender, state, sum(occurences) as summary 

from "test"."test" 

where year = 1983

group by name, gender, state

order by summary desc

やー！

カリフォルニアとニューヨークでマイケル・ジェニファークラスタが強固な一方で、

テキサスでクリストファー勢が勃興していますね。

クリストファーといえばクリストファーウォーケンくらいしか思いつかないのですが、

おそるべしですね。

ああ。全然やりたいところまでたどり着けなかったんですが、

今日は、ここで時間切れなので、次回にパーティションのあたりを触って

設計に少しでも入れるといいなと思います。

つづく

[AWS]AWS Configでルール違反検知　その１

2018.08.01

こんにちは。

middleと申します。

私が日々の業務でぶちあたった壁などについて書いていきたいと思います。

どうぞよろしくお願いいたします。

★今回のお題

セキュリティグループの開けてはいけないポートを開けてしまった時、検知したい

その１　背景〜使用するサービス選択　←本日はこちら

その２　AWS Configとは

その３　カスタムルール作成①

その４　カスタムルール作成②

その５　AWS Config設定〜まとめ

★背景

お客様からこんなご要望がありました。

※背景の背景：現在別クラウドからAWSへの移行案件に参加してます。

★調査開始

監査といえば、ぱっと思いついたのがTrusted Advisorです。

ただTrusted AdvisorはAmazonの推奨に基づいて緑・黄・赤でお知らせ、みたいなイメージだったので、なんとなく出来なさそう、とは感じてました。

▲こんなんですね。

実現可能かどうか緊張が走ります。

★サポートに問い合わせ

いきなり禁じ手（？）ですが、サポートに問い合わせました。

※研究ではなく業務なので、躊躇なく聞いていくスタイルです。

★サポートの回答

お返事をいただきました。

※一部抜粋＆改変してます。

実現出来そう、ということでまずは一安心です。

そしてまさにこれぞ、というAWS Configなるサービスがありました。

ただし「カスタムルールを別途作成いただく」のあたりが多少気になるところです。

一筋縄ではいかない気配……。

ひとまず、こちらのAWS Configを利用していくという方向性までは見えました。

続きは次回お送りいたします。

以上です。

よろしくお願いいたします。

[AWS]LambdaでEC2の起動・停止を制御する

2018.07.24

Lambdaについて弊社ブログを検索したところ、

引っかかってきませんでした。

ちょうどEC2の起動制御をしたいなと思っていたので、

今日はLambdaを利用したEC2の起動制御について書きたいと思います。

・LambdaによるEC2の起動制御について

上記を実現させるために必要となる要素は以下です。

1.Lambda(EC2起動制御用APIをキックする)

2.IAM Role(1.のAPIをキックできる権限をLambdaにつけてあげる)

3.CloudWatch Events(1.のAPIをどのタイミングでキックするか、のトリガーとして仕様)

なので

[CloudWatch Events契機で]

[Lambdaを起動し]

[Lambdaは自身にアタッチされているIAM RoleによってEC2起動制御用APIを叩く]

となります。

じゃあ実際にやって見ましょう。

・やってみる

クラスメソッドさんのナイスなブログに当然のように上記処理が存在したため

「こんなに頼りっぱなしでいいんか?」と小さい声で言いながら

当然のように参考にさせていただきました。ありがとうございます。

AWS management ConsoleのLambdaから関数の作成に進みます。

名前は分かり易いものをつけておくといいと思います。

ランタイムは利用したいものを選択します。

でロールのところで「カスタムロールの作成」を選びます。

すると、IAM Roleを設定する画面に遷移するので、以下のように設定してあげました。

Policyに関して今回欲しい権限はec2の起動・停止なので、

ec2:"startInstances"とec2:"stopInstances"を付与します。

ハイライトしているlogs(CloudWatchLogs)の権限は、

Lambdaの実行結果を書き込むために必要となる権限セットです。

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Action": [

        "logs:CreateLogGroup",

        "logs:CreateLogStream",

        "logs:PutLogEvents"

      ],

      "Resource": "arn:aws:logs:*:*:*"

    },

    {

      "Effect": "Allow",

      "Action": [

        "ec2:StartInstances",

        "ec2:StopInstances"

      ],

      "Resource": "*"

    }

  ]

}

これでRoleの設定まではできたので、次に進みます。

それにしても、分かり易いUIですね。

今回はスケジュールベースでの実行を考えているので、CloudWatchEventsをトリガーにします。

GUIからCloudWatchEventsを選ぶと、処理の流れがざっくり完成した図が出てきて、

まるで自分が何かを成し遂げた気分になりますが、幻想です。

ここからまずは画面下のトリガーの設定(CloudWathcEvents)をやっていきます。

でこのような感じで設定しました。

スケジュール式のところはcron形式を利用しました。

記載方法は以下に従っています。

Rate または Cron を使用したスケジュール

ちなみに、毎日09:00(JST)に起動させたいと思ったので

cron(0 0 * * * *) 

こういう風に書くと自分の中では思ったのですが、

上記リンクの例だと以下のようになっています。

cron(0 0 * * ? *) 

?は「値を指定せず、指定した別の値とともに使用されます。

　　たとえば、特定の日付を指定したが、その日が何曜日であってもかまわない場合です。」

と説明されています。

であれば「*」でいいじゃないかと思うのです。

ものすごく気になったのでよく読んでみると、ドキュメントの最後に

日または週日の値は疑問符である必要があります (?)。

と記載がありました。が、週日の値あたりがより謎を深めてきます。

ちょっと、よくわからないので言語をEnglishにしてみます

One of the day-of-month or day-of-week values must be a question mark (?).

なるほど、少なくともday-of-monthかday-of-weekの

どちらかは「?」を使ってないといかんと。

おそらくいずれも値を設定しちゃうと動かなくなるとか多いから

わざとこういう制限を入れたのだと勝手に推測しました。

で、stopも同じよう18:00に動くようにして、イベントを作って、そこで気づきました。

あれ、これってどうやってstartとstopを打ち分けるんだっけ?

Lambda側にわたすパラメータの設定をするところ見落としたのかなー？

と思って見て見ますが、特になさそうでした。

Lambdaに統合された方じゃできなくて、CloudWatchの画面でしか設定できない系かもしれないですね、と

CloudWatch側で再度Eventを作成して紐付けます。

※Lambda側の画面での設定は早々に諦めたのですが、見落としや、良い方法あればお教えください。

ということで、CloudWatch->Eventsからパラメータをふくめて再度設定します。

これからの予定が10回分表示されます。

inputはJSON形式で渡しています。

{"Action": "start", "Region": "ap-northeast-1", "Instances": ["************"]}  

同じように停止の方も作ってあげて同じLambda関数に紐付けます。

では最後にLambdaで実行する処理を記載します。

このハンドラの引数:eventにCloudWatchEventsにて設定したinput(json)が渡されます。

import boto3

 

def lambda_handler(event, context):

    region = event['Region']

    instances = event['Instances']

    ec2 = boto3.client('ec2', region_name=region)

    if event['Action'] == 'start':

        ec2.start_instances(InstanceIds=instances)

        print ('started your instances: ' + ", ".join(instances))

    elif event['Action'] == 'stop':

        ec2.stop_instances(InstanceIds=instances)

        print ('stopped your instances: ' + ", ".join(instances))

で、CloudWatchEventのスケジュール時間をずらして、起動テストを実施して見ます。

ログ上はうまく行ってそうです。

これだけマスクするともはや何かわかりませんが、インスタンスもきちんと起動してくれていました。

これがどなたかのお役に立つと幸いです。