2026-01-17

「AWSコンテナ設計・構築 [本格] 入門」を改定しました

はじめに

皆さん、お久しぶりです。horsewinです。今回、以前に出版をして反響をいただいた「AWSコンテナ設計・構築 [本格] 入門」の改定の機会を出版社からいただきました。

AWSコンテナ設計・構築[本格]入門増補改訂版

この執筆活動がようやく一息つきました。感慨深いです。そのため、本ブログにて改定した内容も含め、少し内容を紹介できればと思います。

いろいろと共にアウトプットさせていただいている共同執筆者の新井さん(@msy78)からも、きっと書籍の紹介があると思います。

そのため、私からは私が執筆したパートについて触れていきます。以降、改定した書籍は「増補改訂版」と記載します。

書籍について

初版

「AWSコンテナ設計・構築 [本格] 入門」は、2021年10月に出版されました。当時はECSやFargateにひたすらフォーカスして設計ノウハウの獲得や実践できるコンテンツが少なかったです。そのため、「プロダクション運用を念頭にしたコンテナ設計を体系的に学習したい方」「自ら手を動かしながらAWSサービスを学びたい方」に刺さる本を提供したいとなりました。

結果、フルカラー・単行本（ソフトカバー）で448ページという規模の本ができあがりました。図表151個、画面キャプチャ245個を盛り込み、視覚的にわかりやすさを追求した結果、257件のレビューで4.4という高い評価をいただきました。

増補改訂版

増補改訂版は全6章で構成しています。増補改訂版では、初版に掲載できなかった設計ポイントを追加し、初版から約4年経過した最新の知見を反映させるため、全面的にアップデートしました。全体の流れについては初版から大きく変えず、章中身のコンテンツアップデートをしています。

アップデートを加えた結果、フルカラー、単行本（ソフトカバー）で656ページ（208ページ増）の本ができあがりました。図表も199個、画面キャプチャが313個とこちらもパワーアップしました。私たちの本の信条として変わらず、図表で可能な限りわかりやすく直感的に伝えようと心がけました。

以下、それぞれの章の構成です。初版と比較して「Chap 03」が増えています。

Chap 01: コンテナの概要
Chap 02: コンテナ設計に必要なAWSの基礎知識
Chap 03: 基本的なAWS アーキテクチャデザイン
Chap 04: ECS/Fargateを中心としたコンテナ設計
Chap 05: AWSコンテナアーキテクチャの構築（基礎編）
Chap 06: AWSコンテナアーキテクチャの構築（実践編）

対象読者

初版と同様、増補改訂版でも次のような読者の方々を想定しています。

AWS上でコンテナ環境を構築しようとしている方
オンプレミスからクラウドネイティブなアプリケーション移行を検討されている方
Lift＆ Shiftに向けて、コンテナ技術を活用しようとしている方々
プロダクション運用を念頭にしたコンテナ設計を体系的に学習したい方
自ら手を動かしながら AWSサービスを学びたい方
最新の AWSコンテナアーキテクチャとプラクティスについて学びたい方

ハンズオンパートの紹介

今回もAWSのコンテナ周りの基本部分に加え、ハンズオンパートをメインで担当しました。こちらについて少し紹介をします。

Chap 05: AWSコンテナアーキテクチャの構築（基礎編）

まずはコンテナアプリケーションを動かしてみることを主題にしたハンズオンとなっています。フロントエンドアプリケーションとバックエンドAPIアプリケーションをコンテナベースで動かすように構築していきます。また、プロダクションレディを少しでも意識したネットワーク設計やセキュリティ設計を取り入れています。

アプリケーションフレームワーク、どういう構成や画面があれば親しみを持って動かしていただけるか？など、諸々悩みながら作り上げました。

ECSやFargateといったAWSコンテナの本質部分はマネジメントコンソールから構築し、一方、本質的でない部分はCloudFormationで自動化するなど、初心者がハマりやすいポイントを回避する工夫を心がけました。

Chap 06: AWSコンテナアーキテクチャの構築（実践編）

増補改訂版においても、Chap 6では基本編をパワーアップさせる実践編となっています。4章で触れたWell-Architectedフレームワークの柱を満たすように、ハンズオンが組み上げられていきます。初版においても骨があった内容となっていたのですが、増補改訂版ではそれ以上にパワーアップしました笑そのため、各ハンズオンをできるだけ独立させ、気になる部分から段階的に進められるような構成にしています。「これまでやったことがない。ぜひ試してみたい」というモチベーションを大切にしながら、充実したハンズオンを楽しんでいただきたいと考えています！

最大限の感謝を

初版でも多くの方にレビューを頂きました。しかし増補改訂版では、それを遥かに凌ぐ方々にレビューいただきました。そのおかげで書籍の内容がかなりブラッシュアップされました。我々だけでは、ここまでのクオリティは出せなかったと思います！

書籍の謝辞でも触れていますが、この場を借りて、改めてお礼を申し上げたいです。

さいごに

初版でも全く同じことを述べており、あまり改善されてはいないのですが、増補改訂版は初版と比較しても非常に長い時間をかけて執筆しました。そのため、執筆中にも次々と新しいサービスやアップデートが発表され、記述した内容の見直しを何度も行う必要がありました。特に直前に発表されたECS Managed InstanceとECS標準Blue/Green deploymentは取り込むべきか非常に悩みました。なお、結果的に取り込みました！！出版社の方には何度もご迷惑をおかけしました🙇

2021年と比較し、パブリッククラウドの進化の速度は変わらず速い状態です。一方で、サービスラインナップはコモディティ化が進み、最近はAIに関するアップデートが非常に活発になっています。コモディティ化された部分は長く使えるノウハウとなっていきます。それに加え、ものすごい速度でアップデートされるAI活用が今後は重要です。培ったコモディティ部分のノウハウ、AIを開発やデバッグ運用へうまく組み合わせることが今後の設計実装、そして運用のカギとなっていきます。自身の現場へ取り込める部分を持ち帰っていただければと思います。

ぜひ、多くの方々の手に届き、色々なフィードバックやディスカッションをできればと考えています。ありがとうございました。

AWSコンテナ設計・構築[本格]入門増補改訂版

2023-12-24

re:Invent Expoからスポンサー各社の技術傾向を知る

みなさん、こんにちは。horsewinです。 Japan AWS Ambassadors Advent Calendar 2023の12/25分のブログです！ラストランナーとして、BTC熊谷さんからバトンを受け取りました。

熊谷さんのブログでは、「システムのコスト見直しに利用できるAWSサービスと見直しをするべきタイミングについて」という話題に触れられていました。Amazon.com CTO Dr.Werner Vogels がre:Invent 2023 Keynoteの中で発表したドキュメントである「THE FRUGAL ARCHITECT」とも関連があるテーマで重要な観点でしたね。

thefrugalarchitect.com

このブログでは再度 re:Invent にテーマを戻していきます。 re:Inventでは数多くのコンテンツが提供されています。

Keynoteからの新サービス発表
事例セッション
サービスセッション
ワークショップ
Expo
GameDay/Jam
etc...

現地にいる温度感を全力で感じることができるKeynoteはいわずもがなですが、ワークショップやGameDayも非常にオススメです。しかし、今回のブログではあえてExpoに言及します。

Expoはre:Invent スポンサー企業の方々が自社プロダクトやサービスの紹介をする場です。多くの企業がどういったビジネスや技術に関心を持ってプロダクト作りをしているか見ることができます。AWSに携わるプロダクトが2023年時点でどこに関心を持っているか、という2023年の締めとしてよいテーマかなと感じたため、こちらでエントリをします！

今回触れること、触れないこと

次の内容について、本エントリで述べていきます。

触れること

re:Invent 2023 Expo概要
Expoに出展している企業やプロダクトの分類
出展傾向から見える技術活用の傾向

触れないこと

re:Invent 2023 Expoへの出展方法
各社/各プロダクトの詳細
SWAGの内容

では、本編に進んでいきましょう。

re:Invent 2023 Expo概要

