ビッグデータには価値ある経営情報が詰まっていますが、その価値を最大限に引き出すのは容易ではありません。本記事では、Amazon Web Services(AWS)上でビッグデータ基盤を効果的に構築する方法を解説します。
AWSでビッグデータ環境を構築する際に押さえておきたい意思決定のポイント
組織に流れ込む膨大なデータの中には、ビジネスを成功へ導く鍵が眠っています。ビッグデータには競争優位につながる価値ある情報が含まれていますが、そこから示唆を引き出すのは容易ではありません。パブリッククラウドは、ビッグデータを効果的に収集・保存・分析するために必要なコンピューティングパワーを、必要なだけ提供してくれます。本記事では、最大の成果を得るためのAmazon Web Services(AWS)上でのビッグデータ基盤設計について解説します。
パブリッククラウドが解決するビッグデータの課題
かつてビッグデータの活用は、ほぼ無制限のコンピューティングリソースに資金を投じられる大企業だけの特権でした。しかし、クラウドコンピューティングの登場と、オンデマンドのリソース・サービスの普及によって状況は一変しました。事実上無限のリソースを必要なときだけ利用し、使った分だけ支払うことができるようになったのです。
クラウドの進化に伴い、ユーザーは容量確保よりもアプリケーションコードや分析クエリの開発に集中できるようになっています。クラウド黎明期には、仮想マシン上にインスタンスを立ち上げ、自社のコードを動かすアプリケーションを自分でインストールしていました。その後、クラウドプロバイダーがマネージドサービスを提供するようになり、ソフトウェアスタックの多くを担うようになりました。そして現在では、サーバーレスコンピューティングによってサーバーのプロビジョニングに費やしていた時間が解放され、開発者はビジネス価値の高い業務に集中できます。
クラウド技術が進化を続ける今、適切に活用すれば、規模を問わず多くの組織がビッグデータ技術の力を手にできます。
ビッグデータ基盤の主要レイヤー
扱うデータの量・種類・速度が膨大であるため、リアルタイムまたはニアリアルタイムでデータを収集・保存・処理できる、堅牢で柔軟なアーキテクチャが欠かせません。企業は、利用可能なデータの量と多様性に対応できるよう技術スタックを進化させ、その作業を最高速度で——多くの場合リアルタイムまたはニアリアルタイムで——遂行できるインフラを整える必要があります。
効果的なビッグデータプログラムが求める幅広いタスクをこなすには、データの保存・処理・利用を担う多層アーキテクチャが必要です。データは分析の前後で保存されるため、双方向のデータフローを実現できる構造であることも欠かせません。
ストレージレイヤー
このレイヤーでは、データを保存し、カタログ化や分析が可能な形式へ変換します。特定の種類のデータをどう保管するかは、コンプライアンス規制やガバナンスポリシーによって決まります。ただし、保存方法が処理方法を決定づけたり、その逆になったりするべきではありません。
データアクセスとガバナンス
ストレージレイヤーに流れ込む膨大なデータと、データ変換・処理・分析によって新たに生み出されるデータ資産やバージョンを把握するには、効果的なデータガバナンスのプロセスが欠かせません。その中核となるのがデータカタログです。メタデータを専用のデータ管理・検索ツールと組み合わせ、データ資産にクエリを実行するインターフェースを提供し、信頼できる単一の情報源(Single Source of Truth)として機能します。AWS Glue Data Catalogは、処理に使うAWS分析サービスを問わず、バッチ処理ジョブの中央メタストアとして機能します。
バッチ処理で扱うデータは通常データレイクに保存され、さまざまな形式の大量ファイルを格納できます。アクセス管理を簡素化・一元化するサービスであるAWS Lake Formationでは、AWS Glue Data CatalogがAmazon S3データレイクへのアクセス制御を提供し、Amazon Redshift(Amazon Redshift Spectrum経由)、Amazon Athena、AWS Glue ETL、Amazon EMR(Sparkベースのノートブック向け)など、主要なAWS分析サービスと連携します。
オブジェクトストレージ
Amazon S3のようなオブジェクトストレージは、事前のスキーマ定義やデータ容量の制限なくあらゆる種類のファイルを保存できるため、データレイクに最適です。Spark、Hive、Prestoといったビッグデータフレームワークがネイティブに対応し、複数のアベイラビリティゾーンにまたがって99.999999999%のオブジェクト耐久性を実現します。
データレイクは、利用準備の状態に応じてランディング、Raw、Trusted、Curatedの各ゾーンに分割します。データレイク内のデータは、取り込みや分析準備にかかる時間を短縮するため、通常はスキーマを事前定義せずに取り込んで保存します。
ストリームストレージ
リアルタイムのデータストリームやイベントは、Amazon Kinesisのようなストリームストレージ製品で保存できます。Amazon Kinesis Data Streamsを使えば、リアルタイム分析のためにストリームから直接読み込めます。一方、将来の分析に備えてデータを保管したい場合は、Amazon Kinesis Data Firehoseでデータレイク・データウェアハウス・分析サービスといったターゲットへデータを送り、後から分析することも可能です。
AWS Glueクローラーを使えば、ストリームから追加された新しいデータセットやパーティションを検出できます。1回の実行で複数のデータストアをクロールし、メタデータを抽出してAWS Glue Data Catalogにテーブルとして登録します。AWS Glueで定義したETL(抽出・変換・ロード)ジョブは、ソースおよびターゲットのData Catalogテーブルで指定されたデータストアに対して読み書きを行います。
分析レイヤー
用途に応じて、バッチ・インタラクティブ・ストリーム・予測など、さまざまな分析手法でビッグデータからビジネス価値を引き出せます。
バッチ分析は、日次や週次の売上レポートのような用途で、数分から数日の間隔でデータを処理します。Amazon EMRは包括的なクラウドビッグデータソリューションで、Apache Sparkのようなデータ処理フレームワークを用いてバッチ分析を実行できます。
インタラクティブなデータ分析は、分散データベースシステムとレンダリング機能を組み合わせ、ビジネスインテリジェンス(BI)の分析力を最大限に引き出します。セルフサービスのダッシュボードのように、システムから数秒で答えを得たい場面に適しています。ここでもAmazon EMRが活用でき、SparkやSQLクエリエンジンのPrestoと組み合わせます。大規模で構造化されたデータセットにはAmazon Redshiftが適しています。Amazon S3に保存された非構造化・半構造化・構造化データには、Amazon Athenaが有効です。
ストリーミング分析は、不正検知アラートのようにリアルタイム性が求められる用途で利用されます。Amazon EMR上でSpark Streamingを使うか、Amazon Kinesis Data Analyticsを使えば、ニアリアルタイムの分析パイプラインを構築できます。
予測分析は機械学習を活用し、ユーザーの購買履歴・検索履歴・属性・評価などをもとに将来の行動を予測します。Amazon Sagemakerは予測分析に適したソリューションで、機械学習タスクを一元的に実行できる環境と、モデルの構築・学習・デプロイに必要なフルマネージドのインフラ・ツール・ワークフローを提供します。
利用レイヤー
利用レイヤーは、分析エンジン、データクエリ、AI・機械学習アプリケーション、データ可視化を活用し、大量のデータから有用なビジネス情報を引き出す層です。利用者は概ね2つに分けられます。
ビジネスユーザーは、Tableauのような可視化アプリケーションや、Amazon QuicksightのようなフルマネージドBIツールでデータを読み解こうとします。Elasticsearchのデータを可視化するために、オープンソースのUIであるKibanaを使うこともあります。
もう一方はデータサイエンティストです。たとえばR Studioのようなツールから統計分析用のエンドポイントへアクセスしたいというニーズがあります。JDBCドライバーでAmazon AthenaやAmazon Redshiftに接続し、データに直接クエリを実行することも可能です。
ビッグデータ基盤設計のベストプラクティス
ユースケースは一つひとつ異なりますが、パブリッククラウド上でビッグデータの仕組みを設計するうえで成果につながりやすい指針があります。
- ビッグデータプログラムから引き出したいビジネス価値に焦点を当てましょう。施策が達成すべきビジネス目標を明確にしたうえで、その視点をもとに必要な技術をアジャイルに提供していきます。
- システムを疎結合にし、新しいツールや技術を大きな混乱なく統合できるようにしましょう。巨大なモノリシックアプリケーションに依存するのではなく、小さなシステムへ分割すれば、各サブシステムを反復的に進化させ、長期的に育てていけます。
- アーキテクチャを構築する際は全体像を捉え、戦略ビジョンに沿ったアジャイルなプログラムとして取り組みつつ、スケーラビリティを担保するテンプレートを取り入れましょう。
- データを安全に保つため、信頼できる包括的なデータガバナンスのプログラムを整備しましょう。
- 用途に合ったツールを選びましょう。データ構造、レイテンシー要件、スループット、アクセスパターンを踏まえて選定します。中でもデータ構造とアクセスパターンが最も重要です。
- 車輪の再発明はやめましょう。マネージドサービスやサーバーレスサービスを活用すれば、これらの技術に注ぎ込まれてきたエンジニアリングの知見とベストプラクティスをそのまま取り込めます。マネージド/サーバーレスサービスはスケーラブルで弾力性があり、可用性・信頼性・セキュリティに優れ、運用管理の手間もほとんどかかりません。
- コスト意識を持ちましょう。ビッグデータ=高コストとは限りません。
DoiTのビッグデータ基盤設計プロセス
DoiTは、AWSのデータ・分析領域において深い専門性と公式パートナーコンピテンシーを有しています。アーキテクチャと運用の両面でお客様の課題に寄り添い、リスクや摩擦を抑えながら目標達成を加速させます。
プロセスはまず、お客様のビジネスモデル、提供する製品・サービス、チーム体制、リリース戦略、運用体制を把握することから始め、そこからデータに関するニーズ・リソース・ゴールへと焦点を絞っていきます。たとえば次のような質問をします。
- すでにビッグデータソリューションを導入していますか?
- 導入済みの場合、それはオンプレミスですか、それともすでにクラウド上にありますか?
- 主な利用アプリケーションと利用者は何ですか?(BIレポート、MLなど)
- データソース(プロデューサー)は何ですか?量・速度・データ構造の観点でお答えください。
- データ取得・処理から提示までの各ステージを教えてください。
- 機微なデータはどのように扱っていますか?どの規制に準拠する必要がありますか?
- チーム体制はどうなっていますか?(ビジネス側・技術側の双方について)
- プロジェクト管理にはどのような手法を使っていますか?
- 技術チームのメンバーはAWSにどの程度習熟していますか?
- 抱えている課題は何ですか?
- カバーしたいユースケースは何ですか?
- 優先事項と期待値は何ですか?
これらの回答をもとに、最適なアプローチを以下のいずれかから選びます。
- Migration Readiness Assessment(MRA):AWSへの移行を計画されているお客様向けに用います。80問にわたる詳細な質問票をもとに深掘りを行い、事実関係やお客様・インタビュアーの所見を集めて、次のステップを定義します。その後、お客様のクラウド成熟度と移行成功に向けて必要な取り組みを評価する詳細なレポートを作成し、共有します。これにより、移行経路、スケジュール、リソース、資産棚卸し/依存関係、技術ドキュメントを定めることができます。MRAはAWSの無料クレジット申請にも活用できます。
- Well-Architected Review(WAR):すでにオンボーディングを終え、現状を評価したうえで、生じているドリフトを是正するためのアクションと優先事項を特定したいお客様に有効です。WARはAWSが開発し業界で広く採用されている評価フレームワークを用い、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、サステナビリティの6つの柱で評価します。本番環境の改善に向けて、最大$5,000のクレジットベースの資金提供も用意されています。
本番環境の改善に活用できます。
- トレーニング:DoiTのカスタマーイネーブルメントには、特定のAWSサービスに関するトレーニングも含まれます。たとえばImmersion Daysでは、概念的な知識だけでなく実践的なハンズオン体験まで提供する深掘りセッションを行います。
- プロトタイピング(概念実証):DoiTは、KPIに基づく成功基準を定義したうえで、週次の定例セッションで疑問や障壁を解消し、最適化の助言を行いながら技術実装を伴走支援します。プロトタイピング完了後はKPIに照らして結果を測定し、適合性、得られた学び、次のステップを判断します。
次のステップ
データから計り知れないビジネス価値を引き出したいとお考えの方は、AWS上でのビッグデータ基盤設計について、ぜひDoiTにご相談ください。