計算と通信と - その１

# はじめに
この記事は、シスコシステムズ合同会社の同士による [Cisco Systems Japan Advent Calendar 2022](https://qiita.com/advent-calendar/2022/cisco) の 22 日目として投稿しています。

2019年からの参加しており今年で4年目になります。これまではラボやCodingを利用した内容メインでしたが、今年は趣向を変えて読み物系の記事にしようと思います。抽象的・散文的でわかりにくいところもあります。それでも読んでいただけますでしょうか。あまり考えても仕方ないので書き始めてしまおうと思います。
いろいろなご意見があると思いますが、年末の軽い読み物としてお楽しみいただけましたら幸いです。

# この記事の内容
[その１]（今回の内容）
- アプリケーションの作られ方
- ネットワークのあり方はどう変わったか
- これから求められるネットワークとは
- NetworkingとComputingとの境目は
[その２]（次回の内容（来年？もっと早いうちに！））
- Service Meshはネットワーク？
- Shift Left & Shield Rightはコンピューティング？
- Edge Computingもあるよ
- Sustainabilityについて

# アプリケーションの作られ方
皆様日々利用されているアプリケーションはどのように作られているのでしょうか。
![Screenshot 2022-12-19 at 20.42.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/feef8774-716e-9b29-e5fc-40466682ecf1.png)
これは一つ一つがマイクロサービスで、その間の依存関係を示したものです。おおよそ一つのアプリケーションに500ほどのマイクローサビスが利用されており、それぞれが依存しあって一つのサービスを作り上げています。

## モノリシックからマイクロサービスへ
さて、アプリケーションの作られ方の話から始めたいと思います。
例えば上記画像には触れられていませんが、タクシー配車サービスの例を考えてみましょう。
![Screenshot 2022-12-19 at 20.31.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/6c55e80c-107b-d0e5-4549-00cf39c200c4.png)
左側は従来型のモノリシックアプリケーションです。各プロセス間のRPCは高信頼が担保されております。
右側はマイクロサービスを用いて各プロセス間をREST APIで接続したものです。各プロセス間のUnderlay Agnosticであるため、インターネット越しでも構いません。信頼性の担保という意味ではモノリシックよりも考慮事項が増加します。

このように右側のアプリケーション開発では従来とは異なる考慮事項（信頼性、遅延、トラブル時の対応など）が存在しています。そして、このようなアプリケーションはこれからも増加していくでしょう。

## 新たなる脅威
では考慮事項とは具体的にどのようなものでしょうか。
![Screenshot 2022-12-19 at 20.41.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/d9c8a57b-0b39-9e5a-fb14-37feed575685.png)
これは、2018年から2021年までに発生したAPIへの主要な攻撃をまとめたものです。
主要なものだけでも7件発生しています。
もちろんこれまでもAPIセキュリティという考慮事項は存在していましたが、現在ではそのAPIがUnderlay Agnosticな故にクラウドをまたいだり、インターネットをまたいだりしているわけです。
このような状況下で新たにAPIセキュリティを考慮する必要があるでしょう。

# ネットワークのあり方はどう変わったか
今度はUnderlayであるネットワーク部分について焦点を当ててみましょう。
ネットワークのあり方はどう変わってきたのでしょうか。
## これまでのネットワーク
これまではネットワークそれ自身が主体でした。接続すること自体に価値がありました。
![Screenshot 2022-12-19 at 21.10.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/d520392f-ad3c-c2fc-5466-6c6da4129d4c.png)
そういった中では、このようにアプリケーションの影響は少ないものでした。

## これからのネットワーク
これからはアプリケーションそれ自身がネットワーク全体へ広がっていきます。アプリケーションとネットワークとの融合が進んでいます。
![Screenshot 2022-12-19 at 21.10.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/9d76d563-637b-3a0b-28e2-b349aa698435.png)
言い換えるとネットワークそれ自体の接続するという価値はアプリケーションの一部として提供され、アプリケーション自身がネットワークを定義するようになりつつあります。

# これから求められるネットワークとは
ではこれからのネットワークに求められる要件とはどのようなものなのでしょうか？
## App Developerとみんなと
ここでまたアプリケーション（開発者）とインフラ（Computingエンジニア、Networkingエンジニア、クラウドエンジニア）の関係性を見てきたいと思います。
![Screenshot 2022-12-19 at 21.32.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/ee91c7dc-38ea-7847-f986-8719fa4276ef.png)
このように、上にみえるアプリケーションは氷山の一角で、その下にはそれを支えるインフラが横たわっているわけです。
## Devops?
アプリケーションによってネットワークが定義されると上記で述べましたが、そんな中で開発者はどのような状況に立っているでしょうか。
![Screenshot 2022-12-19 at 21.32.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/d696547f-b3f5-df76-ff25-094f455965bc.png)
もはや中心的な存在なわけです。Computingエンジニア、Networkingエンジニア、クラウドエンジニアそれぞれがこの開発者の影響を受けます。
![Screenshot 2022-12-19 at 21.32.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/5d3e7268-e2b6-9c90-3a6d-4e12ed340759.png)
さらには、そのアプリケーションはクラウドをまたぐことも当たり前で、インフラはもう振り回されっぱなしではないでしょうか。

## ネットワークに求められる条件
誤解を恐れず言えばもはやこんな状態でしょう。
![Screenshot 2022-12-19 at 21.32.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/44c15277-b6c6-84fe-f020-2df247ebf60f.png)
このようなマルチクラウド環境でアプリケーションによってネットワークが定義される場合、ネットワークインフラに求められることは何でしょうか。少し整理したいと思います
![Screenshot 2022-12-19 at 21.33.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/35ebaa37-1dff-cb59-c1d0-b4f866c70f0f.png)
### 課題 → 解決策の一例
このような流れで4つの課題について見ていてきましょう。
より詳しい解決策の一例は下図で表示しています。

### Connectivity → Automate Connectivity
複数のクラウドプロバイダーやエッジプロバイダーに分散したコンポーネントを接続するにはどうすればよいか？
→ワークロードの種類や場所に関係なく、接続を自動化
### Zero Trust and Security → Segment Workloads
アプリケーションやクライアントの所在地に関係なく、一貫したセキュリティ体制を維持するにはどうしたらよいか？
→DataCenter、SD-WAN、クラウドを一貫したポリシーで管理
### Visibility → Simplify Day2 Operations
分散した実行スレッドと時間にまたがるトレース、ログ、メトリクスを観察、分析にするにはどうすればよいか？
→DataCenter、SD-WAN、ブランチからクラウドまで、エンドツーエンドの可視性を提供し、Day2 Opsを簡素化
### Application Networking → Application Networking
開発者は、アプリケーションの接続要件を伝えるための宣言的な方法を必要としている。
→クラウド/オンプレにまたがるモダンなアプリケーションの迅速なデプロイメント
![Screenshot 2022-12-19 at 22.40.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/cc9f3992-bab2-cd29-2534-0b8c2967c5fe.png)


# NetworkingとComputingとの境目は
NetworkingとComputingとの境目はどこにあるのでしょうか？
NIC(Network Interface Card)が正解？だと思いますが、もう少し詳しく見ていきたいと思います。
## NetworkingとComputigの歴史
歴史について詳しくご説明することは割愛いたしますが、計算機が誕生した頃から計算機内での通信は存在していました。
それが計算機同士を接続するようになり、計算機から何らかの形で情報を出力する・計算機へ入力する方法が必要になりました。
これがComputingとNetworkingとの始まり・境目の始まりです。
## 集約と分散
このComputingとNetworkingとの境目は通信技術の発達とともに新技術が利用されるようになりました。
無線通信、シリアル通信、Ethernet通信など様々な通信方式が存在しています。
![（出典）総務省（2022）「デジタル社会における経済安全保障に関する調査研究」](https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r04/image/n1001010.png "（出典）総務省（2022）「デジタル社会における経済安全保障に関する調査研究」")
（出典）総務省（2022）「デジタル社会における経済安全保障に関する調査研究」
![インターネットの普及の推移と主要なコミュニケーションサービスの開始時期](https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r01/image/n1101140.png " インターネットの普及の推移と主要なコミュニケーションサービスの開始時期")
インターネットの普及の推移と主要なコミュニケーションサービスの開始時期

## 今は分散フェーズ？集約フェーズ？
これらの通信技術は集約と分散を繰り返しながら発達してきました。集約フェーズでは非力な端末ではなく、高性能なホストコンピュータにすべての処理をさせ、結果として通信量が削減されるというフェーズです。分散フェーズでは各端末で分散的に処理を実施するため、通信量は爆発的に多くなります。
現在はこれらが共存していますが、今後はどちらに進んでいくのでしょうか。後続（その２）のEdge Computingの章で考えてみたいと思います。

## 境目はどこに？
境目を考えるときに考慮すべき技術として仮想化が挙げられます。
Computingの仮想化技術が広く知られているかと思いますが、それに伴うNetworkingの仮想化も重要です。
Virtual Machineの分野ではOVS(Open VSwitch)などがそれにあたりますが、OVSからNIC(Network Interface Card)への接続、NICから外部への接続と、仮想化によりComputing内にNetworkingが進出してきたように思いますが、すべてCPU処理するというわけではなく、NIC（ハードウェア）の役割は依然として重要です。DPDKやPassthroughなどという技術が用いられました。
![Screenshot 2022-12-21 at 3.31.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/225355/86b50306-890a-bc92-49a9-9d5326af76d7.png)
次に、コンテナ技術を考えてみます。コンテナではCNI(Container Network Interface)がNetworkingの仮想化に重要な役割を果たします。CNIは様々な種類がありますが、CPUだけで処理するものやACI-CNIのようにハードウェアに処理をオフロードできるものもあります。オフロード対象としてDPU(Digital Processing Unit)を備えたいわゆるSmart NICというものも登場しており、このレイヤもGPUベンダなどNetworkingと遠そうだったプレーヤーも参入しようとしています。

# まとめ
- アプリケーションの作られ方
    - アプリケーションはモノリシックからマイクロサービス移行し、新たな考慮事項が発生
- ネットワークのあり方はどう変わったか
    - アプリケーション中心のネットワークへと変容した
- これから求められるネットワークとは
    - アプリケーション中心かつマルチ・ハイブリッドクラウドへ対応するための４つの課題
- NetworkingとComputingとの境目は
    - 仮想化・コンテナ技術により境目がComputingに入り込んできている


# Reference
- [アプリ開発者がネットワークに出会ったら？ スキルを活かして可能性を広げよう【デブサミ2020夏】
(https://codezine.jp/article/detail/12691)
    - ネットワークとアプリケーションの垣根について掲載されております。
- [総務省：令和4年　情報通信に関する現状報告の概要]
(https://www.soumu.go.jp/johotsusintokei/whitepaper/r04.html)
- [総務省：令和元年　情報通信に関する現状報告の概要]
(https://www.soumu.go.jp/johotsusintokei/whitepaper/r01.html)

# 免責事項
本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本 Web サイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本 Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。

<!-- 
# Service Meshはネットワーク？
## Service Meshという考え方
## Container Layerのネットワークと呼べるか？
## MessagingとService Mesh
### Kafka Brokerの話
### メッセージングはネットワークか？

# Shift Left & Shield Rightはコンピューティング？
## Shift Leftとは？
## Shield Rightとは？
## セキュリティってなんだっけ？
### 複数レイヤのセキュリティ

# Edge Computingもあるよ
## Edge Computingって？
## Application Layerの話もある
### Kubeflow
### Greatbear

# Sustainabilityについて
## そもそもなぜSustainability?
### どう考えたって電力が足りない！？
### だったらそもそも電力減らすしか無いよね
## 電力が利用される場所
### どのような取り組みがある？
## 電力削減だけではない
### CO2吸収ビジネス
## そもそもガス田では古くから
## 最近はDACも活発
-->