InfoQからの引用 アーキテクチャドキュメントには、システムのコンテキスト、機能構造、デプロイメント環境、情報構造、運用環境などを定義して、非機能要件がどのように満たされるのか説明しておく必要があります。 アーキテクチャドキュメントを端的に表した文書なのでメモ。
アーキテクチャ
Cloud時代のソフトウェア管理
2009年11月10日 · コメント（0） · アーキテクチャ, 考えたこと
Cloudera Distribution for Hadoopのインストール方法を拝見した。 コンフィグレーションを管理サイトで登録して、コンフィグレーション済みのパッケージングされたソフトをRPMとしてダウンロードしてインストールする。 Hadoopだからということではなく、コンフィグレーション管理のサービスが生まれ、クラウド上にカスタマイズされたソフトウェアをダウンロードしてクラウド上のノードで実行する。クラウドを移設することも可能になるだろうし、発展すれば、コンフィグレーションがプロファイルのようなものになり、どこで実行するのかはクラウドの価格やリソースなどで動的に変更できる。（データ移行もあるのでそう簡単ではないが） そういう新しい時代のソフトウェア管理方法を見たような気がして、はっとさせられた。もちろん、HPC的なクラウドも、ガｰトナーの言うところの、CDA（Context Deliver Achitecture）のコンテキスト情報を扱う上で、重要な要素であることは間違えないのでおろそかにできないのだが、今日は別のことを感じた。
タグ :
可用性
2005年12月27日 · コメント（0） · アーキテクチャ
可用性を考える上で、アプリケーションエンジニアとしてもインフラを理解していないといけない気がしている。 可用性の見積 同様な可用性要件からの類推 KKD MTBF、MTTRからの計算 見積に関しては複数のやり方でやってその評価を比較しておこなった方が良いやり方だろうと思う。複数のやり方とデルファイ法という手もある。 最後のやり方はあんまりやられていない気がする。 折角、情報処理技術者試験に出ていてみんな知っているのに。 統計学の世界なので計算上のことだが、論理的な見積ができるのはそれなりに価値があると思われる。 可用性の対応 障害発生時の冗長構成 スペック不足によるシステムダウンの防止のために、無停止な拡張性 http://www.atmarkit.co.jp/flinux/rensai/cluster01/cluster01.html アーキテクチャとインフラ インフラを決定することで、アプリケーションの構造が変わることが当然ある。 Webアプリケーションで言えば、複数のWebサーバやASにリクエストがあるとすればセッションID、セッション情報の格納方法を確認する必要がある。 単一サーバ処理を前提としたアプリケーション構築は拡張性、可用性を失ってしまう。 このような問題についても配慮した設計は結構悩ましい。 インフラのインプットがアプリケーションアーキテクチャとしての制約となることを忘れてしまいがちだ。 アプリケーションの考慮点 id:masashi_oikawaさん経由で、JavaWorldの記事（http://www.javaworld.com/javaworld/jw-12-2005/jw-1226-jee.html）にいくつか乗っている。 JVM上のキャッシュは読み取り専用せよ。 HTTPセッションの分散化対応（上記に書いたこと） 外部リソースのリロード機能があるとよい。 統合的なエラー処理（エラー出力、エラーの発生、エラー画面） アプリケーションの状態監視 タイムアウトを考えた外部呼出し 品質向上
タグ :