![[レポート] クラウド上に効率的なビッグデータ処理基盤を構築するには？～データ特性に応じたシステム設計～ #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2016/06/aws-summit-tokyo-2016.png)
[レポート] クラウド上に効率的なビッグデータ処理基盤を構築するには？～データ特性に応じたシステム設計～ #AWSSummit
当エントリは、先週開催された『AWS Summit Tokyo 2016』、3日目のセッション『クラウド上に効率的なビッグデータ処理基盤を構築するには？～データ特性に応じたシステム設計～』のレポートです。
当日はプレス参戦していた為、写真を交えてセッション参加レポートをお送りしたいと思います。当セッション登壇者はアマゾンウェブサービスジャパン ソリューションアーキテクト 下佐粉 昭氏です。
目次
まずは本セッションで扱う処理の範囲についての言及から。当セッションでは、KinesisやAWS IoT等を使う『リアルタイム処理』では無く、一旦ディスクに保存(着地)してからの処理、すなわち『バッチ処理』『マイクロバッチ処理』に該当する部分について取り扱うものとします、という定義が最初になされました。
ビッグデータ処理基盤構築 3つのポイント
クラウド上でビッグデータの処理基盤を構築する上で変わらない事と言えば、『データを収集して分析し、可視化』するという流れの部分。分析では、標準的な技術やOSSを活用する事が可能です。構築する上で下佐粉氏は『3つのポイントがある』としました。
1つ目は『全てを叶える万能ツールは存在しない』。
自由検索やレポート処理等で数秒〜数分の短いレスポンスを直近数ヶ月のデータに対して要求する場合と、長期的なビジネストレンドを分析する為に過去十数年のデータを数十分〜数時間掛けて行う処理とでは求める基準(サイズ、レイテンシ、アクセス頻度、コスト等々)が異なります。全てをカバーするような万能ツールは存在しなし。必要な技術を必要なところへ配置する事が出来るかがポイント。逆に言うと、これがクラウドのメリットともなる。物理構築の負荷から解放され『何を使うか』にフォーカスする事がAWSでは出来ます。
2つ目は『データは加工せず、全期間残す』。
これまではディスクは高価で上限あり、データはサマリのみ、もしくは期間限定で保存し、処理出来る内容も固定的だったものが、クラウドに移行する事で安価＆上限無しのストレージを使えて、オリジナルデータを全て残す事ができ、処理対象や内容をビジネスに合わせて変える事が出来るようになります。インフラ管理者の仕事もサイズや処理内容を破綻しないように調整する事から、新しい課題に素早く対応出来るインフラを用意し、個別リクエストへの対応を行うと言ったスタイルのシフトが実現出来ます。
下佐粉氏はここで『データレイク』という用語にも触れました。
データレイクとは、多用なデータを一元的に保存してそのデータを失うことがない、サイズ制限からも解放された、決められた方法(例えばAPI)ですぐにアクセス出来るような環境の事を指します。いわば、『システム全体のハブ』のようなものです。以下に、データレイクに関する参考情報を幾つか載せておきます。
- そのデータ分析から顧客体験を向上させることはできますか？ | EMC | 東洋経済オンライン | 経済ニュースの新基準
- データ レイクとは | EMC用語集
- データレイクはビッグデータのストレージ：データウェアハウス(DWH)やデータマートへの取込口です | GiXo Ltd.
データレイクによって、データを全量保存出来、分析は必要なソリューションに応じて作成、そして可視化が済むムーズに行えるようになります。
3つ目は『スケールアウトで解決する』。
スケールアップ(up)はメモリ等の性能を上げる、そしてスケールアウト(out)は台数を増やす事。スケールアップには限界があるので、いつどこまで要望要求が増えるか分からない場合は『スケールアウト』で対応すべきです。
『スケールアウトだと高く付くんじゃないか？』と思いがちですが、クラウドにおいてはそれが当てはまるとは限りません。AWSでは重量課金制を採用しており、掛かった時間x台数のみしかお金は掛かりません。ノードを増やしたとしても利用時間が短くなるのであればコストは同じような形になるのです。この考えを身につけていれば、必要な処理を、スケールアウト出来る技術で爆発的に早く処理を終わらせてしまう、という事も可能です。
AWS＋ビッグデータ基盤
AWSのサービスは現時点で70以上展開されており、これらのマネージドサービスを活用する事で運用負荷は大きく削減する事が出来ます。オンプレ環境との比較をしてみると分かり易いと思います(下記画像参照)。
ビッグデータ周りのサービスに於いても、以下の様なサービス群が利用可能となっています。使えるものを使って行って、運用負荷を下げていってください。
ビッグデータ基盤にAWSをどのように適用させていくか、ここで1つ例を挙げて、どのように進めて行くと良いのかを解説していきたいと思います。
『オンプレミスのデータをAWSで分析する』というケースで考えてみましょう。データソースがオンプレミスの複数データセンターに存在し、定期的にそこからエクスポートしたデータをAWSに転送、10年間以上に亘る100TB以上のデータを保存分析する一方で、多くの利用者については直近1年間のデータのみ分析に使わない、というようなケースです。
経路と帯域
まずは『経路と帯域』について。経路はその手段によって帯域や安定性が異なります。インターネット経由／Direct Connect(専用線)／Import/Export Snowballといった選択肢が検討可能です。ここは重要なのですが、帯域を活かすには『並列化』が有効となります。データ転送の際には以下のポイントを踏まえて検討頂くのが良いでしょう。
- 送信データを小さくする(データを圧縮する、差分データのみ送る等)
- 帯域を使い切れていない場合は並列化が最重要：転送先がS3の場合はaws s3コマンドを使うと自動的に分割転送してくれる
- 帯域安定性を求める場合はプロトコルを専用のものに：商用ソフトウェアやTsunami UDP等
(Tsunami UDPに関するリンクを以下に追記しました。大変便利そうではあるのですが、以下AWSのブログで指摘している様にセキュリティ面に不安があるのも事実。合わせてAWSブログ及び西澤の方で紹介している『ExpeDat Gateway for Amazon S3』を使うという選択肢を検討してみるのも良いかも知れません。)
- Tsunami UDP
- ExpeDat Gateway for Amazon S3
保存
AWSで『データレイク』を実現するにはAmazon S3がうってつけです。S3ならば上限無しでサイジングも不要、高い耐久性で安価な費用の環境を実現出来ます。以降の内容は、S3を軸にデータレイクを組んでいく、という形でお話します。
データは"温度"も重要です。ここでの温度は"データの利用頻度・間隔"を軸に定義します。一概にこう、と言えるものでは無いですが、大まかにはホット(Hot)データは応答速度を重視し、範囲も限定されているデータ。逆にコールド(Cold)データと呼ばれるものは容量当たりの単価を重視し、膨大なデータを指します。HotなデータはElastiCacheやDynamoDB,RDS/RDB、ColdなものはGlacier、といった具合です。
分析
分析についても前述同様、スケールアウト可能な分析サービスを検討しましょう。この分野においては、RedshiftもしくはEMRでだいたい皆様悩まれます。2つのサービスに共通しているのは、標準的な技術で作られているところ、またスケールアウトが可能だという事です。
Amazon Redshiftはリーダーノードとコンピュートノードで構成されており、概念としてはEMRと同じく、処理を分散させています。この『分割させて処理を行う』というのはシンプルですが重要なポイントです。Redshiftの良いところはパッとすぐ使えるというところ。フルマネージドのデータウェアハウスですが、運用処理に必要な機能についても様々なものがビルトインされています。
EMRでは分散処理フレームワークを提供しています。環境上で、HadoopやSparkをすぐに使用する事が出来ます。Hadoopアプリケーションをビルトインで提供出来るようになっているのが良い点です。
オンプレで環境で使う場合と、EMRを使う場合で大きな違いがあります。それは、EMRFSという機能です。こちらの機能を使うとS3にデータを置き、EMRからダイレクトにS3のデータにアクセスしてHadoopやSparkの処理を実行する事が出来ます。これはつまり『Hadoop/Sparkをいつ落としても良い』という事です。データはS3に残っている為、このような事が出来るわけです。また、Hadoopの上で動くSQLエンジンも魅力の1つです。様々な環境にボタン1つでアクセス出来るようになります。
分析サービスをそれぞれどういう局面で活用、選択するか。頻繁にアクセスされるホットデータに対してはRedshiftに格納し、高速なSQLアクセスを活用して分析、また対象範囲が広く然程アクセス頻度が頻繁ではないという場合であればEMRを使ってS3上に置いたデータをEMRFSを介して処理していく、というのが一つの指針となるかと思います。
前処理
ETLのT、前処理に関する部分は重要です。トランスフォーム(Transform)しない事にはデータを必要な形で活用出来ません。この部分についても、スケールアウト出来ないと辛いところがあります。EMRであれば並列処理が得意です。条件に見合うようであれば、この部分にEMRを活用する事も検討してみてください。
可視化
可視化の部分については色々なソリューションが使えるので、必要に応じたものをお選びください。また、現時点ではまだプレビュー版ではありますが、QuickSightについてもいずれ使えるようになります。
事例で見るビッグデータ処理 on AWS
以降の事例紹介パートについては、セッション内でスライド資料が展開されていましたのでその内容を記載しておく事にします。
Nasdaq様 Redshift/EMRの使い分け事例
Redshiftの直近データ(と言いつつもボリュームは300TB...)、EMR+Prest+S3の全期間を共通のSQLでアクセスする、という内容となっています。
Finra様 1日750億イベントの処理を捌く基盤について
S3をデータ共有サービスとして定義し、EMRやRedshiftからアクセスするという内容です。
こちらについてはセッション内容のレポートもブログ化しています。併せて内容をご参照頂けますと幸いです。
スマートニュース様事例
マネージドサービスを中心として技術選択に関する解説スライドとなっています。
まとめ
以上、AWS Summit Tokyo 2016セッション『クラウド上に効率的なビッグデータ処理基盤を構築するには？～データ特性に応じたシステム設計～』のレポートでした。基本的な部分の解説でしたが、とても分かり易く整理されていましたので改めて勉強になりました。事例パートで紹介されていた各種スライド資料についてもRedshiftやEMRをビッグデータ基盤構築の選択肢に検討している場合、熟読必須の資料とも言えそうですね。私も改めて目を通して勉強しようと思います。
![[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
