例のAWSデータレイクの本でお勉強がてら、今更ですがAWS Lake Formation を初めて実際に触ってみましたので、自分へのメモを兼ねて情報を残します。
AWS Lake Formation とは
従来数ヶ月かかったデータレイクの構築を数日で実現するといったものだそうです。
AWS Glueの拡張機能とも言えるようで、マネジメントコンソールでもAWS Glueへリダイレクトされる項目も多く関連性が深くなっています。またAWS Identity and Access Management(以後IAM)を拡張した独自のアクセス許可モデルも持ちます。
AWS GlueやIAMをラップするようなものでもあり、AWS Lake Formation自体の利用は無料なのでユーザー視点だとデータレイク関連の既存AWSサービスなり機能なりを集約管理し、利用しやすくなったというざっくりイメージで良さそうです。
AWS CLIのTab補完で確認した感じこれぐらいしかコマンドもないようです。シンプルですね。(執筆時点)
% aws lakeformation batch-grant-permissions get-effective-permissions-for-path register-resource batch-revoke-permissions grant-permissions revoke-permissions deregister-resource list-permissions update-resource describe-resource list-resources get-data-lake-settings put-data-lake-settings
ここから少し一般的なお話ですが、データレイク周りの蓄積されたデータから応用(分析/可視化等)に関する基盤を包括してセキュリティについてどうあるべきかを考える場合、必要最小限の法則に従ったりというのは当然として、セキュリティ上守るべき箇所は守りつつ、かといって社内利用者によるデータ活用を妨げない自由度をもたせるという事は重要だと思います。
しかし、様々なシステム部門なり時に関連会社なりで将来分析される可能性があるデータを蓄積していこうとなっても、社内の様々な管理部門毎にリソース(AWSを利用している場合は、AWSアカウントやらデータカタログやらS3バケットやらDB単位等)も散っていたりサイロ化されていれば、セキュリティレベルにも差があったりもするかと思いますが、そこを標準化して1つ1つ様々な部門を跨いで調整し、データレイクを作っていき、新たな分析要件なり、新たなシステムなり新たなユーザーなりへの対応を始めとした維持管理の運用をするとなると想像するだけで大変そうな印象を受けます。
従来ではID管理を応用(分析やら可視化)レイヤーで制御する手法が一般的だったようですが、データレイクの場合はその応用レイヤーの範囲が増えたり変わり続けるような事が前提となるので、データレイクとデータレイクを利用するサービスの間に新たなID管理のレイヤーを作成するといった考え方が生まれ、その考えで実装されているのが AWS Lake Formationとなるようです。
こちらのBlackbeltがとても参考になります。
www.slideshare.net
と、ここまでの座学みたいなもので完全理解出来る人は良いですが、自分の場合は触らないとサービス全体像とかがよく理解出来なかったのでとりあえずチュートリアルを試してみました。
AWS Lake Formationのチュートリアル
今回実施したAWS Lake Formationのチュートリアルは公式の以下で、1つめのこちらをやってみました。
Getting Started with AWS Lake Formation - AWS Lake Formation
ざっくり概要説明すると
やることとしては、基本的にどのAWSアカウントでも取得しているであろうAWS CloudTrailのログをAWS Lake Formationでぽちぽちとデータレイク用S3バケットに蓄積するような形を作り、最後に設計した権限通りの動作しているかをAmazon Athenaを使って軽く確認するといった流れになります。
・Step3までが事前準備(権限周り)
・Step4-10からが実際の AWS Lake Formation画面でのオペレーションとなり
・Step11で権限通り動作をしているか Amazon Athenaを利用して簡易確認する
といった感じです。
今回は自身のAWS検証感環境にて実施することとします。 (記載内容は一部省略したり、独自に補足をしています。当たり前ですが実際に試すときはオフィシャルのチュートリアルを参照ください。)
step.0 事前環境準備
で、いきなりハンズオンには振られていない番号ですが
・About the Personas in This Tutorial
・AWS CloudTrail Tutorial Prerequisites
がこちらにあたります。
その中に以下の初期設定があるのですが、AWS Lake Formationを使うにあたり管理用IAMユーザーの登録が必要だったりと結構な設定項目数があります。
検証環境ならわざわざ、datalake_adminなんて作らずAdministratorを使っちゃえばいいっしょ〜とも思えますが権限周りが肝だったりもするので、そこはちゃんとやった方が良さそうです。良さそうですよ？
AWS Lake formationの初期設定
Setting Up AWS Lake Formation - AWS Lake Formation
ワークフローのIAMロールを作成する
ワークフローを作成する際に、AWS Lake Formationにデータを取り込む為に必要なアクセス許可を付与する必要があるので事前に以下IAMロールを作成します。
IAMロール名: LakeFormationWorkflowRole
信頼されたエンティティ: AWS Glue
アタッチするIAMポリシー:
・AWSGlueServiceRole(AWS 管理ポリシー) - 必須
・LakeFormationWorkflow(インラインポリシー*1) - 必須
*1
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess", "lakeformation:GrantPermissions" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::XXXXXXXXXXXX:role/LakeFormationWorkflowRole" ] } ] }
データレイク管理者のIAMユーザー作成する
ここで作るIAMユーザー: datalake_admin は(AWS Glueの)データカタログへのアクセス、(AWS Glueの)データベース作成、AWS Lake Formationでの他ユーザの操作権限付与 等の権限を持つ、正にAWS Lake Formationで管理されるデータレイク管理者といった位置づけのユーザーになります。
データレイクの場所の外にあるデータを取り込む場合は、ソースデータを読み取るためのアクセス許可を付与する場合はオプションとして記載されているので必要に応じてアタッチしたりインラインポリシーを追加します。紹介されているオプションも含めるとこんな感じになります。
IAMユーザ名: datalake_admin
アタッチするIAMポリシー:
・AmazonAthenaFullAccess(AWS 管理ポリシー) - オプション
・CloudWatchReadOnlyAccess(AWS 管理ポリシー) -オプション
・AWSGlueConsoleFullAccess(AWS 管理ポリシー) -オプション
・AWSLakeFormationCrossAccountManager(AWS 管理ポリシー) -オプション
・AWSLakeFormationDataAdmin(AWS 管理ポリシー) - 必須
・LakeFormationSLR (インラインポリシー*2) - 必須
・RAMAccess(インラインポリシー) - オプション
・UserPassRole(インラインポリシー) - オプション
*2
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName": "lakeformation.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess" } ] }
※その他、オプションのインラインポリシーについてはオフィシャルの情報を参照
データカタログ設定の変更
そしてAWS Lake Formation初期設定の初回ログイン時からデフォルトで警告マークが出ておりいきなり考えさせられますが、AWS Lake Formaiton の権限管理が後から出てきた権限管理のモデルとなる為、AWS Glueの既存リソースで影響が出る可能性があるので考慮が必要な旨の注意喚起をしてくれている内容となります。
AWS Lake Formation登場前からAWSでデータレイクを構築やAWS Glueの活用をしているようなアカウントであれば必要に応じて、以下ドキュメントに従い従来のAWS Glueの権限管理の設定を AWS Lake Formaionの権限管理モデルへアップデートの考慮が必要となります。
Upgrading AWS Glue Data Permissions to the AWS Lake Formation Model - AWS Lake Formation
Step1：データ解析者となるIAMユーザーを作成する
クエリを投げてデータを解析する人のような位置づけのユーザーを以下の通り作成します。
IAMユーザ名: datalake_user
アタッチするIAMポリシー:
・AmazonAthenaFullAccess (AWS管理ポリシー)
・DatalakeUserBasic (インラインポリシー*3)
*3
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess", "glue:GetTable", "glue:GetTables", "glue:SearchTables", "glue:GetDatabase", "glue:GetDatabases", "glue:GetPartitions" ], "Resource": "*" } ] }
Step2：AWSCloudTrailログを読み取るためのアクセス許可をワークフローロールに追加する
今回、データレイクの蓄積対象がAWS CloudTrailである事から、Step0. で作った IAMロール:LakeFormationWorkflowRole に DatalakeGetCloudTrail という名前のインラインポリシー(*4)をアタッチします。
<your-s3-cloudtrail-bucket> には自身のAWS CloudTrailの S3bucketのARNを指定します。
*4
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": ["arn:aws:s3:::<your-s3-cloudtrail-bucket>/*"] } ] }
最終的に以下3点がアタッチされていればOKです。
・AWSGlueServiceRole (AWS管理ポリシー)
・DatalakeGetCloudTrail (インラインポリシー 上の内容=*4)
・LakeFormationWorkflow(インラインポリシー Step0で作成アタッチ済み=*1)
Step3：データレイク用のAmazon S3バケットを作成する
(任意の名前で) yourName-datalake-cloudtrail といったS3バケットを作成します。 これはAWS CLIの方がコマンド一発で楽です。
% aws s3 mb s3://ytamu-datalake-cloudtrail make_bucket: ytamu-datalake-cloudtrail %
Step4：AWS Lake Formation でAmazon S3のパスを登録する
ここからが、AWS Lake Formaitonの画面操作となりますが マネジメントコンソール -> AWS -> AWS LakeFormation -> 左ペインの Data lake Locations から Register location を押下し、
データレイクとして利用する上のステップで作成したS3バケットのURIを指定していきます。
Step5：データ取り込み場所(S3バケット)へのアクセス許可を付与する
ワークフローがデータ取り込み先(S3バケット)に書き込めるように、権限を付与する必要があります。 左ペインの Permissions - Data locations からGrant を押下し、
LakeFormationWorkflowRole を指定し、保管場所として上のステップで作成した S3バケットを指定し権限を付与します。
(参考) Data lake administrators に指定がされていないと、いくらIAMユーザー:Administratorでも以下の様にエラーが出るようでした。
Step6：データカタログにデータベースを作成する
こちらはAWS Glueを利用した事がある人ならおわかりかと思いますが、AWS Glueの機能を利用している作業となります。(AWS Lake Formationの画面からでもデータベース作成が可能という事です)
左ペインの Data catalog - Databases からCreate database を押下し、
lakeformation_cloudtrail という名前でデータベースを作成します。
名前を指定して1クリックで作るだけなので簡単です。
Step7：データのアクセス許可を付与する
データカタログ内にメタデータのテーブルを作成するための許可を付与する必要があります。 左ペインの Permissions - Data permissions から Grant を押下し、
上のステップで作成したデータベース: lakeformation_cloudtrail への操作権限を LakeFormationWorkflowRole に付与します。
Create table , Alter , Drop にチェックを入れ (Describeは当チュートリアル作成後に追加されたようで指定はありませんでした) Superにチェックがついていたら外します。(デフォルトでついていませんでした)
ここで、注目なのがパーミッションの指定が Create table , Alter , Drop と SQLのGRANT構文チックなチェックボックスで直感的にデータカタログに対するアクセス制御が可能な点です。
その他、AWS Lake Formation権限の付与の詳細は以下ドキュメントを参照してください。 Security and Access Control to Metadata and Data in Lake Formation - AWS Lake Formation
Step8：Blueprints を使用してワークフローを作成する
まずBlueprintsとは、データレイクにデータを簡単に取り込むという事を実現する「データ管理のテンプレート」だそうです。
簡単な指定をするだけで事前によしなに定義されたAWS Glueのワークフローを利用出来るといったイメージで、執筆時点で大きく2種類(データベース用、ログファイル用)が存在しています。
左ペイン Register and ingest - Blueprints から Use blueprint を押下します。
デフォルトで表示される画面は以下のような感じです。
今回は、AWS CloudtrailのBlueprintsを利用するので指定し、作成していきます。
Blueprint type: AWS CloudTrail
CloudTrail name: ご自身の環境で設定された名称
Start date: 検証なので範囲は少なめに(半月程度にしました)
Target database: lakeformation_cloudtrail
Target storage location: s3://ytamu-datalake-cloudtrail
Data format: Parquet
Workflow name: lakeformationcloudtrailtest
IAM role: LakeformationWorkflowRole
Table prefix: cloudtrailtest
画面を見てお分かりかもしれませんが、Blueprints ついてラジオボタンの選択を切り替える事でフォームの項目も連動して切り替わるイメージとなります。
Step9：ワークフローを実行する
ワークフローをオンデマンドで実行するように指定したため、ワークフローを手動で開始する必要がありますので実行します。
このチュートリアルの場合、指定範囲にもよりますが10minかからない程度で処理が終わると思います。 AWS CloudTrailのログは指定のS3バケット内に取り込まれている筈なので確認します。 きちんとParquet形式でターゲットに指定した S3バケットに取り込まれていることが確認できました。
% aws s3 ls s3://ytamu-datalake-cloudtrail/cloudtrailtest_cloudtrail/region=ap-northeast-1/year=2020/month=10/day=30/ 2020-10-30 15:43:26 626859 part-00005-dbbf0059-75cb-4d5d-9dd1-eedf8234d76e.c000.snappy.parquet %
Step10：datalake_userにテーブルのSELECT権限を付与する
データアナリスト(datalake_user) がクエリできるように、データカタログのテーブルに対するアクセス許可をする必要があるので権限を付与します。 (ワークフローを実行したユーザーには作成したテーブルに対するアクセス許可が自動的に付与されるそうです)
左ペイン Permissions - Data permissions から Grant を押下し、 ユーザー、データベース、テーブル、アクセス許可(Selectのみ)を指定します。
Step11：Amazon Athenaを使用してデータレイクをクエリする
ここからは動作確認作業です。
AWSマネジメントコンソールにIAMユーザー:datalake_user でログインし直し、Amazon Athena を開きます。当該テーブルに対し、プレビューのSELECTのクエリを実行し、正常に SELECTが出来る事を確認します。そして、それ以外のオペレーションを実施し、AWS Lake Formation側の制御により権限エラーで失敗することを確認します。
プレビューのクエリ例
SELECT * FROM "lakeformation_cloudtrail"."cloudtrailtest_cloudtrail" limit 10;
当該ユーザー(datalake_user)にはIAMのポリシーとしては以下がアタッチされているので、本来であればSELECT以外も出来るはずですが、AWS Lake Formationの権限管理が聞き上手く制御が出来ている事がわかります。
・AmazonAthenaFullAccess (AWS管理ポリシー)
権限エラーで失敗するクエリ例
DROP TABLE cloudtrailtest_cloudtrail;
チュートリアルを振り返って
ここまででチュートリアルは終了となりますが、実際に触ってみて個人的に重要と感じたポイントを振り返ると
- AWS Lake Formationのコンソールの画面にてポチポチとするだけで他AWSサービスと連動し、データレイクを構築出来るという点
- AWS Lake Formationモデルの権限管理レイヤーにてSQLライクで直感的な集約管理が出来る点
- Blueprintsのお手軽さ
あたりかなと思います。
特にBlueprintsについては、今回利用したAWS CloudTrail以外でも利用出来るものが用意されているので、今までAWS Glueでワークフローを組み込んでいた処理も1クリック指定するだけとなった点は便利です。
ちなみにBlueprints画面からWorkFlowの実行履歴等を確認出来ますが、Run IDを押下すると、以下画面のよう AWS Glue の Workflow画面へと遷移します。 事前に用意されているものを指定するだけでこれだけの処理を作り込んでくれている〜といった内容が確認できてちょっと感動するのでここは実際に触って覗いてみると面白いかもしれません。
Blueprintsは執筆時点で以下5点となりますが、これから便利で使えるものが充実していくであろうと思われます。(ので期待してしまいます)
- Database snapshot
- Incremental database
- AWS CloudTrail
- Classic Load Balancer logs
- Application Load Balancer logs
まとめ
これからAWSでデータレイク構築の際にはAWS Lake Formationの利用を検討したいと感じました。
