この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どーもsutoです。本記事はAWS re:Invent 2021のセッション「AWS で始めるレイクハウスアプローチ〜Analytics サービスアップデート〜」のセッションレポートです。
すでにこのセッションはオンデマンドで公開されていますので、興味がある方はぜひそちらもご視聴ください。
セッション概要
AWS でレイクハウスアーキテクチャを利用すると、お客様はデータレイクにデータを保存し、適材適所で利用可能な専用データサービスを活用することで、類を見ないコストパフォーマンスとスケーラビリティ、スピードと俊敏性を持ってデータドリブンにマーケットにおける意思決定を実現することができます。本セッションでは、レイクハウスアプローチとレイクハウスアプローチを実現するレイクハウスアーキテクチャに関する全体像について解説の上、レイクハウスアーキテクチャを構成する Analytics サービスとそのアップデートについてご紹介いたします。
- スピーカー
- 川村 誠(Makoto Kawamura)
- Analytics Solutions Architect at AWS
- セッションレベル: Advanced - 300
- セッションID: JAP302
アジェンダ
- レイクハウスアプローチとは
- 必要なデータにアクセスできる環境を用意するためのポイント
- スケーラブルなデータレイク
- 統一されたガバナンス
- シームレスなデータの移動
- 目的に特化した専用データサービス
レイクハウスアプローチとは
お客様がデータから価値はインサイトを得る際に直面する課題を解決する。
- これまではエンタープライズデータウェアハウス（DWH）中心からBIツールを利用して意思決定がなされてきたが、DWHのモデルが現実にフィットしなくなってきている
- 想定を超えるデータ量や多様なデータの種類から拡張性（データのサイロ化発生など）における問題、長期目線の運用に対応するための課題が出てきた
- データの民主化やガバナンスを効かせるための課題も出てくる
- データレイクの活用
- 多様なデータを一元的に保存
- データ消失の回避
- サイズ制限からの解放
- API呼び出しによる連携など決められた方法でアクセス
- セキュリティ＆コンプライアンス、監査へ対応
- データ蓄積と処理系の分離
- １ヶ所にデータを蓄積することで、データの信頼性が明確になり、新たなシステム要件に対応しやすい
- 処理系システムの切り替えが容易になり、アップデートなどの調整がやりやすくなる
レイクハウスアプローチに欠かせない要素
データの蓄積：Amazon S3
- 耐久性に優れる
- 様々なサードパーティ製品のアクセスに対応しているので、データを取り込む際のハブの役割に最適
- Intelligent Tieringによってコストを最適化しながら保存できる
- オブジェクトごとにアクセスコントロール設定が可能
- セキュリティ、コンプライアンス、監査機能
統一されたガバナンス：AWS Lake Formation
- セキュリティ、ガバナンス、監査を一元的に定義
- Quicksight、Glue、Athena、EMR、Redshift、Sagemaker
- 一貫して適用可能なポリシー
- セキュリティ、ストレージ、分析、機械学習サービス と統合
- データベース、テーブル、列に対する権限
- 【Preview】Governed Tables：保存されたデータが断片化されているときにデータをマージすることでパフォーマンスが向上
- クロスアカウントシェアリングで複数アカウントをハブアンドスポーク型で繋げることで、Single Source of Truthの実現ができる
シームレスなデータの移動：AWS Glue、Amazon Redshift
- 最近のアップデートでGlue3.0が利用可能
- 【New（Preview）】AWS Glue Elastic Viewsで、複数のデータストア間で簡単に結合と複製を実施可能
- Redshift フェデレーテッドクエリで、Amazon RDS/Aurora PostgreSQL や Amazon S3 上のデータに 直接クエリすることが可能
- 最近、Aurora MySQLもサポートされました
- Amazon Redshift Data Sharingで、クラスター間でセキュ アに簡単にデータを共有することが可能
- 【New（Comming Soon）】Redshift Data sharing for data lakeで、Redshift 上のデータを他のAWSサービスからアクセス可能に
- アクセス時にRedshiftクラスターが起動している必要はない
目的に特化した 専用データサービス
Athena、EMR、OpenSearch Service、Kinesis、Redshiftがあるが、本記事ではOpenSearch Serviceをピックアップ
- Amazon OpenSearch Service（Amazon ElasticSearchの後継サービス）
- 検索、可視化、最大でペタバイト規模のテキストと非構造化データを分析
- UltraWarm for Amazon OpenSearch Service：課題であったストレージコストを緩和できる機能
- 大規模ログ分析を低コストで実現する ための Amazon OpenSearch Service オリジナルのノードタイプ
- UltraWarm ノードは，S3 に保持した データに対してクエリを実行
- UltraWarm ノードに移動された インデックスは読み取り専用に
- インデックスごとに API を呼んで hot/warm の移動を行う
- Cold Strage（Amazon OpenSearch Service）
- UltraWarm からアクセス可能なインデックス保存領域で、普段使わなくなったデータをこちらに移すことでコストを削減
- Cold Storage に格納されたインデックスは検索不可能となり、UltraWarm ノードから 切り離されることでドメインのストレージサイズ上限に依存せず、更に長期間のデータ 保存を実現できる
- 保存したインデックスは UltraWarm ノードにいつでも戻すことが可能
感想
近年、企業のなかで部門を横断したデータ活用による価値の創出を行うために、多くのシステムのDBをデータレイクに蓄積するためのアーキテクチャについてご相談が増えています。
これから大規模なデータの集約、変換、活用を行う環境を実現するにはAWSにおいてどのようなサービス・機能を使っていけば良いのかが整理できる資料になっていると思います。
とくに去年あたりからRedshift、Glue系をどんどんユーザに使ってもらいたい意図があるのか、コスト削減や機能追加で多くのアップデートの波が来ているように感じます。
Keynoteでもありましたが、Redshift ServelessやEMR Servelessも来るようで、データ分析サービスも機械学習系サービスに負けないくらいのアップデートが続くことを期待しています。
2
