IBM i 顧客サポートの事例紹介、ケース1 － オブジェクト権限の検査とバッチ ジョブのパフォーマンス
バッチ処理は、ほとんどのタイプの業務処理でいつも繰り返し行われています。時折、顧客は、時間が掛かり過ぎるバッチ実行に対応が必要になることがありますが、実行時間に影響を与える要因には様々なものがあります。IBM i におけるそのような要因の1つは、ユーザー プロファイルのオブジェクト権限のアクセス権を、バッチ ジョブによってアクセスされるライブラリーおよびオブジェクトに割り当てているやり方にあるようです。ここでは、以下のケース スタディを通して、この要因の重要性について見て行こうと思います。
何年も前のことですが、ある顧客から、バッチ実行の時間が長く掛かり過ぎる原因を調べてほしいと依頼がありました。その顧客は、毎晩、CPUコアが7個のPower7サーバーで、バッチ処理で25件の並列バッチ ジョブを実行しているそうで、プロセス全体の完了に約8時間掛かっているということでした。顧客は実行時間を大幅に短縮できないかと考え、私が属する地域のIBMソフトウェア サービス チームに相談が寄せられました。
サービス チームの同僚が、必要なすべてのパフォーマンス データを収集し、グローバルIBM i サポート チームにデータを送りました。グローバル サポート チームの話では、Power7サーバー ハードウェアおよびオペレーティング システムのパフォーマンス要因については、すべて問題なさそうということでしたが（つまり、キャパシティーを超えて利用されているわけではない）、ただ、「オブジェクト権限の検査」のオーバーヘッドが非常に多いとのことでした（このパフォーマンス データは、IBM i パフォーマンス データベース テーブルQAPMSYSTEMで確認できます。詳細は、 https://www.ibm.com/docs/en/i/7.1?topic=data-collection-services-files-qapmsystem を参照してください）。その時点では、このオーバーヘッドを減らすにはどうすればよいか誰も分からず、問題の解決に私も駆り出されることになりました。
私はパフォーマンス報告書を作成し、最初にグローバル サポート チームから指摘があったように、サーバー ハードウェアは非常にパワーがあり、バッチ実行中も、ほとんどフル利用されていないことも確認しました。しかし、このようなオブジェクト権限の検査というオーバーヘッド要因と、権限検査のバッチ実行時間への影響という問題に出くわしたのは、この時が初めてでした。
幸い、IBMで働き始めた頃に、私は、「 AS/400 Security Concept and Planning （AS/400セキュリティの概念および計画）」と題するIBM i 顧客トレーニング クラスを何度か担当していたことから、以下に示す図のことをすぐに思い出しました。この図は、オブジェクトに対するジョブのユーザー プロファイルのオブジェクト アクセス権を解析する際に、IBM i が検査する順序を示したものです。明確なアクセス権を判定できると、検査は直ちに停止し、そのアクセスの方法（読み取り、更新、追加、削除、実行など）が許可または拒否されます。
この図は、IBM i が、最初にジョブを実行するユーザー プロファイルでオブジェクト アクセス権の割り当てが見つかるかどうかを判定することを示しています。まずは、そのユーザー プロファイルに*ALLOBJ特殊権限があるかどうかです。なければ次のステップへ進みます。そのユーザー プロファイルで（専用権限で、次いで権限リストで）明確なアクセス権の割り当てが見つからない（許可または拒否されない）場合、IBM i は、関連するグループ プロファイル（実際には別のユーザー プロファイル オブジェクト）の検査、次いで、アクセスされるオブジェクトの共通権限の検査、最後に借用ユーザー プロファイルでの検査（「借用権限」が使用されている場合のみ）へと進みます。IBM i がこの図の中で下へ進まなければならなくなればなるほど、この処理のオーバーヘッドは多くなります。
ジョブがオブジェクトに1度だけアクセスする場合は、明確なアクセス権を解析するために検査パス全体を辿ることになったとしても、CPUサイクルの浪費にはなりません。たとえば、別のユーザー プロファイルの権限を借用するプログラムを実行して、1つの物理ファイルから1つのレコードを読み出すだけの場合、IBM i は上の検査パスの図の一番下近くまで進みますが、これは1度だけであるため、オーバーヘッドを心配する必要はありません。しかし、一般的なビジネス データベース処理環境では、多数のジョブが並行して実行されるのは普通であり、それぞれのジョブが数多くの物理ファイルからのデータ レコードにアクセスし、繰り返しファイルを開き、読み書きして、そのファイルを閉じます。このプロセスにより、権限検査の一連の処理が何度も呼び出されるため、権限検査のオーバーヘッドは累積されることになります。このことは、この記事で紹介している顧客にも当てはまるものでした。
問題の25件のバッチ ジョブを実行するユーザー プロファイルに、コア アプリケーションのライブラリーおよびオブジェクトに対するオブジェクト アクセス権限がどのように割り当てられているのか顧客に尋ねてみました。すると、25件のジョブはすべて1つのユーザー プロファイルの下で実行され、アクセス権限は、グループ プロファイル（そのユーザー プロファイルが属しているグループ）経由で付与され、これは、適切なアクセス権が割り当てられた権限リストで指定されているということでした。上の検査パスの図を参照すれば、上側の2つの四角形（最初はユーザー プロファイル、次はグループ プロファイル）の中の項目を検査するのに7ステップ以上が必要であることが分かります。7ステップ以上というのは、ユーザーの1つ目のグループ プロファイル（ユーザー プロファイルは、最大16個のグループ プロファイルに割り当て可能）での検査でアクセス権が判定されない場合は、次のグループ プロファイルが検査されるからです（図中の2つ目の四角形に「ループ」を表す矢印があるのはそういう意味です）。その場合は、オブジェクト権限の検査プロセスでさらに多くのオーバーヘッドが生じることになります。
顧客に尋ねたところ、権限リスト内のグループ プロファイルを使用して、対話式ユーザー プロファイル向けにコア アプリケーションで実装されたものをエミュレートしているということでした。こうしたオブジェクト権限の検査のオーバーヘッドについては、顧客は意識していなかったようです。
現時点で、権限検査パスの図から見て取れることは、こうしたオーバーヘッドを減らすには、バッチ ジョブを実行するユーザー プロファイルに*ALLOBJ特殊権限を割り当てる（生じるオーバーヘッドは最少） か 、 あるいは 適切なアクセス権を持つユーザー プロファイルをすべてのアプリケーション ライブラリーおよびオブジェクトに直接割り当てる（図中の「専用権限」の項目）必要があるということです。通常、多くの企業では、*ALLOBJの使用は 許可されません。これは、広く浸透しているITセキュリティ ポリシーに反するためですが、そうしたポリシーに反することなく、この手法を利用するやり方については、後で説明しようと思っています。
顧客には、最初に*ALLOBJ、次に専用権限を試してみて、最良の実行時間改善シナリオを判断するよう勧めました。2つの方法の結果を比較して、どちらがよりフィットするか決めるということです。後に、*ALLOBJで試行した際の実行時間は4.5時間だったと顧客から聞きました（8時間からの短縮です）。このことは、私自身も含め、関係者全員にとって、まったくの驚くべき新発見でした。私たちは皆、すぐにこの要因の重要性を認識しましたし、私は決して忘れられません。
この一件の後にも、私は、さらに多くの顧客の同じような問題解決のサポートに関わりました。
このケース スタディから何かしら学ぶところがあったというところで、どうしてグループ プロファイルおよび権限リストを使用する必要があるのか疑問に思われた方もいるかもしれません。では、どうしてなのか見てみましょう。
業務アプリケーションがGUIベースのクライアント サーバー タイプでない場合、すべてのアプリケーション ユーザーは、それぞれのtelnetセッションでそれぞれの非バッチ ジョブを実行します。そして、何千とまではいかなくても何百ものそのようなユーザーが、毎日、IBM i サーバー上でアクティブである場合もあります。*ALLOBJまたは専用権限の割り当ては、実装するには非現実的、さらに言えば不可能です。そこで、グループ プロファイルと権限リストは、システム/アプリケーション管理者が、より複雑でない、それゆえより効率的なオブジェクト アクセス権制御を、サーバー上のすべての「対話式」ユーザーに展開するのに役に立ちます。
グループ プロファイルを使用することにより、数多くのユーザー プロファイルに同じデータ アクセス権を付与できるようになります。権限リストは、以下に示すように、数多くのオブジェクトを同じデータ アクセス権割り当てのセットの下で扱うことを可能にします。
得られるメリットの一例として、100件の対話式アプリケーション ユーザー プロファイルを持つサーバーについて考えてみましょう。たとえば、30件のグループ プロファイルと15件の権限リストを作成して、すべてのアプリケーション オブジェクトに対するアクセス権を、これらすべてのユーザーに割り当てることができます。そうすることで、管理が必要なセキュリティに関する項目は少なくなります。こうした考え方は、ほとんどすべての主要なサーバー オペレーティング システムで用いられているものです。こうすることで、非バッチ ジョブのこれらのユーザーのシステム管理を単純化するのに役立つからです。
しかし、これらの対話式ユーザーのグループ プロファイルおよび権限リストでの、オブジェクト権限検査のオーバーヘッドについてはどうなのかと疑問に思われる方もいるかもしれません。バッチ ジョブとは異なり、対話式ジョブは、比較的実行時間が短い一連のセッションである場合が多く、バッチ ジョブに比べて、より少ないアプリケーション オブジェクトから、より少量のデータにアクセスするプログラムを実行します。だからこそ、オブジェクト権限検査のオーバーヘッドは、バッチ ジョブに比べて、はるかに少なくなるケースが多いと言えます。
反対に、一般的な顧客の場合は、バッチ ジョブを実行するのに、ごく少数のユーザー プロファイルしか必要としません。そして、それらは、はるかに多くのアプリケーション オブジェクトから、はるかに多くのデータにアクセスする傾向があります。したがって、このケースでは、グループ プロファイルおよび権限リストを使用する必要性はより低くなります。
オブジェクト権限を割り当てる際は、対話式ジョブ ユーザーと、バッチ ジョブ ユーザーとで異なるアプローチで行うことが肝心です。そうすることが、後者の実行時間のオーバーヘッドを最小限にする助けになるということをご理解いただけたとしたら幸いです。
最後に、*ALLOBJについて記します。前述したように、システムに、この特殊権限を持つユーザー プロファイルが複数あるというのは、通常は、ITセキュリティ ポリシーに反することになります。しかし、バッチ処理の実行時間の最適化が業務上何よりも重要で、今すぐにも*ALLOBJが必要だという場合には、セキュリティ ポリシー反しない範囲で、どのようなことを行えるのでしょうか。1つアイデアがありますので、参考にしていただければと思います。
基本的には、*ALLOBJ権限を持つユーザー プロファイルを1つ作成する必要があることになります。このプロファイルは、システムにログオンするのには使用できないようにし（無効化されたプロファイルは、対話式ジョブを実行できませんが、バッチ ジョブは実行できます）、また、このプロファイルを、ジョブ投入（SBMJOB）コマンドから使用したり、プロファイル スワップAPIによって使用したりすることができないようにします。このプロファイルは、必要とするバッチ ジョブのみを実行するための専用プロファイルとして使用されます。このプロファイルを指定して、借用権限を使用する「起動」プログラムのセットから、すべての重要なバッチ ジョブを実行します。
*ALLOBJの特殊権限に加えて、以下のプロファイル パラメーターを指定します。
STATUS = *DISABLED
PASSWORD = *NONE
INLPGM = *NONE
INLMNU = *SIGNOFF誰もこのプロファイルでシステムへサイン オンすることはできなくなります。このプロファイルをSUPERMANと呼ぶことにしましょう。
オブジェクト権限編集（EDTOBJAUT）コマンドを使用して、このSUPERMANユーザー プロファイル オブジェクトに「排他的な」アクセス権を割り当て、PUBLIC権限が*EXCLUDEに設定されるようにし、専用権限エントリーをすべて削除します。SUPERMANの所有者をQSECOFRに変更します（QSECOFRを使用してSUPERMANを作成する場合は必要ありません）。これで、誰かが（*ALLOBJを持つユーザーを除く）、SBMJOBコマンドまたはプロファイル スワップAPIを使用して、SUPERMANを使用して他のジョブを実行することはできなくなります。
すべてのバッチ ジョブを起動するすべてのプログラム オブジェクトを確認（または新たなプログラムをコンパイル）し、これらのプログラムの所有者をSUPERMANに変更します。また、プログラム オブジェクトのUSRPRFパラメーターを*OWNERに変更します（デフォルト値は*USER）。これらのプログラムがSBMJOBコマンドを使用してバッチ ジョブを起動する場合は、SBMJOBのUSERパラメーターをSUPERMANに変更します。プログラムがプロファイル スワップAPIを使用する場合は、スワップするユーザー名としてSUPERMANを指定します。
最後に、バッチ ジョブ実行時には、活動ジョブ処理（WRKACTJOB）コマンドを使用して、それらがSUPERMANの下で実行されていることを確認するようにします。そうでない場合、何がまずいか調べるのに、ジョブ ログを検査することが必要になるかもしれません。
これは、問題解決に役立つ可能性がある1つの方法に過ぎません。たとえばソース コードがないためにプログラムを修正することができないなど、実際的な理由から、この方法を採用することができないケースもあることは私も承知しています。しかし、大筋を理解できていれば、それぞれの状況にとって適切なアプローチを必ず見つけられると思います。
対話式ジョブのユーザー プロファイルとバッチ ジョブのユーザー プロファイルは、後者のパフォーマンスを最適化するためには、別々に設定するようにする必要があります。この違いを理解しておくことは、バッチ処理のパフォーマンスが気になる向きには、かなり役に立つと私は確信しています。
