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 ConferenceWindows Azure パートナーアワード(CSV)を受賞.

• Full-stuck Managed Support– 設計支援, アプリケーション最適化から開発, 運用までサポート.

• ご支援の事例– IoT/M2M基盤 on Azure. / ゲーム基盤 on Azure.

2014 (C) Arichika Taniguchi, All rights reserved.© COPYRIGHT 2014 FIXER inc.

Microsoft Azure パートナーコンソーシアム

Azure Council Experts（略称：ACE／エース）アジュール評議会は、MicrosoftAzure を利用した技術やサービスを提供するリーディングカンパニーが集結し、普及ならびに技術者の育成、ノウハウの共有などでコラボレーションを展開するパートナーコンソーシアム。

顧客企業・団体技術者

一般社団法人 Azure Council Experts について

http://a-c-e.biz/


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 向け株価短期予測アプリケーション開発支援

• 検索可能な事例化を支援してくれた企業に深く感謝！


http://obt.hottolink.com/

アジェンダ前半編


前半：クラウド設計を実現するための 3 要素

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

– システム設計のトレンド, 非機能要件のカバーは誰の仕事？

• “復元力” を実現するアーキテクト・トリニティ• 動的な○○にどう対処するか.

– DevOps のトレンド, 業務方の拡張と設計者の役割

• 後編は http://www.slideshare.net/uesaka/enterprise-cloud-design-pattern


http://www.slideshare.net/uesaka/enterprise-cloud-design-pattern

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


システム可用性観点での設計その変遷

性能・負荷を事前に定

義, 壊れないシステム

を指向する.

構成変更し易い基盤構

成で負荷バランスを

ノード間で変える柔軟

なシステムを指向する。

運用自動化, 分散処理

系設計開発手法の導入

で, 直ちに変えられる

戻せる回復しやすいシ

ステムを指向.

～以前 2012年頃～2000年頃～

予期せぬ負荷に対応しようとコスト高なシステム構成に.落ちないための検証/テストの繰り返しで時間観点でも足枷.実際に負荷問題が発生, それは時既に遅しの合図.

過度な仮想化に旧来の運用体制維持で運用負荷は下がらず.頻繁な構成変更に耐えるメンテナンス性が高いPG構造の設計はハイスキル.API連携により外部システムに依存することになった負荷見積もり制御も高度な運用.

復元力(Resilience)

2006年頃～


「壊れないシステム」の設計

• 全ての機器, 部品を物理的に多重化, 全てのシステム構成要素に対して, 可能な限り負荷を計算し推測する.– 突発的なアクセス増や二次曲線的な利用者増が無かった時代.

– 業務要件の変化が穏やか故, システム変更の頻度も多くない.

– システム開発と運用, 改良も同じ企業が引き受ける.

• 適用イメージ– メインフレーム, H/Aクラスタ, VRRP, V字開発, RAID

• 壊れさえしなければ “保守費は利益” のビジネスモデル


「柔軟なシステム」の設計

• 仮想化によるOSとハードウェアの分離, ネットワークのソフトウェア実装, 疎結合サブシステムで柔軟に.– 仮想化がH/W由来による性能制限を緩和.

– 同時に, 仮想化に合わせたネットワーク構成変更の自由度向上.

– API指向, RESTful ブームでのサブシステム連携の一般化.

• 適用イメージ– IA分散, グリッド, 広域L2/FPGA/ASIC, アジャイルスクラム

• インフラ設計ノウハウ高度化, 不景気背景に仮想化売り出し戦略は低コスト指向強く迷走.



このあたりまでは非機能要件

インフラ側の設計運用によりまずまず吸収出来ていた.


非機能要件は（コストと引き替えに）パブリッククラウド故の

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 指向– 再利用するコード → 捨てられるコード（効率化の観点が変化）

– 技術者の力量と開発プロセスに合わせたコードブロックの選択.2014 (C) Arichika Taniguchi, All rights reserved.

世界のチャレンジから（あるコンサル体験）

• 目標：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


http://www.slideshare.net/uesaka/enterprise-cloud-design-pattern

Azure Council Experts / 株式会社 FIXER 技術本部長谷口有近

BS3-1

3要素


enterprise cloud design pattern 前編：クラウドアーキテクチャ－の3要素

Internet