Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素

Azure Council Experts / 株式会社 FIXER 技術本部長谷口有近
BS3-1
3要素
2014 (C) Arichika Taniguchi, All rights reserved.

前説：クラウド時代のデザインパターン
• クラウドデザインパターン 3つの技術的観点
• 入力と処理、出力の分割
• 長時間ロードの分割非同期
• 負荷移動＝変更の容易さの担保
• 管理単位での負荷の制御とSLA運用性
• トランザクション一貫性の選択
• 緩い一貫性の許容と制限完全性
CPUの時間を変換
人の時間を変換
情報の時間を変換

前説：クラウド＝CPU時間変換と障害管理
処理時間＝Ticks＝クロック
CPU数
Workload
時間スケールをノード
超えて変換する
リソースの有効活用
数千台数万台いれば
いつも何か壊れてる
負荷も予測は困難
毎日何かを変更する
非同期
運用性
ダウンしうる環境での
情報の整合性
トランザクションと
スケールとのバランス
完全性
実行時間
≒
UX的観点での
許容出来る“待ち”
または SLA基準

…ではない３要素の話をします.

自己紹介
FIXER Inc. / ACE / Me
少しだけお時間を.

株式会社 FIXER とは？
• Cloud Service Vendor
– 2013 Microsoft Japan Partner Conference
Windows Azure パートナーアワード(CSV)を受賞.
• Full-stuck Managed Support
– 設計支援, アプリケーション最適化から開発, 運用までサポート.
• ご支援の事例
– IoT/M2M基盤 on Azure. / ゲーム基盤 on Azure.
© COPYRIGHT 2014 FIXER inc.

Microsoft Azure パートナーコンソーシアム
Azure Council Experts（略称：ACE／エース）アジュール評議会は、Microsoft
Azure を利用した技術やサービスを提供するリーディングカンパニーが集結し、
普及ならびに技術者の育成、ノウハウの共有などでコラボレーションを展開する
パートナーコンソーシアム。
顧客企業・団体技術者
一般社団法人 Azure Council Experts について
http://a-c-e.biz/

Microsoft Azure パートナーコンソーシアム
【書籍の出版】
【ACE加盟企業による定例会＆ワーキンググループの活動の様子】
Azure Council Experts 著
日本マイクロソフト監修
発行：日経BP社
編集：日経SYSTEMS
ページ数：176P
ターゲット：アーキテクト、システムエンジニア
一般社団法人 Azure Council Experts について

谷口有近 / たにぐちありちか
• 2000年 … SNSベンチャー
– ベンチャー企業で先進的SNS開発に従事.
• 2001年 … オンライン専業証券
– 取引システムの設計, 開発, 運用について、インフラからアプリ
ケーションまで広く従事.
– 課長職を経て ’09 エヴァンジェリスト, ’11 社長付IT戦略担当. 部門
を超えてのR&D, FSなどを支援.
• 2013年 … 株式会社FIXER 技術本部長
– クラウド・アーキテクチャの実践の魅力に取り憑かれ転職を決意

