イベント概要
セッション１：マネコン操作いらず！ TerraformでAWSインフラのコーディングに入門しよう
登壇者：みのるん（KDDIアジャイル開発センター株式会社）
- IaC、Terraform初心者向けの登壇
- IaCとは
- コードでインフラ構築する手法のこと
- そもそもクラウドはAPIを使って構築する
- TerraformはGo言語で実装されているので、Goが裏でAPIを叩いている
- Terraformを構成するコンポーネント
- Terraform本体はコアとプロバイダに分かれている
- コアはTerraform本体のソフトウェア
- プロバイダはAWSなどの構築対象の製品用プラグイン
- 「コンフィグ」と「モジュール」で実際のコードを管理
- 「ステート」で構成管理
- ステートとコードの差分を確認して構成管理を行う
- Terraform本体はコアとプロバイダに分かれている
- Terraformのコード
- terraformブロック
- コア部分のバージョンなどを指定
- providerブロック
- プロバイダ部分のバージョンや共通設定を入れる
- resourceブロック
- 実際に構築したいリソースを書く
- ※Terraormはあるべき姿を書いておくだけでOKな「宣言型」で書く、今どういう状態かは気にしなくて良い
- terraformブロック
- Terraformのコマンド
- コードをかけたらコマンドを実行する
- terraform init
- terraform plan
- 実行するとステートとコードを比較して差分を出力してくれる
- terraform apply
- 3つのコマンドだけで構築完了！！
- コードをかけたらコマンドを実行する
- 便利な機能
- Terraformのコンフィグ（tfファイル）は分割可能
- Terraform内の他のリソースを相対参照できる
- 既存のAWSリソースを参照することも可能（dataブロック）
- 複数人で作業する時のために、ステートをS3バケットに保存できる
- 慣れてきたらモジュールを使おう！
セッション２：いまから始めるAWS CDK 〜モダンなインフラ構築入門〜
登壇者：佐藤 智樹（クラスメソッド株式会社）
- そもそもモダンって？
- 直訳は「現代的であること」
- モダンではないエンプラな現場でよくあるのは。。。
- 開発者がインフラ担当にメールで構成変更依頼をする
- 手順書作って承認してもらう
- インフラ担当が修正してようやく構成変更完了！
- CDKをフル活用できれば開発者だけで完結する！
- インフラ構成変更をGitで管理、お客さんに承認してもらえればそのままデプロイ！
- CDKとは
- AWSインフラをプログラミング言語で構築できるツール
- TS、JS、Python、Goなど
- CDKには何種類かある
- AWS CDK
- CFnテンプレートなどを裏で生成してインフラ構築、構成管理をする
- 今回の登壇で対象になるもの
- CDK for Terraform
- TerraformをラップしたCDK
- CFnではなく、Terraformのステートファイルが裏で作られる
- cdk8s
- k8sマニフェストを生成してk8s環境を管理
- AWS CDK
- AWSインフラをプログラミング言語で構築できるツール
- CDKの利点・欠点
- 利点
- プログラマーにとっては学習コストが低い
- 型安全性によるコード補完
- 最初に型安全性のチェックが走るので安心
- 生成AI時代でもチェック手段の一つとして有効
- アプリとインフラをまとめてコードで管理できる
- 欠点
- 学習コストが高い
- プログラマーがこだわりすぎると複雑化してしまう
- 利点
- CDKのコンポーネント
- App
- アプリケーションの単位、デプロイのエントリーポイント
- Appにより、複数のStackを管理するアプリケーション全体の箱を作るイメージ
- Stack
- デプロイの最小単位
- CFnのスタックと対応
- 複数のAWSリソースをまとめる論理的なグループ
- Constract
- 実際にAWSリソースを実装する単位
- 公式に提供されてるものに加えて、独自に開発することも可能
- L1：CFnのパラメータと1対1に対応
- L2：L1を抽象化
- L3：L2をさらに拡張、複数リソースをまとめてデプロイ
- 基本的にはL2を使うことが多い
- Cloud Assembly
- CDKアプリケーションがデプロイされた後の出力物
- デプロイに必要なファイル一式
- 例）CDKが生成したCFnテンプレート、Lambdaのコードのデプロイ先やパッケージングの定義、など
- App
- CDKのユーザーから見た動き
- まずはローカル環境でCFnテンプレートとAssetsが生成される
- CFnテンプレートとAssetsがS3に転送される
- CFnがS3にあるCFnテンプレートとAssetsをプルしてくる
- CFnテンプレートとAssetsからCFn Stackを生成
- CFn Stackに基づいてAPIが呼ばれて、実際にリソースが作られる
Enhancing AXA Data Platform with Terraform
登壇者：谷口 恵輔（アクサ生命保険株式会社）
- AXAのデータプラットフォーム
- AWS上に構築されている
- Databricksも合わせて使用していて、Databricksへの移行が進行中
- 開発生産性における課題
- CFnのコードに継ぎ足しをし続けた結果1万行に。。。
- コードを修正してからデプロイまでが手作業
- AWSとDatabricksで別々のIaCツールを使っていた
- 運用における課題
- 手作業による修正によってCFnと実際の環境に差分が生まれている
- DatabricksのデプロイはIaCなしでやっていたため、アップデートによる差異が検出されない
- LambdaのパッケージのEOLが迫っている
- AWS上に構築されている
- 運用改善のTips
- Lambdaを例にTipsを紹介
- ディレクトリ構造
- リソースを作成するtfファイルではシンボリックリンクを使用
- 環境特有のパラメータだけディレクトリ内で管理
- 公式にはモジュールを推奨しているが、モジュールを使用するメリットがあまりなかったためシンボリックリンクを使用
- リソースを作成するtfファイルではシンボリックリンクを使用
- Lambdaのコンフィグ
- configディレクトリにYAMLファイルを用意
- バージョンタグが変更された時にのみビルドとデプロイを行う
- lambda_local.tf で構築する前処理（LambdaコードのZip化など）を設定
- YAMLファイルもtfファイル内で読み込み、差分がある場合のみデプロイを行う
- ディレクトリ構造
- Lambdaを例にTipsを紹介
- Terraformの特徴に基づいたTips
- リソースに手作業で修正を加えてしまうと、差分を検知して上書きしにいってしまう
- -generate-config-outオプション
- planの時に指定することで、リソースの定義を特定のファイルに出力できる
- for_each
- 効率的かつ安全にさまざまな設定値を定義できる
- S3バックエンドネイティブロック
- DynamoDBを使わなくても、S3にあるステートの編集の競合を解決できるようになった
- Ephemeral Value
- planの出力やステートに機密情報が出力されないように管理できる
知っておきたい！保守性を高める AWS CDK のセオリー・ベストプラクティス
登壇者：山梨 蓮
- CDKの保守性
- インフラにロジック（ループ処理、条件分岐など）を持ち込むことができる点がCDKのメリット
- ロジックが複雑化しても保守性を上げられるようにするには、を考える必要がある
- 保守性とは？
- システムを修正する時に、どれだけ効率的かつ正確に変更できるか
- CDKの保守性を高めるポイント
- Construct同士の結合を疎結合にする
- 不要なConstructの上書きを防ぐ
- インフラにロジック（ループ処理、条件分岐など）を持ち込むことができる点がCDKのメリット
- 保守性を高めるベストプラクティス
- COnstruct IDに変数を使用しない
- 変数を使ってしまうと、意図しない外的要因によってConstruct IDが変更されてしまう危険性がある
- 衝突を避けるために変数を使用することもあるが、基本的には非推奨
- Construct property/propsはClass型にしない
- propertyはConstructが公開する変数
- propsはConstructが外部から受け取る変数
- どっちも情報交換に使うものなので、Classを使用すると密結合なコードになってしまう
- Interfaceを使用してConstruct間の情報交換を行うようにする
- 外部に公開しないモジュールはprivateディレクトリに
- 外部公開したくないモジュールをprivateモジュールに移動させておく
- 異なるprivateディレクトリからのインポートを防ぐことも可能
- 環境ごとに異なる設定値を外部化する
- 外部化しないと再利用性が低くなる
- 外部化しないと、Stack専用のConstructになってしまう
- propsを使用して設定値の受け渡しを行う
- 外部化しないと再利用性が低くなる
- 命名規則を統一する
- TSならTSの命名規則などを参考に
- COnstruct IDに変数を使用しない
- まとめ
- 5つ全てを実装しないといけないわけではない、場合によって使い分ける
- 公式のベストプラクティスも参考に
Best practices for using the AWS & AWSCC provider in parallel
登壇者：Chris Williams (AWS Community Hero)、Bruno Schaatsbergen (Hashicorp)
- AWSプロバイダー
- プロバイダーはTerraform CLIとAWSの接着剤にすぎない
- プロバイダーが構築する順番などを処理してくれる
- プロバイダーは手作業で作られているため、新しいサービスへの対応に少し時間がかかる
- AWSCCプロバイダー
- AWS Cloud Control APIの略
- 統一されたインターフェイスでAWSリソースを構築できる
- EC2を実際に作るときにEBSのAPIを呼び出したりするが、それらをラップして構築できるイメージ
- コードでの構築をより簡単にできる
- AWSCCプロバイダーは毎日自動的に作成されるため、新しいサービスへの対応が早い
- AWSプロバイダーとAWSCCプロバイダーは一緒に使用できる
- AWSプロバイダーよりもAWSCCプロバイダーの方がサポートするのが早いので、お互いに補完しながら使用できる
- デモ
- AWSCCプロバイダーからAWSプロバイダーへの移行デモを会場で実施
- imoprtとremoveブロックを利用してAWSCCプロバイダーからAWSプロバイダーでの管理に移行することができる
- まとめ
- AWSプロバイダーとAWSCCプロバイダーはお互いに補完し合う関係性にある
- S3のネイティブブロッキングを実装したのは、実はChrisさん！セッション内で紹介されて喜んでいたとのこと
AWS CDKにおけるL2 Constructの仕組み
登壇者：k.goto（AWS DevTools Hero）
- 前提
- CDKはTSで実装されているOSS
- セッションで扱うのはCDK内部のコードなので、一般的に業務で使うものではない
- Constructとは
- L1、L2、L3と数が増えるにつれて抽象度が上がる
- L3は1回の呼び出しで複数のリソースを作れるが、汎用性が低い
- 本家からほとんど出てない
- L2は単一のAWSリソースを対象にしている
- L1はCFnと完全対応
- 便利機能
- grantメソッド
- いい感じのIAM権限を付与してくれる
- Lambdaのビルドができたる、Docker/ECRのビルドができたりする
- grantメソッド
- L1、L2、L3と数が増えるにつれて抽象度が上がる
- なぜL2を取り上げるのか
- ユーザー側でL3を独自に作るのが一般的、L1は抽象度が低くて使いにくい
- L2は一つのプライマリリソースを持つ
- L1をラップしている
- Propsが渡されない場合は自動的に作成してれる
- L2Constructの仕組み
- 複数のコンポーネントがあるが、実際に作る場合には6つだけ意識すればOK
- Examplaというリソースを作る場合を考えると。。。
- IExample
- スタック外のリソースを擬似的に管理下に読み込むための型
- あくまで読み込み用
- ExampleAttributes
- Unowned Resourceを構成する情報になる
- ExampleBase
- 複数のConstructを実装するための共通クラス
- ExampleBaseProps
- 共通でセットしたいプロパティがあれば作る
- ExampleProps
- L2 Constructへの入力のためのStructs Interface
- サービス独自の表記などをクラスとして定義しておくことで、利便性が向上する
- Example
- L2 Construct本体
- L1をまとめて抽象化したもの
- 基本的にはCFnのデフォルト値に従い、AWSサービスとして指定すべき設定があればCDK側でデフォルト値を設定する
- IExample