昨日はPatterns & Practices Summit 2011に参加してきました。
普段あまり聞けないアーキテクチャなお話とBig Dataなお話が聞けるということで結構無理やりな感じで予定組んでの参加です。
以下メモというか走り書きというか。
Windows Azure Platformでのクラウドアプリケーションの進化
スピーカー：MS P&P Senior Program Manager 成元さん
基本的には patterns & practices – Windows Azure Guidance Part.3の先出解説でした。
Part.3ではOnPremiseとCloud（Azure）のインテグレーションというかハイブリッドなシナリオを想定したガイドになっています。これから広がっていきそうな内容ですね。
目指すところとしては…
- インテグレーションにおけるチャレンジ
- ボーダー超えたコミュニケーション
- データの同期と一貫性
- SSO
- 監視と管理
- ベネフィットの最大化
- 可用性とパフォーマンス
- スケーラビリティ
- 認証の多様性
というところ。
で、架空の会社のシナリオをもとに解説していく感じですね。
セッションではその前段として解説してるWindows Azureの機能の紹介がありました。
簡単にまとめるとこんな感じ
|
AppFabric Caching |
分散InMemoryCache、CLRオブジェクトなら保存できる、低レイテンシー |
|
AppFabric ServiceBus |
メッセージオリエンテッドミドルウェア、ACS統合でセキュアで堅牢な通信チャネル |
|
AppFabric ServiceBus Queue |
堅牢で永続可能なストレージ Up to 1GB/Queue |
|
AppFabric ServiceBus Topics |
Queueが持ってる機能は全部持ってる＋Publish/Subscribe |
|
AppFabric ACS |
フェデレーテッド認証シナリオ |
|
Azure Connect |
VPN、IPSec over HTTPS、既存資産の活用、シンプルなセットアップ |
|
Azure Traffic Manager |
複数DCでのロードバランス |
|
VM Role |
開発者がOSイメージをコントロール、実装の変更は不要 |
|
SQL Azure DataSync |
No-Codeで同期（ロケーション、頻度の選択） |
|
SQL Azure Reporting |
BIDS（Business Intelligence Design Studio）を使ったビジュアライゼーション |
|
Azure Marketplace |
ApplicationとData |
というような機能を適材適所で使ってるようなシナリオで解説してくれますhttp://wag.codeplex.com/releases/view/74838
凄いですね！
で、大きくシナリオ内でどんなところに注意して設計したか等のお話がありました。まぁメモなので適当に書き散らかしておきます
- アプリケーション特有の項目で監視したりするためのアプリケーションブロック … WASABi
- マスターをオンプレミスにして1Wayでクラウド上にリファレンスコピーとか（更新頻度低いものとか）
- トレードオフで
- センシティブなのでオンプレミスとか？
- 監査ログとか
- バッチ的な処理でオンプレミスに保持
- SQL Azureで処理してレポートそのものはオンプレミスに保存
- DataMarketと関連付けてみるとか
- どのDBをオンプレミス/クラウドにするか
- 弾力性と堅牢性の向上
- 経路・レイテンシをどうとらえる？
- 非同期なのか同期なのか
- DB分ける・アタックされてもいいようにするとか3段階で
- リライアビリティとのトレードオフで（レギュレーションとか）
- 可用性とパフォーマンスの向上
- CacheはExpireとPeriodをどうするか
- ビジネスロジックの管理
- Content Based Routing
- Content Filtering
- Provisioning Partners
- 権限管理、Subscription管理（Listenのみとか）＋メッセージ単位の認証
- Azure Connect
- SQL ServerでSQL認証にしとけばConnect Software入れる影響を最小限にできる
- WASABi
- Entlib Auto-Scale BlockとDiagnostics Block
- SystemCenterという手もある
- 読み込みと書き込みをわけて考える
- スケールするしない・ワークロードどうか・パラレル開発
- CorrelationId … ServiceBus Topicsの機能（メッセージの関連性を担保）
まぁ詳しくは本編をちゃんと読みましょうということで。
PaaSを活用したSaaS構築のためのアーキテクチャ設計のあり方 ～ 単純な載せ替えを超えて
スピーカー：アークウェイ 福井さん、MS エバンジェリスト 野村一行さん
Azureはプラットフォームなんですが、そのうえで動くアプリを増やすための施策をいろいろやられているようで、その中間報告的な話です。
こちらも具体例含めてPaaSをより活用していきましょう！というメッセージでいろいろ知見を頂きました。
- PaaSを活用するSaaSのあり方
- データ・コンテンツなどが差別化の要因
- そのほかはできるだけ標準化や共通化を目指すべき
- AzureはハイブリッドのPaaS
- Azureアーキテクチャ視点1
- On Cloud or Hybrid
- Azureに全部おく / サービスはAzure、データはOnPremise （経路のパフォーマンスとセキュリティは考慮点）
- 事例…宝印刷、FSOLの経理ワークフローとか
- クラウド前提で一部をオンプレミスにおく、クラウドへの移行の過程、短期間・新規のシステムだけクラウドに置く
- 短期的に高負荷になるものをAzureに置く
- ユーザー制約・法律とかでオンプレミスに置く
- 通信経路（レイテンシ）によるパフォーマンス低下
- インターネット網を利用することによるデータ送受信・セキュリティ
- 指針：サブシステム単位にクラウドとオンプレミスを分割できるか検討、パフォーマンス要求される場合はSSLによるファイル転送とか
- 3Screen+Cloud
- HTML/Device/Metro UI
- View Point（視点）をどうするか/何を選ぶか/セキュリティとか
- 認証の仕組みがバラバラになる可能性、Kerberosなど対応してないのも
- 処理ロジックをどうするか、どこに持たせるか
- 指針：ロジックの処理するレイヤの検討、セキュリティ、ネイティブ or HTML5 どうするか
- 通知（Notification）
- デバイス＋クラウドにおけるフィーチャーの1つ
- 通知シナリオがはまればいろいろ活用できる（MetroUIとか）
- PaaSとしてのAzureの特性を活かす
- クレームベース認証、マルチテナント、Marketplace
- きちんとお金を取るための仕組み
- 認証と認可の分離
- マルチテナントの場合 … セキュリティ（セグメント化）、課金など
- テナントを一意に識別しないといけない
- メンテナンス・バージョンアップには有利
- ただカスタマイズ要件が多いとシングルテナントのほうが向いてる
- Developing Applications for Cloud / P&P ※日本語化されてる
- Cloud Ninja
- Azure Marketplace
- 認証が入口ならMarketplaceは出口
- 共有・購入・販売できる
- データそのものに価値があるならData Market
- レベニューシェア MS2割
- カタログとしてだけMarketplaceも使える
- Windows Azure CSV Council
- クラウドサービスベンダーになろう！
- ISVをリクルーティング
- Azure上にサービスを公開してもらう
- ISVからCSVに
- カウンシルの成果物をホワイトペーパーとして公開
- CSV向け共通基盤アーキテクチャ
- まとめ
- PaaSを正しく活用しましょう 低コストで早期に市場に投入、SaaS開発
- 3S+Cが主流だろう
- Marketplaceで世界市場へ
- できるだけシンプルに・目的/制約を見て考える
Big Dataが及ぼすアーキテクチャの進化
スピーカー：MS DPE アーキテクト 萩原さん
先月末に行われたMSC 2011でもありましたが今日が本丸の萩原さんのBig Data話。内容的に撃沈しそうですがとりあえずキーワードだけでもメモってみました。（理解はこれからですね…）
MSC2011で同じセッションを見た方は違いを探すのもいいかもしれません。（せっかくなのでMSC2011の時のメモも含めてみました）
最近SQL ServerがHadoopもサポートみたいなNewsがありましたが、なんでMSがHadoop？Dryadは？Daytonaは？とかその辺の思惑も垣間見えますね。
- Big Dataの要素
- Volume … 大容量
- Velocity … 高頻度
- Variety … 多様なフォーマット・非構造化データ
- Complexity(Variability）… （データとデータとの）複雑度（重要）
- 複合的に他のデータと結び付けて解析とか
- Big Dataの背景
- ソーシャルグラフ、スマフォ、スマートグリッド（社会インフラ）、FromC ビデオ、FromC GEO
- 2つの流れ
- 水平分散並列実行…データの存在する場所上で原則処理する
- データの位置でアーキテクチャが決まる（スケールさせかたとか）
- Cassandra とか
- 垂直プロセス
- データを集める：Collect
- 保存する：Store
- オーガナイズ：Organize （構造化する）※非構造化データは前処理がいる
- 分析する：Analyze
- 共有する：Share
- Hadoopだとバッチ処理になる
- Storeした段階でデータがきまるのでリアルタイムクエリはStoreされた段階のデータ
- ESB/SOA … 意思決定
- 従来は可視化された結果をもとに人が判断
- スマートシティなどだと意思決定も複合的にデータをまとめたりして自動化も検討しないといけない
- ⇒ ESBが必要
- MSは現代的な処理機能がまだない
- 仮説検証を基にすることが多い
- 仮説検証型の仕組みを入れておかないとBig Dataは厳しい
- フィリップ・コトラー … Marketing 3.0
- Hadoopはイテラなデータには向かない
- パラメータ調整とか
- バッチ処理は基本的にオンデマンドになってる
- 並列処理
- Basic Physical DB Design in PDW
- Shared Nothing Design
- Distributed Tables
- Larger Fact Table in Hash Distributed Across All Compute Nodes
- Replicated Tables
- Graph構造を扱ったデータ分析は今後必要になる → 今のやり方だと厳しい
- 人と人、人とモノ、モノとモノとか
- 2-D Piping
- 処理のそれぞれを並列化する
- MapReduceとか
- Unix-pipesは1-D
- MapReduceとデータパラレル
- MapReduceの振る舞いを制御する関数がある → インフラとして定義（Hadoopとかで利用）
- データ転送減らして効率化するためにどうするかとか…たくさん考えないといけない
- フィルタかけたりデータの前処理も大事（自前でやる）
- Common Join
- MapJoin
- ReduceしないJoin = データ転送しなくて済むので早くなる
- 今のHadoopはやらない（アプリでやる）
- 基本的にデータ量が同じぐらいのとき
- データ量に差があるときは少ない方をコピーして処理とか
- PDWHの考え方になる
- 今のHadoopは昔のDBの技術を取り込んでる段階、分散処理としても高度なわけではない、単純
- テーブルスキャンするけどIndex使わないとか
- バッチなので必要ない、という指向
- 効率化の為にいろいろ取り込んでる
- Big Dataならではの進歩はどこか
- CQRS（Command-Query Responsibility Segregation）列指向
- 行は意味・更新系、列は属性・参照系
- 更新系（OLTP）と参照系（分析）を分ける
- 商品が売れたと 売り上げが計上された と同じ売れたという事実を異なる視点で捉える
- 行を取り込んで列を取り出すとか
- RDBはどっちもできるけどどっちもふつう（不得意？）
- B-Treeはシーケンシャルは早いけど…読み取りはおそめ
- データ分析の世界ではリアルタイムは難しい（CQRSは更新と参照が非同期なので）
- ⇒ なのでバッチ処理
- センサーなどのログは、Casandraみたいな、結果整合のストレージ
- Columnar Database（カラム指向データベース）
- 列の単位でデータが入る（属性ごとにファイルが変わる、ストアが変わる）
- ビット操作なので高速（ビットマップIndexとかでやってるような）
- 圧縮しやすい → I/Oコストが減る（データ転送が減る）
- Denaliもカラム指向を含めている
- 参照系が多いときは列指向、更新が多いときは行指向にするとかできるRDBとか（TeraData）
- ワークロードみて自動的に変わるとか
- MapReduceとかだとDBを組み合わせて列指向とカラム指向を混ぜるとか
- ハイブリッドに使っていこう
- 並列RDBとHadoopの組み合わせとか
- Hive QL – Join in MapReduce
- Mapでキーをつけて Reduceでまとめて取り出す
- キーをどうつけるかは重要
- Job = Directed Acyclic Graph
- 有効循環グラフ
- Hadoopだと自前でやる
- Asakusaみたいなフレームワーク使わないと大変
- DLS
- LSM（Log Structure Merge) – tree
- 今までのRDBはB-Tree
- NoSQLの世界で出てきた
- 書き込みに最適化（読み込みは遅くてもいい）
- 書き込み時に2か所に書き込む
- DiskにLogはく
- メモリ上のキャッシュに乗せる（memtable）
- メモリ上なので一定間隔で永続化する（Disk）
- GFS/HDFS（分散ファイルシステム）
- DiskのLogは3か所に分散する（可用性のためだけに使われる）
- 全部シーケンシャルにアクセスする
- ⇒ Disk書き込み全部シーケンシャルなので早い
- ディスクはテープだ…シーケンシャルが早い（ランダムアクセスすると遅い、しちゃだめ）
- ⇒ Big Dataな世界のコア
- 読み取りにはブルーンフィルタかます（メモリ上に存在するかどうかのフラグを持ってる）
- ※あるときはあるけど、ないといってもない場合がある
- 不要データのごみはあとでゆっくり削除（ガベッジコレクト）
- バックエンドでいろいろ使われだしてる
- HadoopDBの場合
- Job Tracker/Master Node と Data Node（Master/Workerモデル）
- ノード上に分散DB
- スケジュール管理や通信にMapReduce使う
- 総データサイズが小さい（＝扱うデータ量が多い）場合、パフォーマンスがよくない（HDFSに向かない）
- ファイルの保存場所とかの管理に負荷がかかる
- Fat-B-Treeで改善とか？
- MapReduceはバッチ処理（こけても後でデータとってきて処理できる）
- いろいろ制限多い（データ依存関係あったりすると…）
- 変化するデータには向かない（だからデータとってくる）
- Transactional MapReduce
- BSPに近づくアーキテクチャスタイル
- バルクシンクロナイズパラレル
- 典型的なのはソーシャルグラフ
- 常にデータが変化してる
- 分散KVS（全体で1つのデータとする）
- 処理は各データ上でしたい → ローカルデータを使った並列・パターンマッチングなどの実行後データ交換（通信）しローカルで処理する
- 一貫性・状態遷移（オブジェクト指向）
- Windows HPC Server 2008 R2 Cluster
- Dryadは構成要素の一つ
- クライアント側でも並列処理させる
- クライアント上、データ上などそれぞれワークロード違う
- → Job Schedulingが必要（現在ではHadoopではできてない）
- Hadoopは業界標準なのでやってく
- DryadでMapReduce2.0を見据えてやっていく
- プログラミングモデルの統合
- LINQ、非同期プログラミングモデルの組み合わせとか
- Agentも入るか？（Afterモデル）
| Sawzall,FlumeJava | Pig,Hive | LINQ to HPC |
| Map-Reduce |
Hadoop |
Dryad |
|
GFS/Big Table |
HDFS/S3 |
Cosmos/Azure/SQL Server |
こんな感じでした。おわり。
ブチザッキ 