re:Invent 2023 Expo（以降、Expo）とはAWSパートナーであるre:Invent スポンサー企業の方々が自社プロダクトやサービスの紹介をする場です。ブース展示をしているサービス紹介をする流れです。re:Invent 2023ではAWSのブースも含めて406のブース展示がありました*1。

私が以前参加をした2019年ではイベント開始時点でExpoがオープンされていた記憶があります。今回2023年は初日16時からWelcome Receptionという形でオープンされました。

オープンして入場をすると人の洪水に流されつつ、VMwareとHashiCorp等の大きなブースが目の前に展開されていました。

Expo全体像は次のようになっています。真ん中の「AWS Village」にはAWSの各種サービスカテゴリごとにブースが用意されており、サービス担当者と会話ができます。また、Infrastructure Solutions Zone、Security Zoneのように類似したサービスがまとめられているのも特徴かと思います。

Expoに出展している企業やプロダクトの分類

前節では、Expoの概要に触れました。こちらで出展しているブースはAWSパートナーである会社スポンサーであることから、いずれもAWSに関連するプロダクトであると考えられます。

では、AWSに携わるプロダクトが2023年時点でどこに関心を持っているかという観点で、出展内容を調査していきます。これにより、AWSを利用してどういったビジネスが展開されているかを知るきっかけづくりに活用ください。

まず、カウンティングした企業/プロダクト一覧の分類分けをします。ブースの中にはAWSのブースもありますが、そちらは明示的に除外しました。 Expoに展示をしている企業一覧に対して、次のようにカテゴリを割り振っていきました。

会社名	カテゴリ情報
Abacus.AI	人工知能 (AI)
Acorn Labs	データ分析
Aerospike	データベース
AI21	人工知能 (AI)
Aisera	人工知能 (AI)
・・・	・・・
Zscaler	セキュリティ

こちらのカテゴリ分けですが、大枠は生成AIにデータ投入をしてカテゴリ分けをしてもらいました。最初はChatGPT、Bardを使ったりしていたのですが、今回のブログ用にはBedrockのClaude 2.1を活用しました*2。TemperatureやTop Pの値はあまりいじらず、プロンプトを少し工夫して出力してもらっています。大枠を生成AIで割り振ってもらった後、細かいところは自分で製品概要をチラ見しながらカテゴライズをしました。

次の表がTop15となります。すべて列挙すると見づらいところもあるためTop15以降はその他として分類しました。

カテゴリ	総数(401)
セキュリティ	55
ITサービス管理	41
データ管理	32
データ分析	24
ITコンサルティング	22
データベース	20
ソフトウェア開発	18
人工知能 (AI)	13
オブザーバビリティ	13
DevOps	11
ネットワーク	10
FinOps	9
ストレージ	9
インフラ管理	8
バックアップ	8
その他	108

出展傾向から見える技術活用の傾向

ここまででブース出展の分類を知ることができました。分類結果をいくつか見ていきましょう。

変わらず強いセキュリティ

やはりセキュリティ分野を手がけるAWSパートナーは多いことがわかります。有名どころのCrowdStrikeやTrend Micro以外にも筆者の知らないセキュリティプロダクトが多数ありました。 AWSのサービスアップデートにも、「AWS Security Hubコントロールのカスタマイズが可能」、「Amazon GuardDutyが脅威検知の対象範囲を拡大」や「InspectorがEC2のエージェントレス診断に対応」などおもしろいアップデートが多数ありました。

セキュリティへの投資は各社まだまだ続くと見てよいでしょう。

aws.amazon.com

複数のプロダクトを扱うパートナーが多い

分類「ITサービス管理」が2番でした。「ITサービス管理」のネーミングは生成AIがつけたのですが、こちらには複数のプロダクトを取り扱う企業を分類しています。例えば、JIRAやConfluenceを持つAtlassianさんなどです*3。

ここから見えることとして、単独プロダクトに特化せず複数のプロダクトを有機的につなげることで1つのエコシステムを醸成しようとしている企業が多いことがわかります。

特に大企業の場合、複数の技術を活用することでいわゆるSPoFをなくして安定した売上を確保するという思想からも自然かと思います。

FinOpsがジワジワきている

FinOpsは「Financial Operations」の略称です。つまり、企業の財務に関わるオペレーションや判断を効率化することを指しています。AWSを含むパブリッククラウドの文脈の場合、クラウドコストの最適化を行うことによるコスト管理の改善として考えるとわかりやすいです。

今回のre:Invent 2023の発表でも、「CostExplorerの新規UI」や「Cost Optimization Hubの提供を開始」など、よりコスト管理やコストの最適化に向けた発表がありました。

aws.amazon.com

冒頭で述べた24日担当の熊谷さんのブログやTHE FRUGAL ARCHITECTでも同じようにコストへの着目がありましたね。

アーキテクトとして活躍するためにはアプリケーションの構築のみならず、コストを強く意識することが今後AWSを活用してビジネスを作り上げていく際に必要な素養であることが見える分類結果となりました。

人口知能(AI)が意外と少ない？

最後にAI周りの分類結果についても触れます。

Bedrockでも利用可能なモデルであるJurasic-1を手がけるAI21 LabsやPerplexity AIなどはこちらのカテゴリとなります。

AI/MLの発表は今回のre:Invent 2023でも多かったことからAIプロダクトのブースもきっと多いだろうと推測していました。一方、AIを全面に出しているプロダクトは予想よりも少なかったです。

こちらの理由は明白で、各企業はあたりまえのようにプロダクトへAI技術を組み込んでおり、それをメインテーマとしていないからでした。

セキュリティプロダクトでは異常検知へのAI活用
オブザーバビリティプロダクトではインシデント、依存関係等の自動検出にAI活用
ソフトウェア開発プロダクトではコード生成にAI活用
etc...

AIの民主化が進み、誰でもAIを活用できる現在だからこその結果ですね。

今回、一番熱狂したであろうAmazon Qの発表も踏まえると、AWSを活用していく中でもAIは不可避になってきています。当たり前にAIの力を借りながら、ビジネスへの活用を加速していきたいですね。

aws.amazon.com

まとめ

今回のブログでは、re:Invent を軸としてAWSのサービスアップデートのみならず、周辺環境の変化について考察してみました。 2023年の動向をAWSパートナーのプロダクトカットでとらえながら、2024年の技術がどのように進化していくかをワクワクしながら新年を迎える準備をしていきましょう〜。

以上、Japan AWS Ambassadors Advent Calendar 2023のまとめをhorsewinからお届けしました。

qiita.com

*1:Exhibitor Floor Plan - AWS Re:Invent 2023 をベースにカウントしています。

*2:最初はClaude Instantを使っていたのですが、いい感じにならなかったので2.1を使うことにしました

*3:会社さんによってはITコンサルに近い会社さんもいて、どう分類しようかと悩みました。

2023-12-10

CDKで作ったLambdaをremote-invokeでも動かす

みなさん、こんにちは。horsewinです。最近というか2023年はBlogを全然書けていなかったことに愕然としています。

AWS CDK Advent Calendar 2023 10日目の記事となります。

AWS CDK（以降、CDK）で作成したLambdaやStep Functionsを自分のローカル環境で検証するにはいくつかの方法があります。そのうち、筆者が好きな方法は実際の動作と近い形で検証する方法です。具体的には、AWS Serverless Application Model（以降、SAM）のinvoke機能を利用します。 SAMのinvokeにはlocalとremoteがありますが、今回はremote(以降、remote-invoke)を上手く活用する方法について言及します。

CDK本線の機能ではないですが、CDKのコードと近い場所でアプリケーション（特にLambda）を作る際に動作検証はみんなどうやっているんだろう？と疑問になり、1つのプラクティスとして紹介しようと思った次第です。

今回触れること、触れないこと

次の内容について、本エントリで述べていきます。

触れること

CDKとLambda開発の相性の良さについて
Lambdaの動作検証方法について

触れないこと

CDKの概要や詳細
CDK本線のプラクティス
SAMのプラクティス
Lambda以外のinvoke

