SQiP: 東京証券取引所 arrowhead 開発のユーザ側、ベンダ側双方のプロジェクトマネージャに聞く
-
- いいね！1
Yasunobu Kawaguchi
@kawaguti
宇治: フィードバック型V字モデルをやると、より上流工程でバグを減らすことができた。システムテストや受入テストはまさに確認するだけになり、手戻りがなくなり、デグレードがなくなる。 #SQiP
2011-09-09 09:57:44
Yasunobu Kawaguchi
@kawaguti
宇治: フロントサーバとバックサーバは品質の要件がちがう。外部接続があるのはフロントサーバだけなので、そこをしっかりすればなんとかなるという優先度付け。本番稼働２ヶ月前のバグはバックサーバが中心。徐々にシステム凍結。運用回避できるものは対応しない。稼働後に少しずつ直す #SQiP
2011-09-09 09:59:43
Yasunobu Kawaguchi
@kawaguti
宇治: リスク管理。リスクと課題をわけて管理しない。リスクx課題 でスコア化。これから来るイベントを想定してリスク軽減の予定スコアを書く。実際の実績スコアが乖離したら、重点的に対策を打った。 #SQiP
2011-09-09 10:01:16
Yasunobu Kawaguchi
@kawaguti
宇治: 最後に宣伝。ETFの売買手数料を東日本大震災に対する義援金として寄付します。４月から９月まで。この機会にぜひETFの売買をやっていただければ。 #SQiP
2011-09-09 10:02:01
Yasunobu Kawaguchi
@kawaguti
三澤: arrowheadの構造概要。トレーディングサーバの一つのノードにはこのような(図示)ミドルウェアが乗っている。ベンダー側なので商品名のせてます。 #SQiP
2011-09-09 10:04:44
Yasunobu Kawaguchi
@kawaguti
三澤: 高速性、信頼性、拡張性がコアファクター。提案時に結構重い要望があった。社内で実現すべく新たなミドルウェアを開発。Primesoft Server。インメモリDB、UDPベースの高速通信、ダウン時の切り替え機能 #SQiP
2011-09-09 10:06:21
Yasunobu Kawaguchi
@kawaguti
三澤: 売買サーバは緻密な性能設計を行った。当初10msecで設計をしたが、GW-注文管理-トレーディングサーバ間がインメモリになったので、結果的には2msecになった。途中ではいろいろ苦労したので今日はその話を。 #SQiP
2011-09-09 10:07:45
Yasunobu Kawaguchi
@kawaguti
三澤: 高速性の確保は、愚直に性能の作りこみと検証を行った。PDCAサイクル。性能のチューニングにはモデルが重要。東証におねがいして緻密な性能モデルを出していただいたので、緻密にできた。 #SQiP
2011-09-09 10:08:47
Yasunobu Kawaguchi
@kawaguti
三澤: 性能評価設計書。ミドルウェアのAPI発行処理、ミドルウェアのデータアクセス時間、ルータ/スイッチの通過時間、アプリケーションの処理時間、待ち行列モデルによる多重見積もり。ギャップが出たらチューニング。 #SQiP
2011-09-09 10:10:33
Yasunobu Kawaguchi
@kawaguti
三澤: 注文約定処理は処理ステップ削減を目的にロジックの見直し。情報配信は高速性が重要なので、共通部品を利用すると性能がみたせなかったので、情報配信専用に新規開発するなどの対策をとった。データの正規化で大量の参照と更新があり、ボトルネックになった部分で、非正規化 #SQiP
2011-09-09 10:13:03
Yasunobu Kawaguchi
@kawaguti
三澤: コーディング規約。実装規約を。項目初期化の効率化(業務の処理より初期化に時間がかかる)。リテラルで初期化してローカル変数を一回コピーで。アライメントエラーによる性能劣化を、設計時のバイト境界合わせで。少しでも高速化を目指した。 #SQiP
2011-09-09 10:14:51
Yasunobu Kawaguchi
@kawaguti
三澤: 信頼性の担保。３ノードの構成。プライマリノードに対して２系のバックアップノードを持つ。アクティブノードに書かれると、同期をとってスタンバイノードにも書く。アクティブノードがダウンしたら残り２系で即時に引き継ぐ。 #SQiP
2011-09-09 10:16:34
Yasunobu Kawaguchi
@kawaguti
三澤: 拡張性の定義は３つ。緊急拡張、短期拡張、長期拡張。緊急拡張: 急なニュースで取引量の急速な増加が見込まれることがある。昼休みに高負荷サーバからもうちょっとあいているサーバに銘柄を移せるように設計。短期拡張: サーバ追加時に時間がかからないように共通予備機 #SQiP
2011-09-09 10:18:37
Yasunobu Kawaguchi
@kawaguti
三澤: 短期拡張: 現在は１週間でサーバ追加できる。長期拡張: ストレージのディスク追加等は、緊急にならないように計画的に追加。 #SQiP
2011-09-09 10:19:26
Yasunobu Kawaguchi
@kawaguti
三澤: まとめ: 要件定義にしっかり書かれていた、ということがとてもよかった。誰でも作れるというと語弊があるが、しっかり書いてあり、しかも、確認すれば書き直していただけた。利用者部門の要件集約を早く対応していただき、仕様凍結が設計工程に間に合った。 #SQiP
2011-09-09 10:20:33
Yasunobu Kawaguchi
@kawaguti
三澤: まとめ: ３つの非機能要件もしっかりまとめていただいたので、取り組みができた。要件定義トレースの実施。プログラムは手で書くのでどうしてもバグが出る。ソースレビューを３段階。内部レビュー、ソースチェックツール、第３者レビュー。フィードバックV字で前工程でつぶす。 #SQiP
2011-09-09 10:22:32
Yasunobu Kawaguchi
@kawaguti
三澤: 稼働に向けて、発生した障害の対応状況を確認、修正リスクを判断し、稼働後に直すものは先送りにした。スローガン「challenge 10msec」を貼り出した。「コミュニケーション。最後まであきらめない。世界一のシステムをめざそう」 #SQiP
2011-09-09 10:24:38
Yasunobu Kawaguchi
@kawaguti
宇治: いい質問です。最初は要件定義書をユーザの勝手できれいな文書で書いてしまった。あとから要件トレース表をすることになり、作成した。人件費としていくら残業代を払ったかはチェックしていないが、新たに人を雇ったことはないです。業務要件は複雑な条件があり、... #SQiP
2011-09-09 10:29:18
Yasunobu Kawaguchi
@kawaguti
宇治: (途中聞き漏らしました) ユーザサイドからすると、設計書レビューで要件トレース表をつぶしていくので、それほど追加コストはなかったとおもう。メーカー側がどうだったかは富士通さん側。私もきいてみたい #SQiP
2011-09-09 10:30:34
Yasunobu Kawaguchi
@kawaguti
三澤: 私も要件トレースの工数は把握していないが、手戻りがなくなるのであとでかえってくる。レビューの中で追加の作業だが、レビュー時間は倍にはなっていない。品質は向上するので... #SQiP
2011-09-09 10:32:18
Yasunobu Kawaguchi
@kawaguti
森崎: 2006年に初めて宇治さんにあって、arrowheadの共同研究の話があった。こんなにユーザとベンダがリスクを共有することがあるのか、と感動。いい事例は共有したい。 #SQiP
2011-09-09 10:33:32
Yasunobu Kawaguchi
@kawaguti
森崎: あんまりお金をかけられないシステムには同じようなやり方はできないと思う。会場の方々に、ご自身のソフトウェアはどうでしたか、という質問をしますので、会場からもご回答をいただきたいとおもいます。(ニヤニヤ)。 #SQiP
2011-09-09 10:34:45