要点 

以前行った LambdaとIFTTTでBotの作成の続編として、アーキテクチャの改良を行いました。新しいアーキテクチャはAWS CDKで構成管理を行うようにし、SQSを追加することで耐障害性を向上させました。また異常時にはDiscordに通知するようにしました。

今夏に正式リリースされたAWS CDKの所感は、従来のCloudFormationの設定ファイルを書くこと無く、透過的にCloudFormationを扱うことが可能で、さらに学習コストも低いので非常に優秀なフレームワークでした。プロジェクトに存在するCloudFormationの醸成した設定ファイルを置き換える必要性は低いですが、新規作成していくのであれば、採用するに値するフレームワークだと考えています。

正式リリースされたのは今夏でまだまだ使用例は少ないですが、採用は今後どんどん増えていくと思います。

final

はじめに 

AWS クラウド開発キット(以後AWS CDK)が今年2019年の夏に正式リリースされた事を知りました。

AWS CDK使い心地を確かめてみるべく、以前行った LambdaとIFTTTでBotの作成を題材に利用してみました。しかし以前のままだとアーキテクチャ的にAWS CDKで扱う量が少なく、直ぐに終わってしまいそうだったため、アーキテクチャを改良して登場サービスを増やしました。

以下ではAWS CDKについての所感を述べます。またアーキテクチャの改良についても述べます。

AWS CDK 

まずAWS CDKとはなんぞやの前に、CloudFormationを知っておく必要があります。

https://aws.amazon.com/jp/cloudformation/

AWS CloudFormation は、クラウド環境内のすべてのインフラストラクチャリソースを記述してプロビジョニングするための共通言語を提供します。CloudFormation では、プログラミング言語またはシンプルなテキストファイルを使用して、あらゆるリージョンとアカウントでアプリケーションに必要とされるすべてのリソースを、自動化された安全な方法でモデル化し、プロビジョニングできます。これは、AWS リソースに真実の単一のソースを与えます。

CloudFormationはざっくり言うと、AWSで利用するサービス（リソース）をブラウザ上でポチポチ手動で用意するのではなく、設定ファイルに書いておけば勝手にやってくれるよ、というのがCloudFormationです。

利点などの詳細はドキュメントがあるので割愛します。CloudFormationはJSONやYAMLフォーマットで設定ファイルを書くわけですが、各設定項目を誤字無く、漏らすこと無く書かないといけないのでとても辛いです。

黎明期はJSONしかサポートしていなかったためコメントを書けないなど辛みは多々あり、最近はYAMLの登場やプラグインの補完などでマシになったと思います。しかしそれでも設定ファイルを直書きしていくのが辛い、と涙で枕を濡らす人は居ると思っています。

そこでAWS CDKです。

https://aws.amazon.com/jp/cdk/

AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースをモデル化およびプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。

AWS CDKはざっくり言うと、CloudFormationの設定ファイルを書くのが辛いので、プログラミング言語という抽象化レイヤーを用意したものです。つまりJSONやYAMLから開放され、プログラミング言語でコード補完を用いながら快適に、そして透過的にCloudFormationを操作出来るようにしたのがAWS CDKです。

以下では https://cdkworkshop.com/ で学習し、今回のアーキテクチャの改良を踏まえた計約半日〜1日程度触れての所感を述べます。

Github Repository 

fullname star star/day created_at updated_at license language description url
aws/aws-cdk 3,543 4.59 2017-10-04 2019-11-15 Apache License 2.0 TypeScript The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code link

学習コスト 

「ブラウザ上からリソースを作成する際の設定項目の理解度」「プログラミングスキル」に依存します。 ブラウザ上からリソースを作成する際の設定項目について意味を理解しており、若干のプログラミングスキルがあれば学習コストは殆どないと感じました。

学習コストは低いと思いますが、補完機能が効いても設定項目の意味がわからないと、流石に厳しいのかなというのが結論です。それはAWS CDKの学習コストというより、AWSの学習コストな気もしますが…。

使用感 

今回はTypescriptを用いてAWS CDKを利用しましたが、コードの補完機能とドキュメントを用いれば勝手に出来上がっていきます。というのもAWS CDKはあくまで設定ファイルの直書きをプログラミング言語で抽象化したに過ぎず、やっていることはとてもシンプルだからです。

Typescriptの場合はモジュールが細分化されているので、現在使っているモジュールにあってほしいメソッド(機能)が無い場合は、だいたい別モジュール化されているのでドキュメントを確認してインストールする、が基本路線です。それでなんとかなりました。