では、本編に進んでいきましょう。

CDKにおけるLambda開発の手軽さ

CDKでは、インフラストラクチャを作るコード（以降、IaCコード）とLambdaなどのアプリケーションコードを次のように同居させます。次の例はcdk initで作成したディレクトリ構成にLambdaコードを同居させた例です。通常のIaCコードの中にlambdaディレクトリを作成して、その下にアプリケーションのコードを置きます。

❯ tree -L 2 -I node_modules .
.
├── README.md
├── bin
│   └── cdk2023advent.ts
├── cdk.json
├── cdk.out
├── jest.config.js
├── lambda
│   └── hello.js
├── lib
│   └── cdk2023advent-stack.ts
├── package-lock.json
├── package.json
├── test
│   └── cdk2023advent.test.ts
└── tsconfig.json

シンプルなコードの場合、ローカルで開発したLambdaのコードをそのままコピーして、AWSマネジメントコンソールのLambda上のGUIへ直接貼り付けて、コード更新も可能です。一方、アプリケーションの中で外部モジュールを利用する場合、コードアーティファクトをZip圧縮してからアップロードするなど手間がかかります。そのような手間があるため、Lambdaを開発/デプロイするフレームワークや手法がCDK以外にもいくつかあります。

AWS CLIを用いて直接アップロードする
SAMを利用してデプロイする
Serverless Frameworkを利用してデプロイする
Chaliceを利用してデプロイする（Pythonの場合）

筆者は意外とSAMも利用します。例えば、CDKを用いて構築していない既存のインフラに対してLambdaを含むサーバレスなアプリケーションをシンプルに展開したい場合はSAMを使うことがあります。ただし、Node.jsランタイムのLambdaを構築する場合は、NodejsFunctionという便利なコンストラクトがあるためCDKを使います。

docs.aws.amazon.com

他のツールと比べてCDKにおけるLambda開発の手軽さはどこにあるでしょうか。大きなポイントは個人的には2つあります。

IaCコードとアプリケーションコードが近くにある

1点目は、IaCコードとアプリケーションコードを近くに配置することで、双方の状態をコンテキストスイッチを少なく閲覧できる点です。 Lambdaでアプリケーションを作るメリットは、書いたコードがすぐに動くところにあります。加えて、AWSのほかサービスとの統合が容易な点と考えています。 AWSのほかサービスとの統合をする際にIaC側で作成したリソースを活用するケースが多くあります。 IaCコードのリポジトリとアプリケーションコードのリポジトリが分断されていると、ワークスペースの行き来が発生することによるコンテキストスイッチが発生します。これはコーディングする上で少しストレスがたまります。できるだけIaCコードとアプリケーションコードが近い場所にあることで双方が閲覧しやすいのがメリットです*1。また、双方のコードが近くにあることでインフラ見ているメンバとアプリケーションを見ているメンバの会話がしやすくなるといったメリットもあります。

`cdk deploy`によるシームレスなデプロイ

CDKプロジェクト下にあるlambdaはIaCのデプロイと同じライフサイクルでデプロイができます。 IaC側をデプロイして、次にアプリケーションコードをデプロイするという順番を踏まずともシームレスにデプロイができるのは開発者体験としては非常に良いです。

CDKプロジェクト下で開発したアプリケーションの動作検証

今回の本題です。アプリケーションを作成した後は動作検証をしなければいけません。書いたコードが一発で動くというのは幻想です（筆者の感想です）。では、CDKプロジェクト下で書いたLambdaはどうやって動作検証するのでしょうか。

クラウド上のLambdaを更新してLambdaのコンソール上から実行をするのが一番シンプルではあります。しかし、この方法の場合、Lambdaを更新（cdk deploy）→ブラウザに切り替えて画面を更新→Lambda実行という流れになり、ガンガンコンテキストスイッチが入ります。修正が頻繁に発生するケースでは、この方法ではしんどいものがあります。

Lambdaの動作検証にはコンソール実行も含めて次のケースがあります（前後で連携するAWSサービスによっては選択できないものあり）。

Lambdaコンソールから実行する
nodeやts-nodeによってLambdaハンドラを動かす
AWS CLIでLambda invokeコマンドを実行する
SAMのsam local invokeで実行する（以降、local-invoke）
SAMのsam remote invokeで実行する
その他フレームワークでサポートするコマンド(serverlessであれば、serverless invoke）

数年前は1〜3ポチ目で実行をするケースが多かった気がします。最近は、SAMのドキュメントにもCDKアプリケーションをローカルでテストするという内容が追加されており、SAMを利用する例が多くなっている感覚があります。 docs.aws.amazon.com

`sam local invoke`

名前の通り、AWS側にあるLambdaではなく、ローカルのコードを元にLambdaを擬似的に実行します。仕組みとしては、Lambdaランタイムが動作するDockerコンテナの内部でビルドしたLambda関数を動作させています。図にすると次の通りです。

次のCDKのコードがあるとします。

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as lambda from "aws-cdk-lib/aws-lambda";

export class Cdk2023AdventStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new lambda.Function(this, "HelloHandler", {
      functionName: "cdk2023advent",
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset("lambda"),
      handler: "hello.handler"
    });
  }
}

Lambdaのコードは次のように非常にシンプルです。

exports.handler = async function (event) {
  console.log("request:", JSON.stringify(event, undefined, 2));
  return {
    statusCode: 200,
    headers: { "Content-Type": "text/plain" },
    body: `Hello 2023's Advent calendar!\n`
  };
};

CDK下のLambdaである場合、cdk synthによって生成されたCloudFormationテンプレートをInputとして、Lambdaのどのランタイムを動作させるかを指定します。そのため事前にcdk synthやcdk deployによって、CloudFormationテンプレートを作成しておきます。

❯ cdk synth

# -tにテンプレート名を指定、その後にCDKコードで与えたIDを指定
❯ sam local invoke -t ./cdk.out/Cdk2023AdventStack.template.json HelloHandler
Invoking hello.handler (nodejs18.x)                                                                                                                                  
Local image is up-to-date                                                                                                                                            
Using local image: public.ecr.aws/lambda/nodejs:18-rapid-x86_64.                                                                                                     
                                                                                                                                                                     
Mounting /Users/uma/xxx/cdk.out/asset.8d6cbc7038fd2b5b34d654a49fdd3f4936bbae6aeae4657a2a15212537ac1977 as             
/var/task:ro,delegated, inside runtime container                                                                                                                     
START RequestId: 99e2c900-f883-4876-a021-355caa6246d4 Version: $LATEST
2023-12-09T14:15:54.108Z        99e2c900-f883-4876-a021-355caa6246d4    INFO    request: {}
END RequestId: 99e2c900-f883-4876-a021-355caa6246d4
REPORT RequestId: 99e2c900-f883-4876-a021-355caa6246d4  Init Duration: 1.17 ms  Duration: 1274.96 ms    Billed Duration: 1275 ms        Memory Size: 128 MB     Max Memory Used: 128 MB
{"statusCode": 200, "headers": {"Content-Type": "text/plain"}, "body": "Hello 2023's Advent calendar!\n"}

`sam remote invoke`

Lambdaだけで閉じるコードであれば、で十分です。一方、Lambdaだけで閉じるコードは意外と少なく、DynamoDBにデータを書き込み、SQSにデータを書き込みなど他のAWSサービスと連携させるケースが多々あります。ローカル端末にAWSサービスへの操作権限を持つクレデンシャルを持っている場合、local-invokeでも他サービスと連携ができますが、厳密な動作検証とはなりません。やはり、Lambdaに付与したIAMロールを用いてサービス間連携まで含めた動作検証をしたいところです。

SAMのCLIでは、local以外にremoteのinvokeがあります*2。これはその名の通り、remote＝クラウド上にアップロードされたLambdaを起動させるためのコマンドです。

docs.aws.amazon.com

Dry-runや非同期呼び出しなど複数のモードもサポートしており、オプションも豊富です。冒頭で述べた通り、筆者が好きな方法は「実際の動作と近い形で検証する方法」であるため、ちょっとした修正の場合はこちらの動作検証を使いたくなります。

