パスワードを忘れた? アカウント作成
544003 journal

von_yosukeyanの日記: 相変わらず楽天証券が激重な件 5

日記 by von_yosukeyan

システム増強をやったはずなのに、激重じゃねぇかという話があるが、そりゃそうだろうよ、と

楽天証券のフロント系システムは、前にも書いたが一般的な電子商取引サイトで見られるような、Webサーバ層、アプリケーションサーバ層、データベースサーバ層の三層で構成されている。より細かくみていくと、APサーバ層ではWeb系のAPサーバ群と、専用クライアントであるMarketspeed用のAPサーバ群があり、DB層では顧客の財産管理を行う勘定系と受発注を行うブローキングロジックを処理する業務基幹DBと、WebやMS向けに市況やニュース群を配信する報道系DBの二つがある。極めて大量の動的なデータを処理する業務基幹DBは、HPQ製の大型ハイエンドサーバであるSuperdomeが、静的なデータを配信する報道系DBにはHPQ製のミッドエンジサーバであるrx8620を使用している

9月から12月にかけてのシステム増強は、まず耐障害性に問題があった業務基幹DBを、Supwerdome(PA-8900 64CPU構成)1台から、Superdome2台(Itanium2 32CPU)構成に変更し、またRDBMSをOracle RACに変更して、コールドスタンバイ構成からクラスタリング構成に変更したことだ。この変更で、従来障害が発生した場合に64CPUの正常系がダウンしても、32CPUの待機系しか用意されていない問題も解消されたし、クラスタリング動作しているために一方の系統がダウンしても自動的にもう一方が処理を引く継ぐことができる(しかし一方がダウンすれば32CPU2台で分散された処理が1台に集中するのでやはり従来のような問題は残る)。また、業務基幹DBを二分割して、2セットのRAC構成に分散することで負荷を分散させる対策も取られた

しかし、RAC構成は単純にサーバが増えた分処理能力が増えるわけではない。Oracle RACは非常に強力なクラスタリングシステムだが、ソフトウェアでクラスタリング処理を実現するために、ハードが2倍になっても実質的な性能は1.5倍程度にしかならない。つまり、2セット用意しても3倍程度にしか業務基幹DBの処理能力は上がらない。大した増強であるとはいえないのだ

#メインフレームのクラスタリングは、OSレベルでクラスタリングを行う強力なシステムで、ハードウェアが増えた分シームレスに処理能力が上がるし、異機種間でもクラスタ化が可能だ。しかし、メインフレームの場合にはシステム間結合装置と呼ばれる専用のメインフレームを使ってクラスタリング処理を行っているのでRACがダメだという話にはならない(単に楽天の見積もりが甘いだけだ)

もう一つのAPサーバ群の増強にしても、従来のエントリーモデルのサーバの台数を増やしただけで、ハードウェアをより上位のシステムに変更するといった増強策ではない。システム構成は異なるが、他社のAPサーバでは最低でも4CPU、普通でも8CPUのミッドエンジモデルのサーバを採用しているので、楽天の2CPUクラスのエントリーモデルのシステムをいくら増やしても取引の急増に対処できない

つまり、最近のシステム増強は単純にハードウェア的にシステム能力を上げただけで、アーキテクチャを抜本的に見直すといった増強策ではない。業務基幹DBにしても、アカウントを二分割したといっても増強した2セット目のシステムは将来の口座数の増加に合わせて追加されたシステムであって、負荷が均等に分割されたわけではないのだ。しかも、楽天の業務基幹系のデータ処理は、1台のシステムに集中しすぎている。他社では、例えばkabu.comの場合には勘定系と認証・情報系、受発注管理系がそれぞれ分割されているし、負荷の高い勘定系はさらに参照系と更新系に分割されていて、夜間バッチ処理なしに24時間稼動が可能だ(ハード的には128CPU構成のSuperdomeと32CPU構成のES7000をパテーションを切ってクラスタ構成)。イートレードの場合には、顧客収容数50万程度のシステムを30万程度の客ごとに別のセットのシステム群に3分割して分散しているし、そもそも1つのシステムで処理する必要のない投信や、外国株系統のシステムは国内株とは全く別のシステムで処理されている。楽天は、DLJ時代にWebを前提として開発されたシステムで、国内株から外国株、カバード、投信などを1つのシステムで処理しているのに、バッチ処理によるオンライン中断が入る。アーキテクチャ的に限界というよりも、実態に全く似合っていないシステムだ

