Developers.IO 2020のAWS CDK関連セッションを聞きました

-

まえおき

AWS CDKが使いたいです…。

私は今までCLI＆手作業でやってきたAWS関連業務をWebページのボタン1つでできるように簡略する業務を担当しています。何もないアカウントに環境を構築する業務が多いため、必然的にCloudFormationを多く使うようになります。CLIやGUI手作業で作成するよりは便利ですが、テンプレートを書いてると、「もうちょっといい方法ないかな…」と思う時がありました。例えば…

  • yamlの書き方があまり慣れない

    • 配列や連想配列などなど

  • サービスによって(例えば、API Gateway)書かないといけないものが多い

    • SAMを使えば一部解決はできますが…。

  • 使いまわしができない(For文など)

    • 例えば、名前は違うが設定が同じリソースを全部テンプレート書かないといけない

  • ミスの確認が難しい

    • vscodeやpycharmでcfn-lintを利用すればいいものですが、チームのデフォルトエディタはcloud9なんですよね…

  • Lambdaの場合は、事前にS3にアップロードするか、テンプレート内に記載しないといけない

    • S3の場合はzipしてS3にアップロードするPipelineを作ればできそうではありますが、テンプレート記載はメンテ辛いですよね…。

  • StepFunctionの場合は、コード(Amazon State Language)テンプレート内に記載しないといけない

    • これはS3にアップロードもできなく困ってました。あと、書き方にもちょっと苦労してましたね。
    • DefinitionS3Locationという属性がアップデートされてS3から定義ファイルを読んでくることが可能になりました。

といったことですね。

そう思っている中、AWS Cloud Development Kit (以下、CDK)が発表されました。 コードでAWSリソースを構築できるという点はとても魅力的でした。見た瞬間、「使ってみたい！」と思いました。


こんな感じでCDKに惚れてしまいました…。


AWS CDKの詳細な説明はドキュメントとBlackbeltの資料によく説明されています。

上記のドキュメントとBlackbeltを読み、担当業務にCDKを入れようとチームメンバーと相談しましたが、結論は「Cloudformationで十分じゃない？」ということになりました。覚えている変えたくない理由としては「学習コストと比べてメリットがあるか」、、「現在Cloudformationで構築しているリソースをどうするか(量は多くなかったんですが、余力がなかった)」ということがありました。あと、別のサービスでCloudformation+PipelineですでにCI/CDが動いていた点もありました。まだ、知識不足ということもありCDKの魅力を伝えられなかったんですね…。

 

Developers.IO 2020 CONNECT

Developers.IO 2020 CONNECTとはクラスメソッド社で主催する技術イベントです。クラスメソッドのエンジニアさんがAWSを始め様々な技術のトピックでお話します。今まではオフライン開催だったので、なかなか参加できなかってですが(トウキョウ…トオイ…)、今回オンライン開催＆Youtubeに動画アップとのことだったので、セッションを聞くことができました。今回はAWS CDK関連セッションが２つほどあったので、聞いて得られた知識でリベンジの武器にしたいと思いました。(T-shirtも少し欲しかったです…笑)

 

セッション

AWS CDK + Step Functions 入門(CX事業本部 佐藤直哉さん)

内容メモ

AWS Step Function

  • サーバーレスなワークフロー処理を作成できるサービス

  • ワークフローの全体の処理を「ステートマシン」と呼ぶ

    • ステートマシン内の処理単位はStateで７種類が存在する(Task,Wait,Parallel,Pass,Choice,Succeed,Fail)

  • 基本的にはTask Stateの組み合わせで作成

  • デバックやまだ実装はされてない処理にPass Stateが使える

  • 条件分岐するときはChoice Stateを使う

    • Succeed、Failと組み合わせができる

  • 動的並列処理(並列処理の数が動的に変わる)はMap Stateが使える

  • ステートマシンの内容はJSONベースのASL(Amazon State Language)で書く

    • 処理が複雑になると処理を追うのが大変、可読性が悪くなる