一方、SAMではlocal-invokeと同じメンタルモデルでremote-invokeを利用できますが、CDKの場合は少し工夫が必要となります。 remote-invokeを試してみましょう。

❯ sam remote invoke --stack-name Cdk2023AdventStack
Invoking Lambda Function HelloHandler2E4FBA4D
{"statusCode":200,"headers":{"Content-Type":"text/plain"},"body":"Hello 2023's Advent calendar!\n"}START RequestId: 1ea7fc42-abab-463d-9684-62ba77771a02 Version: $LATEST
2023-12-09T14:40:01.099Z        1ea7fc42-abab-463d-9684-62ba77771a02    INFO    request: {}
END RequestId: 1ea7fc42-abab-463d-9684-62ba77771a02
REPORT RequestId: 1ea7fc42-abab-463d-9684-62ba77771a02  Duration: 18.66 ms      Billed Duration: 19 ms  Memory Size: 128 MB     Max Memory Used: 67 MB

Lambda関数が1つしかない場合は普通に動きますね。もう1つ、Lambda関数を追加してみましょう。

import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as lambda from "aws-cdk-lib/aws-lambda";

export class Cdk2023AdventStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new lambda.Function(this, "HelloHandler", {
      functionName: "cdk2023advent",
      runtime: lambda.Runtime.NODEJS_18_X,
      code: lambda.Code.fromAsset("lambda"),
      handler: "hello.handler"
    });

+   new lambda.Function(this, "HelloHandler2", {
+     functionName: "cdk2023advent2",
+     runtime: lambda.Runtime.NODEJS_18_X,
+     code: lambda.Code.fromAsset("lambda"),
+     handler: "hello.handler"
    });
  }
}

cdk deploy後、再度remote-invokeを実行するとエラーとなります。

# 実行対象が見つけられずにエラーとなる
❯ sam remote invoke --stack-name Cdk2023AdventStack
Error: Cdk2023AdventStack contains more than one resource that could be used with remote invoke, please provide resource_id argument to resolve ambiguity.

実行対象のLambdaを特定するためには、「Lambdaリソースの論理 ID またはリソース ARN」が必要となります。 SAMの場合、CloudFormationテンプレートに相当するSAMテンプレートは開発者自身が作成します。そのため、論理IDに直感的な名前（例えば、HelloHandler）をつけることで直感的に動かすことができます。

一方、CDKの場合はCloudFormationテンプレートはcdk synthで自動生成され、論理IDはCDKにおまかせした値になります。今回の例では、1つ目のLambdaには「HelloHandler2E4FBA4D」という論理IDが付与されています。この値を指定することで、remote-invokeを動かすことができます。

❯  sam remote invoke --stack-name Cdk2023AdventStack HelloHandler2E4FBA4D
Invoking Lambda Function HelloHandler2E4FBA4D
START RequestId: ba09d479-0991-4ca8-a918-053d77db9550 Version: $LATEST
2023-12-09T14:52:30.683Z        ba09d479-0991-4ca8-a918-053d77db9550    INFO    request: {}
END RequestId: ba09d479-0991-4ca8-a918-053d77db9550
REPORT RequestId: ba09d479-0991-4ca8-a918-053d77db9550  Duration: 3.06 ms       Billed Duration: 4 ms   Memory Size: 128 MB     Max Memory Used: 67 MB        Init Duration: 166.06 ms
{"statusCode":200,"headers":{"Content-Type":"text/plain"},"body":"Hello 2023's Advent calendar!\n"}%

論理IDを調べて指定するのはつらい

と、めんどくさがりなわたしが言っています。もう少しいい方法がないものかと考えていたのですが、結論としてあまりいい方法はなかったです。

現状、取りうる代替策としては、次の方法ぐらいかなという状態です。

jqやyqコマンドでCloudFormationテンプレートから論理IDを引っこ抜く
functionNameプロパティを元にARNを直接指定する

1はお世辞にも直感的なコマンドにはならないため、筆者は2の方法で試すことが多いです。ただしLambda関数を作成する際に関数名もCDKにおまかせしている場合は、1の手段が必要となります。

2の手段としては次のような使い道になります。

❯ FN=cdk2023advent; sam remote invoke arn:aws:lambda:${CDK_DEFAULT_REGION}:${CDK_DEFAULT_ACCOUNT}:function:${FN}
Invoking Lambda Function arn:aws:lambda:ap-northeast-1:123456789012:function:cdk2023advent
2023-12-09T15:24:47.141Z        acbdc675-3dea-46b7-9e7e-67187075b791    INFO    request: {}
START RequestId: acbdc675-3dea-46b7-9e7e-67187075b791 Version: $LATEST
END RequestId: acbdc675-3dea-46b7-9e7e-67187075b791
REPORT RequestId: acbdc675-3dea-46b7-9e7e-67187075b791  Duration: 13.22 ms      Billed Duration: 14 ms  Memory Size: 128 MB     Max Memory Used: 67 MB
{"statusCode":200,"headers":{"Content-Type":"text/plain"},"body":"Hello 2023's Advent calendar!\n"}

ARNを直接指定しているため、--stack-nameの指定が不要となっています。 CDK_~で始まる環境変数は事前に設定しておく必要があります。

local-invokeの場合はシンプルにLambdaのリソースID指定で動かせた分、少し煩雑に感じます。現状はこの方法が落とし所にはなりますが、remote-invokeを使えることでAWSサービスと連携するLambda開発が捗ることを期待しています。

まとめ

以上、SAMではなくCDKで作ったLambdaをremote-invokeでも動かす方法について本記事では触れていきました。

remote-invokeではLambda以外にもStep Functions実行やSQS、Kinesisへのデータ送信も可能です。少しでも画面移動のコンテキストスイッチを減らしつつ、高速開発を進めたい方は参考にしてみてください。

*1:ただし、全てのアプリコードがIaCのコードと結合しているべき、とは考えてはいません

*2:sam remote invokeはSAM CLI バージョン 1.88.0 以降で利用可能です

2022-12-15

cdk8sやcdk8s+ではじめるKubernetes

みなさん、こんにちは。horsewinです。

AWS CDK Advent Calendar 2022 15日目の記事となります*1。

AWS CDK（以降、CDK）でKubernetes（k8s）のYAMLが記述できるライブラリである、AWS CDK for Kubernetes/cdk8sに触れていきます。 CDKの開発者体験でKubernetes マニフェストを作成できるため、YAMLでマニフェストを書くのに疲れた人は立ち寄ってみてください。

今回触れること、触れないこと

次の内容について、本エントリで述べていきます。特に2022年に晴れて一般公開（GA）となったcdk8s+は、CDKらしさである抽象化が実現されているためオススメです。

触れること

CDKで構築するKubernetes マニフェスト(cdk8s)
より抽象的に記述できるcdk8s+について

触れないこと

CDKの概要や詳細
Kubernetesについて
Kubernetesの運用ノウハウ*2

では、本編に進んでいきましょう。

cdk8sについて

まずは、cdk8sについて触れていきます。cdk8sを一言で述べると、「CDKでKubernetes マニフェストを記述できるOpen Source Software」となります。 2020年2月にGitHub上でTagが切られ、2020年5月に最初のニュースプレスが出ました。

aws.amazon.com

そして、2021年10月に一般公開（GA）しています。

aws.amazon.com

cdk8sの概念図

cdk8sは、次の図のような概念で構成されています。

App
- cdk8sアプリケーションの最上位要素
- Chartとの依存関係や各Chartのパラメータを定義
Chart
- 自動生成されるYAMLの単位
- 複数のConstructsの依存関係を定義
- Chartの入れ子は別YAMLとして生成されるので注意
Constructs
- マニフェストを構成するコンポーネント（基本となる要素）
- 用意されているConstructsを組み込んだ独自Constructsの作成も可能

cdk8sのしくみ

実装を見たほうが早いため、次のDeploymentを記述するTypeScriptコードを見てみます。

