パイプライン周りはまだ探り途中
司会者：まさにBLEA（Baseline Environment on AWS）の開発でやっていることが、僕らが自分たちのアプリケーションを開発する時とメンタルモデルが一緒ですね。どうやってスタックを作っていくのか、BLEAでは複数のアプリケーションがユースケースにまとまっていましたが、どのようにあれを収めていくのか。その中から実行時にユースケースの配下すべてをデプロイしているわけではないじゃないですか。
大村幸敬氏（以下、大村）：そうそう。
司会者：そのあたりを、BLEAではどうやってよりよいサンプルを提示しているのか。「こういう場合はこうやって実行すると、このサンプルを特定してデプロイされますよ」とか。あるいは同時に、2つ、3つのサンプルを同時にデプロイする時には、コマンドに引数を渡すと可能だとか、そういうガイダンスがしっかり整備されている AWS CDK を使った開発のベストプラクティスが随所に見受けられます。
そんないろいろなことをBLEAのプロジェクトの中でもやっていると思うので、すごく参考になるなと（思いました）。
この前お話された方がTipsとしてあげていたことが、まさに「やっていること」という感じで大村さんの話の中にも出ていたので、直面する問題はだいたい似たようなことなのかなと感じました。
大村：そうですね。パイプライン周りは開発の中でもいろいろディスカッションをして、CDKパイプラインも開発の途中で方針を変えたりしていました。みなさんもまだ何か探っている状況なのではないかという気はします。
司会者：パイプラインは、アカウントのオーナーシップの違いや、例えば企業あるいは個人ごとにどういうガバナンスのポリシーで分けたいかによってもかなり変わってくるので、話が尽きなくておもしろそうだなと思いました。
特に私のほうでよくあるのが、開発と言われている領域に関しては、ユーザーを作るところからAWSのアカウントのオーナーシップをデベロッパー側に全部持たせたりする。
さらに前段階のサンドボックスのアカウントは、もっとできることを増やしたいし、逆に言うと、その本番のステージングやプロダクションが乗るようなAWSのアカウントに関しては、デベロッパーは一切触れない。
しかし、例えばGitHubのプルリクを経由した指示出しというか、トリガーはやりたい、かつその環境だけは僕が承認フローの間に入らなければいけないとか、考え方がいろいろあると思います。
大村：そうなんです。パイプラインはいろいろ考えがあって。先ほどは書きませんでしたが、実はCDK Bootstrapもパイプラインでやりたかったんですが、それがうまくいかないことが今調べている感じでは見えています。Bootstrapだけは各アカウントでやっておいてからパイプラインを走らせたほうがよさそうなことが見えていればということで、いろいろ細かいことはありそうです。
司会者：「CDKツールキットはできる。あれに関しては安全なので、どこにでも載せておいてください」という流れになってほしいですね。
（一同笑）
大村：本当はパイプラインがなかったら作るとかをやってほしいんですけどね。今やるとしたら、一度手で（bootstrapの実行を）やらなければいけないので、1回だけ手元に認証情報を持って一つひとつアカウントをアクセス（bootstrap）してしてあとは使わない。そんなことが必要そうでした。
司会者：そういう話は楽しい。僕の一番好きなところですね（笑）。
（一同笑）
BLEAを社内にすすめるための方法
司会者：新井田さん、質問は来ていますか？
新居田晃史氏（以下、新井田）：はい。たくさん来ています。まず1つ目は「BLEAを社内にすすめるためのおすすめの方法がありましたら教えてください」ですが、いかがですか？
大村：2つの側面があると思います。1つはマルチアカウントのガバナンスを進めるためのベースとして使っていただく。これは普通に使えると思います。AWSのSA（Solutions Architect）と知り合いなら、一声かけてもらえれば説明もできると思います。
ほかにコードとしてのBLEAで言うと、もうオープンソースで公開しているしドキュメントもあるので、コードを見てもらって社内でワイワイやってみたり。セキュリティのベースラインをデプロイするだけならあまりコンフィグレーションの必要もないので。まずはデプロイできる上にセキュリティのレベルが上がるので、それを1度やってみるといいのではないかと思います。
新井田：BLEAを使って、まずガードレールを敷いてあげる使い方がいいと。
大村：そうですね。
新井田：（質問を見て）次は、これはBLEAの開発環境かな。「今後クラウドで完結するような予定はありますか」と。
大村：たぶんCloud9の話、IDE（Integrated Development Environment）ですね。AWSの予定については私は話せる立場にありませんが、Visual Studio Codeがブラウザで動くのが個人的におもしろいなと思っています。あのあたりがうまくつながってくると、すべて手元ではないところでやれるようになったりするかもと思うんです。
AWS的には「Cloud9がいい」と言いたいところですが、エクステンションなどを考えていくと、今のCloud9では足りないところがある。それで、私も「今はVisual Studio Codeにしましょう」と言っています。また、どうしても開発が手元でなければ安心できないというお客さんも多いのではないかと思います。
新井田：そうですね。確かにVSCodeのWebブラウザで動くものでいけるようになるとよさそうですね。
API Gatewayをcdkでコード化する場合の管理
司会者：次の質問は「API Gatewayをcdkでコード化する場合、…」。API Gateway自体をSwaggerで定義しているので、たぶんインポートされている方だと思うんですが、「それがCDKだと対応していない。どう管理すべきでしょうか」。
大村：ごめんなさい。今ここでは回答できません。調べるので別枠で回答させてください。
（一同笑）
司会者：Twitterでやりましょう。
大村：Twitterで回答します。
司会者：スライドの一番下（の質問）がおもしろそう。
CDKのディレクトリ構成のベストな組み合わせは？
新井田：「組み合わせるケースでCDKのディレクトリ構成はどういったかたちがベストでしょうか。StackA:LambdaA、StackB:LambdaB、共通ロジックC。AはCを参照し、BはC参照するような」。循環参照みたいなパターンですかね。
大村：スタックを参照するのであれば、別にCDK Appを分けなくていいと思うんです。1つのCDK Appの中で複数のスタックを定義して、そのスタック間で値を参照すれば自動的にスタックのパラメータを参照してくれる。ですので、この場合は標準の構成から変更しなくて大丈夫だと思いました。もしかしたら違うことを言っているのかもしれませんが。
司会者：僕もそれがいいと思います。
大村：BLEAが良いか悪いかはさておき、わりとスタックを分けているんです。1つのAppの中でスタックを作って「これを参照する」みたいになっているので、そこを見てもらうと何をやっているかわかると思います。
司会者：なるほど。実際にBLEAのディレクトリ構成を見てみようということですね。
大村：そうですね。大きな1つのスタックにしたほうがいいと言っている人もいるので、必ずしもそれがいいとは思っていませんが。
新井田：なるほど。Twitterにも「CDKをやる時に、最初にBLEAの構成を見るところから始めたらよさそう」という意見があったので、確かにそのあたりを参考にしたほうがいいと僕も思いました。
司会者：管理するオーナーシップとそのスタック。僕がAもBもCも作って管理するなら1個でいいし、管理する人が違うなど（によって）、いくつかの前提条件がありますよね。
大村：ライフサイクルもあります。私はALB（Application Load Balancer）やフロント側のスタックとECS（Elastic Container Service）のスタック、RDS（Relational Database Service）のスタックを分けたほうがいいのではないかと思っています。それぞれの更新タイミングがまったく違いますからね。
司会者：RDSまで作り直されて泣かないならいいけど（笑）。一緒にして作り直しても泣かないならいいと思います。
（一同笑）
大村：そうなんですよ。--no-rollback（ロールバックを実施しない機能）ができたからよかったものの、あれがなかったら（RDSの再作成が発生した時に）40分くらい虚無の時間を過ごすことになるので。
（一同笑）
大村：RDSは（作成や削除に）時間がかかるぶん、管理がやりにくいことがあります。
司会者：以上でしょうか。大村さんのサミットを楽しみにしています。
大村：はい。またよろしくお願いします。
