ネットワークを考えるときに考えること(7) - # cat /var/log/stereocat

一応、今回でシリーズ終わり。

検討時の考え方

様々な観点からシステム全体の構造やバランスを決定していく必要があるわけですが、「自分が見えていない・わかっていないことをあぶり出す」のはすごく難しいです。他の人からのレビューを受けるというのはもちろん必要なのですが、(自分で)自分のあら探しをするためにどういう考え方ができそうか、というのをちょっとだけ書いておきます。

トップダウン・ボトムアップ:

やりたいこと・実現すべきものから考えて、それらの条件を満たすために何が必要か?
設計はトップダウンに。作業はボトムアップに。

上下左右(面的、位置や場所に関する検討):

地理的な条件
ネットワーク図(地図)から考えたときに、どこに何があってどういう通信をするものか?
必要な要素は図中にすべて現れているか?
必要な要素間の関係性はすべて図中に表れているか?

上層・下層(深さ方向、階層性に関する検討):

ネットワーク図の全体あるいは各箇所において、どのレイヤでどのような技術・設計・設定・ポリシが定義されているか?
物理・論理(仮想)
- これもレイヤリングに関する話とも言えるか…。
- 仮想化技術を使うシステムでは一般的に物理構成と論理構成は全く別物になっていきます。論理構成(ネットワークモデル)としてどうするか。それをどういう物理構造にマッピングしていくか。
- 要件→論理構成→物理構成がどのように詳細化されるか・マッピングされるかを設計段階では考えていきます。運用上はその逆に、物理構成→論理構成→要件という考え方が必要になります。相互の関連性や設定・判断のための条件、ロジックなどを明示できるかどうかを考えてください。

個人的には、ネットワーク考えるときは上下左右と深さ(レイヤ)の組み合わせで、脳内ではわりと立体的というか3次元的なイメージになってたりします。

占有・共有:

誰が、何を、どこまで使うのか。リソース面の独立性とコストバランスの問題。
「特化・汎化」ととらえてもいいかもしれない。特定のリソースを特定の機能のためだけに使う(特化)・特定のリソースを一般的な機能で共有して使う(汎化)、など。
リソースのコントロールをどう考えるか。
境界点のコントロールをどう考えるか、ってあたりもこの範囲内かな。

対象と周辺:

「関係性」の話をしているので、ひとつの対象に対して、連携する複数の要素や付随して必要になる複数のコンポーネントがあります。
- 何かを入れる、変える、減らす…をしたときに、それとくっついて変化がある物は何でしょうか? その変化は周辺の連動するものと合わせて許容されるものですか?
人(運用者・利用者)まで考えた上で「周辺」を考えるとどうなりますか?

時間変化:

追加・変更・削除・更新・移行・移設など、システムに対するCRUD操作やシステムライフサイクルなどを考えたときの制約事項や要件、今後の予測(拡張・変更など)や見込みなど。
時間的特性
イベントに対するシステムの挙動, 障害発生時の動作・メンテナンス作業など、フェーズやシーケンスに応じて変化する(させる)もの、変化の条件や経過時間、サービス影響など

動的・静的:

動く(動かしたい・動かさなければいけない)もの、動かさない(動かせない・動かしてはいけない)ものはなにか。
- 動的なもの: 自動的に動作させる必要がある物は何か

コスト:

物理的なコスト: 機器費用とか回線費用とか
人的なコスト: 単純に人月単価的なもの。オペレーションの複雑さと必要な時間。大がかりな作業については事前検証や作業調整などにかかるコストなんかも考慮に入れた方が良いでしょう。
最初だけなのか継続で(ランニングで)かかるのか
- ランニングでかかるものは、期間でかけ算なので、まあこれくらいなら…と一瞬思えるものでもあとあと響いてくる。

おわりに

「設計はトップダウンに。作業はボトムアップに」とか書いてみたけど、実際のところそんなきれいには進まないんだよね。システム提案出すために細かいところ決まってないんだけどあらかた構成と機材決めて見積もり考えないといけないような場合とか。詳細見積だそうと思ったら設計やらないといけないんだけど、提案段階でそんなに細かい話できないし、そもそも具体的な要件なんて決まらない。それでもある程度の実現性とか使う機材のアテがないと書けなかったりするからボトムアップ的な考え方から入ったりすることもある。でもボトムアップにだけやってると「やりたいこと」から外れていく…。

システムの要件はふつう上から決まっていきます。業務として何を解決すべきか、そのためにアプリケーションで何をすべきか、ミドルウェアとして何が必要か、OSとして…サーバとかストレージは…それらをつなぐネットワークは…全体としてどういう運用にするか、みたいな順番。で、作る時ってネットワークから作るんだよね。下から作らないと何もできないから。要件確定は最後・設計構築は最初、というのがネットワークの常……常に工程/期間が圧縮されるところなんですわ*1。で、アレなプロジェクトでは上物の要件がまだはっきり見えていないのに、時間がないから早くネットワーク考えろとかいわれたりすることもあったり。どうしろって言うんですかねー、みたいな話になるんだけど。(なんとなく書いてますがこれといって解なしです。もうコスト的許容される限りキャパシティとか安全率を大きく取って、後で変更したとしても耐えられる構造みたいな大雑把な作りにせざるを得ない状況もあるでしょう…いいとは思わないけど。)

話がずれてきているか。

今回の一連の投稿は、「わからないものをあぶり出すために何を考えるか」という話で一通り書いてみたつもりですが、「わからないものをあぶり出すための観点がすべてあぶり出されているか」という一段メタな問題もあります。今回こうしていろいろ挙げてみた「観点」自体が私の主観的な見方に沿った偏った見方である可能性が当然あります。「観点」自体をちゃんと一般論として(特定の方向に偏らずに)出せているかどうか。まあ、そもそも論を始めるときりが無いんでやらないですが。今のところ思いつく範囲内ではなるべく挙げてみたつもり(また思いついたら追記するかも)。

最初にも書いたとおり、今回書いてある話のほかにも、まだこういうこと見る必要があるよね、というのがあればツッコミくだされ。

*1:実際にはネットワークの運用をどうするかってのがあるので、要件決定自体は運用周りの話が最後まで残るんだけど、作るところはとにかくネットワークできてこないと何もできないのでネットワークが最初。