Enterprise Cloud Design Pattern 前編：クラウドアーキテクチャ－の3要素
8 likes4,532 views
QConTokyo2014 での講演内容です。エンタープライズの意味が曖昧になっている今、企業ユーザーがクラウドデザインパターンを有効に活用し実践するために必要な、チームのあり方を問い直します。 クラウド時代のシステム設計に重要なアーキテクトとしての要素である、ビジネス、インフラ（またはモデル）、コード構造を、アーキテクトの3つのロールとして捉え「トリニティ」 というキーワードを使って、DevOps の発展的な解釈として理解します。 この3つの役割を意識して、サイエンスに寄った共通言語で、システム開発をドライブすることで、クラウドデザインパターンの理解と実現に必要な、非同期（CPU時間の変換）、運用性（人的リソースの変換）、完全性（情報一貫性の変換）を実現してきましょう。
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基準
- 4. 2014 (C) Arichika Taniguchi, All rights reserved. …ではない３要素の話をします.
- 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.
- 8. Microsoft Azure パートナーコンソーシアム 【書籍の出版】 【ACE加盟企業による定例会＆ワーキンググループの活動の様子】 Azure Council Experts 著 日本マイクロソフト 監修 発行：日経BP社 編集：日経SYSTEMS ページ数：176P ターゲット：アーキテクト、システムエンジニア 一般社団法人 Azure Council Experts について 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.
- 11. アジェンダ 前半編 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.
- 13. “復元力” 指向の Cloud Design Pattern. 壊れる事を前提に全てを設計すること. 2014 (C) Arichika Taniguchi, All rights reserved.
- 14. システム可用性観点での設計その変遷 性能・負荷を事前に定 義, 壊れないシステム を指向する. 構成変更し易い基盤構 成で負荷バランスを ノード間で変える柔軟 なシステムを指向する。 運用自動化, 分散処理 系設計開発手法の導入 で, 直ちに変えられる 戻せる回復しやすいシ ステムを指向. ～以前 2012年頃～2000年頃～ 予期せぬ負荷に対応しようとコスト高なシステム構成に. 落ちないための検証/テストの繰り返しで時間観点でも足枷. 実際に負荷問題が発生, それは 時既に遅しの合図. 過度な仮想化に旧来の運用体制維持で運用負荷は下がらず. 頻繁な構成変更に耐えるメンテナンス性が高いPG構造の設計はハイスキル. API連携により外部システムに依存することになった負荷見積もり制御も高度な運用. 復元力(Resilience) 2006年頃～ 2014 (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環境の制約から コード側での実装が必須に.
- 19. 今は「回復しやすいシステム」設計が必要 • 安価H/Wを活用する故の低コスト, システム変更頻度を引き 上げる自動構成・自動運用, 世界規模サービスでデータ急増 – サーバーは突然落ちるもの. – 単一ハードウェアには性能上限があるもの. – バックアップ・復元が不可能なデータ量. • 適用イメージ – パブリック・クラウド, SDN, Cloud Design Pattern. • セキュリティ更新プログラムの頻繁な適用, プログラムの変 更作業が円滑になった. 2014 (C) Arichika Taniguchi, All rights reserved.
- 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.
- 23. 復元力を実現する アーキテクト トリニティ/マギ＝3要素 動的な○○にどう対処するか. 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.
- 26. 世界のチャレンジから（あるコンサル体験） • 対策：トランザクションスクリプトの有効活用 – エクセル仕様書からコードを起こしテストまでの開発工程を閉じ たクラスに入れ込むことを前提に, 入出力部分をOOPで構築. – 概要設計時点でデバッグテストを楽にするコード構造を決る • ポイント：コアとなるOOP部分はオフショア使わず管理 – OOP/TDDの夢を追わず, 眼前の技術力をコード構造で活かす. – 業務を知っている人間が少数で概要設計と詳細設計を同時に行う. • 設計時点で 業務～基盤～開発 のエキスパートが同時に調整 2014 (C) Arichika Taniguchi, All rights reserved.
- 27. よくあるITの実現プロセス RFP 業務要件 開発者 PM/SE/ Architect 2014 (C) Arichika Taniguchi, All rights reserved. 書類 口頭 書類 口頭
- 28. エンタープラズでも新しいトレンドを実践 Business Architect Code Architect Infra(Model) Architect 2014 (C) Arichika Taniguchi, All rights reserved. Science ここも 大切 ここ 大切 これも 大切
- 29. V字開発とマップ（すると失敗するかも） 業務 設計 詳細 設計 概要 設計 2014 (C) Arichika Taniguchi, All rights reserved. • 情報シスリーダー • システムコンサル • PM • PL • プログラマー • SE • PL 事業会社・ユーザー企業 システム子会社・SIer 工程管理
- 30. サイエンス指向の言葉で会話 Business Architect Code Architect Infra(Model) Architect 2014 (C) Arichika Taniguchi, All rights reserved. • 実現可能なビジネスモデル • 業務上許容されるSLA • 業務はコード構造・システム デザインに強く依存する時代 • コードの構造が運用 負荷を決定する • 自律モデルの構築は プログラムに強く依存 • 動的要素はソフト ウェアにシフトする傾向 • ビジネスの成長と 業務別SLAに あわせた 基盤の Grand Design • データ 整合性等 数理的観点 Science
- 31. DevOps との比較 Product Backlog DevOps 2014 (C) Arichika Taniguchi, All rights reserved. トレンドの拡大は, Opsの本来的な意味へ. Enterprise 開発も インハウス型へ近づく
- 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
- 36. さーて、後編のお話は？ • http://www.slideshare.net/uesaka/enterprise-cloud-design-pattern • 前編の振り返り • ACEのご紹介 • Cloud Design Pattern とは • 今回の大量データ処理の概要 • Microsoft Azure におけるPaaSとScaleOut • ScaleOutを前提とした大量データ処理用アーキテクチャ • クラウド汎用パターン あらゆるプロジェクトで使用推奨 ACE | 株式会社NEXTSCAPE 2014 (C) Arichika Taniguchi, All rights reserved.
- 37. Azure Council Experts / 株式会社 FIXER 技術本部長 谷口有近 BS3-1 3要素 2014 (C) Arichika Taniguchi, All rights reserved.