KubeDeploymentというConstructsを利用してDeploymentを生成しています。 Constructsについては通常のCDKと同様のパラメータを取ります。scope/id/propsの3つのパラメータはCDKを書いていると見慣れるものになりますね。前述したDeploymentのコードからYAMLを生成すると次のようになります。

このようにcdk8sでは、CDKで対応しているプログラミング言語でKubernetes マニフェストの元となるコードを作成し、最終成果物としてYAML マニフェストを生成します。そしてkubectl applyコマンド等を用いて、Kubernetes クラスタにマニフェスト定義を適用するという仕組みをとっています*3。

では、少しコード部分を見てみます。第3引数であるPropsに与えられているパラメータに着目してみましょう。 specという要素にDeploymentコンポーネントのパラメータであるレプリカ数やselector定義、Podのテンプレート定義などが記載されています。 Propsで与えている内容を見ると、KubernetesのYAML マニフェストの記述とあまり変わらないと感じるでしょう。それもそのはずです。cdk8sで書かれたコードとYAMLのリソースの定義は1対1対応しています。通常のCDKを書いていても、CloudFormationのコードをそのまま書くConstructsがいます。

そう。cdk8sはCDKでKubernetes マニフェストを記述する上でL1 Constructsのように振る舞っているのです。ただし、TypeScriptで記述されているためパラメータ名や変数名、三項演算子なども利用できます。もちろん、IDEの補完もバリバリ効きます。ここは大きなメリットと感じる人もいるでしょう。しかし、cdk8sの真価はこの先になります。それが「cdk8s+」です。

cdk8s+について

cdk8s+を一言で述べると、「CDKでKubernetes マニフェストを記述できて、いい感じにデフォルト値を補完してくれるツール」となります。 2020年2月にGitHub上でTagが切られ、2020年5月に最初のニュースプレスが出ました。

aws.amazon.com

そして、2022年10月に一般公開（GA）しています。

aws.amazon.com

cdk8s+のしくみ

では、cdk8sと同様にDeploymentのTypeScriptコードを見てみます。

前述したcdk8sと比較して、指定しているパラメータがかなり少なくなりました。このDeploymentのコードからYAMLを生成すると次のようになります。

多くのパラメータが補完されて、Kubernetes マニフェストが生成されていることがわかります。これはまさに、CDKで抽象化されたConstructsである、L2 Constructsの思想と言えます。例えばcdk8sでは、Deploymentの対象とするPodを選択するselectorを明確に記述していました。一方、cdk8s+ではselectorの定義をせずとも、自動生成されたlabelを元にしてselectorが設定されたDeploymentが生成されます。このあたりのいい感じにめんどくさい定義を吸収してくれるのがCDKっぽさがありますね。他にもsecurityContextがしっかり設定されており、このあたりはCIS for Kubernetesのプラクティスを参考に作られているように感じます。

cdk8sのみではYAML マニフェストと1対1対応で書いていたコードがかなり簡略化されてかける魅力、それがcdk8s+です。

Pros&Cons

ここまで簡単ながら、cdk8sとcdk8s+について紹介しました。cdk8s、cdk8s+のいいところ、苦手なところについても見ていきます。

cdk8s, cdk8s+のいいところ

まずはcdk8s, cdk8s+のいいところについて触れていきます。3つポイントを記載しています。

プログラマブルにマニフェストの作成が可能
Helmとの連携
CDKと連携したデプロイが可能

プログラマブルにマニフェストの作成が可能

ここはすでに言及した箇所でもあります。CDKのメリットの1つは、自分たちが得意または好きなプログラミング言語 *4を選択して、Infrastructure as Code（以降、IaC）を記述できる点にあります。 cdk8s等においても本メリットは享受できます。特に静的型付けがあるTypeScript、Golang、Javaを使えばYAMLではできない強固な型チェックが可能となります。

さらに、cdk8s+を使えば、デフォルト値をうまく活用した最小限の設定でKubernetes マニフェストのベースとなるコードの記述が可能です。

環境ごとのマニフェストの切り替えも可能

プログラマブルにKubernetes マニフェストを作成できる点について、もう少し踏み込んでみます。例えば、Iacを使う利点として、コードを記述すれば開発環境やステージング、プロダクション環境といった複数環境をかんたんに生成できる点があります。複数の環境を構築する際、環境特性に応じて設定値を変更する場合があります。開発環境ではコスト削減のためにECSのタスク数を少なく設定し、プロダクション環境では想定したトラフィック数に合わせて大きく設定する等です。

Kubernetesでは、環境ごとにKubernetes マニフェストを切り替えるためには次のようなツールを使うケースがあります。 - kpt - Kustomize

cdk8sでは、cdk8s synthコマンドでKubernetes マニフェスト生成を実施するため、コマンドにわたすパラメータによって環境ごとのKubernetes マニフェストの生成が可能です。 CDKでも同様のアプローチで環境ごとに設定したい値を切り替えるプラクティスがあります。つぎの動画で詳しく説明されていますのでCDKを実践されている方は参考にするとよいかもしれません。

youtu.be

Helmとの連携

HelmとはKubernetes用に構築されたソフトウェアを検索、共有、使用するための方法を指しています。この記事では、ソフトウェアを使用する文脈で使用します。 HelmはDocker Hubのように、パブリックに公開されたKubernetes コンポーネントと理解すると早いかもしれません。 KubernetesではHelmを利用して外部ライブラリからコンポーネントを取得して、自身のKubernetes クラスタに展開することがあります。

Helmリポジトリに公開されているHelmチャートをcdk8sから直接利用できるため、Kubernetesのエコシステムを有効活用可能です。

CDKと連携したデプロイが可能

こちらは良いところとするか非常に悩みました。 CDKで生成または取り込みをしたEKSに対して、cdk8sで作成したコードを直接利用できるという内容です。コードベースで具体的に見てみます。*5

import * as blueprints from "@aws-quickstart/eks-blueprints";
import { App } from "aws-cdk-lib";
import { MyCdk8sChart } from "../lib/k8s/service";
import * as cdk8s from "cdk8s";

const stack = blueprints.EksBlueprint.builder()
  .account(process.env.AWS_ACCOUNT_ID)
  .region("ap-northeast-1")
  .build(new App(), "eks-blueprint");

const myCdk8sChart = new MyCdk8sChart(new cdk8s.App(), "MyCdk8sChart");
stack.getClusterInfo().cluster.addCdk8sChart("my-cdk8s-chart", myCdk8sChart);

CDKの管理下にあるEKSに対して、addCdk8sChartという処理を追記することでcdk8sで記述したKubernetes マニフェストをEKSに紐付けることができます。 Kubernetes クラスタへの反映についても、kubectl applyを実行せず、cdk deployコマンドによって実施できます。内部的には、cdk8sでKubernetes マニフェストを生成→Lambdaでkubectl applyを実行してKubernetesリソースを更新という動きのようです。

ここの説明のみだと、いいこと尽くしに見えます。一方、cdk8sの思想としてはあくまで「Kubernetes マニフェストを生成すること」にフォーカスを置いています。マニフェストを生成した後、Kubernetes クラスタへのデリバリについては別の責務だということです。そこをCDKと連携してマニフェストの生成とデプロイまでを一貫した責務とするのは私としてはモヤつくところがあります。

しかし、CDKの体験の延長でデプロイまで実施できることはよい点の側面もあるため、良いところとして紹介しました。

cdk8s, cdk8s+の苦手なところ

最後にcdk8s, cdk8s+の苦手なところや注意点について2つポイントを述べます。

cdk8s単体ではデプロイはできない
デフォルト値とコントロールプレーンの設定の衝突

cdk8s単体ではデプロイはできない

ここまで何度か述べていきましたが、cdk8sの思想としてはあくまで「Kubernetes マニフェストを生成すること」にフォーカスしているため、必然とも言えます。しかし、CDKの体験の良さとしてはIDEサポート以外にもシンプルにデプロイできる、ホットリロードなどもあると考えています。デプロイの責務がコーディングと明確に分離されていることはメリットである反面、CDKを利用してきた人から見たときはデメリットとなりえることがあると考えました。

