「分割」をキーワードにつらつら思ったことを書きました(結論はないです^^; ) ・サブルーチン化 ・オブジェクト指向 ・fork&exec ・RPC などツラツラと...

1. 古くて新しいアプリケーション分割の話
2022/01/24 はしもと ただし

2. © はしもと ただし 2022. All rights reserved.
はじめに
「分割」をキーワードにつらつら思ったことを書きました(結論はないです^^; )
ソフトウェアの開発での夢・野望の一つに以下があると思います。
✓ ソフトウェアを部品化して、 中身の詳細を理解せず再利用したい
✓ 部品をブロックのように組み合わせて大きなプログラム・システムを作る
✓ 部品の変更・差し替えは簡単かつ周辺への影響はなしにしたい
ですが、「上手にできた一部のプロジェクト」以外では達成できていません。
「部品化」するのにはコードをある程度まとまった単位で切り出すひつようがあるため、
このソフトウェアを切り出す＝分割するってところに注目して少し振り返ってみました。

3. © はしもと ただし 2022. All rights reserved.
サブルーチン(関数)で分割
昔も今もやりたいこと(ゴール)に変わりはないと思います。
✓ トップダウン設計
✓ 抽象化
✓ モジュール化
構造化プログラミング by ダイクストラさん あたりが起源でしょうか。
単純に「構造化(定理)」＝「goto文禁止」みたいな理解・混同されがちですが、
ダイクストラさんの主張はオブジェクト指向の概念なんかも含んでいそうな気がします。
当時の処理系ではサブルーチンや関数での分割による構造化になったのかなぁと妄想。
(他にも検証容易性とか野望がいろいろあるはずですが割愛)

4. © はしもと ただし 2022. All rights reserved.
オブジェクトで分割
私の理解は「構造化プログラミング」を処理系(言語仕様)でサポートするもの。
✓ 抽象データ型
✓ 継承・移譲
✓ モジュール化
✓ メッセージパッシング
オブジェクト(データ型＋処理)の単位でプログラムを分割。
オブジェクトが処理を知ってるので「これをお願い」ってメッセージを送る。
メッセージ送信なので本来、同期処理・非同期処理の概念もあるが典型的な処理系で
は「同期呼び出し」を軸にサポートされている。

5. © はしもと ただし 2022. All rights reserved.
ロードモジュールで分割
全く別の処理を小さなプログラムの連携処理で実現するのもある意味分割
✓ fork&exec : e.g. unix系のlogin(認証処理後->シェルをexec)
✓ CICSでのEXECマクロ : (呼び出し先のアプリケーションに処理を移譲(リターンしない))
コマンドラインでsortやuniqを組み合わせて処理を実現するのも同じ思想ですよね。
住所録の重複排除くらいならこれでも良いのですが、JP1のジョブネットがお客様先でみる
みる成長していく様子を見ると、効果的に適用できるのは限定されそうな予感...

6. © はしもと ただし 2022. All rights reserved.
プロセス・スレッドで分割 (同期呼び出し)
関数やオブジェクトをプロセスやスレッドに乗せて分割 (RPC, CORBA)
典型的には同期呼び出しで利用することが多いです。
✓ 全体のリコンパイルを伴わずに、部品ごとに差し替えが可能
✓ 影響範囲の局所化(中身を差し替えても呼び出し元に影響なし)
SOAやREST-APIなど色々呼び名(と実装)を変えては何度もチャレンジしている領域。
同期呼び出しの場合「影響範囲の局所化」って見果てぬ夢の様にも思います。
大きなコールツリーが同一スレッドで実行されるのか、別のスレッドやプロセスで実行されるのか
の違いしか無いと考えるためです。
綺麗に機能を整理すれば良いのでしょうが、それはプロセスが一緒か別に関わらない予感...
(ローカル変数参照できないなど実装をある程度強制できる点は同意)

7. © はしもと ただし 2022. All rights reserved.
プロセス・スレッドで分割2 (非同期呼び出し)
非同期処理として分割するのも古典的な手法ですよね。
✓ 1対1のモデルから、1対n(pub—sub)に拡張
✓ ある意味処理の独立は強制される
マイクロサービスアーキテクチャでも「非同期をうまく使うのが処理の独立性を保つコツ」と言
われています。
一方、非同期で連携する部品が多くなるほど、全体で何が実行されるのか見通しが悪く
なりがち。
見通しが甘くて、非同期で投げたメッセージが一周回って戻ってくると無限ループになっちゃ
うなど、非同期ならではの難しいトラブルもあります。

8. © はしもと ただし 2022. All rights reserved.
一旦、まとめ
野望(部品化・再利用)への手段は色々ありそうだけど、銀の弾(決め手)はまだない
(個人の感想です)
1960年代 1970年代 1980年代 1990年代 2000年代 2010年代 2020年代
OS/360 構造化プ
ログラミ
ング
Smalltalk
80
SunRPC
CORBA
IBM MQ
SOA
SOAP
マイクロ
サービス
いまココ

9. © はしもと ただし 2022. All rights reserved.
派生して: 実装は分割するけど一つの業務処理
業務処理と思うとアトミックトランザクションも必要。枯れた技術としては以下があります。
a) 1プロセス(スレッド)での処理なら、DBMSにおまかせ(ローカルトランザクション)
b) 複数プロセスでの同期処理なら、分散トランザクション(e.g XA+)
c) 非同期処理なら、トランザクショナルキュー(e.g. MQ)を利用しDBと一括コミット
bとcで、「アトミックな更新処理」を実現する場合、2フェーズコミットが必要です。
一方、2フェーズコミットでの障害タイミングと回復までの時間によっては、人が介在しないと
DBがいつまでもコミットできない事も!( e.g. Prepared状態でトランザクションマネジャが長時間ダウン )。
こうした障害やオーバーヘッドもあるため「2フェーズコミットはあんまり使いたくない」というアー
キテクトさんもいらっしゃいます。
( ヒューリスティック状態にほとんど陥らない基盤があると世の中変わるかもしれませんね♪)

10. © はしもと ただし 2022. All rights reserved.
DBMS
更に脱線: 実装は分割するけどローカルトランザクション
✓ 業務処理で更新するDBと同じDB上にキュー用の
テーブルを作成
✓ 業務処理で更新するDBコネクションと同じコネクション
でキュー用テーブルに書き込み
上記の様なDBキューを使うと、DBMSからは単に更新する
テーブルが増えるだけなので、ローカルトランザクションとしてコ
ミットすることができます。
(e.g. TP1/Server Base Enterprise Option のDBキュー
Oracle のAQもかしらん?)
• HTTPで呼び出される
• いろいろ業務処理
• DB更新
• メッセージをenq
• commit
非同期処理でDB更新とトランザクショナルキューを使いながらローカルトランザクションでのコ
ミットにする裏技(!?)があります。

11. © はしもと ただし 2022. All rights reserved.
参考資料
✓新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡
https://qiita.com/hirokidaichi/items/591ad96ab12938878fe1
✓ AWS モダンアプリケーション開発
https://pages.awscloud.com/rs/112-TZM-766/images/wp_mad_201906.pdf
✓ DBキュー機能 (TP1/Server Base Enterprise Option 使用の手引)
http://itdoc.hitachi.co.jp/manuals/3000/30003F5170/EEUG0051.HTM

12. 古くて新しいアプリケーション分割の話
Fin