Murga

個人的に言いたいコト・主張・気持ち。

いよいよ図の方が大事な気がしてきた

以前こんな記事を書いた。

neos21.hatenablog.jp

図に起こした方が分かりやすい場面は多い。しかし、テキスト情報がないと、ググラビリティ (検索容易性) が低いと思う、という話だ。

ググラビリティは確かに低い。しかし、文字で示した情報って、そこまで大事なんだろうか?と、最近思うことが増えてきた。

主にインフラ構築をしていてそう思うようになったので、他の分野ではまた違うと思う。見方の一つとして書き残しておきたい。


コーディングにおいては、宣言的であることが保守性も高まる。だから Kubernetes や Terraform がもてはやされるのだろう。機械にやらせたいこと、実現させたいことをテキストで明示しておけば間違いないっしょ、という。実際のところ、設定ファイルを書こうという段階になって困るのは、DSL (独自記法) と API (何がどのように書けるのか) を調べるところだけで、記法と API が一度分かれば、「アレをこうしたい」をコーディングするのは誰だってできる。

図の重要性はその前段。「そもそも何を作るか」「それを構築した後どうしていきたいか」というところの情報を共有する時だ。

クラウドサービスを使うと、全てが仮想技術の上に成り立っていて、なかなかイメージが持ちづらい。だから「アベイラビリティドメイン」だの「サブネット」だの「ロードバランサー」だの「インスタンス」だのといったアイコンを並べて絵を描く。そいつがどこの何であり、誰と関係があるのか、どの概念と違うのか、といったことは、図を見た方が理解が早い。

この「概念的な理解」こそが、それに関わる人間にとっては重要なことだ。構築する際にどんなスクリプトを書けばいいのかなんて、この先どんどん自動化ツールが出てきたり、AI が勝手にやってくれるようになったりして人の手を離れていくはずだ。仮に人間が設定ファイルをほとんど書かなくなった時に、それでも必要なのは、「結局のところ何が行われているのか」という概念を理解しておく力だと思う。

どれだけ技術が発達しても、根幹でやっていることはそう変わらない。HTTPS だろうと Tor だろうと、物理的なモノに近付けば近付くほど、「結局それは何であるか」という抽象化した理解が重要になる。そして抽象的な概念を理解するのにはやはり「図」がてっとり早いのだ。


「こんなことができるシステムが欲しいなぁ〜」といっちょまえに抜かしたくせに、いざ構築されたシステムの画面を見ると、「下手に触ったら壊れるかもしれなくて怖い」「何を触ったらいいのか分からない」などと言ってくる非エンジニアな顧客もいたりする。

そういう人がいるのはそれで仕方なくて、そんな人達に何ができるかというと (そもそも直感的に使える UI で組むことは勿論として)、そのシステムの使い方を分かりやすく説明する資料が必要になる。取扱説明書だ。

何かを理解してもらって、それを使えるようになってもらう。そんな時に必要なのは、

  • 「このボタンを押したら何が出てくるから何を入力する…」

といった説明文章ではなく、

  • 「この画面!」(スクショ)(でっかい矢印記号)「このウィンドウ!」(スクショ)

という、超簡単な「紙芝居」を見せれば十分なのだ。

何をすると何が起こる、とか、コレをしたい時はココを押す、とか、そういう情報を文字情報で理解できる人というのは、実は少ない。彼らに対して、いくら丁寧に説明文章を書いてあげたとしても、きっと読めない。彼らは「読めそうにない」と思うと、たとえ重要なモノであっても読まないのだ。そんな人を相手に仕事するのは本当に嫌だが、文句を言っているだけでは何も変わらない。

じゃあ彼らは何なら理解できるのかというと、紙芝居だ。図と図が矢印で結ばれていたり、何かのアイコンと何かのアイコンが括られていたりするペライチの説明資料を見ると、理解できた気になって喜ぶのだ。

