システム連携における考慮点

最近のお仕事は、概念化された様式美の多いAI界のコンポーネントを物理へ落とし込んでいくことと、クラウドサービスとの繋ぎ込みを物理レベルまで落とし込んで実装方法を検討ていました。物理の見えづらい時代こそ物理が重要。

さて。クラウドサービスを提供している側的に "API" という言葉はとても使い勝手の良すぎるものです。「わたしたちは"API"を提供しています」と聞くととても聞こえは良いですよね。この "API" によって「システム、データ連携はできそうだな」と判断しがちなんですけど、ここがノックアウトファクターにしかなりえないケースは往々にしてあって。

ここを深掘りしなかったがために、実装で頓挫すると言うケースをたまに目にします。インフラをよく知らない人向けに、ここで気をつけるべき主なポイントを紹介します。

ネットワークの接続性の問題

まず大前提として、相互に通信できる経路がなければデータの送受信はできません。ネットワークを通って疎通できることは絶対条件です。

物理的に繋がるか

今どきはあまり見かけませんが、そもそも構内LAN の仕組みしか持っていない所とクラウドサービスを繋げることはできません。

まず物理的にネットワークが繋がっていないもの同士(電波含む)を、接続させることはできません。

ここは当然ですよね。

と思ったらおおまちがいですよ。工場とかでこのケースにハマります。

論理的に繋がるか

物理的に繋がってさえいれば、システム間の接続ができるかと言ったらそんな事はありません。

よくあるのは、Internet から社内のシステムには Firewall などで通信制御されていて論理的にアクセスできないようになっていたりします。状況によっては、物理的には繋がっているけれども TCP/IP の経路が設定されていなくて繋がらないとかもあるかもしれません。

未だに Internet を経由してデータのやりとりを行わないなんて言う企業はごまんといますから、そういった閉域経路を準備できるかは結構大きな壁だったりします。特に我々のようなクラウドサービスベンダーにとっては。

規約上の問題

ネットワークが繋がっていれば万事よしと行かないのがこの世界です。

さまざまな規約によって阻まれるケースは少なくありません。

アプリケーションプロトコルは何を利用するか

より正確に言うと、OSI や TCP/IP におけるアプリケーション層でのプロトコルが一致することです。

ここ最近では (Web) API というと REST を利用することが一般的です。これらは HTTP および HTTPS プロトコル上でやり取りする際に決められたガイドラインの位置づけです。HTTP(S) がプロトコルで、HTTP(S) 上で連携する際のガイドラインとして取り決められたものが REST です。面倒なのであれですが、要するに Web API といえば HTTP(HTTPS) でやり取りされることがほぼ前提だと言っています。

ほんでもって、ここでよくいわれる API というものには他にも様々なものがあります。

例えば、ファイル連携では FTP や SFTP、日本国内だと HULFT なども多くの企業で使われています。データの連携には MQTT/MQ のようなキューイングプロトコルなども存在します。特定のアプリケーション向けだと、メール送信用の SMTP やメールボックスのメールを取得するための POP3やIMAPなどもあります。API という表現はあまりせずにプロトコルと言いますが、これらも API のうちの一つでしょう。

データフォーマットの不一致

古い人間は「電文」なんていいますけど、それはデータのフォーマットのことを示しています。プロトコルでデータフォーマットまで決められたものならいいのですが、REST のように JSON 以外にも XML などを利用することもできてしまうような場合、想定しているデータのフォーマットが異なっていると、そもそもデータの交換すらできないこともあるわけです。

CSVとTSV だって似てはいるけれど、使えるかどうかは相手のシステム次第です。勝手に JSON だなとか考えていると痛い目にあうわけです。

変換ロジック入れればいいじゃん、というのは真理ではありますが、特定の世界ではあってはいけないことです。そんな単純な世界ではありません。この世界。

そもそも、テキストじゃなくてバイナリでデータ伝送されるかもしれないこともあるわけですよ。こわい。

文字コードの不一致

今どきな Internet サービスの大半は UTF-8 っぽくていい世界になりました。20〜30年前は SJIS や EUC などが多くて、文字化けしてよく分からんなんてことはよくある話でした。

ほとんどのクラウドサービスは UTF-8 になったからと言って、社内のレガシーシステムも unicode 対応になったわけじゃありません。そもそも unicode だっていっぱいあるじゃん。

そしてメインフレームは EBCDIC や某社固有文字だったり、オフコンや unix では SJIS が未だフツーに利用されている端末もやたらあったりします。その理由の多くがシステムのデフォルトだったり、作り溜めた遺産のような外字だったりするわけです。この外字がやたら面倒で。UTF-8 で基本的に対処は可能なものの、そのマッピング作業は誰がやるのかとか、誰がその変換を保証するのかとか。UTF-8 でも表現されていない文字があった場合にどうするのかとか。

更に言うと、SJIS もどのコードやねんみたいな諸問題がたくさんあります。わたしは関わりたくありません。

そもそも

実態としてこれだけではありません。「電話線(INS)で繋がりますか」とか「え、TCP/IP ではなかった」なんてことはママあります。ママありますけど、わたしは想定しているので問題にはなりません。
ただ、こういった謎の仕様が分からない人には、そもそも何がいけないのか理由すら分からないでしょう。

どうにかしてこういったことを教育して引き継いでいますが、ホントに伝えていかないといけない人たちに限って研修には参加しないことが常です。

もう少し下のレイヤーにも目を向けて欲しいなと思う今日この頃です。