「ITアーキテクチャー設計の最新動向」 参加報告＠ソフトウェア開発環境展 専門セミナー

更新日：

http://www.sodec.jp/jp/conference/

参加対象

  1. 2009/05/15（金）13:20-16:10 [SD-14] ITアーキテクチャー設計の最新動向

● 最新技術を生かすITアーキテクチャー設計7つのセオリー

日本アイ・ビー・エム（株） テクニカル・セールス・サポート企画 エクゼクティブITアーキテクト
河野 紀昭

最新技術を効果的に用いて基幹システムを構築するには

  • 最新技術を用いた基幹システム構築の課題
    1. 最新技術を効果的に使いたい
      1. Java、EJB、SOA、cloud
      2. グローバルミラー、仮想化
      3. REST、Ajax
    2. 従来と同等以上の品質を確保したい
      1. 性能
      2. 可用性
      3. 拡張性
  • これまで培ってきたノウハウは生きないのか
    1. 誤解1
      • 新技術には新しいシステム設計法が必要だ
    2. 誤解2
      • 技術が変わってもこれまでのノウハウで大丈夫
  • 基幹システムに新技術を取り入れた場合
    1. 新技術を使っても、基幹システムの基本的要件は同じ
    2. 新技術でも、これまでの考え方の80%程度は応用可能
  • 考え方が変わらない例
    1. 従来COBOLとOLTPで構築していたシステムをJavaで再構築した。CPUの見積は？
    2. 見積原理は変わらない
      • 必要CPU数 = 1トランザクションのCPU時間 × トランザクション率
    3. 計算例
      • 0.01秒 × 100trx/秒 = CPU1個
  • 計算結果は変わる
    1. COBOLで1トランザクション0.01秒だったのが、Javaで0.05秒かかるとしたら
      • 0.05秒 × 100trx/秒 = CPU5個
  • 考え方が変わる例
    1. 従来COBOLとOLTPで構築していたシステムをJavaで再構築した。メモリの見積は？
    2. 従来のOLTPのメモリ見積
      • 必要メモリ量 = 根雪 + 1スレッドあたりのメモリ × 同時稼働スレッド数
    3. 計算例
      • 10MB ＋ 2MB × 10スレッド = 30MB
  • 図解（従来型OLTP）
スレッド（2MB） スレッド（2MB）
スレッド（2MB） スレッド（2MB）
スレッド（2MB） スレッド（2MB）
スレッド（2MB） スレッド（2MB）
スレッド（2MB） スレッド（2MB）
根雪（10MB）
  • JavaではGCでメモリを解放
    1. Javaは実行時に動的にメモリを確保し、あとでまとめてガーベジ・コレクション（GC）で解放
    2. アプリケーション・サーバのメモリ見積
      • 必要メモリ量 = 根雪 + 1トランザクションのワークメモリ × トランザクション率 × 目標GC間隔
    3. 計算例
      • 100MB ＋ 2MB × 100trx/秒 × 10秒 = 2100MB
  • 図解（Javaアプリケーション・サーバー）
10秒で1000個分のワーク
100trx/秒 ワーク（2MB） ワーク（2MB） ワーク（2MB） ここでGC
ワーク（2MB） ワーク（2MB） ワーク（2MB）
ワーク（2MB） ワーク（2MB） ワーク（2MB）
ワーク（2MB） ワーク（2MB） ワーク（2MB）
ワーク（2MB） ワーク（2MB） ワーク（2MB）
根雪（100MB）
  • 最新技術を効果的に用いて基幹システム構築するには
    1. 新技術を使いこなすための新しい設計法を導入
    2. 従来のシステム構築ノウハウを応用して、従来通りの品質を確保

セオリー・ドリブン・アプローチとは

  • よいITアーキテクチャーとは
    1. ビジネス要求を適切に実現している
    2. 戦略的なビジネス要件実現のために、新技術を取り入れる
    3. 「普通」のシステム要件は「普通」に実現
  • ITアーキテクチャー設計の考え方を整理して適用することが大切
    1. 従来のベストプラクティスを出来るだけ応用して利用する
    2. 新しい技術を生かすための設計方法を組み入れる
  • セオリー・ドリブン・アプローチ
    1. ITアーキテクチャー設計に用いる考え方を、セオリーとして整理して適用することにより、適切なアーキテクチャーを設計するアプローチ
    2. セオリーは、ビジネス要求に対応させて、リスト化し、明示的に適用する

設計結果を再利用しても上手くいかない。
再利用すべきなのは、設計結果ではなく、考え方である。
セオリーとは、この設計に対する考え方とも言える。

  • セオリー・ドリブン・アプローチの流れ
    1. セオリー集から、ビジネス要求に応じてセオリーを選択
    2. 選択したセオリーを適用
    3. アーキテクチャ設計に反映
    4. ITアーキテクチャー
  • 2種類のセオリー
    1. アーキテクチャー・セオリー
      • 特定のビジネス要求に応えるアーキテクチャ設計の指針
    2. システム構成セオリー
      • アーキテクチャを適切に実装するための見積/構成設計/パラメータ設計方法
      • 基本的な考え方は汎用的であるが、各種の係数は環境/製品に依存

