Janog37 Pattern BoF

Pa#ern
Oriented
Network
Architecture
January
2016

Miya
Kohno
(mkohno@cisco.com)

2© 2014 Cisco and/or its affiliates. All rights reserved. Cisco Confidential
Pa#ern
–
おさらい

•  森羅万象津々浦々，多くのものにパターンが存在する

•  「パターン」は，「モデル」，「構造」と捉えて良いかもしれないが，そこまで厳密で
なくてもよい．また，ボトムアップ的である．言い伝え(saying)やことわざ(proverb)
のようなものもパターンであると言える．

•  パターンを編み出す基本

ref.

Alexander

-‐

A
Problem
(in
a
Context)

(ある状況における)問題を認識する

-‐  Forces
:
The
heart
of
every
pa#ern

その問題の背後にあるものは何か，問題を特徴づけているものは何か

-‐  SoluPons
and
Consequences

どうしたらよいか，そしてその結果何が期待できるか

Pa#ern
–
モデル化のためのアプローチ

論理に基づくアプローチ（演繹的）
事象に基づくアプローチ（経験的）

Pa#ern
Oriented
Network
Architecture

Pa#ern
Oriented
Network
Architectureをつくっているもの

•  日々のdevelopment
&
operaPons

•  NOGの活動

•  IETF　-‐

dejurが支配的な標準化団体とは異なり defacto志向　
Rough
consensus
and
running
code
/
No
vote,
No
kings

•  Open
Source活動

Pa#ern
for
Microservices!

Pa#ern
for
Microservices

h#p://microservices.io/pa#erns/microservices.html

h#ps://uramoto.wordpress.com/2015/09/21/マイクロサービスのデザインパターン/

Microserviceとは

h#p://marPnfowler.com/arPcles/microservices.html

一つのアプリケーションを小さいサービスの集合として開発する手法．それぞれのサービスは個別の
プロセスとして動作し，HTTP
resource
APIなど，軽めの手法でコミュニケーションする．それぞれは異な
るプログラム言語で書かれたり，異なるdata
storage技術を使うこともあり，最低限の集中管理により
管理される．

Networkのステートの問題に取り組んでみたい

h#p://www.mpls.jp/presentaPons/MK_state-‐in-‐programming_01.pdf

•  Web
ApplicaPonは，Stateを最小化することにより，AvailabilityとScalabilityを
獲得した

•  Internetはもともと，Stateless
(circuitに対してdatagram)
，Eventually

Consistent
(ルーティングコンバージェンスは非同期)
だったが，機能追加の
ために，これまで専らステートを増やす方向で進化してきた

　e.g.
PPP/L2TP,
MPLS
TE,
3GPP
mobility,
CG-‐NAT,
HTTP
proxy,
NSR/NSF/ISSU..

ステートをなぜ最小化したいか

•  スケーリングのボトルネックになる

•  過負荷時に耐えられない à
二次障害懸念

•  Single
Point
of
Failureになる

•  ステートを失うとセッション断などにつながる

•  Chaos
Monkey(*)を適用できない！

•  冗長を実現するためには，データの複製だけでなく
ステートの同期が必要　

　　　　　à さらなるスケーリングボトルネック懸念

(*)
頑健性を上げるため，故意に障害を起こすツール．Nedlixが開発し，オープンソース化した．AWS上のアプリケーションに適用．

h#p://techcrunch.com/2012/07/30/nedlix-‐open-‐sources-‐chaos-‐monkey-‐a-‐tool-‐designed-‐to-‐cause-‐failure-‐so-‐you-‐can-‐make-‐a-‐stronger-‐cloud/

ネットワークのステートを縮減するために

(ただし，適用して問題がないかどうかについては熟考が必要!!)

•  データグラムとステートレスマッピング

“A
self-‐contained,
independent
enPty
of
data
carrying
suﬃcient
informaPon
to
be
routed

from
the
source
to
the
desPnaPon
computer
without
reliance
on
earlier
exchanges
between

this
source
and
desPnaPon
computer
and
the
transporPng
network.”
— RFC
1594で
の”datagram”定義

•  Fire
and
Forget

結果までは確認しなくてもよい，という考え方（米国の巡航ミサイルの性能がよく，発射さえし
てしまえば，後は自動的に標的に当たることから）

•  様相論理
(Modal
Logic)
の適用
　モデル検査のように，充足関係を形式論理で判断

　M
=
(S,
(S0,)
R,
V)

[Kripke構造]

S
–
可能世界で取りうる状態,

R
−
到達可能関係（計算過程，状態遷移など）,

V
–
真偽

POSA本(Pa#ern
Oriented
Soqware
Architecture
–
分散コンピュー
ティング編) における
State,
Modal
Behavior
に関する言及

•  Minimizing
condiPonals

　　条件は最小化する

•  Inter-‐mode
dependencies

　　モード（状態）間の依存関係を明確にする

•  Mode
visibility

　　モード（状態）を可視化する

ステート性に関するパターン

(From
a
pa#ern
language
for
distributed
compuPng)

1.
Objects
for
States（ステートのためのオブジェクト）

•  オブジェクトのふるまいは，モードが現在のステートに依存する，という意味
でmodalである．しかし，オブジェクトの実装の中で，対応する複数部分の
条件コードをhard-‐wireしてしまうのはよくない

　　↓

•  オブジェクトのステートに依存するふるまいは，異なるmodal
stateの階層に
隠蔽すべき


(From
a
pa#ern
language
for
distributed
compuPng)

2.
Methods
for
States（ステートのためのメソッド）

•  オブジェクトのふるまいは，モードが現在のステートに依存する，という意味
でmodalである．しかし，オブジェクトの実装の中で，対応する複数部分の
条件コードをhard-‐wireしてしまうのはよくない．さらに，そのふるまいをオブ
ジェクトの一つのコミュニティに委譲してしまうのは，異なるモード間の調整
やデータ共有を複雑にする．

　　↓

•  オブジェクトのステートに依存するふるまいは，内部メソッドとして実装し，あ
る特定のステートのふるまいを表すメソッドを参照するために構造体を使用
する


(From
a
pa#ern
language
for
distributed
compuPng)

3.
CollecPons
for
States（ステートのコレクション）

•  そのふるまいが現在のステートに依存するオブジェクトは，個別のステート
マシンとしてモデル化される．しかし，クライアント特有のステートモデルか
ら独立であるにもかかわらず，クライアントはそれらのオブジェクトをmodal
と認識する．

　　↓

•  クライアント内では，そのステートにある全てのオブジェクトを参照する別の
コレクションによってステートを表現すべき，

Janog37 Pattern BoF

More Related Content

What's hot

Viewers also liked

Similar to Janog37 Pattern BoF

Janog37 Pattern BoF