マイクロサービスアーキテクチャを使うシステム開発

最近ときどき、DX（デジタルトランスフォーメーション）のCMをよく見ます。
DX的にも迅速にアプリケーション開発ができる方法が求められます。
マイクロサービスアーキテクチャへの関心はも高まっていないのですが。
現状はまだ大きなシステムを開発し、維持管理している企業がほとんどです。
しかし、残念ながら現在の情報システムは、一部の修正が全体に影響してしまう機能構造、データ構造であり、
変化に迅速に対応するには簡単ではありません。小規模な修正でも長い時間がかかります。
もはや2年とか3年などの期間での開発は考えられません。2とか3か月でどこまでできるかが重要です。

この資料作成の経緯です：　
この間、昔、私がやっていたアジャイル開発の資料があれば欲しいとの要望がありました。
この手法をかってに「サブシステム分割サブシステムごとの本番移行」と呼んでいました。
古いの資料があったのでて送りましたが、読み返すと古い。最新の幾つかの手法と突き合わせて見ました。
その中でマイクロサービスアーキテクチャと非常によく似ていました。
分割ルールをマイクロサービスアーキテクチャに合わせ厳格にし、ＤＦＤを使っていたのをユースケースに変更し、書き直しました。

１．マイクロサービスアーキテクチャの概要

　：マイクロサービスは独立して運用できる、入出力やデータベースを持つ小さなサブシステムです。
　：このマイクロサービスを順次開発立上げし、対象のシステムを完成させるアーキテクチャです。

1-1. 目的
　・開発工数の大幅低減
　・開発着手から2または3ケ月後に、最初のマイクロサービスを本番移行
　・大きなシステムでも開発着手から1または1.5年後に、すべての移行を完了する

1-2. 作業の流れ
　・まず最初に、システム開発対象の領域を(1)「システム分析」します
　・次に、(2)「マイクロサービスの分割」をします
　・最初に本番移行したいマイクロサービスを決めます
　・この後はマイクロサービスごとに下記の工程を繰り返します
　　　　・(3)「マイクロサービスの設計」
　　　　・(4)「プログラム仕様書の作成」から、(5)「プログラムの実装と単体テスト」
　　　　　　人数が確保できれば複数のプログラムを平行作業します
　　　　・(6)「総合テスト」
　　　　　　マイクロサービスの単位でテストは完結します
　　　　・(7)「リリース」
　　　　　　マイクロサービスの単位で本番に移行します
　・次に本番移行したいマイクロサービスを決めます。(3)へ

1-3. メリット
　・開発も改善もそれぞれのマイクロサービスの中で 行うので、管理がしやすい早い作業ができる
　・障害が発生しても、マイクロサービスの中に限定されるので対策もサービスの中に限定される
　・マイクロサービスごとに開発実装が柔軟になる。（それぞれ違うプログラム言語とか）

1-4. デメリット
　・古いタイプのSEには「マイクロサービスの分割」は難しい
　　　　・ウオーターホールしかしらないひと
　　　　・データベース処理と画面処理やバッチ処理を別々に設計するひと
　・非同期のデータの受け渡しが必要
　　　　・いろいろな方法があるが最適なものを選ぶ

２．マイクロサービスアーキテクチャの作業の流れの説明

(1) システム分析

システム分析は、手順やビジネスを研究してその目標や目的を特定し、
それらを効率的に達成するためのシステムや手順を作成するプロセスです。
最初の作業は開発対象範囲を明確にし、業務を整理します。

しかし、システム分析とは、人によって、ソフトハウスによって、または開発手法によって
なにをするか、なにを作るかの説明内容がことなります。
この私のマイクロサービスアーキテクチャの開発ではの視点で、以下のように定義します。
　・開発対象範囲の現状調査
　　　・現状の業務調査と現状の業務フロー図の作成
　　　・現状のコンピュータ処理の調査と現状の機能関連図を作成
　　　・現状の機能の説明書の作成
　　　・現状の問題点
　・改善要望書き出し
　・新システムの改善を検討し、下記内容を持つ要件定義書を作成
　　　・新の業務調査と現状の業務フロー図案の作成
　　　・新のコンピュータ処理の調査と現状の機能関連図案を作成
　　　・新の機能の説明書案の作成

