IBM SE 奮闘記：クレジットカード基幹業務無停止を目指して

記事をシェアする:

2018年のある日、日本の大手クレジットカードの基幹業務を1996年から20年以上の間担ってきたメインフレーム・サーバー上のシステムが、新しい IBM Zにその役目を引き継ぎ、そっと火を落としました。
その日までのシステム連続稼働日数は4,106日。前回のシステム停止の日から、11年と3ヶ月もの間、「決済を止めない」の一念のもと、日本の金融や小売業などのユーザー企業、そして何よりも大事なエンド・ユーザーである日本の消費者を守るため、システムを一度も止めずに運用・保守を続けてきました。
物理的・論理的に二重化する設計や、休日に実施する切り替え処理での工夫、システムを長年使うための新技術の導入など、時代に合わせてさまざまな知恵を活かしてきました。その思想は、引き継いだ新しいシステムにも継承されています。
連続稼働・無事故は、IBMのメインフレームをお使いのお客様では珍しくないことですが、業務を本気で無停止にしてきた IBM Zの機能と、お客様を含めた我々チームの汗と涙と努力と根性の歴史の一部をご紹介したいと思います。

 

自己紹介

1992年、日本IBMに入社。このシステムを担当した1994年ごろは体力だけが取り柄のSEでした。
SEの先輩方、担当するお客様、協力会社の方々は、銀行の第3次オンライン・システム導入などの修羅場を乗り越え、アセンブラーをかき、ダンプを読み、マイクロ・コードを開発するなどなど、すごいスキルを持った方ばかり。何もかもわからないことだらけで、泣きたいくらいでした。
IBM Z担当でお客様担当SEという役割の女性は当時はまだ少なかったと思います。先輩方は、その新人女子をどう扱ったら良いのかわからなかったようでした。
それからずっと同じお客様を担当し、しかもブログを書くことになるとは・・・ここまで育ててくださり、こんなにも長く付き合ってくださった皆様のおかげです。
このブログでは IBM Zの機能を活用し、長年、保守時も一切業務停止することなく連続稼働し続けたクレジットカードのシステムについてご紹介しようと思います。

 

業務無停止を目指すクレジットカードの基幹業務を担うシステム

今回ご紹介するクレジットカードの基幹システムは、以下のような重要な業務を担っていました。
会員管理、売上計上、会員への請求、加盟店・決済代行会社・国際ブランドとの精算、提携先との精算、入金、債権管理、お金にまつわる業務のほとんどです。
システム構築当初は、売上業務の中でも24時間停止が許されないオーソリゼーション業務（カードを利用したときに、短い時間でカードが使えるか小さな箱にカードを通してチェックする、あれです。）も担っていました。
また、コールセンターのオペレーターさんへ問い合わせをすると24時間回答が得られると思います。例えばカードを無くしました、あといくら使えますか、などです。オペレーターがお客様と応対するためにアクセスしていたシステムも含まれていました。私は主にハードウエア、ソフトウエアなどのインフラを担当するSEでした。

今回ご紹介するシステムの設計目標は次の通りでした。
1) 24時間x365日 業務稼働
クレジットカードは使えない時間帯は基本的にありません。常に業務稼働できることを目指しました。

2)自動化を推進し、人的ミスを減らす
連続稼働を推進するため、ミスによる業務停止に対しても対応をしようとしました。

3)開発ツールの活用により、アプリケーション開発の効率化・影響調査の効率化を進める
プログラム修正による障害、デグレ（過去に修正したバグが元に戻ってしまうなどの事象）など、想定される不具合発生を防ぐためのツールや仕組みを活用しました。

 

連続稼働を目指したシステムのアーキテクチャー、特徴

1)　2セットのシステムとデータベース、DBの同期
このシステムが目指す連続稼働は、障害時の対応だけではなく、計画停止においても業務を止めないという連続稼働でした。そのため、様々なコンポーネントが二重化されています。

• ハードウエア
  CPU筐体は3筐体、ディスクも複数筐体で耐障害性を高めました。
