AWS Lake Formationの導入効果

はじめに

こんにちは、D2Cインフラエンジニアの小川です。
先日、社内分析基盤のリプレイスに伴い、AWS Lake Formation導入を行い多方面でのシステム改善を実現しました。本記事では、Lake Formationを導入をしてよかったことをご紹介したいと思います。

背景

Lake Formationの導入に至る背景として、大きく以下2点がありました。

データの二重管理

分析基盤環境のあるAWSアカウントと、分析対象のデータの格納先のAWSアカウントが、複数アカウントおよび異なるリージョンにまたがっていました。これにより、分析基盤環境のあるAWSアカウントで、データの格納先AWSアカウントからデータの定期移行をする必要があり、この運用方法では以下の課題がありました。

• コスト増
  • データの二重保存料金の発生
  • AWS間のデータ転送料金の発生
• 管理者・ユーザー（分析者）の負担
  • データ転送に時間がかかり、分析業務に支障をきたす
  • データリカバリが必要な場合、手動で分析環境のデータをすべて洗い替える必要がある

権限管理の複雑化

データベースまわりの権限管理において、IAMポリシーでS3・Glueリソースへのアクセス制御を設けていました。しかし、ユーザーの増加・データベースの拡大に伴い、IAMポリシーが肥大化していました。これにより、誰がどのデータベースにアクセスできるのか、直感的に把握するのが難しく、管理が複雑化したり、権限過剰な状態になっていました。今後のユーザー・データベースの増加を考慮すると、IAMでの権限管理からの脱却が不可欠でした。

Lake Formationとは

Lake Formationとは、AWS環境でデータレイクを構築・運用するためのフルマネージドサービスです。データレイク作成に必要となる複雑な手順の多くが自動化されているため、データ移行や保管、クリーニングを安全に素早く行うことができます。今回は以下の図の赤枠の機能を使い、データレイクを構築しました。

やったこと

クロスアカウントデータ連携

Lake Formationを使ったクロスアカウントデータ連携を行いました。クロスアカウントデータ連携は以下の2通りを組み合わせることで実現可能であり、今回は同リージョン×別AWSアカウントでのデータ連携を採用することにしました。

• クロスリージョン × 同AWSアカウント
• 同リージョン × 別AWSアカウント

そのため、以下のようにデータ格納用のAWSアカウントにあわせる形で、分析環境のAWSアカウント自体のリージョン移行を行いました。

移行前

移行後

分析環境用・データ格納用のAWSアカウントのリージョンをそろえ、Lake Formationによるデータレイク連携をしたことで、S3データの二重保存料金、AWS間のデータ転送料金を丸ごと削減できました。また、データ転送を待たずに分析作業ができること、データリカバリ発生時の突発的なデータ入れ替え作業がなくなったことなど、ユーザーにとってより使いやすく、より分析業務に集中できる環境を提供することができました。

アクセスコントロール

Lake Formation導入により、データレイク運用により最適化されたアクセスコントロールができるようになりました。

きめ細やかさ

Lake Formationでは以下のように、データレイク特有の柔軟な設定が用意されており、IAMよりも粒度の細かいのアクセスコントロールが可能です。

• アクションをクエリ単位(SELECT、ALTER、DELETEなど)で設定が可能
• リソースをテーブルの列、行、または行・列組み合わせによるセルレベルでの設定が可能

そのため、Lake Formationでのデータのアクセスコントロールは、IAM側で粗く、Lake Formation側できめ細かに設定することが推奨されています。このやり方で運用することで、IAMでの複雑な運用が一切不要になり、運用負担を大幅に削減できました。さらにLake Formationできめ細やかにアクセスコントロールができるようになり、セキュリティ向上も同時に実現することができました。

スケーラブル

Lake Formationでは以下2つのアクセスコントロール方式を提供しており、今回はタグベースアクセスコントロールを採用しました。

• 名前付きリソースアクセスコントロール
  • 「ユーザーAは、テーブルXにアクセス可能である」のように、IAMプリンシパルごとに設定する方式。
• タグベースアクセスコントロール
  • 「ユーザーAは、ユーザーAと同タグが付与されたテーブル群にアクセス可能である」のように、タグ付けにより設定する方式。

理由としては、タグベースアクセスコントロールは、名前付きリソース方式よりもスケーラブルで、許可管理のオーバーヘッドも少ないためです。
例えば、3つのデータベースと7つのテーブルに対するアクセス許可を、ユーザー3名に付与する場合、名前付きリソースアクセスコントロールを採用すると、以下のように17個全てのルールを設定する必要があります。（これは、IAMポリシーのみで設定した場合も同様です。）

同じルールをタグベースアクセスコントロールに設定する場合、以下のようにユーザーに対して4つ、リソースに対して5つのタグの割り当てを行うのみで、わかりやすいです。さらに、ユーザーやリソースが増えた際も、必要に応じてタグを付与するのみでよいため、拡張に強くシンプルな運用が可能です。

おわりに

今回はLake Formationでのデータレイク構築における、導入前後のアーキテクチャーやユーザー・管理者のメリットをまとめてみました。Lake Formationの導入のきっかけや参考になればうれしく思います。
最後までお読みいただき、ありがとうございました。

参考

https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/access-control-fine-grained.html
https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/data-access-across-region.html