はじめに
そろそろ暖かくなり春を感じるようになってきましたね。
そんな春、新しくデータレイクを構築し始める方もいらっしゃるのではないでしょうか。そんなときにぜひ認証の仕組みとして取り入れたいのが、このAWS Lake Formationですよね。
さてこのサービス、複雑なことで有名です。特に、DB作成の権限周りは非常に複雑となっています。ドキュメントを読み進めて何とか理解し、そのパターンを考えたので記事にしてみようと思います。
今回の記事は、なるべく前提知識も書きますが、「Lake Formationってなに？」という人が読んでもチンプンカンプンかもしれないのでご注意ください。
前提知識
（これだけでかなりの分量になってしまうので、かなり端折っていきます。）
Lake Formationとは
データレイクの認可を楽にしてくれるサービスです。
こちらの方の記事がとても分かりやすいので、一度目を通すとこのサービスでできることなどが理解できると思います。
AWS Lake Formation とは？を5つのポイントで理解する
ポイントは、S3のデータをGlueデータカタログ化することによって、Lake Formationで権限の一元管理ができるようになるというところですかね。権限の付与も、GUI上でポチポチできるので楽になります。
Lake Formationの初期セットアップ
公式ドキュメントを参考にしてください。これを実施することで、とりあえずLake Formationで権限管理ができるようになります。
データレイク管理者を作成したり、Lake Formationで管理をするS3バケットを指定したりします。
その中でもポイントだけ説明します。
4. デフォルトの許可モデルを変更する
今までのIAMオンリーの許可モデルから、IAM + Lake Formationの許可モデルに変更するということです。
これを実施しないと、いくらLake Formationで権限付与しても反映されません。結構忘れがちです。
6. データレイク用の Amazon S3 ロケーションを設定する
これは、Data lake locationsにS3のバケットを登録することを意味します。
これをすることで、その登録したS3バケット配下はLake Formationで権限管理できるようになります。
Lake Formationのペルソナ
さて、ここまででLake Formationで権限管理ができるようになりました。
そのうえで、こちらの公式ドキュメントで、ペルソナとそれぞれの役割を整理してくれています。
また、こちらの方のQiitaの記事 も分かりやすいです。
ペルソナの中で主要な3つをここで紹介します。
データレイク管理者
データレイクの管理者です。上で出てきた、Data lake locationsの登録などをします。そもそもLake Formationで管理ができるように、メタ的な作業を行う人ですね。
データエンジニア
Lake FormationでDB作成やTable作成をしたり、データアナリストの方々にその権限付与を行う人です。
Lake Formationの主役と言っても良いでしょう。この方たちが、Lake Formationの色々な機能を使って、データへの認証をコントロールします。
データアナリスト
データを使う人たち。基本はLake Formationについてはあまり意識しません。もし見たいデータが参照できない場合は、データエンジニアの方に問い合わせます。
初期セットアップを終えてDBを作成するまでにやること（本題）
ここからがこの記事の本題です。
ここまで、初期セットアップも終わって、各ペルソナも決まりました。さて、ではいよいよ権限管理だ！！となったときに、次にすることがDB（データベース）の作成かと思います。
そのパターンをドキュメントから整理しました。なお、ここではData Locationsという概念が重要になってきます。その説明は一旦ここでは省きます。
パターン①：データレイク管理者がDB作成（明示的な許可）
このパターンは、Data locationsを利用することで、データエンジニアに明示的にテーブル作成や更新操作を許可します。
ドキュメントを読むと、この方法ではデータエンジニアに対してDBに対するCreate table権限を付与する記載がないですが、これをしないと動きませんでした。
データレイク管理者がやること
- 空のDBを作成する
- Data locationsに、DBを作成したいS3バケットパスと権限管理させるデータエンジニアを登録する
- Data lake permissionsから、作成したDBに対して、権限管理させるデータエンジニアにCreate table権限を付与する
データエンジニアがやること
- DBにテーブルを作成する
パターン②：データレイク管理者がDB作成（黙示的な許可）
このパターンは、Data locationsは利用しません。その代わり、DBの設定でS3のパスを指定します。さらにデータエンジニアにCreate table権限を付与することで、黙示的にデータエンジニアに許可を与えています。
データレイク管理者がやること
- 空のDBを作成する。この際、LocationにS3バケットパスを指定する。
- Data lake permissionsから、作成したDBに対して、権限管理させるデータエンジニアにCreate table権限を付与する
データエンジニアがやること
- DBにテーブルを作成する
パターン③：データエンジニアがDB作成
このパターンは、明示的にデータエンジニアに許可を与えます。さらに、Create database権限もデータエンジニアに付与します。こうすることで、データレイク管理者ではなくデータエンジニアがDBを作成するパターンです。
データレイク管理者がやること
- Administrative roles and tasksから、権限管理させるデータエンジニアにCreate database権限を付与する
- Data locationsに、DBを作成したいS3バケットパスと権限管理させるデータエンジニアを登録する
- Data lake permissionsから、作成したDBに対して、権限管理させるデータエンジニアにCreate table権限を付与する
データエンジニアがやること
- 空のDBを作成する
- DBにテーブルを作成する
どのパターンが良いの？
まずはデータエンジニアにDBを作成させたいか？ を考えます。作成させたい場合は③、させたくない場合は①か②です。
データエンジニアがたくさんいる場合やあまりリテラシーが高くない場合は、DBが乱立する可能性があります。
一方で、データエンジニアがDBを作成出来ればいちいちデータレイク管理者に依頼などしなくてよいのでスピード感がアップします。
さて、ではDBを作成させたくない（つまり、DBはデータレイク管理者が作成したい）場合です。
この場合は、同じS3のパスで別のDBを作成することがそこそこあるか？ を考えます。ある場合は①、ほぼない場合は②です。これは、例えばテスト用に物理的なデータは1つだけどDBを複数作りたい場合などのことです。
①はData locationsにS3のパスを指定しているので、別のDBを作成した時に再度S3のパスを指定する必要がありません。
一方で、②は再度パスを指定する必要がありますが、DB作成時に一気にS3のパス指定までできるので楽（Data locationsに登録する手間が省ける）です。
Data locationsを使って明示的に権限を付与させると、DBとS3バケットと依存度が下がるんですよね。
逆に、黙示的な権限付与の場合は、DB作成時に直接S3パスを指定するため依存度が上がります。①と②の選択は、これをどうとらえるかというところがポイントです。
おわりに
一応まとめてはみましたが、なかなか難易度の高い記事になってしまいました･･･
特にData locationsのところですよね。これを利用しなくてもLake Formationでの権限管理は出来ますが、利用するとより高度な制御が可能になります。このあたり、また別の記事で解説出来たらなぁと思います。