アーキテクチャとWAS、DB2の活躍
20数年前にもなります。
B2B大規模WebシステムのITアーキテクチャ設計を行い、お客様のビジネスに大きく貢献できたことを今でも誇らしく思っています。リードITアーキテクトとしてプロジェクトに参加しましたが、インフラ・アーキテクト、アプリケーション・アーキテクト、WAS、DB2、ネットワークのスペシャリストとのコラボレーションの総合力で設計できたと考えています。このシステムのITアーキテクチャの判断 (Architectural Decision)を、WAS、DB2の活用とともに紹介いたします。
非機能要件はとても厳しいものでした
このB2B Webシステムは 企業から金融機関への資金移動のオンライン窓口となるため、その要件、特に非機能要件（NFR）は厳しいものがありました。
1. 高セキュリティ資金移動の窓口のため、顧客データや取引データなど高いセキュリティが必須でした。
2. 高可用性 24時間365日の連続運転、部分障害でも３分以内の回復が必要でした。
3. 容易なスケーラビリティ サービスイン当初はパイロット企業との試験運用になりますが、その後は急激に多くの企業のB2B窓口となると予想されたため、長時間停止することなく処理能力の拡張が容易にできる必要がありました。
4. オンライン、バッチの共存 オンラインとしての応答性の良さと、大量のバッチ処理や検索処理という相容れない要件の同時実現が必要でした。
これらを達成するためのWASとDB2を活用したアーキテクチャ判断（設計）を解説します。
基本アーキテクチャ
基本のアーキテクチャ・スタイルは定番のWeb3層アーキテクチャとしました。しかし、1. セキュリティ強化のため、先頭のWAS EdgeサーバとWASアプリケーション・サーバの間に独立したシングル・サイン・オン専用のサーバを設けました。お客様はここで一度厳密に認証・認可されれば、その権限にしたがって資金移動だけでなくメール・サーバや他のサービスにもシームレスにアクセスできます。そのため物理4層のアーキテクチャとし、かつ、各段で物理的にクラスタリングを構成し、どの層でも必要に応じて増強できるようにしました。これは、2. 高可用性、および3. 容易なスケーラビリティの要件を実現させるための判断です。
クラスタリング構成の欠点
しかし、ここで問題が生じました。クラスタリング構成の欠点はDBサーバがボトルネックになりやすいことにあります。とくに「集計カウンター」などロックが必要でリソースが限られているデータベースでは、クラスタリングで処理能力が高まるほど、ボトルネックとなります。アーキテクトとスペシャリストの協同検討の結果、データ・ストア・サーバ内のDB2インスタンスとデータベースをシェアード・ナッシングとするアーキテクチャ判断を行いました。シェアード・ナッシングとは、あるデータ・ストア・サーバ内のDB2インスタンスはお客様識別番号の「ある範囲のグループ」のデータベース（物理ディスク）だけを担当し、データ・ストア・サーバ同士はデータベース（物理ディスク）を共有（シェア）しない方式です。したがって、クラスター・サーバを増設してもボトルネックは発生しません。
シェアード・ナッシングの3つの欠点
しかし、シェアード・ナッシングには大きな欠点が３つあります。
１つ目は、WAS Edgeサーバでの負荷分散を、製品の設定だけで済むIPアドレスなどではできなくなったことです。これは、お客様から送られてくるメッセージ内のお客様識別番号を読み取ることで振り分ける設計としました。
２つ目は、データ・ストア層のクラスター・サーバを増設したときに、お客様識別番号によるグループ分けをやり直し、データベースを再編成しなければならないことです。これは再編成のために長時間の停止が必要で、リスクもあります。工夫としてデータベースのグループ分けとDB2インスタンスのペアをあらかじめ多く設定し、サービスイン当初は１データ・ストア・サーバに複数のDB2インスタンスを搭載し、クラスター・サーバ増設時にはDB2インスタンスの引っ越しだけで済むように設計しました。
３つ目は、データ・ストア・サーバの障害で、そのサーバが担当しているお客様グループの処理が停止してしまうことです。これを回避するため、AIXの拡張スケーラブル機能(HACMP CRM)を検討し採用しました。これは、データ・ストア・サーバの障害を検知したとき、あらかじめ決めておいた他のデータ・ストア・サーバが自動で瞬時にデータベースやネットワークを肩代わりする機能です。
オンラインとバッチの共存
最後に4. オンラインとしての応答性の良さと、大量のバッチ処理という相容れない要件の同時実現として二つのアーキテクチャ判断をおこないました。
一つ目は、開発言語です。WASアプリケーション・サーバの処理は要求が変化しやすいためJavaを選択しましたが、当時Javaの実行には多くのCPUリソースが必要でした。したがってデータ・ストア・サーバで稼働する大量の重たいバッチ処理には向かないと判断し、動作が軽いCで構築すると判断しました。
二つ目は、とくに負荷のかかる汎用検索などがオンラインへの応答時間へ影響することを避けるため、ディスク制御装置の機能であるフラッシュコピー（物理ディスク内のデータの位置情報を瞬時にコピー先へコピーし、元データの更新を許しながら徐々に物理コピーしていく）を採用し、オンラインデータベースを汎用検索専用のデータベースへコピーするアーキテクチャ判断をおこないました。
検証はおおごと
これらのアーキテクチャ判断は机上ではうまく稼働しそうでした。しかし、実機で実現するにはWAS、DB2、AIX、HW、ネットワークの絶妙なコラボレーションが必要です。アーキテクトとWAS、DB2、AIX、HW、ネットワークの各スペシャリストとの協業による綿密な検討と、厳密な構成要素障害影響分析（CFIA : Component Fairer Impact Analysis）を机上で行い、実負荷テスト、実障害テストを徹底的に実施したため、かなりのワークロード増となりました。
良いアーキテクチャと良いミドルウェアは息が長い
筆者はIBM退職後、中堅システム・インテグレーター様数社の若手に年数回「ITアーキテクチャ入門」を講義しています。その講義で参照ITアーキテクチャをいくつか紹介していますが、大規模な事例はなかなか世の中に開示していただけません。しかしサービスイン後しばらく経って、プロジェクトメンバーだったDB2スペシャリストの方による、このシステムの事例論文が日本IBM 技術誌 ProVision で一般公開されました。手前味噌ながらITアーキテクチャの良い事例として「ITアーキテクチャ入門」で紹介しています。
先年、その講義の終了後、参加したひとりの若手技術者から「自分は今、そのシステムの保守と機能拡張にたずさわっています。20年経っているそうですが、基本のITアーキテクチャやミドルウェアは変わっていません。講義中で説明のあった「良いアーキテクチャと良いミドルウェアは息が長い」というのは本当ですね。」と教えてくれました。ハードウェアやWAS、DB2の版はもちろん大きく変わったと思いますが、良いアーキテクチャは技術進化やビジネス変化に強いといわれています。そして、ミドルウェアとしてのWAS、DB2は技術面で大きく進化しつつも、今もそのITアーキテクチャを支え続けてくれているのに感動しました。
良いお客様と、良いチームメンバーと、そして良いミドルウェアに巡り合えたと感謝しています。
以上