連載
» 2006年11月17日 12時00分 UPDATE

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

大量トランザクションを処理するためには、アプリケーション・サーバを複数台並べて負荷分散する一方で、マルチプロセッサのDBサーバを採用しDB処理能力を確保するアーキテクチャが用いられることが多い。さらに高い処理能力が求められる場合には、DBの並列処理やオン・メモリ処理を併用するデザインもあるが、重要なことはスケーラビリティを確保するアーキテクチャ設計と、負荷を平準化する工夫である。

[河野紀昭,日本IBM ICP-エクゼクティブI/Tアーキテクト]

クラスタリングによるトランザクション処理のいろいろ

 インターネット・ショッピングやオンライン証券などのWebサイトでは、ピーク時には大量のトランザクションを処理できるように設計する必要がある。

 大量トランザクションを処理するために一般的に用いられる設計がクラスタリングである。Webアプリケーション・サーバを複数台並べておき、トランザクションを振り分けて処理すればよい(図1)。

ALT 図1 クラスタリング

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

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

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

勘所:クラスタリングと並列化でスケーラビリティを確保しよう



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

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

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

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

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

勘所:ピークを平準化する方法を考えよう



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

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

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

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

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

勘所:重いアプリケーションでは、非同期処理を考慮しよう



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

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

勘所:ピーク性の強い業務ではシステムの仮想化を検討しよう



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

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

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