実際のところ、彼らは何も理解できていない。そのボタンを押して開かれるのが「モーダルウィンドウ」と呼ぶことも、「テキストボックス」と「テキストエリア」の違いも、システムが裏側でどんな入力チェックをしているかも、何も分かっていない。

でもそれでいいのだ。彼らに分かった気にさせられれば、後は勝手に触り始める。そして「あれ、この『電話場号』入力欄にアルファベットをいれるとエラーになるぞぉ?」などといって試行錯誤しながら身体で覚え始める。


図を使って説明するというのは、何ら体系的でもなく、共通認識が取れているのかどうかも分からない。僕個人の感覚で言えば、図だけでは分かった気にはなれない。しかし実際は、図さえ見れば、何らか分かった気になってくれる人が多くて、「自分たちは分かり合えた」と思えるらしい。

一方、正確に分かってもらいたくて、文章で説明するとどうなるか。文量が多かろうと少なかろうと関係なく、「イメージが湧かない」ことで動けない人は多い。いくらその文章をアウトプットするのに労力を使ったところで、相手に受け入れてもらえないと効果がないのだ。

図と文章。どっちが「相手を動かせているか」(実際の効果を出せているか) でいくと、多少不正確だろうと、図の方が圧倒的に伝わりやすく、効果的なのだ。


テクノロジーの話でいえば、これからは文章すらも人間が頑張って書かなくて良い時代が来ると思う。今ですら「設定ファイルジェネレーター」みたいなものは山程あるし、AI が発達してくれば、本当に人の手を一切加えることなく文章ができあがる時代が来るかもしれない。

それに対して、抽象的な概念の関係を描いた「図」なんかは、機械がその意味を読み取るのはかなり困難である。2枚の画像ファイルが矢印で結ばれているから何だというのか。でも人間はそれを「遷移図」として読めるし、その図を基にそのシステムを使った業務が遂行できるようになったりする。

個人的には未だ違和感が拭えないが、どうも「図」「イメージ」というものは、物凄く簡単に人を動かせるツールであり、「文章」「ドキュメント」というのは、それと比べると効果がないようだ。正確性も検索容易性も、図の方が劣ると思うのだが、人間により重要なのは「大局的に理解できること」なようで、その方が仕事を回せる場面が多いんだな、と思う。

…文章で書くとまとまりがなくて何を言いたいんだか分からなくなってしまった…。

図で考える。シンプルになる。

図で考える。シンプルになる。

Kubernetes とか XaaS とかの概念整理

Kubernetes の概念の理解が大変だったので、雑多にまとめる。また、コレに関連して「XaaS」(「なんたら as a Service」系) の話も、自分が調べた範囲でまとめてみる。

Kubernetes 全般

  • Kubernetes は、1つの Master Node が統制を司り (マスター)、複数の Worker Node がその下で動く (スレーブ)。
    • Kubernetes と書くのが長いので K8s と略して書かれたりする。読み方は「クバネテス」「クーバーネイティス」あたり。よく分からん。
  • そもそも Node とは何を指しているかというと、1台のサーバマシンのこと。クラウド時代なので VM (仮想マシン) の場合が多いが、イメージ的には「1台の物理的な PC」を「ノード」と考えて良い。
    • 全体を管理するマスターのパソコンと、その下で冗長構成を取る複数のワーカーパソコンがいる、という感覚で良い。
  • 「Kubernetes クラスタ」というと、Worker ノードが複数いる環境・状況を指す。「クラスタ」はブドウの房のこと。何かいっぱい付いてる感。
  • kubectl は Master ノードの API Server に対して命令を送るコマンド。Worker ノードへの変更なども Master ノードを経由して実現されている。
  • Worker ノードには1つ以上の Pod と、Master と通信するための kubelet というプロセス、Docker などを動かすコンテナランタイムが同梱されている。
  • Pod はデプロイの単位。Kubernetes の構成要素の中で最小単位。
    • 大抵は1つの Pod に1つの Docker コンテナを格納させて使うことが多いので、「1 Pod = 1 Container」とみなせる。
    • しかし、1つの Pod に複数のコンテナを持たせることもできる。その際は kubectl exec 【Pod 名】 --container 【コンテナ名】 といったコマンドを叩くことで、1つの Pod 内の Docker コンテナを指定してアクセスすることになる。

