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

@ AWS Cloud Development Kit -CDK- Meetup

Transcript

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

   View Slide

2. • id:aereal
   • @aereal
   • ブログ統合チーム

   テックリード
   

   View Slide

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

   View Slide

4. CDKとわたし
   

   View Slide

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

   View Slide

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

   スクラッチから書いた
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. はてなブログ タグと
    CDK
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. https://speakerdeck.com/aereal/the-technical-details-of-hatena-
    blog-tag
    

    View Slide

15. front
    GraphQL API
    ϒϥ΢β
    DB
    ॳճGET
    SSRͷͨΊʹ

    σʔλΛfetch
    CSRҎ߱

    ௚઀fetch
    ͸ͯͳϒϩά
    ͸ͯͳϒοΫϚʔΫ
    

    View Slide

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

    View Slide

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

    View Slide

18. ECSデプロイとCDK
    • インフラ構成管理フレームワークであるCDKで

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

    View Slide

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

    View Slide

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

    View Slide

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

    構成管理とデプロイのツールを分けないほうが得策
    

    View Slide

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

    アプリケーションが正常に動く保証もない
    

    View Slide

23. まとめ
    • はてなブログ タグの構成管理はすべてCDKで⾏っています
    • ECSサービス・クラスタ、RDS、StepFunctions,
    Lambda, etc.
    • いわゆるインフラだけではなく

    アプリケーションのデプロイもCDKで
    • いろいろデフォルトのプロジェクト構成から

    変えていることもあるので質問お待ちしております
    

    View Slide

24. アプリケーションエンジニア

    から⾒たCDK
    

    View Slide

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

    View Slide

26. CDKと

    clean architecture
    

    View Slide

27. • 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をカプセル化したもの
    • より⾼⽔準なインターフェース・機能
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. まとめ
    

    View Slide

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

    View Slide