44
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

クラウド時代の身近な用語「ワークロード」とはいったい何なのか?

Last updated at Posted at 2022-10-24

今日は小ネタ的なお話です。
この記事を読んでもAWSやGCPのスキルが身につくわけではありませんので、ご注意ください。

■はじめに

AWSやGCPなどクラウド基盤について学んだり調べたりしているとしばしば目にすることになる用語に「ワークロード」(workload)があります。この言葉の意味を皆さんは同僚や後輩に説明できますか?

私はできなかったので調べてみたところ、AWS公式のリファレンスでは次のように説明されていました:

リソースと、ビジネス価値をもたらすコード(顧客向けアプリケーションやバックエンドプロセスなど) の集まり

OK。これで意味がわかりました。でも問題はここからです。

■それって同じ意味?

SAA資格をお勉強されている方であれば、参考書の冒頭付近に「ワークロード≒システム」という趣旨のことが述べられているのを思い出した方もいらっしゃるかもしれません。たしかにAWS公式の定義からすれば「それって、つまりシステムだよね~」となるのは頷けます。

ところがこの用語を一般的な辞書で調べると 「ある個人や組織が完了させなくてはならない作業の総量」 みたいに説明されています。仕事(work)の負荷(load)。これはこれでわかりやすい。
そしてIT系の用語辞典で調べると 「コンピューターやシステムにかかる負荷の大きさ、CPUやメモリの使用率」 みたいに説明されている。一般用語としてのワークロードと地続きだとわかります。

さて、これを参考書の記述と合わせると 「ワークロード=システムにかかる負荷=システム」?? ということになる。循環的でややこじつけ気味な説明に陥っています。。。「ワークロード≒システム」と言いながら、なぜあえて別の用語を使用するのでしょうか?

■文脈が変わった

この問題について社内でインフラチームの方たちと会話していて気がついたのは文脈の変化です。変化の原動力は「仮想化」と「クラウド化」です。

●第1段階:「仮想化」以前の時代

仮想化以前、システムはサーバールームやデータセンターに配備された物理マシンの上で直接稼働していました。キャパシティ/制約となるのは物理マシンであり、そこに負荷を与えるのは当該マシン上で稼働するアプリ(コード)です。

ワークロード = 物理マシンに直接かかる負荷 = 物理マシン上で動くコード

image.png
▲アプリ(コード)は作業量に応じてスケール。物理マシンはスケールしないのでキャパシティ/制約を規定。

●第2段階:「クラウド化」以前の時代

仮想化以後、システムは物理マシンで動くハイパーバイザー(仮想化基盤)の上に配備された仮想マシンの上で稼働するようになりました。
キャパシティ/制約となるのはハイパーバイザーの稼働する物理マシンであり、そこに負荷を与えるのは当該サーバー上で稼働する仮想マシンや仮想マシン上で動くアプリ(コード)です。

ワークロード = 物理マシンにかかる負荷 = 
仮想マシンとそれにかかる負荷 = 仮想マシン上で動くコード

image.png
▲ハイパーバイザー(物理)がキャパシティ/制約を規定。その内側のアプリが稼働するマシン(仮想)はある程度柔軟にスケール。仮想マシン+アプリがワークロードに。

●第3段階:「クラウド化」以後の時代

クラウド化後、システムはクラウドベンダーが提供する膨大な数のハイパーバイザーとそれを基盤とするSaaSの上で稼働するようになりました。
理屈上、キャパシティ/制約となるのはクラウドベンダーが運用する物理マシン群ですが、膨大過ぎてもはや論点になりません。
負荷を与える側も夥しい数の仮想マシンやコンテナやSaaSを土台として稼働する多数のサービスからなるシステムになりました。

ワークロード = 膨大な数の物理マシンにかかる負荷 = 
仮想マシンやSaaSとそれにかかる負荷 = 
「リソースと、ビジネス価値をもたらすコード…の集まり」

image.png

▲クラウド基盤を成り立たせる物理インフラがキャパシティ/制約を規定するものの・・・もはやユーザー開発者の目に見えない状態。仮想マシンやコンテナやコードやSaaSからなる「システム」がワークロードに。

キャパシティ/制約を規定し負荷を測る対象となる物理的な基盤がエンジニアから疎遠で不可視なものになる一方、必要に応じてスケールするアプリ(コード)は質・量ともに肥大化した。
すると、先程の等式で「ワークロード」と「ソースと…コード…の集まり」の間にあった 「= 膨大な数の物理マシンにかかる負荷 = 仮想マシンやSaaSとそれにかかる負荷」 が抜け落ち(存在感が低下し、遠方に霞んで)、 「ワークロード」「ソースと…コード…の集まり」 が直に結ばれるわけです。

ワークロード =  
「リソースと、ビジネス価値をもたらすコード…の集まり」

■わかること、わからないこと

ここまでお話してきたことはあくまでも私の考えです。
そういう考え方もできるのでは?ということです。

所詮はその程度のものなのですが、でも「わかったようなわからないような」用語について自分なりに考えが整理できると、それを土台に人に説明をしたりより高度な話題について考えることができるようになります。

わかること・わからないことを整理しながら一歩ずつ学んでいく。なんでもかんでも気になったワードに齧り付いていくわけにはいきませんが、時折こうした概念的な作業をしてみるのはオススメです。

44
26
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
44
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?