• LPAR（システムの論理区画の分割）
  対外系システムと業務系システムで論理区画を別区画としました。対外系システムはAct-Stby、業務系はAct-Actの構成です。
• ソフトウエア
  トランザクションを処理する際のミドルウェアであるCICS（Customer Information Control System）はマルチ・リージョン構成とし、1リージョンが障害になった場合も別リージョンで処理できる構成としました。また、更新系と照会系のトランザクションを処理するリージョンを分けるなど工夫をしています。
  データを管理するIMS（Information Management System）は、ソフトウエア二重化構成(Multi Area Data Set:MADS)を選択し、ディスク障害への対応ができる構成としました。

24時間連続稼働を目指す場合、データベースを複数持ち、同期を保つことが必須となります。
アプリケーションの変更に伴うデータベース（DB）の保守、データベース・マネージメント・システム（DBMS:IMSやDb2のこと）の保守に伴うDBの停止はどうしても定期的に発生するためです。
アプリケーションやDBの保守時も切り替え時も業務を止めないため、24時間オンライン処理を担うためのミニDBと、フルセットDBを同じ構造で持ち、同じプログラムがどちらのDBをアクセスしても処理ができるようにしました。
オンライン処理は、通常ミニ会員DBで処理していますが、対外系システムの保守時は、フルセットDBが稼働するシステムで処理されます。
24時間処理を継続したい業務は、この対外系システムとミニDBで稼働させます。
切り替え処理を行うため、DBの同期を行いますが、基本的にはディレード整合処理（データベースの整合処理）というバッチ的な仕組みで同期をとります。ただし、金額に関連するような常に同期を取る必要がある情報は、トランザクションをラウトさせて同期を取るなど工夫をしています。

2)　切り替えの仕組み
2セットのDBと二つの系統のシステムを持っていますが、この二つの間をトランザクションを一つもロスせずに切り替える仕組みを構築しました。「休日代行切り替え（休代切替）」という仕組みです。
オンライン処理は通常対外系で処理されます。業務系への切り替え時、対外系の閉局前に業務系を開局します。オンライン区画での処理が完了したら、オンライン側を閉局するので、一時的に同時に両側のシステムでトランザクションが実行される状態となります。
これにより、1件のロストもなく切り替え・切り戻しが可能なシステムとしています。
ディレード整合については、切り替え・切り戻しの都度実施します。

3)　自動化
システムの切り替えなどの運用は、メッセージ・トリガーでコマンドを発行するように自動化を推進していきました。人が介在することによる遅延、ミスを極力排除し、障害時にも業務停止時間を最小限にするためです。
製品のバージョン・アップによるメッセージの変更についてはアセットも活用し、抜け漏れのないよう対応を継続していきました。
どうしても本番を運用する中で、漏れていた観点に気づくことがありましたが、都度対応することにより安定化が進んだと思っています。

 

サービス・インからの、安定化に向けた取り組み

アプリケーションを全面的に新規構築しましたので、サービス・イン直後は“それなり”に障害が発生していましたが、システム面ではシステム資源不足による不安定性が大きな課題でした。また、24時間365日の業務稼働を目指すための障害対応の仕組み、システム切り替えの仕組みについて、運用テストが十分ではなかったかもしれません。障害が発生～切り替え失敗、という辛い時期が続きました。

(1)：テイクオーバーの時間短縮のための工夫と、その自動化を推進
製品としての切り替えはすぐに完了するのですが、業務開始できる状態になるまでに時間がかかりました。切り替え後DBをOpenしながらトランザクション処理を行うと、CICSのトランザクション処理に時間がかかるため、タスク・フルになってしまう。そのため、トランザクションを入れる前にDBをプレ・オープンしておくことなど、工夫を重ね、目標の 5 分以内の切り替えを目指しました。

当時のファイルはフロッピー・ディスケットに保管されたDOS文書でしたが、現存しておらず、その他の様々な工夫を示すものは残念ながら残っていません。