マネージド Kubernetes サービス

  • Master ノードに対する各種のインストール作業や、ネットワーク周りの設定をよき感じに自動化してくれたり、フォローしてくれたりするクラウドサービスが、「マネージド Kubernetes」。Google の GKE とか AWS の EKS とか。
    • 僕はいきなりマネージド K8s から入ってしまったので、未だに etcd とかなんとかがよく分からない。実体を見ずに使ってしまっている感がある…。
  • マネージド K8s だと、Node Pool という言葉が出てくる。コレは、Worker ノードをスケールさせるための機能。
    • deployment.yaml を設定して Pod 数をスケール (増減) させるにしても、Pod (Docker コンテナ) を複数動かす Woker ノードのマシンスペックは超えられない。
    • 物理的にマシンを増やしてスペックを上げたいね → Worker ノードを増やしたいね。ということで登場するのが、ノード・プールという機能。
    • 予め「こういうスペックのワーカーノードを増やしたい」という設定をしておくと、クラウドサービスがいい感じにインスタンス (≒ ワーカーノード) を作ったり消したりしてくれる、というのがノードプール。
    • サービスによっては各ノード (= ワーカーノード) のスペックが違ったりしても上手く協調できるようにしてくれる。よりスケーリングしやすいね、という話。

サーバレス・FaaS

  • マネージド K8s は IaaS がメインになる。
    • Kubernetes 自体はコンテナを使うので CaaS (Container as a Service) なんて言われることもあるが、その実行環境をクラウドに用意するとなると、IaaS が多いかな。
    • 「空っぽのサーバマシンを貸してあげるから好きに設定して使ってね」というのが IaaS (Infrastructure as a Service)。
    • 仮想化技術を使って、1つの物理サーバ内に VM (仮想マシン) を立てて、それが提供されることが基本。昔からある安価な「レンタルサーバ」とよく似ている。
    • 「ベアメタル」という、専有マシンを借りられるサービスもある。昔からある「専用サーバ」というヤツがクラウドサービスとしてより迅速に・便利に提供されている、って感じ。
  • サーバレスというのは、サーバやインフラの管理をクラウドに任せられる、という意味。
  • サーバレスの考え方・仕組みを発展させたのが FaaS (Function as a Service)。
    • あるイベントに応じて、「この関数を実行する」という設定をするだけ。
    • イベントが発生するごとに仮想コンテナが生成され、関数の実行が終わったらコンテナは破棄される。
    • 実行に必要なサーバはサービス側で自動的にスケールされる。
  • PaaS (Platform as a Service) は HTTP リクエストに応じてアプリケーション全体を起動する。FaaS は必要なサービスごと・関数単位で起動・停止を管理できる違いがある。
    • IaaS が一番広く OS や VM・ネットワークから使える。PaaS はアプリの実行環境。FaaS はスクリプトの実行環境。ぐらいの提供範囲が違う。
  • FaaS はイベントドリブンなので、どれだけ高速に処理されるとしても、コンテナの起動に時間がかかる点が気にされる。負荷量が頻繁に変わるようなイベントの場合は、クラウドサービスに任せてスケーリングできるのが便利ではあるが、一つの処理を高速に行うことを追求するなら IaaS になっていくことが多いかも。

参考資料

Kubernetes実践入門 プロダクションレディなコンテナ&アプリケーションの作り方 (Software Design plusシリーズ)

Kubernetes実践入門 プロダクションレディなコンテナ&アプリケーションの作り方 (Software Design plusシリーズ)

  • 作者: 須田一輝,稲津和磨,五十嵐綾,坂下幸徳,吉田拓弘,河宜成,久住貴史,村田俊哉
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/03/02
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る