ストリーム分析の手法の分類

バッチ処理による分析では、通常分析対象のデータが出揃っていて目的の範囲で容易に取り出すことができる。 例えば、12/2に行うバッチ処理で「11月いっぱいの全取引データを分析する」とか。 しかし、ストリームを扱った分析では、データの対象範囲をどう決めるかがもっと重要になってくる。 流れてくるデータを次々にじゃんじゃか処理しないといけないので、対象範囲の切り方がうまくないと当然パフォーマンスに影響が出てしまう。

ストリームを対象とした分析において、ストリームをどのようなタイミングで分析するか、どのような範囲で区切って分析するかにはいくつかの分類があるようです。 以下を参照した自分なりの理解を書いてみます。

innu.hateblo.jp

github.com

ストリーム分析の手法について HopSize と WindowSize という２つのパラメータで考える。

1. HopSize: ストリーム（対象データ）を、どのような時間間隔で分析するか。
2. WindowSize: ストリーム（対象データ）を、どのような範囲に区切って分析するか。

例えばHopSizeが1秒でWindowSizeが5秒なら、「1秒間隔で直近5秒のイベントを対象に分析をする」という感じ。 そして、この２つのパラメータによって、分析手法をいくつかに分類している。

1. Hopping Window 分析

HopSize が定数で、かつ HopSize < WindowSizeの分析。

上記の「1秒間隔で直近5秒のイベントを対象に分析をする」というのはまさにこれ。 この場合に、分析の度に対象となるデータ範囲が重複することがある。 正確には WindowSize - HopSize の時間範囲のデータが前後の分析で重複した対象範囲となる。

例えば

1. 14:00:10 に 14:00:05 以降 14:00:10 未満 のデータを分析し、
2. 14:00:11 に 14:00:06 以降 14:00:11 未満 のデータを分析し、
3. 14:00:12 に 14:00:07 以降 14:00:12 未満 のデータを分析し、
4. ・・・

という流れ。 この場合に、1番目の分析処理と2番めの分析処理を比べると、 14:00:06 〜 14:00:10 の4秒間のデータが重複している。

2. Tumbling Window 分析

HopSize が定数で、かつ HopSize = WindowSizeの分析。

HopSize と WindowSize が同じ値の場合、分析の度に対象となるデータの範囲に重複が無く排他的となる。 この場合は、とくに Tumbling Window という呼ぶ。

3. Sliding Window 分析

HopSize を事前に決定することはせず（できず）、イベントが発生する度にWindowSizeの範囲を対象に分析を行う。 HopSizeはイベント発生によって（事後的に）決定されるイメージ。

Sliding Window は、分析処理の起動を分析側で制御できない（しない）ので、負荷などに対してかなり考慮が必要そう。

オブジェクトストレージ と ファイルストレージ と ブロックストレージ

ストレージの話をする際、この３つをはっきりと比較して考えたことがありませんでした。 それぞれの意味や用途は分かっているのだけど。

ファイル・ストレージは、データを階層構造で保持しており、ファイル自体にはメタデータは含まれません*1。 階層構造自体が一種のメタデータの役割を果たしているとも言えます。 例えば、/home/hata/tmp/nginx/access.logというファイルであれば、このファイルはhataユーザの持ち物でNginxのアクセスログを一時的に置いているのかな、というのが分かります。 このファイルを/直下に移動してしまえば、上記のような情報（メタデータ）はなくなります。 代表的なファイル・ストレージとしてはNASです。

オブジェクト・ストレージは、ファイルを階層構造で格納せずフラットに保持し、ファイル自体にメタデータを付属させます。 こうすることで、ファイルストレージのような構造（ディレクトリ）の区切れを意識することなくファイル単位で柔軟に分散、再配置ができます。 そのため、ブロックストレージは大容量ストレージの構築に向いています。 一方で、データ更新のレイテンシが高く更新の頻繁な用途には向きません*2 代表的なオブジェクト・ストレージといえば、やはりAWS の S3でしょう。

ブロック・ストレージは、ファイルをブロックというさらに細かい単位ににおいて管理します。 通常、１つのファイルは１つ以上のブロックにまたがります。 ファイル・ストレージはファイル・システムやファイル共有機能を経由してデータ転送されるため、ブロックストレージに比べるとレスポンスが遅い。

もちろん、ブロック・ストレージをOSがファイルシステムとしてフォーマットして使えば、そのOSを介してアクセスするユーザからはファイル・ストレージとしてアクセス可能になります。

itpro.nikkeibp.co.jp

この視点でAWSのサービスを眺めると、↓な感じでしょうか。

		レスポンス	容量の拡張性
S3 (Simple Storage Service)	オブジェクト・ストレージ	△	◎
EFS (Elastic File System)	ファイル・ストレージ	◯	◯
EBS (Elastic Block Store)	ブロック・ストレージ	◎	◯

この記事の下のほうの比較表がとてもまとまってて分かりやすいです。

www.fujitsu.com

---

このブログの全ての意見は個人のものであり、所属する団体や企業とは一切関係がありません。
All opinions expressed are solely my own and do not express the views or opinions of my employer.

*1:ファイル作成日時や作成者などのごく簡単なメタデータは保持しています

*2:なんで、他と比べてレイテンシが高くなるんだろう？HTTPによるAPIアクセスだから？HTTPが使われているのは一般的な実装の話なだけであって、オブジェクトストレージ自体の定義とは関係ないような気もするけど。