(2)：リハーサルがシステム変更時の必須テスト
バージョン・アップを含む比較的大きなシステム変更後は、テイクオーバーのリハーサルを必ず行うことにしました。これにより例え障害が発生したとしても所定の時間内に切り替えが完了することを担保しました。

(3)：システム資源の増強
予算との兼ね合いもありましたが、更改の都度必要な資源を拡充していき、安定稼働に必要なメモリーなどの資源を確保しました。ただ、テクノロジーの進歩により、メモリーのコスト・パフォーマンスも高くなるにつれ、予算との兼ね合いの課題は自然に解消されていきました。

(4)：毎年お札（おふだ）の交換と、センターの目の前の神社への初詣
できることは全てやりましたから、あとは神頼みです。行かなかったからトラブった、ということになるのが怖くて、毎年お客様と一緒に初詣を続けました。ご利益はあったと思っています。

安定稼働の基礎が出来上がってくると、TKOの不安も、休日代行切り替えの不安も、ほぼなくなりました。その後は様々なシステム変更を業務無停止で実施することを追求するようになりました。

 

IBM Zのテクノロジーを活用した業務無停止での更改・変更

システムの保守、ソフトウエアのバージョン・アップ、CPUなど機器の更改時もローリング・メンテナンスと、休日代行切り替えの仕組みを活用し、業務を停止することなく更改を行ってきました。

CPUのMES（Miscellaneous Equipment Specifications、機械仕様変更 = モデル変更やシステム能力の増減作業）は、休日代行切り替えを活用しながら、停止可能なハードウエアから順にMESしていきました。

その他、以下にいくつかの例を示します。

(1)：VTS（IBM TotalStorage仮想テープ・サーバー）無停止でのフロア間移動・移設
VTSは、Peer to Peer構成を導入していたので、フロア間の移設を行う際、片方の系を停止し移設。移設後にフロア間で同期を取り、その後、残ったもう一方の系を移設しました。
このシステムでは、HSM（階層型データストレージ管理：Hierarchical Storage Management）を使用し、DISKのデータをマイグレーション・リコールしながらバッチ処理を行いました。テープ装置の停止はバッチ業務の停止につながるため、このような方式をとりました。

(2)：DISK業務無停止での更改
DISK更改時は、HSMの機能をフル活用し、業務稼働中にデータを移動しました。SMSボリューム内のデータ・セットを移動するコマンドを活用しました（migration vol convertコマンドなど)。どうしてもシステム停止時にしか移動できないボリュームを、休日代行切り替えで停止している際に移動すれば、停止時のデータ移動が最小限で済むからです。
DISK容量は、更改の都度大きくなっていくため、稼働中に安全にデータを移動することは今後も必要になっていくと思います。

(3)：Sysplex timerの業務無停止での更改
Sysplex構成を組むために、以前はSysplex timerという外付けの時計が必要でした。そのハードウエア更改において、Redbookに無停止での切り替え手順があったため、私たちSEはそれにチャレンジしました。
ただし、お客様環境でテストすることは不可能。失敗とはすなわち全システムの停止につながるため、幕張にある環境でテストを行いました。後輩と私と、手順どおり、手順どおり、、、と、進めていると、「あれ？落ちてない？」「うわー怖い！テストしてよかった～。」　そう、手順を間違えました。本当に怖かったですが、テストしに行ってよかったです。お客様環境においては、無事無停止での機器更改を行うことができました。

 

新たなテクノロジーを取り入れていくことの重要性

せっかく開発したシステムですから、長く、システムを有効に活用するために、連続稼働だけでなく、新しいテクノロジーを取り込むことは継続していました。

(1)：Windows端末+WASで、画面をWEB化
開発当初の構成では、ホスト側にCICSのアプリケーションがあり、クライアント側にも端末プログラムがある、という構成でした。OS/2が前提の開発ツールを活用していたため、OS/2端末をもち、ホストから端末にプログラム配布、ホスト・プログラムとの同時リリース、という運用をしていました。