AWS CDK

  • プログラミングでAWSリソースを定義可能

  • Constructというライブラリがあり、Cloudformationよりも少ない行数で技術できる

    • AWSのベストプラクティスを抽象化してくれている
    • １つの言語の言語でCloudformationのリソースと独自言語(例えばStepfunction)の両方を技術できる。
AWS CDK+Step Function

  1. npmでCDKインストール(npm install -g aws-cdk)

  2. CDKプロジェクト作成(cdk init app -language=[language-name])

    • 自動生成されるlibフォルダ配下のファイルにAWSリソースの内容を記載していく

  3. Constructのインストール

    • npm install -d @aws-cdk/[resource-name]
    • 利用するAWSリソースごとにインストールする

  4. リソースを記述する

    • stepfunctionの場合、各Stateを定義し、スタートのStateから.next()でStateをつないでいく

  5. デプロイ

    1. npm run build(Cfnのテンプレート生成)
    2. npm run cdk deploy(AWS環境にデプロイ)
参考文献

感想

  • Step Functionは結構利用していましたが、Map Stateは知らなかったです。ちょうど作業のたびに作業回数が変わる定型作業があり、どうしようかなと悩んでいたところでしたが、Map Stateを利用すれば解決できそうで早く試してみたいです！
  • 実際に利用しているStep Functionを例にしてCDKにした場合の例を挙げてくださたので、ASLとCDKでの書き方の違いがとても理解しやすかったです。
  • 1つの言語で書けるということは確かにメリットありますよね。あと、JSONベースで可読性が悪くなるということも同感です。もうCloudFormationのテンプレートに書かれているStepFunctionのステートマシンの内容を見ると全然解読できない…。よくGUIのStepFunctionに入れて出される図を見て理解しています。

 

実践プロダクションサーバーレス - AWS CDK と TypeScript によるWebアプリケーション開発パターン(CX事業本部 和田祐介さん)

内容メモ

目的
  • サーバーレスアプリケーションをプロダクションデプロイするハードルを下げる
サーバーレスの得意なこと

  • サーバー責任モデル　→　サーバーレスはFaaSとマネジードサービスを組み合わせて作る

  • ビジネス効果

サーバーレスが苦手なこと
  • SFA, CRMといったリレーションによってデータを連携するタイプのシステム
  • 銀行システムのようなトランザクションが頻繁＆大量に発生するシステム
  • オンラインFPSゲームのような低レイテンシが求められるシステム
デプロイまでのステップとAWS CDK

  • 先にデプロイ可能な状態を獲得し、維持する

    • クラウドアプリでは実環境でしかわからないものが多い　→　一番の壁はデプロイと結合
    • 早めにデプロイをしてみて早い段階で壁にぶつかる

  • 開発前

    1. 要件がサーバーレスに合致していることを確認する

      • サーバーレスが苦手な分野ではないか
      • ビジネスサイトの協力が得られるか　→　ビジネス側を含めた全員の納得が大事
      • 事例紹介：SBGift様

    2. AWSアカウントへのサービスは位置を決める

      • アカウントは支払い単位、デプロイ設計の材料

      • 各環境(dev,stg,prd)ごと VS サービスごと

      • サーバーレスアプリケーションにはサービスごとにアカウントを作成することをお勧めする

        • アカウントごとのリソース上限に引っかかりにくい
        • アカウントランニングコスト＝サービスのランニングコスト
        • 新しいサービスを投入するときに既存のサービスを気にする必要がない

    3. 外部インターフェースを設計する

      • どういう形でサービスを使ってもらうか連携するか

  • 開発開始後(サーバーレスで開発を決める)

    1. AWS CDK採用を検討する

      • CloudFormationなら必要だったIAMの設定などが不要

      • クラウドリソースのデプロイもアプリケーション開発の一部となる

        • AWS CDKの場合、リソースの作成にも開発に利用している言語が使えるので、開発者の技術スイッチコストが減る

    2. ソースリポジトリを作ってデプロイする

      • パッケージ構成はyarn workspaceによるものレポがおすすめ

        • Packagesフォルダの配下にAWS CDKコード,lambdaコード,reactコードで分ける
        • それぞれ、またはまとめてビルドすることができる

      • Lambda Function と AWS CDKの連携

        • ビルド後のLambda Functionのパスを指定すればOK

    3. DEV,STG,PRD環境へデプロイできるようにしておく(サービスごとにアカウントを分ける場合)

      • AWS CDKでは環境変数が利用可能

        • 各リソースのデプロイ管理は、スタック名を環境ごとに変えることで可能になる

    4. デプロイ可能なCI/CDパイプラインを組む(AWS CodePipeline 利用)

      • dev環境は自動デプロイ,stg,prdは承認を挟む
      • CodePipelineの構築もAWS CDKで可能

  • デプロイ後

    1. AWS構成を設計する

    2. アプリケーションの実装

      • 必要に応じてLambdaのコードを書く

    3. PRDデプロイ

    4. 本番稼働

