金融取引システムにおいて支配的なポジションを得たLinux 55
ストーリー by hylom
UNIXが生き残る場所はどこにあるのか 部門より
UNIXが生き残る場所はどこにあるのか 部門より
danceman 曰く、
かつて金融システムといえばAIXやHP-UXといったUNIXの独壇場であったが、近年では様子が変わり、Linuxが支配的なポジションを得ているそうだ（本家/.、IT World記事）。
最近のLinuxではシステム間のメッセージ送受信を高速で行えるため、超高速取引を繰り返すHFTのウェイトが大きくなっている金融業界で採用が進んでいるという。たとえば、ニューヨーク証券取引所を運営しているEuronextはLinuxシステムを採用しており、毎秒150万の売買注文を出し、25万の売買注文を締結しているのだそうだ。
また、2007年まで主流であったUNIXの場合、アップデートに2、3年もかかっていたのに対し、Linuxの場合だと一ヶ月足らずで修正を加えることができる。Linuxカーネルの貢献者であるChristoph Lameter氏によれば、「大胆な取引があるところほどLinuxパッケージの修正版を使用している」とのことで、Gentoo Linuxパッケージの修正版を使用しているNASDAQを例に挙げている。
Lameter氏は、今週バンクーバで開催されるLinuxCon会議で金融取引の分野においてLinuxが広く採用されるようになった経緯を話す予定であるとのこと。
部門名 (スコア:3, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
宛部門名 (スコア:1, おもしろおかしい)
＞UNIXが生き残る場所はどこにあるのか部門
えーと････あ、あれだ。GNU系ソフトがデフォルトで入ってないから
意図しないGPL汚染にまみれない、とか！
Re:宛部門名 (スコア:1)
運用が大変そう (スコア:1)
Gentooだと、全部そのマシンでコンパイルしたバイナリを使うから早いのかな。
こういう業界だと、少しでも処理は早いほうがいいもんね。
なんのことでしょう? (スコア:0)
> 最近のLinuxではシステム間のメッセージ送受信を高速で行えるため
本家 /. の方を読むと，「他の UNIX は遅い」みたいなことが
書いてあったけど linux のどの点をさしていっているのでしょう?
なにかこういうベンチマークってあったら教えてください。
本家の方のコメントでは
「FreeBSD の方がもっといいじゃん」
「いや FreeBSD は高負荷時の安定性はいいけどレイテンシはどうでしょ?
Linux では 2.4.x からいろいろ改良してんだぜ」
とか書いてる人がいますが具体的になにをさしているのかよくわからず。
Re:なんのことでしょう? (スコア:3, 参考になる)
ミリ秒からマイクロ秒を競う金融ではスループットよりもレイテンシを優先して、応答時間が決定論的なリアルタイムカーネルが使われます。
なので、IO以前に、リアルタイム性能が低いFreeBSDなどのカーネルは微妙ですね。
Linuxでいうと、CONFIG_PREEMPT_RTパッチがそれに当たります。
Re: (スコア:0)
Re: (スコア:0)
MINIX3は…RTじゃないな
Re:なんのことでしょう? (スコア:1, 参考になる)
InfiniBand HCA の対応具合とか？
適当にぐぐってみたら、この辺(PDF) [daito-me.com]とかLinuxのみ対応OSになってる。
Re: (スコア:0)
FreeBSDはデータサーバ、Linux系はAPサーバに向いているんじゃないかと思うのです。
というのも、
FreeBSDの安定性は、いうまでもなく、また、*BSD系は基本的に速度よりも安定性を重視していることもあり
設計レベルで耐障害性がつよいです。(変なタイミングに電源落ちたりしても大抵の場合、自動復旧できる)
一方、Linux系はファイルシステムにも現れているとおり、安全性よりも速度重視に設計されています。
なんで、高い稼働率と障害復旧を見込んで、FreeBSDはサーバ数が少なく速度もそれほど要求されないデータサーバーに、
ある程度の安定性と高速な処理、そして、たくさんのサーバを利用するようなAPサーバにはLinux系が向いていると思います。
たんにFreeBSDが好きというだけの話ですけど、
好きな理由は、上記の通りシロートには安心設計というのと少ないリソースで動くことです。
# 最近はLinuxでもZFSっぽいものをつくってる？
Re:なんのことでしょう? (スコア:1)
FreeBSDにはオラクルが無い。
> # 最近はLinuxでもZFSっぽいものをつくってる？
Btrfsとか。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
>(変なタイミングに電源落ちたりしても大抵の場合、自動復旧できる)
>一方、Linux系はファイルシステムにも現れているとおり、安全性よりも速度重視に設計されています。
変なタイミングで、電源落ちても耐障害性につよいなんて、
抽象的なこと仕様に明記も説明も満足にできないのに、
設計レベルに耐障害性が強いって一体どんな設計してるんだい？
電源が突然、落ちないシステムを組む方法が普通じゃないのかね。
Re: (スコア:0)
Re: (スコア:0)
なんというか、半端なBSD信者乙というところか。
>設計レベルで耐障害性がつよい（）
もしかしてsoftupdateのこと？
他の商用UNIXが、softupdateの方式ではなくジャーナルファイルシステムを採用しているんだけど。
商用UNIXもある程度の安定性しか狙っていないんだろうか。
>FreeBSDはサーバ数が少なく速度もそれほど要求されないデータサーバーに
1サーバ当りの性能比ではFreeBSDの方が悪いということですね。
データストレージに安定性や対障害性を期待する場合は、DASではなく独立したストレージ装置を用意するのが普通。
その上で、接続に使用するFC/iSCSI HBAなどはFreeBSDでどの程度サポートされ、稼働実績があるのかな？
>少ないリソースで動くこと
FreeBSDでもZFSを利用しそれなりのパフォーマンスを得る場合には、少ないとは言えないリソースが必要では？
Re: (スコア:0)
全体で見ると矛盾してるぞ。
個別の言葉尻を追って都合よく反論してるからそうなる。
金融取引システム (スコア:0)
やっぱりシンボル的なものなんでしょうか。
Re: (スコア:0)
HFTといってもFX業者の相対取引のシステムもそうだし、
ヘッジファンド自身がシステムを持ってることもあるし、
証券会社がヘッジファンドにシステムを提供したりと色々です。
ちなみに海外投資家が日本に事務所はないけど、サーバだけ置いた場合の法人税はどうなるのか？
証券会社のサーバを使った場合はどうなるのかという論争も現在進行形です。
ハードは最近はx86ばっかですね。HPなんかも普通にSUSEなどと組み合わせて納入します。
Re: (スコア:0)
まあそうかなーと思いつつも、弊害もあるんじゃないかと思って見てました
Re: (スコア:0)
間違えて三桁多い注文を出しちゃった、とか。
Re: (スコア:0)
http://osdn.jp/magazine/10/01/05/1038203 [osdn.jp]
本番機はUNIX、開発検証機はLinux (スコア:0)
時代遅れかもしれないが、そういう環境しか見たことがない。
Re:本番機はUNIX、開発検証機はLinux (スコア:1, 参考になる)
元地方SE屋→大手に買収された後ミドルウェア開発・販売も始めた会社に入社して10年経ちますが、本番環境はRHELで開発環境はCentOSというプロジェクトが殆どです。単品で販売しているソフトもそれ前提。
昔は地元の案件でもAIXなりSolarisなりを指定された案件が少なからずあったようですが、私の知っている限りここ数年それも無いようで、「Linuxにしておけば間違いない」というのが通説として定着した感がありますね。厳密にコストなりリスクなりを計算したらどうなるのかはよく判らないですけど。
Re: (スコア:0)
×SE屋 → ○SI屋
Re: (スコア:0)
Re: (スコア:0)
マシンスペックに余裕のできた今こそCOBOLのような高級言語を使えばいいのにと思うよ。
習得も容易だしさ。
Re: (スコア:0)
仮に習得が容易だったとしても、作業自体の容易さは実物のソース如何なわけで、現代的なテスト環境や方法論の前に遺物扱いされるのは仕方がない面も。
移植とリファクタリングを同時進行させるっていう目論見もあるのかもしれないけど。ハノイの塔みたいに。
Re:なんでもいいCOBOLを淘汰しろ (スコア:2, 興味深い)
世の中には DB/DC Unit Test Function of COBOL Debugger [nii.ac.jp] だの COBOLUnit だのといった、中々楽しげなものも存在しますし、COBOL も言語自体のバージョンアップもされていっています。今時の COBOL は普通に Java や .NET と連携できますし、.NET なバイナリーの場合だと NUnit などのテスト系ツールも普通に使えるんじゃないかと。
一応変化して言っている COBOL を見ると、遺物扱いにしたい人が遺物扱いのレッテルを貼りたいだけ感は結構強いですね。
Perl/PHP/Ruby/Python/VB/Java/C/C++/C#/VB.NET 辺りであってもメンテナンス性の低いゴミコードが量産されるかどうかは開発者次第でしかないですし、COBOL で書くと自動的にそんな形になるなんてこともありません。
というか、汚くてメンテナンス性皆無なコードを「COBOL 以外で」散々目にしているであろう人が、「COBOL だから」という理由で = ゴミコード扱いするのはどうかと思いますね。
「COBOL だから遺物」なのではなく「メンテナンス性のカケラもない、自動化されたテストも行われていない、そんな腐れたコード群だから遺物」でしょう。
ま、COBOL の仕事なんてしたくもありませんが。(笑)
# "COBOLer" を言い訳にする人は、まず COBOL の問題じゃなくその人の問題。そんな例ならよく見ます。
Re: (スコア:0)
＞COBOL で書くと自動的にそんな形になるなんてこともありません。
そんあ形になるゴミコードをいじらなければならなくなったのだが？
どんな言語使ってもゴミはゴミです。それこそ、開発者しだいです。
たいていCOBOLerは、動いているならそのままでいいじゃんという時代錯誤な人ばかりですよ。
そんな人たちがゴミ以外のコードを生産すると思いますか？
Re:なんでもいいCOBOLを淘汰しろ (スコア:1)
システム的には動いているものをいじるのはリスクあるから
そのままでいいじゃんは当たり前です。
ゴミでも動いていれば客は文句言いませんし、
リファクタリングに予算が付くなんてよっぽどの事態です。
COBOLに限ったことではありません。
#属人的な要素も大きいけど、謎コーディング規約が生きてるとかも怖いよね
トピ的にはよりパフォーマンスを求められるシステムでの
Linuxみたいな流れになっているので、そんなところでは
何使って開発しているかとかも気になりますね。
Javaなんかは開発効率的に良さそう(＝質はともかく人は多そう)だけど
コードの最適化とか考えたらやっぱりC++に一日の長がありそうだし。
Re: (スコア:0)
マイクロ秒を競ってマシンスペックが不足気味って時に、マシンスペックに余裕とか言っちゃうCOBOLerって時代読めてないよね
24時間365日、オール・リアルタイム処理がこれからのトレンド
市場が開いてないったって夜間PTSはあるしな
Re: (スコア:0)
> マイクロ秒を競ってマシンスペックが不足気味って時に、
> マシンスペックに余裕とか言っちゃうCOBOLerって時代読めてないよね
時代読む前に、空気嫁ｗ
元コメ主の書き方（マシンスペックに余裕・・）も悪いが、
普通に考えればCOBOLインタプリタを使うなんて今時無いだろｗ
COBOLだろうがJavaだろうがコンパイラとリンカの出来が良ければ
採用理由になるし、出来が悪ければ使えない。
＜ 高速化だけに特化すれば、コンパイラとリンカに依存する
＜ 高級言語（C/C++/C# Basic Java COBOL 他多数ｗ）
＜ なんか使用するに値しない。全部糞だ。
＜ アセンブラ以下を自分最適化するしかない。
＜ もっとも、早くなった例を見たことが無いが。ん！？
Re: (スコア:0)
>COBOLだろうがJavaだろうがコンパイラとリンカの出来が良ければ
リアルタイムシステムなんて、ページフォルトを起こさないためにC言語ですら色々制限がキツいのに、高級言語なんて使えない。
https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application [kernel.org]
まぁJavaならリアルタイムJavaという変り種も有るには有るが、それでもリアルタイム性能の低下は大きい (マイクロ秒レベルは不可能)。
http://www.ibm.com/developerworks/jp/java/library/j-rtj1/ [ibm.com]
COBOLでリアルタイム性能を謳う製品なんて一つも見たことが無い。
>高速化だけに特化すれば
問題はスルー
Re: (スコア:0)
COBOLかどうかは関係なく、高級言語や標準ライブラリの使用がダメと言っているだけかな?
あと、リアルタイムを単に早いという意味で使っているっぽいなぁ
># 関係ないけどスループットですら、COBOLはマルチスレッドに対応してなかったような
十数年前に作った銀行や証券のシステムを作ったときは普通にマルチスレッドだったが。
当然事前確保なんかもやっている。
#当然それらはシステムとしての話だから、そこらを言語だけで語るのが間違っているのだ。
#COBOLはそういうシステムを味方につけているということを知らない人は結構多いのかな?
#システムという視点や知識が無いから高級言語だと無理とか平気で言える。
Re: (スコア:0)
>リアルタイムを単に早いという意味で使っているっぽい
使ってない。ジッターを最小限にするという意味。レイテンシの最悪値を一定以下にするという意味。
バッチとリアルタイムのリアルタイムではなく、リアルタイムOSのリアルタイムね。
Re: (スコア:0)
> バッチとリアルタイムのリアルタイムではなく、リアルタイムOSのリアルタイムね。
であれば、COBOLはリアルタイムシステムに長年使われているからそういうリアルタイムシステムの一員だね。
Re: (スコア:0)
えーと、リアルタイムシステム(≠リアルタイム処理)でCOBOLって初耳なのですが。
そもそもSMT型マルチコア対応のリアルタイムOSが普及しはじめたのは2006年から2007年あたりです。
Linuxのrtパッチがミッションクリティカルに使われるようになりはじめたのも、VxWorksがSMTに対応したのも。
それ以前は大規模システムにおけるRTOSの採用自体が少なかったわけで。
# ちなみに組み込み寄りですが、通信業界は2003年ごろからSMTなMIPSのCPUでLinuxのrtパッチを使ってたと記憶 (MontaVista Linux CGE)。
NovellのリアルタイムLinuxへの挑戦 - 「SUSE Linux Enterprise Real Time」発売
http://journal.mycom.co.jp/news/2006/10/27/350.html [mycom.co.jp]
Red Hat，リアルタイム機能でRHELの性能を向上する「MRG」を発表
Re: (スコア:0)
っちょ・・・
最低限の勉強はしてくれ
Re: (スコア:0)
>最低限の勉強はしてくれ
?
オンラインリアルタイムシステムの話じゃなくて、マイクロ秒を競うハードリアルタイムシステムの話ですよ?
ちなみにメインフレームでのAIXやHP-UX、SolarisなんかのUNIX系はカーネルスレッドでプリエンプトを行う程度のソフトリアルタイムが限界です。
Windowsでは知ってる限りCEだけがハードリアルタイムに対応していますが、マルチコアには未対応です。
Re: (スコア:0)
> ハードリアルタイムシステ
おや、新しい単語の出現ですね(笑)。
VxWorksあたりの話題を嬉々としてあげてきたので、そのような限定条件の話と思っていましたよ。
> マイクロ秒を競う
やっぱり、リアルタイムを単に早いという意味で使っている。
> メインフレームでのAIXやHP-UX、SolarisなんかのUNIX系はカーネルスレッドでプリエンプトを行う程度のソフトリアルタイムが限界です。
ですから、もっと広い世界を勉強してください。
でないと、同じ間違いを延々続けることになりますよ。
まあ、どちらにしろCOBOLのような高級言語も金融取引システムも関係ない話になっているね。
#リアルタイムシステムで内でも一部限定の話しだね。
Re: (スコア:0)
一部限定では無いですよ。HFTでは複数の市場にまたがってマイクロ秒単位で取引しているわけですから。
だからこれからのトレンドって言ってるわけで。
Re: (スコア:0)
> HFT
また、新たな単語出現ですね。ずれているし限定的なのは変わらない単語だけど。
> 一部限定では無いですよ。HFTでは複数の市場にまたがってマイクロ秒単位で取引しているわけですから。
> だからこれからのトレンドって言ってるわけで。
爆笑ですね。
不勉強で視野が狭いとここまでひどいのか。
PS. こいつはHFTについても表面的かつ限定的な説明しか出来ないに一票。
Re: (スコア:0)
>限定的なのは変わらない
まぁ危機感なきゃそんなもんでしょうねぇ…昔から大雑把だから
それはどこでも一緒かw
Re: (スコア:0)
リアルタイム
↓
ハードリアルタイム
↓
特定のシステム(HFT)
どんどん話が限定的に。
そもそもHFTはハードリアルタイムになるのか?
エアバックのように特定のタスクが他をとめてでも規定された時間に処理が完了することを求められるのがハードリアルタイムだよね。
金融取引システムではちがうよね。確かに一タスクに限定すれば規定時刻を過ぎれば価値がなくなることもあるが、システム全体では致命傷にはならない。儲けが少し減るだけ。
本当にハードリアルタイムならどんなスケジューリングをしているか聞いてみたいぞ。
だいたい、取引に競り負けたら致命傷を負うシステムで金融取引はしたくないよねふつう。
Re: (スコア:0)
> >限定的なのは変わらない
> まぁ危機感なきゃそんなもんでしょうねぇ…昔から大雑把だから
へぇ～特定のシステムにしか通じない知識を持つことが危機感に対応する方法なのか?
尾も白い
#まあ、自分の言動を正当化したいという危機感から発言内容が正しくなる話題に限定しようとい気持ちはわかります。
で、H何とかはハードリアルタイムなの? どんなシステムなの? 金融取引で一般的なんだよね。特定の取引処理のシステム名ではなくて。
もしかして、複数の市場を相手にしているシステムの話なら限定的でないと言い切っているの?
Re: (スコア:0)
今の証券取引所はそういうシステムです。
取引システムにもHFTにも、ばりばりハードリアルタイムが使われています (arrowheadで2ms、NYSEで900μs、NASDAQで250μs(平均だと100μs程度))。
ネットワークレイテンシがあるので、証券会社は取引システムにあるコロケーションでHFTを動かします。
OSには主にrtパッチを当てたLinuxが使われます。
マジです。
遅ければ見せ玉も他人の注文への割り込みも全部他のHFTに持ってかれます。そういう世界です。
取引所は流動性高めるってんでHFTには好意的ですが、取引リスクが高くなるのはその通り。
どんどん人手のディーラーは解雇されて、プログラマーが雇われてます。
http://jp.techcrunch.com/archives/20110817red-hat-ceo-a [techcrunch.com]
Re: (スコア:0)