ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

Raspberry PIでUTMをオープンソースで作る-IoTのセキュリティ向上のため

2014-12-04 18:07:02 | ネットワーク
という内容の記事が、日経ネットワーク2014年12月号に載っている

ネットワークなんでも実験室
透過型プロキシでIoTのセキュリティを高めよ!

という話。

IPFire
http://www.ipfire.org/

というオープンソースをダウンロード、解凍、SDカードにいれ、
1つのインターネットの口はあるので、もう一つ、USBに拡張NICをさして
行うという話のようです。

報告終わり!


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「エンタープライズアジャイルへの挑戦」を聞いてきた!

2014-12-04 16:03:41 | 開発ネタ
12月2日、
超高速開発&エンタープライズアジャイル2014
に行って来た!のつづき

これで最後

エンタープライズアジャイルへの挑戦
中電CTI

をメモメモ・・なんだけど、途中、聞き取れなかった!ごめん・・・





会社紹介

アジャイル開発手法への取り組みの背景
・電力システム改革への取り組み
  →スピードと柔軟性

求められるITサービス
・従来のシステム開発
 ウォーターフォール
・今後
 スモールスタートも

しさく
(1こみえない)
・新しい開発スタイル
・システムイノベーション
・プロセスマネージメント

ITサービスの継続
・老朽化→ビッグバン
・価値を提供し続ける

ITサービスの必須条件
・安定的かつ継続的
・変化に対して迅速
→アジャイル開発

アジャイル開発手法適用
・拒否感
→メンバーの意識改革
→RADを利用:すリーしズム

PDSA→Cでなく、S(Study)

アジャイル開発
・中だるみ→カイゼン活動
 テストの自動化
→メンバーの意識改革:効果の可視化
・生産性向上への道のり
 あいまいな仕様
 →フォーマルインスペクション

エンタープライズ・アジャイルへの期待と準備
・プロジェクトの失敗回避
  ・大規模
  ・出来たものから早期に
  ・リスクある
 ビッグデザインアップフロント
  ・ゴール
必要になるプラクティス
・要求しよう
・製造・テスト
・リリース:ビルド、デプロイ、構成管理:自動化
方向付けでやることが多くなる

エンタープライズアジャイルの挑戦
1.拒否感への対応
  進め方 すりーしずむ?
  悪い3げん主義:幻想、幻惑、幻滅

2.ITサービスデリバリーの視点を持つ
  ボトルネック
  ツールの例:構成変更とデプロイの連携

3.アーキテクチャの視点
  方向付けフェーズでアーキテクチャ明確化
  不変な部分は方向付けで決定

本日のまとめ

必要なノウハウ
・ソフトウェア工学
・プロジェクト管理
・ソーシャル


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

HTML5→REST/JSON(SPA)→JQuery→AngularJS→JAX-RS→JSR 371(MVC 1.0)をまとめてみる

2014-12-04 12:30:04 | Weblog

「企業文化を創る究極のエンタプライズソフトウェア開発」の聞いてきた内容(個人的には異議あり!)
http://blog.goo.ne.jp/xmldtp/e/f7dcaec498107f63d8ffc21270a1dbb5

の話の続き。そもそも、会社の要望が、こう変わったんじゃなかったっけ?

・デザイナーでもユーザーでもだれでも、短時間でその場で作れてレビューできる
 GUIが必要になった

・どんな端末でも、ある程度すぐに使えるようにしてほしい。

・短期間で、それほど難しくなく開発してほしい

だれか優秀な人が短時間で出来たとしても、その人に頼ってしまう。
また、先輩から後輩に教えるというのでは、技術が陳腐化する
最新技術を取り入れながら、爆速に開発するには、
みんなが、開発できる必要がある。

そこで、ちょうどいいかんじに出てきたのが

  HTML5

で、HTML5なら、まあ、だれでも(ツールとか使えば)かけるし、
PCでもiPadでもスマホでもみれるし(なのでFlashあうと)・・
スマホファーストにして、スマホのとくにオフラインのときの
設計から考えていけば、まあ、PCでもタブレットでも、
見栄えが多少変かもしれないけど、まあまあ、いいかの画面になる。

そこでHTML5がでてきて、GUIに凝れるようになり、デザイナーさんに
画面を頼るようになった・・・




・・・ら、いままでのStrutsのような、画面にタグを入れる形式だと、
デザイナーさんだけで完結しない。HTML5の画面をプログラマがStruts
タグに代えなければならない。ここで時間ロスがでる。

 そこで、画面とサーバーを完全分離するため
   1.画面側はAJAXを使って、データをサーバーからとってきて、
     その内容をJavascriptでセットする
   2.サーバーは、GET/PUTの引数をもとに、データを返すだけ
 という形にしたくなった。

 そこで、1に対してRESTが、2の返すデータに対してJSONが
 使われるようになった。

 こうなると、もう、画面だけで、動きは完結するジャン!ということで、
