「インフラエンジニアには難しい」「手でやったほうが楽」も解消　これからCDKを使う人向けの4つのナレッジ

自己紹介

司会者：次は、今までがんばってCDK（Cloud Development Kit）を普及させてきた大村さんです。

大村幸敬氏（以下、大村）：よろしくお願いします。

司会者：初めて聞く単語なんですが、読み方は「ブレア」でいいですか？

大村：「ブレア」でいいです。

司会者：準備ができたらBLEA（Baseline Environment on AWS）の話を始めてください。

大村：みなさんこんにちは。AWSのソリューションアーキテクトの大村と申します。本日はCDKカンファレンスの場を借りて、Baseline Environment on AWS、BLEAの開発にあたって検討したことを話します。

私はふだん、お客さまをサポートするソリューションアーキテクトとして活動していますが、同時にAWSの中では運用系やDevOps系のサービスをリードする立場としても活動しています。その一環で、セキュリティのベースラインを提供するBaseline Environment on AWSというテンプレートを開発しました。日本ではSA（Solutions Architect）のみんなで開発していますが、私がリードしています。

CDKについて

最初に少しCDKについて話します。CDKは2018年に外部に出ましたが、実は社内ではもう少し前から情報をキャッチしていました。それもあって、1年後の2020年2月、目黒にあるAWSのロフトでやったGA記念のミートアップでは、司会や発表をやらせてもらいました。

2020年3月にCDKのBlack Beltの話をしたほか、直近では2021年末にやっていたアドベントカレンダーを私のほうで作らせてもらいました。みなさんにも参加してもらって、見事に全部埋まって、プラス2ページ目まで行きました。これだけの方にCDKの話を聞いてもらえるのは、すごくうれしいです。

セッションの概要

今日は先ほどから言っているBLEAとは何かについて軽く説明したあと、BLEAを使う中で私たちがディスカッションした内容についても話そうと思っています。

また、CDKの開発を行うにあたって、いくつかの設計方針があったり実装方式を変えたり、開発者が知っておかなければいけないことなど、BLEAの開発の中で検討した内容をお伝えすることで、みなさんがよりよい選択や検討をするための一助になればいいと思っています。

AWSの中の人間として話しますが、これがベストプラクティスだというつもりはまったくないので、「こうやっているんだな」くらいに考えてください。CDKそのものについては先ほど亀田さん（亀田治伸氏）が説明したので私からは話しません。また、BLEAが何かについては5月に実施するサミットで話す予定になっています。まだ詳細は出ていませんが、そちらも楽しみにしていてください。

BLEAとは何か

大村：BLEAとは何か。AWSのセキュリティのベストプラクティスを実装したオープンソースです。AWS Samplesという、AWSのオフィシャルのコードが公開されるところで公開しているサンプルテンプレートです。日本のSAたちが開発しています。

AWSには「ガバナンスベース」と呼ばれる、セキュリティで絶対にやっておかなければならない設定があるわけですが、その設定をするためのCDKのテンプレートと、その上にセキュリティのベストプラクティスに従ったかたちで実装する普通のシステム。Webのアプリケーションやサンプルコードをセットで公開しています。

なぜBLEAはCDKを使っているのか？

大村：なぜCDKを使っているのか。Infrastructure as Codeをみなさんに使ってもらえるようにしたいと思ってBLEAを作っています。今までInfrastructure as Codeをやる上で何が辛かったのかというと、開発したものの引き継ぎができなかったり、コードが難しすぎて内容が理解できなかったりする。そんなことがあったのではないかと思っています。そこで、テンプレートをブラックボックスにしない、わかりやすくて自分たちで編集できるコードを目指して作っています。

そのためには、CloudFormationを生で使うより記述量が少なく、型チェックがあって、エディタもサジェストが強力なCDKのほうが向いていることからCDKを選んでいます。みなさんに使ってもらうことを想定しているので、CDKの学習コンテンツとしても使えるように配慮しています。複雑なクラス構成を使うのではなく、標準のライブラリだけを使ってコメントやリファレンスやHow toみたいなところをドキュメントで厚めに書いて、必要な部分をコピペしながら開発を開始できるように作っています。

（スライドを指して）例えば、ALB（Application Load Balancer）のアクセスログを設定したい場合は、セキュリティのベストプラクティスに照らし合わせるには少し設定を変えなければいけないんです。これはsetAttribute（メソッド）という、普通とは違う書き方をしなければいけないよと。これは例でもあり、実際に設定する時にはこうしなければいけないということでもあります。

「こう書く理由はこういうところに準拠しなければいけないから」とか、「RegionInfoというやや特殊なクラスから情報を引っ張る方法を参考にもなるように書いている」とか。（スライドを示して）BLEAの中のコードはこのように作られています。ぜひ、コードを見てください。

課題1：CDKを使うのは難しそう

大村：今日は大きく分けて2つの話をします。まず「これからCDKを使う方たちへのナレッジ」。そのあとに「すでにCDKを使っている方へのナレッジ」です。

何を言ってもこれなんです。今日はいろいろな話を聞いてもらっていますが、Slackに流れてくるのは「インフラのエンジニアにCDKは難しい」「TypeScriptはしんどい」という声なんです。

それはそのとおりだと思っていて、実際に私たちも「TypeScriptやPythonのコードを書いたことがない」などのユーザーの声を聞いています。Slackにはbash対応が欲しい」みたいな声もありました。ほかに「npmやlintは今まできちんとアプリ開発をやったことがないからあまりよくわからない」という人もいると思います。