しかし、Kubernetesでよく実践されているGitOpsのようなアプローチにはcdk8sの思想は非常にマッチしています。責務の割り切りや、デプロイ以降はKubernetesの世界観や開発者体験に寄せているのは共感を持てました。

デフォルト値とコントロールプレーンの設定の衝突

こちらは抽象化コンポーネントである、cdk8s+の難しい点です。抽象化されているが故に予想外のオプションが設定されることがあるということです。すでに本記事で見た通り、cdk8s+は短いコードでリッチなKubernetes マニフェストを生成していました。 L2 Constructsのように、Recommendedなデフォルト値が設定されてKubernetes マニフェストの生成処理がなされたためです。この挙動についてはcdk8s+の魅力であり、非常によい点です。一方、設定されたデフォルト値がうまくワークしないケースもあります。

Kubernetesには、Admission Controllerという機構があります。 Kubernetes コンポーネントをデプロイするためにはkube-apiserverを介したAPIコールが必要となります。APIコールをする際に3つのフェーズを通過します。

認証処理
認可処理
Admission Control（リクエストのインターセプトやリクエストの改変、チェック）

3が今回フォーカスしている点です。3のAdmission Controlのフェーズでは、リクエストをチェックして、特定の設定がされていない場合はAPIを通過させないというガード機構を実現しています。 Kubernetesコントロールプレーン側に備わるAdmission Controllerというガード機構がデフォルト値とうまくマッチしないケースがまれにあります。

具体例について述べます。cdk8s+でPod定義を作成すると、Pod Security Contextの設定（YAMLのsecurityContextの部分）が入ります。Pod Security Contextの設定の1つにrunAsNonRootというものがあります。これは、root権限以外でコンテナを実行するという内容です（root権限でコンテナを起動されてしまうと権限奪取による危殆化などのリスクが有るためですね）。しかし、runAsNonRootを指定した場合、明示的なUIDを指定しなければAdmission Controllerのガード機構に防御されることがあります。この場合、runAsUserを指定して、Podを生成することでAdmission Controllerのチェックを通過することができます。

このように、cdk8s+が作成してくれたデフォルト値とKubernetes マニフェストを適用するKubernetes クラスタの設定が衝突する可能性について覚えておくとよいでしょう。

まとめ

以上、cdk8sやcdk8s+について本記事では触れていきました。かんたんにまとめます。

cdk8sはCDKでKubernetes マニフェストを生成可能としたソフトウェアです。CDKのコーディング体験でKubernetesのマニフェストの生成が可能となります。また、Kubernetes マニフェストの生成にフォーカスしているため、AWSのみならずオンプレミスやほかクラウドで動作するKubernetesにも適用ができます。 cdk8sでは、いわゆるL1 ConstructsとしてKubernetes コンポーネントを記述できます。しかし、よりCDKらしくコードをかくためにはcdk8s+を使うと良いでしょう。

cdk8s+はcdk8sが提供しているライブラリです。L2 Constructsとして直感的にKubernetes コンポーネントを記述可能となります。

また、cdk8sとCDKを組み合わせて、CDKでインフラとKubernetes（EKSのみに限る）の集約した管理、デプロイも可能となります。ただし責務分離を意識して、デプロイはKubernetesのプラクティスを適用することをオススメします。

*1:本記事は、JAWS-UG CDK支部 #4の発表内容を元に作成しています

*2:当方、KubernetesについてはPoCで複数のプロジェクトに携わったレベルとなっております。Kubernetes上で動くワークロードを運用している経験はありません。そのため、本番運用ではこんな悩みがあるので難しいと思う！などのコメントは歓迎です。

*3:実際にKubernetesを運用すると本番環境に直接applyを叩くことはなく、GitOpsのような仕組みをとって、ArgoCD等を利用してクラスタに反映するのが良いと筆者は考えています

*4:2022年12月現在、利用できる言語はTypeScript/Golang/Java/Python

*5:EKS Blueprintを使って生成したEKSとは相性が悪いのであくまでサンプル程度にとどめてください

2021-10-18

「AWSコンテナ設計・構築 [本格] 入門」を執筆しました

はじめに

AWS x コンテナに関する商業誌を執筆しましたので、本ブログにて少し内容を紹介できればと思います。（しかし、見本誌をつみあげるとなかなか圧巻でした！）

amzn.to

f:id:horsewin:20211018102128j:plain — 見本誌

こちら、共同執筆者の新井さん (@msy78)や、監修いただいた佐々木さん(@dkfj)のブログでも触れられている内容になります。執筆に至った経緯などはお二人のブログでも語られていますので、↓をどうぞ。

『AWSコンテナ設計・構築[本格]入門』の監修しました - プログラマでありたい「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...!

このブログでは執筆者の一人である、私の視点からの書籍の紹介をいたします。

書籍について

本の概要

全5章で構成しています。本当は付録としてECSコンテナを扱うためのツールもいくつか紹介するための文章は書いていましたが、分量の関係上削らざるを得なかったので書籍単体としては全5章です。以下、それぞれの章の構成です。

1章コンテナの概要についてかんたんにウォークスルー
2章 AWSでコンテナを使うための組み合わせや学習方法、ユースケース
3章 ECS/Fargateでアーキテクチャ設計をするためのポイントをWell-Architectedアーキテクチャに照らしながら検討
4章 ECS/Fargateでウェブアプリケーションを動かすためのハンズオン
5章プロダクションレディに近づけるための実践的なハンズオン

対象読者

本書では、次のような読者の方々を想定しています。

これからAWSを活用してコンテナを学習しようとしている方
オンプレミスからクラウドネイティブなアプリケーション移行を検討されている方
Lift&Shiftに向けて、コンテナを活用しようとしている方々
プロダクション運用を念頭にしたてコンテナ設計を体系的に学習したい方
自ら手を動かしながらAWSサービスを学びたい方

特に、オンプレミスからクラウドへアプリケーション移行をしようとしている方、EC2などの仮想マシンでサービスを運用していた人のLift&Shiftを手助けしたいという想いが強いです。

本のメタ情報

単行本（ソフトカバー）で448ページとなります。そして驚くことにフルカラーです。当初は4色刷りというはなしでした。しかし、かなり熱量を込めて執筆し、図表の数が膨大になったためにこういった形をとっていただけたと思っています。

なお、図表が151個、画面キャプチャが245個です。図表は3章のコンテナ設計に関わる箇所が大きな比重を占めており、図表で可能な限りわかりやすく直感的に伝えようと心がけました。

冒頭で述べたとおり、本来であれば付録やさらに多くのキャプチャもつけていて、600ページを軽く超えていました。ですが、さすがに広辞苑にするわけにもいかないので削りに削って448ページ着地となりました。本が少し薄くなることを心がけて紙質も少し薄めのものをチョイスしています。 Kindle版もありますのでKindleやiPadにいれる選択もありですね。

また、2021-10-06時点でまだ予約販売の段階ですが、システム管理・監査部門の売れ筋1位となりました。2021-10-11時点でもシステム管理・監査部門の売れ筋1位 、コンピュータ・サイエンス部門で4位をキープしておりました。総じてありがたい限りです。

4章と5章を少しだけ紹介

私が担当した4章と5章について少し紹介できればと思います。

4章と5章はハンズオンのコンテンツとなっています。

4章では、まずはコンテナアプリケーションを動かしてみることを主題にしたハンズオンとなっています。とはいえ、プロダクションレディを少しでも意識したネットワーク設計やセキュリティ設計を取り入れています。また、4章の内容は以前に同人誌として出版した、「クラウドネイティブファーストストーリー」を下地としています。フロントエンドアプリケーションとバックエンドAPIアプリケーションをコンテナベースで動かすように構築していきます。

booth.pm

f:id:horsewin:20211010235844p:plain

