インフラ食わず嫌いの フロントエンジニアが AWS CDK で自走するまで

小室 雅春 ( 朝日新聞社 ) フロントエンジニア (Vue.js, TypeScript) 好きなサービス AWS CDK, AWS Lambda Re:invent2019参加 自己紹介

> あらまし ● 2019年初めにあるメディアサイトの運用企画へ ● 10年来のレガシーシステム ○ アジリティーの低下 ● システムのモダン化を提案 ○ フロント部分の切り出し ○ 技術負債の解消(リアーキテクト) ○ PoCから徐々に本格化 ○ 中規模開発 ● 2019年末に一旦停止

> 開始当初の知識 AWSのサービス名と役割はなんとなくわかるが、 実際に構築した経験は微 チーム員にもAWSの強いエンジニアはいない

> 制約・要望 ● ビジネス部門なので、高速に構築し、運用コストは最 小限に -> サーバレス構成

> 設計 ● AWSのSAに相談 ● 社内の先輩に相談 ● 経験豊富なフリーランスエンジニアに相談 ○ 大抵BPは確立されているので、要件に合わせて一定の 解に落ち着く ○ 手をかけたくない、ここは硬くいきたい

> 要件・設計概要 記事管理 CMS 入稿 API連携 API フロント ● ZIPをSFTPで ● ID, PASS認証 ● 受け側でIP制限 ● IP制限 ● 記事を整形 ● DynamoDBに格納 DB ● ユーザ

いざ構築

> AWSって難しいくない？(初心者の壁) ● VPC？IAM？サーバレス？その他無限に広がるサービス群 ● 何が設定できて何が設定できないのか？知りたい -> 実際に触っていきたい

> どうやって触る ● コンソール、CLI ○ 簡単な動作の確認に向いている ○ なんとなくで設定できてしまう ● Provisioning(コード化) ○ 敷居が高い？ ■ 作業をコードに落とすことで、意味を具体化 ■ なんとなくで終わらない理解 ○ 構築されたインフラ構成を隅々まで一覧化できる ■ 実装した内容を記録できる、アドバイスをもらいやすい ■ ドキュメンテーション

> Provisioning Tools ● Cloud Formation Themplate ○ プリミティブにリソースを1から記述 ■ 初見には厳しい? ○ 記述が長い (数万行) ○ 変数の埋め込み方が独特 ● Terraform ○ 初めて見る設定言語HCL ○ 独特なファイル構成（.tfvars） ○ 独自の知識が必要

もっと一般的なツールで書きたい

> AWS CDK ● 2019/07/11 GA ● AWS純正 ● TypeScriptでプロブビジョニング(Python, JAVAも使用可能、、) ○ 一般的な(しかも慣れた)プログラミング言語 (内部もTS) ○ 高度な抽象化・モジュール化、環境ごとの切り替え ○ 既存の開発運用のノウハウを活かせる ○ 真のIasC ● 宣言的にリソースを記述可能 ○ シンプルで意図が伝わり安い ● Cloud Formationテンプレートを生成して実行 ○ 標準機能の安心、デバッグ性能、非ブラックボックス化

> TypeScript ● 2012年Microsoftが公開したAltJS ○ コンパイルするとJSに ○ JSの完全なスーパーセット ● 静的型付け ○ 省略も可能 ○ プロパティーの補完 ○ ドキュメンテーションの強化 ● フロントエンドからバックエンドまでコンテキストスイッチを最小に ○ Nuxt.js, API(node.js), AWS CDK, TestCafe

AWS CDKを使う

> Node.jsをインストール 公式サイトからDL

> CDKを開始 # AWS CDKをインストール npm i -g aws-cdk cdk init {{ app名 }} --language typescript # CloudFormationテンプレートを生成 cdk synth # 初回のみ cdk bootstrapを実行 -> Deploy用のS3バケットを準備 # CloudFormation実行 cdk deploy 参考: AWS CDK Workshop

> ディレクトリ構造 ● bin ○ 実行するコード ● lib ○ 各スタックを定義

> 基本的なエントリーコード // AWS CDKを読み込む import * as cdk from '@aws-cdk/core'; // CFと同じくStackという単位で管理 import { TestStack } from '../lib/test-stack'; // CDKを初期化 const app = new cdk.App(); // Stackを実行 new TestStack(app, 'CdkWorkshopStack');