SPAという考え方が生まれてきた




 そこまでくると、画面に動きを持たせたくなり、これが行いやすい

    JQuery

 が流行るようになる。そして大問題が起こった
 JQueryだらけになり、よくわからん・・・

 そこで、このプログラムの汚さを回避する為、
 クライアント側のJavascriptにフレームワークを導入するようになった。

 ここでフレームワークがいろいろ出てきたが、AngularJSの
   ・ディレクティブにJQueryを書きたければおしこめ
   ・そこでタグ等を定義し
   ・基本的にはタグは書くけど、JQueryを各プログラムにいれない
 という考え方が美しく、人気になった。




 そうなってくると、サーバー側もJSON形式を返しやすいフレームワークが求められる。
 それまで日本ではStrutsが人気であったが、Strutsは、どちらかというと、Strutsタグ
 をいれてビューまでつくるのに向いているもので、JSONで書き出すには無駄が多い
 (かけないわけではない。ただし、一般的なプログラマが気づくかどうかは?)

 で、もっと単純にJSONにできないかというと・・・
 サーブレットでもいいんだけど、まあ、Javaのほうで、ラブリーなものができてきた。
 それが

    JAX-RS




 ここまでくると、JavaのMVCは、どうあるべきか論がでてくる。
 JAX-RSを使って、RESTをベースにしたもんを考えるべきか
 いやいや、Strutsでしょう(というのは、日本だけ?とくにStruts1を言うのは)
 サーブレットでよくね?

 ・・・これらの議論をまとめようというのがJSR 371(MVC 1.0)

 だと思っている




なんで、HTML5の出現により、ある程度GUI側の問題は、解決しつつあるという認識
なんだけど・・違うんかなあ?

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「企業文化を創る究極のエンタプライズソフトウェア開発」の聞いてきた内容(個人的には異議あり!)

2014-12-04 11:12:56 | ネットワーク
12月2日、
超高速開発&エンタープライズアジャイル2014
に行って来た!のつづき

企業文化を創る究極のエンタプライズソフトウェア開発
講師:アークウェイの人

の発言内容をそのままメモメモ
(自分は納得言っていない。私の意見ではない)






エンタプライズにおけるソフトウェア開発課題
・問題;人間
  技術力が落ちている→作れる人がほとんどいない
  自分たちが分かっているエリア
 高速化したい:実装?
  実装を早くしても喜ばれない
  →要件、メンテナンス
 メンテナンスまで含めた全体間

・作成するものとフィティングしていますか
  あるところを超えると、スクラッチより遅くなる
  ブラックボックス化
  移行にものすごいお金

企業文化を創る究極のエンタプライズソフトウェア開発
・現状のソフトウェア開発はつらいです
 前を向きましょう

・究極のエンタプライズソフトウェア
  1時間のミーティングで作れるか
  ボタンの位置1個でも要求
   →一瞬で直せますか
  設計の一項目を何分で直せるか
  たった1項目に1週間かかっている

・試作品
  メインストーリーを社長の前でプレゼン
    DBがなくても作る
    ここで承認をもらう

・要求をユーザーの面前で
 試作品で評価
 やらないソフトもある

・皆さんの会社でこれをやってくださいということ
 このために何を準備したらよいか

・試作→すべての工程を1時間以内にやりきる
 開発資産を大事にする
  ・アプリケーションの種類を減らす
  ・ノードの数を減らす

・アーキテクチャ(つみかさなっている)
  ・Oneスタックを準備する

・パターン化
  画面、サービス、ガイダンス
  パターンを暗記してもらう→トレーニング
  スクラッチから1時間以内で作れるトレーニングをする
  作り方を早くするにはパターンしかない
    中身を完全に把握したものを高速化する
  変更部分のデザイン
    →デベロッパーに依存
  この状態になるのに3年かかる

・3年から5年たつと、同じ画面が並ぶので、
 システムをまたがって配置できる
 先輩から後輩に教えられる

・1年目の人が、10年目の人よりも速いことも
 遅い人は呼ばれなくなる
 見積もりの精度は高くなる
 1画面17分と4日くらい差が出るので、
 3日かかるやつは、客の前に出せない
→これが、わたしたちの目指しているところです・・


・数を減らし、技術を絞る→メンテナンス出来ない
 ロードマップ
・トランスファーしていく

昔はあたりまえ→今出来ていない
ソフトウェアの基本形だけをのこしておく

事例紹介
・製造業
  平均6時間11分→雛形でテスティング入れて42分
  8割くらいがパターンでつぶせる
  女性のほうがはやくなる。10倍速くなる

・教育
 底上げになった
 モチベーションが高くなった

まとめ
・究極の開発手法とは
  ・速く作るということは、速く終わるということ
  ・作る前にやめられないか
・最適
  ・数を減らす、ノードを減らす
  ・徹底的に教育
・Word,Excel,Accessはすぐに出る
  ・先輩から後輩にうつす
・ユーザーとのミーティング
  ・一番大事な画面がある→同じように作る
  ・デフォルト値がないような画面はX
  ・価値を作るのは人
  →腕を磨くのが必要

・作っている人が企業に貢献したい
・大きいものを速く作っても直せない




