⇧ 衝撃！
By the way、糸電話ですが、
糸電話（いとでんわ）や針金電話（はりがねでんわ）（英: tin can telephone）とは、音声を糸やワイヤーなどの振動に変換して伝達し、再び音声に変換することによって音声で通信（離れた場所でのコミュニケーション）を行うための道具。英語の「tin can telephone ティン・キャン・テレフォン」は「ブリキ缶テレフォン」という意味。
⇧ 海外だと空き缶を使うみたいですね、知らなんだ。
「電話」という語が含まれるが、telephone（離れた場所で会話する装置）の訳語であり、電気を使うわけではない。
⇧ 「テレフォン」ってそういう意味なんだ。
もともと「telephone」は、「音声通信」という意味で、「電気」という概念は不可欠なわけではないのだが、欧米から遅れて導入した日本の側で「電話」と電気を強調した用語を造語してそれを訳語として定着させておきながら、時代をさかのぼって糸やワイヤーを用いた「telephone」についても強引に「電話」という言葉を適用したものだから、電気を使わない道具にまで「電話」と呼ぶという奇妙な現象が日本語では起きてしまっている。
⇧ 「糸電話」って響きは良いと思うけど...
で、ふと、気になったのは、「糸電話」での通話ってどれぐらいの距離まで可能なのか、ブラジルまで通信できるもんかね？と。
「いいの、いいの、ブラアン・イーノ」など洋楽好きな人じゃないと意味不明なギャグや、「糸電話が可能な距離は830mまで」などストーリーに直接関係のない豆知識が詰め込まれてある。
価値観の違い、世代間のギャップを楽しみたい!! 三木聡監督のオリジナル作『音量を上げろタコ！』 (2018年10月5日) - エキサイトニュース
⇧ 『音量を上げろタコ！ なに歌ってんのか全然わかんねぇんだよ!!（監督・脚本／三木聡）』の映画だと、830mらしい。
実際、やってる人がおりました、スゴイ...
830mです。四捨五入すると、1kmです。
830mっていうと、東京タワー2.5個分ぐらいです。
地図で見てもわかるとおり、かなり長い距離です。
こんな距離でも、糸電話が通じるなんて！
⇧ ブラジルまでは届かないけど、830m届くなら、携帯の電波が届かずに孤立した状態になった時に、糸電話が使えそうですね！
そんなこんなで、通信には様々な選択肢があるじゃないですか？
今回は、マイクロサービスでのアプリケーションに関する通信って、どんなものを選んだら良いのか気になったので、調査してみました。
レッツトライ～。
選択肢が多過ぎる問題
皆々様「選択回避の法則」または「決定回避の法則」 と呼ばれる法則をご存知でしょうか？
もともとはプリンストン大学心理学部のエルダー・シャフィール教授が大和証券のCMで出てきて語ったのが元ネタの様子
CMの中で4種類のベビーカーとたくさんの種類のベビーカーを出し「沢山の種類からのほうがより良いものを選べると思われるが、選択肢が多いと選べなくなる」という旨が紹介されている。
⇧ 上記サイト様の説明にありますように、「エルダー・シャフィール」という人物が提唱した考えですと。
「エルダー・シャフィール」さん、本も出してるようで、
⇧ 上記の本が有名ですかね。
まぁ、要するに、『選択肢が多過ぎると、もはや情報を処理し切れなくて思考停止状態と変わらん現象に陥ると』ってことなんだと思うけど。
現代社会の情報の多さについては、
18世紀の人って、一生かかっても新聞1週間分ぐらいの情報しか触れないんですよね。
あるいは、現代の日本人が1日に触れる情報量は何と一緒かというと、これはグッとさかのぼって平安時代の日本人が一生で触れる情報量になります。けっこう少なめですよね。ちなみにこれ、江戸時代になると1年分になるんです。
「ほう・れん・そう」には“あるパラメータ”が足りない マイクロソフト澤氏が語る、労働生産性を上げるためのヒント - ログミーBiz
⇧ マイクロソフトの澤さんの紹介された情報が有名かと。
昔の壁画や石板も全部データとしてとらえた場合に、直近2年で90パーセントのデータが生まれているんです。ということは、一昨年のデータは我々からすると10パーセントのほうに含まれちゃっているんですね。それぐらい急激にデータは増えています。
「ほう・れん・そう」には“あるパラメータ”が足りない マイクロソフト澤氏が語る、労働生産性を上げるためのヒント - ログミーBiz
⇧ 最早、「選択回避の法則」が発動されるのもやむを得ない環境に我々は否応なく立たされているわけですと。
当然アプリケーションの通信の選択肢も多い
ご察しの通り、アプリケーションの開発においても、アプリケーションに関する通信の選択肢が過多になってるってこと？という予測に容易に辿り着くことになるわけですが、皆々様ご推測の通り多いんですよ。
Javaの開発とかだと、
- HTTP（Hypertext Transfer Protocol）
- RPC（Remote procedure call）
- CORBA
- SOAP（Simple Object Access Protocol）
- SOAPjr
- REST（Representational State Transfer）
- GraphQL
- Message broker
⇧ このあたりを考慮していく感じになるんですかね？
当然、これ以外にも、選択肢はあるわけで、さらに、これらを使うに当たっては、Javaのほうで適切なライブラリを選択する必要もあるって言うんだから、もう考えること多過ぎ問題...
いや～、全部を検討しとれんでしょうって話ですよ。
マイクロサービスではどういう選択肢になる？
マイクロサービスでは、アプリケーションに関する通信についてどういった選択肢が候補に挙がるかと言うと、
つまり、マイクロサービスでは、ユーザが触れるアプリとバックエンドとの通信、バックエンドのサービス同士の通信といったように、モノリシックなシステムと比べてより多くのWeb APIを定義する必要があります。また、基本的にサービスが違うと管理するチームも違うため、アプリケーションの作り方や、用いられているプログラミング言語まで変わる（Polyglot）場合があります。
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
⇧ マイクロサービスはアプリケーションに関する通信が多岐にわたるので、Web APIも多くなると。
そのため、Web APIを使う側がコードを読まなくても、ある程度処理の概要が分かるような管理方法が重要になるわけです。
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
⇧ Web APIの管理が重要になってきますと。
Web APIの管理は、Schema First Development（スキーマファースト開発）という開発手法においても、同様に重要です。これは「最初にWeb APIの仕様（スキーマ）を決め、そのスキーマが満たされる前提のもとにサーバ・クライアントが同時に開発を進め、最後に結合する」という開発手法です。
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
⇧ Web APIの管理ってのは、Web APIの仕様が鍵ですと。
今回は、このようなWeb APIのインタフェースを定義するという観点から、その用途として使える通信方式としてOpenAPI、gRPC、GraphQLの3つを挙げ、それぞれの特徴や技術選択時の観点について紹介していきます。
マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
⇧ 「OpenAPI」「gRPC」「GraphQL」の3つが、マイクロサービスで利用するアプリケーションに関する通信の候補になりうると。
Google さんによりますと、
ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud Blog
⇧ API設計は、「RPC」か「REST」の2つのモデルに大別されますと。
ほとんどの公開 API と多くの非公開分散 API は、トランスポートとして HTTP を使用します。少なくともその理由の一つは、組織がポート 80 と 443 で HTTP トラフィックを許可するというセキュリティ問題への対処に慣れているためです。
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud Blog
⇧ APIは、HTTPを利用していますと。
私としては、HTTP を使用する API のビルドには、重要かつ特徴のあるアプローチが 3 つあると考えています。次のようなアプローチです。
-
REST
-
gRPC（および Apache Thrift など）
-
OpenAPI（およびその競合製品）
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud Blog
⇧ ってな感じで、アプリケーションに関する通信としては、「REST」「gRPC」「OpenAPI」の3つが候補になりますと。
「gRPC」とか「OpenAPI」とか出てくるまでは、
メッセージングとは、ネットワーク上で情報を「メッセージ」という単位で扱い、特定のアプリケーション同士がメッセージでやりとりすることを指します。
非同期処理と疎結合ができる「メッセージング」の常識 (1/4)：企業システムの常識をJBossで身につける（5） - ＠IT
⇧ 「メッセージングシステム」 が、盛んだったってことかしら？
現状、「gRPC」「OpenAPI」が選択肢の有力候補なんですかね？「GraphQL」も注目ですかね。
まぁ、でも、個人的には、「NATS Messaging」が気になるところですが。
NATS is an open-source messaging system (sometimes called message-oriented middleware). The NATS server is written in the Go programming language. Client libraries to interface with the server are available for dozens of major programming languages. The core design principles of NATS are performance, scalability, and ease of use.
⇧ 「Go」で作られてますと。
The source code is released under the Apache 2.0 License. NATS consists of:
- The NATS Server - The core Publish-Subscribe Server for NATS.
- NATS Streaming - A data streaming system powered by NATS that adds persistence, message replay, durable subscriptions, etc. to NATS.
- Client libraries for a variety of programming languages
- A connector framework - a pluggable Java based framework to connect NATS and other services. NATS is a CNCF project with Kubernetes and Prometheus (software) integration.
Microservices frameworks such as Micro, Mainflux, and Hemera rely on NATS as their messaging backbone.
⇧ 「Kubernetes 」や「Prometheus」と同じく、「CNCF（Cloud Native Computing Foundation）」が管理してるプロジェクトらしいし。
今回はこのへんで。
