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

3f4be9784f765877f444bc839de29888?s=47 aereal
July 18, 2019

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

@ AWS Cloud Development Kit -CDK- Meetup

3f4be9784f765877f444bc839de29888?s=128

aereal

July 18, 2019
Tweet

Transcript

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

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

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

  4. CDKとわたし

  5. provisioning tool⼤好き • Ansible: MacやVPSのセットアップに • github.com/aereal/hanase • ⼀時期は毎⽉Macを初期化して最速セットアップソンが趣味 だった

    • Google Deployment Manager • https://this.aereal.org/entry/2018/08/21/192317 • (Terraformはさわりだけ)
  6. provisioning tool⼤好き • AWS CloudFormation (CFn) • はてなブログの⼀部システム構築でがっつり • もう1⼈のアプリケーションエンジニアと


    スクラッチから書いた
  7. https://speakerdeck.com/aereal/the-construction-of-large-scale-tls-certificates- management-system-with-aws

  8. CDKとわたし • TypeScript⼤好き • 趣味でも仕事でも良く書いている • DPの頃に⾒つけて気になった • 社内のSlackで話題にしたのが2018-08-20 (〜v0.8.x)

    • 前述の通りCFnをがっつり触って「こうなっていたら」 と思う点も⾒えてきていた
  9. github.com/aereal/cdk-mackerel-container-agent mackerel-container-agentを追加するconstructs

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

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

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

  13. サービスの技術構成 • インフラはすべてAWS上に構築 • コンテナ実⾏環境 (ECS) でアプリケーションをホスト • 複数の⼩さなコンポーネントからなる •

    API, SSR (= Server-side rendering) サーバ • データ移⾏⽤のバッチ
  14. https://speakerdeck.com/aereal/the-technical-details-of-hatena- blog-tag

  15. front GraphQL API ϒϥ΢β DB ॳճGET SSRͷͨΊʹ
 σʔλΛfetch CSRҎ߱
 ௚઀fetch

    ͸ͯͳϒϩά ͸ͯͳϒοΫϚʔΫ
  16. CFnを使う? • 紋切り型のコードが多い • e.g. Security Group • クロススタック参照を使う際に変更順序に気を遣う •

    適⽤しようとして初めて「こっちを先に更新してね」 と⾔われる • 差分チェックが……
  17. CDKで! • ちょっと触ってとても楽しかった • たぶん⼤⼩様々なハマりは避けられないだろう、だったら少 しでも楽しいことがあるほうが良い • Developer Previewだけど付いていく・貢献する覚悟を決めた •

    フレームワークとして筋の良さを⾒た (後述) • いざという時の脱出パスもある • cdk synthでテンプレートを出⼒できる
  18. ECSデプロイとCDK • インフラ構成管理フレームワークであるCDKで
 アプリケーションのデプロイまで⾯倒を⾒るべきか? • → はてなブログ タグではCDKで管理することに (後述) •

    ちなみに: 他のオプション • ecs-cli, silinternational/ecs-deploy, kayac/ecspresso, etc.
  19. アプリケーションのデプロイって? • ツールのレイヤリングから⾒るとOrchestration • ツール例: Capistrano, Fabric • ミドルウェアのセットアップは別のツールに任せる前提 •

    例: Configuration: Chef, Puppet, etc. • 出典: https://conferences.oreilly.com/velocity/velocity- mar2010/public/schedule/detail/14180
  20. • そのレイヤリング、今でもフィットするだろうか • たとえばEC2とLambdaのレイヤは違いそうだが、ツール も分けるべき? • AppSyncとかもっと⾼⽔準なものは? • コンテナのself-containedな性質と⾷い合わせが悪くない だろうか?

  21. self-contained vs layered • ECS (コンテナ実⾏環境) はアプリケーション観点では ⾊々なコンポーネントを隠してくれている • ⼀⽅、構成管理の観点ではECSを通してコンポーネント間

    の繋がりを意識しなくてはならない • ALB, VPC, Security Group, etc. • そこに明確に引ける線はない =
 構成管理とデプロイのツールを分けないほうが得策
  22. 懸念 • ロールバックが遅くならないか? • 特に他のAWSリソースの更新を伴う時 • ⾮常時はecs-cliなどに頼れるようにする • 変更を切り分けやすいよう細かくスタックを分ける •

    そもそもAWSリソースの更新だけスキップして
 アプリケーションが正常に動く保証もない
  23. まとめ • はてなブログ タグの構成管理はすべてCDKで⾏っています • ECSサービス・クラスタ、RDS、StepFunctions, Lambda, etc. • いわゆるインフラだけではなく


    アプリケーションのデプロイもCDKで • いろいろデフォルトのプロジェクト構成から
 変えていることもあるので質問お待ちしております
  24. アプリケーションエンジニア
 から⾒たCDK

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

  26. CDKと
 clean architecture

  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をカプセル化したもの • より⾼⽔準なインターフェース・機能
  28. https://docs.aws.amazon.com/ja_jp/cdk/latest/guide/home.html

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

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

  31. • AWS Construct library • infrastructure, external interfaces • Constructs

    • domain services, use cases
  32. 秩序⽴ったlayeringとその恩恵 • 関⼼の分離 • 普段はconstructsを触って背後のコンポーネントを隠蔽 • いざという時はAWS constructsに降りるとCFnの知識がそのまま活 かせる •

    layerの性質に応じた効率化 • 例: AWS constructsはリソース定義からコード⽣成している • もしconstructsと別れていなければどこから⼈間が⼿を⼊れていい か判断しづらい
  33. CDKへの期待 • Higher-order construct • constructsの変更はmutationを伴いpureではない • あるconstructを加⼯するリーズナブルなソリューション がほしい •

    近いものだとAspectsがあるが、スコープを限定したい • https://docs.aws.amazon.com/ja_jp/cdk/latest/guide/ aspects.html
  34. まとめ

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

    ⽣産性の⾼さを活かして絶賛開発中のはてなブログ タグ のリリースもお楽しみに