いや、求められているのは、「大きいものを早くつくる」技術だし
早い人を集めて、開発が早くなってもあまり意味がなく、求められているのは

みんなが、そこそこに早くなる

ことであり、

それで、HTML5からの一連のながれになっているのでは?

・・・こんへんを、別エントリで書く


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月3日(水)のつぶやき

2014-12-04 06:48:27 | ネットワーク

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

サイバーエージェントさんのOpenStack導入話を聞いてきた

2014-12-04 06:03:18 | Weblog
12月3日
OpenStack最新情報セミナー
に行ってきた!のつづき

夜の部をメモメモ




■OpenStack Fast Track
 サイバーエージェント

・なぜ採用
 プライベートクラウド構築:勢いあったOpenStack
 icehouseの話。OS CentOSで構築

自己紹介

・本日のアジェンダ
 ・こんなStackを作りました
 ・構築と運用

こんなStackを作りました
・ノード数51台(100以下小規模、1000台
・本番サービス用
・1.5人で1ヶ月
・1台あたりCPU2.4G メモリー16G ディスク480G)

公式Docs++
・公式ドキュメントから離れるほど難しくなる
  ・冗長かと速度が出ない
変更点
・コントロールプレーンの冗長化
  →データプレーンは冗長化していない

・最低限のコンポーネントで組む

必要なもの
・サーバ
・冗長かされたL2,L3,LB

必要な周辺機能
・ベアメタルプロビジョニング
・パッケージレポジトリ
・DNS(正引き/逆引き)
  →RabbitMQなどで逆引きを期待しているものがある
・syslog

アンダークラウド
・クラウドを動かすためのクラウド
  ・OpenStackのコントロール
  ・周辺サービス
・要件
  ・統合管理
  ・ストレージなしでライブマイグレーション

全体のイメージ
・コントロールプレーン

・データプレーン
  KVM
  Open vSwitch
  swift

コンピュート
・オーバーコミット「しない」(1.0)
  →数百倍のコミット率にしている人もいる

フレーバー
 CPU2倍にしたらメモリ2倍ディスク2倍

 ネットワーク
  Neutronは使う
  L3Agentは使わない
  VLAN Type Driverを使う
    169.254.169.254

 ネットワーク設定

ストレージ
 ブロックストレージはインスタンスストアのみ
  インスタンスストアはRAID5で保護
 Glanceの上超過のためSWIFT

 MariaDB Galera Cluster
  →気をつけないといけないことがある
   つねに1台が使われるようにする
   3台で組んでいるクヲーラム確保

 RabbitMQ
  ハイアベイラビリティガイド

 OpenStackコンポーネント
 例外
  glance-api:swiftをバックエンド
  nova-consoleauth:memchashd
  neutron-dhcp-agent:3個

構築と運用
・手動で構築もできるが、700項目もある
・OpenStackインストーラー:トラぶったら?
・汎用ツール:Puppet,Chef,Ansible

構成管理
・SCMにコミット
・複数環境に対応
・冪等性に意識
・完全自動化
開発、検証環境

運用
・オーケストレーション
  Jenkins
   ロギング
   ワークフロー(multiJob plugin)
・手元で動くことを確認
 github push
 Jenkins
 Upstream/production

VLANで4096問題
 →サブネットで4096必要ない
L3Agent使わない→既存のL3環境

NovaCompute、LinuxBridgeを使わない理由
Neutronにいきそうだから、Open vSwitchでも問題にならない

メモリ10枚のりゆう(12枚でなく)
→コスト16G使いまわせる

これから
・ネットワークの真のマルチテナント
・SDN(SDS)




■Design and Operetion of OpenStack Cloud on 100 Physical Servers
http://bit.ly/1CEoQv4
資料は来週くらい?本日の資料はそのあと

・About US
 Docomo

・知りたかったこと
  ハードウェアリソースとマネージメント
  HAの担保
  デプロイメント

・StarBED→100台の物理サーバー
 NICT、JAIST,東大、DELLが協力
 http://starbed.nict.go.jp

・ネットワーク構成
冗長性
・マルチシャーシリンクアグリゲーション(MLAG)
・エンハンスド・イコールキャストマルチパス(ECMP)
ML2
 ・TypeDriver VXLAN

スループット
 ブリッジとOVSの差はあんまりない

VXLANを使うとCPUパワーを取られてしまう
→オフロード機能が無効になってしまった
→急遽VXLANオフロード機能があるNICを入手
  →スループットどかんとあがる
VXLAN オフロードNIC有効

High Availability
・人を減らせる→丈夫にする
・ロードバランサー
 こわれたとき:LBがチェック、付け替える
DR

RabbitMQ-HA
Pythonのライブラリがいいかんじにやってくれる

Neutron-HA

もにたりんぐポイント

障害が起きたら
 エージェントとめます
 ルーターとか、マイグレート
 NICとめないとわるさするらしい

今後
・L3エージェント
・もにたりんぐのカイゼン
・L3エージェントのリスケ

マネージメントリソース

データベースのサイジング

デフォルトのセキュリティグループ:重くなる

管理ツール

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする