Slide 1
Slide 1 text
認知負荷って何？を知った上で再考する
CloudFormationからCDKへの移行
加藤 裕士
にん
クラウド フォーメーション
トークイベントの前段LT~
シーディーケー
ち ふ か
Slide 2
Slide 2 text
名前 : 加藤 裕士 (yushi kato)
居住地：札幌市中央区
好きなサービス : CloudFormationが大好き！
好きな事 : スペースエイジインテリア収集
最近の興味 : CDKは勉強中の白帯です。
音楽鑑賞(Black Music, 和物, アンビエント etc..)
自己紹介
Slide 3
Slide 3 text
目次
1.CDKはCFnの上位互換？
2.予備知識として「認知プロセス」を学んでみる
3.CFnのツラミとCDKでのアプローチ
-「CFnのツラミ」を自分なりに考察
- CDK側でのアプローチ
- CFn→CDKに移行するにあたって「意識改善」出来た点
Slide 4
Slide 4 text
1.CDKは
CloudFormationの
単純な上位互換？
シーディーケー
クラウド フォーメーション
Slide 5
Slide 5 text
CloudFormation
(JSON/YAML)
AWSサービスのリソースをコードで表現し作
成するサービス。
01. 02.
Terraform
(HCL)
マルチクラウド等での利用も可能で、CFnを
介さずAPIを利用した高速デプロイを実現。
AWSにおけるIaC
03.
CDK (Typescript,JavaScript、
Python,Java,C#,Go etc..)
汎用プログラミング言語で記述可能。CFnに相当
するL1の他,高度に抽象化されたL2,L3が存在。
Serverless Framework,SAM,Pulumi etc..
他
Slide 6
Slide 6 text
CDKを一週間ほど触っては見たが...
Slide 7
Slide 7 text
思っていたより
しっくりきていない..。
Slide 8
Slide 8 text
抽象化(L2/L3)
- 本番利用では結局抽象ではなく具体で完璧に把握している必要があるのでは。
- 暗黙的な設定を意識しつつの作業は脳への負荷が高かったりしないかな。
- addoverride(上書き)等に感じる セット注文後にポテトをチキンに変えて、ピクルスを抜いて、
バンズをライスに変えるような違和感 (最初から単品で注文すれば...)
言語選択
- 複数の言語から選択可能である事でコードの再利用性に悪影響はないのか。
- 汎用プログラミング言語で作成したものを結局YAMLで確認するの？
その他
- 物理(論理)命名はダメ(非推奨)なの？
- コンソールや合成して出てきたYAML結果が見づらくてストレス。
- forなど使える事によるメリットは本当に大きい？
- 本音でいえばCFnに慣れていてツラミまでは感じてないんだけど..
当時(初めて一週間時点の)私が感じた色々
Slide 9
Slide 9 text
認知負荷
にん ち ふ か
Slide 10
Slide 10 text
2.予備知識として「認知プロセス」を学ぶ
Slide 11
Slide 11 text
突然ですが、、
Slide 12
Slide 12 text
という問題があったとします。
↑はネットから拾ってきた閏年かどうかを判別するコードですが、
成功者には◯千円など動機付けもあれば皆さん再現出来る方も多いのではと思います。
(例題) ↓のコードを2分で記憶して、エディタに再現してください。
Slide 13
Slide 13 text
一方で↓の文字列は Brainf**kという難読言語で「Hello World!」だそうですが、
先ほどの例と違い、同じ時間でもこれを再現するのは難しいとかと思います。
(※少なくとも私には無理だなと感じます。)
Slide 14
Slide 14 text
記憶する事を難しくしている要因
- 過去に学習した経験のない言語である為、内容の変換に必要な基礎知識が不足している。
- 理解を助けるコメントが存在しない。
- 変数名など自然言語と結びつけて目的を推測する事が出来ない。
- 改行がない為、構造的な分解が難しい。
- 難易度に対して時間が短い &「絶対に記憶しなければいけない」という動機付けが薄い。
Slide 15
Slide 15 text
記憶や認知に関わるプロセスを勉強したい
Slide 16
Slide 16 text
そもそも「認知」とは 〜 人間の脳の作り
我々は何に「ツラミ」を感じているの？
「認知プロセス」を知ろう！
Slide 17
Slide 17 text
①感覚記憶 ※I/Oバッファ
②短期記憶 ※RAM
③長期記憶 ※HD
④作業記憶 ※プロセッサ
Slide 18
Slide 18 text
研究によると②短期記憶は..
- スロットは2個〜多くても6個位しかない。
- 30秒以上保持する事が出来ない。
以降は長期記憶に移動されるか 永久に失われる。
- 短期記憶の容量をトレーニングによって
大きくする確実な方法は見つかっていない。
→1つのスロットに入れられる情報は？？
(なんて事も気になってくる。)
Slide 19
Slide 19 text
http://piggydb.jp/d/68
前提として、先ほどは人間をPCなどに例えてお話ししましたが、
実際には人間の脳内は階層構造になっておらず、
むしろ記憶同士はネットワーク構造になっている。(のだそうです)
Slide 20
Slide 20 text
情報を組み合わせるまとまりを「chunk/チャンク(塊)」と呼び、
長期記憶内から、入ってきた情報と関連性・類似性の高い知識がないか
検索し、存在すればそれらを結びつけて保存し直すように出来ている。
(つまり情報は出来るだけチャンクしてた方が記憶作業には良いという事らしい)
ex.
- 情報が長期記憶にどれだけきちんと保持されているか(貯蔵記憶)
- 情報を思い出すのがいかに簡単か(検索強度)
Slide 21
Slide 21 text
作業記憶も短期記憶と同じく2-6個のことしか同時に処理出来ない。
認知負荷が発生。→「そんなにどんどん命令されても記憶出来ないよ！」
Slide 22
Slide 22 text
他にも勉強になる事は色々書いてあったので、お話ししたい所ですが時間の都合上省略いたします。
もしご興味を持っていただけた方は書籍か後ほど公開するスライドにお目通しいただければ幸いです。
- 問題自体の固有の複雑さ=課題内在性負荷
- 理解の妨げとなる外部要因=課題外在性負荷
(コードの書き方等、閲覧者⇄作成者間の知識ギャップ等で発生)
コードを書く際には、
- コメント
- デザインパターン
- 意味のわかる変数名や演算子やif、elseなどの制御構造etcなど=通称ビーコン
等が、記憶作業を容易にする特徴をコードに付加。
→チャンクし易くし、可読性を助ける働きをする。
のだそうです。
2020
省略
Slide 23
Slide 23 text
抽象化された物事の理解には、
抽象への理解→具象への理解→抽象への再理解というプロセスが必要らしい。
→当人が備えている知識や背景によってどこに難しさを感じるかは変わるのではないか。
省略
Slide 24
Slide 24 text
先行学習が新たな学習に、
- プラスの影響を与える=正の転移
- 邪魔・阻害を与える=負の転移
がそれぞれ存在する為、
新しい知識を獲得する際、適切な「アンラーニング作業」が必要になる。
「こうであるはず」というイメージや期待と食い違いが発生すると学習を阻害する。
省略
Slide 25
Slide 25 text
ここまで「認知的に脳がツラい」はこういう事だよねを再確認した上で、認知云々とは全く別に
CFnがアプローチしきれていない、「効率的な作業を阻害する要素」「痒い所への手の届かなさ」
もユーザーそれぞれの中にきっと共通して存在しているなと思いました。
これ以降は「何が認知を苦しめているか」を中心に話す事はありませんが、
皆様の中でトピックの何が問題なのかのカテゴライズが少し簡単になっていれば幸いです。
Slide 26
Slide 26 text
3.CFnのツラミとCDKでのアプローチ
Slide 27
Slide 27 text
「CFn」のツラみを自分なりに考察
Slide 28
Slide 28 text
私が考察するCDKとの対比においてのCFnのツラミ(一例)
①CFnがツラい=YAML構文の習得がツラいという事ではなさそう。
- そもそも熟知していない情報が大量に視界に入るのが認知的に辛い。(マネコンでも辛い)
- 所謂「よしな(=設定すべてを完了させる能力が未成熟でも、安心して利用出来る助け)」を求めている。
→AWSの全てに詳しくないユーザーも、IaCのメリットを享受したい。気にしている部分以外は任せたい。
→CDKにはあってCFnにはない部分では？という事と考える。
②ロールバックが発生して初めて判明する設定ミスやタイポ。
→ 小さいミスに対して都度ロールバックが発生する時間的なロスが辛すぎる。
→ CDKならリンターがエディタ上でエラーを指摘して大半を削ってくれる。
③リージョンをまたぐデプロイの際、値を引き渡す事が難しい。
(人間が記憶してParameterに値を渡すか自身でパラメータストア等へ保存させ、引き出す工夫が必要)
④マネコンから或いは、CLIからCFnの実行を行う際の画面遷移や入力が毎回面倒くさい。(1アクションがいい)
⑤S3のバケットの物理名重複等、残存リソースとの衝突があると、これまた再デプロイが失敗。
（これに関してはDeletionPolicy:RetainExceptOnCreateの登場で一部解消。）
Slide 29
Slide 29 text
CDKでのアプローチ
Slide 30
Slide 30 text
最近体感しているCDKの良さ(先ほどのツラミに対する対処)
①TSの静的型付け+linterのおかげでエディタ上でエラーがわかり修正出来る。
- 失敗が確定しているデプロイが減少→エラー発生とロールバックの減少。
- ドキュメントの往復回数の減少。
②抽象化の恩恵
- 初手で視界に入る情報量の抑制。
- 気付けていなかった「AWSが提唱するあるべき姿」(セキュリティ設定等)とお友達になれる。
(気付いて→信頼し→任せるという意識フローが存在する。(コンストラクトとユーザー間の信頼関係の醸成))
③ChangeSetを利用した差分変更が容易。
- 初回デプロイ以降は前回デプロイ内容に対する変更で済む為、時間短縮になる。
- cdk diffで「前回との違い」を自分以外にアウトソーシング出来る。
④物理命名が非推奨である事(良し悪しの「良し」)
- 既存リソースとの物理名の衝突を回避。
⑤並列で一気にデプロイしたり、リージョンを跨いで値を引き渡してくれたり、バケットのオブジェクトを消す
Lambdaを作ってくれたりCFnにない便利がいっぱい。
Slide 31
Slide 31 text
逆に、個人的に感じるCloudFomationのいいところ
①エラー文から得られるそれぞれのリソースの詳しい理解がある。
(※このリソースはこれは許さない。これは必須と考えている等)
個人的には学習のひとつのプロセスに感じているが、経験する必要のないエラーと言われればそれもそうかもしれない。
②(個人的に)CFnのドキュメントほどAWSの各リソースについて端的に網羅的で深い理解を与えるものもないと感じる。
③目的に対して書き方の正解の形に揺らぎが発生しにくい事は良い事ではと感じるでもある。(明示・暗黙除く)
Slide 32
Slide 32 text
CFn→CDKに移行するにあたって「意識改善」出来た点
Slide 33
Slide 33 text
CFn→CDKに移行するにあたって「意識改善」出来た点。(と私個人が今一番聞きたい事)
①マネコンから物理名を見て「なんのリソースだったか」を判別し易いメリットは一旦忘れてみた。(そのうち慣れる)
②CDKで記述しているものは、慣れ親しんだCfnテンプレートを作成する為の「更に前段」である事を再認識する。
③Cfnでは手の届かなかった「便利さ」や、「速さ(作業効率の助け)」がいっぱいある。
④これまでのテンプレで蓄積してきたものはL1のProps(第三引数)にコピペして使える為、完全に無駄にはならない。
(が、実際にL1の完成形を起点にL2以上に昇華していく事は少なさそう)
⑤結局Forを使って作成するのもアリかもと思ってきた。(VPCEndPoint等々)
⑥cdk synthの可読性が低く感じていた事については各Metadataを含めないよう設定する事でかなり解消。
ターミナル上では⌘+F「Type: AWS::」をする事で区切れ目を判別する工夫をする等した。
⑦CFnから始めるかCDKから始めるか迷っている人は、L1＝書き方の違うCFnなので、CDKから始めるのが良いと思う。
(cdk synthで合成された結果はJSON、YAMLである為、これを理解する努力＝CFnへの理解と考えて遜色なさそう。)
CFnのドキュメントは最高の教科書だと思っているが、CDKのリファレンスはまだまだ仲良くなりきれていない。
今日の座談会ではCDKリファレンスで補完されない部分(CDK作業時のCFnドキュメントの登場ポイント)も聞きたい。
「CFnで当たり前になっているここはアンラーニングして臨んだ方がいい」という所があればそれも聞きたい。