作成される資料は 　
・要件定義書

(2) マイクロサービスの分割

マイクロサービスアーキテクチャは、処理や機能やデータを独立配置可能な単位の
「マイクロサービス」に分割する考え方です。
機能とデータをサービスという単位で独立させることでサービス間の依存関係を低減し、
マイクロサービスでは機能拡充やスケーリング、あるいは保守などが容易になります。
要件定義書の新機能関連図案をマイクロサービスのの特徴に従って分割する。 　
・個々のマイクロサービスはそれぞれ独立したサブシステムとして動作する 　
・マイクロサービスは基本的に他のマイクロサービスからN/W経由でデータの送受をする 　
　　・非同期の通信ルールで所定のタスクを処理する方法でも良い 　
　　・他のマイクロサービスのデータベースをリアルタイムに検索更新しない 　
・各マイクロサービスは他のマイクロサービスに依存しない 　
　　・依存せず起動でき、独立してデプロイやアップデートが可能
上記の条件を作るため処理を追加することも考える。

ここまで来るとシステムの開発概要が見えてくる。開発計画書を作成する。
内容は開発範囲とそのシステム概要、
マイクロサービスごとの開発日程、
開発体制、
今後作成されるドキュメントやプログラム等のホルダと名称付与ルール。

作成される正規ドキュメントは 　
・開発計画書

今後作成されるドキュメントやプログラム等について 　
・履歴（作成/修正日、作成/修正者、修正内容）を持つこと 　
・修正前のファイルはファイル名末尾に修正日をつけ旧ホルダに保存 　
・修正後のファイルには修正前の内容をコメントアウト等で残さない 　
・議事録や問題点連絡書を開発資料にせず、正規ドキュメントを修正する

下記の図は現状システムの一部分を開発対象範囲として、
その部分をマイクロサービスアーキテクチャーで開発するために、
マイクロサービスに分割する作業イメージを表現しています。

(3) マイクロサービスの設計

分割されたマイクロサービスごとに設計作業を行います。
従来の設計作業と同じようですが、作業対象の範囲がマイクロサービスの広さです。

まず、マイクロサービスの外側を検討。
他のマイクロサービスとネットワーク経由で送受するデータの資料等の作成。
このマイクロサービスが旧システムと関係する場合は、
旧システムに対してネットワーク経由で送受するデータ処理する改修も作成する。

つぎに、マイクロサービスの内部を検討。
処理を整理し、ユースケースの作成をします。
注意点が幾つかありますが、粒度は作成する予定のプログラムの大きさで。
各ユースケースごとに、概要とフローの文と例外フローの文を作成する。
フローの文は、後でコミニケーション図を書かなくてもよいレベルで詳しく書く。
画面のレイアウトと画面の遷移図。
画面はユーザが想像できるレベルで、かつ項目が拾いだせるレベルで書く。
データベースを意識してクラス図を作る。
クラス図からテーブル定義の作成。

