hmoriya .net style 森屋英治

Just another WordPress.com site


投稿者: コメントする

アーキテクトフォーラム　マルチテナントアプリケーション設計手法

  • 久しぶりの成本さん、サーベイアプリケーションのデモから始まりました。マルチテナントアプリケーションのお話。

課題と必要性

  • 運用コスト、
  • コードベース管理、
  • テナント間の干渉、
  • カスタマイズ要求、
  • SLA

上記をどのように解決するかが、アーキテクチャの選択になる

  • ストレージの選択、パーティショニング
  • データスキーマの拡張性
  • パーティショニング
  • スケーラビリティ
  • プロビジョニングの必要性
  • ユーザ認証の選択
  • 管理とモニタリング
  • UIの拡張性
  • 課金

上記についての説明をしてきます。

「ストレージの選択」

  • IaaS vs PaaS 比較の説明　よくまとまっています。利用用途に合わせて選択が必要
  • SQL vs NoSQL　冗長化OR冗長の許容、

NoSQLの選択、

  1. KeyVaues
  2. Document　Database
  3. Column family database(HBase)
  4. Graph database(Neo4j)

ハイブリッドアプローチ（複数の選択）もよくあるパターンである。

ストレージノパーティショイニング

  • 高分離レベル
  • 低分離レベル

データスキーマの拡張

  • テナント毎に別テーブル
  • 複数スキーマを持つ単一テーブル
  • 単一テーブルと拡張用別テーブル

パーティショニング

  • Webロール・ワーカーロール
  • キュー
  • サービスバス
  • キャッシュ

インスタンス境界の設計

  • マルチインスタンス・シングルテナント
  • シングルインスタンス・マルチテナント
  • マルチインスタンス・マルチテナント

境界の設計

  • コスト
  • コードベース管理
  • SLA
  • スケーラビリティ
  • リソースの制限
  • 認証と承認
  • カスタマイズ
  • ALM
  • 課金
  • サードパーティーコンポーネント
  • レギュレーション

キャッシュのパーティショニング

  • Named Cacheによる分離
  • Regionによる分離
  • インスタンス共有
  • ストレージ分離戦略

Web・ワーカーロールのパーティショニング

  • 高分離レベル
  • 低分離レベル

Webリクエストのルーティング

  • URLパス
  • サブドメイン
  • カスタムドメイン名のマッピング
  • 認証、SSLプロビジョニングへの影響

Queueのパーティショニング

  • 共有キュー
  • 標準、プレミアムキュー
  • テナント毎キュー

Workerロール

  • Webロールの負荷軽減
  • Loadの平準化
  • スケーラビリティ
  • タスクのアサイン
  • キューによる優先度コントロール
  • ペシミスティックVSオプティミスティック同時アクセス制御
  • プログレストラッキング（進捗を考慮したキューのハンドル）