> 基本的なスタック定義 /* Lamdbaに接続するAPI Gatewayを作成する場合 */ // 各種モジュールをインポート import * as cdk from '@aws-cdk/core'; import * as lambda from '@aws-cdk/aws-lambda'; import * as apigw from '@aws-cdk/aws-apigateway'; // exportでStackを公開 // Stackの実装はcdk.Stackを継承したClassに記述 export class TestStack extends cdk.Stack { // constructorに宣言したリソースが生成される constructor(scope: cdk.App, id: string, props?: cdk.StackProps) { // お決まり super(scope, id, props); // Lamdbaを作成 const helloLambda = new lambda.Function(this /*お決まり*/, 'HelloHandler' /*任意*/, /*ここが重要*/　{ runtime: lambda.Runtime.NODEJS_10_X, // ランライムのバージョン code: lambda.Code.fromAsset('lambda'), // ファイルシステムからLambdaのコードを読み込み handler: 'hello.handler' // ハンドラ名を指定 }); // API Gatewayを作成 new apigw.LambdaRestApi(this, 'Endpoint', { handler: helloLambda }); } }

> 実行 CdkWorkshopStack.Endpoint8024A810 = https://xxxxxxxxxx.execute-api.us-east-1.amazonaws.com/prod/

いざ構築

> 要件・設計概要(再掲) 記事管理 システム 入稿 API連携 API フロント ● SFTP(ID, PASS) ● IP制限 ● IP制限 ● 記事を整形 ● DynamoDBに格納 DB ● ユーザ

> 要件・設計概要(再掲) 記事管理 システム 入稿 API連携 API フロント ● SFTP(ID, PASS) ● IP制限 ● IP制限 ● 記事を整形 ● DynamoDBに格納 DB ● ユーザ

> 入稿 ● 社内の記事管理CMSから記事をZIPで受け取る ● 配信方法はID, PASS認証のSFTP ● セキュリティーの観点からIP制限をかけたい ○ 変な記事が入稿されたら大変 > 使用するサービス ● SFTPといえばAWS Transfer for SFTP ● 簡単にSFTPサーバを構築 ● 料金 0.30USD/Hour (216USD/Month)

> ID, PASSで認証したい ● Managed Identity Providers認証では鍵認証 ● 自前のAPIに接続することで、Custom Identity Providers認証が可能 ○ ActiveDirectoryへの接続などに利用 ● ハンズオン ○ CFテンプレートを流しながら確認できる > IPを固定したい ● Transfer for SFTP自体にはIP制限をかける機能はない ● VPC Endpointを使用できる

> 実際の構成 VPC Public Subnet Network Load Balancer 記事管理システム NACL AWS Lambda Amazon API Gateway Amazon S3 Transfer for SFTP IP制限 Private Subnet VPC Endpoint カスタム認証用のAPI

いざコードへ

ドキュメントを参照

● API リファレンス ● コンソールと同じような区分け

● Constructsに各種AWSリソース

No content

● Construct Props ○ 初期化する時に必要な引数

● Properties ○ 生成したリソースインスタンスが もつ情報

● Methods ○ リソースに対してできる操作

● Cloud Fromation ResourcesにCfnXxxx というクラス

> 二種類のコンストラクタ ● Low Level Cosntruct (Cfn) ○ Cloud Formation の記述と一対一で対応 ○ 新しいリソースなど ○ 例えば2020/02/06に追加されたWAFv2もCFNで使用可 ○ CFのリリース履歴 ● High Level Construct ○ CFリソースを抽象化し、使いやすく ○ デフォルトの引数を自動で定義 ○ 便利関数が生えている -> TransferもLow Level Constructで実装できる

デモ

> AWS CDKの注意点 ● HightLevelConstructを使用する場合、細かな設定が隠れる ● 宣言的な記述になる他め、コードを追わないと理解できない場合がある ● バグのあるコンポーネントがある ● 全部をコード化しようとしすぎない ○ CloudFormationでも難しいはず、、 ○ from ***のような関数が多数あり、手動で作成したリソースも読み 込める ■ ex) Route53 HostedZone, KMS ● スタックを分けすぎない ○ 依存性の宣言が複雑化

> まとめ ● AWS初心者(フロントエンジニア)でもAWS CDKは簡単にさわれた ● 細かい設定に関しても目を通し安い ● I as C を徹底することにより、チーム内でレビューができた ● フロントからインフラまでを通貫して管理しやすくなった

ありがとうございました。