はてなブログタグとCDK / The epic of AWS CDK and Hatena Blog Tag

by aereal

Slide 1

Slide 1 text

はてなブログタグと CDK id:aereal @ AWS Cloud Development Kit -CDK- Meetup

Slide 2

Slide 2 text

• id:aereal • @aereal • ブログ統合チーム  テックリード

Slide 3

Slide 3 text

アジェンダ • CDKとわたし • CDKとはてなブログタグ • アプリケーションエンジニアから⾒たCDK

Slide 4

Slide 4 text

CDKとわたし

Slide 5

Slide 5 text

provisioning tool⼤好き • Ansible: MacやVPSのセットアップに • github.com/aereal/hanase • ⼀時期は毎⽉Macを初期化して最速セットアップソンが趣味だった • Google Deployment Manager • https://this.aereal.org/entry/2018/08/21/192317 • (Terraformはさわりだけ)

Slide 6

Slide 6 text

provisioning tool⼤好き • AWS CloudFormation (CFn) • はてなブログの⼀部システム構築でがっつり • もう1⼈のアプリケーションエンジニアと  スクラッチから書いた

Slide 7

Slide 7 text

https://speakerdeck.com/aereal/the-construction-of-large-scale-tls-certificates- management-system-with-aws

Slide 8

Slide 8 text

CDKとわたし • TypeScript⼤好き • 趣味でも仕事でも良く書いている • DPの頃に⾒つけて気になった • 社内のSlackで話題にしたのが2018-08-20 (〜v0.8.x) • 前述の通りCFnをがっつり触って「こうなっていたら」と思う点も⾒えてきていた

Slide 9

Slide 9 text

github.com/aereal/cdk-mackerel-container-agent mackerel-container-agentを追加するconstructs

Slide 10

Slide 10 text

はてなブログタグと CDK

Slide 11

Slide 11 text

http://staff.hatenablog.com/entry/2019/06/20/153000

Slide 12

Slide 12 text

“はてなブログタグでは、はてなキーワードの本⽂データ、はてなブログ・はてなブックマークのコンテンツを活⽤し、ある⾔葉についてネット上の意⾒や感想を知ることができます。”

Slide 13

Slide 13 text

サービスの技術構成 • インフラはすべてAWS上に構築 • コンテナ実⾏環境 (ECS) でアプリケーションをホスト • 複数の⼩さなコンポーネントからなる • API, SSR (= Server-side rendering) サーバ • データ移⾏⽤のバッチ

Slide 14

Slide 14 text

https://speakerdeck.com/aereal/the-technical-details-of-hatenablog-tag

Slide 15

Slide 15 text

front GraphQL API ϒϥ΢β DB ॳճGET SSRͷͨΊʹ  σʔλΛfetch CSRҎ߱  ௚઀fetch ͸ͯͳϒϩά ͸ͯͳϒοΫϚʔΫ

Slide 16

Slide 16 text

CFnを使う? • 紋切り型のコードが多い • e.g. Security Group • クロススタック参照を使う際に変更順序に気を遣う • 適⽤しようとして初めて「こっちを先に更新してね」と⾔われる • 差分チェックが……

Slide 17

Slide 17 text

CDKで! • ちょっと触ってとても楽しかった • たぶん⼤⼩様々なハマりは避けられないだろう、だったら少しでも楽しいことがあるほうが良い • Developer Previewだけど付いていく・貢献する覚悟を決めた • フレームワークとして筋の良さを⾒た (後述) • いざという時の脱出パスもある • cdk synthでテンプレートを出⼒できる

Slide 18

Slide 18 text

ECSデプロイとCDK • インフラ構成管理フレームワークであるCDKで  アプリケーションのデプロイまで⾯倒を⾒るべきか? • → はてなブログタグではCDKで管理することに (後述) • ちなみに: 他のオプション • ecs-cli, silinternational/ecs-deploy, kayac/ecspresso, etc.

Slide 19

Slide 19 text

アプリケーションのデプロイって? • ツールのレイヤリングから⾒るとOrchestration • ツール例: Capistrano, Fabric • ミドルウェアのセットアップは別のツールに任せる前提 • 例: Configuration: Chef, Puppet, etc. • 出典: https://conferences.oreilly.com/velocity/velocity- mar2010/public/schedule/detail/14180

Slide 20

Slide 20 text

• そのレイヤリング、今でもフィットするだろうか • たとえばEC2とLambdaのレイヤは違いそうだが、ツールも分けるべき? • AppSyncとかもっと⾼⽔準なものは? • コンテナのself-containedな性質と⾷い合わせが悪くないだろうか?

Slide 21

Slide 21 text

self-contained vs layered • ECS (コンテナ実⾏環境) はアプリケーション観点では⾊々なコンポーネントを隠してくれている • ⼀⽅、構成管理の観点ではECSを通してコンポーネント間の繋がりを意識しなくてはならない • ALB, VPC, Security Group, etc. • そこに明確に引ける線はない =  構成管理とデプロイのツールを分けないほうが得策

Slide 22

Slide 22 text

懸念 • ロールバックが遅くならないか? • 特に他のAWSリソースの更新を伴う時 • ⾮常時はecs-cliなどに頼れるようにする • 変更を切り分けやすいよう細かくスタックを分ける • そもそもAWSリソースの更新だけスキップして  アプリケーションが正常に動く保証もない

Slide 23

Slide 23 text

まとめ • はてなブログタグの構成管理はすべてCDKで⾏っています • ECSサービス・クラスタ、RDS、StepFunctions, Lambda, etc. • いわゆるインフラだけではなく  アプリケーションのデプロイもCDKで • いろいろデフォルトのプロジェクト構成から  変えていることもあるので質問お待ちしております

Slide 24

Slide 24 text

アプリケーションエンジニア  から⾒たCDK

Slide 25

Slide 25 text

• アプリケーションエンジニアならではの観点って? • ソフトウェアの抽象化に対するアンテナだと思います • そういった観点で魅⼒を紹介します

Slide 26

Slide 26 text

CDKと  clean architecture

Slide 27

Slide 27 text

• AWS Construct library • “This library includes constructs that represent all the resources available on AWS. For example, the s3.Bucket class represents an Amazon S3 bucket, and the dynamodb.Table class represents an Amazon DynamoDB table.” • CFnのresourceに相当する • Constructs • “Constructs are the basic building blocks of AWS CDK apps. A construct represents a "cloud component" and encapsulates everything AWS CloudFormation needs to create the component.” • 1つ以上のCFn resourceをカプセル化したもの • より⾼⽔準なインターフェース・機能

Slide 28

Slide 28 text

https://docs.aws.amazon.com/ja_jp/cdk/latest/guide/home.html

Slide 29

Slide 29 text

https://docs.aws.amazon.com/ja_jp/cdk/latest/guide/home.html AWS Constructs

Slide 30

Slide 30 text

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Slide 31

Slide 31 text

• AWS Construct library • infrastructure, external interfaces • Constructs • domain services, use cases

Slide 32

Slide 32 text

秩序⽴ったlayeringとその恩恵 • 関⼼の分離 • 普段はconstructsを触って背後のコンポーネントを隠蔽 • いざという時はAWS constructsに降りるとCFnの知識がそのまま活かせる • layerの性質に応じた効率化 • 例: AWS constructsはリソース定義からコード⽣成している • もしconstructsと別れていなければどこから⼈間が⼿を⼊れていいか判断しづらい

Slide 33

Slide 33 text

CDKへの期待 • Higher-order construct • constructsの変更はmutationを伴いpureではない • あるconstructを加⼯するリーズナブルなソリューションがほしい • 近いものだとAspectsがあるが、スコープを限定したい • https://docs.aws.amazon.com/ja_jp/cdk/latest/guide/ aspects.html

Slide 34

Slide 34 text

まとめ

Slide 35

Slide 35 text

• CDKはCFnのカバレッジの⾼さと⾼⽔準インターフェースが共存しており便利な上に筋の良い設計で将来に期待が持てる • インフラ構築が苦ではなく楽しい • フルスペックの抽象化を得て期待していたIaCが実現されていている • ⽣産性の⾼さを活かして絶賛開発中のはてなブログタグのリリースもお楽しみに