スケーラビリティ

  • 非同期コール
  • 小さいインスタンスをSO
  • 自動化（wasabi)
  • スケーラビリティユニット(アーキテクチャサブセット）
  • テストによるボトルネックの削除

ストレステスト

  • Visual Studio Load Test
  • 高負荷による例外の発見（キャッシュクライアント、存在確認など）
  • ボトルネックの発見

プロビジョニング

  • リソースのセットアップ
  • コンフィグレーション
  • カスタマイズ
  • 認証方式
  • プロセスの自動化

ユーザ認証

  • STSとのSSO
  • 1stパーティーIDP
  • 3rdパーティーIDP

管理とモニタリング

  • テスタビリティ
  • スクリプトによる管理の自動化
  • コンフィグレーション（サービスコンフィグレーションへの移管）
  • システム診断
  • エンドポイントの保護

その他の考慮事項

  • サブスクリプションモデル
  • 課金
  • SLA
  • Throtting
  • On-boarding プロセス

まとめ

  • データタイプに応じて適切なストレージを選択
  • パーティショニング戦略
  • Workerロールの実装と考慮事項
  • スケーラビリティ

Developing Multi-tenant Applicaitons in the Cloud dowonload

WAG.codeplex.com


投稿者: コメントする

アーキテクトフォーラム 2013　その１

久しぶりにアーキテクトフォーラムが開催され、懐かしい顔ぶれがそろった会になりました。１日でほぼ満席になっているのを見るとアーキテクチャに対する需要があることがわかります。

時代が求めるアプリケーションとは、ユーザ中心、ソーシャル、データ思考において価値を見出す必要性を説明されていました。テクノロジーの複雑化が進み、アーキテクチャを使って都市計画を作り構想力をつけましょうという趣旨でこの会を開いたそうです。メインテーマは下記の通りです。

  1. マルチデバイス対応
  2. データ連携・同期
  3. サービス設計
  4. 集中化されたシステム運用、管理
  5. Dev/Ops

最初は、萩原さんの「これからのアーキテクチャ変遷と今後の技術戦略」です。

成熟化社会、リアルタイム性、つまり多様化とリアル（思考速度）へ対応したアーキテクチャが必要である。情報資源という制約への対応を考えて、思考速度への対応必要である。

  1. HWの進化と仮想化（各要素のスピードアップ）HDDが早くなっていない（この課題への対応例：マップリデュース）Open Conpute(FacebookのHW標準化）
  2. 3ティアアーキテクチャ（ロードバランサー、Webサーバ、ビジネスロジック、RDBサーバ）RDBの部分が集中しやすい、２フェーズコミットへの対応（耐障害性：新しいプロトコル,アトミックブロードキャスト）データ思考トランザクション（HWの進化と同期している）SWの信頼性の確保（データの複製を持つ、データ更新にオーバーヘッドがある＝＞非同期での更新反映が必要）耐障害性とレスポンスのトレードオフ）記録一貫性より因果関係の重要になってくる。（ログ、ふるまいの管理）
  3. Shared Nothing（データ思考トランザクション実行制御、Single Writerの原則、Incremental計算）耐障害性への対応が進んでいる。
  4. DSM（Distributed Shared Memory)論理的な共通化を推進している（Object Storeと各リージョンの隔離ドメインが存在）マルチテナントストレージ
  5. Elasticity（ワークロードによって、スケールアウト、スケールダウン、ルールベース、予見）
  6. Resilency(HW障害をソフトウェアで保障、Design for Failure,障害モデルによるアルゴリズムの選択）データセンター間の問題（通信遅延：タイムアウト時間の設定）SPOFの対応だけでは不十分、対称性、非対称性（均一なソフト、バラバラなシステム、対攻撃性、運用コスト）CAP定理をどう考えるかが重要。
  7. データ統合ICF（Infomation Capability Framework)MDMとSOA、Capabilityモデル、メタデータ駆動(Verb)非機能
  8. Client 技術（Web vs Natie App)
  9. 論理と物理設計(SLA,QoS,Latency CAPのCとAの調整）DevOpsによるPDCA（データドリブン、分析プロセス、カラム思考データベース）
  10. 開発の競争優位性（プラクティスからサイエンスへ、サイエンスに寄せて工学で勝負、ALM,TiDD,CI)萩原さんが最も言いたいポイント（工学的、プラクティスを減らしてサイエンス「実証されているアルゴリズム」を利用で解決する）HBassの例（Write スループット）予見できないものは工学、プラクティスとの組み合わせで解決しなければならない。SPDYなど

まとめ、アーキテクチャの重要性、１０種類のトレンドを説明されていました。データ中心、サイエンスの話が多かったかもしれません。人中心（価値と知恵）が重要と締めくくっていました。

クラウド時代トレンドをまとめたいいセッションだと思いました、私なりに適用技術、非機能要件、HW制約の変遷などの観点で確認できたので、勉強になりました。


投稿者: コメントする

HDinsightによるビックデータ

マイクロソフト アーキテクトフォーラム　２０１３

成本さんの２つ目のセッション。

マイクロソフトのHadoopのお話です。

ビックデータとは

３つのV（Volume,Velocity,Variety)を持つ（必ずしもすべて持つものはない）

  1.  Volume:ペタバイトレベル
  2.  Velocity:スピード、
  3.  Variety:Type

Mobitity,Cloud,Socialデータが新規として増加している傾向

BigDataとRDBの違い

  1. 構造化、非構造化データ
  2.  スキーマ（書き込み時、読み込み時）
  3. 高価と安価