こういった観点以外に、受発注遅延の原因になっているのが、業務基幹DBの処理集中以外にも、基幹DBからの受発注を執行する対外系システムの処理限界だ。これは、ハードウェア増強と、接続チャンネル数の増強で東証系に関しては遅延が減りつつあるが、大証/ヘラクレスやJASDAQ、他市場向けのシステムは2月まで増強が行われない予定なので、遅延は依然として深刻なままだ。大証やJASDAQのシステム処理限界も遅延に影響していることは確かだが、大きなボトルネックはやはり楽天側にある

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2006年01月12日 1時58分 (#863257)
    APサーバについては、同じ台数で一台あたりのCPU数をN倍に増強するよりは、
    一台あたりのCPU数は同じで、台数をN倍にした方がより高速になるというのが
    一般的な答ではないでしょうか? もちろん、実メモリ不足のような状況に
    陥ってないということが前提ですが…
    ですから、

    > 楽天の2CPUクラスのエントリーモデルのシステムをいくら増やしても取引の
    > 急増に対処できない

    という部分は納得がいかないのですが…
    私が何か勘違いしている点があるでしょうか?
    • 確かに、1台辺りのCPU数をN倍にするのと、台数をN倍にするのは同じです

      しかし、大量のクライアントからの要求を処理するシステムだと、大量にメモリーを搭載したAPサーバのメモリ上にservantをすべて展開するとか、大量のCPUを積んだAPサーバにマルチスレッドでservantが稼動してメソッドを個別に呼び出すとか無茶な仕様になっていて、実装方法が不適切なままスケールアウトすると、性能がかなり落ちることは珍しくないと思います

      それに、ローエンドサーバと、ミッドエンジサーバのメモリ性能やバス調停性能の差はかなり大きいと思います。N個CPU=N台には必ずしもならないと思ったりするんですが、いかがでしょう?
      親コメント
      • by Anonymous Coward
        > しかし、大量のクライアントからの要求を処理するシステムだと、大量
        > にメモリーを搭載したAPサーバのメモリ上にservantをすべて展開する
        > とか、

        物理メモリから溢れないというのは大前提です。
        このため、CPUの少ない構成であっても、必要なだけのメモリは積む
        必要があります。スケールアウトした場合の方が、システム全体を
        トータルした必要メモリ容量は大きくなるのが普通だと思います。
        逆に、そうやって、物理メモリから溢れないだけの容量を確保すれば、
        特に問題はないはずです。

        > 大量のCPUを積んだAPサーバにマルチスレッドで servantが稼動してメ
        > ソッドを個
        • >アプリケーションデータ更新に伴う排他処理は、同一APサーバ上のスレッド間で行なうのではなく、DBサーバのトランザクションに任せることになるため、スレッドを同一APサーバ上に置いても、スケールアウトして異なるAPサーバに置いても、性能上の違いは出ない筈では

          一応それは踏まえた上で書いてます

          DLJ時代に構築されたシステムは、Web、Marketspeed(TCP/UDP)、コールセンター系(CTI)、imode系Webのトランザクションを一元的に処理するために、ミッドエンジクラスのサーバを前提にCORBAでシステムが構築されています。買収後の04年から05年にかけて、このシステムをスケールアウトしてエントリーモデルのサーバに置き換えていますが、この更新時の実装方法が不適切だったのではないのかというのが趣旨です
          親コメント
          • by Anonymous Coward
            > ミッドエンジクラスのサーバを前提にCORBAでシステムが構築されています。

            CORBAを使う場合も、トランザクション処理はバックエンドのデータベース
            サーバ側に分離するので、フロントエンドにあるアプリケーションサーバ
            に関しては容易にスケールアウト可能になる… というのが典型的な構成
            ではないかと思うのですが、そうではなく、アプリケーションサーバを
            動かすフロントエンドのマシンでも、データベースの一部を持っていると
            いうことでしょうか? アプリケーションサーバとデータベースサーバは
            別プロセスですから、サーバ構成を変更する場合には、データベースだけ、
            バックエンドの強力なマシンに移動することは容易だと思うのですが…
            典型的ではない構成をとっている場合には、その旨、書き添えておかない
            と、私のように疑問に感じる人が出てくるように思います。
typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

読み込み中...