大量トランザクション処理に適したアーキテクチャ：こんな時にはこのITアーキテクチャ （2）

図1 クラスタリング

　通常のトランザクション処理では、アプリケーション・サーバにDBサーバの数倍の負荷が掛かる。そこで、アプリケーション・サーバは台数を増やして処理性能を確保する一方で、DBサーバには性能の良いマシンを充てることにすればよい。

　だが、この構成ではDBサーバが1台のためスケーラビリティに限界がある。最高性能のマルチプロセッサのマシンを用いてもDB処理能力の限界に達しそうな場合、区分化などのテクニックによりDBを分割し、さらに並列化したDBサーバで処理を行うようにするとよい（図2）。

図2 並列化したDBサーバで処理 （クリックすれば拡大）

　図2の方式は、トランザクションの使用するDBの区分に偏りが生じなければうまくいく。しかし、例えば、チケット販売のシステムで、人気スポーツのチケット発売日に注文が殺到するといったケースでは、特定の試合に人気が集中し、その試合の空席等を保持するDBの単一区分にアクセスが集中してしまい、DBの並列化が生かされないかもしれない。

　このような事態に対処するためには、発売枠を分割して別のDB区分に格納し申込者の電話番号の末尾で振り分けるといった工夫が有効である。また、前回紹介したようなDBの内容をメモリにキャッシュし処理を高速化するテクニックも使用できる。図3に、これまで述べたすべての工夫を盛り込んだ「究極」のクラスタリング・システムのイメージを示す。

図3 「究極」のクラスタリング・システムのイメージ （クリックすれば拡大）

　ここまでやれば、「無敵」の性能が得られるかもしれないが、図1から図3まで進化するに従って、システム構築費用はどんどん増えていく。証券取引のように、日々、大量のトランザクション処理が繰り返される場合では、システムに投資する意義もあるだろうが、数年に1回しかピークを迎えないようなチケットの販売システムでは投資を正当化できないかもしれない。

　こんな場合には、「大量トランザクション処理」からは外れるが、トランザクションのピークを減らすように、販売の仕方を変える方がよいだろう。発売時間を決めて先着順にチケットを売りに出すのではなく、申込期間を決めて期間中は申し込みを受け付けるだけにし、抽選で発売する。このようにすれば、先着順でないので発売と同時に高いピークが来ることは避けられるし、申し込みを受け付けるだけであれば、複数のDB区画に適宜振り分けて書き込めばよいので、単一DB区画への負荷集中を回避することができる。

アプリケーション・ロジックが重い場合

　さて、これまでは1件ごとのトランザクション処理負荷はあまり高くない ケースを取り上げてきたが、1件の処理が重い場合、どのような仕組みが必要だろうか。

　大量のデータの中から条件に該当するデータを探して集計するような場合は、ここでもDBの並列化が有効である。DBMSの製品によっては、アプリケーションが1つのSQLの照会を出すと、内部的に複数の照会に分けて並列処理をするものがある。並列処理は、マルチプロセッサの単一サーバの環境でも有効だが、DBサーバを並列化した環境では、より有効に機能する。

　アプリケーション・ロジックが重い場合には、アプリケーション分割して並列に実行するという手もあるが、同期的に複数のアプリケーションを実行させると、実行制御が複雑になってしまう。アプリケーションが重い場合には、非同期処理を採用して、例えばWeb画面では受け付けだけを行い、処理が終わった時点で結果をメールでユーザーに通知するような仕組みを採用した方がよいだろう。この方法では、処理負荷が平準化されることもメリットである（図4）。

図4 処理が終わった時点で結果をメールでユーザーに通知するような仕組みの採用 （クリックすれば拡大）

ピーク性が強い業務システムでのトランザクション処理

　さて、これまで、システム構成は一定のものとして、大量トランザクション処理を考えてきたが、ピーク性の高いアプリケーションの場合、仮想化技術を用いて、システム構成を変化させることも考慮したい。1台のマシンを論理的に分割することができるシステムでは、本番機と開発機でCPUを共用し、ピーク時にCPUパワーを開発機から本番機に回すことができる。また、複数台のWebアプリケーション・サーバを仮想化してプーリングし、実行のために割り当てる台数を増減させるような仕組みも現れている。

　構成を動的に変化させるシステムでは、資源が足りなくなってから増強しようとしても、割り当てに時間がかかって間に合わない可能性がある。事前にスケジュール・ベースで構成を変化させるとか、資源の増加を予測（うまくいけばの話だが）するといった仕組みも必要だろう。

　図4のような非同期実行の仕組みでは、処理の受け付けと実行が別なので、受け付け量が増えた時点で、処理のための資源の割り当てを増やしても間に合いそうだ。この意味でも、大量トランザクション処理には非同期処理が適しているといえる。