今後 

AWS CDKはconstruct librariesの仕組みがあるため再利用性が高いです。そのため今後はアーキテクチャのコード共有が進み、鉄板アーキテクチャの類はconstruct librariesとしてGithubなどに公開されて行くと思います。そうするとビジネスロジック部分をGit Submoduleで導入するだけで良くなり、より技術のコモディティ化が進むと考えています。

ただしAWS CDKは https://cdkworkshop.com/20-typescript/50-table-viewer/500-deploy.html#cdk-diff　にも書かれていましたが、非常に強い権限を持つがゆえにリスクも高いです。技術がコモディティ化すると敷居が下がることはメリットですが、悪意の持った攻撃を防げない人が増えることを意味しています。AWS CDKは影響範囲が甚大なので悪意のあるconstruct librariesに対し、コミュニティによる対策と使用者の自衛がとても大事になっていきます。

アーキテクチャの変化 

前回 

LambdaとIFTTTでBotの作成

元々はBotとしてTwitterに投稿できれば良いを達成するだけのアーキテクチャでした。使用するリソースを少なくする事でリソースが不要になった際の後片付けを簡単にしていました。

origin

改良後 

AWS CDKを導入してCloudFormationでリソースの一元管理を行うことにしたため、リソースが増加しても管理が楽になりました。そこでAWS CDKの使用感の確認も兼ねて、耐障害性の向上と異常時用にリソースを追加しました。

追加したリソースの大雑把な説明としては以下のとおりです。なおWebAPIからデータ取得し、IFTTTにデータを投稿するLambda以降は変化していません。

  • AWS CDK
    • CloudFormationを利用してリソースの一元管理
  • SQS
    • 耐障害性の向上
  • Alarm, SNS, Lambda
    • Alarmを起点にして異常時フローを形成
  • Discord
    • 異常時の通知先
    • Slackのようなチャットツール

final

以下の画像は実際に異常状態を発生させ、Discordに通知した時の画像です。 discord

AWS CDK関連 

この規模の場合、AWS CDKで生成したCloudFormationの設定ファイルは330行でした。しかしAWS CDKを用いてTypescriptで書いたコードは遥かに少なく済みました。だいたい100行程度ですが、クラスの定義や空行、メソッド呼び出し時の引数の改行などを除けば更に少なくなります。記述量が少ないことはとても良いことです！

また下記はAWS CDKでデプロイした際のログです。一応貼っておきます。ログからはリソース名は削除し、行数が多いので一部行も削除してあります。

  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::IAM::Role                  
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::IAM::Role                  
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::SQS::Queue                 
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::CDK::Metadata              
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::IAM::Role                  
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::SNS::Topic                 
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::SNS::Topic                 
  0/16 | 18:19:06 | CREATE_IN_PROGRESS   | AWS::IAM::Role                  
  0/16 | 18:19:07 | CREATE_IN_PROGRESS   | AWS::SQS::Queue                 
  1/16 | 18:19:08 | CREATE_COMPLETE      | AWS::SQS::Queue                 
.....（中略）
 13/16 | 18:20:19 | CREATE_IN_PROGRESS   | AWS::SQS::QueuePolicy           
 14/16 | 18:20:19 | CREATE_COMPLETE      | AWS::SQS::QueuePolicy           
 15/16 | 18:20:21 | CREATE_COMPLETE      | AWS::Lambda::EventSourceMapping 
 16/16 | 18:20:22 | CREATE_COMPLETE      | AWS::CloudFormation::Stack

おわりに 

アーキテクチャの改良を行い、AWS CDKでプロビジョニングするようにしました。

今夏に正式リリースされたAWS CDKの所感は、従来のCloudFormationの設定ファイルを書くこと無く、透過的にCloudFormationを扱うことが可能で、さらに学習コストも低いので非常に優秀なフレームワークでした。プロジェクトに存在するCloudFormationの醸成した設定ファイルを置き換える必要性は低いですが、新規作成していくのであれば、採用するに値するフレームワークだと考えています。

正式リリースされたのは今夏でまだまだ使用例は少ないですが、採用は今後どんどん増えていくと思います。 それと同時にIaaSのワードが再び盛り上がるでしょう。

なお、そもそもこのアーキテクチャで動かしているBotですが、Bot運用(ツイート開始)で約10日が経ち、その中でちょっと盛り上がったツイートのアナリティクスは以下の通りでした😃

origin