谷口有近の代表的な仕事（google me, please.）
• 福岡～東京間の証券取引システムのリアルタイム複製基盤
– ネットワーク側の設計・構築・運用を担当
• ソーシャルメディアセンサーの事業活用調査
– 株式市場の情報を補う情報抽出において成果
• 株価予測アプリの開発支援 (http://obt.hottolink.com/)
– 国内初 Bloomberg 向け株価短期予測アプリケーション開発支援
• 検索可能な事例化を支援してくれた企業に深く感謝！

アジェンダ
前半編

前半：クラウド設計を実現するための 3 要素
• “復元力” 指向の Cloud Design Pattern.
• 壊れることを前提に全てを設計すること
– システム設計のトレンド, 非機能要件のカバーは誰の仕事？
• “復元力” を実現するアーキテクト・トリニティ
• 動的な○○にどう対処するか.
– DevOps のトレンド, 業務方の拡張と設計者の役割
• 後編は http://www.slideshare.net/uesaka/enterprise-
cloud-design-pattern2014 (C) Arichika Taniguchi, All rights reserved.

“復元力” 指向の
Cloud Design Pattern.
壊れる事を前提に全てを設計すること.

システム可用性観点での設計その変遷
性能・負荷を事前に定
義, 壊れないシステム
を指向する.
構成変更し易い基盤構
成で負荷バランスを
ノード間で変える柔軟
なシステムを指向する。
運用自動化, 分散処理
系設計開発手法の導入
で, 直ちに変えられる
戻せる回復しやすいシ
ステムを指向.
～以前 2012年頃～2000年頃～
予期せぬ負荷に対応しようとコスト高なシステム構成に.
落ちないための検証/テストの繰り返しで時間観点でも足枷.
実際に負荷問題が発生, それは時既に遅しの合図.
過度な仮想化に旧来の運用体制維持で運用負荷は下がらず.
頻繁な構成変更に耐えるメンテナンス性が高いPG構造の設計はハイスキル.
API連携により外部システムに依存することになった負荷見積もり制御も高度な運用.
復元力(Resilience)
2006年頃～

「壊れないシステム」の設計
• 全ての機器, 部品を物理的に多重化, 全てのシステム構成要
素に対して, 可能な限り負荷を計算し推測する.
– 突発的なアクセス増や二次曲線的な利用者増が無かった時代.
– 業務要件の変化が穏やか故, システム変更の頻度も多くない.
– システム開発と運用, 改良も同じ企業が引き受ける.
• 適用イメージ
– メインフレーム, H/Aクラスタ, VRRP, V字開発, RAID
• 壊れさえしなければ “保守費は利益” のビジネスモデル

「柔軟なシステム」の設計
• 仮想化によるOSとハードウェアの分離, ネットワークのソフ
トウェア実装, 疎結合サブシステムで柔軟に.
– 仮想化がH/W由来による性能制限を緩和.
– 同時に, 仮想化に合わせたネットワーク構成変更の自由度向上.
– API指向, RESTful ブームでのサブシステム連携の一般化.
– IA分散, グリッド, 広域L2/FPGA/ASIC, アジャイルスクラム
• インフラ設計ノウハウ高度化, 不景気背景に仮想化売り出し
戦略は低コスト指向強く迷走.2014 (C) Arichika Taniguchi, All rights reserved.

このあたりまでは
非機能要件
インフラ側の設計運用により
まずまず吸収出来ていた.

非機能要件は
（コストと引き替えに）
パブリッククラウド故の
H/W環境の制約から
コード側での実装が必須に.

今は「回復しやすいシステム」設計が必要
• 安価H/Wを活用する故の低コスト, システム変更頻度を引き
上げる自動構成・自動運用, 世界規模サービスでデータ急増
– サーバーは突然落ちるもの.
– 単一ハードウェアには性能上限があるもの.
– バックアップ・復元が不可能なデータ量.
– パブリック・クラウド, SDN, Cloud Design Pattern.
• セキュリティ更新プログラムの頻繁な適用, プログラムの変
更作業が円滑になった.

システム設計のトレンド比較
～以前, 2000年前半 2006年～ 2012年～
冗長化 H/A A/A, グリッドクラウド分散処理
負荷分散 L7パーシステント L7ステートレスラウンドロビン
可用性日時のメンテナンスでシ
ステムを停止する
臨時メンテナンスでシス
テムを停止する
オンラインでシステムを
変更する
負荷マネジメント負荷を検証して準備する負荷にあわせて要因を
ノード間で移動する
負荷を細分化・分解し負
荷に応じたSLAを定義
SLA基準システム全体ユーザー毎機能毎
バックアップ日々取得するリアルタイムで取得する取得が困難、仕組みと細
分化により担保
システム設計業務単位アクター単位コード構造単位
開発プロセス V字開発アジャイル・スクラム＋DevOps (+ユーザ)
システム運用開発者が兼任運用担当が専任機械による自動化
システム変更頻度 1年間に数回 1ヶ月に数回 1日に数回
非機能要件の扱い H/W側に分業要件定義に書き出したコード実装→基盤側へ

実装負荷が高い非機能要件は
PaaS 側で極力カバー
（例：Azure Web Sites）
クラウドの“作法”を限定的に.

復元力＝Resilience
• オンプレミスでは Robust 指向＝壊れにくい
– 信頼性の高い部品を組み合わせ冗長化
– OSがダウンしないように手厚く
– 平均故障時間などの指標で品質を管理
• クラウド（グリッド以降）は Resilience 指向=回復し易い
– 信頼性はアルゴリズムの実装で担保
– OSはミドルウェアよりもさらに汎用的な部品に
– 部分的に壊れサービスレベルは一層フラグメント化

復元力を実現する
アーキテクト
トリニティ/マギ＝3要素
動的な○○にどう対処するか.

時代が求める動的な○○の追求の結果
• 動的なビジネス環境＝リーン・スタートアップ指向
– 意志決定の短縮・イニシャルコストの削減・変化を肯定.
• 動的なインフラ規模＝ Immutable Infrastructure 指向
– 容易に増強可能に⇒構成を静的にするせざるを得ない.
– OS 構成に依存しない/させない PaaS 的構造.
• 動的なソフトウェア構造＝ Disposable Components 指向
– 再利用するコード → 捨てられるコード（効率化の観点が変化）
– 技術者の力量と開発プロセスに合わせたコードブロックの選択.

世界のチャレンジから（あるコンサル体験）
• 目標：COBOLで書かれた業務系PGを C# で作り直し
– 10年以上動かしつつ直してきたガチの業務システム.
– RDBMSベースからメモリ処理へ, 処理速度を 1/10 以下に.
• 前提：スケジュール・規模は開発前から決まっている
– 数十万人が同時に利用し性能目標も決まっている.
– 数社による共同開発で性能上の都合からプロセス相乗り.
• 制約：業務仕様の匠は多いが C#技術者は 0 からのスタート
– 業務仕様書の本数からオフショア手配が先行.
– エンジニア採用難/資金繰り調整/その他諸々の課題.2014 (C) Arichika Taniguchi, All rights reserved.

世界のチャレンジから（あるコンサル体験）
• 対策：トランザクションスクリプトの有効活用
– エクセル仕様書からコードを起こしテストまでの開発工程を閉じ
たクラスに入れ込むことを前提に, 入出力部分をOOPで構築.
– 概要設計時点でデバッグテストを楽にするコード構造を決る
• ポイント：コアとなるOOP部分はオフショア使わず管理
– OOP/TDDの夢を追わず, 眼前の技術力をコード構造で活かす.
– 業務を知っている人間が少数で概要設計と詳細設計を同時に行う.
• 設計時点で業務～基盤～開発のエキスパートが同時に調整

よくあるITの実現プロセス
RFP
業務要件
開発者
PM/SE/
Architect
書類
口頭
書類
口頭

エンタープラズでも新しいトレンドを実践
Business
Architect
Code
Architect
Infra(Model)
Architect
Science
ここも
大切
ここ
大切
これも
大切

V字開発とマップ（すると失敗するかも）
業務
設計
詳細
設計
概要
設計
• 情報シスリーダー
• システムコンサル
• PM
• PL
• プログラマー
• SE
• PL
事業会社・ユーザー企業
システム子会社・SIer
工程管理

サイエンス指向の言葉で会話
Business
Architect
Code
Architect
Infra(Model)
Architect
• 実現可能なビジネスモデル
• 業務上許容されるSLA
• 業務はコード構造・システム
デザインに強く依存する時代
• コードの構造が運用
負荷を決定する
• 自律モデルの構築は
プログラムに強く依存
• 動的要素はソフト
ウェアにシフトする傾向
• ビジネスの成長と
業務別SLAに
あわせた
基盤の
Grand
Design
• データ
整合性等
数理的観点
Science

DevOps との比較
Product
Backlog
DevOps
トレンドの拡大は,
Opsの本来的な意味へ.
Enterprise 開発も
インハウス型へ近づく

Architect Trinity / Magi 大切な3要素
Business
Architect
Code
Architect
Infra(Model)
Architect
Science
コード“構造”が持つ
能力を存分に発揮
機能別のSLAを
設計する業務仕様書をPJの
共通語にしない
基盤は将来 PaaS が
カバーするので
モデリング中心かも
復元力
現在は基盤主役
デザインパターン
決定者の役割期待
復元力
業務を技術に
寄せる
運用設計を
コードでカバー
復元力

アーキテクト・トリニティ（三位一体）
• ビジネス価値ビジネスストラクチャ・アーキテクト
– ビジネスを技術に落とし込むアタリをつける力.
– 技術からビジネスを発想する力.
• インフラ価値インフラストラクチャ・アーキテクト
– クラウド時代の運用設計を構築し実践する変えられる力.
– コードを理解して構成を組んで非機能要件を要件にする力.
• ソフトウェア価値コードストラクチャ・アーキテクト
– チームの力量にあわせたコードストラクチャを実現する力.
– クラウドデザインパターンをアルゴリズムとして理解する力.

アーキテクト・トリニティでの復元力の実践
• ビジネスストラクチャ・アーキテクト
– 機能単位・サービス単位でのSLAを定義, サービスの復元を設計.
– 非機能要件を各種ストラクチャから理解し業務へ反映する.
• インフラストラクチャ・アーキテクト
– OS/ミドルを含めたリソースを隠蔽, 復元しやすい基盤を設計.
– 今は過渡期で必須, 最終的にはモデリングのロールと入れ替え.
• コードストラクチャ・アーキテクト
– 分散システムアーキテクチャを理解し情報を復元しやすい設計.
– コードストラクチャが持つ運用や業務でのレジリエンスを理解.

トリニティで Cloud Design Pattern を支援
• 技術3観点と実現指向のアーキ・トレンド “トリニティ”
• 入力と処理、出力の分割
• 長時間ロードの分割非同期
• 疎結合での負荷移動の容易さ
• 負荷単位でのSLAと制御運用性
• トランザクション一貫性の選択
• 緩い一貫性の許容と制限完全性
Business
Architect
Code
Architect
Infra(Model)
Architect
Science

さーて、後編のお話は？
• http://www.slideshare.net/uesaka/enterprise-cloud-design-pattern
• 前編の振り返り
• ACEのご紹介
• Cloud Design Pattern とは
• 今回の大量データ処理の概要
• Microsoft Azure におけるPaaSとScaleOut
• ScaleOutを前提とした大量データ処理用アーキテクチャ
• クラウド汎用パターンあらゆるプロジェクトで使用推奨
ACE | 株式会社NEXTSCAPE

Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素

Similar to Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素 (20)

More from Arichika TANIGUCHI

More from Arichika TANIGUCHI (8)

Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素