Hadoop Ecosystem

  • HDFS
  • MapReduce
  • HBase(Column DB)
  • Pig(データフロー）
  • Hive(SQL Like)
  • Chukwa
  • Mahout
  • Flume
  • Sqoop
  • Avro(シリアル化）
  • Oozie(work flow)

HDFS アーキテクチャ

  • NameNode＝＞DataNode

Job TrackerとTack Tracker

  • Job Tarcker
  • Task Tracker(JVM)

Map and Reduce

  • Word Count (map で単語分解、Reducerで単語毎にカウント）

HDInsight

  • マイクロソフトがサポートしている範囲のコンポーネント群
  • クラウドとオンプレミスから選択可能（ワンクリックインストール）
  • 豊富なBIツールとの組み合わせ（エクセル、ピボット、SSRS)
  • SQL Serverとの統合
  • シンプルな管理ソリューション(システムセンターとの統合）
  • セキュア（AD統合）
  • プロダクティブ

DEV/DBAの視点

  • ソリューションの設計
  • 実装
  • テスト
  • デプロイメント
  • パフォーマンスの最適化
  • モニタリング（トラブルシューティング）

実際にBigデータの世界では、プロセスのようなものはない、データがたまった時点で分析を始める

コンフィグレーションのチューニングポイントは300箇所。

データサイエンティストがデザインする、データソースの品質がかなりのウェイトを占める

ほとんどが１人でやっているケースが多い（笑）

典型的なシナリオ

  • Webログ解析(もっとも多いシナリオ）
  • Sentiment分析（Twitter,評判）
  • リテール顧客分析
  • メディカルデータ分析（4000億件/Day)
  • オンラインリコメンデーション
  • フィナンシャルモデリング（地理が異なるクレジット決済など）
  • センサーデータ解析（787 1TBのデータ/Fright)
  • 予測分析(Wallmart 出店、売上予測)

つぶやき分析デモで、Tweetsのデータをアップロード、Hiveの作成、テーブルへのデータロード、分析

BigData Architecture Model

テクノロジーの選択

  • プラットフォーム
  • ランタイム
  • ストレージ
  • データ収集
  • クエリー
  • データ可視化
  • レポート
  • DWHとの統合

データ収集

  • インタラクティブ
  • 自動化されたバッチ
  • リアルタイムストリーム
  • リレーショナルデータベース(Sqoop)
  • Hive（構造化データに対して有効SQLライク）
  • Pig（どのような構造「データフロー」）
  • Map&Reduce（パフォーマンスを求める時）
  • Hadoop Streaming(Apiベース：テキストのみ）
  • 複数のツールから利用可能

その他のツール

  • HCatalog(データスキーマ、フォーマットのリポジトリ）
  • Oozie（ワークフローエンジン）
  • WebHCat(REST管理用API)
  • .NET Client SDK

データの可視化

  • ツール（エクセルなど）
  • DB転送
  • Sharepoint Server
  • カスタムアプリケーション

パフォーマンスの最適化

  • ストレージへのアクセス
  • ネットワークバンド幅
  • メモリ量
  • CPU使用率（ほどんどスカスカ）

各ステージで上記を分析する必要がある

これからBigDataを始める方は、HDinsightから始めるはいかがでしょうか。


投稿者: コメントする

迷えるITにはアーキテクチャ

画像

弊社サービスを優しく表現したサイトを立ち上げました、ぜひ参考になさってください。

アーキテクチャって何？どのようなサービスをしているかなどよくあるご質問をベースに整理してあります。

私は、企業向けのアーキテクチャのライフサイクルとして、

アーキテクチャ戦略、アーキテクチャ開発、アーキテクチャ管理の３つの工程を定義しています。

ご興味あるかたは、弊社ホームページよりご連絡くださいませ。


投稿者: コメントする

BUILD 2013へ

明日の飛行機で出発する予定ですが、いよいよ BUILDが開催されます。

前回は、昨年11月でしたので、かなり短いスパンでの開催で不安（すくないアップデート）もありますが、そろそろ大きな発表がないかなと期待もあります。

Windows 8.1の内容より、Web開発の新しい何かを期待しています。

勝率は2割くらいでしょうか。

それではまた。


投稿者: コメントする

インフラジスティックさんのイベント

お世話になっている、インフラジスティックさんが名古屋、大阪、東京都とSilverlight開発者向けイベントを開催されます。

池原さんは、もちろんのこと、東さんや、章太郎さんのSilverlight 5のお話も聞けます。

http://jp.infragistics.com/devdays8.aspx

なかなかSilverlightの開発に着手できていない方はも、是非参加ください。


投稿者: コメントする

アーキテクチャの再利用と利用（汎化と適用の狭間で）

一枚のアーキテクチャ図

企業にとって必要なアーキテクチャを検討すると、必ずどこの会社でも一枚のアーキテクチャ図を想像されます。古くは、クライアント・サーバモデル、物理三層モデル、論理三層モデルと言う言葉で連想されるアーキテクチャも、まさに一枚のアーキテクチャ図です。システム制約を整理していくと自ずとアーキテクチャ図が見えてきます。同じ制約の中で特定のソリューションを検討していくのですが、ここでアーキテクチャ図を書く方のバックヤードが大きく影響します。インフラよりの方、実装まで考慮してアーキテクチャを書く方、現行のシステムを踏まえてアーキテクチャ図を書く方など様々です。そうアーキテクチャ図は、書く方によって視点が違いますので、自然に俯瞰する図も変わるのが普通です。もちろん共通のモデリングツールを利用されていれば同じ視点の方で共通の表記のモデルが作成されてる例もあります。違って当たり前なのに、いつも同じアーキテクチャ図が異なる企業、異なるシステムで再利用されているは不思議でなりません。複数の視点によって書かれたアーキテクチャ図によって一つのシステムが表現されシステムがデザインされています。経験が豊富なアーキテクトの方は、アーキテクトを書いた後、あるいは書いている途中で不安に駆られます、「本当にこれで動作するのか、本当にこれでつながるのか、本当にこれで運用できるのか」。この不安を解消するためにアーキテクトの方は、小さな検証を繰り返します、まさにXPの用語でいうと「アーキテクチャスパイク」です。あなたの会社にいらっしゃるこの検証するかたを、私はアーキテクトと呼んでいます。俯瞰して、検証する、改善する作業ループこそが非常に重要です、眉間にしわを寄せている方が実は多いのも特徴です。IEEE1471を勉強されている方、ソフトウェアファクトリを勉強されている方は、異なるステークフォルダのViewpointを連想されると思いますが、まさに複数の視点でモデルを書くことが基本となります。ザックマンフレームワーク、マイクロソフトソリューションフレームワークもその一例です。

アーキテクチャの再利用と利用

ソフトウェア資産の再利用に関して相談されることが多いのですが、私はソフトウェアアーキテクチャによるソフトウェアの再利用をおすすめしていますし、すでに何社かの企業様に導入しています。アーキテクチャの再利用により、ソフトウェア資産を最大限再利用することを体系化し、実践してきています。最初に、アーキテクチャの再利用と利用は、その方向と考え方が全く異なることであることを説明しなくはなりません。再利用推進を前提としたクロスカットの組織は、必ず全社に適用するため汎化（一般化）したソリューションアーキテクチャ、またはフレームワークを構築しまが、多くの企業では、再利用まで至っていません。そうです、実際のプロジェクトへの適用がうまくいかないのです。この汎化と適用のバランスと方向が逆であることを理解していないために再利用できないのではないのかというのが、私の仮説です。適用するために汎化することを忘れ、汎化に集中するあまり実際に構築される方のことをあまり考えなくなり、適用率にこだわるあまり利用される箇所が限定されるのではないでしょうか。汎化には、範囲と度合いがあります、適用を前提として汎化するからこそ意味があるのです。ドメインに特化した汎化は、再利用率が上がるでしょうし、全社を前提とした汎化は、適用箇所が限定され効果が薄くなります。組織そのものも、汎化用と適用のチームは視点が異なりますので分けるのがよろしいのでないかと思います、実際、できる方は現場のプロジェクトに取り込まれてしまい、クロスカットの取り組みが維持できなくなります。汎化と適用の狭間には、非常に重要なバランスがあることを常に考えなくてはなりません。