5章では、3章で触れてきた内容の一部を4章のアーキテクチャに取り入れていきます。4章、5章とステップアップをして、3章のどの部分を実装しているかと対応付けることを意識してハンズオンを組み上げていきました。WAFの導入、FireLens(Fluent Bit)を利用したログ収集、DevSecOpsを意識したCI/CDなど骨のあるコンテンツを盛り込めたと自負しています。

f:id:horsewin:20211010235907p:plain

もちろん、実現したいビジネスやシステムの要件によっては足りない部分があるかと思います。その際は3章の設計ポイントと照らし合わせながら、作り上げたいアーキテクチャを自分たちのモノへアジャストしていただければと思います。

Special Thanks

本書は本当に数多くの方々にレビューを頂いてブラッシュアップできました。 APN Ambassadorである山口さん( @kinunori )やクラメソハマコーさん( @hamako9999 )、アイスリーデザイン久保さん( @seiyakubo )、弊社の佐古さん ( @sakon310 )やArumon(Arumon - NRI発若手中心スタートアップコミュニティ)メンバーなどなど、短い期間の中でのレビュー、本当にありがとうございました。

さいごに

本書はかなり長い期間をかけて執筆していたこともあり、当初記述した内容が古くなったり、どんどん新しいサービスが出てきたりしました（ECS Anywhere、App Runnerなどはキャッチアップと同時並行して加筆していきました）。

パブリッククラウドは本当に変化による陳腐化と進化がはやい領域です。しかし、そういった領域の中であっても、セキュリティ設計や運用設計などは従来の設計ノウハウが残る領域です。そういった陳腐化しにくいノウハウと、今ならこういった形で設計/実装するといったハンズオンをうまく組み合わせた書籍にできました。

また、今回都合上詰めきれなかった内容として、X-rayによる分散トレーシングやIaC (Infrastructure As Code) などがあります。IaCストーリーの著者としても、IaCコンテンツは是非とも届けていきたいので、今後はブログなどからCDKやTerraform、Pulumiで実装したIaCのソースコードも取り上げることができたらと考えています。

booth.pm

ぜひ、多くの方々の手に届き、色々なフィードバックやディスカッションをできればと考えています。ありがとうございました。

amzn.to

2021-06-27

Infrastructure as Codeに関する技術書籍を執筆しました(Part.2)

(2021.06.28更新) 物理本入庫しました！ booth.pm

Overview

非常に久しぶりのエントリとなります。タイトルの通り、Infrastructure as Codeに関する書籍を執筆しました。 A5版で122ページ、1500円で販売中です！

booth.pm

Part.2としているのはすでに共同執筆者の Masaya Arai (iselegant) (@msy78) | Twitterさんが概要と目次、少し書籍について触れたエントリをしているためです。

iselegant.hatenablog.com

私のエントリではその続きとして、目次の再掲とCloudFormation、CDKの章について少し触れていきます。

まずは目次についてです。今回、期間が短かったにもかかわらず執筆ブーストしたことでかなり盛りだくさんな内容になりました。本文に加えて、各IaCで作成したサンプルコードもつけているところがポイントです。また各章の書き口を可能な限り揃えることで読者の方が前の章と比較して読みやすいように意識をしました。

まえがき
第1章はじめに
- 1.1 Infrastructure as Codeとは
- 1.2 なぜInfrastructure as Codeが必要か
  - 1.2.1 構築における再利⽤性と冪等性
  - 1.2.2 コード〜ドキュメントにおけるパラメータ値の乖離
  - 1.2.3 改定証跡の担保
  - 1.2.4 アプリケーション開発者とのコラボレーション
- 1.3 本書の位置づけと構成
- 1.4 各章のサンプルコードで取り上げるAWS構成
- 1.5 本書で扱うバージョン情報
第2章 CloudFormation
- 2.1 概要
- 2.2 基本編
  - 2.2.1 CloudFormation のアーキテクチャ
  - 2.2.2 テンプレート
  - 2.2.3 スタック
  - 2.2.4 変更セット(Change set)
  - 2.2.5 CloudFormation の基本動作と基本⽂法
- 2.3 応⽤編
  - 2.3.1 クロススタック参照
  - 2.3.2 ドリフト検出
  - 2.3.3 CloudFormation Resource Import
  - 2.3.4 カスタムリソース
  - 2.3.5 その他
  - 2.3.6 注意すべき点
- 2.4 筆者のオススメポイント
  - 2.4.1 特殊なツールいらず
  - 2.4.2 定期的なドリフト検出による整合性の担保
  - 2.4.3 cfn-lint による記述内容のチェック
- 2.5 まとめ
第3章 AWS Cloud Development Kit
- 3.1 概要概
- 3.2 基本編
  - 3.2.1 CDK Toolkit
  - 3.2.2 Core Framework
  - 3.2.3 Construct Library
  - 3.2.4 AWS CDK の基本動作と基本⽂法
- 3.3 応⽤編
  - 3.3.1 クロススタック参照
  - 3.3.2 環境に応じた設定値の注⼊
  - 3.3.3 困ったときはL1 に変換する
  - 3.3.4 注意すべき点/制約事項
- 3.4 筆者のオススメポイント
  - 3.4.1 AWS CDK Roadmap が公開されている
  - 3.4.2 制御構⽂やエラーハンドリング、テストコード
  - 3.4.3 diff が簡単に確認できる
  - 3.4.4 少し⾵変わりなAspects という機能
- 3.5 まとめ
第4章 Terraform
- 4.1 概要
- 4.2 基本編
  - 4.2.1 Terraform のアーキテクチャ
  - 4.2.2 リソース作成までの流れ〜Write, Plan, Apply
  - 4.2.3 モジュールによるリソース定義の集約
  - 4.2.4 モジュール利⽤に必要な標準構成
  - 4.2.5 Terraform Registry の活⽤
- 4.3 応⽤編
  - 4.3.1 tfstate のバックエンド管理と排他制御
  - 4.3.2 リポジトリ統合によるCI/CD
  - 4.3.3 注意すべき点/制約事項
  - 4.3.4 さらなるプラクティスに向けて
- 4.4 筆者のオススメポイント
  - 4.4.1 ナレッジが⾮常に豊富
  - 4.4.2 多様なクラウド・PaaS・SaaS のプロバイダに対応
  - 4.4.3 Terraform Cloud やその他OSS ツールの充実
- 4.5 まとめ
第5章 Pulumi
- 5.1 概要
- 5.2 基本編
  - 5.2.1 Pulumi のアーキテクチャ
  - 5.2.2 リソース作成までの流れ
- 5.3 応⽤編
  - 5.3.1 ステートの管理
  - 5.3.2 Github Actions によるCI/CD 統合
  - 5.3.3 注意すべき点/制約事項
  - 5.3.4 プラクティス
- 5.4 筆者のオススメポイント
  - 5.4.1 IaC の中で最も⾃由度の⾼いサービス
  - 5.4.2 クラウドが提供するAPI を100% サポート
- 5.5 まとめ
第6章 IaCサービスの選びかた
- 6.1 どの IaCサービスもそれぞれの良さがある
  - 6.1.1 優れた開発者体験の重要性
  - 6.1.2 ビジネス要件への配慮　6.2 開発者体験を重視した評価軸からの考察
  - 6.2.1 言語の選択性
  - 6.2.2 ドキュメントや情報の充実さ
  - 6.2.3 シンプルで高速な開発
  - 6.2.4 コミュニティの充実性
- 6.3 ビジネス要件観点からの考察
  - 6.3.1 コンプライアンス要件
  - 6.3.2 コスト
  - 6.3.3 開発体制とサポート
  - 6.3.4 セキュリティ
  - 6.3.5 効率性
- 6.4 各IaC利⽤のユースケース
  - 6.4.1 CloudFormation を選択するユースケース
  - 6.4.2 AWS CDK を選択するユースケース
  - 6.4.3 Terraform を選択するユースケース
  - 6.4.4 Pulumi を選択するユースケース
- 6.5 よりよいIaCライフを送るために
  - 6.5.1 まずはIaC を試してみる
  - 6.5.2 事前に⼿作業でクラウドを構築してみる
  - 6.5.3 Dry Run が成功してもうまくいくとは限らない
  - 6.5.4 全リソースのIaC 化は本当に必要か
- 6.6 まとめ
付録A IaCのサンプルコード
おわりに

2章：CloudFormationについて

すこし書籍の内容に踏み込んで行きます。 2章では、AWSを使ってIaCをするときに真っ先に選択肢にあがる「CloudFormation」を題材として取り上げています。 CloudFormationを実行する流れと裏側の簡単な仕組みに加え、10年もの間の歴史を誇るなかで順次開発されてきた機能を応用編として取り上げました。運用をする際に役立つドリフト検出やカスタムリソースインポートなど、ユーザがIaCをする上で悩んでいた機能にも触れています。数年前にCloudFormationに触れていた人にとっては「こんな進化してるんだ！」となる機能が盛り沢山なCloudFormationです。

f:id:horsewin:20210627181304p:plain

3章：CDKについて

3章ではAWSが開発したOSSである、CDKに触れています。 CloudFormationでは実現できない、プログラミング言語でリソースを定義するIaCサービスです。プログラミング言語で各リソースを定義できることにより、大きく次のメリットがあります。

IDEによる補完の恩恵を最大限受けられる
デフォルト設定が組み込まれたAWS Construct Libraryといった抽象化部品の活用

特に2つ目のAWS Construct Libraryにより、CloudFormationと比較して記述量を圧倒的に減らしてシンプルにコーディングもできます。基本編からEscape hatchとしてCloudFormationのAPIをコールする使い方、ハマりどころなどについて触れています。個人的にはAWSでIaCをするならばぜひ勧めてみたいIaCサービスです。

f:id:horsewin:20210627181755p:plain

サンプルコード

本書には4つのIaCサービスのサンプルコードリンクを付録でつけてます。ちなみにサンプルコードで作成されるAWSリソースはこちら↓

f:id:iselegant:20210619225336p:plain

シンプルな構成ですが、一応ECS/Fargateのモダンな構成上に、Go言語APIをデプロイするためのリソースを一式作ってくれるものを用意しました。サンプルコードは全てCloud9で動かせるので、AWS上で完結します。 READMEにそれぞれの実行方法とかも載せています。本書で特徴を掴みながら、ハンズオン感覚でぜひ体験していただければと思っています。

最後に

今まで時間があったら書きたかった内容を今回共同執筆者の Masaya Arai (iselegant) (@msy78) | Twitterさんと夜中までともにブーストしながら書き上げました。我ながら良い内容になったと感じており、満足しています。表紙は前作と同じ方に可愛くしたててもらいました。本の内容と購入可能な経路は現在下記のとおりです。気になる方は是非お買い求めください。A5版で122ページ、1500円、別途サンプルコード付きです。

個人的には、ぜひIaC好きな人とお話しもしたいので、技術書典11オフラインイベントにお越し下さい！ではではー。

BOOTH

物理本は現在倉庫で入庫作業中です。物理本を求めている方は他の経路も参考にください。

(2021.06.28) 物理本入庫しました！ booth.pm

技術書典11

オンライン/オフラインともに参加予定です。オフラインイベントは7/11(Sun)に開催されます。オンライン/オフラインともに物理本も取り扱う予定です。

techbookfest.org

メルカリ

メルカリ分は2021/10/18現在、完売しています。

2020-03-29

AWS Code本（クラウドネイティブファーストストーリー）を書いて思ったブランチ運用の難しさ

出版してから約1ヶ月経過した、「クラウドネイティブファーストストーリー」関連のエントリーになります。私はメインでCodeシリーズによるCI/CDの話を書いたので、実際に運用する上での難しさを少し書こうかと思います。

umarai-books.booth.pm

Gitlab flowによる運用

本書では、「GitLab flow」を採用しています。理由としては、2つです。1つ目はGitHub flowは簡略すぎてリリース後の戻し戦略が組みづらく、並行開発が難しいため、gitflowかGitLab flowにしぼりました。2つ目は、gitflowは少し複雑性が高く頻繁なリリースに向いていないからです。

GitLab flowは適度にシンプルで、アプリケーション開発のライフサイクルにあったブランチ運用ができます。

異常系発生時の運用の難しさ

gitflowであろうが、GitLab flowであろうが何も問題なくリリース処理が進むときは特に苦はありません。運用の難しさが出るのは異常系が発生したときの運用です。

コードレベル

GitLab flowでは基本的にMaster→Pre-production→Productionとリリース成果物が流れていきます。 Pre-production、いわゆるステージング環境で緊急対応が必要なバグが発生した場合はどうするのでしょうか？現在の運用では、個別で緊急対応が必要なバグの場合、各環境（今回の例ではPre-production）でHotfixブランチを生成し、修正をします。ProductionへはHotfiwが反映されたバージョンをDeploy、MasterへはローカルへCherrypick（コミットIDをベースに修正内容を取得して反映）をした後に反映をします。

f:id:horsewin:20200329182833p:plain

ただし、この流れは緊急フローです。急ぎでないバグが見つかったときは、通常の運用に乗せて、local(featureブランチ）→Master→Pre-production→Productionという対処をすることになります。

アプリケーションレベル

こちらは本書でもいくつかパターンに分けて触れています。例えばデプロイ直後でバグが見つかった場合などはCodeDeployの機能をうまく使うだけで済んだりします。アプリケーションレベルになると、ブランチ運用による対処方法の違いは少ないですが、アプリケーションの正しさはコードにあります。コードにどのように修正を反映するかの考え方は上述のコードレベルの運用が重要なので意識しておく必要があります。

f:id:horsewin:20200329183336p:plain

まとめ

ブランチ運用はレガシーシステムであっても、クラウドネイティブシステムであっても重要な要素です。特にクラウドネイティブなシステムでは、デプロイの高速化もキーになるので、コードレベルの運用方法・デプロイされたアプリケーションの戻し方などの意識付けは大切ですね。このあたりのハンズオンもどこかで資料化できたらいいなぁ。

umarai-books.booth.pm

はじめに

書籍について

初版

増補改訂版

対象読者

目次

ハンズオンパートの紹介

Chap 05: AWSコンテナアーキテクチャの構築（基礎編）

Chap 06: AWSコンテナアーキテクチャの構築（実践編）

最大限の感謝を

さいごに

今回触れること、触れないこと

触れること

触れないこと

re:Invent 2023 Expo概要

Expoに出展している企業やプロダクトの分類

出展傾向から見える技術活用の傾向

変わらず強いセキュリティ

複数のプロダクトを扱うパートナーが多い

FinOpsがジワジワきている

人口知能(AI)が意外と少ない？

まとめ

今回触れること、触れないこと

触れること

触れないこと

CDKにおけるLambda開発の手軽さ

IaCコードとアプリケーションコードが近くにある

cdk deployによるシームレスなデプロイ

CDKプロジェクト下で開発したアプリケーションの動作検証

sam local invoke

sam remote invoke

論理IDを調べて指定するのはつらい

まとめ

今回触れること、触れないこと

触れること

触れないこと

cdk8sについて

cdk8sの概念図

cdk8sのしくみ

cdk8s+について

cdk8s+のしくみ

Pros&Cons

cdk8s, cdk8s+のいいところ

プログラマブルにマニフェストの作成が可能

環境ごとのマニフェストの切り替えも可能

Helmとの連携

CDKと連携したデプロイが可能

cdk8s, cdk8s+の苦手なところ

cdk8s単体ではデプロイはできない

デフォルト値とコントロールプレーンの設定の衝突

まとめ

はじめに

書籍について

本の概要

対象読者

本のメタ情報

目次

4章と5章を少しだけ紹介

Special Thanks

さいごに

Overview

目次

2章：CloudFormationについて

3章：CDKについて

サンプルコード

最後に

BOOTH

技術書典11

メルカリ

Gitlab flowによる運用

異常系発生時の運用の難しさ

コードレベル

アプリケーションレベル

まとめ

`cdk deploy`によるシームレスなデプロイ

`sam local invoke`

`sam remote invoke`