2013-01-26 Sat
■ JANOG 31 Togetter まとめ [JANOG]
http://togetter.com/li/444534
http://togetter.com/li/445019
復習に良いよなあ。
書いてくれてる人に大感謝。
2013-01-26 Sat
■ デザインパターンBoFのログ [JANOG]
http://www.janog.gr.jp/meeting/janog31/program/design.html
書いてみたよ。
JANOG MLに投げたテキスト版は以下。
JANOG31 Meeting BoFの記録
BoFタイトル: デザインパターンを知っていますか?
日時: 2013/1/25 18:50〜20:15
場所: 東京ミッドタウンホール＆カンファレンス ホールA
参加者: 30〜40人？
URL: http://www.janog.gr.jp/meeting/janog31/program/design.html
○事前公開アブストラクト
-----------------
デザインパターンを知っていますか?
人の営みにはなんらかのパターンが存在します。
そのパターンを抽出して良いパターンを見つけ活用することにより、
より良い物を作り出すことができるはずです。
このアイディアは元々は建築の分野で生み出されたものですが、
ソフトウェア工学の分野でも活用されています。
ネットワークも人によって作り出されたものであり、
なんらかのパターンがあるはずです。
成功したものには良いパターンが、失敗したものには
悪いパターンがあります。
それを知ることによって、より良いネットワークを
作れるようになるのではないでしょうか。
自然の自己相似形や、音楽のハーモニーのように、
美しいもの、感動するものなど、心を打つものには、
たいていはある一定のパターンが存在します。
一緒にそれを見つけてみませんか。
当日のオツマミは以下を考えています。
オツマミの持ち込みは大歓迎です。
BoFですし、みんなで気楽にガヤガヤ話をしましょう。
- デザインパターンって何?
- どうやって記述する? UMLみたいなツールはネットワークにない?
- たとえば具体的にどんなのが素敵なパターン?
- どんなのが悪いパターン? どこが悪い?
- 他の分野でのデザインパターン
- どう活用する?
○BoFのファシリティー、配置
-----------------
会場の左前方にホワイトボードを用意。
ワークショップ用に付箋紙、ぺんを準備。
(協賛各社様から提供いただきました)。
プロジェクターなし。配布資料なし。マイクなし。
参加者とモデレータの間の距離が近くなるように、
ホワイトボードの回りに半円形に椅子を並べる。
○参加者層
-----------------
レイヤや業種等に特に偏りはなし。
デザインパターンに興味がある人、モデレータ(河野さん)のファン、
他のBoFに比べてグダグダ感を楽しめそう、
というような方が参加者ではないかと思われる。
○当日のお題目と進行
-----------------
事前のアジェンダとは少し変更し、以下の順番で進行。
0.事前前説明、自己紹介等
1.デザインパターンって何？
2.何が嬉しいか？
3.アンチパターン
4.どうやって記述する？抽出する？
5.他の分野のデザインパターン
6.何のパターンを作ると嬉しい？
7.実際にパターン抽出してみよう
8.まとめ
時間切れのため、7番は実施できず。
○お題目1: デザインパターンって何？
-----------------
人の営みにはなんらかのパターンが存在する。
最初にデザインパターンという概念を使い始めたのは建築の分野。
アレグザンダーが始めた。
良いパターンを抽出し、それを元にすれば良い設計ができるはず。
設計は、物を作り出すというすべての行為で行なわれること。
ソフトウェア工学の分野でもこの考え方は発展し活用されている。
アレグザンダーは、都市は階層的に構成されるツリー構造ではなく、
様々な要素が絡み合って形成されるセミラチス構造である、と言っている。
インターネットもまさにセミラチス構造になっている。
武道の達人は型を知っている。それに近い。
武道は型を学び、守り、破り、離れる、ことにより進歩している。
型を知ることで達人も超えられるはず。
[ディスカッション]
デザインパターンの例として、AWSクラウドデザインパターンがある。
ああいうものを作りたい、というイメージか？
--> あれは素晴しい。エンジニアが使いやすい形でパターン化できている。
--> 実はそれは、お題目5、で少し説明しようかと思っていた。
うちの会社でも運用のパターンを作ってみている。
ただ実装が実際には難しい。
--> パターン化する領域はフォーカスする必要がある。
--> そこは、お題目6、で説明しようかと。
ネットワークにパターン化しにくい理由があるのではないか？
--> ソフトウェアと違って制約条件が多い。
> 制約もパターン化できるのでは？
--> プロトコル、構造(リング、スター、メッシュ)、OSIなど
パターンはないわけではない。
SDNやクラウドにより設計の自由度が上がったことで
デザインパターンが注目されてきたのではないか？
--> そうかもしれない。ただそうとも言えない。
--> 河野さんはずっと言ってきているし。ただ河野さんの言葉は難しいのでw
--> たとえば MTU の問題等は、ずっと繰り返されてきている。
○お題目2: 何が嬉しいか？
-----------------
デザインパターンは「言語」でもある。
抽象化して名前を付けるとコミュニケーションがしやすくなる。
デザインパターンは問題発見、解決の支援をしてくれる。
○お題目3: アンチパターン
-----------------
不適切な解決策や失敗を分類したもの。
単なる悪癖や悪習とは違って、リファクタリングにより直せる。
これを知ることで失敗を防げる。失敗からのリカバリーもできる。
○お題目4: どうやって記述する？抽出する？
-----------------
AWSクラウドパターンでは以下のように抽出している。
- 解決したい課題
- 解決方法/パターンの説明
- 実装
- 利点
- 注意点
- その他
これはエンジニアにとって使いやすい。
ただ、以下の3項目で抽出するのが元々のアイディア。
- Context (どのような状況で)
- Problem (どのような問題が生じやすく)
- Solution (どおう解決すれば良いのか)
デザインは問題発見、解決するツールとなっている。
やり方、だけでなく、ありがちな問題、解決方法、も記述される、
というのが、マニュアルや手順書、との違い
○お題目5: 他の分野のデザインパターン
-----------------
「オブジェクト指向における再利用のためのデザインパターン」
GoFによる原典。
AWSクラウドデザインパターン
波田野さんがまとめた監視パターン
他にも様々なパターン化はされている。
[ディスカッション]
会社の内部文書としてパターン集のようなものはある。
これは会社のノウハウで飯の種になっている。
おいそれとは共有できないんじゃないか？
--> ソフトウェアも昔はそうだった。
--> ただ今はオープンソース全盛。他で使われている実績が信頼を生む。
--> 今は内部で持っているノウハウもオープンにしたほうが良くなるはず。
--> 誰かが良いものを作って公開すれば変わるのではないか？
○お題目6: 何のパターンを作ると嬉しい？
-----------------
ワークショップ。
各人が、パターン抽出したいもの、を付箋に書いてホワイトボードに貼っていく。
それを分類。
↓國武さん、田島(taji)さんがテキストおこしをしてくれました。
- ネットワーク設計
- トラフィック分散時のアンチパターン(ECMP)
- POP or iDCの増やし方
- NW構築時のパターン
- NWトポロジー
- DC間を接続したインタークラウドの設計パターン
- 品質
- 長距離バックボーン回線でのLAG
- 輻輳・迂回設計のパターン
- mazのプログラムそのまんまだけど
- トラフィック規模の設計方法
- 1万人規模ISP
- 10万人
- 100万人くらい
- ネットワークの階層構成
- スケーラビリティ実現パターン
- 冗長化のパターン分類
- 止まらないネットワークの作り方
- 冗長
- DC内の物理ファブリックの構成
- 検証環境のIPアドレスアドレッシング
- 組み替えしているとすごくぐちゃぐちゃに
- アドレスの割り当て
- 仮想ネットワークと物理ネットワークのマッピングパターン
- 企業向けシステムの作り方
- プロトコル
- ダメなプロトコルの見分け方(STP)
- ポート番号埋め込まれプロトコル(ex. FTP)
- プロトコルのアンチパターン
- IPv6は
- 4byteASは
- MTU/MSSは
- エラーコードの統一
- プロトコルのシンプルさを求めた時になにをもってシンプルとするか？
- 標準化の進め方
- トラブル対応
- お客様への謝り方
- 障害に対する顧客説明や対策立案のパターン
- トラフィック傾向からの障害解析
- <BADパターン> 増えすぎて管理できなくなったVM群
- テーブル溢れ
- Ex. ARP, NAT, 経路
- トラフィックとかが単一のところでサチる
- Ex. ラックスイッチ
- フロントが軽くてバックエンドがささる
- Ex. Webサービス
- 警察にログ出してって言われた時のパターン
- トラフィックが 100倍になった時の対象方法？
- なにをTraffic異常とするか
- オペミスのパターン
- 障害発生時でもお客様に文句いわれないパターン
- 嫁さんとのケンカのパターン
- 半落ちルータのIsolation or Troubleshooting
- 障害発生時の対処（迂回方法）とか
- 障害発生パターン
- 一週間問題、解決できない時にどうするか？（オペレーションリサーチか？）
- アラートアグリゲーション
- たくさんのアラートメールをまとめる
- 要求のはねのけ方パターン
- こういうお客様ならこうする。
- NWトラブルのデジャブのパターン
- NWトラブルのジャメブのパターン
- 運用
- 少人数でも運用が楽にできるパターン
- コンフィグバージョニング 設定ファイルはバージョン管理ツールに入れる
- テストパターン (擬似障害とか)
- チケットシステムとDBの作り方
- ネットワークの移設
- 幸せな運用体制パターン
- リソース監視とその利用
- 適切な監視システムパターン
- ユーザの動向(使い方)
- 東日本大震災クラスのシミュレーションを毎年やる方法?
- 設定のパターン
- メンテナンスの進行管理
- 組織
- エンジニアが元気な会社のパターン
- 一連の上司の絵? 資料の好み?
- JANOG Meetingに参加するために上司を説得する方法
- 海外出張に行くための上司のおとしかた
- 活発なコミュニティ活動のパターン
- 女性技術者を増やすパターン
- 抽象
- SDN/クラウド上のNWのAbstraction(L2/L3とか) パターン
- 違いに気づく
- 勘に頼る
- マーケティング
- buzzword 発見パターン
- buzzword の定義のされ方
- その他
- 社内のファイルサーバ 整理パターン
- PC、タブレット、ケータイ等 エンド端末の進化と分類
- コスト削減 対処方法
- うけるセッションのパターン
- JANOGのセッションの立て方
- 河野さんの思考パターン
○お題目7: 実際にパターン抽出してみよう
-----------------
※ワークショップの予定だったが時間切れのため実施せず。
○お題目8: まとめ
-----------------
モデレータは楽しい時間を過ごせた。
なにかあったら、メールをくれたり、つぶやいたりしてくださいまし。
Twitterのハッシュタグは以下にしました。
#janog_dp
これからどうするか、はちょっと考えてみます。
○参考資料(関連URL)
-----------------
井庭先生の講義資料:
「パターンパターン・ランゲージによる経験のマイニングと共有」
http://www.slideshare.net/takashiiba/ss-12990656
「オブジェクト指向プログラミングのためのデザインパターン」
http://www.techscore.com/tech/DesignPattern/index.html/
デザインパターン_(ソフトウェア) - wikipedia
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_%28%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%29
アンチパターン - wikipedia
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
クリストファー・アレグザンダ - wikipedia
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%83%BC%E3%83%BB%E3%82%A2%E3%83%AC%E3%82%B0%E3%82%B6%E3%83%B3%E3%83%80%E3%83%BC
AWSクラウドデザインパターン
http://www.publickey1.jp/blog/12/amazon45.html
http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8
波田野さんがまとめた障害監視のデザインパターン
http://rsh.csh.sh/kasf/design-pattern.html
2013-01-26 Sat
■ Design Pattern BoF @ Janog31 [JANOG]
http://cellistmiya.typepad.jp/blog/2013/01/design-pattern-bof-janog31-.html
河野さんの感想。
ささけんさんが、半ばむりやり、半ば強引にBoFを企画して下さった。
そもそも無茶振りしてくれたのは、プログラム委員チェア様だった気も。
当日は軽くディスってみたり大変失礼しました。
でも楽しかったのでまたなんかやりましょね〜。
2013-01-25 Fri
■ JANOG31 meeting 2日目 [JANOG]
http://www.janog.gr.jp/meeting/janog31/
1日目 --> [2013-01-24-1]
2日目は自分の担当プログラムは1つだけ。
でも終了後のBoFを1つ主催。
今回は働きすぎだと思うんだー。
5.
モダンアプリのインパクト
http://www.janog.gr.jp/meeting/janog31/program/appl.html
このセッションはどうなることかと思ったけど、
綺麗にまとまって良かった。
藤本さんの無茶振りは素敵。
無茶振りを受けとめきったじゅんじゅんはとても偉い。
竹迫さんはやっぱりさすが。
荒木さんは登壇できて良かった。一人だけ大人風味？
ただ、やっぱりアウェイなセッションだよなあ、とは思った。
やさしく説明するようなフォローはあっても良いかなあと思う。
6.
デザインパターンBoF
http://www.janog.gr.jp/meeting/janog31/program/design.html
プログラム応募で落選したプログラム(-->[2012-11-07-1])を
BoFで拾ってもらった。
ネットワークもプロジェクターも使えない環境でどうまとめる？、
なんか戦闘力高めの参加者が多いんだけど、
などなど不安はいっぱいあったけど、なんとかまとまった。
個人的にはすごく楽しかった。
ところで次はどうしようねえ。
この手のプログラムって、JANOGに応募しても落とされちゃうんだよなあ。
麻布十番方面に移動して打ち上げ。
抽選は外れた。
残念。
朝まで頑張る気力はなかったので、Orgチェアの片割れと一緒に、
六本木まで走ったよ。
2013-01-24 Thu
■ JANOG31 meeting 1日目 [JANOG]
http://www.janog.gr.jp/meeting/janog31/
スタッフ(プログラム委員)として参加。
会場集合は9:00。
ちゃんと間に合ったのにホワイトボードに鼻フックと書いてあるのは何故？
1日目は担当したプログラムが盛り沢山。
担当プログラムだけ書いておく。
1.
OpenFlow ～JANOGerに楽しんでいただけるか挑戦～
http://www.janog.gr.jp/meeting/janog31/program/SDN.html
このプログラムは事前打ち合わせが本当に楽しかった。
事前打ち合わせだけで4回もやったんだけど、
まったく飽きなかった。
OpenFlowは知れば知るほど面白い。
無茶なあきみちさんの言動も面白かった。
イメージ的には、あきみちさんが白で宮永さんが黒っぽいのに、
実態は逆だった。
発表時間が短いので面白そうなところをピックアップしたけど、
会場に面白さが伝わってれば良いなあ。
- OpenFlowはTCAMコントローラだぞ
- OpenFlow以外のプロトコルも活躍してるぞ
- Diffserveみたいなナツメロ技術も活躍
あたりがグっときてもらえれば勝ちかしら。
2.
高速ping
http://www.janog.gr.jp/meeting/janog31/program/ping.html
これは絶対ウケると思ってた。
やっぱりウケたよ。
プレゼンの作り方も秀逸だった。
/16 に ping 打ってみました --> はえー
/12 に ping 打ってみました --> はえー
ここで終わるかと思いきや
/8 に ping 打ってみました!!
までやっちゃうとは。
使ってみたい人、手を上げて!!、というのに
会場のほとんどが手を上げていた。
素敵。
3.
本当の枯渇後の世界
http://www.janog.gr.jp/meeting/janog31/program/RIR.html
岡田さんのPCが不調だったのが残念だったけど、モアイはインパクトがあった。
データもちゃんとしているし、問題提起はできたんじゃないかと思う。
個人的には事前打ち合わせのときの話のほうがきわどくて面白かったw
4.
IPv6 Deployment Statistics
http://www.janog.gr.jp/meeting/janog31/program/IPv6.html
日本のインターネットは IPv6 がちゃんと使えなくて、
Broken Internet とか言われてる、悔しくないか？、
って話。
続きは IPv6 summit でね。
担当プログラム以外では、竹迫さんのLTがやっぱり秀逸だった。
さすがだよなあ。
休み時間はお世話になっているブースを回ったり。
懇親会はご飯が大量。
まさか余るとは。
ラウンドテーブルではLTのテーブルにいたけど、
あんまり働けなかったかも。
2日目 --> [2013-01-25-1]
2013-01-11 Fri
■ JANOG31 スタッフミーティング [JANOG]
六本木にて。
本業焦げつきにより遅刻。
遅刻すると無茶振りされてることが多い。
馴れてきた。
○追加ミッションその1
懇親会企画のラウンドテーブルでLTテーブルの
ケアをすることになった。
そんなにケアはいらないような気もするけど、
楽しげなテーブルだと思うので喜んで。
○追加ミッションその2
パターンランゲージのBoFをやる方向らしい。
応募したプログラムは落選したんだけど(-->[2012-11-07-1])
面白そうだからBoFで、ってことらしい。
- デザインパターンとはなんぞや？
- 人の営みにはパターンがある
- ネットワークにもパターンがあるはず
- プログラミングの世界にはUMLみたいなパターンランゲージが
- あるけどネットワークにはUMLみたいな便利な道具が足りないのでは？
- 美しいパターンはあるはず。自然の自己相似形や、音楽のハーモニーみたいに。
- ちょっとパターンを書き出してみる？？？
みたいな内容で、河野さんに声をかけてやろうかと思う。
makeできると良いなあ。
2013-01-09 Wed
■ アプリセッションの相談 [JANOG]
午後から六本木ヒルズにて。
発表者が揃った。
個人的にはすごく楽しかった。
でも下のレイヤ専門の人からは、わけわからんと思われたっぽい。
わけわからんと思われたネタを書いとくです。
予習しておいてくださいまし。
○ASって言えば？
JANOGの人だと、AS番号。
アプリの人だと、ActionScript。
※LISPもプログラムを書く人だと間違いなく言語しか思いつかない。
○malloc症候群:
ちょっとプログラムを書けるようになって
メモリ確保命令(malloc)を覚えた頃は、
何も考えずに malloc しちゃう傾向がある。
その頃は「メモリは有限」ってことに気付かないので、
メモリを使いきってしまうようなプログラムを書いちゃって、
それが原因でシステムの不具合を発生させちゃったりする。
同じように「ネットワーク帯域は有限」ってことに、
プログラマが気付かずに、ネットワークプログラムを書いちゃうよね、
って話が出た。
○連想メモリ
SDNとか、プログラム可能なネットワークは注目されてて、
アプリ側の人も興味津々ではある。
でも物理的制約があって、たとえば高速メモリなんかの制約はでかいから、
なんでもできるわけじゃないよ、みたいな話もちらっとした。
連想メモリ↓
http://ja.wikipedia.org/wiki/%E9%80%A3%E6%83%B3%E3%83%A1%E3%83%A2%E3%83%AA
○ルータでもLLが使える話
最近は高めなスイッチではスクリプト言語が動く。
使える言語はスイッチによって違うけど、
Tcl、Perl、Ruby、Python、Lua、なんかが動く実装はある。
なんで書かないの？、っていう話もあった。
アプリの人は気軽に言うけど、
ネットワークの人はそもそも書けなかったり、
書くとCPUが危険なことも知ってたり。
○L4のプロトコルの話
TCPを使ってると帯域を使い切れない。
データセンター間バックアップ等で帯域を使いきれないのは困る。
Akamaiとかは独自プロトコルを使ってるし、Skeedなんかもあるけど、
そもそもTCPに変わるのはなんでないの？
実際にはあれこれ提案されてたけど、なんか最近はそういうネタは聞かない。
IETFの標準化プロセスにも問題があるんじゃね？、という気もする。
○HTML5の仕様定義の話
HTML5は、W3CやIETFと違う標準化プロセスをとってて、
非常に迅速な仕様追加と仕様定義がされてる。
このモデルみたいにネットワークプロトコルも定義できないの？、
っていう話もあった。
○DNSの通信量増えてない？
クライアント端末から、DNSを引く量が増えてる。
加えて、TTLが短かすぎる問題、DNSSECによるデータ量増加、
なんかもある。
ただDNSのキャッシュはセキュリティ的にはしないほうが良い。
○GUIを使う使わない？
上のレイヤの人はGUIを使う。
なのでGUIやコントロールパネルの出来はとても気になる。
でも下のレイヤの人はGUIをそもそも殺しちゃったり。
2012-12-21 Fri
■ 本当の枯渇セッションの相談 [JANOG]
午後から神田にて。
資源が枯渇したときにうまくやらないと滅びるよって話。
キーワードはモアイ。
参考図書は以下。
文明崩壊(上): 滅亡と存続の命運を分けるもの
文明崩壊(下): 滅亡と存続の命運を分けるもの
発表の時に出てくるであろうデータにも注目。
2012-12-20 Thu
■ SDNセッションの相談 [JANOG]
午前中、品川にて。
あー、楽しかった。
OpenFlow だけでは実現できないことも、レガシーなやり方を
組み合わせてうまくやってたり、新しい仕様だと、
宛先不明パケットは捨てられるとか、知らないことが沢山。
初日朝一のセッションなんだけど、絶対に面白いので、
寝坊しないほうが良いと思う。
JANOG31 Meeting
http://www.janog.gr.jp/meeting/janog31/
2012-12-07 Fri
■ JANOG31 英語版プログラム公開 [JANOG]
http://www.janog.gr.jp/en/index.php?JANOG
i18nチーム、毎回偉いよなあ。
ただ、wikiの名前空間には、スペースは使わないほうが無難だと思う。
Wikipedia(mediawiki)のように、URLはアンダースコアに置換しちゃう、
というようなプラグインはpukiwikiにはないのかしら？
2012-11-30 Fri
■ JANOG31 プログラム公開 [JANOG]
http://www.janog.gr.jp/meeting/janog31/program/index.html
今回も盛り沢山。
私は以下のプログラムの裏方をやる予定。
- よくあるOpenFlowの誤解と事実
- 高速ping
- 本当の枯渇後の世界
- モダンアプリのインパクト
- IPv6 Deployment Statistics
って、多くね？？？
自分が出した3つのプログラムは落とされたのにぃ。
頑張る。
BoFも頑張るの？
2012-11-20 Tue
■ 新橋で OpenFlow 話 [インターネット][JANOG]
夜の新橋であやしい飲み会。
風邪ひいてたので、みかんジュースしか飲んでないけど。
OpenFlowの誤解を解く話がメイン。
個人的にはいろいろ整理できてすごく有意義だった。
わかった上で使うとすごく便利で良い技術なのも再確認できた。
OpenFlow は、良くできたSDNの1つ実装なんだけど、
他にも面白そうなSDNは発明されるのかもしれない。
これからどんどん出てくるSDNを正しく理解したり
わくわくしたりするために、OpenFlowをちゃんと
いじっといたほうが良いのかな、と思った。
わりとすぐいじれる環境は作れるしね。
でも思ったことをすぐ行動には移せない駄目な子なのよねえ。