認知負荷理論で挑むPlatform Engineering：サイボウズにおけるKubernetesプラットフォームの拡大に向けて

それでは認知不可理論で挑むプラットフォームエンジニアリング
サイボーズにおけるKubernetesプラットフォームの拡大に向けて
土台しましてサイボーズの池添と山田から発表させていただきます
まず簡単に最初自己紹介からさせていただきます
私がサイボーズの池添ですね
Kubernetesをベースとしたインフラ基盤の開発に従事しておりまして
最近はプラットフォームデベロッパーエクスペリエンスという
新しいチームを立ち上げてプラットフォームエンジニアリングの推進の方を行っております
あとはKubernetesのカスタムコントローラー関連の情報をいろいろ発信しておりまして
作って学ぶクベビルダーなどそういったものを公開しております
私がサイボーズの山田と申しますよろしくお願いします
大学と大学院の修士課程で認知不可理論を引用した心理学研究を行っていました
新卒でグループへのカスタマーサクセスで働いた後に
サイボーズに転職してクラウド基盤のQAを経て
現在池添さんと同じくPDXチームに所属しております
こちらの前の記事で認知不可理論との解説書とか書いていただいたので
もしかしたら見ていただいた方もいらっしゃるかもしれません
あとこの記事きっかけですね
ちょっと消費者さんからお声掛けいただいて
今認知不可理論とエンジニアリングを接続する書籍を
LINEやふー株式会社の高田新三さんと出筆中ですので
そちらも近々お届けできればと思っております
はい
早速内容に入っていきたいと思います
まずはじめに皆さんに質問です
まずですね
認知不可や認知不可理論という言葉を見聞きしたことは皆さんあるでしょうか
はい
で
あすみませんありがとうございます
そうですね
プラットフォームエンジニアリング会議にいらっしゃる方の多くは
もしかしたらご存知かなと思っておりました
ではその認知不可というのは果たして下げるべきものなのでしょうか
そしてその認知不可を下げた後というのは一体どうするのが良いのでしょうか
はい
こういった問いに今回の発表では答えていければと思います
本発表の概要といたしまして
プラットフォームエンジニアリングの分野でも
既に紹介した通り認知不可理論というものはよく言及されております
そして認知不可というものは下げるということに着目されがちなんですけれども
負荷を下げるのはあくまで過程でありまして
本来的にはその先の深い学習を達成することが目的となっています
そしてサイボーズでのプラットフォーム構築と運用の経験から
この見逃されがちな観点への意識が
プラットフォームエンジニアリングでも同様に有用であることを
本発表を通して提案したいと思っております
目的はこちらの3小構成となっております
はじめに認知不可理論の基礎を改めて解説いたします
その後認知不可理論×プラットフォームエンジニアリングとして
プラクティスの一部を認知不可理論の観点で改めて解釈します
最後にサイボーズでの実践例を紹介いたします
それでは早速第1小認知不可理論の基礎から
ご存知の方もいらっしゃるかもしれませんが
改めて紹介いたします
まず認知不可理論というものはどういったものかというと
認知科学教育心理学の分野でもともと発展しました
最初の研究というのは教育心理学者であるジョン・スウェーラー氏による論文で
こちらコグニティブサイエンスという論文誌
認知科学ですね
こちらに掲載されておりました
1988年の論文となっております
こちらは人間にとってのランダムアクセスメモリーのようなものである
ワーティングメモリーというものがあるんですけど
こちらの能力と限界に着目して
効果的な学習デザインを探るために考えられたものです
情報処理を皆さん日々今もされていると思うんですけど
そういったときにワーティングメモリーという
人間にとってのメモリーが圧迫する負荷
これを認知負荷と呼びますが
この負荷を3種類に分類して
それぞれをコントロールする方法を研究しました
右の図のように3種類の負荷が
それぞれワーティングメモリーに対して占めていって
容量があふれると思考がパワーになっちゃうというか
そういう感じですね
そしてその3種類の負荷というものがこちらになります
1つ目が課題外在的負荷と呼ばれるもの
こちらは理解や目的に無関係な要因による余計な負荷です
無関係なので完全にできるだけ削減すべきものです
例えばツールを達成して何かをしたいんだけど
そもそもそのツールのインターフェースが使いにくいために生じてしまうような負荷です
2つ目が課題内在的負荷で
こちらは課題そのものの複雑さから生じる負荷です
これはその対象を理解するためには避けられないものとなっております
例えば新しいプログラミング言語の文法を理解する際に
その文法そのものの難しさによって頭を悩ませているとき
そういうときに生じる負荷ですね
そして最後が学習関連負荷で
こちらはちょっと他の2つと属性が違います
こちらは知識を定着させて理解を深めるための処理で生じる
生産的な負荷となっています
なのでこちらは積極的に発生させるべきで
例えば習得した文法を使って何かの問題を解決しようと
試行錯誤している際に
深い処理を行っている際に生じる負荷となります
そしてもともと認知負荷理論というのは
効果的な学習デザインを探るためのものという紹介をしました
ではここでいう学習とは何かというと
豊かなスキーマの獲得というふうにざっくり定義されています
スキーマというのは右の図にちょっと小さいので
表したような知識のネットワークのようなものです
ここでは発表のためにちょっと割愛しますが
一応諸説あります
例えば右の図だとコンテナ
右上の方にコンテナの知識群があって
ちょっとコンテナから
KubernetesのPodとかネームスペースとか
っていう知識群がつながっているというのもしております
ある分野に熟達している人は
その分野のスキーマが豊かと言われています
そしてスキーマの利用
つまり思い出したりする
応用しようとするという時は
断片的な知識
データのフラグメントみたいなものですね
こちらをバラバラに想起して利用するよりも
認知負荷が小さくなると言われています
最近かなり
もう1700ぐらいいいねがついていた
ココナラさんの全の記事がありまして
こちらをご覧になった方も多いんじゃないかと思うんですけど
この記事
プログラミングにおけるスキーマ獲得による変化を表す
とても良い記事なので
ぜひこの発表やこのカンファレンス終わった後読んでみてください
同じ5行のコードが全く違って見える12の瞬間
なぜ私たちは学ぶのかという記事でした
冒頭のみちょっと引用させていただきます
このようにJavaScriptの5行の関数ですね
たった5行の関数で
GetUserNameという名前が付いていて
ユーザーIDを引数に取ります
そしてユーザー.nameをリターンしています
プログラミングを学んだばかりだと
普通にGetUserNameする関数だなって思うだけなんですけど
これが例えばこの記事中だと
エラーハンドリングを学んだ人だったら
エラーハンドリングしてないけど大丈夫なのかな
型システムというか型を学んだ人なら
型情報ついてないけど大丈夫かな
といったふうに
その人がどんどん学んでいってスキーマを獲得することで
同じものに対しての解像度
見え方というのが変わってくる
というような話が展開されております
話を少し戻しまして
では認知負荷3種類あると言いました
これらの種類に応じた対応は
どのようなものがあるかというと
課題外責的負荷
これ完全に無関係で余計なものなので
シンプルにできるだけ減らすのが望ましいです
そして内在的負荷は学習内容に固有なので
直接減らすことはできません
ただし先ほどのようなスキーマを獲得していくことで
スキーマを思い出すのって
断片で身についてないような知識を
頑張って思い出すよりも
負荷が小さいという話がありました
それによって情報量圧縮できるので
間接的に減らすことができます
例えばKubernetesを学ぶ際に
コンテナも知らない人よりも
コンテナのことをちゃんと学んだ人の方が
その辺りの知識を圧縮できるので
少し減らせるといったような形ですね
あとは課題の提示方法によっても
相対的に負荷を下げられます
一つ言われるのが
諸学者には詳細な説明
熟練の人には要点を捉えた
簡潔な説明が効果的などと言われていて
これが面白いのが
逆にするとかえって負荷が高まる
といった効果があります
こちらは私の前の記事とか見ていただけると
ちょっと書いてあるので
後で見ていただけると幸いです
最後の学習関連負荷は
これ生産的なのでできるだけ増やす
という形になります
ただモチベーションなど
午前のキーノートでもあったんですけど
外発的動機づけとか内発的動機づけとか
ああいうところが絡んできて
コントロールが難しいので
まだ議論が多い分野です
こういった特性に注意して
段階的にスキーマを構築していくことが
重要とされています
段階的といったんですけど
スキーマというのは原則的に
一足飛びには豊かにはなりません
学習者の段階を見極めて
ワーティングメモリから
溢れない程度の認知負荷に
コントロールするのが大事です
筋トレも
自分がいけるギリギリの負荷でやるのが
一番筋肉が成長するみたいな話ですね
あまり負荷かけすると壊れちゃうし
軽い負荷だと訓練にはなるけど
成長しないというような感じですね
小学生はスキーマの構築ができていないので
知識一つ一つが負荷になってしまいます
中級者は構築されていっているので
ある程度の知識のまとまりは
1単位として扱えて
ちょっと負荷が下がっていきます
熟達者は豊かなスキーマと
その利用の自動化まで達成できている
こういった違いがあるので
それぞれに応じた
コントロールが必要となります
先ほど原則一足飛びに豊かにならないと言いました
あくまで原則なので
実は一足飛びに豊かになるケースもあります
皆さんも2つ目以降に学習したプログラミング言語というものは
1つ目より習得が容易ではなかったでしょうか
習得したスキーマの利用というのは
認知負荷が小さいという話がありました
車も初め
他のびっくりいろんな手順を考えながら
運転していたのが
もう無意識にできるようになって
全然他のことも考える
頭の余裕ができているみたいな状態ですね
これは1つ目の言語のスキーマというのが
転移というふうなことが起きて
転移されて獲得済みの知識をベースに
学習を進められた結果と説明されます
なのでスキーマの獲得というのは
単に認知負荷を圧縮するだけじゃなくて
類似の分野の学習にも寄与すると言われます
豊かなスキーマの獲得というのは
労力がかかる
初めに深い理解をして
いろんな情報を結びつけて
自分の頭の中で頑張って考えて理解をする
これは労力がかかることなんですけど
一度豊かなスキーマが獲得できると
適切に転移などできれば
2つ目の言語3つ目の言語はもっと早く学べるといったように
加速度的な学習曲線を描きやすいと言えます
ここまでのまとめを行います
認知負荷理論というのは
ワーキングメモリーに係る3種の認知負荷をコントロールして
豊かなスキーマの獲得を促すことを目指した理論です
認知負荷への対応は
外在的負荷と内在的負荷は減らし
関連負荷は増やすのが望ましいです
そしてそうやって獲得した豊かなスキーマは
該当分野の処理を効率化し
かつ隣接分野の学習も促進してくれるものとなります
ではここから池添に交代します
ここからはではこの認知負荷理論を
どのようにプラットフォームエンジニアリングに
適用していくのかというところについて
お話ししたいと思います
CNCFのプラットフォームホワイトペーパーなんかを見ると
プラットフォームエンジニアリングの目的として
ユーザーの認知負荷を軽減するということが書かれています
あらゆる詳細をカプセル化して
複雑性をあらゆる複雑性を隠蔽すべきです
というふうに書かれています
ですが本当にこのあらゆる複雑性を隠蔽してしまっていいのでしょうか
というところに我々は疑問を持ちました
プラットフォームエンジニアリングの文脈では
よく認知負荷を軽減するということは言われるんですけど
実際にその認知負荷を全部軽減してしまって
適切なスキーマを獲得できなくなってしまうと
いろいろな問題が起きてしまいます
例えばユーザーは提示された方法でのみしか
プラットフォームを使えなくて
自分たちで何か新しい仕組みを考えて
使い方を考えて探求するということができなくなってしまったりとか
あとはプラットフォームチームとユーザーの間で
ちゃんと同じスキーマが構築できていないと
コミュニケーションに疎後が発生したりします
ですので何か問題が起きたときにどういうふうに質問すればいいのかとか
どういった機能が新たに欲しいのかとか
そういった依頼も出せないとか
そういった問題も起きてしまいます
あとは実際にアプリケーションを運用しているときに
何か問題が起きたとしても
ちゃんとスキーマが構築できていないと
その原因を調査できないというふうになってしまいます
というわけで我々はもう
プラットフォームエンジニアリングにおいても
認知負荷というのは単純に減らせばいいというものではなくて
このプラットフォームを適切に学習するために
スキーマを構築していく必要があるんじゃないか
というふうに提案したいと思います
前半のほうでもお話ししましたが
この認知負荷には3種類あるという話をしました
例えば課題外在的負荷ですね
これはプラットフォームを利用する上では
本来必要のない負荷ですね
例えばPodをデプロイするために
何か申請を出さないといけないとか
本当に全然関係のない負荷ですね
こういったものは可能な限りなくす必要があります
課題内在的負荷
これはプラットフォームそのものの複雑さですね
Kubernetesの仕組みであるとかGitOpsの使い方とか
そういったものですね
こういったものは直接なくすことはできないんですが
ユーザーを支援してしっかりとスキーマを獲得してもらうという取り組みが必要になります
最後の学習関連負荷ですね
これに関してはプラットフォームをちゃんと理解してもらって
さらに応用的に活用してもらうというところになります
この負荷はできるだけ上げていけばいいということになるので
プラットフォームすごく使いやすいし
信頼できるのでどんどん使っていこうという
モチベーションアップを図るようなところですね
こういったことをしていかないといけないと考えております
オライリーのプラットフォームエンジニアリング本なんかを見ると
このプラットフォームエンジニアリングのいろいろなプラクティスが紹介されているんですが
それぞれがこの認知負荷に対するいろいろなアプローチに
つながっていくのかなと思っています
例えばこの課題外在的負荷を減らすために
厳選した機能を提供するであるとか
抽象化レギアを提供するであるとか
こういったことでユーザーとは関係のない処理を隠してしまうというところですね
あとは課題内在的負荷を軽減するために
ナレッジ共有であるとか
テンプレートを提供するとか
ガードレールを整備するとか
ユーザーの習熟度に応じていろいろな
段階的に知識を得てもらうというような取り組みが
必要かなと思います
最後の学習関連負荷に関しては
セルフサービスのインターフェースを用意して
ユーザーが自由にいろんな設定をできるようにしておくとか
あとは安定運用やサポートをしっかりして
プラットフォームの信頼感を得る
こういった取り組みが必要になるのかなと思います
ではこういったことを実際
サイボーズではどのように適用しているのかというところを
ご紹介したいと思います
その前にサイボーズの現在のプラットフォームの事情をお話ししますと
サイボーズでは今オンプレミス上で
1000台以上のサーバーを使って
非常に大きなKubernetesクラスターを構築して
それを複数のチームが
マルチテナント環境で利用する
というような環境になっています
古いプラットフォームの方
VMを使った古いプラットフォームから
新しいKubernetesのプラットフォームに
アプリケーションを移行しているという段階です
同時にDevOpsも推進していまして
開発チームがアプリケーションの運用も
担うようになってきています
詳細についてはサイボーズのブログの方でも紹介しておりますので
興味のある方はぜひご覧ください
そうですね
サイボーズでもいろいろな取り組みをしていまして
この課題外在的負荷を減らすために
Kubernetesをベースとした中小化レイヤーを提供したりであるとか
いろいろなサービスですね
データベースであるとか
オブザーバビリティのようなサービスと提供したりであるとか
あとは問い合わせ窓口をきちんと整備したり
ドキュメントを集約したりですね
こういったことをやったりしています
課題内在的負荷を減らすためにも
チュートリアルであるとか
高度な活用のためのドキュメントを整備したりとか
あとはユーザーの習熟度に応じて
いろいろな支援をしたりとかもしています
あとはですね
ガードレールをしっかり整備して
変な使い方をしても
アプリケーションが危険な状態にならないように
セキュアな状態でデプロイできるような仕組みを
用意したりもしています
最後の学習関連負荷のところに関しては
セルフサービスのインターフェースを用意したりであるとか
繰り返しになりますが
安定運用を心がけたり
いろいろなユーザーからの依頼に
細かく対応するというような形で
信頼を得るということをやっております
そうですね
もう少し詳しく見ていきますと
まずはこのマルチテナントKubernetesという形で
Kubernetesクラスターを提供しています
こちらはチームごとに
きちんと権限が分離された環境を
提供するようなものになっていまして
開発チームがプラットフォームチームに対して
このKubernetesクラスターを使いたいよというふうに
予防を出すと
あとは開発チームは自由に
このArgo CDであるとか
テレポートであるとか
Grafanaといったツールを使って
環境にアクセスすることができるようになります
またこのネームスペース上に
自由にデプロイもできるようになりますし
カスタムリソースを使って
いろいろな機能
ストレージであるとか
データベースであるとか
いったものも使えるようになっていて
ほとんどの機能が
セルフサービスで使えるようになっています
ガードレールとしては
バリデーションであるとか
Rバックであるとか
そういったものをきちんと設定しているという環境になります
Kubernetesというのは
Kubernetesの標準リソースを使って
ネットワークであるとか
ストレージであるとか
そういったものを隠蔽してくれているんですが
さらにカスタムリソースというものを使って
いろいろな拡張ができるようになっています
そのカスタムリソースを使っていろんな処理を自動化したりやるとか
例えばMySQLのようなデータベース
そういったものを管理するオペレーターですね
オペレーターを作って
MySQLの管理を自動化したりしていて
ユーザーからはカスタムリソースを利用して
それを使うだけという
そういった環境を提供しています
こうすると
開発チームは
この統一されたメンタルモデル
同じような使い方
Kubernetesの標準リソースと同じような使い方で
いろんな機能を使えるという形になっていて
非常に統一されたインターフェースで
分かりやすいという形になっています
Kubernetesって本当に適切な抽象化なのかという話も
よくあるんですが
我々は実際にKubernetesを運用してみて感じるのは
DevOpsをやっていく
大規模なアプリケーションで
DevOpsをやっていくのであれば
Kubernetesというのは非常に抽象的だな
非常に適切だなと感じています
例えば宣言的技術であるとか
リコンシリエーションループであるとか
Kubernetesのリソースモデルのような
統一された
仕組みがあって
すごい理解しやすいですし
拡張性も非常に高くて
統一的なインターフェースで提供できるので
ユーザーも非常に理解しやすくなると感じております
なので我々はこのKubernetesっていうのが
非常に有効な抽象化の一つなんじゃないかなと思っております
あとはですね
セルフサービスを実現するために
いろいろなOSSなんかも作っています
一つがAcurantっていうツールですね
これはユーザーがセルフサービスで
ネームスペースを作るようにできるための
カスタムコントローラーです
似たようなOSSで
HNCっていうものがあるんですけど
こちら残念ながら
先日アーカイブされてしまったんで
もしこのHNCと似たようなツールを探している方がいたら
このAcurantとか結構おすすめです
あとはCatageっていうツールも開発していまして
これArgo CDをマルチテナント環境で使うための
補助をしてくれるようなコントローラーですね
Acurantでネームスペースを作ったときに
いい感じにArgo CDの設定を変えてくれたりとか
Syncウィンドウみたいな機能がArgo CDにあるんですけど
それをセルフサービスで設定できるようにしてくれたりとか
こういったものをOSSで開発しています
OSSで開発しているんで
実装がサイロ化しないというか
ちゃんとしたKubernetesの仕組みにのっとって
提供できるので
非常にいい感じに作れているという感じですね
実際これうまくいってるの?っていう風に
思われるかもしれませんが
いろいろうまくいってる点と
なかなか課題もあるなというところも感じています
実際良かった点としては
プラットフォームを提供して
それをちゃんとユーザーが理解してくれて
応用的な方法を編み出して
非常に効率的に開発運用ができている
っていうチームがあります
そのチームからプラットフォームチームに対して
適切にフィードバックをくれて
さらにプラットフォームを良くしていくっていう
改善ができています
さらにそういった
結構先行して使ってくれているユーザーが
知見を蓄えてくれて
後発のチームはそれを使って
効率的に開発運用できているという
良い流れができていますね
あとはKubernetesに慣れていないユーザーに対しても
色々と支援をして
使ってもらえていたりします
一方で
なかなかKubernetesに慣れていないチームは
結構苦労していたりもしますし
AWS使っている人たちは
AWSのこの機能を使いたいからって言って
我々のプラットフォームを使ってくれないということもあります
こういったところは今後改善していかないといけないなと
感じているところです
最後まとめしまして
最初認知不可の理論について説明させていただきました
それをプラットフォームエンジニリアリングにどのように適用するのか
我々の提案をさせていただきました
その実際のサイボーズの実践例
抽象化レイヤーであるとか
ドキュメントの整備
セルフサービスインターフェースの提供みたいなところも
紹介させていただきました
ただ色々課題は山積みなので
今後もプラットフォームエンジニリアリングを
推進していきたいなと思っております
最後駆け足になっちゃいましたが
以上で発表を終わらせていただきます
ありがとうございました
ご講演ありがとうございました
それではこれよりQ&Aセッションに移ります
まず最初の質問です
学習意欲がない開発者に
プラットフォームを使ってもらう工夫はありますか
という質問です
学習意欲がない
学習意欲がない
そうですね
でも実際問題
会社というか組織の中には
もちろんそういう方もいらっしゃるとは思っていて
この学習意欲がないが
何に気にしているか次第かなとは思っていて
それが自分がやることで手一杯で
もうこんなのを学んでいる余裕ないよだったら
もちろん余裕ができるように
いろんな調整をしてあげる必要はありますし
余裕があるんだけど学習意欲ない
時間とか心の余裕はあるし仕事も捌けてるけど
新しいこと学びたくないみたいな人に関しては
これは日常の子供に勉強をしているときも一緒だと思うんですけど
初めはやっぱり初めの午前のセッションでもあったんですけど
外発的動機づけからだんだん内発的動機づけにシフトしていくっていうのは
一つのよくある手段かなと思います
外発的っていうのはもちろんその報酬とかが分かりやすいですね
そういったものを与えて
ちょっと実際に実利で釣ってやらせてあげる
そうやって学んでいくとだんだん内発的にシフトしていくっていう
そういったパスを作ってあげるのは一つかなと思います
池津さん何かありますか
はい大丈夫とのことです
先生こちらで回答になりますありがとうございました
ありがとうございます
まだまだたくさんのご質問いただいておりますが
お時間の都合上次の質問を最後とさせていただきたいと思います
一番上の質問ですね
学習関連負荷を増加にセルフサービスインターフェースの提供が有効ということに納得しました
同時に利用者ガイドではなくデザインドックを可能な範囲で公開するのも有効でしょうか
どうでしょうね
我々の場合はそんなにデザインドック
OSSとして開発しているので
結構デザインドックとかも実際見えるようにはしているんですが
実際そっちはあんまり参照されていなくて
ユーザードキュメントの方を基本的には見てもらうのが
一般的かなと思いますが
結構深掘りしたいユーザーは結構デザインドック見て調べてくれることもまあまああるので
公開しても悪いことはないんじゃないかなと
そうですね
なのでデザインドックを公開することで
例えば小学生まだまだ学び中の人がこっちに気を取られて
やっぱり難しいとかなったり
このドキュメント読んでられないってなっちゃったら
逆効果なので
そこをうまく調整する必要があるんですけど
意欲が高い人にとってはすごく学習可能に負荷は上がって
もっともっと理解が深まる要因になるのではないかなと思います
はいありがとうございます
ありがとうございました
それでは以上でセッションを終了いたします
皆様今一度大きな拍手をお願いいたします
拍手