AWSのサービスとアーキテクチャのベストプラクティスを体系的に学べる『Amazon Web Services 定番業務システム12パターン設計ガイド』

『 Amazon Web Services 定番業務システム12パターン 設計ガイド 』を読みました。とても良い本でした。タイトルからAWS初心者向けかと思ったんですが、既にAWSでのシステム運用経験がある中級者の人でも楽しめます。

アーキテクチャだけでなくAWSのサービス自体の説明が豊富

典型的な各種利用シーンについて、アーキテクチャ設計の側面から解説しているのですが、実際にはそのアーキテクチャで使用するAWSのサービスを結構きちんと説明しれくれているのが嬉しいです。

基本的なサービスから順に理解していける構成

最初のほうの章ではEC2やS3、RDSなどといいたド定番のサービスについてもしっかり説明があります。初心者の人でも最初から読み進めていくことで順を追って理解できる構成になっています。

扱っているサービスが幅広い・新しい

2016年06月にGAになったばかりの EFS *1 や、API Gateway、Lambda といったサービスの説明も入っています。

以下に、扱っているサービスや機能を節毎にまとめてみました。 見てもらうと、その構成の秀逸さと網羅性の高さが分かると思います。

---

• その節で初めて登場する、またはその節で大きく解説されるサービスを太字にしています。 EC2やELBなど頻繁に登場するサービスは２度目以降の登場では省略しています。

【基本編】

1章 Webシステム

• 1-1［パターン1］キャンペーンサイト
  • VPC
  • EC2, HVM(完全仮想化)/PVM(準仮想化)
  • EIP
  • EBS
  • Route53
• 1-2［パターン2］コーポレートサイト
  • S3
  • Cloud Front
  • ELB, SSL Termination
  • AZ
  • EBS, Provisioned IOPS, EBS Optimized
  • RDS, Multi-AZ, マイナーバージョン自動アップグレード, メンテナンスウィンドウ
• 1-3［パターン3］性能重視のイントラWeb
  • Cloud Watch
  • Auto Scaling
  • Direct Connect
  • ElastiCache
  • RDS for Aurora
  • AMI
• 1-4［パターン4］可用性重視のイントラWeb
  • Route53, DNS Fail Over
  • RDS, Cross Region Read Replica（クロスリージョンリードレプリカ）, 「リードレプリカのマスタ昇格」
  • S3, Cross Region Replication（クロスリージョンレプリケーション）
  • EC2, Auto Recovery
  • Cloud Watch, 「このインスタンスの復元」
  • 「Zabbixで異常検知をトリガーにコマンド実行」

2章 ストレージシステム

• 2-1［パターン5］バックアップ
  • Glacier, ライフサイクル設定
  • Storage Gateway, ゲートウェイ補完型ボリューム, ****
  • オンプレミスDB と AWS EBS 間のDRBD
  • S3, Versioning, Server Side Encryption
  • RDS, 自動バックアップ
  • Direct Connect
  • サーバーワークス社のDRスターターパック
• 2-2［パターン6］ファイルサーバー
  • SimpleAD
  • WorkDocs
  • S3, s3fs
  • データ同期ツール: LinuxのDRBD, WindowsのDataKeeper
  • クラスターソフト: LinuxのPaceMaker, WindowsのLifeKeeper
  • Storage Gateway, ゲートウェイキャッシュ型ボリューム（階層型ストレージ）
  • Direct Connect

3章 データ分析システム

• 3-1［パターン7］構造化データの分析
  • Red Shift
  • AWS パブリックデータセット
  • データ連携ツール: Flydata Sync、Flydata Direct
  • データ分析ソフト: Tableau Software
• 3-2［パターン8］非構造化データの分析
  • Elastic Map Reduce (EMR) Hive
  • Tableau Server
  • データ連携ツール: Fluentd

【応用編】

4章 クラウドネイティブ

• 4-1［パターン9］サーバーレスのインフラ
  • API Gateway
  • Lambda
  • ジョブ管理ソフト: WebSAM JobCenter （ コミュニティAMI ）
  • CloudFront over API Gateway

5章 アプリケーションの高速開発

• 5-1［パターン10］サーバーアプリの高速開発
  • CodePipeline
  • CodeDeploy
  • Elastic Container Service (ECS)
  • ECS-optimized AMI (Dockerエージェントと ECS Agent がセットアップ済みのAMI)
  • リザーブドインスタンス
  • CIツール: Jenkins
• 5-2［パターン11］モバイルアプリの高速開発
  • AWS Mobile SDK
  • Device Farm
  • Cloud Formation
  • Device Farm Jenkins Plugin

6章 ハイブリッドクラウド

• 6-1［パターン12］オンプレミス環境との連携
  • VM Import
  • オンプレのリソース状況をトリガーにした Auto Scaling
  • Direct Connect

---

メジャーなサービスからスタートして最新のサービス、そしてサードパーティのソフトやサービスまで本当に幅広く取り扱っています。 また、機能の多いサービスは、最初に登場するときは基本的な使い方のみで高度な機能は後続の節で紹介されるような構成です。 良い復習になりました😋

---

このブログの全ての意見は個人のものであり、所属する団体や企業とは一切関係がありません。 All opinions expressed are solely my own and do not express the views or opinions of my employer.

*1:書籍内ではプレビューの時点の情報をもとに記載されている