本当にそうかを今一度疑ってみる
佐藤智樹氏（以下、佐藤）：（スライドを示して）本当にこんなことで悩むのか。悩むのかというとちょっと言い方が悪いのですが、今一度、これに本当の利点があるのかと疑ってみました。
物理名を使う場合のデメリットもあって、インフラの一部を複数デプロイできないというのがあります。そもそも複数人開発時の想定なのかなと思うのですが、リソースの命名規則や自動名付けは、CDKのコードを読むか、Cfnの仕様を理解していないとわかりません。
似たような名前、例えばAテーブルハッシュ値、Bテーブルハッシュ値みたいなのが複数あった時に、自分のはどちらのテーブルなの？ とならないのかと、逆に不便なのではないのかなと、ちょっと思ったりしました。
それから、リソース名の衝突自体はLambda名に命名規則をある程度作って、リソースに個人ごとのステージの名前を付けることで回避することがそもそも可能なので、自分たちできちんと命名規則を決めていれば別にいいのではないかと思いました。
また、あとで紹介するのですが、そもそもStack名は異なっても、Constructのidが同じだと重複するリソースが一部存在するので、これは自動にしたところでうまくいかないところもあるよなと、思いました。
ほかにも、「リソースに破壊的変更を伴う場合、再作成に失敗する」とあるのですが、例にあるDynamoDBのKeySchemaの変更は、テーブルが一度破棄されます。これはDynamoDBの仕様をちゃんと知っていろという話ではあるのですが、もし知らないでCDKデプロイしていたら、本番用のデータが乗っているのに、KeySchemaをとりあえず変更してみるかと、軽い気持ちで変更してぶっ壊してしまいます。ユーザー側がその危険性に気づけないので、逆に失敗したほうがいいのではないのかと思いました。
（スライドを示して）これは私がたかだか半年間ぐらいやってきて思っていたことなのですが、このベストプラクティス、再デプロイ時に前回実行したリソース名が重複しないのはいいのですが、以前のリソースは残ります。自分がズボラなだけですが、こまめに消しておかないと大量にリソースが残って、俺はどれを見たかったんだっけ？ というふうになると思いました。
あとで見た時に、どれを削除していいのかがわかりにくくなります。（スライドを示して）下の図で説明していくと、CDKデプロイを最初にした時は、Lambda作成時にロググループができます。それでStackを削除して、もう1回デプロイし直した時に、2回目と書いてある枠の右側の参照切れログができてしまいます。
n回ぐらいデプロイした場合、CDKから見るとログは1個しかできていなくて、「ああ、うちの環境きれいだわ」となるのですが、開発者側からすると参照切れのログがメチャクチャあるし、ログ名ハッシュ値になっているから今はどれが有効なやつなの？ というのがパッと見た時にぜんぜんよくわからなくて、気づかないうちにすごくゴミが溜まっていることが起きるのが問題だなと思っています。これはお前が整頓しろという話でもあります。
別のStackで同じリソースを作る知恵
（スライドを示して）あとは、別のStackで同じリソースを作る時の知恵です。先ほど言ったようにConstructが重複するという話もあったので、このスライドは以前「DevDay」で発表した時の資料から持ってきました。
CDKのソースの構造はApp層、Stack層、Construct層みたいになっていて、右上に書いてあるStack層の中で、Appの後ろのUserAStackという引数に、envNameやprojectNameを付けて、idを定義します。
それをConstructの中のidに埋め込めば、命名規則がリソースで異なってidが一部重複してしまいます。AuroraとWAFは、Stack名が異なってもidが同じだと重複するという、微妙な仕様なので、こういうidを付けることによってそれが回避できるという、昔からある知恵みたいな感じでやっていました。
自動名付けで経験したつらさ
（スライドを示して）テーブル名だけを消して物理名を付けないと、だんだんこんな感じの名前になってきて、クラスターとサービス名がえげつないことになります。調査や運用で何度もつらい思いをしました。
例えば、以前一部のタスクで問題があって、入って調査しなければいけない時がありました。ここの名前をずっとコピーして持って行っていたのですが、これはなかなか苦行だな、単純につらいなと思っていました。
（スライドを示して）ここに関して、別に自分は認知の専門家ではないのですが、認知負荷の中の、内在性認知に当たるものなのかなと思っています。その負荷がちょっと高くなるのかなと、冷静に客観的に分析するとそういう感じなのかなと思いました。
開発や調査など、本来実施したい作業用のワーキングメモリが少なくなって、疲労して生産性が低下しているのではないのかなと考えています。
（スライドを示して）下に、メチャクチャざっくりした図を書きました。例えば、自分が使いたいLambdaのリソースに、ハッシュ値が付いたこの変な名前が付いていたとします。それについてログを調べたいと思った時に、右側のオレンジ側がロググループだとすると、ロググループもハッシュ名が付いたやつに、さらにハッシュ名が付いてよくわからない名前になっていて、それを調べるのがつらいなというのが、半年ぐらいこのすべてのリソースを自動名付けでやってきた感想でした。
結局、リソース名はどうするべきか 自分の結論
（スライドを示して）ベストプラクティスをあらためて見返して、下のほうをきちんと読むと、「より良い方法はできるだけ名前を指定しないことです」と書いてあります。「より良い方法は」「できるだけ」と書いてありますが、できませんでした。
結局リソース名はどうすべきか。自分なりの結論として、開発／調査／運用でよく確認するリソースは、名前を固定してしまわないと自分の脳がおかしくなりそうだったので、固定することにしました。
ECS、Lambdaのコンピューティングサービス、DynamoDB、S3など、本来良くないと言われているものですが、やはりわかりにくいので、固定することにしました。
また、これは私も作ったことがあるのでわかるのですが、お客さんに見てもらうダッシュボードやアラートを自動生成に任せると、えげつない名前が付いたりするので、このあたりの、お客さんや自分が見る内容は固定することにしました。
ただVPCは、その時そこまで見る機会が多くなかったので、上記以外のリソース・サービスはできるだけ固定しないでやっていこうと思っています。
公理を疑って辿り着いたベタープラクティス
（スライドを示して）まとめです。先ほど言った内容ではあるのですが、CDKのベストプラクティスは本当かを確かめてみました。公理を疑うのはアーキテクトの役目かなと思ったのでやっています。
自動で生成するリソース名を使用し、物理的な名前は使用しないのがベストと書いてあるのですが、なかなかつらい部分もあります。時間がけっこう過ぎていると思うので、このあたりのベストでなかった経験については軽く飛ばします。
最終的には、リソース名の自動生成は程々にして、つらい時は固定化しようというのが、ベストプラクティスではないのですが、ベタープラクティスかなぁと思っています。
（スライドを示して）追加として、今回きちんとした発表もあったと思うのですが、できればもうちょっとこういうカジュアルな話もしたいと思っていて、JAWS CDKみたいなものを立ち上げていきたいなと思っています。もっと日本の中で、知見を共有できたらいいなと思っています。
CDKの知見を発表したい方や、「CDKをもっと日本で盛り上げていきたいぜ」という方がいたら、私のTwitterにDMや、リプライで連絡をいただくか、JAWS UGのslackの中にjawsug-cdkチャンネルを作ってもらったので、そこのチャンネルに入って「私もなんかやりたいっすわ」と連絡をいただけるとうれしいです。私も運営経験がまったくないのでこれからなのですが、気になる方は入ってもらえるとうれしいです。
以上で発表を終わりたいと思います。ありがとうございました。
質疑応答
吉田真吾氏（以下、吉田）：ありがとうございました。
新居田晃史氏（以下、新居田）：ありがとうございました。
吉田：まさにアレですよね。ARNのように扱いたいツール側と、今俺は認知する名前として扱いたいというのの、戦いですよね。
佐藤：そうですね。CDKを作っている側の気持ちはわかるけど、いや俺たちはつらいんだと、ユーザーはもっと言うべきかなと思っています。
吉田：なるほど。ありがとうございました。新居田さん、質問は来ていますか。
新居田晃史氏（以下、新居田）：はい、1つ来ています。「リソース物理名以外に変更可能なエイリアスなどが使えると便利な気がしますが、そういう方法はご存じですか」という、アイデアが来ています。これはCDK上でという感じなのかな？
吉田：いや、Stack名だったりいろいろ。
新居田：AWSのStack名とか。
吉田：そうそう。というのは自動でできたとして、それに対してエイリアスあるいはタグ？
佐藤：見にくいかもしれませんが、確かにタグで見るのがベストですかね。
吉田：これはそれぞれきちんと手に馴染む方法が見つからないと、つらいものはつらいということにしかならない気がします。
佐藤：まぁそうですね。タグになると、結局コンソールからすぐ見られるわけではないから、なかなかつらいなという。
吉田：あと、リストみたいに検索する時にタグを付けておくと、こういう検索はできるんだっけ、できないんだっけとか。そういうことは使い方によってある気がします。まぁ、少なくとも今はつらいものはつらいという（笑）、ところですね。
佐藤：だから曖昧ですが、どちらかに合わせるという極論よりは中庸ぐらいな、どちらも許容するぐらいがいいのかなと。
吉田：なるほど。せめて事故らないように、ステージやリージョンは名前の中に入れておきたい、入れておこうかなとか、そういう話もあるかもしれないですね。あとオーナーとか？
佐藤：オーナーとか。だいたいそうですね。プロジェクトだけはわかるように、プロジェクト名を入れたりしています。こちらに関連するやつかとか。
吉田：OKです。ということで、佐藤さんでした。引き続きよろしくお願いします。ありがとうございました。
佐藤：よろしくお願いします。ありがとうございました。失礼します。
Published at
June 03, 2022 at 07:00PM
https://ift.tt/07Li152
「それでも俺はAWS CDKが作るリソースに物理名を付けたい」 アーキテクトが辿り着いた、リソース名のベタープラクティス - ログミーTech
https://ift.tt/A6EJPgC
Mesir News Info
Israel News info
Taiwan News Info
Vietnam News and Info
Japan News and Info Update
Bagikan Berita Ini
0 Response to "「それでも俺はAWS CDKが作るリソースに物理名を付けたい」 アーキテクトが辿り着いた、リソース名のベタープラクティス - ログミーTech"
Post a Comment