アプリケーション開発者はみんなすごく強い開発環境を手元に持っていて、それはいいのかもしれませんが、整備がとても面倒そうじゃないか。「やっぱりメモ帳でやりたいな」「さ〇〇エディタでやりたい」「秀〇でやりたい」ということがきっとあると思うんです。しかし、CloudFormationもそうですが、エディタの力は使ったほうがいいです。

そのためにどうするか。私たちは想定の開発環境をいったんVisual Studio Codeに限定しました。その代わり、Visual Studio Codeを使った時に必要な開発環境の設定ファイルや初期手順を細かく用意して、まずは使い始めやすくしています。

例えばVSCodeのExtensions。インデントや対応コードやフォーマッターやlintという設定がリポジトリの中に入っているので、チェックアウトして手順どおりにVSCodeを立ち上げれば、きれいなかたちで使い始められるようにしました。

確かにCDKをデプロイするだけならコマンドだけでもいいんですが、中身は絶対に編集するんです。しなければいけないんです。だからエディタもきちんと使いましょうということで、スライドのような手順が入っています。ぜひ恐れずに触っていただきたい。

課題2：L2Constructがない、またはCloudFormationを使いたい

大村：次に「L2 ConstructがないのでCDKが使えない。それならCloudFormationと一緒でしょ？　ならCloudFormationがいいかな」という声も聞きますが、BLEAの場合は「L1 Constructが必要なら積極的に使いましょう。場合によってはCloudFormationのテンプレートをインポートしてもいいのでは」と、わりとゆるい感じで考えています。

これまでの発表の中にも何度か出ましたが、CloudFormationリソースイコールL1 Constructがあるということです。自動生成されています。L1 ConstructはCloudFormationと同じ設定をしなければいけませんが、スライドの右側にあるように、サジェストが非常に強力なんです。

何が必須パラメータなのか、何がオプションなのか、どんな項目を取り得るか。これは文字列ベースで、実際はリファレンスを見ることになるんですが、そういうことをやらなくてもいいんです。なので、仮にCloudFormationを使う場合でもL1 Constructでコードを書いてCloudFormationテンプレートを生成して、そこからスタートするほうが楽かもしれません。

CDKはアプリケーション開発者向けで、CloudFormationはインフラ担当者向けみたいに思われるかもしれませんが、そんなことはありません。そこは自由に行き来してもらって、必要なところで必要なものを使ってもらって大丈夫だということを伝えたいです。

課題3：やっぱりYAMLがいい

大村：「やっぱりYAMLがいい」という話を聞くんですよ（笑）。「コードを書くのはやっぱり……」「クラスは蕁麻疹が出そう」みたいな話も聞きます。しかし、大丈夫です。

スライドの右側を見てもらうと、CDKのコードは特にif文やfor文や、ものすごく複雑なクラス構成を考えなければいけないかというと、そんなことはありません。例えば、セキュリティグループを定義してバケットを作り、アプリケーションロードバランサーをすでに用意してあるVPC（Virtual Private Cloud）の中に作り、セキュリティグループを先ほどのものに紐づけてリスナーを作って、とやっているだけなんです。

だから、YAMLのCloudFormationの定義の仕方とそんなに違いはないんです。インスタンスを作ること、リソースを作ることとそれを紐づけること。だいたいそれだけでできちゃうんです。それでいてYAMLを書くのに比べてリソースを参照しやすいので、コードを書くとすごくスッキリするし、そんなに難しくもないと思います。

ものすごくアプリケーションを書くのが得意な方も、やはりCDKの話をされるので、そういうことばかりやらなければいけないと思うかもしれませんが、ぜんぜんそんなことはありません。普通にクラスを並べていくだけでできるので、恐れずにコードを見てもらえればと思います。

スライドの右側に出ているのも、BLEAの中にあるコードです。そちらも見てもらうと、そんなに難しくはないと理解してもらえるのではないかと思います。そもそもロジックが複雑なコードは構成管理のコードとして本当に適切なのかと個人的には思っています。

if文などが中に複雑に入り込んでくると、コードと実体の対応がわかりにくくなるんです。では何かを変更しようと思った時に、本当にこのコードをデプロイすればやりたいようにできるのか。コードを見るだけではわからなくて、ロジックを追わなければいけなくなるんです。そこは「本当にいるのかな」「大丈夫かな」と注意してほしいと思います。

課題4：手でやったほうが楽

それから「手でやったほうが楽」という問題。これはあると思います。本当に手でやったほうが楽で、回数が少ないのなら手でやってもいいのではないかとBLEAでは考えています。BLEAはベースラインを作るという特性上、例えばOrganizations全体に対してSecurity Hubを有効化したり、GuardDutyを有効化したりすることがあります。

CloudFormationでは今、実はOrganizations全体に対しての有効化を行うリソースがないんです。ではどうするのか。Lambdaを書いてAPIを呼べばやれなくもないですが、マネコン（マネジメントコンソール）で2ステップか3ステップの手順なんです。Organizationsやアカウントにつき1回しかない操作なら、そんなにがんばらなくてもいいのではないかと考えています。

コードを書くということは、そのメンテナンスを保守していかなければいけないということなので、やっぱり書くコードは少なければ少ないほどいい。実施回数が少なくて手順がシンプルなら、手でやっちゃってもいいのではないかという考え方です。CDKを使おうという方へのナレッジというかメッセージは、だいたいこんなところです。

　（次回に続く）