OS/2って何？と思われる方もいらっしゃるのではないでしょうか。IBMが開発した当時先進的な完全マルチ・タスクの端末用のOSです。
ただ、それ以降次第にWindowsが中心になっていきました。PC調達コストも高くなり、端末プログラム配布もやや手間になってきたため、そこでWEB化を行いました。端末プログラムは持たせず、端末サーバー側で画面を作り、ブラウザーで表示させる方式に変更しました。

(2)：MQ接続の追加
実際のエピソードを昔話風に。昔々、あるところに和尚さん(注参照)がいらっしゃいました。和尚さんは、CICSに精通された方だったのですが、ある時から急に、我々社員にも、お客様にも、「これからの時代はMQダヨ！」と、おっしゃるのです。
気づいたらお客様も、「MQで設計しろ」とおっしゃるようになりました。
そこで受け付けしておける、お互いのシステムが稼働した時に受け取れるという非同期であることが有利である業務において、MQを活用し始めました。
その他、レスポンス・タイムの要求が厳しいトランザクションから、MQ経由で不正検知パッケージにメッセージを派生させる処理でもMQを導入しました。
MQはその後、和尚さんの予言通り、多くのシステムがメッセージ連携に活用するようになったため、外部システムとの接続に重宝するインターフェースになりました。
注：和尚さん：大先輩の大変有名な、弊社内のみならずお客様からも大変信頼されていらっしゃる技術者です。

(3)：TCPIP/VIPA/Socket接続の追加
SNAをご存知でしょうか？“スナ”と呼んでいます。当時、ネットワークと言えば SNAだったのですが、時代はTCP/IPスタンダードになっていきました。そこで、ホストにもTCP/IPで接続できるように設定を追加していきました。
接続するシステムとはSocket接続、仮想IPアドレス（VIPA）でIPを切り替えて、などということも、OSのアップグレードにより可能になりました。

(4)：IMS-Db2のレプリケーションで、パッケージ・ベースの与信システムを構築
与信を行うシステムをパッケージ・ベースで行うことになりましたが、前提がDb2だったこともあり、基幹システムのIMSを直接アクセスはできませんでした。そこで、IMSからDb2にレプリケーションし、それを審査する仕組みを追加しました。
Sysplexに2区画を追加し、別システムではあるが、同一Sysplexという環境にして運用しました。

(5)：HW/マイクロ・コードのUpgrade
– FICON（Fibre Connection）化
DASDのレスポンス・タイムは、それまで2桁msだったものが、1桁以下になりました。特にバッチは非常に早くなりました。翌朝ではなく当日の夜中にバッチが終わっている、という日もあり、オンライン開始を心配することはほぼ皆無となりました。
RMFのレポートや、OPCでジョブの進行を見て、みんなで喜び合った記憶があります。
– GRS STAR化
データ・セットのENQの都度、GRS/XCFでその情報をSysplex内で一周させるRINGの構成がSTARになった途端、その処理に必要な時間は激減しました。STAR化でもオンライン、バッチが、とてつもなく早くなりました。

オンライン・トランザクションは、レスポンス・タイムが非常に改善され、CICSのレポートをご覧になったお客様担当の方の大喜びされた顔は忘れられません。

 

補足のエピソード

ー監査法人からの指摘対応
次世代システムは10年、15年活用するシステムなのである、と説明をしたところ、x86系の基盤ではプログラムの書き換えを伴うハードウエア・ソフトウエア更改が一般的なためか、「10年以上使えるシステムなんてあるはずがない。」と、監査法人から指摘が入ったとお聞きしました。
それに対するカウンター・クレームとして、このクレジットカード会社のシステム事例をお客様が語り、10年、15年継続利用できるということを証明されました。ハードウエアの更改、ソフトウエアの更改を継続していくが、アプリケーションは変更せずに活用できていること、これが現実に今持っているシステムで実現できていることを説明し、証明することができたそうです。
IBM Zでは当たり前で普通のことなのですけどね。

 

