この記事は、Finatextグループ Advent Calendar 2024の3日目の記事です。
はじめに
ナウキャストでデータエンジニア/データプラットフォームエンジニアとして働いている@mt_musyuです。ナウキャスト社内のデータ基盤の構築や運用を行い、また社内の知見を生かしてクライアント企業様のデータ基盤の構築や運用の支援を行っています。
近年、データ利活用の推進や生成AIの利用が進む中で、データ基盤の重要性が増しています。単にデータ基盤を構築するだけでなく、増え続けるデータやユーザーを考慮した運用も求められています。そのため、データ基盤の構築や運用を効率化するために、IaC（Infrastructure as Code）の導入が重要であると考えています。もちろん、通常のシステム開発においてもIaCは重要ですが、データ基盤においては特にその重要性が際立っていると考えています。そう思っている理由をデータ基盤の特徴・要件を整理しながら述べていきたいと思います。
データ基盤の特徴・要件
データ基盤におけるIaCの重要性を理解するために、まずデータ基盤の特徴・要件について整理します。
データ基盤は以下の5つの特徴・要件を持っていることが多いと思います。
1. 多様なデータソースの統合
データ基盤は、さまざまなデータソース（データベース、API、ファイルストレージなど）からデータを収集し、統合する役割を果たします。このため、異なるフォーマットや構造のデータを扱う必要があります。オブジェクトストレージ(S3など)からデータを取得するのか、RDBからデータを取得するのか、またCRM(Salesforceなど)からデータを取得するのか、などバリエーションに富んでいます。
2. 複雑なユーザーアクセス権限の管理
データ基盤は、エンジニアだけでなく、アナリストやビジネスメンバーなど、さまざまなロールのユーザーが利用します。それぞれのユーザーに対して適切な権限を設定し、データのセキュリティを確保することが求められます。これが一つのテナント・アカウントに同居することがデータ基盤の場合、求められがち(なぜならばデータが複数のアカウントやテナントに散らばっていたら複数のデータを組み合わせた分析がしづらいため)なため、権限管理がより複雑になりやすいです。例えるならば1つのAWSアカウントに複数のWebサービスが同居しているような状態です。
3. スケーラビリティと柔軟性
データの量や利用者が増加する中で、データ基盤はスケーラブルである必要があります。また、ビジネスニーズの変化に応じて柔軟に対応できる設計が求められます。データ基盤はそれ単体では付加価値を生まないコストセンターに見られがちです。リッチなデータ基盤だけあっても、基盤にあるデータを利用したデータ利活用・データプロダクトがなければ、意味がありません。なので、素早く成果を出す必要があり、それに耐えうる基盤でなければなりません。
4. ガバナンスとコンプライアンス
データの利用に関するガバナンスやコンプライアンスの要件が厳しくなっている中で、データ基盤はこれらの要件を満たす必要があります。適切な監視やログ管理が不可欠です。
誰がどのデータにアクセスしたか、どのデータがどのように利用されたか、などの情報を記録し、必要に応じて監査を行うことが求められます。
5. データメッシュの必要性
小さな組織やPoC的にデータ基盤を構築する場合、中央にデータ基盤を構築し、そこにデータを集約して中央のデータチームで管理することが一般的でした。しかし、データ利活用が進むにつれ、データ基盤を利用するユーザーが増え、データの種類も多様化してきました。その結果、中央のデータチームがボトルネックとなり、データ基盤の運用が困難になることがあります。
ここで、データメッシュという考え方が注目されています。データメッシュとは、データ基盤を中央に持たず、データを利用するユーザーに近い場所にデータ基盤を配置し、それぞれのユーザーが必要なデータを自由に利用できるようにするアーキテクチャです。データメッシュは以下の4つの原則に基づいて設計されます[1]。
-
ドメインオーナーシップの原則:
- ドメインチームが自らのデータに責任を持つことを求める原則です。この原則に従い、分析データと運用データの所有権は中央のデータチームからドメインチームに移行します。
-
データを製品として扱う原則:
- 分析データに製品思考の哲学を適用する原則です。この原則は、データにはドメインを超えた消費者が存在することを意味します。ドメインチームは、他のドメインのニーズを満たすために高品質なデータを提供する責任があります。基本的に、ドメインデータは他の公開APIと同様に扱われるべきです。
-
セルフサービスデータインフラストラクチャプラットフォームの原則:
- データインフラにプラットフォーム思考を採用することを目指す原則です。専任のデータプラットフォームチームが、ドメインに依存しない機能、ツール、システムを提供し、すべてのドメインに対して相互運用可能なデータ製品を構築、実行、維持するための支援を行います。このプラットフォームにより、ドメインチームはデータ製品をシームレスに消費し、作成できるようになります。
-
フェデレーテッドガバナンスの原則:
- 標準化を通じてすべてのデータ製品の相互運用性を実現する原則です。ガバナンスグループによって推進され、データメッシュ全体にわたって標準化が促進されます。連邦ガバナンスの主な目標は、組織のルールや業界規制に従ったデータエコシステムを構築することです。
データメッシュを何も考えずに導入すると、データ基盤の運用が複雑化する可能性があります。そのため、データメッシュを導入する際には、データ基盤のアーキテクチャを再設計する必要があります。
データメッシュアーキテクチャ[2]
データ基盤をIaCで管理することの重要性
これらのデータ基盤の特徴・要件を満たすためにIaCは役に立ちます。
IaCの特徴として、以下のようなメリットがあり、これらはデータ基盤の構築や運用においても有用です。
一貫性と再現性の確保
こちらはデータ基盤の特徴・要件の
1. 多様なデータソースの統合
2. 複雑なユーザーアクセス権限の管理
3. スケーラビリティと柔軟性
5. データメッシュの必要性
に特に有用です。
多様なデータソースを統合するため、またきめ細やかな権限管理を行うためには、環境の一貫性が不可欠です。IaCを用いることで、インフラの構成をコードとして管理し、再現性のある環境を構築できます。
データのバリエーションが増えた際にも、IaCのコードを使い回すことで、迅速に対応できます。例えばS3のデータをSnowflakeにロードするパイプラインを一度Terraformなどで作成しておけば、新たなデータソースが増えた際にも、同じコードを使い回すことで迅速に対応できます。
多様なユーザーに対する権限管理も、IaCを用いることで一貫性を保つことができます。この複雑な権限管理を手作業でポチポチと行うのは非常に困難ですが、IaCを用いることで、権限設定をコードとして管理し、再現性のある環境を構築できます。
インフラの構築や変更をコードとして管理することで、そのコードをテンプレートとしてドメインチームに提供することができます。
これにより、各チームがセルフサービスでデータのパイプラインを構築できる環境を整えることができます。
ガバナンスの強化
こちらはデータ基盤の特徴・要件の
4. ガバナンスとコンプライアンス
に特に有用です。
IaCにより、インフラの変更履歴が明確に記録されるため、トレーサビリティが向上します。
これにより、ガバナンスやコンプライアンスの要件を満たすことが容易になります。いつどのタイミングで変更が加わったのかが簡単に確認できるため、監査やトラブルシューティングが容易になります。もちろん実際の変更の履歴はAWS CloudTrailやGCP Cloud Audit Logsなどのログを使って確認することもできますが、IaCを使うことで、GitHubのコミットログやCI/CDのログを使って変更履歴を簡単に確認することができます。
コードとして管理されるため、変更の承認プロセスを導入することも容易になります。
例えば、Two Person Integrity(2人以上の人が関与することで変更を行う)的に変更者以外の誰かの承認がデプロイには必須とする仕組みを構築することがコードで管理されているからこそ簡単に実現できます。
これらは、データ基盤に限らない、システム開発におけるIaCのメリットでもありますが、データ基盤においても同様に有用です。
とりわけデータ基盤のデータリソースの多様性や複雑な権限管理を考慮すると、IaCのメリットは大きいと言えるでしょう。
データ基盤をIaCで運用する上でのプラクティス
次にデータ基盤をIaCで運用する際に考慮すべきプラクティスについて述べます。
Single Source of Truthの確保
IaCを用いてインフラの構成をコードとして管理し、それがSingle Source of Truth(信頼できる唯一の情報源)であることを確保することが重要です。
IaCを実際のリソースに反映(Terraformの場合、apply)するのが原則CI/CD経由のみとすることで、インフラの状態が常に最新のコードに基づいていることが保証されます。
異なるスキルセットのメンバーでも変更を行いやすくするための考慮
異なるスキルセットを持つメンバーがIaCによるリソースの変更を容易に行えるようにCI/CDパイプラインを構築すると良いです。データ基盤のチームは、データエンジニア、データサイエンティスト、データアナリストなど、異なるスキルセットを持つメンバーで構成されていることが多いです。
そのため、CI/CDで自動でIaCの変更差分が確認でき、その差分が可視化できるようにすることが重要です。
Terraformを使っている場合は、Atlantisやtfcmtを使うなどして、ユーザー(開発者)のTerraform使用のハードルを下げることができます。
ガードレールの仕込み
IaCを用いて、セキュリティガードレールを事前に仕込んでおくことが重要です。例えば、ユーザーのパスワードポリシーを共通で強固なものに設定し、MFA（多要素認証）を必須とする、DBはTerraform経由でしか作成・削除できないようにする(ユーザーに付与する権限には作成・削除権限を付与しない)など。これにより、各チームにセルフサービス的にパイプラインの構築を行ってもらう際にも致命的なミスを防ぐことができます。
まとめ
データ基盤の構築や運用において、IaCを導入することで、効率的かつ安全なデータ管理が実現できると考えられます。ただ、世の中にはまだまだIaCで管理されているデータ基盤が存在していると思います。データ基盤を価値の出るプロフィットセンターにするためにも、IaCの導入を検討してみてはいかがでしょうか。
参考文献
-
Data Mesh Principles and Logical Architecture, Zhamak Dehghani, ThoughtWorks, 2020. https://martinfowler.com/articles/data-mesh-principles.html ↩︎
Discussion