有用な7つのセオリー

  • 有用な7つのセオリー
    1. セオリーはたくさんある
    2. 特に有用な7つのアーキテクチャー・セオリーをご紹介
  • 要求に応じたセオリー
    1. 機能要件
    2. 性能
    3. 可用性
    4. 拡張性
    5. 信頼性
  • セオリー1）ビジネス上の利点のある場所に新技術を導入する
    1. ビジネスニーズの実現に新技術を用いる
    2. 新技術の長所がビジネスニーズにマッチするようにする
  • セオリー2）クラスタリングでスケーラビリティーと高可用性を実現する
    1. 処理量が増えたら、マシンを並べるだけですむようにする
    2. DBなど処理が集中する部分には、高速マシンを使用
    3. 電力（=発熱）も考慮する
  • セオリー3）キャッシュ、オンメモリー処理、非同期処理で高速化を達成する
    1. トランザクション処理でのCPU時間は数ミリ～数十ミリ秒
    2. ハードディスクの1回のランダム読み込みは10ミリ秒程度
    3. いかに「見かけ」のレスポンスを早くするか
  • セオリー4）システムを非機能要件に従って複数セグメントに分割して構築する
    1. いろいろな要件を同時に実現するのは大変
      • 24時間365日連続稼働
      • 災害対策
      • 大量トランザクション処理
    2. 要件毎にセグメントを分ければ、構築しやすくなる
  • セオリー5）技術的難しさをフレームワークで分離し、隠蔽する
    1. 大規模な開発では、「一定の品質保証」が課題
    2. アプリケーション開発者には、ビジネスロジック実現に集中してもらう方がよい
    3. 技術を使いこなすコードを、フレームワーク内にコーディングし、アプリケーションと分離する
  • セオリー6）テスト実施可能なアーキテクチャーにする
    1. テスト可能な構造にする
      • テスト可能なサイズにシステムを分割する
      • 事前条件を設定、テストデータ投入と結果確認が出来る構造にする
    2. テスト環境を整備する
      • テストを意識したフレームワークを構築する
      • 自動テスト・ツールを取り入れる
  • セオリー7）非機能要件の保証された部品やサービスを作成し、再利用する
    1. 「便利な部品」の性能が悪いことがある
      • Javaのリフレクションを使った部品
    2. 性能や品質が保証された部品を使ってアプリケーションを作成すれば、一定の品質が確保できる
  • セオリーリスト
機能 性能 可用性 拡張性 信頼性
1）利点のある場所に新技術を導入 ○
2）クラスタリングでスケーラビリティと高可用性を実現 ○ ○ ○
3）キャッシュ、オンメモリ処理、非同期処理で高速化 ○
4）システムを非機能要件に従って複数セグメントに分割 ○ ○ ○ ○
5）技術的難しさをフレームワークで隠蔽 ○ ○
6）テスト実施可能なアーキテクチャ ○ ○
7）非機能要件の保証された部品を再利用 ○ ○

●“Social”な情報システムの実現とそのデザイン：日本最大のSNS『mixi』の事例

（株）ミクシィ 小山 浩之

（株）ミクシィ 技術顧問
小山 浩之

  • 要約
    1. 変わったことはしない
    2. パターンを見つけ・使う
    3. 多少壊れても動くように
    4. 壊れる前提で作る
    5. 天井を上げておく
      • 天井：いくらでも拡張出来るように、性能の話
  • mixiの特徴
    1. トラフィックは、主にユーザの「日記」を元に生じる
    2. Weblogと酷似したモデル
    3. 書いた日記は友人達に自動配信
    4. ソーシャルグラフを伝送網に見立てることで、コンテンツを適切な消費者に配信・交換
      • 適切な：アクセスコントロールのこと
  • mixiの構成要素
    1. ユーザプロフィール
      • ユーザ個人の情報
    2. ソーシャルグラフ
      • ユーザ同士のつながり
    3. コンテンツストレージ
      • ユーザが作成したコンテンツ
    4. データストリーム
      • 友人のデータが自動的に自分に集まる仕組み
  • mixiのハードウェア・ミドルウェア構成
    1. 一般的なIAサーバ
    2. Linux
    3. Apache Web server
    4. MySQL
    5. Perl
  • ミドルウェア
    1. L1、L2、IC というmixi独自の構成
      • 1つの計算機資源にデータやアクセスが集中する構成を避ける
      1. 購入元を一元化する
      2. 普通に購入できるハードウェアを使う
      3. 業界標準を取り込む
      4. OSの設定は統一する
      5. ブラックボックスを持たない
      6. L2、ICなどのアーキテクチャを再利用する

-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2024 All Rights Reserved.