作成される正規ドキュメントは
　・送受するデータ(旧システム残る処理や他のマイクロサービスとの送受）
　・ユースケース図
　・画面レイアウト
　・画面遷移図
　・クラス図
　・データベース定義
　・テーブル定義

マイクロサービスの設計終了後レビューをする。

参考例として、ここで使用するあまりなじみのないユースケース図とクラス図を説明します。
この参考例の設定は生産システムの一部を改修対象範囲として分析作業をし、
さらに分割された「AA製造サブライン」の機能をマイクロサービスとして想定しています。

参考例としてのユースケース図です。

(4) プログラム仕様書の作成

ユースケース図のユースケースと関係する画面レイアウトからプログラム仕様書を作成する。
また、旧システムとのデータ受け渡しがある場合は、
旧システムの受け渡し部分の追加もプログラム仕様書として作成する。

プログラム仕様書の項目
　・処理概要
　・画面レイアウト詳細
　・入力項目定義やバリデーション
　・イヴェント別処理内容
　・ログ
　・単体テスト計画書

作成される正規ドキュメントは
　・プログラム仕様書

(5) 実装と単体テスト

この資料は、使用するサーバや開発言語を限定していません。
本来なら実装の準備段階で、決まっている開発環境から本番環境までのサーバや、
データベースや言語についてのドキュメントを作成します。
そのドキュメントに従って実装の環境の準備がされまが、
サーバや開発言語を決めていない為、具体的作業内容は省略します。
実装の準備段階作成される正規ドキュメントとして下記のような資料を作成してください。
　・環境説明書（開発サーバ、テスト、本番サーバ環境などやリモート接続方法など）
　・開発言語説明書（例えばVisualstudio2022でC++で...）
　・データベース説明書

実装テストに関する下記作業を行う。
　・データベース定義からデータベース実行環境の作成
　・テーブル定義からテーブル等の登録（複数あり）
　・プログラム仕様書からプログラムの作成（複数あり）と単体テスト

作成される正規ドキュメントは
　・プログラム仕様書（単体テスト後の結果追記）

作成されるプログラム等は
　・プログラム実行環境の作成
　・データベース実行環境の作成
　・テーブル等の登録
　・プログラム等

(6) 総合テスト

この部分は環境により違いが大きいので、詳細は書けません。
簡単に書きます。

総合テストの準備をする。
できれば現状システムのデータを抜きだし加工して使用する。
全てが利用できれば現状との動きを突き合わせチェックが可能だが。
また、旧システムとのデータ受け渡しがある場合は、
旧システムの受け渡し部分の追加もテストされる必要がある。

実行環境が生産設備と連携するような場合は、そのテストも必要となる。
稼働週の稼働日の前日の休日を利用して本番データで稼働テストをする。
数件処理してOKなら稼働日はその状態から稼働。
エラーならすべて戻し、後日対策後やりなおしする。

(7) リリース

この部分も環境により違いが大きいので、詳細は書けません。
簡単に書きます。

開発環境を本番環境にコピーします。
マイクロサービスの単位でリリースする。

３．マイクロサービスアーキテクチャの考慮点

3-1. システム分析ができているかの確認

開発作業の一番最初に行う作業は、システム分析で「要件定義書」の作成です。
システム分析とは、開発対象範囲とそのシステムに何を求めるのか、明確にしていく工程です。
必要な機能や仕様をまとめて要件定義書を作成します。
要件定義書がまともに作成されていないと、システムの品質やコストに大きな影響を与えます。
以下が「まとも」であるかのチェック項目です。
ひとつでも問題があれば必ず修正をユーザと行ってください。
　
・現状を改善せず、伝票中心の業務になっていないか？ 　
　・伝票廃止が検討されるべき 　
　・画面入力から「いつだれが何を」記録されれば伝票は不要 　
・画面入力は完結する作業で作られているか？ 　
・画面入力のミスや不正が毎日チェックされる体制ができているか？ 　
・画面処理は使用目的と必要性が明記されているか？ 　
・現状を改善せず、帳票中心の業務になっていないか？ 　
　・帳票廃止が検討されるべき 　
　・帳票が必要なら具体的な使用方法と必要性が明記されるべき 　
・承認処理について 　
　・高額な稟議システムなどを除き、承認処理は不要 　
・大量に他のシステムのデータベース操作が必要な場合 　
　・処理で他のシステムのデータベース操作は禁止 　
　・データでの受渡を作るべき 　
・少量の他のシステムのデータベース操作が必要な場合 　
　・端末機の画面OSで他のシステム画面を同時表示 　
　・処理ではなく人の操作で関係を作るべき 　
・要件書全体をみて 　
　・数十年前の1980、90年代のやり方ではなく、現代のやり方で分析されているか？

3-2. マイクロサービスの分割方法

業務内容のドキュメントと業務現場での実際の作業を理解している必要があります。
理解してから、マイクロサービスに分割する作業に入ります。
システムの特徴によって分割方法が違います。

生産系のシステムの分割
工場の製造は、工場内には幾つかの建物があり、建物の中には幾つかの製造ラインがあります。
加工、組付、溶接、塗装、組立などいろいろな製造ラインがあると思います。
生産のシステムでは各製造ラインに対応させてマイクロサービスを作ります。
理由はコンピュータシステムの変更は製造ラインの改造に対応して発生します。
その他に、生産計画を管理するマイクロサービスや製品の出荷を管理するマイクロサービスが必要になります。

事務系のシステムの分割
事務系の場合はほとんど現場がありません。担当する部とか課や係はありますが。
部署は事務工数などの都合や作業時期などから複数の機能を関連なく担当しています。
部署での分割はむりです。機能で分けるしかありません。
関係の強い機能を集めてマイクロサービスを作ります。

分割に問題はないか再度確認
　・サービスのサイズは
　　　・大きすぎない（２ケ月前後で作れるサイズ）？
　　　・小さすぎない（１ケ月前後で作れるサイズ）？
　　　・移行や切替にちょうど良い範囲か？
　・他のサービスや旧システム残処理との関係
　　　・非同期のデータ受渡は両方に作られているか？
　　　・直接に他のサービスやシステムのDBを操作していないか？
　・他のサービスや旧システム残処理とのWindows画面での関係がある場合
　　　・クリップボードの内容は必要な場合に適切か？
　　　・各画面はサイズに問題はなく操作しやすいか？

参考例です。
例えば部品必要数を計算する為に、製品の計画と部品引当DBをN対Nで照合する場合、
部品必要数を計算の機能を新たなマイクロサービスに分割し独立させる。
このとき他のサービスにある部品引当DBを直接読めないので、
部品必要数を計算のマイクロサービスのDBへ部品引当をインポートする。
独立させることで、高速で処理できるハードを持つ専用サーバや、
高速で処理できる言語で設計ができるメリットがある。

3-3. 非同期通信方法

他のサービスや旧システム残処理とデータの受渡をするための非同期通信です。
マイクロサービスを移行するとき、機能するように、
当マイクロサービスと他のサービスまたは旧システム残処理の両方に
非同期通信の受渡の処理が作られる必要があります。

Widous server のホルダを使う
　・環境の作成
　　　・Widous server を決める
　　　・通信データごとにホルダを作る
　　　・通信データごとにファイル名を決める
　・制限その他
　　　・大きいデータは送受可能
　　　・メッセージが頻繁な場合、First-In First-Outをファイル名等で独自管理が必要
　・使い方
　　　・通信データごとのホルダで、送信側が格納し、受信側が読込と削除

キューイングツールを使う
　・SQS(Amazon Simple Queue Service)の場合
　　　・マイクロサービス間で任意の量のメッセージを送信、保存、受信することがでる
　　　・メッセージが頻繁な場合、First-In First-Outで送受ができる
　　　・メッセージを失ったりする危険がない
　　　・制限として、大きいデータは送受できない（最大 256 KB のテキスト）
　　　・詳細は直接SQSを検索してください

3-4. 労働環境について

もともとブラック企業なら救いようがないのだが、
ウオーターホールだろうが、スパイラルだろうが、アジャイルであっても、
プロジェクトマネージャや、プロジェクトリーダやプロジェクトサブリーダがだめなら地獄になる。
ノルマにおわれ、稼働がどんどん上がり、残業地獄が起きてしまう。
アジャイルだからと言っても解決策にはならない。
たとえばスプリントは1から2週間で実装チームが完了する仕事量を予測し管理しながら進めていく。
早く終わったら、前倒しで次のスプリントに早く入れば良いのだが、
予備日程を超えて終わらない場合が続くと問題。
このとき、仕事が遅いと言い出しだしたらたらマネージャやリーダ失格だ。
予測や実装方法が間違っているのだ。
　・実装者それぞれのスキルを把握していない
　・複雑または高度なコーディングが、実装で要求されている
　・プログラムおたくが実装方法をきめている
早く開発を完了する必要があるが、ブラックにしてはならない。
マネージャや、リーダは、「安全、品質、生産性」を意識してプロジェクトを作り管理する。
特に「安全」は重要だ。「安全」の反対の「危険」は残業増加から始まる。
労働環境で最重要は残業ゼロでプロジェクトを作り管理していくこと。
絶対残業させてはいけない。

4．まとめ

マイクロサービスアーキテクチャーは以下の業務処理のシステムでは最善の開発方法でした。
　・生産関係のシステム
　・経理や人事などの事務係のシステム
　・購買や部品手配などの事務係のシステム
　・営業関係などの事務係のシステム
しかし、ユーティリティーアプリ、ツールアプリの開発では、関連が強く分割できない為、うまく使えません。
マイクロサービスを切り出せるかにかかっているようです。
また、その他のシステムについては検証できていません。これからです。