Más contenido relacionado La actualidad más candente (20) Similar a Enterprise Cloud Design Pattern 前編:クラウドアーキテクチャ-の3要素 (20) Más de Arichika TANIGUCHI (8) Enterprise Cloud Design Pattern 前編:クラウドアーキテクチャ-の3要素1. Azure Council Experts / 株式会社 FIXER 技術本部長 谷口有近
BS3-1
3要素
2014 (C) Arichika Taniguchi, All rights reserved.
2. 前説:クラウド時代のデザインパターン
• クラウドデザインパターン 3つの 技術的観点
2014 (C) Arichika Taniguchi, All rights reserved.
• 入力と処理、出力の分割
• 長時間ロードの分割非同期
• 負荷移動=変更の容易さの担保
• 管理単位での負荷の制御とSLA運用性
• トランザクション一貫性の選択
• 緩い一貫性の許容と制限完全性
CPUの時間を変換
人の時間を変換
情報の時間を変換
3. 前説:クラウド=CPU時間変換と障害管理
2014 (C) Arichika Taniguchi, All rights reserved.
処理時間=Ticks=クロック
CPU数
Workload
時間スケールをノード
超えて変換する
リソースの有効活用
数千台数万台いれば
いつも何か壊れてる
負荷も予測は困難
毎日何かを変更する
非同期
運用性
ダウンしうる環境での
情報の整合性
トランザクションと
スケールとのバランス
完全性
実行時間
≒
UX的観点での
許容出来る“待ち”
または SLA基準
5. 自己紹介
FIXER Inc. / ACE / Me
少しだけお時間を.
2014 (C) Arichika Taniguchi, All rights reserved.
6. 株式会社 FIXER とは?
• Cloud Service Vendor
– 2013 Microsoft Japan Partner Conference
Windows Azure パートナーアワード(CSV)を受賞.
• Full-stuck Managed Support
– 設計支援, アプリケーション最適化から開発, 運用までサポート.
• ご支援の事例
– IoT/M2M基盤 on Azure. / ゲーム基盤 on Azure.
2014 (C) Arichika Taniguchi, All rights reserved.
© COPYRIGHT 2014 FIXER inc.
7. Microsoft Azure パートナーコンソーシアム
Azure Council Experts(略称:ACE/エース)アジュール評議会は、Microsoft
Azure を利用した技術やサービスを提供するリーディングカンパニーが集結し、
普及ならびに技術者の育成、ノウハウの共有などでコラボレーションを展開する
パートナーコンソーシアム。
顧客企業・団体技術者
一般社団法人 Azure Council Experts について
http://a-c-e.biz/
2014 (C) Arichika Taniguchi, All rights reserved.
9. 谷口有近 / たにぐち ありちか
• 2000年 … SNSベンチャー
– ベンチャー企業で先進的SNS開発に従事.
• 2001年 … オンライン専業証券
– 取引システムの設計, 開発, 運用について、インフラからアプリ
ケーションまで広く従事.
– 課長職を経て ’09 エヴァンジェリスト, ’11 社長付IT戦略担当. 部門
を超えてのR&D, FSなどを支援.
• 2013年 … 株式会社FIXER 技術本部長
– クラウド・アーキテクチャの実践の魅力に取り憑かれ転職を決意
2014 (C) Arichika Taniguchi, All rights reserved.
10. 谷口有近の代表的な仕事(google me, please.)
• 福岡~東京間の証券取引システムのリアルタイム複製基盤
– ネットワーク側の設計・構築・運用を担当
• ソーシャルメディアセンサーの事業活用調査
– 株式市場の情報を補う情報抽出において成果
• 株価予測アプリの開発支援 (http://obt.hottolink.com/)
– 国内初 Bloomberg 向け株価短期予測アプリケーション開発支援
• 検索可能な事例化を支援してくれた企業に深く感謝!
2014 (C) Arichika Taniguchi, All rights reserved.
12. 前半:クラウド設計を実現するための 3 要素
• “復元力” 指向の Cloud Design Pattern.
• 壊れることを前提に全てを設計すること
– システム設計のトレンド, 非機能要件のカバーは誰の仕事?
• “復元力” を実現するアーキテクト・トリニティ
• 動的な○○にどう対処するか.
– DevOps のトレンド, 業務方の拡張と設計者の役割
• 後編は http://www.slideshare.net/uesaka/enterprise-
cloud-design-pattern2014 (C) Arichika Taniguchi, All rights reserved.
15. 「壊れないシステム」の設計
• 全ての機器, 部品を物理的に多重化, 全てのシステム構成要
素に対して, 可能な限り負荷を計算し推測する.
– 突発的なアクセス増や二次曲線的な利用者増が無かった時代.
– 業務要件の変化が穏やか故, システム変更の頻度も多くない.
– システム開発と運用, 改良も同じ企業が引き受ける.
• 適用イメージ
– メインフレーム, H/Aクラスタ, VRRP, V字開発, RAID
• 壊れさえしなければ “保守費は利益” のビジネスモデル
2014 (C) Arichika Taniguchi, All rights reserved.
16. 「柔軟なシステム」の設計
• 仮想化によるOSとハードウェアの分離, ネットワークのソフ
トウェア実装, 疎結合サブシステムで柔軟に.
– 仮想化がH/W由来による性能制限を緩和.
– 同時に, 仮想化に合わせたネットワーク構成変更の自由度向上.
– API指向, RESTful ブームでのサブシステム連携の一般化.
• 適用イメージ
– IA分散, グリッド, 広域L2/FPGA/ASIC, アジャイルスクラム
• インフラ設計ノウハウ高度化, 不景気背景に仮想化売り出し
戦略は低コスト指向強く迷走.2014 (C) Arichika Taniguchi, All rights reserved.
17. 2014 (C) Arichika Taniguchi, All rights reserved.
このあたりまでは
非機能要件
インフラ側の設計運用により
まずまず吸収出来ていた.
18. 2014 (C) Arichika Taniguchi, All rights reserved.
非機能要件は
(コストと引き替えに)
パブリッククラウド故の
H/W環境の制約から
コード側での実装が必須に.
20. システム設計のトレンド比較
~以前, 2000年前半 2006年~ 2012年~
冗長化 H/A A/A, グリッド クラウド分散処理
負荷分散 L7パーシステント L7ステートレス ラウンドロビン
可用性 日時のメンテナンスでシ
ステムを停止する
臨時メンテナンスでシス
テムを停止する
オンラインでシステムを
変更する
負荷マネジメント 負荷を検証して準備する 負荷にあわせて要因を
ノード間で移動する
負荷を細分化・分解し負
荷に応じたSLAを定義
SLA基準 システム全体 ユーザー毎 機能毎
バックアップ 日々取得する リアルタイムで取得する 取得が困難、仕組みと細
分化により担保
システム設計 業務単位 アクター単位 コード構造単位
開発プロセス V字開発 アジャイル・スクラム +DevOps (+ユーザ)
システム運用 開発者が兼任 運用担当が専任 機械による自動化
システム変更頻度 1年間に数回 1ヶ月に数回 1日に数回
非機能要件の扱い H/W側に分業 要件定義に書き出した コード実装→基盤側へ
2014 (C) Arichika Taniguchi, All rights reserved.
21. 2014 (C) Arichika Taniguchi, All rights reserved.
実装負荷が高い非機能要件は
PaaS 側で極力カバー
(例:Azure Web Sites)
クラウドの“作法”を限定的に.
22. 復元力=Resilience
• オンプレミスでは Robust 指向=壊れにくい
– 信頼性の高い部品を組み合わせ冗長化
– OSがダウンしないように手厚く
– 平均故障時間などの指標で品質を管理
• クラウド(グリッド以降)は Resilience 指向=回復し易い
– 信頼性はアルゴリズムの実装で担保
– OSはミドルウェアよりもさらに汎用的な部品に
– 部分的に壊れサービスレベルは一層フラグメント化
2014 (C) Arichika Taniguchi, All rights reserved.
24. 時代が求める動的な○○の追求の結果
• 動的なビジネス環境= リーン・スタートアップ 指向
– 意志決定の短縮・イニシャルコストの削減・変化を肯定.
• 動的なインフラ規模= Immutable Infrastructure 指向
– 容易に増強可能に⇒構成を静的にするせざるを得ない.
– OS 構成に依存しない/させない PaaS 的構造.
• 動的なソフトウェア構造= Disposable Components 指向
– 再利用するコード → 捨てられるコード(効率化の観点が変化)
– 技術者の力量と開発プロセスに合わせたコードブロックの選択.
2014 (C) Arichika Taniguchi, All rights reserved.
25. 世界のチャレンジから(あるコンサル体験)
• 目標:COBOLで書かれた業務系PGを C# で作り直し
– 10年以上動かしつつ直してきたガチの業務システム.
– RDBMSベースからメモリ処理へ, 処理速度を 1/10 以下に.
• 前提:スケジュール・規模は開発前から決まっている
– 数十万人が同時に利用し性能目標も決まっている.
– 数社による共同開発で性能上の都合からプロセス相乗り.
• 制約:業務仕様の匠は多いが C#技術者は 0 からのスタート
– 業務仕様書の本数からオフショア手配が先行.
– エンジニア採用難/資金繰り調整/その他諸々の課題.2014 (C) Arichika Taniguchi, All rights reserved.
32. Architect Trinity / Magi 大切な3要素
Business
Architect
Code
Architect
Infra(Model)
Architect
2014 (C) Arichika Taniguchi, All rights reserved.
Science
コード“構造”が持つ
能力を存分に発揮
機能別のSLAを
設計する 業務仕様書をPJの
共通語にしない
基盤は将来 PaaS が
カバーするので
モデリング中心かも
復元力
現在は基盤主役
デザインパターン
決定者の役割期待
復元力
業務を技術に
寄せる
運用設計を
コードでカバー
復元力
33. アーキテクト・トリニティ(三位一体)
• ビジネス価値 ビジネスストラクチャ・アーキテクト
– ビジネスを技術に落とし込むアタリをつける力.
– 技術からビジネスを発想する力.
• インフラ価値 インフラストラクチャ・アーキテクト
– クラウド時代の運用設計を構築し実践する変えられる力.
– コードを理解して構成を組んで非機能要件を要件にする力.
• ソフトウェア価値 コードストラクチャ・アーキテクト
– チームの力量にあわせたコードストラクチャを実現する力.
– クラウドデザインパターンをアルゴリズムとして理解する力.
2014 (C) Arichika Taniguchi, All rights reserved.
34. アーキテクト・トリニティでの復元力の実践
• ビジネスストラクチャ・アーキテクト
– 機能単位・サービス単位でのSLAを定義, サービスの復元を設計.
– 非機能要件を各種ストラクチャから理解し業務へ反映する.
• インフラストラクチャ・アーキテクト
– OS/ミドルを含めたリソースを隠蔽, 復元しやすい基盤を設計.
– 今は過渡期で必須, 最終的にはモデリングのロールと入れ替え.
• コードストラクチャ・アーキテクト
– 分散システムアーキテクチャを理解し情報を復元しやすい設計.
– コードストラクチャが持つ運用や業務でのレジリエンスを理解.
2014 (C) Arichika Taniguchi, All rights reserved.
35. トリニティで Cloud Design Pattern を支援
• 技術3観点と実現指向の アーキ・トレンド “トリニティ”
2014 (C) Arichika Taniguchi, All rights reserved.
• 入力と処理、出力の分割
• 長時間ロードの分割非同期
• 疎結合での負荷移動の容易さ
• 負荷単位でのSLAと制御運用性
• トランザクション一貫性の選択
• 緩い一貫性の許容と制限完全性
Business
Architect
Code
Architect
Infra(Model)
Architect
Science
37. Azure Council Experts / 株式会社 FIXER 技術本部長 谷口有近
BS3-1
3要素
2014 (C) Arichika Taniguchi, All rights reserved.