AWSでのアプリケーションパターン

  • AWS AppSyncによるBackend for Frontend

    • クライアントアプリケーションにGraphQL APIを提供する
    • Front側はBack側を意識せず利用可能

  • VPC Linkを利用したVPC内APIとの連携

    • 既存システムの一部をサーバーレスで置き換える場合に遭遇するケース

  • どうしてもJavaライブラリを使わなくてはならない

    • 他ベンダーの外部APIの利用方法で、JARを通すしかないケースなど
    • 全体をJavaにするか、最小限(実行するだけのJava lambdaを用意)にするか

  • Step Functionsを利用したサーバーレスジョブ

    • Labmda Functionを分解してジョブにする
    • 進行状況が知りたいときに有効
そしてモダンアプリケーションへ
  • 本番環境にデプロイしたアプリケーションは、お金を稼ぐことができる　→　変化への追随が必要

 

Q&A

  • CDKのアップデートに破壊的な変更があるときには運用に支障があると思うが、どう回避すればいいか

    • 基本的はアップデートがある場合はできるだけ、コードも変更してアップデートする
    • どうしてもコードをアップデートできない場合は、CDKのアップデートを保留する

  • CDKではIAMが自動生成されるが、ブラックボックスとなるのでセキュリティ的に不安

    • 書いたコードの動作に必要な最小構成のIAMが自動構成されるが、IAMを自分で定義してリソースにアタッチすることも可能

  • CDKはTypescriptで書く場合が多いと思うが、LambdaのコードもTypescript(node.js)で統一する場合が多いか

    • 案件やエンジニアの裁量による
    • Typescriptでは型があるので、メンテナンスの面でドキュメンテーションの役割を持たせられるのがメリット

  • Step functionsとSimple Work Flowの使い分け

  • Serverlessのメリットの誤解の解け方(例えば、コスト絶対安くなるんでしょうなど)

    • 要件定義のところで、サーバーレスの確認＆説明をし、全員が納得感を得るまで話しあう

感想

  • AWS CDKの「リソースのデプロイまで含めてアプリケーション開発の一部」という点では、インフラとアプリの境界がどんどん薄くなっていることを再び思いました。昔から言われてますが、インフラ屋もコードを書かないと生きていけない時代ですね。
  • yarn workspaceは新しい発見でした。うまく利用すれば、CI/CDのパイプラインも一つで済むかなと思いました。やはりTypescriptで統一か…
  • CDKの話だけではなく、サーバーレスのアプリケーションを作成するときに必要なステップ、注意点などを知ることができたのでよかったです！もうちょっと早めにこのセッションを見たかった…。

 

まとめ

２つのセッションですが、CDKの内容以外にも得ることが多かったです。やはりCDKってすごく魅力的だなと思いました。今回知ったCDKのメリットをいれて、もう一回チームメンバーの説得にチャレンジしようと思います！説得にはCDKに変えるコストを超えたCDKど導入するメリットの説明、既存のCloudformationで作成したリソースをどうするか、現在進行している開発とのスケジュール合わせなど課題は多いですが…。とりあえず、導入をしないことになっても勉強したCDKの知識は残るから！

あと、Developers.IO 2020 CONNECTにはまだまだたくさんのセッションがあるので、最近興味があるデータ分析や機械学習セッションを中心に続けていろいろ聞いてみようと思います。

 

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

-
イメージ
まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若干違うみ
続きを読む

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachineのドキュメントペ
続きを読む