おわりに

(1)：IBM Zはよくできてる
無停止を目指すシステムにおいて、IBM Zの優位性ははかり知れません。今までの歴史の積み重ねでよく考えられて設計されています。ハードウエア・ソフトウエア共にIBMという会社の優秀な技術者が設計しているためだと信じています。
障害が発生したら、障害を切り離し、生きているシステムを救う思想、システム更改や変更においても、止めずに反映する機能が増えています。基本的にはローリング・メンテナンスの仕組みで対応し、製品も止めずにパラメーターを変更することができるようになってきています。止めなくて済む機能があります。
さらに、テクノロジーのアップグレードがあっても、過去のアプリケーション資産は（基本的には）動くよう設計されています。新しい機能、パフォーマンス向上といった機能を取り入れても、アプリケーション開発をやり直す必要はないのです。

(2)：IBM Zテクノロジーのアップデート、アップグレードはこれからも続いていく
ハードウエアもソフトウエアも、常にアップデートやアップグレードを続けていくと思います。
新たなトレンドを取り入れること、価格性能比を上げること、お客様の要望される機能を追加していくことは今後も続いていくでしょう。基幹システムにおいて、新たなものを取り入れていくのは勇気がいることですが、私は今後も積極的に新しい機能をお客様にご提案したいし、お客様のシステムに取り入れることで、長くシステムを安定稼働させながらお使いいただきたいと思っています。

(3)：お客様と保守を担当した歴代メンバーと一体となって安定したシステムを維持する
それはこのブログだけでは語りきれない保守の歴史でした。お客様、カトさん、、、、本当に色々ご迷惑おかけしました。最後までサポートしてくれたSEのみなさん、ハードウエア・サポートのみなさん、そして協力会社のSさん、Dさん、お疲れさまでした。Kさんにもご負担おかけしました。本当に、名前をあげていったらきりないですね。
多くのお客様、システム担当の皆様の努力のおかげで、安定稼働ができました。

そして、先日、長年担当させていただいてきたこのシステムは、新しい IBM Zシステムにその役目を引き継ぎました。業務稼働時間は、連続4106日を達成いたしました。写真は最後の連続無事故記録の張り紙です。

ー次の歴史にむかって
さて、このシステムですが、新たなIBM Z基盤に新たにアプリケーションを構築し、移行を済ませました。そのシステムも今後長く活用していただくために、テクノロジーのアップデートは継続してご提案をしていくつもりです。
今、我々が興味のあることを少し記載するだけでも、いくつかのトピックがあります。

• CPU使用率改善のためのCOBOLのバージョンアップ
• REST/API接続の追加
• データ圧縮
• zIIP （IBM System z Integrated Information Processor ）へのオフロード
• Cloudへのデータ・バックアップ

IBM Z上に構築しているシステムは、基幹システムなど、不具合による停止が許されない、ミッション・クリティカルなシステムが多いと思います。それに対し変更を加えるということは障害のリスクもあるため、敬遠されがちです。ですが、せっかく構築したシステムを長期的に活用していくためにも、新しい機能の取り込み、新たなテクノロジーの活用・適用に常に挑戦していきたいと思っていますし、これを読んでいただいた皆さまにも、ぜひ挑戦していただきたいと思っております。
その結果として、安定した障害のないシステムと長く付き合える、長い目で見てコストの削減にも繋がるのではないかと思っております。システムの安定化のためにはこのまま触れないのが一番、ではなく、どんどんアップデートしていく。そうすることで、担当するメンバーはシステムの理解を深め、スキルも向上していきます。もしかすると、IBMの開発部門にご意見を言いたくなることが出てくるかもしれません。それも良いと思うのです。積極的に意見を言い、機能を追加してもらいましょう。そして欲しい機能が追加された IBM Zを中心に、長く安定的な良いシステムを活用できるようにしていきましょう。
ベテランとなった現在、あたまが追いつかないと思うこともあるのですけれど、私も勉強を続けてまいります！

---