データ作成・変換と課題
これだけでは、まだ実感がわかないという方のために、ここではさらに深堀りして、データ作成について考えていきます。
データ作成といっても、大概、コーディングレベル（＝どう書くか）という点だけでとらえている人が多いのではないでしょうか。しかし、システム間連携でも、同じ考え方ができるかと不安に思う方もいるかも知れません。実際、システム内におけるデータ作成と複数のサービス間におけるデータ作成では似て非なる部分があり、その違いが大きすぎるがゆえに同じ物として認識できない場合がよくあります。ここでは、「似て非なる部分」がよりわかりやすいように説明していきます。
もっとも基本的なデータ作成・変換
まずは、もっとも基本的なデータ作成、または変換を考えたときに、図6のような処理があります。
（1）の「変換」はもっとも基本的な形で1つのデータを別のデータ形式にそのまま変換することです。そして、（2）の「分割」も変換の一種ではありますが、1つのデータを2つ、または2つ以上のデータへと変換することです。ここでの注意点としては2つのデータを同時に出力しているのではありません。
連続した2つのデータの生成であり、1行のデータを2行に分割しているイメージといえばもう少し分かりやすくなると思います。そして、最後の（3）は（2）の反対の処理で複数のデータを1つのデータへと統合する処理です。
これらを見ると、「別に簡単ではないか」と思えるかもしれません。しかし、実は思ったよりも難しい処理があります。
それが、（3）の「結合」です。先ほど述べたように、分割が1行から2行であれば、その反対の結合は2行を1行にするイメージです。ここでデータ変換のイメージとして、プログラム内の関数だと捉えるならば、2つの引数を受け取ると考えればシンプルです。
しかし、「2つの引数」は、この場合、完全に同時に取得できなければなりません。しかし、一般的には、取得する時間には差があるため、同時に2つのデータにアクセスしてデータ結合することは単純にはできません。
例えば、複数の入力セット自体が連続することもあるため、まずは（A）のように考える必要があります。そして、このままでは、どの単位がセットとして扱えるのかがわからないため、（B）のように最初と最後を区別する何らかの識別データが必要になります。そして、これらの入力が同時になされるのではなく、連続的に渡されるため、実際には（C）のように連続する4回の入力につき、1つの出力ということになります。
このような処理はデータ変換という認識よりは「プロトコル」処理といった方がイメージしやすいでしょう。「プロトコル」というと難解に聞こえる方もいると思いますが、やっていることは「結合処理」を伴う出力です。そして、システム間連携では、この「プロトコル」という概念が欠かせないのは、ネットを利用する場合には既に多くの方は知っているはずです。
複数の入出力を伴うデータ作成・変換
続いて、同時に複数の入出力を伴う場合のデータ変換を考えてみたのが図8です。
（1）は1つの入力から2つのデータを作成する場合です。先ほどは1行のデータから2行のデータを作成するようなイメージでしたが、今回は1つのファイルから2つのファイルを作成するイメージです。従って、（2）の結合でも2つのファイルを元に1つのファイルを作成するイメージになります。このため、先ほどのような複雑性は生じません。
ここで、複数の入力から複数の出力のケースがないのはおかしいと思った方もいるかもしれません。しかし、その場合には、図9のように「結合」と「分割」を組み合わせるだけです。
2つの入力が同時にあって、2つの出力が同時にあるというケースはデータ変換だけの世界ではよくあるケースです。そのため、このようなわざわざ面倒な考え方をしなくても、2つ以上の入力と2つ以上の出力が可能なデータ変換処理を用意したほうが便利なはずと思うかもしれません。
しかし、実はここにも理由があります。それが先ほどと同様にシステム間連携では、厳密な意味で2つ以上の入力が同時にあることを保証するのは現実的に不可能です。
例えば、図10のように2つのサービスから得られる別々の結果をもとにデータ結合しようとしても、左図のような理想的なケースは生じ得ません。実際には右図のように時間の差が必ず生じます。
また、場合によっては片方だけが失敗するというケースもあり得ます。そのような場合には、その後の処理はどうしたら良いのかが判断しにくくなるというのは、マイクロサービスで生じやすい問題だと前回述べました。そして、この問題はデータ変換においても同様に存在します。
このような場合には、図11のようにデータ結合を多段で組み合わせることで、片方のデータ準備が整わない場合の待ち処理やエラー処理などが行いやすい構造をとることが可能になります。
このような特性がわかると、同一システム内におけるデータ作成や変換と違って、入力データがほとんどのケースでより難しい課題になり得るということがイメージできたのではないでしょうか。そして、その特徴を事前に知っておくことで、今後のシステム間データ連携はよりやりやすくなります。
システム連携のデータ連携イメージ
ここまでの考え方をつかって、商品の注文処理から発送データを送る場合のデータ連結イメージを記した一例が図12になります。
実際の業務をカバーできるようにするとさらに複雑化するのですが、このような図を見て思い浮かべるものがある方もいるはずです。実は、このような考え方はシステムでは至る所で使われています。例えば、以下のようなものの中から一つでも想像していたら、そのイメージはおおよそあっているはずです。
- 継続的インテグレーションおよび継続的デプロイメントにおけるパイプライン処理
- ビルドや環境構築手順などの定義ファイル
- 自動テストフロー
- 業務フロー
- ジョブ制御言語（JCL）
このような処理を技術的に「パイプライン」ということがよくあります。ただし、実際の開発コードでのすべての処理をパイプライン化することは見ての通り面倒です。今回の目的はあくまでデータ連携の準備なので、図13のようにパイプラインを部分的にすれば、複雑さも軽減できます。
NOTE
JCLは汎用機時代に使われていたジョブの制御言語であり、また、それを実行する環境を含めて示すことがよくあります。この用語を見てイメージできる方は今では少ないと思いますが、インターネットが普及する前から業務システムでは広く使われていて、同じような考え方は今でも通じるものがあるということを知っていただくためにあえて記しました。
筆者は2000年に汎用機システムからWebシステムの世界に飛び込んだ際にこのJCLというパイプライン処理をするシステムがないことに驚き、このJCL相当のシステムを作ることから始めたことをよく覚えています。
